The speed of the system is stellar. I feel like it is faster than the Linux and FreeBSD installations, but I don’t have proof of it. I suspect there is less bloat to weight things down and the hardware support for Thinkpads is super in OpenBSD.
I find this rather surprising, because the last time I installed OpenBSD this (or rather the fact that it was too slow) was my main issue. I’m not sure, but as far as I understood this was because of the global kernel lock that inhibits some parallelism, where Linux permits it. Was really shocked me was the difference in time needed for Emacs to start for the first time, it was something like 1-2 seconds on Linux vs 15-20 seconds on OpenBSD.
Was really shocked me was the difference in time needed for Emacs to start for the first time, it was something like 1-2 seconds on Linux vs 15-20 seconds on OpenBSD
Not really certain about much of this and not much of an Emacs user myself, but I recall that Emacs uses some awful build hack where it pre-loads a bunch of stuff (Emacs-lisp macros I guess) and serialises it out by simply writing a chunk of memory out to disk. I vaguely recall that this needed a special Glibc hack to work properly and as a result couldn’t be done on non-Glibc systems. Ultimately I guess what I’m trying to say is, I’m not sure that Emacs launch time is a great benchmark for OS performance generally. (But again, I’m not willing to make any firm claims here).
Hmm, it makes sense. This is the phenomenon you’re mentioning, and all I knew about that and OpenBSD was that they couldn’t compile Emcas to be fully ASLR (?) compatible. But it would make sense that that could slow down the start-up time.
But that didn’t change the general issue, it was just very pronounced when it came to booting Emacs. Anything like opening a file, generating an overview, etc. was noticeably slower, which saddened me, since I like OpenBSD but my primary allegiance is to Emacs :(
You recall correctly. It basically starts from a minimal executable (temacs), loads a bunch of elisp files, and then dumps the resulting memory image out to create what the manual calls a “pure Emacs”:
The command temacs -l loadup would run temacs and direct it to load loadup.el. The loadup library loads additional Lisp libraries, which set up the normal Emacs editing environment. After this step, the Emacs executable is no longer bare.
Because it takes some time to load the standard Lisp files, the temacs executable usually isn’t run directly by users. Instead, as one of the last steps of building Emacs, the command temacs -batch -l loadup dump is run. The special dump argument causes temacs to dump out an executable program, called emacs, which has all the standard Lisp files preloaded. (The -batch argument prevents temacs from trying to initialize any of its data on the terminal, so that the tables of terminal information are empty in the dumped Emacs.)
The dumped emacs executable (also called a pure Emacs) is the one which is installed. The variable preloaded-file-list stores a list of the Lisp files preloaded into the dumped Emacs. If you port Emacs to a new operating system, and are not able to implement dumping, then Emacs must load loadup.el each time it starts.
Emacs on Android - via Termux - has the same issue: it takes more than six seconds to start on my phone, and it loads far more files than what I see on my laptop (or even my netbook, which has a comparable startup time “thanks” to its 2011 Atom CPU and 5400 rpm HDD).
I love OpenBSD but yeah, speed is not it’s strong suit nor the focus of the project. But to me it was always fast enough with the exception of youtube (which I rarely use so things might have changed there)
If I remember correctly, there’s been a lot of development recently to get rid of this. Last I heard the networking stack was being refactored to be lock free, so OpenBSD might be significantly more performant in the near future. Someone who’s more involved with OpenBSD dev would know more…
I have tried OpenBSD on my desktop (and also on an ancient home srver), and it could not replacy Windows on my secondary computer (ThinkPad X200). My problems with OpenBSD are the following (still actively using/evaluating it, and I truly love lots of aspects of the system!):
The problem about binary package updates. I know how it can be done, and I don’t think it is good that way. I can live with this.
Cumbersome contribution. CVS. I know this won’t change anytime soon, and I can live with it, but a more modern PR based workflow would lower the barrier of contribution. I believe that this secret sect mentality (pervasive in the whole BSD world IMHO) counterproductive for the projects.I can live with this.
Disklabel. It should die now. LVM or actually anything would be better. This is a minor annoyance, as I don’t interact with it too often though. I can live with this.
FFS. At least one modern FS would be nice. Some true believers keep saying HAMMER2 will get imported eventually. I truly hope so, as it is very promising. I can live with this.
Some security features are smoke and mirrors in their current form. Especially W^X annoys me: I cannot develop Python on home unless I add wxallowed˛ to mount options, which actually disables the security feature. I wonder if it will ever be properly supported over relevant ports, or is my usecase so special, that I want to do development in my home directory, and I should need a separate /unscure-python-develoment mountpoint for it? I can live with this.
It is slow. It was slow for me, on old hardware. The IO drivers downgraded the OHCI and IDE drives to PIO Mode 1… 1,5 MB/s. (I was triing to salvage data from an old machine) Then I rebooted with Ubuntu, and everything ran 20-40MB/s. On the my old ThinkPad X200 I also found it slower than expected. I can live with this, as that machine is likely going to scrap.
something around the dynamic loader is terribly slow. smbd startup on the ancient machine I needed to get data off from is 3 minutes. I tried it with ubuntu on the same machine, and it is matter of seconds. Others have reported similar problems about libreoffice. The performance problems I have seen on the ThinkPad may very well rooted in this, as I tried to use Firefox, ThunderBird, Libreoffice mostly, in addition to vim, and usual UNIX cli stuff. I can either live with this, or give it a shot to improve on. I might learn a thing or two about implementation of a loader.
certain ports are missing, which are important for me. I have digged into porting them myself, but I’m not sure I’ll ever get to implement them. One is Telegram Desktop. Other is Visual Studio Code. Third is GlusterFS. Fourth is TrueCrypt. The first is doable IMHO, the second is harder nut to crack. The third… I have no idea. Fourth: also no idea, but I cannot find a portable encrypted volume tool between Windows, Linux and OpenBSD. This together are a showstopper for me to migrate my desktop to OpenBSD. These are showstoppers (gluster on server, other on desktop).
I had stability isues with the iwn driver, it kept crashing at a specific point, cauing data loss on FFS drives. After a point fw-update updated the inter wireless firmware, and have not encountered the problem ever since, so this is not a bug in OpenBSD networking code. (I have some debug data saved, if it comes back I’ll try to fix it.) I can live with this, or give it a shot, and it is likely it would get fixed soon anyway.
On the other hand I really like to simple and uniform, polished and well documented feeling around lots of system tools. The network stack I especially liked! The trunk driver totally impressed me with its simplicity and usefulness from an admin point of view. The docs are pretty good, actually I think it is the best documentation I have seen, second to this is NetBSD. Third are some GNU core tools I love (make and awk). The docs are up to date (only found one tiny outdated info, I think, almost irrelevant, will report it). On IRC the community was supportive, though not totally beginner friendly, which was not a problem for me, as I’m experienced Linux, and NetBSD user.
I guess it is not fit for my usecases right now, but I’ll keep on evaluating it, as I really want to believe.
To be honest I have some irrational aversion to FreeBSD. If I analyze myself it is because a person who I got along really badly with, but had to tolerate him, was an aggressive and rude advocate of FreeBSD. I’ll try to come over this and try it sometime, as I have some freetime currently, and this of course has nothing to do with FreeBSD project of software itself.
Some security features are smoke and mirrors in their current form. Especially W^X annoys me: I cannot develop Python on home unless I add wxallowed˛ to mount options, which actually disables the security feature.
You still get most of the benefits even without wxallowed. For W|X mappings, OpenBSD requires both of the following conditions to hold:
The executable is on a wxallowed partition
The executable was linked with the -z wxneeded flag
Thanks, I tried a snapshot, and 4+ minutes startup time shrinked to 2 seconds on the ancient Atom machine. Also I have seen some newer versions of some ports, which are pomising to get VeraCrypt compiled for example… I’ll continue my evaluation of OpenBSD, as I have very good experience with it with regards to issues being solved/acted upon quickly.
I use qemu on OpenBSD to run Linux, Windows (admittedly it’s Windows XP :~/), sortix and other virtual machines - I don’t know how it compares to virtualbox but it works well.
In my experience (as an OS programmer), VirtualBox is very buggy and unreliable. QEMU/KVM is much better, indeed. (OpenBSD’s native hypervisor will likely eventually be ready for prime time here, if it isn’t already.)
Depends a little if you for example use Vagrant and then VirtualBox might be a lot more handy. In my last job I gave up being the only person with lxc images because everyone else was on mac+virtualbox, so I had to relent.
If your guests are Linux or Windows, it’s well-polished and stable. If your guests are anything else (especially if you’re doing active OS dev on the guest!), I imagine you’ll find holes in short order.
As others have suggested, vmd is your friend here.
While not perfect in terms of speed, I managed to completely get rid of linux @work as a main system.
Now I just fire up an ubuntu instance (to be able to install it you need to make the image boot in console mode, nothing too hard) with x2go-server installed. Using x2go-client, I fire up emacs and I’m set.
Other (+) points (for me at least):
the ability to just test on the fly an older release. Just a vmctl start <vm-name> away!
as some days I work remotely, there’s no need to ‘pollute’ my base installation with stuff I do not need (php, a web server, the whole npm ecosystem, etc)
Of course all the above are dependent to one’s needs. :)
Using the aforementioned work flow, I truly do not care if the vm breaks; and if it does, I just copy my backup image and I’m set. :)
Most likely no, as X is a huge pile of code, and OpenBSD is not so large. It is more rational and economical, to add a shim to be able to run Wayland, and move on along with the rest of the world.
In general, you don’t expose X11 sockets on the internet any more. They’re unix domain sockets in /etc/X11/. Remote X is tunneled over SSH.
The insecurity that people tend to complain about in X11 comes from any window (such as a web browser) being able to look at the resources like clipboard contents of other windows run by the same user.
Besides apps being able to look at each others’ stuff, X11 is also a perennial source of privilege-escalation bugs, because some of it needs to run SUID, and it’s a large pile of old, mostly un-audited code. E.g. a recent example that affected OpenBSD.
I’m no expert in X, but I have the same impressions. As we all nkow if security is an afterthought it is usually far more expensive to add to a system, if possible at all. Given RedHat’s reluctance to further support the project it can be called dead.
It has been in maintenance mode at least for 5 years now. Also, when I tried to configure X recently it hurt so badly, I had to give it up, and I’ll be happy when it will be gone. (No config file, but autodetection is the thing now, but you can override parts, but you need to know what would be in the config file, but you cannot get a dump of the config file as understood by the server… it was PITA. I wanted to tweak some input preferences, but it hurt so badly I gave up.)
I understand the impetus to start using X in Linux, because it was there and it worked and it enabled graphical interfaces “out of the box”. But it’s woefully behind the times now, and a lot of its complexity is tied to an obsolete use case (running windows remotely on more powerful machines).
With that said I haven’t really followed the debate around its replacement(s). My Linux use is almost all command-line based nowadays.
and a lot of its complexity is tied to an obsolete use case
I don’t think that’s true. Remote windows are not particularly complex – the bulk of the complexity comes from a woefully misdesigned font and keyboard handling architecture, and a protocol that wasn’t particularly designed, and as a result is an incredible mess of special cases to parse and handle correctly.
Sure, I totally agree. Now with Wayland in the works hopefully stuff will get done soon. To be honest a session migration between remote and local terminals in the sense Windows RDP offers it would be pretty nice. Sometimes I find is useful.
The one reason I switched from OpenBSD to Void Linux is my Nim and Love2d usage. If it weren’t for those being unmaintained (and hard to compile) I’d be back in a flash
I haven’t tried a BSD in many years. I went just now to look for some OpenBSD packages (ports) for software that I often use. As expected, there are ports for the super-popular things like Firefox, Chromium, Thunderbird. I regularly work with audio, video and graphics/images. There are ports for kdenlive and audacity, and that’s nice, but notably absent are ardour and GIMP, and that’s pretty much showstopping for me.
Ardour might indeed be something missing but might not be too hard to package or port over.
GIMP is packaged, stable and regularly updated on OpenBSD, I use it often :)
Having said that I am not entirely sure how workable Ardour would be or how well can OpenBSD perform in the low-latency/realtime needs music/sound editing has. But I also don’t have active knowledge on this dept so might be wrong.
huh… you are right… might have been confused with another Graphic suit package or seen a dept update and not realize it wasn’t the base package as well.
2.8 has been very workable and stable for me, now I am wondering why 2.10 ain’t there… might either be orphaned or there might be a blocker 🤔
I find this rather surprising, because the last time I installed OpenBSD this (or rather the fact that it was too slow) was my main issue. I’m not sure, but as far as I understood this was because of the global kernel lock that inhibits some parallelism, where Linux permits it. Was really shocked me was the difference in time needed for Emacs to start for the first time, it was something like 1-2 seconds on Linux vs 15-20 seconds on OpenBSD.
Not really certain about much of this and not much of an Emacs user myself, but I recall that Emacs uses some awful build hack where it pre-loads a bunch of stuff (Emacs-lisp macros I guess) and serialises it out by simply writing a chunk of memory out to disk. I vaguely recall that this needed a special Glibc hack to work properly and as a result couldn’t be done on non-Glibc systems. Ultimately I guess what I’m trying to say is, I’m not sure that Emacs launch time is a great benchmark for OS performance generally. (But again, I’m not willing to make any firm claims here).
Everyone knows Emacs stands for “Eight megabytes and constantly swapping”…
Hmm, it makes sense. This is the phenomenon you’re mentioning, and all I knew about that and OpenBSD was that they couldn’t compile Emcas to be fully ASLR (?) compatible. But it would make sense that that could slow down the start-up time.
But that didn’t change the general issue, it was just very pronounced when it came to booting Emacs. Anything like opening a file, generating an overview, etc. was noticeably slower, which saddened me, since I like OpenBSD but my primary allegiance is to Emacs :(
You recall correctly. It basically starts from a minimal executable (
temacs), loads a bunch of elisp files, and then dumps the resulting memory image out to create what the manual calls a “pure Emacs”:Emacs on Android - via Termux - has the same issue: it takes more than six seconds to start on my phone, and it loads far more files than what I see on my laptop (or even my netbook, which has a comparable startup time “thanks” to its 2011 Atom CPU and 5400 rpm HDD).
I love OpenBSD but yeah, speed is not it’s strong suit nor the focus of the project. But to me it was always fast enough with the exception of youtube (which I rarely use so things might have changed there)
If I remember correctly, there’s been a lot of development recently to get rid of this. Last I heard the networking stack was being refactored to be lock free, so OpenBSD might be significantly more performant in the near future. Someone who’s more involved with OpenBSD dev would know more…
That would most certainly be nice to see!
I have tried OpenBSD on my desktop (and also on an ancient home srver), and it could not replacy Windows on my secondary computer (ThinkPad X200). My problems with OpenBSD are the following (still actively using/evaluating it, and I truly love lots of aspects of the system!):
wxallowed˛to mount options, which actually disables the security feature. I wonder if it will ever be properly supported over relevant ports, or is my usecase so special, that I want to do development in my home directory, and I should need a separate /unscure-python-develoment mountpoint for it? I can live with this.On the other hand I really like to simple and uniform, polished and well documented feeling around lots of system tools. The network stack I especially liked! The trunk driver totally impressed me with its simplicity and usefulness from an admin point of view. The docs are pretty good, actually I think it is the best documentation I have seen, second to this is NetBSD. Third are some GNU core tools I love (make and awk). The docs are up to date (only found one tiny outdated info, I think, almost irrelevant, will report it). On IRC the community was supportive, though not totally beginner friendly, which was not a problem for me, as I’m experienced Linux, and NetBSD user.
I guess it is not fit for my usecases right now, but I’ll keep on evaluating it, as I really want to believe.
We have them all on FreeBSD :)
Yes, even VSCode is possible, a version of Electron was added to ports recently. (code-server sounds like a better idea though — use an existing browser instead of a new chromium instance)
Also: s/TrueCrypt/VeraCrypt. TC is extremely dead.
Nice! Thanks for the info.
To be honest I have some irrational aversion to FreeBSD. If I analyze myself it is because a person who I got along really badly with, but had to tolerate him, was an aggressive and rude advocate of FreeBSD. I’ll try to come over this and try it sometime, as I have some freetime currently, and this of course has nothing to do with FreeBSD project of software itself.
You still get most of the benefits even without wxallowed. For W|X mappings, OpenBSD requires both of the following conditions to hold:
wxallowedpartition-z wxneededflagThere is a patch to resolve the slowness in ld.so, specifically for smbd actually. Should be applied at some point.
Thanks, I tried a snapshot, and 4+ minutes startup time shrinked to 2 seconds on the ancient Atom machine. Also I have seen some newer versions of some ports, which are pomising to get VeraCrypt compiled for example… I’ll continue my evaluation of OpenBSD, as I have very good experience with it with regards to issues being solved/acted upon quickly.
no virtualbox is a handicap
I use qemu on OpenBSD to run Linux, Windows (admittedly it’s Windows XP :~/), sortix and other virtual machines - I don’t know how it compares to virtualbox but it works well.
In my experience (as an OS programmer), VirtualBox is very buggy and unreliable. QEMU/KVM is much better, indeed. (OpenBSD’s native hypervisor will likely eventually be ready for prime time here, if it isn’t already.)
vmm(4) is already great at running OpenBSD virtual images - but I’ve not tested it with other OS yet - it’s on my todo list
Depends a little if you for example use Vagrant and then VirtualBox might be a lot more handy. In my last job I gave up being the only person with lxc images because everyone else was on mac+virtualbox, so I had to relent.
I have the exact opposite experience. I have been using VBox for many years on Linux and MacOS and it is very reliable.
If your guests are Linux or Windows, it’s well-polished and stable. If your guests are anything else (especially if you’re doing active OS dev on the guest!), I imagine you’ll find holes in short order.
Except OpenBSD doesn’t have KVM, but its own VMM. You’re stuck with TCG for QEMU.
As others have suggested, vmd is your friend here.
While not perfect in terms of speed, I managed to completely get rid of linux @work as a main system.
Now I just fire up an ubuntu instance (to be able to install it you need to make the image boot in console mode, nothing too hard) with x2go-server installed. Using x2go-client, I fire up emacs and I’m set.
Other (+) points (for me at least):
vmctl start <vm-name>away!Of course all the above are dependent to one’s needs. :)
Using the aforementioned work flow, I truly do not care if the vm breaks; and if it does, I just copy my backup image and I’m set. :)
[edited for grammar]
I wonder if OpenBSD will pick up the X development work now that RedHat is dropping it.
Most likely no, as X is a huge pile of code, and OpenBSD is not so large. It is more rational and economical, to add a shim to be able to run Wayland, and move on along with the rest of the world.
Isn’t X notoriously insecure? I seem to remember issues with unencrypted tokens being slung around so one could launch windows on other machines.
In general, you don’t expose X11 sockets on the internet any more. They’re unix domain sockets in /etc/X11/. Remote X is tunneled over SSH.
The insecurity that people tend to complain about in X11 comes from any window (such as a web browser) being able to look at the resources like clipboard contents of other windows run by the same user.
Besides apps being able to look at each others’ stuff, X11 is also a perennial source of privilege-escalation bugs, because some of it needs to run SUID, and it’s a large pile of old, mostly un-audited code. E.g. a recent example that affected OpenBSD.
I’m no expert in X, but I have the same impressions. As we all nkow if security is an afterthought it is usually far more expensive to add to a system, if possible at all. Given RedHat’s reluctance to further support the project it can be called dead. It has been in maintenance mode at least for 5 years now. Also, when I tried to configure X recently it hurt so badly, I had to give it up, and I’ll be happy when it will be gone. (No config file, but autodetection is the thing now, but you can override parts, but you need to know what would be in the config file, but you cannot get a dump of the config file as understood by the server… it was PITA. I wanted to tweak some input preferences, but it hurt so badly I gave up.)
I understand the impetus to start using X in Linux, because it was there and it worked and it enabled graphical interfaces “out of the box”. But it’s woefully behind the times now, and a lot of its complexity is tied to an obsolete use case (running windows remotely on more powerful machines).
With that said I haven’t really followed the debate around its replacement(s). My Linux use is almost all command-line based nowadays.
I don’t think that’s true. Remote windows are not particularly complex – the bulk of the complexity comes from a woefully misdesigned font and keyboard handling architecture, and a protocol that wasn’t particularly designed, and as a result is an incredible mess of special cases to parse and handle correctly.
Sure, I totally agree. Now with Wayland in the works hopefully stuff will get done soon. To be honest a session migration between remote and local terminals in the sense Windows RDP offers it would be pretty nice. Sometimes I find is useful.
The one reason I switched from OpenBSD to Void Linux is my Nim and Love2d usage. If it weren’t for those being unmaintained (and hard to compile) I’d be back in a flash
Nim is in the ports.
it’s an old version.
I haven’t tried a BSD in many years. I went just now to look for some OpenBSD packages (ports) for software that I often use. As expected, there are ports for the super-popular things like Firefox, Chromium, Thunderbird. I regularly work with audio, video and graphics/images. There are ports for kdenlive and audacity, and that’s nice, but notably absent are ardour and GIMP, and that’s pretty much showstopping for me.
GIMP is there…
That’s a release from 2017.
Mostly due to the fact it doesn’t have a maintainer.
Is it available in the ports tree to build from source, though? Or is that implied? I’m a BSD noob, so I wouldn’t know.
[Comment removed by author]
Yes, binary packages are just builds of ports.
Ardour might indeed be something missing but might not be too hard to package or port over.
GIMP is packaged, stable and regularly updated on OpenBSD, I use it often :)
Having said that I am not entirely sure how workable Ardour would be or how well can OpenBSD perform in the low-latency/realtime needs music/sound editing has. But I also don’t have active knowledge on this dept so might be wrong.
To be fair, the current port is gimp-2.8.22, which is over two years old by now (May 2017). Current stable GIMP is 2.10.12.
huh… you are right… might have been confused with another Graphic suit package or seen a dept update and not realize it wasn’t the base package as well. 2.8 has been very workable and stable for me, now I am wondering why 2.10 ain’t there… might either be orphaned or there might be a blocker 🤔