'Mainframes en telefoons lijken best op elkaar'
21 april 2008
De eisen voor grote datacentra en kleine mobieltjes groeien naar elkaar toe, denkt Linux-kerneltopman Alan Cox. Hij was laatst in Nederland voor een lezing in Sioux’ Hot-or-not-serie. Tijdens een interview vertelt hij over de laatste ontwikkelingen in realtime, doet hij het kernelontwikkelproces uit de doeken en fulmineert hij tegen DRM en softwarepatenten.
‘Het is niet echt mijn expertisegebied’, tempert Alan Cox direct als we onze bedoelingen aan hem kenbaar maken; praten over Linux in de embedded wereld. Maar hij heeft als een van de hoofdontwikkelaars van de Linux-kernel toch zeker wel een goed overzicht van de ontwikkelingen? Ja, dat wel, beaamt hij. En dus kan hij er toch wel wat zinnigs over zeggen.
Sterker nog, Cox doet een opmerkelijke observatie: juist de vereisten voor de grote datacentra met honderden servers en die voor kleine apparaten zoals mobieltjes vertonen grote overeenkomsten en kruipen zelf steeds meer naar elkaar toe. Op de wensen voor geheugen en energieverbruik liggen deze uiterste toepassingsgebieden dicht tegen elkaar aan.
Vooral de virtualisatierevolutie van de laatste jaren helpt een handje. Servers zijn vaak toegerust op een enkele taak, vooral bij instellingen als banken, waar beveiliging een grote rol speelt. Daardoor bleef veel capaciteit onbenut. Door nu meerdere virtuele servers op een enkele machine in te richten, moeten ze weer werken voor hun geld. Dit betekent echter ook dat geheugengebruik weer belangrijk wordt. De ingesleten gedachte dat geheugen goedkoop en ruim beschikbaar is, is aan revisie toe als vele kopieën van het OS naast elkaar draaien.
Dat gaat ook op voor energiegebruik. Processoren die op maximale belasting draaien, warmen de toch al op heteluchtovens lijkende processorruimtes nog verder op. Bovendien wordt iedereen zich steeds meer bewust van het andere grote opwarmingsprobleem; dat van de aarde. En bovendien wordt energie er niet goedkoper op. Ook kijken de serveradepten steeds meer naar realtime. Bijvoorbeeld voor financiële instellingen is een voorspelbare reactie nodig. Dus geheugen, energie en realtime, drie met uitstek belangrijke gebieden voor embedded, staan weer op de agenda.
Vaak geldt dezelfde oplossing voor de verschillende gebieden. ‘Zoals voor het terugdringen van geheugengebruik en dingen als het beheer van timers’, vertelt Cox. ‘Andere keren deel je slechts een gedeelte van de oplossing, zoals het faciliteren van efficiënt energiegebruik. Alleen het basismodel daarvan is hetzelfde voor de verschillende toepassingen. Maar de implementatie is verschillend. In de pc-wereld moet je de implementatie aan specifieke processorkernfeatures en aan ACPI-firmware verbinden. In embedded gebruik je dan niet dezelfde device layer en volgorde.’
Dat embedded mee kan liften op het werk voor zijn grote broers, komt goed van pas. Vanuit de embedded-hoek klinkt vaak het bezwaar dat Linux zich voornamelijk focust op big iron. Volgens Cox behoeft dit beeld nuancering. ‘Er is geen eenzijdige focus, want je hebt verschillende groepen die aan verschillende projecten en systemen werken. Zij trekken de kernel dus in verschillende richtingen.’ Maar de input vanuit de embedded-hoek blijft wel achter, vindt hij. ‘Het is zeker een belangrijk groeigebied. Een groot aantal producten gebruikt embedded Linux. Maar dat komt op het moment waarschijnlijk niet zo duidelijk terug in de ontwikkeling van de kernel. Embedded-werk bestaat veelal uit om kleine afsplitsingen van de Linux-kernel, die allemaal weer afsterven. Veel van het werk wordt steeds overgedaan. Meestal zijn het de bedrijven die de uiteindelijke apparaten ontwikkelen die de device drivers schrijven. Terwijl andere bedrijven vergelijkbare hardware gebruiken.’ Ook is de hardware minder uniform in de embedded-wereld. ‘In de pc-wereld heb je een platform dat je begrijpt. Dat betekent dat code die in het ene project werkt, ook in het andere project werkt. Als je dat in embedded wil, heb je een goede set standaarden nodig. Gestandaardiseerde firmwaretabellen, geheugenlay-outs, dat soort dingen. Dat zou ieders kosten uiteindelijk verlagen’, filosofeert Cox.
Een andere factor ten slotte is dat embedded-ontwikkelaars niet altijd bovenop de nieuwst ontwikkelingen duiken. ‘Een probleem is dat ze geneigd zijn om met oudere Linux-versies te werken. In embedded wil je vaak betrouwbare code die niet te vaak verandert. Er is dus een beetje een cultuurbotsing.’
Vergaarbak
Cox – met zijn lange haar, baard en T-shirt van zijn werkgever Red Hat bijna een Dilbert-achtige karikatuur van de klassieke Unix-goeroe - is wat wel eens omschreven wordt als een van Linus Torvalds luitenanten. De Finse programmeur bepaalt de uiteindelijke koers van de Linux-kernel, maar hij kan niet meer elk stukje code apart beoordelen. Daarvoor is het project te complex geworden. Vertrouwelingen nemen daarom delen voor hem waar. De meeste insiders plaatsen Cox op de derde positie na Torvalds en Andrew Morton.
Cox’ belangrijkste claim to fame is de -ac-lijn. Enkele jaren terug was de kernel die Torvalds uitbracht niet altijd de meest stabiele. Torvalds richtte zich op nieuwe features en het duurde vaak tot de volgende release voordat bugfixes werden doorgevoerd. De lijn van Alan Cox had deze wel en Linux-distributeurs baseerden hun producten vaak hierop.
'Voor de gevallen waarbij je een machine de muur in boort als je een deadline van honderd milliseconden mist, speelt Linux niet echt mee'
Heden ten dage is de situatie min of meer omgekeerd; de hoofdkernel is stabiel, de experimentele onderdelen zitten in -am - de lijn van Andrew Morton. Cox legt uit hoe de ontwikkeling van een kernel-versie in zijn werk gaat: ‘Op dit moment is onze aanpak om regelmatig nieuwe kernel-versies uit te brengen. Linus Torvalds onderhoudt de hoofdlijn. Geaccepteerde dingen worden daarin opgenomen. Veel wordt echter gedurende lange tijd buiten die lijn ontwikkeld. Voor elke versie komt Linus met een stel release candidates. Er is een tijdvenster waarin alle grote veranderingen worden doorgevoerd, en als dat gebeurd is, krijg je release candidate 1. Daar spelen mensen een tijdje mee en er zullen ongetwijfeld regressies zijn en dingen waar niemand aan gedacht had. Dat leidt tot release candidate 2, 3 en op een gegeven denken we dat het goed genoeg is en brengen we het uit. En dan beginnen we opnieuw.’
Omdat iedereen met zijn eigen agenda aan de kernel werkt, is het de taak van de kernelbeheerders om het grote geheel in de gaten te blijven houden. ‘Een van de manieren waarop je realiseert dat je een gezamenlijk probleem hebt, is doordat verschillende mensen verschillende oplossingen voor hetzelfde probleem aandragen. Ik denk dat de meeste bijdragers niet naar het grote geheel kijken. Meestal gaat het alleen om het oplossen van het probleem dat hun werkgever heeft. Doordat mensen uit verschillende hoeken zeggen ‘je kunt het niet op die manier oplossen’, krijg je uiteindelijk een gezamenlijke oplossing.’
‘Het kan bijvoorbeeld gebeuren dat iemand een wijziging inbrengt die het systeem beter laat draaien op een grote mainframemachine, maar dat iemand in de embedded-wereld vervolgens zegt dat zijn platform niet langer opstart of dat het systeem plotseling op halve snelheid draait. Normaal gesproken vinden we dan wel een manier die het niet erger maakt voor de rest - soms wordt het een configuratieoptie, als de feature niet op een nette manier te implementeren is. Bijvoorbeeld bij sommige geheugenallocaties die snelheid tegen efficiëntie inruilen.’
Cox zelf houdt zich nu voornamelijk bezig met onderhoud. ‘Ik beheerde een stabiele lijn, maar ik zit niet meer in de positie dat dat nodig is’, legt Cox uit. ‘Het meeste van wat ik nu doe, is onderhoud. Dingen repareren die moeten worden gerepareerd, in plaats van nieuwe toevoegingen. Op het moment verricht ik veel werk aan harddiskdrivers. En ik werk aan de seriële drivers, want die code is al lang niet meer aangeraakt. Af en toe vind ik nog wel eens een bug in een ander onderdeel, die los ik dan wel op en daar stuur ik dan een patch voor in.’ En hij is regelmatig op de mailinglijst te vinden. ‘Soms lijkt het dat ik de vergaarbak ben van kennis over hoe al de oude, antieke, gemene hardware werkt’, lacht Cox.
Dat alles doet hij in de baas zijn tijd. Cox staat op de loonlijst van Linux-distributeur Red Hat, dat de infrastructuur levert voor grote bedrijven. ‘Een van de grote voordelen van werken voor een bedrijf als Red Hat is dat je een goed idee krijgt van je klanten wat er nodig is. Dus meestal heb je niet iemand die zegt wat je moet doen, het is overduidelijk wat er moet gebeuren.’
Ecos
De afgelopen jaren heeft het Linux-gebruik een hoge vlucht genomen. Vooral de serverbedrijven ontdekten het OS als een krachtige en goedkope bron. Ook embedded-ontwikkelaars kiezen steeds vaker voor het vrije besturingssysteem. Uit een recente inventarisatie van marktonderzoeker Venture Development Corporation blijkt dat maar liefst 87 procent van de embedded-ontwikkelaars overweegt om Linux te gebruiken in het volgende project, waarvan ruim vier vijfde denkt aan een niet-commerciële distributie.
Hoe verklaart Cox dit succes? ‘Een gedeelte is kosten en efficiëntie. Er zijn geen licentiekosten per gebruiker, het is makkelijk aan te passen en er zijn veel anderen die het gebruiken. Dat laatste heeft verschillende voordelen. Het is makkelijker om mensen te vinden die Linux kennen, maar ik denk dat het ook wordt gezien vanuit een sociaal oogpunt. Bovendien is het acceptabel om Linux te gebruiken, je doet niet iets afwijkends. Klanten voelen zich er ook niet door bedreigd.’
Dat is wel eens anders geweest. ‘Als je een tijdje terug zei dat je Linux ging gebruiken in een project, dan zei de klant vaak: ‘O, Linux, was dat niet iets met een enge licentie en gebruiken anderen dat wel?’ Maar tegenwoordig reageren ze met: ‘O natuurlijk, waarom zou je geen Linux gebruiken?’ De gebruikers snappen nu ook de juridische overwegingen beter.’ Maar, zo moet Cox toegeven, hype zal hier en daar ook wel een rol spelen. ‘Er zijn zeker ook gevallen waarbij ik niet echt begrijp dat mensen Linux kiezen. Linux is bijvoorbeeld zeker niet de beste keus voor zeer kleine systemen. Het is niet klein in vergelijking met de meeste RTos’en. En er zijn wel degelijk vrije embedded RTos’en beschikbaar, zoals Ecos.’
'Software is op de een of andere manier terechtgekomen in deze puinhoop waar zowel copyright als patenten gelden'
‘Als je kijkt naar de grootte van de kernel dan zie je dat die op een neer gaat over tijd. Wanneer je steeds dingen toevoegt wordt het steeds groter. Tot op een gegeven moment gaat iemand zich afvragen waarom het zoveel groter wordt. Soms moeten we gewoon dingen verfijnen, zoals het gebruik van inline functies en het opschonen van datastructuren. Vaak zijn er wel opschoningen bezig, soms met een grote impact. Maar er zijn een hoop mensen die simpelweg niks om de grootte geven en andere groepen voor wie het zeer belangrijk is.
Ook de boottijden zijn een pijnpunt. ‘Dat is een belangrijk gebied voor de embedded-mensen. Neem de Nokia-handhelds. Het duurt lang om ze fysiek aan te zetten of uit te schakelen, volgens mij ergens tussen de vijftien en twintig seconden.’ Dit is een probleem dat ook nog wel even zal blijven bestaan. ‘Het is een combinatie van kernel en user space. Het bestandssysteem dat we momenteel gebruiken voor flash bijvoorbeeld is journalled. Dat is erg robuust, maar het betekent ook dat het erg lang duurt voordat het is geïnitialiseerd en aan de slag kan. Een van de problemen bij het terugdringen van de boottijden is dat als je alle voor de hand liggende oorzaken hebt geëlimineerd, er niet een enkel punt overblijft waarop je kan verbeteren. Het is een botsing van piepkleine onderdelen die allemaal individueel opgelost moeten worden. Er is geen quick fix.’
Boterzacht
Cox denkt dat Linux dan ook slechts gedeeltelijk een hap neemt uit de RTos-markt. ‘Een voordeel dat de traditionele RTos’en hebben, is dat ze extreem klein zijn, waardoor ze vaak verifieerbaar zijn. Linux is een groot en complex stuk software. De gereedschappen, de technologie en de software-engineeringvaardigheden voor dit soort serieuze validatie bestaan niet op deze planeet.’
Een ander belangrijk punt voor embedded toepassingen is realtime. Op dat punt maakt Linux stormachtige ontwikkelingen door. Traditioneel waren de realtimecapaciteiten van Linux boterzacht. Het fatsoenlijk implementeren ervan was echter een grote wijziging, die niet goed past in het evolutionaire ontwikkelmodel van Linux. Toch is Linux nu door de zure appel heen. ‘Als we het willen hebben over realtime in de kernel moeten we naar de allerlaatste ontwikkelversie kijken. Het basiswerk is klaar, zoals het vervangen van de meeste semaforen door mutexen. Die wijzigingen zijn nu geaccepteerd in de hoofdkernel. Dan is er een set patches die daar bovenop komen, die de realtime thread implementeren. Dat zijn eigenlijk hele mooie patches, ze veranderen geen code verspreid over de hele kernel. Dus hopelijk worden ze opgenomen in de komende versies.’ Het resultaat moet de kernel echt realtime maken, alhoewel Linux niet zal kunnen tippen aan de traditionele RTos’en. ‘We hebben geen keiharde realtime, behalve via bijvoorbeeld RTLinux. Linux is prima voor het soort realtime waarvan je zegt: ‘Tijden in de honderd milliseconde zijn oké en zolang het niet blokkeert of faalt zijn we tevreden.’ Voor de gevallen waarbij je een machine de muur in boort als je een deadline van honderd milliseconden mist, speelt Linux niet echt mee.’ Daarvoor is er altijd nog RTLinux, waarbij Linux als applicatie draait op een hypervisor, naast de realtime applicaties. ‘Maar als Linux je realtime systeem is, heeft dat als voordeel dat al je software realtime kan zijn. Dat speelt voornamelijk een rol in de serverwereld. Daar zijn ze niet geïnteresseerd in het realtime gedrag van een klein stukje, maar van grote, complexe applicaties zoals webservers.’
Godzijdank
Ondanks dat het buiten grauw en grijs is op de dag dat we hem spreken, hoeft Alan Cox geen jas aan als we naar buiten gaan voor de fotosessie. ‘Het is hier in Nederland lekker droog’, grapt de Linux-goeroe, die het weer in zuid-Wales gewend is. Daar sleutelt hij vanuit huis aan de Linux-kernel. Is iemand die zo gepassioneerd is over Linux eigenlijk ooit klaar met werken? ‘Soms werk ik in mijn vrije tijd wel aan Linux, maar ik ben eigenlijk meer bezig met softwarevrijheid, zoals politieke zaken, lobbyen, werk met actiegroepen, dan direct software schrijven.’ Cox is in dat opzicht een onvervalste idealist. Van softwarepatenten moet hij niks hebben en een sticker tegen digitaal rechtenbeheer (DRM), zoals kopieerbeveiliging op digitale muziek, siert zijn laptop. ‘Het probleem is dat je de wet en al zijn uitzonderingen niet kan implementeren in software. Bij DRM heb ik grote moeite met toegang voor gehandicapten. Vanwege de Europese copyrightwetgeving kunnen we geen dvd-spelers ontwikkelen die cryptografische sleutels gebruiken, ondanks dat iedereen weet hoe het werkt. We kunnen in de vrije-softwarewereld geen software uitbrengen die bijvoorbeeld flitsen wegfiltert voor mensen die daar problemen mee hebben, we kunnen geen ondertiteling verzorgen gericht op dyslectische mensen. Er zijn allerlei mogelijkheden die waardevol zijn voor mensen met een handicap. Dus is het in feite verboden om gehandicapten te helpen, en dat vind ik beledigend. In essentie neemt DRM hun vrijheid weg.’
‘We hebben ook geen enkel geval gezien waar digitaal rechtenbeheer het probleem oplost dat het claimt op te lossen. DRM is altijd gekraakt. Dat hoeft maar een persoon te doen en het hele systeem is kapot. Een van de voorspelde effecten van DRM was ook dat de muziekindustrie de controle zou verliezen. En we zien nu dat Apple de prijzen van muziek bepaalt. Dat was precies hetgeen dat Google’s topeconoom Hal Varian voorspelde. DRM heeft vele nadelen, het bemoeilijkt archivering, het bemoeilijkt het toekomstige gebruik. Allerlei cultuur zal verloren gaan.’
Ook over patenten op software heeft Cox geen goed woord over. ‘Software is een creatief werk, daarom krijg je een copyright. Traditioneel heb je de engineeringtoepassingen, waarop je geen copyright kan krijgen maar wel een patent, en software en letterkundige werken zoals boeken, waarvoor het omgekeerde geldt. Software is op de een of andere manier terechtgekomen in deze puinhoop waar alles geldt. Zelfs de copyrights op software zijn vreemd. Met boeken kun je geen patent krijgen op bijvoorbeeld een bepaalde stijl. En met een copyright krijgen de mensen die het boek ontvangen feitelijk ook de broncode. Je kunt zien hoe het boek geschreven is, hoe het werkt, je kunt leren, je kunt de literatuur bestuderen. Copyrights op software zijn juist bedoeld om je daarvan te weerhouden.’
‘Het patenteren van software is zoals het patenteren van wiskunde, boeken, toneelstukken, muziek. Neem bijvoorbeeld MP3-encoding, dat is een complexe wiskundige bewerking. Zoals de situatie nu is, kun je geen patent krijgen op het uitvoeren ervan met pen en papier. Als je de bewerking op een computer doet in de VS, dan overtreed je softwarepatenten. In Europa waarschijnlijk niet, maar de hele softwarepatentkwestie hier is nog steeds een rotzooitje dat een keer goed opgeruimd moet worden. Ik ben nog nooit een advocaat tegengekomen die me kan uitleggen waarom de twee situaties zouden moeten verschillen. En dan nog, als ik nu een rekenmachine gebruik om me te helpen met de berekeningen, wanneer schaad ik dan het patent?’
‘Al het economische bewijs, alle studies die wereldwijd zijn uitgevoerd, wijzen erop dat softwarepatenten innovatie hinderen. In studies van andere toepassingsgebieden lijkt het erop dat patenten innovatie en vooruitgang bevorderen en voorkomen dat geheimen achter slot en grendel verdwijnen. Patenten op software veroorzaken schade en zouden niet moeten bestaan.’
‘Hier in Europa is de situatie tegenwoordig wat beter, de leden van het Europese parlement weten meer van softwarepatenten af dan dat het geval was - en ze eigenlijk zouden willen. Ze beginnen in te zien dat het alleen maar monopolieposities en problemen creëert. Vroeger zeiden we in Europa: ‘We hebben geen goed softwarebeleid en daardoor hebben we ook geen bedrijven als Microsoft. Tegenwoordig zeggen veel parlementsleden: ‘We hebben geen softwarebeleid, godzijdank hebben we geen bedrijven als Microsoft.’ We zien steeds meer dat Europa het voortouw neemt, in zaken variërend van milieubeleid tot intellectueel eigendom.’
Apple
Toch heeft Cox’ werkgever, die hij toch hoog in het vaandel heeft staan, een patentportfolio. Gericht op software. ‘Het probleem met patenten in de VS is dat het een beetje vergelijkbaar is met een nucleaire wapenwedloop’, legt Cox deze ogenschijnlijke discrepantie uit. ‘Het is een erg goed idee om kernwapens te hebben, want als iedereen ze heeft vuurt niemand ze af. Maar als ze dat wel doen, moet je terug kunnen slaan. Vanuit Red Hat is er de belofte dat als je bijvoorbeeld software ontwikkelt onder de GPL-licentie, je automatisch rechten krijgt voor het gebruik van deze patenten. We willen niet dat Red Hat de ontwikkeling van vrije software in de war schopt.’ Dit soort beloften zijn niet geheel ongebruikelijk en ook niet geheel zonder controverse in de wereld van de vrije software. IBM, Nokia en Sun bijvoorbeeld hebben een gedeelte van hun portfolio opengesteld.
Het moge duidelijk zijn, voor Alan Cox is vrijheid in software een van zijn grootste drijfveren. Bij veel embedded toepassingen is het echter helemaal niet de bedoeling dat gebruikers de boel zelf in de hand hebben. Stoort het hem niet dat je bijvoorbeeld een Linux-telefoon vaak niet kunt hacken? ‘O, ik kan hem wel degelijk hacken’, lacht Cox. ‘Maar het zit sommige mensen inderdaad dwars’, vervolgt hij op serieuzere toon. ‘Bij veel apparaten heb je echter over het algemeen geen reden tot hacken. Ik heb thuis apparaten die Linux draaien, zoals een DSL-router. Ja, daar kan ik de software voor downloaden, maar ik heb niet echt een reden om dat te doen. En ik zou JTag-borden enzo nodig hebben om het te herprogrammeren. Dus zolang ze de broncode openbaar maken en ik vrij ben om dat op andere hardware te gebruiken, zit dat me niet echt dwars.’
‘Het geval van telefoons is echter listig, want dat is een gebied waar gebruikersconfiguratie, -beheer en software de toepassing maken. Je kunt niet een telefoon en een PDA combineren en dan vervolgens alle PDA-capaciteiten weglaten. Het succes van Palm is bijvoorbeeld gebaseerd op de mogelijkheid om software toe te voegen. Hetzelfde zal waar zijn voor het succes van een Linux-telefoon. Maar ik denk dat het zichzelf zal oplossen. We hebben het ook gezien met de Iphone. Apple heeft de slag hierin verloren door nu software van derde partijen toe te laten.’
‘Wat me wel dwars zit, is als mensen de broncode niet openbaar maken. Want als het apparaat niet echt hackbaar is, kunnen er in die broncode wel dingen zitten die waardevol zijn voor andere mensen met andere apparatuur. De meeste overtredingen van de licentievoorwaarden in Europa zijn ook per ongeluk, bijvoorbeeld als Linux gebruikt wordt door de partij die het systeem ontwikkelt voor een klant.’
Slimme mensen
Cox kwam oorspronkelijk met Linux in aanraking toen hij het Abermud-computerspel schreef en een systeem zocht waar dat op kon draaien. ‘Het werkte, dus ik bleef het gebruiken. Toen ging ik steeds meer bugs fixen.’ Langzaam begon Cox de mensen te kennen en de politieke kant van het verhaal te zien. Hij ziet een aantal voordelen aan zijn Linux-werk. ‘Je kan met bijzonder slimme mensen werken. Dat is erg prettig, want zo blijf je altijd wat bijleren. Verder heb je de macht om dingen te veranderen. Bovendien verandert hetgeen wat je doet regelmatig, je bent niet altijd met hetzelfde bezig. En je hebt de macht om de wereld te veranderen. Je bent bijvoorbeeld in een positie dat je software in de derde wereld kan verspreiden. Wanneer ik ermee stop? Geen idee. Waarschijnlijk als ze me in een kistje stoppen.’
Op 5 maart sprak Alan Cox in Eindhoven tijdens de Hot-or-not-lezingencyclus van Sioux Embedded Systems, waarmee het bedrijf de embedded-gemeenschap bewust wil maken van nieuwe ontwikkelingen in het vakgebied. In 2008 gaat de cyclus verder met goeroepresentaties van Joe Armstrong over Functioneel Programmeren (8 mei) en Alistair Cockburn over het Agile Manifesto (29 juni). Meer informatie is te vinden op: www.jouwontwikkelingtelt.nl.
Pieter Edelman
Terug naar overzicht