[vezzy-fnord]

In a discussion of systemd history held here previously, it was pointed out that back in 2007-or-so, there was a large amount of interest expressed by various distro makers in adopting OSX's launchd as the basis for a new platform standard, if only it had been FOSS at the time.

I don't think there ever was a large amount of interest. In fact, the only party that studied launchd at the time (circa 2006) was Canonical. It was indeed licensing issues that stalled further research, but there was also another contender at the time being considered called initng, which Canonical ended up rejecting and went on to write Upstart instead, led by Scott James Remnant. See SJR's proposal and introduction to Upstart. [1]

Early systemd was a launchd clone; upstart also started as a launchd clone before mutating.

Upstart was never a launchd clone to the best of my knowledge. launchd was likely a spark that influenced Canonical to take action, but the design is pretty different.

Your musings about the "multi-runtime" convergence that systemd will allegedly enable do not appear to pan out. systemd is nothing like the OS X Core frameworks or like the Windows Runtime, it's much lower level than that. It's more of a middleware than a runtime platform (think Hurd, not Core Foundation).

There is also absolutely nothing implying that GNU/Linux will ever target Android code. The divergences are plentiful, with my article about an Android init porting attempt listing only a few. [2] Nor is there any expressed interest from any Android vendor to have any serious GNU/Linux convergence to begin with.

Not sure what "first-class Wine support" is supposed to mean. Wine is pretty self-contained.

If we don't, though, at least systemd is decent.

You're too big of a dreamer, I'm afraid.

[1] https://wiki.ubuntu.com/ReplacementInit

[2] http://blog.darknedgy.net/technology/2015/08/05/0-androidini...

[derefr]

> systemd is nothing like the OS X Core frameworks or like the Windows Runtime, it's much lower level than that. It's more of a middleware than a runtime platform

You're not considering the full scope of the thing labelled "systemd." If you only use parts of it, it's middleware, yes. If you "work with the grain" of systemd, though, then you're packaging services in nspawn containers and so forth, which does constitute a separate "platform target", in the same way that e.g. CoreOS is a (mostly-ignored attempt at a) "platform target."

Basically, I'm talking here about a Linux equivalent to Solaris's "Branded Zones": within a container boundary, an app can be made by the system to think it's running on "systemd Linux", or on "POSIX Linux", or on "Android Linux", or on BSD or Win32 or Cocoa or whatever else. Runtime-virtualization is done at the system container-management level (with more or less help from the kernel), rather than expecting applications to "port" themselves by applying their own proprietary virtualization wrappers ala Cider for OSX.

> Not sure what "first-class Wine support" is supposed to mean. Wine is pretty self-contained.

I mean, basically, support to the level of DOS applications run in Win32 VMM containers, rather than to the level of X11 applications run on OSX: management of Wine sandboxes as OS-level "runtime containers", such that you could run and maintain Wine apps alongside other apps, in production, using the OS's maintenance tooling. A Linux "ReactOS Runtime" equivalent to Windows's "POSIX Runtime."

> Nor is there any expressed interest from any Android vendor to have any serious GNU/Linux convergence to begin with.

I don't mean to suggest convergence. This is something very different: making "running an Android binary" a primitive action of the system (not the Linux kernel), where "using an Android virtualization layer" is then an implementation detail of how the system accomplishes this. Think of Linux's binfmt_misc and its ability to execute e.g. JVM code by booting a JVM, but with an upcall to the init daemon to decide how to implement the policy of running a particular binary format. If that init daemon is effectively a container-manager that understands how to instantiate and manage different "branded containers" for each runtime it supports, Linux multi-runtime support just falls out.

[vezzy-fnord]

nspawn containers are yet not really used as a platform target, and currently Docker is leading. Though nspawn has since acquired some notion of the Docker image format, and even in light of the OCI standard, I do not foresee it becoming a primary container solution in its present form. rkt being nspawn-based may or may not take hold.

Indeed, systemd is as of yet not comprehensive enough to be a POSIX-parity target. There is no "systemd Linux" as such, it's systemd/GNU/Linux or Linux with the GNU and systemd suite. Android is a top-down integrated system on the other hand and does not linearly track GNU/Linux.

As of yet, there is nothing like system call emulation or similar in nspawn to have branded zones.

Nor does Red Hat's present actions imply something like this. The GNOME project, affiliated with Red Hat, is working on a poor reinvention of Nix called xdg-app to enable the "app frameworks and runtimes" design that Lennart Poettering wrote about in "Revisiting How We Put Together Linux Systems," but that too is firmly specific to GNU/Linux as the host.

Red Hat is also leading a container OS called Project Atomic, however nothing like branded zones is seen there as a goal, either. Instead, they've made a simple meta-framework for running various Linux container images over several orchestration frameworks and PaaS, called Nulecule. It's firmly a layer over Docker and Kubernetes, however, so it is limited to that.

A Linux "ReactOS Runtime" equivalent to Windows's "POSIX Runtime."

That would be quite a feat in of itself, systemd or branded zones aside. ReactOS isn't Wine, but even with Wine it would be a sizable integration effort.

If that init daemon is effectively a container-manager that understands how to instantiate and manage different "branded containers" for each runtime it supports, Linux multi-runtime support just falls out.

The init daemon is not a container manager in this case, but an object-oriented resource management with a transactional job scheduler and some limited execution environment modification that work with namespaces and cgroups, but the container framework is outside. As it should be. An init daemon as your container manager sounds dreadful and horrifying, though I hear RancherOS boots from Docker as PID1...

But as there is no such init daemon yet nor anything like branded zones, I still have to say you're a dreamer. This might be a long-term strategy, but with acts like Project Atomic it really doesn't look like it. I still think it's more middleware than Core runtime. I pray it is...

[derefr]

Note that I wasn't suggesting that systemd is itself an attempt at an "init daemon with branded zones"—instead, it's a particular runtime that will increasingly differentiate itself from POSIX Linux, and I believe that that friction will eventually cause developers to want to create an init daemon with branded zones to supercede systemd, where emulating systemd-as-it-stands (for apps built to expect it) would be one of that multi-runtime system's goals. With the POSIX people and the bigcorp Linux providers pulling in opposite directions, a multi-runtime Linux would be the only Nash equilibrium. (Though it'd need someone like FreeDesktop to suggest it and start a working group for it, because neither "side" would care about it on their own.)

That may not be the way things play out, certainly. Things might just diverge and stay that way, if nobody cares enough to change things. But there are unknown unknowns that can give things a very hard shove in that direction. For example: imagine that systemd decides to integrate deeply with GNOME, to the point that you now have an integrated "systemd+glib+GNOME platform" with a unified API, the way that OSX is a "launchd+CoreFoundation+Cocoa platform". That would be an extremely divergent target in the Linux ecosystem introducing a lot of friction to everyone else's development efforts—similar to the early stages of the Android project—and it would get a lot of people's hackles up. But it's not out of the realm of possibility for RedHat and Debian to agree on something like that.

[vezzy-fnord]

instead, it's a particular runtime that will increasingly differentiate itself from POSIX Linux

Ah, correct.

I believe that that friction will eventually cause developers to want to create an init daemon with branded zones to supercede systemd, where emulating systemd-as-it-stands (for apps built to expect it) would be one of that multi-runtime system's goals. With the POSIX people and the bigcorp Linux providers pulling in opposite directions, a multi-runtime Linux would be the only Nash equilibrium. (Though it'd need someone like FreeDesktop to suggest it and start a working group for it, because neither "side" would care about it on their own.)

It's a hypothesis, then. Plausible, certainly. I assume you're presenting this as a probable way out of the portability concerns from GNU/Linux becoming more of a closed environment to the point of instigating a massive developer schism? This still raises the question of why it would need to reside in the init daemon, but I suppose crass architectural decisions are not a stranger to Linux developers.

For example: imagine that systemd decides to integrate deeply with GNOME, to the point that you now have an integrated "systemd+glib+GNOME platform" with a unified API

Such a decision might just backfire quite tremendously and prove to be systemd's overturning, though it does sound like a similar integration is very much in the spirit of the project. Then, yes, radical surgery would occur, but it may not be quite as dramatic as branded zones and simply an abandonment of systemd and related Freedesktop-ware.

RedHat and Debian to agree

Debian aren't really that large of a player, more of a passive target platform. Being a non-affiliated foundation, they're generally steered into things by whoever is on the committee and seldom ever lead themselves. So, no agreement strictly necessary.