×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

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

Lts-versies van Linux-kernel krijgen vier jaar langer ondersteuning

Door , 51 reacties

Google-ontwikkelaar Ilyan Malchev heeft op de Linaro Connect-conferentie aangekondigd dat lts-versies van de Linux-kernel nu zes jaar ondersteund worden in plaats van twee. Dat heeft onder meer gevolgen voor Android-apparaten.

In zijn presentatie legt Malchev, die werkt voor Project Treble, uit dat vrijwel alle Android-apparaten op een lts-versie van de Linux-kernel draaien. Doordat de ondersteuning eerst twee jaar was, was het zo dat tegen de tijd dat een apparaat uitkwam, er in het beste geval nog een jaar aan ondersteuning over was. Dat is problematisch, omdat onder meer belangrijke bugfixes via lts binnenkomen.

Google zou volgens Malchev willen dat een telefoon gedurende zijn lifecycle vier upgrades krijgt, maar in de realiteit gebeurt dit niet. Door de langere ondersteuning moet dit nu tot de mogelijkheden behoren. De ontwikkelaar stelt dat dit niet alleen te maken heeft met Android, maar dat veel meer apparaten van de lts-versies gebruikmaken. De verlengde ondersteuning moet beginnen bij versie 4.4 van de Linux-kernel.

Op de kernelpagina van Linux is inmiddels te zien dat deze in 2016 uitgekomen versie ondersteuning zal krijgen tot februari 2022. Een nieuwe lts-versie zou ongeveer elke negen maanden moeten uitkomen.

Door Sander van Voorst

Nieuwsredacteur

03-10-2017 • 08:55

51 Linkedin Google+

Reacties (51)

Wijzig sortering
Opzich niets tegen een LTS van 6 jaar, er zijn andere projecten die doen al jaren met 2.6 versie en houden het up to date.

Maar het had google juist gesiert, als ze tegen de fabrikanten hadden gezegt, jullie geven maar de specs vrij of gebruiken opensource drivers.

Daar hebben wij als gebruikers, veel meer aan. Aangezien wij dan elke toekomsteige kernel zouden kunnen gebruiken om onze devices te updaten.
Er zitten 72 maanden in 6 jaar, dat wilt dus zeggen dat er 8 LTS versies tegelijk ondersteund zullen moeten worden en daar komen de gewone releases nog eens bij. Is dit misschien niet een beetje te hoog gegrepen? Ze hadden beter de frequentie van LTS releases dan ook aangeapst naar 1 jaar of zelfs langer.

Daarbij, hoe exact lost dit het probleem met Android op? Waarom niet het gewoon makkelijker maken om de kernel updates mee te nemen voor toestellen, waarom die op een oude LTS houden?

[Reactie gewijzigd door Loller1 op 3 oktober 2017 09:09]

Omdat Qualcomm etc. hun drivers voor 1 LTS schrijven. Het probleem is dat dat zoveel tijd kost dat tegen de tijd dat ze eindelijk klaar zijn een LTS dus al bijna geen support meer heeft. Iedere keer drivers updaten hebben ze geen zin in.

Met de nieuwe LTS van 6 jaar zou het in principe mogelijk moeten zijn om 6 jaar lang security updates te pushen zonder dat Qualcomm etc. hun drivers hoeven aan te aanpassen.
Inderdaad. Het feit dat Linux geen stabiele kernel driver interface heeft maakt het moeilijk om veel kernel versies te ondersteunen op de manier waarop Qualcomm e.d. dat doen. Er is een zeer goede oplossing: de drivers in de Linux kernel tree onderhouden. Dan zouden Android telefoons gewoon een recente of de laatste kernel versies kunnen draaien zoals dat buiten Android gebruikelijk is. Maar daarvoor moet o.a. Qualcomm haar drivers onder de GPL vrijgeven.
Precies. Het feit is nu dat Linux een impliciete stabiele kernel interface heeft. Qualcomm zegt simpelweg dat (bijvoorbeeld) 4.9 de ondersteunde kernel versie is. Als versie 4.10 dezelfde kernel interface heeft, dan zal die ook wel werken met Qualcomm drivers. Dat is echter niet gegarandeerd.

Het praktische gevolg is dat iedere SoC fabrikant zelf een kernel interface kiest, en dat is niet noodzakelijkerwijs dezelfde keuze.

Dit project van Google creŽert effectief dus semi-stabiele kernel interfaces, namelijk de interfaces van de LTS versies.
Veel Nexus en Xperia (en Fairphone?) telefoons met Qualcomm SoCs hebben al mainline support, in de zin dat ze booten. Dat hebben we niet te danken aan Qualcomm (al hebben die wel een hoop onder GPL uitgegeven), maar aan Google en Sony.
Wat dan geloof ik nog rest is de GPU drivers, maar die kunnen wellicht worden vervangen door Freedreno (met dank aan Rob Clark).
Ik ben er niet teveel in thuis (dit is ook uit mn hoofd) maar iig zijn er wel mogelijkheden zonder dat Qualcomm hoeft mee te werken.
Er verandert toch niks? Elke 9 maanden blijft een nieuwe versie komen waarvoor ook drivers geschreven moeten worden ;)
Als de fabrikanten nou zouden "mainlinen". Dan was dat nog een werkelijkheid ook. :+
Veel fabrikanten zullen alleen drivers schrijven voor de versie die ze gaan gebruiken, dan zullen ze niet iedere 9 maand een nieuwe versie hoeven te maken.
Is dit misschien niet een beetje te hoog gegrepen?
Valt wel mee, denk ik. Zo heel veel security bugs in de Linux kernel worden er niet gevonden, en een patch past waarschijnlijk zonder veel aanpassingen op al die kernels. Als hij niet past, zit die bug waarschijnlijk niet in die versie.
Als je op cvedetail.com kijkt, lijkt het allemaal ernstiger dan het is. 378 issues dit jaar. Maar als je het een beetje doorleest, zitten er daarvan een hele hoop in proprietaire drivers van Qualcomm, gaat het over oude versies, of gaat het over een beperkt versiebereik.
Dit is erg goed nieuws! De huidige generatie mobiele telefoons hebben de hardware en features om makkelijk 3-4 jaar mee te gaan.

Wat ik mij alleen even afvraag is of de verschillende merken (Samsung, Sony, LG etc.) hier ook in mee zullen gaan.

[Reactie gewijzigd door robertjan88 op 3 oktober 2017 09:04]

Waarschijnlijk hebben Samsung etc. nog steeds geen zin om een oud toestel te update, als het alternatief is nieuwe verkopen. Maar het voordeel is in elk geval dat ze zich niet langer achter gebrekkige hardwareondersteuning hoeven te verschuilen als het gaat om security-updates. Nieuwe Androidversies vereisen meestal ook een nieuwe kernel, dus daar veranderd dit (helaas) niets.
ja maar met oreo zijn dergelijke bugfixes toch vendor onafhankelijk gemaakt ?
zodat we voor security niet moeten wachten tot Samsung zin heeft en onze providers daarna ook een willen aan een nieuwe versie werken.
Sony doet iets wat nog veel beter is dan fucking 6 jaar oude kernels supporten, namelijk hun devices in mainline zetten.
Dat heb ik nooit goed begrepen, hoe zit dat met Linux in x86? Is dat ook z’n gedoe om nieuwe drivers te brengen bij nieuwe kernel versies?

Het zal toch beter zijn als die mobieltjes ook Linux kernel updates krijgen? I.p.v. alleen patches. Want hoe gaan ze dat straks met treble doen? Oreo komt in Qualcomm 835 devices met kernel 4.4, straks krijgen die devices P, en Q maar nog steeds met versie 4.4 van de linux kernel...
Nee, op de PC of beter gezegt the IBM clones, hebben ze een standaart, waardoor ze kunnen achterhalen welk devices iets is. Aan de hand van deze identificatie, zijn er programma's die de juiste modules/drivers laden.

Deze standaart, heeft er juist voorgezorgt, dat de IBM clone PC zo groot geworden zijn.
Maar voor de huidige fabrikanten is dit een probleem, omdat als ze zo'n standaart zouden gebruiken, iedereen er dan een O.S. voor kan uitbrengen en de fabrikanten en telco's van deze wereld de controle over deze devices verliezen.
Niet helemaal...

Een fabrikant levert opensource drivers en/of documentatie, zodat drivers werken met de laatste kernel omdat ontwikkelaars bij een aanpassing in de kernel ook die drivers kunnen bijwerken. Er zijn ook fabrikanten die dat niet doen, zoals Nvidia, waarbij een groep ontwikkelaars met reverse engineering probeert te achterhalen hoe zo'n ding aan te sturen.
Verder is er een hele groep hardware met opensource drivers, maar waarbij een stukje binary microcode nodig is. Voorbeeld hiervan is wifi hardware, daarbij draait alles om de microcode.

Wat fabrikanten van telecomplatforms doen is hetzelfde als wat Nvidia doet: een binary driver waarvan niemand weet wat het doet, in combinatie met een kleine hoeveelheid open code die het in de kernel kan laden. De binary module spreekt vervolgens rechtsteeks delen van de kernel aan, en dat is waar de schoen wringt: die veranderen bij elke kernel versie. Nvidia brengt voor elke kernel nieuwe drivers uit, een telecomfabrikant die inmiddels alweer 2 nieuwe chipsets verder is doet dat niet.
6 jaar support en elke 9 maanden een LTS versie? Dat betekend dus dat we 8 kernel versies als LTS gaan bestempelen?

Dat lijkt me dan echt weer slecht... Doe dan ook minder releases...
Is dit dan niet beter voor mobiele platformen (Android) voor betere hardware support?
Dat denk ik niet. Developers worden niet blij van backporten. Dus de 'core' kernel developers gaan wel netjes bugfixes doorvoeren in 8 versies. Maar denk maar niet dat mensen van Qualcomm, Broadcom etc (makers van mobiele chips/chipsets) in alle 8de versies backports gaan bouwen.

Dus je krijgt in je mobieltje vast een LTS versie, en die kan vast security updates van het core linux team krijgen, maar of deze ook netjes updates krijgt hangt ook nog af van makers van drivers / kernel modules.

En ik verwacht daar toch wel wat minder medewerking.
Qualcomm/Broadcom/etc. hoeven niet te backporten, omdat het grootste deel van hun code niet "in-tree" is.

Voor deze 6-jaar support waren er twee opties voor Android vendors:
1) Na 2 jaar een LTS kernel blijven gebruiken maar zonder security updates van core linux devs
2) Na 2 jaar migraten naar een nieuwe LTS kernel - bijv. van 4.4 naar 4.9

Allebei de opties zijn natuurlijk niet ideaal; 2) is veel te veel werk voor de vendors, want juist omdat hun code niet upstream is, is de kans vrij groot dat er bijv een interne API veranderd is, en ze hun code moeten wijzigen.

De ideale situatie zou natuurlijk zijn dat Qualcomm ed hun code wel upstreamen; daar hoort dan ook direct de verplichting bij dat ze backports doen.
Vendors hoeven geen 'backports' te maken. De ondersteuning begint met de eerste release van de kernel nadat de driver/module uitgebracht wordt. Ik kan me niet voorstellen dat drivers/modules volledig herschreven worden tussen kernel LTS releases, dus in dat geval zal er maar een beperkte hoeveelheid code nodig zijn om het met alle verschillende versies van de kernel samen te laten werken. Als het goed is, wordt de kernel niet elke versie volledig omgegooid.
Dat klopt, maar het moet uberhaupt wel 'geprobeerd' worden. De sources zijn vaak niet vrij, en de scripts om tegen meerdere versies aan te compilen worden bij lange na niet altijd vrijgegeven. Er zijn legio voorbeelden van drivers die met minimale aanpassingen best werkend te krijgen waren op specifieke kernel versies, maar omdat er geen ondersteuning vanuit de leverancier was qua scripting bleef het toch lastig.

Dan krijg je dus partijen als Debian die daar nog wel effort in steken dmv custom patches bovenop bepaalde drivers. Maar ik gok niet dat dat gaat gebeuren voor mobiele platformen.
Ik denk eerder dat er maar een LTS zal zijn en er gewoon door ontwikkeld word om non LTS kernels. Security patches en eventuele nieuwe security features worden dan naar de LTS kernel gebackport.
Op dit moment zijn er al heel wat LTS versies. Een aantal daarvan worden onderhouden door distributie maintainers. Ben Hutchings voor Debian, Sasha Levin voor SuSE. Vroeger had elke distributie zijn eigen kernel en moest elke distributie zelf maar gaan kijken welke patches gebackport moeten worden. Er is nu veel meer samenwerking, al was het alleen al vanwege CC's naar de stable kernel teams als iets gebackport moet worden naar een stable kernel.
Is er eigenlijk een Europese wet omtrent updates en ondersteuning van elektronische apparaten? Iets in dezelfde stijl als 2 jaar verplichte garantie op toestellen maar dan gericht op updates voor zaken zoals telefoons, TV's, etc.
Persoonlijk vind ik het raar dat dit nog niet onder de huidige wetgeving valt.

Cybersecurity is zo'n essentieel onderdeel geworden (welke vooral word verbeterd via updates) dat je het als onderdeel van een product zijn functioneren moet kunnen zien.

Waardoor je dus twee jaar fabrieksgarantie zou moeten hebben om deze updates te verkrijgen omdat anders, wellicht, er functionaliteiten wegvallen (malware bescherming is in wezen ook een functionaliteit). Alleen beseft de overheid nog niet hoe erg malware gelijkend aan criminaliteit is.
Ik denk dat dit eigenlijk onder de huidige wetgeving valt, maar nog niemand heeft het geprobeerd dit juridisch af te dwingen. Hier ligt ruimte voor consumentenorganisaties, want voor een individu heeft het geen zin te procederen.
Bij wie ga je aankloppen? Garantie is een overeenkomst tussen koper en verkoper. Ik wil een verkoper wel eens een update zien ontwikkelen voor een toestel.
De meeste verkopers kunnen zelf geen garantie leveren. Het is aan de verkoper om het dan op te nemen met de invoerder/producent of je terug te betalen, en het dan opnieuw op te nemen met de invoerder/producent...

Door het toevoegen van allerhande 'smart' functies gaan dit soort problemen alleen maar toenemen.
Ik zie niet in waarom dit onder de huidige garantie regeling zou vallen. Dat gaat over een functionerend product. Een smartphone blijft gewoon werken, ook zonder software updates.

Een ander probleem is wat dan eventueel onder verplichte updates zou moeten vallen. Alleen critical security patches of complete OS updates? En voor hoelang? Een Samsung kan een paar jaar support makkelijk incalculeren maar een kleine hardware/software fabrikant kan dat misschien niet.

Dat regelgeving wenselijk is daar ben ik het mee eens maar daar moet wel goed over nagedacht worden.
Kritische beveiligingsupdates; twee jaar.

"Werken" is een rekbaar begrip. Je toestel niet meer kunnen gebruiken bij het bankieren, of het risico dat je camera / microfoon ook voor anderen werken maakt een toestel toch onbruikbaar volgens mij.
Hoeveel internet bankieren apps hebben de laatste versie nodig? Mijn HTC M7 kan nogsteeds internet bankieren met android 4.4. Je camera en microfoon openstellen... wat doen al die Facebook en Google apps? Meer een feature ;)

Geloof dat alles met Android 2.3 en hoger zo'n beetje alle apps kan draaien dus functioneel duurt het heel lang voordat je telefoon echt onbruikbaar is.
Ik vraag me af of het niet onder de 2 jaar garantie zou vallen. Als je apparaat door malware onbruikbaar wordt gemaakt wat via een bug in de software binnenkomt, is dat dan een fout in het product en kan je daar garantie op claimen? Ik zou zeggen van wel.
Maar jij koopt in een uitverkoop een apparaat dat 5 jaar geleden op de markt is gekomen voor een prijsje en hebt nog altijd 2 jaar recht op garantie. Maar wie gaat dan de software nog bijwerken voor je gedurende die 2 jaar? De fabrikant heeft het product al lang EOL verklaard.
Dan moet de verkoper dat niet verkopen. Je hebt recht op 2 jaar garantie van de verkoper. Hoe de verkoper dat dan kan waarborgen is niet mijn probleem. In het geval dat een fabrikant niet zelf kan updaten, heb ik dus recht op ontbinding van de koopovereenkomst of een vervangend product.
Jazeker. Als een defect binnen 6 maanden onstaat, dan bestond het defect al tijdens de productie. Verder mag je redelijkerwijs uit gaan van de levensduur van een apparaat. Voor een stuk elektronica is dit ongeveer 2 jaar, dus heb je feitelijk 2 jaar garantie op veel elektronica. Dat is inclusief de software.

Als jouw telefoon ineens geen update meer krijgt voor een bepaald securityprobleem, dan heb je binnen de garantieperiode gewoon recht op reparatie of vervanging.

Daarom is Android zo prettig. Het zit zo vol met problemen, datje gedurende de gebruikersduur van je telefoon steeds een nieuw toestel krijgt omdat Google weigert updates uit te brengen.

[Reactie gewijzigd door Trommelrem op 3 oktober 2017 09:51]

De "levensduur, ongeveer 2 jaar" is een misvatting. Het komt doordat de EU wetgeving volgde op de Nederlandse wetgeving. De oude Nederlandse wetgeving was "redelijke levensduur". De EU richtlijn zei daarna "tenminste 2 jaar op duurzame goederen". Nederland zei daarop weer "je mag sowieso een levensduur van tenminste 2 jaar verwachten, dus onze bestaande wet hoeft niet aangepast te worden".

Voor duurdere goederen mag je meer verwachten. Apple zal zich zorgen moeten gaan maken, maar ook op een Samsung mag je meer garantie verlangen.
Apple geeft echter een duidelijke roadmap over software. In vergelijking met Android is de roadmap van Apple heel royaal. Wist je dat zelfs de antieke iPhone 5S nog in support valt? _/-\o_

De ondersteuning van Apple is veel royaler dan er van wetgeving mag worden verwacht. De ondersteuning van Android voldoet nog steeds niet aan wetgeving.

Bovendien: Als je aan een winkelier vraagt wat de levensduur van een apparaat is, dan is het antwoord bijna altijd 2 jaar. Dus is een wettelijke levensduur van 2 jaar geen misvatting.

[Reactie gewijzigd door Trommelrem op 3 oktober 2017 10:31]

Wat bedoel je met "support"? De iPhone 5S krijgt geen wel iOS 11.

[Reactie gewijzigd door kakanox op 3 oktober 2017 12:44]

De iPhone 5 kreeg geen iOS 11, de 5S wel. Nog erg content mee, hoop op een spec bump van de SE tzt.

[Reactie gewijzigd door :murb: op 3 oktober 2017 12:10]

@MultivlaaiTaart @:murb: Jullie hebben gelijk, ik heb niet goed opgelet.

Spec bump van de SE zou inderdaad mooi zijn. Het is nu nog een ontzettend snel toestel, ook op iOS 11, en ik vind het formaat ook prettiger dan dat van de 8/X.

[Reactie gewijzigd door kakanox op 3 oktober 2017 12:45]

Is het verstandig om elke keer een nieuwe kernel te installeren, of kan je beter bij de versie blijven die met je distro geinstalleerd kwam? Ik ben een nieuwe Linux gebruiker (in mijn geval Peppermint 8 ) en vroeg me dit dus af.

[Reactie gewijzigd door desalniettemin op 3 oktober 2017 12:57]

Ik ben niet erg bekend met Peppermint OS maar ik lees dat het is afgeleid van (L)Ubuntu. Persoonlijk installeer ik op mijn Ubuntu LTS machines wel altijd de laatste kernel. Sowieso kernel updates omdat deze security- en bugfixes bevatten, maar ik stap ook altijd over op nieuwere kernel versies via het Ubuntu Hardware Enablement programma. Zeer waarschijnlijk werken dezelfde commando's ook op Peppermint OS, met de gebruikelijke waarschuwing dat je nooit zomaar commando's moet plakken en uitvoeren in je terminal als je niet begrijpt wat ze doen.
Okť bedankt. En het is inderdaad gebaseerd op Ubuntu. Ik heb namelijk ergens gelezen dat het installeren van de nieuwste kernel niet altijd verstandig is, omdat dan een bepaal programma niet meer goed werkt.

[Reactie gewijzigd door desalniettemin op 3 oktober 2017 15:36]

Ik heb namelijk ergens gelezen dat het installeren van de nieuwste kernel niet altijd verstandig is, omdat dan een bepaal programma niet meer goed werkt.
Ik weet niet waar je dat gelezen hebt, maar het is niet waar. De Linux kernel developers zorgen er juist al jaren voor dat de zogenaamde "kernel to userspace interface", met andere worden de manier waarop reguliere software met de rest van het systeem communiceert, zeer stabiel is en niet verandert. De software die je gebruikt zou dus op iedere versie van de Linux kernel moeten blijven werken.

https://unix.stackexchang...ernel-breaking-user-space
Zoals gezegd ik ben helemaal nieuw met Linux en heb wat zitten zoeken op internet over Ubuntu, omdat Peppermint gebaseerd is op Ubuntu en zodoende kwam ik deze website tegen:

https://sites.google.com/site/computertip/

En daar las ik onder andere dit:

Wilt u Ubuntu vastzetten op een bepaalde systeemkernversie (kernel), bijvoorbeeld om mogelijke complicaties door een toekomstige bijgewerkte systeemkern te vermijden?

Dat kan handig zijn, bijvoorbeeld als u een bepaald stuurprogramma handmatig hebt geÔnstalleerd, wat onbruikbaar zou worden in een nieuwe systeemkern.
Ah okť, dan gaat het ineens niet meer om gebruikerssoftware maar om handmatig geÔnstalleerde stuurprogramma's en dat is andere koek. Zoals @Just3 al in een eerdere reactie hier aan gaf is de kernel interface van Linux niet stabiel, dat wil zeggen dat deze wel zomaar eens kan veranderen als het een bug oplost of voor andere verbeteringen zorgt, al proberen ze dat natuurlijk te voorkomen. Gelukkig zitten de meeste stuurprogramma's voor consumentenhardware tegenwoordig in de Linux kernel ingebakken en zou je hier dus geen last van moeten hebben. Een uitzondering kan het binaire, gesloten stuurprogramma van je videokaart van ATI of NVidia zijn, maar ook die werken tegenwoordig eigenlijk altijd prima met nieuwere kernels, zeker omdat Ubuntu niet de allernieuwste kernels gebruikt zelfs niet voor hun Hardware Enablement programma.
Bedankt. Weer wat geleerd ;)


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*