OpenBSD on the Desktop (Part I)
paedubucher.ch
paedubucher.ch
But my experience to make it work as a Desktop OS is very poor. Some reasons: The overall performance is way worse than Linux, the ports are not always up-to-date, other OS simulation is also outdated which means running commercial apps will be a challenge, upgrade process from version X to Y can be quiet painful, the lack of support for certain HW and Battery usage on laptops. I could never find anything that i could not do better and more efficient on Linux.
On the positive side: CWM and their Artwork are really cool.
1. No binary blobs, so hardware acceleration can be missed.
2. There have been issues with specific apps e.g. Firefox that seem optimised for things that OpenBSD doesn't do.
3. Historically SMP/Hyperthreading support hasn't been as performant as it is on other platforms. In some cases this is due to prioritising security over performance - e.g. speculative cache execution bugs.
Anyways, my hardware was supported perfectly on all of them, so no problems there. This way FreeBSD was only slightly faster than NetBSD, and i could have 132x60 textmode on its console, which didn't work at the time for NetBSD, and many, many ports of software. But I didn't need them all, and it felt a little more bloated. Since my goal was full desktop with KDE3 I didn't care much about textmode and went with NetBSD.
It flew, rock-solid, unkaputtbar!
While OpenBSD, at the times with the parts of KDE3 which were available for it had unexplainable periodic hiccups, not only during load, but light desktop use when no swap was in use at all!
That felt very weird, and after a few months I discarded it, since other users and developers/contributors of it which I've spoken to in person(sometimes looking at me like I'd be an alien from outer space for using it as desktop) didn't have more to offer than right tool for the job, yadda yadda...
Since then I'm following its progress from afar, only mildly interested. PF and ACKPRI were nice, but at least ACKPRI could be had by other means elsewhere, or some appliance.
So... right tool for the job, I guess?
edit: the hiccups didn't only happen while in X/KDE. Also when no Xserver at all was running, just doing things on the console, also while no swap was in use.
2nd edit: I pivoted to Arch from there, which in direct comparison to the riced NetBSD flew hypersonic, but wasn't as unkaputtbar (though only slightly less so), but saved much compile time :)
The security "track record" isn't really much of a track record when you consider that their only claim pertains to "the default install" which frankly doesn't comprise a very useful set of tools for doing anything other than a router. But if you want a router, there's pfsense.
Anyways. My experience with OpenBSD mirrors yours. It's easy to set up if your desired end state is an X desktop and ethernet networking. 802.11 in OpenBSD is an exercise in patience to say the least, and the last time I looked (admittedly back in 2016 or so) most guides were still recommending wpa_supplicant and config file editing with a straight face.
I'm Canadian, so I really want to like The Little Canadian OS That Could but honestly it's second- or third-best at everything and best-in-class at nothing.
I don't know why a person would reach for OpenBSD in 2020 when Debian exists, except perhaps if you want to enable corporations to make parasitic profits from others' hard work. And even then there's FreeBSD for your playstation and for pfsense, and NetBSD for your toaster.
I dunno, it just seems like they make so much hay out of being secure, but the "secure OS" isn't much of an OS at all in terms of functionality.
That being said, OpenBSD has an excellent installer, amazing docs, and I did run it as a desktop for a while. Went back to Linux because I wanted to play Dwarf Fortress natively of all things. Things don't neccesarily work better with Linux, but I definitely spend less time tinkering now. Which could be a good or a bad thing depending on whom you ask.
If your question is "what options are allowed in rc.conf and what is the syntax?" then your answer is not found in the manual page for rc but from a random Reddit post your Google search brought up.
... which is why you would look at the rc.conf man page for that:
Are you sure that you checked or did you assume that it wasn't there based on you Linux experience?
I still run a couple of dedicated audio workstations on Linux as I need preemptive scheduling (not available on OpenBSD) and Linux drivers.
Why do you think that's true? The GPL just protects you work if someone else wants to re-distribute your code. Look at Google, they can have their own private Gnu/Linux (no i don't talk about android) and never ever have to opensource it.
Quantum Software Systems / QNX :-)
The only reason I am not using OpenBSD for desktop is because it does not have an NVIDIA driver. This has been the case for a very long time. I am not holding my breath for its support, for sure. For servers I use Arch Linux and OpenBSD.
But once the install is done, the experience is...underwhelming. Bare-bones X11 and FVWM. Yikes. That with the xenodm login screen give it a distinct 1992-era experience.
I'm obviously aware I can install full-blown KDE/GNOME but the whole point (to me) of using OpenBSD is to go minimal, using secure and vetted built-ins as much as possible.
If I wanted 500 Gnome packages with potentially thousands of accompanying bugs, well, I'd just run Ubuntu, right?
But I also am too ....impatient? old?....to spend hours tweaking .Xresources and dealing with bitmap fonts and the whole (horrific) 1990's X11 experience.
I just want a default desktop that does NOT look like complete garbage. Make it super optional and put it under the "lame-n00b" option during install. Mock me during setup and tell me to go back to WinDoze. I'll happily take all that abuse just to boot into something that doesn't look like it ran Ross Perot's campaign.
“The recommended way to run X is with the xenodm(1) display manager. It offers some important security benefits over the traditional startx(1) command.“
I think startx now only works if you’re root or have given users additional permissions - xenodm doesn’t require that.
That was the case for a while but in OpenBSD 6.7 startx works again out of the box, as long as you have certain graphics hardware, eg. radeon.
One of the features I find most useful is that you can have a window focused without raising it. So if you have some reference material open in a browser over top of part of your terminal, you can switch focus to and even click in the terminal without raising it (in my setup, I alt-click to raise). Admittedly, I'm not sure if this is the default behavior, as many of my settings are non-default.
I also really like the ability to search through window titles. I have alt+/ set to open the window search menu, then I can type a substring of the window title I want to raise, press return, and it's automatically raised and focused.
CWM is really, really nice, and every other WM I've tried before or since has disappointed me by comparison.
Even Windows used to have a powertoy to enable it on Win32.
Exactly how I used fvwm (the original one) and twm back in the 1994 onwards.
To be raised one needs to additionally click on it.
Like you said, it's great to have a small editor or terminal window floating over a web browser, really makes a lot of things easier.
As a side note, I feel like my workflow has improved in productivity, because I've been forced to think about how I do things, and change, which leads to insight and improvement. I discovered a lot of command line utilities that are more productive than what I was doing on Linux when I used them because they're "pretty".
I installed OpenBSD on an X270 laptop and everything worked incredibly smoothly and cohesively out of the box. Everything from power management to a sensibly-spec'd console font, without hundreds of helper daemons and dbus. The breadth of software in a Linux distribution means it will never be as cohesive as this.
Performance was not as good as Linux. I suspect OpenBSD is just not as heavily optimised in a multi-threaded environment, which is fine and expected.
However I did start to feel OpenBSD losing its way a little. I hoped such a slim system would be good for an automated install which could be used as VMs to run its smtpd, httpd etc. in the same cohesive environment.
But I found myself working against the installer's prompt-driven approach; really I just wanted some shell functions I could run to un-pack a system after partitioning it.
In the process I also discovered the whole "relink the kernel on every boot for security"; actually a blunt approach of shell scripts to rerun the final stage of compilation after booting and copy it into place for next time. 372Mb of disk space is used just for this and removing it requires modification of the OS. Not saying this is wrong, just not right for me at this time and it seemed a missed opportunity in a world of Alpine Linux and the like.
No need to have that uglyness in your face all the time.
Sometimes HN goes a bit too far. Is this technology as a tool to make life easier or better for someone or is this just playing around with esoteric technology with little practically purpose?
> Installing a basic GUI with Suckless software was a rather smooth experience on OpenBSD
Says the person who had to write C code to get a gui working to his liking