1. 40
  1.  

  2. 28

    There’s a dissonance in the past which I don’t quite understand. They’re:

    • criticising mariadb for not being ready to jump to openssl 3 right after release
    • criticising “move fast and break things”
    • hoping to remove the current openssl LTS as soon as things support openssl 3, even though “Version 1.1.1 will be supported until 2023-09-11 (LTS)” (https://www.openssl.org/policies/releasestrat.html)

    What’s the rush? If the reliability is praised, why would they move ansible to community, instead of holding off on a new openssl release?

    Also the link for mariadb shows that they started the work shortly after openssl 3 RC was released. That sounds like a very reasonable time to start looking at it given you have 2+ years left to finish the work.

    1. 4

      As I understand it, mariadb has been using deprecated APIs for a long time which are now finally being removed from openssl. They could’ve moved to non-deprecated APIs under openssl 1.1, which would make it (mostly?) forward compatible with openssl 3. That definitely deserves criticism, regardless of whether you’re in a “move fast and break things” mindset.

      And the “rush” I guess is simply wanting to be able to use a single version of openssl for the base system. They could’ve stuck with 1.1 for a while longer of course, but if nobody is putting pressure on upstream to update, they probably won’t.

      1. 3

        The implied message to me seems to be that mariadb’s technical excellency has waned, by not moving from unclean API’s.
        The other one is that by moving your supply chain to clearly better suppliers (ie. to newer OpenSSL in this particular case) you’re making longer-term maintenance of your software easier. And that in turns helps Alpine’s LTS users.

        1. 4

          I would argue that this has little to do with technical excellency. Mariadb target does not include any rolling distros. (https://mariadb.com/docs/deploy/os-compatibility/) They still target rhel7 with openssl-1.0.2k. (started on 1.0.1). That support will not be going away soon.

          There’s ~0 people seriously thinking: what I want is latest alpine with latest openssl to run my production database. Alpine wants to keep on latest everything, but there’s very few incentives for maintainers in large projects to care about that. I’d even say that they have their technical priorities set pretty well - a pure-churn task got identified and scheduled at the right time.

      2. 9

        Is there some write up which spells out Alpine+Rust technical problem exactly? From this article, I infer the following:

        • Alpine has two year support cycle, and they need to stick to the same version of the compiler throughout the cycle.
        • Rust, however, releases every 6 weeks, and only officially supports the latest stable. Eg, a security issue found in the compiler will be backported to the current stable, but not to the stable from two years ago.

        Would this be a fair summary of the problem?

        1. 31

          It sounds like it. Note that Clang has the same problem: LLVM has a release every 6 months and upstream supports only the latest version. In FreeBSD, we maintain our own backports of critical issues and move the base system’s toolchain to newer versions forward in minor releases (a major release series has about a five-year support lifecycle).

          This is not ideal from a stability perspective because sometimes a newer clang can’t compile things an older clang could but this also needs to be balanced against the desire of people to actually compile stuff: If we didn’t ship to a base system compiler that supported C++17 in FreeBSD 12 (EOL 2024) then by the end of its support lifecycle the base system compiler would be a waste of space and everyone would use one from ports (most of the stuff that I work on has been C++17 for a while and is moving to C++20 at the moment).

          Note that the reason that we have clang in the base system at all is that POSIX requires a cc binary. Without that, we’d probably move to supporting clang only in ports (where we carry multiple versions and anyone who wants to install an old one can, putting up with the bugs in the old one instead of the bugs in the new one).

          I don’t have a huge amount of sympathy with a lot of these complaints because they often come from policies that the packaging system is enforcing. You want to maintain a complete set of packages for two years with security backports? That means that you are committing to back-porting security fixes for two years. If you’re RedHat then you might have customers who are willing to do that (so that they can then run Alpine / Debian / Ubuntu in containers because nothing in their host OS is sufficiently recent to be useable) but if you don’t then you need to ask yourself why you want to make that commitment. Can you relax it and say that you’ll bump the version of the Rust compiler?

          Packaging policies should first be driven by what is possible, then by what users want. Promising to do the impossible or promising to stick to some arbitrary standards that users don’t actually care about doesn’t help anyone.

          1. 18

            I don’t have a huge amount of sympathy with a lot of these complaints because they often come from policies that the packaging system is enforcing. You want to maintain a complete set of packages for two years with security backports? That means that you are committing to back-porting security fixes for two years.

            Exactly! As someone who’s been on the receiving end of, “Bbbbut but we promised client X we would provide these guarantees even though we have no way to enforce them and it’s not our lane! We (and by ‘we’ I mean you) have to find a way to provide said guarantees!”

            Note that in the OP, and unlike in my anecdote, it looks like Alpine is doing the right thing here by moving those packages they can’t support into community, so kudos on making the hard uncomfortable calls.

            1. 3

              I don’t have a huge amount of sympathy with a lot of these complaints because they often come from policies that the packaging system is enforcing. You want to maintain a complete set of packages for two years with security backports? That means that you are committing to back-porting security fixes for two years.

              Of course it’s a policy that someone made up. The point is that it’s a useful policy for users. I think software developers in general often have quite different interests from the people who run their software—they want to move fast and break things, while as a sysadmin I just don’t have the bandwidth to keep up with everything breaking all the time. Distros don’t backport just for the sake of it; they’re bridging a gap between what FOSS developers want to make and what users need.

              But also, in general, they do backport. I think it’s reasonable to complain when upstream projects make that intractably difficult, though, to the extent that it’s reasonable for anyone to complain about something that’s free. As a user who relies on stable distros, if they weren’t complaining for me, I’d be complaining myself.

              1. 5

                The point is that it’s a useful policy for users

                No, the point is that it may be useful in some cases for some users in some contexts and probably was useful for a large subset of visible users at the time that the policy was created.

                I think software developers in general often have quite different interests from the people who run their software—they want to move fast and break things, while as a sysadmin I just don’t have the bandwidth to keep up with everything breaking all the time

                As a developer, I want access to the latest versions of my tools and libraries. That’s easy.

                As a sysadmin, I don’t want security vulnerabilities in the things that I deploy. I also don’t want unexpected changes that break things for my users. In the LTS model, these two constraints very often come into conflict. Security vulnerabilities are easy to fix in the mainline branch but if you want back-ports then someone needs to do that work. If you want volunteers to do that, then you’re asking them to do work. If you’re RedHat (IBM) then you’ve got a load of customers who are paying you to pay engineers to do that. If you’re FreeBSD or Alpine? You have users demanding it but not being willing to do the work or pay for it, so you have to ask why you’re devoting effort to it (in the case of FreeBSD, most of the big companies that use it run -HEAD so don’t care about this at all).

                As a user who relies on stable distros, if they weren’t complaining for me, I’d be complaining myself.

                How much are you / your employer paying (and who are they paying) to ensure that you have support for a stable distro?

              2. 2

                the reason that we have clang in the base system at all is that POSIX requires a cc binary

                I thought it has more to do with the base/ports split and the “base builds base” tradition. It’s not impossible to just ship system images with a pkg-installed llvm :)

                (Also who cares about that aspect of POSIX. Not the Linux distros where you have to pacman -Sy gcc, haha)

            2. 5

              For cases like cryptography, I feel like Rust needs better tooling for minimum supported Rust versions (MSRVs). https://github.com/foresterre/cargo-msrv exists, but this sort of functionality should be built-in to Cargo and/or the compiler.

              1. 4

                Agreed. There has also been discussion about adding an LTS branch. I haven’t followed the latest discussion on either topics, as it seems mostly a time/resource issue that requires some individual/group/company to step up and provide all the resources required support such an effort.

                1. 3

                  Progress is being made on this. The RFC to add msrv was accepted and has been implemented in cargo (accessible on nightly cargo at the moment). https://github.com/rust-lang/rust/issues/65262

                  1. 2

                    Even better: it was stabilized and hits stable on October 21st!

                    1. 2

                      Even better!

                2. 5

                  FWIW having to get some packages from a “community” repo doesn’t actually sound like a big problem from a user perspective.

                  I wouldn’t be surprised if most ansible users were ignoring OS packages and installing specific pinned versions with pip anyway.

                  1. 2

                    Most developers do indeed probably do that, but the question is what do folks in big enterprise environments do? I know some who lean pretty heavily on distribution packaging of pretty much everything, and with good reason.

                    Your use case is not everyone’s use case :)

                    1. 1

                      I would be a little surprised if those people were using Alpine at all over, say, Debian. But point taken.

                      I’d still expect enterprise environments to often use a pinned version of ansible from pip anyway, fwiw. The imperative “use a version of ansible that someone else vetted” may be overridden by “use a version of ansible that we have tested and know works”.

                  2. 4

                    They don’t run on C because C is a good language with all the latest features, they run on C because the risks and mitigations for issues in C programs are well-understood and documented as part of MISRA C.

                    Since there are only two languages in the world, C and Rust, free software developers should stick to C and purchase MISRA specifications and tools[1]. Sounds perfectly reasonable. ;)

                    [1] The spec (which is a small booklet) used to cost around $100 last I checked.

                    1. 1

                      It’s difficult not to read this as an explanation of why classical distros – standard cadence, releasing every few quarters, packages distributed only as binaries – are no longer well-suited to distributing Free Software. Distros based on ports trees used to take a long time to compile software, but we now have fusions of community repositories and automated builders to accelerate most builds without removing the ability to locally patch and update software.