What FreeBSD can offer compared to other operating systems (2020)
vermaden.wordpress.com
vermaden.wordpress.com
FreeBSD definitely has things to offer compared to other operating systems, but I'd also argue that the reverse is true in many cases.
Linux, generally speaking, has a much nicer upgrade story. FreeBSD's works, but having to reboot and run freebsd-update multiple times during a major upgrade is annoying.
FreeBSD's init system works and is generally fine, but I much prefer the simplicity of systemd unit files over FreeBSD's rc scripts. The common use-case of "Run $X as user $Y, capture it's output, restart it if it dies, and track it's PID" is incredibly easy to do in a systemd unit file. FreeBSD could learn a lot here[0].
Related to the upgrade story, packaging is interesting in FreeBSD. The base system is just "there" and managed by freebsd-update, but 3rd party software is installed via packages (ports build a package then install it). The separation of base (/, /usr, etc) vs 3rd party (/usr/local) is good, but it would be nice if all of the software was managed the same way. FreeBSD has started work on this[1], but I have no idea if it's actually going anywhere.
[0] https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s...
This also annoyed me so I implemented one reboot way with ZFS Boot Environments - described here in details:
- https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-wi...
Sometimes its even possible to upgrade without reboot as beadm(8) supports the 'reroot' feature. If you kernel did not upgraded - then you do not need to reboot - just reroot:
- https://vermaden.wordpress.com/2022/03/14/zfs-boot-environme...
Regards.
#!/bin/bash
cd /opt/minecraft-player
exec 2>&1
exec setuidgid minecraft /usr/bin/java -Xmx2048M -Xms1024M -jar /opt/minecraft-player/server.jar --nogui --port 32122
#!/bin/bash
exec multilog s10485760 n5 /var/log/minecraft-player
The first one goes into a servicename/run file, and the second into servicename/log/run.
Running the run file is precisely what the daemontools system will do. There's no need to track the PID. `svstat servicename` will tell you how long it's been running or if it's disabled. The default is to restart on death, and if it flickers too much, disable it. Adding /etc/init.d wrappers to this is a 60 second edit of a skeleton file.
Code is superior to configuration when the code is this simple.
I think we should try to do something better, I’m certain nobody will agree on a good language to use but I might propose starlark (a dialect of python, which recently got a rust implementation of the language thanks to Facebook).
I should add: I’m quite adept at bash (I have the LinkedIn skill badge! (This is a joke)) but I can agree with people who dislike it, there are too many edge cases, it’s not easy to understand and while expressive and powerful: evidently we should have something that is easy too.
So if you want to run starlark, or oil, or your favorite lisp dialect, go ahead.
In summation: bash isn't the problem here.
Nothing prevents us using alternative interpreters for rc.d, ones with hooks for process supervision, hooks for something akin to cgroups, centralised logging and so on.
But as a user who makes init scripts: you can do anything, which is pretty liberating when you really think about it.
/usr/sbin/daemon -R 2 \ # If terminated, restart after two seconds
-u foouser \
-p /var/run/foo.pid \
-o /var/log/foo.error.log \
/usr/local/bin/foocmd
This is the only issue I have with FreeBSD. On my desktop is one thing, but trying to manage upgrades across a large fleet of remote servers? No thanks.. (To be fair, this goes for some Linux distributions as well. Upgrades should never require user intervention.)
If a host fails to come back up, we boot back into the old environment, and someone from ops gets a ticket to try it again manually (rare, usually the OS upgrade works, but then fails the app healthcheck).
We manage 1000s of instances this way, and it's saved our skin lots of times.
We can't do that on linux where we have to depend on hypervisor snapshots (we run proxmox hypervisors mostly) which stop the world for memory state and cause some issues for us.
YMMV, of course.
I can't say the same thing for Ubuntu. I've lost track of the number of "oddities" that have occurred. Examples: network interfaces getting renamed, missing default routes, UEFI boot weirdness that can only be resolved from the console. Maybe I just have bad luck.
I agree with every point I ever see (in this and similar articles) about why FreeBSD is awesome, but I don't use it because when I create a virtual machine on GCP the default is Debian, and when I download disk images from the Orange PI or Raspberry PI websites they're Debian.
I know that I can set up FreeBSD on both those platforms, but it's way easier to use the default because it's the thing that's most widely supported and has the most documentation.
Nowadays the internet is so well stocked with answers that I can find copy and paste ready configuration and/or commands for just about everything I need to do with Linux on StackOverflow so the fact that I don't particularly know a lot about Debian doesn't really matter.
I have no idea how or why Debian became so popular, and I have no idea how FreeBSD could replace it.
I hope someone figures it out though! There's a lot to love about FreeBSD.
Oh, that's simple, it's the package management system, debs. The early redhat experience involved opening up the redhat webpage and downloading every rpm related to the system you were maintaining in order to update or install stuff. yum came in 2002.
Debian started with apt-get in 1998. With debian, it was `apt-get update`, `apt-get install thing`, and `apt-get upgrade` and you get everything you want/need to run stuff.
For why not FreeBSD, IDK, but I'll guess that the linux kernel simply got more attention and corporate support. I don't think there's much beyond that.
I am not sure that Debian popularity really had much to do with it. The first Linux distro to really pull away from the pack was Red Hat ( pre RHEL and Fedora ) with the introduction of a package manager ( RPM ). Most of the other popular distros of that era were based off RPM ( Mandrake and SUSE for example ). But RPM at first required downloading packages individually before they could be installed or upgraded. You could upgrade an entire installation to the next release with a CD that had all the new RPMs on it.
Debian solved that problem by introducing the concept of a repository. While .deb files worked similarly to RPM, “apt-get update && apt-get upgrade” was a new thing. Even then, Debian was kind of a niche, power-user distro. The revolution came when Ubuntu created a more user friendly version of Debian. RPM based distros eventually got YUM and other repository based equivalents to apt-get but by then Ubuntu had the momentum. I think Debian became more popular later because of Ubuntu ( though I may have that wrong ). Ubuntu itself had a huge diaspora with many other popular distros starting off as basically Ubuntu modified to address some user complaint or other.
These days, it feels like the torch is being passed to the Arch based distros.
FreeBSD may never regain its position vs Linux but it has maintained its market position pretty well relative to some Linux distros I would say.
It does. What would you say are the features driving that? My guesses are:
1. Users find repository management painful or cumbersome, especially but not exclusively on deb-based distros. On Arch you've basically got a couple of distro repos plus a giant catch-all (the AUR) so there's no real repo management in practice.
2. Speed is a package manager's most visible, user-facing feature, and pacman is very fast, relatively speaking.
3. People have bad experiences of botched release upgrades, and most Arch-based distros just don't have those
4. The AUR has a very low barrier to entry, which substantially soothes the typical 'straying from the happy path' pain point, because it means there are easily available packages for novel, proprietary, and quirky or ill-behaved applications which can be difficult, impossible, or slow to get packaged and maintained so they can reside in a distro's main repos.
In theory this was the e reason. In practice, Linux played nicely with the PC partition table and linux installers became newbie friendly much earlier than BSD. BSD did not have a graphical installer until DragonflyBSD. Also for many users, the ability to coexist with Windows and DOS was crucial. BSD did not advertise DOS compatibility (fatfs) and dual booting.
Ah, the old days of sourceforge, when each package downloaded for configuring something in redhat asked for a couple of another missing packages. Packages that in turn asked for a trio of missing packages. Each one of them asking for four new libraries missing...
FreeBSD just lacks the modern tooling environment that is Homebrew and Docker and I no longer even consider using FreeBSD as a hobby server.
I don’t have much to say about docker except that its dominance can be irritating when you don’t want to strongly couple all your things with Linux (yes, it technically runs on macOS and Windows but not very nicely…). I keep hoping for a more platform agnostic container to steal the show.
I guess it's only Docker that bothers me then.
I'm sure BSD has some unique features and properties that make it very appealing to use for certain things. However, what makes it very unappealing is the fact that there just aren't a lot of people with relevant skills and that the ones that do exist are probably on the expensive side. Many Linux users could probably train up, if they wanted or needed to. But the reality is that most never do that. Either way, hiring people with BSD skills is probably harder than finding people with Linux skills.
The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year. That's a big commitment to run anything and hiring is going to be tough.
Bare metal linux has the same problem but with the difference that a lot of people have experience using it and there are all sorts of companies that can support you with this. And people tend to start using linux in cloud based environments where they can outsource the business of keeping the environment up and running. So Linux allows you to start very cheaply, relying on skills most devops people and developers already have, and then later transition to a bare metal setup with some standardized thing from a company that can offer you lots of support.
No reason BSD could not work like that but of course it has been historically been like that at all and is mostly a thing that shows up on bare metal instead in a few companies that for whatever reason decided that was a good idea; maybe a very long time ago.
Running BSD on a vm hosted on linux is of course possible but probably does not make a lot of sense. Doing it the other way around might make sense if you are in the PAAS/IAAS business but it seems most of that industry has long standardized on Linux. Would there be any benefit for them to switch?
This is flat-out wrong. I single-handedly managed a fleet of over 100 FreeBSD servers running in various data-centers all over the world. 90% Nginx, 10% Apache. Mostly Wordpress websites. The 'brand' was #3 in the world for it's niche. $Million+ revenue.
In my experience, BSD is EASIER then Linux.
The words "single handedly" are a dead give away: you're a single point of failure unless there's more than 1 of you.
It might be easier for you personally. But for a typical organization finding 4-6 of you would be a challenge. And unless they would, it would be a problem waiting to happen.
What should an organization that cannot afford a full operations team do? This is not an OS question.
Of course, it isn't representative at all of what happens in places that actually matter (like California..), but still.
That wasn't the original point though.
The problem presented is "The market for FreeBSD operators is smaller than the market for Linux operators". Which was countered with "I, as one guy, could manage 100s of freebsd servers".
That does not address the initial problem. There are a LOT more sysops people skilled in linux operation vs BSD operation. That means choosing FreeBSD limits your pick of people that could reasonably manage a fleet of servers.
That's how we create software mono-cultures, end up being forced to use mediocre software, and how searching for vulnerabilities becomes very profitable (ransomware etc.). Companies should think about the ecosystems they live in, not only about their sole immediate profit.
I contend that companies ARE thinking about the ecosystems they live in when they pick the boring things everyone else is doing. That's what drives picking boring technology is the ecosystem surrounding that tech (Libraries, articles, experts, education, etc). Ecosystem is more than just the diversity of choices.
Software doesn't live in a bubble and we are long past the days when an interesting language feature can trump modern infrastructure.
A company that decides to write their app in Erlang because it's neat and interesting will be at a disadvantage to a competitor who decides to do the same project in java. Even though erlang has a lot of neat features, java has a giant ecosystem and support structure.
... And a "pinch" of risk aversion too.
There are a LOT more people directly exposed to Linux, that's true.
But anyone who is actually an expert in Linux (an actual old-school sysadmin expert) will have zero trouble adapting to any BSD in no time.
I started with Debian in ~1994'ish (USB didn't work yet, it was probably the stable branch at the time). I had DECADES of experience with Linux.
It was easy to transition to *BSD. This is the beauty of Unix. I still get a brain fumble when I'm bouncing between systems and type the wrong command on OpenBSD vs FreeBSD when I'm doing something common like installing or searching for software. The core mechanics work everywhere. Knowing the right question to ask when searching gets you that last 10%.
How do I restart the $X service on: (OpenBSD, FreeBSD, RedHat, Debian, Arch, ...etc)
(Free|Open)BSD are more simple, while Linux feels more automagical in the way services are managed. I dislike SystemD for this reason and prefer the BSDs.
Certainly, if I was in the position to make infrastructure decisions for my employer (which I am not, plan never to so it will never happen), then the decision has mostly been made for me. In fact, many decisions have been made, and it doesn't just stop at relying Linux and the GNU userland if I rely on a popular distribution.
FWIW, there is a lot of obscured differences between BSDs and GNU/Linuxs as I see, but installing and getting setup on FreeBSD on my laptop felt quite familiar (maybe more culture shocks than anything - like there is no `sudo` in the base system :) )
Yeah, people are making it out like the two environments are totally different from each other. Any competent Linux admin would be able to cross-train on any of the BSDs pretty quickly, and vice-versa. It's mostly a matter of, "Hey Google, where the hell is X in TrendyBSD? Ok, thanks."
If true, this would of course be a great reason not to use BSD, but I've seen too many single person startups on HN using FreeBSD over the years to believe this statement.
The wiser move is to outsource risk like that to cloud services. It will cost you but far less than hiring a team to get your five nines of uptime would. I maintain several clusters and we have a few people that can do some emergency fixes. But I am a bottleneck when it comes to knowing how to. Having BSD in the mix would make this far worse for us.
This is obviously incorrect.
But if you're making a statement about how many people you need to staff 24x7x365 operations, the exact same math applies to Linux.
I remember when MS used to say similar things about Linux.
Not sure where you got your numbers from, but I have been maintaining FreeBSD servers for 2 decades and would estimate the attention a machine needs at about 10% of what a Linux box needs.
I was talking with a longtime Linux security administrator about why he was converting much of his security stack over to OpenBSD and retiring his Linux security boxes in mass.
Similar to what you mentioned, he estimated his maintenance needs for OpenBSD at 5-10% of equivalent Linux systems, and the increased security posture was gravy on top.
For those of us who worked the industry in the 90s and remember the pains of "just use windows like a normal person and forget this weird linux hobby thing", there's some irony in saying that.
Common/mainstream doesn't always (even usually) mean better. With Linux (not Linux the actual kernel, but Linux userspace distros) going in directions away from security and stability in the search for mainstream-ness, the BSDs feel like breath of fresh air these days. Very similar to how Linux felt back when everyone was telling me to run windows.
Meanwhile WhatsApp ran their entire infrastructure on FreeBSD and were able to serve a billion end-users with not a lot of people.
Netflix still uses it for their caching boxes and probably elsewhere in the infrastructure.
It's the price of not being dependent on IBM, Oracle, or any other customer-hostile company. Besides, frankly, those 4-6 people will provide _way_ better quality of service than offshoring.
The client opted for FreeBSD as the OS seemed to handle much bigger traffic without breaking a sweat (HAProxy, Nginx, PHP & MySQL)
Overall I enjoyed the exposure to FreeBSD and learned a lot in the process.
I really would like to know but only on practical points.
(Not like "the documents are good", "well integrated" kind of points that never are primary points to use FreeBSD)
I think this is by design. If things are too different from one os to another, it raises the barrier to entry and hampers adoption. Furthermore, Linux distributions often also rely on things like standardized tooling and file system layout to ensure backwards compatibility
There are people who try to do new things in the space (gnu guix and nixos come to mind), but they tend to be comparably fringe when put side by side with something more mainstream (and perhaps battle-tested) like Debian or BSD
> [about jails] They are also very easy to debug and troubleshoot comparing even to plain Docker – not to even mention Kubernetes which requires whole team of highly skilled people to maintain.
Yeah, of course, a single-node container tool is easier to run than a Kubernetes cluster.
> Can you tell my how many steps (and which ones are required) to rebuild CentOS or Ubuntu for example without Bluetooth support?
Why do I need to rebuild without Bluetooth support?
> When using systemd(1) you never know how the services gonna start because it will be different each time. Zero determinism.
systemd starts services in dependency order. The author makes it sound like systemd just randomly shuffles the services each boot for fun.
I'm not sure if this is still the case, because I no longer use Linux, and I may be misremembering it. But IIRC a good while back, there was no way to guarantee service start order at boot.
You could specify dependencies for some services, but even then, if there was more than one choice of dependency order that satisfied the requirements, systemd did not guarantee that the same one would be used on each startup. Otherwise, services with no dependency specs (or groups of services at the end of the same dependency chain) would get started in parallel. If you really wanted to start a sequence of services in order, doing so by specifying dependencies in separate unit files was really painful and basically impossible to debug, especially since dependencies weren't exactly easily described (various combinations of After=, Requires=, Wants=, BindsTo= that went both ways between targets and service links in the dependency chain).
Please note the "I may be misremembering it" part. My life is a lot happier now that I no longer need to care about Linux userspace stuff so I may be repressing some memories :-D.
Edit:
> Why do I need to rebuild without Bluetooth support?
The author chose a lazy example. Yeah, you don't usually need it. A better example: rebuild with `CONFIG_BFQ_GROUP_IOSCHED=y` to enable proportional weight division of disk bandwidth in CFQ.
I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there. Most apps are messy and starting a system tends to be a messy affair in of itself.
The much simpler solution to specifying services to start in order is to write a script and have one big service start and terminate them.
But I can't really imagine a real world scenario where that is somehow better than just giving each service the dependency definitions it needs.
edit: the simpler solution to compiling the kernel is just blacklisting the module. Then bluetooth won't be loaded obviously. Though not everything can be a module, in practise I've found it to be rare that I was looking for a kernel option to be enabled that wasn't in my distro (but then again, I run most of my personal stuff on archlinux, which ships a near default config of the kernel anyway).
I mean... sometimes you have to do it, because that strictness really is there.
> the simpler solution to compiling the kernel is just blacklisting the module.
What module? I'm not talking about removing a module, but changing a compile-time option for one.
Removing a module is certainly best achieved by just blacklisting it, that's why I mentioned this as a lazy example that the author picked. (But, FWIW, even that has unexpected consequences. A while back, for example, you could (sometimes significantly) improve the startup time of most embedded devices running Linux by removing the modules instead of blacklisting it because going through the list of blacklisted modules is surprisingly slow. That's probably not a relevant use case for what the author of this article is describing though)
A good init system IMO doesn't have deterministic behaviour built in but rather as emergent property. Your start order falls out of the service definition.
---
The bluetooth module. Linux is highly modular and you can blacklist modules you don't want. And you can even compile modules after the fact. If you need bluetooth but your distro didn't ship it, you can in fact compile just that module and load it.
Only some core options need a full recompile of the kernel but that isn't too terrible on most distros (apt source, Arch's ABS, etc.) either.
What bluetooth module? `CONFIG_BFQ_GROUP_IOSCHED=y` is a cgroup-related option.
It's not pretty, and not because of a lack of tooling (apt source, ABS, whatever). The problem is that, since there's no "standard" configuration that you can depend on (unlike FreeBSD), you can't just take a "standard" system and reliably change a compile-time setting (or compile a module, or blacklist a module). There are a lot more moving parts (other compile options enabled downstream, additional patches applied downstream, especially in LTS kernels, compile-time options for userland applications and so on) which vary from one distro to another.
I personally see the value of this approach. I think it's more flexible than what FreeBSD does. But it is far more time-consuming and, generally, pretty nerve wracking.
Even upgrading your kernel will ensure the option is enabled. And it'll ensure that any downstream modifications done by wherever you pull the kernel from has them enabled too.
In that case, wouldn't it be more correct to specify the strictness explicity through service dependencies?
Service dependencies form a DAG. Sequential start of services can be modeled by a DAG in which every node except the first and the last one has exactly one dependency and one dependant. So systemd way of starting services is a superset of the traditional, sequential way.
- Unit properties can be specified both ways. For example, an unit can specify both that it should start after another unit (After=) and that it should start before another unit (Before=). So if you have two units, B can start after A either because B's definition includes After=A, or because A's definition includes Before=B.
- Order and dependency is specified separately. If B depends on A (specified by Wants=A in B's definition) that does not, in fact, guarantee sequential start.
- Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets.
That's true. However, most software can be easily misconfigured if you don't know what you're doing. And when creating any kind of DAG, it's implied we need to avoid cycles. I suppose systemd could use a tool for visualizing service dependencies and order.
> Order and dependency is specified separately
Order is stricter than dependency, and it slows down the whole process. If things can run in parallel, they should. If they cannot, then we should specify it explicitly. Leaving out order would make systemd useless for situations when order matters, and leaving out dependency would slow the whole process down.
> Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets.
I agree, the rules are pretty complex. I don't like that about systemd at all. Combined with the fact that there are 175 different options [0] you can use in a unit file makes systemd really unpleasant for writing any kinds of services. I have a couple of boilerplate unit files I've written long time ago and I just reuse them with changed parameters.
[0] check for yourself:
cat <(man systemd.service) <(man systemd.unit) <(man systemd.exec) | grep '^ [A-Za-z]*=' | sed 's/=.*/=/' | sort -uIn which case you specify service dependencies and systemd will start them one after another, you know, you have the After= option in your units just for that.
In all other cases does it matter jack shit, to put it bluntly, if your bluetooth services start after your NFS share exports or before them? Or is it some sort of OCD speaking?
First off, After= specifies order, not functional dependency. This doesn't do what you want which, I think, kind of proves my point. The complaint in the original article (and mine) isn't that it's impossible to specify order between two services, which, yes, you can do just fine. The complaint is that doing so repeatably across boot times is impossible (because systemd literally and explicitly does not support it) and that debugging the "weak" version of it is really difficult.
It's really difficult because Aftter= is, literally, one twelfth of the story, possibly less. Order and dependency ae specified not just though After=, but also Before=, Wants=, Requires=, WantedBy=, RequiedBy=, Requisite=, RequisiteOf=, Triggers=, TriggeredBy=, PartOf= and ConsistsOf=.
Ordering and dependency are treated separately by systemd. I think that's a good design trade-off but it's not without consequences.
> specifying dependencies in separate unit files was really painful and basically impossible to debug
This is actually quite easy to check and to claim otherwise is FUD
It's only easy to check if you have a small number of dependent services that mostly go one way. On the general case it absolutely isn't easy to check. If I had a dime every time I've seen non-trivial chains of serial operations implemented through a systemd target that just runs a shell script, I could erect an ice statue for Stephen Bourne and it would be made out of the frozen tears of everyone who's had to deal with both systemd and shell scripts.
If the services boot after their dependencies, why do you care what order they boot in?
Plus, it's rare to find a CPU with fewer than four cores these days, so 'order' becomes harder to reason about.
Second, you care about it in scenarios where predictability is required. If your customer says they want their smart TV or their POS or whatever to boot in no more than X seconds under normal operating conditions, it's really not cool if the system can take a slightly different way to multi-user.target. Dependencies across separate chains can contend for resources, for example.
"But these are embedded systems, you should just run rc.local" I hear you say? Right. These things run like fourty services, from telemetry to user interface and from firmware update to encrypted cloud backup, half of them written in Node.js, on top of a system that's basically built for systemd. It's not something you can extricate yourself out of.
I don't know if there are equivalent examples in the server world (not my field), but I wouldn't be surprised if there were.
Have you tried Bluetooth on FreeBSD? It's an unstable mess which does not support any newer device. Bluetooth always worked for me out-of-the box on any reasonable Linux-based OS. FreeBSD was like 20 years old memories of Linux Wi-Fi Cards. Remember 'ndiswrapper'? That's how bad Bluetooth on FreeBSD is. So the author probably assumes that Bluetooth is a piece of shite everywhere and want even Linux programs without a support or so.
Or your hardware doesn't have any Bluetooth and the relevant modules are never inserted.
Or you insert the module manually to send it a packet that will open a hole that... wait, to do that you need to have host and root access already.
My freaking god, when are fanboys going to grow a clue already?
Why would you when you can just disable the kernel module, then nothing bluetooth works. Why rebuild ?
For a prime example see hash maps in Go, which is specifically non-deterministic when iterating over them to prevent users from relying on any kind of implicit behavior.
> "When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next."
Except now you just _know_ that somebody out there is using hash map iteration order as a source of entropy. ;)
> "Is map iteration sufficiently random for randomly selecting keys?"
https://stackoverflow.com/questions/41019703/is-map-iteratio...
Systemd has a dependency graph which you can influence, but there is no guaranteed execution order and it does change between boots.
That's an acceptable thing or a bad thing depending on your use-case.
I think the point here is that any code on your system is a potential security liability, regardless of whether the relevant feature is active. Removing linked in code removes potential security liabilities and as such it is always a good thing.
Regarding the original article's question Can you tell my how many steps . . . Ubuntu for example without Bluetooth support?, its not actually that bad
apt-get source linux-image-$(uname -r)
Finally. I'm surprised at how many posters here deflected this point, because last I checked it's actually really easy on major distros.
I guess that tells us something about how many Linux users on HN have ever compiled their kernel, that most were like "LOL why?" and not "sure, it's easy".
zzz... Then I guess any binary distro that you don't compile your own kernel with absolute minimum requirement aren't good? Not sure how Red Hat customers are doing their business then.
>>comparing even to plain Docker – not to even mention Kubernetes
>Why do I need to rebuild without Bluetooth support?
Because you don't need it? Or you don't want it, but cannot deactivate it in bios? Security and Kernel-size
>> services gonna start because it will be different each time
Please read and don't make your own interpretation like with docker -> kubernetes
Just blacklist the kernel modules, then. Or even plain delete them from disk.
Compiling kernels is really a lost art that many people have never done. It’s probably best to avoid too much of that in production until it’s absolutely necessary.
Well yes, being organized is always important, like a customer of mine wanted all Linux server with GUI and installed all of them as "Desktop-Role" aka preempt-kernel.
Gui-Server...bleh..but Customer is King, but i could at least change he's mind about the kernel so Gui-Server-Role it was.
A slimmed-down kernel make the difference from ~100MB (kernel) + 32MB (Modules) to 2MB (Kernel + Modules), faster load, or for smaller devices, and overall less potential attack surface.
This is about easily disabling support for one thing. The OP says it's easier in FreeBSD because you add a line to a text file and recompile the kernel. We're saying it's also very easy in Linux even without recompiling the kernel by simply blacklisting and/or deleting a module. Alternatively, recompiling the kernel is also quite easy but what's the point? To shave off 5kb from the kernel, or not even that, since the module is external anyway? My time is worth a lot more than those potential few kbs.
By the time you're fine-tuning your kernel to be the absolute minimum for a specific machine, it doesn't really matter if it's FreeBSD or Linux. It will take time and probably quite a bit of trial and error. And then again, if you have ever run `make menuconfig` on a Linux kernel tree you probably know it's pretty easy. In fact, the discoverability is excellent there, since the options are presented to you with explanations. Is that harder than manually editing a conf file, having to know beforehand exactly what lines to add/delete/edit and with what values? If you think it is, you can also edit the conf file for the Linux kernel.
I have nothing against FreeBSD, but this argument is total nonsense.
Hint is was not about about Bluetooth ;)
But maybe everyone else is wrong, just not you.
The magic of reading....
By the time you want to slim down the kernel that much, Linux, OpenBSD, FreeBSD, they're not that different.
That was not the point of this thread, so back at ya:
> The magic of reading....
>By the time you want to slim down the kernel that much, Linux, OpenBSD, FreeBSD, they're not that different.
Yes, but you don't do that by blacklisting modules right? Because that was your solution ;)
Otherwise it's just an implementation choice: recompile kernel, or blacklist+delete modules.
Oh yeah, since we care about security so much, let's have a whole fucking C compiler suite on every machine because what if we need to recompile the kernel to mitigate a potential problem that might not even be there!?
If you really care that much, you delete the modules and run depmod. It's fast and you don't need to have a compiler on hand.
By the way, as an example, you can also disable IPv4 and IPv6 in the kernel, I'm not sure how to do it in Linux.
But why so aggressive? No one attacks your substitute religion.
Okay, you can set up a whole container so you can recompile your kernel to your heart's delight. Fine. How does it scale? How do you distribute your new shiny kernel to hundreds of machines and keep track which is running which? What if you make a mistake, is it easy to roll back? How easy is it?
Also, need I remind you that a world where you don't have to (but can if you really really want to) compile things to get the results you want is infinitely better than a world where you have to compile things?
Like you distribute a iso or a image, is that really so impossible for you?
>How does it scale?
As much as you want.
>What if you make a mistake, is it easy to roll back?
See you don't even know zfs or be's..or hell version's??...your a evangelist and i don't like them.
>I know, when you run out of any arguments of merit
Seams like you run out of arguments, again you can create your own image of freebsd without compiler, nfs, zfs whatever you want. But your are probably happy having the cruise-ship for the fishing side trip. Have fun with your religion.
He works at Kyndryl do you know what it is/was?
Everyone forgets the GNU in GNU/Linux.
Everyone forgets the unix philosophy.
So they get on linux, and with no care of licensing, bloat, etc, tend to overutilize the vast package repos without taking a moment to think about their computing strategy.
Computing is inherently, a philosophical choice!
So for me, only having actually embraced the four computing freedoms as articulated by those such as RMS and Eben Moglen and the FSF, I transitioned into working towards making as much of my compute stack gpl-first, with compat licenses allowed but not preferred, and later, gplv3+ preferred.
What I found was that I started gravitating to tools that were often built in GNU-land tools that had been ignored while chasing the latest thing. Emacs probably being the largest game changer for this. But often third party tools written in gpl tend to remember and adopt the unix philosophy of doing one thing and doing it well, and are still a part of my userland.
Truly, there is much more behind the oft told joke, GNU is my operating system, Linux is just my (current) kernel.
Linux complexity hasnt skyrocketed that much, the available ecosystem around it core has. Thus, when keeping the core pure, I find gnu/linux just as easy to have a mental model of as freebsd. FreeBSD keeps to the unix philosophy by nature, hence the at a glance disparity.
I'm still a big fan and have at least one of each major BSD variant running on one server or another just to keep up with developments across the space. So many innovations we take for granted come from the BSDs or were incubated there and they continue to innovate and refine the OSes in ways that I think more people should pay attention to.
Just a few of the things that we can thank BSDs for:
• The 'TCP/IP stack' • OpenSSH • OpenSMTPd • OpenBGPd • OpenNTPd • LibreSSL • privilege separation • pf • Darwin (The MacOS Kernel) • The Ports system (pkgsrc in NetBSD and DragonflyBSD. Inspired Gentoo) • A whole slew of security innovations : https://www.openbsd.org/innovations.html • NetBSD can run your toaster: https://wiki.netbsd.org/ports/ • DragonflyBSD's HAMMER filestystem • OpenBSD's Todd Miller also looks after development of sudo
A couple of weeks ago I decided to try it again for an amd64 server and a Raspberry Pi (model 1), headless, without desktop.
The ports collection for the amd64 is extensive. Undoubtedly it is not is not as wide as Debian. FreeBSD had a binary port for Zig, which Debian doesn't have in any of its versions. The FreeBSD ports seem quite fresh, too.
The letdown for me is that the binary ports for the Pi 1 (which will also include the Pi 0) on FreeBSD was much more restricted compared to amd64. I don't want to get involved in compiling from source. I did try compiling Zig, and there seemed to be a problem with the version on llvm involved.
This means that for the Pi 1 I'm going back to Raspberry Pi OS.
FreeBSD vs Linux: they each have their pros and cons. A lot of the technical arguments on either side tend to be overblown. You pays your money and you takes your choice. But if you held a gun to my head and said I could only choose one, I'd choose Linux.
I'd say, though, that if you like Slackware, then you'll probably like FreeBSD more.
Hehe, someone saying this exact thing to me was what made look into BSD for the first time, and whoever said it to me was correct.
On the desktop/laptop, I prefer GNU/Linux, because the hardware support etc. is just much better. My home server runs FreeBSD, though, and it hasn't given me any trouble in almost seven years (other than a µSD card dying, but I don't think the OS is to blame here).
If you do have a problem, you invariably find yourself in a byzantine hell maze where you are celebrating if you manage to find a cryptic error message (often you aren't even entitled to that). It can be incredibly nasty to debug as there is no actual code to step through, nothing to reason about. There is no where it went wrong.
Pretty much the only thing about shell scripting that is useful and not easy to do in other languages is input/output redirection and piping. Service managers should take care of things like figuring out where stdout and stderr logs are sent to, so you shouldn't have to do that stuff in your service scripts.
Thus there is no benefit to shell compared to other languages / formats, and there are a lot of problems with shell scripting otherwise.
You don't have to. The fact that Linux had anachronisms like that wasn't because of shell scripts, it's an entirely orthogonal issue; a typical rc script in, say, FreeBSD, looks like this: https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/.... It's declarative, it's easy to understand, but it also provides you with flexibility when you need it, as opposed to one-off hacks with custom, fixed functionality and random syntax.
I've taken to periodically running a task that allocates craploads of memory and lightly dirties it to force the OS to "collect" the laundry.
Googling it finds a random smattering of other people who have the same issue but no solutions.
So my take on FreeBSD is that it's pretty nice but without the larger user base of Linux it has more weird bugs that don't get teased out.
Why FreeBSD though? I used it for two years in college, so it has a sentimental quality for me :) But also, I want to catch up when life took over (i.e. job, etc.) and understand more of my own and other biases about UNIX operating systems, particularly as I understood and now understand it. It is also a way to comfortably go through problems I encounter without mental commitments. For example, I have two issues now: the wireless doesn't load after resume sometimes and sometimes X crashes. It's ok it happens - the FreeBSD is not even setup for desktop use by default. Anything I learn here like this gets applied to work, even if it is on Linux systems. It's a form of freshening up my problem solving skills, something I miss sometimes from work.
BTW, vermaden's guides are great. I use his desktop configurations and they are filled with things to look into.
I don't know that tool but I like its 5th Element name.
OSS is the unix de-facto standard. All problem with OSS was fixed in OSS4.
OSS is not a de-facto standard, and has many issues that led to us moving on from it back in the late 1990s.
It might offer you precisely what you want, but it does not solve all the problems, and in addition is still absolutely the wrong API to offer for application development. Hint: you don't use open/read/write/close to do video, and for some similar reasons and some different ones, it's the wrong model for audio too.
I've been doing audio development on Linux (and macOS and tangentially Windows) for more than 20 years. I wrote device drivers for pro-audio interfaces, application frameworks (JACK) and large applications (Ardour); I used to have to spend the closing part of the aughts and early part of the 2010's explaining to seriously misinformed people what all the problems with OSS were. That doesn't mean that there have not been issues with audio on Linux, but OSS (4 or otherwise) is not the answer to those problems and never was.
The issues are too many (and too old) for me to list them all, but the biggest of all was that OSS tries to do everything inside the kernel, which is (a) inefficient (b) prevents the use of floating point (the preferred sample format for mixing) (c) makes inserting processing elements within audio streams much more complex (and likely to be rejected because of Linus' practice of mechanism not policy). Even macOS, which originally implemented its audio mix engine in the kernel, gave up on this idea, and moved it into user space (coreaudiod).
OSS's API also made dealing with pro-audio interfaces quite difficult, because of channel layout. I can't recall if OSS4 fixed this, but OSS also did not offer mmap. When it comes to device control, you really not want to export thousands of OSS_IOCTL_FOOBAR constants to describe every control on every device, so ALSA made an attempt to create a parallel control API (parallel to the I/O API). This has been partially successful, but not entirely (note that on other platforms, there is frequently a dedicated device control app; more recently a few h/w makers have shifted to provide a web interface for device control)
Linux is kind of famous for this approach. From what I've seen most problems with OSS were either problems with Linux implementation, and could be fixed without inventing a new proprietary API, or problems of OSS being too low-level, and thus could be fixed by providing a higher-level API on top of OSS (which userspace part of ALSA kind of is, but my question was about the kernel API). From what I can tell pretty much every single one you've mentioned above fits into those two categories - except device control, but I honestly have no idea what it is; can you give some real-life example?
You want to adjust the gain level used for capture. Or hardware gain control for playback. Or which input stream will be captured. Etc. etc.
By your apparent definition above, the kernel API doesn't matter, it is inward facing, and really just affects device drivers. Nobody cares, because within a couple of months ALSA had all the drivers OSS had, and then rapidly gained many more (partly it was much better structured for writing drivers than OSS was).
Even without an application framework like JACK though, it matters what the API presented to user space is, and ALSA made the deliberate choice to essentially completely hide the actual kernel interface and wrap it in libalsa. This allows for interposition (without using LD_PRELOAD) and very flexible configuration, all occuring in user space. Fun fact: "reading" audio data with ALSA is actually done with an ioctl() call!
>By your apparent definition above, the kernel API doesn't matter
Replacing a standard, portable API with a proprietary one doesn't matter to Linux - but it makes life harder for everyone else.
On an RME9652, there are 3136 gain controls on that single device alone.
On most Intel HDA-compatible chipsets (i.e. the builtin audio for just about every off-the-shelf motherboard in existence these days), there are between a dozen and 500 controls.
> Replacing a standard, portable API with a proprietary one doesn't matter to Linux
I have no idea what this is supposed to mean.
Not that I don't believe you, but quick googling shows this card doesn't have analog, so... what do those gain controls do?
>On most Intel HDA-compatible chipsets (i.e. the builtin audio for just about every off-the-shelf motherboard in existence these days), there are between a dozen and 500 controls.
Again, what for? I don't remember Windows or OSX showing 500 controls for internal sound card. More like five - two gains, two input/output dropdowns, left/right.
>I have no idea what this is supposed to mean.
OSS wasn't perfect, but was portable. ALSA is proprietary. Forcing it is no different from other vendors forcing their proprietary replacements for open solutions.
Yes, Windows and macOS won't show you those controls, and neither will Linux (for the most part). However, ALSA provides a standardized API to access them, and utilities like alsactl and amix can be used to set them in a device independent way.
You seem to be using the word "proprietary" in a very different way than most people in this world and on HN use it. ALSA in GPL'ed, part of the Linux kernel, and part of most typical Linux run-time environments, and has been worked on by hundreds of individuals. OSS4 was developed by 4Front Technologies, and they made money by developing non-GPL, non-open-source device drivers under contract. There are no such drivers within ALSA, and there have even been some attempts to port ALSA to other posix-y OS's, generally but not entirely limited to the user-space component.
OSS was not portable to anything except a few other Unix-y systems that also used OSS. That did not include Solaris or macOS/OSX, and at the time OSS was developed for Linux, it was not available for any of the *BSD systems (that came later). The only sense in which it was "portable" was that it provided /dev/dsp as did several other Unix-y systems, which is useful for doing party tricks on the command line, but very little else. ALSA still (or used to) provide that too, for back-compatibility with a tiny number of toy applications that used it.
> Also maybe bit width, and number of channels, and sampling rate
No, those are part of the setup for the PCM (I/O) API. An application sets those when using the device.
The controls I am referring to are independent of audio streaming by an application.
Is unix actually used for "serious audio"? If not, talking about "de-facto standards" doesn't make any sense.
I'm sure there are one or two SGI boxes still ticking out there, but I haven't booted mine in months.
Exaggerating a niche case doesn't do it any justice. I usually use Ubuntu but never had the system become unusable with package updates for 15 years.
People say FreeBSD is more integrated but never felt it brings any benefit from user's perspective. Tried to like FreeBSD by using it on a personal server on several occasions but I see no reason to use it anymore because it lacks Homebrew and Docker which is becoming more essential to make a comfortable environment with modern tools and apps.
The only better part is zfs integration but Ubuntu also has a very painless integration of zfs, I see no advantage at all.
> When using systemd(1) you never know how the services gonna start because it will be different each time.
What is this guy talking about? Apparently the article is heavily biased only trying to make it look like FreeBSD is saner but apparently not.
I sometimes feel like some people live in an alternate dimension where everything is broken all the time. I can't remember a single time that a Linux system I use was rendered unbootable from a regular update. It happened once, when I was messing around with nonfree Nvidia drivers under OpenSUSE, which had (has?) poor support for such things.
I know it does happen to some people once in a while, but I feel like some people complain about it as if it happened to them constantly.
And bare metal runtimes like Arduino and ESP-IDF.
Kind of proving the point GNU/Linux partnership was a lucky one.
BSD also somehow lost the embedded and appliance market where GNU is nowhere to be found. (Yes, we all know of the two or three exceptions like PlayStation and a couple of NAS vendors, which just proves the point.); that is harder for me to understand. Is the driver support and more widespread knowledge of the Linux kernel to blame for that?
Still, that increase in alternative OSes seem to be triggered by not wanting to deal with Linux despite of that.
But the freebsd license isn't listed in this page : https://doc.dl.playstation.net/doc/ps5-oss/index.html
So I'm not sure if the first page is correct.
For PS4, the freebsd license was listed here : https://doc.dl.playstation.net/doc/ps4-oss/index.html
Playstation is made by Sony Interactive Entertainment so they probably have different directives/rules
So it doesn't matter what FreeBSD can offer if I can't run it on the hardware I have available. If I'm stuck running it in a VM why would I bother with it?
I have moved to using FreeBSD for my servers though, and am happy with it for the most part.
For instance, jails are nice -> docker, podman,... exist. Might be better or worse for your use case, but similar enough that it is not worth switching for.
Or ZFS is nice -> ZFS is still nice and also available on linux. Btrfs also exists.
Boot environments are nice -> Snapper does this and more and things like NixOS or Fedora Silverblue go much further still.
Popular package is in the repos of ... -> It is in any OS's repo.
Package manager is good -> Even Windows now includes apt-... er, winget https://docs.microsoft.com/en-us/windows/package-manager/win...
Kdeconnect offers nice integration of your phones, tablets and pcs -> Apple copies it, MS copies it; gsconnect, mconnect....
Combine that with the fact that switching always involves some uncomfortable adjustment and any "killer feature" becomes -> Eh, now I will have to wait a bit until it is available on the OS I am comfortable with.
But having some variety is good thing in itself, IMHO. I recall some major DNS company making a point of always running a mixture of various hardware/OS platforms to ensure that a problem with a particular configuration would not take down the entire site. (This is a bigger issue, too - on the server and desktop, you basically have the choice between Windows and some variant of Unix[0]. There are a few alternatives on the server, OS/400, OpenVMS, z/OS, etc., but those are pretty niche.)