Ideally the history lesson comes from someone with knowledge of SMF from many angles.įor 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.īryan 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. But that's not quite the same as someone being able to put the story into context of today's technology and status quo. Indeed, there are lot of good resources that came out when it was introduced. 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. 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 a refined SMF-like system with influences from daemontools and BSD rc.d. 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. There will be systemd unit file compatibility.
#Systemrescuecd stuck at rpc portable#
Android has a portable implementation in ~5000 LoC.ĭependencies and ordering is actually calculated by a separate process called svcorder, influenced by BSD systems' rcorder(8). It's much leaner than D-Bus and at least nominally capable of network transparency. 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. local socket services) can, for example, opt to be watched by a delegated inetd-like restarter that uses the SystemXVI RPC interfaces. Much like Solaris SMF, there is a master restarter, but certain services (i.e. The primitive process management is currently in libs16rr, but the actual supervision strategy is defined in restarters. It's useful for having a point of fault recovery and to introspect services in a dynamic, transient manner as they run. The repository is a hash table that stores instance information and service properties. init(8) is kept small and instead SystemXVI is based on the idea of the service repository (inherited from SMF) and delegated restarters. The closest equivalent would probably be Solaris SMF, but it's still different. SystemXVI, the design is quite interesting. 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). He's a former Solaris/illumos committer and most recently was involved in the Tox community. 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. However, the author (David Mackay) decided to be a bit of an expedient troll and advertise on /g/, to arouse some controversy. SystemXVI only began less than a couple of weeks ago, and is still a very early stage project. Alright, I'm an acquaintance of the author, so let me clear things up.
0 kommentar(er)
