18 ms·

Funny enough, I decided to play with FreeBSD for personal projects in 2020. I gave up and I am reverting all my servers to Linux in 2022, for the opposite of th

Funny enough, I decided to play with FreeBSD for personal projects in 2020. I gave up and I am reverting all my servers to Linux in 2022, for the opposite of the reasons mentioned in this article. * Lack of systemd. Managing services through shell scripts is outdated to me. It feels very hacky, there is no way to specify dependencies, and auto-restarts in case of crashes. Many FreeBSD devs praise launchd, well... systemd is a clone of launchd. * FreeBSD jail are sub-optimal compared to systemd-nspawn. There are tons of tools to create freebsd jails (manually, ezjail, bastillebsd, etc…) half of them are deprecated. At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. With Linux, debootstrap + machinectl and you're good to go. * Lack of security modules (such as SELinux) -- Edit: I should have written "Lack of good security module" * nftables is way easier to grasp than pf, and as fast as pf, and has atomic reloads.

DarylZero 5y ago
- DarylZero 5y ago
  Haters be voting.
SpaceInvader 5y ago
Regarding jails - I do use separate loopback device per jail, plus pf with nat. No issues with firewalling.
- densone 5y ago
  Same .. I don’t use the separate loop back. Just firewall what I need to firewall .
fullstop 5y ago
I've grown to love systemd. It solves a lot of my problems with init scripts, particularly the ones involving environment / PATH at boot time. I've made init scripts for things before which work when they are invoked manually, but not at boot time because PATH was different. With systemd I am confident that if it works through systemctl it will work at boot. Maybe I am not tuning Linux appropriately, but I have been in situations where a Linux system is overwhelmed / overloaded and I am unable to ssh to it. I have never had that experience with FreeBSD -- somehow ssh is always quick and responsive even if the OS is out of memory. Most of the systems that I deal with are Linux, but I still have a few FreeBSD systems around and they are extraordinarily stable.
- eptcyka 5y ago
  I think there's something pathological in the I/O subsystems on Linux that make it a bad experience - I've experienced horrible U/I latencies on desktop and server settings with Linux when there was any kind of I/O load, and found FreeBSD to always be a breath of fresh and quick air in this regard.
  - pedrocr 5y ago
    There are definitely pathological cases around. Here's an 8 year old bug, still valid, that's a common extreme slowdown when copying to/from a USB drive: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208993 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208993
    - rogers18445 5y ago
      It sometimes manifests as audio stuttering (the kind which sounds like unstable sample rate) which suggests a lot of context switching, perhaps a scheduler problem. Had this problem intermittently and seemingly at random for many years. Sometimes would happen all day, then nothing for months. Quite Bizarre.
  - skeptical1 5y ago
    For a long time after creating my own Linux distro, I had the same kind of problems also. It turns out the Linux kernel is horribly tuned by default. After a number of tweaks and adjustments, I finally got all those bugs ironed out. Now my (four core) desktop is perfectly smooth and responsive under all loads, even playing video and running multiple builds while copying files around. Here's the important parts of what I've done: * set disk i/o schedulers to 'bfd' for spinning drives and 'deadline' for solid state, and 'none' for nvme, by creating a file in /etc/udev/rules.d . kernel must have deadline and bfd schedulers compiled in. * turned on SCSI block multiqueue in kernel config. requires kernel command line option scsi_mod.use_blk_mq=1 to actually enable it. this helped, but did not completely cure the disk i/o problem. * patched kernel source file ./block/blk-mq-sched.c to hard limit number of queued block device requests to 2, instead of default which is like 32. this absolutely cured the problem. no more disk i/o dragging the system down. doesn't seem to have a major effect on throughput. * kernel is configured for full preemption, with 1000hz timer frequency. * for architectures which will boot using the muqss cpu scheduler patch, i enable that with a 100hz timer freq instead. * overcommit is disabled, as well as swap, and i use earlyoom to ensure process destruction proceeds in a controlled manner in event of memory exhaustion. That's the bulk of it. No real magic involved; just un-fuck-ifying the default kernel config, which is garbage even for server use IMO. (This is on a 4.x kernel btw, and I have no plans to downgrade to the 5.x series.) The fact that these some or all of these tweaks aren't done by default would seem, along with other evidence, to support my belief that Linux is actively being sabotaged by people who don't want it to succeed.
lordgroff 5y ago
There's a lot to unpack here. For example, there's certainly other ways to network jails and all three ways you've mentioned to maintain jails are not deprecated. Security modules do exist, they're different from Linux. Are you sure you're not just expecting FreeBSD-as-Linux? As for init... What can I say, I've never been anti-systemd, not even remotely, but rc.d is much nicer than sysvinit, and I find it much simpler to understand than systemd. In fact, I think rc.d is an example of how Linux could have alternatively migrated from sysvinit without pissing some people off.
- acatton 5y ago
  > Security modules do exist, they're different from Linux. Are you sure you're not just expecting FreeBSD-as-Linux? You're right. My original message was wrong, I edited it, while keeping the original content. What I meant is "good security module". SELinux on CentOS is "enabled by default and forget about it", unless you do something weird. MAC (= Mandatory Access Control) on FreeBSD requires much more configuration. They have some cool stuff like memory limits, but it's not as powerful as SELinux.
  - zie 5y ago
    The security posture is quite different, so it's not as easy as just oh, turn on some magic module and be done. Security requires work, regardless of OS. A fair bit is included in the base system already, see capsicum for example. Also, see HardenedBSD, which is arguably better than anything Linux has built-in.
    - YATA0 5y ago
      >which is arguably better than anything Linux has built-in. No it isn't. There's a reason why government and military servers run hardened Linux with SELinux, and not any of the BSDs.
      - NexRebular 5y ago
        Any source for this statement?
throw0101a 5y ago
> there is no way to specify dependencies # PROVIDE: mumbled oldmumble # REQUIRE: DAEMON cleanvar frotz # BEFORE: LOGIN # KEYWORD: nojail shutdown * https://docs.freebsd.org/en/articles/rc-scripting/ https://docs.freebsd.org/en/articles/rc-scripting/ * https://www.freebsd.org/cgi/man.cgi?query=rcorder https://www.freebsd.org/cgi/man.cgi?query=rcorder
- acatton 5y ago
  From your link https://www.freebsd.org/cgi/man.cgi?query=rcorder https://www.freebsd.org/cgi/man.cgi?query=rcorder > The `REQUIRE' keyword is misleading: It does not describe which daemons have to be running before a script will be started. > It describes which scripts must be placed before it in the dependency ordering. For example, if your script has a `REQUIRE' on `sshd', it means the script must be placed after the `sshd' script in the dependency ordering, not necessarily that it requires sshd to be started or enabled.
hestefisk 5y ago
“Managing services through shell scripts is outdated.” By inference, since most things in Unix like systems are built on the notion of shell (and automation using the shell), this is saying large part of the foundation of Unix is outdated. A tool is a tool, but I would take a shell script from rc.d any time over a binary blob from systemd.
- crazy_hombre 5y ago
  systemd unit files are text files, not binary blobs. And it is much easier to grok a unit file than a 500 line init script.
  - waynesonfire 5y ago
    At what cost? Thats not the enirety of systemds complexity curve. Your systemd unit file is backed by pages and pages of docs that must be comprehended to understand and hack on. Unix developers have all they need from the script. Furthermore, its all in context of existing unix concepts and thus your unix experiance is paying dividends.
    - crazy_hombre 5y ago
      Now you're just exaggerating. Are you really saying spending 5-10 mins skimming through a couple of man pages is that hard? Are you saying that a lot of documentation is a bad thing? (I thought FreeBSD fans liked to harp about their handbook..) And besides, there are already hundreds of systemd unit files on your system that you can easily copy and make relevant changes for your own services. Not having to deal with finicky shell features is a major advantage IMO.
      - waynesonfire 5y ago
        I think the disconnect we're having is your inability to perceive complexity. And I don't blame you, it's not easy to quantify. I suggest you start with, Out of the Tar Pit by Ben Moseley. I'm not knocking on documentation, it's a vital property that I consider when adopting new technology. What I'm saying is that systemds documentation currency (if you accept my metaphor) is spent on covering its accidental complexity and it's voluminous. If you disagree with me, that's fine. This is just my experience as a linux user that's had to deal with systemd. If your claim is that systemd man pages are well written documentation then I think you're exaggerating and I'll wager you've relied on stackoverflow examples or tutorial blogs to solve your systemd issues--because I have. The reason for this is because the number of concepts and abstractions that you have to piece together to solve your problem is massive. But yeah, it's just a 5 line Unit file. I prefer strawberry kool-aid, thanks.
hestefisk 5y ago
Btw, HardenedBSD is a good security module and available.
krageon 5y ago
Systemd has only one advantage, which is also it's prime disadvantage: It's paws are everywhere in your system. Before there was Systemd, init systems worked okay too - in that space nothing was changed by it.
- acatton 5y ago
  Every company I worked at (before systemd was mainstream) was running most of their services under supervisord[1] which was started by initv. I'm not sure initv "worked okay". [1] http://supervisord.org/ http://supervisord.org/
  - spamizbad 5y ago
    init scripts were "great" if you were a unix wizard. For mere mortals they were frustrating.
toast0 5y ago
> At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. You may want to look at vnet, which gives jails their own networking stack; then you can give interfaces to the jail. If you use ipfw instead of pf, jail id/name is a matchable attribute on firewall rules; although it's not perfect, IIRC I couldn't get incoming SYNs to match by jail id, but you can match the rest of the packets for the connection. And that brings up the three firewalls of FreeBSD debate; maybe you had already picked pf because it met a need you couldn't (easily) meet with ipfw; you can run both simultaneously, but I wouldn't recommend it. Nobody seems to run ipf, though. Edit: you may also just want to limit each jail to a specific IP address, and then it's easy to firewall.
- ybloviator 5y ago
  And iocage makes all of this extremely simple, it can manage IPs for you and all that nonsense. There's also a sort of "clone" of iocage for bhyve.
HotHotLava 5y ago
My boss graduated from Berkely, and so I occasionally had to administer a FreeBSD box he kept around for the "superior OS philosophy". My biggest annoyance, apart from the obvious lack of systemd, was a social one: Any time I had to look up how to accomplish some non-trivial task I would inevitably find a thread on the FreeBSD forums by someone else who has had exactly the same problem in the past, together with a response by some dev along the lines of "why would anyone ever need to do that?".
- willjp 5y ago
  I have mixed feelings about this. On one hand, this is extremely alienating. On the other hand, I respect when devs reject features to keep their code simple. I don't think this has anything to do with graduating from berkely, I'm a hobo with a keyboard.
- gunapologist99 5y ago
  Even though I severely dislike systemd, and am a fan of FreeBSD's stability and simplicity, I also have found this attitude to be an annoyance. For example, if I want to upgrade a fleet of a hundred or so FreeBSD boxes remotely, the answer seems to be, "Don't do that. You must upgrade each one by hand." This is the principal reason why I've leaned toward Debian stable (which also aims at being a stable UNIX like FreeBSD) for decades, even though Debian has also been infected with systemd and has made other questionable decisions. Alternatively, I've also had good luck with Void, Alpine, and Artix. (I've had difficulties with electron apps on Void desktop, but it runs flawlessly on servers.)
  - simcop2387 5y ago
    > For example, if I want to upgrade a fleet of a hundred or so FreeBSD boxes remotely, the answer seems to be, "Don't do that. You must upgrade each one by hand." either that or "don't do an upgrade, build new ones and replace the old ones instead"
  - LAC-Tech 5y ago
    > (I've had difficulties with electron apps on Void desktop, but it runs flawlessly on servers.) If by any chance it was related to sound, today is your lucky day as I just solved that this morning before work.
jsiepkes 5y ago
> Many FreeBSD devs praise launchd, well... systemd is a clone of launchd. No they are not. Systemd has a way bigger scope then launchd. It's like saying a truck is the same thing as a family car because they both solve the mobility problem. > FreeBSD jail are sub-optimal compared to systemd-nspawn. systemd-nspawn isn't a container. For example it doesn't manage resources such as CPU or IO. Again, the scope is way different and in this case there is a whole slew of things systemd-nspawn isn't going to manage for you. BTW launchd doesn't have a feature like 'systemd-nspawn'. > Lack of security modules (such as SELinux) -- Edit: I should have written "Lack of good security module" And how is SELinux a good security module? SELinux with it's design fell in the same pitfall dozens of security systems did before it; ACL-Hell, Role-hell and now with SELinux we also have Label-hell.
- acatton 5y ago
  > systemd-nspawn isn't a container. For example it doesn't manage resources such as CPU or IO. Again, the scope is way different and in this case there is a whole slew of things systemd-nspawn isn't going to manage for you. It does[1]. At the end systemd-nspawn runs in a unit, which can be (like all systemd unit) resource-controlled. > BTW launchd doesn't have a feature like 'systemd-nspawn'. Neither does systemd. systemd-nspawn is just another binary, like git ant git-annex. The only difference from git and git-annex is that systemd and systemd-nspawn are maintained by the same team. But like git and git-annex, most systemd installations don't have systemd-nspawn, but systemd-nspawn needs systemd. > And how is SELinux a good security module? SELinux with it's design fell in the same pitfall dozens of security systems did before it; ACL-Hell, Role-hell and now with SELinux we also have Label-hell. SELinux is generic enough to allow for sandboxing of services. But in its mainstream use, SELinux is well design that it allows for reuse of policies. Most people don't care about SELinux, they just run CentOS, install RPM from the repository, and everything works out of the box with heighten security. (= if there is a vulnerability in any of these packages, the radius-blast of the attack is limited thanks to SELinux's Mandatory-Access-Control) [1] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html https://www.freedesktop.org/software/systemd/man/systemd.res...
  - 5y ago
traceroute66 5y ago
>Lack of systemd. Managing services through shell scripts is outdated to me. This, this and this again ! After decades of cron, I discovered systemd timers via a passing comment I read here on HN. My god is it amazing. No more hacky work-arounds in my scripts, systemd now takes care of all the magic such as random timings etc. I'll never go back to cron.
- torstenvl 5y ago
  Can you elaborate? I'm a macOS laptop/FreeBSD server guy. What are systemd timers, how do they work, and why do you feel they solve your problem better?
  - zaarn 5y ago
    Generally I would say the biggest difference is that with timers, you get more control. For example, you can schedule a timer to run 10 minutes after boot. Or a timer that actives 10 minutes after it has last finished running (note: not when it started last time but when it finished! So if the proc takes 10 hours, there is a 10 minute gap between runs. If it takes 10 minutes, there is still a 10 minute gap). You can also schedule something 10 minutes after a user logs in (or 10 seconds later, etc.). Additionally you get Accuracy and RandomizedDelay. The former lets you configure how accurate the timer needs to be, down to 1 sec or up to a day. So your unit now runs somewhere on the day it's supposed to run. And with the later you can ensure that there is no predictable runtime, this can be important for monitoring. My biggest favorite is Persistent=. If true, systemd will check when the service last ran. And if it should have been scheduled atleast once since then, it'll activate. I use this for backing up my home PC. When I do a quick restart, no backups are done but when I shutdown for the night, first thing in the morning my PC has a backup done.
    - throwawayboise 5y ago
      Counterpoint is that I've never had a requirement for timing scenarios like this, so now I'm dragging all that along for the ride for no advantage. Bloat is great when you need that rare thing I guess; otherwise it's just bloat and complexity for no benefit.
hnlmorg 5y ago
> Lack of systemd. Managing services through shell scripts is outdated to me. It feels very hacky, there is no way to specify dependencies, and auto-restarts in case of crashes. Many FreeBSD devs praise launchd, well... systemd is a clone of launchd. I'm not a fan of systemd personally but I do understand it has some good parts to it (such as the ones you've listed). That all said, you can still specify dependencies in FreeBSD with the existing init daemon. Albeit it's a little hacky compared with systemd (comments at the top of the script). But it does work. > FreeBSD jail are sub-optimal compared to systemd-nspawn. There are tons of tools to create freebsd jails (manually, ezjail, bastillebsd, etc…) half of them are deprecated. At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. With Linux, debootstrap + machinectl and you're good to go. It's definitely possible to have one interface per jail, I've done exactly that. However back when I last did it (5+ years ago?) you needed to manually edit the networking config and jail config to do it. There might be a more "linuxy" way to do this with Jails now though but its definitely possible. eg https://etherealwake.com/2021/08/freebsd-jail-networking/ https://etherealwake.com/2021/08/freebsd-jail-networking/
JediPig 5y ago
I like how userland and the kernel are sync in freebsd. I disdain how linux works in that. However Linux has its core advantages, some distos are well suited and tested for certain scenarios. I used to have a bunch of freebsd, but nowadays, I use containers, light weight runtimes. With Lambdas and Serverless, most, but not all, business api are streamed line where servers matter not. Its the runtime. Serverless is killing containers. Its killing the need to care about if its freebsd or linux, does it run my api fast enough?
- passthejoe 5y ago
  This whole "userland and kernel" thing sounds good, but in my BSD use, the trade-off is that most desktop app packages (and ports) get a whole lot less attention and are more buggy than those in Linux. I imagine it's not a problem for servers.
freedomben 5y ago
> well... systemd is a clone of launchd sort of. Systemd took a lot of lessons from launchd but also from sysv and upstart. For anyone who hasn't read Lennart Poettering's "Rethinking PID 1" post[1] I highly recommend it. You'll understand the history, but most importantly you'll understand systemd a ton better. [1]: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html
irthomasthomas 5y ago
1.5M lines of code is not an init system, it is a time bomb... and with dodgy wiring. I think it was a ZFS dev who complained he had to update 150 files to port ZFS to systemd. Simples? And you have to love all them binary log files, with their dynamic and spontaneus api. Yes, everything is always new and exciting with systemD. I use devuan. A debian fork with a choice of init systems (well, everything but systemD. ;) It took the dev/devs 2 years just to swap out/revert the init system. Also, just learned devuan's website is JS and cookie free. https://www.devuan.org/ https://www.devuan.org/ Edit: I will concede that systemD is great for a lot of people. I honestly wish them success. The work that goes in to building, maintaining, and using it, is substantial. It must be a boon for the economy and job creation.
- nine_k 5y ago
  Don't make a mistake, systemd is not (just) an init system. It's a replacement of more and more Linux userland. I suppose later on it will replace much of the filesystem, network, and process security management tools, stuff like xattrs, ip / ipfw, and selinux. I suppose that the end goal of the systemd project is an ability to deploy a production Linux system with just systemd and busybox, and run all software from containers. Not that it's a bad thing to strive for. But it's not going to be Unix as we know it.
  - dullgiulio 5y ago
    > But it's not going to be Unix as we know it. Right, that's Plan9.
    - nine_k 5y ago
      Plan9 is different in many core concepts. I didn't notice that systemd creates new file systems or allows to mount resources over the network. (Yes, I do regret that Linux was a hyper-succesful project that replicated Unix, not Plan9. But Plan9 is more complex, maybe it was just infeasible.)
  - StreamBright 5y ago
    > It's a replacement of more and more Linux userland. To be more specific is it a replacement of more and more Linux userland that nobody asked. I would be ok if systemd would be a process management system that replaces init with a standardised way of managing services (it would be amazing if it was written a safe language, if it was respecting configuration files, if it did not take over managing system limits, etc. etc.). Unfortunately it is trying to do too much.
wyager 5y ago
> At the end all of your jails end up on the same loopback interface, making it hard to firewall. I suppose you didn't use vnet? It's a vastly better jail networking experience. You can pretend jails are separate machines, connected via ethernet. I don't think anyone who knows about vnet chooses not to use it! > I couldn't find a way to have one network interface per jail. I think vnet is what you want. > nftables is way easier to grasp than pf, and as fast as pf, and has atomic reloads. pfctl allows you to do atomic reloads. `pfctl -f`
mortenlarsen 5y ago
>At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. FreeBSD jails has quite a bit of history (developed in 1998) and made public in the year 2000. FreeBSD has had VNET for use with jails allowing you to add epair interfaces connected to a bridge, or add a physical interface or VLAN to a jail. This feature has been in FreeBSD since 8.0 (2009) and enabled by default since 2018. It also allows you to run PF in each jail. Sadly many people a bitten by outdated forum and blog posts when it comes to jails. I agree that firewalling jails with loopbacks is a pain, but most people don't do it that way anymore. Also PF has always had atomic reloads.
- ybloviator 5y ago
  Yeah, it's a weird argument. I've used vnet, but rarely need it. I bind my jails to their own IPs and that's that. That has been available from the very early days of jails. Again, mature, simple and secure, with very few surprises lurking. There's likely fewer lines of code to support all jail functionality than in systemd.
yakaccount4 5y ago
Why exactly is launchd so praised by BSD folks?

DarylZero 5y ago

DarylZero 5y ago
Haters be voting.

SpaceInvader 5y ago

Regarding jails - I do use separate loopback device per jail, plus pf with nat. No issues with firewalling.

densone 5y ago
Same .. I don’t use the separate loop back. Just firewall what I need to firewall .

fullstop 5y ago

I've grown to love systemd. It solves a lot of my problems with init scripts, particularly the ones involving environment / PATH at boot time. I've made init scripts for things before which work when they are invoked manually, but not at boot time because PATH was different. With systemd I am confident that if it works through systemctl it will work at boot. Maybe I am not tuning Linux appropriately, but I have been in situations where a Linux system is overwhelmed / overloaded and I am unable to ssh to it. I have never had that experience with FreeBSD -- somehow ssh is always quick and responsive even if the OS is out of memory. Most of the systems that I deal with are Linux, but I still have a few FreeBSD systems around and they are extraordinarily stable.

eptcyka 5y ago
I think there's something pathological in the I/O subsystems on Linux that make it a bad experience - I've experienced horrible U/I latencies on desktop and server settings with Linux when there was any kind of I/O load, and found FreeBSD to always be a breath of fresh and quick air in this regard.
- pedrocr 5y ago
  There are definitely pathological cases around. Here's an 8 year old bug, still valid, that's a common extreme slowdown when copying to/from a USB drive: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208993 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208993
  - rogers18445 5y ago
    It sometimes manifests as audio stuttering (the kind which sounds like unstable sample rate) which suggests a lot of context switching, perhaps a scheduler problem. Had this problem intermittently and seemingly at random for many years. Sometimes would happen all day, then nothing for months. Quite Bizarre.
- skeptical1 5y ago
  For a long time after creating my own Linux distro, I had the same kind of problems also. It turns out the Linux kernel is horribly tuned by default. After a number of tweaks and adjustments, I finally got all those bugs ironed out. Now my (four core) desktop is perfectly smooth and responsive under all loads, even playing video and running multiple builds while copying files around. Here's the important parts of what I've done: * set disk i/o schedulers to 'bfd' for spinning drives and 'deadline' for solid state, and 'none' for nvme, by creating a file in /etc/udev/rules.d . kernel must have deadline and bfd schedulers compiled in. * turned on SCSI block multiqueue in kernel config. requires kernel command line option scsi_mod.use_blk_mq=1 to actually enable it. this helped, but did not completely cure the disk i/o problem. * patched kernel source file ./block/blk-mq-sched.c to hard limit number of queued block device requests to 2, instead of default which is like 32. this absolutely cured the problem. no more disk i/o dragging the system down. doesn't seem to have a major effect on throughput. * kernel is configured for full preemption, with 1000hz timer frequency. * for architectures which will boot using the muqss cpu scheduler patch, i enable that with a 100hz timer freq instead. * overcommit is disabled, as well as swap, and i use earlyoom to ensure process destruction proceeds in a controlled manner in event of memory exhaustion. That's the bulk of it. No real magic involved; just un-fuck-ifying the default kernel config, which is garbage even for server use IMO. (This is on a 4.x kernel btw, and I have no plans to downgrade to the 5.x series.) The fact that these some or all of these tweaks aren't done by default would seem, along with other evidence, to support my belief that Linux is actively being sabotaged by people who don't want it to succeed.

lordgroff 5y ago

There's a lot to unpack here. For example, there's certainly other ways to network jails and all three ways you've mentioned to maintain jails are not deprecated. Security modules do exist, they're different from Linux. Are you sure you're not just expecting FreeBSD-as-Linux? As for init... What can I say, I've never been anti-systemd, not even remotely, but rc.d is much nicer than sysvinit, and I find it much simpler to understand than systemd. In fact, I think rc.d is an example of how Linux could have alternatively migrated from sysvinit without pissing some people off.

acatton 5y ago
> Security modules do exist, they're different from Linux. Are you sure you're not just expecting FreeBSD-as-Linux? You're right. My original message was wrong, I edited it, while keeping the original content. What I meant is "good security module". SELinux on CentOS is "enabled by default and forget about it", unless you do something weird. MAC (= Mandatory Access Control) on FreeBSD requires much more configuration. They have some cool stuff like memory limits, but it's not as powerful as SELinux.
- zie 5y ago
  The security posture is quite different, so it's not as easy as just oh, turn on some magic module and be done. Security requires work, regardless of OS. A fair bit is included in the base system already, see capsicum for example. Also, see HardenedBSD, which is arguably better than anything Linux has built-in.
  - YATA0 5y ago
    >which is arguably better than anything Linux has built-in. No it isn't. There's a reason why government and military servers run hardened Linux with SELinux, and not any of the BSDs.
    - NexRebular 5y ago
      Any source for this statement?

throw0101a 5y ago

> there is no way to specify dependencies # PROVIDE: mumbled oldmumble # REQUIRE: DAEMON cleanvar frotz # BEFORE: LOGIN # KEYWORD: nojail shutdown * https://docs.freebsd.org/en/articles/rc-scripting/ https://docs.freebsd.org/en/articles/rc-scripting/ * https://www.freebsd.org/cgi/man.cgi?query=rcorder https://www.freebsd.org/cgi/man.cgi?query=rcorder

acatton 5y ago
From your link https://www.freebsd.org/cgi/man.cgi?query=rcorder https://www.freebsd.org/cgi/man.cgi?query=rcorder > The `REQUIRE' keyword is misleading: It does not describe which daemons have to be running before a script will be started. > It describes which scripts must be placed before it in the dependency ordering. For example, if your script has a `REQUIRE' on `sshd', it means the script must be placed after the `sshd' script in the dependency ordering, not necessarily that it requires sshd to be started or enabled.

hestefisk 5y ago

“Managing services through shell scripts is outdated.” By inference, since most things in Unix like systems are built on the notion of shell (and automation using the shell), this is saying large part of the foundation of Unix is outdated. A tool is a tool, but I would take a shell script from rc.d any time over a binary blob from systemd.

crazy_hombre 5y ago
systemd unit files are text files, not binary blobs. And it is much easier to grok a unit file than a 500 line init script.
- waynesonfire 5y ago
  At what cost? Thats not the enirety of systemds complexity curve. Your systemd unit file is backed by pages and pages of docs that must be comprehended to understand and hack on. Unix developers have all they need from the script. Furthermore, its all in context of existing unix concepts and thus your unix experiance is paying dividends.
  - crazy_hombre 5y ago
    Now you're just exaggerating. Are you really saying spending 5-10 mins skimming through a couple of man pages is that hard? Are you saying that a lot of documentation is a bad thing? (I thought FreeBSD fans liked to harp about their handbook..) And besides, there are already hundreds of systemd unit files on your system that you can easily copy and make relevant changes for your own services. Not having to deal with finicky shell features is a major advantage IMO.
    - waynesonfire 5y ago
      I think the disconnect we're having is your inability to perceive complexity. And I don't blame you, it's not easy to quantify. I suggest you start with, Out of the Tar Pit by Ben Moseley. I'm not knocking on documentation, it's a vital property that I consider when adopting new technology. What I'm saying is that systemds documentation currency (if you accept my metaphor) is spent on covering its accidental complexity and it's voluminous. If you disagree with me, that's fine. This is just my experience as a linux user that's had to deal with systemd. If your claim is that systemd man pages are well written documentation then I think you're exaggerating and I'll wager you've relied on stackoverflow examples or tutorial blogs to solve your systemd issues--because I have. The reason for this is because the number of concepts and abstractions that you have to piece together to solve your problem is massive. But yeah, it's just a 5 line Unit file. I prefer strawberry kool-aid, thanks.

hestefisk 5y ago

Btw, HardenedBSD is a good security module and available.

krageon 5y ago

Systemd has only one advantage, which is also it's prime disadvantage: It's paws are everywhere in your system. Before there was Systemd, init systems worked okay too - in that space nothing was changed by it.

acatton 5y ago
Every company I worked at (before systemd was mainstream) was running most of their services under supervisord[1] which was started by initv. I'm not sure initv "worked okay". [1] http://supervisord.org/ http://supervisord.org/
- spamizbad 5y ago
  init scripts were "great" if you were a unix wizard. For mere mortals they were frustrating.

toast0 5y ago

> At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. You may want to look at vnet, which gives jails their own networking stack; then you can give interfaces to the jail. If you use ipfw instead of pf, jail id/name is a matchable attribute on firewall rules; although it's not perfect, IIRC I couldn't get incoming SYNs to match by jail id, but you can match the rest of the packets for the connection. And that brings up the three firewalls of FreeBSD debate; maybe you had already picked pf because it met a need you couldn't (easily) meet with ipfw; you can run both simultaneously, but I wouldn't recommend it. Nobody seems to run ipf, though. Edit: you may also just want to limit each jail to a specific IP address, and then it's easy to firewall.

ybloviator 5y ago
And iocage makes all of this extremely simple, it can manage IPs for you and all that nonsense. There's also a sort of "clone" of iocage for bhyve.

HotHotLava 5y ago

My boss graduated from Berkely, and so I occasionally had to administer a FreeBSD box he kept around for the "superior OS philosophy". My biggest annoyance, apart from the obvious lack of systemd, was a social one: Any time I had to look up how to accomplish some non-trivial task I would inevitably find a thread on the FreeBSD forums by someone else who has had exactly the same problem in the past, together with a response by some dev along the lines of "why would anyone ever need to do that?".

willjp 5y ago
I have mixed feelings about this. On one hand, this is extremely alienating. On the other hand, I respect when devs reject features to keep their code simple. I don't think this has anything to do with graduating from berkely, I'm a hobo with a keyboard.
gunapologist99 5y ago
Even though I severely dislike systemd, and am a fan of FreeBSD's stability and simplicity, I also have found this attitude to be an annoyance. For example, if I want to upgrade a fleet of a hundred or so FreeBSD boxes remotely, the answer seems to be, "Don't do that. You must upgrade each one by hand." This is the principal reason why I've leaned toward Debian stable (which also aims at being a stable UNIX like FreeBSD) for decades, even though Debian has also been infected with systemd and has made other questionable decisions. Alternatively, I've also had good luck with Void, Alpine, and Artix. (I've had difficulties with electron apps on Void desktop, but it runs flawlessly on servers.)
- simcop2387 5y ago
  > For example, if I want to upgrade a fleet of a hundred or so FreeBSD boxes remotely, the answer seems to be, "Don't do that. You must upgrade each one by hand." either that or "don't do an upgrade, build new ones and replace the old ones instead"
- LAC-Tech 5y ago
  > (I've had difficulties with electron apps on Void desktop, but it runs flawlessly on servers.) If by any chance it was related to sound, today is your lucky day as I just solved that this morning before work.

jsiepkes 5y ago

> Many FreeBSD devs praise launchd, well... systemd is a clone of launchd. No they are not. Systemd has a way bigger scope then launchd. It's like saying a truck is the same thing as a family car because they both solve the mobility problem. > FreeBSD jail are sub-optimal compared to systemd-nspawn. systemd-nspawn isn't a container. For example it doesn't manage resources such as CPU or IO. Again, the scope is way different and in this case there is a whole slew of things systemd-nspawn isn't going to manage for you. BTW launchd doesn't have a feature like 'systemd-nspawn'. > Lack of security modules (such as SELinux) -- Edit: I should have written "Lack of good security module" And how is SELinux a good security module? SELinux with it's design fell in the same pitfall dozens of security systems did before it; ACL-Hell, Role-hell and now with SELinux we also have Label-hell.

acatton 5y ago
> systemd-nspawn isn't a container. For example it doesn't manage resources such as CPU or IO. Again, the scope is way different and in this case there is a whole slew of things systemd-nspawn isn't going to manage for you. It does[1]. At the end systemd-nspawn runs in a unit, which can be (like all systemd unit) resource-controlled. > BTW launchd doesn't have a feature like 'systemd-nspawn'. Neither does systemd. systemd-nspawn is just another binary, like git ant git-annex. The only difference from git and git-annex is that systemd and systemd-nspawn are maintained by the same team. But like git and git-annex, most systemd installations don't have systemd-nspawn, but systemd-nspawn needs systemd. > And how is SELinux a good security module? SELinux with it's design fell in the same pitfall dozens of security systems did before it; ACL-Hell, Role-hell and now with SELinux we also have Label-hell. SELinux is generic enough to allow for sandboxing of services. But in its mainstream use, SELinux is well design that it allows for reuse of policies. Most people don't care about SELinux, they just run CentOS, install RPM from the repository, and everything works out of the box with heighten security. (= if there is a vulnerability in any of these packages, the radius-blast of the attack is limited thanks to SELinux's Mandatory-Access-Control) [1] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html https://www.freedesktop.org/software/systemd/man/systemd.res...
- 5y ago

traceroute66 5y ago

>Lack of systemd. Managing services through shell scripts is outdated to me. This, this and this again ! After decades of cron, I discovered systemd timers via a passing comment I read here on HN. My god is it amazing. No more hacky work-arounds in my scripts, systemd now takes care of all the magic such as random timings etc. I'll never go back to cron.

torstenvl 5y ago
Can you elaborate? I'm a macOS laptop/FreeBSD server guy. What are systemd timers, how do they work, and why do you feel they solve your problem better?
- zaarn 5y ago
  Generally I would say the biggest difference is that with timers, you get more control. For example, you can schedule a timer to run 10 minutes after boot. Or a timer that actives 10 minutes after it has last finished running (note: not when it started last time but when it finished! So if the proc takes 10 hours, there is a 10 minute gap between runs. If it takes 10 minutes, there is still a 10 minute gap). You can also schedule something 10 minutes after a user logs in (or 10 seconds later, etc.). Additionally you get Accuracy and RandomizedDelay. The former lets you configure how accurate the timer needs to be, down to 1 sec or up to a day. So your unit now runs somewhere on the day it's supposed to run. And with the later you can ensure that there is no predictable runtime, this can be important for monitoring. My biggest favorite is Persistent=. If true, systemd will check when the service last ran. And if it should have been scheduled atleast once since then, it'll activate. I use this for backing up my home PC. When I do a quick restart, no backups are done but when I shutdown for the night, first thing in the morning my PC has a backup done.
  - throwawayboise 5y ago
    Counterpoint is that I've never had a requirement for timing scenarios like this, so now I'm dragging all that along for the ride for no advantage. Bloat is great when you need that rare thing I guess; otherwise it's just bloat and complexity for no benefit.

hnlmorg 5y ago

> Lack of systemd. Managing services through shell scripts is outdated to me. It feels very hacky, there is no way to specify dependencies, and auto-restarts in case of crashes. Many FreeBSD devs praise launchd, well... systemd is a clone of launchd. I'm not a fan of systemd personally but I do understand it has some good parts to it (such as the ones you've listed). That all said, you can still specify dependencies in FreeBSD with the existing init daemon. Albeit it's a little hacky compared with systemd (comments at the top of the script). But it does work. > FreeBSD jail are sub-optimal compared to systemd-nspawn. There are tons of tools to create freebsd jails (manually, ezjail, bastillebsd, etc…) half of them are deprecated. At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. With Linux, debootstrap + machinectl and you're good to go. It's definitely possible to have one interface per jail, I've done exactly that. However back when I last did it (5+ years ago?) you needed to manually edit the networking config and jail config to do it. There might be a more "linuxy" way to do this with Jails now though but its definitely possible. eg https://etherealwake.com/2021/08/freebsd-jail-networking/ https://etherealwake.com/2021/08/freebsd-jail-networking/

JediPig 5y ago

I like how userland and the kernel are sync in freebsd. I disdain how linux works in that. However Linux has its core advantages, some distos are well suited and tested for certain scenarios. I used to have a bunch of freebsd, but nowadays, I use containers, light weight runtimes. With Lambdas and Serverless, most, but not all, business api are streamed line where servers matter not. Its the runtime. Serverless is killing containers. Its killing the need to care about if its freebsd or linux, does it run my api fast enough?

passthejoe 5y ago
This whole "userland and kernel" thing sounds good, but in my BSD use, the trade-off is that most desktop app packages (and ports) get a whole lot less attention and are more buggy than those in Linux. I imagine it's not a problem for servers.

freedomben 5y ago

> well... systemd is a clone of launchd sort of. Systemd took a lot of lessons from launchd but also from sysv and upstart. For anyone who hasn't read Lennart Poettering's "Rethinking PID 1" post[1] I highly recommend it. You'll understand the history, but most importantly you'll understand systemd a ton better. [1]: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html

irthomasthomas 5y ago

1.5M lines of code is not an init system, it is a time bomb... and with dodgy wiring. I think it was a ZFS dev who complained he had to update 150 files to port ZFS to systemd. Simples? And you have to love all them binary log files, with their dynamic and spontaneus api. Yes, everything is always new and exciting with systemD. I use devuan. A debian fork with a choice of init systems (well, everything but systemD. ;) It took the dev/devs 2 years just to swap out/revert the init system. Also, just learned devuan's website is JS and cookie free. https://www.devuan.org/ https://www.devuan.org/ Edit: I will concede that systemD is great for a lot of people. I honestly wish them success. The work that goes in to building, maintaining, and using it, is substantial. It must be a boon for the economy and job creation.

nine_k 5y ago
Don't make a mistake, systemd is not (just) an init system. It's a replacement of more and more Linux userland. I suppose later on it will replace much of the filesystem, network, and process security management tools, stuff like xattrs, ip / ipfw, and selinux. I suppose that the end goal of the systemd project is an ability to deploy a production Linux system with just systemd and busybox, and run all software from containers. Not that it's a bad thing to strive for. But it's not going to be Unix as we know it.
- dullgiulio 5y ago
  > But it's not going to be Unix as we know it. Right, that's Plan9.
  - nine_k 5y ago
    Plan9 is different in many core concepts. I didn't notice that systemd creates new file systems or allows to mount resources over the network. (Yes, I do regret that Linux was a hyper-succesful project that replicated Unix, not Plan9. But Plan9 is more complex, maybe it was just infeasible.)
- StreamBright 5y ago
  > It's a replacement of more and more Linux userland. To be more specific is it a replacement of more and more Linux userland that nobody asked. I would be ok if systemd would be a process management system that replaces init with a standardised way of managing services (it would be amazing if it was written a safe language, if it was respecting configuration files, if it did not take over managing system limits, etc. etc.). Unfortunately it is trying to do too much.

wyager 5y ago

> At the end all of your jails end up on the same loopback interface, making it hard to firewall. I suppose you didn't use vnet? It's a vastly better jail networking experience. You can pretend jails are separate machines, connected via ethernet. I don't think anyone who knows about vnet chooses not to use it! > I couldn't find a way to have one network interface per jail. I think vnet is what you want. > nftables is way easier to grasp than pf, and as fast as pf, and has atomic reloads. pfctl allows you to do atomic reloads. `pfctl -f`

mortenlarsen 5y ago

>At the end all of your jails end up on the same loopback interface, making it hard to firewall. I couldn't find a way to have one network interface per jail. FreeBSD jails has quite a bit of history (developed in 1998) and made public in the year 2000. FreeBSD has had VNET for use with jails allowing you to add epair interfaces connected to a bridge, or add a physical interface or VLAN to a jail. This feature has been in FreeBSD since 8.0 (2009) and enabled by default since 2018. It also allows you to run PF in each jail. Sadly many people a bitten by outdated forum and blog posts when it comes to jails. I agree that firewalling jails with loopbacks is a pain, but most people don't do it that way anymore. Also PF has always had atomic reloads.

ybloviator 5y ago
Yeah, it's a weird argument. I've used vnet, but rarely need it. I bind my jails to their own IPs and that's that. That has been available from the very early days of jails. Again, mature, simple and secure, with very few surprises lurking. There's likely fewer lines of code to support all jail functionality than in systemd.

yakaccount4 5y ago

Why exactly is launchd so praised by BSD folks?