[Top][All Lists]

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

Re: A GNU/Hurd Roadmap dream

From: olafBuddenhagen
Subject: Re: A GNU/Hurd Roadmap dream
Date: Tue, 9 Jun 2009 07:19:28 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Wed, Jun 03, 2009 at 10:55:06PM +0200, Arne Babenhauserheide wrote:
> On Wednesday, 3. June 2009 17:41:22 Sergiu Ivanov wrote:

> > Could you please dream how to solve the major drawbacks in Hurd and
> > to make it mainstream? :-)
> Which are the other drawbacks? 
> I don't currently care that much about raw speed. My Linux goes to
> disk speed when it begins heavy swapping because I copy large amount
> of data - or download a torrent... or did until I beat vm.swappiness
> to 20. The Hurd can host a wiki, so why shouldn't it be usable as my
> desktop system? 

Well, there are still lots of stability problems and other bugs... And I
think this is really the major obstacle to serious use.

I have been using the Hurd for most of my everyday work for some two
years now. Most of the time it's pretty OK, but occasionally programs
crash, or the screen session dies, or even the whole system. Also,
various programs simply don't work at all, or don't work in certain

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...)

One particular problem for desktop use is the fact that while X does
work, it works very poorly -- it's not only slow and jerky all the time,
but also tends to lock up completely. (At least with the local socket
transport... Haven't tried whether forcing TCP works better.)

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.


reply via email to

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