1. 46
  1.  

  2. 28

    There’s an implied assumption in distros that old versions are stable and good. Unfortunately all packages are forced to conform to that, and it causes pain for packages that don’t fit this assumption.

    Not every project can afford to maintain multiple old release branches and make it possible to backport fixes.

    It’s super annoying for authors when users complain about bugs that have already been fixed years ago, and there’s no solution other than to tell users to stop using their distro.

    1. 16

      I wonder how much of this is the distro model being designed around being…. actually physical distributions. Debian in 1998 was for many an entire set of CDs, and all the little packages in it were assumed to be part of the operating system you were just slicing like a ham. It was both a freezing of the world in that state of time, and pretending it was all one big mass.

      Likewise, how much did internet distribution change the assumptions that made the distros in the first place? Are they still valid ones? I’m thinking a lot about this and what my answer would be.

      1. 4

        I don’t think stable release cycles are tied to the physical distributions. It is assumed that users of a stable distro with a release cycle of 2 years just expect things to be stable for 2 years. If they need 5 years, they find a distribution with a 5 year release cycle. Distributions are often seen as responsible of distribution old software, but for most software, users just expect stability. People not interested in stability can use Arch or Debian Unstable.

        The main problem is that for some piece of software, some users may want a more recent one. Debian answers this with backports (by Debian), Ubuntu with PPA (by random people). For desktop-type applications, there are distribution-agnostic methods, like Flatpak.

        Releasing more often would be a pain as Debian (for example) would need to maintain several distributions in parallel. Currently, the maximum is two (during one year). With a release cycle of 6 months, this would mean 4 distributions simultaneously (old stable, stable, n-1 and n), like Ubuntu. We just don’t have the manpower for that (and no real demands either).

        1. 2

          Related to this, the package versions in a stable distro are known to work together. In the OpenTTD case this probably isn’t as big of a deal, but software packages in general are known to have problems when future versions of libraries are released. When you use, e.g. Debian stable, you’re assured that everything that worked yesterday will continue to work today.

        2. 1

          I don’t think so. I expect things on my LTS release to stay stable for some years and I know that they won’t be the latest and greatest. And games with multiplayer & co may just be unsuited for this. But they aren’t as relevant for stability as my file manager, login or displaymanager..

        3. 5

          This might be slightly off topic and might sound a bit like being a “fanboyism”, but I don’t mean it that way, because I hope that others will pick it up, so it isn’t a somewhat unique feature anymore.

          The BSDs for historical reasons split base and ports/packages. But it kind of developed into a feature and great care is taken in all of them on what goes in and out of the base system. The base is of course supposed to be stable.

          But then there is the ports which are not just “everything in there is rolling release”, but more fine grained. For projects where it makes sense there is different versions, for example different PostgreSQL versions. So one can freely choose.

          But it goes further. OpenBSD and FreeBSD also have flavors so you also get to pick and choose for (just because it’s famous) Python.

          And if you are self compiling you get to choose different variations, let’s say you wanna build an old Postgres, with LibreSSL, but with a new (supported) PostGIS, you can do so.

          And on top of that for FreeBSD and NetBSD you get to choose if you want have the stable quarterly branches of the ports trees or the latest one, with the latest versions, which (I think largely cause they are usually not modified) very stable and fit for server usage. All because you have that stable base still

          I think if I wouldn’t have used it for so long in very different production environments it would sound kind of messy to me, but it’s not like one somehow has to constantly make a decision. It works out very nice and one doesn’t usually stumble across issues (certainly less frequently than in Debian, where I think the main issue stems from packages being modified (heavily patched), split, etc.).

          It would be great to see something similar being undertaken in the Linux world. There have been quite a lot of situations where I only went with FreeBSD because of the above.

          There is no technical reason for this not existing, so it very much surprises me that it doesn’t exist. There have been people using pkgsrc on Linux, but it’s not so much the point to bring that into Linux, as it is to bring those concepts to Linux. I think bringing in pkgsrc can be hard, because a lot naturally is optimized for its main platforms and the pkgsrc distros at large simply were tiny one person shows that never reached enough mass.

          So I am wondering if I’m the only one who’d sometimes really liked something like this existing. I think something like Gentoo (or pretty much anything else really) could still be used as a base for such an approach. Does such a project exist?

          1. 1

            I think it’s a bit more complicated WRT BSDs, because FreeBSD is unifying ports/packages UX wise but keeping the same release policy/separation. They also have the luxury of developing a stable base, whereas Linux components are disparate and and separately developed. I think it’s a good thing (and a proven strategy) in the case of say, FreeBSD, where they keep binary compatibility going, because it provides a stable base to build off of. Windows and macOS go further and just put more components you’d need to rely on like the GUI or audio as part of a stable, ABI compatible base.

            1. 1

              As a long time Debian user and developer, I’d love us to move to a base/ports-like model, and have a leaner Base than what “main” is today.

            2. 3

              This is a fairly serious educational problem I agree. Issues in a distro version should never be reported to upstream, but to the distro.

              1. 3

                As an end user, what do I get out of reporting it to the distro and not the upstream if something breaks that doesn’t seem like a downstream issue? The triage can be useful, but not enough I’d think to report there first.

                Commercially, I do know what it’s like - I support a PHP distribution, but I think it has more merit than for say, the typical Linux distribution, because the proprietary platform we support it on isn’t well known by most PHP developers, there are necessary distribution differences, additional patches to make it work, etc. that means they get support from us - they usually pay for it though.

                1. 3

                  You get the benefit of reporting against the version you actually run, and maybe getting the version you actually run fixed. Repoting to upstream in the best case causes the fix to go into a version you are not using for possibly a long time or ever, and worst/common case just annoys upstream.

                  1. 1

                    True, but how likely would I be able to get a fix in that case? If a bug is fixed in 0.9.3 and Debian ships 0.9.1, they don’t usually backport fixes like that unless it’s security, because it would break the entire point of stable.

                    1. 1

                      I suppose it depends if the maintainer agrees it is a bug. The point of stable is to work and not break, so if already broken a fix shouldn’t “break the point” but of course this will vary by maintainer

                2. 1

                  It’s not an educational problem, IMO. That’s just shunting the problem to the user. It’s a UI problem; if there were some sort of standard bug-reporting platform that auto-included relevant info like distros, I don’t see why upstream devs couldn’t set an automatic rule like “bugs with Debian stable are automatically forwarded to the Debian packagers and the user is automatically sent a reply saying “hey your distro is old as eff and we recommend using something newer”.

                  1. 2

                    I mean, there is a standard bug reporting UI for debian (reportbug), can be run from either shell or as GUI. But I agree it needs to be more prominently featured in default desktop installs.

                3. 1

                  and there’s no solution other than to tell users to stop using their distro.

                  Or distribute the game/software as a static binary and tell users to update manually/bundle an auto updater.

                  1. 4

                    Static binaries help until you need NSS (for auth/NS), or more realistically for a game, to get to libGL.

                4. 10

                  When a package maintainer has 10 packages to update, security updates may end up at the top of the pile and updates of games such as OpenTTD at the bottom. And if packages are flagged as out-of-date, they are often updated in a day or four, depending on how much non-Arch-Linux work the maintainer has (like work, family etc).

                  Then there is always the unofficial Arch Linux User Repository (AUR), for when users require applications to be this week’s very latest version, or the latest git commit from main or master.

                  I’m all for more open source games ending up on Steam, but I wouldn’t say this is an unsolved problem on Arch Linux.

                  1. 3

                    And if packages are flagged as out-of-date, they are often updated in a day or four

                    Unrelated to the topic, but Guile Scheme has been out of date on Arch for months now. Can I report this to someone? Would love the new version of the language on Arch since it has a lot of performance improvements.

                    1. 2

                      The guile package can be flagged as out-of-date by clicking the Flag Package Out-of-Date link here: the guile package.

                      I see that guile has already been flagged, and was last updated 3 days ago (2020-04-11).

                      If packages have not been updated for 14 days after being flagged, it is possible that there is a bug in the latest release that is stopping the maintainer from releasing a new version, or that it just takes time.

                      It is possible to ask about packages that have not been updated 14 days after being flagged in #archlinux on IRC (ie. irc.freenode.net).

                      1. 1

                        I see that guile has already been flagged, and was last updated 3 days ago (2020-04-11).

                        No, 2020 was a year ago. It’s pretty outdated by now.

                        1. 1

                          Ah, I misread. Yes, that’s longer than usual.

                  2. 9

                    I mean, this is exactly the sort of problem Flatpak and Snap intended to solve as far as I understand, but Steam got there first and (for games) is more convenient to use.

                    1. 4

                      It got there first but a lot of the engineering was done by people who went on to design and implement flatpak

                    2. 8

                      This is such a weird take. Having a 3 year old version continue to work is the point of somethng like Debian stable. Nothing prevents upstream from releasing their own binaries if they like (using something like appimage if their dependencies are really gnarly, but even proprietary games seem to grt by fine on “Linux” without that) – I don’t rely on my distro togt me the latest versions but to get me working versions that will keep working past the whims of upstream.

                      Now, the game being also in Steam seems like a good idea to reach those Steam users out there, but people like me who play OpenTTD from debi stable will continue to happily do so.

                      1. 9

                        I think the point of the article is that Debian stable’s guarantees aren’t nearly as important for games. For e.g. Apache httpd, I really don’t want it to change except for security updates. But for OpenTTD, I probably would rather have the latest version, especially if I’m playing multiplayer.

                        What this article didn’t address was the usual solution to this problem (backports). I wish it had. I do find that sometimes I wish something was backported in Debian but it isn’t, whether because no one had time or was interested or whatever else.

                        1. 4

                          For Debian, browsers get exception because it is too hard to maintain them. It could be applied for games, but it is difficult to draw the line where this should stop. So, it’s easier to have very few exceptions and everything else should follow the rule.

                          1. 1

                            Newer versions can still have regressions or new instabilities. Especially very new versions (article also considers December too old!)

                            It is true some games don’t keep their multiplayer stable, but all the more reason to have an easy for everyone to get older version without changes!

                        2. 6

                          HardenedBSD has OpenTTD 1.10.3 in its package repo. We even apply an exploit mitigation called SafeStack to it. ;-P

                          1. 1

                            Doesn’t the application of different options make multiplayer determinism issues worse, though?

                            1. 1

                              I’m unsure I understand your question. Can you rephrase?

                              1. 1

                                I reverse my stance, this is a good thing - if a compiler security mitigation like stack hardening causes a desync, that means the mitigation was triggered during play.

                          2. 4

                            I wonder if splitting repositories into multiple categories would help. Core utilities should have been more thoroughly tested, and the older software is the more it has been “tested”. But of course this doesn’t apply to all software. The backports system tries to help here, but something like a game obviously doesn’t have to be tested to the same degree as bash. Then there are also examples where software just breaks due to external changes, such as with web browsers or youtube-dl. Then again, the biggest problem with having different lanes would probably be dependency management.

                            1. 7

                              youtube-dl is a great actual example of a case where stability is an anti-feature. I like my games stable, but for ytdl to work at all you often need close to latest version.

                              1. 1

                                To be fair, youtube-dl could be engineered in such a way that extractors aren’t hard-coded but their logic is downloaded from somewhere (some central network or a P2P swarm).

                                1. 9

                                  I think that might be controversial, and would certainly be controversial with distros.

                                  1. 5

                                    That seems to be arguing that any program that needs to be frequently updated needs to build in its own update mechanism. That then raises two questions:

                                    • What is the distro’s packaging mechanism for, if people are expected to build their own on top and use the distro only for the bootstrapping phase?
                                    • Why not factor out that per-application update mechanism into something generic?

                                    I find it quite depressing how much effort seems to be being spent in the open source world working around RedHat / Debian’s packaging policies. As a long-time FreeBSD user, I have never experienced the problems these things are trying to solve.

                                    1. 1

                                      I’m not saying that youtube-dl should be responsible for it’s own updates (even though it does have this functionality implemented), just that it might have been more convenient to have some kind of a DSL for describing how to extract videos, that can be distributed independently from the program itself.

                              2. 3

                                I take it Steam doesn’t require any modifications that would violate the GPL?

                                1. 5

                                  Steamworks/Steam DRM wrapper are optional. You can use steamworks through a second process or an LGPL component (for example) though

                                  1. 4

                                    This is a grey area and if you want to link your own GPL app with the Steam SDK one should definitely hire a lawyer first.

                                    1. 10

                                      I hate that kind of response. Most people don’t have that kind of money. “The only way to know whether what you want to do is legal or not is to blow all your money and time on a lawyer” is such a terrible system.

                                      1. 10

                                        If you select a license that is multiple pages of dense legalese, then you are explicitly opting in to needing to talk to a lawyer to know what you can do with it.

                                        1. 8

                                          This seems to be implying you need a lawyer because of GPL, but of course you need a lawyer equally much because of Steam’s terms.

                                          1. 1

                                            So what’s the solution then? Write proprietary software and give up on open source?

                                            I like the MIT license for many things, but there are some projects where I don’t want other people or corporations to just take the project and sell a modified proprietary version. I currently license those projects under the GPL. Should I just make them proprietary instead?

                                            1. 2

                                              I like the MIT license for many things, but there are some projects where I don’t want other people or corporations to just take the project and sell a modified proprietary version. I currently license those projects under the GPL. Should I just make them proprietary instead?

                                              It’s your choice. I don’t really see a difference between a company taking my software, making a load of changes, and making money by selling it without making their changes available to their customers (not allowed by the GPL), and a company taking my software, making a load of changes, and making money by deploying it at scale in-house (allowed by the GPL). In both cases, someone is making a load of money from my software and is not contributing changes back. I consider this the cost of doing business for open source: I care more about how much it benefits me than about preventing it from benefitting someone else more than it benefits me.

                                              If this is a concern for you, then you are already embarking on trying to enforce some legal protection that prevents people from doing something with your software. When you want to do use the law to prevent someone from doing something, you need to understand all of the nuances of the law in any of the applicable jurisdictions. You generally do this by either studying law or paying a lawyer. If you created the software, then it’s entirely your right to choose how you license it. The only thing that I object to is people choosing to use a complex legal document to restrict what other people can do with their work and then complaining that they need to be or hire a lawyer to understand how it interacts with other people’s complex legal documents.

                                              1. 1

                                                Is this (steam compatability) a real problem you have? If we can convince someone to use their case to have a good lawyer create a resuable opinion we could solve the problem for many projects at once. If you are in a position to have a case worth analysis, PM me and let’s talk strategy.

                                            2. 4

                                              Unless we can get a system of unambiguous law, I fear we may never do better…

                                        2. 1

                                          honestly stuff like this is one reason why I eventually stopped using linux on my desktop. I wanted new software but I didn’t want to install arch (I know about flatpak/appimage but that didn’t solve everything for me because reasons).

                                          1. 7

                                            Curious why you’d rather leave the ecosystem rather than run Arch, Debian Testing, or another distro with focus on freshness?

                                            I mean, do what you like of course. Just curious since you called it out.

                                            1. 3
                                              • arch: don’t want to have to subscribe to a mailing list in case of breaking changes
                                              • debian testing and other distros: not as well supported for me as ubuntu, sure i could download and build source for the stuff I use but I really couldn’t be bothered
                                              1. 8

                                                I use and love Arch but it still bugs me that Gentoo (not known for being the easiest of distros to use) gets eselect news read and automated warnings about important changes, and the official Arch answer is still “It broke? You should have checked the website before you updated”.

                                                1. 4

                                                  I’m on the announce mail list, but even then, I don’t always check email before upgrading.

                                                  Instead, I deal with it when it happens. Having busybox and pacman-static installed, breakage would have to be very bad to not be quickly fixable.

                                                  Sure, I used Gentoo unstable for some 15 years before adopting arch as my main system, so my pov might be a little abnormal.

                                                  1. 2

                                                    But what is the envisioned functionality here? Do you just want something like pacnews to list out arch-announce or are you after something integrated with pacman? The former can be done by the week, but pacman is not really Arch specific and it doesn’t make sense to support something like that upstream.

                                                  2. 5

                                                    YMMV but I’ve had less breakage with Arch than I’ve had with Ubuntu, macOS, or Windows. I think it’s because the rolling release model prevents issues from clustering into large, hard-to-debug groups as you have with most other distros and OS’.

                                                    1. 1

                                                      arch: don’t want to have to subscribe to a mailing list in case of breaking changes

                                                      What’s wrong with following the low-traffic announce mail lists of projects you depend on?

                                                      1. 3

                                                        What’s wrong with following the low-traffic announce mail lists of projects you depend on?

                                                        I’d rather just use my pc without doing that.

                                                        1. [Comment removed by author]

                                                          1. 6

                                                            What a weird take this is. This is a solved problem, e.g. with eselect news and automated warnings mentioned elsewhere in this thread. Debian’s doing that too, all within apt. Why would you use a separate piece of software and a separate communication channel to learn about changes that are caused/triggered by the package manager? Shouldn’t it be its job?

                                                            “Arch can’t be bothered to improve their software” is very far from “you value open source low”. The fact that Arch doesn’t care about this sort of stuff and pretends that it should be your job is a very good reason to not use it, and it has nothing to do with “not valuing open source”. It has everything to do with not valuing Arch, and that’s perfectly understandable.

                                                            1. [Comment removed by author]

                                                              1. 1

                                                                I’m not sure he’s actually tried all of the ones he listed

                                                                🤔

                                                  3. 1

                                                    I’m curious as to what your using how and how does it solve stuff like this for you?

                                                    1. 1

                                                      I switched back to windows

                                                      every app i need only comes in one form, exe’s with manual or automatic updates

                                                      also warzone runs on it which is nice/not nice for my productivity

                                                  4. 1

                                                    but Valve has already done most of the work with the presence of the Steam Runtime to make single Linux binaries run pretty much on any distro.

                                                    Nope. Only on distros using glibc. Not on any distro.

                                                    1. 11

                                                      Only a few distros don’t ship glibc, and their users are probably sadly used to lots of things being broken…

                                                      1. 7

                                                        … and they typically offer a glibc install for those that want/need it.

                                                        1. 3

                                                          There’s also gcompat too. I always thought the Steam Runtime included its own libc, so it’d be completely standalone… (edit: except i realize libGL exists. oops!)

                                                    2. 0

                                                      When I used Linux, I usually just compiled OpenTTD from source, which was very simple for the most part.