4 ms·

Why do commercial Linux products only target specific distros? E.g. Steam on Debian/Ubuntu, Davinci on RedHat/CentOS. Is it just to reduce support costs or are

by pcr0 10y ago

Why do commercial Linux products only target specific distros? E.g. Steam on Debian/Ubuntu, Davinci on RedHat/CentOS. Is it just to reduce support costs or are there other technical differences in play here?

killjoywashere 10y ago
I think this is the way to go actually: start at the really high end. Who has Linux desktops? Google engineers and professional video color people. Maybe the Mazzaratti engineers will be allowed to play next.
- erichocean 10y ago
  Most professional 3D apps also run natively on Linux.
figgis 10y ago
I imagine it's much easier to maintain a working release for one distro and allow the package maintainers for other distros to package it how they need. Than it is to provide support for the endless amount of distros out there.
JoshTriplett 10y ago
Proprietary software can't follow the "here's the source, let distributions package it or users build it for any platform they like" approach. They have to build it for target platforms, so they pick a few and target those. Products with non-upstream kernel modules have a similar problem, but they additionally have to support a range of kernels, and it's easier to just say "we support RHEL and SLES" if they think that will suffice for their customers.
- thinkmassive 10y ago
  To be fair though, there are multiple distro-agnostic package platforms becoming available. For example flatpak, snap, and even electron. I realize this last one is essentially a webapp build tool, but that's sufficient for a number of tasks. The first two can package nearly anything, and can even offer additional benefits (principal of least privilege) on top of a typical deb/rpm. Edit for clarification: it should be feasible to target libraries rather than full distributions.
Sanddancer 10y ago
Both. Good support is expensive and rarely a "just". Adding a new supported platform means having to train your support techs in all the quirks that come out in using said platform, and those little things add up in a hurry. On the technical side, each distro has their own similar, but not quite the same, different set of patches against base software and build options which can potentially interact with your software, etc, all of which will need to have regression testing done against before release. Furthermore, software like RHEL itself is supported for a known duration of time, so developers can build their own release and support schedules and not have to worry about getting the rug pulled under them.
paridae 10y ago
In the case of Steam they have SteamOS, which is Debian-based, and hardware products. But the client itself is agnostic and packaged in lots of distros.

by pcr0 10y ago

killjoywashere 10y ago

I think this is the way to go actually: start at the really high end. Who has Linux desktops? Google engineers and professional video color people. Maybe the Mazzaratti engineers will be allowed to play next.

erichocean 10y ago
Most professional 3D apps also run natively on Linux.

figgis 10y ago

I imagine it's much easier to maintain a working release for one distro and allow the package maintainers for other distros to package it how they need. Than it is to provide support for the endless amount of distros out there.

JoshTriplett 10y ago

Proprietary software can't follow the "here's the source, let distributions package it or users build it for any platform they like" approach. They have to build it for target platforms, so they pick a few and target those. Products with non-upstream kernel modules have a similar problem, but they additionally have to support a range of kernels, and it's easier to just say "we support RHEL and SLES" if they think that will suffice for their customers.

thinkmassive 10y ago
To be fair though, there are multiple distro-agnostic package platforms becoming available. For example flatpak, snap, and even electron. I realize this last one is essentially a webapp build tool, but that's sufficient for a number of tasks. The first two can package nearly anything, and can even offer additional benefits (principal of least privilege) on top of a typical deb/rpm. Edit for clarification: it should be feasible to target libraries rather than full distributions.

Sanddancer 10y ago

Both. Good support is expensive and rarely a "just". Adding a new supported platform means having to train your support techs in all the quirks that come out in using said platform, and those little things add up in a hurry. On the technical side, each distro has their own similar, but not quite the same, different set of patches against base software and build options which can potentially interact with your software, etc, all of which will need to have regression testing done against before release. Furthermore, software like RHEL itself is supported for a known duration of time, so developers can build their own release and support schedules and not have to worry about getting the rug pulled under them.

paridae 10y ago

In the case of Steam they have SteamOS, which is Debian-based, and hardware products. But the client itself is agnostic and packaged in lots of distros.