On 10/19/05, Wolfpaw - Dale Corse <[EMAIL PROTECTED]> wrote: > > well, I don't know about BSD in general, but just try it with > > OpenBSD. If the machine is generally capable of this task > > (has the mem and power to suppert n sessions in parallel), > > it's just your task as admin to make it happen. The means are > > there. If your users bring down your machine it's most > > probably your own fault. > > You may well be right, though I would say that the amount of > Code changes users would be required to do, to make it work > Would end up in my lap, seeing as there are some things OpenBSD's > Kernel does not have, or has fairly out of date versions of
well, for most things I'd say you won't need to change any code. If you mean newb programmers _hacking on the very OpenBSD they share_ this is generally a bad idea. > One example I can think of is libpcap - and it seems to be > Lagging behind more because some folks are upset that the devs > There won't accept their commits, then actually fixing the software. > > Perhaps I will port it .. And see how many people yell at me for > That. :) If you can port it, you can also use it on your own box, so where is the problem? > Resource use in general was the problem - you can't lock them down > entirely, because the progs use 99.9 CPU when starting, then settle > to 2 or 4.. So using something like lshell, or equiv. Doesn't work > very well. I use a prog that simple snaps a picture of the proc > table every half hour, and kills things that are over their limit > for 2 runs. login.conf (5) > Problem comes into play when a user starts say .. 50 > Copies of the same thing, because it didn't boot.. They just keep > hitting the button .. :( login.conf (5) --knitti
