OK, I know I should not answer to this thread, but I do it anyway, sorry
for that.
On Wed, 22 Mar 2000, Matthew Dillon wrote:
> Generally speaking if a user wants to crash a machine, he can crash
> a machine. We've probably 'fixed' a dozen crashability holes in the
[...]
> For example, just before the 4.0 release it was found that one can
> easily run the kernel out of vm_map_entry resources by mmap()ing
> hundreds of thousands of tiny files. We added a vm.max_proc_mmap
> sysctl to control that. And it still quite easy to bypass the datasize
> resource limit through the use of MAP_ANON mmap's.
[...]
The point is IMHO (all I say here is IMHO, of course), Unix (Ok, Linux
Is Not UniX) Unix is intended as an OS to enable a capable user &
programmer to use the computer as a very powerful tool. You see this
everywhere in the design of Unix. The scripts and possibility of filters
everywhere in the system setup and daemons show that and allow the capable
person to manipulate and do everything. Of course this is not simple,
the OS is designed to be used by a capable user, not for the click a
button and hope it does the right thing person.
In addition, each single user should be able to get the maximum usage of
the machine.. Unfortunately there are some obvious unsolvable conceptional
problems if each user can get the maximum usage of the machine for him.
Another design issue of Unix is that most of the system is readable by
anyone. Normally any user can see which processes everyone else runs, for
example. All this is ok in the situation where you have a workgroup of
people using a machine to get the maximum use of it.
Unix is not designed to have logged in a community of hostile users. And
you cannot really make Unix behave like that. Unix does not want to be
like that actually: That level of hostility of the os to users would
hinder users in a normal context to make good use of the machine.
The point here is like always: there does not exist the solution to
everything: C (or C++) is a nice language, I like it myself very much..
for example. However, it cannot do everything.. There are cases where
Lisp, Fortran maybe Java.. a shell script, whatever... is better suited..
Does that mean you would pervert C to have all the features of these
languages? No, you don't. Actually you cannot do that. Some features are
actually contrary to each other. So a sensible programmer uses the
language most fit to the problem he wants to solve.
Now, if you have a bunch of hostile users, you don't let them login into
your unix. You don't use unix actually.. You could run one of these old
mainframe OS's.. maybe the old IBM VM/CMS.. every user gets actually a
small virtual PC with a single threaded CPU and some fixed amount of
memory.. Well... you lock up your login session... you can't just login
another time.. (no other process possible for you).. you dial up the
operator and tell him zillions of excuses and how stupid you are and he
will kill your old session.. Oh.. a bug in the OS.. your session is
unkillable... don't worry.. at the scheduled maintenance next week the
machine is rebooted..
So what does that mean? Unix is just not the right OS for what you want
to do and cannot be it and does not want to be it. Is that a problem? Not
really.. just choose another OS. Actually, you could achieve what you want
under unix by not giving people a full login account but give them a
special application as login shell which only allows very limited
operations. Loading or coding an own application and run it should by far
not be one of their options. Maybe some very restrictive scripting
language which is interpreted in a sandbox (a dialect of Java, maybe?)
The same holds for the undieable overcommitment thread. Many new linux
users come from a single threaded DOS or home computer OS scenario. They
just don't understand unix memory semantics. I had the same problem when I
first came into contact with unix (not linux those days).. However, I was
first surprised only, then informed myself and realized why it was made
this way and realized it is indeed useful for me.
Actually, in those old days, we used to have some machine with a
non-overcommitting unix.. It was a pain.. I tell you.. we could simply not
use all the memory the machine actually had.. just because the fork() and
general process semantics of Unix does not work w/o overcommitting. That
machine always had megs of never used swapspace around (which was pretty
expensive those days). It is a simple decision: you overcommit memory or
you don't use the unix API. This does not mean that one should not discuss
other ways to deal with OOM.. you may have some quotas or whatever.. I
really like the sending of SIGDANGER in case some low watermark is hit and
each process can decide to to catch it, notice with some syscall that
memory is low and react accordingly.. still it is impossible to completely
get rid of overcommitment.. IF you want to have the powers of a unix OS!
So, please.. this list is about creation of a unix style os.. if that is
not what you need.. go away..
BTW, I must admit I strongly dislike the 'linux world domination' attitude
of some people. There is no OS for everything. Not linux, not anything
else. This attitude makes people only think linux must be the solution for
them when it is not.
I don't want a linux OS in my dishwasher as much as I don't want a Windows
in there.
Best wishes and peace to everyone,
Michael.
--Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:38 EST