É um trabalho monstruoso, mas será um trabalho que os desenvolvedores do Cinnamon terão que realizar mais cedo ou mais tarde, caso contrário eles estarão utilizando uma interface baseada em um servidor gráfico abandonado. O desenvolvimento do Xorg está estagnando mais e mais e daqui para frente só vai piorar.
Vejo o XFCE conseguindo fazer a transição de forma tranquila devido a simplicidade da interface, tanto que eles já portaram o app Catfish (buscador de arquivos) para o Wayland. Já o Clem vai ter que se virar para transicionar o Cinnamon. Vai ser uma loucura.
Sim, no Ubuntu também tem um fork, mas não é parte do GNOME, é uma extensão justamente. Nesse caso seria trabalho de quem desenvolve a extensão ou quem envia ela com o sistema de compatibilizar se querem que seja usada com o Wayland.
Também considero, como a maioria aqui até agora, um exagero dizer que se trata de abandonware. Até porque o linux ainda é usado em muito hardware antigo que provavelmente não está nos planos do wayland suportar. E até porque tem outros SOs, como BSD que ainda usam (nesses não sei se vão migrar para wayland agora ou no futuro).
Que o Wayland substituirá o Xorg é quase certo, mas não vai ser tão próximo, como o Wayland tem diversas limitações, elas precisam ser contornadas pelo compositor e fazer isso sem alguém por trás incentivando ($)
Na verdade, tá bem complicada a situação
Na verdade, eles portaram pro GTK 3 que tem suporte “automático” ao Wayland, mas isso não funciona em dois apps em particular que são o core pra um port do Wayland: XFWM e XFPanel, nas palavras do mantenedor:
Improvável que tenhamos mão-de-obra para fazer do XFWM4 um compositor wayland,
é claramente muito trabalho…
Mas se estivéssemos, ou usaríamos Mutter ou libweston.
O primeiro significa
que mataríamos xfwm4 inteiramente e transformaríamos o painel xfce4 em um shell como gnome-shell -
Não tenho certeza se é isso que eu gostaria…
Olivier.
Definitivamente e eu compreendo isso, mas pode muito bem servir como alerta, porque ter mais de 2300 issues abertos em um projeto não é um bom sinal. Os issues não estão sendo monitorados? Por que tantos estão abertos?
Mas entendo o ponto, alterei a postagem para ficar mais coerente.
Com certeza, por isso que eu disse que só o tempo dirá, mas de qualquer forma, um dia que se passa é um dia mais perto
Então é mais um projeto que vai sofrer com a transição
Uma colocação sobre o Xorg que eu acho tipo quase uma martelada, quando acabar o suporte no RHEL8 o X vai perder importantes desenvolvedores para o wayland, para RH/Fedora Xorg já está em modo de manutenção difícil, kkkk é a culpada como sempre é?
Acertou, NVIDIA. https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
Finally there is the NVidia binary driver support question. So you can run a native Wayland session on top of the binary driver and you had that ability for a very long time. Unfortunately there has been no support for the binary driver in XWayland and thus and X applications (which there are a lot of) would not be getting any HW accelerated 3D graphics support. Adam Jackson has worked on letting XWaylands load the binary NVidia x.org driver and we are now waiting on NVidia to review that work and hopefully be able to update their driver to support it.
Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.
The Fedora Workstation project is something we made using those tools and it has been tested and developed as an integrated whole, not as a collection of interchangeable components. The Fedora Workstation project might of course over time replace certain parts with other parts over time, like how we are migrating from X.org to Wayland. But at some point we are going to drop standalone X.org support and only support X applications through XWayland. But that is not the same as if each of our users individually did the same. And while it might be technically possible for a skilled users to still get things moved back onto X for some time after we make the formal deprecation, the fact is that you would no longer be using ‘Fedora Workstation’. You be using a homebrew OS that contains parts taken from Fedora Workstation.
Usei wayland a primeira vez em 2012 em um Pentium E5700 com placa nvidia on board, nessa época mesmo utilizando o driver gallium (renderização por software) rodava tranquilamente, fedora 20 e Debian 7 se me lembro.
Acho que praticamente todos. O OpenGL ES 2.0 e um driver no kernel é o requisito mínimo para a maioria dos compositores Wayland usarem a placa gráfica, e todas as GPUs Intel integradas de 2008 em diante têm os dois no Linux.
Pra GPUs sem um dos dois, ainda dá para usar o Wayland, mas rodando direto na CPU, sem ajuda da placa gráfica.
MAs leva mas tempo do que isso. O 32 bits tá começando a cair agora, se cair de fato. Agora no Kernel 5.10 que desativaram uma função que foi implementada para dar suporte a 286, salvo engano.
Eu tinha visto este artigo e sou obrigado a concordar. Infelizmente o XOrg se tornou um mal necessário, se transformando em um tapa buraco em momentos em que o Wayland dá problemas.
Não exatamente, a NVIDIA é responsável pelas distros não adotarem por padrão, mas os desenvolvedores não conseguirem portar os compositores do X11 pro Wayland é culpa do Wayland
Xorg é software legado, não abandonado, e deve continuar assim enquanto o Wayland e softwares dependentes do mesmo não sairem de um estado beta… Comunidades opensource deveriam se acostumar a dar estas garantias de QA.
Honestamente, a transição do Xorg para o Wayland está sendo uma das mais ortogonais transições de software legado para novo que eu já vi no mundo open source, gostaria muito que tivessem tido essa visão nas transições de versões de DEs como KDE e GNOME, lembro muito bem o caos e frustração que foi do KDE 2 -> 3 -> 4 e GNOME 2-> 3.
Não estou dizendo que o wayland não tem bugs, infelizmente vão surgir muitos bugs quando as distros populares adotarem, agora se uma distribuição não faz os testes da sua interface no wayland aí já é outra história, seu usuário está ciente que o servidor X escolhido é o padrão, como é o caso do Pop_OS que nem tem uma entrada para sessão wayland pois buga tudo.
Me parece que o XOrg está no limite da sua filosofia de programação. É como melhorar o notebook ao máximo dentro das possiblidades da placa mãe, mas pra fazer coisas diferentes precisa começar do zero. Esse zero é o Wayland, uma nova filosofia.
Acho injusto falar que que é Abandonware, pois funciona muito bem dentro de suas limitações.
Estou com um bug no Wayland no KDE, quando eu inicio a sessão Wayland e abro menu iniciar, o PC trava tudo. Tenho uma placa de vídeo gforce 210 e to usando o drive nouveau.
Por que os desenvolvedores do Wayland precisam garantir isso? Até onde está escrito, o Wayland é uma tecnologia (servidor gráfico) diferente do X11. Essa lógica, aos meus olhos, não faz sentido (ou faz? ).
).