UFS/FFS is well tested code and won't corrupt itself, but it lacks the checksumming to detect data corruption from unreliable hardware/firmware/drivers.
I had a power outage corrupt UFS and another indecent due to a kernel panic while debugging a WiFi driver.
I've run Linux on various filesystems for significantly longer and have never seen filesystem corruption - (excluding me not reading btrfs documentation right).
This deals with the 'original' Hammer, this is way above my head, and I don't know how much applies to either OS or the HAMMER2 so this is just me posting another link but:
"There are several major differences:
* All VOP operations related to the namecache... those using named
path elements like lookup, rename, etc... those are completely
different.
The biggest one is that our VOP_NRESOLVE() API is completely different
from the old VOP_LOOKUP() API. The old VOP_LOOKUP() API had to handle
numerous side effects and I don't recall the FreeBSD namecache
subsystem doing any namespace locking (beyond locking vnodes, that
is).
Also our VOP_NREMOVE() is fairly radically different... it's an all
in one call whereas the older VOP_REMOVE was paired with a VOP_LOOKUP
that stored side-effects (not sure if FreeBSD has cleaned that up yet).
i.e. old was LOOKUP(save side effects) + REMOVE(use side effects).
And DragonFly's is just NREMOVE().
* HAMMER uses a far more sophisticated buffer cache call-back interface
which allows HAMMER to veto write requests from the buf_daemon's (to
enforce certain write ordering requirements).
* DragonFly uses a locking model that I don't think FreeBSD has an API
for (our token locking model which releases held locks within the
model when a thread switches out and reacquires them when the thread
switches back in). If FreeBSD also has an API for this model this
would be easy to port (if not for all of the above issues).
* DragonFly uses a slightly different stacked BUF/BIO mechanic for I/O.
This would be easy to port (if not for all of the above issues).
* DragonFly's BUF/BIO allows for different buffer sizes within the
file buffers (not just the device buffers). Generally speaking
there can be significant mixing of buffer sizes and the cluster code
has to be able to deal with it given appropriate argumetns. I don't
think FreeBSD's cluster code could handle it.
Personally I think it might be too much for a GSOC project.
-Matt"
It's crazy that they did an entire release with no obvious major big new features, only a hundred small improvements here, a hundred small improvements there. I wish Apple could do the same with macOS.
Maybe someone here would have advice for upgrading ancient OpenBSD installs?
I inherited some 5.x OpenBSD systems at my current job and I'm really curious how I'd go about upgrading to 7.4 - I have a feeling I'll be running into some broken links.
I'd really like to meet the person who was gung-ho enough to use OpenBSD in prod but seemingly treated them like a LTS system - not a "releases are supported for ~1 year" system.
Make backups, make sure you can restore them, then just step through it one version at a time. Things got a lot easier around 6.6 when sysupgrade was introduced.
It looks like some mirrors have packages going way back (http://ftp.eu.openbsd.org/pub/OpenBSD/), but depending on your use-case, it may be more beneficial to focus on the base system upgrades (documented in the upgrade guide) and worry about the packages later.
That many years of package changes could be troublesome to deal with, and it may be better to fast-forward to whatever the modern tooling would be.
However speaking with my manager I think the long term plan is to dump it for RHEL - too bad because I'd like it on my resume :-) Not every day you can play with OpenBSD in prod - usually it's just on my oddball computers.
It's possible, but you'll run into annoying breakage long the way. It's probably safer and less troublesome (unless you're deeply familiar with the changes along the way and the old upgrade procedures) to take the existing configurations as guidelines what to recreate on the latest release.
Probably the best method.
I believe most applications our either our own (some Golang tools, for some reason?) or basic base applications (migration to relayd instead of nginx as a proxy is probably a good idea.)
What are you using them for? I feel a lot more comfortable using OpenBSD in production than Linux for the long-term (my personal opinion). I've been using it since ~3.5, and the 6 months releases have been ticking along nearly flawlessly for a long, long time.
Yes I feel like OpenBSD can be a great system for this use case, but the prior owner of this system had neglected it. Now it's still on 5.6 and who knows how much cruft has built up.
It's currently acting as a bridge system that translates 5010 X12s to 4010 and vice versa. Strangely enough the whole stack in Golang which I don't believe considers OpenBSD to be a supported platform?
OpenBSD fares far worse in performance than Linux and its BSD cousins because they actively avoid supporting CPU, memory, and other features that increase performance via some shared resource because these are often vectors for information leakage and attack.
Everyone else has taken the approach of utilizing these features and getting the performance, but mitigating attacks (or class of attacks) as they are are discovered. Which is not a worse approach per se, especially if your project places a higher value on raw performance (or performance per dollar spent) and you can strengthen security at other layers.
phoronix benchmarks are bad on average, but this one is particularly garbage.
it doesn't make sense for zstd to be performing orders of magnitude slower on some OSs, because the bottleneck (at least at higher compression levels) is pure userspace code. as I recall, someone on the freebsd mailing list found that the actual speed is almost identical, but zstd used a totally wrong timing API on freebsd. phoronix also uses totally different zstd versions and only sets the compression level the same, ignoring that the achieved compression ratio may vary greatly between versions for some special data.
considering these basic errors, the whole benchmark should be considered garbage in garbage out and not useful for any real purpose.
Thanks. I am aware of that test but it is two years old and OpenBSD had quite a few optimisation in between. Hopefully we will have some update test from Phoenix again once FreeBSD 14 releases.
Indeed. There's been a lot of work towards unlocking the kernel and network stack (removing "big locks" that force code to run serially), so it would be cool to see some iperf tests on the same hardware with different OpenBSD versions.
I believe it's an Intel-managed distribution and is heavily optimised for Intel hardware. Not surprising it did so well as the tests in that article were done on an i9.
Clear Linux OS defines its minimum hardware requirements to be second-generation Intel® microarchitecture code name Westmere (released in 2010) or later.
OpenBSD or NetBSD would be better than Linux if you wanted to delve into operating system internals, or you wanted to operate the OS at a more direct explicit level. They are more straight forward in their implementation - modern Linux has more layers of abstraction (udev, dbus, systemd etc) which are useful but more complex.
Other than that, it mostly would come down to licensing or subjective taste questions.
seriously the best operating system i have ever used, and i've tried ubuntu, debian, alpine, gentoo, osx, windows, solaris, freebsd, netbsd, openwrt.
it's also one of the best products i have ever used, staying consistent, being well documented, extreme application of principle of least surprise. learn it once, use it forever kind of product.
regularly scheduled updates, extreme focus on technology, hardly any politics. if we want software development to become engineering, this is probably what it's going to look like.
OpenBSD just refuses many things that are must have, like Nvidia, ZFS, .. so it's not a option for all things. For things it can do, it's often the best.
On OpenBSD 6.x, after power outage/intel drm kernel freeze I had catastrophic data losses. This is not acceptable for me on a desktop/workstation OS. Linux FS stability is better since the 2.4 era in my experience.
I wasn't quite as bad for me, but every once in a while, after a power outage (or the very, very rare kernel panic), I need to get out the laptop and the serial cable to manually fsck my headless server box, because the automatic fsck wouldn't continue on its own.
It's pretty annoying, to say the least. But OpenBSD is such a fantastic system overall, I keep using it, and just wait for them to adopt a journaling filesystem. (And have good backups.)
Look, I'm a big fan of OpenBSD (and use it myself), but journaling filesystems are many decades old at this point, and they have very clear advantages. One is not to have to sit through an excruciatingly long fsck after a power outage, with a real chance to lose data. This is not an esoteric scenario.
OpenBSD will be better once it adopted a journaling filesystem, until then nobody claimed it's "bullshit".
Evey time BSD news gets posted, I always come in the comments looking for reasons to switch from Linux. There is consistently high praise accompanied by not so minor grips that make me stick with Linux.
Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
OpenBSD itself is a very capable and secure, but also very clean operating system. Everything feels as if it's out of "a single mold", much unlike e.g. Linux which is, in a sense, clearly cobbled together from many different pieces.
Changing the system is a breeze, documentation is extremely clear and detailed, and it just "doesn't get in the way".
That doesn't mean it's the OS for you. There are disadvantages with using a less common operating system, and it does require a certain mindset of liking to tinker with a UNIX-like operating system. I don't use it as a desktop OS, but for various servers.
My concern is lack of support for certain things and flexibility.
To be fair, I have very little knowledge of what's supported and what's not. If it help, here's 2 things I love about Linux:
1. The dev experience. This is obvious. Great package managers, native container support, etc. It all works great and feels snappy.
2. Ability to do obscure things. For example, a family friend may want a bunch of pictures archived. I can mount his google Drive with rclone, grab all of his pics and burn them to a blu-ray. Obviously, this is not an everyday use case but I appreciate the ability to do these types of things if I ever need to. I don't want to have to spin up a VM to support these odd one offs.
> Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
Let me try.
First up, it is extremely possible that OpenBSD is not for you. If you require something that is Linux specific, or you absolutely need Bluetooth or one of the other few things that you don't get with OpenBSD, and you are unable to refactor your life to not need those things anymore, then OpenBSD is a no go.
If that is not a concern, the strongest argument I can make for OpenBSD is that it's an operating system that wants you to trust it. It's written by people who understand system correctness matters above all else (and security just happens to be a nice side effect). Most of the time, this has only small and subtle user facing effects: good documentation, sensible defaults etc. But it really shows when you use it for a long period of time and see how over and over again, a decision made 10 years ago made OpenBSD somehow immune to the burning zero-day crisis of the day.
Right tool for the right job. I used to say OpenBSD is great for routers and firewalls, but honestly it's so left behind in performance and Linux has gained so much with eBPF that Linux is looking like the better option now.
I used FreeBSD on my desktop way back in 2000-2008 but today after 9 years on Fedora it seems like the stoneage.
> Anyone got a strong, concise argument for or against BSD over Linux for desktop use?
For desktop it should mostly depend on you. Does the things you personally run on a regular basis even work on BSD?
Unfortunately mine don't (terraform: too few providers support BSD and the one's I specifically work with do not). Yes, I could run terraform within a virtual machine on the system but that's heavier than I would like it to be.
If you eventually want some multimedia (3d, videos, etc), probably you won't like BSD. (opinion based on 4 year old experience)
I have used OpenBSD and NetBSD on desktop and servers. While they have their merits, as a Windows and Mac poweruser I have always felt some void. Linux is bearable from this perspective, BSDs were really far from the limited-priviliege user dynamical reconfigurability needed for a road-warrior notebook user. Linux is almost there.
If you have a mostly static setup and a sufficiently outdated Hw setup, you might be able to play high resolution youtube videos. If no other audio is holding the audio device. (though last time I used NetBSD had OSSv4 in the pipeline, and had limited success on openbsd, if all streams had the same sampling rate)
Oh, and OpenBSD managed to loose my data. (I liked many aspects of the system despite the above, but after this it got on my nope list, this was not acceptable even 30 years ago)
I was using softdeps on OpenBSD 6.4, on an old Thinkpad x200.
Once the battery ran out unexpectedly (old battery reporting incorrect remaining time), while I was doing some downloads and compiling a package. The system became unbootable because of filesystem corruption, after fsck and overwrite of system packages from other boot media I noticed extensive data loss.
After clean reinstall experiencing intel drm driver kernel panics during ports install the disk became corrupted once again, with some files lost.
I reinstaled the system once again and with disabled intel drm and softdeps the system worked for a while, but was slow as an ancient pentium.
I reinstalled windows and the machine worked great for years afterwards (with the wifi being a bit choppy, which was perfect on openbsd) for some tasks I needed a semi-portable windows machine (running some windows only plc programming tools).
The ssd was healthy, memcheck did not find memory errors. I reinstaled my openbsd server with linux which was running ok meanwhile, but now I can sleep assured that my data is mostly safe.
the ports often dont work (or require a rodeo-size production to get them to work). A couple of years ago I installed FreeBSD, went to ports and did a "make install clean" of vim, and it wasted 10 minutes of my time only to fail on some arcane package's compilation. I asked for help and was told that "ports are not the OS, contact the ports maintainer for your pkg", technically true, but they tout their ports as this awesome, universal collection of amazing software. (the real workaround is for common packages like vim, you use "pkg install vim" and it installs binaries). The beauty of ports (if they worked) is that you can do cool things with the USE flags (this should be familiar to Gentoo users, my mind is drawing a blank though for a concrete example to explain this to someone unfamiliar).
Recently I tried to install prolog on OpenBSD-7.3, it failed even from pkg. I didn't want to waste my time on ports, so I just wiped the OS from my machine (running neofetch takes a couple seconds, which gives you an idea of how slow it is, however if I ever needed a very secure machine (such as an SSH bastion or anything internet-facing) I wouldn't hesitate to pull it up again.
FreeBSD is almost usable as a desktop though. Only thing keeping me is audio wont work over HDMI/DisplayPort, but I totally understand they don't have time to fix all that hoopla. A pro OR a con, depending on your POV is that FreeBSD support really expects you to put your big-boy pants on when you ask for help. They get (justifiably) annoyed if you dont RTFM and concisely lay out everything you tried to do to fix it. For various reasons, the Linux ecosystem is way more tolerant of SO-style "how do I do X on linux" type questions.
> Only thing keeping me is audio wont work over HDMI/DisplayPort, but I totally understand they don't have time to fix all that hoopla.
What video card? I've got a half done patch for Intel that might help, a little. Some things are easyish; there's a flag I forget the details of that got audio devices to show up, in the likely event that boot time firmware didn't set things up properly. Some things are much harder; at least on haswell era intel video, audio and video clocks are linked, so the audio and video driver really need to communicate, but (when I was last looking at it) there's no plumbing for that in FreeBSD, and the video driver is imported from Linux anyway. Some things seem impossible; on the machine I using HDMI audio with, the audio device stops responding overnight and rebooting is the expedient way to get it back; there's probably something better, but I dunno.
I really hope the work to port HAMMER2 to OpenBSD lands in -current (and someone will own/maintain it).
https://github.com/kusumi/openbsd_hammer2
OpenBSD lacking a modern filesystem has been an achilles heel for it.
EDIT: why the downvotes?