System stability (was: A GNU/Hurd Roadmap dream)

[olafBuddenhagen]

Hi,

On Wed, Jun 10, 2009 at 07:50:39PM +0200, Arne Babenhauserheide wrote:
> Am Dienstag, 9. Juni 2009 07:19:28 schrieb olafBuddenhagen@gmx.net:

> > I have been using the Hurd for most of my everyday work for some two
> > years now. 
> 
> Wow, that's a statement we should have in the wiki! 
> 
> Maybe your whole post as addition to the "status of the GNU/Hurd"
> site? 
> 
> It's a honest, practical information about the current state of the
> Hurd. 

I haven't been thinking about that when I wrote this statement... But
you are probably right :-)

> > (Unfortunately, I'm not one of these people who immediately try to
> > fix every problem they meet. Most of the time, I just live with
> > them, while dreaming about greater deeds...)
> 
> You're not alone with that. I file a bug report for about every three
> problem I encounter (since filing the report takes significantly more
> time than just ignoring the problem - at least on the short term... ). 

I must admit that the ratio is probably even worse in my case... I got
very mixed results with bug reports to various projects in the past,
which is not exactly encouraging :-(

> > Note that while many of the stability problems are simply bugs to
> > fix, the system will still be very fragile in the absence of these
> > -- a simple port leak is sufficient to kill it within seconds. This
> > is something that can't be easily solved. Properly fixing this will
> > require a sound resource accounting framework, i.e. very fundamental
> > changes to the system... Though I tend to believe that it could be
> > improved at least partially, at the expense of flexibility, by
> > enforcing certain fixed limits on users, processes etc. like other
> > UNIX systems do.
> 
> Can that be done in a way which can easily be undone once a proper
> framework is in place? 

Adapting the system to use such a framework would probably require
touching the same places anyways, so I guess it's not a problem.

> I think it's important to have something which works first and then
> improve it (while taking care not to block the path forward). 

Full agreement!

> This fragility does sound like it would make the Hurd completely
> unusable in most situations,

Nah, it's not that bad. Usually you don't have actively malicious local
users on your system; so that leaves us with bugs in the software, which
need to be fixed anyways...

Note that until recently, you could pretty much kill many UNIX systems
(including GNU/Linux) in the default configuration, with a simple fork
bomb like this one:

   _(){_|_};_

I think the situation is somewhat better nowadays, as most machines have
enough RAM, that the per-user process limit is hit before memory
exhaustion sets in -- now you actually would need to use a considerable
amount of memory in each forked process, to make it really effective
again ;-)

In fact, once when I had something that reproducibly triggered a zalloc
panic, I tracked it down to an inadvertant fork bomb...

> and sacrificing some short-term flexibility for the sake of getting
> more users (and reestablishing the flexibility later) might actually
> make the flexibility get into a stable system faster. 

Again, full agreement :-)

> Is it possible to do it with not too much effort? 

I'd hope so, but I can't really tell for sure...

-antrik-