4 ms·

I worked on some large commercial software for Linux for many years that had to support a wide variety of Linux installs (old and new), I can vouch for it not b

by chipx86 11y ago

I worked on some large commercial software for Linux for many years that had to support a wide variety of Linux installs (old and new), I can vouch for it not being easy. The technical side of supporting Linux in this environment can be very difficult. There are, as you note, issues with the locations or presence of certain files, directories, and scripts. That's one part of the problem, but probably the easier one to solve (we had a whole big function that would try to detect how to open a URL by checking for xdg-open and older variants, checking configuration for KDE/GNOME/etc., and then falling back on detected browsers). This also has to be done for opening arbitrary files using their assigned program. What's more complicated are library dependencies. Depending on system installs on GTK+ isn't always enough. You may need features not available on that install, due to version issues. You may have to work around versions of system libraries that have a bug present on one particular distro due to a custom patch. Themes and icon sets are a problem if you hit any version compatibility problems. Your UI can appear broken if you reference icons that aren't registered on that system (generally an issue on older installs). This actually gets complicated quick in some cases. So as an ISV, you have a couple of options for how you approach all this. You can limit the distros and versions you support, putting out builds for each. This is a perfectly fine strategy if you can get away with it, but not everyone's going to be able to use your program in that case. Another option, which is what we did, was to basically ship everything we needed along with the program. Libraries (glibc, gtk, x11, everything we were forced to ship for compatibility), icon sets, themes, etc. You then try to dynamically figure out which modules you can load from the system, and which you need to load from shipped modules. You also need to handle setting up paths for anything like icon sets and fallback themes you may need, and deal with the compatibility issues that can occur from that (older versions of the XDG icon theme spec didn't have a properly-functioning fallback system when specifying multiple icon theme directories). If you ever need to do anything more specialized (support for hardware devices, anything using D-BUS on older installs, more specialized window management abilities), you run into a whole new set of issues. These days I focus almost entirely on web-based software, so that sort of wide range of compatibility problems are entirely behind me. (Ahem.)

bkor 11y ago
It would be great to still file bugreports for anything you think could be improved in e.g. a distribution. I help out with Mageia. There's often various things which are simply overlooked or people aren't aware of. Obviously your bugreport could be ignored or not dealt with, but it doesn't have to be. It's a small investment to hopefully (years later) have less things to deal with. I do the same when packaging upstream software. Sometimes there are build problems due to configure(.ac) not checking for dependencies properly. I'll then open a bugreport that these checks should be added. All that small stuff helps quite a bit.
- chipx86 11y ago
  A lot of the problems we hit were due to having to support many versions of many distros, not so much a particular bug in one distro. That said, we filed bugs, provided patches, and even drafted XDG specs for some of the issues we were dealing with. The problem is, even if we filed a bug report with a patch for a 3.0 release of some distro, and it was fixed in 3.1, we still had to support 3.0. That meant code that worked with both the buggy 3.0, and the fixed 3.1. That's not a big deal when isolated to one distro or one component, but we're talking all the major distros, various third-party libraries, etc. We may have been a bit nuts, trying to keep such a wide variety of environments supported, but that said, we also got really good at it, and it meant we didn't have to force customers to make changes to their system that they didn't want to make. The products ran on distros so old that they still only shipped GTK 1.2 (though we eventually finally walled off some of the older ones when we started supporting only 64-bit processors).

by chipx86 11y ago

bkor 11y ago

It would be great to still file bugreports for anything you think could be improved in e.g. a distribution. I help out with Mageia. There's often various things which are simply overlooked or people aren't aware of. Obviously your bugreport could be ignored or not dealt with, but it doesn't have to be. It's a small investment to hopefully (years later) have less things to deal with. I do the same when packaging upstream software. Sometimes there are build problems due to configure(.ac) not checking for dependencies properly. I'll then open a bugreport that these checks should be added. All that small stuff helps quite a bit.

chipx86 11y ago
A lot of the problems we hit were due to having to support many versions of many distros, not so much a particular bug in one distro. That said, we filed bugs, provided patches, and even drafted XDG specs for some of the issues we were dealing with. The problem is, even if we filed a bug report with a patch for a 3.0 release of some distro, and it was fixed in 3.1, we still had to support 3.0. That meant code that worked with both the buggy 3.0, and the fixed 3.1. That's not a big deal when isolated to one distro or one component, but we're talking all the major distros, various third-party libraries, etc. We may have been a bit nuts, trying to keep such a wide variety of environments supported, but that said, we also got really good at it, and it meant we didn't have to force customers to make changes to their system that they didn't want to make. The products ran on distros so old that they still only shipped GTK 1.2 (though we eventually finally walled off some of the older ones when we started supporting only 64-bit processors).