[lkml]   [1996]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: memory crash [flame]

    I guess this is a (mild) flame. Real Linux kernel hackers
    probably have something better to do than read this. This
    is my own opinion way too late in the morning, and shouldn't
    be taken too seriously. I've only submitted very minor
    patches, and my name isn't in the CREDITS. I am not to my
    knowledge a member of the Church of the Subgenius, a
    worshiper of Eris, or a member of the Illuminati.

    In general, Linux hackers care a lot more than I imply.
    Maybe a nerve was struck. I'll say it again


    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.


    > 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
    (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.


    > 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.


    > '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

    > 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)

     \ /
      Last update: 2005-03-22 13:38    [W:0.108 / U:32.288 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site