In general, Linux hackers care a lot more than I imply.
Maybe a nerve was struck. I'll say it again
WE DO CARE ABOUT THE QUALITY OF THE KERNEL CODE.
We wouldn't be doing this for free if we didn't.
So, "Don't bug us, man!" as it were.
Sheldon Newhouse wrote:
> On Tue, 10 Dec 1996, William Burrow wrote:
> > > Just for the hell of it, I decided to see what would happen if I
^^^^^^^^^^^^^^^^^^^^^^^
> > > overloaded my system with cpu intensive programs which would cause the
> > > system to run out of memory and swap. The system started thrashing, and
> > > ultimately required a hard boot. I don't think this is healthy. Any user
> > > could do this.
> > Is this news to you guys? This ran by the newsgroups a few weeks ago. Do
> > you guys read the newsgroups? Do you want, say, two line summaries of the
> > latest brouhahas on the newsgroups and length of such threads?
> Which of the 11 newsgroups had this thread? Was it 'any one can crash
> your system' or something like that? Sorry, did not read it. Sounded too
> much like 'Anyone can make an enormous amount of money.' I look to the
> kernel mailing list and the RedHat mailing list for more serious stuff.
> Don't have time to read everything in the newsgroups.
All too true, but in this case it *is* off topic. And if
you're interested enough in stress testing your machine to
be doing things "just for the hell of it" you might look at
the "crash your system" threads. After all, they don't
contain the words "money" or "cash", or the symbol "$".
> > > I have some questions:
> > > 1. Is it possible to set limits on accounts so that
> > > a. this kind of thing cannot be done ?
Not a kernel development question. (Unless you've verified
the answer is "no" -- which I highly doubt you have -- and
are asking "what kernel support needs to be added so that
this kind of thing cannot be done"?)
> > > 2. What should be done to insulate the system against this kind of thing?
Again, not a kernel development question, at least not with
this phrasing.
(And, to respond to the response...)
> > Better swap scheme. Linux performs horribly under heavy swapping.
This is needed. Linux assumes you pretty much have enough
RAM most of the time, and enough swap all of the time
(AFAIK). In general, that's good enough. But, there's
always going to be someone pushing it over the edge.
> > Memory is getting cheaper though, so maybe the impetus is slowly moving
> > away.
This is a lame response. The impetus is *not* moving away.
People will just want to be able to solve *bigger* systems
on their Linux boxes. Or handle *more* users. Or whatever.
The point is that Linux has problems with certain kinds of
memory use. Throwing more RAM at the problem is fundamentally
unsatisfying, regardless of how cheap it is.
And, back to sen:
> My point was not to show a simple way to crash the system. It was to
> ask about ways to control errant programs. The defaults should be
> set up to do this automatically. I am surprised they aren't.
ROTFL
> Is Linux an Operating System or a puzzle?
Yes; this is a false dichotomy. If you got it for free (or
paid less than $50, or bought something called SLACKware
(there's a reason it's called that)) then you get both. Tell
your family: "Don't buy me anything from a hobby or game
shop for Christmas, I have Linux. Buy me clothes this year."
(Check out http://www.monmouth.com/~jshahom/jargon/slack.html
(sense 2) for more info on slack.)
> Don't get me wrong. I think Linux is great.
Not that you've shown you know that much about it.
> Shows even greater promise.
Yep.
> And I think you developers are doing great things.
I'm sure they thank you very much.
> But, c'mon, the default setup on the box should not make the sysadmin
> check more or less everything to make sure there is no danger.
Again, where did you get your "Linux" from? If you paid
for it, complain to the people you bought it from. Kernel
hackers already know the problems and have worked around
them to their own satisfaction, for the time being. The
primary use for Linux really is compiling the Linux kernel.
Everything else is gravy. Linux mm handles compiling the
kernel really well.
> There
> ought to be a simple procedure in the kernel to kill runaway processes.
How do you know when the process has run away? Why should
it be "in the kernel"? That doesn't strike me as how the
kernel works.
> Because a user doesn't know enough about how to run things is no reason
> why the whole system should get killed.
ROTFL some more. Sure, that's true. <smirk> But maybe
the assumption in your distribution was that the user isn't
clueless, so it never came up. At the very least, the
sysadmin would double check everything to make sure.
> Bet this doesn't happen with Solaris. I'll try tomorrow.
After you do, talk over the results with Dave Miller.
> Wonder if it happens in FreeBSD.
And if it doesn't, what if there's something about *IT* you
don't like. Then what?
> I have been arguing positively about the modern 'stability and
> advantages' of Linux with my friends for months now.
Thanks.
> 'Not just for hackers'.
Not *just* for hackers -- but hacker friendly will always be
the most important attribute (because hackers are who produce
the other attributes). "Hacker's OS" ought to be the
ultimate accolade.
> 'More secure
If set up correctly. Though, I am under the impression
that NT isn't oriented to remote logins... Disabling them
increases the security of your Linux box, too.
> and functional than NT.'
Unless the function you want is MS IE, or some other
proprietary software.
> 'Linux on Intel is a great cost-effective alternative to Solaris on SUNS
> in a production environment'
Depending on what you're producing...
> etc. etc.
As has been pointed out to me multiple times when I promote
Linux, software costs themselves are usually the *least*
costs associated in business with software maintenance.
Man hours are what cost you. If you've really found
something that Solaris is better for this year, great. Next
year, it may be a different story.
> No more ranting, now. I am just amazed. One answer to my post that says
> this isn't a kernel issue,
Which we pretty much know that it isn't, except for the
above-mentioed aspect.
> and now an answer which says:
> 'We all know this, where have you been?'
> As if this is just the most natural thing in the world,
> and why would one expect anything esle?
Because writing perfect mm code is nontrivial. The current
code does the 90% solution. This is what you usually aim
for in Unix. Not that that's an excuse, just an
observation. If you have the time and ability to fix the
code, go for it. I've never locked up my box (even a 386/40
w/8M of RAM with Linux 1.2) compiling the kernel. (Did it
once intentionally, then made sure it was unlikely to happen
accidentally.)
> It isn't supposed to be this way, period!
And one more hearty guffaw.
Get a copy of _The UNIX-hater's Handbook_. Read it and
weep, man; read it and weep. (And then go back and read my
intro: Linux hackers care more about good code than DEC,
Sun, HP, AT&T... or anyone else with shareholders.)
-- Michael J. Micek, peripatetic philosopher. (currently) mmicek@muddcs.cs.hmc.edu