4 ms·

Good lord no - if I can run my current laptop for 10 years on 20.04 - I'll be more than happy to do so. I want innovation in my own code, my applications, brow

Good lord no - if I can run my current laptop for 10 years on 20.04 - I'll be more than happy to do so. I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... Save the new operating systems for new hardware, bus standards, innovative GUIs, etc... Let me just keep pounding away 12-hours/day without a hiccup on my current gear.

Arnavion 5y ago
>I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... So either your applications and browsers come from the distro's package repo, in which case when their upstreams update to newer versions that require newer dependencies your distro doesn't have, your distro will be stuck on older versions lacking the innovation you seek. Or you use flatpaks or snaps, which don't have that problem because the flatpak / snap bundles the newer libraries, but then the stability of the OS doesn't help you. And you're still stuck with an old flatpak / snap daemon that could cause problems with new flatpaks / snaps, and with an old kernel that could be missing syscalls that the newer libc's inside the flatpaks / snaps require. Eg I remember discovering that 16.04 and earlier don't have the getrandom syscall, which made it impossible to run a newer OS's Docker container since its libc expected it. To be clear, I'm all for people wanting to remain on supported OSes for a decade. I'm just pointing out that expecting "innovation" is incompatible with that.
- The_Colonel 5y ago
  > I'm just pointing out that expecting "innovation" is incompatible with that. No, it's not. There's a huge difference between "let me update these 2 apps which I care about" and having to upgrade the whole system to get those 2 new updated apps.
  - Arnavion 5y ago
    Perhaps you should read the two preceding paragraphs to see the problem with that expectation instead of assuming the third paragraph was written in isolation.
    - The_Colonel 5y ago
      Of course I read them. But the very special case of docker and some hypothetical problems don't invalidate the concept.
- ghshephard 5y ago
  Fair. Particularly the point you make about Docker not being compatible with 16.04 - and, I will make the following confession - everything I said in that post applied to my work system - which is a linux laptop - and almost everything I do there is predicated on things like new python modules, new vscode innovations, new pandas releases - all sorts of things that don't really benefit from the latest and greatest. And, yes - as your OS gets older you need to start to rely on alternative repos like https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa for important things. I guess the point I was trying to make is that I wish, and would pay for (or have my company pay for) distros that just kept everything packaged and running smoothly for 5 year cycles (10 years is probably a bit much, I'll grant you that), understanding that yes, when it comes to innovations like containerization or hypervisors - you might have to bite the bullet and move forward an OS release. At home - I'm a MacOS user, and work very hard not to upgrade the to a new OS in the first month it's released, and am quite comfortable upgrading to a new laptop every 4-5 year. So, I like new things for my personal environment. It's just my work environment that I want to stay the same for as long as possible.

Arnavion 5y ago

>I want innovation in my own code, my applications, browsers - not my Operating System/BIOS/UEFI/etc... So either your applications and browsers come from the distro's package repo, in which case when their upstreams update to newer versions that require newer dependencies your distro doesn't have, your distro will be stuck on older versions lacking the innovation you seek. Or you use flatpaks or snaps, which don't have that problem because the flatpak / snap bundles the newer libraries, but then the stability of the OS doesn't help you. And you're still stuck with an old flatpak / snap daemon that could cause problems with new flatpaks / snaps, and with an old kernel that could be missing syscalls that the newer libc's inside the flatpaks / snaps require. Eg I remember discovering that 16.04 and earlier don't have the getrandom syscall, which made it impossible to run a newer OS's Docker container since its libc expected it. To be clear, I'm all for people wanting to remain on supported OSes for a decade. I'm just pointing out that expecting "innovation" is incompatible with that.

The_Colonel 5y ago
> I'm just pointing out that expecting "innovation" is incompatible with that. No, it's not. There's a huge difference between "let me update these 2 apps which I care about" and having to upgrade the whole system to get those 2 new updated apps.
- Arnavion 5y ago
  Perhaps you should read the two preceding paragraphs to see the problem with that expectation instead of assuming the third paragraph was written in isolation.
  - The_Colonel 5y ago
    Of course I read them. But the very special case of docker and some hypothetical problems don't invalidate the concept.
ghshephard 5y ago
Fair. Particularly the point you make about Docker not being compatible with 16.04 - and, I will make the following confession - everything I said in that post applied to my work system - which is a linux laptop - and almost everything I do there is predicated on things like new python modules, new vscode innovations, new pandas releases - all sorts of things that don't really benefit from the latest and greatest. And, yes - as your OS gets older you need to start to rely on alternative repos like https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa for important things. I guess the point I was trying to make is that I wish, and would pay for (or have my company pay for) distros that just kept everything packaged and running smoothly for 5 year cycles (10 years is probably a bit much, I'll grant you that), understanding that yes, when it comes to innovations like containerization or hypervisors - you might have to bite the bullet and move forward an OS release. At home - I'm a MacOS user, and work very hard not to upgrade the to a new OS in the first month it's released, and am quite comfortable upgrading to a new laptop every 4-5 year. So, I like new things for my personal environment. It's just my work environment that I want to stay the same for as long as possible.