Eric Turgeon, a GhostBSD alapítója és projektvezetője, egy blogbejegyzésben részletezte, miért cseréli le a FreeBSD-alapú BSD disztribúció az Xorgot az XLibre display szerverre. A GhostBSD kifejezetten asztali használatra készült, és bár a rendszer alapja a FreeBSD, több olyan összetevőt is használ, amely a Linuxos ökoszisztémából érkezik. Ez az évek során egyre több portolási és függőségi nehézséget hozott magával, főleg ott, ahol a Linuxon megszokott irányvonalak nem feltétlen esnek egybe a BSD irányvonalával. A bejegyzés szerint a Wayland térnyerése a mainstream Linuxon, valamint az Xorg körüli visszalépések együtt olyan helyzetet teremtettek, ahol beszűkültek a reális opciók, ezért a GhostBSD projekt az alternatív X szerverre történő átállás mellett döntött.
Tartalomjegyzék
Miért XLibre, és miért most?
A szerző úgy látja, a GhostBSD helyzete lényegesen eltér a Linuxos disztribúciókétól, mert FreeBSD-alapú rendszerként több, Linuxon általánosan elérhető összetevő nem áll rendelkezésre. Ezért a fejlesztőknek több energiát kell fordítaniuk arra, hogy a Linuxra szabott függőségeket FreeBSD-n pótolják vagy kiváltsák, ami kockázatosabbá teszi a hirtelen technológiai váltásokat, és inkább a fokozatos, kiszámítható fejlesztési lépések felé tereli a projektet. Úgy látja, hogy a Wayland sok projektben már jövőbeli irányként szerepel, miközben az Xorg körüli negatív fejlemények egyre nagyobb bizonytalanságot keltenek. Nem csak arról van szó, hogy lassan halad a fejlesztés, hanem arról is, hogy egyre nehezebb megítélni, mennyire marad hosszabb távon megbízható a klasszikus display szerver működése.
Az XLibre megjelenésekor a GhostBSD projektvezetője nem döntött azonnal a váltásról, előbb megvárta, hogy a projektből valóban életképes alternatíva lesz-e. Amikor ez egyértelművé vált, célzott tesztelés indult, majd a FreeBSD-s portolás elindulásával az XLibre bekerült a GhostBSD ports fájába is, még a FreeBSD hivatalos ágában történő megjelenése előtt.
A 26.01-es GhostBSD kiadás előkészítésekor még nem számoltak az XLibre-vel, az Xorg körüli egyre aggasztóbb hírek után azonban a fejlesztő úgy látta, hogy ha a kiadás továbbiakban is a hagyományos Xorgra támaszkodik, ez később nagyobb hibakockázattal és nagyobb karbantartási teherrel járhat, különösen ha verziófrissítésekről és a sérülékenységek javításáról van szó. A fejlesztő a döntést azzal indokolja, hogy jelenleg a GhostBSD még nem tud Waylandre átállni, mivel a BSD ökoszisztémában még nem működik.
Merre tovább? Kérdőjelek a MATE körül, lehetséges átállás a Gershwinre, és a projekt jövőbeni fenntarthatósága
A fejlesztő bizonytalannak tartja a rendszer alapértelmezett felületének számító MATE asztali környezet jövőjét: kevés az érdemi közösségi visszajelzés, és a elmúlt években a fejlesztési aktivitás is érezhetően visszaesett. Azonban a Wayland-támogatás bejelentése már egy olyan fordulópontnak tűnik, ami hosszabb távon meghatározhatja az asztali környezet irányát. A szerző a GTK 3-at kifejezetten kedveli, de nem látja biztosnak, hogy meddig marad problémamentesen használható. A GTK 4-et elfogadható iránynak tartja, ugyanakkor külön kiemeli, hogy a GTK 5 várhatóan már nem fogja támogatni az X11-et. Elméletben létre lehetne hozni egy külön X11-el kompatibilis ágat, a GhostBSD projekt mérete és a szűkös fejlesztői kapacitás miatt ez azonban aligha reális opció.
Joe Maloney visszatérése és az, hogy a Gershwin asztali környezet bekerült a GhostBSD-be, egy MATE-tól független irányt is reálissá tett. A szerző szerint a Gershwinből kinőhet egy hosszabb távon is vállalható asztali környezet,azonban a fejlesztő nem szívesen azonosul a jelenlegi fejlesztési iránnyal, amely jelenleg az Objective-C-t használja a szoftver fejlesztéséhez. Azt is megjegyezte, hogy a Gershwin MacOS-szerű kinézete sokakat elriaszt, ráadásul több részlete is kidolgozatlan, mivel egy meglehetősen friss projektről van szó, a külső megjelenés és a felület logikája azonban még alakítható.
Innen nézve a következő lépés nem egyértelmű: vagy tovább folytatják a MATE körüli elemek fokozatos lecserélését, vagy inkább a Gershwint helyezik előtérbe, és erre fordítanak több energiát. A helyzetet az is egyszerűsítené, ha a közeljövőben megjelenne a Swift-támogatás, mert az szélesítené a fejlesztési lehetőségeket az Objective-C mellett.
A fejlesztő a fenntarthatóságot nevezi meg a jelenlegi legnagyobb problémának: a projekt túl nagy, az ütemterv szerinte egyre nehezebben tartható, és nem biztos benne, hogy a GhostBSD megállna a saját lábán, ha ő a visszalépés mellett döntene. A fejlesztő a jövőben több feladatot is át szeretne adni más fejlesztőknek és jobban szeretné dokumentálni a munkafolyamatokat, mert enélkül a projekt könnyen a feledés homályába süllyedhet.
