Hey Hurd people!
I've been using Emacs for so long, that I forget sometimes that it is
a little clunky to use. C-y is paste? C-x is NOT to cut text? What!?
I love Emacs, but it is a little odd sometimes. In a similiar vein, I
wanted to record some of the "papercuts" that using the Hurd currently
has, before I forget what the issues are. Please do not take these
things as me saying the "Hurd sucks". Rather, these are minor issues,
with maybe simple fixes.
- syncfs vs. sync -> Until syncfs' functionality can be merged into
sync, maybe we should link sync to syncfs ?
- Upgrade issues:
- When I used the stable release of Debian GNU/Linux, I used command
this to upgrade:
` # apt update`
` # apt upgrade`.
But the Hurd recommends to [use this update
command](https://www.debian.org/ports/hurd/hurd-install):
```
# apt upgrade --without-new-pkgs
# apt full-upgrade
```
Perhaps, this is the upgrade command that one should use when
using the unstable Debian release? I have a hard time remembering
the above command, so I define the alias "update" for it. Maybe we
should define such an 'update' alias by default?
- When I choose to upgrade the Hurd after starting i3, I patiently
wait for the upgrade to finish. I do not use any other programs
or switch workspaces. When I have done so in the past, many times
the Hurd slowed to a crawl and eventually X locked up on me.
C-Alt-Del did not kill X, even though I have configured it to do
so. I have noticed that if X starts to lock up, then I have 5
seconds to press C-Alt-Del, otherwise C-Alt-Del won't work. I am
using a T43 with 1.5 Gb of RAM, so maybe the hardware with limited
resources is to blame? Though OpenBSD can easily run with that
amount of limited resources (though they make it a goal to support
really old hardware). Sometimes I believe that Hurd has been sooo
slow, that I could not connect to it via ssh and halt it remotely.
How hard would it be to add a GNU Mach specific ["raise the
elephant"? ](https://en.wikipedia.org/wiki/Magic_SysRq_key)
- If the upgrade is major, (I have not upgraded in 2+ months), then
I make sure that I run the upgrade in the Hurd console, which
always works on major. When I have upgraded the Hurd via a
terminal in i3 on a major upgrade, then the Hurd got so busy that
it stopped accepting my keystrokes. C-Alt-Del failed to kill X.
- Lock screen issues (i3 & xlock): sometimes when I am performing an
upgrade patiently waiting and not typing on the keyboard, the X lock
screen will appear and not accept my keystrokes. I will get stuck
on the lock screen...and I will wait several minutes (max 10). At
that point, I hope the update finished, and I force shutoff the
machine. Sometimes I try ssh-ing into the machine to shut off the
Hurd, and that doesn't work.
- One cannot do `# halt` when running X. [This is a known
issue.](https://darnassus.sceen.net/~hurd-web/faq/x-exit/) The last
time that I tried it on the Hurd, the OS did not return me a
console, nor could I switch to another Hurd console. The Hurd was
still running, but was not responding to any keyboard commands. I
should try this again and see if I can ssh into the machine at this
state. Not being able to run `# halt` will confuse the casual user.
So to halt my machine, I still have to kill X, then run `#halt`. I
tried running shutdown-hurd from inside X, as per Samuel's request.
Weirdly enough, after I pressed return on that command, I could
still move the cursor. It took X maybe 5 or so minutes before it
locked up on me and stopped accepting mouse movements. Then I had
to hard shutoff. I believe I still had filesystem corruption that
was fixed on next boot.
- `sudo service networking restart` normally fails. I have to run `#
service networking stop; service networking start; service
networking start` to restart the hurd's networking, since the first
"start" command always fails. It is not the end of the world, that
I have to run the "start command twice, but it is a little
confusing.
- ftpfs doesn't work so well without internet (obviously)
- settrans -c \~/hurd-iso /hurd/iso9660fs
$HOME/ftp://ftp.someftpserver.org/img.iso
- Often times I will be working offline editing the wiki, and I will
type `ls ~/`, which will take one minute to list the directory
contents. C-c, works but really slowly (30 second lag). It would
be nice if during ftpfs startup, it could check if the Hurd has an
active internet connection. If the IP address is 0.0.0.0 maybe
that means no internet?
- Starting X issue: This one took me a while to figure out. The Hurd
automatically runs fsck on your filesystems at boot, and it fixes
all issues without user intervention! BUT sometimes it is unable to
automatically rid the filesystem of corruption, and the Hurd will
mount your filesystem/s readonly. When this happens, X will fail to
start, because X needs to write some temporariy file in ~/ ...?
Some type of socket or something? Anyway, I have this poorly
written script in my `.bashrc` to work around this issue:
# tell me if / or /home are writeable or not
myroot=$(fsysopts / | awk '{ print $2 }')
myroot=${myroot:2}
myhome=$(fsysopts /home | awk '{ print $2 }')
myhome=${myhome:2}
mytty=$(tty)
mytty=${mytty:0:9}
# autostart X if this is tty1 and / and /home are writable
if [[ $myhome == $myroot && $myhome == "writable" && $mytty == "/dev/tty1" ]];
then
eval `ssh-agent -s`
ssh-add
startx;
else
echo "/ is $myroot.";
echo "/home is $myhome";
echo "tty is $mytty.";
echo "NOT starting X.";
fi
- Using the Hurd in qemu: I personally find that the Hurd is far more
reliable to use on real hardware. So I no longer use the Hurd via
qemu. I believe that the reason that I found it hard to use, was
that the Hurd would "lock up" in qemu, I would then kill qemu, which
would cause filesystem corruption. (Yes users should try to ssh
into the Hurd and kill it that way, but sometimes that won't work
either). Upon rebooting the Hurd in qemu, most of the time, the
auto fsck worked. BUT sometimes, it failed and mounted things
readonly. So I would be confused when apt failed to work. At the
time I did not know that users may need to manually fsck the Hurd's
filesystem from GNU/Linux with lose2up (is that the right command?).
I still don't know how to reliable fsck the Hurd via lose2up.
Perhaps we could write a script, that would automatically use
lose2up to fsck the filesystem, before starting it in qemu.
Thoughts?
Joshua
--
Joshua Branson
Sent from the Hurd
