dato che Pulseaudio sta per essere sostituito da un qualcosa di cui non ricordo il nome dato i suoi punti deboli
Pipewire? E no, non succederà a breve e francamente non sembra nemmeno che succederà. Pipewire era un'idea di uno sviluppatore Redhat, per creare un manipolatore di stream audio e video che coprisse i casi d'uso di Pulseaudio e Jack. Oltre a funzionare con Flatpak e gli ambienti containerizzati in generale e supportare lo streaming delle sessioni Wayland e una forma di screencasting sana.
Però non vedo una grande attività. Per cui Pulseaudio può dormire sonni tranquilli.
Che sia migliore di Xorg NO, è solo stato deciso a tavolino che il design server-client di un prodotto secolare andava contro il markenting.
Beh non esageriamo. L'utenza Linux è in gran parte aggratis e c'è ben poco marketing ( e guadagno ) da farci sopra. Xorg non va bene perchè (1) i driver DDX sono una botta in fronte da sviluppare e mantenere, (2) introduce una massiccia ridondanza con quanto presente nel kernel sotto forma di DRM e KMS, (3) ha dei bug by design ( come l'accesso al framebuffer da parte di tutti i client X e il buffer ghosting, che consente la lettura dei pixel prodotti da un'applicazione X anche se è stata chiusa ), (4) complicazioni col 3D accelerato a causa dell'indirect rendering che producono cose brutte come il tearing e creano grossi problemi ai giochi, oppure immagina l'era della VR ubiqua ma con Linux che arranca sugli FPS perchè Xorg manda i buffer a spasso tramite indirect rendering, (5) impossibilità di gestire configurazioni multihead in modo semplice ( bisogna taroccare il tutto con Xrandr ), (6) difficoltà nella gestione di sistemi multi-gpu, cioè avere un solo server X per N gpu, ognuna con un certo numero di monitor connessi, (7) impossibilità di fare l'hand-over del display ad altre GPU ( problema grosso per i sistemi Nvidia Optimus ) senza riavviare il server grafico.
La nascita di Wayland è stata necessaria per colmare queste mancanze. Già la sola implementazione del direct rendering via DRM, ha consentito di velocizzare il rendering delle applicazioni 3D pesanti, eliminare tearing e stuttering, ecc... Nonchè ridurre la codebase di milioni di righe di codice ( no, non scherzo ).
Hogsberg lanciò il progetto e parliamo dell'uomo che creò AIGLX per l'accelerazione 3D sotto Xorg. Credo che lui ne sappia parecchio di queste cose. E non è certo un megalomane, a cui piace fare cose inutili per pure sadismo.
E poi Android mica lo usa! Di fatto oggi è inutilizzabile, tranne per i contemplatori.
Ma non usa nemmeno Xorg. Quando Android fu lanciato, non esisteva Wayland. E Xorg era troppo pesante e poco appetibile per i vendor di dispositivi embedded. Tant'è che nel mondo embedded si sta rapidamente migrando verso Wayland. E non è escluso un Android con Wayland in futuro. Per ora SurfaceFlinger fa il suo lavoro. E nota che ci sono molte similitudini tra SurfaceFlinger e Wayland, soprattutto per il fatto di lasciare che i client renderizzino le loro view accedendo direttamente alle risorse 3D. Una manna per gli sviluppatori di driver, che possono occuparsi dello stack OpenGL/Vulkan, senza doversi concentrare sulle necessità del server grafico.
Wayland è un protocollo, ovvero un insieme di procedure che tutti dovrebbero seguire per la interoperabilità e per la gestione del sottosistema grafico. È un protocollo neutro, in quanto può essere usato da solo o sottostare a un server (ma tu guarda!, Canonical spinge dalla notte dei tempi l'uso di Mir quale display server sostitutivo di Xserver).
Ecco, semmai la questione dei buchi nella specifica andrebbe affrontata. Drew DeVault, il creatore di SwayWM e Wlroots ( uno dei migliori e più completi compositor Wayland in circolazione ), ne ha a pacchi di critiche a riguardo. Però ammette pure che c'è stato bisogno di far maturare il progetto, man mano che i problemi venivano a galla. Cioè, sulla carta sembra tutto ok, poi nel mondo reale ti accorgi che manca questo o quello e ci sono cose che proprio non vanno e bisogna sostituirle/modificarle.
Il bello è che Wayland, essendo solo un compositor, rende abbastanza semplice queste modifiche. Un client che rispettava una parte non modificata delle specifiche, non dovrà fare nulla per continuare a rispettarle e girare sotto Wayland.
Ad oggi, dopo aver fatto delle prove personalmente, tra Gnome, Kde e Sway solo Gnome è risultato utilizzabile con Wayland. Sway è risultato il peggiore, in pratica inutilizzabile.
Gnome ha Redhat dietro. Kde è un progetto no-profit, basato su Qt che pure ha problemi di suo ( chi usa Qt per programmare, sa quanti bug insidiosi restano lì per anni ).
Mi pare strano che Sway non funga. Personalmente ho avuto problemi su GPU Nvidia, ma questo perchè Nvidia si rifiuta di supportare GBM in favore del suo EGLstream.
Io sono certissimo che anche tra dieci o vent'anni Linux non riuscirà a prendere il posto di Android, è già troppo tardi.
Soldi e accordi commerciali. Alla fine Android è Linux. Ma con dietro Google, i suoi dollari, le sue legioni di ingegneri, i suoi avvocati, i suoi lobbisti. Bazzico l'informatica dagli anni '80 e ho puntualmente visto prodotti ed aziende scarsi avere la meglio su prodotti fenomenali.
Se bastasse la bontà tecnica, oggi useremmo tutti BeOS.
E sinceramente non posso aspettare una nuova tecnologia su cui c'è ancora tanto lavoro da fare. Non appena mi toccano Xorg io passo in seduta stante a Windows 10 e a tutte le sue schifezze (e mi fa sempre più schifo).
Xorg non se ne andrà. Ma lo sviluppo è congelato. Nessuna innovazione arriverà in Xorg. E verrà progressivamente sostituito da Wayland fino alla deprecazione e alla successiva morte.
Passare a Windows 10 per via di Wayland, è come tagliarsi i gioielli di famiglia per far dispetto alla moglie. Avere il naso di Bill che esce dal mio monitor...no grazie!
E comunque è un discorso ozioso, visto che il phase-out di Xorg durerà chissà quanti anni.
