[Gllug] ulimits

[home at alexhudson.com]

On Sun, Sep 02, 2001 at 03:32:50PM +0000, Ian Norton wrote:
> > > And this is a problem how? I presume you know how nice works.
> > 
> > I suppose it must be ``beyond my abilities'' to understand that too huh?
> > :)
>  
> I am quite sure you have zero knowledge of jcms coding ability. and inferring
> that it was beyond the ability of an under grad, wasnt our good friend linus an
> undergrad once? please do not make such sweeping and offensive generalisations
> about people!

This is the same Linus Torvalds who, as a student, set /dev/modem to
/dev/hda and overwrote his boot sector with ATDT... ? :)

I wasn't inferring that jcm is particularly stupid - I'm inferring the
problem is particularly hard, and beyond the abilities of most people. Linus
has only got to his level of knowledge because he has been working on an OS
for over ten years. I didn't say jcms ability to understand is poor, just
that his understanding of this problem was limited. 

> > > If users are run low priority, then the machine is still able to do
> > > its work.
> > 
> > Now you're heading away from the original point - of course it can
> > ``still do its work'' however setting priority limits alone do not a
> > good system make IMO.
> 
> priority and fork limits yes, useful for keeping a machine used by many for
> critical operations under control.

I refute the suggestion that hard CPU resource quotas are needed for a good
system. Priorities are all you need. CPU quotas would make the system
slower, in every circumstance. There is no speed gain over priorities ever.
Such hard quotas are used in real life in contract scheduling, but the
design trades off the loss in speed for the ability to get a guarantee. 

> > > Linux is not a research OS.
>  
> would you have us use minix instead?

In some respects, yes. The problem with Linux is not design-related,
particularly, but that it is a moving target. Minix & Mach (which you can't
compare anyway, Mach not being a kernel ;) have much better defined
interfaces, which don't change (Mach particularly). It's almost design by
contract. You can mess with any part of the OS, and as long as you don't
break the contract it still works. I'm not just talking about APIs, but
also behaviour and all sorts of other things. Minix & Mach are just better
understood, and they're also a hell of a lot simpler. As I said, the right
tool for the right job.

> > > Find me a paper researching OS principles on Linux
> > > and I'll show you twenty on Mach.
> > 
> > Fine, go use it then if you want to. I have not imposed any restrictions
> > on your choice however you seem to wish to convince me that mine are all
> > wrong.

I'm trying to offer you good advice to avoid pitfalls novices make. Take it
or leave it, it doesn't matter. You asked a question, and I'm giving you
correct answers. Your choices are wrong - if you knew a lot about the
subject, you wouldn't have asked the question in the first place. I'm trying
to give you an understanding of the problem, and in which circumstances it
would be most appropriate / easiest to implement - Linux is about as far
away from that as is possible.

> > I shall continue this discussion off list.
> 
> remind me to read messages before hitting reply ;-)

Should put it at the top like me :)

Cheers,

Alex.

-- 

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug