Alt ut for Altinn

[Shruggie]

Du glemmer at YouTube er basert på et (relativt) fåtall store filer som skal deles på mange brukere over hele verden samtidig. AltInn er et enormt antall små filer som skal deles på mange bruker i et lite område. Derfor er cache langt smartere.

[Shruggie]

Uansett. Den personen som for noen dager siden sa at løsningen er en enkel tekstmelding med: "Du får igjen/blir skyldig kroner X" har helt rett. I tillegg legger du til: du får mulighet til å sjekke selvangivelsen i tre dager fremover. Din pulje har tilgang mellom 16.00 og 17.00 20/3, 21/3 og 22/3. I tillegg vil alle få tilgang kontinuerlig fra 1/4.

 

Eller lignende.

Perfekt løsning.

[Terrasque]

Hm, naturligvis har plattform mye å si for skalerbarhet. Facebook har utviklet en egen kompilator for php på grunn av det. ref. http://en.wikipedia..../HipHop_for_PHP

 

Oi, glemte nesten denne i alt det andre. Du mikser opp horisontal skalering og vertikal skalering.. Beklager, skulle være mer presis der. Horisontal skalering er design, og har ingenting å gjøre med språk og plattform. Vertikal skalering har delvis med det å gjøre, men du har få options når du går forbi maks kapasitet for serveren den kjører på. Derfor, når man snakker om skalering på slike ting som dette, snakker man om horisontal skalering. Altså, hovedsaklig evnen til å bryte opp arbeidsmengen og spre den over flere maskiner.

[Del]

Må bare kommentere på denne.. Hvis du ser

(14:50 og litt utover) av den youtube videoen jeg nevnte tidligere, ser du at han nevner et par skalerings-teknikker de går etter. Blant annet "divide and conquer" - han nevner blant annet database sharding, og å dele prosesser opp i deler og sub-deler som kan kjøres uavhengig av hverandre (Han nevner ganske ofte RPC som en av hoved-teknikkene dems).

Ja, de distrubuerer lasten på mange noder. Database sharding funker fint for det så lenge du har enkel lokalitet av data. I tilfelle Altinn burde både det og RPC være anvendelig, og kunne gi god skalering på databasebiten.

Jeg ser ikke noen som helst grunn til at det ikke kan gjøres på hvilken som helst plattform, med hvilket som helst programmeringsspråk, så lenge det har sockets tilgjengelig. Noen språk og plattformer har en del verktøy som gjør det lettere, men det er fremdeles noe du må designe inn i systemet.

Nå består systemene av mer enn bare databaser, og det er ikke opplagt at alt lar seg distribuere like greit. Eksempelvis påståes det at kommunikasjon mellom autentiseringsserverne forårsaket at systemet var nede hele dagen.

Oi, glemte nesten denne i alt det andre. Du mikser opp horisontal skalering og vertikal skalering.. Beklager, skulle være mer presis der. Horisontal skalering er design, og har ingenting å gjøre med språk og plattform.

Jeg blander ikke, jeg bare tok for meg den beste formen for parallellitet som man alltid bør gå etter først, nemlig parallellitet på instruksjonsnivå. Hvis du ønsker å skalere koder, er dette en av nøklene. Å bare slenge på flere noder med råtten plattform har sine begrensninger. Du har essensielt tre nivåer parallellitet, i HPC trenger du å vurdere alle tre. Horisonal og vertikal er ikke tilstrekkelige begrep.

 

Når det gjelder å splitte opp i prosesser, så har det klare begrensninger. Begrepet lokalitet er svært viktig her. Dernest har du Amdahls lov, det kan ligge serielle elementer i problemet. Det nydelige med ILP (instruction-level parallelism) er at den kan hjelpe deg rundt Amdahls lov (og forsåvidt lokalitet).

[henrikwl]

Jeg har skrevet det før, jeg skriver det igjen: Det spiller ingen rolle HVOR buggen var, noen er ansvarlig for den. Rent teknisk kan vi si i dette tilfellet at det var de som skrev cache-greia som er ansvarlig, men spørsmålet er da hvem som valgte dette produktet. Gjorde de en god nok jobb? Var dette programvare de kunne gå inne for. Det har de tydeligvis gjort, så Accenture er til slutt ansvarlig. (Antageligvis. Det kan selvsagt hende at denne softwaren var en del av kravspeccen fra myndighetene, men jeg tviler.)

 

Her er det visst litt forvirring ute og går igjen. For det første: det er ikke snakk om en softwarekomponent. BIG-IP er en hardware lastbalanserer, og feilen lå i firmware på denne. For det andre: en kunde er ikke ansvarlig for bugtesting av utstyr fra leverandør. Det blir som å si at du er ansvarlig for skadene etter at bremsene på den flunkende nye Toyotaen din svikter, siden det var du som valgte akkurat den bilen.

 

Når man er på innkjøpsrunde, er ens første prioritet hvorvidt utstyret tilfredsstiller funksjonalitetskravene man har. Hvorvidt utstyret er pålitelig eller ikke bedømmes i stor grad ut i fra produsentens omdømme, samt andres erfaring med produktet. Det er veldig få som har midler nok til å kjøre lange pilotperioder med stresstesting og full pakke. Man forventer at produsenten har tatt den utgiften under utviklingen av produktet.

[Del]

Her er det visst litt forvirring ute og går igjen. For det første: det er ikke snakk om en softwarekomponent. BIG-IP er en hardware lastbalanserer, og feilen lå i firmware på denne.

Jeg er redd det er du som er forvirret. Jeg kompilerer all firmware på mine routere selv. En av mine litt sære interesser, hvor jeg også synes det er morsomt å spore bugs. I gråsonen finner du fpga, men denne lastbalensereren kjører nok en mer standard CPU arkitektur, og denne cachemodulen kan du trygt gå ut ifra at er implementert i software, uansett om man ender opp med å kalle binærfilen(e) firmware overfor kunde.

For det andre: en kunde er ikke ansvarlig for bugtesting av utstyr fra leverandør.

Enten tester du selv, eller så ber du om dokumentasjon fra leverandør. Å ta snarveier her er ikke OK. Hvordan tror du det hadde gått i Nordsjøen om man ikke hadde hatt ordentlige rutiner for å sikre at alle komponenter gjør det de skal. Er du gammel nok til å huske Sleipner? Du trenger et kurs i sikkerhet før du får befatning med systemer som håndterer sensitive opplysninger.

Det blir som å si at du er ansvarlig for skadene etter at bremsene på den flunkende nye Toyotaen din svikter, siden det var du som valgte akkurat den bilen.

Jeg proklamerer herved Dels lov: Alle diskusjoner på internet kommer til slutt til et punkt hvor noen drar frem bilanalogier. Det er et klart tegn på at diskusjonen er i ferd med å spore av fra ethvert konstruktivt spor. Endret 25. mars 2012 av Del

[henrikwl]

Jeg er redd det er du som er forvirret. Jeg kompilerer all firmware på mine routere selv. En av mine litt sære interesser, hvor jeg også synes det er morsomt å spore bugs. I gråsonen finner du fpga, men denne lastbalensereren kjører nok en mer standard CPU arkitektur, og denne cachemodulen kan du trygt gå ut ifra at er implementert i software, uansett om man ender opp med å kalle binærfilen(e) firmware overfor kunde.

 

Hva du synes er morsomt å gjøre er da vel ikke veldig relevant. Det er de færreste hardwareleverandører som leverer kildekoden sammen med enhetene sine, og uansett er dette en luksus de færreste prosjekter av en viss størrelse har midler til å gjøre - det er gjerne derfor man handler dedikert utstyr i utgangspunktet. Si meg, hvor mye prosjekterfaring har du egentlig?

 

Og nei, leverandøren kan ikke bare "kalle binærfilene firmware ovenfor kunde". Jeg antar du vet forskjellen på firmware og software, så hvorfor du formulerer deg slik forstår jeg ikke.

 

Enten tester du selv, eller så ber du om dokumentasjon fra leverandør. Å ta snarveier her er ikke OK. Hvordan tror du det hadde gått i Nordsjøen om man ikke hadde hatt ordentlige rutiner for å sikre at alle komponenter gjør det de skal. Er du gammel nok til å huske Sleipner? Du trenger et kurs i sikkerhet før du får befatning med systemer som håndterer sensitive opplysninger.

 

Og hva får deg til å anta at det har blitt tatt snarveier angående valg av BIG-IP? F5 er en vel anerkjent leverandør, og BIG-IP er et mye brukt produkt; det er ingen grunn til å anta at produktet holder generelt lav kvalitet.

 

Videre, gitt at alderen du har oppgitt i profilen din stemmer, og gitt at vi har foretatt de samme utdanningsvalgene, har jeg jobbet med slike ting 4 år lenger enn deg. Hva med Sleipner mener du er relevant å sammenligne med her?

[Del]

Hva du synes er morsomt å gjøre er da vel ikke veldig relevant.

Jeg forsøkte bare å forklare deg at firmware ofte er software. Du ser også ut til å ha store problemer med å forstå hva minnehåndtering er, og da blir meningsfull diskusjon svært vanskelig.

Det er de færreste hardwareleverandører som leverer kildekoden sammen med enhetene sine, og uansett er dette en luksus de færreste prosjekter av en viss størrelse har midler til å gjøre - det er gjerne derfor man handler dedikert utstyr i utgangspunktet.

Man trenger ikke tilgang til kildekode for å gjøre testing. Man trenger ikke å gjøre testing en gang hvis leverandør kan dokmentere testing. Si meg leser du noe av det jeg skriver før du svarer?

Si meg, hvor mye prosjekterfaring har du egentlig?

Mistet tallet på hvor mange prosjekter jeg har vært ansvarlig for, så det begynner å bli en del.

Og nei, leverandøren kan ikke bare "kalle binærfilene firmware ovenfor kunde". Jeg antar du vet forskjellen på firmware og software, så hvorfor du formulerer deg slik forstår jeg ikke.

Vennligst forklar meg akkurat hva du tror ligger i ordet firmware? Når du har gjort det så kan jo du og jeg ha et lite veddemål. Jeg er villig til å satse noen kroner på at feilen hos Big-ip blir rettet i software, ikke med loddebolt.

Og hva får deg til å anta at det har blitt tatt snarveier angående valg av BIG-IP?

Rapporten naturligvis. Det ser ikke ut til at Accenture har gjort noen egen kvalifisering av denne delen, men slått seg til ro med at siden mange andre bruker den, så er den sikkert bra nok her også.

F5 er en vel anerkjent leverandør, og BIG-IP er et mye brukt produkt; det er ingen grunn til å anta at produktet holder generelt lav kvalitet.

Snakk om snørr og bart. Det handler ikke om hvovidt man har grunn til å tro at produktet har feil. Det handler om å gjøre en uavhengig vurdering av hvorvidt produktet er testet godt nok, eventuelt ikke tiltro den komponentet sensitiv informasjon overhodet. Bare så dette er helt klart for deg. Det kan hende Accenture har gjort alt riktig i denne saken, det er ikke det jeg sier. Jeg sier at det er på ingen måte klart i dag. Skjønte du nyanseforskjellen? Det ligger en plass mellom svart og hvitt.

Videre, gitt at alderen du har oppgitt i profilen din stemmer,

Hm, jeg har ikke oppgitt noen alder, og tenkte ikke gjøre det nå heller. Jeg var ikke ute etter alderen din, men Sleipner er en svært relevant sammenligning, all den tid at det også der visstnok var bruk av software, ja software, som forårsaket uhellet.

http://en.wikipedia.org/wiki/Sleipner_A#1991_accident

[Shruggie]

Bilanalogien feiler med en gang siden du snakker om en privatbil. En mer korrekt analogi hadde vært om jeg var ansvarlig for å velge hvilken bil skulle bli brukt som ambulanse i hele Norge, og det viser seg året etter at bilen har et problem hvor gasspedalen fester seg i gulvet, noe som fører til en dødsulykke.

[JohndoeMAKT]

BIG-IP er en hardware lastbalanserer, og feilen lå i firmware på denne.

Har du en kilde på dette? Det jeg har lest er «feil i BIG-IP», men ikke spesifisert om det er «feil i BIG-IP firmware», «feil i applikasjonens bruk av BIG-IP» eller «feil i konfigurasjon av BIG-IP».

En PDF jeg leste et par dager siden sa omtrent «profilsiden til Kenneth(36) ble feilaktig cachet i BIG-IP-lastbalansereren. Cachefunksjonen ble derfor deaktivert. F5 undersøker problemet, men greier ikke reprodusere problemet».

 

Så har du en kilde på at det faktisk var feil på selve enheten og at det ikke bare var der systemfeilen var?

[Terrasque]

BIG-IP er en hardware lastbalanserer, og feilen lå i firmware på denne.

har du en kilde på at det faktisk var feil på selve enheten og at det ikke bare var der systemfeilen var?

 

Fant dette i en digi.no artikkel:

Dette er en feil som ikke har vært sett tidligere.

.......

 

F5 sendte aldri eksperter fra USA over dammen, slik enkelte pressoppslag har hevdet. Derimot arbeidet selskapet med problemstillingen i laben, der de også har lykkes med å gjenskape feilen i en lignende situasjon.

 

- De jobber fortsatt med å verifisere at de har fått med seg alt. Når de er ferdig med det vil jeg tro at de kommer med en feilfiks som retter problemet, sier Viksaas.

Endret 25. mars 2012 av Terrasque

[henrikwl]

Jeg forsøkte bare å forklare deg at firmware ofte er software. Du ser også ut til å ha store problemer med å forstå hva minnehåndtering er, og da blir meningsfull diskusjon svært vanskelig.

 

For det første, det firmware og software har til felles er at de begge består av prosessorinstruksjoner og data. Det gir dog ingen mening å sammenligne dem ut over dette. Både distribusjon og deployment er så vidt forskjellig at å snakke om dem som om de var det samme er en grov overforenkling.

 

For det andre, jeg har problemer med å forstå minnehåndtering? Så langt er jeg langt mer skeptisk til hvorvidt du har begrepsbruken din på det tørre her; jeg antar det er fordi du overforenkler i et forsøk på å holde diskusjonen leselig for ikke-tekniske brukere. Et prisverdig foretak, men husk på at andre tekniske personer ikke nødvendigvis vet hvordan du tenker i det du forenkler begrepsbruken.

 

Du ser jo at overgangen "det var en feil i cachemodulen i hardware-lastbalansereren fra F5" til "ja, Microsoft løsninger har som regel dårlig minnehåndtering" er svært mangelfull i teknisk sammenheng.

 

Man trenger ikke tilgang til kildekode for å gjøre testing. Man trenger ikke å gjøre testing en gang hvis leverandør kan dokmentere testing. Si meg leser du noe av det jeg skriver før du svarer?

 

Jeg leser det du skriver, så jeg synes gjerne du kunne gjengjelde tjenesten. Jeg spurte deg hva som får deg til å tro at F5 ikke har dokumentert testing under utvelgelsesprosessen. Kan du vise til noen kilder som underbygger den antakelsen?

 

Mistet tallet på hvor mange prosjekter jeg har vært ansvarlig for, så det begynner å bli en del.

 

Så bra, da vet du utmerket godt at når kunden vil ha funksjonalitet i går, så er det ikke mye gehør å få for "vi bør heller kompilere firmware til ruterne våre selv i stedet for å gå for Cisco-rutere".

 

Vennligst forklar meg akkurat hva du tror ligger i ordet firmware? Når du har gjort det så kan jo du og jeg ha et lite veddemål. Jeg er villig til å satse noen kroner på at feilen hos Big-ip blir rettet i software, ikke med loddebolt.

 

Se over. Firmware er ikke software. Hvis det (hypotetisk sett) skulle oppdages en bug i Cisco-rutere, hvor f.eks. pakker over en viss størrelse ble droppet, ville ingen tekniker med respekt for sitt fag kalt det en softwarefeil.

 

Rapporten naturligvis. Det ser ikke ut til at Accenture har gjort noen egen kvalifisering av denne delen, men slått seg til ro med at siden mange andre bruker den, så er den sikkert bra nok her også.

 

"Det ser ikke ut til"? Enten så mottok de dokumentasjon, eller så mottok de den ikke.

 

Snakk om snørr og bart. Det handler ikke om hvovidt man har grunn til å tro at produktet har feil. Det handler om å gjøre en uavhengig vurdering av hvorvidt produktet er testet godt nok, eventuelt ikke tiltro den komponentet sensitiv informasjon overhodet. Bare så dette er helt klart for deg. Det kan hende Accenture har gjort alt riktig i denne saken, det er ikke det jeg sier. Jeg sier at det er på ingen måte klart i dag. Skjønte du nyanseforskjellen? Det ligger en plass mellom svart og hvitt.

 

Du uttaler deg fryktelig bastant med tanke på at detaljene her "på ingen måte er klart i dag". Det er mye synsing ute og går, Microsoft-antipati (historisk sett berettiget, innrømmeligvis) og en tendens til å ville gi dem skylden for alt. En feil i utstyr fra F5 er en feil i utstyr fra F5, uavhengig av hvor godt testet det er. Microsoft har ikke ansvar for alle feil i et system som benytter komponenter fra dem. Selv det best testede utstyret i verden vil kunne inneholde feil. Heldigvis var F5 raskt på banen her og fikk isolert og fikset problemet, all ære til dem for det.

 

Hm, jeg har ikke oppgitt noen alder, og tenkte ikke gjøre det nå heller. Jeg var ikke ute etter alderen din, men Sleipner er en svært relevant sammenligning, all den tid at det også der visstnok var bruk av software, ja software, som forårsaket uhellet.

http://en.wikipedia....A#1991_accident

 

Da har jeg nok blingset, og/eller blandet din profil med en annen. Beklager det.

 

Du er dog fortsatt den eneste tekniker jeg har vært borti som nekter å vedkjenne seg firmware-begrepet. Noen spesiell grunn til det?

Endret 27. mars 2012 av henrikwl

[Del]

For det første, det firmware og software har til felles er at de begge består av prosessorinstruksjoner og data. Det gir dog ingen mening å sammenligne dem ut over dette.

Vi snakker om en cache modul. Den er høyst sannsynlig kodet i C og kompilert opp som enhver annen kode, sannsynligvis er den en modul i ordets riktige forstand, en modul kodet i C. At den kalles firmware er typisk fordi den kommer på en ferdig boks hvor det ikke er meningen at kunder skal installere OS eller applikasjoner. Med andre ord gjelder de samme forhold som for annen software, man bør vuderer hvor godt testet denne komponenten er for akkurat den bruk man har.

Både distribusjon og deployment er så vidt forskjellig at å snakke om dem som om de var det samme er en grov overforenkling.

Faktisk kan deployment (få boksen ferdig oppsatt) og distribusjon (oppgradering over nett eller gjennom en pakket fil) være identisk alt ettersom.

Du ser jo at overgangen "det var en feil i cachemodulen i hardware-lastbalansereren fra F5" til "ja, Microsoft løsninger har som regel dårlig minnehåndtering" er svært mangelfull i teknisk sammenheng.

Ja, den er i grunnen ment å åpne en diskusjon. En mulig kobling er rett og slett at cache modulen er nødvendig primært fordi minnehåndtering i resten av systemet er så dårlig at man må kompensere ytelsesmessig. En annen mulig kobling er at generelt sloppy forhold til minnehåndtering kan forklare hvorfor man lar en tredjeparts modul selv få bestemme om den vil cache sensitive data. Men å konkluderer med at jeg mener minne=cache blir en rimelig fet stråmann.

Jeg leser det du skriver, så jeg synes gjerne du kunne gjengjelde tjenesten. Jeg spurte deg hva som får deg til å tro at F5 ikke har dokumentert testing under utvelgelsesprosessen. Kan du vise til noen kilder som underbygger den antakelsen?

Ja, notatet fra Accenture og Basefarm De argumenterer med at siden mange andre bruker produktet så kunne ikke de vite at det var feil i det (eller noe i den duren, du finner nøyaktig ordlyd i rapporten). At de har sluppet unna med en så latterlig unnskyldning er utrolig. At andre bruker delen betyr ikke at den er kvalifisert for Altinn. Man blir gitt inntrykk av at Accenture her ikke har gjort noen selvstendig vudering. Her skal du få et annet eksempel av meg som viser hvor galt det går når man antar at kvalifisering for et formål automatisk kvalifiserer for et annet:

http://en.wikipedia.org/wiki/Cluster_%28spacecraft%29#Launch_failure

Regningen her var også i likhet med Sleipner i milliardklassen.

 

Kanskje det er vanlig strategi fra Accenture, å velge en stor leverandør for da trenger de ikke kvalifisere teknologien. Kanskje derfor de valgte Microsoft også, for da kan jo Microsoft ta støyten hvis systemet deres kollapser. Det begynner å tegne seg et mønster, og mønsteret er ikke pent.

Så bra, da vet du utmerket godt at når kunden vil ha funksjonalitet i går, så er det ikke mye gehør å få for "vi bør heller kompilere firmware til ruterne våre selv i stedet for å gå for Cisco-rutere".

Kutt ut stråmenn. Jeg forsøkte å gjøre dialogen jovial ved å dele av meg selv, sørgelig at du svarer slik.

[Del]

Angående definisjon av firmware, her har du den:

http://en.wikipedia.org/wiki/Firmware

Les spesielt denne biten:

There are no strict boundaries between firmware and software, as both are quite loose descriptive terms. However, the term firmware was originally coined to contrast with higher-level software which could be changed without replacing a computer hardware component. Firmware is typically involved with very basic low-level operations, without which a device would be completely non-functional.

[nebrewfoz]

_{Oppsummering i Teknisk Ukeblad 28/3: http://www.tu.no/it/2012/03/28/her-stoppet-altinn}

[Del]

Ser ut som støvet begynner å legge seg. Noen fant også bug-rapporten fra F5:

http://support.f5.com/kb/en-us/solutions/public/13000/400/sol13493.html?sr=20349498

 

Henrik, du får være glad for at vi ikke veddet, det ser ut til at Basefarm, F5 og omtrent alle andre ser på dette som en programvare bug, og fiks gjøres for øyeblikket som du ser med kode, på klientsiden.

 

Personlig har jeg vel allerede gitt uttrykk for det tydelig nok , men jeg står for det ennå. Nemlig at Accenture har gjort en meget dårlig figur i denne saken. Overrasket over at ikke flere i denne tråden ser dette.

[Terrasque]

Ser ut som støvet begynner å legge seg. Noen fant også bug-rapporten fra F5:

http://support.f5.co...tml?sr=20349498

 

Henrik, du får være glad for at vi ikke veddet, det ser ut til at Basefarm, F5 og omtrent alle andre ser på dette som en programvare bug, og fiks gjøres for øyeblikket som du ser med kode, på klientsiden.

 

Personlig har jeg vel allerede gitt uttrykk for det tydelig nok , men jeg står for det ennå. Nemlig at Accenture har gjort en meget dårlig figur i denne saken. Overrasket over at ikke flere i denne tråden ser dette.

 

Personlig ser jeg egentlig ikke hvorfor du bryr deg med det, og hvorfor du mener at en tidligere ukjent feil i et 3djeparts system er noe de kan klandres for.

 

Bare så vi er på samme side her.. Du vet at det er matematisk umulig å garantere at et program er feilfri i de aller aller fleste tilfeller? Og at man derfor også aldri kan være sikker på at et program av en viss kompleksitet ikke har bugs? Du sier kanskje "Dette burde kommet opp i testing" - kanskje, kanskje ikke.. Grunnet samme problem kan man heller ikke teste alt 100%, så all testing er da per definisjon mangelfull.

 

Så om det er en software bug eller hardware bug har ingen praktisk betydning i dette tilfellet.

 

Edit: På de ruterne du compilet egen firmware på, som du snakket om tidligere. Er de linux-basert? Har du kjørt linux noensinne, på en server?

Endret 31. mars 2012 av Terrasque

[Del]

Personlig ser jeg egentlig ikke hvorfor du bryr deg med det, og hvorfor du mener at en tidligere ukjent feil i et 3djeparts system er noe de kan klandres for.

Jeg klandrer dem ikke for at feilen var der. Jeg klandrer dem for følgende momenter:

-de ser ikke ut til å ha gjort en selvstendig vurdering av tredjepartssystemet

-de ser ikke ut til å ha mer enn ett lag sikkerhet på den delen av systemet, i sikkerhetsammenheng er det elementært å ha flere lag sikkerhet nettopp fordi alle systemer feiler innimellom.

-jeg stiller spørsmålstegn ved hvorfor en cache modul var nødvendig i første omgang, kanskje systemet er for komplekst (ref. bruk av mammutløsning fra microsoft)

-når tatt med buksa nede for tredje gang nekter de å ta noe ansvar til tross for at de har overordnet ansvar for hele løsningen. De vil ikke en gang uttale seg, men overlater det til Basefarm som kun er drifter i denne sammenhengen.

Bare så vi er på samme side her.. Du vet at det er matematisk umulig å garantere at et program er feilfri i de aller aller fleste tilfeller?

Nei, der er matematisk umulig å verifisere korrekthet av en algoritme i alle tilfeller. Dette ble bevist av Gödel som et svar på Hilberts utfordring til verdens matematikere i forrige århundre. ref. http://en.wikipedia....ert%27s_program

 

Nettopp derfor bør man alltid ha mer enn en barriere i sikkert design. Alle som har hatt et snev av opplæring i HMS vet dette.

Så om det er en software bug eller hardware bug har ingen praktisk betydning i dette tilfellet.

Enig, jeg bare synes det var en smule latterlig at Henrik insisterte på at det var en hardware bug.

Edit: På de ruterne du compilet egen firmware på, som du snakket om tidligere. Er de linux-basert? Har du kjørt linux noensinne, på en server?

Ja, jeg bruker OpenWrt. Jeg har blandet erfaring med firmware fra Cisco. Ja, jeg har en rekke linux servere kjørende til enhver tid. Det har jeg hatt i mange år. Hvordan det? Endret 1. april 2012 av Del

[selux]

Det er mulig å bevise at en algoritme er uten feil i alle tilfeller, helt klart at du ikke kan teorien din. Gödel sier heller ikke at det er umulig, men derimot umulig under noen omstendigheter, men mulig under andre. Vi gjør dette hele tiden når vi lager parallelle programmer. Modellen vår (algoritmen om du vil) vil være helt feil fri noe som lett kan bevises.

 

edit: kilde: http://en.wikipedia....al_verification

Endret 1. april 2012 av selux

[henrikwl]

-jeg stiller spørsmålstegn ved hvorfor en cache modul var nødvendig i første omgang, kanskje systemet er for komplekst (ref. bruk av mammutløsning fra microsoft)

 

Fordi som vi tidligere har prøvd å forklare deg: caching er elementært i all systemutvikling, uavhengig av leverandør.

 

Nettopp derfor bør man alltid ha mer enn en barriere i sikkert design. Alle som har hatt et snev av opplæring i HMS vet dette.

 

Det er ikke vanlig å snakke om HMS i forbindelse med informasjonssikkerhet og systemutvikling. Igjen formulerer du deg på en måte som skaper usikkerhet om hvorvidt du forstår hva det faktisk dreier seg om.

 

Enig, jeg bare synes det var en smule latterlig at Henrik insisterte på at det var en hardware bug.

 

Det har jeg aldri påstått. Jeg hevdet det var en feil i firmware, og så vidt jeg kan se har jeg rett. Det finnes ingen grunn til å tro at dette er software som kjører på Altinn sine servere.