Comment by Mister_Snuggles | Hacker News Reader

Comment by Mister_Snuggles | Hacker News Reader

Mister_Snuggles

Honestly, I like and use FreeBSD.

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

> 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:

- 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.

"Run $X as user $Y, capture its output, restart it if it dies, and track its PID" for daemontools-style systems:

  #!/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

and logging:

  #!/bin/bash
  exec multilog s10485760 n5 /var/log/minecraft-player

Logging is set for 10MB files, keep last 5.

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.

As much as I really really dislike systemd, bash is not the answer.

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.

First, there's no requirement to use bash. Any shell that has an exec equivalent and can redirect stderr to stdout will work. There's not even a requirement for it to be a script -- daemontools-style supervisors don't parse the run program, they execute it. It's pretty convenient to use the setuidgid tool, though.

So if you want to run starlark, or oil, or your favorite lisp dialect, go ahead.

In summation: bash isn't the problem here.

That's a really good point actually;

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.

In FreeBSD:

   /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

https://github.com/uxtely/ops-utils/blob/main/location-serve...

https://www.freebsd.org/cgi/man.cgi?daemon(8)

For some reason, I couldn't figure this out the last time I had to do it. This seems perfectly reasonable though.

I'll take this thread as argument for _systemd_ as example simplified tooling for pretty standard tasks.

> 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.)

We do it via ansible, we create a boot environment (bectl create something) mount it (bectl mount something), then ansible upgrades the os and|or pkgs in the new be, and reboots into it. BE choice at boot is provided by some pxe/DHCP magic we rigged up.

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 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.

Systemd is in control of all of those issues (network devices, routes, mounts, etc). Unfortunately, almost all Linux distributions are really just different distributions of systemd now.. most likely the lines of code in systemd components far outweigh the package management components which are the clearest differentiator between one distribution and another. (definitionally, a distribution distributes packages.)

Reply on news.ycombinator.com