> What would you have them do? Support it on every single distribution out there?
No, say that Unity comes to Ubuntu.
No, say that Unity comes to Ubuntu.
Gone are the days when distros decided if something worked or didn't. Thanks to things like SystemD this will continue down that road (Ducks). Also hoping we finally do package management in a elegant modern way soon and not like we are right now.
How? systemd touches a completely different layer. The main thing that might prevent ELF interoperability across distributions is if the distro has some esoterically configured binutils/glibc toolchain and the provided application is a dynamically linked binary blob.
Before SystemD we had init scripts in our thousands of packages. Each package system would have different init systems and procedures. This is one of the big reasons why things were not inter-operational between distros. This is why Arch and Debian among others distros jumped off their old init systems and adopted SystemD.
They're completely orthogonal tools.
And no, it was hardly a "big reason" why distros weren't interoperable. Initscripts were rarely supplied by upstream vendors and frequently written downstream. Then many other people didn't use them at all, but wrote runscripts for some flavor of daemontools in about 4 lines or something.
The main reason has always boiled down to the toolchain. One proposed way to get around it was fat ELF binaries, but that effort got metaphorically curbstomped by the Linux community. Universal package managers aren't supported for political/branding reasons.
In any event, systemd doesn't help with this.
Never said integration saying packages have scripts to init themselves and that was different based on your distro.
Don't know why you feel the need to correct a point that distros are becoming more and more alike and that systemd is one of the elements that has helped this? Anywaysssss SystemD is the standard now for most of Linux and I am hoping for MORE standardization.
(To be pedantic, there is no "standardization" so to speak of. It's more like an informal fiat than anything.)
And if you question this you are simply an ignorant infidel that will see the light in due time, they just need to spread the gospel more fervently (or should i say forcefully?).
The general lack of compatibility between distributions usually leads software publishers to packaging and testing only one or two versions of their software. The community will then try to repackage it for other distributions. When the apps are not 100% open-source, it usually leads to huge delays for updates and broken packages after a while.
One difference is that as an ISV you don't have a lot of control on the way the system is setup, you have to start with assumptions and then work from there. -> Your job is to make your software work on fragile systems.
When you are dealing with managing systems at scale, hopefully you know exactly what you're dealing with. You don't have to make assumptions, you _control_ what components are on each box. -> Your job is to make your systems run broken apps :)
However, the incompatibilities come from how these tools are configured: there are numerous ways of interfacing/configuring X.org, syslog, networking and wireless tools, etc. Generally each distribution comes up with its "own true way" of doing it. This introduces a lot a pain for anyone trying to come up with a generic way of working with underlying subsystems. It's not impossible but it takes a lot of effort, is very fragile and needs an ongoing maintenance to keep up with the changes introduced by the distributions.
My point is that systemd exposes a set of capabilities and known interfaces you can rely on being there. This is far from being enough but it still an improvement in my eyes.
Linux software is compatible with any GNU/Linux distribution (and even some non-GNU Linux distributions). It's only a matter of having the right libraries and environment installed. That might be easier when things standardize on things like systemd, but for most software, such implementation details rarely matter.