It would require a radical shift among BSD developers and the companies that sponsor them to make any serious inroad into the desktop. AFAIK, there are almost no BSD developers contributing to DE's like KDE or Gnome.

This is probably because the focus for BSD's are servers; their sponsors pay for making server software that may be close sourced. All the major DE's are using GPL toolkits, so BSD developers are unlikely to make any contributions besides the minimal required work to make the DE's work on BSD.

In case that eg. Wayland support don't materialize on BSD, then I find it much more likely that DE's like KDE and Gnome will split their code, leaving it up to BSD developers to maintain whatever they need to make those DE's run, in the same way OpenBSD does with OpenSSH.

It doesn't.
That a particular distro/package maintainer utilizes their distro's init-system and service manager for launching a daemon is hardly a problem or even controversial.

It seems to me that have some problems with understanding what an init-system does. SysVinit/systemd/SMF deals with starting daemons and similar processes, not end user programs like games. Of course, if a game has a server mode what uses sockets and what not, then it probably is convenient to use a proper init-system.

There are many different OS container modes, from running single services, to full blown servers. Each mode has it advantages and disadvantages. That flexibility is exactly what makes OS containers interesting.

Unlike other OS container implementations, systemd also support running unmodified Linux distros as containers. That means that I can boot a standard Debian distro on top of my Fedora distro, or running a newer unstable version of my distro on top. It takes seconds or minutes (depending on net speed) to launch such a container. A great way to test and debug new stuff without bothering with a full VM.
The "machine concept" that allows maintaining OS containers from the "outside" is also way cool.

All in all, systemd is on its way to become the best OS container manager the world have ever seen, and that is great news for Linux.

"journald" isn't useless, even if you don't use binary logging, but forward everything directly to syslog.
"journald" works as a syslog helper that enhances syslog by collating all logfiles into a single file (instead of around +5 logfiles, some of them binary like "utmp"), and by collecting logging info from early boot, since journald can log from before even the root file system is mounted. When kdbus is mainlined, it will be able to collect "metal-to-metal" logging info, that means before rootfs is mounted, and after it is dismounted. Try that with syslog.

It also provide per-damon rate limiting and notification when syslog drops messages (syslog silently drops messages).

All in all, it would be stupid to turn of journald, even if forced to rely on flat file text logs.

There is exactly one project that joined systemd, and that was the basically one-man project "udev". The udev inventor is also the co-inventor of systemd, and that project started way before Red Hat had even started to say "no" to using systemd (they later said "yes"; read the interview). So it is demonstrably wrong to claim that RH could have forced Kay Sievers/udev into the systemd project.

Dbus isn't a single project, but a standard just like tcp/ip with several different implementations. systemd makes heavy use of dbus, and even have some dbus helper libs, but the point is that systemd works with the "standard" dbus specification, regardless of implementation. That is the whole point of using a standard.

All the talk about RH/systemd "subsuming" other projects are simply plain wrong.

Systemd isn't broken by design, it is in fact a brilliantly designed init-system which is why all major Linux distros are converting to it.

"UNIX philosophy" seems to be a codeword for "I have no real technical arguments against systemd".

But tell me this, if the most popular certified UNIX platforms are using init systems very similar to systemd, like SMF and launchd, aren't you really claiming that certified UNIX'es aren't UNIX?

Even non-certified UNIX clones like FreeBSD are talking about the necessity of having a init-system just like systemd/SMF/launchd. It is only a matter of time before all *BSD's have a modern init-system, and of course, they will clone every systemd feature possible.

The point is that this is all done by different daemons and tools. So each systemd tool basically just do one thing. It is documented in the man pages if your are interested in facts.

Oh and by the way, systemd doesn't do "ntpd". Claiming that is a sure sign that you haven't studied the systemd documentation. systemd comes with an optional sNTP client that is meant for use in OS containers, which have special timekeeping needs because of timedrift between host and container when sleeping etc.

That really isn't the case with systemd; it basically depends on glibc and util-linux for "mount" etc. just like most other init-systems, but everything else is optional.

That upstream projects actually make use of systemd features like systemd-logind can hardly be a problem either; all the non-systemd platforms are free to provide their own similar services that upstream projects can use, so there are no problems there either.

Some facts first; systemd's journal isn't proprietary. It is a well documented standard with a stable API and language bindings:
  http://www.freedesktop.org/wik...
There are several independent journal readers already. I can't think of any non-contrived user case where it is a problem that the logs are binary.

In fact, I can't think of any non-contrived user case where old style flat text file logging is better than systemd's journal; it scales better in every direction and allows for powerful filtering in a much better way than using humongous regex lines, is much more secure, allows for a single collated system log and much better debugging, etc. etc.
Not forgetting that it is now possible to have reliable, robust logwatch scripts and even make a log viewing GUI that isn't just a glorifed "less" with windows decorations.

Just like you I have been bitten by (proprietary) binary log files (and much worse; binary config files). And just like you I was really, really skeptical about systemd's binary log format. But the more I used it, and the more documentation I read, the more I became really glad about it: systemd's journal just solves so many problems I have had over the years with syslog files. It is a really well thought out and well designed logging system.

If you don't understand it, it is probably because you don't use OS containers. Almost all new features and development on systemd the last couple of years have been OS container related; the sNTP client, networking, dhcp etc., are all meant for massive scale OS container deployment, and for the special need for OS container regarding keeping time (their environment can start-stop/freeze without notice, so time drift between host and container is a problem).

Google launches 2 billion OS containers a week, that is 3300 OS containers every second. The speed of "booting" a single OS container is therefore crucial for such massive deployments.

In fact, OS containers are rapidly becoming a central part of all new Linux deployment, and systemd is a central part of that.

So nothing on Linux must ever change, because there is always some reactionary, lazy admin somewhere who can't be bothered to learn something new and change his work-flow.

I have seen so many examples of such "IT-fossilization" during the last three decades. Some people scream and moan about how "new way" is bad and "old way" is much better. The end result is always the same; they get ejected out of the IT business when their old and obsolete skills are no longer needed.

If you work in tech, you just better have to learn to adapt to new and better technology like systemd. The first step in this is to be factually informed about how the new technology works.

Don't tell me you rely on hearsay from some swivel eyed systemd-hater to know the technical facts about Gnome and systemd?

It is a plain view fact that Gnome 3 runs on non-systemd platforms like BSD. So where is the problem?
Is the problem that Gnome developers for years have pleaded for someone to step up and actually maintain crucial infrastructure needed by Gnome in order to work on non-systemd systems?

If you want "metal-to-metal" logging and collating all logging info into a single file, and remain 100% compatible with syslog, you have no other choice than to design a logging system like systemd's "journald". It can't be split off because of how the Linux kernel is designed and handles /dev/log.

journald can start logging before even the root filesystem is mounted because systemd becomes active already in initramfs and then jumps to the rootfs when it is mounted.

It is a really good solution to a hard to solve problem.

If the cartoonish interpretation of "Unix philosophy" and "modularity" had any real substance, serious people would have forked systemd and split it into "modules". (The core of systemd is; systemd (daemon), udev, and journald; everything is optional). But they don't. The reason is simply that systemd have really, really good technical reasons for being designed like it is.

Link please. AFAIK, it isn't possible to run Xorg as non-root in a safe manner using either CK or ConsoleKit2.

And BTW, the difficulty in running xorg as non-root in a safe manner is caused by the way the Linux kernel handles devices, not Xorg. That is why you need user session management from systemd-logind in order to secure that attached devices can't be abused to compromise security.

Sure, my agenda is to show that supporting multiple init systems is very difficult.

That FreeBSD (and other BSD's) will change to a systemd-like init system is a given thing too. Even the founder of FreeBSD has publicly said it is in the future for FreeBSD.

The fact is that the way people uses computers have changed dramatically the last decade; virtualization, OS containers, instantiated services, mobile devices etc. SysVinit and similar legacy style script based init systems simply aren't up to working with all this.

So when FreebSD change their init system (and they will), they won't support a free choice between the new init system and old legacy script based init systems either.

Well, I am right ain't I. You funnel the donated Devuan money into dyne org, and as CEO/Chairman of that small org with self elected people, with no public oversight of the money, you also pull money out of dyne org into your own pocket to "pay for taxes". Dress it all up as a non-profit org too.

Make Devuan a proper org that directly receive the donated money you are begging for all the time, and have a proper elected committee with public oversight over the donated money and what they are spend on, and then maybe the smell of scam will evaporate.

Without source or citation. I think your representation of what was said is rather biased.

If it isn't a bug, why patch it? Sure, some people have tried to drop some turd patches into systemd, eg. ripping out security features in order to support some obscure glibc variant. The right thing of course is to patch the glibc variant to support the proper security functions, not patching systemd.

No package maintainer wants to support non-trivial, non-mainline patches without very good reasons. The whole point of open source software, that as many people as possible can share and enjoy improvements, so patches should go upstream as fast as possible. Maintaining non-trivial, non-upstream patches can also be a real problem when backporting security fixes, and may introduce patch specific bugs too.

I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.

Huh? The main point is that systemd mainline accepts Debian (and distro) specific patches if it is unavoidable. Despite the many claims to the contrary, the systemd developers do care about feedback and have many different distro developers with commit access. If you got a good user case, chances are good that a distro specific patch will be accepted. And having the patch going into the upstream repo is much better than carrying it as a separate distro patch.

In short, Debian developers where taking part in creating systemd long before Debian discussed making systemd the default init system. So they knew what they where doing when selecting systemd over Upstart (the CLA was enough to discount it), and the latest GR have confirmed that the vast majority of Debian developers firmly backs systemd as the default init-system.