> > 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 > > > > 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. > > Either submit complete bug reports or diffs, but stop whining.
I wasn't whining - again - how the hell is justifying what I said whining? > > Perhaps I will port it .. And see how many people yell at > me for That. > > :) > > We have good reasons not to blindly follow changes in libpcap. >From what I understand they are security related reasons.. Would anyone care to expand a bit on that, so that I may know what to look for when doing so? > > 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. > > 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 > > .. :( .. Something Kernel level has saved the box from dying many > > times. > > I don't know lshell, but did you try the standard resource > limit facilities that can be set up using login.conf? Sometimes that works, but again it's a hard limit - then we get users bitching about it being 'slow' when they compile. Thank you for the suggestion though :) I remember on 'the other bsd' we tried - the box actually just couldn't take the abuse it seemed, and kept crashing.. Plus you mix the code differences in software which was written mostly on linux, with BSD, and you get a bunch of changes required to each one. Gets heavy on the support queue :) > Again, submit complete bug reports and please stop talking > vague. If you find something is wrong supply us with hard > facts, so we have some clue what your problem is. I have taken that point - and apologized for not doing so - I would appreciate it the hostility would dissipate - as stated, this email here was simply for discussion. -D.
