4 ms·

Binary compatibility is certainly a major issue but I think you are downplaying the compatibility headaches introduced by the way each distributions are solving

by athrun 11y ago

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.

vezzy-fnord 11y ago
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.
- digi_owl 11y ago
  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.
  - athrun 11y ago
    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 :)
- athrun 11y ago
  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.

by athrun 11y ago

vezzy-fnord 11y ago

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.

digi_owl 11y ago
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.
- athrun 11y ago
  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 :)
athrun 11y ago
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.