It is interesting that JH's conclusion; that the changing computing landscape (mobile/mass deployment/virtualization/etc) are making systemd-like OS building blocks a necessity for (Free)BSD in order to stay relevant.

Couldn't agree more. Any OS that stagnate into solving yesterdays problems instead of tomorrows, is going to wither away.

I really didn't think I'd hear something like this from one of the FreeBSD founders, so guarded are the community of the current init system. 

FreeBSD and progress? This is joke.

One thing I really want (for Linux as well) is remote debugging (+telemetry and others sorts of system integration). There is an unfortunate tendency to use adb (eg, Ubuntu Touch), unfortunate because it's so crappy I can't even begin... The iOS approach with usbmuxd as a high-perf remote service hub is really nice to work with in practice, and could be used for more than just debugging. (AND the open source version of usbmuxd is actually faster than Apple's :-))

but… but… if *BSD gets something like systemd, where will all the Unix diehards will go, now?! ;-)

I think he's referring specifically to launchd, hence the joke about it, and there's been some work on launchd in the ports tree.

I think most server administrators (still the biggest part of FreeBSD's user base) still don't see the point in it, and they're not really covered by the use cases.

What may change is if a third party decides to invest in this particular direction and make it a standard. 

+James Trimbee​ I thought a 3rd-party already had (i.e. Apple) invested in making launchd work.

I don't know what iOS uses to start things but I thought Mac OS X used launchd.

+Anand Kumria It's there (in ports) but nobody seems to want to use it. It'll take a big server vendor I suppose, but I guess people like Netflix don't necessarily benefit from something like Launchd. 

I'd love to see more of FreeBSD on mobile and laptop but it hasn't been their area up to now and I don't see that changing. 

Well, if FreeBSD guys actually do that, it is likely that they will not repeat the flamed parts of systemd, like binary logs and non-portability.

I wonder how Linux specific the DBUS-interfaces of systemd are.

+Emmanuele Bassi They can still wait for The Hurd ;).

+Aigars Mahinovs I'm willing to bet over a crate of beer with you that whatever init system the FreeBSD people will be coming up with, it will be certainly not portable. One of the fundamental reasons why systemd is so much better than previous init systems is because it takes advantage of modern features that the Linux kernel provides that are not available on other kernels. And I am pretty certain that FreeBSD will gain similar modern features and the FreeBSD init system developers are going to use them.

+John Paul Adrian Glaubitz i wouldn't be so sure.
they've discussed porting apple's launchd in the past,
& they've recently discussed the use of openbsd's systemd-like utility.
both of those presuppose that software portability is an ABSOLUTE REQUISITE

+Poppy Faria
They have discussed porting launchd but they never went through with it because launchd isn't really a good design. It supports socket-activation only as far as I know and there are no other ways of starting services. Filesystem checks during boot have to be run outside launchd. It's design approach is the main reason why launchd wasn't really adopted outside OSX.

+John Paul Adrian Glaubitz make that two crates of beer, at least currently I do not see a way to please portability fetishists and achieve the required design or implementation. can safely assume that people that insist on this have no clue on what this entails. even the old, distro specific variations of sysvinit were not portable. this is just a figment on the imagination of some purists.

There is already openlaunchd :
https://github.com/freebsd/openlaunchd
This is a port of launchd to FreeBSD. Launchd is very powerful and a pure success story. It runs in Mac OSX since OSX 10.4 and it runs stable as hell. Why do we not all use that? I know why ..... its the licence thing!!
Damn, launchd is brilliant and it is free!! Why not use that?
Why reinvent everything when you already have it?
 On the page above one reads:
"The primary goal of this project is to port launchd in its entirety over to FreeBSD, hopefully making it usable by other BSD or Linux systems along the way."

+Al Gebra Because launchd has a very limited focus on MacOSX and requires *all* daemons to be patched for it, quoting:

DEPENDENCIES
Unlike many bootstrapping daemons, launchd has no explicit dependency model. Interdependencies are expected to be solved through the use of IPC. It is therefore in the best interest of a job developer who expects dependents to define all of the sockets in the configuration file. This has the added benefit of making it possible to start the job based on demand instead of immediately.

Thus, if you have one daemon on *BSD that doesn't support socket activation or similar, it won't work. systemd, on the other, does support all daemons and even init scripts that run on System V Init.

I don't think the BSD people are going the way more radical, launchd approach.

+Cristian Rodriguez Exactly. In the end, developers have to make the decision where they weigh the portability against modern features, fewer bugs and more performance.

There is no point in keeping a port for an obscure target platform if the audience on that platform is negligible.

We had many people in Debian coming up with the non-portability as an argument against systemd, claiming that systemd is bad for the kFreeBSD port which they considered important to Debian. However, as of now, there is only one active maintainer of that port left. On the other hand, we have around 10 people maintaining the 68k port of Debian and yet that isn't even a release architecture, these people (including me) just do that for fun while kFreeBSD was supposed to be used in production. Luckily, the release team dropped the kFreeBSD port from the stable releases for these obvious reasons.

And I don't really think that the FreeBSD developers care so much about portability. Heck, their whole development model has always been keeping the whole operating system in one repository, including the complete userland. Yet, it's the systemd developers who get flamed for things like that.

Maybe all the anti-systemd circlejerk will move to "devuan" now, the proposed fork of Debian, and let the rest of Debian move forward.

Well, it looks like Debian is now going to "fork" away from systemd.
https://devuan.org/
...wait a go, Lenny !
:(

+Rick Smithson There isn't a single Debian Developer involved in this what you call a fork as far as I know, being a DD myself. And furthermore, this isn't even the first Debian derivative, there are already dozens of these like Ubuntu and Linux Mint. So this isn't something even worth a news post.

And, no, Debian didn't decide to use systemd because "Lenny" forced it upon us. We chose systemd because it is by far better than the huge pile of mess that System V Init is.

+John Paul Adrian Glaubitz

 That's because Gnome/Depain DD's like yourselves stopped listening to Linux/UNix User's/Admins many moons ago.  hence it'll be done the GNU/Linux way and thankfully NOT your way anymore -understand now? -it couldn't be more simple to understand -jus like simple shell-scripts to administer simple startups, instead of a horrendous single-point of a failure -aka systemD'uh !

+Rick Smithson The original Unix way is NOT how SysVInit works these days. In fact, the modern way distributions used SysVInit was a complete abuse of the original design.

Init was actually designed to start daemons through /etc/inittab. Anything below /etc/rc.d was just to be run once when changing runlevels and the idea is to run things like "mount -a" or "rm -rf /tmp" and not starting daemons which inittab is for which allowed automatic restarting of crashed daemons.

The problem with inittab is however that there is no way to declare dependencies. Back in the 70ies, Unix didn't need that. Network interfaces and filesystems were static, daemons were started during boot. However, more recent development in the userland did require that. For example, the NFS server requires portmap to be running, so you need to somehow tell init it has to load portmap before nfsd. Init was born long before NFS, so they didn't have to think about dependencies.

And since inittab doesn't provide any mechanisms for dependencies, someone thought it would be a good idea to abuse /etc/rc.d for that, the runlevel script mechanism. However, since this one was never intended to start daemons, they had to invent double-forking such that a daemon can detach from its init script. However, double-forking means that init no longer has a reliable way of telling whether a daemon is running or not. The moment the PID file is gone, you have absolutely no way of telling.

I have seen countless cases on webservers and build daemons were "service <bla> restart" would return with "OK" without actually doing anything because of the aforementioned limitations.

Seriously, SysVInit in it's last implementation was an abuse of the original design and never worked reliably and anyone who understands that because they actually cared enough to dig into the underlying code is welcoming the depreciation of SysVInit through systemd since systemd was written from scratch taking the needs of a modern operating system into consideration.

And, btw, I don't even use Gnome. So there is no need to go ad-hominem. In fact, I have sponsored and reviewed many WindowMaker-related packages in Debian and things like Openbox and fvwm.

Lets atleast realize something, first of all, systemd is not a realization of an automation-creep of an init system, it's an abomination. SMF was a realization that improved secure administration, (for Solaris-eyes-only) without getting in the way of everything else.
 There is a difference.
Mr Hubbard needs to also realize, this is NOT about camera-time for pretend-pro-unix photo-ops, it's about unix-security staying intact. Systemd answers NONE of the aboce, and launchd is little else than questionable Apple motives/plugins.

+Rick Smithson Can we stop with the agenda "Everyone is an idiot except me?"

It's getting boring. People have elaborated endlessly why systemd was needed and eventually adopted. There is no need to rehash the same non-sense over and over again. The fight is over and the vast majority of distributions have jumped the bandwagon.

If you don't like it, don't use it. There are distributions like Gentoo and Slackware which allow to stick with non-systemd solutions.

Worked for apple for 10 years, meh.

I don't understand why FreeBSD "needs" a new direction in their init system. FreeBSD is a minimalist system out of the box with only a few internal daemons like moused, ntpd, and sshd starting at once in the system. The rest of the daemons are add-ins for a customized system tailored by the system administrator for the purpose of the system. Starting daemons in parallel, even with tree-based dependency loading, is self-defeating in FreeBSD because no two systems are exactly alike. Yes you can have a generalized desktop of FreeBSD from the handbook, but FreeBSD and a typical Linux distribution like Fedora, Slackware, Debian, or VoidLinux have nearly nothing in common with design, features, deployment, and software included with the distribution. FreeBSD is more akin to Gentoo, but even then the similarities are few and far between. Plus FreeBSD has it's own building blocks in a monolithic design specific to FreeBSD, so honestly, the system works and no change is needed if the system is tightly coupled together like it is.

Adding launchd, SMF, Runit, or any other init system to FreeBSD doesn't really solve a problem, but merely sidesteps the issue of the fact the system already is customizable, and little change is needed. Add onto that the fact that while FreeBSD is developed at a slower pace in mind with hardware support, they do allow for a lot of OEM drivers from the manufacturer and do make it a point to get a driver working correctly rather than issue out a skeleton driver that is either incomplete in features, requires excessive usage of firmware, or simply is broken. Nouveau comes to mind as the project to get Nouveau in was summerily postponed because Nvidia themselves provide a driver. Argue free versus OEM all you want, the pount is the OEM is at least providing a driver and it does work.

But in all, FreeBSD is not Linux, and is not GNU, nor is it GNU/Linux, so how can you compare FreeBSD and GNU/Linux even using a minimalist distribution like CRUX or Gentoo that have nearly equal status to FreeBSD respectfully, when neither of the two sides of the equation can truly be compared. It's a UNIX-like system similar to GNU/Linux, but equally, it's a different operating system and environment all together.

Plus, I've never understood the hatred people have for FreeBSD. I've used a variety of systems over the years, and while you do have to do homework into a system to research hardware requirements, even GNU/Linux often can have issues with bleeding edge hardware for at least 3 to 12 months depending on how fast kernel developers receive hardware specifications to include driver support vectors. I don't seethe need for equality in systems. Systems that are different provide uniqueness and quirks that make that system what it is and specialized in. It doesn't matter to me if I use OSX, Windows, GNU/Linux, Illumos, or even DOS. FreeBSD is just another system out there doing it's thing. Loving it or hating it is one thing, but trying to do a comparative judgment against a system completely different, is just ludicrous.

+Kenneth Harrison go back to the cave neckbeard, you fear change, so keep using old ass operating systems while the rest of the world moves forward. "Add onto that the fact that while FreeBSD is developed at a slower pace in mind with hardware support," hahahahaha I loaded pc bsd the other day and my internal wireless was not picked up, and wireless on laptops is not uncommon, so why do a lot of people hate freebsd? because of people like you clinging onto the 70's. The driver support still sucks even in 2014, and if you are one who thinks it should only run command line only on servers, good for you, the rest of us would like to use it everywhere. If the old init systems are just fine, why has windows had a similar system to systemD for years i.e. windows services. Why did OS X go to launchD, why are the linux guys going to systemD, why is one of the founders of freeBSD saying they need a new init system. I tend to think that the tons and tons of other insanely smart guys who created and develop these OS's know more than you, so shut your mouth and go back to your cave you old fart.

How can I fear change when I use a variety of operating systems? Just because you failed to read the FreeBSD hardware compatibility list, it's FreeBSD's fault? No, you like a lot of other trolls failed to weigh the consequences of your actions. You made the mistake, now others must clean up your mess? I think not. You're going to harshly find that us "old farts" don't tolerate insolence from youth who try to be the nail that sticks up.

I never even said change is bad. It's the fact all change is never good. Change for the sake of change is moronic, misguided, and unilaterally stupid to partake in. Until you see the broader picture, your talk on the immediate and short term only makes you look like a fool, an idiot, if not completely inept at your own arguments and their points.

I never said systemd was inherently bad. Yes it has good ideas. But like all people in the world, our points of view are going to differ. Is it right for all systems? That truly remains to be seen per the situation, and there are numbers of them. Think, if you are using systemd to launch a couple dozen services at once on a PC, is it going to help, yes. What about just one service? Probably not. Why wait time and resources on just one single service? Now do you see?

FreeBSD and PCBSD are the same system, but PCBSD is a distribution, I personally have used it, but then again, I was smart and careful to read the hardware compatibility list, ask questions on the forums beforehand, and then install using what I had learned. That's being wise, and wisdom comes with age. Now, please, do yourself a favor, go actually learn your systems instead of sniveling and whining like a spoiled brat who isn't getting the toy at Christmas they felt they wanted, but instead got the socks they deserved.

Just think, one day you'll be an old fart too, and when someone tells you to go back to your cave, remember our conversation well please.

The telemetry API ideas sound nice too.

If systemd was "an init system" people wouldn't be freaking out over it.

The problem is that systemd is a complete replacement of the core userland.

+Peter da Silva The same goes for the opponents. The problem isn't that they're against systemd or the changes it introduces, the problem is that the vast majority of them fails to bring up actual technical arguments which renders the whole discussion pointless.

Even if there are no technical defects with systemd, the fact that it creates dependencies on systemd APIs is a huge problem that would not exist if systemd was "just an init system".

+Peter da Silva I'm sorry, but if you say something like that you actually have to explain WHY these dependencies were a problem. Moreover, there isn't a strict dependency on "systemd APIs", just projects like GNOME or KDE that decided to migrate to logind.

If you can't accept that, you're free to fork these projects and do whatever you want. However, there is something fundamentally wrong with the attitude to tell developers what to do and what not. Everyone is free to write the software they want.

If Linus Torvalds decides to drop Linux altogether and write Windows applications, he's free to do that. No one can keep him writing the code he wants.

And the same is true for the GNOME, KDE and systemd developers. They have decided to replace the old init system and the session managament with a new design and they're free to do that.

Dependencies are inherently a problem.

* They increase the complexity of a system, because you have to include everything it's dependent on as part of the system. This makes debugging harder, because you can't eliminate problems in the subsystem you're dependent on by switching it out.

* They decrease the portability of the software, because it now requires the dependency and so it can no longer run on platforms that don't include that dependency. This is the biggest one, particularly for FreeBSD users who are already unable to use projects that have unnecessary Linux dependencies.

"If Linus Torvalds decides to drop Linux altogether and write Windows applications, he's free to do that."

That doesn't mean it wouldn't be a problem. Just because someone is free to do something that causes problems doesn't mean those problems don't exist.

+Peter da Silva Again, then go ahead and fork. You don't solve these "problems" (I put that in quotation marks because I don't agree) by ranting here but by writing actual code.

You're free to jump the Gentoo, Slackware or *BSD band wagon if you disagree what's happening here. No one forces you to use a systemd-based desktop.

I use FreeBSD. I'm trying to draw the distinction between "a new init system" and systemd, explain why FreeBSD using a new init system doesn't necessarily imply that it's going to something like systemd, and explain why people object to systemd because it's not "just a new init system".

If you're not interested in understanding other people, just say so. I have no interest in trying to teach someone who doesn't care about learning.

OK guys, please find a different place to discuss this. The next one who comments here, discussing whether systemd is evil or not (regardless which side you are on) I'll block right-away. You have been warned, and you are welcome!

+Lennart Poettering Great, block me, I want absolutely NOTHING to do with "Lennart Linux" thank you very much!