summaryrefslogtreecommitdiff
path: root/hurd/status.mdwn
diff options
context:
space:
mode:
authorArne Babenhauserheide <arne_bab@web.de>2009-06-16 21:35:22 +0200
committerArne Babenhauserheide <arne_bab@web.de>2009-06-16 21:35:22 +0200
commit8da018fafbaa48a65b757d9bce29a316d722619e (patch)
treef6491e7d6c1033a3bf62cbf4adb30eb7ab9ab4ec /hurd/status.mdwn
parentf85d8d27a530e75fb91ade0ef464486def092cf3 (diff)
parentcc989b7700a472d2f65e7fcf6c24acdfe541dd1d (diff)
fix merge
Diffstat (limited to 'hurd/status.mdwn')
-rw-r--r--hurd/status.mdwn81
1 files changed, 41 insertions, 40 deletions
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index cc303dc..3ee8ddc 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2009 Free Software
+Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -60,42 +60,43 @@ 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.
-
-My everyday work includes reading/writing email and other texts, preparing and giving
-presentations, text-mode web browsing, viewing pictures, IRC, reading
-PDF documents, programming, and various other random stuff...
-
-[...]
-
-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.
-
-[...]
-
-[But] unlike a few years back [...] the system is stable enough under load nowadays [...].
+## Usability Reports
+
+### Olaf Buddenhagen, 2009-06-09
+
+> 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.
+>
+> My everyday work includes reading/writing email and other texts, preparing and giving
+> presentations, text-mode web browsing, viewing pictures, IRC, reading
+> PDF documents, programming, and various other random stuff...
+>
+> [...]
+>
+> 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.
+>
+> [...]
+>
+> [But] unlike a few years back [...] the system is stable enough under
+> load nowadays [...].