Af Torben Okholm, Alt om Data
Denne artikel er oprindeligt bragt på Alt om Data. Computerworld overtog i november 2022 Alt om Data. Du kan læse mere om overtagelsen her.
Stationære Linux-pc’er er i mindretal. Det er svært at angive et præcist tal, men de fleste vurderinger anslår brugen til at ligge på under 3 procent. Linux-brug på Steam synes at være omkring 1 procent. Og det er i orden, for der er ikke nogen bydende grund til, at Linux skulle ligge højt på disse skalaer. Dets fortsatte eksistens er ikke truet, blot fordi folk sært nok stadig kører Microsoft Office, så de kan udfylde deres TYPS-rapporter korrekt. Men en del brugere nyder faktisk at høre til mindretallet, og nogle af dem ynder endda at se ned på de brede desktopmasser.
Linux på stationære pc’er var imidlertid kun en bivirkning af Linux’ mageløse vækst på andre områder. Til servere og supercomputere passer Linux’ driftssikkerhed, tilpasningsevne og mangel på pris perfekt, og her har systemet været dominerende siden slutningen af 1990’erne. Hertil kommer to milliarder Android-smartphones. Men Linux fylder endnu mere end som så. Hvis man ser grundigt efter, vil man finde Linux indlejret alle mulige steder: fra hjemme-
routere, smart-tv’er og Blu-ray-afspillere til elektroniske signaturer, bilcomputere og industrielle kontrolsystemer. Eftersom Linux kan findes i så mange forskellige cpu-arkitekturer, er systemet attraktivt for mange producenter.
Alternativet til at bruge Linux er at udvikle (og vedligeholde) et skræddersyet styresystem. I bedste fald svarer det til at genopfinde hjulet, og i værste fald er det kostbart, risikabelt og tidskrævende.
Linux over det hele
Linux er i førersædet lige fra routere over mp3-afspillere til printere. Læs her, hvordan det fandt sted, og hvorfor man bruger Linux
Når så mange producenter vælger Linux, er det ikke overraskende, at der eksisterer en række specielle distributioner (distroer), der sigter på det indlejrede marked. Du har måske hørt om DD-WRT og OpenWRT, som man kan installere på et imponerende antal forskellige routere. På den måde kan man give brugerne et kønnere interface og ekstra funktioner, men vigtigst af alt lindre den situation, der består i, at producenter sjusker med sikkerhedsopdateringer. DD-WRT blev født som et resultat af, at Linksys brugte tilpassede Linux-drivere og komponenter i sin WRT54G-routerserie uden at frigive nogen kildekode, sådan som det ellers kræves af GPL’en (General Public License).
Efter nogle krasse e-mails bøjede Linksys sig og frigav koden. Det blev først grebet af Sveasoft, der lancerede sin skræddersyede firmware under navnene Alchemy og Talisman. Da Sveasoft besluttede sig for at kræve penge for “community support”, greb DD-WRT (www.dd-wrt.com) den seneste version og har foræret den væk lige siden.
Bortset fra routere findes der et andet vellykket projekt, nemlig Rockbox (http://rockbox.org), der lægger Linux på ens mp3-afspiller. Man kan få firmware til en imponerende række af enheder: fra dyre iPods til Sandisks billige og festlige Sansa-serie. Det giver flere funktioner i form af øget og mere driftssikker support til filformater, forbedret ydelse, support til Unicode plus muligheden for at spille Doom (se tekstboksen ”Den kører Doom”). Rockbox blev introduceret i 2002 ved en omarbejdelse af den fejlbehæftede firmware til Archos Player. Installation på alle enheder omfatter en udskiftning af bootloaderen. Når det er gjort – og det kan være lidt akavet, fordi Apple-produkter kræver et signeret image – kan man installere Rockbox-operativsystemet på enhedens lager, og det er derfor nemt at foretage opdateringer og tilføje ekstraudstyr.
Det ikoniske Linksys WRT54G indledte bølgen af hjemmelavet firmware i 2003.Yocto-projektet (www.yoctoproject.org) har til formål at forenkle processen bag det at lægge Linux på indlejrede enheder. Yocto er ikke i sig selv en distro. Den sigter snarere på at strømline processen bag fremstilling af distroer til en bestemt enhed. En af Yoctos nøglekomponenter er byggeredskabet BitBake. Den er inspireret af Gentoos pakkemanager, Portage, og bygger skræddersyede images fra kilden ved hjælp af Tasty Recipes. Nu inddrager Yocto det OpenEmbedded-byggesystem, der selv var baseret på en teknologi ved navn Buildroot, og som stadig bliver aktivt udviklet. Buildroot er prækonfigureret til hyldevarer såsom Raspberry Pi, og teknologien skal bruges med OpenWRT.
Et andet projekt, der er udgået fra OpenEmbedded (og andre) er Angstrom Distribution, der har til formål at være alsidig og brugervenlig. Hvis der er behov for at få plads til den på 4 MB flashlager, kan det lade sig gøre. Hvis der er brug for at bruge den som en mere komplet distro, kan den også klare det. Den er godt understøttet på enkeltkort-computere, herunder Intels stærke MinnowBoard.
Centralt i Linux ligger GNU C Library (glibc). Stort set enhver pakke på computeren er afhængig af det, idet det indeholder alle de low level-sager, som kompileret kode af typen C/C++ er afhængig af. Resultatet er, at det er noget af et skrummel og ikke egnet til indlejret computerarbejde. Der findes imidlertid nogle slankede glibc-udgaver (herunder dietlibc), som er beregnet til indlejrede miljøer. En af de mest udbredte er uclibc, der ikke engang kræver en hukommelsesmanager, og som derfor kan porteres til alle mulige former for svagstrømsenheder, navnlig microcontrollere. Uclibc er ikke blevet opdateret siden 2012, men dets spinoff-projekt, uclibc-ng, er under aktiv udvikling. Android bruger det Google-udviklede Bionic C-bibliotek, der sigter på mindre og knap så stærkt maskineri. En anden hovedårsag til dets udvikling er at isolere de specielle dele af Androids økosystem fra copyleft-problemer, som kan udspringe af brugen af Linux-kernen. Bionic er BSD-licenseret, og derfor er afledte produkter, som i kraft af en lidt tyndbenet argumentation omfatter Android-apps, der er bygget op mod det, ikke forpligtede til at levere kildekode.
Den kører Doom
PrBoom er en af de få kildeporte til Doom (hvis kildekode blev frigivet i 1997), som er tilgængelig for Windows, Linux og mange andre platforme. Den er langt mere effektiv og tilpasnings-dygtig end originalen, og den bevarer stadig kompatibilitet med de oprindelige WAD-filer (således at man kan bruge niveauer og grafik fra originalen). Nu, da Linux kører så mange uortodokse steder, går der sport i at få PrBoom over på disse enheder såvel.
Et af vores yndlingseksempler var, da Michael Jordon fik den til at køre via LCD-skærmen på en Canon Pixma-printer. Det var en sikkerhedsbrist i firmwarens opdateringsmekanisme, der gjorde denne overdådige hacking mulig.
(http://bit.ly/PixmaDoomed).
Bortset fra det kører der forskellige aftapninger af Doom på RockBox (selvom det ser ret underligt ud i monokrom), grafiske regnemaskiner, digitalkameraer for ikke at tale om et oscilloskop (men det kørte på Windows 95, og den slags kan vi virkelig ikke gå ind for.)
Skat, jeg har skrumpet Linux
Indlejret Linux er stadig Linux, men i praksis er det et andet dyr, der boltrer sig på dit skrivebord. Lad os se, hvordan vi kommer fra det ene til det andet
Blot fordi der er så mange Linux-enheder i omløb, betyder det ikke, at man kan tilslutte tastatur, netkabel og skærm og begynde at tampe Bash-kommandoer ind. For det første er der intet sted at tilslutte dette udstyr, for det andet drejer indlejret sig først og fremmest om minimalisme, og der er derfor måske ingen support til PS/2-tastaturer, framebuffere eller networking-stakke i kernen.
Hardwarens kaliber kan også være meget forskellig fra en typisk desktop-pc med flere kerner. De fleste indlejrede enheder bygger på arkitekturerne ARM eller MIPS, og de rummer gerne nøjagtig den minimale mængde ram, de skal bruge for at fungere. Lagerkapaciteten kan også være stærkt begrænset. Således har mange hjemmeroutere mindre end 2 MB nvram, og håbefulde OpenWRT-brugere er sommetider nødt til at bruge et specielt minimeret image. Kan du huske, at MS-DOS 5 blev leveret på tre disketter? Det viser sig, at man stadig kan få plads til styresystemer på meget beskeden plads, blot “styre”-delen, som man forventer af “systemet” er snævert defineret. Vi prøver med en hurtig tankeøvelse at se, hvor meget vi kan slanke Linux.
Vi begynder med en generisk gui-fri Linux-installation: Det kan være Arch, Debian eller OpenELEC – det betyder ingenting, for de har alle et installeret fodaftryk på mindre end 1 GB. Formålet er at se, hvor meget vi kan slippe afsted med at fjerne, før det hele bryder sammen. Hvis vi begynder med de lavthængende frugter, kan vi skille os af med alle unødvendige pakker. Mange læsere er blevet fristet til at prøve det på deres maskiner, men resultaterne (navnlig på Ubuntu) peger gennemgående i to retning: For det første bryder alt sammen, og for det andet begynder pakkemanageren at anbefale geninstallation af alt det, der er blevet fjernet, plus installation af alt muligt andet. Disse to reaktioner udelukker ikke hinanden.
Men det indebærer ikke, at fremgangsmåden ikke kan være sund; det betyder blot, at desktoppakker rummer komplicerede afhængighedsskabende elementer, og man står sig ved ikke at udfordre dem. Det, vi kan fjerne, afhænger af, hvad vi havde til at begynde med, og hvad vi har brug for. Vi beslutter os måske for, at vi ikke har brug for alle de eksotiske redskaber til eksotiske filsystemer, raid og logisk drevstyring. Hvis vi erindrer, at alt dette er hypotetisk, kan vi fortsætte ad dette spor. Mange distroer omfatter både Perl og Python, og vi kan undvære dem begge. Vi kan måske spare nogle få hundrede megabytes, og selvom vi gladeligt kunne fortsætte denne øvelse i pakkefjernelse, ender vi med et ringere resultat. Derfor ændrer vi nu taktik og indfører ændringer, som pakkemanageren ikke vil bryde sig om.
Skær ned på fedtet
Dokumentation er et nemt mål – mapperne /usr/share/doc og /usr/share/man er formentlig ikke overfyldte efter en ny installation, men vi har ingen brug for dem. Den slags fjernelser bliver rullet tilbage, så snart der kommer en pakkeopdatering, men lad os lade, som om vores enhed ikke gør det. Vi kan faktisk helt afskaffe pakkemanagement, hvis vi har mod nok. På godt og ondt bliver mange indlejrede enheder leveret med den forudsætning, at deres operativsystem aldrig bliver udsat for softwareopdateringer eller sikkerhedsjusteringer. Når det gælder enheder, der ikke skal på et netværk eller udsættes for vilkårligt brugerinput, er det faktisk ikke noget problem. For nymodens Internet of Things-gadgets er det helt begrædeligt. Ikke desto mindre kan vi fortsætte med at slette alle downloadede pakker fra /var/cache.
Vidløs Systemd-bashing synes aldrig at gå af mode, men til indlejrede enheder kan det være overkill. Vi skal stadig bruge et normalt init-system, og vi kan måske få brug for en servicemanager, men vi har ikke brug for alle de andre ting, som Systemd gør. Derfor kan vi vride en hjemmelavet init ind og droppe 30 MB Systemd. Vi kan gå endnu videre og skaffe os helt af med en konventionel init og få et script, der booter direkte til enhedens hovedapplikation. Nu ligner vores Franken-Linux knap nok sine ophav, og vi kan derfor lige så godt sigte efter struben og rode rundt med kernen. Igen skal vi huske, at dette er hypotetisk: Vi har næppe lyst til at have en hel compiler-toolchain installeret på vores styresystem, og derfor skal vores optimerede kerne konstrueres og (kryds)-kompileres på en anden maskine.
Vores Arch Linux-installation fylder 28,3 GB. Denne frås med pladsen ville ikke blive godkendt i den indlejrede Linux-verden.
Trim kernen
De fleste distroer pakker deres kerner med alle understøttede drivere kompileret som moduler: Hvis der bliver fundet et stykke hardware, bliver det relevante modul indlæst. Men hvis vi ved, at vi aldrig kommer til at ændre vores hardware, kan vi sorgløst slippe af med alle disse uønskede drivere. Linux- og Linux-firmwarepakkerne fylder tilsammen omkring 200 MB. Vi skal naturligvis stadig bruge en kerne, og vi får måske også brug for et par firmwarefiler, men hovedparten af disse pakkers indhold er ligegyldige for os. Derfor er vores første mål at kompilere en skræddersyet kerne, der kan forbedre boottiden ved kun at inddrage de drivere, vi har brug for. Vi kunne endda kompilere de drivere, vi skal bruge, ind i kernen, og det vil forbedre boottiden. Så snart vi har konstateret, at det virker, kan vi slette pakkerne, og så har vi barberet 150 MB af installationen. Vi kan reducere kernen yderligere, hvis vi ikke skal bruge nogen netværksfunktionalitet.
Hvis man følger disse retningslinjer, vil man sandsynligvis ende med et samlet operativsystem på omkring 500 MB, og det er slet ikke ringe – men der er nogle, der har gjort det bedre. Det ville være upassende ikke at nævne Damn Small Linux og de beslægtede Tiny Core Linux-projekter her. De kan sagtens vride en fuldt arbejdsdygtig Linux ind på en tiendedel af denne plads, men de har det med at snyde og dekomprimere sager i ram, og det fungerer ikke i mange enheder. Men lad os fortsætte.
Efter at have puslet med brugerpladsen, init-systemet og kernen vender vi os nu mod bootloaderen. Grub er ret forbløffende, men den hører ingen steder hjemme i den indlejrede verden. Her skal vi have fat i Das U-Boot. Den er lavet med henblik på fart og bærbarhed og er blevet porteret til talrige enheder. I x86-pc’er tager BIOS (og på det seneste UEFI-firmware) sig af at bringe hardwaren i en sund tilstand. U-Boot er anderledes. Den er typisk den første software, der bliver indlæst i indlejrede systemer. Og derfor er den ofte genstand for flere begrænsninger, idet den tit skal vrides ind i flashlager, der i nogle tilfælde kan udgøre blot 128 kB. Der er imidlertid den fordel – i hvert på ARM-arkitekturer – at man helt slipper for bøvlet med at genkende hardware.
Det skyldes, at U-Boot er forsynet med et såkaldt Device Tree, der fortæller styresystemet alt om den hardware, der er knyttet til systemet, og de drivere, der skal bruges. Den slags giver ingen mening for desktopmaskiner, hvor man kan udskifte enhver komponent med noget, der typisk kræver en helt anden driver. Hardwaregenkendelse i Linux kan være en smule indeterministisk – harddiske bliver genkendt i den rækkefølge, i hvilken de bliver tændt. Det, der var /dev/sda ved en boot, kan være /dev/sdb ved den næste. Noget tilsvarende gælder for netværksinterface, og det er grunden til, at vi bruger partition UUIDS og persistent navngivning nu om dage. Når vi ikke skal bekymre os om al den usikkerhed, bliver livet meget nemmere for indlejrede systemer.
Hurtig bootning
For nogle systemer er hurtig boot altafgørende – man kan forestille sig at skulle vente 20 sekunder, før en hjertestarter begynder at gå i gang. Desktopbrugere er blevet forvænt med forbedret strømstyring i årenes løb, og man kan derfor undgå langsom start ved blot at lægge softwaren i en dvale, som den kan vågne fra på et øjeblik.
Det er desværre en luksus, der ikke tilfalder indlejrede enheder. Selv hvis de kunne falde i søvn, ville de stadig trække så megen strøm, at omgivelserne ikke kunne klare det. Man har derfor gjort sig store anstrengelser for at skrue op for boottiderne, og resultatet er, at Linux med den rette hardware og de rette optimeringer kan boote på mindre end et sekund. Der er nogle få nemme fordele her (fjernelse af ubrugte funktioner, ingen verifikation af kerneimage, intet irriterende bootoutput); nogle stykker, der svarer til de ritualer, der bliver praktiseret af fast-booters (som bruger bootcharts eller system-analyze til at finde langsomt startende tjenester) og nogle, der kræver masser af forskning og anstrengelser (for eksempel med en speciel bootloader til ens hardware). Linutronix’ Jan Altenberg har lagt en fremragende videooversigt her:
(http://bit.ly/BootOneSecond).
Systemd-analyze kan fremstille disse nyttige bootcharts, så man kan spilde timer på at få sit system til at boote få brøkdele af et sekund hurtigere.Droner over det hele
En af de mest spændende og populære anvendelser af indlejret Linux i dag finder sted inden for udviklingen af hobbydroner
I sin tid drejede ubemandede luftfartøjer (Unmanned Aerial Vehicles, UAV) sig navnlig om CIA’s Special Activities Division i Mellemøsten. Nu om dage spiller de en stadig større rolle i det civile liv. Du har måske hørt en, der forstyrrede søndagsfreden, eller også har du hørt, at de bliver brugt til at indsmugle sager i fængsler. Men de har andre anvendelsesområder: I nogle dele af Kina bruger kurerer dronelevering til at aflevere en pakke i den nærmeste hjørnebutik. Man får præcise oplysninger om, hvor og hvornår forsendelsen ankommer.
Takket være rigide regler om, hvad man må sende op i skyerne, kommer vi næppe til at se den slags forsendelser i vores del af verden foreløbig. Men på grund af den stigende efterspørgsel efter hobbydroner kommer vi ganske givet til at se flere og billigere droner på markedet og dermed i luften. Der findes alle mulige former for flyveklare droner i butikkerne. Der findes også mange minidroner, men her vil vi holde os til de gedigne maskiner, altså dem, der er beregnet til udendørs brug, og som har en batteritid, der ikke skal måles i sekunder. I denne gruppe kan man få en billige quadcopter til omkring 4000 kroner, og hvis man vil op i den høje ende, kan man snildt få lov til at give ti gange så meget. I dette ekstreme prislag finder man virkelig overdådige flyvende maskiner med 1080p kardanmonterede kameraer, der kan rotere 360 grader om tre akser, samtidig med at de streamer stærkt komprimeret video i noget nær realtid tilbage til hjemmebasen.
Sådan en skabning kan flyve i op til 30 minutter, før den skal hjem. Og hjem kommer den af egen drift takket være autopilot-teknologi. Man kan sågar programmere en kurs ud fra specifikke gps-punkter, før man letter.
Op at flyve med Linux
Det er ikke ganske nemt at få en genstand til at flyve, navnlig hvis det blæser. Hvis en drone med held skal forblive flyvende, må den kunne reagere lynhurtigt på ændringer i vilkårene. Så snart den opfanger en uønsket rotation om en given akse, skal de relevante motorer accelerere med det samme for at forhindre, at fartøjet styrter ned. Sådanne korrektioner skal finde sted flere tusinde gange i sekundet, og de bliver styret af dronens flyve-controller.
Denne controller er udstyret med sensorer, der kan klare den opgave. Som minimum vil der være et gyroskop, men mere avancerede modeller vil også have et accelerometer. Udstyret kan også omfatte et barometer, gps, kompas og afstandssensorer, der forlader sig på ultrasonisk puls eller lidar. Lidar kan læses som et akronym for Light Detection And Ranging, men er oprindelig dannet som en sammensætning af ordene “light” (lys) og “radar”. Vi skal imidlertid bruge noget, der kan bearbejde alle disse inputs, og derfor sidder der en cpu i controlleren. Eftersom batteritid er kritisk, brugte man oprindelig 8-bit Arduino-baserede chips, der ikke gav store muligheder for at udvide.
Et af de tidligste eksempler er ArduPilot Mega (APM), der kom frem i 2007. Den havde en 8 MHz-cpu med 8 kB ram og 256 kB flashlager. APM-hardware bliver parret med firmaets Mission Planner-software der klarer alt, hvad man kan ønske sig af en jordbaseret kontrolstation, herunder evnen til at planlægge kurser ved hjælp af Google Maps. Det ændrer sig nu, og vi ser langt mere avancerede controllere, den kan håndtere flere sensorer og foretage mere avanceret navigation. Et eksempel er 3D Robotics’ Pixhawk, der bliver drevet af en 32-bit ARM Cortex M4, og som kører realtid-styresystemet NuttX.
Stærkere enkeltkort-computere såsom Raspberry Pi er allestedsnærværende og har også vej op i skyerne. Den almindelige Linux-kerne var ikke beregnet til realtid-applikationer. Men behovet har ændret sig inden for så forskellige felter som audioproduktion og industriel CNC-fræsning. Det har affødt en meget udbredt patch, PREEMPT_RT, som omdanner store portioner kernekode, således at den bliver til et sandt kraftværk, der kan udvides. Den APM-firmware, der tidligere kun kunne fås til Arduino-enheder, er med held blevet porteret til Linux. Således kan man nu bruge dette styresystem til at styre en flyvemaskine.
3DR’s solodrone er en af de fineste på markedet. Foruden autopiloten Pixhawk har den et ekstra Cortex A9-kort, der kører Linux og giver yderligere regnekraft.Det er denne fremgangsmåde, man kan se hos Erle-Brain 2-autopilot, der omfatter en Raspberry Pi 2 i kombination med et PixHawk Fire Cape 2.0-kort (PXF 2.0). Hele historien er nydeligt pakket ind i et vibrationsdæmpet og kompakt format. PXF-kortet er et fuldkommen åbent hardware-design og omfatter alle de fornødne sensorer, og her er også stik til I2C-bussen for det tilfældes skyld, at man vil tilføje mere. Den kan styre op til 12 outputenheder (motorer/rotorer/ror/kameraer) via PWM og har fire LED’er, der viser rudimentær diagnostisk information. Producenten leverer et Debian-baseret image (med RT-patches) foruden en mere moderne affære, der bygger på Ubuntu Snappy Core. Snappy er et letvægts-styresystem, der er beregnet til IoT-enheder og cloud-installationer.
Det adskiller sig fra den traditionelle pakkebaserede Linux-opdateringsmetode, idet den bruger transaktionelle opdateringer, hvor basesystemet er opdateret som en enkelt enhed. Hvis denne opdatering slår fejl, er det enkelt at rulle den tilbage til det forrige image. Snappy understøtter også apps (‘snaps’), som man kan downloade fra Erle Robotics’ butik på (http://erlerobotics.com/blog/snappy-store). Erle-Brain kan købes separat eller som del af firmaets dronesæt. PXF 2.0-kortet kan man ikke få separat, men de, der er interesserede i en mere gør det selv-agtig tilgang kan overveje Erles nyeste bud – PXFmini. Der er tale om et shield til nyere Raspberry Pi’er, navnlig Zero. Det vrider alle de fornødne sensorer og stik på plads på et fuldt APM-kompatibelt kort på kun 15 gram. Navio2 Autopilot Shield gør noget lignende, men omfatter også et gps-modul (der også fungerer sammen med det russiske Glonass-netværk og det kinesiske BeiDou-net) og et strømmodul.
Dronecode-projektet
I oktober 2014 blev Dronecode-projektet søsat under Linux Foundations ledelse og i samarbej-de med de førende firmaer 3D Robotics og Yuneeq. Det er et samarbejde med industriens repræsentanter om at skabe en delt open source-platform, der bygger på Linux-baseret UAV-software.
Håbefulde flyvning-softwareproducenter kan blive belønnet for deres bidrag til platform i form af ros. Der er i øjeblikket over 1200 udviklere, som arbejder på Dronecode-tilknyttede projekter.
Dronecode sigter på at standardisere protokoller (såsom MAVLink), flyvekode (såsom APM og PX4) og software til styring fra jorden (QgroundControl, APM Planner etc.). Formålet er at fremme og forbedre adgangen til det Linux-baserede drone-økosystem. I takt med, at hardwaren ombord på fartøjet bliver bedre, skal Dronecode styre udviklingen af avancerede funktioner såsom videostreaming (Pi 2 har markant forbedret denne situation), kollisionskontrol og computerstyring. Disse funktioner kan kun komme for langsomt, hvis de nye planer, som bliver fremlagt af det hollandske politi, bærer frugt. De foreslår, at man bruger højt specialiserede ørne (den er god nok: http://bit.ly/EagleSquad) til at neutralisere droner på afveje, der er allerede udtrykt interesse i at bevæbne de fjerede vagtposter.
Inden i Ubuntu-bilen
Førerløse biler bliver allerede afprøvet på vejene, og selvom lovgivningen forbyder dem at forlade garagen uden en supervisor af kød og blod, kan det udmærket tænkes, at de bliver til virkelighed i nogle af vores yngre læseres levetid. Teknologien er allerede så avanceret, at fantasien stejler – med lidar, kameraer, der virker i alle retninger, gpu-baserede neurale netværk, cloud og anden magi. Imidlertid er det nuværende mål for disse biler at fungere uafhængigt i enkle situationer på hovedvejen snarere end at navigere gennem ukendte vejkryds og forbi pingviner, der krydser gaden i en obskur forstad. De projekter, der fylder mest i pressen, bliver finansieret af Google, Tesla og på det seneste også af Nvidia. Men kort før jul 2015 blev det ændret af en overraskende meddelelse.
Den kom fra en George Hotz, der i et tidligere liv blev kaldt geohot, og som låste op for den oprindelige iPhone og hackede Playstation 3. Hotz meddelte, at han havde modificeret sin Honda Acura med en hjemmelavet førerassisteret autopilot. Centralt i al dette trylleri var Ubuntu Linux. Hotz håber via sit firma, comma.ai, at markedsføre systemet til bilindustrien til en pris af cirka 1000 dollar. Med den gestus håber han, at det monopol, som i øjeblikket tilfalder Mobileye (der for tiden arbejder sammen med mange bilproducenter og blandt andet leverer Teslas autopilot-system) bliver brudt. Systemet er ikke kønt med dets mange kabler, en stribe kameraer, et handskerum fuldt af rod og den lyserøde uhyrlighed, der er Ubuntus standardtema. Men Hotz hævder, at det er ekstremt avanceret: Alt, hvad det ved om kørsel, stammer fra kunstig indlæring snarere end fra klodsede og upræcise regler fra et menneske.
Googles robot-bilflåde bruger også Linux. Andre køretøjer og fodgængere fremstår som kasser. Indtil nu har køretøjerne ikke sat sig for at ramme disse kasser.