Interest in FreeBSD seems to be on the rise, with the advent of systemd. Many Linux users have been able to avoid it thus far, by sticking to 6.x Of RedHat and derivatives, or Debian 7. As these versions become longer in the tooth, it will be interesting to see if more people will switch over to FreeBSD. Popularity may not be a good thing however, with the recent political drama and institution of a code of conduct getting in the way of FreeBSD's meritocratic approach. Thankfully, there's still plenty of choice available in open source operating systems. Thankfully, we can always trust Theo to keep OpenBSD's purist approach to technical correctness :P

>Interest in FreeBSD seems to be on the rise, with the advent of systemd.

I don't buy this, why would someone who complains about the consolidation and standardisation of core tools/services in Linux want to move to FreeBSD which does exactly the same as it is a full operating system and only supports what they ship, anything else you are on your own, just like what we get with standardising around systemd across distros.

The choice/flexibility which is potentially lost if the entire Linux ecosystem embraces systemd was never available on FreeBSD in the first place, what standardising around systemd is doing is moving Linux distros closer to one of the often touted advantages of choosing one of the BSD distros, which is a standard set of core tools/services which can be targeted (however in Linux's case it is across distros as opposed to the BSD's where it is per-OS).

Because in BSD, that consolidation and standardization is optional by design, with everything given knobs to disable it. For example, I don't like FreeBSD's syslog -- I prefer syslog-ng. Therefore, I have the following in my /etc/rc.conf

    #use syslog-ng instead of the built-in syslog
    syslog_ng_enable="YES"
    syslogd_enable="NO"

and as such, I have my own syslog running. Systemd, on the other hand, disabling their syslog is simply not an option, as is the case with so many components that it encompasses. The BSD's philosophy is indeed to have a cohesive system, however, they recognize that they don't always have the best defaults for every situation, and thus make it easy, and supportable, to set options the way you want.

> Systemd, on the other hand, disabling their syslog is simply not an option

You can set Storage=none and ForwardToSyslog=yes in /etc/systemd/journald.conf [0].

[0] https://wiki.archlinux.org/index.php/Syslog-ng#syslog-ng_and...

The journal still takes over /proc/kmsg. You're relying on journald working properly, and you cannot bypass it. Forwarding things on from journald is not the same as disabling it completely.

(This sort of inability to make decisions about what tools you use for your system is one of the complaints about systemd)

That's not disabling journald, that's disabling journald writing messages. It's still receiving every byte sent to the system log, it's still in memory, and otherwise still running.

Most opponents of systemd are not against consolidation and standardization of linux system administration. What they object to is the development approach and happiness to introduce bugs and unbootable systems.

To add one more anecdote: give voidlinux a try at some point. It uses runit as its init system and boots at least twice as fast as a systemd-based arch linux system. As with startups, the idea is less important than good execution, and systemd only succeeded on the former (so far).

With all that being said, I do like that I know how to do common administration on both Arch Linux and RHEL and Debian without learning three toolsets.

> boots at least twice as fast as

Honestly, why is this important? I want a system that is fast once booted, not a system that boots quickly.

I've never understand that argument either. I suppose it might make a difference if you are constantly (shutting down and) spinning up new instances all day long. Most of my hosts "boot up", at most, two or three times a year, though. An extra 30 seconds is not something that causes me pain.

Even in a cloud environment where you might be scaling dynamically based on demand, it's fairly trivial to set your scaling policies with just slightly lower tolerance to account for a couple dozen seconds startup time. If you're not scaling until you have an immediate need for that capacity, you're in trouble and your users are going to be encountering reduced performance or service outages anyway.

It's important because systemd boasts faster boot times and to show that systemd isn't really much faster than existing solutions. Boot times are important if you start on demand. See MirageOS's network initiated quick boot for one extreme.

>Most opponents of systemd are not against consolidation and standardization of linux system administration.

That's not my experience, in the discussions I've seen and taken part in, most (as in vast majority) of the detractors are opposed to systemd as a consolidation of a large array of core tools and services all under the same 'umbrella', which is exactly what the BSD's do at an even higher level as they are developed as full operating systems.

I'm not sure what 'happiness to introduce bugs and unbootable systems' refer to, I've been using systemd ever since Arch made the switch (~4 years ago). I've yet to have stability issues and I haven't read of any widespread problems in the Arch forums either.

There are (and likely always will be) distros which default to and promote alternatives (Gentoo comes directly to mind), but in the grand scope we're seeing a huge convergence around systemd across distros, which tells me this type of standardisation is something the Linux ecosystem really pined for overall.

I think that the issue that a lot of BSD people have with systemd is the development model and consolidation of projects around systemd only APIs which are difficult to integrate into non-Linux platforms.

That combined with the systemd developers saying 'Systemd is a Linux-only project, we'll only be accepting patches for Linux and we'll only be supporting Linux. If this breaks on non-Linux systems, you're on your own.' Granted the community has adapted very well, as Gnome Shell running on OpenBSD demonstrates, but the non-inclusive attitude must have left a sour taste in a lot of people's mouths and you can understand why they feel bitter.

Personally, I'm a Solaris guy. I use BSDs when Solaris isn't practical. I'm fully on board with the consolidation of an array of core tools and services by a competent team.

I'm just not sure that I believe the systemd team is said team. Their behavior on mailing lists and bugzillas has been extremely disconcerting at times, such as when they screwed over kernel developers who used the debug kernel option and basically said 'Tough shit that we broke the existing standard workflow, we don't care' ( https://bugs.freedesktop.org/show_bug.cgi?id=76935 )

Whether or not you agree that reasons like that are enough to distrust the team, if I were to keep running Linux in production, and make my own personal choice about what I am using, I can no longer realistically do this. Extremely necessary things such as udev being merged into systemd (and being a large pain in the ass to compile and use without systemd) mean this is no longer something as easy as replacing one or two components.

I'm all for convergence. Hell, I don't even particularly like sysv init - if systemd was a product as refined as even SMF, I'd care a lot less. And, I like the ease of use of journalctl - I spend a lot less time mangling text with grep and awk and sed when going through logs when I'm not on a system where things are being sent to splunk or kibana.

Whatever happens in the Linux community, I'm not particularly affected. SmartOS and OmniOS already have things very similar to systemd because of their Solaris heritage, and they work well. The BSDs seem to be moving in that direction, and I expect they'll create a solid product. I'll use those and be happy to do so. When I have to deal with other environments where Linux is used, well, I've learned plenty about systemd and feel perfectly comfortable working with it. I won't particularly like it, but ultimately, it's not something I care about to do more than discuss it on the internet.

I've seen and I am seeing the following on Arch Linux:

- still unfixed shutdown errors from systemd - new shutdown errors from systemd - failed to boot or shutdown a system due to a systemd bug hence fixed - harder to fix if shutdown or boot fails compared to old init systems

My impression is that there isn't enough QA for the amount of churn they have in each release. Most bugs are very obvious and not someone using an obscure configuration for his sparcstation.

Standardization for a single common administration interface is a good thing but the resulting product is of sub-par quality thus far.

To clarify, I mean consolidation in terms of the admin interface and not necessarily putting everything into a single executable. Being able to use the same commands across most linux distros is the advantage.

I don't think the biggest complaints about systemd are the consolidation of tools into a core. Nobody complains about coreutils. It's about the consolidation of tools into a few monolithic binaries. And about the piroritization of desktop use cases over server use cases.

>It's about the consolidation of tools into a few monolithic binaries.

Could you go in to some detail here, what are the tools that have been turned in to monolithic binaries ?

The systemd project consists of some 70 different binaries, the vast majority of them being optional, and each of them handling specific tasks very much in the UNIX tradition.

They are being developed in the same tree, exactly like the BSD's, and just like the BSD equivalents they want to make use of features the kernel can provide even if that makes it less portable.

Red herring: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...

Even without that, systemd is still technically unsound in its design: http://blog.darknedgy.net/technology/2015/10/11/0/

> with the recent political drama and institution of a code of conduct getting in the way of FreeBSD's meritocratic approach.

I missed this - any link you'd recommend to catch up on what happened?

In reverse chronological order:

https://lists.freebsd.org/pipermail/freebsd-announce/2016-Ja... http://www.breitbart.com/tech/2016/01/01/freebsd-community-b... http://blog.randi.io/2015/12/31/the-developer-formerly-known... https://lists.freebsd.org/pipermail/freebsd-advocacy/2015-Ju... https://www.freebsd.org/internal/code-of-conduct.html

Thanks and ouch, what a palava. Their CoC is actually one of the better ones I've seen (and I object to them on principle - if the community isn't strong enough to keep and want a good and healthy environment, there's a bigger problem to worry about) but all this effort wasted...

FreeBSD is going to eventually adopt a systemd-like approach. So people who switch for this reason will be betrayed down the line.

Even if they do, I'm pretty confident that FreeBSD will do it better. If for no other reason, they'll be able to take the lessons from systemd and see what worked and what didn't.

Yes, and FreeBSD wouldn't allow unbootable systems that you can easily run into with systemd.

Or break stuff from one release to another. I fear that the web app approach to release often and break often is getting into Linux userland development. Gtk3 is another example of that. 3.16 was fine and 3.18 started drawing slower and displaying black rectangles anytime while a built-in dialog (color, file, etc.) is opening. Then there's Gtk3's reluctance to support themes. Almost all themes have to be ported again for each Gtk3 release. And you cannot configure your theme once and reuse the config ($HOME) on two different versions of a linux distro. If GNOME wouldn't approach the default theme like everybody uses Gtk3 on a tablet, it wouldn't be problem to have no theming. I've been using a Gtk2 theme I wrote for at least 12 years or even longer and it never glitched on me. This is the same mindset systemd development in general seems to have. But like in all organizations I've seen reasonable developers in the systemd community and those who are not.

I don’t think this is a new trend: https://web.archive.org/web/20151126183335/https://www.jwz.o...

Many different groups in the FreeBSD ecosystem have a lot of interest in some aspects systemd, launchd, etc., and patches exist for several different implementations in various states of completion. At this point though your statement is just speculation and has no basis in fact; there is no current plan to integrate this work into FreeBSD proper.

A fair statement would be "FreeBSD may eventually adopt a systemd-like approach."

What makes you say FreeBSD is eventually going to adopts a systemd like approach?

And what do you mean by a systemd like approach?

http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-..., slides 32 and 33:

"etc/rc.d is quite sophisticated for what it does, but the paint on /etc/rc is obvious"

"Too many things need to know explicitly about dependencies"

"Even the Linux die-hards have essentially grasped the necessity of systemd"

Talk is by Jordan Hubbard, FreeBSD co-founder (https://en.wikipedia.org/wiki/Jordan_Hubbard)

Discussion at https://news.ycombinator.com/item?id=8645188, video at https://www.youtube.com/watch?v=Mri66Uz6-8Y (49 minutes)

Jordan is pushing this into FreeNAS/TrueNAS and NextBSD. He would love to see this happen in FreeBSD as well, but from what I've seen it isn't moving anywhere.

there is no proof of this. Several FreeBSD derivatives might (FreeNAS for example), but there is no definitive sign that a systemd-like approach is coming to FreeBSD.

(The FreeBSD core team appears to strongly dislike all the currently proposed options.)

Hopefully it will be nosh and not launchd. nosh can also import systemd units, so it's a good way to support daemons predominantly developed on Linux+systemd.

nosh can also import Warden-configured jails. They become individual native services, separately controllable with service start/stop and with parameterization adjustable with rcctl set/get .

It furthermore provides a FreeBSD jails extension to the systemd unit file syntax. The JailID=i setting for a service unit is translated into "jexec i" in the native service bundle's run program.

Doesn't matter really, with all the complaints, ramblings of systemd.. system admins will be forced to move to systemd. An admin has no choice since the company they work for runs it's entire stack on GNU/Linux and will not switch to another OS because of an init system.

Remember, companies used to run their entire stacks on things like Solaris, or on IBM mainframes, until someone snuck a Linux box in there somewhere. Change does happen, even when policy exists.

That perspective is a case by case. From the perspective of a sysadmin who is powerless to make decisions and not taken seriously by his/her management, maybe you're right. From the perspective of a consultant or trusted sysadmin hired to streamline architecture, maybe not.

Nope, I don't think this is it. The problem with lxc, jails, zones, is that of shipping the state of the containers. Docker solves this with the registry. I think that they would each be as successful (or more-so as the tech is more baked in) if they had a better developer story.

Being able to docker pull/commit/push is what made docker so popular with developers. The "alternatives" all seem to lack this. I almost see it like I see dpkg vs apt-get. You can do what you need with a pile of deb files and dpkg -i, but why, when you can simply apt-get install? Same concept.

FreeBSD seems to have the hurdle that linux had for so many years - hardware support.

Server hardware is well supported though. To be honest, anecdotally I've found desktop hardware to be pretty well supported too. Not to the level where you'd use it for gaming (gaming software support aside), but for general use it's a usable desktop. In fact I seem to recall FreeBSD working better with WiFi than Linux did, back when WiFi support in Linux was relatively new and often required using a userspace wrapper around Windows binaries.

Obviously there's always room for improvement and people's experiences often differ, but I've honestly had no major issues with hardware support in the ~15 years I've been running FreeBSD.

And presumably the binary NVIDIA driver should work more smoothly because the kernel doesn't break installation of the driver at random times.