14 ms·

PHP 8.0 is 10 months old, and debian’s upcoming release will be upgrading from 7.3 to 7.4, which will make 7.4 the standard for the next ~3 years (even though i

PHP 8.0 is 10 months old, and debian’s upcoming release will be upgrading from 7.3 to 7.4, which will make 7.4 the standard for the next ~3 years (even though it only gets upstream support for 1 more year)… I am starting to reconsider my personal policy of “use debian-stable as a benchmark for what language runtimes I should build on top of”, now tending towards “use debian stable as the bare-metal OS, and build all my projects inside docker, using each language’s most recent stable release”

samueloph 5y ago
Seems like you should take a look at https://deb.sury.org/ https://deb.sury.org/ PHP 8.0's release wasn't long ago enough to fit into the stable release, bullseye was too close to the initial freeze period when that happened.
- stephenr 5y ago
  This is the correct answer. For those unaware, these packages are built using the same packaging repo as the Debian “offical” packages, by a member of the “official” Debian php team. I can’t speak highly enough of Ondřej’s work on this.
roenxi 5y ago
I'll opine, happily, that nothing showcases the gap between the OS people and the Web people as well as someone who considers 10 months to be a significant length of time. There is a happy day coming for the web developers, sometime this decade hopefully, when skills learned as long as 12 months ago will still be up to date. Did you notice OpenJDK has been upgraded from v11 to v11? That sort of radical change is why I run Debian. They don't break stuff.
- Shish2k 5y ago
  Very fair point :) All my other dependencies, using 5 year old versions is fine; it’s mostly just PHP that gets an order of magnitude less-painful to work with in each release, so being stuck a few versions behind is extra frustrating...
  - slim 5y ago
    That's because php decided it needs 6 month release cycles now. You're better off targeting php 7.4 for the next 3 years imho
    - jorams 5y ago
      PHP releases once a year. They've been doing that for almost a decade now.
  - CogitoCogito 5y ago
    Is it that difficult to build and/or install a newer version that better fits your needs? I tend to stick to debian stable, but in the few cases where I need newer software I just build it myself. Using `apt build-dep [package]` and then something along the lines of `configure && make && make install` basically always works. edit: I guess if you work somewhere with a policy of requiring you to use system packages, you're a little screwed, but that seems more of an organizational problem than a debian problem.
    - dreyfan 5y ago
      PHP 8.x is very easy to install on debian by adding deb.sury.org to apt sources. https://deb.sury.org/ https://deb.sury.org/
    - Shish2k 5y ago
      In this case I’m building software whose primary selling point is “trivial to install on practically any cheap-ass $1/mo shared web host, just unzip and FTP the files to your website folder” - which is the whole reason it’s written in PHP in the first place. (The more I think about it, the more sad I am that it’s 2021 and still no other language has come close to PHP’s low barrier to entry...)
    - curryst 5y ago
      Yes. Just as an example, I use VSCode. VSCode no longer works on CentOS 7. It needs a newer glibc, so I'm going to have to recompile a lot of stuff and do some PATH fiddling to get it to work. It's usually not that it's hard to do that for your packages. It's when their dependencies go out of date and I'm looking at having to build a Frankenstein system where I'm running one up to date system on top of a really out of date one, and trying to make the two co-exist in a single OS. It's not insurmountable, but it's enough effort that dealing with occasional Arch breakage becomes easier. Or even something in between like Ubuntu.
- koolba 5y ago
  OpenJDK is still at 11 because that’s the latest LTS version. Subsequent versions have significantly shorter upstream support lifetimes (IIRC, six months). Until another LTS is released, it’ll continue to be 11.
  - smarx007 5y ago
    Next LTS will be released on Sep 14, exactly in one month.
    - vbezhenar 5y ago
      Too bad, now wait for 2023.
      - smarx007 5y ago
        I think it’s rather Docker, Alpine, JDK 17 and jlink than waiting till 2023 :)
    - AndyPa32 5y ago
      It means nothing that it will be released in a month. Because new software goes into unstable first, then is promoted to testing and only then to stable. So even if the next LTS release would have been released a month ago, it certainly wouldn't have made it into debian stable.
      - throw0101a 5y ago
        * https://packages.debian.org/bullseye/openjdk-17-jdk https://packages.debian.org/bullseye/openjdk-17-jdk * https://packages.debian.org/search?keywords=openjdk-17 https://packages.debian.org/search?keywords=openjdk-17
  - cogman10 5y ago
    There's no such thing as "LTS" for the OpenJDK. LTS is strictly a JDK/JRE vendor concept. Oracle's distributions have 11 as an LTS and will have 17 as an LTS. That, however, only matters if you are paying oracle for support.
- 5e92cb50239222b 5y ago
  You don't seem to know anything about the "web people" you're criticizing here. PHP skills learned two decades ago are still very relevant today. It's the Java of the web world.
  - roenxi 5y ago
    What criticism?
    - JasonFruit 5y ago
      That's an excellent point: you described a difference, which is in fact real. Any perceived criticism is just that: a perception.
  - bonzini 5y ago
    Hmm no, not at all. My first job in 2002-2004 was using PHP4. I barely used classes (and if I did they were just my code, not from the library because I didn't need anything from PEAR) and used the original MySQL client API. Almost nothing of what I used back then would be useful today. PHP4 vs PHP8 is almost more different than Python 2 to Python 3.
    - itwy 5y ago
      Nonsense. +95% of Python 2 knowledge is transferable to Python 3. Same for PHP 4 to PHP 8.
      - ptero 5y ago
        I agree with your point, but your first word may get you many a downvote; I would remove the "nonsense" word to increase the penetration :).
  - formerly_proven 5y ago
    I've initially learned PHP4 when PHP3 was still used. Later I learned PHP 5 which iirc was the first version which had classes. I also learned Drupal 6 and then 7. Modern PHP code looks nothing like PHP code back then. Of course, the core syntax is mostly the same, but if you look at a framework like D6 or D7 no one would do anything even remotely like this today. PHP security has completely changed since then as well.
- elipsey 5y ago
  When I was an intern there was this old dude who had an ancient computer with the same Debian on it for like 7 years. He never got excited about new stuff, and just didn't want to break anything. I thought that was kind of funny and un-hip, back then, but now I'm like that. It's like Dad OS. :)
  - burntsushi 5y ago
    I'm a Dad and I use Arch. I can't stand non-rolling release Linux distros. They are constantly getting in my way because they don't track upstream. I have multiple machines running Arch (some over a decade) with no problems. In constrast, doing dist upgrades on Ubuntu has put me into states that I could not figure out how to get out of, and thus had to do a clean install. (Granted, it's been a long time since this has happened, but mostly because I very specifically avoid non-rolling release distros.)
    - zozbot234 5y ago
      Ubuntu upgrades are extremely messy compared to Debian. If you want a rolling-like experience, the testing channel of Debian is pretty good for that - though it does get frozen when approaching a stable release.
      - burntsushi 5y ago
        The dist upgrade is more of an example meant to dispel the myth that non-rolling release distros break less frequently than rolling release. Or at least, an anecdote anyway. Jumping down from the meta level of rolling vs non-rolling, I personally find Archlinux style of packaging much much simpler than Debian's. I've writte numerous PKGBUILD files over the years and it's been dead simple. But my eyes gloss over whenever I look at Debian packages. I'm sure the complexity in Debian is warranted for one reason or another. But it ain't for me.
        e12e 5y ago
        Note that, Ubuntu had some rough times, and did some odd things (I distinctly remember changing gid of system groups, for example) - but it has gotten a lot better. I don't think I can remember Debian ever having any serious issues on dist upgrade. Well, there was a bit of hairpulling with the change from lilo to grub - but I think that was because I tried it early, before grub became the new standard..). But of course, there are no perfect tradeoffs. I'm inclined to believe GNU guix (or nixos) might be the next best thing(tm) - but I've yet to put that to the test..
- seoaeu 5y ago
  In other settings I can add a new feature to one of my dependencies and start using it within days or weeks. You're telling me you prefer having to wait years to get any newly implemented feature?
  - notyourday 5y ago
    OS should not ship your language run time. OS is a giant cargo ship. It does not turn on a dime and it is not piloted by a "lets rewrite it in rust!" crew.
  - tomc1985 5y ago
    So add a couple of vendor repos and jump the versions queue like everyone else. I do this for all my main dependencies... postgres, ruby, etc
  - robertlagrant 5y ago
    Can you give an example?
    - seoaeu 5y ago
      Sure. In the Rust ecosystem, if you submit a pull request to a library it is very common for the maintainer to release a new version soon after. Even patches to the Rust compiler repository are released to stable in a matter of a few months (and the very next day for the nightly channel that many people use) There's always workarounds and so forth, but it is really empowering to be able to have an impact over such a short timespan
  - yjftsjthsd-h 5y ago
    Unironically yes. I would love to be done with the endless version churn and would trade many, though not all, features to get it.
- mwcampbell 5y ago
  I think the web people have the right idea. If it hurts, do it more often [1], right? I've used Debian for a long time (edit: on servers), but the short (and in some cases getting shorter) release cycles of popular projects like Chromium and Rust have got me wondering if Debian just moves too slow. I'm tempted to try using Fedora as a container base image and see if it's practical to keep up. Edit: I guess Fedora is no worse than Alpine if you actually update to each new major release quickly, since they both release every 6 months. [1]: https://www.martinfowler.com/bliki/FrequencyReducesDifficulty.html https://www.martinfowler.com/bliki/FrequencyReducesDifficult...
  - qwertox 5y ago
    It is possible that if you build up a routine to always stick to the latest, it will become an automatism. This opens the door to several types of risks. Containers are always an option.
  - miohtama 5y ago
    Static binaries like Snap, macOS, etc. solve “moving slowly” issue. There should be little need to update the core OS (kernel, initd, /etc stuff) often.
  - murgindrag 5y ago
    No, the web people have it wrong. It's called: - Failure to do upfront design (yay, misinterpreted agile/MVP/etc) - Reinventing wheels over, and over, and over Newer versions and frameworks tend to be 10% improvement, and 90% unnecessary churn.
    - asddubs 5y ago
      I'd say PHP is still getting a lot of good and important improvements
      - murgindrag 5y ago
        PHP exactly makes my point. PHP was a no-good, terrible, poorly-made, horrific original design for something like powering Facebook. As a result, it needed a lot of good and important improvements. Or to be more specific, it was a great design for what it was intended to be: a pet hobby project to make it easier to make Personal Home Pages, and was never intended to be a programming language. https://en.wikipedia.org/wiki/PHP#Early_history https://en.wikipedia.org/wiki/PHP#Early_history The concept of putting out something this bad, and then refactoring for over a quarter-century to make it almost-usable, is exactly the definition of the webdev way. The result is a ton of churn.
- martinp 5y ago
  OpenJDK 17 is in Debian 11 as well [0]. A decision was made to include it before its official release since the release is so close (September). An updated package will be available when it's released. From the release notes [1]: Debian bullseye comes with an early access version of OpenJDK 17 (the next expected OpenJDK LTS version after OpenJDK 11), to avoid the rather tedious bootstrap process. The plan is for OpenJDK 17 to receive an update in bullseye to the final upstream release announced for October 2021, followed by security updates on a best effort basis, but users should not expect to see updates for every quarterly upstream security update. [0] https://packages.debian.org/source/testing/openjdk-17 https://packages.debian.org/source/testing/openjdk-17 [1] https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html https://www.debian.org/releases/bullseye/amd64/release-notes...
- eyelidlessness 5y ago
  I read GP as considering ~4 years total and 2 years out of support a long time.
- TavsiE9s 5y ago
  > They don't break stuff. Unless they do due to their stance on licenses and remove mp3 support from the lame package.
- AbraKdabra 5y ago
  There is a fine line where you need to see which weighs more, using a stable version or using an up-to-date security version, I fully support the latter. PHP 7.4 security support will end in November 2022, will Debian upgrade to 8.0 once this happens?
  - asddubs 5y ago
    no, they'll start backporting security fixes. There's still php 5 versions in the wild
- nextaccountic 5y ago
  But it doesn't make much sense to run an outdated PHP. I agree with the point of the top level comment, that is to put your dependencies inside docker and completely uncouple from OS dependencies.
zozbot234 5y ago
PHP 8.0 was not shipped in bullseye specifically because it could not be supported by Debian. A semi-official backport will most likely be available shortly after bullseye is released and testing/sid are reopened for new updates.
- JPLeRouzic 5y ago
  > PHP 8.0 was not shipped in bullseye specifically because it could not be supported by Debian. Please what do you mean by this sentence? What is the problem? (I use PHP 7.3 for my personal web site under Debian 10)
  - progval 5y ago
    There is a discussion on the topic here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811 > The timing of this request makes me uneasy: php8.0 has been in Debian for less than a week, and we are a month away from the transition freeze. > My point of view after actually working on those issues is that there is a significant number of packages that are not working just fine with PHP 8.0, and require a fair amount of work before that. Some of them being security sensitive, so just working around visible issues may not be of the best interest of anyone… And by the time the maintainers decided to go with 8.0, they missed the deadline: > The transition freeze has started, so we'll not transition to php8.0 in bullseye.
- GekkePrutser 5y ago
  I'm kinda surprised they didn't run out of toy story characters yet. After all Ubuntu already ran out of letters
  - georgyo 5y ago
    Ubuntu releases twice a year. It only takes 13 years to outrun the English alphabet. Meanwhile, Debian from 1.0 released in 1996, 25 years, had only 11 releases. 16 if you count unique codenames.
  - 5y ago
5e92cb50239222b 5y ago
Unlike previous PHP releases, 8.0 broke backwards compatibility pretty hard. Some old PHP projects that I have to support are completely unusable on 8.0. This gives me a few more years to port them, so I am all for it.
- miohtama 5y ago
  The same happened with Python 3 and it took a decade to catch up. To be fairness, it was mostly about Unicode support and applications doing stupid stuff with strings.
geofft 5y ago
I'm an occasional Debian contributor and to be honest I think that's the right policy these days. It is effectively what we do at my employer. At my last employer, we ran Debian stable, and we told people to use versions of software (notably Python and Python packages) from the OS. One of my teammates was a Debian Developer, meaning he has full access to upload packages, and the two of us would package things up for the OS as we needed and get fixes into Debian as appropriate. In many cases we needed newer versions of packages than were appropriate for a stable release and (for whatever reason) weren't appropriate for backports either, so we ended up with a noticeable delta - it wasn't obviously less work than just building things ourselves independent of Debian. But because they were systemwide and you needed someone on the systems team to install those packages, what ended up happening is that my team found ourselves artificially in the middle of artificial development conflicts between other groups in the company, where one wanted a really old version and one wanted a really new version of the same package. At my current employer, we also run Debian stable, but our VCS repository ("monorepo," as people seem to call it these days) includes both internal and third-party code. Our third-party directory includes GCC, Python, a JDK, etc. (sometimes compiled from source, sometimes just pre-built binaries from the upstream). A particular revision / commit hash of our repo describes not just a particular version of our code, but a particular version of GCC and Python and Python libraries and so forth. Our deployment tool, in turn, bundles up all your runtime dependencies (like the Python interpreter) when you make a release. In effect, it's exactly the software release cycle properties you get from something like Docker. The practical effect is that upgrades are so much easier because they're decoupled. Upgrading the OS is hard enough - you have some script that's calling curl, and /usr/bin/curl is using the OS's version of OpenSSL, which has deprecated all the ciphers that some internal service that nobody wants to touch uses. Or whatever. Testing this is particularly hard if it affects your bare-metal OS, because you have a fairly slow process of upgrading/reimaging a specific machine, and then you run all your code on the new OS, and you see if it works. If this change also includes upgrading your GCC and Python and JDK versions, it becomes extremely cumbersome. If you can deploy your language runtime, library, etc. upgrades separately (via Docker, via LXC, via something like our monorepo, whatever), then you've decouple all of your potentially-breaking changes, and you can also revert changes for a single application. If the latest GCC mis-compiles some piece of software, it's a lot nicer, operationally, to say that this one application gets deployed to prod from an old branch until you figure it out than to prevent anyone from upgrading. And if a particular team insists on staying on an old version of some library, they don't hold up the rest of the company. And in turn that's why Debian has such a long freeze cycle and doesn't release the latest version of things. There's a whole lot of PHP software in Debian. All of it has to work with the exact same version of PHP (or you have to go to lengths to find every place that calls /usr/bin/php and stick a version number on it). If something is incompatible with PHP 8, the whole OS gets held back. That's exactly the policy you want for things that are unavoidably system-wide (init, bash, libc, PAM, etc. etc.), but you don't need that policy for application development.
dmd 5y ago
Meanwhile, over here in healthcare, I'm currently carefully evaluating whether to update some software packages from their 2011-release version to their 2015-release version (which are 99.9% compatible but add one or two new features). And many of our critical systems (mostly MRIs) are on RHEL 5. (Not connected to any network, don't worry!)
- user5994461 5y ago
  That's a bit too extreme in the opposite direction. :D For those wondering what features are missing from RHEL 5, look further than SSL.
  - dmd 5y ago
    Fortunately nobody has ever needed to access the internet from these machines. People on HN forget that a huge amount of computing has nothing whatsoever to do with the web.
    - inglor_cz 5y ago
      In 2002, I underwent a LASIK operation on a machine that ran Windows for Workgroups. I believe the same machine was in use until 2012 or so.
    - user5994461 5y ago
      Expect all healthcare machines to be networked, even if only internally. Need the active directory to login and need to upload the image/test sample somewhere else after it's taken. That's sadly one reason why ransomware can propagate so easily and stop hospitals. :( In theory there can be computers with no network, typically an isolated computer attached to heavy test machinery, but it's becoming impossibly rare in all industries. And they should be easy to recognize, look for the post-it nearby with the shared username/password to unlock it, also notice the doctors leaving with the x-ray printed on paper or a USB key to be able to transfer it elsewhere.
      - 5y ago
nickjj 5y ago
> ... build all my projects inside docker, using each language’s most recent stable release This has been my personal policy for the last 6 years, it works well in practice. You get the best of both worlds. A rock solid system with the flexibility to use whatever programming runtime versions you want.
- user5994461 5y ago
  I don't think that works anymore with the speed that languages are moving and breaking these days. If you tried to use Python 3.9.0 for example (released November 2020), it had changes in the C bindings and broke many libraries (like numpy), which was not noticed until after the stable release. That took months to fix and I'm not even sure if all packages have been fixed as of today (9 months later).
  - mistrial9 5y ago
    side note - this is huge news to me that Python 3.9 broke numpy ! very interesting to hear this
  - nickjj 5y ago
    > I don't think that works anymore with the speed that languages are moving and breaking these days. The beauty of this approach is you don't have to use the latest version if you don't want to, but the option is there if your app is compatible. You can still use Python 3.7.x or whatever you want. Docker has official Python images going way back.
- KronisLV 5y ago
  Agreed. This also has the opposite effect - if there is any old or outdated component or piece of software that you still need to be running for unfortunate reasons, there's always the possibility of putting it in a container with all of the packages and other environment configuration that it requires. That way you don't have to risk compromising the entire system and don't even have to run VMs with old OS releases, while at the same time only need to expose the ports that the software uses, if even those at all. In my eyes, access to devices and such could still use a few improvements in Docker and other competing container runtimes, but for the most part, the technology is a lifesaver! While i do think that it's nice if the same packages are also available outside of containers, for the OS of your choice, which i'm sure will also be the case for latest versions of PHP and other software, even if done by a third party shortly after Debian's new release, that's sadly not always the case. In those situations, containers indeed seem like a good choice.
SkyMarshal 5y ago
Or just use the Debian Alternatives system to install PHP 8.0 and make it the system default: https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives Once setup, one command can toggle between your version and the Debian repo version as the system default. DA is great, I used it for years on Ubuntu to override Debian's older default versions, or to install anything I wanted to build from source. I eventually migrated over to NixOS because, in a way, NixOS takes the concept of Debian Alternatives and applies it to the entire OS.
- robertlagrant 5y ago
  This is why I like nvm/pyenv. Available versions should be managed via a tool, not by the system.
  - iso8859-1 5y ago
    This is why I like Nix. The tool should be the system.
  - SkyMarshal 5y ago
    Sure, if your tool is aware of its own versions and can do that, that should be the preference over most systems, Nix/NixOS/GUIX excepted. But it's nice for traditional systems like Debian to be able to do it too, for tools that can't.
regularfry 5y ago
That is the correct approach. Docker optional, but language interpreters included with the OS are for the OS. The distribution is there to provide a mutually compatible set of working applications for end users so they don't have to care about matching package versions by hand. Unless what you're doing is writing an application to be packaged with Debian, the version shouldn't matter to you: /usr/local is there, use it. (note: none of this is "official" in any way, just what I've learned over 15 years or so of deploying on Debian-derived distros)
- ncphil 5y ago
  IMHO, that is the correct approach no matter the distro. The OS is a platform, the software included with it should be what works best to support that platform during a given release cycle. Anything beyond that can be addressed by containers, or third-party package repositories (including your own personal repo). It may be a biased perspective from the server side, but give it credit for being based on long, hard experience with frightening permutations (as in ugly, prone to misbehaving, many-headed beasts supporting critical services).
flatiron 5y ago
I do the same but with Ubuntu. Arch Linux containers are awesome.
rubyist5eva 5y ago
Personally, I moved to CentOS from Debian (and then to AlmaLinux OS) because of DNF modules. You get multiple versions of different language runtimes and you can pick the ones you want to use - so I stick to the LTS versions. You aren't necessarily stuck to just one packaged version of a language runtime now - and 10 years of support is lovely.
- zozbot234 5y ago
  Debian has the alternatives mechanism for that kind of thing. It works quite well.
- jaboutboul 5y ago
  Thanks for supporting AlmaLinux!
  - rubyist5eva 5y ago
    no problem, it's a worthy successor to CentOS
deleted 5y ago
[deleted]
pavon 5y ago
The only time it took 3 years between Debian stable releases was between Woody and Sarge, which happened over 15 years ago. All releases since have been on a 2 year cadence.
deleted 5y ago
[deleted]
je42 5y ago
On the other end of the spectrum you have a distribution like Arch which gives you most recent releases, but then you also have to deal with breaking packages / package dependencies much more often. But i guess this comes down to "there is no free lunch".
- kelp 5y ago
  Is that your experience with Arch? I've hardly ever had anything break over many years of using it. I've even committed the sin of waiting many months between upgrades, like on a laptop that sat in a closet. Upgrading usually just works, or there is just a minor issue that can be easily resolved. Usually documented on the arch website.
  - uluyol 5y ago
    It's been some time since I've used it, but Arch was more solid for me than any non-LTS distro. It definitely helps too stay up to date though. I remember the moves to pulseaudio and systemd...not fun. Of course, you also have the advantages of being up to date and never needing to do a apt-get dist-upgrade.
e2le 5y ago
Given the inclusion of the Guix and Nix package managers into Debian stable, installing newer versions of software is an option if you need it. Perhaps even a better alternative to installing and using Docker. https://packages.debian.org/bullseye/guix https://packages.debian.org/bullseye/guix
dannyobrien 5y ago
I'm similar, except that I use Debian as the underlying system, and install with Guix. I imagine it's the same with Nix folks. I'm still unsure whether Docker injects that much more complexity and runtime burdens, but it sure feels a little more messy after installing a few tools.
arendtio 5y ago
AFAIK, Debians conservatism was the reason why Ubuntu got so popular. So complaining that Debians packages are too old is somewhat of an old story itself ;-)
- rixed 5y ago
  More importantly the inclusion of non free drivers. And marketing.
  - int_19h 5y ago
    Debian has the "non-free" repo specifically for stuff like this. E.g. the NVidia non-free GPU drivers have been available there for well over 15 years now.
heurisko 5y ago
On the other hand, I can think of many businesses who would be happy with such a conservative baseline.

samueloph 5y ago

Seems like you should take a look at https://deb.sury.org/ https://deb.sury.org/ PHP 8.0's release wasn't long ago enough to fit into the stable release, bullseye was too close to the initial freeze period when that happened.

stephenr 5y ago
This is the correct answer. For those unaware, these packages are built using the same packaging repo as the Debian “offical” packages, by a member of the “official” Debian php team. I can’t speak highly enough of Ondřej’s work on this.

roenxi 5y ago

I'll opine, happily, that nothing showcases the gap between the OS people and the Web people as well as someone who considers 10 months to be a significant length of time. There is a happy day coming for the web developers, sometime this decade hopefully, when skills learned as long as 12 months ago will still be up to date. Did you notice OpenJDK has been upgraded from v11 to v11? That sort of radical change is why I run Debian. They don't break stuff.

Shish2k 5y ago
Very fair point :) All my other dependencies, using 5 year old versions is fine; it’s mostly just PHP that gets an order of magnitude less-painful to work with in each release, so being stuck a few versions behind is extra frustrating...
- slim 5y ago
  That's because php decided it needs 6 month release cycles now. You're better off targeting php 7.4 for the next 3 years imho
  - jorams 5y ago
    PHP releases once a year. They've been doing that for almost a decade now.
- CogitoCogito 5y ago
  Is it that difficult to build and/or install a newer version that better fits your needs? I tend to stick to debian stable, but in the few cases where I need newer software I just build it myself. Using `apt build-dep [package]` and then something along the lines of `configure && make && make install` basically always works. edit: I guess if you work somewhere with a policy of requiring you to use system packages, you're a little screwed, but that seems more of an organizational problem than a debian problem.
  - dreyfan 5y ago
    PHP 8.x is very easy to install on debian by adding deb.sury.org to apt sources. https://deb.sury.org/ https://deb.sury.org/
  - Shish2k 5y ago
    In this case I’m building software whose primary selling point is “trivial to install on practically any cheap-ass $1/mo shared web host, just unzip and FTP the files to your website folder” - which is the whole reason it’s written in PHP in the first place. (The more I think about it, the more sad I am that it’s 2021 and still no other language has come close to PHP’s low barrier to entry...)
  - curryst 5y ago
    Yes. Just as an example, I use VSCode. VSCode no longer works on CentOS 7. It needs a newer glibc, so I'm going to have to recompile a lot of stuff and do some PATH fiddling to get it to work. It's usually not that it's hard to do that for your packages. It's when their dependencies go out of date and I'm looking at having to build a Frankenstein system where I'm running one up to date system on top of a really out of date one, and trying to make the two co-exist in a single OS. It's not insurmountable, but it's enough effort that dealing with occasional Arch breakage becomes easier. Or even something in between like Ubuntu.
koolba 5y ago
OpenJDK is still at 11 because that’s the latest LTS version. Subsequent versions have significantly shorter upstream support lifetimes (IIRC, six months). Until another LTS is released, it’ll continue to be 11.
- smarx007 5y ago
  Next LTS will be released on Sep 14, exactly in one month.
  - vbezhenar 5y ago
    Too bad, now wait for 2023.
    - smarx007 5y ago
      I think it’s rather Docker, Alpine, JDK 17 and jlink than waiting till 2023 :)
  - AndyPa32 5y ago
    It means nothing that it will be released in a month. Because new software goes into unstable first, then is promoted to testing and only then to stable. So even if the next LTS release would have been released a month ago, it certainly wouldn't have made it into debian stable.
    - throw0101a 5y ago
      * https://packages.debian.org/bullseye/openjdk-17-jdk https://packages.debian.org/bullseye/openjdk-17-jdk * https://packages.debian.org/search?keywords=openjdk-17 https://packages.debian.org/search?keywords=openjdk-17
- cogman10 5y ago
  There's no such thing as "LTS" for the OpenJDK. LTS is strictly a JDK/JRE vendor concept. Oracle's distributions have 11 as an LTS and will have 17 as an LTS. That, however, only matters if you are paying oracle for support.
5e92cb50239222b 5y ago
You don't seem to know anything about the "web people" you're criticizing here. PHP skills learned two decades ago are still very relevant today. It's the Java of the web world.
- roenxi 5y ago
  What criticism?
  - JasonFruit 5y ago
    That's an excellent point: you described a difference, which is in fact real. Any perceived criticism is just that: a perception.
- bonzini 5y ago
  Hmm no, not at all. My first job in 2002-2004 was using PHP4. I barely used classes (and if I did they were just my code, not from the library because I didn't need anything from PEAR) and used the original MySQL client API. Almost nothing of what I used back then would be useful today. PHP4 vs PHP8 is almost more different than Python 2 to Python 3.
  - itwy 5y ago
    Nonsense. +95% of Python 2 knowledge is transferable to Python 3. Same for PHP 4 to PHP 8.
    - ptero 5y ago
      I agree with your point, but your first word may get you many a downvote; I would remove the "nonsense" word to increase the penetration :).
- formerly_proven 5y ago
  I've initially learned PHP4 when PHP3 was still used. Later I learned PHP 5 which iirc was the first version which had classes. I also learned Drupal 6 and then 7. Modern PHP code looks nothing like PHP code back then. Of course, the core syntax is mostly the same, but if you look at a framework like D6 or D7 no one would do anything even remotely like this today. PHP security has completely changed since then as well.
elipsey 5y ago
When I was an intern there was this old dude who had an ancient computer with the same Debian on it for like 7 years. He never got excited about new stuff, and just didn't want to break anything. I thought that was kind of funny and un-hip, back then, but now I'm like that. It's like Dad OS. :)
- burntsushi 5y ago
  I'm a Dad and I use Arch. I can't stand non-rolling release Linux distros. They are constantly getting in my way because they don't track upstream. I have multiple machines running Arch (some over a decade) with no problems. In constrast, doing dist upgrades on Ubuntu has put me into states that I could not figure out how to get out of, and thus had to do a clean install. (Granted, it's been a long time since this has happened, but mostly because I very specifically avoid non-rolling release distros.)
  - zozbot234 5y ago
    Ubuntu upgrades are extremely messy compared to Debian. If you want a rolling-like experience, the testing channel of Debian is pretty good for that - though it does get frozen when approaching a stable release.
    - burntsushi 5y ago
      The dist upgrade is more of an example meant to dispel the myth that non-rolling release distros break less frequently than rolling release. Or at least, an anecdote anyway. Jumping down from the meta level of rolling vs non-rolling, I personally find Archlinux style of packaging much much simpler than Debian's. I've writte numerous PKGBUILD files over the years and it's been dead simple. But my eyes gloss over whenever I look at Debian packages. I'm sure the complexity in Debian is warranted for one reason or another. But it ain't for me.
      - e12e 5y ago
        Note that, Ubuntu had some rough times, and did some odd things (I distinctly remember changing gid of system groups, for example) - but it has gotten a lot better. I don't think I can remember Debian ever having any serious issues on dist upgrade. Well, there was a bit of hairpulling with the change from lilo to grub - but I think that was because I tried it early, before grub became the new standard..). But of course, there are no perfect tradeoffs. I'm inclined to believe GNU guix (or nixos) might be the next best thing(tm) - but I've yet to put that to the test..
seoaeu 5y ago
In other settings I can add a new feature to one of my dependencies and start using it within days or weeks. You're telling me you prefer having to wait years to get any newly implemented feature?
- notyourday 5y ago
  OS should not ship your language run time. OS is a giant cargo ship. It does not turn on a dime and it is not piloted by a "lets rewrite it in rust!" crew.
- tomc1985 5y ago
  So add a couple of vendor repos and jump the versions queue like everyone else. I do this for all my main dependencies... postgres, ruby, etc
- robertlagrant 5y ago
  Can you give an example?
  - seoaeu 5y ago
    Sure. In the Rust ecosystem, if you submit a pull request to a library it is very common for the maintainer to release a new version soon after. Even patches to the Rust compiler repository are released to stable in a matter of a few months (and the very next day for the nightly channel that many people use) There's always workarounds and so forth, but it is really empowering to be able to have an impact over such a short timespan
- yjftsjthsd-h 5y ago
  Unironically yes. I would love to be done with the endless version churn and would trade many, though not all, features to get it.
mwcampbell 5y ago
I think the web people have the right idea. If it hurts, do it more often [1], right? I've used Debian for a long time (edit: on servers), but the short (and in some cases getting shorter) release cycles of popular projects like Chromium and Rust have got me wondering if Debian just moves too slow. I'm tempted to try using Fedora as a container base image and see if it's practical to keep up. Edit: I guess Fedora is no worse than Alpine if you actually update to each new major release quickly, since they both release every 6 months. [1]: https://www.martinfowler.com/bliki/FrequencyReducesDifficulty.html https://www.martinfowler.com/bliki/FrequencyReducesDifficult...
- qwertox 5y ago
  It is possible that if you build up a routine to always stick to the latest, it will become an automatism. This opens the door to several types of risks. Containers are always an option.
- miohtama 5y ago
  Static binaries like Snap, macOS, etc. solve “moving slowly” issue. There should be little need to update the core OS (kernel, initd, /etc stuff) often.
- murgindrag 5y ago
  No, the web people have it wrong. It's called: - Failure to do upfront design (yay, misinterpreted agile/MVP/etc) - Reinventing wheels over, and over, and over Newer versions and frameworks tend to be 10% improvement, and 90% unnecessary churn.
  - asddubs 5y ago
    I'd say PHP is still getting a lot of good and important improvements
    - murgindrag 5y ago
      PHP exactly makes my point. PHP was a no-good, terrible, poorly-made, horrific original design for something like powering Facebook. As a result, it needed a lot of good and important improvements. Or to be more specific, it was a great design for what it was intended to be: a pet hobby project to make it easier to make Personal Home Pages, and was never intended to be a programming language. https://en.wikipedia.org/wiki/PHP#Early_history https://en.wikipedia.org/wiki/PHP#Early_history The concept of putting out something this bad, and then refactoring for over a quarter-century to make it almost-usable, is exactly the definition of the webdev way. The result is a ton of churn.
martinp 5y ago
OpenJDK 17 is in Debian 11 as well [0]. A decision was made to include it before its official release since the release is so close (September). An updated package will be available when it's released. From the release notes [1]: Debian bullseye comes with an early access version of OpenJDK 17 (the next expected OpenJDK LTS version after OpenJDK 11), to avoid the rather tedious bootstrap process. The plan is for OpenJDK 17 to receive an update in bullseye to the final upstream release announced for October 2021, followed by security updates on a best effort basis, but users should not expect to see updates for every quarterly upstream security update. [0] https://packages.debian.org/source/testing/openjdk-17 https://packages.debian.org/source/testing/openjdk-17 [1] https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html https://www.debian.org/releases/bullseye/amd64/release-notes...
eyelidlessness 5y ago
I read GP as considering ~4 years total and 2 years out of support a long time.
TavsiE9s 5y ago
> They don't break stuff. Unless they do due to their stance on licenses and remove mp3 support from the lame package.
AbraKdabra 5y ago
There is a fine line where you need to see which weighs more, using a stable version or using an up-to-date security version, I fully support the latter. PHP 7.4 security support will end in November 2022, will Debian upgrade to 8.0 once this happens?
- asddubs 5y ago
  no, they'll start backporting security fixes. There's still php 5 versions in the wild
nextaccountic 5y ago
But it doesn't make much sense to run an outdated PHP. I agree with the point of the top level comment, that is to put your dependencies inside docker and completely uncouple from OS dependencies.

zozbot234 5y ago

PHP 8.0 was not shipped in bullseye specifically because it could not be supported by Debian. A semi-official backport will most likely be available shortly after bullseye is released and testing/sid are reopened for new updates.

JPLeRouzic 5y ago
> PHP 8.0 was not shipped in bullseye specifically because it could not be supported by Debian. Please what do you mean by this sentence? What is the problem? (I use PHP 7.3 for my personal web site under Debian 10)
- progval 5y ago
  There is a discussion on the topic here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811 > The timing of this request makes me uneasy: php8.0 has been in Debian for less than a week, and we are a month away from the transition freeze. > My point of view after actually working on those issues is that there is a significant number of packages that are not working just fine with PHP 8.0, and require a fair amount of work before that. Some of them being security sensitive, so just working around visible issues may not be of the best interest of anyone… And by the time the maintainers decided to go with 8.0, they missed the deadline: > The transition freeze has started, so we'll not transition to php8.0 in bullseye.
GekkePrutser 5y ago
I'm kinda surprised they didn't run out of toy story characters yet. After all Ubuntu already ran out of letters
- georgyo 5y ago
  Ubuntu releases twice a year. It only takes 13 years to outrun the English alphabet. Meanwhile, Debian from 1.0 released in 1996, 25 years, had only 11 releases. 16 if you count unique codenames.
- 5y ago

5e92cb50239222b 5y ago

Unlike previous PHP releases, 8.0 broke backwards compatibility pretty hard. Some old PHP projects that I have to support are completely unusable on 8.0. This gives me a few more years to port them, so I am all for it.

miohtama 5y ago
The same happened with Python 3 and it took a decade to catch up. To be fairness, it was mostly about Unicode support and applications doing stupid stuff with strings.

geofft 5y ago

I'm an occasional Debian contributor and to be honest I think that's the right policy these days. It is effectively what we do at my employer. At my last employer, we ran Debian stable, and we told people to use versions of software (notably Python and Python packages) from the OS. One of my teammates was a Debian Developer, meaning he has full access to upload packages, and the two of us would package things up for the OS as we needed and get fixes into Debian as appropriate. In many cases we needed newer versions of packages than were appropriate for a stable release and (for whatever reason) weren't appropriate for backports either, so we ended up with a noticeable delta - it wasn't obviously less work than just building things ourselves independent of Debian. But because they were systemwide and you needed someone on the systems team to install those packages, what ended up happening is that my team found ourselves artificially in the middle of artificial development conflicts between other groups in the company, where one wanted a really old version and one wanted a really new version of the same package. At my current employer, we also run Debian stable, but our VCS repository ("monorepo," as people seem to call it these days) includes both internal and third-party code. Our third-party directory includes GCC, Python, a JDK, etc. (sometimes compiled from source, sometimes just pre-built binaries from the upstream). A particular revision / commit hash of our repo describes not just a particular version of our code, but a particular version of GCC and Python and Python libraries and so forth. Our deployment tool, in turn, bundles up all your runtime dependencies (like the Python interpreter) when you make a release. In effect, it's exactly the software release cycle properties you get from something like Docker. The practical effect is that upgrades are so much easier because they're decoupled. Upgrading the OS is hard enough - you have some script that's calling curl, and /usr/bin/curl is using the OS's version of OpenSSL, which has deprecated all the ciphers that some internal service that nobody wants to touch uses. Or whatever. Testing this is particularly hard if it affects your bare-metal OS, because you have a fairly slow process of upgrading/reimaging a specific machine, and then you run all your code on the new OS, and you see if it works. If this change also includes upgrading your GCC and Python and JDK versions, it becomes extremely cumbersome. If you can deploy your language runtime, library, etc. upgrades separately (via Docker, via LXC, via something like our monorepo, whatever), then you've decouple all of your potentially-breaking changes, and you can also revert changes for a single application. If the latest GCC mis-compiles some piece of software, it's a lot nicer, operationally, to say that this one application gets deployed to prod from an old branch until you figure it out than to prevent anyone from upgrading. And if a particular team insists on staying on an old version of some library, they don't hold up the rest of the company. And in turn that's why Debian has such a long freeze cycle and doesn't release the latest version of things. There's a whole lot of PHP software in Debian. All of it has to work with the exact same version of PHP (or you have to go to lengths to find every place that calls /usr/bin/php and stick a version number on it). If something is incompatible with PHP 8, the whole OS gets held back. That's exactly the policy you want for things that are unavoidably system-wide (init, bash, libc, PAM, etc. etc.), but you don't need that policy for application development.

dmd 5y ago

Meanwhile, over here in healthcare, I'm currently carefully evaluating whether to update some software packages from their 2011-release version to their 2015-release version (which are 99.9% compatible but add one or two new features). And many of our critical systems (mostly MRIs) are on RHEL 5. (Not connected to any network, don't worry!)

user5994461 5y ago
That's a bit too extreme in the opposite direction. :D For those wondering what features are missing from RHEL 5, look further than SSL.
- dmd 5y ago
  Fortunately nobody has ever needed to access the internet from these machines. People on HN forget that a huge amount of computing has nothing whatsoever to do with the web.
  - inglor_cz 5y ago
    In 2002, I underwent a LASIK operation on a machine that ran Windows for Workgroups. I believe the same machine was in use until 2012 or so.
  - user5994461 5y ago
    Expect all healthcare machines to be networked, even if only internally. Need the active directory to login and need to upload the image/test sample somewhere else after it's taken. That's sadly one reason why ransomware can propagate so easily and stop hospitals. :( In theory there can be computers with no network, typically an isolated computer attached to heavy test machinery, but it's becoming impossibly rare in all industries. And they should be easy to recognize, look for the post-it nearby with the shared username/password to unlock it, also notice the doctors leaving with the x-ray printed on paper or a USB key to be able to transfer it elsewhere.
    - 5y ago

nickjj 5y ago

> ... build all my projects inside docker, using each language’s most recent stable release This has been my personal policy for the last 6 years, it works well in practice. You get the best of both worlds. A rock solid system with the flexibility to use whatever programming runtime versions you want.

user5994461 5y ago
I don't think that works anymore with the speed that languages are moving and breaking these days. If you tried to use Python 3.9.0 for example (released November 2020), it had changes in the C bindings and broke many libraries (like numpy), which was not noticed until after the stable release. That took months to fix and I'm not even sure if all packages have been fixed as of today (9 months later).
- mistrial9 5y ago
  side note - this is huge news to me that Python 3.9 broke numpy ! very interesting to hear this
- nickjj 5y ago
  > I don't think that works anymore with the speed that languages are moving and breaking these days. The beauty of this approach is you don't have to use the latest version if you don't want to, but the option is there if your app is compatible. You can still use Python 3.7.x or whatever you want. Docker has official Python images going way back.
KronisLV 5y ago
Agreed. This also has the opposite effect - if there is any old or outdated component or piece of software that you still need to be running for unfortunate reasons, there's always the possibility of putting it in a container with all of the packages and other environment configuration that it requires. That way you don't have to risk compromising the entire system and don't even have to run VMs with old OS releases, while at the same time only need to expose the ports that the software uses, if even those at all. In my eyes, access to devices and such could still use a few improvements in Docker and other competing container runtimes, but for the most part, the technology is a lifesaver! While i do think that it's nice if the same packages are also available outside of containers, for the OS of your choice, which i'm sure will also be the case for latest versions of PHP and other software, even if done by a third party shortly after Debian's new release, that's sadly not always the case. In those situations, containers indeed seem like a good choice.

SkyMarshal 5y ago

Or just use the Debian Alternatives system to install PHP 8.0 and make it the system default: https://wiki.debian.org/DebianAlternatives https://wiki.debian.org/DebianAlternatives Once setup, one command can toggle between your version and the Debian repo version as the system default. DA is great, I used it for years on Ubuntu to override Debian's older default versions, or to install anything I wanted to build from source. I eventually migrated over to NixOS because, in a way, NixOS takes the concept of Debian Alternatives and applies it to the entire OS.

robertlagrant 5y ago
This is why I like nvm/pyenv. Available versions should be managed via a tool, not by the system.
- iso8859-1 5y ago
  This is why I like Nix. The tool should be the system.
- SkyMarshal 5y ago
  Sure, if your tool is aware of its own versions and can do that, that should be the preference over most systems, Nix/NixOS/GUIX excepted. But it's nice for traditional systems like Debian to be able to do it too, for tools that can't.

regularfry 5y ago

That is the correct approach. Docker optional, but language interpreters included with the OS are for the OS. The distribution is there to provide a mutually compatible set of working applications for end users so they don't have to care about matching package versions by hand. Unless what you're doing is writing an application to be packaged with Debian, the version shouldn't matter to you: /usr/local is there, use it. (note: none of this is "official" in any way, just what I've learned over 15 years or so of deploying on Debian-derived distros)

ncphil 5y ago
IMHO, that is the correct approach no matter the distro. The OS is a platform, the software included with it should be what works best to support that platform during a given release cycle. Anything beyond that can be addressed by containers, or third-party package repositories (including your own personal repo). It may be a biased perspective from the server side, but give it credit for being based on long, hard experience with frightening permutations (as in ugly, prone to misbehaving, many-headed beasts supporting critical services).

flatiron 5y ago

I do the same but with Ubuntu. Arch Linux containers are awesome.

rubyist5eva 5y ago

Personally, I moved to CentOS from Debian (and then to AlmaLinux OS) because of DNF modules. You get multiple versions of different language runtimes and you can pick the ones you want to use - so I stick to the LTS versions. You aren't necessarily stuck to just one packaged version of a language runtime now - and 10 years of support is lovely.

zozbot234 5y ago
Debian has the alternatives mechanism for that kind of thing. It works quite well.
jaboutboul 5y ago
Thanks for supporting AlmaLinux!
- rubyist5eva 5y ago
  no problem, it's a worthy successor to CentOS

deleted 5y ago

[deleted]

pavon 5y ago

The only time it took 3 years between Debian stable releases was between Woody and Sarge, which happened over 15 years ago. All releases since have been on a 2 year cadence.

deleted 5y ago

[deleted]

je42 5y ago

On the other end of the spectrum you have a distribution like Arch which gives you most recent releases, but then you also have to deal with breaking packages / package dependencies much more often. But i guess this comes down to "there is no free lunch".

kelp 5y ago
Is that your experience with Arch? I've hardly ever had anything break over many years of using it. I've even committed the sin of waiting many months between upgrades, like on a laptop that sat in a closet. Upgrading usually just works, or there is just a minor issue that can be easily resolved. Usually documented on the arch website.
- uluyol 5y ago
  It's been some time since I've used it, but Arch was more solid for me than any non-LTS distro. It definitely helps too stay up to date though. I remember the moves to pulseaudio and systemd...not fun. Of course, you also have the advantages of being up to date and never needing to do a apt-get dist-upgrade.

e2le 5y ago

Given the inclusion of the Guix and Nix package managers into Debian stable, installing newer versions of software is an option if you need it. Perhaps even a better alternative to installing and using Docker. https://packages.debian.org/bullseye/guix https://packages.debian.org/bullseye/guix

dannyobrien 5y ago

I'm similar, except that I use Debian as the underlying system, and install with Guix. I imagine it's the same with Nix folks. I'm still unsure whether Docker injects that much more complexity and runtime burdens, but it sure feels a little more messy after installing a few tools.

arendtio 5y ago

AFAIK, Debians conservatism was the reason why Ubuntu got so popular. So complaining that Debians packages are too old is somewhat of an old story itself ;-)

rixed 5y ago
More importantly the inclusion of non free drivers. And marketing.
- int_19h 5y ago
  Debian has the "non-free" repo specifically for stuff like this. E.g. the NVidia non-free GPU drivers have been available there for well over 15 years now.

heurisko 5y ago

On the other hand, I can think of many businesses who would be happy with such a conservative baseline.