Ubuntu krijgt in 24.10 mogelijk standaard Wayland-ondersteuning bij Nvidia-gpu's (2024)

Soldaatje
17 mei 2024 19:38

In plaats van TPM kan je ook een tang/clevis opzetten, heb dit laatst gedaan, een oude raspberrypi B uit 2011 unlocked automatisch al mijn luks-versleutelde root-schijven. Ideaal!

Voor extra veiligheid heb ik de tang server map ook versleuteld met encfs, dus power eraf is alles gelockd.

kozue

Besturingssystemen

@Soldaatje • 18 mei 2024 07:30

Ik snap eigenlijk niet waarom een encrypted disk automatisch unlocked moet worden. Dat helpt toch de hele point van encryptie om zeep? Als je je laptop kwijt raakt kan iemand gelijk bij jouw hele disk door simpelweg het systeem op te starten. Het enige waar het dan nog tegen zou beschermen is als iemand de disk uit de machine haalt en ergens anders in stopt. Maar wie steelt er ooit een losse disk uit een laptop? Makkelijker om gewoon het hele apparaat mee te nemen.
Dus ik blijf lekker mijn luks wachtwoord typen bij het opstarten. Ook geen TPM voor nodig, dus als je moederbord overleid kun je nog steeds bij je data.

Soldaatje
@kozue • 18 mei 2024 10:45

Voor een laptop maakt het niet veel uit inderdaad, dan kan je gewoon het wachtwoord intypen maar voor servers die thuis draaien en je wil op afstand kunnen rebooten is het wel handig.

kozue

Besturingssystemen

@Soldaatje • 19 mei 2024 07:39

Voor servers maakt het nog veel minder uit. De point van disk encryptie is om de data te beschermen wanneer deze bij iemand beland die er geen toegang toe hoort te hebben. Als die disk nooit je huis verlaat, waarom überhaupt encrypten? Het enige wat ik me kan bedenken is wanneer iemand inbreekt in je huis en de disks uit je server meeneemt. Maar dan kom je terug op het punt wat ik hierboven al maakte: het is veel makkelijker om gewoon de hele server mee te nemen dan om m ter plekke open te maken. Als je de hele server meeneemt unlockt ie automatisch bij het opstarten en kun je meteen overal bij.

Een waarschijnlijker scenario is dat iemand op afstand in je server inbreekt. Via zerodays, onbekende lekken, nog ongepatchte services, verouderde software/libraries, bugs in eigen code, of wat dan ook. En daar helpt de encryptie helemaal niets tegen, want je systeem draait al met alles unlocked. Anders zou je systeem immers niet opstarten

Overal maar klakkeloos encryptie op zetten is voornamelijk een nutteloze performance hit. Je moet wel na blijven denken over de meerwaarde van dat soort functies. Encryptie met auto-unlock doe ik dus niet aan. Ik gebruik het wel op m’n werklaptop om de data te beschermen bij verlies, maar alleen met het zelf invoeren van een wachtwoord. Op servers laat ik het lekker zitten.

Soldaatje
@kozue • 19 mei 2024 12:51

Als je de hele server meeneemt unlockt ie automatisch bij het opstarten en kun je meteen overal bij.

Klopt met TPM is dat zo, ze nemen de hele server mee, starten hem weer op en hij wordt unlocked. Dan is het aan de software die erop draait om de data te beschermen.
Met Tang en Clevis is dit anders, ze moeten namelijk ook mijn Tang-server meenemen om te kunnen unlocken. Mijn Tang-server draait op een Raspberry PI, dus die kunnen ze makkelijk meenemen maar zodra de stroom eraf gaat worden de sleutels gelocked door EncFS. Dus ze moeten én mijn servers stelen én mijn Tang-server én de Tang-server moet altijd van stroom voorzien blijven. Ik zie niet hoe ze dat voor elkaar gaan krijgen.

Een waarschijnlijker scenario is dat iemand op afstand in je server inbreekt. Via zerodays, onbekende lekken, nog ongepatchte services, verouderde software/libraries, bugs in eigen code, of wat dan ook. En daar helpt de encryptie helemaal niets tegen, want je systeem draait al met alles unlocked. Anders zou je systeem immers niet opstarten

Uiteraard is encryptie geen oplossing voor alles wat mis kan gaan met een server.

Overal maar klakkeloos encryptie op zetten is voornamelijk een nutteloze performance hit. Je moet wel na blijven denken over de meerwaarde van dat soort functies. Encryptie met auto-unlock doe ik dus niet aan. Ik gebruik het wel op m’n werklaptop om de data te beschermen bij verlies, maar alleen met het zelf invoeren van een wachtwoord. Op servers laat ik het lekker zitten.

Hier ben ik het niet helemaal mee eens, de meeste nieuwere CPU's hebben de AES-instructie ingebakken dus de impact op performance van encryptie/decryptie is verwaarloosbaar.

Overigens is er nog een ander argument om encryptie te gebruiken, namelijk als een schijf kapot gaat dan hoeft deze niet fysiek vernietigd te worden, zodat de niet-versleutelde data die erop staat hersteld zou kunnen worden. Bron Redhat

HollowGamer
@Soldaatje • 17 mei 2024 20:42

Ik heb hier nog nooit van gehoord. Maar je kunt bijvoorbeeld ook een USB maken die een key laadt en dan unlocked.

Soldaatje
@HollowGamer • 17 mei 2024 22:13

Het is een vorm van Network Bound Disk Encryption. Ik had er ook niet eerder van gehoord, het voordeel is dat ik niet steeds de usb stick hoef mee te nemen per computer en dat ik kan laten rebooten zonder wachtwoord op afstand.

savale
@Soldaatje • 18 mei 2024 08:37

Klinkt interssant! Kan niet helemaal vinden wat je hebt. Heb je een linkje naar de juiste richting?

Soldaatje
@savale • 18 mei 2024 11:08

Het beste kan je beginnen bij de source van de pakketten: tang en clevis. Er zijn ook meerdere tutorials te vinden zoals deze.

MneoreJ
17 mei 2024 19:31

Wayland is inmiddels bijna 16 jaar in ontwikkeling en nog altijd net niet de mainstream default. Dat is overigens geen kritiek, maar geeft wel te denken over hoe ongelooflijk X verankerd is. En dat terwijl het met Wayland juist de bedoeling was dat alle legacy meuk die X vervelend maakt om te ondersteunen van tafel geveegd zou kunnen worden. Dat laatste heeft er in ieder geval niet voor gezorgd dat het makkelijk migreren is.

Ik ben maar een simpele ziel met een enkele monitor per systeem, dus ik blijf geduldig bij X totdat alle andere mensen over zijn, aangezien Wayland me niets biedt dat ik nodig heb. Temeer daar ik ook nog gewoon game en er met X nog altijd minder complicaties zijn op dat gebied dan met Wayland.

Guru Evi
@MneoreJ • 17 mei 2024 20:01

Er is echt niet veel veranderd in X, het is gewoon meer stabiel en het 'werkt' gewoon. En het grootste deel van applicaties op Wayland gebruikt XWayland want Wayland op zichzelf heeft bijna niets qua standaarden of ondersteuning. Copy-paste, screen lock, zelfs applicatie icoontjes, het delen van vensters en het inlezen van absolute/relatieve posities moet elke desktop manager (KDE, Gnome, XFCE ...) die zaken individueel her-implementeren zodat elke applicatie enkel maar op KDE of enkel maar op Gnome zal werken of een implementatie voor elk van de 15 grote window systemen maken.

Het duurt een tiental jaren omdat ze X verwijten stagnant te zijn omdat elke beslissing door committee moet gaan, terwijl ze de-facto zelf een committee vormen voor letterlijk alle simpele dingen die een window manager in principe zou moeten doen uit de doos en dan zijn al die extensies nog optioneel ook. Er is zodanig veel indirectie dat ze nu al problemen hebben met CPU instructie cache flushes (omdat elke window/extensie een eigen "programma" heeft ipv een single binary en omdat alle berichtjes via dbus moeten) en omdat alles verbonden is, crashen alle programma's eenmaal de onderliggende Wayland thread herstart moet worden.

https://gist.github.com/p...0257af5dd915e3a9f2d1f2277

[Reactie gewijzigd door Guru Evi op 17 mei 2024 20:12]

emansom
@Guru Evi • 18 mei 2024 01:34

Je refereert naar problemen met CPU cache flushes veroorzaakt door het Wayland ecosysteem: heb je daar enige referenties/achtergrond info over?

Niet offensief bedoeld, enkel uit interesse.

Guru Evi
@emansom • 20 mei 2024 00:12

Zoek maar eens op "High CPU usage wayland" en ook "high memory usage wayland" simpele dingen zoals de muis bewegen of zelfs keyboards in 'vreemde karakters' die constant berichtjes heen en weer zoemen waardoor Gnome/DBus hoge CPU verbruiken (aka context switches). Natuurlijk het idee van portals etc zorgt ervoor dat er veel geheugen verbruikt wordt door dingen die staan te wachten op berichtjes.

En dan ofwel krijg je het bericht dat ze het probleem niet kunnen repliceren omdat context switch problemen vaak afhankelijk zijn van de CPU en natuurlijk draaien de devs waarschijnlijk AMD gaming dozen met gigabytes aan geheugen en af en toe lossen ze het probleem op door minder berichtjes heen en weer te duwen (dus het probleem naar de toekomst zenden).

Voor een degelijke programmeur weet je snel waar te kijken met zulke problemen, echter de architectuur zelf laat niet toe om dit op te lossen. De beste oplossing zou meer in de core te compileren of een gedeeld geheugen ipv portals, pipewire en dbus te gebruiken.

kaas-schaaf
@Guru Evi • 19 mei 2024 09:35

Persoonlijk vind het meest annoying het verlaten van het klassieke client/server model door die minimalistische implementatie. In heb meerdere x clients op headless devices staan en die je dan prima via ssh en een x server kan benaderen (handig voor als je geen zin hebt in sql bijvoorbeeld). Met wayland is dat volstrekt onmogelijk op een normale manier.

kozue

Besturingssystemen

@MneoreJ • 18 mei 2024 07:15

Ik heb zelf ondertussen een aversie gekregen tegen dat hele Wayland gebeuren. Iedere keer dat ik een nieuwe installatie uitvoer loop ik weer tegen problemen of irritaties aan die onder X11 niet bestonden.

Geavanceerde instellingen voor je beeldscherm werken bv ineens niet meer. Waar je vroeger via de commandline met xrandr van alles aan kon passen, zit je nu ineens vast aan de beperkte mogelijkheden van de control center van je desktopomgeving. Wat als ik daar niet genoeg aan heb, of gewoon een CLI tool nodig heb? Zo was TV-out een drama onder Wayland. De GUI lijkt dat niet of maar heel basic te ondersteunen (want ja, TV-out op videokaarten lijkt al een tijdje dood sinds de overstap naar HDMI), maar ik gebruik nog regelmatig PAL apparaten voor mijn hobby’s.

En ik hecht waarde aan een consistente desktop, maar in Wayland doen ze dat blijkbaar niet. Ze hebben geen ondersteuning voor standaard window decorators (de vensterbalk met titel en knoppen), dus onder Wayland moet de applicatie die zelf renderen. Dat gaat wel ok voor applicaties die native bij de desktop horen, maar wanneer je iets draait wat niet bij de desktop hoort (zoals Qt onder Gnome), krijg je iets anders wat niet meer in je desktop integreert. Of als je pech hebt helemaal niets (is zeldzaam maar heb ik ook wel eens gezien). En ik gebruik best veel non-gnome software onder gnome. En ik draai in dark mode, dus die lelijke witte balken stoor ik me aan.

En nog wel meer dingen die ik vergeten ben. Sommigen zijn vast wel op te lossen (nieuwe xrandr tool bouwen bv, maar waarom zouden ze nog tijd steken in TV-out/PAL?), maar anderen zijn een designkeuze in Wayland en dus niet te fixen (inconsistente window decorators). Bovendien heb ik geen problemen met Xorg, dus het is vanuit mij gezien een oplossing voor een niet-bestaand probleem. Dus ik blijf lekker op Xorg hangen. Als ze dat op een dag niet meer ondersteunen in Ubuntu, wordt het tijd voor een andere distro denk ik.

Alhoewel ik daar sowieso al mee begonnen ben. Ik draai op m’n werklaptop tegenwoordig PopOS, want ik ben ook klaar met dat belachelijke geduw naar snap. Iedere keer weer moeite doen om Firefox terug te zetten naar deb is best irritant, en ze zijn steeds meer applicaties aan het omzetten Ik wil geen snap. Snap is een diskspace en memory hog, een bron van integratie problemen en een security nachtmerrie (iedere applicatie moet los z’n libraries bijwerken).

johnbetonschaar
@kozue • 18 mei 2024 10:42

Ik ben niet echt pro of anti Wayland of X11, voor mijn toepassing en hardware werkt Wayland prima maar ik kan me goed voorstellen dat het in specifieke situaties X11 beter werkt. Op dezelfde manier dat voor bepaalde dingen Windows XP of zelfs DOS vandaag de dag nog geschikter is dan Windows 11 bijvoorbeeld, en dat waarschijnlijk altijd zal blijven.

Echter waar het over Xrandr gaat en hoe X11 het aan applicaties overlaat om met de beeldscherm instellingen te klooien ben ik echt blij dat dit met Wayland verleden tijd is. De display server moet gewoon altijd alle schermen met optimale settings aansturen, dus native resolutie, VRR, optioneel HDR etc. Dit is echt veel beter dan hoe het op X11 is waar applicaties (denk aan fullscreen games etc) zelf de resolutie en framerate kunnen instellen, of dingen als scherm rotatie, schaling etc. In theorie klinkt dat handig en logisch maar in de praktijk levert het allemaal problemen op die je met moderne hardware met VRR en goede upscalers en tone mappers etc niet hoeft te hebben.

De Steam Deck is hier een voorbeeld van, omdat daar alles in een Wayland compositor draait (met daarin de games via Xwayland) kun je naadloos games draaien van het DOS tijdperk tot moderne games, op instelbare resoluties en framerates, framerate en resolutie limiters om batterij te besparen, retro pixel upscales voor 8-bit stijl games, etc. En dat allemaal zonder flitsend scherm bij het opstarten, naadloos switchen tussen game en OS, etc, en zonder dat de games daar iets van hoeven te weten.

kaas-schaaf
@johnbetonschaar • 19 mei 2024 09:39

Dit is echt veel beter dan hoe het op X11 is waar applicaties (denk aan fullscreen games etc) zelf de resolutie en framerate kunnen instellen, of dingen als scherm rotatie, schaling etc.

Ik weet niet of je het door hebt maar dit is de default op vrijwel alle os'en behalve die van Apple. En ik ben daar blij om want niet iedere applicatie wil ik in idioot oversized letters hebben omdat de scaling dat zo graag wil. En voor iedereen die geen extreme high end gpu heeft ook wel handig.

johnbetonschaar
@kaas-schaaf • 19 mei 2024 14:08

Het is helemaal niet de default op alle OS-en, ook op Windows draaien veruit de meeste spellen tegenwoordig standaard als borderless windowed.

Dit heeft niks met ‘extreme GPU’ te maken en voor je beeldkwaliteit maakt het ook niks uit. We hebben tegenwoordig geen CRT’s meer die verschillende resoluties kunnen weergeven dus ergens zal hoe dan ook moeten worden geschaald naar de native resolutie van het scherm, en in de meeste gevallen is upscalen door OS/GPU beter dan het scherm laten upscalen want zo verschrikkelijk goed zijn de upscalers van een gemiddelde monitor niet. Het heeft echt geen enkele zin om de resolutie van een LED scherm op iets anders dan native in te stellen (edit: ok, ik kan 1 reden verzinnen: als de combinatie van je scherm en HDMI/DP bekabeling/bandbreedte de maximale framerate niet op de native resolutie halen maar wel op een geschaalde mode). Refresh rate zou nog een probleem kunnen zijn als een game per se een framerate wil uitsturen die geen deler is van de refresh rate van het scherm, daarom schrijf ik ook dat VRR hiervoor een randvoorwaarde is. Zo’n beetje elke moderne gaming monitor heeft tegenwoordig VRR dus dat probleem is al zo goed als verleden tijd.

Je verhaal over het scalen van desktops en fonts en Apple dit en dat heeft hier helemaal nul komma nul mee te maken, dat gaat over dpi scaling en heeft niks met de render resolutie, framerate of kleurruimte van games te maken. Het is ook nog eens onwaar dat ‘alleen Apple’ dit met system-wide dpi scaling oplost (wat trouwens een prima oplossing is zeker nu de dpi ondergrens voor goede schermen zo hoog is dat de mogelijke scaling artefacts praktisch niet te zien zijn), want bijvoorbeeld KDE en Cinnamon doen precies hetzelfde.

[Reactie gewijzigd door johnbetonschaar op 19 mei 2024 14:19]

mekkieboek
@MneoreJ • 17 mei 2024 22:10

Ook op andere gebieden zijn er nog complicaties. Mijn distro was ook geswitched naar default wayland en ik merkte dat pas toen ik mijn scherm wilde delen in een conference call, zwart beeld en niet goed te krijgen. Na veel frustratie en tijdverlies bleek wayland de veroorzaker. Het zal vast wel goedkomen met wayland maar ik moet ook kunnen (thuis)werken en blijf nog maar even op X11 (en blij dat dat uberhaupt kan met weinig moeite, dat dan weer wel).

Het is een complex gebeuren (ik weet niet half hoe complex) en de devvers moeten bereid zijn ook de laatste 20% goed te krijgen. Zie b.v. pipewire vs pulseaudio/alsa, Linux audio is in feite volwassen geworden sinds pipewire. Maar dat kost moeite en doorzettingsvermogen.

beerse

Besturingssystemen

@MneoreJ • 18 mei 2024 11:16

Volgens mij zal wayland nooit x11 vervangen. Naar mijn idee blijven ze naast elkaar voort bestaan. Voor vele gebruikers heeft X11 niet genoeg nadelen om over te stappen naar iets anders zoals wayland. Aal de andere kant zijn er voor wayland genoeg redenen van bestaan en ook genoeg gebruikers om de verdere ontwikkeling te verantwoorden.

Vergelijk het met het gebruik van kde, gnome of andere window/display managers. Daar is de keuze ook altijd nog ruim genoeg. En elk heeft ook daar haar reden voor bestaan. En zo ook de diverse linux distributies. Of installatie pakket formaten. Of andere belangrijke zaken. Een linux gebruiker is er vooral voor de eigen keuze. Soms een bewuste keuze, soms een oorzaak-gevolg keuze, soms een onbewuste keuze.

MornixRS
@MneoreJ • 21 mei 2024 12:37

Exact mijn situatie. Ik begin er dus ook nog niet aan.

braboman
17 mei 2024 19:26

Ik vind Ubuntu de laatste tijd wel erg snel nieuwe packages meenemen. Onlangs Ubuntu 24.04 geïnstalleerd en daar zat Python 3.12 al in. Niet heel handig omdat er voor veel packages nog helemaal geen 3.12 compatible release is. Verder wel super tevreden met 24.04.

ard1998
@braboman • 17 mei 2024 19:57

Dat is omdat het 12 jaar ondersteunt gaat worden. dan is het handiger om bij het begin van de ondersteuning bij te zijn met de nieuwste pakketten. Bovendien is de LTS aanbeveling om pas vanaf .1 mee te gaan, en tegen die tijd zullen de populaire libraries geupdate zijn voor 3.12.

- peter -
17 mei 2024 19:31

Hier kijk ik naar uit. Met de nieuwe explicit sync support in Gnome/Wayland icm de komende Nvidia drivers zou Wayland eindelijk zonder issues moeten werken. T werkt al grotendeels, maar sommige applicaties hebben rare flickeringen en delays in bijv menu selectie. Ik gebruik t nu al wel, en t is lekker vloeiend. Maar t blijft soms wat behelpen nog.

The Otherside
@- peter - • 17 mei 2024 21:38

Kijk ook rijkhalzend uit naar explicit sync. Te veel apps werken niet of slecht(er) i.c.m. nvidia kaart. Veelal de apps die Xwayland gebruiken of electron gaan vaak nat. Zelfs gaming werkt stuk matiger onder wayland met rare sync issues.

Voor nu toch weer terug op X11, todat explicit sync uit is.

nout77
17 mei 2024 20:24

Wel heel fijn dat Wayland vanaf oktober dan ook op Nvidia gaat werken, ik kijk er naar uit! De afgelopen jaren heeft Nvidia hun closed source user space driver maar mondjesmaat geschikt gemaakt voor Wayland en pas het laatste jaar wat meer ontwikkeltijd er ingestoken. Goed dat het aantal openstaande bugs inmiddels te overzien is. Hopelijk komt 24.10 dan ook met Linux kernel 6.10 die ook heel wat verbeteringen met zich mee brengt.

kozue

Besturingssystemen

@nout77 • 18 mei 2024 07:37

Het jammere aan die closed source driver is dat ze alleen maar recente kaarten ondersteunen. Voor oudere kaarten heb je oudere drivers nodig (daarom zitten er altijd heel veel versies in distro’s), en die gaan ze niet meer updaten. Als iemand die nauwelijks op de PC gamed ga ik geen dure nieuwe videokaart kopen, alleen maar om de nieuwste driver te kunnen gebruiken (en nog een closed source blob ook, kan ik beter een AMD halen). Een oude goedkopie is ook prima voor het soort spellen wat ik dan zou doen.

Overigens is dat voor mij niet zo relevant meer. Ik heb al jaren geleden die oude nvidia kaart eruit gehaald en overgeschakeld naar de onboard Intel chip. Die bleek ongeveer dezelfde performance te hebben, en draait mijn oude games nog prima. Wayland draai ik niet om andere redenen.

eclipce
17 mei 2024 19:37

Naar mijn weten hadden ze een tijd geleden al wayland als default ingesteld. Ik vond het zelf een verademing. Alles voelde een stuk sneller aan. Zeker op grote beeldschermen.

Ik draaide linux ook een tijd prive, maar ik stoorde me ontzettend aan de screentearing bij X11 wanneer ik een filmpje wilde kijken.

Nadat ik erin gedoken ben, viel bij mij bij veel reclame-schermen de screentearing ook op. Ik kan nu nooit meer over een station lopen zonder aan X11 te denken

Sp3ci3s8472
@eclipce • 18 mei 2024 14:24

NIks tegen Wayland want ik wil uiteindelijk overstappen; maar ik heb het laatste jaar geen last gehad van enige screen tearing op Linux (EndeavourOS met XFCE. Ik gebruik dan wel een AMD gpu en heb adaptive sync aanstaan; maar zelfs op mijn secundaire scherm dat geen adaptive sync heeft heb ik er geen last van.

MornixRS
@eclipce • 21 mei 2024 12:38

Eh werkelijk nog nooit meegemaakt. In welke situatie ervaar jij dit?

2green
18 mei 2024 11:04

Ik dacht echt dat Ubuntu al default op Wayland zat, maar gebruik zelf geen nvidia (wat jaren terug bewust omgekeerd was).

Sp3ci3s8472
18 mei 2024 14:26

Heeft wel lang geduurd voordat Wayland eindelijk goed genoeg op Nvidia hardware werkt; maar ik kan goed begrijpen dat dat een stuk lastiger was met hun gesloten drivers op Linux.

Hopen dat dit weer de adoptie gaat versnellen uiteindelijk.

The Zep Man

Besturingssystemen

17 mei 2024 20:21

Geen ondersteuning om de primaire GPU te kiezen met Optimus? Geen deal.

Dit is iets wat nog steeds mist met Wayland, en de reden dat ik X.org blijf gebruiken. Als ik niet kan overschakelen naar de discrete GPU dan hapert het beeld op externe monitoren.

[Reactie gewijzigd door The Zep Man op 17 mei 2024 20:25]

mrtak
20 mei 2024 23:04

Super tof die tweakers-reacties.
Ik lees alle dingen die ik ook heb met X11 vs Wayland.
We zijn niet gek. We gebruiken linux.

Op dit item kan niet meer gereageerd worden.

Ubuntu krijgt in 24.10 mogelijk standaard Wayland-ondersteuning bij Nvidia-gpu's (2024)

References