Hacker News Reader

Comment by laumars | Hacker News Reader

I'm curious, what is it you find messy about FreeBSD's init system? Personally I prefer it to systemd.

(I know these topics can get quite heated, but I'm genuinely not looking to start a flame war).

Previously service administration was different from linux distro to linux distro. This is of course no problem for FreeBSD, since there wasn't such a difference to begin with. One feature that FreeBSD may be missing is the dynamic behavior of desktop and mobile machines, which doesn't seem to map well to the existing init scripts.

While systemd clearly helped consolidate and make administration more predictable across linux distros, there are deficiencies and regressions due to systemd which for the most part didn't exist in the pre-systemd era. It may be due to the scope of functionality systemd aims to cover, but some of the unconventional or missing command line options don't help either. However, it's used by enough mainstream distros that I expect the kinks to be fixed with time.

I'm familiar with systemd. I've used it lots. Admittedly I'm not a fan of systemd but that's personal preference.

I was more interested in why the OP didn't consider FreeBSD to have a "useful init system". Just wondered if it was a preference thing or if there were features s/he considered it to be missing or were perhaps unaware of.

Its just trolling, thats why the original comment is content free.

> One feature that FreeBSD may be missing is the dynamic behavior of desktop and mobile machines, which doesn't seem to map well to the existing init scripts.

I keep seeing this argument, and i keep wondering what it is actually trying to say.

Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working.

But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.

Then again, maybe i am not the laptop packing dev convention goer that seems to use their laptop more like an oversized phone than a laptop (never mind a desktop).

Edit: damn keyboard ignored the copy command somehow, so i had the wrong quote pasted...

I don't know, it's just an argument I've heard from systemd and launchd proponents. I've had hardware events via udev for a long time before systemd.

Rule number one: if you don't understand a claim, don't repeat it. Nobody benefits.

You're right. I've trusted the content of Jordan Hubbard's presentation, seeing how he was inside OS X for a long time and is a FreeBSD expert too, and didn't question the validity.

> Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working. But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.

Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc. Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.

Reply on news.ycombinator.com