Ubuntu 22.04 LTS verschijnt met Gnome 42 en betere Raspberry Pi-compatibiliteit

Canonical heeft Ubuntu 22.04 LTS uitgebracht. Deze nieuwe OS-versie brengt onder meer versie 42 van de Gnome-desktopomgeving met zich mee. Ook worden Raspberry Pi-modellen met 2GB geheugen officieel ondersteund en wordt Wayland standaard gebruikt.

Ubuntu 22.04 krijgt de codenaam Jammy Jellyfish en is een LTS-release. Daarmee wordt deze versie van het besturingssysteem vijf jaar lang voorzien van beveiligingsupdates en ondersteuning, tot in 2027. Canonical brengt dergelijke LTS-versies iedere twee jaar uit. De vorige LTS-build was 20.04 LTS, die tot 2025 wordt ondersteund. Gebruikers kunnen het OS downloaden via de Ubuntu-website, of hun bestaande Ubuntu-installatie upgraden.

Versie 22.04 brengt verschillende nieuwe features met zich mee ten opzichte van voorgaande releases. Zo is Wayland voortaan weer de standaard displayserver, in plaats van Xorg. Bij de release geldt dat alleen nog niet voor systemen met een Nvidia-videokaart, vanwege bekende bugs en problemen. Gebruikers kunnen verder nog steeds kiezen voor Xorg door deze displayserver te selecteren bij het inloggen.

Het nieuwe OS krijgt verder standaard betere compatibiliteit voor Raspberry Pi's. Voortaan worden 2GB-modellen van die singleboardcomputers standaard ondersteund. Canonical deelde eerder al details over hoe dat is bereikt. Gebruikers konden deze ondersteuning eerder al inschakelen door bepaalde zswap-instellingen te wijzigen, maar vanaf Ubuntu 22.04 is dit standaard.

Verder wordt Ubuntu 22.04 grotendeels geleverd met versie 42 van de Gnome-desktop. Wel worden bepaalde onderdelen van Gnome geleverd als versie 41, omdat het team de nieuwe varianten nog niet voldoende kon testen.

Gebruikers kunnen onder meer nieuwe accentkleuren voor het OS kiezen en gebruikers krijgen voortaan ook de optie om de dock kleiner te maken. Voorheen reikte die standaard de volledige lengte of breedte van een scherm. Het OS wordt ook standaard geleverd met nieuwere versies van bepaalde applicaties, zoals Firefox 99, Thunderbird 91 en Libreoffice 7.3. Firefox wordt voortaan ook geleverd als een Snap-package. Gebruikers kunnen de deb-versie nog wel handmatig installeren.

Reacties (103)

Het schijnt dat Firefox sinds deze release in Ubuntu alleen nog als Snap beschikbaar is i.p.v. een native deb-package. Ik zit er totaal niet op te wachten, maar iemand al ervaring met het upgrade-pad daarnaartoe? Worden bestaande installaties en instellingen netjes overgezet? Ik vind het wel een deal-breaker eerlijk gezegd...

[Reactie gewijzigd door zordaz op 21 april 2022 20:10]

Dit is echt shit inderdaad. Had gewoon de keuze gegeven.

Maar Mozilla heeft een eigen repo die je kan toevoegen. Flatpaks wil ik ook niet, ik wil alles gewoon in mijn systeem zodat de dynamic libraries hun ding kunnen doen.

Die repo is: https://launchpad.net/~mozillateam/+archive/ubuntu/ppa . Ik werd er ook door iemand anders op gewezen overigens ). Ik doe zelf bijna niks meer met Ubuntu, alleen nog met servers die lang ondersteund moeten blijven, en dan is firefox niet echt een ding. Niettemin was snap wel de laatste druppel die me heeft doen overstappen voor desktop gebruik. Daar heb ik nu FreeBSD voor (met veel meer tevredenheid).

[Reactie gewijzigd door GekkePrutser op 21 april 2022 21:21]

In den beginne was de tagline van Linux Mint "Ubuntu how it should be". Een Ubuntu-gebruiker ziet vaak geen meerwaarde in Linux Mint, totdat ze zelf meemaken dat hun favoriete package of onderdeel wordt geschrapt.

In dat licht is het misschien voor deze LTS-release interessant om even te wachten op de release van Linux Mint over een maand of twee. Een paar jaar terug schreven ze alvast het volgende over snap:

When snap was announced it was supposed to be a solution, not a problem. It was supposed to make it possible to run newer apps on top of older libraries and to let 3rd party editors publish their software easily towards multiple distributions, just like Flatpak and AppImage. What we didn’t want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors [and] to prevent direct distribution from editors [through] what is essentially a commercial store operated by a RedHat competitor [and] it’s wrong for any vendor to think that such a store can be the only store for all Linux users. For this to work it would need to be governed by us all, with clear goals, without bias and without conflict of interest. [In stead,] it could reduce access to free (as in beer) software and free (as in freedom) software.

There are a lot of things you can do with package managers (apt/dpkg in Linux Mint), that you can’t do with Snap, and there are two reasons for this. First, they’ve been around for a while. They’re mature, they’re integrated fully within the OS in every distributions. Second, they’ve been developed with Free Software in mind. There are no commercial aspects in the design of apt/dpkg, it’s all about empowering users and distributions. You can’t modify, rebuild, pin, patch, mirror a snap, you’re not supposed to.

There’s a certain sense of urgency which demands action on our side. Ubuntu is planning to replace the Chromium repository package with an empty package which installs the Chromium snap. In other words, as you install APT updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back. This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT. [...] We don’t want this to affect Linux Mint.

A self-installing Snap Store which overwrites part of our APT package base is a complete NO NO. It’s something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint.

En de follow-up na de vorige release:

A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.

First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed. Second, to address this situation we’ll do exactly what we said we would:

• In Linux Mint 20, Chromium won’t be an empty package which installs snapd behind your back. It will be an empty package which tells you why it’s empty and tells you where to look to get Chromium yourself.
• In Linux Mint 20, APT will forbid snapd from getting installed.

[Reactie gewijzigd door Redsandro op 22 april 2022 01:56]

ik geef ook de voorkeur aan een .deb, maar met flatpack is ook niet zoveel mis hoor. Als gebruiker heb je er weinig nadeel van.

Dit in tegenstelling tot Snap wat gewoon baggertraag is.

Flatpak - a security nightmare

Wat is het voordeel van pacman?

Niks vergeleken met apt. Conceptueel is het exact hetzelfde namelijk een package manager.

Pacman wordt gebruikt door de Arch Linux distributie. Deze heeft een rolling release filosofie.

Rolling release druppelt wel langzamerhand de Enterprise wereld in maar LTS releases worden zakelijk toch altijd nog meer gebruikt.

[Reactie gewijzigd door coolkil op 21 april 2022 23:54]

Snap (en ook Flatpak) ben ik zelf ook geen fan van. Gebruik nu maar Librewolf.

De vraag is alleen waarom je er geen fan van bent. Er zijn legitieme redenen, maar voor de meeste mensen lijkt het meer een "change is bad" dingetje te zijn.

edit voor @zordaz en @NielsFL: Ik ervaar zelf de traagheid niet zo met Flatpaks en Snaps, maar verder zijn jullie argumenten valide wat mij betreft. Ik ben ook zeker van mening dat beiden nog wel wat werk kunnen gebruiken, maar ik denk wel dat het idee er achter, namelijk het draaien van applicaties in een sandbox, in principe een goed idee is.

[Reactie gewijzigd door rbr320 op 21 april 2022 23:35]

De vraag is alleen waarom je er geen fan van bent.

1. Snaps zijn (veel) groter, je hebt duplicates van alle dependencies
2. Snaps zijn (aanzienlijk) trager
3. De backend is closed-source
4. Snaps zelf zijn closed-source en niet te inspecteren/controleren
5. De snapd daemon draait met root-rechten
6. Clement Lefebvre (van Linux Mint) zegt ook beter van niet

Ik vind de auto-updates van Snap ook een enorm nadeel. Dat zou een optie moeten zijn, geen verplichting. Je kunt wachten op serieuze issues vanwege dit principe.

[Reactie gewijzigd door zordaz op 22 april 2022 14:07]

De installatie instructies voor certbot gaan via snapd is dat dan anders dan waar het hier over gaat?

Ik gebruik incidenteel ook Flatpak en Snap-versies. In de praktijk levert het de eindgebruiker echter vaker nadeel dan voordeel op. Naast de performance issues (vooral bij Snap) leidt die Sandboxing ook vaak tot problemen of onlogisch gedrag van de applicatie. Soms ook tot inconsistenties in de UI, denk aan bijv. filechoosers e.d. Je ziet het nu ook bij de Snap versie van Firefox; daar werkt bepaalde functionaliteit dus niet en daarmee jaag je gebruikers gewoon weg.

Je zou verwachten dat dat soort kinderziektes er na een jaar of 5 wel uit zouden zijn bij Snap en Flatpak, maar verre van dat. Het is altijd maar afwachten als je er iets van installeert of het enigszins werkt en dat is best treurig.

De snap van DBeaver bijvoorbeeld werkt niet omdat je een 'local driver' aan moet wijzen in je /usr/bin directory; daar heeft de snap geen toegang toe. Om maar een voorbeeld te noemen.

Tweeledig:

1. Ik irriteer me aan de traagheid.
2. Apps werken niet meer zoals ik verwacht.

Die tweede is wat vaag, maar ik weet van allerlei apps precies in welke directories ik moet moet wezen, welke permissies nodig zijn, welke tweaks ik zelf doe, etc.

Bij een snap werkt dat dan weer opeens anders en moet ik mij daar opnieuw in verdiepen. Dat is kostbare tijd. Geen ramp als de hele Linux wereld die kant op beweegt, maar snaps zijn Ubuntu-specifiek.

Het is niet de linux wereld die een kant op beweegt, het zijn de distributies die hun kant op gaan om het voor zichzelf eenvoudig te maken. Gelukkig zijn er distributies genoeg om uit te kiezen en elk hebben zo hun eigen reden om wel of niet voor flatpack of snap te kiezen. Elders in deze draad word al melding gemaakt van LinuxMint. Zelf ben ik na een ubuntu-flatpack/snap issue overgestapt op Kali Linux.

Size matters

Ik had de beta al geinstalleerd van 2204. Firefox dus nu een snap, en traag.... Bij het opstarten 3-5 seconden. Vreselijk irritant. Heb hem verwijderd en de flatpak geinstalleerd. Die is wel snel genoeg.

Hier gaat Ubuntu nog veel klachten over krijgen.

Nou zeg dat is van de regen in de drup. Het probleem met problemen als snap en flatpak is niet de snelheid, maar het model.

Wat is er mis met het model van het sandboxen van applicaties zodat ze niet meer toegang hebben tot het systeem dan strikt noodzakelijk?

Eerlijkheid gebied me te zeggen dat ik ook gemengde gevoelens heb met betrekking tot snaps en in mindere mate flatpaks. Er zitten zeker voordelen aan, maar er zijn ook wel enkele nadelen te noemen. Overigens is willen besparen op packaging zoals @- peter - beweerd nooit een argument geweest. Sterker nog, voor snaps gaat dat niet op want die moet Canonical alsnog zelf packagen aangezien het aanleveren daarvan via hun eigen gesloten ecosysteem gaat.

Ik begreep dat er 2 fulltime developers bezig waren met Firefox te packagen voor alle ondersteunde Ubuntu versies. Maar misschien was dat niet correct. Nu hoeven ze maar 1 snap te maken en ondersteunt ie alles.

Als dat correct is dan begrijp ik wel waarom ze over willen gaan naar een snap package voor Firefox. Ik begrijp dat het onderhouden van een Linux distributie tijd kost, zeker als je meerdere versies in support hebt, maar 2 beheerders voor 1 package is toch wel van de zotten.

Nu hoeven ze maar 1 snap te maken en ondersteunt ie alles.

In Ubuntu ondersteunt de Firefox snap zeker niet alles: spellcheckers doen het niet en plugins zoals Video Downloadhelper doen het ook niet.

Nee, dat is volledig geautomatiseerd. Packagen is echt niet zo moeilijk.

Je bouwt 1 source tree die voor alle distributies een package kan maken. Natuurlijk is het zo dat een Firefox op een bepaald moment afhankelijk kan worden van een nieuwe versie van een library, maar de meeste open source applicaties zijn niet zo strikt afhankelijk van nieuwe library versies.

De overhead en resources. Op een 36 core processor zul je het niet snel merken maar heb jij bijvoorbeeld een rpi. Ja dan heb je vaak niet veel schijfruimte. En je 4 cores die bijvoorbeeld Netflix in de browser aan het cachen + afwerken zijn. Dat is een ander verhaal. (Ik denk dat ze voor de rpi daarom de swap space vergroot hebben )

[Reactie gewijzigd door rob12424 op 21 april 2022 23:12]

Ik snap dat ze willen besparen op packaging werk, dus ja minste van 2 kwaden.

Tja je begrijpt het probleem met het model dus niet.

Ik neem aan dat je doelt op alle layers van software die ze meeleveren in snaps en flatpaks ipv gedeelde libraries te gebruiken van het systeem zelf?
Daarom ook: minste van 2 kwaden. Debs zijn natuurlijk idealer, maar flatpak werkt tenminste sneller dan snap.

Er is een groot verschil. Snaps en flatpacks zijn er met een totaal ander doel.

Vroeger en tegenwoordig ook nog met .debs moest je symlinken up of downgrade van packages en kreeg je een depency hell in het ergste geval. Het nam weinig ruimte in dus was in eerste instantie niet zo erg.

Met Flatpacks en snaps is het zo dat bijvoorbeeld Firefox al zijn afhankelijkheden bij elkaar heeft. Je kan dus alles los van elkaar upgraden downgrade enz. Maar er is 1 super grote reden om dit te doen: een flatpacks of snap moet ook als een soort sandbox werken. Heb jij een virus in Firefox dan gaat alleen die snap of flatpack eraan (als het goed is) en niet de rest van je systeem! Bij een hackaanval idem dito.

Maar als we allemaal een libary van hetzelfde 10* installeren is dit bijvoorbeeld een embedded device niet altijd wenselijk

Niet dat ik 1 van beide gebruik, maar volgens mij zou een applicatie in een sandbox op Linux amper tijd mogen kosten. Een chroot/jail die gebruikers-I/O en een netwerklijn doorlinkt naar een afgeschermde omgeving...
Naar mijn idee moeten eigenlijk gewoon alle grote browsers compleet op de schop omdat ze belangen hebben in de reclamemarkt en daarom moeite hebben met transparant en modulair zijn.

Chroot/jail is net iets anders. Een Linux container komt dan meer in de buurt. Je weet dat Firefox geen winstoogmerk heeft dus reclame niet hun inkomstenbron is

Bij een chrootjail maak je een directory met extra root rechten aan die je vervolgens in een gevangenis stopt. Het is niet meer zo veilig als het was en kost aardig wat resources. (De Ch staat voor change) root.

Een Linux container komt meer in de buurt er is eigenlijk de verbeterde versie van een chrootjail van Unix.

Ik ben geen expert maar ik denk dat een flatpak of snap een minimalistische versie is van een linux container.

Wat zei eigenlijk meer creëren is wat ooit met Qubes OS al gepoogd is. Maar dan wat minder extreem.

Misschien is het een idee voor Tweakers om een keer een plus artikel te wijden aan de verschillen/overeenkomsten en ontwikkelingen en toekomstigheden van chrootjail, lxc en flatpacks en snaps?

[Reactie gewijzigd door rob12424 op 21 april 2022 22:36]

Dat zijn echt zoveel verschillende dingen. Ik kan je aanraden om "The Container Revolution: Reflections After the First Decade" eens te kijken.

Een chroot is iets anders dan een jail. Een Linux container is geen "verbeterde versie van", maar een volledig andere implementatie. Tussen (Docker/Linux) containers en full-blown virtualisatie zit een gigantisch verschil, Qubes is gestoeld op het tweede.

Ik bedoelde een chrootjail. En lxc containers LXC is eigenlijk een verbeterde versie van een chrootjail. Er werd o.a. bij de ontwikkeling van LXC al gewaarschuwd dat het aantal DDos aanvallen extreem zou gaan toe nemen. In verhouding tot vroeger. En ook een demo gegeven toen hoe en ook hoe je uit een chrootjail moest breken (wel legaal overigens)

En ja ik weet het verschil tussen een VM en een LXC en ook para virtualisatie enz.

Maar bedankt ik ga hem kijken.

Een chroot is iets anders dan een jail. Een Linux container is geen "verbeterde versie van", maar een volledig andere implementatie. Tussen (Docker/Linux) containers en full-blown virtualisatie zit een gigantisch verschil, Qubes is gestoeld op het tweede.

Het is dat je een +2 hebt gekregen: Volgens de geschiedenis is een chroot, in ieder geval onder unix en linux de basis van een jail. Er werd in de vorige eeuw al gesproken van een chrootjail.

De draad begon hier bij snap en flatpack. Dat is naar mijn idee juist een 'jail-light'. Waar de containers een mooi voorbeeld zijn van jails waarbij versie-afhankelijkheden netjes worden opgelost, hebben ze de versie-onafhankelijkheid daarvan uit de containers proberen te halen. Met een flatpack of een snap proberen ze de versie afhankelijkheid die applicaties hebben op libraries ook netjes te verwerken.

Voor speciale applicaties en misschien ook applicaties die juist buiten de repositories om worden aangeboden, zou dat wel handig/welkom zijn. Maar voor universele en veel gebruikte (desktop) applicaties zoals webbrowsers, office applicaties en email-software zouden ze dat juist niet moeten doen.

Snap en FlatPack zijn voor mij de grote reden geweest om van Ubuntu af te stappen en ook niet naar Fedora te gaan. Voor de desktop ben ik over naar Kali Linux. De 'usual suspects' zoals libreoffice, firefox en thunderbird zitten daar nog gewoon in geïnstalleerd. Ook de menu's zijn nog zoals ik ze graag zie zonder fancy geflabber van ikoontjes. En ook de roling--release heeft mijn voorkeur.

[Reactie gewijzigd door beerse op 22 april 2022 09:57]

Een probleem met chroot is dat browsers allemaal meer willen zijn dan andere programma's. Dat is waar het mis gaat, naar mijn mening.

Een probleem met chroot is dat browsers allemaal meer willen zijn dan andere programma's. Dat is waar het mis gaat, naar mijn mening.

Helemaal mee eens. Browsers zijn gigantisch complex. En tegelijk, ze krijgen de volledige vrijheid en kunnen overal bij. Op OpenBSD zijn de browsers voorzien van pledge en unveil; dat is echter geen sandboxing. De eerste is een beperking op de syscalls en de tweede op de toegang tot het filesystem; het is bijvoorbeeld niet mogelijk, met het standaard profiel, dat dr browser bij je SSH en GPG keys kan komen

Een ietwat vergelijkbare methode is voor Linux ook beschikbaar, bijvoorbeeld met AppArmor en Firejail (en eventueel linux-hardened en hardened_malloc voor wat extra bescherming). Ook is er sinds kort Landlock.

Helaas zijn die dingen niet standaard geforceerd. Een browser mag, in mijn ogen, flink aan banden gelegd worden.

Groot gelijk: ChromeOS laat zien dat de browser graag het os, de display en de windows omgeving is.

En aan de andere kant is dat juist de reden dat de browser misschien toch wel in een 'jail' gestoken zou moeten worden.

Meer dan dat. De inkomende en uitgaande data, plus wat er binnen die jail wordt opgeslagen en gelezen moet precies in kaart gebracht worden. Het uitdelen van gebruikersinformatie aan grote bedrijven via secundaire cookie-url's op websites kan nog steeds binnen elke afgeschermde omgeving. Dat is feitelijk gewoon een legale hack met lokale schrijftoegang als bereikt doel..

[Reactie gewijzigd door blorf op 22 april 2022 10:33]

Het schijnt dat Firefox sinds deze release in Ubuntu alleen nog als Snap beschikbaar is i.p.v. een native deb-package.

Ik mag toch hopen dat niet alles naar snap gaat, typisch weer iets waar je niet op zit te wachten. Komt er een release later weer een mooie wrapper om snap heen en dan heb je weer drie lagen waar shit stuk kan gaan.

Geen idee waarom je nog een wrapper om snap heen zou willen maken, het lijkt me niet dat dat gaat gebeuren. Ubuntu Core is een distro die al volledig is opgebouwd door middel van snap packages, inclusief de kernel. Ik begrijp ergens wel waarom Canonical die kant op wil gaan, maar ik sta er zelf ook niet helemaal achter, alleen al omdat de backend van snaps niet open source is.

Die geweldige(...) Electron apps in combinatie met Snap (of Flatpak) kun je beschouwen als een soort wrapper om een wrapper en zijn daarom vaak bizar groot. Het is wel het omgekeerde van wat jij schrijft, maar het idee is hetzelfde.

En wellicht komt zo'n wrapper er straks inderdaad wel, want waar je vroeger hoofdzakelijk deb/rpm/tar had (en nog steeds), zit je nu met Snap/Flatpak/AppImage. En natuurlijk is niet alles in elk formaat beschikbaar. Wie weet lost zo'n wrapper dat wel op... De geschiedenis herhaalt zich dan weer eens...

Klopt. Standaard als snap. Je kunt uiteraard ook de flatpak installeren mocht dat handiger/beter zijn.

De tragere opstarttijd van de snap valt nog wel mee, het is enkel de eerste keer na het opstarten dat het iets langer duurt. Vervelender vond ik dat je met de Firefox-snap geen gebruik kunt maken van extensions.gnome.org. Dan moet je even een andere browser installeren om extensies in Gnome (de standaard DE in Ubuntu) te kunnen installeren/activeren.

Verder vind ik Ubuntu 22.04 erg prettig werken.

Ook voor die reden gebruik ik al jaren Ubuntu niet meer. Eigenlijk ben ik er weggegaan toen die amazon lense standaard werd meegeleverd.

Nog steeds onbegrijpelijk dat ze voor GNOME blijven gaan terwijl KDE veel geschikter lijkt voor al hun custom aanpassingen.

Daar heb je toch Kubuntu voor? https://kubuntu.org

Je kan ook gewoon kde metapackage installeren. Kubuntu is niet eens nodig.

Met hetzelfde idee kan je dan ook Debian Sid gebruiken en je benodigde packages naar keuze installeren.

Al die distro's, Linux zijn grootste zwakte.

Al die distro's, Linux zijn grootste zwakte.

Als FreeBSD gebruiker vind ik dat eigenlijk ook wel ja.. De aanwezige informatie over Linux is nogal gefragmenteerd.

Sommige distro's zijn erg sterk in documentatie zoals Arch, maar de dingen die je op de Arch wiki vind zijn lang niet altijd toepasbaar op andere distro's. Alhoewel Arch wel een megabreed gamma treft, je kan bijna alles zelf kiezen. Behalve het init systeem helaas wat ik juist liever zonder systemd zou willen.

Kubuntu is community-maintained.

Voor puur gnome heb je ook een variant: https://ubuntugnome.org/

Is wel verouderd voor zover ik kan zien.

is nog gnome2, daarvoor is mate/xfce in dat gat gedoken

Helaas ondersteunt dit alles alleen weer geen Wayland. Dat is nog erg beperkt qua window managers/desktop environments.

Zie het ook ja, via GitHub kan ik vinden dat het niet langer maintained is. Waarschijnlijk omdat Ubuntu de gnome kant op is gegaan paar jaar geleden.

sudo apt install vanilla-gnome-desktop

Klaar is kees!

....moest het even 2x lezen, maar beide DE zijn prima aanpasbaar, schaalbaar, kraakbaar etc. kde is voor de eindgebruiker wat 'uitgebeider' qua aanpassen look en feel. maar dan heb ik het over sliders en vinkjes zetten.

functioneel kun je beide tot in de treure aanpassen. als het zou gaan om snelheid en resources (minimaal) zou ik mate/xfce eerder logische keuze vinden. die gebruiken duidelijk minder geheugen/processor dan gnome of kde

overigens vind ik het vrij onlogisch dat een DE standaard geïnstalleerd/actief wordt met de rasberry-install tool. dat ze daar geen optie toegevoegd hebben; wil je interface, ja of nee ... zoals ik eva rasberry gebruiken is dat headless

[Reactie gewijzigd door himlims_ op 21 april 2022 17:18]

Het probleem met Gnome aanpassen is dat vrijwel alles met addons moet en die lopen vaak nogal achter met hun ondersteuning waardoor je met elke update weer gezeur hebt. Op zich niet zo'n probleem als ze een degelijke basis hadden, maar eigenlijk staan al hun keuzes me erg tegen. Dikke ruimteverslindende titelbalken en witruimte in de apps. Alles verborgen onder hamburger menu's. Zo weinig mogelijk opties. Zo kaal mogelijke UI. De hele designfilosofie staat me tegen (en is ook de reden dat ik prive niets meer met Mac doe omdat die ongeveer dezelfde insteek hebben). Dus om Gnome voor mij bruikbaar te maken zit je aan tig addons en dan wordt het gewoon een zooitje om goed werkend te krijgen en te houden.

Bij KDE is configureerbaarheid niet iets 'vies' wat anderen maar op moeten lossen, maar gewoon een eersteklas kernwaarde.

Gelukkig is er met FOSS gewoon voor ieder wat wils.

[Reactie gewijzigd door GekkePrutser op 21 april 2022 19:54]

Bij KDE is configureerbaarheid niet iets 'vies' wat anderen maar op moeten lossen, maar gewoon een eersteklas kernwaarde.

Ik denk dat dit precies de reden is, dat Ubuntu standaard met Gnome komt. Ubuntu blijft toch altijd een OS waarbij ze makkelijk nieuwe users willen werven, zonder dat deze users perse (veel) Linux ervaring hebben.

Gnome heeft out of the box niet heel veel features tov kde, maar ik denk dat praktisch iedereen er zijn weg wel in kan vinden (smaak blijft persoonlijk natuurlijk). Plain KDE (zonder tweaking) voelt voor mij altijd een beetje meh aan. Er is veel te halen, maar daarvoor moet je ook veel doen.

Ik heb een paar jaar lang Gnome gebruikt (tot 2 jaar geleden, toen ik van m'n nieuwe werkgever een MacBook kreeg) en heb op 2-5 extensies na altijd een prettige ervaring gehad met Gnome.

Tis meer dat GNOME heel erg opinionated is en Canonical best moet knokken om dingen aan te passen, terwijl KDE daar veel opener in is.

Subjectief toch? KDE is niet inherent beter dan Gnome.

Welke redenen zou iemand Ubuntu kiezen boven iets als CentOS of Fedora? Vooral dat laatste werkt uitstekend met YUM.. ?

Bekendheid, google maar eens op linux en installeren nginx of whatever, geheid dat je op een how to terecht komt waarbij ubuntu als voorbeeld gebruikt word. Men is dus al gauw geneigd dan ook maar dat OS te gebruiken denk ik.

Exact. Een paar jaar geleden ben ik begonnen met Ubuntu, simpelweg omdat je daar het makkelijkst antwoorden op je vragen voor vond. Toen een tijdje Kubuntu gedraaid, omdat ik KDE prettiger vind. En inmiddels draai ik Manjaro (met KDE).

Exact. Een paar jaar geleden ben ik begonnen met Ubuntu, simpelweg omdat je daar het makkelijkst antwoorden op je vragen voor vond. Toen een tijdje Kubuntu gedraaid, omdat ik KDE prettiger vind. En inmiddels draai ik Manjaro (met KDE).

En als kers op de taart zo dadelijk eens een BSD proberen? Weer leuk computeren met een echte Unix!

Ik denk dat het is wat je gewoon bent.
Zelf grijp ik altijd naar mint.
Zo weet ik hoe ik bepaalde quirks moet aanpakken om een deel applicaties nodig voor het werk te laten functioneren.

Vooral waar je mee begonnen bent, of aangeleerd gekregen hebt wellicht.
Ik heb het omgekeerde, waarom een CentOS/Fedora gebruiken als je al Ubuntu/Debian(/rasperry pi OS) gebruikt?

Welk voordeel biedt yum bijvoorbeeld tov. aptitude (apt update/upgrade/...)?

Zelf gebruik ik linux enkel voor servers/Raspberry pi zonder gui. Nog geen issues gehad met het OS. Draait allemaal stabiel en vlot.

[Reactie gewijzigd door SmokingCrop op 21 april 2022 20:22]

Wat apart, ik zou de vraag precies andersom stellen, in deze vergelijking. En Yum en RPMs zijn al helemaal niet echt een aanbeveling.
Los daarvan begrijp ik niet dat mensen Ubuntu kiezen in plaats van Debian. Ubuntu is in essentie Debian--.

Hoe was die grap ook weer?
"Ubuntu" is Swahili for 'can't install debian'

Ik werk veel met ST en zei ondersteunen vaak alleen ubuntu based systems (werkt ook prima op Debian en derivatives). Dus compatibiliteit is vaak voor mij wel een belangrijke factor.

Voor ARCH is er meestal wel een AUR package beschikbaar, maar niet altijd.

Alle andere platformen is vrijwel altijd een no-no.

En voor welk acronym staat ‘ST’ dan?

https://www.st.com/content/st_com/en.html

https://en.wikipedia.org/wiki/STMicroelectronics

dank je wel, deze club kende ik nog niet.

Voor mij; gewenning. Ik krijg maar niet in m'n systeem dat ik iets anders moet gebruiken dan apt als package manager.

Daarnaast is Ubuntu volgens mij nog steeds de meest gebruikte Linux distro, 9 van de 10 Google searches op Linux issues komen direct met een oplossing voor Ubuntu en voorheen vond ik de software support van de programma's die ik gebruikte op Ubuntu (of in mijn geval meestal Debian) beter dan op andere distro's.

Tussen Ubuntu aan de ene kant en centos/fedora aan de andere kant: Die zijn vergelijkbaar. Het verschil tussen die 2 kampen is vergelijkbaar met hun bronnen: Debian versus RedHat.

Voor mij is het verschil tussen Debian en RedHat dat Debian volledig open source is en RedHat is toch commercieel. Zelf ben ik 20 jaar geleden al van RedHat af gestapt. Op 1 of andere manier kom ik wel steeds weer bij Debian of een afgeleide terecht. Naar mijn ervaring en de geschiedenis zie ik Debian.deb pakketten en repositories als stabieler en flexibeler dan de redhat.rpm pakketten en repositories. Ook de bijgaande software is naar mijn ervaring minder aan verandering onderhevig.

Aan de andere kant zie ik zakelijk en/of commercieel juist dat daar meer gebruik gemaakt wordt van RedHat of afgeleiden. Dus als Linux specialist is het handig om beide kampen/kanten te kennen.

Verbaasd me niets dat ze Wayland met Nvidia standaard uitzetten. Wayland + Nvidia drivers is uit mijn ervaring echt bagger. Linus Torvalds is natuurlijk ook wel bekend met Nvidia

Hangt af van je drivers 495+ werkt opzicht goed mits je via gdm pakt. Los daarvan voegt in mijn optiek Wayland nog niet extreem veel toe tov X tenminste niet voor mij.

Ik denk dat het ook niet zozeer gaat over of het iets toegevoegd. Ik denk dat het belangrijk is dat wayland feature complete is zodat het xOrg kan vervangen. Ik vind het daarom zelf juist belangrijk om wayland te gaan gebruiken zodat de community ervoor kan zorgen dat alle problemen met Wayland gladgestreken worden.

[Reactie gewijzigd door Archcry op 22 april 2022 07:57]

Zeker waar en sway is op Wayland mijn mail. Dat get uiteindelijk wel wat word ga ik vanuit alleen ol dit moment zijn er nog aardig wat hordes te gaan.

Ik heb het geprobeerd op 21.10 maar ik had diverse crashes en bugs in libmutter waardoor ik toch weer van Wayland af ging.

Op mijn laptop (met Intel + Nvidia Quadro GPU) draai ik Manjaro met veel recentere versies van Gnome en Linux en daar kan ik kiezen tussen gebruik van mijn HDMI poort en Wayland. Ik zit daar normaal op X11, maar als ik van plan ben het ding aan mijn TV of een scherm te hangen dan log ik alvast preventief uit en schakel ik naar X11. De crash van mijn desktop environment na het inpluggen van een scherm heeft me al eerder werk doen verliezen, dat doe ik niet nog eens.

Wayland werkt prima en is in mijn ogen beter ontworpen voor moderne use cases, maar als je de fout maakt Nvidia te kopen, zou ik nog even een paar maanden wachten zodat de Ubuntu-mensen wijdverspreid de bugs eruit kunnen werken.

Hangt af van je drivers 495+ werkt opzicht goed mits je via gdm pakt.

Probeer het nu eens met Optimus. Spoilers: het zuigt.

Volgens mij gaat Ubuntu 22.04 ook met nVidia hardware naar Wayland. Tenminste, als je bv. de nieuwspagina's mag geloven:

https://www.phoronix.com/...-22.04-NV-Wayland-Default
https://www.reddit.com/r/..._default_to_wayland_with/

T is op t laatste moment gecancelled qua Nvidia en Wayland ivm bugs .

Ik had 21.10 met Nvidia op Wayland. Geen issues. Helaas kon ik in meets niet meer mijn hele scherm delen, en ook alleen chromium tabs. Dat was voor mij niet werkbaar en daarom heb ik Wayland uitgezet.

Ik mis er niets aan. Ik begrijp dat het efficiënter en sneller zou moeten zijn, maar ik heb er geen last van dat X11 langzamer is. Heb ik verder een voordeel gemist?

[Reactie gewijzigd door casberrypi op 22 april 2022 13:30]

Dat het niet botert tussen Wayland en nvidia is ook aan de commerciële instelling van nvidia. Met de opensource nvidia drivers wordt lang niet te hele grafische hardware ontsloten. En de commerciële drivers van nivdia komen er bij veel open source gerichte distributies niet in.

Linus is heel goed bekend met nvidia. Het is dat nivdia de technische documentatie voor het schrijven van drivers niet wil vrijgeven. Het is de keuze van nivida om zelf drivers te willen leveren maar zich niet aan de linux manier van werken te conformeren.

EINDELIJK Wayland... Als Ubuntu dit eerder had gedaan had driversupport misschien niet zo'n jarenlang drama geweest..

Het werkt juist de andere kant op. Driver support moet er eerst komen vanuit de hardware fabrikanten, en deze spenderen hier nagenoeg 0 tijd aan (uitzonderingen daargelaten) waardoor al het werk door de community gedaan moet worden.

AMD is hier een goed voorbeeld van. "AMD drivers werken tegenwoordig zo goed onder Linux". Maar volgens mij zijn de meeste commits in Mesa en dergelijken van de open-source community en niet AMD zelf... alhoewel ik ze moet nageven dat ze wel specificaties van hun hardware vrijgeven de afgelopen jaren.

Wie dan ook de drivers maakt, niet zo lang geleden grapte ik nog dat AMD alleen door principiële puristen werd gekocht, en Nvidia door mensen die daadwerkelijk hun PC wilden gebruiken. Tegenwoordig heb ik zelf een AMD. En de desktopervaring is gewoon beter. Vensters waren plakkerig op Nvidia. Nu perfect vloeiend. Dat wil best lekker werken. Terwijl ik voorheen juist Nvidia koos omdat AMD destijds zo dramatisch slecht was. Dat is nu toch wel anders.

Als ik zo rond Google, is Wayland al zeker sinds 21.04 de standaard. Alleen op Nvidia systemen was het nog Xorg, omdat Wayland op Nvidia gewoon niet een ding was. Ik hoop wel dat veel distro's zullen volgen.

Wayland is al langer de default op Ubuntu. Tenminste sinds 2021. Ik hoop wel dat meer distro's dat gaan doen, want hoe meer mensen get gebruiken, hoe beter de ervaring wordt, hoe meer het gebruikt wordt, etc. Wayland is gewoon overduidelijk beter. Maar het mist ook nog belangrijke dingen. De keuze in window managers is bijvoorbeeld enorm beperkt. Het is vooral Gnome, KDE, en Sway.

Er zijn er meer maar dat zijn naast enlightenment wel de grootste inderdaad

Enlightenment is op Wayland nog erg experimenteel, begreep ik.

E is üperhaupt een eeuwiglopend experiment. Wel absoluut prachtwerk, maar ja, experimenteel prachtwerk.

KDE is ook nog niet helemaal klaar voor Wayland geloof ik. Ik zie bij elke release nog dingen als "Functie X werkt nu onder wayland!" staan Maar het is inderdaad wel bruikbaar, heb ik begrepen.

Ik draai zelf nog onder X omdat KDE-Wayland op FreeBSD momenteel stuk is, en het heeft niet veel prioriteit bij de maintainers (en bij mijzelf ook niet overigens, daar niet van).

Wat wel fijn is op FreeBSD is dat je qua packages altijd rolling bent (of quarterly, als je daar voor kiest), terwijl je OS wel stabiel is. Ik vind dat een super combinatie.

[Reactie gewijzigd door GekkePrutser op 21 april 2022 21:21]

Ubuntu niet-TLS is elk half jaar. Dat is voor mij frequent genoeg. Rolling is wat mij betreft leuk voor specifieke applicaties, maar niet voor je hele machine voor dagelijks gebruik.

FreeBSD heb ik nog niet gedurfd.

Maar dat is dus precies wat FreeBSD doet. Het OS is stabiel (afhankelijk overigens van welke versie je installeert, je hebt zeg maar een "LTS" versie en een "rolling" development versie, een beetje zoals met Debian).

Maar de user applicaties die niet bij het OS horen zijn wel rolling. Zo heb je de nieuwste apps maar wel een stabiel OS.

Als er bijvoorbeeld een nieuwe KDE versie is, dan heb ik die meestal de volgende dag al Bij FreeBSD wordt dat niet bij 'het OS' gerekend, dat is alleen alles dat ze zelf onderhouden. Dus echt het OS zelf. Bij Linux ligt dat wat anders omdat je daar de centrale kernel hebt en dan de distro's die er een OS omheen bouwen.

Ik ben erg tevreden met FreeBSD maar ik heb wel gehoord dat er wat problemen zijn met moderne WiFi chipset ondersteuning. Ik gebruik zelf weinig WiFi omdat ik eigenlijk alleen met desktop computers werk, NUCs met name. WiFi is voor mij alleen voor mobiele apparaten.

[Reactie gewijzigd door GekkePrutser op 22 april 2022 15:13]

Het is jammer dat dit artikel niet klopt. Ubuntu 2204 wordt op dit moment nog verspreid naar alle mirrors (op dit moment zit dat op zo'n 25%). Pas als de meeste mirrors de nieuwe iso's hebben is het officieel gereleased. Van wat ik begrijp zijn nu juist vanwege alle announcements een aantal mirrors lichtelijk druk, waardoor het verspreiden juist nog langer duurt.

Soon

Edit: anderhalf uur na deze comment was de release wel officieel uitgebracht:
[19:14:06] * ChanServ has changed topic for #ubuntu-release-party to: "Welcome to the party! Ubuntu 22.04 LTS (Jammy Jellyfish) is the 36th release of Ubuntu and it's OUT!"

[Reactie gewijzigd door Freeaqingme op 21 april 2022 21:50]

In plaats van de direct de iso downloaden zou men de torrent daarvan kunnen pakken. Het is een extra stap, maar downloaden gaat snel(ler) en je bespaart de maintainers en mirrors bandbreedte, zeker als je de torrent daarna ook nog blijft seeden.

Ik zie alleen nog geen torrent voor 22.04!

edit:
wel via https://releases.ubuntu.com/jammy/

[Reactie gewijzigd door Mattie112 op 21 april 2022 19:16]

Heeft deze nieuwe Ubuntu release i.c.m. GNOME 42 ondertussen ondersteuning voor het configureren van een WireGuard VPN verbinding via de GUI?
De ondersteuning hiervoor zit al een tijdje in de onderliggende NetworkManager component zelf dacht ik maar de GUI integratie in GNOME was tot nu toe nog niet rond, wat jammer is. Momenteel gebruiken we nog de OpenVPN VPN plugin, die uitstekend geïntegreerd is, maar WireGuard zou handig zijn als alternatief.

Eindelijk lost gnome, alle vragen op.

Als ik het allemaal zo lees dan wacht ik nog even met het overhoop halen van m’n 18.04 servertje