https://www.openbsd.org/images/LifeOfAFish.png
https://www.openbsd.org/images/puffy77.gif
t-shirts, hoodies, stickers on openbsdstore.com
[0] https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
I guess I will have to wait for another phoronix benchmarks.
What Id love is a journaling file system and extended attributes personally...
Same; that would really improve the remote router scenario. I've had a router refuse to boot up after a power outage until I manually ran a disk check. I'd like to at least be able to force start-up no matter what, but journaling is the proper fix.
https://github.com/kusumi/makefs
Maybe? As a starting point?
This doesn't inspire confidence. OpenBSD is famous for how well the base system is integrated (even compared to other BSDs). I wouldn't trust base's stability to an arbitrary set of patches.
You might think that OpenBSD on its own incurs a massive performance hit (at least I used to think that), but when I compared it against Alpine Linux on that underpowered desktop it was really not different enough for say video playback/encoding that I could tell much of a difference. Yes, OpenBSD is slower, but I would guess the margin is maybe 5% which is certainly not what I expected. Maybe for other workloads it is very different from my experience, but I am a user and not expert benchmarker so I can not give a better answer.
Where there is a difference is when you have multiple jobs hitting syscalls hard. Say, heavy disk access. On Linux this will not cause your cursor to freeze momentarily, delay the launch of other programs, or your audio playback to halt or distort, but on OpenBSD this happens even on something as powerful as a 3950X when I tried it. I am not enough of a kernel hacker to tell exactly what the issue is, but I suspect it is that OpenBSD's kernel has very limited preemption. This is not great, but it is not enough of an annoyance to deter me from using it on some of my desktops.
Other than the above, the experience of maintaining a server or desktop with OpenBSD is amazing. Top-notch documentation, everything is a flag in rc.conf.local or text file in /etc, and the base system is capable enough to run all the services I need and for my other uses ports has me covered. Plus, it gets better with every release. 7.7 comes with massive improvements to the USB video subsystem that has fixed every device I had that previously did not work with OpenBSD.
My annual donations will keep coming, but I wish I was rich enough to fund or good enough of a kernel hacker to work on whatever it is that the kernel needs to address the last few snags and I would happily run OpenBSD on every box I have.
• Check available disk space in /usr. Verify that the /usr partition has a size of at least 1.1G. With less space the upgrade may fail and you should consider reinstalling the system instead.
When this says "available disk space," it means "total" disk space of the /usr partition, not "free" space. I had less than 1.1GB of unused free space on /usr and had to verify that that was fine before proceeding.
At that point it'd be cheaper/easier to arrange 64 Mbyte of RAM in the old pentiums. With Raspberry Pi's having 4 GB these day it'll be perhaps just be a painful exercise.
I'm happily using OpenBSD as my core router, my Minecraft server, a laptop OS, and on my retro PCs. Currently updating my Raspberry Pi 4 to 7.7 as well.
* On 7.5 the built-in `bwmf0` was not detected
* On 7.6 `bwmf0` was detected and works great, even in AP mode. However, my latest Node project core dumped when running `npm install` and nothing I tried got it working (short of recompiling Node)
* On 7.7 (today's release) `npm install` is working perfect
Not worth an entire blog post, but just goes to show improvements in OpenBSD over time on the Pi 4 :)
Mine hosts a LAN using the built-in wireless adapter (bwmf0) so it's easy to SSH in, but if it's stuck in single user mode, this doesn't work.
With a spare HDMI monitor and USB keyboard it's not too difficult to get back in, but it's a hassle without these laying around.
I also tested a USB-KVM style solution: I used a mini HDMI adapter connected to an inexpensive USB capture card which let me view the console in OBS Studio. I used a regular keyboard to enter commands, but I also discovered there are "RS232 USB HID emulators" which are DE-9 serial on one end and USB on the other, allowing one to type characters into a serial session (e.g. PuTTY) and have them pop out the other end as an emulated USB keyboard. I didn't end up testing this, but in theory it would give you a basic KVM or crash cart style setup to get back into the Pi. The total price would have been around $40-50, much less than a real USB KVM like the Startech Notecons01. [0]
Another idea is to use a power brick with pass-through charging. Many good Anker batteries support this and some of them are the size of the Pi - so one could easily setup a long lasting UPS for the Pi for $30-40. At around 2.5 watts idling, a 10,000 mAh battery should easily give 6-8 hours of charge which should be enough to survive brief outages and prevent an unclean shutdown. A basic USB-C charging meter will show the Pi's power draw as well.
Other than that, the next best thing is to mount as much of the system read-only as possible to help reduce the chances of needing to fsck.
FWIW, I'm using a basic Apacer 32GB microSD card and haven't had any issues with failed writes or endurance or anything like that.
[0] https://www.startech.com/en-us/server-management/notecons01
Power loss and single user mode complications aside, OpenBSD 7.7 runs fantastic on the Pi 4. It feels no different from a standard AMD64 install for most tasks. I haven't used the GPIO pins under OpenBSD but it otherwise works like any other system. :)
NoWordsKotoba•1mo ago
anyfoo•1mo ago
I’m actually genuinely excited when a new version comes out, taking time to read the changelog.
rubyfan•1mo ago