Hi,
On Wed, Jun 10, 2009 at 07:50:39PM +0200, Arne Babenhauserheide wrote:
> Am Dienstag, 9. Juni 2009 07:19:28 schrieb olafbuddenha...@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-
