summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2009-06-12 14:36:36 +0200
committerThomas Schwinge <tschwinge@gnu.org>2009-06-12 14:36:36 +0200
commit017bc841c14053299e92504ab121af9df52b7eaa (patch)
treeea780dd40ce5dcec9dae3cb8f15d0cb9f78625f0 /hurd
parent5b98aca709481099d89065ce2558ddd764fbcbc8 (diff)
Formatting.
Diffstat (limited to 'hurd')
-rw-r--r--hurd/status.mdwn73
1 files changed, 37 insertions, 36 deletions
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index 5a121937..19b2889f 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,38 +60,39 @@ 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.
-
-[...]
-
-[But] unlike a few years back [...] the system is stable enough under load nowadays [...].
+## Usability Reports
+
+### Olaf Buddenhagen, 2009-06-11
+
+> 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.
+>
+> [...]
+>
+> [But] unlike a few years back [...] the system is stable enough under
+> load nowadays [...].