[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A GNU/Hurd Roadmap dream

From: Arne Babenhauserheide
Subject: Re: A GNU/Hurd Roadmap dream
Date: Wed, 10 Jun 2009 19:50:39 +0200
User-agent: KMail/1.11.4 (Linux/2.6.29-hh2; KDE/4.2.4; x86_64; ; )

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. 

We'd have to keep it up to date whenever something improves, though. 

But I think it would be a great way to keep track of usability progress to 
just add comments everytime one of the problem areas get improved. 

> While I have learned to work around many of these issues, I don't
> believe I would be able to use it as my primary system, without having a
> GNU/Linux system running in parallel, as a fallback for all the stuff
> that doesn't work on the Hurd.
> (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 hope that other people will fill the gaps I leave :) 

> 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? 

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

This fragility does sound like it would make the Hurd completely unusable in 
most situations, 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. 

Is it possible to do it with not too much effort? 
Then bug fixing would give much higher benefits (actually having the goal of 
getting a noncrashing system)

Best wishes, 

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]