diff options
Diffstat (limited to 'hurd/status.mdwn')
| -rw-r--r-- | hurd/status.mdwn | 73 |
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 [...]. |