X11(Meestal XFree86) vervangen door 'Y' ?

[Verwijderd]

Spider.007 schreef op 20 februari 2004 @ 16:10:
[...]

Het punt is dat al deze zaken (acceleratie, anti-aliassed) erbovenop zijn gezet; terwijl dingen als netwerk-ondersteuning zijn uiteraard goed zijn om te hebben maar vooral voor thuisgebruikers is het redundant dat het als basis al is opgenomen in X. Hier is dus vooral sprake van overhead.

[snip]

Volgens mij is Y ook netwerk transparant, of heb ik dat soms verkeerd begrepen?

[HarmoniousVibe]

Met X is niet veel mis, met de meestgebruikte implementatie, Xfree86, echter wel. Deze is idd traag en instabiel etc. Ik denk dat men, zeker op de middellange termijn, moet kijken naar betere implementaties van X, zoals Xouvert of die van freedesktop.org (kdrive oid?). Hierdoor blijft alles wel een beetje compatible met elkaar.

Niet dat ik niet vind dat het een goed inititiatief is, maar ik denk dat het geen waanbeeld is dat X nog lang zal blijven voortbestaan.

[Verwijderd]

LB06 schreef op 20 februari 2004 @ 21:54:
Met X is niet veel mis, met de meestgebruikte implementatie, Xfree86, echter wel. Deze is idd traag en instabiel etc. Ik denk dat men, zeker op de middellange termijn, moet kijken naar betere implementaties van X, zoals Xouvert of die van freedesktop.org (kdrive oid?). Hierdoor blijft alles wel een beetje compatible met elkaar.

Niet dat ik niet vind dat het een goed inititiatief is, maar ik denk dat het geen waanbeeld is dat X nog lang zal blijven voortbestaan.

Zucht...ik denk dat jij met traag bedoeld de DE's of de window managers die er op draaien...probeer eens X te starten in failsafe mode, dus zonder wm en start dan XMMS, da's snel, dus de problemen moeten denken ik ergens anders gezocht worden. Y is een manier van aanpakken door gewoon de toolkit al direct op te nemen in de server ipv "bloated" GTK2 of QT. ze hebben beide voor en nadelen dus ik denk juist dat dit soort initiatieven juist aangemoedigd moet worden, survival of the fittest.

[Verwijderd]

Traag is onzin:
1) Die paar indirectiestappen maken op moderne hardware niets meer uit -- in moderne software engineering kan je bijna niet genoeg abstraheren, ook als dat wat extra overhead oplevert. Zeker als het 2D applicaties betreft. (zoals het meeste windowing spul)
Verder lijden de beschikbare commerciele windowing omgevingen onder het zelfde "euvel". Naar mate de complexiteit hoger wordt heb je meer overhead.
Dit is net zoiets als zeggen "een gemiddelde gebruiker draait maar 1 applicatie tegenlijk, dus laten we multithreading maar uit het besturingssysteem slopen".

2) Network transparency word al omzeild als jij een applicatie op dezelfde pc als dezelfde user draait. In dit geval wordt er gebruik gemaakt van shared memory; sneller kan niet. En met de extensie DGA kan je zelfs directe toegang krijgen tot de frame buffer. GLX werkt ook in "direct mode". (dat het ook over het netwerk kan is alleen maar een bonus)

En XF86 instabiel? Oke, er zullen bugs in zitten door de inderdaad bloated code, maar het staat niet algemeen bekend als instabiel. Sommige mensen schijnen de neiging te hebben elke grafische omgeving instabiel te noemen. De meeste instabiliteit komt door hardware combinaties en hardware drivers.
Verder heeft instabiel inderdaad niets te maken met het protocol.

Ik hoop er ook op dat iemand eens de code van XF86 op zou poetsen, het grootste probleem bij dat soort projecten (kdrive et al) is de driver ondersteuning van ATI en NVidia, helaas.
Vooral dankzij hen heeft XF86 nog de 'monopoly' positie.

De widget toolkit opnemen in de server is het hele open source keuzevrijheid idee om zeep helpen. Ik zie het nut van op die manier 'dwingen' een bepaalde toolkit te gebruiken niet in. Ik ben zelf een voorstander van GTK2, en zal het niet leuk vinden als iets QT-achtigs werd geintegreerd. Andersom zou een QT-liefhebber afdruipen bij de keuze GTK2. Er een 'neutrale laag' onder planten is dus een ideale beslissing. X heeft dit al.

Hoe dan ook, ik denk dat Linux developers beter kunnen werken aan applicatie support om het aantrekkelijker te maken voor end users (GNOME,KDE), dan de onderliggende windowing laag.

[ Voor 16% gewijzigd door Verwijderd op 21-02-2004 12:11 ]