Please help

[Esben Mose Hansen]

Arryn: I like linux as much as the next man, but linux is only a little better than windows with regard to what runs at ring 0/1. In fact, all kernel modules run in the same ring as the kernel itself: it is monolithic. BSD is the same. If you want a microkernel, which does not exhibit this problem, you want HURD or other exoteric kernels. Last time I heard, (true) microkernels have a 20% performance hit (according to Tannenbaum as far as I recall)

Graeme Dice: It is getting difficult to crash a modern, hardened linux system. E.g, fork-bombs doesn't work anymore. The trick you mention I do not understand. The kernel has no thread or process as such; so I don't understand how you can determine or exceed it's prioty?

[Sheap]

As far as what runs in what ring, it isn't really that big a deal. First, most modern CPUs have only 2 rings, so if your OS is intended either for platform independence or targeted at a 2-ring CPU, you don't have a choice. This is pretty much everybody except Windows. Secondly, one of the reasons many CPU designs have only 2 rings, is because having extra rings isn't really all that useful. As evidence you can look at free Unix type systems, and note their great stability, yet they all run in 2 rings only. What should they be doing that they aren't, and how much real-world improvement would it give?

[Arryn]

Originally posted by Esben Mose Hansen:
Last time I heard, (true) microkernels have a 20% performance hit (according to Tannenbaum as far as I recall)

Esben: One of my biggest beefs with MS is that they have always favored performance over stability (hence allowing drivers and apps to run at the same level as the kernel). What good is software that loads a second or two faster if you never know when it'll crash your system?

Sheap: when did Intel switch from 4-ring to 2? I haven't followed CPU hardware all that closely in a number of years. The 386 processors had 4 rings, and I believe the 486s as well.



The basic problem is that MS OSes never used more than 0 and 3 (sticking what should have been in 1 & 2 in 0 where it shouldn't have been), so I presume that Intel (who was in partnership with MS for quite a while) eventually gave up the idea in order to simplify their designs if MS wasn't going to use the feature.

[Esben Mose Hansen]

I also fail to see what you gain from the middle rings. The discussion is mostly what should be in ring 0 / kernel space and what should be in ring 123 /userland.

Another problem is that people think that moving something to ring 0 improves performance (anybody remember the HTTPD module?), but in reality, this is not always so.

But I am no expert in OS design; I regret that HURD is becoming increasingly irrelevant, as it has some interesting ideas. Besides, I'm spoiled: I dislike having to reboot just because I have upgraded my kernel

[Graeme Dice]

Originally posted by Esben Mose Hansen:
Graeme Dice: It is getting difficult to crash a modern, hardened linux system. E.g, fork-bombs doesn't work anymore. The trick you mention I do not understand. The kernel has no thread or process as such; so I don't understand how you can determine or exceed it's prioty?

Make a blocking I/O thread that will never return control to the Kernel, and that intercepts all interrupts and ignores them. It might not be doable on all unix based systems, but I know that it was under Darwin just two years ago.

[Tuskerlove]

Thanks all for the input. I'm only partially computer literate (King Lear) so I'll try all the things you suggested. Hopefully, I can get it installed. I can always contact customer service and see if someone can walk me through how to use the

/NCRC switch.

I'm sure this is illegal but I have to ask - am I allowed to download the program off of Kazaa or someplace and use my cd key to prove I own the software? I have already registered the game with the company so they have all my pertinent info plus the sales receipt and packing list.

I jsut don't want to spend another 50+ to get the game again if I can avoid it.

Again you guys are the greatest!

Thanks

Tuskerlove,

Please contact Annette at the Customer Service:

http://www.shrapnelgames.com/cgi-bin...wonderdesk.cgi

She may be able to help you with finding something out about your copy of Dom2, or CD-key, registration, etc.

[alexti]

Originally posted by Graeme Dice:

quote:

---

Originally posted by alexti:
While OS can survive one or 2 deaths of VC, after a dozen or so it apparently runs out of its lives.

Well, if you're writing low-level software, then it's possible to crash just about any OS. Try making an I/O thread that runs at a higher priority than the kernel in *nix based systems for example.

---

The best way to kill *nix that I've experienced was to have bug in "fork" logic that caused my process to multiply exponentially. I've tried to kill them manually, but I was losing the race frantically typing kills. Apparently sysadmin didn't set any quotas on processes, so my application was gradually taking over big Solaris server. Luckily, the server has enough life force to survive until I've paused to think and to figure out that I could do better than doing kills from the console

But I think that a lot of those kind of problems can be protected against on properly configured *nix system. Not if you're writing the kernel yourself, of course, though.

[Norfleet]

Originally posted by alexti:
The best way to kill *nix that I've experienced was to have bug in "fork" logic that caused my process to multiply exponentially. I've tried to kill them manually, but I was losing the race frantically typing kills. Apparently sysadmin didn't set any quotas on processes, so my application was gradually taking over big Solaris server. Luckily, the server has enough life force to survive until I've paused to think and to figure out that I could do better than doing kills from the console

Heh, you mean something like "kill -9 -1"? I'm surprised that it took so long. You'd think that the faster the server was, the faster it would devour its own resources. Although maybe your program wasn't quite as directed as something like "while(1) fork();"

[alexti]

Originally posted by Norfleet:

quote:

---

Originally posted by alexti:
The best way to kill *nix that I've experienced was to have bug in "fork" logic that caused my process to multiply exponentially. I've tried to kill them manually, but I was losing the race frantically typing kills. Apparently sysadmin didn't set any quotas on processes, so my application was gradually taking over big Solaris server. Luckily, the server has enough life force to survive until I've paused to think and to figure out that I could do better than doing kills from the console

Heh, you mean something like "kill -9 -1"? I'm surprised that it took so long. You'd think that the faster the server was, the faster it would devour its own resources. Although maybe your program wasn't quite as directed as something like "while(1) fork();"

---

Yeah, it was much better camouflaged, but they key was that the each process was establishing communication with the spawned process before spawning a new one. This required to do some work before, and as the server was getting loaded more and more whole thing started to slow down which gave me a breath