What truly suprises me about BSDs is their simplicity and low footprint, OpenBSD being gold standard.
I've been playing with `byve` the last two weeks (I highly recommend vermaden's blog for anyone interested in BSDs and obviously the handbooks of each project) and I'm seriously thinking not doing a dual boot Linux install again. On my old x230 (which is running FreeBSD) I will be installing OpenBSD just to become more familiar with it.
I still don't get why just after installing Debian `top` shows me around 200 proceses. BSDs? Under 20. Other thing that pisses me off is for example how polluted (at least on Ubuntu) mountpoints are. Package management is also fragmented on Linux, while on BSDs is either a flavour of `pkg` or ports.
Perhaps I should still try more minimalistic Linux distributions, just don't know which are good candidates
Don't get me wrong, I love Linux and still recommend it heavily to non-tech people around me but when you taste a BSD is hard to go back.
Top on linux shows kernel threads (all the processes in square brackets), on BSD it doesn't show these afaik. A fresh debian install only lists a handfull of processes (all the expected ones, ssh, systemd, ntp, gettys etc) besides the 200+ kernel-threads.
Uh, ok then. I always thought that those were actually real kernel processes. What's the use of having top report those kernel threads? Is it possible to renice them?
Openbsd has been my router for a decade... I have a ansible playbook that does everything I need... I use a cheap USB drive in a fanless computer the only failure has been the $9 USB drive
If I had a nickel for every time my OpenBSD buddies told me "your ASUS router is not secure, just configure an OpenBSD machine as your router", I'd have a lot of nickels.
The part they never tell me is what hardware they recommend for the Wi-Fi, or rather which devices have OpenBSD driver support and allow for at least 4-5 good connections over 802.11ac?
I'm all for it, I just don't know where to start on the hardware.
Yeap, actually I haven't run directly `bhyve` but using the `vm` wrapper as is very convenient.
I haven't looked at passrhrough yet, but I do feel that if I need to use it I would probably have to fight a bit with it, anyone had a hard experience setting it up?
While at it, a good minimalistic Linux could be Void Linux, which has several BSD folks on the team. I'm running it for about 7 years, and am happy with it. Unlike BSDs though, it's a rolling release, so I get fresh packages a few days after an upstream release.
Arch Linux is the closest I've seen to BSD in the Linux-verse. I recommend trying it. I'm not sure about production though, or using more exotic things like CUDA.
> Arch Linux is the closest I've seen to BSD in the Linux-verse.
It really isn't. The BSDs are smaller and cleaner, especially OpenBSD, which is positively minimal. Arch is huge.
The closest Linux to OpenBSD is probably Alpine, of all those I've seen. Takes as much disk as most modern distros take RAM, and because of no glibc and no systemd, a tonne of familiar Linux tools aren't available or don't work... just the old fashioned Unixy stuff... which is very much how running a BSD feels.
>and I'm seriously thinking not doing a dual boot Linux install again
Same here, i had dualboot Arch/FreeBSD for some years, but i just don't need that arch install i just stayed in FreeBSD and for games i have a bhyve Win11 VM (with GPU Passthrough) and that's all i need.
The BSDs seem to have their own fragmentation as well. All targeting their own niches and somewhat overlapping work. For example or ZFS or virtualization technologies that aren’t cross-pollinated easily.
Like, it’d be cool to have zfs on openbsd, etc. But you can’t easily mix and match.
At least on the linux side you can usually fit something into a different distro if you wanted without an insane level of effort.
I'm impressed that they still maintain PA-RISC support even though HP discontinued that architecture in 2008.
They maintain all these architectures in such a small, consolidated codebase with such minimal (if any) bloat.
Their built-in httpd is far and away the best experience I ever had setting up a static file server for my local network, and I can't think of many times where I would ever need anything I couldn't do with the built-in FastCGI support.
I'm also pleasantly surprised by how well Chicago95 (a Windows 95-style UI based on xfce) works on OpenBSD, even though the author never intended to run it on anything but xubuntu. I wouldn't recommend trying that unless you're willing to roll up your sleeves, but the payoff definitely justifies the elbow grease if you like that look and feel better than xenodm, XFCE, or GNOME.
You did a lot of cool things, mister. How do I send you pizza (from one of the good places)?
Glad to see how many high-value changes OpenBSD is receiving. You just inspired me to get Chicago95 up and running on an old MacBook I have lying around right now, and replace the battery. I run it off of an old Lenovo Thinkcentre that I use as a server on my local network, but I haven't been using it as my daily driver. The number of things I can run on macOS is a lot smaller than it used to be 15 years ago, so I might give OpenBSD another shot as my daily driver.
P.S. I didn't know there were other people interested in using Chicago95 on OpenBSD, let alone OpenBSD contributors. Good stuff, man!
I'm a long-time Linux user, but have always been drawn to OpenBSD, in large part due to the team's philosophy on software. I wish I had the willpower to switch to it as my main OS, but unfortunately, my workflow is too dependent on popular software and cutting-edge hardware, which historically don't work too well on OpenBSD. I don't blame the team for it—in fact I applaud their unwavering commitment to their values. It's what makes the system great, after all.
Regardless, I'm grateful that everyone can still benefit from the great set of tools that were started, and most still maintained, in the OpenBSD project. OpenSSH, PF, tmux, etc. They're a beacon of light in the software world.
What is the status on FS journaling/softupdates? I used to like openBSD but it kind of disappeared of my life once they removed support for softupdates a couple of years ago. I am not so fond of those fsck and lost data we used to have on an occasional basis after an unexpected hard shutdown due to a power cut in the 90's.
> I am not so fond of those fsck and lost data we used to have on an occasional basis after an unexpected hard shutdown due to a power cut in the 90's.
Yup, still the case today.
Currently with an SSD, when there’s a power cut, there’s about a 20% chance my router will require me to walk downstairs and plug in a keyboard, type “fsck” manually and press y at all the prompts.
I haven’t actually had any issues with noticeable data loss though.
I’d settle for a default “boot anyway, press y for all fsck questions” mode on boot. I just don’t want to have to physically touch the thing.
> Currently with an SSD, when there’s a power cut, there’s about a 20% chance my router will require me to walk downstairs and plug in a keyboard, type “fsck” manually and press y at all the prompts.
> I’d settle for a default “boot anyway, press y for all fsck questions” mode on boot. I just don’t want to have to physically touch the thing.
Look up where fsck is run in /etc/rc and add the -y there.
Softupdates was never an approach towards journaling. It was removed because it caused more problems than it solved and because its complexity stood in the way of future work to improve FFS2.
AFAIK there's currently no news about plans on getting journaling into FFS2 or bringing one of the other modern file systems onboard. The most "modern" choices you have on OpenBSD is FFS2 and ext3 (supported through OpenBSD's ext2 driver but without journaling).
My own experience with FFS/FFS2 the past 20 or so years is that it's been wholly robust through the relatively few power outages and other incidents I've had. While I wouldn't mind it becoming snappier I do prefer that its fully synchronous. I've never used softupdates.
FFS/FFS2 has been reliable for me, but unfortunately don’t have reliable power. It does frequently require fsck -y on boot. It’s not the most pleasant with my headless units requiring a serial cable.
My solution has been a huge UPS so they never turn off. Softupdates prevented this issue for over a decade (?), so hoping we get HAMMER2 or something down the road.
I’ve been running OpenBSD continuously since 3.4, and no other OS beats it in simplicity IMO. The upgrades have ticked along quickly and flawlessly year over year. I wish more systems would take a page out of that book and implement something like sysupgrade.
Then again, the sentence "tcp is outside of global lock" is very generalized, there are so many parts that got out of the kernel lock in pieces, like ip input, routing lookups and device packet handling that it is hard to talk about it as one singular thing that you just flip a switch on to make it MP-performant.
You could make filesystem code mp, disk device drivers mp and then still run on an IDE-disk which forces all IO to be one at a time and serialized first-come-first-served at which point all the work was for 'nothing'.
Same goes for networking, there are many many layers and places that all need code that actually allows for MP processing to improve its performance, fine grained locks (which reduce perf at this stage), then prove that the fine grained locks are sufficient for ALL use cases, all kinds of layering violations that could possibly happen, then you can unlock this single layer, and move to the next if nothing acts up on any machine.
Network performance has gotten steadily better during the last three or so years, to the tune of most network drivers today seeing around 2x throughput compared to a few years back.
I have a retired mid-2010s Celeron platform which managed about 300 Mbit/s on OpenBSD 7.1/7.2. With OpenBSD 7.6 it reached well over 700 MBit/sec. I also have an early 2020s Atom platform which saturates its 2.5GbE interface without any problems. Not all of the network drivers perform equally but the network stack improvements have all the same made them take pretty big leaps.
Not benchmarked on my system yet but I use OpenBSD on my home router (PCEngines APU2) and even before this stuff, OpenBSD could handle 1Gbit just fine. And that's with VLANs, LACP, a good number of PF rules, etc.
Ditto here; upgrades are very boring under OpenBSD. You can keep the same setup for ages,
even more with cwm, xterm, mupdf, mpv and a bunch of CLI/TUI tools and games...
Readit News
I've been playing with `byve` the last two weeks (I highly recommend vermaden's blog for anyone interested in BSDs and obviously the handbooks of each project) and I'm seriously thinking not doing a dual boot Linux install again. On my old x230 (which is running FreeBSD) I will be installing OpenBSD just to become more familiar with it.
I still don't get why just after installing Debian `top` shows me around 200 proceses. BSDs? Under 20. Other thing that pisses me off is for example how polluted (at least on Ubuntu) mountpoints are. Package management is also fragmented on Linux, while on BSDs is either a flavour of `pkg` or ports.
Perhaps I should still try more minimalistic Linux distributions, just don't know which are good candidates
Don't get me wrong, I love Linux and still recommend it heavily to non-tech people around me but when you taste a BSD is hard to go back.
Your right, you can show the system-processes in top with Shift+S, threads with Shift+H
The part they never tell me is what hardware they recommend for the Wi-Fi, or rather which devices have OpenBSD driver support and allow for at least 4-5 good connections over 802.11ac?
I'm all for it, I just don't know where to start on the hardware.
I believe you meant "bhyve".
I haven't looked at passrhrough yet, but I do feel that if I need to use it I would probably have to fight a bit with it, anyone had a hard experience setting it up?
It really isn't. The BSDs are smaller and cleaner, especially OpenBSD, which is positively minimal. Arch is huge.
The closest Linux to OpenBSD is probably Alpine, of all those I've seen. Takes as much disk as most modern distros take RAM, and because of no glibc and no systemd, a tonne of familiar Linux tools aren't available or don't work... just the old fashioned Unixy stuff... which is very much how running a BSD feels.
Same here, i had dualboot Arch/FreeBSD for some years, but i just don't need that arch install i just stayed in FreeBSD and for games i have a bhyve Win11 VM (with GPU Passthrough) and that's all i need.
Like, it’d be cool to have zfs on openbsd, etc. But you can’t easily mix and match.
At least on the linux side you can usually fit something into a different distro if you wanted without an insane level of effort.
Deleted Comment
They maintain all these architectures in such a small, consolidated codebase with such minimal (if any) bloat.
Their built-in httpd is far and away the best experience I ever had setting up a static file server for my local network, and I can't think of many times where I would ever need anything I couldn't do with the built-in FastCGI support.
I'm also pleasantly surprised by how well Chicago95 (a Windows 95-style UI based on xfce) works on OpenBSD, even though the author never intended to run it on anything but xubuntu. I wouldn't recommend trying that unless you're willing to roll up your sleeves, but the payoff definitely justifies the elbow grease if you like that look and feel better than xenodm, XFCE, or GNOME.
I did a thing. :-)
https://www.linkedin.com/posts/brynet_openbsd-activity-73074...
Glad to see how many high-value changes OpenBSD is receiving. You just inspired me to get Chicago95 up and running on an old MacBook I have lying around right now, and replace the battery. I run it off of an old Lenovo Thinkcentre that I use as a server on my local network, but I haven't been using it as my daily driver. The number of things I can run on macOS is a lot smaller than it used to be 15 years ago, so I might give OpenBSD another shot as my daily driver.
P.S. I didn't know there were other people interested in using Chicago95 on OpenBSD, let alone OpenBSD contributors. Good stuff, man!
I remember running windows95 overnight so that it could be a "server".
The next morning, moving the mouse was making the harddrive go nuts, it was paging just by moving the cursor!
Memory leak galore.
This makes me want to run linux as my daily driver! [1]
[1] https://github.com/grassmunk/Chicago95/blob/master/Screensho...
Regardless, I'm grateful that everyone can still benefit from the great set of tools that were started, and most still maintained, in the OpenBSD project. OpenSSH, PF, tmux, etc. They're a beacon of light in the software world.
https://www.openbsd.org/images/Terraodontidae.png
https://www.openbsd.org/images/puffy78.gif
https://www.openbsd.org/78.html
Are they any new FS supported nowadays?
Yup, still the case today.
Currently with an SSD, when there’s a power cut, there’s about a 20% chance my router will require me to walk downstairs and plug in a keyboard, type “fsck” manually and press y at all the prompts.
I haven’t actually had any issues with noticeable data loss though.
I’d settle for a default “boot anyway, press y for all fsck questions” mode on boot. I just don’t want to have to physically touch the thing.
> I’d settle for a default “boot anyway, press y for all fsck questions” mode on boot. I just don’t want to have to physically touch the thing.
Look up where fsck is run in /etc/rc and add the -y there.
AFAIK there's currently no news about plans on getting journaling into FFS2 or bringing one of the other modern file systems onboard. The most "modern" choices you have on OpenBSD is FFS2 and ext3 (supported through OpenBSD's ext2 driver but without journaling).
My own experience with FFS/FFS2 the past 20 or so years is that it's been wholly robust through the relatively few power outages and other incidents I've had. While I wouldn't mind it becoming snappier I do prefer that its fully synchronous. I've never used softupdates.
Ehmm it is a alternative approach for fs consistency then journaling:
>>The use of soft updates obviates the need for a separate log or for most synchronous writes.
https://www.mckusick.com/softdep/
My solution has been a huge UPS so they never turn off. Softupdates prevented this issue for over a decade (?), so hoping we get HAMMER2 or something down the road.
I’ve been running OpenBSD continuously since 3.4, and no other OS beats it in simplicity IMO. The upgrades have ticked along quickly and flawlessly year over year. I wish more systems would take a page out of that book and implement something like sysupgrade.
https://github.com/kusumi/openbsd_hammer2
Somehow it was just never taken over the finish line though. I don't know why.
I wonder how useful this will be for the modest but still multicore systems used for firewalls.
Then again, the sentence "tcp is outside of global lock" is very generalized, there are so many parts that got out of the kernel lock in pieces, like ip input, routing lookups and device packet handling that it is hard to talk about it as one singular thing that you just flip a switch on to make it MP-performant.
You could make filesystem code mp, disk device drivers mp and then still run on an IDE-disk which forces all IO to be one at a time and serialized first-come-first-served at which point all the work was for 'nothing'.
Same goes for networking, there are many many layers and places that all need code that actually allows for MP processing to improve its performance, fine grained locks (which reduce perf at this stage), then prove that the fine grained locks are sufficient for ALL use cases, all kinds of layering violations that could possibly happen, then you can unlock this single layer, and move to the next if nothing acts up on any machine.
) https://www.youtube.com/live/wEM-E-IJ6sY?si=X3lLX9tEIO2mcEJl...I have a retired mid-2010s Celeron platform which managed about 300 Mbit/s on OpenBSD 7.1/7.2. With OpenBSD 7.6 it reached well over 700 MBit/sec. I also have an early 2020s Atom platform which saturates its 2.5GbE interface without any problems. Not all of the network drivers perform equally but the network stack improvements have all the same made them take pretty big leaps.
since:
> o Implement support for "vmmc-supply" in sdhc(4), needed to power on the WiFi chip on the Raspberry Pi 5.