Door Krijn Soeteman

Freelanceredacteur

Ubuntu 16.04 Xenial Xerus Review

Meer dan een bugfix-release

21-04-2016 • 06:00

102

Multipage-opmaak

Inleiding

De tweejaarlijkse uitgave van een long term support-versie van Ubuntu is een belangrijk moment in het uitgaveschema van Canonical. Ubuntu 16.04, met codenaam 'Xenial Xerus', is de zesde lts-versie van Ubuntu. Een lts-versie moet stabieler zijn dan een 'gewone' versie uit het halfjaarlijkse uitgaveschema en wordt vijf jaar ondersteund voor de desktop- en serverversie. Standaard levert Ubuntu beveiligingsupdates voor de aangeboden software uit de repositories, al zijn er enkele uitzonderingen, zoals Firefox en Chromium. Deze laatste twee applicaties worden vrijwel direct volgens hun eigen releaseschema geüpdatet vanuit Ubuntu's softwarebronnen. Voor hen die extra zekerheid willen voor de uitgave is het verstandig te wachten op de eerste point-release, ofwel 16.04.1.

Ubuntu Xenial Xerus 16.04

Deze uitgave is beduidend spannender dan de versies die Canonical in de afgelopen jaren introduceerde, al is niet alles direct zichtbaar. Zo is ZFS toegevoegd zonder dat daar bijvoorbeeld Fuse voor nodig is, al blijft die keus tot nog toe controversieel. Ook wordt het met snap mogelijk om op een makkelijkere manier aan nieuwere versies van bepaalde software te komen zonder dat het 'eeuwige' gedoe met afhankelijkheden of dependencies blijft doorzeuren.

Dat is vooral de onzichtbare binnenkant. De buitenkant blijft zoals hij is en ziet er zo langzamerhand wat outdated uit. Unity 8 en Mir zijn opnieuw doorgeschoven naar een volgende versie, waardoor de displaymanager blijft steken op Unity-versienummer 7.4. Uiteraard is Unity 8 met Mir voor de geïnteresseerden apart te installeren. Onze ervaring tot nu toe met Unity 8 en Mir is dat het er steeds beter uitziet, maar er blijft volgens ons behoefte aan meer dan alleen wat finetunen.

Zichtbare veranderingen

Hoewel er nauwelijks sprake is van zichtbare veranderingen, zijn er wel degelijk aanpassingen gedaan die het vermelden waard zijn.

Gnome Software

Ubuntu Software CenterHet Ubuntu Software Center is niet meer. Het werd voor het eerst bij Ubuntu 9.10 of Karmic Koala meegeleverd, maar zelfs op zeer moderne systemen met ssd's duurde het lang om het softwarecentrum te starten. In november 2015 kondigde Canonical aan dat het tijd was voor het integreren van Gnome Software, waarvan de eerste uitgave in september 2013 het licht zag, al duurde het nog tot 23 maart 2016 voor de eerste stabiele release. Software, dat intern gewoon Ubuntu Software Center blijft heten, ondersteunt ook fwupd, een daemon voor het onderhouden van firmware-updates onder Linux, maar daarover later meer.

Het besluit om te wisselen van softwarecentrum werd genomen tijdens een Ubuntu-desktopsprint in Londen eind vorig jaar. Ontwikkelaars van Canonical werken aan de Ubuntu Store op Ubuntu Phone. In Unity 8 moet de Store ook op de desktop gaan fungeren. In de tussentijd wordt Gnome Software gebruikt. Canonical zal plug-ins maken om het nieuwe systeem installatiebestanden in de vorm van snaps te laten begrijpen. Wat er na het uitkomen van Unity 8 precies met Ubuntu Store en Software Center gebeurt, is nog niet duidelijk. Een van de functies die bijvoorbeeld nog niet in Software Center zitten, is de mogelijkheid tot betalen.

Gnome Software in Ubuntu Gnome Software in Ubuntu 16.04

Gnome Calendar

Niet alleen Gnomes softwarecentrum heeft zijn plaats gevonden in Xenial, maar ook Gnome Calendar 3.20. Calendar integreert met de Online Accounts uit het systeemmenu van Ubuntu. Het laat dezelfde agenda-afspraken zien als rechtsboven in de balk worden getoond via het pull-downmenu dat te zien is als er op de klok geklikt wordt. Helaas is Calendar niet te openen vanuit een agendalink in datzelfde menu, maar wellicht wordt dat nog toegevoegd.

De agenda heeft twee opties: een maand- of een jaaroverzicht. Het toevoegen van een afspraak wijst zichzelf, al is het voor mensen die veel verschillende agenda's hebben wellicht handig om enkele oude, ongebruikte agenda's uit te zetten, aangezien Calendar ook alle, op onzichtbaar gezette agenda's zichtbaar maakt. Synchronisatie werkt op dit moment zonder extra moeite met Google Calendar en Yahoo Calendar door in de systeeminstellingen de koppeling bij Online Accounts aan te zetten.

Net als Gnome Software heeft Calendar het voordeel dat het ook door veel andere distributies gebruikt wordt en daardoor goed wordt onderhouden. Het is ook de standaardagenda-applicatie op Fedora Workstation, openSUSE Leap en uiteraard Ubuntu Gnome.

Unity Launcher

Het kost wat moeite, maar de Unity Launcher, of Starter in het Nederlands, is naar beneden te verplaatsen. De opties zijn nog wat beperkt: links of beneden, maar het kan via het commando:

gsettings set com.canonical.Unity.Launcher launcher-position Bottom

of left om weer links te zetten of via dconf-editor.

Ubuntu launcher unity beneden

Notificaties voor software-updates

Het notificatiesysteem dat werd geïntroduceerd met Unity zal nu ook aangeven dat er softwareupdates zijn. Dit houdt in dat als er standaardinstellingen worden gebruikt, er rechtsboven een pop-up verschijnt. Of dit betekent dat de pop-up in de Unity-starter nu verleden tijd is, is nog niet duidelijk op het moment van schrijven.

Apt-get

Gebruikers van de terminal voor het installeren van applicaties zullen merken dat 'apt-get install' niet langer per se nodig is. Alleen 'apt install' werkt ook. Het meest zichtbare verschil is dat er een voortgangsbalk te zien is. Apt is 'simpeler' dan apt-get en apt-cache.

Verwijderde software

Met het klimmen van de jaren zijn er ook steeds meer apps die niet of vrijwel niet meer onderhouden worden, zoals Brasero en Empathy. Brasero, de aloude toepassing om cd's en dvd's te branden, wordt niet meer standaard geïnstalleerd. Ook chatprogramma Empathy moet het veld ruimen. Beiden zijn nog terug te vinden in het Softwarecentrum en desgewenst te installeren.

Ultra-hd-monitoren en schalen

Onlangs schreef Tweakers een achtergrond over het nut van 4k-monitoren. Daarbij kwam ook het schalen aan bod. Schalen in Windows 10 werkt meestal goed, maar niet altijd, was de conclusie van dat artikel. Datzelfde geldt voor Ubuntu, maar in vergelijking met 15.10 lijkt Xenial het schalen een stuk beter onder de knie te hebben. Bij 15.10 resulteerde opschalen op een 28"-monitor tot rare reacties van bijvoorbeeld de muiscursor. Alles wat onder de windowmanager viel, in dit geval Unity, schaalde oké, maar binnen applicaties wilde dat nog weleens verschillen. De muiscursor sprong dan van een normaal, of eigenlijk twee keer zo groot, formaat naar een heel klein, bijna onzichtbaar pijltje. Dat probleem lijkt nu opgelost, in ieder geval met de opstelling die wij gebruiken: een Nvidia Quadro 2000 met een Intel Xeon E5 en een IIyama 28"-monitor.

Om de juiste schaling te krijgen moet dat wel eerst ingesteld worden in het instellingenmenu. Op een 'normale' 28"-monitor is een instelling van 2 aan te raden. Op een 40"-tv is schalen praktisch niet nodig en zijn alle iconen op 1 al van het juiste formaat.

Wat dat betreft lijkt een 28"-monitor een veilige optie voor Ubuntu. Toch bleek Dells 28"-monitor P2715Q niet gedetecteerd te worden op ons moderne systeem, terwijl Asus' 28"-monitor ProLite PL2888UH wel werd gedetecteerd. Een oudere laptop, die niet in staat bleek 4k te serveren, zag beide monitoren dan weer wel via de hdmi-poort. Voor het workstation gebruikten we displayport. Het niet detecteren kan liggen aan de gebruikte displayport-chipset van de monitoren, maar als het goed is, hebben beide monitoren dezelfde chipset. Hoe het ook zij: voorzichtigheid is geboden bij het aanschaffen van een 4k-monitor.

Screenshots Ubuntu 16.04 op uhd-monitorScreenshots Ubuntu 16.04 op uhd-monitorScreenshots Ubuntu 16.04 op uhd-monitorScreenshots Ubuntu 16.04 op uhd-monitor

1. Beeld zonder schalen 2. Beeld met schalen (2x) 3. Verhouding niet goed schalende applicatie uhd-monitor 4. Verhouding met Unity-launcher op hd-monitor

Opvallende veranderingen onder de motorkap

Van de buitenkant gaan we naar de binnenkant. Onder de motorkap zijn wat zaken toegevoegd die op z'n minst opvallend te noemen zijn, waaronder de ondersteuning voor ZFS vanuit de main-repositories en snap, een relatief nieuw verpakkingsformaat voor apps en afhankelijkheden. Ook is het nu mogelijk om firmware te updaten vanuit het besturingssysteem zelf via fwupd en de Linux Vendor Firmware Service.

Kernel 4.4

Niet alleen de release zelf is een long-term-supportversie, maar ook de Linux-kernel met versie 4.4. Daarmee zijn wel veel verbeteringen toegevoegd aan de opensource-AMD-drivers. Helaas is er nog geen PowerPlay-ondersteuning voor AMD-kaarten in meegenomen. Dat komt pas in kernel-versie 4.5. Ook belooft 4.4 extra stabiliteit voor bezitters van Nvidia-kaarten met de nouveau-drivers. Ondanks alles verdient het bij upgraden de aanbeveling om per definitie de opensourcedrivers aan te zetten in de extra stuurprogramma's.

Snaps naast debs

Geen afhankelijkheden meer, gewoon een werkende applicatie. Dat is het idee van snappy packages. Gebruikers van Snappy Ubuntu Core, ofwel Ubuntu voor iot-apparaten, zijn al langer bekend met snaps en het ontwikkelen van apps met Snapcraft. Snappy werd in eerste instantie ontwikkeld om een provider-grade updatemechanisme te hebben voor Ubuntu's mobiele- en iot-systemen.

Het besturingssysteem en de applicaties worden met snappy compleet gescheiden gehouden als een verzameling read-only-images. Doordat de files read-only zijn, kan er niet naderhand mee gerotzooid worden. Voor updates gebruikt snappy delta updates, ofwel alleen de gewijzigde code hoeft gedownload te worden, wat weer bestandsgrootte scheelt. Een ander voordeel is dat als een ontwikkelaar een update uitrolt, de update ook direct bij iedereen binnenkomt, zonder afhankelijk te zijn van updatecycli. Bij fouten in een update moet de update ook makkelijk terug te draaien zijn.

Nu heeft Canonical de installatiemethode doorgevoerd in de desktop- en serverversie van Xenial. Snap-packages kunnen gewoon naast traditionele deb-packages geïnstalleerd worden, zelfs identieke apps kunnen naast elkaar bestaan.

snap snappy ubuntu snapcraft

Wat is het grote verschil tussen een deb-package en een snap? Afhankelijkheden of dependencies. Velen die wel eens een deb- of rpm-pakket hebben geïnstalleerd, hebben meegemaakt dat een afhankelijkheid niet meer in de softwarebronnen staat. Vaak gaat het dan om een softwarebibliotheek die verouderd is, zoals een lib-bestand. Over het algemeen is het benodigde bestand wel ergens te vinden, maar het kan hoofdbrekens opleveren.

Dat moet met snaps over zijn. Ze lijken in essentie erg op containers als Docker en LXD, maar dan kleiner. Een ontwikkelaar kan aan een snap-package zowel de applicatie-binary als de afhankelijkheden toevoegen die nodig zijn om de app te draaien. Het maakt niet uit of de libraries al op het host-systeem staan of niet. Het betekent ook dat gebruikers veel makkelijker nieuwe applicaties kunnen gebruiken op oudere versies van Ubuntu zonder toeren uit te halen die soms tot vervelende complicaties leiden.

Het klinkt allemaal goed doordacht, alleen is er op het moment van schrijven nog geen enkele app officieel voor de desktop uitgebracht. Er is een test-snap-rekenmachine-app, maar de versie die wij konden vinden, kon nog niet via Software Center worden geïnstalleerd. Via Snapcraft moet het mogelijk zijn om bestaande debs in snaps om te zetten.

Fwupd

De updateservice voor firmware is niet veel meer dan een simpele daemon die het mogelijk maakt dat software tijdens een sessie firmware updatet op een lokale machine, iets wat sinds eufi mogelijk is vanuit Windows. Het project kwam in september 2015 in de 3.18-versie van Gnome terecht als gevolg van een samenwerking tussen ontwikkelaars van het Gnome-project en Dell. Nu is het meegenomen door Canonical in Ubuntu. In theorie is het een interessante toevoeging, alleen moeten zowel hardwareboeren als de community ermee aan de slag.

Fwupd is wat dat betreft nog in ontwikkeling en leunt op de Linux Vendor Firmware Service. De service is een online bron voor hardwarebouwers om hun nieuwste firmware te uploaden. Op het moment van schrijven is de lijst van de LVFS nog vrijwel leeg. Er staan vier Dell-systemen in en drie opensource-colorimeters van Hugski. Niet toevallig is Richard Hughes een van de drijvende krachten achter het systeem. Hij onderhoudt onder andere Gnome Software, Power Manager, Color Manager en colord, en ondersteunt nog vele andere projecten.

Hopelijk kan de toevoeging aan Ubuntu het aantal ondersteunde systemen dat via uefi updates kan uitvoeren, snel vergroten. Tot dan klinkt het vooral als een mooie belofte dat het niet meer nodig is om via Windows of DOS een bios-update of iets dergelijks uit te voeren. Dat ook randapparatuur direct in de implementatie wordt meegenomen, lijkt vooralsnog niet het geval.

AMD grafische drivers

AMD's propriëtaire Catalyst of fglrx-driver wordt niet meer ondersteund. Dat hoeft voor de meesten niet direct een probleem te zijn, maar gebruikers van specifieke functies, zoals OpenCL en een AMD-kaart, moeten misschien wel even oppassen alvorens te upgraden. Omdat veel verbeteringen voor AMD-kaarten in de 4.5-kernel zijn terechtgekomen, zegt Ubuntu veel daarvan teruggeport te hebben naar de 4.4-variant.

De propriëtaire drivers van AMD komen niet terug in hun huidige vorm. Er is al wel een hybride driver in de maak met zowel open- als closedsourcecomponenten, amdgpu-pro, waarin Vulkan, OpenGL en OpenCL werken. Het aantal ondersteunde kaarten is wel klein.

ZFS: is GPLv2 incompatibel met CDDL?

Eveneens onder motorkap, maar de beslissing om OpenZFS als bestandssysteem mee te nemen in Ubuntu 16.04, verdient vanwege de gevolgen een eigen hoofdstuk. Xenial is de eerste uitgave van Ubuntu waarbij Canonical standaard het bestandssysteem OpenZFS meelevert.

ZFS als next-gen-bestandssysteem is vooral goed bruikbaar als er in een systeem verscheidene harde schijven worden gebruikt, omdat het naast bestanden serveren, ook functioneert als lvm en raid-engine. Het is daarom een hybride bestandssysteem en beschikt niet over traditionele partities. Canonical prijst ZFS dan ook aan als het bestandssysteem voor containers, iets waar het al enkele jaren zwaar op inzet binnen de server- en cloudwereld. Andere voordelen zijn het maken van snapshots, het kunnen maken van incrementele back-ups, copy-on-write, continue integriteitschecks, waardoor datacorruptie vrijwel niet kan voorkomen, automatische reparatie van corrupte bestanden en het efficiënt omgaan met datacompressie.

Canonical heeft ervoor gezorgd dat ZFS in de kernel zelf als module zit en niet via dkms gecompileerd hoeft te worden. De package ZFSutils-linux is inbegrepen in de Ubuntu Main-repository en installatie is snel gedaan door middel van enkele simpele commando's. Er is één addertje onder het gras; Canonical zegt dat zijn juristen hebben uitgezocht dat ZFS compatibel is met GPLv2. De consensus is echter jarenlang geweest dat ZFS, dat onder CDDL valt, niet compatibel is met GPLv2, waar de linux-kernel onder valt.

Om de juridische strijd en alle achterliggende pro's en cons hier te gaan behandelen, is te veel van het goede. ZFS was al op een andere manier bruikbaar binnen GNU/Linux-distributies via de fuse-api, maar kon niet zomaar meegeleverd worden vanwege de vermeende licentieverschillen. Het ZFS-bestandssysteem valt onder CDDL, een softwarelicentie ontwikkeld door Sun Microsystems. CDDL is niet compatibel met GPLv2, maar ze bijten elkaar niet. Dat leidt tot veel frustratie, te meer omdat Oracle, de huidige eigenaar van Suns intellectuele eigendom, de licentie van ZFS niet wil wijzigen in een licentie die wel compatibel is met GPLv2.

openzfs logoNu heeft Canonical gesteld dat beide licenties 'copyleft'-licenties zijn, met het verschil dat bij CDDL alle bestanden onder die licentie vallen en GPLv2 alleen overgaat op afgeleide werken. Canonical is van mening dat CDDL bij het gebruik van ZFS niet ineens van toepassing is op de Linux-kernel. Canonical stelt dat zfs.ko een bestandssysteemmodule is die op zichzelf staat en dat de kernel daarom 'duidelijk geen afgeleid werk is' van het nieuwe bestandssysteem. Het is volgens Canonical een afgeleide van OpenZFS en OpenSolaris, en behoort daarom tot de uitzonderingen waartoe meer opzichzelfstaande non-GPL-kernelmodules behoren. Daarom concludeert Canonical dat ZFS 'goed is voor Ubuntu-gebruikers, voor Linux en voor alle vrije en opensourcesoftware'.

De discussie zal zeker op juridisch vlak nog verder gevoerd worden, getuige de vele artikelen die er in de afgelopen tijd over zijn verschenen.

ZFS vs. Btrfs

Waarom doet Canonical zoveel moeite om OpenZFS als kernelmodule mee te leveren terwijl Btrfs een prima alternatief lijkt? Het antwoord daarop is simpel; ZFS is af en volledig rijp voor productieomgevingen. Het is een volwassen volgendegeneratie-bestandssysteem en dat is Btrfs nog niet. Er zijn wel enkele verschillen, waardoor beide bepaalde voordelen zouden kunnen bieden op bepaalde plekken. Btrfs is bijvoorbeeld compatibel met ext4, waardoor het makkelijk is een Btrfs-implementatie uit een bestaande ext4-Linux-implementatie te vormen. Het lijkt er ook op dat Canonical expres de knuppel in het hoenderhok gooit, misschien om Oracle te dwingen de licentie aan te passen of de discussie in ieder geval weer open te breken. Saillant detail is dat Btrfs ook mede van Oracle is.

Voor de gewone, enkele eindgebruiker lijkt de hele discussie niet zo belangrijk. Thuis een nasje in elkaar klussen zal waarschijnlijk niet leiden tot een juridische strijd, maar je bent gewaarschuwd.

Ubuntu met Unity-desktop

xenial xerusHoewel de Unity-interface een oude bekende is voor de doorgewinterde Ubuntu-gebruiker, lopen we even langs enkele kleine wijzigingen, handige gebruiksinstellingen en enkele standaardprogramma's. Iedereen zal daarin zo zijn voorkeur hebben en mensen die Unity echt te achterhaald vinden, kunnen probleemloos een andere desktopomgeving gebruiken binnen de *buntu-familie.

Systeeminstellingen

De belangrijkste wijziging in het systeeminstellingenmenu ten opzichte van voorgaande versies zit bij de beveiliging, namelijk dat Internetzoekresultaten via Dash, of in het Nederlands 'Snelzoeker', standaard uitstaan. Dit was tijdens de introductie in 12.04 een heikel punt. Het werd door sommigen zelfs gezien als spyware toen het standaard aanstond. Nu lijkt Canonical naar de community geluisterd te hebben.

Standaard worden menu's voor de applicatie die in gebruik is, weergegeven in de menubalk bovenin. Dit gedrag is te wijzigen naar menu's in de menubalk van het venster bij Gedrag onder Uiterlijk. Canonical stelde de wijze van menu's weergeven juist zo in, omdat het de verticale ruimte ten goede kwam, wat vooral praktisch is op breedbeeldmonitoren.

Verder is er niets veranderd aan de standaardinstellingenmenu's. Toch blijft het voor nieuwe gebruikers handig om eens door de instellingen heen te gaan, al was het maar om de standaardtoepassingen in te stellen onder Details of om een tekentablet beter te configureren bij 'Wacom-tablet'. Ook kan er bij Geluid voor gekozen worden om het maximale volume hoger te zetten dan honderd procent. De maat van de iconen uit de Unity Launcher kan er ook aangepast worden. Dit gebeurt onder Uiterlijk tot minimaal zestien pixels breed.

Bij het langer ingedrukt houden van de 'super'-, of in veel gevallen Windows-toets, verschijnt een overzicht van alle sneltoetsen, zoals super+w om alle in gebruik zijnde vensters te zien of hoe door verschillende instanties van hetzelfde programma te browsen via linker-alt-tilde. Ook kan de supertoets gebruikt worden om via Dash snel in de menu's van het geselecteerde programma te zoeken. De sneltoetsen zijn naar eigen smaak aan te passen via Toetsenbord en Sneltoetsen.

Om dieper in de instellingen te duiken via een gui moet gconf-editor geïnstalleerd worden, maar dit vereist iets meer kennis van zaken. Ook is het aloude Compiz Config-instellingenbeheer nog te installeren via de terminal. Onder de gui van deze laatste configuratietool bevinden zich veel opties die allemaal tot problemen kunnen leiden, maar het kan leuk zijn er eens mee te spelen. Onder Bureaublad en vervolgens Ubuntu Unity Plugin zijn heel wat opties te vinden.

Standaardprogrammatuur

Als altijd komt Ubuntu met een keur aan applicaties voor dagelijks gebruik. Mocht bepaalde programmatuur niet al voorgeïnstalleerd zijn, dan is vrijwel alles wat nodig is uit het Ubuntu Software Center te halen. Het nieuwe softwarecentrum van Gnome werkt snel en soepel, heel wat anders dan het oude. Toch vertoont het softwarecentrum op het moment van schrijven nog wat eigenaardigheden, zoals het niet altijd tonen van de 'verwijder'-knop, en is de informatie over de programmatuur nog erg karig. Wel is al zichtbaar wat de mening van anderen is over de software, waarbij de beoordelingen van het oude Software Center zijn opgenomen. Aankopen kunnen nog niet via het centrum gedaan worden, iets wat wel kon in het oude.

De verschillende smaken

Als vanouds bestaat de *buntu-familie uit veel verschillende smaken. Sommigen worden rechtstreeks door Canonical ondersteund en anderen gaan hun eigen weg op basis van Ubuntu, zoals Linux Mint. Omdat het aantal afgeleiden groot is, houden we het op de officieel ondersteunde smaken. Een aantal behandelen we hier kort.

Kubuntu

Kubuntu 16.04 BetaDe eerste uitgave van Kubuntu zag zes maanden na de eerste Ubuntu-uitgave 4.10 Warty Warthog het levenslicht en is daarmee de oudste officiële afgeleide. Kubuntu is gebaseerd op de KDE-desktop. Het was tot eind maart nog onduidelijk of het Kubuntu-project wel zou meedoen met de releasecycle van Ubuntu 16.04. De nieuwste versie maakt gebruik van KDE Plasma 5.5.4 samen met de KDE Applications 15.12.1-softwaresuite en de KDE Framework 5-pakketten. Verder bevat Kubuntu LibreOffice 5.1 en Firefox 45.0. Kubuntu is in zowel een 32- als een 64bit-uitgave beschikbaar.

Xubuntu

Xubuntu 16.04 Xenial XerusDe derde variant op Ubuntu was Xubuntu in 2006 met de uitgave van Ubuntu 6.06 Dapper Drake. De tweede variant die uitkwam, de op educatie gerichte Edubuntu, slaan we hier over, omdat Edubuntu vooral bestaat uit enkele voorgeïnstalleerde pakketten op de standaard-Ubuntu-uitgave met wat extra instelmogelijkheden. Xubuntu gebruikt als desktop Xfce en vereist minder zware hardware dan Ubuntu zelf. De minimale systeemeisen voor de grafische omgeving zijn 512MB intern geheugen en een processor die physical address extension ondersteunt, ofwel processors vanaf Pentium Pro, geïntroduceerd in 1995. Toch adviseert het team minimaal 1GB intern geheugen om applicaties goed naast elkaar te kunnen draaien en een schijfruimte van 20GB.

Lubuntu

Een andere bekende variant die gebruikmaakt van een lichte desktopomgeving is Lubuntu, gebaseerd op de LXDE-omgeving. Lubuntu 16.04 is een mijlpaal, aangezien het de eerste lts-versie wordt. Het lukte de community achter Lubuntu niet om bij de vorige lts-versie aan de minimale eisen van Canonical te voldoen om het label te mogen dragen. Lubuntu blijft gebruikmaken van LXDE en gaat nog niet over naar LXQt, de nieuwe in Qt geschreven desktop die het werk van LXDE en Razor-qt mixt. Omdat 16.04 een lts-uitgave is, is stabiliteit belangrijk en LXQt is volgens het team nog te veel in ontwikkeling, maar voor de nieuwsgierigen is het uiteraard mogelijk om het te installeren. De minimale eisen zijn 256MB ram, maar het advies is om minimaal 512MB te gebruiken, samen met een 512MHz-processor en een harde schijf van 6GB, al kan het systeem ook met een tragere pae-processor toe.

Ubuntu Gnome

Als antwoord op de komst van de Unity-interface werd in 2012 Ubuntu Gnome geïntroduceerd. De uitgave bevat niet veel wijzigingen ten opzichte van de laatste versie. De hoop was dat Gnome 3.20 gebruikt zou worden, maar vooralsnog is het Gnome 3.18 met Gnome Shell 3.18, hoewel Gnome 3.20 op 23 maart werd uitgegeven. Met de invoering van Gnome Software Center in Ubuntu zit het eigen softwarecentrum nu ook in Ubuntu Gnome, evenals Gnome Calendar. Interessant is dat ook Wayland wordt meegeleverd met Ubuntu Gnome, al moet daarvoor wel de gnome-session-wayland-package geïnstalleerd worden. Daarna is 'Gnome on Wayland' in het loginscherm te selecteren. Wayland werkt alleen met opensource- grafische drivers.

Ubuntu Mate

Ubuntu Mate MutinyLiefhebbers van de Gnome 2-desktopomgeving kunnen bij Mate terecht. In de 16.04-versie is onder andere Synapse 0.2.99 te vinden, een semantische bestandsstarter en een vervanging van Gnome Do. Een nieuwe versie van Mate Tweak is meegeleverd en de integratie met Compiz is onder handen genomen. In de vorige versie gebruikte Mate nog Grid als softwarecentrum. Dat is nu vervangen door Gnome Software.

Via Mate Tweak is het thema Mutiny te activeren en dat lijkt verdacht veel op Unity. Wel ontbreken bepaalde zaken, zoals de Dash en de hud. De minimale systeemeisen van Mate zijn met een Pentium III op 750MHz laag, maar het advies is liever een Core 2 Duo op 1,6GHz of equivalent te gebruiken, met 2GB ram en 16GB opslaggeheugen. Daarnaast is Mate beschikbaar voor PowerPC en ARMv7 op de Raspberry Pi 2.

En de rest

De smaken die we hier nog even noemen zijn Edubuntu, Mythbuntu, Ubuntu Studio en Ubuntu Kylin. Edubuntu heeft als voordeel dat bepaalde kioskmodi al zijn voorgeïnstalleerd en dat het voor kinderen geschikte spelletjes en educatieve software bevat, al is de Nederlandse taalondersteuning niet altijd even goed. Mythbuntu is eigenlijk meer een add-on met de focus op het opzetten van een standalone-MythTV-systeem en werkt ook binnen een bestaand MythTV-netwerk. Ubuntu Studio is een normale Ubuntu-installatie met extra veel praktische applicaties voor audio-, video- en beeldbewerking. Ubuntu Kylin ten slotte is een versie van Ubuntu die op Chinese gebruikers is gericht, met een volledig Chinese out-of-the-box-ervaring.

Conclusie

Voor de doorgewinterde Ubuntu-gebruiker verandert er eigenlijk niets. Misschien wat saai, maar wat ons betreft maar goed ook. Unity 8 komt in de verste verte nog niet over als 'af', getuige de verschillende filmpjes op YouTube en de eigen ervaring via convergence. Hierbij is overigens niet gelet op snelheid, aangezien de gebruikte Nexus 4 om convergence te testen toch echt hardware uit 2012 bevat, waar het overigens erg netjes op draait.

Het uiterlijk van 16.04 doet zo langzamerhand gedateerd aan. Wat dat betreft is het duidelijk dat Canonical al enkele jaren zijn menskracht inzet op de vele andere projecten waarmee het bedrijf bezig is, zoals Ubuntu Phone, Core, Snappy, LXD, Server en wat al niet meer.

Voor de hardcore LTS-gebruikers is het verstandig te wachten met upgraden tot de point-release is uitgebracht, ofwel 16.04.1. In die uitgave zal het gros van de bugs geplet zijn en is de kans om voor vervelende verrassingen te staan, een stuk kleiner.

Minder

Er zijn een paar dingen uit het verleden nog steeds niet fatsoenlijk opgelost voor de argeloze eindgebruiker. Iedereen die ooit een upgrade heeft gedraaid, is waarschijnlijk weleens iets geks tegengekomen. Over het algemeen geen grote problemen, maar als je niet beschikt over voldoende zoekkunst op internet en slechts ongeveer weet waar je naar moet zoeken, ben je hopeloos in de aap gelogeerd. Daarom geldt ons inziens nog steeds: een upgrade gaat bijna altijd goed, maar niet goed genoeg.

Als een upgrade op zichzelf wel goed gaat, is nog niet alles altijd koek en ei. Eindgebruikers die argeloos applicaties hebben geïnstalleerd vanuit andere softwarebronnen en er nu nog van uitgaan dat deze keurig worden geüpgraded via de softwarebronnen, komen bedrogen uit. Apps als Spotify, Dropbox, Steam, Opera en vele andere gebruiken hun eigen repositories, waardoor ze niet afhankelijk zijn van het updateschema van Canonical. Deze worden tijdens een upgrade uitgeschakeld om de upgrade niet te verstoren bij eventuele fouten in die repo's. Daarna blijven de repo's uit en er is geen manier waarop een argeloze eindegebruiker wordt gewezen op de noodzaak om ze weer in te schakelen. Na weer inschakelen blijkt meestal dat er updates zijn voor de desbetreffende programma's, terwijl de eindgebruiker een vals gevoel van veiligheid kan hebben gehad 'omdat ie toch wel automatisch alles zelf updatete'.

Dat brengt ons direct bij het nieuwe softwarecentrum. Dat werkt redelijk, maar mist nog veel opties. Zo is het niet mogelijk om systeempakketten te laten zien en werkt de zoekfunctie nog niet naar behoren. Een advies kan zijn om Synaptic te installeren, een zeer krachtig pakket om programmatuur aan de tand te voelen, te installeren en te verwijderen. Zeer krachtig betekent ook: let op, alles kan kapot.

Als je Xenial Xerus nieuw installeert en de komende twee jaar niet wil upgraden naar een nieuwere versie, zit je waarschijnlijk goed en heb je aan Ubuntu 16.04 een stabiel en zeer compleet besturingssysteem, waarop vooral door de inspanningen van Valve steeds meer games goed draaien en dat betreft dan niet alleen meer indie-titels.

Xenial Xerus met de standaard Unity-interface is via de image-server van Ubuntu te downloaden voor zowel 32- als 64-bitsystemen, maar ook voor PowerPC, zoals een Apple Macintosh G3 en verder, PowerPC64, IBM System Z- en LinuxONE-mainframes en verschillende ARM-systemen.

Reacties (102)

102
102
56
7
0
30
Wijzig sortering
Een ander voordeel van Ubuntu 16.04 is dat het standaard met PHP 7.04 en LXD komt.

Lang is er binnen de LTS community discussie geweest of PHP 7 niet te nieuw was. De versie heeft dan ook lange tijd naast PHP 5.6 in de Ubuntu xenial repo gezeten. Kort geleden is de knoop doorgehakt en een week of twee geleden werd PHP 5.6 uit de xenial repo verwijdered en nu is alleen PHP 7 over.

Canonical had al aangegeven dat ze niet meer dan 1 versie willen ondersteunen voor hun LTS versie. Persoonlijk ben ik blij dat de keuze op PHP7 is gevallen.

Een groot voordeel van de PHP 7 serie is dat hier aanzienlijke verbeteringen in zijn gemaakt in performance en ook wat in geheugen verbruik.

Dit heeft grote voordelen voor LTS hosters zoals bij mij op het werk. De PHP 7 hype train zorgt er ook voor dat veel projecten nu al beginnen met het praten over het droppen van support voor de hele PHP5 range. ( of zelfs al gedaan hebben: typo3 v8 ) Hierdoor zou PHP 5.6 in de LTS release het dan ook erg lastig gekregen hebben de komende twee jaar.

Ook is LXD toegevoegd in Ubuntu 16.04
Dit beloofd container virtualisatie mogelijk te gaan maken met typische hypervisor features zoals live migration. Ook zonder shared storage. Ook dit is iets wat we graag in de praktijk willen gaan testen.
Hoewel het natuurlijk goed is dat PHP7 er in zit, snap ik niet zo goed dat PHP5.6 er per sé uitgesloopt moest worden, zeker last minute. Ik draai al een tijdje de Xenial béta en werk (helaas) nog met wat software die nog niet met PHP7 werkt. Ik had dan ook PHP5.6 geínstalleerd. Helaas is dat nu dus opeens ongedaan gemaakt en is alleen PHP7 beschikbaar.

Ik vind het persoonlijk ietwat overhaast, zeker gezien het feit er dal tientallen releases uitgekomen zijn met zowel Python 2.7 en Python 3.x. Zo ook weer Xenial. Waarom dan geen twee versies van PHP? Nu moet ik weer in de weer met PPA's die PHP5.6 wel packagen voor Xenial.

Waarom een beta-versie van Ubuntu op een productiemachine? Ik heb net een nieuwe Skylake-laptop en de hardwareondersteuning in oudere versies is zwaar on de maat. Helaas in 16.04 nog steeds, maar het is wel beter. Met name met betrekking tot de IGP Intel HD Graphics 530 icm Optimus.

[Reactie gewijzigd door MadEgg op 22 juli 2024 15:39]

Ik had stiekem zelf ook een beetje gehoopt dat ze PHP 5.6 er ook in hadden gelaten.
Ook omdat ze elkaar niet in de weg zaten qua packages. Op die manier hadden we dan vrijwel al onze huidige projecten zonder aanpassingen over kunnen zetten naar de huidige LTS versie. En degenen die dat ondersteunden naar PHP7.

Aan de andere kant, De Ubuntu 14.04 release is ook nog gewoon drie jaar beschikbaar met PHP 5.5.9 en security fixes. De afgelopen twee jaar heb ik hier weinig issues mee gehad dus dit blijft nog wel even goed gaan. Dus projecten die wij niet kunnen draaien op PHP7 zullen wij de komende tijd nog gewoon op basis van Ubuntu 14.04 blijven ondersteunen.

Ik ben het daarom opzich wel met Canonical eens dat als er voor een enkele PHP versie gekozen moet worden, het beter is om voor PHP7 te gaan.

[Reactie gewijzigd door MoonWatcher op 22 juli 2024 15:39]

Ik ben het daarom opzich wel met Canonical eens dat als er voor een enkele PHP versie gekozen moet worden, het beter is om voor PHP7 te gaan.
Daar ben ik het wel mee eens, maar waarom moet er voor een enkele PHP-versie gekozen worden? En waarom geldt een dergelijke "regel" dan niet voor Python?

Ik draai geen Ubuntu op de server, dus aan de productie-kant zit het mij niet in de weg, maar op de desktop / laptop wel.

Dat PHP5 niet tot in den treure ondersteund blijft worden kan ik inkomen, maar PHP7 is pas december 2015 uitgekomen, dat is slechts 4 geleden. Ik vind het wel erg vroeg om het dan al als een volledige, volwaardige opvolger van PHP5 te zien, zeker aangezien je te maken hebt met ERG veel andere projecten die PHP gebruiken.
Op zich heeft dat een totaal andere reden, namelijk dat Python 2.7 & Python 3 apps niet compatibel zijn met elkaar.
PHP 5.6 apps en PHP 7.0 zijn normaal in de grootste gevallen wel compatibel met elkaar (met enkele uitzonderingen, bv. het uitschakelen van mysql extension).

Vandaar dus :")
apt-get -> apt
dit gebruik ik al een hele tijd hoor ...
da's niet zo nieuw al het artikel doet uitschijnen...

bovendien zijn er een paar kleine wijzigingen in de syntax bij apt als het gaat om opties..
maar apt kan ook zoeken bv met apt list blah zoek je op naam in de lijst van installables en krijg je dan ook alle hits (enkel namen), bovendien staat erbij of het installed is of niet
je kan ook apt search blah doen, dan zoekt hij ook in de descriptions en geeft hij een lijst weer, ook hier weer zet hij erbij '(installed) als dit het geval is
en mert apt show blah dan geeft hij de volledige sheet weer van de app blah
bv apt show firefox dan laat hij alles zien wat je normaal in synaptic kan opvragen over de firefox applicatie.

ik gebruik apt al zeer lang omdat, zoals in het artikel staat, er inderdaad een voortgangsbalk is die je bij apt-get niet hebt.
Die situatie bij Python loopt anders aardig uit de klauwen. Je ziet steeds meer software die krampachtig hun best doet om compatibel te blijven met zowel Python 2.7 als 3.x. Dit alleen maar omdat hierbij distributies al jaren en jaren nalaten om de knoop door te hakken en het verleden achter zich te laten.

Het is bijzonder eenvoudig om Python 2 code om te zetten in Python 3 code, dus er zijn weinig geldige excuses om Python 2 zo lang in de repositories te houden. Heel wat minder dan om PHP5 nog één LTS-release langer mee te laten gaan in ieder geval.

Python 3 stamt nota bene uit 2008. Dat betekent dat in de LTS-releases 10.04, 12.04, 14.04 en 16.04 zowel Python 2 als Python 3 meegeleverd zijn. Maar voor PHP is het opeens te veel werk? PHP zelf ondersteund PHP5.6 ook nog en daar worden ook gewoon nog patches voor utigebracht t/m 31 Dec 2018. Vooruit, dat is niet de volledige LTS-periode, maar wel voldoende om de komende tijd vooruit te kunnen. Bovendien blijft Debian ongetwijfeld fixes backporten waardoor er nog minder reden is om PHP5.6 te weren uit deze release; het meeste werk wordt al voor ze gedaan.
Ik ga er zelf eerder vanuit dat ze proberen een PHP4-scenario te vermijden.

PHP 4 heeft véél te lang blijven hangen. Als ze PHP 5.6 nu als optie blijven geven, gaan hosters enz. mogelijk weer blijven hangen bij die versie, zoals bij PHP 4 het geval was.
Al is PHP 7.0 nog wel heel erg nieuw. Maar ja, PHP 5.6 nog 5 jaar supporten lijkt mij dan ook wel heel erg lang, dus vanuit dat opzicht begrijp ik de keuze voor PHP 7 compleet.
Tja, zo werkt het sowieso niet. PHP 7.0 wordt ondersteund t/m 3 Dec 2018. Dat betekent dus dat Ubuntu vanaf 3 december 2018 ook zelf de support voor PHP 7.0 op zich zal moeten nemen, ofwel overgaan naar PHP 7.1 of nieuwer. PHP 5.6 wordt nog langer ondersteund dus.

Het zou vanuit dat oogpunt zeer goed te verdedigen zijn om na een point release de ondersteuning voor PHP5.6 te droppen, zo ergens in 2018. Net zoals ze zullen doen met PHP7.0 waarschijnlijk. Het is nu gewoon echt te vroeg om PHP5.6 te laten vallen.

Het zijn in ieder geval dit soort beslissingen dat maakt dat ik Ubuntu zeker niet zal overwegen om op een server te gebruiken.
Tja, ik vind het toch wel een goede move. PHP 7 is enorm popular, mede door de grote prestatie verbeteringen. Porten is niet super moeilijk en veel projecten zijn al over - als gezegd, sommigen droppen zelfs 5.x al! Zit je daar met je trage 5.6... Zolang er backports zijn (en die zijn er) is het niet zo'n issue en het zet druk op vendors om snel naar 7 te porten. Snel in de zin van 3 jaar, want zo lang blijft 14.04 nog ondersteund...
Die situatie bij Python loopt anders aardig uit de klauwen. Je ziet steeds meer software die krampachtig hun best doet om compatibel te blijven met zowel Python 2.7 als 3.x. Dit alleen maar omdat hierbij distributies al jaren en jaren nalaten om de knoop door te hakken en het verleden achter zich te laten.
Ik vrees een beetje dat we zo'n schism ook zullen zien bij Perl5/Perl6 en dat het eerder de regel dan de uitzondering zal worden voor "interpreted" languages.
Alleen komen die uitzonderingen al weer veel te snel naar boven waardoor je zeer vele systemen alsnog moet gaan aanpassen specifiek aan PHP7. Bijkomend hebben vele PHP devs geleerd om terughoudend te zijn bij nieuwe major releases en beslist canonical toch al om relatief snel een nieuwe major op te nemen in een LTS versie. Geef eerst iedereen de tijd om hun webapps aan te passen zou ik zeggen voordat je ze gaat "verplichten" om PHP7 te gebruiken. Nu gaan vele webdevelopers weer een PHP5 binnen halen uit een andere bron omdat het te veel werk is om alles in 1 keer om te zetten.
Dus je wilt dat een nieuwe release van een distro oude software gebruikt.

Als je zo graag verouderde releases van een pakket wil gebruiken, dan blijf je toch lekker bij een oudere release van een distro? Probleem opgelost.

Het moet een zeer speciaal persoon zijn die niet al klaar is met de PHP7 overgang, toch een kersverse Ubuntu wil hebben, deze ook nog eens gebruikt voor zijn ontwikkel omgeving en op de servers.

Mensen die cutting edge willen zijn, zijn al lang met 7 bezig, mensen die liever alles eerst even afwachten gaan niet meteen een 16.04 gebruiken.
[...]


Daar ben ik het wel mee eens, maar waarom moet er voor een enkele PHP-versie gekozen worden? En waarom geldt een dergelijke "regel" dan niet voor Python?
Dat is nu ook zo in sommige gevallen. Uit de officiële release notes:
Python2 is not installed anymore by default on the server, cloud and the touch images, long live Python3! Python3 itself has been upgraded to the 3.5 series
En Digital Ocean:
Ubuntu 16.04 comes by default with Python 3.5.1 installed as the python3 binary. Python 2 is still installable using the python package
Dat hij niet standaard geïnstalleerd wordt is wat anders dan dat hij niet meer beschikbaar is. PHP5.6 hoeft ook echt niet standaard geinstalleerd te worden, maar het zou leuk zijn als de mogelijkheid er was zonder PPA's te gebruiken.
Bedankt voor de waarschuwing. Zo'n geintje was vorige LTS ook met een nieuwe Apache die ineens de configs anders deed ( zonder waarschuwing dus het was wel even zoeken ).

Wel vervelend voor developers die vast zitten aan oudere PHP versies om te testen, aangezien er nog steeds zuthosters met zelfs PHP 5.2 bestaan ( en PHP 5.3, maar dat is minder irritant ) .
Opaich mag je met een LTS upgrade ook wel enige breaking changes verwachten, en ik denk dat de apache changes redelijk snel te vinden waren. Ja, het was even puzzelen, maar ik hoop niet dat iemand 'do-release-upgrade' op een productieserver heeft gedaan zonder te testen.

En mensen die php 5.2 of 5.3 willen draaien mogen dat vanaf nu gewoon lekker in een vm of container stoppen. Helemaal 5.2 is al zo oud dat je daar echt vanaf wil.
Vertel mij wat met dat PHP. Jammer genoeg willen sommige klanten dat je ook op allerhande houtje-touwtje servers draait vaak zonder dat ze zelf controle hebben daarover. Fijn dat Tweakers het in elk geval meldt, dan weet je waar je aan begint. ;)
Evengoed wil je op een server niet direct PHP 5.6 droppen.
Wij willen zelf default 5.6 aanbieden met optional (via htaccess) PHP 7
Ik zocht in het artikel al naar deze informatie. Een maand geleden was hier online ook bijna niks over te vinden.
Fijn dat ze voor PHP7 hebben gekozen.
"Of en wanneer de propriëtaire drivers van AMD in de nabije toekomst weer op Ubuntu gaan werken, is nog niet duidelijk"

fglrx zal niet meer ondersteund worden. AMD heeft al zijn aandacht verschoven naar de opensource driver. Voor workstation toepassingen is er de Hybrid pro driver. Dit is de oude fglrx userland die op de opensource amdgpu kernel driver draait.
http://www.phoronix.com/scan.php?pag...d-Linux-Driver

[Reactie gewijzigd door mard0 op 22 juli 2024 15:39]

Ik had gelezen dat er gewerkt wordt aan een soort hybride driver, waar natuurlijk niet per se mee gezegd wordt dat fglrx hier (deels) inzit.

Als ik achter een gewone computer zit, zal ik dat even wijzigen en toevoegen dat als je afhankelijk bent van specifieke zaken die alleen met de deprecated drivers werken, je nog drie jaar 14.04 kunt gebruiken :) (of iets in die richting)
Zou wel fijn zijn, goed werkende AMD drivers. Heeft mij al heel wat hoofdpijn opgeleverd in het verleden.
Open source drivers die buggy zijn en willekeurige karakters op het scherm veranderen in vage bitmaps.
Propriety AMD driver die op zich goed werkt, maar plotseling Unity niet meer op laat komen.

Het werkt momenteel , maar is niet altijd even stabiel :)

Dat gezegd hebbende kijk ik weer uit naar de laatste versie van Ubuntu. Als OS om op te ontwikkelen vind ik het persoonlijk zeer prettig werken.
Wat ik mij afvraag van het ZFS-gedeelte: Kan je vanuit de installer al een ZFS volume aanmaken waardoor je Ubuntu op een ZFS partitie kunt installeren of moet je ZFS achteraf installeren waardoor Ubuntu op een EXT4 partitie wordt geïnstalleerd?
Die snaps naast debs vind ik interessant.

Dat systeem word ook in PCBSD gebruikt. Ik draai nu alleen maar nog Debian maar moet soms op Ubuntu debs terugvallen om iets geistalleerd te krijgen wat onder Debian niet beschikbaar is.

Als die snaps onder Debian beschikbaar zouden komen zou dat handig zijn. Hoop dat er in de volgende versie werk van wordt gemaakt.
Ik hoop dat het niet naar Debian komt. Ik vind het een slecht systeem en een veiligheidsrisico. Devs staan ineens zelf in voor het packagen van elke library. Als er morgen een nieuw lek gevonden word in bijv. openssl dan moet elke dev van elke snappy app die daar gebruik van maakt een update voorzien en moet jij als eindgebruiker ook maar zien dat al je paketten bijgewerkt geraken.

Je weet zo dat na een tijd er exemplaren gaan zijn die niet meer ondersteund worden en onveilig zullen blijven of dat devs hun updates gaan verwaarloorzen.

Vandaag maakt iedereen gebruik van dezelfde bibliotheek en moet deze dan ook maar 1x gepatched worden om alle software weer veilig te krijgen.

en dan hebben we het nog niet gehad over de overhead. Heb je een pakket dat een SQL server als dependency heeft? Mag dat pakket maar zien dat de SQL server mee verpakt zal zitten. Heb je er zo meerdere mag je systeem meerdere SQL servers gaan draaien.

Neen, geef mij maar het huidige debian model waarin alles gedeeld word en transparant draait tov elkaar.
Wat ik begrepen had draait snaps in een sandbox waardoor er juist geen veiligheidsrisico is.
De rest van de excuses zag ik een aantal jaar geleden ook terug in de FreeBSD community toen PCBSD hiermee begon. En daar draait het niet in een sandbox.
Uiteindelijk viel dit allemaal mee en is het niet uitgedraaid zoals men eerst dacht.
Bovendien is dit handig voor op een desktop.

[Reactie gewijzigd door El_Bartholomew op 22 juli 2024 15:39]

Sandbox is nog niet een garantie voor veiligheid. Als er een bug zit in een bepaalde library bijvoorbeeld van versie X. En het wordt geupdate in versie Y. En de SNAP blijft lekker draaien met versie X die vatbaar is voor een exploit.
Ben niet helemaal bekend met containers, maar het grote voordeel van containers is volgens mij dat een developer niet alle scenario's dat een applicatie niet goed zou functioneren hoeft voor te zijn maar zich alleen hoeft te focussen op hoe het wel goed werkt.
Updates van de applicatie gaan dan ook gepaard met updates van onderliggende libraries maar dat lijkt mij helemaal geen raar scenario. Maar zouden er gerichte aanvallen zijn op een applicatie die nog op een oudere libraries gebruikt, dan zou het zoals El_Bartholomew ook zegt niet te veel schade moeten kunnen aanrichten gezien deze binnen een sandbox draait.
Anoniem: 145867 @aileron23 april 2016 14:46
Containers zorgen ervoor dat je een library toespitst op een enkele service. Dit zorgt ervoor dat er minder kapot gaat ja. Maar je krijgt wel overhead.
En als je die library alsnog update moet je alsnog je service weer testen of hij wel werkt met deze library.

Maar als je update kan het nog steeds kapot gaan, en als je niet update ben je vatbaar voor exploits bij de desbetreffende oude library die toevallig zo goed werkt met jou service. Leuk voor jou, maar minder leuk dat het vatbaar is voor exploits.
Het is niet handig voor op een desktop. Het is alleen handig voor developers die zo minder rekening hoeven te houden met verschillende distributies en alle deps maar gewoon in hun package erbij kunnen mieteren. Met het riscio dat het pakket niet bijgewerkt wordt na security exploits waardoor je lekke code blijft draaien. Leuk dat het dan in een sandbox draait maar je applicatie blijft net zo kwetsbaar.

Als gebruiker ga je hier alleen de slechte kanten van ondervinden, niet de goede kanten. Voor dependencies had de gebruiker namelijk al 'apt' en de repositories.
Ik denk zelf dat het wel een goed idee is voor desktops en consumentenapparatuur. In mijn ogen zijn er twee partijen. De mensen achter het besturingssysteem en de mensen achter de individuele applicaties die op dat systeem draaien. Een applicatie vanuit de optiek van een beheerder bestaat deels uit applicatiespecifieke code en een deel uit libraries.

Als we er van uitgaan dat applicaties gemiddeld uit 80% libraries bestaand dan betekend het dat 20% applicatiespecifieke code is. Het maakt dus niet uit hoe goed de mensen achter het besturingssysteem zijn in het patchen van libraries op beveiligingsproblemen. Zij zullen nooit* bij die overige 20% kunnen komen. En dan heb ik nog niet eens over closed source code gehad.

Wat kunnen de mensen achter het besturingssysteem dan wel doen? Zij kunnen applicaties isoleren en faciliteren. Duidelijk naar de gebruiker communiceren welke rechten een applicatie heeft binnen zijn isolement. En duidelijk aangeven dat zij, zoals uitgelegd hierboven, niet gerant kunnen staan voor de veiligheid van de applicatie.

Maar wie kunnen dat dan wel? Dat zijn de applicatieontwikkelaars. Zij hebben namelijk 100% toegang tot de code. Zij bepalen immers welke libraries zij gebruiken. Dit maakt het voor de gebruiker ook veel duidelijker. Als je een veilige VPN verbinding wilt, gebruik dan een applicatie hiervoor van een vertrouwde uitgever.

Ik gok dan ook dat applicaties zich in de toekomst zich steeds meer als diensten gaan manifesteren. Een stuk code (de applicatie, al dan niet in een Snap) en een bedrijf of community die het onderhoud.
Kan iemand vertellen wanneer de server versie uitkomt?
Niet opgelet de afgelopen eeuwigheid? De server variant komt altijd vrijwel gelijk mee met de Desktop variant..
Nee te druk met andere dingen
Dat kan ook, maar bij de release van de nieuwe Ubuntu, komt standaard ook de Server variant mee..
Waar kan ik downloaden of is het nog niet uit?
ik vraag me af of systemd inmiddels in de plaats van upstart is gekomen, aangezien daar geen medling van wordt gemaakt?
Ik kan bevestigen dat systemd nu de default is geworden in Ubuntu 16.04

Verschillen die mij opgevallen zijn qua booten.
- Alle informatie die tijdens het booten op het scherm getoond wordt zie ik nu ook in de syslog weggeschreven worden. ( erg handig :D )
- Ik krijg openvpn niet meer gestart en heb moeite dit te debuggen met systemd.

You gain some you lose some.

Verder heb ik geen principiele problemen met systemd.

[Reactie gewijzigd door MoonWatcher op 22 juli 2024 15:39]

En migreert het systeem bij een upgrade vanaf 14.04 vanaf Upstart naar Systemd? Of is Systemd alleen standaard bij een schone installatie? Ook ik heb geen principiele problemen, maar wil het graag van te voren weten.

Overigens is het lastiger debuggen van Systemd-problemen een van de kritiekpunten...
Ik heb eerder bij mijn upgrade 15.04 -> 15.10 (oid) al systemd gekregen, ik vermoed dat bij een upgrade 14.04 -> 16.04 dit ook zo zal zijn.
Systemd is op Debian / Ubuntu backwards compatible geimplementeerd, scripts in /etc/init.d worden ook gewoon nog gedraaid. Daarmee is het mogelijk om geleidelijk aan over te schakelen en zal een upgrade dus vanzelf de overstap kunnen maken, zelfs als er nog packages zijn die niet geschikt zijn voor systemd.

Overigens vind ik het debuggen veel makkelijker; met journalctl kun je eenvoudig de output van één enkele service zien in plaats van dat je zelf door diverse logfiles moet gaan grasduinen.
Als je OpenVPN configuratie op de juiste plek staan, kan je ze opstarten dmv:

sudo systemctl start openvpn@naamvanjeconfig
Systemd zat al in Ubuntu 15.
Ik heb hier een HTPC met Ubuntu 15.10 staan en ook daar is systemd al in gebruik (default), dus ze zijn hier in 16.04 niet vanaf gestapt.

Werkt prima en start sneller op. Helaas is het zelf maken van start-scriptjes wel wat complexer dan met upstart of sysvinit, maar gelukkig is er een backwards compatibility wrapper gebouwd waarmee je ook met 'ouderwetse' scriptjes kunt werken.
Zeg, misschien kijk ik er overheen, maar via ubuntu.com is op dit moment 16.04 unity noch de gnome flavour te downloaden. Ben ik ongeduldig, blind, of moet de VS nog wakker worden?
Anoniem: 467952 @Vygotsky21 april 2016 10:27
Neen je bent niet blind ;) Het is inderdaad nog niet te vinden. Ik meen mij te herinneren dat het meestal even duurt voor een ISO beschikbaar komt *wanneer ze wakker zijn* ;)

[Reactie gewijzigd door Anoniem: 467952 op 22 juli 2024 15:39]

Ik zie de ISO-images (non-beta) nu binnen komen druppelen op de diverse FTP servers.
Heb hem nu hier gevonden, bij Alternative downloads op hun site.
Anoniem: 572096 21 april 2016 06:43
Ik heb de beta al een tijdje draaien en heb in elk geval niet veel last van bugs die er nog zouden inzitten.
Ik wordt wel blij van zfs-ondersteuning, al zal dat niet voor elk systeem weggelegd zijn wegens memory-happy....

Mooie, nuchtere review!
ZFS is prima te gebruiken op systemen met wat minder geheugen. Vanaf 512MB geheugen zou je al prima ZFS kunnen gebruiken. Als je ARC limiteert op 128MB gaat dat prima.

Waar je vooral op moet letten is dat ZFS geheugen kernel geheugen is, en niet zomaar 'losgelaten' wordt als gewone applicaties geheugen nodig hebben. Je zult dus zelf even een klein limiet op moeten geven.

Wil je dat ZFS zijn spierballen echt laat zien, dan is (relatief) veel geheugen wel fijn. Voor een desktop systeem moet je dan aan 6GB+ geheugen denken.
Is het niet zo, dat hde ideale hoeveelheid geheugen ook afhangt van je totale opslag? Verder is het volgens mij oko aan te raden om ECC geheugen te gebruiken!
Nee, dat is een fabeltje.
De vuistregel voor Enterprise gebruik, (welke door de ZFS advocates altijd genoemd wordt) is 1GB RAM per 1TB Storage. Maar dat is een Enterprise regel waar er rekening gehouden wordt met een stevig IO patroon.

Voor thuisgebruik hoef je die regel absoluut niet toe te passen.
Is het niet zo, dat hde ideale hoeveelheid geheugen ook afhangt van je totale opslag?
Ligt er voornamelijk aan hoeveel van die opslag actief gebruikt wordt (de workload). Waar de totale opslag voorzover ik weet vooral uitmaakt is voor deduplicatie, omdat dan de deduplicatietabellen waarin wordt bijgehouden welke blokken duplicaten van elkaar zijn ook groter worden. En die wil je absoluut in RAM houden, anders komt alles stil te staan :P
Mijn ervaring met de FreeBSD implementatie is dat de ARC gewoon krimpt als applicaties het geheugen echt nodig hebben, maar wellicht is er hier een verschil. Moet wel bij gezegd worden dat dit pas echt goed werkt zonder tuning vanaf zo'n 4 à 6 GB RAM, wellicht bedoel je dat ;)

[Reactie gewijzigd door Sfynx op 22 juli 2024 15:39]

Om het technischer te maken: Ik bedoelde dat bij > 4GB automatisch ZFS Prefetching aan gaat. Dat kan je aanzetten met specifieke tuning onder 4GB, maar in veel gevallen is dat helemaal niet verstandig.

ZFS met Prefetching aan performed stukken beter dan zonder :)
Lees ik het dan goed dat je als AMD videokaart eigenaar niets hoeft te vrezen van deze nieuwe LTS ( enkel tenzij je opencl wenst te gebruiken )
D.w.z. GUI draait normaal , alle belangrijke functionaliteiten van de AMD propriëtaire driver zitten nu in de open source variant ? ( zoals instellingen voor meerdere schermen , video acceleratie ) Games draaien is ook geen probleem ?
In veel gevallen werkt het meeste goed, maar even wachten met upgraden en/of een Google actie doen met je specifieke hardware en games kan nooit kwaad.

Persoonlijk heb ik al een tijd geen negatieve ervaring met de open source drivers en al veel eerder uit de proprietaire drivers gegooide ati-kaarten en wat oudere games, zoals tf2 en Portal, maar Cities:Skylines... Nou ja. Daar heb je toch echt iets nieuws voor nodig.
Waar ik heel benieuwd naar ben, en nooit echt lekker werkend heb gekregen in 14.04 / 15.04 is mijn laptop met dual graphics obv een Radeon.
Beste "oplossing" was over het algemeen de dual graphics uitzetten en op de GPU van de processor draaien. Maar dat is een beetje zonde natuurlijk.

Hopelijk dat dat met de nieuwe AMD graphics drivers wat gladder werkt.
Bedoel je hiermee bv die HP laptops die zowel een radeon als een normale videokaart hebben? Ik heb er ook zo eentje en dat werkt inderdaad voor geen meter. Gamen moet ik dan ook nog steeds op windows aangezien vrijwel niets draait.

Zou fijn zijn als daar een oplossing voor komt, maar ik heb er een hard hoofd in. Zelfs op windows draait catalyst niet aangezien HP al tijden gestopt is met het bijwerken v/d firmware, althans voor de laptop die ik heb ( Pavilion G6 )
Exact, een ProBook 4740s in dit geval.
Zou wel mooi zijn. Valve werkt keihard om ook Linux users te laten meegenieten, zou fijn zijn als daar gebruik van gemaakt kan worden!
Ik heb er een hard hoofd in. En afgezien van de positie van de ventilator gaat dit ook een onderzoekspunt worden van mij bij aanschaf van de opvolger. Ik heb namelijk alleen maar gezeik gehad van die dubbele videokaart. Ook onder Windows gaat dat namelijk niet altijd vlekkeloos.
Lenovo Thinkpad Edge hier met 2nd Gen i5 en Radeon 6630. Dat is ook Dual Graphics en die 6630 wil je toch graag gebruiken. Indien mogelijk zou ik de intel-GPU willen uitschakelen, vooral onder Linux want onder Windows lijkt het wel goed te werken.
Anoniem: 719316 @letatcest21 april 2016 10:56

Op dit item kan niet meer gereageerd worden.