Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 72 reacties
Submitter: mikeoke

Linux-kernel 4.0 is uitgekomen. De nieuwe kernel bevat onder andere de mogelijkheid om deze zonder herstart van het besturingssysteem te updaten. Ook zijn er de nodige grafische verbeteringen aan de kernel.

TuxIn kernel 4.0, die de obscure werktitel 'Hurr durr I'ma sheep' draagt, is live kernel patching geïntegreerd. Deze toevoeging aan de kernelcode maakt het mogelijk om aanpassingen aan de kernel door te voeren zonder dat een herstart van het systeem nodig is. De achterliggende kernel patching-code is ontwikkeld in samenwerking met Red Hat en Suse die soortgelijke mechanismen hebben uitgebracht onder de namen Kpatch en kGraft.

De kersverse Linux-kernel bevat ook displayport-ondersteuning in de Radeon drm-driver. Ook is er ondersteuning voor IBM's nieuwe Z13-mainframe toegevoegd, evenals voor de Quark-soc van Intel en diverse ARM-socs. Ook kan de kernel overweg met Intels Skylake-architectuur, terwijl de opensource Nouveau-driver voor Nvidia-hardware ook de nodige verbeteringen kent.

Moderatie-faq Wijzig weergave

Reacties (72)

Hurr durr I'm a sheep
Konden ze echt niks anders verzinnen?

Dat live updaten is wel een grote verandering. Kernel updates waren volgens mij de enige updates die een herstart vereisten.

[Reactie gewijzigd door Bonobo op 13 april 2015 10:48]

En hier is de poll besproken in de commit: https://plus.google.com/+LinusTorvalds/posts/TvigQqA9m3w

Edit: Woeeps hieronder al gereferenceerd.

[Reactie gewijzigd door space_octopus op 13 april 2015 12:32]

Volgens mij staat daar alleen de oorzaak dat deze naam het geworden is, niet de reden van de naam :-)
Maar uit de oorzaak kan je zelf de reden concluderen.
Kernel updates en updates aan de graka-driver.
Nu was voor de laatste genoeg om X compleet te killen, maar wie weet nu hoe dat moet?
je display manager (lightDM, MDM, KDM, GDM) herstarten werkt en is niet zo moeilijk
sudo restart lightdm
voor lightDM
De grote diversiteit in mogelijkheden, waarvan jij hier een paar voorbeelden geeft, is al veel te moeilijk voor de doorsnee gebruiker.
Daarom is een reboot veel simpeler uit te leggen, want dat werkt nl. altijd ongeacht welke display manager of versie of zelfs os.
Puristen vinden het lastig, maar uiteindelijk is het veel gebruiksvriendelijker dan mensen te dwingen om uit te gaan zoeken wat distributie x versie y nu exact voor cli commando's nodig heeft om hetzelfde te bewerkstelligen.
Zeker tegenwoordig nu een reboot maar een paar tellen kost.
De doorsnee gebruiker zal ook niet een display manager moeten herstarten, toch?
Als hij een nieuwe graka driver installeert wel.
En dat is toch iets dat regelmatig noodzakelijk is.
Ja maar wat is een "doorsnee gebruiker" van Linux. In de context van een artikel over de Kernel ga ik er persoonlijk vanuit dat dit toch echt ICT mensen zijn, en niet mensen die wat hobbyen met een Raspberry PI.
sudo killall X

Maar alleen als je zeker weet dat je de X server rechtstreeks wil killen.
@jeroen7s en brompot758.

Hoe dat moet hoef je mij niet te zeggen.
Maar er zijn genoeg mensen die dat niet weten en dan is een reboot makkelijker.
Nu was voor de laatste genoeg om X compleet te killen, maar wie weet nu hoe dat moet?
Dat is een taak voor je distributie/package manager. Als die gebruik gaan maken van deze optie kunnen ze kernel patches installeren zonder reboot. De gebruiker hoeft, als deze automatische updates aan heeft staan, helemaal niets te doen. En ook niet meer te rebooten voor dat patches actief worden.
[...]

Konden ze echt niks anders verzinnen?.
Dat is democratisch gekozen via de Google+ van Linus: https://plus.google.com/+LinusTorvalds/posts/TvigQqA9m3w
De vorige naam(van de versie voor 4) was ook aardig obsecuur. "Diseased Newt". De eerste git commit versie van kernel 2 was "Woozy Numbat".
Dit is wat je krijgt als je programmeurs zonder een marketing team namen laat kiezen. :+ (Natuurlijk is dit stereotypering, er zit wat in maar niet al te serieus nemen)
Het zijn ook geen "echte" namen, het zijn namen van het bestand Makefile. Het wordt gebruikt om het programma te compilen.

[Reactie gewijzigd door space_octopus op 13 april 2015 12:43]

Ik ben tenminste nog blij dat ze het een rare naam hebben gegeven. Linux, is zover ik weet, de enige die humor in het OS heeft zitten. Rare namen en humor = goede combo. Kortom: Linux = Geniaal!
Ik denk dat ze makers refereren naar de gemiddelde Apple gebruiker. Uiteraard als een grapje bedoeld.

Programmeurs mogen toch ook af en toe een grapje maken ;)

Edit: Heb het even nagekeken. Het was een 1 april grap.

[Reactie gewijzigd door Macfreakje op 13 april 2015 10:58]

Referentie? De commit wat "Hurr durr I'm a sheep" aangeeft is gemaakt op 23-02-2015
Dat zonder herstarten updaten van de kernel is wel echt heel erg handig. Vooral voor mission critical diensten die altijd moeten blijven draaien :) Ideaal!
mission critical services hebben gewoonlijk al redundantie/failover, dus hebben eigenlijk nu al het minste last van server reboots die nodig zijn voor patches.

Ik denk dat het een goed idee blijft om bij complexe electronica af en toe terug te gaan naar de meest eenduidig gedefinieerde toestand... uit.
Onzin, je gaat servers niet uitzetten gewoon omdat het kan. Dan doe je echt iets niet goed.
Dus je wilt zeggen dat ze gestoord zijn bij Netflix? :)
Juist het continu verstoren van (delen van) je infrastructuur zorgt er voor dat je wéét dat je overeind blijft staan op het moment dat het er echt op aan komt ;) En het zorgt er daarnaast ook nog eens voor dat je goed voorbereid bent...
Dat is gewoon het aftrappen van VM's en nieuwe automatisch deployen. Dat is iets heel anders dan "complexe electronica af en toe uitzetten".
Wat is het verschil?
Beide systemen moeten up-to-date gehouden worden, beide systemen hebben last van configuratiefouten, BSOD's of Kernel Panics, in beide gevallen gaan alle gehoste services volledig down. Het enige verschil is of de software als enige gebruik maakt van de hardware, of dat deze mogelijk gedeeld is.
Beide omgevingen hebben last van runtime errors die langzaam aan het geheugen corrumperen. Beide omgevingen kunnen last hebben van memory leaks.

Beste 'fix' daartegen blijft nog steeds het credo uit The IT Crowd: 'Have you tried turning it off and on again?'. Je wil dan echter wel weten dat je omgeving (server plus services) weer correct online komt, of het een gevirtualiseerde omgeving betreft of een fysieke maakt in het geheel niet uit.
Hoe test je dat? Juist, moedwillig verstoren :)
ik denk dat je m'n post moet herlezen en je interpretatie wat moet verengen. ik raad niemand aan om voor de lol wat servers uit te zetten. ik zeg alleen dat het een goed idee is terug te gaan naar een gekende status. Hoe complexer de electronica, hoe strict minder gedfinieerde statussen er zijn. Power off power on blijft een zeer effectieve manier om alvast naar één vrij goed gedefinieerde status te gaan. Op die manier lost een reboot soms een probleem op, maar brengt er evengoed soms aan het licht.
dit is zeker: iedereen wil dat z'n systemen op komen na een reboot. Er is maar een manier om dta zeker te weten: rebooten.
Precies! Net als het testen van een backup eens in de zoveel tijd
Het testen van een backup is voor systeembeheerders zonder zelfvertrouwen 8)7

Nee niet serieus bedoeld maar een vast opmerking waar ik werk om het niveau aan te geven van de gemiddelde niet-systeembeheerder.
Het is echter wel een uitkomst voor non-mission-critical productieservers. Nu moet ik 's-nachts downtime inplannen voor kernel-upgrades, wat dus overwerk betekend. Ik doe dit liever overdag, en dat zou hiermee moeten kunnen.
Dat zonder herstarten updaten van de kernel is wel echt heel erg handig. Vooral voor mission critical diensten die altijd moeten blijven draaien :) Ideaal!
Het is wel cool dat het kan. Maar ik vraag mij af of het echt zo handig is. Als je een missie kritieke infrastructuur hebt ben je al niet goed bezig als je de uitval van een paar machines niet goed kunt afhandelen lijkt mij.
Daarom moet je je systemen ook regelmatig restarten zodat je altijd blijft testen dat je systeem goed werkt na een reboot.
Er bestaat geen wedstrijd voor je uptime van je machine :+
Niks bijzonders voor Novell. Hier haalden we regelmatig uptimes van 2+ jaar.
Blijkbaar niet erg 'cheat-proof' :+ :
<line Id="192728">
<place>1</place>
<machine>192728</machine>
<hostname>jutukas</hostname>
<owner>291801</owner>
<uptime>1354406400</uptime>
<uptime_formatted>42 years 346 days</uptime_formatted>
</line>

*edit : source : https://linuxcounter.net/xml/toplist_uptime.xml

[Reactie gewijzigd door ag_001 op 13 april 2015 11:45]

LOL... kansloze uitspraak: "er bestaat geen wedstrijd voor.... ".

Veel te veel nerds hier die er eentje weten te vinden ;)
Denk dat het ook cynisch bedoelt was ;)

Vroeger op IRC was het een trend om te kijken wie de hoogste uptime heeft waarbij iedereen het commando /uptime intoetste :P Waarbij sommigen er een hele sport van maakten met thuis-servertjes die 3 jaar nonstop aanstonden.
LOL, dat zijn de echte nerds inderdaad :)
Sterker nog. Ik doe eraan mee :+
Het is wel cool dat het kan. Maar ik vraag mij af of het echt zo handig is. Als je een missie kritieke infrastructuur hebt ben je al niet goed bezig als je de uitval van een paar machines niet goed kunt afhandelen lijkt mij.
In de ideale wereld heb je gelijk. In de praktijk echter ligt het aan de invulling van het begrip 'afhandelen'...

Een mogelijke (en veel gebruikte) oplossing als 'afhandeling' is downtime, die kan worden ingezet om bijv. een service op een andere machine op te starten. Ik heb situaties gezien waar dat een paar uur duurt. Waarom? Omdat je soms een service slechts op 1 machine kan draaien om de data consistent te houden - en initialisatie (incl recovery) lang kan duren. Dit is een prima oplossing om om te gaan met exceptionele gebeurtenissen als 'servers die overlijden', blikseminslag, etc - maar minder prettig bij upgrades / updates. In dat laatste geval heb je een service window nodig, die meestal in de nacht wordt uitgevoerd. Standaard (externe) monitoring en een roze telefoon lossen de rest van het service level op.

Nogmaals, dit is zeker niet ideaal (en het kan ook zeker wel automatisch), maar wel hoe het vaak gedaan wordt. Oorzaak is dat de focus van business (critical) software primair ligt op het oplossen van het business probleem en niet op de mooiste of meest automatische oplossing. Dat laatste kost tijd, die ook elders besteed kan worden (en heb je een goede software architect voor nodig, die schaars is).

Dat maakt dat de keuze in de praktijk neerkomt op geen updates installeren of nachtwerk. Drie keer raden wat voor gevolgen dit heeft.

Dergelijke updates zonder herstart lossen een aanzienlijk deel van de gehele ellende op, doordat het aantal service windows afneemt. Er is hiermee niet echt meer een reden om een update niet te installeren, wat volgens mij een aanzienlijke plus is.
Er zijn natuurlijk een hoop situaties te bedenken waarbij je de kernel wilt updaten, maar dat het herstarten voor een ongewenste downtime zorgt. Wanneer je eenmaal ervaring hebt opgebouwd met deze methode kan ik mij voorstellen dat dit veelvuldig gebruikt gaat worden.
Haha, dat is een heel ander verhaal inderdaad. Helaas zie ik het vaak zat gebeuren bij klanten bijvoorbeeld!
de seininstallatie bij de spoorwegen om een voorbeeld te geven, redundant met hotswappable van alles en nog wat maar indien de veiligheidsprocedures gevolgd worden moet het spoornet op dat stuk volledig onderbroken worden indien 1 van de redundant/backup systemen off-line gehaald worden.
MIssion critical systemen zijn meestal dubbel (of meer) uitgevoerd waarbij makkelijk 1 server down kan voor een patch / reboot.

Als dat niet kan is het systeem toch niet zo mission critical ;)
Je zou er versteld van staan hoeveel business systemen mission critical zijn, volledig HA infrastructuur, maar de applicatie zelf, waar het uiteindelijk om gaat natuurlijk, niet HA-aware is. Kan iedereen wel roepen:
- dan is het niet mission critical
- dan moet de klant maar een andere applicatie kiezen, anders is het niet mission critical

Sorry. Bullshit. Zo werkt de wereld (helaas) niet altijd. :)
Ja echt wel! Zou fijn zijn als ik m'n servers niet opnieuw hoef op te starten. Echter voor deze kernel in de stable Debian release komt zijn we paar jaar verder vrees ik...
Dat zonder herstarten updaten van de kernel is wel echt heel erg handig. Vooral voor mission critical diensten die altijd moeten blijven draaien :) Ideaal!
Persoonlijk vind ik het onnodige complexiteit toevoegen voor een feature waar mensen met echt mission critical diensten toch niet effectief gebruik van gaan maken (aangezien die nu al gewoon een server kunnen rebooten zonder downtime).
Is toch al heel lang gewoon mogelijk?

http://www.computerworld....th-linux-and-ksplice.html (2009)

Ik snap dat dit een slimmere manier is omdat het nu echt meegeleverd word in de Linux kernel, maar je distro moet het alsnog ondersteunen. Iets wat Ubuntu dus nog niet out of the box doet.
Het bestaat al lang, maar niet gratis+ingebouwd.
ja alleen is ksplice van Oracle en wil het niet delen, daarom zijn er nu 2 OpenSource alternativen waarvan de gedeelde code nu in de kernel zit.
Het bedrijf dat dit maakte is opgekocht door Oracle, die het vervolgens closed source gemaakt heeft.
Ja het is wel mogelijk maar niet zondermeer.
Domme vraag wellicht, maar maakt de mogelijkheid om de kernel "live" aan te passen het systeem niet kwetsbaarder voor aanval van buitenaf? En zo ja, maakt beschermingen daarvoor de kernel niet logger dan noodzakelijk?
Juist niet; potentiële exploits kunnen worden gepatched zonder dat jij daar een melding van krijgt. Je kunt Linux zo configureren dat ook veiligheidspatches automatisch worden geïnstalleerd zonder tussenkomst van de gebruiker. Kernel-upgrades vallen daar in de regel ook onder.

Zo hoef je je geen zorgen te maken om de integriteit van je systeembeveiliging.

Aangezien Android ook gebruik maakt van een Linux-kernel zul je in de toekomst systeemupdates voor je smartphone kunnen doorvoeren zonder dat je toestel daar opnieuw voor moet opstarten, wat de kans op "bricken" verkleint. Het zal je maar gebeuren dat je accu het begeeft tijdens het herschrijven van de firmware.
Elke keer als ik een telefoon moest flashen had ik die gewoon op de lader hangen hoor. Ik vind het niet zo een super idee om zo een zaken op batterij te doen. Zelfde met BIOS updates of firmware updates van andere apparatuur, die hang ik dan op UPS.

Ook al moet je nu niet meer herstarten bij een update, als de stroom uitvalt net op het moment dat er data weggeschreven wordt dan is je toestel nog gewoon bricked.
Enige nuancering bij het versienummer is wel op zijn plaats. De reden dat Linus de kernel versienummer 4.0 in plaats van 3.20 heeft gegeven is dat hij afwilde van hoge versienummers achter de komma/punt. Dat maakt de release van 4.0 een stuk minder bijzonder dan het nummer doet vermoeden.
Zoals Cilph hierboven al linkt:
https://git.kernel.org/cg...be9507871fab3931deccff539

In dit geval was het ook gewoon een uitkomst van een poll. Wel leuk dat mensen er al best wel snel vrede mee hebben gekregen dat versienummers van de kernel niet zoveel meer zeggen.

Voor de luie mensen:
.. after extensive statistical analysis of my G+ polling, I've come to
the inescapable conclusion that internet polls are bad.

Big surprise.

But "Hurr durr I'ma sheep" trounced "I like online polls" by a 62-to-38%
margin, in a poll that people weren't even supposed to participate in.
Who can argue with solid numbers like that? 5,796 votes from people who
can't even follow the most basic directions?

In contrast, "v4.0" beat out "v3.20" by a slimmer margin of 56-to-44%,
but with a total of 29,110 votes right now.

Now, arguably, that vote spread is only about 3,200 votes, which is less
than the almost six thousand votes that the "please ignore" poll got, so
it could be considered noise.

But hey, I asked, so I'll honor the votes.
Dit was de "test poll":
https://plus.google.com/+LinusTorvalds/posts/TvigQqA9m3w

Dit was de 4.0 poll:
https://plus.google.com/+LinusTorvalds/posts/jmtzzLiiejc

[Reactie gewijzigd door afraca op 13 april 2015 10:55]

Dat "live kernel patching" zit er volgens mij al langer in. Nadat ik mijn Ubuntu 14.10 installatie (volgens mij v3.16.0-34) heb geupgrade naar de developerversie van 15.04 werd de systeemkernel geupdate naar v3.19.0-13. De oude kernel kernel werd vervolgens "live" uit het geheugen gehaald en verwijderd van mijn systeem.

Ik hoefde niet opnieuw op te starten terwijl "uname -r" aangaf dat de nieuwste kernel actief was.
Dat lijkt me eerder kexec.

Kexec staat een draaiende kernel toe om 'over te springen' naar een andere kernel. Dit doen ze door alles in de huidige kernel te ontladen, over te springen en dan alles opnieuw in te laden.

Het lijkt me echter sterk dat ze dit als kernel upgrade mechanisme hebben uitgerold, meestal wordt dit gebruikt als recovery mechanisme bij grote problemen - wat natuurlijk niet betekent dat het niet alsnog zo kan zijn, natuurlijk...
kGraft is ontwikkeld door SUSE.

Hier staat wat leuke additionele informatie:
http://www.phoronix.com/s...page=news_item&px=MTg3MTE
Mooie functies toegevoegd in deze update.

[Reactie gewijzigd door 2green op 13 april 2015 12:31]

Is dit echt een major bump waardig?
Het gaat wel hard zo, nog niet zo hard als Firefox maar toch.
Het is ook zeker niet de eerste keer dat de codename niet 100% serieus te nemen is:
http://en.wikipedia.org/wiki/List_of_Linux_kernel_names

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True