6

Linux is great - to tinker, to pull in all your FOSS, mess around...
But it's so fucked up, if you actually build and maintain a product on it, i.e. try to distribute s.th. in binary for money even. It's just not intended. If you offer your code for free, you can always say: "Ah, just compile it yourself. You might need these 29 dependencies, of which 2 are not even checked by configure, oops, and now it crashes, maybe in that qt library version, you picked there's still a bug?.. you know, it worked on my machine, sorry."
But if you sell it, it better install and run! And even if you target only the main distros of all that fragmented Linuverse - let's say, Debian, Ubuntu, RHEL, CentOS, Fedora, and if you're in Germany OpenSuSE and SLES, you'll start to see the crap of work you're up with. What you could try is to orchestrate a docker fleet with one container per distro, where you take the oldest version you still support compile a newer gcc there (to at least have C++11) and all your third party libs and then hope the resulting binary runs on all the newer versions of that distro, too.
(You could even be so brave as to try to pick a deb and rpm distro to build for all other distros.)
But ABI incompatibility can still bite you. For instance we once had the insane case, that our GUI would no longer start just by switching the Window-Manager to KDE.

Comments
  • 1
    Have you ever heard of appimage, or other projects like it?
  • 1
    @-vim- Sure, also briefly considered snap and flatpack. But it doesn't seem so widely used, that any of these ideas has gained enough traction to overcome the diaspora.
  • 0
    Idk I've hardly used software on Linux which didn't work.

    And most packages are available through the package manager anyways.
  • 0
    @linuxxx Generally, I was also really pleased in how most recent desktops work out of the box. Not like Gutsy Gibbon (Ubuntu 7) where the WiFi would just not work (speaking of that my colleague and I now experience some instabilities on Ubuntu 18.04 again.) - Printer can also still be a pain. With some Sharp at work even after importing the ppd-file some filter component would go haywire. Did not fully get around to extract the coredump out of CUPS -

    But this also not so much about the user perspective, but how hellish life of maintainer has to be. If for example you have customer still lingering on their RHEL 5 box which should long be dead but has extended support till 2020 (wanna know how *old* this is: their gcc is still 4.1.x - openssl some 0.98 - on the upside that's why they were not even affected by Heartbleed)
  • 0
    @andros705 Gladly I don't have to do much on Windows, but enough that I experienced this dll-dependency-hell-problem two or three times.

    Also if you read the good ol' SimCity story (https://joelonsoftware.com/2004/06/...) you might imagine that MS will tightly control ABI-compatibility of their tool chain.

    If you are always on a very new and shiny distro, you'll probably not even see that kind of problems on Linux ever, but just try running one of the newer binaries on an old CentOS and shit will break loose (this one here: https://github.com/phusion/...)
  • 0
    Mmmh... Just wondering, but couldn't this be solves by including some static libraries in your package? Of course it's always better to use native ones, but...
  • 0
    @soulsuke For our own libraries we already switched from static to all dynamically and back (due to licencing you might not link statically with all 3rd party libs), tried to bundle the libstdc++ from the compiler we compiled with, but we still get f**.

    Just today I almost spent entirely on trying different versions of Qt, because Qt 5.11.0 had some nice renderer bugs crashing our application.
  • 1
    this sounds a lot like Shiny Things disease: you grab the latest *something*, it won't built on your other something, and that's somehow unexpected.

    There's a really big reason why people develop on stable platforms, and it's to minimize all this dependency hell at the cost of less shine.

    Packaging was simple 20 years ago, and it can be even simpler with CI/CD techniques. Currently I'm building RPMs triggered by code pushes -- it's that easy once it's all set up.

    Your talent shouldn't be impaired by an inconsistent environment and builds that fall over constantly, and this is definitely possible.
Add Comment