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.
> 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.
This also annoyed me so I implemented one reboot way with ZFS Boot Environments - described here in details:
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:
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.
> 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.
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.)
I can generally rely on FreeBSD to actually boot up properly, after doing a major upgrade.
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.
FreeBSD was the first *nix distro I used, and I used it for many years as both a server environment and a workstation.
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.
> I have no idea how or why Debian became so popular
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.
Unless you absolutely need BSD in production, there's a lot to be said to just use something more common/mainstream instead. I.e. Linux. It's probably going to be a lot cheaper and there's not a lot it can't do.
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?
In all fairness all these comparisons and all these BSD vs. another BSD vs. Linux OS wars are becoming long in the tooth. There haven't been any news or revelations in a long, long time. Want to try a BSD (or a Linux distro) on a VPS? Good for you. Want to do it on a laptop? By all means. Want things to work out of the box? Get a system with an OS preinstalled (and supported). Otherwise, the differences between the OS you'll find will be minor.
I feel like these articles always do a disservice by misrepresenting things about Linux. Just some parts I stumbled over:
> [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.
> Why do I need to rebuild without Bluetooth support?
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.
I think determinism would be way better than a system with some pseudo random setup.
I think hand waving away the specific language used, ie "determinism" without really talking about what it means or why it does (not) matter is dishonest.
> Why do I need to rebuild without Bluetooth support?
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
What’s useful about FreeBSD is that one can understand the whole system and have a complete model of it in your mind. Then you feel like it’s an extension of yourself. With Linux complexity skyrockets and sub-systems are not always consistent.
Here is the main disconnect I've found as a user of both in the past (FreeBSD 3-4 era).
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.
If you can fully understand just the kernel, I think you have managed to achieve some sort of god-like transcendence. This is well above the abilities of us mere mortals. I don't even want to talk about understanding the whole system (maybe back in the 70s...)
I got started with BSDs just over 20 years ago when I needed to setup some servers and firewalls and the choice was between linux 2.2's ipchains or OpenBSD's pf. I was blown away by the simplicity of the firewall rules syntax for pf and then became enamoured with other niceties like the emphasis on security and correctness, the logical filesystem hierarchy, the simple licensing, the UNIX pedigree (sort of), the completely integrated build system for userspace and kernel, the fact that you had to actually turn services on rather than have several daemons running unnecessarily, and MAN pages that actually were useful and had examples and everything.
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
My main desktop is Debian Stable. A few years ago I tried FreeBSD, but its desktop didn't work properly.
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.
My experience with declarative set-up tools ranging from systemd to gradle to kubernetes is that they're amazing as long as you don't have any sort of problem.
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.
I feel a lot of the points in the article boils down to "it's not what I'm used to". I mean, that's totally fine as an argument for not switching away if you already run FreeBSD, but not so much as an argument for switching to it.
A shell script _is_ a way of specifying what binary to run. It's just that it's standardised and relatively well thought-out, as opposed to one-off hacks, like with systemd.
This is a big sticking point for me when evaluating other init systems / system service managers. There are a lot of weird and bad things about Systemd, but the declarative service file format is a big plus to me.
My only experience with FreeBSD is running a TrueNAS server, and there's some weird bug where once a month or so all the RAM (literally like 70 GB) gets eaten up by FreeBSD Laundry which crowds out the ZFS cache causing performance to tank and then never goes down again. I've not installed anything "weird", just running a few basic jails like FAMP.
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.
I have been toying again with FreeBSD after a 15 year absence for fun. The intent of the project was to document every experience I have with it, from setup, to packages installed (with shell scripts to cover setting it up) and then do things like catch errors. I installed and toyed with it on another laptop and just moved to my main personal laptop a few days ago.
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.
Is there a tool like multipass out there where I can boot and run a FreeBSD VM to try it out easily? Even if there were some bash script in the form of a Gist that curls an ISO and boots in in QEMU that would be fantastic.
It might (just barely) be an accurate description of (some) of the issues, but it is absolutely not "so true".
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.
One thing that FreeBSD really was great at was setting up traffic shaping for a large network. I set up per-user shaping of all DSL users for a rural ISP in maybe a couple commands and it worked very reliably. Meanwhile in Linux I've tried several times to set up shaping, and anything more than just the most basic setup I've never really gotten working reliably.
> After a week or month many of these packages will get updates sometimes making this CentOS system unusable or even unbootable (recent GRUB Boothole problem for example).
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.
Somehow I think there is some irony, that although FreeBSD lost to GNU/Linux in installed based, there is a growing number of MIT/BSD/Apache OSes targeting the IoT space like Azure RTOS, NuttX, Zephyr, Mbed.
And bare metal runtimes like Arduino and ESP-IDF.
Kind of proving the point GNU/Linux partnership was a lucky one.
I always want to love FreeBSD, it's the first Unix system I used with any regularity many years ago. Every few years I get some inspiration to load it up and play. Without fail every time I have tried I've run into some problem with hardware support. From it just refusing to boot on an Opteron server to networking just not working on a mini PC. Ubuntu on those same machines had zero problems.
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?
[+] [-] Mister_Snuggles|3 years ago|reply
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...
[1] https://wiki.freebsd.org/PkgBase
[+] [-] vermaden|3 years ago|reply
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.
[+] [-] dsr_|3 years ago|reply
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.
[+] [-] gunapologist99|3 years ago|reply
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.)
[+] [-] icedchai|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] LennyHenrysNuts|3 years ago|reply
[deleted]
[+] [-] dools|3 years ago|reply
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.
[+] [-] cogman10|3 years ago|reply
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.
[+] [-] jillesvangurp|3 years ago|reply
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?
[+] [-] Koshkin|3 years ago|reply
[+] [-] mxey|3 years ago|reply
> [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.
[+] [-] alxlaz|3 years ago|reply
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.
[+] [-] mm007emko|3 years ago|reply
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.
[+] [-] ungamed|3 years ago|reply
Why would you when you can just disable the kernel module, then nothing bluetooth works. Why rebuild ?
[+] [-] sagonar|3 years ago|reply
[+] [-] dijit|3 years ago|reply
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.
[+] [-] steeleduncan|3 years ago|reply
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
edit your options and get compiling.[+] [-] nix23|3 years ago|reply
>>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
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] ahoka|3 years ago|reply
[+] [-] SnowHill9902|3 years ago|reply
[+] [-] arminiusreturns|3 years ago|reply
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.
[+] [-] 5e92cb50239222b|3 years ago|reply
[+] [-] mekster|3 years ago|reply
[+] [-] vogon_laureate|3 years ago|reply
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
[+] [-] blippage|3 years ago|reply
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.
[+] [-] frankjr|3 years ago|reply
[+] [-] marginalia_nu|3 years ago|reply
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.
[+] [-] Saint_Genet|3 years ago|reply
[+] [-] trasz|3 years ago|reply
[+] [-] nerdponx|3 years ago|reply
[+] [-] ape4|3 years ago|reply
[+] [-] kalleboo|3 years ago|reply
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.
[+] [-] ainar-g|3 years ago|reply
[+] [-] bigpeopleareold|3 years ago|reply
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.
[+] [-] steeleduncan|3 years ago|reply
[+] [-] hericium|3 years ago|reply
I don't know that tool but I like its 5th Element name.
[+] [-] znpy|3 years ago|reply
[+] [-] efortis|3 years ago|reply
[+] [-] j16sdiz|3 years ago|reply
OSS is the unix de-facto standard. All problem with OSS was fixed in OSS4.
[+] [-] PaulDavisThe1st|3 years ago|reply
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.
[+] [-] elpescado|3 years ago|reply
Is unix actually used for "serious audio"? If not, talking about "de-facto standards" doesn't make any sense.
[+] [-] linsomniac|3 years ago|reply
[+] [-] mekster|3 years ago|reply
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.
[+] [-] pjmlp|3 years ago|reply
And bare metal runtimes like Arduino and ESP-IDF.
Kind of proving the point GNU/Linux partnership was a lucky one.
[+] [-] haunter|3 years ago|reply
[+] [-] niea_11|3 years ago|reply
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
[+] [-] giantrobot|3 years ago|reply
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?