top | item 10372154

(no title)

skarnet | 10 years ago

It's important to realize that "a replacement for systemd" is neither achievable nor desirable.

systemd has grown fast and conquered large market shares because it was backed up by a company, which put a lot of money and manpower into it - to write it, to integrate it, to advertise it. The only thing that has not been correctly funded in systemd is research and design.

systemd is only Open Source if you read the license; all its other aspects are proprietary - it's software made by a company and aiming to capture a market. It is impossible to compete with systemd on the same grounds, because no real Open Source developers will have as many resources as Red Hat.

And even if it was possible, the result of such an attempt would simply be another integrated behemoth, powered by money and marketing instead of good technical decisions. (Or even worse, powered by ideology - can you imagine a systemd-like controlled by the FSF?) In the end, the situation for the users would be even worse than it is today. You don't fight Goliath with Goliath; you don't fight Microsoft's hegemony by buying Apple products.

About interface compatibility: the author of the DnE article (vezzy-fnord) has written uselessd, and finally abandoned the project because the systemd interfaces are so tightly integrated with the systemd design in the first place that it's impossible to be compatible without simply being a systemd clone, which he did not want uselessd to be. No, interface compatibility is not an option, because it would simply acknowledge the validity and superiority of the systemd architecture, and nobody wants a copy of systemd.

I believe that the way to provide an alternative to systemd is to provide all the functionality that the systemd users like, but in a technically better, less integrated, more unixish way.

With s6, s6-linux-init and s6-rc, I now have respectively a process supervision system, a simple init process and a service manager, which should be sufficient for a majority of applications. The next important thing that sysadmins like in systemd seems to be cgroup management, so I'd like to study the thing soon and assess what needs to be done next; but for now, I believe that the s6 family of programs is now viable as a serious alternative to systemd, and I would love to give it a broader audience.

discuss

order

glogla|10 years ago

> systemd has grown fast and conquered large market shares because it was backed up by a company, which put a lot of money and manpower into it - to write it, to integrate it, to advertise it. The only thing that has not been correctly funded in systemd is research and design.

> systemd is only Open Source if you read the license; all its other aspects are proprietary - it's software made by a company and aiming to capture a market. It is impossible to compete with systemd on the same grounds, because no real Open Source developers will have as many resources as Red Hat.

This. The reason systemd is hated so much by "old unix guys" is because it shows that Red Hat basically owns linux the way Microsoft owns Windows and Apple owns OS X.

Many people protested against systemd but it was still pushed by force. It was made specificaly incompatible to make experience on BSDs worse and it sucessfuly removed Gnome from there.

So yeah. Some "haters" talk about unix this and complex that, but I believe it's mostly about scummy company showing off it owns linux now.

derefr|10 years ago

I would say it's more like RedHat has actually stepped up and made a "Linux-derived OS" the way that Android is a "Linux-derived OS" or OSX is a "BSD-derived OS." They've thrown the "basic Unix principles"—the ones that make Linux distributions effectively interchangable commodities, but with software having to target a very low lowest-common-denominator of functionality—to the side, and instead adopted a complete "base system API", in the same sense that CoreFoundation+Cocoa is for OSX, and Win32 is for Windows.

As with those other APIs, you can now "target systemd" in the same way you could "target Win32" or "target Android"—and, because of this, we'll probably see a virtualization library (like winelib is for Win32; like ARC is for Android) spring up, giving other OSes the ability to provide the "systemd API" without needing to run a Linux kernel.

From RedHat's perspective, they were just trying to copy OSX and Android: making a "real OS" atop Unix-y foundations. The interesting thing is that a large number of other providers in the Linux space has started to agree with their design decisions—effectively unifying on the "systemd platform" rather than on the "Posix platform" they were focusing on previously.

I think this has been coming for a long time; the large OS providers already think of Desktop Environments as the GUI equivalent to a "platform" rather than as application software for the OS; thus why Ubuntu, for example, has a separate distribution for each GUI software suite.

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. Early systemd was a launchd clone; upstart also started as a launchd clone before mutating.

I have a feeling that although RedHat was the one to step up and create a platform, all of the major distro providers were actually waiting to hop on the first available FOSS "OS platform", no matter who it came from. If, for example, Apple had created "Apple Linux": a version of Linux that runs the OSX GUI and OSX apps—then I can bet you right now that every other distro would have standardized on whatever "platform" gunk was in-between that GUI and the Linux kernel; CoreFoundation et al would have become to Linux distros as WebKit is to mobile web browsers.

As it stands, it's only an accident of history that this didn't happen with the Android platform. (If the Android Runtime ran native-speed binaries from the start, and the GUI was developed five-or-so years later such that it was developed from the start with Win8-like unified desktop/mobile support in mind rather than getting type-cast as "only for mobile devices", I could bet that Linux would "be" Android now.)

---

With all that said, while all the big, commercially-backed Linux providers have been waiting on tenterhooks for a "platform" to latch onto, all the little distros are looking to remain Unix-y, and that's a wonderful thing.

Think about it: when you've got the POSIX platform "for desktops and servers" and the Android platform "for mobile", and nary the twain shall meet, it makes little sense to care about cross-compatibility; why would you want to run Android apps natively on your desktop? But if you add in a third platform that's also for desktop—the systemd platform—suddenly kernel developers and distro makers and whatever you call the FreeDesktop people start thinking about how to create a Linux-based OS that natively supports multiple platforms, so that it can run code targeting systemd, and code targeting Plain-old-POSIX, without making a mess. And once you have that infrastructure in place... why not let it run code targeting Android too? Why not first-class Wine support? Etc.

One thing Windows has had forever (though lately in a degraded state) is multi-runtime (or, given the above discourse, multi-"platform") support. Windows can be Win32 to one program, OS/2 to another, and POSIX to a third. OSX had the capability for multi-runtime support back when it was called Rhapsody (the "Red Box, Blue Box, Yellow Box" architecture) and also co-supported Cocoa and Carbon apps for about a decade. And these are just single companies trying to meet small needs. Linux, the OS with a kernel that supports every device a nerd ever cared to packet-probe, could easily become "the multi-runtime OS", if we care enough to make it that way.

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

mst|10 years ago

Also, given http://skarnet.org/software/sdnotify-wrapper.c it becomes possible to both use s6's superior notification approach in code and to be compatible with how systemd handles notifications.

This is exciting to me and I would like to encourage you to make it way more obvious, given I've been playing with s6 for a while and still only managed to notice it existed because of http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/un... - and while perhaps that's due to my own stupidity, likely there will be other similarly stupid people who'd also value this information ;)