Hacker News Reader

Besides... have you seen what happens when people are actually successful at pushing compatibility? Have you seen the shit people throw at Lennart/RH for Systemd? Why would anyone ever want to play that game?

Let's not bait with systemd, that's a different issue.

Package manager interoperability is certainly a political issue. A lot of distributions are identified by their PM infrastructure, so adopting a universal one like Nix or Guix would mean losing their identity. Conflict of interest, quite clearly.

We might end up with, GNOME-based distros at least, running a NIH version of Nix called xdg-app, however.

Package management is the least of our worries when it comes to cross-distro compatibility.

What truly affects companies wanting to release and support their software on multiple distributions is the lack of universal fat-apps. And yes, xdg-app is the way to go - sadly, only GNOME has been leading that front and cross-desktop talks have stopped.

The XDG mailing list is dead. Sending an email there is equivalent to pissing in a violin.

Meh, I'm pretty jaded. But I totally do think systemd is a clear example of what happens when a group tries to push for less NIH and more standardization. Tools get replaced and people get upset.

xdg-app is a prime example of NIH. It poorly reinvents reproducible, deterministic and isolated builds when battle-tested and academically sound solutions like Nix are available off the shelf. People refusing to adopt it is a good thing in my book, it'll only be harmful in the long term.

The Linux community has rejected fat apps (primarily fat ELF binaries) many times, so that's not out of the ordinary.

I find the idea of systemd being less NIH to be quite baffling, though. Just look at its ad-hoc LISTEN_FDs protocol rather than adopting something well designed like UCSPI.

"fat-apps"? What is the difference between that and a tar.gz with all dependencies included? Mozilla offer Firefox that way, Opera used to offer, well, Opera that way (until they wen't full retard and cloned Chrome).

Heck, a RPM is pretty much a fancy tar.gz at first glance (and a DEB a bit more elaborate).

I swear i wonder of far up the devops exhaust channel the Linux userspace thinking has gone these days...

> What would you have them do? Support it on every single distribution out there?

No, say that Unity comes to Ubuntu.

It's supported on Ubuntu, but if it's available there, it's essentially compatible with Linux. You can't realistically not be compatible with Linux if you're available on Ubuntu.

Ubuntu is Linux, I don't use Ubuntu. I use mostly OpenSUSE/SUSE and sometimes Arch or a Redhat version and if I must Ubuntu or Debian. It will work in Linux just wish we had a solid second tier desktop Distro.

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.

Thanks to things like SystemD this will continue down that road (Ducks).

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.

SystemD pretty much takes over the core of the OS. This has helped the trend of Distros being interoperational with each other. This is why some people HATE SystemD.

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.

The package systems never had init system integration. What some PMs did was they ran procedures in the postinstall scripts to do things like update SysV symlink farms. In Debian, this was done by sysv-rc and in RPM-based distros, chkconfig or something similar.

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.

> The package systems never had init system integration

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.

Distros are undeniably becoming more alike thanks to systemd, but from this premise does not in any way follow that package interoperability will be improved, which was the topic at hand.

(To be pedantic, there is no "standardization" so to speak of. It's more like an informal fiat than anything.)

BUT deamons are now standardized on how to init them into systemd.

"standardization" straight out of the MS play book that is...

For what monetary end game???? I don't want to start the SystemD debates again but what "play" out of the playbook with what evil end game motivation?

Does it have to be monetary? Best i can tell, the people involved are on what may border on a holy crusade to "improve" the desktop Linux experience. Meaning that to them the goal justifies the means.

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?).

Binary compatibility is certainly a major issue but I think you are downplaying the compatibility headaches introduced by the way each distributions are solving the same issues with slightly different methods. I'm thinking of: logging, default character sets, locale, timezones, mount points & encrypted block storage, basic OS versioning information, networking, service management, networking. And I'm forgetting a plethora of others areas. There were/are attempts to have standardization around some this, like the FHS or the LSB for example. But it's hard to argue that systemd was far more successful into bringing a semblance of order than any past attempts. There's still a long way to go.

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.

Pretty much all of those were de facto standards, as provided by X.Org, util-linux, wireless-tools, the syslog protocol, fstab(5) and so forth. The situation was nowhere near as grim as is often presented, considering much of it was just standard kernel and shell interfaces. Encrypted storage has always had multiple different approaches, and remains so.

And those that grumbled about it was more often than not people working to automate large server farms or similar, not your average software dev.

Automating large server farms is a very different job from being an Independent Software Vendor (ISV).

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 :)

I disagree. You're referencing to specific _tools_ being used as a de facto standard and this is certainly true to some extent.

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.

As a Slackware user, I'd hardly attribute the compatibility of "supported for Ubuntu, other distros be damned" software on non-Ubuntu distros on systemd :)

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.

No the WHOLE POINT was Linux is coming CLOSER to each other and SystemD is ONE example of standardizing in the general Linux community.

I'd argue that compatibility between distributions isn't a strictly good thing - but rather serves to hamper innovation and new developments in userland from distros in all but a few cases.