Live data from Hacker News

Why I run FreeBSD for my home servers (2024)

aumont.fr

81–90 of 251 posts

Re: Why I run FreeBSD for my home servers (2024)

#81
For me, it's about friction vs total understanding. I accept that I don't know and won't know/understand everything.

I can install a relatively minimal Linux server (usually Ubuntu Server), disable snaps, install Docker community, copy my app directories (with docker-compose.yaml files in each) and `docker compose up -d` in each directory and be (back) up in moments. When I was trying a couple different hosts for mail delivery, the DNS changes took longer than server setup and copy/migration. It was pretty great.

It's also lead me to a point where I'm pretty happy or unhappy with given applications by how hard or easy a compose file for the app and it's dependencies are. Even if, like my mail server, the whole host is effectively for a single stack.

No, I'm not running more complex setups like Kubernetes or even Swarm... I'm just running apps mostly at home and on my hosted server. It's been pretty great for personal use.

For work, yeah, apps will be deployed via k8s. The main projects I'm on are slated for migration from deployed windows apps, mostly under IIS or Windows Services, to Linux/Docker.

Re: Why I run FreeBSD for my home servers (2024)

#82
post #65

Linus is too in-bed with Microsoft. RedHat the main powerhouse behind Linux ans is now owned by IBM. And Ubuntu is just corporate Debian who pushes their own proprietary (Flatpak) software which is cobbled together and just generally sucks. Systemd is bloated in wanting to do everything at once. I have never had a linux systemd distribution that just shutdowns without prompting me "waiting x/2minutes - x/y retries".…

Wifi? You mean the thing where people often resort to running a Linux VM to handle it?

I have had no issue with Wifi on multiple occasions. Works just fine nowadays without any Linux compatibility add-on.

Wifi not being available isn't the fault of FreeBSD. If vendors actually gave open sourced drivers to their products and not locked behind a proprietary binary blob then we would be in a completely different world.

I can recall when WiFi on Linux was pretty much non-existent until deals were made back in 2018.

So stop throwing that this is FreeBSDs fault, it's 100% down to the vendors locking down hardware.

Re: Why I run FreeBSD for my home servers (2024)

#83
post #13

The main complain of the author seems to be that linux use systemd. In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic (ex: when this and that happen, start doing this, except when such and such are present) Most of the problems I've seen come from trying to duplicate systemd functions: in the author example, why bother with rsyslog or network-manager? I…

> It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces).

On FreeBSD, ifconfig works fine for having multiple addresses on the same interface (and has since like forever?? I had multiple addresses on the same interface in 2004, and it's documented in the FreeBSD 1.0 man page) and it also manages configuration for wireless interfaces too. There's no need for new tools when there is already an appropriate tool that can be updated to do the job. Keeping the existing tools working means you don't need to retrain users and you don't need to update documentation that doesn't touch the new use cases.

Re: Why I run FreeBSD for my home servers (2024)

#84

For some reason the silverbullet link in the website is broken if I copy it or just click it. But typing the exact same thing works.

The article link is wrong.

https://siliverbullet.md/

It should be below (without the extra “i”):

https://silverbullet.md/

Re: Why I run FreeBSD for my home servers (2024)

#86
post #21
post #12

If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular). If "kubesomething" is the reason, there's no requirement to use it. I think most people don't run it on their home servers. If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex. FreeBSD has a number of strong…

> But the usual Linux hobgoblins listed above are a red herring here, to my mind. Absolutely > If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex. The only point I agree with the author is that many things are shipped to be used with docker when they don't need to be, which creates a needless dependency.

I have "reversed engineered" dockerfiles in order to avoid containers. Any software should be installable without docker, it just takes more knowledge and time. Also sometimes it doesn't, there is a binary (like with go and rust and .net) or other times the long route is pip or apt and some conf fiddling. Databases are the worse part maybe but once you get it is more control for you and what you want to do with your setup. Moving database server to other dir o server? no prob. Sometimes dockerfile deploys postgresql when you can configure it for home a simple sqlite. If you end up modifying the dockerfile you understand what are the application requirements are and you can install raw.

Re: Why I run FreeBSD for my home servers (2024)

#87
post #78

I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. Leverage containers. Statelessness. I don't want to spend time meticulously configuring things beyond the core infrastructure my services run on. I…

> I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. I've worked at 'pets not cattle' and 'cattle not pets', and I vastly prefer pets. Yes, you should be able to easily bring up a new pet when you ne…

> But no, it's not really ok when your servers have an average lifetime of 30 days. It's very hard to offer a stable service on an unstable substrate.

The whole cattle mindset because at the end of the day everything is a "unstable substrate" your building a stable service on unstable blocks pets don't solve the issue that each pet is fundamentally unstable and your just pretending it's not.

Re: Why I run FreeBSD for my home servers (2024)

#88
post #78

I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. Leverage containers. Statelessness. I don't want to spend time meticulously configuring things beyond the core infrastructure my services run on. I…

> I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. I've worked at 'pets not cattle' and 'cattle not pets', and I vastly prefer pets. Yes, you should be able to easily bring up a new pet when you ne…

I agree on the "knowledge stability" front. I feel like I have to relearn Linux server networking config every three years because I switched distro or a distro switched their network management middleware.

But.

Having tried to move a machine from rhel 5 to rhel 7, where 12 people had used the server over the past 8 years for any scripting/log analysis/automation, for hosting a bespoke python web request site and a team-specific dokuwiki... The idea of having all that in source control and CICD is alluring.

Re: Why I run FreeBSD for my home servers (2024)

#89
post #64

Earlier quoted context omitted.

Basic systemd is really not that complex.

I think the author's point is that systemd by itself is complex, and it doesn't matter if you use it in a simple configuration, or in a more complex one.

And I'm saying that's a somewhat ridiculous premise, because a simple systemd configuration will "just work" 99% of the time. That complexity is not something the generic case needs to care about.

Re: Why I run FreeBSD for my home servers (2024)

#90
post #65

Earlier quoted context omitted.

Wifi? You mean the thing where people often resort to running a Linux VM to handle it?

I have had no issue with Wifi on multiple occasions. Works just fine nowadays without any Linux compatibility add-on. Wifi not being available isn't the fault of FreeBSD. If vendors actually gave open sourced drivers to their products and not locked behind a proprietary binary blob then we would be in a completely different world. I can recall when WiFi on Linux was pretty much non-existent until deals were made back…

> Wifi not being available isn't the fault of FreeBSD.

No. Just because it's available doesn't mean it's good. Until FreeBSD supports modern Wifi (4/5, i.e 802.11n/ac) then you're just ticking the box to say you've got it, but Linux actually supports these modern network setups and FreeBSD does not. There is no debating this at this point in time.

And to be clear, I'm referencing wifibox (https://github.com/pgj/freebsd-wifibox) which has been written about extensively and exists to work around FreeBSDs well known poor wifi support.

> So stop throwing that this is FreeBSDs fault

Nope, it's on FreeBSD if they want it. They appear to have finally prioritized it but it's not there yet.

https://freebsdfoundation.org/blog/january-2025-laptop-suppo...

Post reply on HN