Linus: Vi er bekymrede for stabiliteten

Den hastighed, som kode tilføjes Linux med, kan i fremtiden blive en trussel imod styresystemets stabilitet. Det siger systemets grundlægger Linus Torvalds i et nyt interview.

Udviklingen af styresystemet Linux har efterhånden 20 år på bagen, men for systemets grundlægger, finske Linus Torvalds, er der ingen grund til at hvile på laurbærrene.

»Jeg tror ikke, det vil gå væk,« siger han om Linux til det australske Computerworld.

»Jeg har en mistanke om, at jeg vil gøre det her i lang tid, og jeg har slet ikke en fornemmelse af, at det er færdigt.«

Selve størrelsen af den 20 år gamle kodebase kan dog give Linus Torvalds rynker i panden.

»Der er altid den bekymring, at vi er ved at miste grebet og kan få kæmpe stabilitetsproblemer. Andrew Morton (som håndterer kodebasen, red.) taler hele tiden om det her: At vi må sikre os, at kvaliteten ikke falder.«

Det er dog ikke sådan, at det hele er ved at ramle ned over Linux-udviklerne.

»Vi har ikke nået til det punkt, hvor vil tilføjer kode så hurtigt, at vi mister stabilitet.«

Mini-bærbare giver nye udfordringer

Linus Torvalds har skaffet sig en Asus Eee mini-bærbar, der markerede startskuddet til den nye bølge af billige mini-bærbare. Eee'en benytter Linux som styresystem.

»Vi er i den første fase med netbooks, og der er nogle pinefulde problemer. Den afpillede grænseflade er et pinefuldt problem, og de første netbooks var for svage.«

Han håber, at den næste generation af mini-bærbare vil have flere kræfter og byde på en bedre brugerflade. Linus Torvalds har endda brugt mini-bærbare til kerne-udvikling, og det var slet ikke så ringe endda.

Microsofts 90'er-succeser er historie
Intet interview med Linus Torvalds er komplet uden spørgsmålet om, hvordan han synes det går for ærke-konkurrenten Microsoft.

Han mener, at Windows 7 er et fremskridt fra Vista. Men meget af det, som gav Microsoft succes i halvfemserne, er væk, mener Linus Torvalds.

Problemerne for Microsoft skyldes, at der går for lang tid mellem versionerne.

»Jeg tror, at Microsoft har indset, at Vistas udviklingscyklus er alt for lang og at det ville være vanvid at gøre det igen. De stræber vist efter en to-års cyklus, og jeg tror, det er for lang tid,« siger Linus Torvalds.

Microsoft bør sende Windows på gaden oftere, ligesom Linux og Apple, lyder rådet fra den nu 39-årige systemopfinder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (27)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Jensen

For svage? I forhold til hvad? En computer med 900 MHz processor, 1 GB RAM og mange GB harddisk, var et mega-kraftigt monster for få år siden. Er det ikke bare Linux-kernen der er blevet for bloated?

Når jeg tænker på hvor meget man kan med windows 3.1, der kom på 3 disketter, så synes jeg det er absurd hvor meget et styresystem idag kræver. Jeg kan slet ikke få regnestykket til at gå op.

Thomas Jensen, Horsens

  • 0
  • 0
Christian Nobel

Præcis samme tanke fik jeg.

Måske tiden mere er til at kikke dybt på hvordan man får gjort Linux (og for den sags skyld alt muligt andet) slankere.

Det bare at forlade sig på at processorerne bliver kraftigere og kraftigere er en sovepude, da programmers kompleksitet og dermed risiko for fejl stiger nærmest eksponentielt med størrelsen.

Så kan vi ikke snart få vendt skuden og barberet fedtet af - et eller andet sted er det da lidt ynkeligt at nutidens systemer i det store hele ikke er specielt meget hurtigere (endda nogen gange langsommere) end en 20 år gammel PC eller Mac, trods det at processorerne er blevet sådan ungefähr 500-1000 gange hurtigere og mængden af hukommelse er steget med en tilsvarende faktor.

Uden præcis at kunne bevisføre det vil jeg mene at en Eeepc har mere datakraft end hele DTU havde for 25 år siden!

/Christian

  • 0
  • 0
Christian Nobel

Linux kører jo fint på mobiltelefoner, DVD afspillere, hjemme-routere osv.

Nu ikke kun hjemmeroutere - men uagtet det, så er min bekymring bare hvis kernen bliver for bloatet, fordi der kommer for meget i den.

Måske er vi ved at nå der hen hvor en genovervejelse af operativsystemer var ved at være værd at tænke på, måske i form af noget mikrokerne baseret noget, med en helt klar definition af hvordan tingene omkring kernen skal fungere.
Der er immerværk rigtig mange års viden omkring hele *nix verdenen der kunne bruges til at kortlægge hvordan man IKKE skal gøre det.

Der er vel forhåbentlig ikke nogen der tror at Linux (samt BSD og alle mulige andre *nix'er og Windows) er sidste trin på computerevolutionens stige.

Mon ikke han taler om den grafiske grænseflade og programmer med stort hukommelseforbrug.

Jo det gør han nok, men det ændrer ikke på det faktum at moderne programmer også er blevet alt, alt for opsvulmende.

Vi forbenter noget andet af vores arbejdscomputere i dag end for 10 år siden.

Gør vi egentlig det?
Hvis jeg sammenligner med en Mac fra slutningen af firserne så synes jeg faktisk at der er sket skuffende lidt.

/Christian

  • 0
  • 0
Steen Krøyer

I gamle dage måtte vi stå op før vi gik i seng, og binært morse maskinkodeinstruktioner ind i en klat gammel bolledej som havde 4 bytes lager og forstod 2.5 instruktion. Bagefter fik vi tæsk, og måtte udlæse resultatet af vores program ved at tolke de pruttende lyde det gav når bolledejen faldt sammen. Men det virkede!

(Med skyldigt nik til de gamle (Monty) Python-drenge).

Sorry, men jeg kunne ikke lade være. Det er selvf. rigtigt at meget nyt software æder urimeligt mange ressourcer. Men inden i nu smider jeres nuværende sw ud og i et nostalgisk øjeblik lægger MS-DOS 2.1 ind på PC'en, så tænk over at mange af de krav vi idag stiller til eksempelvis vores OS, slet ikke kan honoreres af MS-DOS 2.1, Win3.1 eller lign. I vil have ordentlig virtuel memory management så hver proces kører i sit eget adresserum. I vil have IPv4 og måske også IPv6 så i kan komme på nettet. I vil have et ordentlig filsystem, gerne med journal og mere end 8.3 tegn per filnavn, men samtidigt baglæns kompabilitet så i kan læse/skrive på en FAT-formateret enhed. I vil have fuld support for USB, så i bare kan klaske webcam/dvd-drev/lydkort/mus/tastatur/Bluetooth dongle/osv. på. Og Bluetooth der gør det muligt at sync'e mobilen med den bærbare kræver jo så også lige en Bluetooth-stak. Nåja, og så skal der jo også lige være en fuld Wifi-stak så Netbook'en kan koble på det vilde net. Og derhjemme skal i jo så lige hoppe på netværksdrevet (kræver lige en SMB/CIFS-stak) .... og .... og ....

Der er en grund til at et moderne OS ikke kommer på 3 disketter og heller ikke kan køre på en klat bolledej.

Når det så er sagt, kunne vi sikkert allesammen ønske os at der ind imellem var lidt mere fokus på at få eksempelvis operativsystemer til at bruge færre ressourcer. Men det kommer lidt hen ad vejen. Ovenstående artikel er en lidt dårlig oversættelse af en artikel fra Computerworld (se http://www.computerworld.com/action/article.do?command=viewArticleBasic&...). Linus bruger udtrykket "teething pains" om den første generation af Netbooks. Og selv om det er "pinefuldt" at få tænder, er en mere korrekt oversættelse "begyndervanskeligheder". Og på Linux-siden er der jo allerede opstået en stribe distributioner der udnytter Linux' modularitet og fleksibilitet til at lave udgaver der kører bedre på Netbooks. Og hvis rygterne er sande kræver Windows 7 også færre ressourcer end Vista.

Men jeg tror adrig at vi kommer dertil hvor et moderne full-blown OS kommer på 3 disketter (hvordan skulle vi også læse dem :-)

  • 0
  • 0
Torben Mogensen Blogger

De er for svage til at vise film i høj opløsning og spille de nyeste 3D spil, men det er heller ikke det, de er designet til. Der er gode til at tage noter i skolen, til at tilgå nettet (undtagen de dele, der bruger absurd mange ressourcer til flashanimationer osv.), til at lave skoleopgaver, til at lave præsentationer, til tekstbehandling, til sjove småspil osv. Kort sagt 90% af det, man alligevel bruger en bærbar PC til.

Min største anke ved dem er ikke regnekraften, men den forholdsvist lave skærmopløsning. Selv til tekstbehandling og netsurfing er 1024x600 i underkanten.

Og der findes masser af Linux installationer, der kører fint med små ressourcer, så jeg ser ikke det som problemet.

  • 0
  • 0
Thomas Ammitzbøll-Bach

Hvorfor skal man altid kritisere Linux. Nu ham her Linus Torvalds taler om "stabilitetsproblemer", "pinefulde problemer" og "[Linux notebooks] er for svage".

Hvem er han, og har han overhovedet nogen erfaring med Linux? Hvis der er noget, han er utilfreds med, så kan han selv skrive et operativsystem! Jeg installerede Ubuntu for et halvt år siden og har brugt det til spil og netbank uden problemer, så jeg ved nok mere om Linux end ham...

Alle, der kritiserer Linux, er bare nogle n00bs og nogle MS-fanbois hele bundtet!

Thomas

PS: Er der nogen, der ved hvad [root@hellbox:~]# betyder?

  • 0
  • 0
Niels Elgaard Larsen

==

Nu ikke kun hjemmeroutere - men uagtet det, så er min bekymring bare hvis kernen bliver for bloatet, fordi der kommer for meget i den

Det er kun kildeteksten, Linus taler om.

En linuxkerne fylder ca 1.5 MByte. Derudover læser den de moduler ind, som den har brug for.

Man kan også selv oversætte sin kerne med alting oversat ind i den.

Jeg har en gammel server, hvor jeg oversætten kernen uden support for moduler. På fire år fra 2005-2009 er kernen vokset fra 1.7 til 1.9 MByte. På en desktop-PC ville det nok være noget mere. 1.4-kernerne fyldte dog en del mindre.

Det er alt sammen komprimerede kerner, så de fylder mere når de er læst ind. Derudover allokerer kernen noget RAM, når den booter.

Men alt i alt er størrelsen af den oversatte kerne ikke ligefrem eksploderet. Desuden kan man trimme 2.6 kernen en del, fx til indlejrede systemer.

  • 0
  • 0
Nick Frederiksen

Hmmm... Tror nu nok Linus Torvalds ved en hel del mere om Linux end dig. Det er trods alt ham der lavede den første udgave af linux.

Navnet Linux kommer jo af hans eget Linus, men s'et er erstattet med x fordi kernen bygger på unix.

Måske du skulle sætte dig ind i sagerne før du disser manden der opfandt dit elskede system.

  • 0
  • 0
Nick Frederiksen

Man ved aldrig... Der findes faktisk folk der kører linux, blot fordi det er gratis og ikke Microsoft, der kalder sig habile superbrugere og som påstår at kunne svare på hvilket som helst spørgsmål omkring deres OS.
Men når det kommer til stykket er det sådan noget de fyre af...

  • 0
  • 0
Jakob Bruun Hansen

Hmmm... Tror nu nok Linus Torvalds ved en hel del mere om Linux end dig. Det er trods alt ham der lavede den første udgave af linux.

Ja ja, det kan en vær jo komme og sige. En mand starte et helt operativsystem?? Nu er du vist fjollet!

  • 0
  • 0
Thomas Ammitzbøll-Bach

1) Linus Torvalds skal selvfølgelig ikke disses. Faktisk skal han have en masse credit for at have startet lavinen, selvfølgelig, men sandelig også for at have et sobert overblik over muligheder og risici for kernens fremtid.

2) Jeg må nok erkende, at jeg har brugt Linux i lidt mere end et halvt år. Linux er det bedste der sket for computerverdenen siden skiveskåret brød. Der er mange fede ting i Linux, og der er ting, der godt kunne være bedre. Hvis nogen, indenfor eller udenfor, har noget at kritisere, så er det mest frugtbare nok at lytte, tænke, designe og kode fremfor ligegyldig tungerækkeri.

3) Jeg har fundet ud af det med [...]# nu. Det er noget man bruger, når man skal compile en ny kerne :-)

Thomas

PS: Hvordan skifter man til drev D: ? (Running for cover)

  • 0
  • 0
Christian Nobel

Ok kan godt sige at selve den kompilerede kerne ikke har samme tendens til at direkte eksplodere i størrelse som alt det omkringliggende.

Omvendt så kan man konstatere at hvis vi kikker på antal af source kode linier i kernen så har udviklingen været sådan her:

1.0.0: 176.250
2.0.0: 310.950
2.2.0: 1.800.847
2.4.0: 3.377.902
2.6.0: 5.929.913

Altså en ganske voldsom stigning i kompleksitet.

Endvidere så er kernen monolitisk, hvilket er hvorfor jeg begynder at spørge mig selv om tiden ikke er ved at nærme sig der hvor noget nytænkning kunne være på sin plads, dvs. et helt nyt OS hvor man bruger mikrokerne i stedet - set i lyset af de stigende problemer med "dårlig adfærd" (trojanere mv.) så kunne en ny arkitektur med endnu højere fokus på sikkerhed være interessant.

/Christian

  • 0
  • 0
Jarle Knudsen

Man ved aldrig... Der findes faktisk folk der kører linux, blot fordi det er gratis og ikke Microsoft, der kalder sig habile superbrugere og som påstår at kunne svare på hvilket som helst spørgsmål omkring deres OS.
Men når det kommer til stykket er det sådan noget de fyre af...

Man ved aldrig... Der findes faktisk folk der kører Windows, blot fordi "den kom med maskinen", der kalder sig habile superbrugere og som påstår at kunne svare på hvilket som helst spørgsmål omkring deres OS.
Men når det kommer til stykket er det sådan noget de fyre af...

Virker begge vejer, ik?

  • 0
  • 0
Nick Frederiksen

Glemte lige,
Hvordan kan det være at et linux eksempel straks skal oversættes til windows eksempler, men windows eksempler aldrig må oversættes til linux?

Havde jeg skrevet

Man ved aldrig... Der findes faktisk folk der kører Windows, blot fordi "den kom med maskinen", der kalder sig habile superbrugere og som påstår at kunne svare på hvilket som helst spørgsmål omkring deres OS.
Men når det kommer til stykket er det sådan noget de fyre af...

Så var der ingen der havde skrevet

Man ved aldrig... Der findes faktisk folk der kører linux, blot fordi det er gratis og ikke Microsoft, der kalder sig habile superbrugere og som påstår at kunne svare på hvilket som helst spørgsmål omkring deres OS.
Men når det kommer til stykket er det sådan noget de fyre af...

  • 0
  • 0
Steen Krøyer

Omvendt så kan man konstatere at hvis vi kikker på antal af source kode linier i kernen så har udviklingen været sådan her:

1.0.0: 176.250
2.0.0: 310.950
2.2.0: 1.800.847
2.4.0: 3.377.902
2.6.0: 5.929.913

Altså en ganske voldsom stigning i kompleksitet.

Ork, tallet er nu omkring 10 millioner linier kode (se f.eks http://www.heise-online.co.uk/open/Kernel-Log-More-than-10-million-lines...). Men der er primært tale om en voldsom vækst i antallet af drivere (som kan loades og unloades modulært). Og support for en række nye arkitekturer. Selve kernen er slet ikke vokset i samme omfang. Men prisen for at Linux i dag kører på næsten alt, og supporterer en hulens masse hardware, er selvfølgelig mere kode. Kun ved at skære ned på mængden af drivere og supporterede arkitekturer kan kodemassen mindskes - og det vil sikkert ikke gøre selve kernen meget mindre.

Endvidere så er kernen monolitisk, hvilket er hvorfor jeg begynder at spørge mig selv om tiden ikke er ved at nærme sig der hvor noget nytænkning kunne være på sin plads, dvs. et helt nyt OS hvor man bruger mikrokerne i stedet

Et godt spørgsmål ... prøv evt. at tage diskussionen op med Linus - nej, lad hellere være :-) (se http://oreilly.com/catalog/opensources/book/appa.html).

Endvidere så er kernen monolitisk

Jepsen, som de fleste andre udbredte kerner er det idag. Men det betyder mindre på runtime i praksis, da kernemoduler dynamisk kan loades og unloades efter behov. Man sidder ikke og kører 10 millioner linier kode på sin Netbook.

Et mikrokerne-baseret system der supporterede lige så mange arkitekturer og havde ligeså mange drivere, vil sikkert have (mindst) lige så mange linier kode. Man kan måske argumentere for at det vedligeholdelsesmæssigt ville være nemmere at have med at gøre, men det er svært at afgøre.

Og for at komme tilbage til det med Linux og Netbooks, skal vi lige huske at der er mere end kernen i spil. Det er meget sandsynligt at det der er sværest at trække er hele GUI-delen, med bling-bling, fest og farver. Men jeg er sikker på at nogle af de nye Netbook-orienterede Linux-distroer finder ud af at bruge noget der er nemmere at trække end en fuld KDE eller Gnome (desktop-miljøer).

  • 0
  • 0
Dennis Decker Jensen

Blot fordi man mener, at moderne styresystemer og software er bloated, betyder det ikke, man nostalgisk går og drømmer om MS-DOS 3.3 e.lign.

Faktisk vil jeg mene, at software enemy no. 1 er størrelse, både i kildekode og objektkode. Jeg har ikke set noget slå et softwareprojekt lige så hurtigt ihjel som størrelse. Det skulle da lige være inkompetente folk.

  • 0
  • 0
Torben Mogensen Blogger

Faktisk vil jeg mene, at software enemy no. 1 er størrelse, både i kildekode og objektkode.

Det er bestemt et stort (no pun intended) problem, men at det skulle være det største er nok lidt overdrevet. Men størrelse er til gengæld i større grad med til at gøre det vanskeligere at løse andre problemer (sikkerhed, stabilitet, effektivitet, ...)

Jeg har ikke set noget slå et softwareprojekt lige så hurtigt ihjel som størrelse. Det skulle da lige være inkompetente folk.

Der er nok også en sammenhæng her. :-)

Der er en tendens til, at problemer løses ved at tilføje kode, der behandler symptomer, i stedet for at rette i den kode, der er årsag til problemet.

Eksempel: Man har lavet et SQL bibliotek, hvor SQL queries overføres som tekst. Det giver så et sikkerhedsproblem, da man ved at sætte SQL-kode ind i søgeord kan ændre de egentlige queries. Den almindelige (og inkompetente) løsning er, at der alle steder, hvor biblioteket bruges, indsættes kode, der fjerner problematiske tegn fra søgeord.

Dels fylder det mere at lave symptombehandling af den slags ved enhver brug i stedet for at designe biblioteket, så problemet ikke eksisterer, og dels risikerer man nemmere, at nogen glemmer symptombehandlingen, så der alligevel opstår et sikkerhedsproblem.

Og man risikerer også at udelukke legitim brug af "underlige" tegn i søgeord. I nogle applikationer bliver navne som O'Conner gemt som OConner, fordi man har fjernet det mistænkelige ' i søgeordet. I V2's eget leksikon blev F# til F, da jeg oprettede en artikel om det.

  • 0
  • 0
Dennis Decker Jensen

Det er bestemt et stort (no pun intended) problem, men at det skulle være det største er nok lidt overdrevet. Men størrelse er til gengæld i større grad med til at gøre det vanskeligere at løse andre problemer (sikkerhed, stabilitet, effektivitet, ...)

Ja, det var også det, jeg mente, blot satte jed det lidt på spidsen. Måske lidt for kategorisk.

Om alt andet, du har da fuldstændig ret; det er nok nærmere ovennævnte implikation - at det gør det vanskeligere at løse andre problemer - hvor en masse andre faktorer spiller ind, og er med til at forværre problemet.

Godt eksempel med SQL-biblioteker. Det er symptomatisk for udvikling og brug af biblioteker i det hele taget.

  • 0
  • 0
Jens Madsen

Problemet med Linux, er at mange udvikler på kernen. I princippet, bør der ikke udvikles væsentligt på en kerne, og kernen skal være statisk og stabil. De udviklinger og udvidelser der kommer, skal placeres udenfor kernen, og kernen skal stå inde for isolation af disse programmer/drivere og andre udvidelsesmoduler. I princippet, skal alt kode, der udvikles som "open source" udvikles under sikre omgivelser, således at en fejl i softwaren ikke kan medføre operativsystemet går ned, eller dets ustabilitet. Kernen, står for multitasking, og hvor mange resourcer som et program får tildelt. Resourcer, er såvel ram, som harddisk, CPU kraft, og eventuel reservering af CPU'en i kort tid, eller andre former for resourcer, såsom grafikkort, printer osv. I princippet, må ingen applikation reservere en resource i uendelig tid, f.eks. en printer, uden at lade andre komme til. For en printer, kan det ske ved der er et maksimalt antal sider der kan udskrives samlet for enhver process eller bruger.

Et operativsystem, skal kun indeholde de grundlæggende regler for samarbejde og sikkerhed, således der garanteres at operativsystemet forhindrer at programmørerne ødelægger noget for hinanden. Hvis så meget som muligt skrives under operativsystemets beskyttelse, så vil det være nemmest at sikre operativsystemets stabilitet, og garantere mod misbrug f.eks. i drivere, og nedbrud. Selve OS'ets kerne, bør helst ikke være for stor, og bør ikke ændres af nogle, da denne del ikke er underlagt sikkerhed for opgraderingsmoduler, drivere, og brugerprogrammer.

Da jeg har set hvordan studerende kunne få "presset" egen kode ind i et operativsystems kerne, ved at lave noget software der ikke fungerede uden, og at påstå det var OS'et der ikke fungerede og var program fejl i - og ved at vise at det så virkede, når noget blev udskiftet med deres kode - så er min opfattelse at OS'er i princippet bør være lukket land for alle. Kun drivere, programmer, og moduler, der er isolerede så man er i stand til at kunne se som bruger hvor ansvar for fejl skal placeres, er lovligt at skrive af "hvemsomhelst". Et OS skal derfor isolere drivere, programmer, osv. så godt, at det ikke har mulighed for at sabotere hinandens funktion, og få det til at se ud som om andre har begået fejl. Er en fejl i en driver, må kun driveren selv gå ned. Den må ikke kunne hive andet i sænk, eller få det at se ud som om dette fejler. Det vil betyde, at hvis der laves en deffekt driver, så skal brugeren umiddelbart kunne se hvor fejlen er, og smide driveren bort. Eventuelt kan en teknisk ansvarlig, uden kodekendskab indsé det, ved at bruge driveren, og derved identificere fejlen. Hvis den får andet til at gå ned, eller fungere forkert, vil det nemt medføre at en fejl diagnostificeres forkert. Dette må ikke ske. Isolation, og at hindre noget får andet til at hænge, samt "firewall's" mellem applikationer, og måske "debuggere" der kan vise kommunikation, er dele af den sikkerhed som er nødvendigt, for at sikre stabiliteten af et OS.

  • 0
  • 0
Torben Mogensen Blogger

Måske en del af svaret findes her: http://www.usdoj.gov/atr/cases/exhibits/365.pdf

Det er kun en del af svaret. De vigtigste faktorer er nok:

  1. "The second edition syndrome", som siger, at den anden udgave af et stykke software altid er større end den foregående version, fordi producenten har fyldt ekstra features på for at gøre det mere tiltalende at opgradere.

  2. Mere "bling". Større skærmopløsning og lydkvalitet medfører større pladskrav til fonts, ikoner, animationer, lydeffekter osv.

  3. Flere standarder (specielt på Internettet) kræver mere software for at understøtte dem. Tænk bare på Java, Flash, Javascript, osv., som ikke fandtes, da Windows 3.1 kom på banen.

  4. Mere hardware. Der skal gemmes drivere til langt mere tredjepartshardware end tidligere -- og disse drivere er heller ikke blevet mindre. Her er en del af problemet, at Windows forventer, at drivere allerede er tilgængelige på disken, når man sætter en ny enhed på.

  5. Optimering for hastighed i stedet for plads. Da plads (i RAM og på disk) er steget hurtigere end hastighed, er der en tendens til at optimere kode for hastighed på bekostning af plads.

Pånær punkt 5 er alle disse eksempler på ekstra "features". Mange af disse kommer kun sjældent i brug, og specielt drivere vil de fleste brugere kun bruge en brøkdel af. Og man kan overveje hvor meget behov, der egentlig er for ekstra bling og mange af de andre features.

  • 0
  • 0
Jens Madsen

Optimering for hastighed i stedet for plads. Da plads (i RAM og på disk) er steget hurtigere end hastighed, er der en tendens til at optimere kode for hastighed på bekostning af plads.

Nej! Der skal ikke optimeres på hastighed. Optimeringer, er en vildand. Enhver, der ved hvordan man programmerer, kan programmere korrekt, og med rette algorithmer i første omgang. Der er ingen grund til at først lave en O(nn) sortering, for herefter at "optimere" den til en O(nlog(n)) sortering. Optimering, er bluff.

Det som sker, er at der ikke er styr på kompleksitet indenfor softwareudvikling. Dette er såvel et problem indenfor CPU forbrug, og indenfor ram forbrug. Som eksempel, er en funktion måske O(n), og dette angives ikke i dokumentationen. Dem, som bruger den, placerer brugen i deres egen O(n). Og nu er det O(n*n). Sådan bliver det ved. Manglen på styr på kompleksitet, er det store problem.

En simpel måde, at styre softwareprojekter på, er at forbyde sløvt software. Enhver programmør, der laver en O(n) kompleksitet fyres. Så er det nået. Størst tilladelige kompleksitet er "ca" O(log(n)). O(log(n)) giver ikke problem, trods mange programmører med O(log(n)) kompleksiteter, kalder hinandens objekter og funktioner inde i hinanden.

I ganske få tilfælde, kan være nødvendigt med en O(n) kompleksitet, men en sådan må kun godkendes, hvis der ikke findes andre muligheder. En programmør, der spørger efter lov til en O(n) kompleksitet, hvor det ikke er nødvendigt, er en dårlig programmør, og står til opsigelse. En, der gør det, hvor det er nødvendigt, og ikke kan løses uden, er dygtig nok, og får det godkendt.

I dag er man ikke skrap nok, over for programmører der "ødsler" med CPU'ens forbrug. Det betyder, at de sidder og udvikler sløve søge, sorterings, og arkiveringsfunktioner, eller måske andre algorithmer der i princippet kunne løses ved en standard søge, eller sorteringsalgorithme, eller rød-sort træ, og bruger tid på udvikling af O(n*n) algorithmer. Denne udvikling tager tid, og deres software er kun til at smide ud. Hvis de udvikler software der har højst O(log(n)) kompleksitet hvor det er muligt, vil den kunne - og måtte - bruges overalt, uden der skal udvikles tusinder af forskellige algorithmer for det samme, med forskellige dybder af kompleksitet. En gang korrekt udviklet - så kan det bruges forever. Og dem der ikke kan, kan ikke bruges.

Præcis det samme gælder med ram forbrug. Du vælger ikke mellem hastighed og ramforbrug, eller sløvt og lavt ramforbrug. Normalt er nærmere modsat: Stort ramforbrug, er kendetegnet sløve algorithmer. Og ikke mindst, er den væsentligste årsag til algorithmer er sløve, netop ramforbruget. Der er tendens til, at en algorithme med stort ramforbrug, kan få alt til at gå sløvt, fordi den får operativsystemet til at nemt page sider ud på harddisken, uanset din computers mængde af ram.

Det, som betyder noget ved ram, er som ved algorithmekompleksitet, "store O funktionen" for ram forbruget. Altså, øges forbruget eksponentielt med antal data i databasen. Eller, øges det med nn på antal data? Naturligvis, er det et krav, at det ikke må bruge mere ram end ca. O(nlog(n)) for n data. Og det må ikke - som ellers er standard i dag - øges proportional med tiden (O(t) eller O(t*t) i det værste).

Problemet er dårlige programmører. Og dette løses bedst, ved at hæve kravene. Ingen programmører, "har lov" at lave sløvt software, og fyres hvis de laver noget med kompleksitet større end O(log(n)), uden at få lov. Beder de om lov, og viser en analyse, at det ikke var nødvendigt, kan de fyres på grund af dumhed.

Endeligt, bør softwarebranchen, gøre det til en selvfølge at de angiver store O funktioner, og ram forbrug, for deres rutiner og objekter. Som eksempel, findes mange compilere, der ikke angiver store O funktionen for deres rutiner. Derfor, foretrækker jeg maskinkode, da den slags er rutine for hardwareprogrammører, og altid angives i hardware datablade. De har forståelse for de ting de arbejder med, og forståelse for, at det er nødvendigt at angive nøjagtige og sikre tekniske data for hardware. Ellers, kan brugeren hellerikke angive og garantere sikre data for deres hardware.

Typisk medfører mangel på kendskab til hvor lang tid en operation tager, også mangel på mulighed for test. Hvor længe, skal du vente på, at en rutine svarer? Du kan kun besvare dette, hvis du har datablade for din software som overholdes. Så software, der ikke har tidsaspektet med i deres design, er ikke testbart software indenfor endelig tid.

  • 0
  • 0
Log ind eller Opret konto for at kommentere