summaryrefslogtreecommitdiff
path: root/hurd/status.mdwn
diff options
context:
space:
mode:
authorArne Babenhauserheide <arne_bab@web.de>2009-06-12 12:59:55 +0200
committerArne Babenhauserheide <arne_bab@web.de>2009-06-12 12:59:55 +0200
commit46cab2ba91659d8569d31d05dab3fcc1f6551a47 (patch)
tree0acf56283d7af4d2645916059cb65816a9339022 /hurd/status.mdwn
parentd38cdb58180e61e1e4184b3c2fcaa34527d48bb6 (diff)
status: Added antriks statement about his experience during the last two years.
Diffstat (limited to 'hurd/status.mdwn')
-rw-r--r--hurd/status.mdwn37
1 files changed, 37 insertions, 0 deletions
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index 1122b70..8b95534 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -60,4 +60,41 @@ already expect delays; to disappoint them in this way as
well would be unfortunate. Moreover, it would lessen the
possibility that they would want to try the Hurd again in the future.
+## Usability status 2009-06-11
+*(This text is taken from two emails posted on the [[bug-hurd mailinglist|mailing_lists]]
+by Olaf Buddenhagen)*
+
+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
+situations.
+
+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.
+
+[...]
+
+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.
+
+[...]
+
+Anyways, if you want to revive the Gentoo GNU/Hurd port, that would be
+great! Unlike a few years back when it was first attempted, the system
+is stable enough under load nowadays, to make a source-based
+distribution actually feasible...