Mike Gancarz sums up the Unix philosophy:
 
        Small is beautiful.
        Make each program do one thing well.
        Build a prototype as soon as possible.
        Choose portability over efficiency.
        Store data in flat text files.
        Use software leverage to your advantage.
        Use shell scripts to increase leverage and portability.
        Avoid captive user interfaces.
        Make every program a filter.

Avoiding-systemd asks: Would it be possible to provide some analysis on distros that refuse to implement systemd and its friends? Many people, including myself, believe systemd is taking Linux in the wrong direction. It abandons simplicity and embraces a model of opacity and centralized control, while increasing dependencies and reducing freedom and choice. Being a dedicated Debian user for 20 years, I'm extremely saddened and disappointed that Debian has succumbed to systemd, and that I must now leave Debian to find a new simple yet elegant distro solution that does not implement systemd, and specifically, will never implement systemd as a philosophical decision.
 
DistroWatch answers: When systemd first appeared on the scene as an alternative init system I was optimistic. There was a lot of talk about starting services in parallel and improving dependency resolution during start up and greatly improving boot times. While systemd seemed a bit more complicated than other init technologies, I think most system administrators (and developers) could agree that older init systems could be improved upon.
 
Over the past few years the systemd project has expanded, absorbing other low-level components and adding large amounts of unwanted complexity. Despite the fact many popular distributions (including Fedora, Red Hat Enterprise Linux, openSUSE, Debian, Arch and Ubuntu) have decided to adopt systemd in favour of SysV or Upstart, some users have opposed the spread of systemd. The Boycott systemd website features a list of reasons as to why many believe systemd is poorly designed and implemented.
 
In an effort to be fair to systemd I did a web search for "benefits of systemd" which returned two relevant results. One was the systemd website with its mission statement and the other was the Don't Boycott systemd website which simply stated: "systemd is [a] symbol of big changes in Linux world. Many people talks [sic] about how bad they are. And that's all." Which isn't a compelling argument. Instead, for comments about the advantages and disadvantages of systemd we might look at the recent debate by Debian developers as to whether they should adopt systemd or not.
 
On to the question of who is not currently using systemd and who will not be adopting it in the future. At the moment Ubuntu and most of the Ubuntu community projects have not adopted systemd, though they plan to migrate to systemd in the future. The PCLinuxOS distribution has not adopted systemd and, so far as I know, has no plans to migrate to the new init software. Slackware Linux, CRUX and Gentoo Linux are all Linux distributions which are unlikely to adopt systemd as their default init system for philosophical reasons. (Gentoo does offer systemd as an alternative init technology for those who want it.)
 
Most open-source operating systems which are strictly opposed to adopting systemd are not Linux distributions, but rather flavours of BSD. The systemd project intentionally targets Linux exclusively and this makes it highly unlikely systemd will be ported to FreeBSD, PC-BSD, OpenBSD or NetBSD. In fact, the OpenBSD Foundation began work on software which will allow the operating system to avoid running systemd, but will enable OpenBSD to run applications which depend on systemd. However, since the original poster mentioned running the Debian distribution, I have a potential solution that might avoid any big changes. The Debian project maintains an official port that marries the FreeBSD kernel with GNU libraries and Debian's package manager. I have run this branch of Debian in the past in test environments and if you can get it running on your hardware it will offer the Debian experience as far as the installer and package managing are concerned and the kFreeBSD port of Debian is unlikely to adopt systemd.
 
While systemd has stirred up a lot of strong opinions, both in favour and against the new init system, I suspect most people running Linux desktop systems will not notice the difference when they switch to systemd. I run a different distribution each week and haven't noticed any practical difference between running a desktop distribution that features Upstart, SysV or systemd. The various distributions typically boot at about the same rate, tend to be stable and desktop users rarely need to interact directly with the init process. The only time I interact with systemd is when I'm running it on a server, something the majority of people don't do.

Linus Torvalds: So I think many of the "original ideals" of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation.
 
There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality.
 
It might describe some particular case, though, and I do think it's a useful teaching tool. People obviously still do those traditional pipelines of processes and file descriptors that UNIX is perhaps associated with, but there's a *lot* of cases where you have big complex unified systems.
 
And systemd is in no way the piece that breaks with old UNIX legacy. Graphical applications seldom worked that way (there are certainly _echoes_ of it in things like "LyX", but I think it's the exception rather than the rule), and then there's obviously the traditional counter-example of GNU emacs, where it really was not about the "simple UNIX model", but a whole new big infrastructure thing. Like systemd.
 
Now, I'm still old-fashioned enough that I like my log-files in text, not binary, so I think sometimes systemd hasn't necessarily had the best of taste, but hey, details..

Theodore "Ted" Ts'o, a leading Linux kernel developer and a Google engineer, sees systemd as potentially being more of a problem. "The bottom line is that they are trying to solve some real problems that matter in some use cases. And, [that] sometimes that will break assumptions made in other parts of the system.”
 
Another concern that T'so made — which I've heard from many other developers — is that the systemd move was made too quickly: "The problem is sometimes what they break are in other parts of the software stack, and so long as it works for GNOME, they don't necessarily consider it their responsibility to fix the rest of the Linux ecosystem.”
 
This, as T'so sees it, feeds into another problem:
 
    "Systemd problems might not have mattered that much, except that GNOME has a similar attitude; they only care for a small subset of the Linux desktop users, and they have historically abandoned some ways of interacting the Desktop in the interest of supporting touchscreen devices and to try to attract less technically sophisticated users. If you don't fall in the demographic of what GNOME supports, you're sadly out of luck.  (Or you become a second class citizen, being told that you have to rely on GNOME extensions that may break on every single new version of GNOME.)”
 
T'so has an excellent point. GNOME 3.x has alienated both users and developers. He continued, "As a result, many traditional GNOME users have moved over to Cinnamon, XFCE, KDE, etc. But as systemd starts subsuming new functions, components like network-manager will only work on systemd or other components that are forced to be used due to a network of interlocking dependencies; and it may simply not be possible for these alternate desktops to continue to function, because there is viable alternative to systemd supported by more and more distributions."
 
Of course, T'so continued, "None of these nightmare scenarios have happened yet. The people who are most stridently objecting to systemd are people who are convinced that the nightmare scenario is inevitable so long as we continue on the same course and altitude.”
 
T'so is "not entirely certain it's going to happen, but he's afraid it will.

This summer I, along with my mentors Landry Breuil and Antoine Jacoutot, worked on systemd shim-like replacements for four D-Bus daemons systemd provides, namely hostnamed, localed, timedated, and logind.
 
Now let's clear some things up:
 
The purpose of this GSoC was (is) not to port systemd to *BSD in way, shape or form. Nor is it to replace the existing init(8), boot(8) or rc(8) programs. Systemd and *BSD differ fundamentally in terms of philosophy and development practices and special care was taken to only wrap the functionality of the aforementioned daemons and not create any new systemd-like functionality.
 
Upon completion and review, my code will most likely end up as a port to be installed along with the GNOME suite, or any other ports that depend on systemd (upstream) and need a compatibility layer to work properly on non-systemd operating systems. It goes without saying that none of my code will end up (or belongs) in the base system.
 
Hostnamed (formally systemd-hostnamed) is a D-Bus daemon that handles setting system hostnames (in our case, that's through the sethostname(3) call and the /etc/myname file) as well as provides system information mostly found through uname(1). Hostnamed also handles determining the system's chassis type, whether it be a server, desktop, laptop, handheld, VM, etc. and providing a proper icon from that information.
 
Localed and timedated are more straightforward daemons that allow setting system/xorg locales/keymaps and times/dates/timezones/NTP settings respectively.
 
Logind (currently unfinished) is a rather large daemon that encompasses many aspects of a user's login session. This includes everything from getting current users and any PIDs under them, as well as system suspension and shutdown/reboot preparation. We are still researching a proper way to implement this as native systemd uses PAM for authentication, something we do not want to do on OpenBSD.

 
forking systemd is certainly a kooky thing to do, but we feel it had to be done, as a blunt statement (and because of our aforementioned qualities). Even in this light, uselessd is not just a political protest. We aim to make it usable and as a solid alternative for people who want the features the systemd core provides (socket activation, parallel execution, resource limiting, cgroups, the declarative configuration syntax, etc.) without the unnecessarily intrusive features, as well as maintaining a conservative development philosophy that prioritizes conciseness and focus over an ever-rolling gargantuan for system-critical software like this.
 
Nonetheless, we do believe there are problems with the state of contemporary Linux application development, both philosophical and technical in nature. Linux has become a de facto hub for Windows refugees, who seem to have brought the baggage with them. Opaque service libraries, intrusive, all-encompassing and poorly documented system daemons and frameworks, laughable pipe dreams of a “year of the Linux desktop”, among many other things plague the Linux userland today.

The fact that systemd offloaded a lot of work for distro maintainers was probably the main motivation for its adoption. Distro maintainers are lazy.

Our TODO list isn’t particularly impressive, but here’s some general things we’re planning for:
 
Getting the Manager interface running on FreeBSD.
Integration into other operating systems, including NetBSD, OpenBSD and Debian GNU/Hurd.
Refactoring of the core and shared files.
Testing on dietlibc. Setting up a diet-based system takes some effort. If you have time and resources, be sure to try it out and send us patches (more like pull requests in this case, but what the hell...)!
Get the uselessd Linux build to run as a userland process supervisor, without necessitating that it serves as PID1, as well.
These are more long term goals and kind of general, but we'll iterate as we move on. Join us.