Ubuntu 16.04 Xenial Xerus Review

Meer dan een bugfix-release

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)

[MoonWatcher]

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.

[MadEgg]

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]

[MoonWatcher]

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]

[MadEgg]

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.

[Kevjoe]

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 :")

[bogy]

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.

[MadEgg]

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.

[Kevjoe]

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.

[MadEgg]

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.

[Superstoned]

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...

[goarilla]

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.

[Blokker_1999]

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.

[sfc1971]

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.

[Xylon]

[...]


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

[MadEgg]

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.

[Basszje]

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 ) .

[Kees]

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.

[Basszje]

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.

[hackerhater]

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

[Orthodroom]

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.

[mard0]

"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]

[letatcest]

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)

[fverhoef]

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.

[magnifor]

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?

[El_Bartholomew]

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.

[Blokker_1999]

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.

[El_Bartholomew]

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]

[Anoniem: 145867]

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.

[aileron]

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]

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.

[MadEgg]

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.

[tuXzero]

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.

[Silence]

Kan iemand vertellen wanneer de server versie uitkomt?

[robcoenen]

64-bit PC (AMD64) server install image (torrent)
32-bit PC (i386) server install image (torrent)

[SilentDecode]

Niet opgelet de afgelopen eeuwigheid? De server variant komt altijd vrijwel gelijk mee met de Desktop variant..

[Silence]

Nee te druk met andere dingen

[SilentDecode]

Dat kan ook, maar bij de release van de nieuwe Ubuntu, komt standaard ook de Server variant mee..

[TheRealProcyon]

Waar kan ik downloaden of is het nog niet uit?

[7th]

Ubuntu 16.04:
http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/
Mirror:
http://de.releases.ubuntu.com/16.04/
http://mirror.pnl.gov/releases/16.04/

Kubuntu:
http://cdimage.ubuntu.com/kubuntu/releases/16.04/release/

Ubuntu Mate:
http://cdimage.ubuntu.com...e/releases/16.04/release/

Ubuntu Gnome:
http://cdimage.ubuntu.com...e/releases/16.04/release/

Lubuntu:
http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/

Xubuntu:
http://cdimage.ubuntu.com/xubuntu/releases/16.04/release/

Ubuntu Studio:
http://cdimage.ubuntu.com...o/releases/16.04/release/

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

[Tha_Butcha]

ik vraag me af of systemd inmiddels in de plaats van upstart is gekomen, aangezien daar geen medling van wordt gemaakt?

[MoonWatcher]

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 )
- 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]

[zordaz]

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...

[geez]

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.

[MadEgg]

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.

[jaapzb]

Als je OpenVPN configuratie op de juiste plek staan, kan je ze opstarten dmv:

sudo systemctl start openvpn@naamvanjeconfig

[DenBeke]

Systemd zat al in Ubuntu 15.

[MadEgg]

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.

[Vygotsky]

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]

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]

[M.D.J.]

Ik zie de ISO-images (non-beta) nu binnen komen druppelen op de diverse FTP servers.

[Anoniemand]

Heb hem nu hier gevonden, bij Alternative downloads op hun site.

[Anoniem: 572096]

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!

[FireDrunk]

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.

[borft]

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!

[FireDrunk]

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.

[Sfynx]

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

[Sfynx]

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]

[FireDrunk]

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

[MPAnnihilator]

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 ?

[letatcest]

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.

[Blamm]

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.

[Basszje]

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 )

[Blamm]

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!

[Basszje]

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.

[BeosBeing]

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]

Hier staat wat aanvullende info: http://www.omgubuntu.co.u...talyst-fglrx-driver-16-04