I could do FreeBSD on my laptop I think. I don't play games, and I've been wanting to play around with kqueue.
Is it sort of like OpenBSD? I liked their manpages and their built in server thing (httpd). or is it completely different...
Is it sort of like OpenBSD? I liked their manpages and their built in server thing (httpd). or is it completely different...
This was especially notable at BSD-wide events like BSDCan, AsiaBSDCon, EuroBSDCon etc.
OpenBSD supports suspend to disk, whereas FreeBSD does not. (Is this being changed as part of this laptop project?)
OpenBSD has always supported graphics, sound and other desktop things in the default kernel, without having to tinker with kernel config or loadable kernel modules. FreeBSD? http://cr.yp.to/unix/feedme.html
Also, on OpenBSD, the basic X is part of the base system, in the xenocara repository, and it basically just works, straight from the default installer:
https://en.wikipedia.org/wiki/Xenocara
OpenBSD actually does NOT support loadable kernel modules at all, and you're strongly discouraged from running a customer kernel, too. This has a side effect that both graphics and sound works out of the box, since deviation from defaults is discouraged, and if it didn't work by default, it'd not be recommended in the first place.
On FreeBSD, even the most basic X stuff is part of the Ports tree, which basically implies that most installations wouldn't have it, and it's often far less integrated, and requires way more tinkering, than xenocara on OpenBSD. For example, when you know most of your installations wouldn't have X, would you have graphics and sound support in the default kernel, or would that require further tinkering of the kernel config and/or LKM?
(On both systems, you still install KDE and GNOME from ports/packages, if needed, it's only the lightweight basic X and WM stuff that's part of OpenBSD base xenocara.)
So, even though FreeBSD is faster and more popular in many ways, to most people's surprise, OpenBSD actually has better laptop support.
That was definitely true five years ago. At this year's FreeBSD developer summit in Ottawa I saw more Framework laptops than Apple laptops.
For example, I installed FreeBSD on an old laptop and had to fiddle with building Xorg to get a GUI. Same laptop on OpenBSD just worked after running the installer.
Ports tree in general is a great way to install third-party software, but not necessarily for Xorg.
You still install KDE or GNOME through ports/packages on both systems, but X being more tightly integrated with the base system has benefits in reducing complexity for the rest of the components.
For Arch users of KDE Plasma and applications, are essential packages ever missing? <https://wiki.archlinux.org/title/KDE#Installation>
From https://gist.github.com/grahamperrin/307b8cdef5d4dcd30f5fdc4... for FreeBSD:
> It's not unusual for a Tier 1 platform to have no package for a wanted desktop environment. Two platforms are at this tier: …
For example, kde for FreeBSD 15.0-CURRENT was recently missing for a few days for AMD64; is still missing for aarch64 (64-bit ARMv8).
This is not to criticise the maintainers of packages or repos. I do understand the constraints.
The absence of an essential meta package is, inescapably, an impedance when aiming to test installers and upgrades, especially with pkgbase.
Man pages are just as good, and the Manual is a bit more comprehensive.
Whichever man page I read, they always cite specific standards. They also tend to follow the de facto standards, judging by the breadth of software in their ports tree (which more often than not, is actually full of Linuxisms).
The simplest example is gets(3) doesn't exist in libc. rand(3) and family aren't deterministic (srand_deterministic(3) gives you that, but it's OpenBSD-specific). There are others, but it's not something I think about a lot so I can't think of them off the top of my head.
If you're genuinely interested I'd recommend asking over at DaemonForums. I'm sure someone has compiled a list somewhere.
As defined by POSIX.1-2001:
> If a read error occurs, the error indicator for the stream shall be set, gets() shall return a null pointer, and set errno to indicate the error.
IMHO the least-unreasonable thing to do is to behave exactly as if a read error occurred, but programs that do use gets(3) are unlikely to check for errno anyway.
> The rand() function shall return the next pseudo-random number in the sequence.
<https://pubs.opengroup.org/onlinepubs/007904875/download/> susv3/functions/rand.html
The spec does not say what the sequence should look like, other than it's pseudorandom, so the exact sequence is implementation-dependent. You can't use it to e.g. seed a test run, a terrain generator, etc - and expect repeatable results across platforms, releases. (And I honestly can't think of another reasonable use case for deterministic output.) IMHO at that point you should define your own PRNG, it's about 8 lines of C.
But you're obviously correct, these are deviations.
I personally don't have an issue with their choices - they're completely in line with OpenBSD's mission of producing a secure OS. I'd be less pleased to see that sort of thing in other systems like NetBSD, though.