5 ms·

For one thing, if there is any place to treat software like a toy and to play around with the latest version, it would be a college or university. I don't part

For one thing, if there is any place to treat software like a toy and to play around with the latest version, it would be a college or university. I don't particularly care about having my software on the latest version. I personally prefer using the old version for six months while the newest version gets the bugs worked out of it. I know sysadmins value reliability and security, but it's really frustrating when every upgrade takes dozens of hours of work to approve. Questions like "What features do you need in the new version" miss the point. It isn't about the features of the software, it is about maintaining a modern code base. 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. 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. 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. Ultimately, sticking with a version of software because it works is trading a little stability now for an absolute mess down the line.

jstimpfle 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. 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

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.