Overzicht van de ergste bugs in de geschiedenis

In 1945 begon het allemaal: de Harvard Mark II-computer functioneerde tijdens een simpele vermenigvuldiging en optelling niet zoals het zou moeten. Na wat onderzoek vonden de wetenschappers de fout, namelijk een motje dat de computer binnen was gevlogen. Het beest werd gevangen en in het logboek geplakt met de tekst 'first actual case of a bug being found'. Met de jaren zijn de bugs gedigitaliseerd en anno 2005 wordt er vreemd opgekeken als er nog echt ongedierte computers binnen is gekropen. In de afgelopen zestig jaar zijn computers eveneens een grotere rol gaan spelen in onze samenleving. Waar de mot in Harvard Mark II hooguit een dag of twee extra werk opleverde voor wetenschappers, kan een vervelende bug vandaag de dag miljoenen aan schade opleveren. Er zijn zelfs gevallen bekend van situaties waarin mensen de dood vonden omdat een computersysteem niet goed functioneerde. Wired News vond dat het tijd werd om het zestigjarige jubileum te vieren met het opsommen van tien exemplaren van de meest schokkende bugs sinds 1945.

Mariner 1 takeoffIn 1962 moest de Mariner I-ruimtesonde boven de Atlantische Oceaan worden vernietigd omdat een formule verkeerd overgeschreven was van een beschreven papiertje. Twintig jaar later introduceerden agenten van de CIA een fout in het computersysteem van de trans-Siberische gasleiding, waarvan vermoed werd dat de aankoop door de Sovjet-Unie onderdeel uitmaakte van een project om geheime Amerikaanse technologie te kopen en te transporteren. Het resultaat was de grootste niet-nucleare explosie in de geschiedenis. Tussen 1985 en 1987 faalden Therac-25-apparaten in verschillende ziekenhuizen. Het apparaat, dat gebruikt werd voor stralingstherapie, bleek gevoelig te zijn voor een type bug genaamd 'race condition'. Als iemand de commando's te snel invoerde, kon het apparaat onverwachts een te hoge dosis straling leveren. Er vielen enkele zwaargewonden en minstens vijf patienten stierven ten gevolge van deze bug.

In 1988 brak 's werelds eerste internetworm uit en infecteerde binnen een dag tussen de twee- en zesduizend computers. De 'Morris Worm' maakte gebruik van een bufferoverflow-mogelijkheid in de Berkeley Unix finger-daemon. De routine in kwestie, de gets()-functie, werd uit de code van de daemon gehaald, maar de programmeurs weigerden het uit de standaard C-bibliotheek te halen. Deze bibliotheek is nu nog in gebruik en nog steeds kwetsbaar. Vanaf datzelfde jaar werd van Kerberos een Random Number Generator voor authenticatiemethoden in gebruik genomen. De programmeurs vergaten echter om de generator te voorzien van een juiste 'seed', waardoor de functie voorspelbare getallen uitspuwde. De bug is acht jaar later pas gevonden, maar er zijn geen gevallen bekend waarin deze is gebruikt in een aanval.

Intel divide bugBegin 1990 werd bekend dat de centrales die AT&T gebruikte voor interlokale gesprekken crashten als ze een bepaalde boodschap kregen van een andere centrale. Laat dat nu net de boodschap zijn die een soortgelijke centrale uitzond als deze van een crash herstelde. In New York was het zover: een centrale crashte en startte automatisch opnieuw op, met als gevolg dat de naburige centrales hetzelfde lot ondergingen. Binnen korte tijd waren 114 centrales om de zes seconden aan het herstarten en zestigduizend mensen konden negen uur lang niet buiten de regio bellen. Drie jaar later liep een relatief onschadelijke bug in de Intel Pentium-processor uit op een PR-fiasco. De processor kon bepaalde floatingpointgetallen niet precies genoeg delen en had een foutmarge van 0,006 procent. Aanvankelijk wilde Intel alleen dat deel van de 3 tot 5 miljoen defecte chips vervangen waarvan de gebruikers konden aantonen dat ze nadeel ondervonden van deze marge. Na veel kritiek gaf Intel toe en besloot elk defect exemplaar te vervangen als de klant daarom vroeg. Intel verloor $475 miljoen door deze bug.

In de jaren 1995 en 1996 werd er niet goed gecontroleerd op fouten binnen packets in de IP-fragmentatie herstelprocedure, wat tot gevolg had dat een verzameling besturingssystemen, waaronder Windows en Macintosh, konden vastlopen als deze een speciaal pingverzoek kregen. In juni van dat laatste jaar steeg de Ariane 5-raket op met dezelfde zelfde software die gebruikt werd door Ariane 4. Wat de wetenschappers niet hadden voorzien was dat de krachtigere motoren aanleiding gaven tot de openbaring van een bug die een overflow veroorzaakte in de boordcomputer. Dit had als resultaat dat het computersysteem de motoren verkeerd afstelde en veertig seconden na lancering de raket in vlammen deed opgaan.

Tot slot openbaarde zich in het najaar van 2000 wederom een fout in de software van bestralingsapparatuur. Deze keer vond het drama plaats in het National Cancer Institute in Panama City. Het programma dat de dosis van de straling uitrekende, maakte een fout als dokters de gegevens over het gebruik van metalen schilden verkeerd op het computerscherm tekenden. Deze schilden worden gebruikt om gezond weefsel te beschermen tegen de straling. Het programma was beperkt tot het gebruik van vier schilden, maar de artsen wilden er nogal eens vijf gebruiken. Ze wisten de software te foppen door de vijf schilden als één te tekenen en een gat in het midden te maken. Het programma bleek echter niet berekend te zijn op dit gebruik en gaf verschillende antwoorden op basis van de manier waarop het gat werd getekend. Minstens acht patiënten vonden de dood en twintig kregen door de overdosis aan straling extra gezondheidsklachten. De specialisten is doodslag ten laste gelegd.

Large bug on keyboard

Door Bart Veldstra

Freelance Nieuwsposter

10-11-2005 • 23:18

157

Bron: Wired News

Reacties (157)

157
152
65
18
2
35
Wijzig sortering
Hm, ik mis die neergestorte marslander van een paar jaar geleden. Een van de NASA-programmeurs had in de berekeningen inches en centimeters door elkaar gehaald wat er voor zorgde dat de raketten niet tijdig werden gebruikt en de landing nogal abrupt eindigde... Dat rekenfoutje heeft de Amerikaanse belastingbetaler een heleboel centjes gekost...

Zie bijv http://www.space.com/busi...oftware_crash_000331.html
Anoniem: 159988 @ymmv10 november 2005 23:49
Dit was niet echt een bug. Het programma deed precies wat ervan gevraagd werd, de programmeur helaas niet...
Met die definitie kun je wel heel veel bugs afschrijven als niet bug zijnde. In bijna alle gevallen in het artikel genoemd, doet de software precies wat er van verwacht was, dus dat zouden allemaal geen bugs zijn volgens jou?
In feite bestaan bugs niet, als de kamer goed was afgesloten, was er geen insect in gekomen, waardoor er geen verkeerd contact werd gelegd in de machine, waardoor er geen rekenfout ontstond.
Met andere woorden, bugs zijn allemaal tekortkomingen van de makers die in de machine/software verwerkt zijn.
Anoniem: 103774 @^Mo^11 november 2005 08:50
@gabiballetje
ja héhé, is nogal logisch als die systemen zelf ook door mensen zijn gemaakt :Y)

een bug is in mijn opvatting (en die van heel wat anderen ook) een stukje code wat niet volgens de specificaties werkt
Anoniem: 154239 @^Mo^11 november 2005 09:09
De hack van de CIA is geen bug, en de genoemde worm ook niet. Een bug is een foutje dat er per ongeluk ingeslopen is.
de worm maakt gebruikt van een bug in het besturingssysteem om te bestaan.. de worm is dus zelf niet de bug
Dat zeg ik. Feit is dus dat foutjes in de machine/code veroorzaakt door onzorgvuldigheid of onkunde van de mens "bugs" genoemd worden.
Elk stuk code doet precies wat er van verwacht wordt. Als de programmeur natuurlijk geen rekening houdt met de limieten van de machine of enkele variabelen door elkaar haalt dan gaat er inderdaad een probleem zijn, dat noemt men dan een bug. Dit is meestal onopzettelijk maar kan ook opzettelijk gebeuren.
Tja, een computer doet wat je zegt, niet wat je wil :+
Ik mis er ook één,

In de vietnam oorlog waren monteurs bezig met vliegtuigen die op een vliegdekschip stonden. Plotseling vuurde 1 vliegtuig al zijn raketten af, gevolg: een enorme explosie, 26 vliegtuigen ontploft, en een aantal doden (weet niet pecies hoeveel, maar iig meer dan 10)

Volgens kwam dit ook door een bug, maar weet het niet zeker.
Verkeerd draadje geraakt of zo ?
Oops :P
Veiligheidsmaatregelen niet in acht nemen noem ik geen bug.
Overigens was het één raket die de brand veroorzaakte die uiteindelijk 134 doden tot gevolg had.
zie o.a. http://www.lancehatfield.com/tonkin.htm
Waren dat geen meters en miles?
Om precies te zijn waren het feet en meters :)
meters en miles lijkt me onwaarschijnlijk ;) dan zou hij van 1 meter 1600 meter hebben gemaakt O.o

volgens mij is het inches/centimeter probleem ook eens voorgekomen met een warmteschild ofzoiets waardoor vele belasting centjes na de lanceren ook kapot gingen |:(

zoiets vind ik eigenlijk onvoorstelbaar :/ dat zijn toch de basic dingen in een berekening? als je dan een berekning moet maken voor apparatuur van miljoenen dubbel check je dat toch? en al helemaal de standaard dingetjes
Het probleem was geloof ik het verschil tussen hoogte in foots of meters ,een factor 3 :-)
Bij de Hubble was toch ook een plus door een min vervangen in een berekening, waardoor later de sateliet een "brilletje" kreeg?
Anoniem: 133254 @ymmv11 november 2005 23:59
In zweden staat er in een klein dorpje een kerk waar dezelfde fout is gemaakt --- inches in centimeters --- waardoor er dus een enorme kerk in een klein dorpje staat. Volgens deze logica is dat dus een (computerloze) bug?

Nee, dit is geen bug, wel een rekenfout. Het argument "computer deed exact wat gevraagd was, dus het is geen bug" is inderdaad niet helemaal goed... Maar de fout is een niveau boven het software-gebeuren, bij de input, gemaakt, dus ik zou het NASA (hey, was dat geen ESA ding, die crashende lander?... Noordwijk?... Hm, er zijn er toch geen twee kwijt?)
Uhmm.. volgens mij ging de Ariane 5 anders hoor.
Ding werd gelanceerd, systeem liep vast om wat voor reden dan ook.
Ding werd compleet onbestuurbaar en kantelde.
Men deed direct een self-destruct.


Kijk aan, wiki:
http://en.wikipedia.org/wiki/Ariane_5
http://en.wikipedia.org/wiki/Ariane_5_Flight_501
Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 40 seconds after launch because of a malfunction in the control software, which was arguably one of the most expensive computer bugs in history. A data conversion from 64-bit floating point to 16-bit signed integer value had caused a processor trap (operand error). The floating point number had a value too large to be represented by a 16-bit signed integer. Efficiency considerations had led to the disabling of the software handler (in Ada code) for this trap, although other conversions of comparable variables in the code remained protected.
Ariane is overgens daarmee volgens mij ook de duurste bug ooit.

Vreemd overgens dat de bufferoverflow LSAS van windows er niet bij staat.. Die was ook catastrofaal.
Zoals ik het gehoord heb:

Rakketten hebben een fout-controle systeem die ervoor zorgt dat, als ze neerstorten, ze automatisch vernietigd worden. (zodat ze niet op aarde vallen en mensen vermorzelen).
Dat neerstorten wordt uitgelezen van versnellingsmeters. Als je dat nu in een 32-bits integer stopt, en die loopt over (omdat de motoren een hogere acceleratie geven dan bij Ariane 4), dan wordt die weer heel laag. Software denkt dat de raket naar beneden gaat (neerstort) -> KABOEM, raket ontploft.
Als ik het goed heb onthouden van Discovery Channel kwam het ook omdat de oude software in de raket zat. Echter, er was wel degelijk nieuwe software geschreven voor de Ariane 5 raket (voor de nieuwe moteren etc).

Echter is door een miscommunicatie de oude software er weer ingeladen en inderdaad - de software kon niet met de nieuwe motoren overweg waardoor de raket na 40 seconden te veel overstuurde en dus omlaag kwam.
Gelukkig werkte de fail-safe wel perfect en blies de raket zichzelf op voordat hij terug kon vallen.
Alhoewel men wel er achter kwam dat de explosie in de lucht beter is dan op de grond, de rommel die een explosie zo dicht boven het lanceerplatform teweeg brengt ook verre van wenselijk was :D
Design by Contract: The Lessons of Ariane
by Jean-Marc Jézéquel, IRISA
and Bertrand Meyer, ISE :

http://www.mive.nl/Ariane.html

Ik hoop dat jullie 'm kunnen lezen anders zet ik straks even een miror open.

"The exception was due to a floating-point error: a conversion from a 64-bit integer to a 16-bit signed integer, which should only have been applied to a number less than 2^15, was erroneously applied to a greater number, representing the "horizontal bias" of the flight. There was no explicit exception handler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the on-board computers, hence the mission."

edit : Even mirror opgezet, sorry beetje aan de late kant
helaas, access denied.
Bugs bugs ... heb nog 2 weken geleden zo'n vervelende mot uit men case gehaald ... die beestjes hebben het gemunt op mijn fans die blauw licht geven blijkbaar ... ;(

Verder zat er ook nog een spin in me case .. maar die is precies toch ergens tussengekropen waar ze niet moest zitten ... want ze had nog maar 1 poot en de andere 7 pootjes lagen los in men case }>
Die is zeker naar binnen gegaan door een fan :+
insecten worden aangetrokken door infrarood licht, blijkbaar komt dat uit jouw kast :P
*kuch* unltraviolet *kuch*

Of denk je dat die insecten vanger in restaurants voor de sfeer blauw/violet licht uitzenden :+


Muggen vinden hun prooi wel mbv infrarood...
En toch klopt de naam goed, de processor van een vriend van mij is gestorven doordat er een spin eitjes aan het leggen was in zijn kast. |:(

Al is een spin geen insect (bug) maar toch.

@Cobra_lup

Een grotere versie van jouw het plaatje, deze is makkelijker te lezen:
First Bug
Ik denk dat eens spin wel een insect is hoor...
een insect heeft 6 poten, een spin 8.
en is dus GEEN insect
Een insect heeft zes poten, twee antennes; nul, twee of vier vleugels, en een in drieën verdeeld lijf. Een spin heeft echter acht poten en behoort daarom tot de categorie spinachtigen :Y).

Wel behoren zowel spinnen als insecten tot de geleedpotigen.
En wat als je een overgangsvorm hebt die op 8 poten kan lopen maar 2 van die poten óók als antenne kan gebruiken?
Ik herriner me de bug in de calculator van Windows 3.11 nog. Bij getallen tussen de 2 en 16 ging het mis met de afronding van de tweede decimaal.
Bijvoorbeeld 12.01-12 gaf 0.00.
Het grappige was dat de meeste gebruikers zich in die tijd veel meer opwonden over de bug in de Pentium dan deze bug, waar de kans veel groter was dat je ermee te maken kreeg.
LOL !!!
Da's best slecht...
Ik weet niet of ik andere post verkeerd opvat en die zeggen maybe hetzelfde. Maar die marslander op mars die zich waarbij:

- robot raakt steen en zit vast
- log werd geschreven
- geheugen liep vol
- reboot
- log geschreven van wat fout ging
- geheugen liep weer vol
- reboot
- log schrijven enz enz....

Vond dat toch wel een hele leuke. Vooral omdat het domme ding erg weinig geheugen meehad gekregen. terwijl het niet bar veel ruimte inneemt (of simpelweg niets)*.

Volgens mij gebeurde dit nadat de robot tegen een steen was opgeknalt en zichzelf niet los kreeg. Maar dat kan een foutje zijn (muis werkt niet dus internetten is lastig)

*ja ik weet het.Meer transistors enz enz is meer risico. Maar dit was ook behoorlijk dom*
Om dat soort dingen moet je dus heen zien te werken op aarde, dat moet je voorzien, en niet achter komen als je al een paar miljoen/miljard de ruimte in hebt geschoten.
In feite is de steen niet de schuldige, maar de ontwerper van de machine en software.

Maar het is wel humor dat zo'n steentje het blootlegt na een paar miljoen dollar erin te hebben gestopt.
ow en doet ie dat nog steeds of is de batterij op?

Ik zie het al voor dat het arme ding over 100 jaar nog steeds bezig is
Daar gaat hij waarschijnlijk mee door tot de batterij op is, of er iets echt gaar gaat door de actie, zoals geheugen of cpu, maar ik denk dat de batterij het als eerste begeeft.
"...introduceerden agenten van de CIA een fout in het computersysteem van de trans-Syberische gasleiding, waarvan vermoed werd dat de Sovietunie deze gebruikte om geheime Amerikaanse documenten te transporteren."

Zoals ik die info daarover lees was het niet omdat dat computersysteem documenten transporteerde. Dat computersysteem was gewoon in de Sovjetunie.
Nee, de Amerikanen waren boos dat Rusland hun technologie jatte, en lekten bewust controlesoftware met een trojaans paard erin, wat een explosie veroorzaakte. De Russen zouden daardoor voorzichtiger zijn geworden met het toepassen van gestolen technologische know-how.
http://www.rhythmism.com/forum/archive/index.php/t-178.html
Meer: http://users.cyberone.com.au/myers/sutton.html


EDIT: vermoedelijk een zwakke vertaling van 'History's worst software mistakes' http://wired.com/news/tec...5,00.html?tw=wn_tophead_1
Vind je het erg dat ik dit niet geloof?
Anoniem: 88331 @Jaco6911 november 2005 12:09
Ja ik lig daar de komende 6 maanden wakker van denk ik :o

Maar waar ik op wilde wijzen was de volkomen verkeerde formulering van deze bug in het berichtje.
Ze zijn nog een bug vergeten.
De millenium bug.
Duurste 'bug' ooit.
Das geen bug...maar een feature :)
Klopt, ook gewoon "niet aan gedacht" door de makers. Maar die leverde relatief weinig problemen op nog.
Zo is het wel gebeurt dat in een ziekenhuis de pc net 's nachts na 12 uur dus aangaf 01-01-1800 00:02.
En omdat die tijd officieel bepalend is was er een 100 jaar oude baby, maar ik denk dat ze dat stiekem toch gecorrigeerd hebben.
Zo waren er ook liften die niet meer werkten omdat ze dachten dat ze al 100 jaar geen servicebeurt gehad hebben etc.
Maar verder geloof ik weinig extreme fouten of ongelukken daardoor.
Eerlijk gezegd snap je blijkbaar de milleniumbug niet. Het vervelende was juist dat het beginnen van een jaartal met 19 hard coded was. Als het het jaar 1800 kon worden was die hele bug er niet geweest. ;)
Het beest werd gevangen en in het logboek geplakt met de tekst "first actual case of a bug being found".
Dan kan nooooit van z'n leven! Dat is hetzelfde als een oude munt vinden met het jaartal 300 v.Christus... :Y)
Die bug werd overigens door een pionier(vrouw) op gebied van informatica gevonden. Zij (Grace Hopper) was ook één van de eerste om (de 3de) high level programmeertaal op de tafel te brengen, met name FLOW-MATIC. (Nulletjes en eentjes programmeerden niet zo lekker.)

high level bedoelt men: complexe taal; en met taal verstaan we het gebruik van woorden ipv 0'n en 1'n.

Fortran is hier later op gebasseerd, en eigenlijk kort daarop de beste bedrijfsgeoriënteerde taal -ook nog steeds imho- COBOL
COmmon Business Oriented Language
. Die nog steeds volop in de wereld van financiën, overheden, militaire installaties en voor administratie wordt gebruikt.

edit: Er stond/staat IMHO, ik verkondig geen feiten maar geef slechts mijn mening.

Ik haal nog iets uit je tekst:
COBOL kan niet recursief werken
edit2: Gek, MF COBOL ondersteunt wel recursive calls, en is niet de enigste. :-/
Fortran is hier later op gebasseerd, en eigenlijk nadien de beste bedrijfsgeoriënteerde taal -ook nog steeds imho- COBOL.
Je vindt COBOL, dat by-design niet kan multithreaden, niet recursief kan werken, geen heapallocaties kan uitvoeren, geen OOP kent, geen exceptions ondersteunt en een ronduit walgelijke syntax heeft voor variabeledeclaraties (iemand een pic(09) gezien recent?) serieus de beste programmeertaal in 2005? :X

Like dude, kom eens bij de rest van ons in de 21e eeuw. Of begin eens met de 90'er jaren als je bang bent voor teveel verandering tegelijk.
Like dude, kom eens bij de rest van ons in de 21e eeuw.
Sorry, maar ik vind dit erg arrogant overkomen en spreken van onwetendheid.

Jou profiel toont mij dat jij een "System Engineer" bent van opleiding en ook ervaring hebt met COBOL, misschien enkel in je opleiding en later niet meer, dat stond er niet.

Maar hoe dan ook, hier zal ik jou eens even een vraag geven waarop je zelf met een antwoord mag komen om over na te denken:
Welk systeem (taal) is veelal (en nog steeds) gebruikt bij bankinstellingen?

TIP: Het is niet 'Visual Basic' en in de (West-Europese) industrie vertegenwoordigt deze taal nog steeds 70% (!!!) als basis voor de systemen.

Voor de Belgen: Het systeem Banksys is gemaakt met deze taal.
Dat het nog bij veel banken draait heeft meer te maken met de enorme kosten die gemaakt moeten worden voor een migratie terwijl het huidige systeem 'ook nog wel werkt'. Het zegt helemaal niks over of het de beste bedrijfs georienteerde taal is.

Dat er nog veel COBOL software is klopt, maar het enige dat tegenwoordig nog in COBOL gedaan wordt is onderhoud en eventueel uitbreiden van bestaande systemen.
Het is niet omdat dat daarin geschreven is dat dit het meest optimale is... Cobol wordt gebruikt voor de BC/MC backend, maar wordt vervangen door een andere die klaar is voor EMV, en ik weet niet wat ze daar nu voor gingen gebruiken, C of Java (al een paar jaar niet meer bij banksys geweest), maar het overgrote deel van hun ontwikkelaars is toch nog steeds C. Alle frontend applicaties (betaalterminals etc) zijn wel degelijk in C geschreven, en in niets anders...

Het is niet omdat COBOL 20/25 jaar geleden de beste taal was om zoiets in te doen en dat het teveel zou kosten om heel dat ding opnieuw te herontwikkelen in een andere taal dat dit nog steeds "de beste taal is".

Ik denk ook dat je een klein beetje de plaats van Cobol overschat, Cobol-programma's worden inderdaad nog enorm veel gebruikt, maar 70%? Niet idioot doen he, deel dat door 100 en je komt er mischien. De bankwereld en accounting zijn ongeveer de enige sectoren waar men nog Cobol-programma's gebruikt, en dan nog enkel voor back-ends.

Vergeet niet dat tegenwoordig wel 60/70% van de gezinnen een Windows/Linux/Mac pc in huis heeft staan die voor het overgrote deel in C/C++/ObjectC geschreven is, net als alle programma's daarop, daar is geen letter Cobol aan geschreven :)
VB komt waarschijnlijk op een 2de plaats, want in enorm veel kleine bedrijfjes gebruiken ze dat om interne toolings te schrijven. Geen enkele commerciele applicatie voor end-user is nog in Cobol geschreven voor zover ik weet. Hoe groter de markt, hoe groter de hoeveelheid software, dus die 70% is totaal uit de lucht gegrepen en is een getalletje van 20 jaar geleden.

PS: Ik ben geen fan van zowel Cobol als VB, het zijn naar mijn mening beide achterhaalde rommelige talen. Geef mij maar een mooi gestructureerde taal als C/C++/Java/C#...
@packman

Ik vind C een erg mooie taal, maar om die qua gestructureerdheid nou in het rijtje Java en C# te zetten lijkt me niet echt juist...C geeft je juist de vrijheid om enorm coole dingen te doen, maar ook om enorme puinhopen te creeeren...in mindere mate is dit in C++ ook het geval.

Ik heb zelf dik 2 jaar cobol zitten kloppen op een HP3000 omgeving en eerlijk gezegd ben ik er ook niet kapot van....ladingen met Job Control Language aan elkaar geplakte programmas die een vreselijke brei aan onoverzichtelijke troep veroorzaken die in 9 van de 10 keer te vervangen is door een vrij simpel programma in een fatsoenlijke taal...Zelfs VB was een verademing geweest in plaats van Cobol.

Het is inderdaad waar dat er een aantal initiatieven zijn die geprobeerd hebben om Cobol met zijn tijd mee te laten gaan...o.a. acucobol en de .NET cobol compiler...maar ik kan die dingen gewoon niet serieus zien als je er dan een taal als C# naast legt...
@Packman:
(per paragraaf genummerd)
1- De frontends vormen niet de basis van dit alles; dat bedoelde ik ook niet. Als je toekomst denkt, kan je ook aan SQL denken bijvoorbeeld, deze is ook ontwikkeld ahv de COBOL-filosofie. True, het is iets anders, maar het principe erachter is hetzelfde, en dient dus ook modern te zijn, en toch ook weer 'tijdloos' om heel wat jaren bij te blijven

2-Onder de 'beste' taal nu begrijp ik dat deze nog de voorkeur geniet, zoals eerder al gezegd, omdat er grote kosten bij komen kijken en er geen noodzaak naar is om die overstap te maken, omdat alles nu nog netjes gaat. Voor bedrijven is dit de logica hetzelve, zij kunnen deze investering uitsparen.

3- Dat getalletje '70%' is niet uit de lucht gegrepen, maar je moet m'n zin herlezen, er stond:"in de (West-Europese) industrie vertegenwoordigt deze taal nog steeds 70%". Ik had het nergens over de desktop-gebruiker van thuis die met een meer comfortabel systeem zit en dito OS.
En bankwereld en accounting...is dit dan zo 'weinig' ? Ik vind dit wel enorme delen uit de zakenwereld die wel veel inpakt hebben hierop. Alsook defensie bij ons (Belgie), mag je niet zomaar even vergeten. (Akkoord, wat stelt onze 'landsverdediging' nog voor....maar in Europa en Amerika zullen er nog wel meer militaire instellingen zijn die het gebruiken.)

4- 70% van de CPU-kracht ligt niet bij de thuisgebruiker; misschien dat er wel ene meerderheid aan thuisgebruikers tov systeemontwikkelaars aan een computer zit, maar deze vertegenwoordigen ook een andere markt. En COBOL is een bedrijfsgeoriënteerde taal, dus niets voor de thuisgebruiker en dat zal ook nooit komen. Dus ja, VB of C-varianten, uiteraard dat deze daar meer voorkomen.

5- Zo hoog van stapel zou ik nu ook weer niet lopen van C-taal... C++ zou ik altijd verkiezen boven C als het kon, en C# idem weer boven C++. PER uitzondering als er een degelijke rede is. (Op die manier kan je soms dus ook argumenteren om voor ASM te kiezen ipv JAVA bv. spreekt voor zich.)
Echt snel ben je niet he ?
Ze vonden echt een bug (insect) en juist door die gebeurtenis is een fout in een systeem of code etc een "bug" genaamd.

Nog een goeie, is geen bug maar wel stom.
Als we het toch over rekenfouten e.d. hebben zoals in het artikel:
pak een rekenmachine, toets in 100 / 3 en druk op =.
antwoord = 33.3333333333 (tot in het oneindige).
Doe dat getal weer keer 3 en druk op =, da krijg je waarschijnlijk 99.999999999999999(tot in het oneidige).
Dat klopt helemaal, omdat eerst de rekensom was afgesloten door op = te drukken en de uitkomst is gebruikt voor een volgende som.
MAAR !!!
Doe nu eens in een keer:
100 / 3 * 3.
Kijken wat je krijgt.
Net als 10 / 2 * 2 = 10 zou er moeten komen 100 / 3 * 3 =100
Zo kun je zien of je rekenmachine goed doorrekent of een goed geheugen heeft. Doet ie het niet goed ? Dan hoop ik dat je hem niet gebruitk voor ZEER belangrijke berekeningen.
Dit soort problemen komen echter alleen voor bij dit soort berekeningen.

Niet zozeer een bug als wel gewoon slecht in mekaar gezet, check maar eens, meest rekenmachines doen het fout. Je windows calculator en ik neem ook aan de Mac doen het wel goed (mag wel voor zo'n systeempje :P )
.oisyn Moderator Devschuur® @gabiballetje11 november 2005 01:02
Ze vonden echt een bug (insect) en juist door die gebeurtenis is een fout in een systeem of code etc een "bug" genaamd.
Nee, het woord "bug" is al voor die tijd gebruikt, hence ook de notitie "first actual case". Edison noemde het al in 1875, waar hij op een mechanische fout doelde. Zie http://en.wikipedia.org/wiki/Software_bug voor meer info.
Klopt. maar daar bedoelt als zijnde niet helemaal goed werkend, en niet als beestje zijnde.
Vandaar dat die ene persoon ook schreef"
first actual case of bug"
Eigenlijk heeft Edison waarschijnlijk door gebrek aan een andere geschikte term dat verzonnen en het woord "bug" de wereld in geholpen als zijn een term voor een fout.
Zo leren we nog eens wat :P
Wat je vergeet is dat 100/3*3 gelijk is aan 100/3 = ans en daarna nog *3
Delen gaat voor vermenigvuldigen dus moet je zeggen 100/(3*3)
koop Mathematica en ga verder spelen :>
Als we het toch over rekenfouten e.d. hebben zoals in het artikel:
pak een rekenmachine, toets in 100 / 3 en druk op =.
antwoord = 33.3333333333 (tot in het oneindige).
Doe dat getal weer keer 3 en druk op =, da krijg je waarschijnlijk 99.999999999999999(tot in het oneidige).
Ik pak mijn Casio fx-115s en typ het in 100 / 3 = 33,33333333, vervolgens toets ik * 3 = 100.

Het is een oude calculator, niet zo'n grafische iig, en toch maakt ie er 100 van.
Dan heb je dus een goed machientje(die gebruikt dus zijn geheugen om de berekening te checken waarmee men begonnen is, doen de meeste simpele niet), het zijn meestal die goedkope rukdingen die je ergens bij krijgt en zo die het fout doen.
De casio's zitten meestal wel soepe in mekaar.
Probeer maar eens wat machinetjes van kennissen en zo.
Sterker nog, pak je mobieltje eens.
Mijn Nokia doet het ook niet goed.
(6230i als jet het wilt weten).
Wat komen die andere rekenmachines 'die het slecht doen' dan uit? Want als het 99.99999... weergeeft is het eigelijk ook goed, want 99.99999... en 100 zijn gelijk aan elkaar.

[edit] kort wiskundig bewijsje:
x = 99.9999...
10x = 999.9999..
10x - x = 999.9999.. - 99.9999..
9x = 900.0000..
9x = 900
x = 100

gabiballetje: ga wat googlen en lees dan zelf wat de wiskundigen er van denken :z
staat onder andere ook op wikipedia
zolang die reeks geen einde heeft, zijn die 2 waardes nooit gelijk aan elkaar ;)

je kunt wel tot oneindig naderen, maar het is niet gelijk.
.oisyn Moderator Devschuur® @Sir_Eleet11 november 2005 00:57
zolang die reeks geen einde heeft, zijn die 2 waardes nooit gelijk aan elkaar
Dus als hij wel een einde heeft, zijn ze wel gelijk aan elkaar? :+
99.999999 (tot in het oneindige) is gewoon NIET en NOOIT hetzelfde als 100, er is altijd EEN of 1 verschil aan het eventueel niet bestaande eind van de reeks, maar het is en kan gewoon niet hetzelfde zijn.
De O en de 0 en de o zijn ook niet hetzelfde, ook al is het verschil nog zo klein :P

Er is al gesteld dat x - 99.999999999...
Dus kan x niet 100 zijn.
Er is dus een kleine discrepantie in de berekening, of de beredenering is niet geheel correct.
Dat KAN niet anders.
Daarbij werkje nu met 99.9999999999...., en dat getal is oneindig, en omdat het gehele getal dus eigenlijk niet bekend is zo kun je zeggen, kun je het niet gebruiken in een berekening.
Punt blijft, x = 100 dus x is geen 99.9999
A is geen B, ook al kan het een enorm klein verschil zijn.

Zoals gesteld , er moet een einde zijn om te kunnen rekenen, dus wordt gedaan alsof, maar het is niet zo.
er blijft altijd een verschil van 0.0000(oneindig)00001
En het oneindige is het probleem.

Zo is Pi ook oneindig (tot dusver, niemand heeft het nog helemaal 100% zeker tot het einde kunnen berekenen), maar is er een afspraak gemaakt dat Pi = 3.14....., waardoor er dus meteen een bepaalde foutmarge in alle berekeningen met Pi zitten, maar de impact daarvan kan slechts heel klein zijn, maar hij is er wel.

(Jongens, zullen we er eens een uberwiskundige op los laten die de zomaar aangenomen wetten laat varen en echt gaat rekenen, zonder ook maar enige foutmarge ? En dat is nou juist het probleem, de foutmarge :P )

Wat betreft Wikipedia stellen ze zelf ook al dat 0.99999 oneindig is, maar er een bepaald getal wordt gebruikt omdat het anders niet kan.
En denk nou eens logisch en SIMPEL na, x=100 dus kan x niet 99.999999 zijn.
Het verschil is misschien verwaarloos baar, maar er blijft een verschil, dat men niet noemenswaardig noemt.

Kijk eens naar het stukje Generalizations:
special case considered...
Considered en generalizations zijn de key words hier.
Het wordt zo aangenomen, ook al is er een klein verschil, omdat je er anders niet mee kan rekenen, omdat je dan tot in de eewigheid (zonder einde dus) blijft rekenen hoeveel 9's er zouden moeten staan, daar is geen eind aan.

Nog iets bij Elementary Proofs:
Elementary proofs assume (!!!!!! DING DING DING) that manipulations at the digit level are well-defined and meaningful, even in the presence of infinite repetition.

Er wordt aangenomen, maar het si net anders :P

Nog wat:
Proofs fall into two main categories, depending on the level of mathematical sophistication and rigor demanded. Examples of both are given.
Daarmee zeggende, hoe belangrijk vindt je de klein afwijking... of hoe precies, maar nooit helemaal 100% wil je het hebben.

100 /3 *3 = 100 Omdat je het echt getal 99.9999... niet echt berekend, je gaat eromheen. Net als 100 / 4 * 4 = 100 ook altijd moet kloppen. Alleen is de tussensom daarvan 25, en dat is wel makkelijk te berekenen en te gebruiken.
Kerel, leer eens fatsoenlijk om te gaan met wiskunde! Wel eens van limieten gehoord?

En pi oneindig? Kom op! |:(
@gabiballetje:

Wiskundig niet al te best onderlegt dus.

Wil jij soms beweren dat 1/3 + 1/3 + 1/3 een andere uitkomst heeft wanneer je het decimaal uit zou schrijven?

100 en 99.999.. zijn verschillend wanneer de reeks 9 eindig zou zijn. In dat geval zou het verschil 0,00..01 zijn. Bij een oneindige lengte is er geen 1. Dat je iets op een andere manier schrijft betekend nog niet dat het niet dezelfde waarde kan hebben. Zestien, 16, &h10, 020 (octaal) en &b10000 zijn toch ook allemaal hetzelfde?


@edit boven: Wat jij wilt beweren is dat enkel het opschrijven van een tussenresultaat tot gevolg heeft dat het eind resultaat verschillend wordt?? Ik neem aan dat je zel fook wel begrijpt dat dat onzin is.

@hieronder: Het zijn de mafketels die denken dat het verschillend is. het verschil is 1/INF en dat is gewoon gelijk aan 0 (niks afronden of wat dan ook).
volgens mij is dit een paradox hoor, want iedere mafketel snapt dat 99.999... niet hetzelfde is als 100. afgerond wel en niet afgerond is het verschil maar minimaal, maar er is een verschil.
jori:

Ga eerst eens wat wiskundige onderbouwing halen voor je idiote uitspraken gaat doen.

Ik kan het bewijsje dat al gegeven is nog eens herhalen maar dat gaat sommigen hun petje blijkbaar al te boven. Bijgevolg ga ik het iets praktischer aantonen (jawel, zonder onbekendes :D).

Als je iets deelt door iets uit de verzameling { 9, 99, 999, 9999...} dan krijg je een periode.

1/9 = 0.11...
2/9 = 0.22...
3/9 = 0.33... = 1/3
23/99 = 0.2323...
123/999 = 0.123123...

Bijgevolg:

9/9 = 0.99...

En als je niet wist dat 9/9 = 1, tja dan kan je terug naar de basisschool.
Sorry, maar het is zo simpel
99.999 INF is gewoon geen 100
Er is en zal altijd een .00000...0001 verschil zijn.
Het probleem is dat je niet kan uitrekenen omdat het INF is.
Wie is er nou simpel ?
Jij zegt in feite hetzelfde, je neemt aan dat het 100 is omdat het verschil zo enorm klein is. maar het is en kan nooit hetzelfde zijn.
En met een niet geheel bekend getal kun je dus nooit zonder foutmarge rekenen, je kan wel aannemen dat het verschil/foutmarg die ontstaat zo enorm klein is dat het niet boeiend is.
Het is gewoon logica.
x kan maar 1 ding tegelijk zijn, en dat is 100 OF 99.9999... maar niet allebei.
Heel simpel en logisch.
Iedereen die denkt van wel neemt dus genoegen met een bepaalde foutmarge.

En bij mijn weten is er nog niemand geweest die Pi tot zijn einde heeft kunnen uitrekenen.

100 en 99.999 zou verschillend zijn als de 9 reeks eindig zou zijn, maar wel gelijk als de 9 reeks oneindig is ? Eigenlijk slaat dat nergens op. Er is altijd een verschil, hoe klein ook.
Porbleem is dat je het niet kan uitrekenen omdat het oneindig is.

Nee het opschrijven is niet het verschil, dat het getal in zijn geheel bekend is of niet is het verschil.
Heel simpel
iets kan altijd door zichzelf gedeeld worden, behalve 0 dan.
Zeker met positieve getallen kan iedereen dat.
1/9 = 0.111111111... INF
In feite weten we hat antwoord daarop niet omdat het inderdaad niet deelbaar is door 9.
Dus zullen we de echte uitkomst nooit weten, misschien omdat die dus eigenlijk niet bestaat.
Bij anderen heb je dat probleem wat minder, zoals 2/4 = 0.5
De wiskunde moet er echter wat mee kunnen dus zetten ze er een limiet aan om er toch wat mee te kunnen.
Je kan er wel omheen proberen te rekenen zoals Sir-Beet liet zien, maar eigenlijkkan dat dus niet omdat je het hele resultaat niet weet (99,999...INF).
@Janoz:

Ik ben nog nooit een wiskundige tegengekomen die zegt dat 1/INF gelijk is aan 0.

Ze zeggen dat altijd dat de limiet van 1/INF gelijk is aan 0.

Helaas zijn wiskundigen op dat punt niet erg consequent en beweren ze wel rustig dat 0.999... gelijk is aan 0, zonder dat je dan met een limiet moet werken.
Wat dat betreft is het eerdere bewijs dan ook bepaald niet overtuigend.

1/3 + 1/3 + 1/3 is wat dat betreft een veel beter bewijs omdat je daarbij niet met die limiet hoeft te klooien.

Maar ja, dit soort zaken is dan ook precies waarom natuurkundigen het nooit zo goed met wiskundigen kunnen vinden :)
Toch zal de stelling:
1 = 9/9 = 0.99999999..

Een grove wiskundige fout zijn , want je stelt 1 gelijk aan 0.99999.. en dat kan alleen via aannames
Het is gewoon heel simpel :Y) .

100 / 3 ≈ 0,999 INF
en 100 / 3 ᾐ 0,999 INF

Ik denk dat daar wel alles mee is gezegd. Je moet niet gaan rekenen met die 0,999 INF. Dat is slechts een manier van weergave in het decimale stelsel. Als breuk (100 / 3) klopt het verder wel.
Sorry, wel gelijk. 99.9999.... = 100. Reactie van iemand die wiskunde heeft gestudeerd. Is trouwens ook al gelijk als je middelbare school wiskunde hebt gehad (nivo vwo, misschien zelfs havo).
@mjtdevries
Je hebt helemaal gelijk

@Janoz
Wil jij soms beweren dat 1/3 + 1/3 + 1/3 een andere uitkomst heeft wanneer je het decimaal uit zou schrijven?

NEE, dat zeg ik nou juist, dat zou ook 100 of in dit geval 1 moeten zijn, maar sommige nullige rekenmachines komen uit op 99.9999...
het begint al met 99.9999 dus geen 100.
Maar volgens wiskundigen die dingen "aannemen" wel.
Sorry maar dna ben je de logica vergeten, en benje overgegaan naar wat makkelijk is.
1 is toch ook geen 3, ook al is het verschil "maar" 2.
@LauPro

JUIST !!! en dan probeer ik nu al de hele tijd uit te leggen
100 /3 *3 is altijd 100, als je het juist berekent.
maar ga je doen die 33.3333INF *3 dan niet.
1/3 + 1/3 + 1/3 = 1 en niet 99.9999INF

Een mens is ook geen Oerang Oetan, als id er maar een 1% verschil in de genen, dat kleine verschil maakt dta we anders zijn.
Appellen en peren vergelijken is hetzelfde.
Leuke gedoe hier

Okee dan maar een leek

de fout in de rekenmachines is dat 99,99999999 niet oneindig is
Maar de 99,999999 is voor die goedkope rekenmachines dus wel eindig
en daar gaat het dus mis want dan krijg je

x = 99,9999
10x = 999,999
10x - x = 999,999.. - 99,9999..
9x = 899,9991

x = 99,9999

en dan word het echt geen 100 hoor
Maarja Ach daar moet je ook NIET voor geleerd hebben

:+
@gabiballetje:
Er is en zal altijd een .00000...0001 verschil zijn.
Nee, dat geldt alleen als 't eindig zou zijn.
Omdat het ONeindig is, is het verschil .00000...0000
:P
Trouwens, is er wel verschil tussen
0.0000(inf)0000001 en
0.0000(inf)0000000 en
0.0000(inf)0323367?

Bestaat 0.0000(inf)00000001 wel? Is dat niet net zoiets als delen door 0?
Geen bug, maar ook niet stom. Er is zelfs een tak van de wiskunde die zich bezighoud met het uitvoeren van berekeningen en introductie van fouten: Numerieke Wiskunde.
Eigenlijk moet iedereen die met getallen werkt voor proffesionele doeleinden deze wiskunde beheersen en weten wat het apparaat wat hij gebruikt met zijn getallen doet. Anders krijg je problemen, vooral bij delingen en aftrekkingen, want die zijn slecht geconditioneerd.
Nou uhm, zie het plaatje dat Cobra_Lup al postte:

http://www.it.uc3m.es/tao/Lab1/H96566k.jpg

Ik denk dat je het een beetje bevooroordeeld leest; ze bedoelen met 'first actual case of a bug being found' daadwerkelijk dat ze een beestje vonden. Dat dat woord nu zo ingeburgerd is, maakt de opmerking des te grappiger, maar het kan prima.
Maar toen noemden ze fouten in de code nog geen 'bugs', dat incident zorgde erjuist voor dat dat soort fouten bugs genoemd werden, dus iemand heeft het er later waarschijnlijk bijgezet....
Juist wel, de tekst betekent volgens mij dat ze fouten al bugs noemden en dat ze verrast waren dat er een echt insect klem zat tussen de poten van een relais.
nu is het wachten op de eerste vis in een waterkoeling :P
Kan wel en niet.
Je kan je pc vullen met een niet electriciteit geleidend goedje waardoor geen contact wordt gemaakt maar wel gecooled wordt. Probleem, dat vindt die vis niet gaaf.
Water is een slecht plan voor je PC.
Helaas...
In normal waterkoeling zitten ook nog andere dingen die hitte goed opnemen en afstaan, die nogal nasty zijn, jullie allen waarschijnlijk wel bekend, anders zou het wel enorm cool zijn :P
Voor 'even' kan het wel, alleen na een dag of 2-3 word het water slechter en da's op den duur funest voor je fishies :P (en ze moeten niet in de pomp gezogen worden :P )

Waterkoelingsadditiven gebruiken legt je vissen meteen om natuurlijk :X

Op dit item kan niet meer gereageerd worden.