lkml.org 
[lkml]   [1996]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.0, loggings, cpu quotas, 2.1 issues, etc.
Date
From
+> > It's implementable. The kernel needs a "struct userinfo" per logged-in user 
+> > for that to work. The same structure could also hold total memory usage,
+> > which would enable us to finally block most of the more malicious
+> > fork/malloc bombs.
+>
+> Make that a chargeable group and we get the ability to partition a big
+> machine up by department and to do sensible charging schemes. For big number
+> crunchers that is an issue.

Hmmmm. I don't know _THAT_ many big numbercrunchers, that are running LINUX right now...
(But I'd like to see that! ;-) )

Usually you still may do accounting. Well, I know it has some drawbacks, but for
most cases, you can create bills for your users, in dependancy to how much they
used your machine... - Isn't that what you want ?

Since LINUX is still run mostly on single-User-machines (Workstations ?! :-) ),
you won't need such a kernel-feature. And since it would decrease performace, I would make
at best a "configurable option" for the kernel.

+>
+> > But then, if you have that kind of user population where this is a
+> > significant problem, your money is better spent on educating these guys to
+> > Not Do That (and kick the few people who can't understand the words "cease
+> > and desist" off the system).
+>
+> Users you can educate, "Customers" tend to be trickier
+>
"Customers" can calculate, users tend to be clumsier. ;-)

Which shall mean:
A "Customer" is always a strong force. But they sure will calculate how much
their efforts/time will cost them and will tend to search for the cheapest
alternative. So if there's any alternative for your service, be careful...

Users on the other hand, tend to be dumb and slow. It's "not their fault", so
they won't do a thing.

Regards,

Herbert
_____________________________________________________________________
Herbert Wengatz, 81375 Munich |Disclaim: This Mail is my own opinion,
Office :hwe@uebemc.siemens.de |not that of my company.
Private:hwe@rtfact.muc.de | http://www.muc.de/~hwe/rtfact




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:1.122 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site