Hvad bliver det næste vi slukker-tænder for ?

Vi er efterhånden blevet totalt følelseskolde overfor folk der slukker og tænder for ting for at få dem til at virke.

Men var der slet ikke andre end mig, der studsede over, at man i sidste uge gjorde det med det nye signalsystem til S-togene?

På sin vis var jeg lettet over at det ikke hjalp, det gør det forhåbentligt mindre attraktivt at prøve samme metode næste gang.

At man i det hele taget fik ideen til at begynde med bekymrer mig meget, at det faktisk kunne lade sig gøre bekymrer mig endnu mere.

Burde et system der skal holde hundredevis af mennesker der fræser rundt i konservesdåser i live ikke være mere robust end som så ?

Jeg har ladet mig fortælle at man "for en sikkerheds skyld" genstarter kirurgiske robotter inden de tager fat på næste patient og det giver mig dejafu til den berømte XKCD stribe om kondomer.

NASA's Inspector General udsendte en rapport sidste uge, som på glimrende vis illustrerer den tilgang til IT jeg frygter:

Man havde noget flight hardware i en stor grim ovn der skulle teste at det kunne klare mosten, en test-sekvens tager typisk en arbejdsuge eller mere.

Ovnen var styret af en PC med Windows.

Som undervejs blev opdateret og genstartet.

Hvilket naturligvis ikke genstartede ovnstyringsprogrammet.

Efterladende ovnen på "ON".

Det viste sig at deres flight hardware ikke virkede når alle plasticdele var smeltet.

Men der var sikkert kommet en ny version af OutLook eller noget nyt antivirus software og den slags skal man aldrig vente med at opdatere, vel ?

Jeg er godt klar over at det nye signalsystem kører en slags sandkasse-drift på en lidt ligegyldig S-togsstrækning i god tid inden det skal rulles ud over hele landet.

Klogt gjort, bifald tak!

Men det er ikke nogen undskyldning for at ty til "sluk vent 10 sekunder og tænd igen".

Tværtimod: Hvis ikke man kan fejlrette signalsystemet på den lillebitte banestump, mens det kører, er det formodentlig fejldesignet og burde det aldrig være rullet ud i live-traffik til at begynde med.

Personligt mener jeg at denne "begivenhed" bør opfattes som og efterforskes som en "near miss" begivenhed og rent undtagelsesvist har vi faktisk en Havarikommission som har området under deres resort.

Jeg krydser fingre for at de fortæller os allesammen, hvad vi lærte og kan lære af dette nedbrud.

phk

Poul-Henning Kamps billede
Poul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.

Kommentarer (159)

Mogens Hansen

Burde et system der skal holde hundredevis af mennesker der fræser rundt i konservesdåser i live ikke være mere robust end som så ?

Der er masser af robusthed i systemet, når det gælder om at holde folk i live. Masser af del-systemerne i togene vil ganske enkelt bringe togene til stop, hvis der er ting, som ikke stemmer overens. Det er med stor sandsynlighed det, som gør at man ikke kan få togene til at køre.
Det er robusthed over for at holde togene kørende, der mangler.
Det er fint at du kritiserer mange aspekter af disse ting - men det er dybt uretfærdigt over for rigtig mange mennesker som udfører et stort sikkerhedsarbejde, når din manglende indsigt i togdrift oversætter manglende fremdrift til trussel mod menneskeliv.

Filip Larsen

Uden jeg har en pind forstand på det nye signalsystem, så vælger jeg alligevel at tolke genstarten derhen, at vi har endnu et teknisk system der er så komplekst at fagfolk ikke kan fejlfinde og -rette på det men må ty til genstart for at komme tilbage til en kontrolleret tilstand af i hvert fald dele af systemet, hvilket så i dette tilfælde (heldigvis) heller ikke virkede.

Og bare for at gøre det klart, så er det er altså egentlig ikke så meget selve genstarten der undrer mig (jeg ved jo ikke om systemet er designet til dette), men mere udmeldingen om, at man ikke kan finde ud af hvad er er galt og så vælger genstart for at se om det hjælper, hvilket umiddelbart lyder som en beslutning taget af folk uden tilstrækkelig teknisk indsigt.

Eskild Nielsen

Jægersborg Hillerød er ca 30 km.

S-bane skal have et system CBTC som er meget anderledes en det system fjernbanen får.

Personligt giver det mig en dårlig fornemmelse at CBTC er baseret på wifi protokoller, og at S-banen bliver det CBTC system, der har størst fysisk udstrækning til dato.

Casper Bang

...er jo desværre ofte brugt når noget ikke er ordentligt forstået. Det handler vel både om økonomi samt håndværk (nogen vil sige 2 sider af samme sag, her er jeg dog uenig) og fejl kan altid opstå - spg. er bare i hvilken grad de forsøges mitigeret eller ej. En watchdog på en MCU er jo et glimrende eks. på en fin balance - men det er jo så heller ikke alle der udnytter disse. Godt med fokus på emnet QA og fejlhåndtering, det mangler vi sgu lidt i disse hast tider hvor IT tvinger sig ind alle steder.

Poul-Henning Kamp Blogger

Der er masser af robusthed i systemet, når det gælder om at holde folk i live. Masser af del-systemerne i togene vil ganske enkelt bringe togene til stop

Det bør de gøre, men hvilken sikker viden har vi om at de faktisk vil gøre det ?

Jeg tror faktisk jeg har ret god indsigt i både togdrift og komplexe IT-systemer - det er sådan set derfor jeg skrev blogindlægget til at begynde med.

Grunden til at jeg ikke tager din nebuløse forklaring og forsøg på jedi-handwave for gode varer, er at den kommer fra samme miljø som håbet/forventningen/bønnen om at signalsystemet ville give sig til at virke hvis bare man slukkede og tændte det.

Det er tydeligt for envher, ud fra at man fandt det fornødet at informere pressen og at det skulle tage nogle timer, at en sådan sluk/tænd "recovery" ikke er en del af designet eller den normale fejlsøgningshåndbog.

Derfor er denne "begivenhed" en direkte anklage imod din påstand om "masser af robusthed i systemet", i den forstand at "man" tydeligvis ikke ved hvordan systemet faktisk virker og at det tydeligvis heller ikke har den "masser af robusthed" til at isolere, identificere eller arbejde udenom hvad de så end var der plagede det.

Hvis ikke en begivenhed som denne bliver udredt helt til bunds, således at der foreligger en rapport der præcist forklarer hvordan det gik galt, hvordan man reproducerede det, hvorfor man ikke rettede problemet på en langt mere hensigtsmæssig måde, og hvordan man har aftestet den nye fejlrettelsesinstruks, er budskaber på formen "stol på os" utroværdige.

Og ja, det er en høj stang at springe over og sådan skal det være, for det er ikke alene menneskeliv der er på spil, det er også rigtig store klumper af bruttonationalproduktet, hvis man om føje år bliver nødt til at stoppe alle tog i et par timer mens de ansvarlige håber på at løse "uforklarlige" problemer med en trefingersalut.

Og nej, det hjælper bestemt ikke på goodwill at computeren med "masser af robusthed" i IC4 ikke kan finde ud af at få en dieselmotor og en automatgearkasse til at arbejde sammen.

Poul-Henning Kamp Blogger

Og bare for at gøre det klart, så er det er altså egentlig ikke så meget selve genstarten der undrer mig (jeg ved jo ikke om systemet er designet til dette), men mere udmeldingen om, at man ikke kan finde ud af hvad er er galt og så vælger genstart for at se om det hjælper, hvilket umiddelbart lyder som en beslutning taget af folk uden tilstrækkelig teknisk indsigt.

Det er sådan set den eneste ting der kan få mit blodtryk om det her ned igen: Hvis direktøren for det hele kommer ud med en klokkeren melding om at det var ham der beordrede genstarten trods teknikernes protester (og at han aldrig vil gøre det mere).

Hvis det, som jeg har hørt det, er teknikerne der var løbet tør for gode ideer, er det en falliterklæring for teknikerne og systemet.

Mogens Hansen

Det bør de gøre, men hvilken sikker viden har vi om at de faktisk vil gøre det ?


Ingen. Og som naturvidenskabsmand ved du også, at det er et ublu krav at stille. Men vi kan sammentælle antallet af tilskadekommende i dansk togdrift de sidste 100 år, og så spørge os selv, om ikke trafiksikkerhedsfolkene har ret godt styr på hvad det er de laver?

Jeg tror faktisk jeg har ret god indsigt i både togdrift og komplexe IT-systemer - det er sådan set derfor jeg skrev blogindlægget til at begynde med.


Jeg er ikke i tvivl om dine kompetencer udi IT. Men dine skriverier både her og på ing.dk viser, at du har meget ringe indsigt i alle det komplex af systemer - mekaniske, menneskelige, proceduelle - der indgår i fjernstyring af tog her til lands. Du vedbliver at fastholde et utroligt snævert IT perspektiv og ignorerer fuldstændigt at IT kun udgør en procentdel af den samlede pakke, der i høj grad og hele tiden understøttes af en masse mennesker, der rent faktisk ved hvad de gør.

Grunden til at jeg ikke tager din nebuløse forklaring og forsøg på jedi-handwave for gode varer, er at den kommer fra samme miljø som håbet/forventningen/bønnen om at signalsystemet ville give sig til at virke hvis bare man slukkede og tændte det.


Hvad er det nu "regel 1" er på din blog?

Derfor er denne "begivenhed" en direkte anklage imod din påstand om "masser af robusthed i systemet", i den forstand at "man" tydeligvis ikke ved hvordan systemet faktisk virker og at det tydeligvis heller ikke har den "masser af robusthed" til at isolere, identificere eller arbejde udenom hvad de så end var der plagede det.


Jeg skrev præcist hvad jeg mente med robusthed. Når begrebet vendes til noget jeg ikke har skrevet, så er det jo let at lave en ny anklage.

Hvis ikke en begivenhed som denne bliver udredt helt til bunds, således at der foreligger en rapport der præcist forklarer hvordan det gik galt, hvordan man reproducerede det, hvorfor man ikke rettede problemet på en langt mere hensigtsmæssig måde, og hvordan man har aftestet den nye fejlrettelsesinstruks, er budskaber på formen "stol på os" utroværdige.


Hvor har du læst at en sådan udredning ikke vil finde sted?

Og nej, det hjælper bestemt ikke på goodwill at computeren med "masser af robusthed" i IC4 ikke kan finde ud af at få en dieselmotor og en automatgearkasse til at arbejde sammen.


Hvad har det med fjernstyringssystemer at gøre?

Rasmus Nielsen

Ovnen var styret af en PC med Windows.
Som undervejs blev opdateret og genstartet.

Dette har jo intet med sagen at gøre. Windows genstart for at gennemføre en opdatering af systemet er noget helt andet end at genstarte et system, som er kommet i en fejltilstand. Jeg beklager, men hvis man prøver at belyse en sag som denne, er det altså nødvendigt at være mere præcis i det billede man tegner.

Når man har at gøre med et komplekst system kan det ske at der opstår en uforudset fejl. Det vil typisk tage i størrelsesordenen flere dage eller uger at belyse den fuldstændigt. Man står derfor i en situation hvor man her og nu må foretage en handling på baggrund af de mangelfulde oplysninger, som foreligger. I dette tilfælde har en genstart så været det, der alt i alt gav mest mening. Som enkeltstående begivenhed er det ikke noget, der indikerer inkompetence, og det udelukker bestemt ikke en efterfølgende grundig undersøgelse, som jeg er overbevist om at teknikerne arbejder hårdt på i denne sag.

Jesper Frimann

Jeg er enig med.. både PHK og Mogens Hansen, ment på den måde, at jeg er sikker på at Mogens Hansen har ret (current point in time) når han siger, at der er redundante systemer, faglighed, erfaring og robusthed i den måde man gør tingene på. Men jeg mener også at PHK har ret, for det at 'genstarte et system' sker jo i langt langt langt de fleste tilfælde, fordi systemet er i en 'tilstand', hvor man ikke kan/magter/har overblik over, hvordan man får det tilbage til en veldefineret tilstand.
Og hvis man er nødt til at gøre dette, og det så stadig ikke virker.. ja så tyder det på at der er noget mere fundamentalt galt.

Og ja.. grunden til at det så bliver til en lidt større issue er, at det her er jo et mønster vi har set før.

// Jesper

Christian Nobel

Det største problem jeg ser i hele sagen er den "opdragelse" der er sket i IT branchen gennem de sidste 35år, hvor selv "garvede" IT folk er blevet lullet ind i Windows svøben om crtl-alt-del, og dermed gør løsningen til en del af problemet.

Det er beskæmmende.

Poul-Henning Kamp Blogger

Du vedbliver at fastholde et utroligt snævert IT perspektiv og ignorerer fuldstændigt at IT kun udgør en procentdel af den samlede pakke

Du får det til at lyde som om denne procentdel kun er 1 eller måske 2 ?

I virkeligheden udgør IT ca. 95 procent af alt det der kan gå galt i de nye signalsystemer: Selv signalbehandlingen i radiosenderne og -modtagerne er software-baserede.

Jeg håber på at arkitekten (er der overhovedet en ?) i signalprojektet har læst Perrows glimrende bog: http://press.princeton.edu/titles/6596.html

Og forhåbentligt har alle involverede ingeniører/designere/programmører, hvad enten de laver hardware eller software også læst Richard Cook's "How Systems Fail":

http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf

Jeg skrev præcist hvad jeg mente med robusthed.

Du skrev "masser af delsystemer i toget". Det er ikke præcist.

Det er også en lidt hovmodig måde at argumentere - IC4 taget i betragtning.

Hvor har du læst at en sådan udredning ikke vil finde sted?

Jeg er blevet forsikret om at den ikke vil komme til offentlighedens kendskab, fordi "visse leverandører" har krævet den slags under NDA og at Bane.DK's ledelse heller ikke ser nogen værdi i at "hænge vasketøjet ud".

Hvad har det [IC4] med fjernstyringssystemer at gøre?

At det er den præcis samme branche, som slet ikke har fattet konsekvenserne af computeriseringen og de mange størrelsesordner højere komplexitet af deres førhen så trivielt simple systemer.

Som gennemsnitsbetragtning bliver hvert relæ-lignende funktion i det gamle signalsystem erstattet af ca. 100.000 linier kildetekst i det nye system.

I 100.000 linier kode er der typisk 50-100 fejl.

Poul-Henning Kamp Blogger

Når man har at gøre med et komplekst system kan det ske at der opstår en uforudset fejl. Det vil typisk tage i størrelsesordenen flere dage eller uger at belyse den fuldstændigt.

Der er himmelvid forskel på at få "belyst", dvs. udredt, dokumenteret, reproduceret og afhjulpet en fejl og på at bringe systemet i brugbar tilstand igen.

Et velkonstrueret system er normalt dubleret, på en sådan vis at man kan bruge den ene kopi til at parallelkørsel, simulationer og frem for alt til at snapshot'te fejltilstanden, men den anden "side" bruges til produktion.

Det var f.eks således man i starten af 1960'erne designede de første computerstyrede telefoncentraler (ESS-1) og NASAs ground systems for månelandingerne.

Der er også andre måde at gøre det på, IBM plejede at elske at printe flere hundrede kilo papir ud med hexdump af hele maskinen, andre systemer igen gør det med replay af meget detaljerede logfiler osv.

Men under alle omstændigheder skal en debug facilitet for komplexe og koblede fejl designes og bygges ind fra starten, det er ikke noget man klasker på som CR 3049 når man mest mangler det.

For det andet, skal systemet kunne bringes i en kendt funktionsdygtig tilstand på "ingen tid".

De før omtalte telefoncentraler kunne f.eks varm-startes på få millisekunder og kold-startes på under 100ms[1]

(Til sammenligning: Moderne "enterprise" servere der fedter rundt i 5-10 minutter inden de overhovedet loader et operativsystem.)

Som begivenheden sidste uge dokumenterede, har det nye signalsystem ikke en funktionsdygtig facilitet der bringer det i en kendt tilstand på kort tid og selv ikke en timelang genstart bragte systemet i funktion.

Det er, med andre ord, bygget helt uden hensyntagen til hvad vi har lært om konstruktion af den slags systemer de sidste 50 år.

Finn Glamhøj

Som gennemsnitsbetragtning bliver hvert relæ-lignende funktion i det gamle signalsystem erstattet af ca. 100.000 linier kildetekst i det nye system.

Hvis en relæ-lignende funktion erstattes med kode i det omfang er der helt klart noget galt, så skal man forstå udsagnet som de er binde gale og aner ikke det mindste om software design?

Eller er der tale om, at det der før kunne klares med en relæ-lignende funktion, nu på grund af de systemer de indgår i, er blevet så komplekse, at det kræver kode i det omfang?

Der må ligge mere bag det udsagn end der er udtrykt i indlægget, så en uddybning vil være velkommen.

Peter Rosenberg

Enig med Christian, men desværre sniger Genstart ind flere steder.
Jeg har nu en 3'dje generation Android SmartPhone (<1½ år gammel).
Senest har jeg haft udfald, 4G signal, der kun virker den ene vej, så IP protokollen ikke kan starte sessioner (Browse, Musiklytning osv), eller SMS'er der ikke ankommer, når afsender bevisligt har afsendt dem fra deres Mobil (til udbyder) og derefter IKKE bliver leveret nogensinde.
Svaret fra min telefoniudbyder var: Genstart SmartPhone
Og vi er på en Android version 5.0.2 sidst opdateret 2 Apr 2016.

Kenn Nielsen

Svaret fra min telefoniudbyder var: Genstart SmartPhone
Og vi er på en Android version 5.0.2 sidst opdateret 2 Apr 2016.

"Den slags"(tm) har jeg, i de sidste 10 år , tilskrevet "en ukendt tilstand ved min egen mobiltelefant, som bliver afhjulpet af telefantens software, der (re)initialiserer til en funktionsdygtig tilstand, når den opdager et SIM-kort med gyldigt abonnement"...

K

Poul-Henning Kamp Blogger

Hvis en relæ-lignende funktion erstattes med kode i det omfang er der helt klart noget galt, så skal man forstå udsagnet som de er binde gale og aner ikke det mindste om software design?

Det er som sagt en gennemsnitsbetragning, noget i stil med "antallet af linier kode i det ny system" divideret med "antallet af relæ-lignende funktioner i det gamle".

Der er primært to grunde til at forholdet bliver så stort.

I gamle dage var "Keep it Simple Stupid" princippet meget højt skattet i signal- og sikkerhedsbranchen. Ingen tilføjede 10 ekstra relæer, hvis ikke de gjorde tilsvarende stor gavn.

Nu om dage er der et fokus på "Common Off The Shelf" komponenter, hvilket på markedsøkonomiens vilkår medfører anvendelse af alt for store og komplexe komponenter, ikke mindst inden for software og operativsystemer[1], ikke mindst hvis projektledelsen har "blame allocation" som successkritierie.

Der er naturligvis en masse legitime tradeoffs: Skal det være en relativt ukommunikativ RTOS kerne der kan starte på 30msec, eller skal vi ofre
et minut startop tid på at få en UNIX kerne med en lille samling omhyggeligt udvalgte værktøjer (tcpdump, debugger, [ksd]trace) ?

Men vi er helt sikkert i omegnen af "binde gale" når missionskritisk real-tids udstyr har grafiske brugergrænseflader med en browser åben og slet ikke vil starte op hvis de ikke kan finde deres keyboard eller mus[2].

[1] Grelleste eksempel jeg har set: En relativt triviel fjernstyringsopgave løst med VNC til en Windows maskine og effektueret via LabView/IEEE488. Maskinen havde også Office og AutoCad, fordi det var standardkonfigurationen hvis man skulle have LabView i det firma.

[2] Særligt så, hvis der ikke er en slavisk fulgt vedligeholdelsesplan for at udskifte CR2032 knapcellerne (også den i musen), regelmæssigt.

Christian Nobel

men desværre sniger Genstart ind flere steder.

Ja og det er det der er det skrækkelige, nemlig at de forgangne 35 år har gjort det til en naturlig del af tankesættet.

Og når PHK udtrykker det:

Det er, med andre ord, bygget helt uden hensyntagen til hvad vi har lært om konstruktion af den slags systemer de sidste 50 år.

Så er det jo desværre nok et udtryk for at vi intet har lært de sidste 50 år - tværtom.

Det ses jo også meget tydeligt i hvordan selv helt banale programmer, som i "gamle dage" ikke fyldte andet end et par KB, nu er mastodonter på flere MB, uden de nødvendigvis er blevet bedre.

En stor det af grunden kan så være at programmørerne ukritisk inkluderer monster libraries (som de ingen styr har på), fordi det er nemmere på den måde, end selv at lave en robust funktion på måske 10 linier.

Og på den måde går overblikket fløjten, og den kollektive fordummelse forfalder til paradigmet om at vi-kan-da-bare-stige-ud-af-bilen-og-gå-ind-igen.

Peter Kyllesbeck

Gid det var så vel, men mange overordnede systemer til industristyring er blevet 'opgraderet' fra *nix til Windows indenfor de sidste 10-15 år


Havde i slut 90'erne en SUN arbejdsstation til alt det daglige arbejde, administration, udvikling, test og support.
Den kørte uafbrudt i over et år uden genstart, og så var det kun pga strømafbrydelse, den blev genstartet. :-)

Poul-Henning Kamp Blogger

Så er det jo desværre nok et udtryk for at vi intet har lært de sidste 50 år - tværtom.

Det er simpelthen ikke rigtigt, vi har lært en masse, men flertallet i IT branchen har aldrig hørt om det.

IT branchen blev ca. 100 gange større i personer igennem 1990'ernes "dotCom" bobble og som hovedregel aner disse personer og dem der er kommet til senere ikke en dyt om hvad der skete eller hvad man lærte inden 1990.

Carsten Kanstrup

Det ses jo også meget tydeligt i hvordan selv helt banale programmer, som i "gamle dage" ikke fyldte andet end et par KB, nu er mastodonter på flere MB, uden de nødvendigvis er blevet bedre.

Ja, for ca. 35 år siden kunne jeg f.eks. styre PLC-delen af en foderstoffabrik med 400 automatisk styrede enheder og transportveje flettet ind mellem hinanden som sporene på Københavns hovedbanegård med 5 computere med hver en 2 MHz 8080, 6kB RAM og 8kB EPROM, der var intet at genstarte i én uendelighed, og pga. en effektiv eventorienteret struktur var responstiden typisk under 100 ms på trods af den meget lave clockfrekvens og 4, 5, 7, 10 eller 11 clockcycles pr. instruktion. Idag skal MIcrosoft bruge minimum 256 MB RAM, 2 GB FLASH og minimum en 400 MHz processor for at styre en kaffemaskine (Windows 10 IoT) - og så er det stadig uden grafik.

Det går den helt forkerte vej. Det vrimler med fejl og sikkerhedshuller i dagens IT systemer, fordi selv ikke de dygtigste programmører kan overskue de ekstremt komplekse systemer, de selv laver - godt hjulpet på vej af programmeringssprog som C, hvor man skal læse hieroglyffer i stedet for simpel engelsk tekst. "Any fool can write code that a computer understands. God programmers write code that humans understand".

Iøvrigt er jeg helt enig med PHK med hensyn til funktionssikkerhed og delvis enig med Mogens Hansen med hensyn til fejlsikkerhed.

Hvis det er nødvendigt at genstarte et system, uden at der skal installeres ny software, og uden at der kan udskrives en fejlrapport, så man har en chance for at rette fejlen, er det ganske simpelt dårligt design i stil med Microsoft's kendte "Unknown Error", og man kan kun vente på næste crash.

Der er til gengæld heller ingen tvivl om, at DSB gør, hvad de kan, for at skabe så stor fejlsikkerhed (personsikkerhed) som muligt. Man kan så spørge, om det er nok, når bremsefejlen på IC4 aldrig er fundet og ikke kunne reproduceres, og man oven i købet har set sig nødsaget til at udkoble bremsen på én aksel og dermed reducere bremsekraften med yderligere 10 % på IC4 og 17% på IC2; men her er vi nok inde i en hvepserede af ekstremt kompliceret software, hvor valget står mellem at feje problemet ind under gulvtæppet under dække af glatte skinner og håbe på, at folk tror på den forklaring, eller grounde hele IC4 flåden og lave det hele om ud fra KISS principper.

Og nej, det hjælper bestemt ikke på goodwill at computeren med "masser af robusthed" i IC4 ikke kan finde ud af at få en dieselmotor og en automatgearkasse til at arbejde sammen.

Her er vi også inde på spørgsmålet om funktionssikkerhed kontra fejlsikkerhed; men jeg vil give PHK ret i, at når man med al ønskelig tydelighed har demonstreret sin uduelighed ved ikke engang at kunne få sammenkoblingen til at virke eller har kunnet styre en simpel automatgearkasse, har jeg ikke meget tiltro til, at den samme (software)afdeling kan lave et sikkerhedssystem.

Christian Nobel

Det er simpelthen ikke rigtigt, vi har lært en masse, men flertallet i IT branchen har aldrig hørt om det.

Ja, hvis "vi" går på dig og mig, samt en lille eksklusiv skare som måske er at finde herinde, så har "vi" nok lært en masse (og stadig synes jeg at jeg lærer noget nyt hver dag).

Men hvis vi betragter "vi" som en kollektiv homogen betragtning af alle dem der udgør "IT-branchen", så vil jeg nok mene at "vi" har ikke lært ret meget - og da beslutninger jo som regel tages ud fra "vi" nr. 2's begrebsverden, ja så har vi miseren.

Poul-Henning Kamp Blogger

Her er vi også inde på spørgsmålet om funktionssikkerhed kontra fejlsikkerhed

Hvilket meget ofte bliver overset i disse lean-outsourcing-grønthø^H^H^H^H^H^Hrationaliserings tider.

Hvis man f.eks nogensinde skal evakuere København eller en af de store provinsbyer fordi en lastvogn er væltet med det periodiske system skal jernbanen kunne virke og det nytter ikke at de lige skal bruge et par timer på at genstarte signalsystemet med evakueringskonfigurationen.

Finn Glamhøj

Det går den helt forkerte vej. Det vrimler med fejl og sikkerhedshuller i dagens IT systemer, fordi selv ikke de dygtigste programmører kan overskue de ekstremt komplekse systemer, de selv laver - godt hjulpet på vej af programmeringssprog som C, hvor man skal læse hieroglyffer i stedet for simpel engelsk tekst.

Det er jeg ikke enig i. Jeg mener ikke det er sproget der er årsagen, men viljen/evnen til at lave et robust design til at starte med.

Det er designet og ikke sproget der afgøre om man kan få afluset et program og dermed gjort det robust. Et godt design betyder, at man kan rette fejl uden at indføre nye og dermed over tid få gjort det robust/stabilt.

Carsten Kanstrup

C tillader ikke anvendelse af UniCode i identifiers eller reserverede ord.

De sidstnævnte er forresten alle simple engelske ord.

Hvem snakker om UniCode? Engelsk syntaks som i Visual Basic, de nyeste versioner af Fortran og tildels også Python er meget lettere at forstå og overse for hjernen end C-stil. Prøv bare at læse C kode op. Hver eneste gang, du møder hieroglyffer som f.eks. ==, & ! etc. skal du oversætte det til engelsk for at udtale det. Hvorfor ikke i stedet skrive som vi taler og tænker? Desuden har man besværet med at huske alle de semikolon ";" og tuborgparenteser "{}", og null-terminerede strenge har fanden skabt i sin vrede. Nørderne elsker det, for i C kan de skrive konstruktioner, som ingen andre end dem selv forstår, og så kan de rigtig vise, hvor dygtige de er; men der har aldrig været så mange fejl i IT systemer som nu, og jeg vil give C stilen en del af skylden, da den fører til manglende overblik - ikke mindst for andre, der senere skal servicere koden eller godkende den.

Og Når der virkelig skal skrives pålidelig kode, er det forresten næsten altid C man bruger til det.

Ja, men man har normalt heller intet andet valg - ikke mindst ved embedded programmering, hvor det ofte er det eneste højniveausprog, der er understøttet. Alternativet er assembler, som ikke har udviklet sig de sidste 40 år, selvom syntaksen sagtens kunne opgraderes til en form for primitivt, men super effektivt højniveausprog. MOV A, B kunne f.eks. lige så godt skrives B = A, og IF-ELSE-ENDIF, DO-WHILE og lignende konstruktioner kan let oversættes til tests, labels og hop.

Finn Glamhøj

Engelsk syntaks som i Visual Basic, de nyeste versioner af Fortran og tildels også Python er meget lettere at forstå og overse for hjernen end C-stil. Prøv bare at læse C kode op. Hver eneste gang, du møder hieroglyffer som f.eks. ==, & ! etc. skal du oversætte det til engelsk for at udtale det. Hvorfor ikke i stedet skrive som vi taler og tænker? Desuden har man besværet med at huske alle de semikolon ";" og tuborgparenteser "{}"

Det er en vanesag at foretage denne oversættelse i hoved og ikke noget man behøver programmere særlig ofte i C for at huske.

Da editoren jeg anvender fortæller mig når der mangler et semikolon eller tuborgparanteser, hvis ikke direkte så indirekte, er det ikke noget jeg først finder ud af på oversættelsestidspunktet og derfor er det heller ikke et stort problem og under alle omstændigheder ikke noget der får indflydelse på programkvaliteten.

Ja, men man har normalt heller intet andet valg - ikke mindst ved embedded programmering, hvor det ofte er det eneste højniveausprog, der er understøttet.

Det er der nok en grund til.

Med C har man mulighed for en stor grad af kontrol over den resulterende kode, hvilket ofte er nødvendigt i indlejret programmer på grund af begrænset ressourcer.

Jo højere abstraktionsniveau som sproget tilbyde (og som man anvender) jo mere overlader man ansvaret til kompiler/fortolker konstruktøren og det kan måske være en af årsagerne til programmer fylder så meget i dag i forhold til tidligere, fordi programmøren i dag ikke længere har ansvaret for effektiviteten i samme grad som før.

Glenn Møller

Nye togsignaler er ikke testet: Minister var advaret:
https://ing.dk/artikel/nye-togsignaler-er-ikke-testet-minister-var-advar...
"...For det første er ERTMS ikke færdigspecificeret..."

Hvorfor har man ikke satset på ERTMS-2 (senere ERTMS-3) til både S-tog og fjerntog, så man kun skal have udfordringer med ét system - reservedele - og optræning?:
https://da.wikipedia.org/wiki/European_Rail_Traffic_Management_System

CBTC-teknologi skal få flere S-tog på skinnerne:
https://ing.dk/artikel/cbtc-teknologi-skal-fa-flere-s-tog-pa-skinnerne-1...
"...
»Det er meget nemmere at vedligeholde et radiobaseret system med få dele i sporet. Og så er det opbygget redundant, så pålideligheden er høj,« siger Steen Nørby Nielsen.
..."

Signalproblem: S-tog ‘forsvinder’ på Hillerødbanen:
https://ing.dk/artikel/signalproblem-s-tog-forsvinder-paa-hilleroedbanen...

Martin Wolsing

IT branchen blev ca. 100 gange større i personer igennem 1990'ernes "dotCom" bobble og som hovedregel aner disse personer og dem der er kommet til senere ikke en dyt om hvad der skete eller hvad man lærte inden 1990.

Hvis skyld er det? Det er vel næppe IT-folkene selv. Det må være deres uddannelse den er gal med. Eller manglen på samme. IT-branchen er et af de få steder, hvor man kan nå langt uden nogen uddannelse overhovedet.

Finn Glamhøj

Ja, den simple at C er blevet de-facto standard.

Jeg er i virkeligheden ligeglad med om det er standard eller ej, hvis du kan anbefale et sprog, hvormed man kan realisere det samme som med C, bare lettere/bedre, så sig frem, jeg er meget interesseret.

Hvilket sprog vil du anbefale til brug for programmering af mikrokontroller med få ressourcer? Eksempelvis 8 bit mikrokontroller med 1-4 KB RAM.

Finn Glamhøj

Det må være deres uddannelse den er gal med. Eller manglen på samme. IT-branchen er et af de få steder, hvor man kan nå langt uden nogen uddannelse overhovedet.

Eller også er det deres indstilling.

Jeg arbejdede på et tidspunkt sammen med en civilingeniør som på spørgsmålet om, hvad det hans måde at løse et problem på, havde af betydning for effektiviteten af programmet, svarede, hvis det ikke køre hurtig nok så må kunden bare købe en hurtigere computer.

Carsten Kanstrup

Jeg er i virkeligheden ligeglad med om det er standard eller ej, hvis du kan anbefale et sprog, hvormed man kan realisere det samme som med C, bare lettere/bedre, så sig frem, jeg er meget interesseret.

Det kan jeg desværre ikke - gid jeg kunne. Måske Python en dag kunne blive et alternativ, hvis det kommer i en version, som kan kompilere direkte til effektiv maskinkode og ikke bare byte kode.

Hvilket sprog vil du anbefale til brug for programmering af mikrokontroller med få ressourcer? Eksempelvis 8 bit mikrokontroller med 1-4 KB RAM.

Her kunne højniveau assembler være en mulighed - hvis altså assemblerprogrammering havde udviklet sig det mindste de sidste 40 år :-( Som det er nu, er der ikke rigtigt noget alternativ til C, selv om man ved 1-4 kB RAM har brug for absolut maksimal effektivitet - og iøvrigt en langt mere effektiv, stakorienteret mikroprocessorarkitektur, end vi ser idag.

Når jeg en sjælden gang skriver assemblerkode til noget, der skal have maksimal effektivitet, er alle mine kommentarer struktureret som et højniveausprog, hvor hver enkelt statement direkte oversættes til assemblerkode således at f.eks. kommentaren ELSE bliver et jump efterfulgt af en label; men det ville være rart, hvis det skete automatisk, så man reelt set kunne nøjes med kommentarerne og dermed få velstruktureret kode, som samtidig kørte med absolut maksimal effektivitet.

Mogens Hansen

Du får det til at lyde som om denne procentdel kun er 1 eller måske 2 ?


Du hører tydeligvis hvad du vil.

I virkeligheden udgør IT ca. 95 procent af alt det der kan gå galt i de nye signalsystemer: Selv signalbehandlingen i radiosenderne og -modtagerne er software-baserede.


Hvis man stikker vat i ørerne og holder sig for det ene øje så man udelukkende ser IT aspekterne, så er det rigtigt at der er 95% IT.
Hvis man derimod har sat sig en smule ind i mængden af sporskifter, overkørsler, akseltællere, bygninger, fremførsel af strøm og signaler, manualer og procedurer, træning og ca. tusind andre ting som skal udvikles/monteres/fremføres som en del af signalprogrammet, så risikerer man at få en mere nuanceret forståelse af sagen.

Jeg håber på at arkitekten (er der overhovedet en ?)


Nej, naturligvis er der ingen arkitekt. Dét er der ingen som har overvejet. Heldigvis har vi til gengæld en masse bedrevidende personer som kan sidde i deres elfenbenstårne og pisse på resten, mens de peger på bøger de en gang har læst.

"Jeg skrev præcist hvad jeg mente med robusthed."
Du skrev "masser af delsystemer i toget". Det er ikke præcist.


Her er lidt læsevejledning: Jeg skrev "Der er masser af robusthed i systemet, *når det gælder om at holde folk i live. *". Det kræver ganske vist at man når hele vejen til enden af sætningen for at få det hele med. Men det er naturligvis sjovere at klippe den halvt over, og så banke folk oven i hovedet med en tekst der er taget ud af kontekst - så vidt jeg kan tælle, 4-5 gange indtil videre.

"Hvor har du læst at en sådan udredning ikke vil finde sted?"
Jeg er blevet forsikret om at den ikke vil komme til offentlighedens kendskab, fordi "visse leverandører" har krævet den slags under NDA og at Bane.DK's ledelse heller ikke ser nogen værdi i at "hænge vasketøjet ud".


Det skægge her er, at du beskylder os andre for tågesnak og hand-waving. Men det er OK at dine egne påstande kommer fra nogen der har hørt nogen sige at...
I øvrigt var din påstand at der slet ikke ville være nogen udredning. Nu er det blevet til, at der vil være en, men den vil ikke blive offentliggjort. Der er da f... til forskel på de to ting.

Som gennemsnitsbetragtning bliver hvert relæ-lignende funktion i det gamle signalsystem erstattet af ca. 100.000 linier kildetekst i det nye system.


Bullshit.

Jeg må indrømme en vis fascination af at læse dine indlæg. Jo mere man læser, jo mere går det op for en, at du ved så lidt om signalsystemer, at du end ikke ved, hvor lidt du ved som en anden konspirationsteoretiker. Og på helt samme vis kaster du om dig med vilde påstande og løber ud af en tangent, hver gang du bliver modsagt.

Jeg vil følge den videre udvikling med stor interesse. Men skal nok holde mund herefter. Over and out.

Peter Kyllesbeck

S-tog Hellerup - Lyngby ca 12 millioner rejser.
På strækningen Hellerup - Holte: Høj kapacitetsudnyttelse.

Roskilde - Ringsted ca 15 millioner rejser,
På strækningen Ringsted - Slagelse: Middel kapacitetsudnyttelse.

Se mere her ( også om Opgradering Lyngby-Hillerød(2014) )

https://www.trm.dk/~/media/files/publication/2012/traengselskommission/5...

Poul-Henning Kamp Blogger

Mogens,

Jeg må give dig 100% ret i at det næppe nytter noget at fortsætte "dialogen".

Jeg håber at du trods alt er nysgerrig nok til at læse de to kilder jeg linkede til ovenfor...

Glenn Møller

Det kan jeg desværre ikke - gid jeg kunne. Måske Python en dag kunne blive et alternativ, hvis det kommer i en version, som kan kompilere direkte til effektiv maskinkode og ikke bare byte kode.

?:
https://micropython.org/
"...
Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM.
...
MicroPython is written in C99 and the entire MicroPython core is available for general use under the very liberal MIT license.
..."

https://github.com/micropython/micropython

Kjeld Flarup Christensen

Ikke fordi jeg vil hænge mine kolleger i kundeservice ud, men de er nok mere tilbøjelige til at kræve en genstart i stressede situationer end jeg er.

Jeg skal ikke udelukke at det kan være på ordre oppefra, at Signalsystemet blev genstartet. Det er som tekniker svært at koncentrere sig om at finde fejlen, når der er et stort pres på en hurtig løsning.

Og jeg vil faktisk håbe at de ikke er teknikerne på gulvet der i begge tilfælde har beordret genstarten, for en genstart har også konsekvenser.
Jeg kalder mig for teknisk chef, så jeg kan tillade mig at gøre det, men det står ikke øverst på min liste, fordi jeg har andre muligheder.

Poul-Henning Kamp Blogger

Det er som tekniker svært at koncentrere sig om at finde fejlen, når der er et stort pres på en hurtig løsning.

Det er netop her kæden hopper af for mig.

Vi taler om et system der kan fuldt udrullet hver dag skal flytte over 100.000 personer rettidigt til arbejde, studie, lægeundersøgelse, retssager, brylluper og begravelser.

Hvis det var mig der skrev kravspecifikationen, ville et af de første tekniske krav være at systemet skulle kunne bringes i drift fra en vilkårlig tilstand der ikke involverede mere end X hardware fejl, på max Y sekunder og det være helt OK hvis man gjorde det ved at tage hovedafbryderen til hele systemet i 10 sekunder.

I det foreliggende tilfælde er det tydeligt at:

  1. Hvis der var et sådant krav, var det ikke gennemtestet eller opfyldt.

  2. Forsøget med at genstarte systemet som fejlretning var et totalt skud i tågen.

  3. Genstarten virkede ikke.

Punkt 1 fortæller os at det var skrivebordsgeneraler uden forstand på komplexe systemers fejlmåder og fejlkilder der skrev kravene eller skrev under på testrapporternes varianser.

Punkt 2 fortæller os at ingen forstod hvad der foregik i denne situation og det dermed har vi existensbevis for at systemet er for komplext eller fejlfyldt til drift her og nu.

Punkt 3 fortæller os at heller ikke dem der har bygget systemet har noget at være stolte af.

Så ja, med en S-togs linie ude af drift er der helt sikkert blevet lagt press på teknikerne for at få det i luften igen - som der skal være - men bagefter, nu, er der brug for at en uafhængig og neutral instans går ind og finder ud af hvordan vi forhindrer det i at ske igen - i dette projekt og andre.

Jeg håber inderligt at havarikommissionen for jernbanen opfatter dette som noget der ligger under deres resort og giver os den offentlig tilgængelige rapport.

Hvis ikke, vil jeg gentage at i jeg øvrigt mener at vi skal have en IT havarikommission.

Ole Laursen

Og Når der virkelig skal skrives pålidelig kode, er det forresten næsten altid C man bruger til det.

Det er fint at du er glad for C. Det er der mange der er, og med god grund, i hvert fald hvis man kigger på sproget og ignorerer standardbiblioteket for en stund.

Men ovenstående udsagn er altså ikke rigtigt. Faktisk har tendensen de sidste mange år været at man forsøger at kommer væk fra C når det gælder programmer der tager mod input udefra, f.eks. browsere. Fordi det er for svært at undgå fejl der fører til sikkerhedshuller når man jonglerer med pointere.

Mange af de "pålidelige" indlejrede systemer skrevet i C der har kørt i mange år er utvivlsomt trivielle at hacke. Jeg følger en blog skrevet af en der morer sig med at crashe IoT-ting som fjernstyrede lyspærer, det plejer ikke at tage ham lang tid at finde et hul.

Jn Madsen

Det var f.eks således man i starten af 1960'erne designede de første computerstyrede telefoncentraler

Hov !!! Der vågnede jeg :-)

Med et par årtier + en sjat i statens telekommunikation, har jeg blandede følelser her.
Jeg husker tilbage på tiden med "håndværk", tingene blev testet til de var en ulmende bunke aske på gulvet. Nultolerance over for fejl. Systemer skulle boote og korrigere for fejl så hurtigt, at kunderne ikke ville opdage noget.

I kan godt grine af - og tilsvine de "gamle" telefonselskaber vi havde. De havde absolut også problemer med "kunde-venlighed", men hold da op, der var styr på teknikken.
Jeg var i transmissions-teknikken (PDH og SDH). Systemerne skulle detektere og korrigere for fejl inden 50 for millisekunder,- f.eks. ved overgravede fibre.

Godt man nåede at opleve faglig stolthed inden det gik af mode.

Poul-Henning Kamp Blogger

Mange af de "pålidelige" indlejrede systemer skrevet i C [...]

Jeg tror ikke vi taler om de helt samme problemer.

Ja, der er meget skod for man kan skrive skodkode i alle sprog og der er ikke skyggen af produktansvar på software.

Men når folk skal skrive rigtig højpålidelig kode, rumfartøjer, fly, biler og den slags, er det stadig C (Herunder C++) der dominerer totalt.

Flemming Riis

udover det er nemt at give windows skylden , da det jo er windows

Hvis PSU på maskinen døde var det vel samme problem , hvis der kun er en kan man ikke stole på den , så logikken kan ikke kun ligge et sted

Men udover det så kbh lufthavn nu på 4rd uge med en windows baggrund på en infomations stander , hvis ting skal køres embedded skal det konfigurers / overvåges rigtigt (og være stabilt)

Jens Jönsson

Gid det var så vel, men mange overordnede systemer til industristyring er blevet 'opgraderet' fra *nix til Windows indenfor de sidste 10-15 år


Der er ufatteligt så mange 95/97/XP systemer derude, som er koblet til styring af "alt muligt"....
De er da mere end 15 år gamle mange af dem :-(

Personligt har jeg for en del år siden isoleret ret så mange bag en firewall, sådan at de ikke blev ramt af de dengang huserende "orme" (Ja, rigtigt mange år siden)
Gad vide hvor mange af dem der kører endnu. Mit gæt er ret så mange, desværre, efter snak med gamle kollegaer.
Hører tit om problem med udskiftning af defekt IDE harddisk (Hvor mange år er det ikke lige vi har haft SATA ?).

Jeg får det helt dårligt af at tænke på det....

I mange år var beskeden: "Prøv lige en genstart for at se om det ikke hjælper"....

Kjeld Flarup Christensen

ville et af de første tekniske krav være at systemet skulle kunne bringes i drift fra en vilkårlig tilstand der ikke involverede mere end X hardware fejl, på max Y sekunder og det være helt OK hvis man gjorde det ved at tage hovedafbryderen til hele systemet i 10 sekunder.


Set udefra er jeg sådanset enig, det er trods alt et begrænset domæne, der opereres indenfor. Jeg ved dog fra min egen verden, at mine telefoncentraler ikke er alene, der er titusinder af telefonapparater og mennesker, som indgår i et dynamisk system med dem. Og de rebooter ikke på min kommando.
Så der er ikke altid et designkriterie som giver mening, men selvfølgelig kan mine centraler genstartes og bringes i en kendt tilstand i løbet af et halvt minut.

Men heller ikke mere end en kendt tilstand, hvad der sker derefter er oftest jokeren.

Der er selvfølgelig også himmelvid forskel på om det er et system der har kørt upåklageligt i lang tid, eller om det er et nyt system som lige er rullet ud. Det er nok det sidste der aktuelt er problemet med signalsystemet. Det er et klassisk tilfælde af "software møder virkeligheden".

Hvis der var et sådant krav, var det ikke gennemtestet eller opfyldt.


Det kan sagten både eksistere og være opfyldt.
Og hvis det er, vil en skrivebordsgeneral naturligvis kræves at der trykkes på knappen.

Punkt 2 fortæller os at ingen forstod hvad der foregik i denne situation og det dermed har vi existensbevis for at systemet er for komplext eller fejlfyldt til drift her og nu.


Det ved vi jo ikke ret meget om.

En test er desværre ikke bedre end den model man har af verden. Og software til en telefoncentral, kan man ikke endeligt sige er fejlfri, før det har overlevet tirsdag efter påske præcis kl. 8, hvor ALLE skal ringe til lægen og andre efter at de har holdt lukket i mindst 5 dage. Det er et scenarie man kan loadteste, men testen følger altid nogle regler. Det gør virkeligheden ikke.

Der kan sagten sidde en udvikler og pege på hvad der går galt, hvordan virkeligheden snyder testen. Han skal blot lige lave en rettelse i systemet, tilføje en case eller to til testen og køre testen inden han kan lægge den i produktion, og det med risiko for at der introduceres nye fejl.

I sidste ende er genstarten et udtryk for management og ikke så meget for systemudvikling.
Hey vi forsøgte da at gøre noget - og det plejer da at virke med din PC ikke!

PS: Vores telefoncentraler kører naturligvis stabilt takket være 10 års erfaring med virkeligheden.

Kjeld Flarup Christensen

Tror du "software-producenterne" og "kontrakt underskrivere" gider læse og lære af IT havarikommissionens rapporter?

Det virkede med luftfart og jernbaner...


Jeg vil da gerne koge samtlige rapporterne ned til følgende:

  • Projektets tidsramme var for langt fra start til praktisk anvendelse.
  • Det var ikke muligt at køre nye og gamle systemer parallelt, hvorfor det var et alt eller intet skifte.
  • Der var for meget fokus på nye funktionaliteter, og for lidt på eksisterende funktionaliteter
  • Der var for mange brugere som på en gang skulle tage et nyt system i brug.
  • Der indgik for få standardværktøjer.
    Og jeg kan sikkert blive ved.

Strengt taget er havarikommisionerne spild af tid, de vil ikke afdække noget væsentligt nyt.

Omvendt hvis det er det som kan få folk til at lytte, om ikke andet når der i en havarirapport henvises til at man har gentaget fejl nævnt i en tidligere havarirapport. Jeg har dog mine tvivl, fordi de her ting allerede er kendt viden i dag.

Og forskellen til luftfart er indlysende, et fly er et "standard" produkt, som man kan stille krav til. Lidt det samme med jernbaner. Der går en feedback til et specifikt produkt.

Offentlige software projekter er derimod unikke fra gang til gang. Derfor kan havarirapporter ikke direkte kobles op på dem. Man kan kun konstatere at best practice ikke overholdes.

Malthe Høj-Sunesen

Jeg sidder i øjeblikket i et IC4-tog på vej fra Odense til København. Vi fik følgende besked for nogle minutter siden: "Ja, mine damer og herrer, vi har et problem med en computer i det forreste togsæt som falder ud. Vi prøver at genstarte den og kører så videre igen. Jeg regner ikke med at der går mere end 5 minutter."

Toget holder i Korsør. Jeg kan se ikke-lyntoget holder på modsatte perron - og det betyder, at "lyntoget", som jeg sidder i, bliver fanget og mindst en halv time forsinket.

Fordi en computer "falder ud". Under kørsel.

Mads Asbjørn

Kunne man ikke overtale en ing.dk/v2.dk journalist til at lave en mere systematisk gennemgang af driftstabiliteten på S-togs (Hillerødbanen) f.eks. ved at sætte journalisten med toget hver morgen i myldretiden i et par uger. Så kan vi få det dokumenteret hvor elendigt togene kører. Jeg tager toget hver morgen mellem Hillerød og Lyngby og det kører horribelt (det ord dækker det ikke engang).

Ikke engang deres informationssystemer virker særlig stabile - enten bliver man spammet med beskeder eller også får man intet at vide, og det gælder også deres apps og SMS system.

/Mads

Martin Bøgelund

Kunne man ikke overtale en ing.dk/v2.dk journalist til at lave en mere systematisk gennemgang af driftstabiliteten på S-togs (Hillerødbanen) f.eks. ved at sætte journalisten med toget hver morgen i myldretiden i et par uger. Så kan vi få det dokumenteret hvor elendigt togene kører. Jeg tager toget hver morgen mellem Hillerød og Lyngby og det kører horribelt (det ord dækker det ikke engang).

Kunne man ikke overtale dig til at notere de fejl du oplever ned i en notesbog, og så efter en måneds tid sende notesbogen til v2/ing?

Der er vel ingen grund til at bruge journalist-tid på data-indsamling, når du allerede er på stedet, og er motiveret for at få problematikken belyst?

Lasse Mølgaard

Hører tit om problem med udskiftning af defekt IDE harddisk (Hvor mange år er det ikke lige vi har haft SATA ?).

Ha! Her kan jeg være med. I det mindste når vi snakker servere.

Jeg har før sat servere op, som endte med at være småsenil, når man kaldte uptime. Serveren blev kun skiftet ud fordi blæsernes lydstyrke var steget til 70-80 dB. :-)

Peter Rosenberg

ADA, blev nævnt, ligesom Operativ Systemer (Windows), C, C#, Python, VisualBasic etc...
Nu kunne jeg være spydig, ikke overfor Jer der skriver her, men forklar mig lige hvorfor der opstår ca 50-100 nye programmeringssprog hver decade (se evt: https://en.wikipedia.org/wiki/Timeline_of_programming_languages#2000s) ?
Mit bud, ikke på mit retoriske spørgsmål, men på Robusthed, er:
- Programmører starter ikke med at programmere fra BIOS og opefter, de regner med et vist basalt grundlag er tilstede (OperativSystem eller OS) .
- Hvis programmører ikke kender dette OS, så vil de blive lokket til at tro på API'erne fra OS-leverandøren er fejlfrie og sågar robuste.
Det er her 'filmen knækker', og derfor ser utallige forsøg (sprog) der forsøger at udbedre den manglende agilitet, robusthed osv. i det underliggende OS !

I kender det alle sammen fra "gamle dage": Hvorfor kan man ikke kode imod en Access Database OG en Mainframe (DB2, IMS etc) , og lade en Transaction opnå atomicitet ?
Nemlig, det underliggende lag giver ikke flere frihedsgrader fordi man koder med noget nemt ovenpå, snarere tværtimod.
Så skip snakken om sprog, indtil man skaber robusthed i OS og den underliggende Hardware.

Carsten Kanstrup

Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM.
...
MicroPython is written in C99 and the entire MicroPython core is available for general use under the very liberal MIT license.

Men kan vel stadig ikke generere maskinkode?

MicroPython is written in C99

Det er svært ikke at smile lidt... :-)

Ja, men det skyldes vel netop, at MicroPython ikke kan generere maskinkode? Der et intet 100% interpreterende sprog, der kan generere sin egen fortolker.

Peter Rosenberg

Præcis PHK ! (du så mit spm var retorisk, håber jeg)
Så man kan IKKE lave et programmeringsprog der 'omgør' et system på et mindre robust OS til en robusthed der er stærkere end det svageste led (i OS'et) det er bygget på.
ADA, hvis vi skal snakke om eet, prøvede at skabe denne vel-afgrænsede lag-på-lag model, men kan ikke omgøre et dårligt OS eller HW for den sags skyld.

Christian Nobel

Som jeg ser det, så er det jo primært den nu engang udviklede compiler og de tilgængelige libraries der definerer anvendeligheden af et programmeringssprog.

C kunne for den sags skyld sagtens have en meget mere letlæselig syntaks ala Pascal, det er kun et spørgsmål om hvordan compileren fortolker koden ved gennemløb.

Så det er nok primært historisk betinget at hvilken vej de to værktøjer, som i øvrigt har fælles forfader i Algol, har bevæget sig - men der er intet til hinder for at man kan lave et højniveausprog med høj læsbarhed (og at pointe sig direkte ned i helvede er ikke noget jeg anser for specielt intelligent).

Carsten Kanstrup

Så skip snakken om sprog, indtil man skaber robusthed i OS og den underliggende Hardware.

Sprog handler med henblik på robusthed om én eneste ting - bedst mulig interface til den menneskelige hjerne, så man får det bedst mulige overblik. Som jeg skrev tidligere: "Any fool can write code that a computer understands. God programmers write code that humans understand."

Når jeg programmerer FPGA'er gør jeg det i hierarkisk grafik (ViewDraw), da det giver langt det bedste overblik. Hjernen er først og fremmest grafisk orienteret - vi kender alle talemåden: "Én tegning kan forklare mere end 1000 ord." Ikke ti vilde heste skal få mig over på tekstbaseret VHDL, Verilog eller hardware-C, selvom det er det, "man gør", for så ville jeg aldrig nogensinde kunne garantere robusthed i de ting, jeg laver (bl.a. med dual-phase clock overalt), og med asynkrone netværk med over 5000 gates ville jeg have mistet overblikket for længst.

Med hensyn til robusthed i OS forstår jeg ganske simpelt ikke, at sikkerhedsoperativsystemer til en fornuftig pris, som f.eks. SafeRTOS, ikke har fået langt mere udbredelse, end de har. Det kan da godt være, at systemet ikke skal sikkerhedsgodkendes efter f.eks. IEC 61508; men det er meget nemmere at debugge en fejlsituation, når man har garanti for, at én task aldrig nogensinde kan smadre, stoppe eller blokkere andre, og det er guld værd, hvis kun dele af programmet skal legal godkendes, som f.eks. målesystemer. Desuden er et sikkerhedsOS langt mindre følsomt over for hackerangreb etc., da man jo f.eks. bare kan lade al harddiskaccess gå via en sikkerhedstask. Giv mig bare én god grund til, at f.eks. en tilfældig hjemmeside skal have lov til at installere software på min computer uden mit vidende! Det var aldrig sket i "de gode gamle dage"; men idag sættes standarden af nørder uden jordforbindelse, som så bare lader det være op til 3. part i form af f.eks. antivirusprogrammer at korrigere for deres manglende evner og overblik. Jeg fatter ikke hvad folk vil med diverse UNIX varianter, som bl.a. har verdensrekord i brugerfjensk interface i form af f.eks. de talrige -xx kommandoer, som kun nørderne kan huske, og desuden er en formiddag om at starte op. Der er ialtfald ikke noget, der hedder genstart på 50 ms.

Med hensyn til hardware kan man f.eks. skabe robusthed med de moderne lock-step computere, hvor to, tidsforskudte og spejlede kerner eksekverer den samme kode og løbende sammenlignes, og hvor der normalt også er fejldetektering på RAM.

Det ene udelukker ikke det andet.

Peter Rosenberg

Tak Carsten K. jeg er enig, men nu inkluderer du også IDE'er hvilket jeg ikke har omtalt eller sågar noget imod.
Det er et helt emne for sig, især når man kryber op ad software stakken (får vi CASE igen en dag ?). IDE'er handler nemlig om Maintainability , på godt dansk-engelsk, og er en meget vigtig komponent når man skal beslutte sig for et vilkårligt sprog.
POSIX, den kerne del af UNIX der vist blev ISO certificeret (efter min hukommelse), ville kunne have udviklet sig til en OS standard, som f.eks. på Linux ville have skabt en OS standard der måske (set i bagklogskabens lys) kunne have minimeret det utal af varianter vi ser idag. MEN, sådan gik det ikke.

Poul-Henning Kamp Blogger

POSIX, den kerne del af UNIX der vist blev ISO certificeret (efter min hukommelse), ville kunne have udviklet sig til en OS standard [...]

Posix er en OS standard, der på alle leder og kanter blev modarbejdet og undergravet af store firmaer som IBM, Microsoft, Sun, HP, DEC der alle satsede på at låse kunderne fast med proprietære kerne-API'er.

Som sagt: Markedsfejl.

Peter Rosenberg

PHK, er svaret at standarder ikke skal udvikles af firmaer (eller deres lobbyister) - da disse altid er drevne af andre motiver end robusthed og matematikkens (dvs logikkens) skønhed ?

Finn Glamhøj

Sprog handler med henblik på robusthed om én eneste ting - bedst mulig interface til den menneskelige hjerne, så man får det bedst mulige overblik.

Det er jeg ikke enig i. Jeg mener, at du med din holdning til sprog, simplificere mere end godt er.

Programmeringssprog handler også om abstraktionsniveau. Jo højere abstraktionsniveau jo nemmere er det at udtrykke det som man ønsker udført, men der er en pris som man må betale, hvilket er, at man som jeg tidligere har nævnt, overlader mere af ansvaret til kompiler/fortolker konstruktøren og man derfor nemt kommer til at glemme overvejelserne vedrørende effektivitet etc. fordi det er jo noget kompiler/fortolker tager sig af.

Når jeg programmerer FPGA'er gør jeg det i hierarkisk grafik (ViewDraw), da det giver langt det bedste overblik. Hjernen er først og fremmest grafisk orienteret - vi kender alle talemåden: "Én tegning kan forklare mere end 1000 ord." Ikke ti vilde heste skal få mig over på tekstbaseret VHDL

Her er jeg heller ikke enig, omend jeg er enig noget af vejen.

Grafisk repræsentation kan være en rigtig god måde at udtrykke sig på til nogle opgaver, hvorimod tekst er at foretrække til andre. (jeg programmerer ikke FPGA’er, men en gang i mellem PLC’er).

Det ene udelukker ikke det andet.

Hvilket også gælder programmeringssprog og metoder.

Christian Nobel
Poul-Henning Kamp Blogger

PHK, er svaret at standarder ikke skal udvikles af firmaer (eller deres lobbyister) - da disse altid er drevne af andre motiver end robusthed og matematikkens (dvs logikkens) skønhed ?

Jeg tror svaret er lovgivning der er resource-fokuseret men teknologineutral.

F.eks kunne EU med stor fordel beslutte noget i stil med:

"Inden 2019 designer industrien fem størrelser udskiftelige opladelige batterier på markedet, de skal spænde hele området fra fra lommedimser over laptops, skruemaskiner til elcykler. Alle fem design skal være open hardware og gratis at bruge for alle. Fra 2020 bliver alt udstyr og alle batterier med ikke standardiserede batterier belagt med 400% afgift."

Tilsvarende kan man rydde op i software-junglen, men det tager mere end fire linier og et eksempel vil her på v2 bare føre til pindehuggeri over den anvendte stråmand.

Finn Glamhøj

Men den ulykke er allerede sket i C, hvor der jo er en stor afhængighed af hvordan kompileren samt libraries opfører sig - og når denne ulykke så alligevel er sket, hvorfor så ikke gøre tingene mere læsevenlige, det kan jo så afstedkomme at andre ulykker ikke sker.

Abstraktionsniveauet i sproget C er ikke synderlig højt og kompileren overlades ikke opgaven at afgøre hvad der menes med en given konstruktion i nævneværdig grad (der er stor overensstemmelse mellem betydningen af en C konstruktion og den kode der genereres), men bibliotekerne er en anden sag som de altid er, hvilket jo som bekendt kan løses:

En stor det af grunden kan så være at programmørerne ukritisk inkluderer monster libraries (som de ingen styr har på), fordi det er nemmere på den måde, end selv at lave en robust funktion på måske 10 linier.

Pascal (som du ynder) er umiddelbart mere læsesligt end C, men den del er næppe det som giver anledning til fejl hos andre end de der er meget uøvet i programmering – det er i min opfattelse mest af alt et spørgsmål om vane.

Jeg er ikke fundamentalist udi programmeringssprog (eller andet), men jeg har naturligvis vaner som de fleste andre og det giver min selvfølgelig nogle præferencer.

Carsten Kanstrup

Det er jeg ikke enig i. Jeg mener, at du med din holdning til sprog, simplificere mere end godt er.

Programmeringssprog handler også om abstraktionsniveau. Jo højere abstraktionsniveau jo nemmere er det at udtrykke det som man ønsker udført, men der er en pris som man må betale, hvilket er, at man som jeg tidligere har nævnt, overlader mere af ansvaret til kompiler/fortolker konstruktøren og man derfor nemt kommer til at glemme overvejelserne vedrørende effektivitet etc. fordi det er jo noget kompiler/fortolker tager sig af.

Generelt set er et højt abstraktionsniveau en fordel med mindre man skal programmere meget små systemer, hvor absolut maksimal effektivitet er et must. Jo større systemerne bliver, jo sværere bliver det at bevare overblikket, og man kan let lave fejl. I f.eks. C#.Net skal man selv huske at foretage et check for en null-delegate, når man ønsker at "raise" en event, og huske at gøre det i en temporer variabel, hvis man bruger multitasking. Det glemmer langt størsteparten af programmørerne, hvorved de afleverer en tidsindstillet bombe. I VB.Net sker det automatisk som vist nedenfor, hvilket skaber robusthed:

   RaiseEvent MyInstance.MyEvent(AnyData)  

erstattes i VB automatisk med:

   Dim TempValue As MyEvent = MyInstance.MyEvent  
   If (Not TempValue Is Nothing) Then  
       TempValue.Invoke(AnyData)  
   End If

Når man én gang har fundet den "skudsikre" måde at gøre noget på, kan man lige så godt indføre det i sproget.

(jeg programmerer ikke FPGA’er, men en gang i mellem PLC’er)

Og du mener ikke, at hierarkisk, grafisk programmering er en kæmpe fordel ved en PLC?

Jeg har beskæftiget mig med elektronisk proceskontrol i over næsten 40 år og er af en noget anden mening! Med grafisk programmering er vejen åben til fuldautomatisk kodegenerering, hvor man stort set bare behøver at tegne fabrikkens flowdiagram og indtaste nogle få værdier for timere etc., og så har men en kode med et intelligensniveau", som der næppe er mange programmører, der kan hamle op med, og uden at det går ud over effektiviteten i kodeeksekveringen.

Finn Glamhøj

Generelt set er et højt abstraktionsniveau en fordel med mindre man skal programmere meget små systemer, hvor absolut maksimal effektivitet er et must.

Hvilket så er det jeg har gjort mest i.

Min reservation i forhold til højt abstraktionsniveau er ikke, at jeg har noget imod at få noget forærende, men at jeg desværre har set for mange tilfælde, hvor det har udmøntet sig i en ansvarsfralæggende adfærd, hvor rationalet har været det er jo op til kompileren at sørge for.

Og du mener ikke, at hierarkisk, grafisk programmering er en kæmpe fordel ved en PLC?

Det mener jeg bestemt jeg allerede har svaret på:

Grafisk repræsentation kan være en rigtig god måde at udtrykke sig på til nogle opgaver, hvorimod tekst er at foretrække til andre.

Poul-Henning Kamp Blogger

Generelt set er et højt abstraktionsniveau en fordel [...]

Kun hvis man ignorerer prisen man betaler for det ?

Overvej f.eks hvordan danske uddannelser skød en masse unge mennesker i foden ved kun at undervise i Java, netop med henvisning til hvor meget bedre det var med et højt abstrationsniveau.

Hvis det ikke lige var for Flash ville Java suverænt kunne udnævnes til den største sikkerhedsbommet nogen sinde...

Den anden pris man betaler er ofte kortere systemlevetid eller direkte at blive kørt bag af dansen fordi den "høje abstraktion" man satsede alt på pludselig er død og borte. Hvem husker f.eks ikke CORBA ?

Der var store komplexe systemer der blev bygget på de dengang spritnye platforme OSF/1 og DCE som end ikke var leveret i produktion da begge platforme var "forældede".

Alting har en pris og komplexitet, uanset hvordan man spenderer den, særligt så.

Ditlev Petersen

Engang for længe siden skrev en forfatter en trist SF-novelle "The Machine Stops". Ud over den begrædelige som-om verden (Facebook-lignende), så er verden karakteriseret ved, at ingen efterhånden magter at vedligeholde de komplekse systemer. Og så falder det hele fra hinanden.

Der har vist altid været mærkelige fiduser for at få ting til at fungere. Førhen kunne man angiveligt opleve folk slå på et fjernsyn for at det i synk. Sommetider skal det endog have virket. Jeg kom engang over for en psykiater til at sammenligne psykiatrien med at slå på et fjernsyn. Der er en løs forbindelse et eller andet sted og vi ved ikke, hvor eller hvordan, men et par dunk (piller) plejer at hjælpe.

Det er bare skrækkeligt, når det ikke er en "privatmand", der slår på et fjernsyn, men den tekniker, der burde kende indmaden. Man kan ikke løse ret mange problemer med genstart, spark eller vievand og åndemaneri.

Forresten var det just det, man gjorde i Jurassic Park - med store resultater. Crichton kunne vist ikke fordrage hverken computere eller programmører. Men der havde han altså en pointe.

Carsten Kanstrup

Kun hvis man ignorerer prisen man betaler for det ?

Jeg mener ikke, at der nødvendigvis behøver at være en særlig høj pris at betale for et højt abstraktionsniveau, hvis systemerne er lavet fornuftigt, og jeg har også givet et par eksempler ovenfor.

F.eks. vil højniveauassembler generere nøjagtig den samme kodemængde som traditionel assembler, men være velstruktureret og mange gange lettere at læse og vedligeholde.

Det samme gælder RaiseEvent eksemplet. Koden skal skrives alligevel, hvis den skal være robust. Det er bare et spørgsmål om hvem, der gør det, og er det kompileren, bliver der færre kodelinjer og dermed et bedre overblik, og man begår ikke fejl.

Ligeledes vil jeg påstå, at det intelligensniveau, jeg efter mange års udviklingsarbejde har fået lagt i mine enkeltstyringer til f.eks. styring af foderstoffabrikker og lignende, langt overstiger, hvad en almindelig PLC programmør kan komme frem til, og så er abstraktionsniveauet samtidig så højt, at man bare kan skrive koden direkte ud fra fabrikkens flowdiagram, hvilket jeg har gjort mange gange. F.eks. lavede jeg engang styringen til et affalddestruktionsanlæg ud fra den traditionelle metode, man tidligere havde brugt i firmaet, for "sådan gør man sådan noget". Det tog 3-4 måneder. Efter at jeg havde udviklet det nye system, skulle fabrikken ombygge og udviddes. Nu tog styringen med det nye system kun ca. 2-3 uger incl. idriftsættelse og udskiftning af noget hardware (dog ikke kraftigere CPU), og styringen var betydelig mere "intelligent". Hvad tror du, det sparede firmaet for i kr. og ører? Hvis systemet blev videreudviddet til grafisk programmering, ville man stort set bare skulle tegne fabrikkens flowdiagram, og det diagram skal man nok alligevel bruge for at kunne vise driftstatus på en skærm.

Fordi Java er noget "dyt" betyder det ikke, at man ikke kan udvidde abstraktionsniveauet uden store omkostninger i f.eks. effektivitet og sikkerhed. Det gælder ialtfald inden for min branche.

Filip Larsen
Glenn Møller

Der har vist altid været mærkelige fiduser for at få ting til at fungere. Førhen kunne man angiveligt opleve folk slå på et fjernsyn for at det i synk.

Hej Ditlev

Det virkede faktisk!

Grunden var talrige løse forbindelser i form af "fejldesignede" lodninger:
* Steder med stor mekanisk stress på printplader ved fx højspændingstransformatorben, effektdioder, elektronrørssokler, formentlig grundet opvarmning og afkøling. Nogle af de løse forbindelse skyldes måske dårlig fortinning af komponetben.
* korroderede stikflader.

Med et forstørrelsesglas på x10 kunne man mange gange se små gnister mellem komponentben/rørsokkelben og loddeøens loddetin, ved en let mekanisk stress mod printpladen med en isoleret pind.

Mindst halvtreds procent af det udstyr jeg reparerede på, havde fejlet grundet sådanne løse forbindelser.

Det "værste" eksempel var et stort flot (gammelt) luksus Loewe fjernsyn, hvor alle ICerne sad i gennemsigtige sokler. Soklernes ben var alle sort korroderede, og alle ICere virkede ustabile grundet de løse forbindelser. Et let tryk på ICen, et bank og der skete "mærkelige ting" enhver astrolog/mystiker kunne have tjent penge på i årtier.

Heino Svendsen

Når man én gang har fundet den "skudsikre" måde at gøre noget på, kan man lige så godt indføre det i sproget.

Nu er det jo sådan, at one size does not fit all. Til daglig skriver jeg software i en god blanding af højniveausprog. Og hvis man nu indførte én måde at indføre NULL værdi håndtering, ville jeg godt nok blive trist. Nogle systemer vil fx. gerne kunne initialisere variablen, andre vil gerne fange Exception.

Det samme, når jeg kigger på Embedded Programming : Nogle systemer skriver jeg til i Assembler for størrelse og hastighed, andre i C, og så er der så lige de, som kører Emb. Linux, hvor jeg bruger C/C++. FPGA får VHDL.

Personligt bryder jeg mig ikke om VB/VBA/VB.NET, men derfor kan man jo godt lave noget fornuftigt alligevel. I min verden er det et sprog, ikke-teknikere brugere for at bikse noget kode sammen, men det betyder jo ikke, at det ikke kan bruges til noget fornuftigt.

Heino Svendsen

Det er jo ganske vist min egen holdning, så enhver kan jo blot bruge sin egen.

  1. Least :
    Least code, Least processes, Least Privileges
    Jo mindre kode, som kører, jo mindre er chancen for fejl.
    Jo færre processor, jo mindre er chancen for CPU starvation / synkroniseringsproblemer.
    Jo mindre rettigheder, jo mindre burde chancen for graverende fejl være.

  2. KISS :
    Keep IT Simple Stupid
    Simplere kode holder bedre overblik.
    Simplere kode giver lettere tests ( forhåbentligt )

  3. Fordobling af koden, firdobler chancen for fejl.
    En uoverskuelig / kompleks kodeblok bør brydes ned i mindre dele for at kunne teste delene individuelt.

  4. Valg af det "rette" værktøj til opgaven.
    En af mine venner arbejdede på en embedded platform. Én af projektlederne fik gennemtvunget brugen af Windows Emb. med en .NET CF platform som software. Produktet endte med at køre langsomt, selvom kodebasen var forholdsvis lille. Alene sammenligningen med C/C++... .NET / VB er fint til PC platformen, men sgu ikke imponerende på Emb. systemer.

Mit lille opstød

Carsten Kanstrup

Personligt bryder jeg mig ikke om VB/VBA/VB.NET, men derfor kan man jo godt lave noget fornuftigt alligevel. I min verden er det et sprog, ikke-teknikere brugere for at bikse noget kode sammen, men det betyder jo ikke, at det ikke kan bruges til noget fornuftigt.

I .Net er det vel fuldstændig ligegyldig hvilket sprog, man bruger, for den genererede kode er stort set den samme bortset fra små differenser som f.eks. RaiseEvent; men her er vi netop tilbage i holdningen: C# er for proferne, VB er for amatørerne - på trods af, at man kan nøjagtig det samme. Når VB bruges af begyndere, skyldes det jo netop den langt bedre og mere overskuelige syntaks.

Det var det samme med Commodore Amiga kontra IBM PC'en. Amigaen havde et glimrende multitasking operativsystem, en ikke-paged processor (68000) og god grafik med bit-blitter og blev i en periode faktisk brugt til at styre affyringssekvensen for rumfærgerne. IBM have kun tekstbaseret, singletask DOS og Intels forfærdelige pagede arkitektur. Alligevel var holdningen, at PC'en var for proferne og Amigaen for gamerne, og Commodore begik selvmord ved også kun at markedsføre Amigaen som "Verdens vildeste spillecomputer" :-(

Baldur Norddahl

I .Net er det vel fuldstændig ligegyldig hvilket sprog, man bruger, for den genererede kode er stort set den samme bortset fra små differenser som f.eks. RaiseEvent; men her er vi netop tilbage i holdningen: C# er for proferne, VB er for amatørerne - på trods af, at man kan nøjagtig det samme. Når VB bruges af begyndere, skyldes det jo netop den langt bedre og mere overskuelige syntaks.

Den generede kode er på ingen måde det samme. Det ene er et sprog med statiske typer og det andet er dynamisk typet. Dynamiske typer indebærer at koden skal tjekke typerne runtime, hvor oversætteren gør det ved statiske typer.

Til det andet vil jeg betvivle dit udsagn om at et sprog entydigt kan erklæres for bedre alene målt på parameteren nemt for nybegyndere.

Carsten Kanstrup

Uhm nej.

Amigaen blev brugt til at lave syn-locked grafik til fjernsynssignaler på NASATV, ligesom den gjorde det på utallige lokal-TV stationer over hele verden.

Jeg var engang medlem af en Commodore brugergruppe, hvor ét af medlemmerne var en dansker ansat direkte i Commodores udviklingsafdeling (jeg kan desværre ikke huske navnet). Jeg har det fra ham, og jeg opponerede netop imod, at en sådan oplysning ikke blev brugt til at fremhæve Amigaen som en maskine også til seriøst brug; men desværre kunne ledelsen ikke se andet en "Verdens vildeste spillecomputer".

Carsten Kanstrup

Den generede kode er på ingen måde det samme. Det ene er et sprog med statiske typer og det andet er dynamisk typet. Dynamiske typer indebærer at koden skal tjekke typerne runtime, hvor oversætteren gør det ved statiske typer.

Jeg taler om .Net:

Though C# and VB.NET are syntactically very different, that is where the differences mostly end. Microsoft developed both of these languages to be part of the same .NET Framework development platform. They are both developed, managed, and supported by the same language development team at Microsoft.[5] They compile to the same intermediate language (IL), which runs against the same .NET Framework runtime libraries.[6] Although there are some differences in the programming constructs (discussed further below), their differences are primarily syntactic and, assuming one avoids the Visual Basic "Compatibility" libraries provided by Microsoft to aid conversion from VB6, almost every command in VB has an equivalent command in C# and vice versa. Lastly, both languages reference the same Base Classes of the .NET Framework to extend their functionality. As a result, with few exceptions, a program written in either language can be run through a simple syntax converter to translate to the other. There are many open source and commercially available products for this task. The only fundamental differences between the languages can be found in the implementation of interfaces and in the declaration, raising and handling of events. Although both languages are high-level programming languages, VB.NET maintains a slightly higher level of abstraction in some respects.

Derfor er det lidt pjattet at fremhæve C# som værende for de professionelle og VB for amatørerne.

Jesper Louis Andersen
Jesper Louis Andersen

Der er for mig at se en række situationer hvor en kontrolleret genstart er helt i orden for at rette op på et system. Det er ud fra den betragtning at jeg snart har 10 års erfaring med Erlang-programmering, og der benytter man netop en genstart af fejlede dele til at bringe dem i orden igen. Ericsson har systemer hvor reliability har været nine nines (99.9999999%), så metoden må siges at virke (det kræver dog tilsvarende hardware-support for at nå det tal).

Det havari vi så får imidlertid en række alarmklokker til at ringe:

  • Når et system fejler genstarter man ikke, hvis man kan stoppe blødningen ved delvist at lukke systemet. Man bør have en safe-mode der er basis så man kan stoppe de mere komplekse dele af systemet, og etablere en stabil basis. Genstart kræver kontrol, og det virker det ikke til at man havde da man trykkede på knappen.
  • Hvis fejlen skal rettes fremadrettet skal man snapshotte passende mængder post-mortem data til at kunne finde fejlen bagefter i ro og mag.
  • Panikbeslutninger er pissefarlige.
  • Efter genstart skal man have en stabil tilstand, en invariant, man kan komme videre fra.

Som Jim Gray bemærkede er mange computerfejl transiente. Hvis du prøver igen med et tomt papirark er det ofte at systemet nu virker efter hensigten. Så man kan med fordel designe dele af systemet sådan at det hurtigt kan bringes op fra sidste stabile tilstand. Erlang-systemer kan gøre dette partielt for en lille del af systemet uden at påvirke resten. Ideerne herfor er som taget ud af Peter J. Dennings arbejde omkring virtuel hukommelse og isolation, bare internt i en (UNIX)-proces.

Den korte historie er at man hurtigt detekterer en fejl, hurtigt genstarter og løbende eskalerer op hvis en lokal genstart ikke virker. Naturligvis sørger man for at post-mortem snapshotte fejlede delsystemer til disk så man kan undersøge dem senere. Mange fejl er proaktive i den forstand at de skaber støj længe inden de smadrer hele systemet. De kan derfor rettes i tide med lidt omhu.

Mht til valget af programmeringssprog så er det afgjort en faktor. Men jeg tror at det rigtige systemdesign har langt større betydning end sproget i praksis. Abstraktioner er også kun noget værd hvis de, som sprog, tillader dig at beskrive løsningen med større præcision. Mere præcision eliminerer fejl, giver hurtigere programmer og er ofte også nemmere at vedligeholde. Mange abstraktioner er faux i den forstand at de lader dig bygge et elfenbenstårn, men de lader dig ikke løse det konkrete problem direkte.

Ole Laursen

Abstraktioner er også kun noget værd hvis de, som sprog, tillader dig at beskrive løsningen med større præcision. Mere præcision eliminerer fejl, giver hurtigere programmer og er ofte også nemmere at vedligeholde.

Smukt sagt. Det kræver tid og kræfter og ikke mindst omtanke at tilpasse og skærpe en abstraktion.

Og der er også nogle sprog hvor man hurtigere løber panden mod en mur hvis man sidder og finpolerer.

Heino Svendsen
Troels Henriksen

Jeg forstår ikke hvorfor brugen af ord skulle være mere læsbart, på sigt, end brugen af symboler. I matematikken klarer vi os fint med symboler, og drager stor nytte af deres koncision. Jeg tror ikke på at den menneskelige hjerne fundamentalt set har nemmere ved at genkende f.eks. 'andalso' (eller hvad det nu er i VB) end '&&' - i sidste ende er de begge blot streger og prikker som vi har lært at tillægge en bestemt betydning.

Jeg kan anbefale at læse Ken Iverson's Turing Award-artikel, Notation as a Tool of Thought, der detaljeret redegør for værdien af en god notation i en programmerings-kontekst. Jeg synes det er mindre vigtigt om en utrænet lægmand kan læse et program fordi sproget er lavet så det ligner naturligt talesprog, end om en trænet programmør kan drage nytte af sprogets valgte notation.

Christian Nobel
Carsten Kanstrup

Lidt lige som, hvis man ønsker at lære et skandinavisk sprog og har problemer med stavning, så lær norsk i stedet for dansk.

Netop, og alle kunstsprog er derfor opbygget, så de staves, som de udtales. Erstat C med enten K eller S, alt efter hvordan det udtales, og fjern W etc. Så er man godt på vej - i modsætning til f.eks. fransk, hvor udtale og skrift er to forskellige verdener.

Hvorfor skal man slås mod sproget og bruge lang tid på at få hjernen omstillet? I fjernøsten bruger de en meget stor del af deres skoletid på at lære det komplicerede tegnsprog. Dygtige telegrafister ville også kunne programmere med prikker og streger; men det er altså ikke særlig hensigtsmæssigt eller særlig let læst for andre.

Troels Henriksen

Men så formoder jeg også at hvis du skal til Kina, så lærer du lige først kinesisk flydende før du rejser, for det er jo kun et spørgsmål om tegn og tale er anderledes, inderst inde tænker folk jo ens - og tilsvarende for alle andre lande du rejser i.

Jeg tror ikke kinesiske tegn er intrinsisk sværere at lære end det latinske alfabet, hvis det er hvad du mener? (Udover at der er mange flere af de kinesiske, hvilket medfører tekniske vanskeligheder.) Hvis jeg skulle bo i Kina, så ville jeg naturligvis lære mig kinesisk.

Ellers forstår jeg ikke din pointe. Bør programmeringssprog fortrinsvist designes til folk der kun kursorisk skal benytte dem og ikke har tid til at sætte sig ind i dem, hvorfor sprogene bør ligne naturligt sprog? Det er en helt gyldig holdning, og faktisk et interessant (og stedvist relevant) designscenarie, men jeg er ikke enig i at alle sprog bør fungere sådan. Mange programmeringssprog, ganske som matematisk notation, er beregnet til at blive betjent at folk der er blevet trænet.

Dijkstra har også skrevet noget fornuftigt omkring vigtigheden notation (inklusive velfortjent kritik af de tåbeligere dele af matematisk notation), med eksempler på hvordan god notation letter læsbarhed og manipulation. Det er selvfølgelig stadigvæk ikke helt empirisk, men jeg synes denne tekst (samt Ken Iverson's ovenfor) giver gode argumenter for nytten ved notationer der ikke umiddelbart ligner naturligt sprog.

Carsten Kanstrup

I matematikken klarer vi os fint med symboler, og drager stor nytte af deres koncision.

Der er da ingen, der drømmer om at erstatte f.eks. +, -, * og / med tekst, for de symboler er jo en integreret del af vores hverdag lige fra børnehaven - ligesom engelsk også er ved at være.

Jeg tror ikke på at den menneskelige hjerne fundamentalt set har nemmere ved at genkende f.eks. 'andalso' (eller hvad det nu er i VB) end '&&' - i sidste ende er de begge blot streger og prikker som vi har lært at tillægge en bestemt betydning.

Ja, ligesom f.eks. japansk tegnsprog! Såre enkelt og lige til at gå til - det er jo bare streger.

Har du nogensinde hørt om en !&&-gate? Det er vist kun nørder, der synes at en sådan notation er smart :-)

Troels Henriksen

Der er da ingen, der drømmer om at erstatte f.eks. +, -, * og / med tekst, for de symboler er jo en integreret del af vores hverdag lige fra børnehaven - ligesom engelsk også er ved at være.

Okay, men hvad så med andre matematiske symboler? Det meste matematik gør brug af et stort antal symboler, ofte specifikke til hvert felt. Dårlig notation kan naturligvis skabe stor skade, men overordnet set lader det til symboler er noget folk finder værdi i. Matematiken startede jo også med at være rent sproglig, og blev først senere symbolsk.

Ville typereglerne for den enkelt-typede lambda kalkulus på denne side være nemmere at forstå hvis de blev forklaret i ord? Det har vi prøvet før (i datalogiens ungdom), og den fremgangsmåde er gradvist blevet erstattet med mere formelle metoder, efterhånden som de blev udviklet. Jeg tør slet ikke tænkte på hvor ubehageligt det ville være at føre beviser over en formel semantik hvis den var beskrevet i naturligt sprog.

Og nej, jeg er heller ikke bange for japansk tegn. Jeg har ikke lært det, men hvis jeg skulle lave noget tilstrækkeligt vigtigt med døve folk i Japan, så kunne jeg sikkert godt.

Troels Henriksen

Vi snakker om programmeringssprog, og C har sit udgangspunkt i UNIX med 7-bit ASCII kode (gud bedre det). Det bliver vist lidt op ad bakke at finde plads til alle dine matematiske symboler.

Min hensigt var at søge en grundlæggende enighed om vigtigheden af god notation. Dit eget eksempel med visuel programmering (hvor det giver mening) er i øvrigt også et eksempel, selvom min egen erfaring mest er med symbolbehandling. Når først det er etableret at en god notation ikke nødvendigvis er lig en notation der er forståelig for en uindviet (dvs. den behøver ikke ligne naturligt sprog), så kan man diskutere hvorvidt C's notation er velegnet til det ene domæne eller det andet.

Selv mener jeg at C har en ganske skrækkelig syntaks, omend det mest har at gøre med hvor frygteligt erklæringer af komplekse typer ser ud. Jeg har ikke noget imod den grundlæggende brug af symboler.

Finn Glamhøj

Der er bland nogle debattører her en tilsyneladende meget stor aversion mod C, hvilket på mange måder er forståeligt. C’s syntaks er ikke nødvendigvis den kønneste der findes.

Årsagen til at C er som det er, er helt sikkert mange og har nok en del med historie at gøre. Det er et sprog der er gammelt, hvor syntaksen nok for en dels vedkommende er bestemt af, hvordan selve kompileren nemmest kunne bygges og afvikles på de på tidspunktet tilrådighed stående computer.

Når det er sagt så er C et sprog der har bevist sit værd og som stadigvæk er meget anvendeligt til ganske mange ting. (jeg har ikke set et reelt alternativ til små mikrokontroller som jeg tidligere har nævnt)

Når en opgave skal løses skal man vælge det værktøj der er bedst til opgaven og en del af dette valg er også den erfaring man har med værktøjet.

Det nytter jo ikke at man vælger et værktøj der kan en hel masse, hvis man ikke aner hvordan man bruger det. Det kan og bør man måske nok lære, men i den virkelige verden er det jo ikke altid sådan, at man har tid til det og så bruger man det værktøj man kender.

Jeg synes at spore en vis religiøsitet hvad angår valg af værktøj hos nogle af debattørerne som kommer til udtryk i udsagn som:

Når jeg programmerer FPGA'er gør jeg det i hierarkisk grafik (ViewDraw), da det giver langt det bedste overblik. Hjernen er først og fremmest grafisk orienteret - vi kender alle talemåden: "Én tegning kan forklare mere end 1000 ord." Ikke ti vilde heste skal få mig over på tekstbaseret VHDL

Nogle ting er nemmere at udtrykke med en tegning og andre som tekst. Kommandoen hent en kop kaffe er nok en del nemmere at forstå end en tegning af selv samme vil være det.

Grunden til jeg blandede mig i debatten til at starte med var udsagnet:

Det går den helt forkerte vej. Det vrimler med fejl og sikkerhedshuller i dagens IT systemer, fordi selv ikke de dygtigste programmører kan overskue de ekstremt komplekse systemer, de selv laver - godt hjulpet på vej af programmeringssprog som C, hvor man skal læse hieroglyffer i stedet for simpel engelsk tekst

Jeg tvivler på, at nogen bare nogenlunde habil programmør vil lave alvorlige fejl som følge af hieroglyfferne i C, eller C’s syntaks generelt.

Alvorlige fejl opstår primært når opgaven ikke er forstået (defineret) til fulde, eller det fulde omfang af konsekvenser af den løsning man har valgt, ikke er indset. (ligegyldighed kan selvfølgelig også være en årsag)

Naturligvis kan der opstår der fejl som følge af af manglende overskuelighed, hvilket syntaksen kan medvirke til, men det er fejl der er (eller bør være) rimelig lette at finde og som ikke medføre nye fejl når de rettes.

Carsten Kanstrup

Naturligvis kan der opstår der fejl som følge af af manglende overskuelighed, hvilket syntaksen kan medvirke til, men det er fejl der er (eller bør være) rimelig lette at finde og som ikke medføre nye fejl når de rettes.

Sådan er det desværre ikke altid med C. Jeg kender et firma, hvor man måtte opgive at rette i et program, fordi der var en statement, som man trods ihærdig intern diskussion blandt programmørerne ganske simpelt ikke kunne gennemskue. Programmet var skrevet af en tidligere ansat/nørd, som elskede den slags; men "maintainability" er jo et rent 0.

Finn Glamhøj

Sådan er det desværre ikke altid med C. Jeg kender et firma, hvor man måtte opgive at rette i et program, fordi der var en statement, som man trods ihærdig intern diskussion blandt programmørerne ganske simpelt ikke kunne gennemskue. Programmet var skrevet af en tidligere ansat/nørd, som elskede den slags; men "maintainability" er jo et rent 0.

Det sige vist mest om de tilbageblivende medarbejder, hvis de ikke kunne rette et program fordi ét statement var ulæselig.

Man må da altid kunne gå et niveau op ved omskrivning således at den funktion som det indgår i kan skrives om sådan at den er læselig og fejlfri.

Jacob Sparre Andersen

Hvilket sprog vil du anbefale til brug for programmering af mikrokontroller med få ressourcer? Eksempelvis 8 bit mikrokontroller med 1-4 KB RAM.

Ada. Fint til alt fra 256 bytes op til flere 100 MB. (I den lave ende dog uden tasking og exceptions.)

Jacob Sparre Andersen

Og her troede jeg at Ada var sagen når det gjaldt pålidelighed og sikkerhed og runtime check.
Syntes jeg har hørt ad F-35 indeholder en hel del Ada-kode.

Lige netop F35 er stort set rent C++. :-(

Men jo, Ada er designet til udvikling af pålidelig software. Hvis du flyver med Airbus- eller Boeing-maskiner, så er den kritiske software skrevet i Ada. I Frankrig er softwaren der styrer togsignaler ligeledes også skrevet i Ada (og fylder hele 300 kLOC).

Men markedet er sådan at det i mange sammenhænge er billigere/lettere at vælge andre sprog, og det sker så.

Jesper Louis Andersen

Der er bland nogle debattører her en tilsyneladende meget stor aversion mod C, hvilket på mange måder er forståeligt. C’s syntaks er ikke nødvendigvis den kønneste der findes.

C er rigtigt godt hvis dit problem har relativt lille abstraktionsbehov, eller kan skæres sådan at abstraktionsbehovet ikke er der. Det er også godt til at løse problemer med rå brute-force uden for meget omtanke omkring algoritmer og datastrukturer. Det gør det virkeligt godt i embedded software, hvor koden typisk er begrænset i omfang og kompleksitet (hvilket er en god ting!). Det er også godt i "software kerner" hvor du har en lille mængde af kodelinier der køres igen og igen.

Til gengæld er C ikke er specielt godt valg hvis det problem man sidder med er af abstrakt natur, hvis man har brug for modulære systemer eller hvis man har en grænseflade der er kompleks. F.eks. er mange af programmerne til formelle metoder skrevet i sprog der har et langt højere niveau end C byder på. Der er også et stort overhead i at få C til at kunne håndtere concurrency set i forhold til andre sprog (Go, Erlang, Haskell, ...). Som i så mange andre tilfælde er der steder hvor det ikke er specielt velegnet.

Så alt efter den baggrund folk har, så er deres indstilling til sproget nok, forventeligt, forskelligt. Personligt ville jeg hellere foretrække et imperativt sprog som Go i stedet for C, da der er ryttet op i mange af de småfejl C har. Men jeg er endnu mere til hybride imperative/funktionelle sprog såsom OCaml, Standard ML, eller Erlang. Det er så ikke så anvendeligt på meget små systemer, men de dør også indenfor den næste årrække fordi prisen på kraftigere hardware er faldende og udkonkurrerer 8bit med 16kilobyte. Det eneste der holder det i live pt er at et mindre system er nemmere at overskue og det kan lede til simplere systemer der virker. Mere power er ikke nødvendigvis bedre.

Finn Glamhøj

Ada. Fint til alt fra 256 bytes op til flere 100 MB. (I den lave ende dog uden tasking og exceptions.)

Er det en anbefaling som kommer sig af, at det er det du selv bruger? Eller skal det forstås som, det er en mulighed, hvis man ikke bryder sig om C?

Det er mange år siden jeg har snuset til Ada (og aldrig mere end det) så inden jeg kikker nærmere på det (hvilket jeg nok vil gøre) vil det være rart at vide om erfaringerne er, at det genererer lige så kompakt kode som C og eksekveringshastigheden er den samme som C kode.

I øvrigt har jeg lige set lidt på forskellige biblioteker til forskellige udgaver af GNAT (AVR og ARM) og helt fri for C er de jo ikke omend det ikke er overvældende :-)

Finn Glamhøj

Der er også et stort overhead i at få C til at kunne håndtere concurrency set i forhold til andre sprog (Go, Erlang, Haskell, ...)

Jeg har desværre ikke kendskab til de nævnte sprog (det burde jeg måske se at få) og stiller derfor følgende spørgsmål: det overhead du tale om, er det ikke kun gemt væk i de pågældende sprog i forhold til C? Med andre ord, er der tale om et runtime overhead i C i forhold til de pågældende sprog?

Det er så ikke så anvendeligt på meget små systemer, men de dør også indenfor den næste årrække fordi prisen på kraftigere hardware er faldende og udkonkurrerer 8bit med 16kilobyte. Det eneste der holder det i live pt er at et mindre system er nemmere at overskue og det kan lede til simplere systemer der virker. Mere power er ikke nødvendigvis bedre.

Jeg er enig et langt stykke hen ad vejen, at til mange opgaver vil man vælge eksempelvis en ARM baseret MCU i stedet for en en 8-bit MCU, men der vil gå lang tid inden vi er helt færdige med 8-bit MCU’er til opgaver der kræver et meget lavt energiforbrug (batteriforsynet systemer, hvor man ikke bare lige kan udskifte batterierne).

Lars Opstrup Poulsen

"Én tegning kan forklare mere end 1000 ord." Ikke ti vilde heste skal få mig over på tekstbaseret VHDL, Verilog eller hardware-C, selvom det er det, "man gør", for så ville jeg aldrig nogensinde kunne garantere robusthed i de ting, jeg laver (bl.a. med dual-phase clock overalt), og med asynkrone netværk med over 5000 gates ville jeg have mistet overblikket for længst.

Mener du virkelig at du garanterer robusthed ved at vise et billede?
Jeg er med på at et fint billede kan vise et bedre overblik over hvordan funktionaliteter hænger sammen, men robusthed vil jeg mene demonstreres på helt andre måder

Jesper Louis Andersen

Hvis du mener "arbejde for applikations-programmøren", så ja.

Hvis du mener spilde af tid & instruktioner, så NEJ!

Arbejde for applikations-programmøren, naturligvis.

Go kommer relativt tæt på C efterhånden (indenfor en faktor 1.5 er ikke umuligt for typiske programmer. De har arbejdet temmeligt meget på SSA i compileren de sidste par år). Haskell kan komme tæt på, men så ligner koden også mere C end godt er :) Erlang-programmører har det bare med at skrive de dele der er performancekritiske i C, og så skrive den overordnede del af systemet i Erlang. Bemærk dog, at Erlang har systemets robusthed og oppetid som primært kritisk fokus, ikke dets effektivitet. Datastrukturer der er robuste over flere års kontinuær operation uden genstart har det med at mindre effektive, fordi det ikke er det primære fokus.

Der findes dog også den mulighed at det mindre arbejde for applikations-programmøren gør at vedkommende har tid til at udtænke en bedre løsning på begrænset tid. Og det kan ofte lede til et langt mere effektivt program. I andre situationer handler det om at skrive en generator der skriver et C program som er optimeret til opgaven. Og her er sprog som Haskell (eller OCaml) utroligt effektive redskaber. Et eksempel herpå er FFTW (fftw.org). Det er C kode, men generatoren er skrevet i OCaml.

Jesper Louis Andersen

Jeg har desværre ikke kendskab til de nævnte sprog (det burde jeg måske se at få) og stiller derfor følgende spørgsmål: det overhead du tale om, er det ikke kun gemt væk i de pågældende sprog i forhold til C? Med andre ord, er der tale om et runtime overhead i C i forhold til de pågældende sprog?

Overhead i forstanden "kognitiv belastning". De sprog har en runtime-kerne skrevet i C alle sammen. Man stille bare et univers til rådighed hvor arbejdet med at udnytte kernen er noget simplere end det C tilbyder. Naturligvis er afvejningen så den at du mister noget fleksibilitet.

mht 8bit og batterier: 100% enig.

Christian Nobel

men der vil gå lang tid inden vi er helt færdige med 8-bit MCU’er til opgaver der kræver et meget lavt energiforbrug (batteriforsynet systemer, hvor man ikke bare lige kan udskifte batterierne).

MSP430, som mig bekendt er noget nær det mest strømbesparende man kan finde, er 16 bit.

Endnu en "opbyggelig" Internet of Trash historie:
https://www.engadget.com/2017/02/17/when-vending-machines-attack/

Og så lige et spørgsmål, nu vi er på vej ud på et sidespor - er der nogen der har en holdning om hvorvidt man skal vælge MicroPython eller eLua, når man roder med ESP 8266?

Peter Christiansen

Hej Christian,
mht strømbesparende, er microchip godt inde i kampen i forhold til en msp430, f.eks med en pic12f675 den har et standby forbrug på i standby på 1 nA hvor msp'en trækker 350nA.

Mht til ESP 8266, foretrækker jeg selv at programmere den i c, der bruger jeg selv open ESP https://github.com/pfalcon/esp-open-sdk.

Jeg er imod at ligge flere lag på en micro controller der allerede er begrænset i forvejen, jovist har den whopping 64k ram (det er vanvittigt meget for microcontrollere) og er pænt kraftfult, men jeg foretrækker at undvære fortolkeren og programmere den mere jordnært.

Men hvis jeg skulle vælge, ville jeg tage MicroPython, men det er mest ud fra hvad jeg føler mest for af de 2 sprog. Prøv dig frem!

Carsten Kanstrup

Mener du virkelig at du garanterer robusthed ved at vise et billede? Jeg er med på at et fint billede kan vise et bedre overblik over hvordan funktionaliteter hænger sammen, ...

Ja, i højeste grad, for robusthed handler først og fremmest om overblik. Hvis jeg lister den VHDL kode, der autogenereres ud fra min grafik, vil jeg garantere for, at der ikke findes én eneste programmør i hele verden, der ville kunne skabe sig nok overblik til sikkert at kunne rette nogen steder.

Jacob Sparre Andersen skriver ovenfor:

Lige netop F35 er stort set rent C++. :-(

Og ved lige netop F35 har man massive softwareproblemer, der ingen ende vil tage med bl.a. ca. 80% fejl på fejlmeddelelserne fra ALIS systemet - se http://fortune.com/2016/03/10/the-f-35-is-still-a-mess/ . Enhver erfaren projektleder ved (eller burde vide), at hvis småfejl ikke er rettet i næste version, er det et stensikkert tegn på, at programmørerne ikke agter opgaven, og så skal der handles. Se lige F35 og IC4! Ok, F35 er et særdeles kompliceret system med ca. 8 millioner kodelinjer, men så må man finde metoder, som muliggør, at den menneskelige hjerne stadig kan overskue det, i stedet for bare at gøre, som man altid har gjort! At man netop har problemer ved brug af C++, undrer mig på ingen måde.

... men robusthed vil jeg mene demonstreres på helt andre måder.

Der er selvfølgelig også andre måder at skabe robusthed på. Bl.a. er alle mine FPGA flip-flop's baseret på en dual-phase clock, som dels muliggør, at man kan clocke fra andet end et dedikeret clocknetværk med meget lille clock-skew og dermed kan lave asynkrone kredsløb, og dels sikrer, at kredsløbet bliver særdeles robust over for ældning og produktionstolerancer. Komponenterne i en IC kan jo i modsætning til diskrete komponenter ikke testes individuelt for en lang række parametre, så man ved reelt set ikke, hvor tæt man er på fejlgrænsen; men med en dual-phase clock, kan man acceptere særdeles store parameterændringer. Vis mig lige det VHDL eller Verilog system, som kan syntetisere countere og flip-flop's baseret på en sådan teknologi - eller for den sags skyld den FPGA designer (bortset fra mig), der tænker på disse ting!

Jacob Sparre Andersen

Er det en anbefaling som kommer sig af, at det er det du selv bruger? Eller skal det forstås som, det er en mulighed, hvis man ikke bryder sig om C?

Jeg bruger selv Ada. Men jeg mener seriøst at Ada er et godt alternativ til C. Ada er generelt designet til at løse de samme problemer som C - bare også på en større skala.

Det er mange år siden jeg har snuset til Ada (og aldrig mere end det) så inden jeg kikker nærmere på det (hvilket jeg nok vil gøre) vil det være rart at vide om erfaringerne er, at det genererer lige så kompakt kode som C og eksekveringshastigheden er den samme som C kode.

Jeg har ikke målt hvor kompakt det er sammenlignet med C, men en af mine kollegaer skrev noget styring til en AVR MCU for et par uger siden. Der fyldte Ada-udgaven (oversat med GCC) cirka dobbelt så meget som assembler-udgaven, så måske står det lige så galt til i forhold til C.

Eksekveringshastigheden er cirka den samme som med C. Nogle gange lidt hurtigere. Nogle gange lidt langsommere.

Poul-Henning Kamp Blogger

Se lige F35 og IC4! Ok, F35 er et særdeles kompliceret system med ca. 8 millioner kodelinjer

Carsten, stik lige fingeren ind.

For det første er IC4 mindst 10 gange større end F35 i antal kodelinier, hvis det kan gøre det (husk at tælle Labview, Windows, WxWorks osv. med!)

For det andet er problemerne med F35's software egentlig ikke selv softwaren, der formodentlig er noget af det mest kompetente der bliver skrevet for tiden, men det faktum at en masse fundamentale problemer med flyets design blev "løst" ved at skrive "Software controlled" uden at nogen som helst grund til at tro det kan lade sig gøre.

Carsten Kanstrup

Carsten, stik lige fingeren ind.

I hvad, PHK? Den slags bemærkninger hører ikke hjemme på ing.dk :-(

For det første er IC4 mindst 10 gange større end F35 i antal kodelinier, hvis det kan gøre det (husk at tælle Labview, Windows, WxWorks osv. med!)

Har du bevis for denne påstand? Dokumentation tak.

For det andet er problemerne med F35's software egentlig ikke selv softwaren, der formodentlig er noget af det mest kompetente der bliver skrevet for tiden, men det faktum at en masse fundamentale problemer med flyets design blev "løst" ved at skrive "Software controlled" uden at nogen som helst grund til at tro det kan lade sig gøre.

Hvilke problemer er bare blevet "Software controlled", uden at det vil kunne lade sig gøre eller mere hensigtsmæssigt kunne løses udelukkende i hardware?

Hele flyet er - som alle andre moderne kampfly incl. YF-16 - bevidst gjort passivt ustabilt og skal så stabiliseres elektronisk af software, for ellers kan det ikke manøvrere tilstrækkelig godt. ALIS fejldetekterings- og vedligeholdelsessystem, som har vist massive problemer, kan vel heller ikke rigtigt laves i andet end software, og det samme gælder hjelmdisplayet, så piloten kan kikke gennem flyet og få information om missiler etc.

At sige, at det ikke kan laves i software, er det samme som at sige, at det ikke kan laves i det hele taget, så mener du reelt set, af F35 ikke kan realiseres ud fra de givne specifikationer?

Finn Glamhøj
Finn Glamhøj

MSP430, som mig bekendt er noget nær det mest strømbesparende man kan finde, er 16 bit.

Absolut, jeg burde måske nok have skrevet 8/16-bit, men når det er sagt så vil jeg fastholde, at også 8-bit MCU’er såsom eksempelvis AVR (som strengt taget er 8/16-bit) stadigvæk er relevante i en strømbesparende henseende.

Valg af MCU med henblik på reduktion af energiforbrug involvere meget andet end blot den typiske uA/MHz specifikation.

Der er en lang række af parametre der gør sig gældende som bestemmes af opgaven der skal udføres, at optimere for lavt energiforbrug er på ingen måde en triviel opgave.

Peter Rosenberg

Tak Carsten K for din reference til en DOT&E status for Testen af F35 fra Marts 2016.
Det meste interessant der står i den - for at bringe debatten her tilbage på sporet - er følgende:
"
Separate from the DOT&E study, reports also circulated this week that a glitch in the F-35’s radar software interferes with the system’s ability to remain online during flight.
That is, pilots are forced to reboot the plane’s radar periodically while in flight. For emphasis, pilots are having to regularly Ctrl+Alt+Delete the radar on the world’s most sophisticated warplane while in flight. "
Så vi kan måske snart høre om Ctrl+Alt+Delete (aka Genstart) i de fly vi skal ha´ og som US Marines er nogle af de første til at benytte.

Lars Opstrup Poulsen

Ja, i højeste grad, for robusthed handler først og fremmest om overblik. Hvis jeg lister den VHDL kode, der autogenereres ud fra min grafik, vil jeg garantere for, at der ikke findes én eneste programmør i hele verden, der ville kunne skabe sig nok overblik til sikkert at kunne rette nogen steder.


Carsten, vi snakker om at "garantere" robusthed. Her har hvad man får ud af at se på et billede, eller hvor godt man tror man læser kildekode ingen relevans.
Jeg tror ikke vi behøver bruge mere tid på den kode dit værktøj autogenerer i forhold til det her emne.

Komponenterne i en IC kan jo i modsætning til diskrete komponenter ikke testes individuelt for en lang række parametre, så man ved reelt set ikke, hvor tæt man er på fejlgrænsen; men med en dual-phase clock, kan man acceptere særdeles store parameterændringer. Vis mig lige det VHDL eller Verilog system, som kan syntetisere countere og flip-flop's baseret på en sådan teknologi - eller for den sags skyld den FPGA designer (bortset fra mig), der tænker på disse ting!

Jeg ved ikke hvorfor du går og bilder dig selv ind at du er unik i forhold til at tage sådan nogle parametre, eller for den sags skyld temperatur udsving, i betragtning. Det er muligt du er unik i din måde at løse det på men det er så også det.
Så ud over dig vil jeg antage at det er alle andre der tænker på disse ting.

Carsten Kanstrup

Carsten, vi snakker om at "garantere" robusthed. Her har hvad man får ud af at se på et billede, eller hvor godt man tror man læser kildekode ingen relevans.

Der er stort set ingen, der kan garantere robusthed i software - bortset måske fra producenterne af sikkerhedsoperativsystemer.

Mange softwarefejl og sikkerhedsproblemer vil typisk opstå, når overblikket svigter. Windows XP var vel oppe i nærheden af 500-1000 vigtige sikkerhedsopdateringer, inden systemet blev taget af bordet. Det går over min forstand, hvordan der kan være så mange sikkerhedshuller i ét produkt, og dertil kommer så de talrige mindre kritiske fejl. Tilsyneladende har mange af vore dages programmører bare givet op og retter så fejlene, efterhånden som hackerne finder dem, lader det være op til 3. part i form af antivirussoftware eller hævder, at det er brugerens egen skyld, hvis en ondsindet hjemmeside installerer programmer på computeren.

Jeg ved ikke hvorfor du går og bilder dig selv ind at du er unik i forhold til at tage sådan nogle parametre, eller for den sags skyld temperatur udsving, i betragtning.

Ja, lad os endelig få den kære jantelov på bordet.

Det er nok desværre et fåtal, som går så grundigt til værks som mig og kikker så dybt under "motorhjelmen", inden de bruger et system. I f.eks. databøgerne fra Microsemi vil du kunne se adskillige anvendelseseksempler på kredsløb som f.eks. countere, UART'er og lignende, hvis funktion ikke kan garanteres i praksis, hvis man gør, som vist, og jeg har bevist over for daværende Actel (nu Microsemi) - og fået det bekræftet af dem, at der var mulige glitch-problemer i nogle af deres macroer til de antifuse-baserede kredse - og iøvrigt at nogle macromuligheder, som de hævdede ikke kunne realiseres, sagtens kunne det i praksis (her var jeg faktisk unik). Når ikke engang den halvlederfabrik, der laver kredsene, er opmærksomme på problemerne, er det nok ikke specielt udbredt, at man tager den slags hensyn. Jeg tror bare de fleste regner med, at et kredsløb fungerer, som det burde ud fra den indtastede kode eller grafik - og det burde man også kunne; men det er bare ikke altid tilfældet i praksis med FPGA'er, hvor routing delays kan være sammenlignelige med kredsløbsdelays. Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne. Selv asynkrone 2-delere, som ellers burde være "idiotsikre", har jeg måttet konvertere til dual-phase clock for at skabe robusthed.

Hvis man vælger at bruge VHDL eller Verilog, er det normalt med henblik på automatisk syntese af kredsløbet; men her kan man igen løbe ind i problemer i de tilfælde, hvor man ikke benytter dedikerede clock-netværk, så her har vi netop eksempler på udbredte programmeringssprog, som ikke altid genererer robusthed - og iøvrigt er meget svært overskuelige.

Jesper Louis Andersen

Ja, i højeste grad, for robusthed handler først og fremmest om overblik. Hvis jeg lister den VHDL kode, der autogenereres ud fra min grafik, vil jeg garantere for, at der ikke findes én eneste programmør i hele verden, der ville kunne skabe sig nok overblik til sikkert at kunne rette nogen steder.

Til gengæld findes der programmer der kan symbolbehandle VHDL-kode og finde optimeringsmuligheder og finde fejl i det. Du kan stole på at AMD og Intel benytter model checking af deres kredsløb og de aflæser noget der ligner VHDL for at kunne gøre det. F.eks. Symbolic Trajectory Evaluation (STE), der er en generalisation af bit-simulering benyttes ofte i Hardware-laget. Moderne CPUer indeholder også en del protokoller, f.eks. i forbindelse med cache coherency. Disse kan checkes med SMT-solvere. Højere oppe i stakken bliver algoritmerne verificeret af Proof Assistants (HOL, Coq, ACL2, osv).

Grunden er at hardware er en af de få områder hvor ovenstående kan betale sig. En hardware-fejl i en CPU kan være en ekstremt bekostelig affære, så det temmeligt store formelle verifikationsarbejde står mål med dets værdi.

En grafisk repræsentation af et kredsløb kan være rart for mennesker, men maskiner er nu engang bedre til at behandle symbolske repræsentationer. Så et eller andet sted foregår der en oversættelse, så man kan anvende maskinbehandling. Ikke mindst fordi moderne systemer af stor størrelse har for mange transistorer til at vi kan have mennesker der placerer dem over det hele. I stedet benyttes en kombination af menneske og maskine til at konstruere CPUen.

I gamle dage var en af de typiske opgaver på DIKU at konstruere en 5-stage MIPS CPU. Det gjorde man i symbolsk logik via programmering. Så det kan lade sig gøre. Et par år efter kom der et grafisk værktøj til, men hvis du kan sætte 2.-års studerende til at lave designs for en 1987-æra RISC-CPU, og komme afsted med det, så er opgaven altså rimeligt overkommelig, trods alt.

Lars Opstrup Poulsen

Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne


Ja? Hvis dit design er afhængig af et givent routing delay kan det vel dårligt komme som en overraskelse? Med mindre selvfølgelig det du skriver er at værktøjet ikke overholder de constraints du har sat op, men sådan læser jeg det ikke.

Bortset fra det ligner resten af dit indlæg noget der skulle have noget med det jeg skrev at gøre, men jeg kan ikke rigtig se en sammenhæng.

Peter Christiansen

Jeg tror bare de fleste regner med, at et kredsløb fungerer

Det tror jeg de færreste regner med, i hvertfald ingeniører , det er derfor der er noget der hedder "technical errata", hvor man efter produktion af en chip kan se hvilke ting der ikke virker og hvilke man skal lave en workaround på, for at virke.

Martin Bøgelund

"Carsten, stik lige fingeren ind."

I hvad, PHK? Den slags bemærkninger hører ikke hjemme på ing.dk :-(

Hej Carsten,

Dansklærerforeningen ringede. De sagde at du skulle læse PHK's udsagn som en sammensmeltning af
- "Carsten, stik lige fingeren i jorden", og
- "Carsten, stik lige piben ind"

Eventuelle obskøne associationer du måtte have fået ud af denne uskyldige sammensmeltning af udtryk, må du selv tage ejerskab for.

Fortsat god dag.

Carsten Kanstrup

Du kan stole på at AMD og Intel benytter model checking af deres kredsløb og de aflæser noget der ligner VHDL for at kunne gøre det.

Ja, og desuden benytter AMD og Intel synkront design og har kun få routing delays, så de har netop ikke har de problemer, som jeg omtaler. De forekommer kun ved asynkront design af FPGA'er (ikke ASIC's).

Faktisk kunne man opnå betydelig større hastighed, mindre effektforbrug, mindre spændingsspikes og meget større robusthed over for f.eks. høje temperaturer (langsomme transistorer), produktionstolerancer og ældning, hvis man kunne lave asynkrone CPU'er; men det har man trods forskellige forsøg hidtil måttet opgive.

Carsten Kanstrup

Ja? Hvis dit design er afhængig af et givent routing delay kan det vel dårligt komme som en overraskelse?

Det er ikke et givent routing delay, der er problemet, men forskelle i routing delay, som opstår ud fra den tilfældige routing.

Langt de fleste flip-flops og countere i CMOS teknologi laves som master-slave FF dvs. en kortere eller længere ring af skiftevis masters og slaves, hvor det er altafgørende for funktionssikkerheden, at ingen master og slave nogensinde er åben samtidig. Det kan sikres med et globalt low-skew clocknetværk (synkront design) eller ved en fælles metalisering i en ASIC; men ingen af de muligheder har man ved asynkront design i en FPGA. Her er en dual-phase clock en mulighed, da den giver en pause, hvor både master og slave er lukket samtidig i en (længere) periode.

Med mindre selvfølgelig det du skriver er at værktøjet ikke overholder de constraints du har sat op, men sådan læser jeg det ikke.

Hvis du vil sikre funktionen af et asynkront master-slave system ved at specificere constraints, skal du ned på tider, som er lig med delay'et i hver gate dvs. typisk omkring 0,5 ns, og det skal sikres for hver eneste clockindgang i f.eks. en counter. Det vil ofte gøre det umuligt at route kredsen uden en global clock, da du jo ikke kan route fra clockindgang til clockindgang uden at addere delay'ene sammen (virker som et stigenetværk med seriemodstande (routing) og parallelkondensatorer (gate kapaciteter).

Carsten Kanstrup

Jeg tror bare de fleste regner med, at et kredsløb fungerer

Det tror jeg de færreste regner med, i hvertfald ingeniører , det er derfor der er noget der hedder "technical errata", hvor man efter produktion af en chip kan se hvilke ting der ikke virker og hvilke man skal lave en workaround på, for at virke.

Jeg snakker ikke om "technical errata", som man trods alt kan læse sig til. Jeg snakker om de problemer, som ikke omtales nogen steder, og som man kun kan få kendskab til ved et virkeligt godt indblik i, hvad der sker "under motorhjelmen".

Det burde være sådan, at man kan stole 100% på sine værktøjer; men det kan man desværre ikke altid i praksis.

Lars Opstrup Poulsen

Det er ikke et givent routing delay, der er problemet, men forskelle i routing delay, som opstår ud fra den tilfældige routing.


Jo det er et problem at dit design er afhængig af et givent routing delay, når du ikke har gjort dig umage med at fortælle værktøjet hvad dette delay skal være.
Når du ikke har gjort dig umage med dette havner du i situationer hvor du ender med at skrive:

Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne.

Når du skriver dette, samt det uoverskuelige i at constraine et asynkront design, kommer du altså til at fremstå som om du ikke rigtig har forstået problematikkerne og løsningerne på samme. Det er muligt det ikke er tilfældet men nu ved du hvilken følelse dine læsere sidder tilbage med.

Carsten Kanstrup

Jo det er et problem at dit design er afhængig af et givent routing delay, når du ikke har gjort dig umage med at fortælle værktøjet hvad dette delay skal være.

Vrøvl. Hvis jeg specificerer constraints på 0,5 ns eller mindre på samtlige clock-input i en counter, kan kredsløbet ikke routes uden brug af dedikerede clocknetværk, som jeg jo netop skriver - gider du læse det, inden du farer til tasterne?

Når du skriver dette, samt det uoverskuelige i at constraine et asynkront design, kommer du altså til at fremstå som om du ikke rigtig har forstået problematikkerne og løsningerne på samme. Det er muligt det ikke er tilfældet men nu ved du hvilken følelse dine læsere sidder tilbage med.

Jeg har aldrig skrevet, at det er uoverskueligt at specificere constrains; men det giver ingen mening at gøre det, da man i så fald ikke kan route kredsløbet! Jeg har om nogen - incl. Actel/Microsemi - i høj grad forstået problematikken og har arbejdet med FPGA'er i 30 år. Hvis nogen læsere incl. dig og PHK ikke forstår den, må det skyldes jeres manglende kendskab og erfaring med asynkront FPGA design.

Finn Glamhøj

Ja, lad os endelig få den kære jantelov på bordet.

Det er nok desværre et fåtal, som går så grundigt til værks som mig og kikker så dybt under "motorhjelmen", inden de bruger et system.

Janteloven bliver brugt af folk der udover at mene at de selv er fantastiske (hvilket de naturligvis har lov til) også mener, at det skal alle andre også mene.

Hvordan ved du, at andre ikke går grundigt tilværks?

Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne.

Hvis du designer et kredsløb således, at ændringer et helt andet sted (i ikke relaterende kredsløb) vil få dit kredsløb til at holde op med at virke, så må det være en fejl i dit design da der tydeligvis er mulighed for at der kan opstår en race condition.

Det kan sikres med et globalt low-skew clocknetværk (synkront design) eller ved en fælles metalisering i en ASIC; men ingen af de muligheder har man ved asynkront design i en FPGA. Her er en dual-phase clock en mulighed, da den giver en pause, hvor både master og slave er lukket samtidig i en (længere) periode

I øvrigt så kan jeg ikke se det giver mening, at påstå at du designer asynkrone kredsløb og samtidig bruger en dual phase clock fordi det jo netop gør at kredsløbet bliver synkront (synkronisere til din dual phase clock).

Poul-Henning Kamp Blogger

I øvrigt så kan jeg ikke se det giver mening, at påstå at du designer asynkrone kredsløb og samtidig bruger en dual phase clock fordi det jo netop gør at kredsløbet bliver synkront (synkronisere til din dual phase clock).

Finn,

Lad være med at spilde for meget tid på Carsten, han lever i sin egen verden hvor han har sine egne naturlove og en af dem er at alle andre ved mindre end han gør.

Mads T. Jensen

Nu ved jeg tilfældigvis lidt om systemet bag det nye signalnet og jeg kan oplyse om, at de som alle fornuftige mennesker burde gøre, slukkede computeren, da de skiftede cartridge. Alle ved man ikke må tage et cartridge ud mens C64'eren er tændt. Hvordan skulle de ellers ændre køreplanen?

Carsten Kanstrup

Hvordan ved du, at andre ikke går grundigt tilværks?

Så ville bl.a. Actel, der lavede FPGA'en, ikke have valgt en gate-implementering, der kan generere glitches, og de ville have indset, at alle 16 ud af 16 gatemuligheder i ACT 1 kunne udnyttes i stedet for 12.

Jeg har fra mit eget virke flere eksempler på, at kredsløb kan virke i én version, men fejle i næste version ved få rettelser et helt andet sted, fordi kredsen så routes lidt forskelligt - og det på trods af, at jeg er meget opmærksom på problemerne.

Hvis du designer et kredsløb således, at ændringer et helt andet sted (i ikke relaterende kredsløb) vil få dit kredsløb til at holde op med at virke, så må det være en fejl i dit design da der tydeligvis er mulighed for at der kan opstår en race condition.

Netop, og derfor måtte selv en 2-deler, som jeg ellers havde anset for sikker, redesignes til dual-phase clock. Race condition opstod netop pga. forskelle i routing af det samme kredsløb. Man skal stort set helt ned på transistorniveau, hvis man vil have fuld sikkerhed, og ingen steder kan man tillade sig at "slappe lidt af".

Det kan sikres med et globalt low-skew clocknetværk (synkront design) eller ved en fælles metalisering i en ASIC; men ingen af de muligheder har man ved asynkront design i en FPGA. Her er en dual-phase clock en mulighed, da den giver en pause, hvor både master og slave er lukket samtidig i en (længere) periode

I øvrigt så kan jeg ikke se det giver mening, at påstå at du designer asynkrone kredsløb og samtidig bruger en dual phase clock fordi det jo netop gør at kredsløbet bliver synkront (synkronisere til din dual phase clock).

Man kan altid diskutere betegnelser; men jeg bruger dem, du også vil finde i en databog for logikkredse. Når jeg f.eks. snakker om en asynkron deler eller delerkæde kontra en synkron deler eller delerkæde, er den asynkrone typisk udformet så ét trin clocker det næste. I mit tilfælde vil hvert trin dog typisk dele med 4 eller 5 i stedet for 2, da det sparer på kredsløbet til at generere dual-phase clock til det næste trin. Ved synkront design vil samtlige clockindgange i hele delerkæden have én fælles clock, og de enkelte trin styres så af et enable netværk, der bliver større og større for hvert trin, hvilket kræver rigtig mange gates ved store deleforhold.

Carsten Kanstrup

Commodore Amiga og NASA artikel... Det ser det ud til at Amiga'erne ikke kun blev brugt til display af data men også bearbejdede dem.

http://obligement.free.fr/articles_traduction/amiganasa_en.php
https://www.youtube.com/watch?v=qAPD9HA8Unw

Nemlig. Tusind tak for disse links, som jeg ikke har set før :-)

Den pågældende dansker, som jeg i sin tid hørte det fra (jeg kan stadig ikke komme på navnet), fik faktisk en rimelig høj ledende stilling hos Commodore i USA, og hvorfor skulle han fortælle løgnehistorier? Det ærgelige var bare, at Commodore's PR afdeling ganske simpelt ikke kunne se potentialet i at få den slags viden ud til offentligheden. I stedet "solgte" de kun Amigaen som "Verdens vildeste spillecomputer", og dermed begik de reelt set selvmord. Jeg tror godt de kunne have fået en stor del af automationsmarkedet og måske også kontorsiden. Dengang IBM med deres PC stadig skrev ud på en nåleskriver fra DOS, kørte jeg fuld Desktop Publishing til en Postscript LED-printer fra Amigaen; men den blev alligevel ikke opfattet som "seriøs" :-(

Carsten Kanstrup

Lad være med at spilde for meget tid på Carsten, han lever i sin egen verden hvor han har sine egne naturlove

Selvfølgelig har jeg ikke mine egne naturlove. Kan du virkelig ikke finde noget mere begavet at beskylde mig for, når du ikke magter at argumentere sagligt?

og en af dem er at alle andre ved mindre end han gør.

Hvad med at feje for din egen dør først? Man kan jo bare læse din blog for at finde ud af, hvad du mener om dine egne evner og viden i forhold til andres!!!

Henrik Matzen

Nemlig. Tusind tak for disse links, som jeg ikke har set før :-)

Den pågældende dansker, som jeg i sin tid hørte det fra (jeg kan stadig ikke komme på navnet), fik faktisk en rimelig høj ledende stilling hos Commodore i USA, og hvorfor skulle han fortælle løgnehistorier? Det ærgelige var bare, at Commodore's PR afdeling ganske simpelt ikke kunne se potentialet i at få den slags viden ud til offentligheden.

Velbekomme, Carsten :-) Det er bestemt ret interresant, Amiga'en har været involveret i meget mere end man lige går og tror.

Én dansker på mit nethinde er John Zinck - han endte i en høj stilling hos Commodore US - men jeg mindes også der var en decideret udvikler der kom derover, og hans navn er også forsvundet for mig lige nu :-)

Helt enig mht. den måde de fik den markedsført på - altså de gjorde det jo noget bedre i Europa, men på deres hjemmemarked samt APAC var de jo slet ikke med..

  • og ja, vi arbejdede i farver, stereo lyd, GUI og multitasking før de andre overhovedet kunne følge med.. og mine Amiga'er kører såmænd fint stadigvæk her 25~30 år senere :-)

Kan iøvrigt anbefale en rigtig fin film der udkom i starten af året:
https://vimeo.com/ondemand/vivaamiga/195541850

Log ind eller opret en konto for at skrive kommentarer