I'm the one who originally submitted this on 9/1/14, FWIW.
I'm not sure if there's any substantial progress update yet. Last I heard, they're still waiting for kdbus to be merged, after which they'll need to finish up the GNOME sandboxing features, and only then will they truly start.
Given that kdbus is receiving some shaky reception, it might prove to be a while.
The weird thing to me is why Nix was never brought up. Not only that, but Lennart was actively avoiding the question when he submitted this to his G+ feed.
It's indeed extremely odd they never say a word about Nix, Guix or even Gobo Linux.
Ignoring history usually leads to reinventing things in a bad way. Nix for example, has put a lot of effort into getting all these things right. Why not having at least a look into it to see if we can borrow many of their ideas?
That's the same thing they did when systemd was first released. Everyone complained it's not too wise to have a huge process running as PID 1, yet they never even considered these criticisms.
While systemd brings some valuable things to the table, I wonder if they price to pay is too much. We seem to be destroying all elegant Unix core concepts and creating a messy architecture of tightly coupled components.
Because they don't use the sexy tech de jour, containers.
Gobo and Nix (Guix is something of a reimplementation of Nix) get around the whole "dependency hell" that Poettering's container fetish is supposed to solve without requiring the use of container, cgroups, or any of the other "sexy" that systemd uses (though i have come to understand that Nix has adopted systemd).
Heck, Gobo is basically driven by shell scripts. And its boot system is the sysv's init binary combined with homegrown scripts (it may be likened to BSD init).
Containers are also part of Nix (which unlike Guix uses systemd). AFAIK, in Nix these are used for booting up an isolated environment (e.g. if you're running some binary which you perhaps would like to isolate).
But they are two different things: nix package manager -> managing dependencies, containers -> managing isolation.
By performing both at once, I feel systemd is not only breaking the Unix ethos (do one thing, and do it well); but it may eventually also creep into the package manager arena. Eventually, most userland will belong to systemd.
Ignoring Nix is a blatant sign of failure. systemd could learn a thing or two, or even a few dozen things from the language design itself.
About UNIX concepts, they're hidden temporarily because systemd, IMHO, is surfing a deep wave of change in the way OSes are understood. It's very declarative, open to instrumentation (virtualization). Turning the machine into an object. In a few years ideas will have settled and maybe tiny unix-like core components will emerge.
I assume they didn't mention nix for the simple reason that RedHat and Debian and other distros aren't going to give up their own packaging setup. So the only way forward is to work with what you have.
Err, what the blog entry describes is just as disruptive to the deb/rpm setup as what nix is doing.
Heck, i think with some clever symlinking you could in theory dump a rpm into its own (optionally versioned) subdir and still have it working in the grand scheme of things.
The biggest stumbling block for current package management is that of versioned libs. Usually they work around this by putting different package names on different major lib versions.
NIH isn't limited to the commercial world. There's a problem to be solved, and inventing a solution is much better for one's career than pointing out an existing solution.
I'm not sure if there's any substantial progress update yet. Last I heard, they're still waiting for kdbus to be merged, after which they'll need to finish up the GNOME sandboxing features, and only then will they truly start.
Given that kdbus is receiving some shaky reception, it might prove to be a while.
The weird thing to me is why Nix was never brought up. Not only that, but Lennart was actively avoiding the question when he submitted this to his G+ feed.