I think you missed the point. Prior to systemd, Debian was truly the universal operating system in the sense that it ran on just about anything, and you could swap out the kernel (not a trivial thing to do, but possible) for the FreeBSD kernel, for example. Because systemd is Linux-only, this is no longer possible. Because the list of smaller userspace utilities dependent on systemd is growing faster every day, it's likely that Debian will end up being no different from Arch, Fedora, RedHat, or Mandriva overall, apart from the package manager. Basically GNU/Linux is becoming GNU/systemd/Linux.

Some people don't have a problem with that, some do. In the end it's not about choosing an init system; indeed, I think a lot of the arguments and opposition to systemd would go away if systemd were interchangeable with any other init. But that's not the case; if your distro of choice has decided to go with systemd, then you're running systemd or you're not booting (yes, there are shims in Debian right now but they exist only for migration purposes).

You seem to be confusing Debian with NetBSD...

How so? Debian runs on more architectures and with more flexibility (prior to current events) than any other GNU/Linux. NetBSD also runs on just about anything, including toasters, but systemd isn't an issue there since it won't work on any BSD. I'm not sure why you would think that I was confused about it at all.

You have never been able to exchange glibc on a Debian system, or replace dpkg with rpm, or (in recent releases) run without udev.

Highly recommend to read this excellent mail by Russ Allbery on portability and Debian's history:

https://lwn.net/Articles/618322/

I played around with upstart, it worked fine.

Alternative init systems are a very old idea implemented over and over for decades.

The "innovation" of systemd is product tying it deeply to Gnome. Nobody is willing to kick out Gnome, so they can make everyone else do whatever they want. Including, say, making it impossible to run any other init system.

By analogy it would be like product tying emacs into python, such that you can't install or run vi if you have python installed at the upstream level, because the default location for python temp files is now /usr/bin/vi. Well, I guess you could stop shipping python, or cave in and remove vi. This is the "innovation" that is new in systemd. Merely being an advanced init is really old stuff.

And if it was done commercially, an antitrust lawsuit may have been considered. It is that kind of tying that got MS into hot water regarding IE after all.

Are you serious? sysvinit's modular architecture allows an easy substitution with other alternatives, that's why you can replace it with say systemd and have a working system.

I ran something called InitNG for a while under Gentoo, and I know there are people running Gentoo's openrc on Debian (though technically that still uses sysvinit as PID 1, it just replaces the service management layer running on top of it). Most Docker containers are running something different from the standard init, though what exactly they use varies. And so on.

YEp, i don't think people know how minimal the core of "sysv" really is. There is one binary, init, that do the initial (heh) lifting. From there on it hands things over to one or more files. These can be binaries, scripts, or a mix of both.

On Debian/kFreeBSD? 1, but that's 1 more than after systemd.