Alright, I'm an acquaintance of the author, so let me clear things up.
SystemXVI only began less than a couple of weeks ago, and is still a very early stage project. However, the author (David Mackay) decided to be a bit of an expedient troll and advertise on /g/, to arouse some controversy. It ended up blowing up greater than anticipated, even ending up being mocked on Linux Unplugged and hitting /r/linux as the project was still a skeleton.
First thing's first:
This is not a joke project. Mackay is not some amateur, either. He's a former Solaris/illumos committer and most recently was involved in the Tox community. He actually wrote a small service manager called Charge last year as an experiment, and some of the logic is borrowed on to SystemXVI (though the architecture is different).
SystemXVI, the design is quite interesting. The closest equivalent would probably be Solaris SMF, but it's still different. init(8) is kept small and instead SystemXVI is based on the idea of the service repository (inherited from SMF) and delegated restarters. The repository is a hash table that stores instance information and service properties. It's useful for having a point of fault recovery and to introspect services in a dynamic, transient manner as they run.
The primitive process management is currently in libs16rr, but the actual supervision strategy is defined in restarters. Much like Solaris SMF, there is a master restarter, but certain services (i.e. local socket services) can, for example, opt to be watched by a delegated inetd-like restarter that uses the SystemXVI RPC interfaces. Or let's say you have a Java, Erlang or other service that needs special behavior, you can write a restarter for it while reusing SystemXVI's process management.
TI-RPC/SunRPC plays a big role here. It's much leaner than D-Bus and at least nominally capable of network transparency. Android has a portable implementation in ~5000 LoC.
Dependencies and ordering is actually calculated by a separate process called svcorder, influenced by BSD systems' rcorder(8).
There will be systemd unit file compatibility. Internally, SystemXVI has semantics similar to systemd units, but much simplified - no need for transactions or complicated job modes, since a repository is used instead to contain state.
It's a refined SMF-like system with influences from daemontools and BSD rc.d. Very microkernel-ish, it's meant to have strong module/communication boundaries and have its components be easily hotswapped or rewritten per a stable RPC interface.
It's very early and the project really shouldn't be getting such publicity, but a pre-alpha might be out soon, and it's a project well worth watching. I have confidence it will turn out well.
I think it's great to see someone writing a new manager that is inspired by SMF.
I would love to see a (series of?) blog post(s) about SMF. This wouldn't be a missive against systemd, but given that SMF has seen 10 years of production use, it would be a valuable history lesson. Why was SMF needed for Solaris, what was scope of responsibility, why were the abstractions picked, why were its boundaries where they were, and finally what has and hasn't worked for it?
It seems like the technical community would eat that kind of content up.
Indeed, there are lot of good resources that came out when it was introduced. But that's not quite the same as someone being able to put the story into context of today's technology and status quo. Ideally the history lesson comes from someone with knowledge of SMF from many angles.
For instance Bryan Cantrill (full disclosure I worked for/with Bryan while at Joyent) was at Sun for the development of SMF, he's had experience using SMF in production, and more recently from his LX Brand work he's been exposed to the facilities that Linux has created to deal with the same sorts of issues.
Bryan is a superior technologist and a hell of a story teller, I'm sure I would enjoy reading/hearing his telling of why things like libproc and contracts were created and how they evolved over time, and if that as any relationship to why SMF is designed and behaves the way it does.
Note, Bryan is just an example -- there are many other people in the community that were there and could tell the stories. He's just the first person I thought of.
The point is that [re]creating interfaces/subsystems is ok, so long as we do that with the full view of history, such that we avoid that repeating cliche.
> even ending up being mocked on Linux Unplugged and hitting /r/linux as the project was still a skeleton.
To be entirely fair, I think there are few communities that can claim the honour of being worse and more amateurish than /r/Linux. It's incredible how many Linux experts who have used nothing but Arch Linux for about an year can gather in one single place. Every once in a while there's an OK post, but it's downvoted.
I hope your friend didn't take them too seriously.
/r/linux is schizophrenic. On the one hand, posts about new game releases for Steam are voted up and (Steam) gaming posts are quite active. On the other hand, they're badgering every single FOSS project which is trying to make money without begging their users for it (see the recent posts about Firefox). It's crazy.
I have no idea what to recommend anymore. Most of my colleagues, myself included, have either moved from Linux to BSD or OS X land (depending on preferences) or just stopped being too involved. Helping people learn about software in general (and sometimes, but not necessarily, Linux in particular) used to be fun and rewarding. Nowadays, about 70% of the answers are either "Yeah, that's a bug they don't want to fix because they don't think it's a bug" or "I know that's not how you do it in Finder but that doesn't make it broken."
The Linux ecosystem is increasingly centralized and most of the organizations that are centralizing it, like the Gnome project, are actively discouraging contributions that don't match their agenda. This is reducing the importance -- and cohesion -- of any community. It's no coincidence that many people are finding less common ground in software they're all using than in software they're all hating.
The only Linux community I'm still vaguely in touch with (I read the mailing lists and sometimes the forums) is the Gentoo community. Largely because my only remaining Linux machine is running Gentoo. It eats a lot of my time, but stubborn USE flags control seems to be the only way to get a usable Linux distribution lately, and I'd rather spend an extra hour a week configuring it carefully enough to keep crap software out than spend a whole evening each month dealing with sudden breakage. It's not necessarily a friendly community, but most people seem to know what they're talking about.
Frankly, as bitterly as it may sound (and it's coming from someone who started using Linux just in time for the 2.0 to 2.2 switch), I'd rather recommend the OpenBSD community.
What about the ArchLinux community (IRC/forums/wiki etc)?
Arch has both made it easier for new Linux users to adopt it day-to-day while still appeasing the more advanced users, ala Gentoo. The Arch wiki has been the single best contribution to the Linux desktop world in recent memory IMO.
I'm curious how the more hardcore *nix users view it.
> I'd rather recommend the OpenBSD community.
My attempted to use OpenBSD and take part in the community left me disappointed. On the surface it seems to be exactly what I'm looking for (correctness + security). But I was turned off by the culty vibe of the users and it seemed like a backwaters in terms of software versions, as everything outside of the core seemed severely outdated.
I have... mixed feelings about Arch :-). It certainly doesn't appease me in any way; I don't use Gentoo because I like speed or especially DIY. I've done a lot of DIY crap on my Linux machines in the 90s and 00s. I don't enjoy doing it again. The only reason I use Gentoo is that, via the thickest web of USE flags I've ever woven, I can keep freedesktop.org's EverythingKit, most of Gnome's crap, pulseaudio and systemd out of my system. I can't really do that on Arch.
I think Arch is good in terms of "learning experience" for someone who wants to learn more about how a distribution is put together, but that's about it. I used it for a while, back in 2005 or so, but our later contacts have been... less than fortunate. I tried it again two or three years ago and my system regularly broke after every update. I eventually ragequit when I ended up with a system that wouldn't boot because, in The Great Move of Everything to /bin, it somehow managed to screw up the bootloader. I figured my data was going to be next, wondered what the fuck they were thinking even in the context of a rolling release, shrugged and wiped it out.
The Arch Wiki is a great repository of information though. It's even better than the Gentoo wiki was, back before it got (disastrously) wiped out.
> I'm curious how the more hardcore *nix users view it.
They probably think lowly of the whole Linux thing, but what do they know :-)
> But I was turned off by the culty vibe of the users and it seemed like a backwaters in terms of software versions, as everything outside of the core seemed severely outdated.
I found the culty vibe of the OpenBSD community to be far less obnoxious than that around... pretty much any major Linux distribution.
There are quite a few outdated packages in ports though, yes. That's often because of a lack of maintainers, but there are programs where that's just because of compatibility problems. There are very few broken packages, if any, in the ports tree -- and sometimes the broken status is very paranoidly assigned (i.e. I've had packages that were marked as broken but it turned out they ran just fine).
> I tried it again two or three years ago and my system
regularly broke after every update.
Having used Arch for years and experienced the same thing years ago I've found that stability has greatly improved in the last year or two. I believe they were going through some major transitions back then and now have found a good stable foundation which they are now building on.
I haven't had it break in a very long time and having brought this up before on HN I've had many other people share a similar experience with Arch.
Although this is possibly due to the fact I've become significantly more experienced with Linux as a result of my professional work. Dedicating yourself to a single distro and becoming deeply familiar with it can be rewarding in that sense.
>TI-RPC/SunRPC plays a big role here. It's much leaner than D-Bus and at least nominally capable of network transparency
Isn't that true of D-Bus as well? I mean, maybe it's just semantics, but if you're going to use the word "nominally" (read as "it claims to be") when saying it's network transparent, D-Bus is certainly "nominally" network-transparent as that's an advertised feature of it.
Network transparency is most certainly not an advertised feature of D-Bus. There has been some experimentation, but nothing concrete has ever come out of it. Nor does anyone really use it as a remote protocol.
In contrast, SunRPC is RPC, so network transparency is a given. The reason I said "nominally" is because in the case of SystemXVI, having proper distributed service management (not a goal at this point) would require more than that.
Which is more or less what CoreOS's `fleet` already does on top of systemd. They used a different protocol for remote communications (etcd, ie. HTTP+JSON) vs. local, which I guess can be a sensible choice as requirements are quite different.
Yes, and they had to create an ad-hoc layer over systemd using a particular K-V store. Contrast to the more generic and seamless option of RPC interfaces, which are more versatile in making policy decisions.
I've never liked SMF's XML format, but it is by far one of my favourite process managers from my Solaris days (back when Sun still existed, since then I haven't touched it :-().
hanks for setting the record straight. I am glad you stepped up and explained. I always come to HN for expert insider comments, and people like you do not disappoint.
Alright, I'm an acquaintance of the author, so let me clear things up.
SystemXVI only began less than a couple of weeks ago, and is still a very early stage project. However, the author (David Mackay) decided to be a bit of an expedient troll and advertise on /g/, to arouse some controversy. It ended up blowing up greater than anticipated, even ending up being mocked on Linux Unplugged and hitting /r/linux as the project was still a skeleton.
First thing's first:
This is not a joke project. Mackay is not some amateur, either. He's a former Solaris/illumos committer and most recently was involved in the Tox community. He actually wrote a small service manager called Charge last year as an experiment, and some of the logic is borrowed on to SystemXVI (though the architecture is different).
SystemXVI, the design is quite interesting. The closest equivalent would probably be Solaris SMF, but it's still different. init(8) is kept small and instead SystemXVI is based on the idea of the service repository (inherited from SMF) and delegated restarters. The repository is a hash table that stores instance information and service properties. It's useful for having a point of fault recovery and to introspect services in a dynamic, transient manner as they run.
The primitive process management is currently in libs16rr, but the actual supervision strategy is defined in restarters. Much like Solaris SMF, there is a master restarter, but certain services (i.e. local socket services) can, for example, opt to be watched by a delegated inetd-like restarter that uses the SystemXVI RPC interfaces. Or let's say you have a Java, Erlang or other service that needs special behavior, you can write a restarter for it while reusing SystemXVI's process management.
TI-RPC/SunRPC plays a big role here. It's much leaner than D-Bus and at least nominally capable of network transparency. Android has a portable implementation in ~5000 LoC.
Dependencies and ordering is actually calculated by a separate process called svcorder, influenced by BSD systems' rcorder(8).
There will be systemd unit file compatibility. Internally, SystemXVI has semantics similar to systemd units, but much simplified - no need for transactions or complicated job modes, since a repository is used instead to contain state.
More here: https://github.com/ServiceManager/ServiceManager/blob/master... (Flowchart: https://github.com/ServiceManager/ServiceManager/blob/master...)
It's a refined SMF-like system with influences from daemontools and BSD rc.d. Very microkernel-ish, it's meant to have strong module/communication boundaries and have its components be easily hotswapped or rewritten per a stable RPC interface.
It's very early and the project really shouldn't be getting such publicity, but a pre-alpha might be out soon, and it's a project well worth watching. I have confidence it will turn out well.