3 ms·

I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is

I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is mostly security updates. Breakage between major upgrades is very rare. I don't think this thread is about "maintaining a modern code base" at all. Whatever that should mean -- My impression is you've fallen victim to the hype train. In my perception the thread is about always catching up with the latest and greatest. Would you say in all earnest that my code is not modern because I make a point of developping against solid standards and not constantly longing for things that are not in my distribution (the software there is usually 0.5-2.5 years old)? You can check some of my code at https://github.com/jstimpfle https://github.com/jstimpfle. Is it "not modern"? I'm a reasonable but not outstanding developer, and not saying that everything will work on your computer (since I'm usually the only tester) -- but I'm pretty sure I can get everything there to run on your computer with minor effort. > When you upgrade often, it is easier to read the documentation and find where changes might break something, and when things do break it is easier to fix them. No. Breakages are less frequent because the software is not brand new, and they are better known because all people using the stable release are on the same version. Documentation comes with the distribution, but I don't have any problems googling it by giving the version string either. > Upgrades always have the potential to break things, but when you keep up with the upgrades it is easier to achieve the stability and security goals the sysadmin wants. This thread was never about security and I don't approve. I don't think you are familiar with the concept of a stable release. > Upgrades that jump over several versions at a time are a nightmare to debug, and it creates a lot of technological debt that you have to work out later. No. If you develop against solid standards you have less breakage. It's not about incompatibility with the most recent versions. That would be a stupid idea. It's about compatibility with releases other than the latest and greatest. This means not depending on the hot new features that are only in these versions, simple as that.

flukus 10y ago
> I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is mostly security updates. Breakage between major upgrades is very rare. That's fine for an OS, but what do you think business customers would say if you said "sorry, that feature won't be added until the next release in 2 years time"?. That's were tools like pip come in, they let the software move faster, which it often needs too.
- jstimpfle 10y ago
  So what exactly are the latest-and-greatest libraries that you absolutely need to implement your own business critical features? Please list more than only one. It's simple to make exceptions for exceptional requirements.
  - flukus 10y ago
    Well for me, all of the libraries I use because none of them exist as packages for any OS. With most of them security fixes will only go into the latest version though, so once you get behind your system is insecure. Applications aren't something you build and forget. An unmaintained project is a dead one.
    - jstimpfle 10y ago
      > Well for me, all of the libraries I use because none of them exist as packages for any OS. In conclusion you don't use any libraries that are packaged for any OS. What libraries? Also assuming that some libraries you use don't exist for your OS, that doesn't mean that you absolutely need the latest and greatest in a business critical way. So, not approved. All in all, not too fond of the reasoning and the evidence you provide.
      - flukus 10y ago
        Your logic would prevent any app from just about any non-c ecosystem running. Java, ruby, python, dotnet, rust, go, they all have their own library management and very few of those libraries will be available in an apt repository (let alone a compatible one). Your policy may work in a university, but you'd be fired from any real business.
        jstimpfle 10y ago
        You are still not providing evidence. You're also making bold claims ("any app from just about any...") that my personal experience can just not validate. It's very easy to write applications without fancy dependencies. Recently I did algorithms, systems and applications in C, C++, python, sdl, alsa, X11, Unix shell scripting, lp_solve, and some web programming in python, javascript, sqlite3. All rock solid and stable - all will probably run on any Linux box from the last 5-10 years (python3 came only in about 2008; forget about the lp_solve bindings and just use the command-line tool). There are 2050 python3-* packages on my system. Not that I think it's a good idea to use most of them. What's "compatible"? So what are the libraries you absolutely need? What is this week's secret sauce?

flukus 10y ago

> I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is mostly security updates. Breakage between major upgrades is very rare. That's fine for an OS, but what do you think business customers would say if you said "sorry, that feature won't be added until the next release in 2 years time"?. That's were tools like pip come in, they let the software move faster, which it often needs too.

jstimpfle 10y ago
So what exactly are the latest-and-greatest libraries that you absolutely need to implement your own business critical features? Please list more than only one. It's simple to make exceptions for exceptional requirements.
- flukus 10y ago
  Well for me, all of the libraries I use because none of them exist as packages for any OS. With most of them security fixes will only go into the latest version though, so once you get behind your system is insecure. Applications aren't something you build and forget. An unmaintained project is a dead one.
  - jstimpfle 10y ago
    > Well for me, all of the libraries I use because none of them exist as packages for any OS. In conclusion you don't use any libraries that are packaged for any OS. What libraries? Also assuming that some libraries you use don't exist for your OS, that doesn't mean that you absolutely need the latest and greatest in a business critical way. So, not approved. All in all, not too fond of the reasoning and the evidence you provide.
    - flukus 10y ago
      Your logic would prevent any app from just about any non-c ecosystem running. Java, ruby, python, dotnet, rust, go, they all have their own library management and very few of those libraries will be available in an apt repository (let alone a compatible one). Your policy may work in a university, but you'd be fired from any real business.
      - jstimpfle 10y ago
        You are still not providing evidence. You're also making bold claims ("any app from just about any...") that my personal experience can just not validate. It's very easy to write applications without fancy dependencies. Recently I did algorithms, systems and applications in C, C++, python, sdl, alsa, X11, Unix shell scripting, lp_solve, and some web programming in python, javascript, sqlite3. All rock solid and stable - all will probably run on any Linux box from the last 5-10 years (python3 came only in about 2008; forget about the lp_solve bindings and just use the command-line tool). There are 2050 python3-* packages on my system. Not that I think it's a good idea to use most of them. What's "compatible"? So what are the libraries you absolutely need? What is this week's secret sauce?