[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: System stability
From: |
olafBuddenhagen |
Subject: |
Re: System stability |
Date: |
Sun, 28 Jun 2009 22:27:58 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
Hi,
On Tue, Jun 16, 2009 at 11:13:26PM +0200, Arne Babenhauserheide wrote:
> Am Montag, 15. Juni 2009 00:38:16 schrieb olafBuddenhagen@gmx.net:
> > 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 :-(
>
> Maybe I just had better luck... most of my bugreports where either
> well received or ignored...
Well, "ignored" is the worst possible response to a bug report...
> > > > 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.
>
> Should I add it as a feature request or such?
I guess it would be useful to add it to the Savannah task tracker...
Note though that there is no consensus about this. It is my *personal*
believe that this is doable and worthwhile.
> > > 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...
>
> If it means that the users need to be malicious, the issue is not as
> much of a problem, I think. It sounded to me as if it could be killed
> by a simple user- error.
Usually it's not user errors, but bugs in software that cause port
leaks. But user errors *can* cause resource exhaustion:
> Naturally having limits which keep userfs from shooting the whole
> system would be nice anyways - even if only in the case that a user
> unintentionally creates a fork-bomb or similar (I once managed to
> shoot my system with one, though I only wanted to try the python
> subprocess module ;) )
This is one type of user error that even mainstream systems aren't safe
against in standard configurations -- which IMHO is a pretty clear
indication that this is acceptable in some cases at least...
-antrik-
- Re: A GNU/Hurd Roadmap dream, (continued)
- Re: A GNU/Hurd Roadmap dream, olafBuddenhagen, 2009/06/09
- Re: A GNU/Hurd Roadmap dream, Arne Babenhauserheide, 2009/06/10
- Re: A GNU/Hurd Roadmap dream, Arne Babenhauserheide, 2009/06/12
- Re: A GNU/Hurd Roadmap dream, ms, 2009/06/12
- Re: A GNU/Hurd Roadmap dream, Arne Babenhauserheide, 2009/06/15
- Re: A GNU/Hurd Roadmap dream, Arne Babenhauserheide, 2009/06/15
- Re: A GNU/Hurd Roadmap dream, olafBuddenhagen, 2009/06/16
- Re: A GNU/Hurd Roadmap dream, Arne Babenhauserheide, 2009/06/16
- System stability (was: A GNU/Hurd Roadmap dream), olafBuddenhagen, 2009/06/16
- Re: System stability (was: A GNU/Hurd Roadmap dream), Arne Babenhauserheide, 2009/06/16
- Re: System stability,
olafBuddenhagen <=
- Re: System stability, Arne Babenhauserheide, 2009/06/30
Re: A GNU/Hurd Roadmap dream, olafBuddenhagen, 2009/06/09