A lot of pain, bugs and dissapointment in an attempt to get a functional desktop

unix-enjoyer at tilde.institute unix-enjoyer at tilde.institute
Mon Nov 21 09:09:16 PST 2022


Hello. I decided to try out DragonflyBSD as a desktop system, and had a
lot of problems. If you want to know why I decided to try Dragonfly
specifically, read the next paragraph, otherwise, skip.
Windows is not an answer for me because the last reasonable version was
7. After that, the design was unbearable. 7 is now unsupported by most
software. Besides, I'm not willing to fight proprietary software anymore
after I learned about Linux. Linux distributions also have a share of
design problems, which led to me switching from Linux Mint to Debian,
Garuda and finally Void. What happened in all cases: my programs just
broke after unfortunate package management. I wasn't surprised since I
knew that most of this code was not written to be good and stable. It
was to get paid by Redhat/Google/Microsoft/any other corporate Linux
contributor. By that point I was sick of the same corporations that
control Windows controlling my Linux boxes and decided to trade Wine and
inconsistent Linux interfaces for security, cli minimalism, stability
and documentation of OpenBSD. It works just fine. I was a little sad
that virtualisation is limited to single-core with serial console.
FreeBSD also looked like an interesting alternative, though I have heard
horror stories about desktop usage + I'm paranoid about OpenSSL
security, in light of Heartbleed and this recent bug which also affects
everybody. Once I learned more about Dragonfly, I figured that this
might just be a perfect fit for my usecase. I live in an area where
short power outages just happen, and you have to cope with it. Hence why
I use an additional battery-powered power supply just in case. However,
my main PC power supply  sometimes fails, soon to be replaced. The
usefulness of CoW hammer2 (or ZFS/btrfs/bcachefs on Linux) is obvious.
Program snapshots would allow me to put simple programs like mupdf to
disk to easily continue my reading/watching/editing session when I want
to. I tend to prefer very basic programs after all of the bad experience
I had with complicated ones. Virtualisation will allow me to play some
of my favourite games, I'm not interested in AAA. A little sad that Wine
isn't ported yet, but not a big deal. LibreSSL in base provides at least
some network security, even though ports still use OpenSSL (surprised
that ravenports have an option of compiling everything with LibreSSL).
So, what's up with the title?
I have two devices I tried Dragonfly on. Both attempts failed to meet my
requirements of being a stable desktop. A reasonably good browser that
doesn't spy on me like chromium or default firefox, mpv video player, a
terminal emulator, and a vis text editor is all I need for my everyday
existense. I prefer vis to (neo)vim or regular vi because it's just much
less complicated for me to use. Structular regular expressions are more
comfortable than macros for me. Anyway, let's start with the first
attempt, which I assumed to be a success at first.
Dell Inspiron 3542 with 2 core Haswell Pentium 1.4 GHz, 4GB RAM,
1366x768 IPS screen (replacement for the old dead one), 128 GB SSD in
the main slot + 512 GB HDD on rails in the CD slot. No dGPU, dead
battery.
The installation went ok. Although the installer is not very flexible,
e.g. I had to mount my HDD in my home directory after installation, but
that's a non-issue for me.
1. Docs (https://www.dragonflybsd.org/docs/handbook/X/) don't explain
that I need to install and enable appropriate graphics drivers in
/etc/rc.conf (the "outdated" page does half of the job, explaining the
need for installing drivers, but failing to mention rc config
https://www.dragonflybsd.org/docs/how_to_get_to_the_desktop/#index7h3).
They also don't explain how to enable mouse, and that my user should be
in the video group. They don't point me to the appropriate manpages or
FreeBSD documentation.
2. At least both the touchpad and the built-in (PS/2?) keyboard worked.
However, USB mouse & keyboard didn't work in Xorg regardless of moused,
devd, or udevd being enabled. In console, USB keyboard works just fine,
however.
3. Xorg has a long startup (about 5-8 seconds). I stare on a black
screen for a while instead of doing something. I still have no idea why
this is the case. I see no error messages in logs.
4. I can't switch to the console with the usual Ctrl+Alt+n, where n is
the tty I wish to switch to.
5. Qutebrowser starts slowing down after one or two restarts, and
crashes randomly.
6. Netsurf browser crashes when I go into Edit/Settings.
7. Otter browser crashes for unknown reasons.
8. xterm starts slowing down after restarts.
9. htop reports wrong cpu usage. Over 9000% wrong, actually. It was
pretty amusing to watch, but it doesn't provide any useful information
now that the percentages are screwed.
10. Something I don't understand in BSD's is why the vis(1) program
needs to be on my hard drive and not in ports. Not a big deal, it's one
rm command away from being fixed for me.
11. So I tried to compile vis-the-editor
(https://github.com/martanne/vis) from source. It failed to find curses
even though ncurses was explicitly installed. So I built it without
curses. I receive a lot of epileptic flashing when I edit anything in
xterm, but overall the program works ok.
After declaring the initial testing on this laptop a relative success
(at the time I thought I fixed qutebrowser by fiddling with it's config
file), I decided to install Dragonfly on my main PC: Intel Ivybridge
Xeon, 4 cores/8 threads, 12 GB RAM, Radeon RX 580, 512 GB SSD + 1 TB
HDD, 2 1920x1080 displays.
1. In console, USB keyboard worked fine. When I later tried my PS/2
keyboard, it could only produce some weird sequences (^A, >, etc.) and
nothing more.
2. Xorg said no. No matter what input device I try, nothing can be used
in Xorg. At first I thought that it just hangs my GPU, but no, that
wasn't the case. Tried cwm and wmii, and noticed that in wmii, the panel
still displays stats and time in realtime, so that's how I know. 
3. Wayland is unusable on both devices. It stays there (just like Xorg
the first few seconds), but can't start due to some DRM error I can't
catch because it doesn't go into stderr, so redirecting it to a file is
not possible. I suppose I could record the process, but I have to have a
stable desktop to do it first, right? Tried hikari and wayfire.
4. Arcan is outdated and also unusable on both devices. The issue seems
similar to Wayland. I would prefer to use Arcan over Wayland & Xorg if
it worked. It looks like future technology to me. I think embracing the
project might even help with some of your code bounties. Later about
that.
After experiencing these problems (which forced me to poweroff with a
button on my motherboard an uncomfortable amount of times) I decided to
compile my own kernel & packages from dports.
Kernel upgrade worked fine, and changed nothing. I can post my config if
you're interested.
1. When compiling Dports in console, packages have broken menus that
hide options. You have to press arrow keys to inspect all of the options
because they get crammed in one tiny spot, and long descriptions can't
be read. Sometimes the issue resolves itself and packages display their
options properly, but most of the time it's broken and unreadable.
2. Searching for a particular port proved tedious. On OpenBSD, it was as
simple as "make search".
3. No matter what I tried to compile, be it xorg, wayland or arcan, I
had to rmconfig-recursive because something broke. Is there a better way
of handling my unfortunate choices? Reconfiguring my stuff every time is
very tedious and a lot of packages tend to break.
With no luck in dports, I tried ravenports.
The docs are not finished, I get it, but the help command + quickstart
guide were sufficient to figure out basic usage. 
1. The last pre-built image I was able to find for ravenadm is for
Dragonfly 5.8. 
2. When I try to compile any package with ravenadm build, only the error
message about needing to rebuild ravenadm or update the ravenports
package pops up. 
3. So I decided to build ravenports from source. And... I can't do that
because gnat is not available in repos. I am stuck. I have to compile
gnat, but since gnat requires an older version of gnat to work, I can't
compile it.
I suspect that building stuff with llvm might resolve some of my
compilation problems, a more modern compiler ~ better compatibility,
especially with freebsd ports which are compiled with clang after all.
After getting angry at constantly crashing browsers, extremely slow
xterm and epileptic editor, I switched my laptop back to OpenBSD and
currently write this email on it.
I have some questions:
1. Why an outdated gcc instead of a recent llvm in base? gcc 8.5 was
discontinued a year ago, and you use 8.3. llvm is not that big of an
improvement in terms of code size (still millions of loc), but it is an
improvement in design and licensing compared to historical inconsistency
of gcc. I suspect that at least some of my problems come from outdated
toolchain which you use for unknown reasons.
2. Would it be possible to compile ravenports with clang, flang and
gnat-llvm? The only reason I think it will fail is, again, a lack of
gnat for gnat-llvm. Also,
https://sourceforge.net/projects/hacadacompiler/ might be of use to
you... if you have an ada compiler. It's under an MIT license and might
work too, I guess.
3. Is tcplay dead or just resting? Last update on github was 2.5 years
ago. I would be interested in TrueCrypt compatibility mentioned on your
website, some of those crypto algorithms seem to hold up well enough for
decades.
4. nouveau port anytime soon? I don't know why only NetBSD bothered to
do it out of all BSD's, users of old-ish nvidia cards are still common
in desktop space, at least.
5. tickless kernel anytime soon? energy efficiency suffers, performance
in virtualisation also suffers.
While waiting for my -j1 llvm15 compilation to fail, I skimmed through
your code bounties, and have some suggestions:
1. usb webcam support & utf8 in console
both of those are solved in Arcan. See Arcan console
(https://arcan-fe.com/2018/10/31/walkthrough-writing-a-kmscon-console-like-window-manager-using-arcan/)
and libuvc, Arcan's dependency (https://github.com/libuvc/libuvc).
Durden (http://durden.arcan-fe.com/) is able to emulate the behaviour of
most traditional desktop environments. Pipeworld
(https://arcan-fe.com/2021/04/12/introducing-pipeworld/) is a
spreadsheet-shell-like zoomable window manager. Safespaces
(https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr-desktop/)
is a 3D & VR environment. These are lua scripts wrapped around an engine
developed for 15+ years. Letoram (main developer) is very interested in
userspace drivers, and already implemented cross-platform VR,
streamdeck(https://arcan-fe.com/2019/10/30/interfacing-with-a-stream-deck-device/), and USB video drivers. Arcan provides a stable alternative to Xorg and Wayland while keeping compatibility with them through arcan-wayland and
xarcan. What I want to say is that there is an intersection between your
goals and Arcan:
- Migration of drivers to userspace
- Plan 9-like namespaces with your nullfs union mounting & remote
  hammer2 mounting, Arcan's network transparency, cfgfs & durden
  filesystem menu
  - Compatibility through virtualisation with nvmm, arcan's qemu
    frontend, arcan-wayland, xarcan.
    An interesting sidenote: the first desktop environment for Arcan was
    influenced by Amiga's UI (scroll to the bottom of
    https://arcan-fe.com/videos/). You all know what Dillon was working
    on in the 80's.
    Both you and Arcan might benefit from cooperation, and you certainly
    have similarities.

2. userspace vkernel on other os's
    cosmopolitan libc (https://github.com/jart/cosmopolitan) allows C to
    run on unices & windows. The amount of implemented syscalls is
    limited, but I think that's the best option you have right now.
    3. reducing boot time
    I suggest to move on from single-core synchronious rc boot scripts
    to an asynchronius service manager: s6-rc
    (https://www.skarnet.org/software/s6-rc/). It starts services in
    parallel instead of one after another. It provides dependency
    management in case some services depend on others. It does not wake
    up every couple of seconds, so energy efficiency should increase
    too. Service scripts can be written in any scripting language, so
    migration shouldn't be a problem for anybody who still uses shell
    scripts instead of systemd.
    The rest of skarnet.org software might be of interest to you if you
    ever needed secure implementations of network utilities,
    non-interactive alternative to /bin/sh, small portable unix-ish
    utilities, or a portable systems programming C library that doesn't
    suck as much as others do.
    That's all, I wait for help & answers. I can transfer whatever logs
    you need using USB flash. I would like to have a functional
    DragonflyBSD desktop on my main PC, but if it's not possible, I will
    move on with my life.


More information about the Users mailing list