5 ms·

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 ma

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_systemd/ https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s... [1] https://wiki.freebsd.org/PkgBase https://wiki.freebsd.org/PkgBase

dsr_ 4y ago
"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.
- dijit 4y ago
  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.
  - dsr_ 4y ago
    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.
    - dijit 4y ago
      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.
- efortis 4y ago
  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-server/jails/node_j/usr/local/etc/rc.d/node#L32 https://github.com/uxtely/ops-utils/blob/main/location-serve... https://www.freebsd.org/cgi/man.cgi?daemon(8) https://www.freebsd.org/cgi/man.cgi?daemon(8)
vermaden 4y ago
> 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-with-zfs-boot-environments/ 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-environments-revolutions/ https://vermaden.wordpress.com/2022/03/14/zfs-boot-environme... Regards.
icedchai 4y ago
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.
- gunapologist99 4y ago
  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.)
gunapologist99 4y ago
> 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.)
- cyberpunk 4y ago
  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.
LennyHenrysNuts 4y ago
deleted 4y ago
[deleted]

dsr_ 4y ago

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

dijit 4y ago
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.
- dsr_ 4y ago
  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.
  - dijit 4y ago
    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.
efortis 4y ago
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-server/jails/node_j/usr/local/etc/rc.d/node#L32 https://github.com/uxtely/ops-utils/blob/main/location-serve... https://www.freebsd.org/cgi/man.cgi?daemon(8) https://www.freebsd.org/cgi/man.cgi?daemon(8)

vermaden 4y ago

> 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-with-zfs-boot-environments/ 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-environments-revolutions/ https://vermaden.wordpress.com/2022/03/14/zfs-boot-environme... Regards.

icedchai 4y ago

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.

gunapologist99 4y ago
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.)

gunapologist99 4y ago

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

cyberpunk 4y ago
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.

LennyHenrysNuts 4y ago

deleted 4y ago

[deleted]