Je bent knap als je dit kunt.....

[Verwijderd]

Je bent errug knap als je QNX vast kunt laten lopen...
Mij lukt het niet.
Zal dit het enigste OS zijn die niet kan vastlopen?

Succes

ps. Als je het wel lukt zeg effe hoe

www.qnx.com

[wzzrd]

Zonder nou vervelend te willen zijn, maar wat doe je ermee? Je kunt op dit moment ook nog erg weinig met QNX, dus vast laten lopen is erg lastig. Volgens mij zijn er nog minder proggies voor dan voor BeOS..

[Verwijderd]

Precies mensen lopen altijd MS zo af te zeiken... maar probeer je eens het ontwikkeltraject van zo een groot plaform in te denken, hoeveel werk erin zit hoeveel source code om ook zoveel computers te kunnen ondersteunen met de meest uiteenlopende configuraties, en dan maar altijd oplossingen vinden voor gevonden en ondervonden problemen.

Ik denk dat mensen dit zwaar onderschatten, ook moeten deze OS'en ongeveer elk mogelijke applicatie ondersteunen. En moet alles dan ook nog is simultaan kunnen blijven werken.

Natuurlijk heb ik mijn problemen ook met MS producten, maar als je kijkt naar alles eisen en mogelijkheden wordt MS echt zwaar onderschat.


Wacht maar tot de gebruikerseisen van alternatieve OS'en omhoog gaan, en zij alle hardware moeten kunnen ondersteunen en alle gadgets moeten implementeren... Dan is het ook gedaan met die software

[JayTaph]

Naar een QNX-bak toe telnetten,

CTRL-C drukken op het moment dat je aan het compilen bent (watcom)...

telnet-sessie == dood



QNX an sich is niet interessant voor eind-gebruikers. Wij gebruiken het voornamelijk voor het realtime controleren van processen.

Ik heb het wel al een paar keer laten crashen, ik moet alleen even kijken hoe ik dat precies deed . Ik geloof dat het met de "Dosfsys" en "Tulip" drivers te maken had als ik me niet vergis...

[warp]

Op donderdag 13 december 2001 10:11 schreef Markiedam het volgende:
Zal dit het enigste OS zijn die niet kan vastlopen?

One word: VAX/VMS.

[Talon]

Zeg je nou echt VMS ?
Dat krijg je echt wel plat ...
Als je dat op 99 % load laat draaien voor langer dan 5 uur krijgt ie een panic.
Waarom zeg ik 99% ?
Nou ...omdat dat het getal is die hem de nek omdraait.

[riffey#4]

One more word: OS/400 ;-)

[Verwijderd]

Op donderdag 13 december 2001 11:02 schreef warp het volgende:

[..]

One word: VAX/VMS.

Dat zijn 2 woorden hoor

[Vinz]

makkelijk te doen: gebruik hardware die niet helemaal 100% is (in mijn geval een kapotte cd-speler).
Kan linux ook niet tegen, windows kon daar opvallend beter tegen dan de os'sen die ik heb geprobeert (wat aangeeft dat windows niet alles uit je HW haalt wat erin zit).

[JayTaph]

One word: VAX/VMS.

QNX is de huis-tuin-en-keukenversie van VMS met een unix-interface.

Maar euhm, stapje verder: Svms

[reddog33hummer]

Op donderdag 13 december 2001 11:04 schreef riffey#4 het volgende:
One more word: OS/400 ;-)

als ik al het ramgeheugen uit onze AS400 uithaal dan loopt dat ook wel vast hoor.

[kroeske]

als je het moederbord eruit trekt ook

[TumbleCow]

Op donderdag 13 december 2001 11:08 schreef vinz het volgende:
makkelijk te doen: gebruik hardware die niet helemaal 100% is (in mijn geval een kapotte cd-speler).
Kan linux ook niet tegen, windows kon daar opvallend beter tegen dan de os'sen die ik heb geprobeert (wat aangeeft dat windows niet alles uit je HW haalt wat erin zit).

Zo kan je op de een of andere mysterieuze wijze ook Win '98 booten met een veelstever overgeklokte proc.

elk 'normaal' os krijgt vrij snel problemen, maar op de een of andere manier doet win'98 gewoon een hoop dingen waarbij het totaal niet uitmaakt als er een bitje omvalt.

[warp]

Op donderdag 13 december 2001 11:04 schreef Talon het volgende:
Zeg je nou echt VMS ?
Dat krijg je echt wel plat ...
Als je dat op 99 % load laat draaien voor langer dan 5 uur krijgt ie een panic.
Waarom zeg ik 99% ?
Nou ...omdat dat het getal is die hem de nek omdraait.

Last van brakke hardware dan zeker?

[warp]

Op donderdag 13 december 2001 11:06 schreef Death996 het volgende:
Dat zijn 2 woorden hoor

Laat maar, je snapt hem niet

[warp]

Nog een paar erg robuuste OS'en:

OSF/1 (aka Digital UNIX aka True64),
OpenVMS,
UniCos,
Plan9,
Solaris/SPARC (dus niet de intel versie),
BSD,
OS/400 idd (was al genoemd).

En uh, OS/2 (Ja, OS/2 is best wel erg stabiel).

[Onno]

Op donderdag 13 december 2001 12:36 schreef warp het volgende:
True64

Veel gemaakte fout. Het is Tru64.

[kenneth]

Ik krijg BeOS niet over z'n nek ... tenminste ... nooit helemaal. Tis zo modulair, je killt gewoon de app_server, of de net_server ... sim-pel

[warp]

Op donderdag 13 december 2001 12:44 schreef Onno het volgende:
Veel gemaakte fout. Het is Tru64.

Klopt. Was een domme typo zie ik nu

[jep]

Dat windows juist al op zn bek kan gaan van een vies cd'tje of een haperende floppy is juist waar ik me zo aan irriteer. In linux kom ik hier altijd perfect omheen

[RupS]

Errug stabiel: ReliantUNIX (aka Sinix)

[jep]

Scheelt niet veel, mijn creatie heet xinix (LFS dat boot zonder beeld)

[0siris]

ook erg stabiel: mijn linuxbak-met-kernel-op-maat-en-zonder-X-met-Debian. Die krijg jij niet onderuit. En waarom niet? omdat jij geen account hebt op mijn bak!
Maar vanwaar dit topic

[blouweKip]

Wacht maar tot de gebruikerseisen van alternatieve OS'en omhoog gaan, en zij alle hardware moeten kunnen ondersteunen en alle gadgets moeten implementeren... Dan is het ook gedaan met die software

Ach, linux ondersteund in principe alles en het is nog steeds tig veel keren meer stabieler dan windows (zelfs xp), dat windows meer drivers en gadgets (welke btw?) heeft komt niet door ms oid, dat komt door de support vanuit de industrie, als in linux een brakke driver neergaat dan loopt mn systeem nooit vast, in windows xp simpelweg wel...dat heeft alles met het ontwerp van het systeem te maken en niets met de brede ondersteuning

//ontopic

qnx zag er idd heel mooi en stabiel uit toen ik het de laaste keer bekeek, maar toen was er ook al nauwelijks software voor (dezelfde reden dat ik gekapt ben met beos)

[Verwijderd]

Ik blijf erbij dat dit soort OSén nog steeds niet relevant genoeg zijn om echt een begin mee te maken mocht het wat worden... Het grootste probleem is dat deze OSén te loslopend van elkaar zijn waardoor er zo indien het ooit zo ver komt nooit een standaard kan komen waarop alle programma's bijvoorbeeld kunnen draaien... en of implementatie van andere stukken drivers zodat het systeem over alles support heeft....

[Verwijderd]

Wat een onzin. Als ik als root een fork bomb kan opstarten krijg ik elk systeem hardstikke plat. In C:

code:

#include <unistd.h>

int main(void) {
  for(;;) fork();
  return 0;
}

Of nog simpeler in een shell(script):

code:

'$0 & $0 &'

[odysseus]

Op donderdag 13 december 2001 15:47 schreef mietje het volgende:
Wat een onzin. Als ik als root een fork bomb kan opstarten krijg ik elk systeem hardstikke plat.

Hmm, gaat je toch niet lukken . Hij raakt gewoon op mijn systeem gewoon door zijn maximum aan open bestanden heen, waarna hij niet eens meer kan forken...of een andere gebruiker gaat even goochelen met Magic SysRq zodat die processen snel genoeg weg zijn...en mocht je toch het geheugen volledig volkrijgen, dan is er nog de OOM die jouw proces zal gaan afschieten. Nee, mijn systeem krijg je niet zomaar plat . Wat wel zou werken is om als root iets te draaien als 'dd if=/dev/zero of=/dev/mem', maar dat is valsspelen. Bovendien kun je als root elk systeem laten crashen, geen enkel probleem. Het gaat erom of je het ook kunt doen zonder de bedoeling te hebben het te laten crashen. En hoewel het niet onmogelijk is, maak ik me sterk dat je dat bij een goed geconfigureerd systeem onder een bijna willekeurig OS niet zo snel lukt.

[Verwijderd]

Op donderdag 13 december 2001 16:37 schreef odysseus het volgende:
Hmm, gaat je toch niet lukken . Hij raakt gewoon op mijn systeem gewoon door zijn maximum aan open bestanden heen, waarna hij niet eens meer kan forken...

Laat hem dan eens lekker een uurtje lopen. Hij gaat echt alle process slots in je OS bezetten, en dan kun je geen nieuwe processen meer starten, dus hangt hij.

of een andere gebruiker gaat even goochelen met Magic SysRq zodat die processen snel genoeg weg zijn...

Jij activeert magic SysRq op een multiuser systeem en beweert dat het niet plat te krijgen is?

Bovendien kun je als root elk systeem laten crashen, geen enkel probleem. Het gaat erom of je het ook kunt doen zonder de bedoeling te hebben het te laten crashen.

Kuch kuch, volgens mij was ik knap als het mij lukte willens en wetens een systeem te crashen; en dat is zoals je zegt geen enkel probleem.

[odysseus]

Op donderdag 13 december 2001 17:12 schreef mietje het volgende:
Laat hem dan eens lekker een uurtje lopen. Hij gaat echt alle process slots in je OS bezetten, en dan kun je geen nieuwe processen meer starten, dus hangt hij.

Niet als je zorgt dat je altijd al vantevoren een paar shells hebt geforkt (a la apache zeg maar)

Jij activeert magic SysRq op een multiuser systeem en beweert dat het niet plat te krijgen is?

Hier thuis ben ik de enige die weet waar de SysRq zit, laat staan dat iemand die knoppen per ongeluk indrukt. Over het netwerk een SysRq uitvoeren is niet eenvoudig, daar ben ik niet bang voor (die pc hangt ook niet direct aan internet)

Kuch kuch, volgens mij was ik knap als het mij lukte willens en wetens een systeem te crashen; en dat is zoals je zegt geen enkel probleem.

Wel, als het geen enkel probleem is, waarom ben je dan nog knap . De topicstarter heeft dit soort reacties waarschijnlijk nooit bedoeld .

[RG]

Op donderdag 13 december 2001 11:04 schreef riffey#4 het volgende:
One more word: OS/400 ;-)

Hehe, nou de developservert waar ik wel eens in de vakantie wat bijverdien is een keer midden in de nacht op zijn gat gegaan. Iedereen dacht aan een kapotte tokenring kaart maar die deed het bij nader onderzoek gewoon...

Ach, er zijn momenteel zoveel systemen die gewoon zo degelijk zijn dat ze goed geconfigureerd echt niet zomaar plat zullen gaan. Met name alle Unices zijn behoorlijk goed. In de uptime top 50 van webservers staan alleen maar Unices (met name BSD's en IRIX). Novell is ook best wel stabiel. Iedereen kent dat verhaal vast nog wel van die ingemetselde Novell server.

Linux is ook behoorlijk stabiel te noemen, tenminste als je een goede versie hebt. Vanaf 2.6 zal Linux echt goed de clag aan kunnen gaan met andere unices denk ik zo, aangezien nu grote bedrijven zich ermee gaan bemoeien...

[deadinspace]

Op donderdag 13 december 2001 16:37 schreef odysseus het volgende:
Hmm, gaat je toch niet lukken . Hij raakt gewoon op mijn systeem gewoon door zijn maximum aan open bestanden heen, waarna hij niet eens meer kan forken...of een andere gebruiker gaat even goochelen met Magic SysRq zodat die processen snel genoeg weg zijn...en mocht je toch het geheugen volledig volkrijgen, dan is er nog de OOM die jouw proces zal gaan afschieten. Nee, mijn systeem krijg je niet zomaar plat . Wat wel zou werken is om als root iets te draaien als 'dd if=/dev/zero of=/dev/mem', maar dat is valsspelen. Bovendien kun je als root elk systeem laten crashen, geen enkel probleem. Het gaat erom of je het ook kunt doen zonder de bedoeling te hebben het te laten crashen. En hoewel het niet onmogelijk is, maak ik me sterk dat je dat bij een goed geconfigureerd systeem onder een bijna willekeurig OS niet zo snel lukt.

code:

#include <unistd.h>
#include <sys/types.h>

int main( int argc, char *argv[] )
{
      while( fork() < 1 )
            ;

      for( ; ; )
            malloc( 10000 );
}

En je systeem staat zo stil. Ik heb mijn systeem destijds moeten resetten (dus met die windowsknop op de voorkant van mijn kast).
Misschien dat je je hier met je SysRq wat netter uit kunt redden, maar ik vrees dat je niet aan een reboot ontkomt.

En wat betreft SysRq over het netwerk, dat is niet moeilijk, dat is onmogelijk. (nouja, als root zou je misschien wat voor elkaar kunnen krijgen... ff in de kernel variabelen rommelen ofzo )

[Verwijderd]

Op donderdag 13 december 2001 17:43 schreef odysseus het volgende:
Niet als je zorgt dat je altijd al vantevoren een paar shells hebt geforkt (a la apache zeg maar)

Dan is het een kweste welke applicatie als eerste die slots weet te reserveren. Aangezien een fork bomb een verder lege lus is en er exponentieel child processen ontstaan, heeft de bomb een betere kans dan een ingewikkelde applicatie.

Hier thuis ben ik de enige die weet waar de SysRq zit, laat staan dat iemand die knoppen per ongeluk indrukt. Over het netwerk een SysRq uitvoeren is niet eenvoudig, daar ben ik niet bang voor (die pc hangt ook niet direct aan internet)

SysRq over een netwerk lijkt me idd. wat lastig, maar dat is het punt niet. Met SysRq kan iedere console user ingrijpen in het systeem, zelfs al staat je systeemkast achter slot en grendel (en geloof me dat er in een arbeidssituatie vroeger of later een smartass langs komt die het probeert).

Wel, als het geen enkel probleem is, waarom ben je dan nog knap . De topicstarter heeft dit soort reacties waarschijnlijk nooit bedoeld .

Agreed. Dat is dus wel een punt waar veel mensen aan voorbij gaan, iemand met root/admin rights krijgt elk systeem plat, en bij systemen die niet constant gemonitord worden zijn rootrights soms niet eens nodig.

[Verwijderd]

In de drie jaar dat ik nu met AS/400's werk (OS/400 operating system dus) heb ik er nog nooit eentje plat zien gaan (door softwarematige oorzaak that is, een overlijdende schijfcontroller of een collega die een schakelaartje achterop een UPS perongeluk omzet heb je ze zo mee plat )

[edit]
Ik wil wel nog steeds eens gaan proberen of ik er eentje onderuit krijg, toch als qsecofr eens een fork()-bommetje op loslaten...

[BezurK]

geloof het of niet, ik heb QNX gecrashed gekregen...
Ik draaide het een paar weken geleden op mijn pc, na 2 weken non-stop draaien crashede hij ineens, een complete freeze, onder windows had ik dit dagelijks (of zelfs meerdere keren per dag) en onder linux heb ik dit nog nooit (lees: _NOOIT_) gehad, en ik draai linux al ruim anderhalf jaar.

Ik stond wel ff achter m'n oren te krabben toen QNX vast liep, ik had gehoord dat het retestabiel was, maar blijkbaar zit er toch een bug in, ergens.Het kan echter ook een hardware fout zijn, maar hoe verklaar je dan dat het me bij linux niet gebeurd .

Voor de rest is het trouwens een retegoed OS! Ik snap niet waarom het nooit aangeslagen is, het is stabiel, posix-compliant en heeft een ONTZETTEND mooie GUI (photon rox!).

[Verwijderd]

Op donderdag 13 december 2001 10:11 schreef Markiedam het volgende:
Je bent errug knap als je QNX vast kunt laten lopen...
Mij lukt het niet.
Zal dit het enigste OS zijn die niet kan vastlopen?

Er zal echt wel een manier zijn om het te laten vastlopen waarschijnlijk maar er zijn wel meer OSsen die niet (of nauwlijx) vastlopen hoor . Ja na Windows zou je bijna denken dat het niet meer mogelijk is, maar gelukkig wel (BSD en BeOS draaien bij mij ook zeeer stabiel)

[Fireman]

///Off topic///

Op donderdag 13 december 2001 10:11 schreef Markiedam het volgende:
Je bent errug knap als je QNX vast kunt laten lopen...
Mij lukt het niet.
Zal dit het enigste OS zijn die niet kan vastlopen?

Succes

ps. Als je het wel lukt zeg effe hoe

www.qnx.com

Ik ben helemaal geen taal purist of een programmeur maar enigste is wel heel erg onstabiel.

/// end off topic///


Ps: het is enige

[TrailBlazer]

Het Besturingssyteem vanmijnmagnetron heb ik nog noit een blauw scherm zien geven. En ja dat is een besturingssyteem

[Verwijderd]

Op donderdag 13 december 2001 22:23 schreef TrailBlazer het volgende:
Het Besturingssyteem vanmijnmagnetron heb ik nog noit een blauw scherm zien geven. En ja dat is een besturingssyteem

zeker een zwart/wit monitor?

[Verwijderd]

Op donderdag 13 december 2001 21:51 schreef BezurK het volgende:
Voor de rest is het trouwens een retegoed OS! Ik snap niet waarom het nooit aangeslagen is, het is stabiel, posix-compliant en heeft een ONTZETTEND mooie GUI (photon rox!).

Uhm omdat Qnx versie's die voor neutrino ontwikkeld waren niet gratis te downloaden waren ?

[BezurK]

Op donderdag 13 december 2001 22:18 schreef firemen het volgende:

///Off topic///

[..]

Ik ben helemaal geen taal purist of een programmeur maar enigste is wel heel erg onstabiel.[afbeelding]

/// end off topic///

Ps: het is enige

Als we toch aan het zeuren zijn, het is instabiel niet onstabiel

[BezurK]

Op donderdag 13 december 2001 22:52 schreef X-terior het volgende:

[..]

Uhm omdat Qnx versie's die voor neutrino ontwikkeld waren niet gratis te downloaden waren ?

Windhoos is toch ook nooit gratis te downloaden geweest?

[RG]

Op donderdag 13 december 2001 22:23 schreef TrailBlazer het volgende:
Het Besturingssyteem vanmijnmagnetron heb ik nog noit een blauw scherm zien geven. En ja dat is een besturingssyteem

Nou ik heb ooit verhalen gehoord van Samsung TV's die vastliepen. Maar zulek embedded handel kun je moeilijk vergelijken met een computer OS.

[JayTaph]

Op donderdag 13 december 2001 17:12 schreef mietje het volgende:
Laat hem dan eens lekker een uurtje lopen. Hij gaat echt alle process slots in je OS bezetten, en dan kun je geen nieuwe processen meer starten, dus hangt hij.

Niet als je zorgt dat je altijd al vantevoren een paar shells hebt geforkt (a la apache zeg maar)

Jij activeert magic SysRq op een multiuser systeem en beweert dat het niet plat te krijgen is?

Het ellende is dat na elke 'enter' de shell een nieuwe fork() opstart . Ik weet het niet zeker, maar ik geloof dat er ook patches zijn waarbij PID 0-999 alleen voor init en priviliged doeleinden zijn (inclusief getty's). Hierdoor kan je bombarderen wat je wilt, en wordt het systeem langzamer, maar je kunt *altijd* inloggen als root, of bash-shells draaien als root (tenzij jij 1000 root-fork()'s nodig hebt )

[kenneth]

Op donderdag 13 december 2001 15:38 schreef blouweKip het volgende:

[..]

Ach, linux ondersteund in principe alles en het is nog steeds tig veel keren meer stabieler dan windows (zelfs xp), dat windows meer drivers en gadgets (welke btw?) heeft komt niet door ms oid, dat komt door de support vanuit de industrie, als in linux een brakke driver neergaat dan loopt mn systeem nooit vast, in windows xp simpelweg wel...dat heeft alles met het ontwerp van het systeem te maken en niets met de brede ondersteuning

Onzin. Uitgaande van een gemiddeld OS op een i386-architectuur heeft een driver keiharde ring-0 toegang, wat inhoudt dat hij de machine kan laten crashen, geheugen onbedoeld kan overschrijven, hardware verkeerd kan aanspreken, spinlocks eeuwig kan vasthouden, enz enz.
Tenzij je het over user-level drivers hebt (en die zijn, uhhh, zeldzaam ) is het, ongeacht het besturingssysteem mogelijk om met een brakke driver het systeem omlaag te halen.
Dat is gewoon inherent aan het concept driver. Er kan door het OS wel iets tegen gedaan worden, maar als een driver er zin in heeft, trekt-ie zo je systeem omlaag.

En nog iets: Linux 2.4.x ... wat een bagger kernel-tree zeg, dat kan je toch niet menen als industrial-strength-wannabe?
Nee, dan is winxp vers van de pers bij mij (en vele anderen) stukken stabieler. Of anders de 2.2 serie ...

[JayTaph]

Op donderdag 13 december 2001 21:51 schreef BezurK het volgende:

Voor de rest is het trouwens een retegoed OS! Ik snap niet waarom het nooit aangeslagen is, het is stabiel, posix-compliant en heeft een ONTZETTEND mooie GUI (photon rox!).

Ik hou niet van gui's onder qnx .. maar QNX heeft mqueue's en proxies standaard plus het feit dat het compleet op ipc-messages draait. Of je dus 1, 2 of 100 qnx-dozen hebt, het lijkt voor elk systeem of alles op hetzelfde systeem draait.. (wat heeeeerlijk werkt btw)

[PolarWolf]

Op donderdag 13 december 2001 20:10 schreef deadinspace het volgende:

[..]

code:

#include <unistd.h>
#include <sys/types.h>

int main( int argc, char *argv[] )
{
      while( fork() < 1 )
            ;

      for( ; ; )
            malloc( 10000 );
}

man ulimit :-)

[Fireman]

Op donderdag 13 december 2001 23:17 schreef BezurK het volgende:

[..]

Als we toch aan het zeuren zijn, het is instabiel niet onstabiel

Zie je wel ik ben geen taal purist

Onstabiel is zeker als je het geestelijk niet zo goed meer op een rijtje hebt.


Cu. geen gezeur meer

[Verwijderd]

Op vrijdag 14 december 2001 08:57 schreef PolarWolf het volgende:
man ulimit :-)

/me zucht

Gaan we er een wedstrijdje van maken? Als root kun je alle hard- en softlimits veranderen (man setrlimit). Compile deze, run hem als root en zie de load binnen een seconde ver boven de 100 schieten. Binnen een een paar seconden zit je systeem muurvast.

code:

#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <limits.h>

int main(void) {
  struct rlimit limits;
  limits.rlim_cur= limits.rlim_max= INT_MAX;
  setrlimit(RLIMIT_CPU, &limits);
  setrlimit(RLIMIT_NPROC, &limits);
  for(;;) fork();
  return 0;
}

[deadinspace]

Op vrijdag 14 december 2001 15:17 schreef mietje het volgende:

[..]

/me zucht

Gaan we er een wedstrijdje van maken? Als root kun je alle hard- en softlimits veranderen (man setrlimit). Compile deze, run hem als root en zie de load binnen een seconde ver boven de 100 schieten. Binnen een een paar seconden zit je systeem muurvast.

Mja, als root kun je je systeem altijd wel over de zeik helpen... das niet zo moeilijk hoor...

code:

# cat /dev/zero > /proc/kcore

Maar mijn fragmentje werkt dus ook als user (tenzij er dus maatregelen tegen zijn getroffen, wat maar bij ERG weinig mensen het geval is lijkt me).

[edit] Met 'mijn fragmentje' bedoelde ik het stukje C code dat ik eerder in deze thread gaf. [/edit]

[Verwijderd]

Op vrijdag 14 december 2001 15:25 schreef deadinspace het volgende:
Mja, als root kun je je systeem altijd wel over de zeik helpen... das niet zo moeilijk hoor...

Dat bedoel ik maar Ik wil met dat code-voorbeeld laten zien dat je elk systeem met een paar regeltjes code plat krijgt, en dat je zo'n stukje code zelfs portable kunt schrijven; je hoeft niet eens in de kernel zitten rotzooien.

<edit>
Je stukje code crasht een systeem alleen als de ulimits niet goed staan. Als normale user kun je een soft-limit niet boven een hard-limit zetten, dus zal hij stoppen met forken en mallocen als de limits bereikt zijn.
</edit>

[Verwijderd]

Er word wel erg van de vraag/opmekering afgeweken