9 ms·

One of the things that's quite popular with people out in the world is being able to set up a Linux server and then leave it be for the better part

by TekMol 3y ago

One of the things that's quite popular with people out in the world is being able to set up a Linux server and then leave it be for the better part of a decade without having to reinstall it or upgrade the distribution. Why not the better part of the century? I have never seen anybody who runs a business being happy about something new in the next version of the distro which powers their onlineshop or blog or whatever they run. But I constantly see how annoying it is for real world applications having to update the "outdated" stack every few years. The stack is almost always already perfectly fine for what they are doing. All it needs is security updates. Which get less and less frequent as the system matures. There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than all the work that will go into Debian 13, 14, 15 etc.

brnt 3y ago
The problem is that shoving a full modern OS into an appliance means you'll need to deal with the many surfaces of attack on that OS somehow. Updating it from time to time might be better than getting hacked and recovery being difficult or impossible?
- TekMol 3y ago
  From the perspective of a distro, I am sure that fixing bugs in the current version takes way less work than building the next version of the distro. So I suggest it is worth building the next version 5% slower and use the free 5% of resources to fix security issues in the last one. And by this, extending security fixes for the last version to 50 years.
  - mcny 3y ago
    If we say "security updates only" for the kernel, does that mean we won't support new processors and graphics cards? When Intel and AMD say they have a patch that enables new processors and peripherals, do we decline it? Why? People will expect the distribution to just work with newer hardware. Or maybe you're saying upgrade to debian 13 if/when you get new hardware but stay with 12 for fifty years on current hardware? Intel and AMD should fire their marketing if a lot of people feel ok running the same hardware for fifty years, no?
    - Dalewyn 3y ago
      >If we say "security updates only" for the kernel, does that mean we won't support new processors and graphics cards? Why would you need support for new hardware if the use case is hardware that's going to sit for 50 years doing one thing and doing it well?
  - brnt 3y ago
    1. People are building a next version of the distro anyway. Even if you want stable, you don't want 80ies stable. 2. Is making a new release really more work? Most parts of a distro come from upstream, so their development too. I don't think most tools have stable branches, you're just expected to upgrade. Backporting security fixes is then actually more work than simply updating and solving breakage every now and then.
  - cdogl 3y ago
    For any distro, “fixing bugs” that affect users will mean upstreaming patches to source in over 99% of cases. If you’re upstreaming patches, you’ll want to run the new version of upstream with those fixes included. Now you’re running new software and you’ve come full circle to a distro upgrade. The alternative is to maintain your own patches, but that is not remotely sustainable for even the largest commercially supported distributions. I sidestep all these concerns by running a rolling release distro on my workstation and deploying serverless code at work. I don’t miss the days of trying to get software downloaded off the web to work on a fixed debian or Ubuntu install. Edit: nor having my production language runtime constrained by distro!
  - rcxdude 3y ago
    Backporting and maintaining patchsets is a huge portion of the work of distro maintainers, possibly more so than developing each new version. Why do you think Arch (which very much has a "least effort for maintainers" philosophy) avoids it as much as possible while happily keeping up with the bleeding edge?
  - comboy 3y ago
    Just judging by your karma you are not new to software development. So how do you imagine it? Your installation is a point in time, there are sometimes refactorings which need to be done, version of library which fixes the security hole depends on 3 other libraries in newer version than your current one and of it goes. It such a common pattern and it's really hard to avoid because you can't maintain 20 versions of product for people who installed at different points in time. I wholeheartedly agree with the sentiment, but it sounds like a wishful thinking. If you maintain a simple library, do you backport a bugfix to every single previous released version? Because that's what would be required. From every single one of them.
  - jart 3y ago
    > So I suggest it is worth building the next version 5% slower and use the free 5% of resources to fix security issues in the last one. And by this, extending security fixes for the last version to 50 years. If we want to bring math into the conversation, then I don't think that would cut it, since supporting old releases is basically quadratic in terms of human effort. It's why distros ship LTS releases at a different cadence, which makes the problem less bad. But the costliness explodes if they do it for any longer than a few releases. It'd be fine if all the sticks in the mud could agree to use one specific old version, like RHEL5 and only RHEL5. But that's basically what projects like the BSDs are already doing, and they're awesome. I wish people who desire Linux to not change so rapidly were supporting the BSD folks instead, because they actually live up to preserving UNIX in a very authentic form.
- deleted 3y ago
  [deleted]
Denvercoder9 3y ago
> which powers their onlineshop or blog or whatever they run 50 years of support doesn't make sense for these usecases, as the world keeps moving on around them. A blog that still looks like it's 2008 won't sell your business in 2023. A webshop from 2013 won't accept the popular payment methods of 2023 in large parts of the world. If these products will be updated anyway, at a certain point building on an old stack causes more work than it saves.
- blueflow 3y ago
  I maintain the infra for some over a decade old http applications. They are not for selling or self-promotion using the newest shit. These sites are for getting a job done. And users actually enjoy it very much when the http form they use daily stays the same for over a decade.
  - 6510 3y ago
    The most requested feature: Put it back the way it was.
  - Denvercoder9 3y ago
    There's a big difference between "over a decade old" and "50 years" though. I'm not contending that there's a sizeable amount of 10+ year old applications that are still useful, but I'd wager that their number is inversely correlated with their age; and that 50 years is too long of a support term to be sensible. E.g. HTTP is less than 35 years old. And it's not just because the outside world is moving on, if you use a distro from 2000 for 50 years you'll run into problems in 2038 because it still uses 32-bit time_t.
- rakoo 3y ago
  A sizeable part of the web is not about selling stuff but providing a service, information, exchanges. Consumption and capitalism is incompatible with stability and longevity, so of course tending only to it will not work. In 50 years, we'll still want a forum-like to discuss about the latest shenanigans of then-Elon Musk.
- 3y ago
2143 3y ago
> There should be an effort to offer 50 years of security updates for Debian 12. That reminds me, SQLite is engineered to keep working until atleast 2050 (and beyond). https://www.sqlite.org/lts.html https://www.sqlite.org/lts.html
mrweasel 3y ago
Just yesterday we had the 30th birthday of Windows NT and while I'm not suggesting that moving between versions would not have required effort, that it probably the platform you should have opted for if you want multi-decade stability for your application. You would have need to adapt your code along the way but if you wrote a C++ application or service 30 years ago, there is a good chance of making that run on modern Windows as well. I'm not a Windows, nor a C++ guy, but that seems like it would have been a pretty safe choice if you built an application back then with the expectation of having it running 50 years later.
- justinclift 3y ago
  For long term stuff, maybe mainframes or VMS is where it's at? https://vmssoftware.com https://vmssoftware.com <-- seems to be the company doing VMS these days
- Dalewyn 3y ago
  Windows and Microsoft are worth respecting for ensuring ancient code will run so long as it follows either of two requirements: Code according to documented standards of the time, or become significant enough that Microsoft will write special patches for you (eg: SimCity). Windows is a really interesting stark contrast to the rest of the computing world that prefers moving fast and breaking things, much to the chagrin of most users.
  - pjmlp 3y ago
    Not the rest of the industry, the mainframe and micro computer worlds are even more focused on that regard. Probably many of Burroughs B5000 applications will still mostly run without any issues on a recent Unisys ClearPath MCP, just as one possible example.
jakjak123 3y ago
This is one of the costs of most free software. You either update to latest version, or you pay for support. Of course it is up to each project if they even want to offer such support.
- jillesvangurp 3y ago
  You get the same cost with closed source software and it's as old as software is. Try getting support for older versions of windows. Or DOS. MS walked away from that at some point as well. The benefit of open source software is that as long as the code is out there, somebody could take it upon themselves to fix things and share the results. You don't have that option with windows. And you only have that option with Dos because somebody created an OSS version of that; which is still being used by some to run stuff from last century. Windows is probably a bit more tricky.
j1elo 3y ago
Coincidentally, yesterday I was talking with a friend about which terminal we use, and how I went from the default gnome-terminal to the more capable konsole, moved by a silly bug: "Select all" doesn't select _all_ text, but only the text that is currently under view [1]. That's caused by a "temporary" fix in an underlying library, which seems was not so temporary, given that it got into the feature freeze and release of the Ubuntu LTS I use. This means that for the whole support period of any distro that bundled the broken feature, users will find it and have to work around it, over and over. Can you imagine if that was for a century? I think distros should relax their policies and not only accept changes to fix security vulnerabilities (as is the case now), but also to fix promised features that shipped in a broken state. Otherwise, once some broken software ships, it stays broken for the whole lifecycle of the distro, which is bonkers. [1]: In case anyone can provide further feedback, ideas for the author on how to fix it, or any help. https://gitlab.gnome.org/GNOME/vte/-/issues/2504 https://gitlab.gnome.org/GNOME/vte/-/issues/2504
- blueflow 3y ago
  > Can you imagine if that was for a century? If i had to keep a software stack for a century, i wouldn't pick GNOME. Generally you'd avoid any software project that has the faintest smell of "move fast and break things". -- ex GNOME user
  - Dalewyn 3y ago
    I wouldn't pick anything Linux in general if moving fast and breaking things is problematic.
    - blueflow 3y ago
      I'm still looking, do you have recommendations?
      - rakoo 3y ago
        The BSDs, OpenBSD in particular, are built for long-term. Any change is evaluated multiple times before being integrated. From the point of view of Linux they can seem outdated/old/lagging, but from their point of view they just work.
hannob 3y ago
Eventually you run into issues with your stack being incompatible with the rest of the world. Your 20 year old debian won't be able to provide a TLS stack that is compatible with any modern browsers. And you could argue that this is still a "security backport", but backporting a new TLS version isn't like your garden-variety buffer overflow backport patch.
- the8472 3y ago
  The TLS treadmill + certificate authority lists are antithetical to stability. HTTP + merkle-tree based integrity checking + having the merkle root in DNS could be way more stable. Even the the SHA1 deprecation would barely affect this, as long as you're not using the hash tree to vouch for content provided by 3rd parties collision attacks don't matter.
  - rakoo 3y ago
    Ok but once you have integrity, how do you open a private channel with the website ? You do need TLS, or something akin to that, somewhere. And like all crypto stacks, holes are found and change still needs to happen.
    - the8472 3y ago
      > How do you open a private channel with the website ? I wasn't assuming you would. That's one of the things that have to go on the chopping block if long-term stability is the goal.
      - yencabulator 3y ago
        You can make computers even more stable by casting them in concrete and dropping them in the sea. Do you genuinely think people want computers that cannot be used to read email, do online banking, buy things with, watch Netflix, and so on?
  - Denvercoder9 3y ago
    Forget the whole PKI infrastructure, the OpenSSL in your 20 year old Debian wouldn't have AES. You'd be using DES, 3DES or RC4.
JonChesterfield 3y ago
> There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than... Real businesses seem to prefer to spend time dealing with breakages than money to avoid them. It's not economically optimal. Some buy their OS from IBM instead with mixed results but generally more focus on doing things businesses seem to want.
- pmontra 3y ago
  We know that something is going to break anyway because the world changes and it's impossible to cope with future unknown changes. So it's worth having some robustness but too much of it is not robustness anymore, it's money spent on wishful thinking.
Avshalom 3y ago
because 51 years ago was the age of speaking to room sized computers with typewriters and punchcards. Nothing about computing is anywhere close to settled enough for anyone to actually think about it on century-long time scales. Maybe we're at a point where we can talk about appliance style computers-single task, very limited I/O lasting that long. It'd be nice, don't get me wrong, but OpenBSD should probably last a century before we start asking if we could let it run for another century.
- Aerbil313 3y ago
  This. The entire field of software is nowhere near mature or settled. My gut says that, in terms of software technology, the society today has progressed only %20 of the road and utilized the techology only that amount, compared to what it could be. Very few software I use I can call mature (i.e there's no meaningful room of improvement), they can be improved much more. The collective amount of work that has been put in to develop software by humanity so far not being enough means that the potential of the field is so great, maybe uncomparable to any other (e.g. think about carpentry).
- nullifidian 3y ago
  >is anywhere close to settled enough Some things are pretty well settled. 40 year old Unix software (K&R C,IPC/network sockets) would work on a modern linux with trivial or zero changes, and it doesn't look like it's gonna change soon. That was the age of not room sized, but half a fridge sized "minicomputers". Old software that people rely on doesn't necessarily need new features or improved capabilities that new standards and interfaces provide. Security, the constant change of the environment(network, protocols), and hardware and software changing in tandem are the only reasons people have to migrate or rewrite some pieces of well established software. Some of these changes in the environment feel as if these changes are for the changes' sake, to create programmer jobs.
  - AnimalMuppet 3y ago
    > 40 year old Unix software (K&R C,IPC/network sockets) would work on a modern linux with trivial or zero changes, and it doesn't look like it's gonna change soon. Is that true? Will K&R C (that is, C with old-style function declarations, not prototypes) compile on a modern compiler? I thought that gcc, for instance, no longer supported that declaration style. (And if you just have to add a flag to the makefile, I will agree that it's a trivial change.) On the sockets, I agree with you.
NovemberWhiskey 3y ago
Working in a Fortune 100 company, the upgrade cadence of our Linux plant is driven 100% by our info-sec organization. Left to their own devices, most of the developers would still happily be on RHEL 6. Or possibly 5. Or in some cases, Solaris 8. Ditto for Java 8.
- krzyk 3y ago
  Seriously? I'm a developer and if I would be left to my own devices I would upgrade to the newest beta software where possible and run Java 21 EA with enable-preview. The only stopper is lazy people and infosec.
  - hdaz0017 3y ago
    they call it bleeeeeding-edge for a reason ;)
  - solatic 3y ago
    Are you a developer for a Fortune 100? The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS, because anything with shorter upgrade cycles takes too much time to get too many other people to buy in before a new version is released (and the old version is no longer supported). There's a reason why you see a ton of stuff like VBA in the military, and it's not because VBA is usually the best tool for the job by any technical metric. It's because the people who chose it didn't need to align 100+ other stakeholders in order to pick a different tool; they were able to start implementing what they needed immediately.
    - signal11 3y ago
      > The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS This is an archaic view and certainly not true for all Fortune 100 teams. Plenty of them have digital platforms that bring in lots of money, and staying with legacy tech isn’t going to be good for business when faced with new, nimble challengers. Learning from the wider industry, FAANG included, is the smart thing to do. > LTS The key here is to save $$$ and stay secure. LTS is just deferred cost and pain. For teams with good tests and CI for instance — if they’ve migrated to Java 11, upgrading the JVM is relatively easy after that. Staying on LTS releases for ages is costly as you’re just deferring cost, as even Oracle JDK contributors have pointed out. Ultimately it’s a cost/benefit equation, but often it’s economically sensible to bite the bullet and upgrade from Java 8 -> 11, and then upgrade more regularly. Incidentally, Oracle’s recommendation is to perform Java LTS upgrades every 3 years. Sure you can defer further, but it’ll cost you. Oracle support ain’t free. But most well-run teams with tests and CI can move every 12-24 months. [1] [1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3bjar/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3cn6p/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...
solatic 3y ago
> which powers their onlineshop or blog or whatever they run Why are small businesses like that running their own servers? Pay for the most managed service you can - if it's an online shop, then something like Shopify; if it's a blog, then something like Ghost. Running Internet servers isn't just about security updates, it's also DDoS protection, backups, and VM replacement when the underlying hardware fails, at the very least. Why would any business devote any headspace to that unless they're forced to in order to make a profit?
- yakubin 3y ago
  > Why are small businesses like that running their own servers? Because the more managed a service, the less of a commodity it tends to be and leaves you at the mercy of the service provider wrt price changes, future availability, general quality.
  - solatic 3y ago
    I don't disagree that there are benefits to running your own servers, just that it's not worth the cost unless you need it. When I buy a car, I may own the car, but I'm at the mercy of whoever for parts and service, which becomes more and more true over time as the OEMs shove more and more computerized parts into cars and stop publishing service manuals. Does that mean that I should build my own car from spare parts, so that I can be free of dependency on any one upstream manufacturer? Of course not - the costs of self-maintenance are too high. Now, if I run the New York Police Department vehicular fleet, and I'm responsible for thousands of cars that can't afford to be off the streets for too long, with the budget for a bunch of mechanic salaries and all the latest tools, then sure, maybe that's a serious argument. But not if I'm a small business and I have one server running a simple application.
    - yakubin 3y ago
      Cars are commodities though. Your business won’t be disturbed when you change your car. There’s basically no difference from the point of view of your customers. But when you use a managed ecommerce service and you want to migrate to another provider, your old links will stop working, order histories will be lost etc.
ilyt 3y ago
> There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than all the work that will go into Debian 13, 14, 15 etc. Well business is free to sponsor such effort, I'm sure Debian project will be happy with extra money. Just that cost will be steadily growing year by year because backporting new fixes to ancient code gets more and more expensive in general. Also majority of security problems will not be "distro machine is running" but "app that is running on that distro". A container with app that can just run on modern distro is far more preferable method to support something for long time.
hackerbrother 3y ago
50 years is simply not realistic in terms of technology lifecycle.
nonameiguess 3y ago
An application that deployed 50 years ago and never updated would not run on 64-bit processors and would not be able to use the TCP/IP protocol suite. 50 years is longer than the average lifespan of any physical hardware component and it's not clear whatever drivers you had from back then would support any replacement part you could still find.
- ElectricalUnion 3y ago
  > An application that deployed 50 years ago and never updated would not run on 64-bit processors and would not be able to use the TCP/IP protocol suite. You can run legacy 24-bit mainframe apps on modern 64-bit mainframes fine. You can use legacy 3270 "green-screen" CICS mainframe apps over TCP/IP using CICS Transaction Gateway, with basically no changes to your CICS app. It's just that mainframe customers pay a lot for this convenience and stability.

by TekMol 3y ago

brnt 3y ago

The problem is that shoving a full modern OS into an appliance means you'll need to deal with the many surfaces of attack on that OS somehow. Updating it from time to time might be better than getting hacked and recovery being difficult or impossible?

TekMol 3y ago
From the perspective of a distro, I am sure that fixing bugs in the current version takes way less work than building the next version of the distro. So I suggest it is worth building the next version 5% slower and use the free 5% of resources to fix security issues in the last one. And by this, extending security fixes for the last version to 50 years.
- mcny 3y ago
  If we say "security updates only" for the kernel, does that mean we won't support new processors and graphics cards? When Intel and AMD say they have a patch that enables new processors and peripherals, do we decline it? Why? People will expect the distribution to just work with newer hardware. Or maybe you're saying upgrade to debian 13 if/when you get new hardware but stay with 12 for fifty years on current hardware? Intel and AMD should fire their marketing if a lot of people feel ok running the same hardware for fifty years, no?
  - Dalewyn 3y ago
    >If we say "security updates only" for the kernel, does that mean we won't support new processors and graphics cards? Why would you need support for new hardware if the use case is hardware that's going to sit for 50 years doing one thing and doing it well?
- brnt 3y ago
  1. People are building a next version of the distro anyway. Even if you want stable, you don't want 80ies stable. 2. Is making a new release really more work? Most parts of a distro come from upstream, so their development too. I don't think most tools have stable branches, you're just expected to upgrade. Backporting security fixes is then actually more work than simply updating and solving breakage every now and then.
- cdogl 3y ago
  For any distro, “fixing bugs” that affect users will mean upstreaming patches to source in over 99% of cases. If you’re upstreaming patches, you’ll want to run the new version of upstream with those fixes included. Now you’re running new software and you’ve come full circle to a distro upgrade. The alternative is to maintain your own patches, but that is not remotely sustainable for even the largest commercially supported distributions. I sidestep all these concerns by running a rolling release distro on my workstation and deploying serverless code at work. I don’t miss the days of trying to get software downloaded off the web to work on a fixed debian or Ubuntu install. Edit: nor having my production language runtime constrained by distro!
- rcxdude 3y ago
  Backporting and maintaining patchsets is a huge portion of the work of distro maintainers, possibly more so than developing each new version. Why do you think Arch (which very much has a "least effort for maintainers" philosophy) avoids it as much as possible while happily keeping up with the bleeding edge?
- comboy 3y ago
  Just judging by your karma you are not new to software development. So how do you imagine it? Your installation is a point in time, there are sometimes refactorings which need to be done, version of library which fixes the security hole depends on 3 other libraries in newer version than your current one and of it goes. It such a common pattern and it's really hard to avoid because you can't maintain 20 versions of product for people who installed at different points in time. I wholeheartedly agree with the sentiment, but it sounds like a wishful thinking. If you maintain a simple library, do you backport a bugfix to every single previous released version? Because that's what would be required. From every single one of them.
- jart 3y ago
  > So I suggest it is worth building the next version 5% slower and use the free 5% of resources to fix security issues in the last one. And by this, extending security fixes for the last version to 50 years. If we want to bring math into the conversation, then I don't think that would cut it, since supporting old releases is basically quadratic in terms of human effort. It's why distros ship LTS releases at a different cadence, which makes the problem less bad. But the costliness explodes if they do it for any longer than a few releases. It'd be fine if all the sticks in the mud could agree to use one specific old version, like RHEL5 and only RHEL5. But that's basically what projects like the BSDs are already doing, and they're awesome. I wish people who desire Linux to not change so rapidly were supporting the BSD folks instead, because they actually live up to preserving UNIX in a very authentic form.
deleted 3y ago
[deleted]

Denvercoder9 3y ago

> which powers their onlineshop or blog or whatever they run 50 years of support doesn't make sense for these usecases, as the world keeps moving on around them. A blog that still looks like it's 2008 won't sell your business in 2023. A webshop from 2013 won't accept the popular payment methods of 2023 in large parts of the world. If these products will be updated anyway, at a certain point building on an old stack causes more work than it saves.

blueflow 3y ago
I maintain the infra for some over a decade old http applications. They are not for selling or self-promotion using the newest shit. These sites are for getting a job done. And users actually enjoy it very much when the http form they use daily stays the same for over a decade.
- 6510 3y ago
  The most requested feature: Put it back the way it was.
- Denvercoder9 3y ago
  There's a big difference between "over a decade old" and "50 years" though. I'm not contending that there's a sizeable amount of 10+ year old applications that are still useful, but I'd wager that their number is inversely correlated with their age; and that 50 years is too long of a support term to be sensible. E.g. HTTP is less than 35 years old. And it's not just because the outside world is moving on, if you use a distro from 2000 for 50 years you'll run into problems in 2038 because it still uses 32-bit time_t.
rakoo 3y ago
A sizeable part of the web is not about selling stuff but providing a service, information, exchanges. Consumption and capitalism is incompatible with stability and longevity, so of course tending only to it will not work. In 50 years, we'll still want a forum-like to discuss about the latest shenanigans of then-Elon Musk.
3y ago

2143 3y ago

> There should be an effort to offer 50 years of security updates for Debian 12. That reminds me, SQLite is engineered to keep working until atleast 2050 (and beyond). https://www.sqlite.org/lts.html https://www.sqlite.org/lts.html

mrweasel 3y ago

Just yesterday we had the 30th birthday of Windows NT and while I'm not suggesting that moving between versions would not have required effort, that it probably the platform you should have opted for if you want multi-decade stability for your application. You would have need to adapt your code along the way but if you wrote a C++ application or service 30 years ago, there is a good chance of making that run on modern Windows as well. I'm not a Windows, nor a C++ guy, but that seems like it would have been a pretty safe choice if you built an application back then with the expectation of having it running 50 years later.

justinclift 3y ago
For long term stuff, maybe mainframes or VMS is where it's at? https://vmssoftware.com https://vmssoftware.com <-- seems to be the company doing VMS these days
Dalewyn 3y ago
Windows and Microsoft are worth respecting for ensuring ancient code will run so long as it follows either of two requirements: Code according to documented standards of the time, or become significant enough that Microsoft will write special patches for you (eg: SimCity). Windows is a really interesting stark contrast to the rest of the computing world that prefers moving fast and breaking things, much to the chagrin of most users.
- pjmlp 3y ago
  Not the rest of the industry, the mainframe and micro computer worlds are even more focused on that regard. Probably many of Burroughs B5000 applications will still mostly run without any issues on a recent Unisys ClearPath MCP, just as one possible example.

jakjak123 3y ago

This is one of the costs of most free software. You either update to latest version, or you pay for support. Of course it is up to each project if they even want to offer such support.

jillesvangurp 3y ago
You get the same cost with closed source software and it's as old as software is. Try getting support for older versions of windows. Or DOS. MS walked away from that at some point as well. The benefit of open source software is that as long as the code is out there, somebody could take it upon themselves to fix things and share the results. You don't have that option with windows. And you only have that option with Dos because somebody created an OSS version of that; which is still being used by some to run stuff from last century. Windows is probably a bit more tricky.

j1elo 3y ago

Coincidentally, yesterday I was talking with a friend about which terminal we use, and how I went from the default gnome-terminal to the more capable konsole, moved by a silly bug: "Select all" doesn't select _all_ text, but only the text that is currently under view [1]. That's caused by a "temporary" fix in an underlying library, which seems was not so temporary, given that it got into the feature freeze and release of the Ubuntu LTS I use. This means that for the whole support period of any distro that bundled the broken feature, users will find it and have to work around it, over and over. Can you imagine if that was for a century? I think distros should relax their policies and not only accept changes to fix security vulnerabilities (as is the case now), but also to fix promised features that shipped in a broken state. Otherwise, once some broken software ships, it stays broken for the whole lifecycle of the distro, which is bonkers. [1]: In case anyone can provide further feedback, ideas for the author on how to fix it, or any help. https://gitlab.gnome.org/GNOME/vte/-/issues/2504 https://gitlab.gnome.org/GNOME/vte/-/issues/2504

blueflow 3y ago
> Can you imagine if that was for a century? If i had to keep a software stack for a century, i wouldn't pick GNOME. Generally you'd avoid any software project that has the faintest smell of "move fast and break things". -- ex GNOME user
- Dalewyn 3y ago
  I wouldn't pick anything Linux in general if moving fast and breaking things is problematic.
  - blueflow 3y ago
    I'm still looking, do you have recommendations?
    - rakoo 3y ago
      The BSDs, OpenBSD in particular, are built for long-term. Any change is evaluated multiple times before being integrated. From the point of view of Linux they can seem outdated/old/lagging, but from their point of view they just work.

hannob 3y ago

Eventually you run into issues with your stack being incompatible with the rest of the world. Your 20 year old debian won't be able to provide a TLS stack that is compatible with any modern browsers. And you could argue that this is still a "security backport", but backporting a new TLS version isn't like your garden-variety buffer overflow backport patch.

the8472 3y ago
The TLS treadmill + certificate authority lists are antithetical to stability. HTTP + merkle-tree based integrity checking + having the merkle root in DNS could be way more stable. Even the the SHA1 deprecation would barely affect this, as long as you're not using the hash tree to vouch for content provided by 3rd parties collision attacks don't matter.
- rakoo 3y ago
  Ok but once you have integrity, how do you open a private channel with the website ? You do need TLS, or something akin to that, somewhere. And like all crypto stacks, holes are found and change still needs to happen.
  - the8472 3y ago
    > How do you open a private channel with the website ? I wasn't assuming you would. That's one of the things that have to go on the chopping block if long-term stability is the goal.
    - yencabulator 3y ago
      You can make computers even more stable by casting them in concrete and dropping them in the sea. Do you genuinely think people want computers that cannot be used to read email, do online banking, buy things with, watch Netflix, and so on?
- Denvercoder9 3y ago
  Forget the whole PKI infrastructure, the OpenSSL in your 20 year old Debian wouldn't have AES. You'd be using DES, 3DES or RC4.

JonChesterfield 3y ago

> There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than... Real businesses seem to prefer to spend time dealing with breakages than money to avoid them. It's not economically optimal. Some buy their OS from IBM instead with mixed results but generally more focus on doing things businesses seem to want.

pmontra 3y ago
We know that something is going to break anyway because the world changes and it's impossible to cope with future unknown changes. So it's worth having some robustness but too much of it is not robustness anymore, it's money spent on wishful thinking.

Avshalom 3y ago

because 51 years ago was the age of speaking to room sized computers with typewriters and punchcards. Nothing about computing is anywhere close to settled enough for anyone to actually think about it on century-long time scales. Maybe we're at a point where we can talk about appliance style computers-single task, very limited I/O lasting that long. It'd be nice, don't get me wrong, but OpenBSD should probably last a century before we start asking if we could let it run for another century.

Aerbil313 3y ago
This. The entire field of software is nowhere near mature or settled. My gut says that, in terms of software technology, the society today has progressed only %20 of the road and utilized the techology only that amount, compared to what it could be. Very few software I use I can call mature (i.e there's no meaningful room of improvement), they can be improved much more. The collective amount of work that has been put in to develop software by humanity so far not being enough means that the potential of the field is so great, maybe uncomparable to any other (e.g. think about carpentry).
nullifidian 3y ago
>is anywhere close to settled enough Some things are pretty well settled. 40 year old Unix software (K&R C,IPC/network sockets) would work on a modern linux with trivial or zero changes, and it doesn't look like it's gonna change soon. That was the age of not room sized, but half a fridge sized "minicomputers". Old software that people rely on doesn't necessarily need new features or improved capabilities that new standards and interfaces provide. Security, the constant change of the environment(network, protocols), and hardware and software changing in tandem are the only reasons people have to migrate or rewrite some pieces of well established software. Some of these changes in the environment feel as if these changes are for the changes' sake, to create programmer jobs.
- AnimalMuppet 3y ago
  > 40 year old Unix software (K&R C,IPC/network sockets) would work on a modern linux with trivial or zero changes, and it doesn't look like it's gonna change soon. Is that true? Will K&R C (that is, C with old-style function declarations, not prototypes) compile on a modern compiler? I thought that gcc, for instance, no longer supported that declaration style. (And if you just have to add a flag to the makefile, I will agree that it's a trivial change.) On the sockets, I agree with you.

NovemberWhiskey 3y ago

Working in a Fortune 100 company, the upgrade cadence of our Linux plant is driven 100% by our info-sec organization. Left to their own devices, most of the developers would still happily be on RHEL 6. Or possibly 5. Or in some cases, Solaris 8. Ditto for Java 8.

krzyk 3y ago
Seriously? I'm a developer and if I would be left to my own devices I would upgrade to the newest beta software where possible and run Java 21 EA with enable-preview. The only stopper is lazy people and infosec.
- hdaz0017 3y ago
  they call it bleeeeeding-edge for a reason ;)
- solatic 3y ago
  Are you a developer for a Fortune 100? The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS, because anything with shorter upgrade cycles takes too much time to get too many other people to buy in before a new version is released (and the old version is no longer supported). There's a reason why you see a ton of stuff like VBA in the military, and it's not because VBA is usually the best tool for the job by any technical metric. It's because the people who chose it didn't need to align 100+ other stakeholders in order to pick a different tool; they were able to start implementing what they needed immediately.
  - signal11 3y ago
    > The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS This is an archaic view and certainly not true for all Fortune 100 teams. Plenty of them have digital platforms that bring in lots of money, and staying with legacy tech isn’t going to be good for business when faced with new, nimble challengers. Learning from the wider industry, FAANG included, is the smart thing to do. > LTS The key here is to save $$$ and stay secure. LTS is just deferred cost and pain. For teams with good tests and CI for instance — if they’ve migrated to Java 11, upgrading the JVM is relatively easy after that. Staying on LTS releases for ages is costly as you’re just deferring cost, as even Oracle JDK contributors have pointed out. Ultimately it’s a cost/benefit equation, but often it’s economically sensible to bite the bullet and upgrade from Java 8 -> 11, and then upgrade more regularly. Incidentally, Oracle’s recommendation is to perform Java LTS upgrades every 3 years. Sure you can defer further, but it’ll cost you. Oracle support ain’t free. But most well-run teams with tests and CI can move every 12-24 months. [1] [1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3bjar/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3cn6p/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...

solatic 3y ago

> which powers their onlineshop or blog or whatever they run Why are small businesses like that running their own servers? Pay for the most managed service you can - if it's an online shop, then something like Shopify; if it's a blog, then something like Ghost. Running Internet servers isn't just about security updates, it's also DDoS protection, backups, and VM replacement when the underlying hardware fails, at the very least. Why would any business devote any headspace to that unless they're forced to in order to make a profit?

yakubin 3y ago
> Why are small businesses like that running their own servers? Because the more managed a service, the less of a commodity it tends to be and leaves you at the mercy of the service provider wrt price changes, future availability, general quality.
- solatic 3y ago
  I don't disagree that there are benefits to running your own servers, just that it's not worth the cost unless you need it. When I buy a car, I may own the car, but I'm at the mercy of whoever for parts and service, which becomes more and more true over time as the OEMs shove more and more computerized parts into cars and stop publishing service manuals. Does that mean that I should build my own car from spare parts, so that I can be free of dependency on any one upstream manufacturer? Of course not - the costs of self-maintenance are too high. Now, if I run the New York Police Department vehicular fleet, and I'm responsible for thousands of cars that can't afford to be off the streets for too long, with the budget for a bunch of mechanic salaries and all the latest tools, then sure, maybe that's a serious argument. But not if I'm a small business and I have one server running a simple application.
  - yakubin 3y ago
    Cars are commodities though. Your business won’t be disturbed when you change your car. There’s basically no difference from the point of view of your customers. But when you use a managed ecommerce service and you want to migrate to another provider, your old links will stop working, order histories will be lost etc.

ilyt 3y ago

> There should be an effort to offer 50 years of security updates for Debian 12. That would create more value for real businesses than all the work that will go into Debian 13, 14, 15 etc. Well business is free to sponsor such effort, I'm sure Debian project will be happy with extra money. Just that cost will be steadily growing year by year because backporting new fixes to ancient code gets more and more expensive in general. Also majority of security problems will not be "distro machine is running" but "app that is running on that distro". A container with app that can just run on modern distro is far more preferable method to support something for long time.

hackerbrother 3y ago

50 years is simply not realistic in terms of technology lifecycle.

nonameiguess 3y ago

An application that deployed 50 years ago and never updated would not run on 64-bit processors and would not be able to use the TCP/IP protocol suite. 50 years is longer than the average lifespan of any physical hardware component and it's not clear whatever drivers you had from back then would support any replacement part you could still find.

ElectricalUnion 3y ago
> An application that deployed 50 years ago and never updated would not run on 64-bit processors and would not be able to use the TCP/IP protocol suite. You can run legacy 24-bit mainframe apps on modern 64-bit mainframes fine. You can use legacy 3270 "green-screen" CICS mainframe apps over TCP/IP using CICS Transaction Gateway, with basically no changes to your CICS app. It's just that mainframe customers pay a lot for this convenience and stability.