Live data from Hacker News

Why I run FreeBSD for my home servers (2024)

aumont.fr

191–200 of 251 posts

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

#191
Wow OP there, I didn't think anyone would pass by my random blog and post the link here .... I'm surprised at the number of comments for a post that was originally there just to feed my blog with a first page and provide a bit of content. Especially for an article that I feel is barely finished and needs a lot of updating.

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

#193

I use FreeBSD for my home server and I have for years. For me, the biggest reason is just the stability from a user perspective. I don't mean system stability, although it has been rock solid, I mean the stability in terms of administration - the tools don't change frequently. `ifconfig` just works, like it has worked for 20 years. On my linux servers, it's all swallowed into `ip addr` now. I don't mind that, I certa…

> like it has worked for 20 years .. almost forty years

man you're making me feel old. those kids on my lawn are pissing me off tho...

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

#194

Earlier quoted context omitted.

> the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file I started with FreeBSD and it never was a problem to me until I started to use Linux too. Now I just make symlinks from /usr/local/etc to /etc for software I use both on Linux and FreeBSD. The rule is simple - if an app is from the base system it is in /etc and if you installed some software from packages…

FreeBSD is more of an admin's system than a user's system and this perfectly illustrates one of the reasons why. Outside of this forum, in regular consumer land, OS users don't want to know or care about the distinction between base and ports, and nothing anyone says about it is going to change that. So I run lots of BSD at home but I recommend Mint to family.

May be I'm biased but a distinction between base OS and 3rd party software is a simple concept to me, also it is not unique to BSD. E. g. in Windows there were different menu sections to install/uninstall optional Windows components and to uninstall 3rd party software.

If aynthing Linux is an outlier in that core OS components and 3rd party apps both come in similar packages which makes it hard to distinguish which is a part of the base OS and which and optional 3rd party software. In FreeBSD I know that I can delete all packages and still have a system remotely accessible via SSH (with rare exception a normal user will not come across). In Linux to tell which package can be uninstalled without breaking the system one have to be an expert. Can I delete iproute package if I don't use ip command, can I remove NetworkManager, is systemd-container optional? Where the OS stops and 3rd party apps start?

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

#195

Earlier quoted context omitted.

> If systemd is the reason, there are several good distros without systemd I totally get avoiding systemd, I don't myself, but I get it. The author on the other hand talks about the problems doing this in a professional setting. This I do not get. As far as management of large fleets of servers goes, systemd is quite nice. Yeah, it's odd for some things but as far as automation is concerned it's the way to go. With s…

> With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini. There is no "syntax", it's all just key=value pairs, and all the subsystems have their own set of keys/directives, and the values have their own mini-DSLs. Things that end in "Sec" (for "seconds"…

> There is no "syntax", it's all just key=value pairs,

This, with the sections, is INI. Duplicate keys included. Loosely defined spec, but INI none the less

> I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place

It's common to store information in a DB, or some other format that is easy to merge/override programmatically. Even configuration management tools like puppet, salt, ansible do this with JSON/YAML

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

#196
> The biggest issue with FreeBSD : The very bad habbit of developper to deploy OpenSource software only with Docker

Holy smokes, that's quite biased!

Good on the author for having strong beliefs, but in my eyes containers avoid entire categories of problems, like: https://blog.kronis.dev/user/pages/blog/oracle-jdk-and-openj... (request processing times for a random system at work ages ago under load tests, it ran passably in OpenJDK, whereas running with the Oracle JDK resulted in an order of magnitude worse performance, this was before containers were introduced in the project; guess which vendor's version was installed in prod without telling us about it)

It was an old post, but sometimes there's configurations that do break in mysterious ways when the dependencies and the runtime environments aren't matched exactly to what was developed/tested against; see the whole reproducible software movement, can have good install scripts and other tools to help even without containers, but good luck managing the support matrix of a bunch of separate *nix distros and OSes, as well as having testing environments for those. Not even that much of an enterprise concern.

We shouldn't need containers for everything, but there aren't that many other good options for packaging software.

> There is a new fashion on the OpenSource world. Developpers think Docker is the new de-facto standard and only propose to install the tools with Docker.

It shouldn't be the only way, but I'll take Docker over random shell scripts and the ability to easily launch software and then later tear it down without messing up my host OS or having to mess around with VMs. Tbh, I do kind of wish that Vagrant had caught on more.

> Most of the time they do no provide any DOCUMENTATION to install their software in a baremetal way.

> At best, they offer an .rpm or .deb package for installation on a non-docker OS. But most of the time it's a docker file.

The Dockerfile is more or less living documentation, which is better than having a source code repo with nothing but obviously worse than someone taking the time of the day to write some guides or docs. Then again, if it's FOSS devs, then I'll take anything over nothing, given how much time they (don't) have.

> Even worse, modern applications often deploy the code and database needed to run the code directly in the docker compose file.

Deploying DBs or even multiple separate apps within a single container is pretty much an anti-pattern (anyone who has needed to decipher what happens inside of a GitLab Omnibus image, or update the Sonatype Nexus image from the embedded OrientDB to PostgreSQL probably understands the pain) and should be avoided, maybe save for rare cases like a web server with PHP-FPM (maybe with supervisord) if you really need to, or for the lazy/testing setups that will ultimately be a mess to maintain.

Edit: however if the complaint is literally just about having a Docker Compose file which contains a self-contained DB container, then it's up to you to decide whether you want or don't want to use it, or reference another DB running on the host or elsewhere (e.g. host.docker.internal or equivalent). It doesn't take much work to comment out a block.

> At what point did these people think it was relevant to run 10 different databases when I'm hosting 10 applications ?

You don't have to. You could have a single PostgreSQL or MariaDB/MySQL instance that just has multiple users and DBs/schemas. I honestly prefer the more distributed setup because I now can move software across servers trivially and can update the versions as I please and when something misbehaves, the impact is limited (because you can set CPU/RAM limits, easier than with cgroups).

Good for the author for enjoying FreeBSD, it's a pretty cool OS and feels more like it's "designed" instead of the more organic feel of how Linux distros work.

But I reject the motionally charged language and stance.

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

#197
post #181
post #173

Earlier quoted context omitted.

> If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular). There are people in the FreeBSD camp that actually do advocate for something like systemd in FreeBSD. See "The Tragedy of systemd": https://www.youtube.com/watch?v=o_AIw9bGogo

Is there a text version of that?

no, but here's the sum up: "systemd is actually good, the current init system in freebsd is severely lacking under many aspects, systemd is more of a system manager rather than just an init system, that's actually a good thing and actually we'd need something like systemd in freebsd".

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

#198

I use FreeBSD for my home server and I have for years. For me, the biggest reason is just the stability from a user perspective. I don't mean system stability, although it has been rock solid, I mean the stability in terms of administration - the tools don't change frequently. `ifconfig` just works, like it has worked for 20 years. On my linux servers, it's all swallowed into `ip addr` now. I don't mind that, I certa…

Linux still has ifconfig, it doesn't support all the new features but maybe this use case doesn't need them.

(Also the "ip" command from iproute2 came around in the last millenium, no?)

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

#199
post #93

Earlier quoted context omitted.

ZFS is a first class part of FreeBSD. you can use it on linux, but it will always have some rough edges. How rough it open to question though, for some it works well.

Well since FreeBSD is pulling ZFS source from Linux, I am not certain what are the rough edges. And I have ran ZFS for 7+ years on Linux with zero issues.

ZFS is not part of linux. It is a separate project that publishes both to FreeBSD and some shims so you can run it on Linux. FreeBSD pulls and directly integrates it, but for license reasons linux doesn't pull it in directly. Yes the upstream project does have some shims of linux use that they public directly, but FreeBSD is a first class user of that project while the linux shims are a hack that some in the kernel do not want to work.

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

#200
post #183

I started reading but stopped as soon as it was a systemd rant. systemd, while not for everyone is a good for most people .

> systemd, while not for everyone is a good for most people Are you really sure? systemd is a tool that automates system configuration with no interaction from the user, and it does it in such a way that the user doesn't have to know how the system works, then the user doesn't want to know, and then no longer actually knows . When that happens, the user can't make any political decisions about his/her system, the "sy…

I'm 100% certain, you're regurgitating the typical anti-systemd shill that hates into a future where we might be so lucky that Linux users don't need to know anything about their init system. That day is a good day for Linux users if it happens.

I don't think not knowing all of what systemd does will turn Linux users into mindless drones and it's quite dismissive to take that stance, these are users that chose another OS for their out of their own free will.

Post reply on HN