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

Fwd: Installing latest hurd



I sent this privately to Samuel and he suggested to me that I ought to
be sending things like this to the list, hence this message. Samuel
did respond to me concerning the issues I raised here, but I will
leave it to him to decide whether he wants to forward his response to
the list.

/Don Allen


---------- Forwarded message ----------
From: Donald Allen <donaldcallen@gmail.com>
Date: Sun, Aug 25, 2013 at 10:27 AM
Subject: Re: Installing latest hurd
To: Samuel Thibault <samuel.thibault@gnu.org>


Samuel --

I got the contents of my home directory rsync-ed to the G41 running
the Hurd. This brought up the first problem. This machine, while circa
2005, has a 3+ Ghz processor, 2Gb of memory and a 7200 rpm disk. While
not a speed-demon by today's standards (the 3 Ghz is a bit deceiving,
since it's an old Intel Xeon processor, which does not get as much
work done per clock tick as the newer Intel processors; as I recall,
the issue is that one of the pipelines is too deep, so a lot of work
can get wasted when doing speculative processing of conditionals), its
performance is perfectly adequate running Linux or Windows. I have run
Linux on this machine for years (it was my primary machine for a good
while when it was new) with an ext2 filesystem (I never used ext3,
because ext2 was noticeably faster and Linux crashes were rare enough
that the fsck time wasn't a problem; I also never lost a filesystem or
a substantial portion therefore, which is theoretically possible with
ext2, though I was and am diligent about backups). Transferring my 13
Gb home directory took hours and this was over 100 Gb ethernet. Doing
the same transfer to a Linux system might take .5 hours, if that. The
disk light was on pretty constantly on the G41, only occasionally on
the source machine, which also has a 7200 rpm disk and is running Arch
with a journal-less ext4 filesystem. My point is that it looks like
the filesystem performance is very poor. Is there a buffer cache? Is
it unified? The disk driver could also be an issue, depending on how
it treats the disk cache.

I managed to get X working (unfortunately, I did a text install, not
pseudo-text; I wish I'd known the implications of that decision at
install time, regarding the need to run the console command; I haven't
reviewed the installation documentation, but if it doesn't discuss
this issue -- it's possible that it does and I missed it -- it
should). I don't use a desktop -- just a window manager (xmonad),
dmenu, rox-filer, and something to provide info in the bar (xmobar).
xmonad and xmobar were available in the repository and seem to work
correctly. dmenu and rox-filer are not available. For this experiment,
I managed without them.

My first priority was a web browser. I installed iceweasel, which
would not start. I got an error that talked about threads (I can be
specific if you need it, though I suspect the project already knows
that firefox/iceweasel doesn't work). I then tried installing midori,
which did come up, but could not display any web pages, claiming it
could not find the sites. Yes, I had entered the addresses of
comcast's dns servers in /etc/resolv.conf and verified that dns was
working by pinging a couple of sites.

And again, anything I did, e.g., starting X and the window manager,
starting midori, was painfully slow.

Now it's true that the Hurd documentation does talk about  the
performance not being as good as Linux, but what I experienced is not
usable, for me, and I doubt for many others. I would like to help with
this -- performance analysis and improvement was a specialty of mine
for many years -- but I am very busy with some things that I must do
for my family. Hopefully this will settle down soon and if and when it
does, perhaps I can devote some time to helping with Hurd.

/Don


Reply to: