*Zucht*

Microsoft's PR apparaat weet het hele gebeuren wel weer naar hun hand te
zetten hoor...

@Stake's credibiliteit is bij de meeste mensen toch al ingestort, aangezien ze
een werknemer hadden ontslagen nadat deze ``te eerlijk'' was over het
crappy-ness van het Windows-platform.

Tevens denk ik dat *niemand* naar Microsoft zal bellen om ze te wijzen op
bugs. Als ze dat doen lopen ze het risico vervolgd te worden vanwege
inbreuk op intellectueel eigendom en copyright, althans, die angst wordt in de
media rondgeslingert.

microsft zijn gewoon kneuzen sukkeltjes kunnen nie eens wat
maken zonder bugs

Indien Microsoft achter deze stelling staat kan zij misschien beter
alle source code openbaar maken.

Alhoewel dat meer een gedachtegang is dan iets realistisch, zou
het toch een vooruitgang zijn mijner inziens.

de reacties:
"@Stake's credibiliteit is bij de meeste mensen toch al ingestort,
aangezien ze een werknemer hadden ontslagen nadat deze
``te eerlijk'' was over het crappy-ness van het
Windows-platform."
Het was inderdaad een opmerkelijk ontslag.

Conspiracy theory #1:

Ik denk dat MS dit persbericht + valse source code expres zelf heeft
verspreid, zodat ze nu "iemand anders" de schuld kunnen geven van al die
virussen, en zelf dus "slachtoffer" pogen te zijn.

Het feit dat er voor Linux en Mac OSX vrijwel geen virussen zijn komt juist
door de openheid van de source.

Die woordvoerders van bedrijven die er belang bij hebben om
goed in het nieuws te komen zijn ook nooit en nimmer
geloofwaardig:
Voor dat de broncode op straat lag beweren ze bij hoog en
laag dat het wegstoppen het beste is zodat niemand misbruik
van de broncode zou kunnen maken. @stake was hier ook een van.
En nu ligt het op straat en wat geven ze als reactie: nee,
tuurlijk is het niet erg, het leidt ertoe dat bij MS
eindelijk eens wat aan de situatie gedaan gaat worden dat er
security bugs inzitten waar ze eerder niet naar om keken.

Probeer jij maar eens een besturingssysteem te vinden waar
geen bugs in zitten.

Geen enkel groot softwareproject is foutvrij. Het gaat er
alleen om hoe je met de gevonden bugs omgaat. Daarin zijn ze
inderdaad wel een 'beetje' knullig.

lijkt als een gozer op ons werk..

altijd programmeurs afzeiken over fouten in programma`s
"waarom maken ze niet alles in 1x goed"

toen maakte hij de website van het bedrijf,
en zaten er ook wat fouten in..
direct de mond gesnoert :)

quote:
--------------------------------------------------------------------------------
Door Anoniem
microsft zijn gewoon kneuzen sukkeltjes kunnen nie eens wat
maken zonder bugs
--------------------------------------------------------------------------------

Bljkbaar is een zin zonder spelfouten voor sommigen al moeilijk genoeg.

Goeie onderbouwing van JOU gedachtes.

[( quote]Door Anoniem
microsft zijn gewoon kneuzen sukkeltjes kunnen nie eens wat
maken zonder bugs[/quote] )


Probeer jij het eens. De complexiteit van dergelijke systemen zal je een
beste koppijn geven.

Een programmeur

Het gevaar van code-lekken moet je niet onderschatten. Ik als ervaren ex-C
programmeur weet hoe C zijn geheugen beheert. Ter info: merendeel (zo
niet alle) is geschreven in C.
Bij het opzoeken van geheugen-fouten (de zogenaamde segmentation faults
ed) zoek je naar plaatsen waar geheugen potentieel kan worden
overschreven. Geheugen wordt binnen C op 2 manieren gebruikt:
statisch - door declaratie
dynamisch - door malloc (memory allocatie)
Het grote verschil tussen beide manieren is dat dynamisch geheugen van
de heap wordt gereserveerd en het statisch geheugen midden in het
geheugen staat waar OOK de programma machine instructies staan.
Bij het opzoeken van zwakke plekken in de code kijk je met name naar het
statische verhaal. Je kijkt dan naar veel te klein gedefinieerde buffers. Truc
is dan om te zorgen dat de meer in de buffer geschreven wordt dan er
beschikbaar is. Je kunt bijvoorbeeld machine-instructies van het
programma overschrijven door je eigen instructies. Op die manier kun je het
verdere verloop van het programma beinvloeden.