Onderzoeker vindt 200 beveiligingsproblemen in X.org

Een Belgische beveiligingsonderzoeker heeft zonder veel moeite 200 beveiligingsproblemen gevonden in X.org, de displayserver die in de meeste Linux-distributies wordt gebruikt. Zo'n 120 bugs bevonden zich in het deel dat als root wordt gedraaid.

Bij 80 kwetsbaarheden ging het om bugs in de X.org-server. "Er is heel veel slechte code", zo zei de Belgische beveiligingsonderzoeker Ilja van Sprundel, die zijn bevindingen op de CCC-hackersconferentie in Hamburg uit de doeken deed. "Dit is alleen nog maar het laaghangend fruit." Van Sprundel had een week nodig om de bugs in de X.org-client te vinden, hoewel het vinden van de serverbugs meer tijd kostte.

"Veel code is dertig jaar oud en niet voorbereid op de manier waarop X.org vandaag de dag wordt gebruikt", stelt de onderzoeker. Zo kan X.org op sommige punten crashen bij het wegschrijven van bestanden van 4 gigabyte; in de dagen dat X.org was ontworpen was het wegschrijven van bestanden van die grootte ondenkbaar, maar vandaag de dag al lang niet meer. Software-crashes zijn een beveiligingsprobleem, omdat ze soms door malware kunnen worden misbruikt om eigen code uit te voeren. Van Sprundel heeft geen exploits ontwikkeld, dus of de bugs daadwerkelijk door kwaadwillenden kunnen worden misbruikt is niet bekend.

De meeste kwetsbaarheden in de X.org-server moeten nog worden gepatcht; bij het gros van de client-kwetsbaarheden is dat al gebeurd. In de meeste gevallen ging het om variabelen waarvan de input niet werd gecontroleerd. Daarmee zouden ze kunnen worden gebruikt voor het uitvoeren van malafide code. Vooral bij de X.org-server, die met root-rechten opereert, is dat een probleem. Een aanvaller die al van een beveiligingsprobleem in andere software misbruik maakt, zou via de X.org-server dan root-rechten kunnen verkrijgen, wat de impact van de aanval vergroot. "Ik geef weinig informatie vrij over de bugs in de X.org-server, omdat ze nog moeten worden gepatcht", aldus Van Sprundel.

X.org is de displayserver van veel Linux-distributies, waaronder het populaire Ubuntu, al is die distributie wel bezig met zijn eigen displayserver. De displayserver is in Linux-distributies en andere op Unix gebaseerde besturingssystemen verantwoordelijk voor het op het scherm tekenen van de grafische interface. De X.org-server bestaat uit clients en een server, waarbij de clients doorgeven aan de server wat er op het scherm moet worden getekend. De X.org-client wordt vooral gebruikt als onderdeel van een toolkit, zoals GTK van Gnome of Qt van KDE. Volgens Van Sprundel zijn ook die implementaties van de client echter zo lek als een mandje.

De Belgische onderzoeker is het minst te spreken over de code van de OpenGL-extensie in X.org. Die is volgens Van Sprundel 'onvoorstelbaar slecht'. "Het is een eindeloze stroom aan crap", aldus Van Sprundel. "Het is verschrikkelijk en broken beyond repair." Zo wordt geheugen niet goed gealloceerd en zijn er geheugenlekken, die kunnen worden misbruikt voor het uitvoeren van malafide code. Ook de ondersteuning voor lettertypen is volgens Van Sprundel 'erg slecht'. De X.org-ondersteuning voor het tekenen van teksten wordt zelden nog gebruikt, maar is wel nog aanwezig.

Volgens Van Sprundel wordt X.org de komende jaren nog niet door iets anders vervangen, en is het daarom belangrijk dat bugs worden gevonden en opgelost. Hij is wel te spreken over de manier waarop het X.org-team bugmeldingen oppakte. "Er werd niet relativerend gereageerd, zoals nog wel eens gebeurt", aldus Van Sprundel.

Reacties (185)

[Verwijderd]

Daar gaat de theorie die veel mensen gebruiken dat je bij Linux de code kunt bekijken en het dus daarom wel veilig zal zijn. Als één onderzoeker al zoveel bugs weet te vinden dan weten onderzoekers van veiligheidsdiensten deze bugs ook wel te vinden met het doel natuurlijk om een kijkje te kunnen nemen op die Linux systemen.

[Nardon]

Iedereen weet dat X.org onderhand qua code niet echt bruikbaar meer is.. het is ook een gigantisch project en ook ongelofelijk ingewikkeld geworden in de loop der tijd. Na 30 jaar bevat het project een hoop oude code die al lang niet meer gebruikt word, maar ook nog niet is verwijderd. Het is bijna niet te doen om dat op orde te krijgen en zou een volledige herschrijving van de kern betekenen.

Daarom zijn ontwikkelaars nu bezig met een opvolger van de X server, namelijk Wayland. Deze is moderner en heeft al die problemen niet. Daarnaast is Canonical voor Ubuntu ook begonnen aan hun eigen display server Mir. Dit oude systeem word dus nu al langzaamaan uitgefaseerd.

[Reactie gewijzigd door Nardon op 24 juli 2024 21:43]

[BartOtten]

Waarbij Mir de boel wel weer in de wielen rijdt want straks moeten fabrikanten OF kiezen of DUBBEL ondersteunen. Heel vervelend van Canonical.

[sfranken]

Niet echt want Mir zou Wayland/Weston drivers moeten ondersteeunen.

[TheVivaldi]

Precies. En anders kun je altijd nog XMir gaan ondersteunen. Dan hoef je nauwelijks je X-code te wijzigen en heb je tóch Mir-ondersteuning naast (X)Wayland-ondersteuning. Is geen definitieve oplossing maar de komende paar jaar zal het in ieder geval voldoen.

[sfranken]

Xmir is een tijdelijke en lelijke work around voor gebrek aan compatibiliteit voor mir.

[mcDavid]

Het voordeel blijft, want in dit geval heeft deze onderzoeker de bugs aan het licht kunnen brengen, terwijl bij closed-source software alléén de veiligheidsdienst die zich (voor heel veel geld of gewoon illegaal) toegang tot de broncode verschaft heeft, dat zou kunnen.

[Reactie gewijzigd door mcDavid op 24 juli 2024 21:43]

[Tourmaline]

Het is juist gemakkelijker voor de beveiligingsdiensten daar dit gewoon gratis te downloaden is! Je doet je voor als een developer en je walware/backdoor wordt geimplementeer. Makkelijker kunnen ze het niet maken.

[ClementL]

Je kunt niet zomaar ongemerkt exploits installeren, projectleiders controleren code voordat het gemerged wordt.

Daarbij is er hier sprake van bugs, die het dus mogelijk maken dat een extern programma het proces compromitteerd. Op het moment dat je de broncode aan moet passen om een beveiligslek te creëren, is het geen lek. Op die manier zou je zelfs het meest perfecte programma onveilig kunnen maken.

[Reactie gewijzigd door ClementL op 24 juli 2024 21:43]

[Ergomane]

> Je kunt niet zomaar ongemerkt exploits installeren, projectleiders controleren code voordat het gemerged wordt.

Wat mij als code reviewer van een OSS project soms wakker houdt zijn zeer subtiele bugs die mogelijk doelbewust met functionele patches worden ingebracht.

De underhanded C contest geeft een idee van wat ik bedoel.

[Tourmaline]

Goed om te horen in ieder geval dat de community alles in de gaten houdt en dat niet zoals bij vele commerciële software bewust bugs en backdoors ingebouwd worden.

De vraag is echter of de NSA de bugs al niet misbruikt. Zij zitten ook niet te slapen en zullen ook al op de hoogte zijn van wat er in de community speelt!

Of ben ik nu toch wat te paranoide aan het worden na al die verhalen over de NSA....Als je dat ander bericht leest en hoort dat ze zelfs pakketten van amazon e.d. openmaken en voorzien van malafide hardware...Ze deinzen nergens meer voor terug!

Maar hoe veilig is je OS nog als ze zelfs op 16km afstand je zaken nog kunnen uitlezen...Er is alleen een geïnfecteerde usb stick voor nodig en je hele veilige OS werkt al niet meer!

Ik denk niet dat ze na 30 jaar niet een van die bugs hebben misbruikt bij de NSA! Ze hebben zo te lezen alles gekraakt en misbruikt, dus vast ook Linux!

Het lijkt mij een beetje naïef om te denken dat alleen Linux veilig is! Dat blijkt wel uit het feit dat na 30 jaar nog 200 bugs zijn gevonden.
We kunnen slechts hopen dat dat niet bewust is gebeurd!

[Reactie gewijzigd door Tourmaline op 24 juli 2024 21:43]

[aswelter]

Gisteren nog een stuk gelezen over het inbouwen van de backdoor in de compiler zelf. Schijnt de oplossing te zijn tegen wakkere code reviewers. Als het niet zo treurig was had ik achter de vorige zin een gezet helaas rest vandaag de dag alleen nog een

[Tourmaline]

Zie, ik zat er helaas dus toch niet ver vanaf! Ik ben er helaas niet zo blij mee dat ik gelijk blijk te hebben. Niets, maar dan ook niets blijkt meer veilig of heilig te zijn.

[Reactie gewijzigd door Tourmaline op 24 juli 2024 21:43]

[joepurlings]

Jaja, wijzigingen doorvoeren in grote open source projecten gaat toch wel wat gecontroleerder dan het aanpassen van een wikipedia item...

[Tourmaline]

Vast wel als er slechts een handjevol ontwikkelaars zijn. Of wil je beweren dat je exact weet wat de code van linux doet. Ook kun je de downloads vervangen voor gemanipuleerde exemplaren. Simpel toch. Dit gebeurd soms al bij gehackte websites.

[Reactie gewijzigd door Tourmaline op 24 juli 2024 21:43]

[Verwijderd]

Nee dat kan niet, ja dat kan bij jezelf, maar als je het probeert terug te brengen in de cominuty dan gaat het versie controle systeem (git) zeuren.

Tenzij je het commit, maar dan moet je een naam en email adress opgeven. En als de beheerders er 1 keer achter komen dat je kwaad in de zin hebt. Dan accepteren ze je patch simpelweg niet meer.

Xorg is ouder als linux zelf. het is in de linux commiunty bekkend dat crap is. Punt is dat er door de jaren heen heel veel software afhankelijk van geworden. En al wanneer er een vervang komt zoals wayland/weston of mir, moet al deze software worden aangepast. Wat een monsterlijke klus is.

De reden dat de kwaliteit zo slecht is, is vrij simpel: In al de jaren dat xorg met de tijd mee werd gehacked door verscheindende mensen, is het protocol nooit aangepast. Dit is ook meteen de reden waarom er zoveel software voor is.

Daarnaast is de noodzaak van een goede display server niet zo essentieel voor linux als dat het is voor bijvoorbeeld windows. De desktop markt (inc laptops) is een zeer kleine fractie van alle machines die linux draaien. Android gebruikt bijvoorbeeld geen X, daarnaast instaleert men doorgaans op hun servers ook geen display server (anders lachen mensen je uit). voor super computers is dit al helemaal niet nodig. en embeded systems zoals auto's of routers hebben simpelweg geen grafische kaart dus ook geen display server nodig.

[Blokker_1999]

Alleen word code vaak niet rechtstreeks van een developer site gedownload. En diegene die dat wel doen kijken meestal ook de checksums na. Zulke zaken worden meestal vrij snel opgemerkt en zelfs als het gebeurd is de impact klein. Het soort bugs waar dit artikel over gaat zijn kwalijker omdat ze in elke implemenatie voorkomen.

[Frij5fd]

Torvalds is benaderd door de NSA om in de kernel iets aan te brengen:
http://falkvinge.net/2013...-backdoors-into-gnulinux/

Er is zeker interesse bij de NSA en ze zullen ongetwijfeld meerdere opties uitproberen, op een vasthoudende wijze. Ga ervan uit dat de source van de kernel iets bevat, dan kan het altijd meevallen. Of neem de tijd om (met vrienden die je 100% kunt vertrouwen) om de source door te akkeren.

[Gomez12]

Volgende vraag is dan : Heeft Torvalds dit gedaan?

Want hier heb je al een voorbeeld van software die al 30 jaar alle open source controles omzeilt en dat is dan nog onbewust. Moet je je eens indenken hoe moeilijk het wordt om bewust verborgen bugs(/lekken) te vinden.

[dtech]

Zoals in het artikel staat is de buggy code soms al 30 jaar oud, toen open source nog veel meer in zijn infancy was dan nu. Nieuwe code of aanpassingen worden wel bekeken.

[Relief2009]

Leuk verhaal, maar het maakt geen ruk uit. Zolang de bugs de laat worden geconstanteerd, dan worden de bugs in de tussentijd ook gewoon misbruikt.

[mcDavid]

Juist. En daarom is het zo fijn dat bugs ook geconstateerd kunnen worden door normale mensen, en niet alleen door malafide organisaties die op illegale wijze een broncode bemachtigd hebben.

[Gomez12]

Ach, als een van de core-componenten van linux pas na 30 jaar eens bekeken wordt door "normale" mensen dan twijfel ik toch ernstig aan het nut...

[mcDavid]

Die tijdsduur van 30 jaar maakt weinig uit. Deze onderzoeker heeft juist het nut maar weer eens gigantisch bevestigd door als relatieve leek zomaar een paar 100 bugs op te sporen, die nu gefixt kunnen worden vóórdat ze misbruikt worden!

Stel je voor dat deze code closed source was geweest. Dan waren deze bugs alleen gevonden door malafide partijen die de broncode gestolen hebben, en pas bekend geworden op het moment dat ze al lang en breed actief misbruikt worden.

Dat je er niets (of minder) van hoort, betekent namelijk niet dat er geen fouten zitten in closed source software. Alle software bevat fouten. Het enige wat je daarmee kan doen is zorgen dat de kans dat die fouten gevonden worden zo groot mogelijk is.
Als alleen de fabrikant zelf, en malafide russische bedrijven die zich specialiseren in het verkopen van exploits aan de hoogste bieder dat kunnen, is dat een behoorlijk extra risico waar in mijn ogen veel te weinig aandacht aan besteed wordt.

[Reactie gewijzigd door mcDavid op 24 juli 2024 21:43]

[Zer0]

door als relatieve leek zomaar een paar 100 bugs op te sporen

Het is natuurlijk wel raar dat code ondanks het feit dat er miljarden ogen naar hebben kunnen kijken toch nog bugs blijkt te bevatten.

Het voordeel van Open Source is dat vele ogen naar de source kunnen kijken, maar dit voorbeeld toont aan dat dat lang niet altijd gebeurt.

[mcDavid]

Nee, dit voorbeeld toont juist aan dat dat WEL gebeurt. Ik weet niet wat jij gelezen hebt, maar het staat er vrij letterlijk:

Een Belgische beveiligingsonderzoeker heeft zonder veel moeite 200 beveiligingsproblemen gevonden in X.org

Het maakt niet uit of het vandaag of gisteren of volgend jaar is, feit is dat, doordat het pakket open-source is, er nu 200 beveiligingsproblemen uitgehaald kunnen worden VOORDAT deze misbruikt worden, in plaats van NADAT ze misbruikt worden zoals bij closed-source software het geval zou zijn.

[Zer0]

Dus alle bugs die in open source gefixeerd worden zijn nog nooit misbruikt, en alle bugs die in closed source gefixeerd worden werden al misbruikt? Ook al zitten de bugs er al lange tijd in?
Degene die dit soort bugs misbruiken lopen er over het algemeen niet mee te koop.

Een Belgische beveiligingsonderzoeker heeft zonder veel moeite 200 beveiligingsproblemen gevonden in X.org

Dat ze gevonden zijn betekent daarnaast nog niet dat ze opgelost zijn, misbruik is dus nog steeds mogelijk.

[Reactie gewijzigd door Zer0 op 24 juli 2024 21:43]

[mcDavid]

Dat kun je wel stellen ja. Bugs komen over het algemeen niet zichzelf melden, die worden pas gevonden als iemand er naar zoekt. En die iemand kan een onafhankelijke belgische onderzoeker zijn, of een malafide botnetproducer. Als ik mag kiezen, heb ik liever dat die eerste ze vind. Wat dus alleen mogelijk is als de source vrijgegeven is.

[Crazy D]

Dit toont juist WEL aan dat het feit dat de source in te zien is, dat of niet veel gebeurt, of niet door mensen met genoeg kennis en zin om de code door te spitten op bugs. Natuurlijk is het mooi dat iemand die niets met het project te maken heeft, de code in KAN zien en bugs KAN vinden, maar dat dit pas na zoveel jaar gebeurt, toont dus aan dat dat grote voordeel van open source, ook niet al teveel overdreven moet worden. Als dat in zo grote getalen zou gebeuren als dat open source fanboys ons willen doen geloven, waren deze bugs al jaren eerder gevonden...

(maar natuurlijk, uiteindelijk is het goed dat ze gevonden zijn, en bij closed source gebeurt dat inderdaad over het algemeen pas als er misbruik van gemaakt wordt).

[BartOtten]

Over het algemeen worden ze wel gevonden. Maar Xorg is zo ernstig verrot dat ontwikkelaars niet eens meer naar de code willen kijken......Het is denk ik een van de grootste legacy zooi (ter wereld) die nu nog gebruikt wordt

[huntedjohan]

sorry, maar als het waar is wat jij zeg is het toch wel droevig gesteld met de ontwikkelaars die het systeem van Linux veilig moeten houden. we blijven iets gebruiken wat zo brak is als het maar kan, en het mooiste onderdeel van Linux laten we hierbij dus maar lekker zitten wat de code is gewoon ruk.

als iedereen Linux zo veilig wil houden mag ik aannemen dat dit soort brakke software juist extra controle krijgt, en door iedereen juist constant in de gaten gehouden word. het is al 30 jaar oud blijkbaar, hoe serieus moet je Linux dus nog nemen als het al 30 jaar lang een onderdeel gebruikt wat door iedere Linux gebruiker als brak en slecht bestempeld word?

[BartOtten]

Xorg moet je niet meer serieus nemen. Dat doet niemand en het is de schandvlek van OSS. Het verdedigen is zinloos.

De problemen met het vervangen zijn al wel aangestipt in de reacties. Ik denk dat een groter struikelblok dan 'elk programma gebruikt het' nog wel de support door fabrikanten is. Daarom duurt het vervangen zo lang. Er moest 1 alternatief komen en voordat een OSS gemeenschap daar over eens wordt.........zucht

[huntedjohan]

maar zolang het wel gebruikt word in Linux distro's is het toch van extra groot belang dat er aandacht geschonken word aan dit soort software? het veiligheids gedeelte wat altijd hoog staat bij Linux komt volgens mij zo toch een beetje in het gedrang zolang dit soort software gewoon gebruikt word. dat het niet gelijk vervangen kan worden is geen probleem, maar als er dan ook niet naar omgekeken word krijg je vanzelf dit soort problemen, en het lijkt mij niet dat de Linux community hier op zit te wachten. zeker niet nu Linux steeds meer in het nieuws komt in positieve zin

[BartOtten]

Zoals ik al aangaf: ze vinden is het probleem niet. Ze netjes fixen des te meer. Zoals de onderzoeker al aangaf "broken beyond repair". De Linux gemeenschap weet dat nu al wel wat jaren maar Xorg vervangen is extreem lastig. Zeker als een grote speler voor de desktop (Canonical) dat wat in ontwikkeling is niet steunt maar lekker z'n eigen weg gaat en dus zeer kostbare developers-uren voor eigen plannen gebruikt. De argumenten die nadien gegeven werden sloegen (aantoonbaar) ook nog eens nergens op

De onbeheersbaarheid van Xorg was al enkele jaren bekend. Een nieuwe displayclient (of server) schrijven kost meer tijd dan een jaar. Xorg fixen duurt ook zo lang...en dan ben je nog geen stap verder in de toekomst. Daarom is er, redelijk moedwillig, gekozen om Xorg te laten voor wat het is. Er was na 20 jaar gewoon geen beginnen meer aan om de X legacy uit te roeien. Toen Xorg begon hadden ze het wel als streven (zie ook artikel) maar in the end liepen ze gewoon tegen de grootste rommel aan. Daarvan is een flink deel overboord gekieperd zover dat kon...maar niet met alles was dat mogelijk

Laten we het er op houden dat Xorg een gigantische les is geweest voor OSS (en software in het algemeen). Hou dingen van elkaar gescheiden anders schrijf je uiteindelijk een printerdriver die een vliegtuig kan besturen en ondertussen het album van een artiest kan downloaden

Zie huidige voortgang van KDE. Die trokken in KDE4 al hele stukken uit elkaar* en met KDE Framework 5 wordt het helemaal een collectie mini-libraries. Er is al lang geleden geleerd...het kost gewoon teveel tijd om dat te vertalen.

*en schreven miljoenen workarounds om een moderne desktop op Xorg mogelijk te maken. Die worden nu in sneltreivaart geschrapt en dat levert flink wat codebesparing op. Er zijn zat blogposts over te vinden

[TheVivaldi]

Nuja, ik vind het ook jammer dat Canonical niet meedoet met Wayland maar laten we eerlijk zijn: zelfs *als* Canonical mee zou helpen voor de volle 100% dan zou het nog steeds lang duren om X te vervangen. Minder lang dan nu, maar toch lang.

[BlackOwl]

beveiligingsproblemen uitgehaald kunnen worden VOORDAT deze misbruikt worden, in plaats van NADAT ze misbruikt worden zoals bij closed-source software het geval zou zijn.

Waar haal jij de zekerheid vandaan dat deze bugs niet al 10 jaar of langer misbruikt worden?

[hackerhater]

Inderdaad.
En daarnaast is het geen geheim dat Xorg crap is en compleet niet voorbereid is voor het huidige gebruik.
Het is niet voor niets dat ze bezig zijn met een opvolger ipv X aan te passen.

[mcDavid]

...en daarnaast is het ook geen core-component van Linux, maar dat leek me niet de essentie van zijn reactie.

[Blokker_1999]

Feit is, het is gevonden. In windows zit evengoed code van enkele decennia oud en die kan niemand nakijken. En ja, daar komen soms ook fouten in naar boven. Hier worden ze nu bekendgemaakt, vanuit een closed source pakket weet je het gewoonweg niet.

[TheVivaldi]

Ach, als jij graag de tijd wilt nemen een immense code-basis door te spitten en dan ook nog eens per ding bekijken of het al dan niet een exploit is... mij lijkt het in ieder geval geen leuke klus die ik elke dag even zou willen doen.

[Tourmaline]

Beveiligingsonderzoeker is echt niet een normaal mens, dit is een expert op beveiligingsgebied die gericht heeft gezocht! Normale mensen maken niet eens gebruik van Linux, meestal Windows of iets anders zoals ios of Android op een tablet.

Ik denk niet dat een normaal mens 200 bugs gaat vinden in een linux kernel!

[koelpasta]

"Het voordeel blijft, want in dit geval heeft deze onderzoeker de bugs aan het licht kunnen brengen, "

Ja, in 30 jaar oude software, ja.

Als het iets duidelijk maakt dan is het wel dat je geen enkele garantie hebt dat open source code beter onderhouden wordt dan closed source code.

[mcDavid]

Garantie kan niemand geven. Het beste wat je kunt krijgen is een zo groot mogelijke poule van mensen die helpen bugs op te sporen. Kortom: open-source.

[SuperDre]

uhm, je hebt helemaal geen toegang tot de originele code nodig, met een fatsoenlijk decompiler kom je echt al bijna net zo ver... enuh, met .net is het nog makkelijker, als je eens wist hoeveel developers niet eens weten dat de volledige code gewoon meegaat tenzij je een externe obfuscator gebruikt...

[mcDavid]

Niet iets wat voor de gemiddelde leek weggelegd is, zeker niet aangezien decompiled code alles behalve leesbaar of onderhoudbaar is.

[SuperDre]

Maarja, beetje hackers die door de gewone code heenspitten naar exploits zijn dan ook geen gemiddelde leken...
En waarom zou decompiled code alles behalve leesbaar zijn? en onderhoudbaar hoeft het niet te zijn, immers gaat het om exploits vinden.. En juist met decompiled code vindt je mogelijk meer exploits als met de originele code, en waarom? omdat decompiled code ook zwakheden tonen in de compiler zelf.
Het zal niet de eerste keer zijn dat een redelijk fatsoenlijk geschreven stukje code naar iets compleet raars wordt gecompileerd dat niet doet wat de geschreven code bedoelde (komt gelukkig tegenwoordig steeds minder voor, maar toch)..

En met betrekking tot leesbaarheid, dat is natuurlijk maar afhankelijk van wat je gewend bent, want wat voor jou perfect leesbare code is, wil nog niet zeggen dat dat ook voor een ander is.. Goede code is all in the eye of the beholder..

[Verwijderd]

Ja, een onderzoeker die na 30 jaar eens een kijkje gaat nemen. Veel code van Linux wordt niet continu onder de loep gelegd. Het klopt dus wel degelijk wat ChicaneBT zegt.
Dat het bij closed-source nog lastiger is om achter bugs te komen maakt Linux code niet opeens veilig.

[mcDavid]

Het gaat hier niet over Linux code. En dat is dus pertinent wél het geval. Lees de discussie boven je maar eens, ik blijf mezelf niet herhalen.

[TheVivaldi]

Linux-code? Sinds wanneer is Xorg onderdeel van de kernel???

[Verwijderd]

Het is maar hoe je het ziet he, met closed source is het moeilijker om gaten te vinden.

[mcDavid]

Nee, met closed-source code is het voor GOEDWILLENDE mensen moeilijker om gaten te vinden. Kwaadwillende mensen daarentegen, scoren toch wel ergens een illegaal kopietje van de source op de zwarte markt.

[ThePendulum]

Er wordt hier gemeld dat er bugs zijn gevonden, en jij komt met de opmerking dat daarmee de kracht van open source verloren gaat? Dat klinkt nogal paradoxaal. Juist doordat het open source is kunnen deze vindingen gedaan worden.

Als X.org closed source was geweest had waarschijnlijk niemand ons het nieuws gebracht. X.org zelf had daar geen belang bij, en de veiligheidsdiensten gaan ons echt niet hun gereedschapskist laten zien.

[Verwijderd]

In zijn post lees ik gewoon dat het overroepen is, niet compleet verloren.

[Inspector]

Dat is natuurlijk onzin. Ik gebruik zelf ook erg veel op linux gebaseerde os'n. Linux is een kernel en hoewel voor desktop os'n de linux kernel vaak gepaard gaat met een xorg installatie zijn dit nog steeds twee compleet sepperate stukken software. Voor mijn servers draai ik dan ook linux zonder xorg en daar zijn de potentiële kwetsbaarheden dan ook niet van toepassing. Verder is open source juist de manier om dit soort problemen te vinden en aan te pakken. Foutloze software is een utopi dus ik ben alleen maar blij dat er een manier is om zoveel mogelijk fouten in software op te sporen. Ik beweer niet dat linux compleet veilig is maar het afdoen als onveilig i.v.m. brakke xorg code is ook een stap te ver.

[Verwijderd]

Verder is open source juist de manier om dit soort problemen te vinden en aan te pakken.

Hier heb je helemaal gelijk in, maar kennelijk zijn er in dit geval niet voldoende mensen met de juiste kennis die er ook nog eens belang bij hebben om door de code heen te gaan.
Het gaat hier niet bepaald om splinternieuwe code; deze fouten hadden al jaren geleden opgespoord en opgelost kunnen zijn.

Het gesloten karakter van niet-open sources is op zichzelf zeker geen voordeel, maar de commerciële drijfveer kan wel zorgen dat er voldoende kennis in een closed-source wordt geïnvesteerd om ook in dat geval tot steeds betere code te komen. Alleen kunnen 'wij' dat niet zomaar controleren.

[Verwijderd]

X.org is gigantische, oude, niet onderhoudbare crap, zoals het in de bron wordt genoemd. X.org is eigenlijk een soort cross-platform operating system bovenop je operating system. Het doet veel te veel, en op een manier die 20 jaar geleden al een slecht idee was. Dit soort fouten zijn jaren geleden ook al gevonden, en worden zoals je ziet nog steeds gevonden. Het is echt broken beyond repair. Vandaar dat er al jaren wordt gewerkt aan een opvolger. Zo'n centraal onderdeel van je systeem vervang je echter niet 1-2-3. X.org is in de laatste 10 jaar al vrijwel compleet uitgekleed, door dingen naar de kernel te verplaatsen en door moderne extensions die het core protocol compleet overbodig maken. De laatste stap moet nu nog komen met Wayland, en dan kunnen we X.org voorgoed gedag zeggen.

[Blokker_1999]

Zelfs na d ekomst van Wayland verwacht ik niet direct dat X.org zal verdwijnen. Wayland en Mir zullen eerst onder elkaar moeten gaan uitmaken welk van de twee het dominante platform van de toekomst zal worden. Daarna moet alle software nog geport worden en dan moet 1 van die 2 projecten ook nog eens de ondersteuning krijgen vanuit AMD en nVidia voor degelijke drivers. Als we over 10 jaar X.org het label deprecated mogen geven, dan mogen we blij zijn.

[BartOtten]

De meeste KDE ontwikkelaars hebben al hun vinger laten zien aan Mir. Qt zal voor zover ik weet geen Mir gaan ondersteunen (vanuit het kernteam) dus ik denk dat het al wel duidelijk is dat Wayland de battle wint. Canonical kan veel, maar Mir was denk ik een te flinke stap (zeker omdat ze zoveel mensen tegen de schenen hebben geschopt)

[TheVivaldi]

Precies. En Enlightenment heeft ook gezegd dat ze Mir niet gaan ondersteunen en GNOME Shell lijkt ook geen interesse te hebben. Dus Wayland is voorlopig de "way" to go.

[Blokker_1999]

Maar ... moest mir wonder boven wonder toch een dominant platform worden dan zie ik de core devs van die projecten alsnog de ondersteuning voor mir zelf opnemen.

Zulke discussies zijn zinloos zolang er geen releases zijn en zolang er geen duidelijke winnaar is. NAT zou ook nooit deel gaan uitmaken van IPv6 in de linux kernel. Ondertussen is NAT wel degelijk mogelijk. Zeg dus nooit nooit.

[Mellow Jack]

Het gesloten karakter van niet-open sources is op zichzelf zeker geen voordeel, maar de commerciële drijfveer kan wel zorgen dat er voldoende kennis in een closed-source wordt geïnvesteerd om ook in dat geval tot steeds betere code te komen. Alleen kunnen 'wij' dat niet zomaar controleren.

Niet helemaal lijkt mij. Bij Closed source wordt iets pas echt verbeterd wanneer dit een commercieel voordeel oplevert. Zoals je hebt kunnen lezen is 1 van de bugs blijkbaar het crashen bij het wegschrijven van grote bestanden. Dit was nooit een probleem totdat we grote bestanden wilden wegschrijven. Dus of dit nou open of closed source was, naar mijn mening worden dit soort zaken pas opgepakt wanneer het ergenissen gaat opleveren. Dus ipv de schuld te leggen bij closed of open software leg ik de schuld liever bij de mens zelf... In beide gevallen had hier iets aangedaan wanneer hier of genoeg geld of genoeg tijd voor zou zijn

[Verwijderd]

Onzin, ook het voorkomen van commerciele nadelen is van groot belang.

[Crazy D]

Bij closed source is de drijfveer inderdaad meestal commercieel voordeel. Maar bij open source is dat niet anders: Red Hat gaat niet zomaar een aantal man ergens op zetten "omdat het open source is, en iedereen mee kan ontwikkelen". Dat doen ook zij alleen maar omdat ze er geld mee denken te verdienen (direct of indirect, soms ontwikkel je het 1, om aan de andere kant geld te verdienen). Ongeacht of het ergernis oplevert of niet, want in beide gevallen geldt dat als het geen commercieel gewin oplevert, er niets aan wordt gedaan.

Open source zou dan nog als voordeel hebben dat iedereen eraan mee kan werken, maar de hobbyist (niet denigrerend bedoelt) gaat niet voor zijn lol in 30 jaar oude code graven om daar verbeteringen in door te voeren, die zal vaak de leuke interessante dingen willen doen. En als ik het zo lees valt de code van Xorg niet in die categorie... dus gebeurt er niets aan.

[TheVivaldi]

Mag je mij even uitleggen waarom Red Hat Lennart Poettring in dienst heeft genomen. Naar hun zeggen omdat "zijn 2 projecten van belang zijn voor Linux en iedereen mee kant ontwikkelen".

[Crazy D]

Als hij 2 projecten heeft die belangrijk zijn voor Linux in zijn algemeenheid, is dat OOK in het belang van Red Hat. En dus prima te begrijpen waarom daarin geïnvesteerd wordt. En dan is het commercieel ook nog eens aantrekkelijk dat je kunt zeggen "wij van Red Hat financieren...." wat ook nog eens goodwill kweekt... Geen enkel bedrijf doet iets volledig belangeloos, er zijn altijd belangen. Soms erg obvious, soms iets verder verstopt. En dat geldt dus ook voor bedrijven die hun geld verdienen met open source producten.

[TheVivaldi]

Met het verschil dat Lennarts tweede belangrijke project waaraan hij onder werktijd werkt, systemd, niet in Red Hat zit. Maar ze betalen hem er wel voor. Dus veel belang heeft Red Hat er niet bij, of ze moeten wel heel genereus zijn naar andere distro's toe...

[tuXzero]

Bij zowel open als gesloten software bepaald de markt wat belangrijk is. Klanten of gebruikers van grafische software hechten niet veel waarde aan beveiliging. Maar software voor IP filtering is door de doelgroep wel weer veiliger.

Uiteindelijk als beveiliging een issue wordt kun je je afvragen wat makkelijker is. Een onafhankelijke beveiligingsonderzoeker op open of gesloten software zetten (als je de gebruiker maar niet de eigenaar bent).

[Verwijderd]

Dit heeft niets met Linux te maken. X wordt ook in *BSD gebruikt.

Maar iedereen die ooit de source van X heeft gezien kan beamen dat het gewoon inderdaad crap is. Het is niet voor niets tijd voor Wayland.

[Blokker_1999]

Het is inderdaad tijd voor iets nieuws na al die jaren. Toch hebben X.org en nu ook Wayland al aangetoond dat het niet zo eenvoudig is om met een alternatief te komen. Toen X.org de standaard overnam van XFree86 hadden zij zich als doel gesteld om de codebase te moderniseren, dat doel is slechts beperkt gelukt met het resultaat dat we nu dus zien. En ook Wayland, een project dat van 0 begint, loopt tegen de ene vertraging na de andere aan. Zelfs Canonical met een dedicated team dat aan Mir werkt heeft dat project al moeten vertragen.

[Verwijderd]

Ik denk dat je dat toch iets verkeerd ziet. Alhoewel ik geen expert ben is dit mijn ervaring.

Het grote probleem met X is compatibility. Dat maakt het zo lastig. Ze willen dat alle programma's blijven werken en dan moet je om de brij heen gaan werken.

Met Wayland heb je dat probleem niet. Maar met Wayland krijg je een nieuw stel problemen. En een aantal zijn politiek, zoals de drivers, maar ook Weston is een nieuwe ontwikkeling die gewoon tijd kost. En alhoewel de verwachtingen hoog gespannen waren rondom Wayland, was volgens mij alleen Canonical die echt verwachtte dat het snel af zou zijn en druk op de ketel zette (ivm hun telefoon).

We zijn nu denk ik in de eindfase van de Wayland opstartfase. De grote distributies gaan het volgend jaar toepassen. Maar dan nog zal het velen jaren duren voordat de meeste programma's herschreven is naar KDE / GTK+ / ...

[BartOtten]

KDE is redelijk op weg. De eerste 'go test it' builds kunnen al gedownload worden. Dan krijg je een basix desktop maar dus wel op het nieuwe framework + wayland.

[TheVivaldi]

En niet alleen KDE. E17 werkt al keurig op Wayland en de nieuwe E18 zelfs nóg beter. GNOME Shell werkt sinds 3.10 ook best goed op Wayland, maar E18 draait het voorlopig het beste.

[egnappahz]

Wat je zegt is misschien niet helemaal fout,...

Maar het gaat hier nu eenmaal over een (hopeloos) voorbijgestreefd protocol, waar de hele Linux wereld het lastig mee lijkt te hebben om een volledig stabiele opvolger te vinden (Wayland?)

[ClementL]

Lastig? Mir is tot nu toe een Canonical-only feestje. De rest van de Linux community lijkt Wayland als opvolger te beschouwen.
Op een paar na die, om de een of andere reden, liever Xorg behoud.

[egnappahz]

Canconial is niet de hele linux wereld.

[ClementL]

Nee, ik beweer toch ook het tegengestelde.

[sfranken]

Xorg is een uitzondering op de regel. De code van Xorg is > 20 jaar oud en voor heel veel mensen onleesbaar door alle wijzigingen en aanpassingen over de jaren. De code van Xorg stinkt aan alle kanten, zo erg zelfs dat de ontwikkelaars er zelf geen heil meer in zien.

Een van de redenen dat het uitgefaseerd wordt door Wayland/Mir

[Verwijderd]

Daar gaat de theorie die veel mensen gebruiken dat je bij Linux de code kunt bekijken en het dus daarom wel veilig zal zijn. Als één onderzoeker al zoveel bugs weet te vinden dan weten onderzoekers van veiligheidsdiensten deze bugs ook wel te vinden met het doel natuurlijk om een kijkje te kunnen nemen op die Linux systemen.

Ga er maar van uit dat veiligheidsdiensten ook over windows en OSX code beschikken. Wellicht zelfs dat Apple en Microsoft met de veiligheidsdiensten mee werken.

Dat iedereen de code van Linux kan bekijken, is op den duur veiliger. Het leidt tot betere code. Dit onderzoek bewijst dat juist. Het X.org team zal deze zwakke plekken er uithalen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 21:43]

[Verwijderd]

Dat iedereen de code van Linux kan bekijken, is op den duur veiliger. Het leidt tot betere code. Dit onderzoek bewijst dat juist. Het X.org team zal deze zwakke plekken er uithalen.

Op den duur... Ruim 30 jaar later is het nog niet veilig. Lang leve open source.
Tot die tijd niet gaan klagen over closed source die nog geen 30 jaar oud is hè.

[rfpels]

Ik zie dat je niet gehinderd word door enige kennis. De meeste zo niet alle servers die hun werk doen zonder desktop omgeving hebben misschien wel X-clients beschikbaar maar de server is er niet op aanwezig omdat die daar gewoon niet nodig is.

Als je opgelet had dan wist je dat X.org een display server is - een programma dat display diensten aanbied aan cliënten. En dus op hun verzoek allerlei grafische zaken op het beeldscherm tovert.

Bovendien spreek je voor je beurt. Je hebt nog niet eens een lijst gezien van de bugs die gevonden zijn en ook geen onderzoeksverslag gezien van de bugs en hun mogelijke impact.

[markg85]

Diepe diepe zucht..

De X.org-client wordt vooral gebruikt als onderdeel van een window-manager, zoals GTK of KDE. Volgens Van Sprundel zijn ook de implementaties van de client in GTK of KDE ook zo lek als een mandje.

GTK = GIMP Toolkit en zeker niet een "window manager".
KDE = K Desktop Environment en ook zeker niet een "window manager".

De eerste (GTK) is wel de ergste fout. Het heeft zelfs niets met een window manager te maken. Je kan het wel omdraaien: Je kan er een window manager mee maken. KDE is al beter, maar ook een fout. Het is "KDE SC" om mee te beginnen en dan nog is de window manager (KWin) er maar 1 onderdeel van.

Wat jullie eigenlijk bedoelden is:
De "mutter" window manager van Gnome en "KWin" van KDE. Maarja, ik begrijp ook wel dat die twee termen zelfs de meeste tweakers niet veel zal zeggen.

[Kewne]

Van wat ik begrijp uit de slides gaat het eigenlijk om GTK & Qt, de toolkits dus. De slides zijn trouwens zeker interessant.

[markg85]

Dat kan, maar dan zijn het weer toolkits en geen window managers

[Amiga3000]

Jaren van hergebruik van C of C++ code die nooit is herzien, het zal niet het enige product zijn wat problemen heeft hiermee. Iedereen heeft in die tijd dezelfde code en dus fouten gemaakt.

Zal ook wel nooit een einde aankomen...

[hardwareaddict]

Ja kijk ze zeggen altijd tegen studentjes dat ze maar beter kunnen wachten tot ze in een bedrijf rondlopen en dan de closed sources mogen checken - dan pas schrikken ze echt

Niemand betaalt voor het fixen van oude bugs he. Alleen als er iemand heel veel geluid over maakt dan kijkt er soms iemand met een half oog naar

[Amiga3000]

Precies en als het bedrijf groot genoeg is of de gevolgen van de bugs komt er actie.
Helaas worden veel toolkits overgenomen en men vindt het gewoon te veel werk om deze te verbeteren.

TCP en UDP is mooi bijvoorbeeld maar wel uitgevonden in een tijdperk dat dit niet speelde allemaal. Nu moeten we door met deze protocollen en kunnen we geen grote wijzigingen meer maken.

En ja wat heeft iedereen gedaan, je pakt de source code van een bestaande implementatie en je zet er wat bij.

Maakt eigenlijk niet uit wat de programmeer taal is, kijk maar naar de PHP forums problemen van een tijdje geleden. Iedereen nam de basis over en rommelde er zelf wat bij. Zo waren de bugs en beveiliging problemen mooi overgenomen en hadden veel sites deze problemen.

strcpy en maar hopen dat er een null komt

[Xtuv]

Het is mij niet helemaal duidelijk wat dit precies is als Linux-n00b.

"De displayserver is in Linux-distributies en andere op Unix gebaseerde besturingssystemen verantwoordelijk voor het op het scherm tekenen van de grafische interface."

Daar maak ik uit op dat de grafische interface via een onlineserver op je scherm getoverd wordt? Dus als je offline bent krijg je de interface niet (goed) te zien

[Firestone]

X.org stamt nog uit de tijd van de mainframes waaraan meerdere terminals hingen. Toen draaide de client op de mainframe en de servers op de terminals. Op de standalone PC's van nu draaien zowel de server als de clients, waar de server als backend op rootniveau draait en waar elke window of window-manager in userspace als aparte client gezien wordt.
Wellicht maakt deze illustratie het duidelijker : https://upload.wikimedia....x_Graphics_Stack_2013.svg.
<edit: was toch in de war, zie Hoopje>

[Reactie gewijzigd door Firestone op 24 juli 2024 21:43]

[Hoopje]

Bij X.org is het andersom: daar draait de server op de terminals en de client op de mainframe. Het is de server die een dienst aanbiedt (grafische interface) en de clients gebruiken die dienst. Tegenwoordig draaien X-server en X-client inderdaad meestal op dezelfde machine, maar het is nog steeds mogelijk om remote applicaties een lokale X-server te laten gebruiken (X forwarding).

[Xtuv]

Duidelijk, dankjewel! Had al zo'n vermoeden dat het iets met 'thin clients' te maken zou hebben. Heeft zo'n systeem ook voordelen in omgevingen waar je niet met mainframes/terminals werkt?

[riotrick]

Je kunt bv een x server op een andere machine draaien dan waar een applicatie op draait. De uitvoer van die applicatie kan dan op een andere x server (computer/scherm) worden weergegeven.

Voorbeeld: je draait een server in een datacenter daarop heb je een (grafische) backup applicatie. Je kunt op je desktop een x-server draaien (kan ook onder windows). Dat backup programma start je op de computer in het datacenter. Het window wordt dan getoond op de x-server die op je desktop draait (als venster). Dit alles kun je automatisch laten tunnelen door ssh voor wat encryptie.

Zoeits kun je dan krijgen, linux (x) applicaties dire draaien op een linux machine en op een andere (windows) machine worden getoond: http://a.fsdn.com/con/app/proj/xming/screenshots/91875.jpg

[Reactie gewijzigd door riotrick op 24 juli 2024 21:43]

[speedydown]

Een server kan ook lokaal draaien en heeft zelfs 9/10 gevallen niks met internet te maken

[Xtuv]

Dus je bent dan op je Linux-desktop zowel client als server? Gezien onderstaande quote en het feit dat het om X.org (website...) gaat leek dit mij iets wat online gebeurt.

De X.org-server bestaat uit clients en een server, waarbij de clients doorgeven aan de server wat er op het scherm moet worden getekend.

[g4wx3]

Inderdaad.

Dit is zo gegroeid historisch.

Je had een Mainframe, met UNIX, en dan client-PC die met die mainframe werden verbonden.
Achteraf werden die client-pc krachtig genoeg om zelf UNIX te draaien, en dus integreerde je ook de client op dezeflde pc.

Echter is het nog steeds krachtig protocol als je op afstand een computer wilt overnemen. Vergelijk het met windows Remote desktop. Of beter nog: Citrix, en de ICA-Client. (zij hebben trouwens de source van windows danig mogen aanpassen om het mogelijk te maken)

Het alternatief om een scherm op afstand over te nemen is een screengrabber, ala VNC. Die vergt veel meer bandbreedte, en je hebt last van lagging door de hoge latency van je internetverbinding, Het werkt gewoon niet goed. Dit wordt gebruikt onder OSX.

Vergelijk het de je om je scherm op te bouwen HTML serverside genereert, die dan naar je browser wordt gestuurd die de html zal tekenen. Voor scrollen, typen, links hoeft er geen dataverkeer te zijn.

Een screengrabber zal bij iedere verandering een nieuwe printscreen moeten sturen, wat nagenoeg onwerkbaar is.

De toekomst stapt men af van Client-server op 1 machine.
Nu voor linux en OSX maakt dat eigenlijk niet uit, want via SSH kan je via command line inloggen, waar je alle beheerderstaken kunt uitvoeren die je maar wenst. Op Windows is iets dergelijks standaard althans onbestaand.

[Bauknecht]

Het jammere is natuurlijk dat ik hier op het werk (en blijkbaar ook onder MacOS X) zie dat de meesten wel degelijk VNC gebruiken, o.a. omdat dit crossplatform werkt. Met inderdaad rampzalige latencies als gevolg. Ook TeamViewer werkt op die vrij 'primitieve' screengrabbing-manier.
Voorzover ik weet, is er één product dat effectief die geavanceerde X-opbouw gebruikt, en dat is NoMachine. Dat gaf wel degelijk een zeer goede performance wanneer je op een lage bandbreedte zit (ik praat van kbps ipv Mbps). Met dan weer het nadeel dat het wel wat zoeken was om het aan de praat te krijgen in geavanceerde HW-versnelde omgevingen, zodat ik remote vrij snel op een Xfce zat te werken omdat Unity maar raar deed.

Maar een lang verhaal kort gemaakt: als je dan ziet hoe het énige pluspunt van X.org tot dergelijke miserabele code leidt terwijl het in de praktijk:
- Amper gebruikt wordt
- Ingehaald wordt door de toenemende bandbreedtes en geavanceerde compressietechnieken van screengrabbers
- Die dan boven dien nog crossplatform en stabieler werken dan een NoMachine.

Maak je dan beter niet de conclusie dat het sop de kool niet waard is? Just my €0.02.

[MrQuincle]

Volgens mij gebruikt NoMachine een aangepaste versie van X, zie https://en.wikipedia.org/wiki/NX_technology. Voor gewoon X tunnelen heb je niks anders nodig dan:

ssh -X

Maar dat wist je vast al wel.

[--Andre--]

Een NX implementatie draait inderdaad een eigen X server en doet meer dan ssh -X. Het is zeg maar een "screen voor X".

En het feit dat je X gewoon kan tunnelen met ssh, dat is nou net mijn bezwaar tegen Wayland en Mir. Leuk en aardig, dat alternatief, maar als het server/client model wegvalt, kan ik dus ook geen remote grafische applicaties meer draaien.

[Verwijderd]

Wayland sluit geen remote uit. De reference-implementatie Weston heeft inmiddels ondersteuning voor RDP. Gnome en KDE zullen uiteraard ook iets dergelijks doen. Wees blij dat je van het inefficiënte en onveilige X protocol af bent; dat zit zo vol met server roundtrips dat je het echt niet op een high-latency internetverbinding kan gebruiken. Het is tijd voor iets beters.

[TheVivaldi]

Het voordeel van Wayland is dat extensies veel makkelijker te maken zijn en veel beter samenwerken met Weston. Een remote-extensie kan dus best komen in de toekomst.

[mcDavid]

Dat klopt. Je kunt een X.org server wel via een netwerk verbinding benaderen (en zo een programma op computer 1 starten, terwijl het venster op computer 2 getoond wordt) maar dat is hoogst ongebruikelijk.

30 jaar geleden toen er veel met mainframes gewerkt werd waarbij meerdere mensen op één computer werkten, was het client/server systeem super handig, maar tegenwoordig wordt het nauwelijks nog gebruikt, vandaar dat er momenteel alternatieven zoals Wayland ontwikkeld worden, die deze overhead niet hebben.

[Gomez12]

30 jaar geleden toen er veel met mainframes gewerkt werd waarbij meerdere mensen op één computer werkten, was het client/server systeem super handig, maar tegenwoordig wordt het nauwelijks nog gebruikt

Het principe wordt nog steeds gigantisch veel gebruikt hoor.
Op dat principe berust namelijk citrix / Remote Desktop etc.

[mae-t.net]

En daarvan neemt het gebruik alleen maar toe.

Ook het idee van niet je hele scherm over je verbinding pompen is nog steeds actueel en levensvatbaar, dus ik hoop dat daar in toekomstige protocollen nog aan gedacht wordt. Ook remote desktop ondersteunt tegenwoordig een enkel venster, al moet je me niet vragen hoe dat precies overgestuurd wordt.

[batjes]

Ja, je maakt een lokale verbinding met de X server.

[ClementL]

In het verleden wel, tegenwoordig is het gewoon een service die op de machine zelf draait.

[PolarWolf]

Niks nieuws. X(.org) was en is zo lek als een mandje. Ook zijn er in het verleden al een aantal alternatieven aangedragen die veel beter zijn/waren. Er was (en is) alleen één probleem mee...alle software was (is) geschreven voor X, en dan hebben we het nog niet eens gehad over de benodigde GPU drivers die ook "even" aangepast moeten worden op een nieuwe infrastructuur. Een soort kip/ei/nest probleem, dus.

Als het zo makkelijk was om van legacy af te komen dan was het allang gebeurd, he.

Overigens daarmee niet gezegt hebbende dat het daarmee minder erg is, allemaal.

[Reactie gewijzigd door PolarWolf op 24 juli 2024 21:43]

[ClementL]

Zowel Wayland als Mir werken met de EGL standaard. Dit betekend dat de drivers alleen maar EGL support in hoeven te bouwen, en beide driverplayservers (+ eventueel nieuwe in de toekomst) zullen werken.

[PolarWolf]

Uhuh. het probleem met "standaarden" is dat er zoveel van zijn. En elke paar jaar komt er weer een nieuwe bij, i.h.k.v. "the next big thing". Dit zijn niet het eerste initiatieven, en zal ook niet het laatste zijn. Intussen werkt alles en iedereen nog steeds met het onveilige en zwaar verouderde protocol (X) en implementatie (X.org) omdat...nou ja, omdat alles en iedereen nog steeds werkt met X.

Voor elk probleem is een oplossing. Iedereen moet het er alleen over eens zijn dat de oplossing inderdaad een oplossing is. Dat wil nog wel eens een "dingetje" zijn in de OSS wereld.

Het duurt nog wel een decenniumpje om deze legacy weg te krijgen.

[ClementL]

Nee, het gaat al veel sneller. Veel Toolkits en Windowmanagers hebben al support voor EGL. Daardoor zijn veel applicaties en games nu al Wayland compatible. Daarbij lijkt de OSS wereld ook in overeenstemming te zijn dat EGL de toekomst is. Grote OS´s zoals android gebruiken EGL al bij standaard.

Daarbij is EGL juist opgezet om het aantal verschillende API´s te verkleinen. EGL is namelijk niet meer dan een standaard, waarbij Xorg een API en een implementatie van die API is. Een sterk verouderde API, die onmogelijk gefixt kan worden. De hele reden waarom Wayland oorspronkelijk is opgezet.

[Zayl]

Ik hoop dat dit een goeie motivatie is om de boel eens te upgraden, ik merk zelf namelijk aardig wat problemen met de interface op ubuntu (veel quirks). Deste meer reden om een betere display server er doorheen te pushen!

[sfranken]

En je weet zeker dat dit aan Xorg ligt? Het kan zoveel zijn... Denk aan drivers, een GTK probleem, een installatieprobleem...

En Wayland is nog láng niet geschikt

[TheVivaldi]

Wayland draait anders prima met E18 en GNOME Shell hier. Bovendien wordt Wayland ook gebruikt op SailfishOS op de Jolla phone en heb van geen enkele gebruiker gehoord dat ze een grafisch probleem hadden (met Wayland). Dat het nog niet af is, soit. Maar geschikt voor normale doeleinden is het al wel.

[sfranken]

Uhm.. Nee. Ik heb een nvidia kaart met 2 schermen eraan en Wayland icm GNOME crashed bij initialisatie. Ik krijg niet eens m'n login scherm te zien.

Als dit soort dingen niet werken is het niet klaar voor algemeen gebruik.

[TheVivaldi]

nVidia heeft nog geen drivers voor Wayland en de meeste mensen hebben gewoon 1 scherm. Nouveau werkt al wel aardig met Wayland en met 1 scherm is het dus prima geschikt. Aangezien verreweg de meeste mensen met maar 1 scherm werken is het dus wel geschikt voor algemeen gebruik.

[sfranken]

Toch knap hoe je, zonder onderbouwing of bron, kan zeggen dat "de meeste mensen met maar 1 scherm werken".

Iedereen hier bij ons op de afdeling heeft minimaal 2 schermen. Dat werkt nou eenmaal veel fijner als je code schrijft.

Dat jij thuis met 1 scherm werkt wil niet zeggen dat jij representatief bent voor de algemeen populatie. Van alle Ubuntu installaties die ik ken/beheer is een goeie 90% daarvan met 2 schermen of meer.

[Zayl]

Het is vaak een combinatie van, het is niet goed compatible en vaak outdated. Windows XP draait ook redelijk goed, toch zijn het vaak de drivers die crashen. Het wordt dus tijd voor een core update

Met quirks bedoel ik dan vooral render areas die niet updaten, style changes die toch standaard wel zouden moeten werken die het niet doen, muis cursors die er anders uit zien per window (Stel bv m'n muis op zwart in en sommige windows is hij nog gewoon wit). Ja, het zal vast ook wel unity/gnome/xfce conflicten zijn (alles is wel eens geinstalleerd), maar dat neemt niet weg dat de code oud is, brak is en nodig vervangen moet worden.

[hackerhater]

Tjah ze zijn bezig met de opvolger wayland. Maar deze moet helemaal af zijn voor je kan gaan denken aan X vervangen. Xorg is een gedrocht, maar zoveel is er van afhankelijk. Het gaat hier om een van de core onderdelen van een Linux/BSD desktop installatie.

[Blokker_1999]

Alleen vervangt Wayland de X server niet volledig (lees hun faq er maar eens op na). In princip zou men X overboord kunnen gooien met Wayland, maar niet met de huidige implementatie.

[Verwijderd]

Daarom hadden ze bij Ubuntu 14.04 display manager MIR moeten gebruiken, nu als nog komt X.org als display manager.

[MadEgg]

Want de verse code in MIR is natuurlijk compleet bugvrij geschreven? De komende tijd kun je echt nog meer stabiliteit en betrouwbaarheid van X.org verwachten dan van MIR of Wayland...

[Verwijderd]

Dat is complete onzin die je schrijft. Zowel Wayland als MIR zijn per definitie een stuk veiliger. Ze bevatten beide namelijk ontiegelijk veel minder code. Alles wordt namelijk client side gerenderd.

[--Andre--]

Maar dat betekent wel dat er alleen beeld op de lokale machine weergegeven kan worden. Een thin client met een X server erop, en software die elders draait, kan met die alternatieven niet meer.

Ik realiseer me dat slechts een klein deel van de X gebruikers hier gebruik van maakt, maar toch...

[Verwijderd]

O, dat kan wel, via VNC. Zie link. Ok, het is nog een voorstel, maar ik heb hier toch ook al meer over gelezen en tijdens presentaties van de Wayland developers is het ook ter sprake gekomen.

[--Andre--]

Je wil serieus VNC voor een thin client gaan gebruiken? VNC werkt misschien voor sporadisch gebruik, maar voor een thin client lijkt me dit traag te gaan voor begrippen van jaren '80

edit: Ik heb het dus over een "traditioneel" X server/client model, waarop de X server en de machine waarop X applicaties draaien verschillende machines zijn.
Aangezien VNC werkt met screengrabbing, dus zeg maar screenshots verstuurt, is dit nogal inefficiënt.

[Reactie gewijzigd door --Andre-- op 24 juli 2024 21:43]

[Verwijderd]

Als je met thin client een server voorstelt met daaraan tientallen gebruikers, dan wens ik je ook met X veel succes. Nee, dit gaat primair voor een gebruiker die thuis nog ff de werkstation op het werk wil raadplegen.

Maar X heeft (althans dat zeiden ze tijdens een presentatie) een hogere bandbreedte dan Wayland met VNC.

[--Andre--]

Ja daar is VNC wel geschikt voor

[MadEgg]

Heb je X ooit gebruikt op die manier? Dat is om te huilen qua performance. VNC werkt beter, en helaas moet ik zeggen dat Microsoft's Remote Desktop Protocol hier veruit de kar trekt qua performance in remote desktop toepassingen.

[--Andre--]

Ja hoor, bij mijn studentencomputerverenigng (MCGV Stack) hebben we enkele inlogmachines.

[TheVivaldi]

Een thin client kan dan nog Edubuntu gebruiken.

[Verwijderd]

Dat waarschijnlijk niet, maar wel beter als X mag ik hopen.

[simon]

Dat is niet bijzonder vreemd, MIR is nog lang niet ver genoeg om een goede vervanger van X.org te zijn. Een displayserver+client is opzich wel een groot project... Dat heb je niet 1, 2 en 3 hop, gemaakt.

[mcDavid]

MIR moet (net als wayland) dan ook bewust géén displayserver/client worden.

[7o9]

MIR is uiteraard veel moderner, maar daarmee is niet gezegd dat het beter is. Hopelijk is dat wel zo en zal MIR gebruikt worden als deze volwassen genoeg is. 14.04 is LTS dus ik kan me voorstellen dat een relatief onbewezen product als MIR nog niet opgenomen wordt.

[rfpels]

Ja natuurlijk hadden ze dat moeten doen. In nieuwe code zit namelijk geen bugs. Dat is onmogelijk.

[sfranken]

Leuk idee, alleen minder dat MIR alleen goed werkt op een bepaalde Intel graphics chipset en dat je op alle andere chipsets geen beeld krijgt...

[TheVivaldi]

Nouveau ondersteunt Mir ook.

[Rinzwind]

Zegt wel iets over de kwaliteit of aanwezigheid van code reviews als hij daadwerkelijk maar een week nodig had om zoveel ellende te vinden....

[markg85]

En dat krijgt een +2..
Je krijgt een -1 van me voor de troll reactie!

Maar even ontopic aangezien je er volgens mij niets vanaf weet.

De code is ~30 jaar oud! Oftewel, jij was 3, x64 bestond nog niet, de HDD's waren nog groot in afmetingen en een paar 100 MB max! C++ bestond nog niet. C bestond pas ~8 jaar. Linux bestond nog niet.

Oftewel, het is een klein wonder dat X.org nu nog werkt. En met zoveel regels code is het nog knap dat er maar 200 bugs zijn.

[Ergomane]

Er zijn niet "maar" 200 bugs. Er zijn 200 bugs die volgens de onderzoeker makkelijk te vinden zijn in relatief korte tijd.

De hoeveelheid problemen die door een oppervlakkige codereview aan het licht worden gebracht en de aard van deze problemen zijn in mijn ervaring een imperfecte maat voor de codekwaliteit en het vookomen van additionele kwetsbaarheden.

[Reactie gewijzigd door Ergomane op 24 juli 2024 21:43]

[markg85]

Goed punt!

En om dat allemaal van de grond af aan te verbeteren zou je X.org opnieuw moeten schrijven. Zie daar: wayland

[Rinzwind]

Ah dus jij zegt eigenlijk dat x.org totaal ongeschikt is om de laatste jaren te gebruiken? En nee was geen troll, maar een observatie.

[markg85]

Dat heb ik niet gezegd, maar kan je er wel uit concluderen.

Sterker nog, X.org is al jaren een beest wat snel weg moet! Er was alleen geen vervanger voor die ook levensvatbaar was. Nu begint die wel te komen onder Wayland. En dan zal je ook - eindelijk - zien dat X.org langzaam verdwijnt. X.org gaat pas weg zodra er AMD/Intel/Nvidia drivers voor wayland zijn en die komen er pas zodra de desktop omgevingen erop draaien. En dat gaat allemaal volgend jaar gebeuren.

Vergeet niet dat X.org en Wayland door dezelfde mensen worden ontwikkeld. Wayland is geen concurrent van X.org, maar juist de opvolger.

[BartOtten]

Niemand wacht op Wayland? Laat me niet lachen. Iedereen die met Xorg en bovenliggende systemen werkt weet hoe verdomd irritant Xorg is en smeekt om een nieuwe display'server'.

[markg85]

Je heb er duidelijk totaal geen verstand van.

[ll roel j]

Vraag me af in hoeverre OS-x nu ook gebruik maakt van xorg, omdat het Unix gebaseerd is. Als ze het doen heeft dit ook impact op de veiligheid van MACs, lijkt mij.

[sfranken]

OS X heeft een Xorg client aan boord, maar standaard word deze geloof ik niet gebruikt. Ik geloof dat Apple met Cocoa dit afhandelt.

[LXFan]

Ik begrijp de reikwijdte/scope van het veiligheidsprobleem nog niet helemaal. Wil iemand uitleg geven?
Betekent het, dat bijvoorbeeld Lxde en Xfce distributies, liever niet moeten worden gebruikt?
Zijn Gnome, KDE, Mate, Cinnamon beter?
Ben enthousiast Linux Mint xfce gebruiker en wil natuurlijk niet "verkeerde" distributies promoten/installeren. Bijvoorbeeld, als Windows XP alternatief.

[hackerhater]

Zo goed als elke Linux desktop installatie heeft Xorg aan boord. DE's als Lxde, Gnome, KDE, etc draaien bovenop Xorg.
Alleen is dat hooguit 0,1% van alle Linux installaties aangezien Linux vooral als server of embedded wordt gebruikt.

Voor een desktop distro : maak je hier niet druk om. Het probleem zal opgelost worden en tot Wayland klaar is kom je er toch niet omheen.

[Parsec01]

De X.org implementatie in OSX heet X11 en is normaliter niet nodig. Die is wel nodig om Open-source software te draaien die per se een X-server nodig heeft om te draaien. Veel open source heeft dit inmiddels niet (meer) nodig (Open Office/Libre Office, VLC-player, etc). Die heeft dus bijna niets met OSX te maken

[MSalters]

Eh, nee. X11 is het origineel. XFree86 was een gratis kloon daarvan, x.org is daar weer een afgeleide van. X.org is dus een implementatie van het originele X11 protocol en niet andersom.

Los daarvan is X11 op Apple geïmplementeerd door XQuartz (aka X11.app), een plug-in voor X.org.

[ClementL]

Gelukkig zijn de major desktopomgevingen Wayland ondersteuning aan het inbouwen .

[TheVivaldi]

En sommigen hebben het al grotendeels ingebouwd zoals E17/E18 en GNOME Shell.