7 ms·

LTS == 15 Years Not 5

41 points by jandeboevrie 3y ago

nabla9 3y ago
This is why OSS software with simple html interfaces that can run locally or from server, or with QEMU from the newest Apple laptop is so great.
baz00 3y ago
If you want LTS, target Windows. I have stuff I wrote on NT4 that still runs today. Linux and macos can't get near that.
- skywal_l 3y ago
  Assuming you are talking about OS kernel API, what if you static link your libc? My understanding is that the linux kernel API famously does not change [0]. [0] https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75
  - PlutoIsAPlanet 3y ago
    Windows has a stable userland API/ABI, Microsoft go above and beyond for backwards compatibility. Linux does not have a stable userland ABI/API, it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user. The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps). Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...)
    - Arnavion 3y ago
      >Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...) Your link is about glibc, not libc in general. For example musl is perfectly fine to link statically to.
    - stingraycharles 3y ago
      Static linking libc is very iffy indeed, it’s much better to just use a very old libc and dynamically link against that. Python’s “manylinux” binary target is a good example on how to do that. We’re currently targeting “manylinux2014”, which is a decent middle ground.
    - skywal_l 3y ago
      > Linux does not have a stable userland ABI/API I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace". > it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user. But that would be the same thing on windows. If you dynamically link your executable to an old version of libcurl and run your executable on a windows with a newer version containing a breaking change, you'll be in trouble, whatever your OS. > The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps). Flatpak and Docker solves many other problems than kernel API. Actually, it does not solve this problem at all if you think about it because these technologies do not insulate you from the kernel (contrary to a VM). > Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statical https://stackoverflow.com/questions/57476533/why-is-statical...) Statically linking glibc. You can perfectly statically link with any other libc. You can even code without a libc (see zig).
      - Snetry 3y ago
        > I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace". I think you interpreted Linus wrong. When he says "we do not break userspace" he is talking about the Kernel APIs that are exposed to the Userland. Userland APIs would be stuff like glibc, which has a terrible track record in regards to API breakage.
        skywal_l 3y ago
        The statement "Linux does not have a stable userland ABI/API" is about the kernel. If you are talking about glibc you are already in the Linux OS/GNU Linux (whatever it is called) domain. I think I correctly interpreted Linus when he talked about the kernel API/ABI facing the user (developer of application). A lot of trouble you are going to get maintaining builds are due to poor tooling, not linux. But we are getting into semantics here. At the end of the day, I think that if you are careful with what you are doing and think a little before choosing your tools and writing code, you should get very good mileage out of your linux binaries. I don't know enough about windows to comment on its stability but I very much doubt I could just slide my original Quake CD or 3DS max 4 install into Windows 10. But I might be wrong!
    - the8472 3y ago
      On the other hand, old software often runs better (or at all) on dosbox or wine than on windows.
  - baz00 3y ago
    Linus does really well with the kernel ABI and API but the problem is really with literally everything else. It's usually impossible to get something to even compile that's more than a few years old let alone run an old binary.
  - kukkamario 3y ago
    Linux kernel API itself isn't really enough to do eg. any UI software, because things like creating windows or showing notifications, are not part of it directly. You need additional software on top of that for those features. Win32 API is much larger than Linux kernel API and is stable so there is quite large chance that a couple decades old software still works without recompiling or updating libraries. It has its issues with many parts of it being completely horrifying to use, but the stability is something that Microsoft has done well.
  - Arnavion 3y ago
    All this talk about what is or isn't stable ABI on Linux is irrelevant to the article anyway. The article's author explicitly doesn't want their 15-year LTS to ever update its OS or libraries. So ABI stability is not a concern.
- Dalewyn 3y ago
  10 years of support is standard on Windows, and they might be longer depending on the situation (see: Windows XP) or if you're enterprise and pay up (see: Windows 7). And then there's what you allude to: A stable Windows environment that will, in most cases, run ancient code mostly fine assuming they were written to specs of the time or it's a very important piece of code (eg: Simcity).
- EddyTests 3y ago
  If it’s medical devices I assume they want RTOS? Windows wouldn’t work for that world
  - troupo 3y ago
    Depends on the device. A lot of medical equipment still runs on Windows versions from the beginning of the century.
  - baz00 3y ago
    Depends. Most of the stuff would have an RTOS in the hardware interface and a windows GUI.
  - kreetx 3y ago
    Depends on the device but plenty of old Windows machines (XPs) run in hospitals. edit: Hah, good work, siblings!
    - EddyTests 3y ago
      Sure, but I assumed they meant pacemakers rather than desktop apps to manage appointments etc!
      - kreetx 3y ago
        Most of the article is about desktop machines..
      - tmottabr 3y ago
        i guess neither.. this is probably machines that handle special hardware.. like MRI, ECG, or monitor for vitals like pulse, blood pressure, blood oxygenation or other stuff like that.. Those machines need to be certified as a whole package and this include the computer that will control it.. and once you certify you cannot make changes to the package without having to certify again.. So you certify the machine with that software on it.. that specific kernel version, that specific libc version and so on.. if you change anything you need to get a new certification.. and now those machines are no longer air gapped because hospitals want to be able to remote monitor the patients vitals from a central nurse station..
- crabbone 3y ago
  That's because you are lucky, not because it's designed to be that way. Windows has very variable support timeline for its releases, and, going forward, Microsoft only looking to cut down on support times, not increase them. So, even if it worked for you during NT era, it's not going to work for people writing for Windows 10 or whatever the present day version is. Not to mention that Windows is just not a player in many major computer markets, so not even an option for someone who eg. wants to provide storage solutions or HPC and many others.
ynik 3y ago
These days, you're lucky if you get 5 years. Worst offender I have to deal with is "Jenkins LTS", which is supported for only 12 weeks.
- baz00 3y ago
  It takes longer than 12 weeks to start the Jenkins server!
msh 3y ago
The article is full of shit, the author wants free LTS support for 15 years so he can more easily make money... The quote is: Those of us creating medical devices, software for factory lines, and systems that matter need a minimum of 15 years for an LTS especially if you have it in your fool head we should pay money for it. Over that course of time you cannot drop our operating system just because you want to. If his company wants 15 years of LTS support for their products they should find someway of paying for it....
- highwaylights 3y ago
  Absolutely this - expecting free support for no reason is a ridiculous notion to build your own business on. Even then, I think 15 years of support for a Linux distribution is a bad idea anyway - software just moves way faster than that. How supported is that release really going to be after 14 years, even with the best of effort? Is every upstream package going to be version compatible with a 15 year old release with no breaking changes? And if it's not, and you patch around that or freeze those packages, is your software still "supported"? What if there are unpatched critical issues? Is that a better idea than keeping up-to-date with a rolling 24/36/48 month release cycle? In the analogy of a roof or a basic appliance that's fine, but the long-term support equivalent of that is have a copy of the software on a couple of USB drives and disconnect the machine from the internet completely. As long as you don't do anything novel with it, it'll probably work for decades. There are still Windows 3.1 terminals in the wild somewhere.
  - rightbyte 3y ago
    > software just moves way faster than that Which is the problem if you don't want to spend your days troubleshooting BS problems. Much of the movement is for no good reason at all.
    - BadBadJellyBean 3y ago
      There is a very good reason. It is hard to split bugfixes from features. Sometimes it is even very hard to fix a bug without changing the behaviour. It is unreasonable to expect everyone to backport their fixes to all old versions.
jb1991 3y ago
Since it’s not actually mentioned in the article and I found myself quite confused, “LTS“ means “long-term support“. A pet peeve of mine is when bloggers write articles without defining in a single simple parenthetical what the acronyms are.
ptico 3y ago
“We produce an extremely expensive hardware and bill millions for consulting and support but don’t want to spend a single dollar to update a firmware, so now, dear OSS developer, it’s your responsibility to keep my solutions functional for the half of your career years” Did I read this correctly?
- crabbone 3y ago
  > Did I read this correctly? No. Firmware upgrade is a risk that has no mitigations for certain kinds of systems. No amount of money will solve this problem. No sum of money will convince a sensible patient to upgrade firmware on their pacemaker or anything like that. But even for less critical systems -- what's the problem with wanting to pay less? This is like one of the primary economical drivers... You also for some reason think that software upgrades are some sort of a natural phenomena which others have to adjust to, and it just happens on predictable interval, and if you miss your cycle you have to pay. Which is obviously ridiculous. A result of industry conditioning you to expect this to work a certain way, w/o questioning the reason for it to work this way. What should drive software upgrades is in the large part the longevity of hardware. The author claims that the longevity of hardware has improved, even though industry didn't particularly invest into it. It's upsetting to have to generate a lot of e-waste just because we (as an industry) set our sights on a particular release schedule designed to maximize profits for those who provide releases and minimize them for those who consume them.
  - ptico 3y ago
    It’s not about pacemakers at all here for the same exact reason you described: if you’re not able to update firmware, you’re able to update underlying OS as well The problem here is when you sell LTS solutions for $10M thinking you can pay $1000 for keeping your solution afloat for two decades. It doesn’t work this way. Operation systems as well as frameworks and runtimes, are constantly changing, because the industry is constantly moving forward. The only way to keep up is to constantly (and regularly) update YOUR software too (and plan the budgets accordingly). It’s your responsibility to fulfil your obligation. After all, you can still run an up to date Linux (or better NetBSD) on a very old hardware, the problem is that you didn’t update your software regularly to just keep up with changing API/ABI, means didn’t invested too much on a longevity of your product
andrelaszlo 3y ago
"Brew-ha-ha"? This must be an eggcorn! https://en.m.wiktionary.org/wiki/eggcorn https://en.m.wiktionary.org/wiki/eggcorn
mavhc 3y ago
Pre internet you would do the same thing with your computer every day for 15 years and then buy a new one, you could load the same version of MS Word 15 years later no problem. But when you're dealing with the rest of the world, a) you need to keep up, people send you Word n+15 compatible files, b) you want to access new websites, and c) you don't want to get hacked. If you want to run your offline computer for 15 years, that still works today
- Dalewyn 3y ago
  I use Office XP just fine to open documents sent to me that were made in Microsoft 365 or whatever Office is called these days. Yes, I greatly respect Microsoft's attitude towards compatibility.
aaron695 3y ago
[dead]
fragmede 3y ago
Red Hat will sell you support contracts for up to 10, more if you pay them enough and promise not to talk about it. That Ubuntu isn't as business focused as Red Hat is... Well, there's a reason Red Hat is a billion dollar company and Ubuntu isn't. Not that there's anything wrong with that.
Dalewyn 3y ago
Everyone commenting here how author wants 15 years support for free hasn't read the article. >Those of us creating medical devices, software for factory lines, and systems that matter need a minimum of 15 years for an LTS especially if you have it in your fool head we should pay money for it. Emphasis mine. Author is saying, rightfully, that "long term" support needs to be more than 5 years. Author is also saying, reasonably, that it should be at least 15 years if the developers in question want to be paid for support. Author is saying he will pay for long term support if that's what it takes, but not if it's any shorter than 15 years.
- Arnavion 3y ago
  They're implying they wanted to pay for 15 years support but found no takers. Is the problem that nobody wanted to support them for 15 years (their insinuation) or that they didn't pay enough? Given they keep talking about 5-year LTSes without bringing up any of the 10-year LTSes that do exist (Freexian, RHEL, etc), it seems clear to me that it's the latter. Also their requirement is nonsensical. They want support, ie bugfixes, which will require them to install updates. But at the same time they don't want a model that will update them to the latest supported version. Why do they care what the content of the update is? The point of the support contract is that they will be supported regardless. Also also, speaking as someone who works at a company supplying software to car manufacturers, we don't have 15-year LTS for our software either and the manufacturers don't have a problem with it. Their stacks are being designed around automatic updates, which again they had to be anyway to get bugfixes in general. Support contracts are support contracts. Whether an update changes v1.0.0 to v1.1.0 or v2.0.0 makes no difference to them. So what the author says about car manufacturers is also nonsense.
arianvanp 3y ago
I can run 30 year old programs on my x86_64 machine just fine. What the heck is the author talking about. X86 is one of the beacons of long term support. I upgrade computers every 10 years or so. And never had issues. Ever.
mduggles 3y ago
Backporting packages is a time-consuming process that actually requires skill. It is insane to expect people to do that for free on a volunteer basis because it makes your situation easier, especially as backporting gets harder the longer you go. RHEL offers 10 years, it costs money, that's your option. Or you pay for the staff to monitor and backport to your particular distro and foot the bill. It's also maddening to present the issue as "our time is expensive and your time is free". If your field is unable to commit any work at all to updates, fine. UBI Micro is as small as its gonna get and moves everything difficult to the host. That could conceivably run for 15 years if you are careful with how you build it.
mcv 3y ago
I need to read this article more carefully at another time, but it comes across as rather confused to me. > Some time near the end of the 1990s and beginning of the 2000s is when desktop/laptop computer quality began to improve. What does this mean? Computer quality has continuously improved since their inception. At different times on different axes, and sometimes some things got worse, but on the whole they've always improved. > Not one of those libraries has Internet. I can't figure out which libraries are referred to here. Tons of libraries have internet. The article also seems to be confusing hardware and software a lot. Lots of hardware is thrown away too easily because modern software often tends to assume it's run on modern hardware where it can waste resources. Software should be more frugal in its use of resources and if you do, there's no technical reason you can't have modern, secure software running on 15 year old hardware.
- crabbone 3y ago
  > Computer quality has continuously improved since their inception. Not really. For example the switch to LCD monitors from CRT was a step back in quality. LCD was just way cheaper and more convenient as in taking less space that regardless of worse quality it still took over. It took many years for the various aspects of image / video quality to catch up. There are plenty of similar examples where price decrease was what driving the industry rather than quality. In general, shrinking form-factor brought lots of drops in quality, because it's harder to make various electronic parts smaller and as durable. Opening markets to wider range of players (eg. "the PC revolution") is also bound to bring drops in quality as many inexperienced players will be seeking to enter the market and typically contest the lower bound of quality. It's only when the industry stabilizes on some standard and creates a group of experienced players who compete for the same niche is when it's possible for the quality to continuously increase. Did something like this happen in the 90s and 00s? -- I don't know. From software perspective, I think about those years as the time when the decline started to accelerate, and I see us still on the decline of software quality in general. But I don't know what the author is referring to.
  - mcv 3y ago
    > LCD was just way cheaper and more convenient as in taking less space that regardless of worse quality it still took over. They were definitely not cheaper at first. But taking up less space is also a quality. You often get trade-offs like that. You often get things that are faster, but they produce more heat. Early SSDs were faster, but had less capacity than HDDs. It's still part of progress, and these technologies often exist side by side for a while before for a lot of people, the trade-off means they prefer the older tech, until the newer tech catches up on the attributes it was less good at. > In general, shrinking form-factor brought lots of drops in quality, because it's harder to make various electronic parts smaller and as durable. Again, different aspects of quality. The fact that computers now fit in your pocket instead of taking up an entire room is progress. It enables new ways to use them. Early laptops were not an attractive replacement for many desktop uses, but now they generally are. But still not quite for all (I just bought a new desktop PC).
BadBadJellyBean 3y ago
In this day and age it should be possible to not tightly integrate the computer into the device you are building. That way you can update the hardware and stay current with software. Building things with computers is just an ongoing investment into updates and staying current. Because the longer you push it away the harder it gets to update.
BiteCode_dev 3y ago
It's 5 years for free. You can have 15. You just have to pay for it.
kemotep 3y ago
The tone and quality of this article is atrocious. Let alone demanding that software developers (the very ones the author spends a chunk of the article belittling) work for free for 15 years. There is more nuance than upgrading everything 6 months/yearly versus being fine with still using Windows XP 20 years later. As an aside it feels not only blogs but news articles from places like the BBC and NPR have several glaring spelling and grammatical errors. The quality of writing either has gone down significantly the past few years or is it my standards of writing being higher now?
happymellon 3y ago
This piece seems very confusing. RedHat will sell you longer long term support if you want it, I believe they will do 15 years, Suse offer 13 years. What's the issue here? That you don't have to throw away a Mac that isn't connected to the internet, but they feel like they have to throw away a PC?
HeavyStorm 3y ago
The article is full of unjustified hatred for modern software practices. The author fails tô acknowledge the amount of failures of big projects and escalating costs, focusing only in the fact that today practices output less robust software.
- crabbone 3y ago
  Hatred for modern software practices is fully justified. Unfortunately we didn't have enough of historical evidence yet, nor did we have enough shifts in software development practices to tell if we had it much worse or much better before, but there are obvious shortcomings of what we do today compared to 20-30 years ago. The major shortcomings, the way I see them: 1. The overall software quality is on steady decrease since late 70's. This is, at least in part, due to more software being developed for less mission-critical systems and consequently by less qualified personnel. So, commercially, we don't need as much of higher-quality software as we did before. 2. Software industry is exceptional in the way it relies on multiple other players in the industry for individual production and as such is a lot more susceptible to trends and more influenced by majority than many others. I.e. of the majority of the industry decides they don't need long-term support, then the minority won't have it because the minority's survival is contingent on the policy and services (inadvertently) provided by the majority. 3. Software quality is exceptionally difficult to measure formally. This leads to big and small players, intentionally and unknowingly, mis-advertising and misunderstanding the quality of their own products. This makes it very hard to almost impossible to price your products or services based on quality. The realistic alternative to quality the companies are using is the ability of the product / service provider to support the customer in the case of failure. Which is a function of size of a company provider more than anything else. This leads to the situation where instead of focusing on understanding and improving software quality, companies develop reputation though marketing and customer support, which they later misrepresent as software quality. All the above is the result, at leas in the large part, of the modern software practices. We created the practices that emphasize speed of delivery over every other aspect of software because we don't know and don't want to figure out how to reliably increase any other metric. We created a lot of monopolies in software world by following the modern development practices which preach using commonly used third-party components, even of lower quality over bespoke alternatives. This is especially motivated by cost savings when it comes to human resources, which become more interchangeable (and cheaper in the short term for the employer) with this approach. Software monopolies stifle innovation and fix prices not only in the software field, but they also adversely affect the hardware field which has to adjust itself to the software practices. We could be doing better if we understand the shortcomings of our current process -- these aren't the necessary consequences of making software, but in order to effect a change initial good will is needed from multiple players, which is hard to accomplish w/o these multiple players, at least, first acknowledging the problems.
crabbone 3y ago
ITT: surprisingly many people think that software grows on trees and is harvested twice a year to get new versions of it. And that if you miss your harvesting cycle you might as well close your software farm and just kill over and die. The way I see it, the primary motivation for software longevity should be the hardware longevity. Ideally, software needs to outlive the hardware rather than the other way around. But we came to expect ridiculously short version iterations because this process was a major profit driver for software companies. If modern hardware happens to be more reliable than what was the norm 20-30 years ago, then, naturally, we should want the software to adjust to service the modern hardware. And if this doesn't happen -- it's a problem. In this instance, it seems to be an indication of companies big and small trying to sell worse quality software than what was reasonably possible while duping the audience into believing that the quality is still good. Well, of course it is upsetting! Why would you even think otherwise?
hnbear 3y ago
I got this far, wondering if this was satire or not, then realized they just have no concept of the world at large: > America, some of the EU, England, and some others are considered “First World” countries Some others? Canada? England isn’t a country. UK is the state, yes, there’s weird terminology, but even as a Brit we don’t class England as a country. I love the implication Wales, Scotland and NI are not first world. Some of the EU? There’s so much missing here it’s crazy. Yes, the article has many many flaws, that was my personal limit. Besides, when I’m half way through and still can’t tell if it’s a joke or not, I think that’s a red flag.

41 points by jandeboevrie 3y ago

This is why OSS software with simple html interfaces that can run locally or from server, or with QEMU from the newest Apple laptop is so great.

baz00 3y ago

If you want LTS, target Windows. I have stuff I wrote on NT4 that still runs today. Linux and macos can't get near that.

skywal_l 3y ago
Assuming you are talking about OS kernel API, what if you static link your libc? My understanding is that the linux kernel API famously does not change [0]. [0] https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75
- PlutoIsAPlanet 3y ago
  Windows has a stable userland API/ABI, Microsoft go above and beyond for backwards compatibility. Linux does not have a stable userland ABI/API, it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user. The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps). Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...)
  - Arnavion 3y ago
    >Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged https://stackoverflow.com/questions/57476533/why-is-statical...) Your link is about glibc, not libc in general. For example musl is perfectly fine to link statically to.
  - stingraycharles 3y ago
    Static linking libc is very iffy indeed, it’s much better to just use a very old libc and dynamically link against that. Python’s “manylinux” binary target is a good example on how to do that. We’re currently targeting “manylinux2014”, which is a decent middle ground.
  - skywal_l 3y ago
    > Linux does not have a stable userland ABI/API I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace". > it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user. But that would be the same thing on windows. If you dynamically link your executable to an old version of libcurl and run your executable on a windows with a newer version containing a breaking change, you'll be in trouble, whatever your OS. > The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps). Flatpak and Docker solves many other problems than kernel API. Actually, it does not solve this problem at all if you think about it because these technologies do not insulate you from the kernel (contrary to a VM). > Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statical https://stackoverflow.com/questions/57476533/why-is-statical...) Statically linking glibc. You can perfectly statically link with any other libc. You can even code without a libc (see zig).
    - Snetry 3y ago
      > I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace". I think you interpreted Linus wrong. When he says "we do not break userspace" he is talking about the Kernel APIs that are exposed to the Userland. Userland APIs would be stuff like glibc, which has a terrible track record in regards to API breakage.
      - skywal_l 3y ago
        The statement "Linux does not have a stable userland ABI/API" is about the kernel. If you are talking about glibc you are already in the Linux OS/GNU Linux (whatever it is called) domain. I think I correctly interpreted Linus when he talked about the kernel API/ABI facing the user (developer of application). A lot of trouble you are going to get maintaining builds are due to poor tooling, not linux. But we are getting into semantics here. At the end of the day, I think that if you are careful with what you are doing and think a little before choosing your tools and writing code, you should get very good mileage out of your linux binaries. I don't know enough about windows to comment on its stability but I very much doubt I could just slide my original Quake CD or 3DS max 4 install into Windows 10. But I might be wrong!
  - the8472 3y ago
    On the other hand, old software often runs better (or at all) on dosbox or wine than on windows.
- baz00 3y ago
  Linus does really well with the kernel ABI and API but the problem is really with literally everything else. It's usually impossible to get something to even compile that's more than a few years old let alone run an old binary.
- kukkamario 3y ago
  Linux kernel API itself isn't really enough to do eg. any UI software, because things like creating windows or showing notifications, are not part of it directly. You need additional software on top of that for those features. Win32 API is much larger than Linux kernel API and is stable so there is quite large chance that a couple decades old software still works without recompiling or updating libraries. It has its issues with many parts of it being completely horrifying to use, but the stability is something that Microsoft has done well.
- Arnavion 3y ago
  All this talk about what is or isn't stable ABI on Linux is irrelevant to the article anyway. The article's author explicitly doesn't want their 15-year LTS to ever update its OS or libraries. So ABI stability is not a concern.
Dalewyn 3y ago
10 years of support is standard on Windows, and they might be longer depending on the situation (see: Windows XP) or if you're enterprise and pay up (see: Windows 7). And then there's what you allude to: A stable Windows environment that will, in most cases, run ancient code mostly fine assuming they were written to specs of the time or it's a very important piece of code (eg: Simcity).
EddyTests 3y ago
If it’s medical devices I assume they want RTOS? Windows wouldn’t work for that world
- troupo 3y ago
  Depends on the device. A lot of medical equipment still runs on Windows versions from the beginning of the century.
- baz00 3y ago
  Depends. Most of the stuff would have an RTOS in the hardware interface and a windows GUI.
- kreetx 3y ago
  Depends on the device but plenty of old Windows machines (XPs) run in hospitals. edit: Hah, good work, siblings!
  - EddyTests 3y ago
    Sure, but I assumed they meant pacemakers rather than desktop apps to manage appointments etc!
    - kreetx 3y ago
      Most of the article is about desktop machines..
    - tmottabr 3y ago
      i guess neither.. this is probably machines that handle special hardware.. like MRI, ECG, or monitor for vitals like pulse, blood pressure, blood oxygenation or other stuff like that.. Those machines need to be certified as a whole package and this include the computer that will control it.. and once you certify you cannot make changes to the package without having to certify again.. So you certify the machine with that software on it.. that specific kernel version, that specific libc version and so on.. if you change anything you need to get a new certification.. and now those machines are no longer air gapped because hospitals want to be able to remote monitor the patients vitals from a central nurse station..
crabbone 3y ago
That's because you are lucky, not because it's designed to be that way. Windows has very variable support timeline for its releases, and, going forward, Microsoft only looking to cut down on support times, not increase them. So, even if it worked for you during NT era, it's not going to work for people writing for Windows 10 or whatever the present day version is. Not to mention that Windows is just not a player in many major computer markets, so not even an option for someone who eg. wants to provide storage solutions or HPC and many others.

ynik 3y ago

These days, you're lucky if you get 5 years. Worst offender I have to deal with is "Jenkins LTS", which is supported for only 12 weeks.

baz00 3y ago
It takes longer than 12 weeks to start the Jenkins server!

msh 3y ago

The article is full of shit, the author wants free LTS support for 15 years so he can more easily make money... The quote is: Those of us creating medical devices, software for factory lines, and systems that matter need a minimum of 15 years for an LTS especially if you have it in your fool head we should pay money for it. Over that course of time you cannot drop our operating system just because you want to. If his company wants 15 years of LTS support for their products they should find someway of paying for it....

highwaylights 3y ago
Absolutely this - expecting free support for no reason is a ridiculous notion to build your own business on. Even then, I think 15 years of support for a Linux distribution is a bad idea anyway - software just moves way faster than that. How supported is that release really going to be after 14 years, even with the best of effort? Is every upstream package going to be version compatible with a 15 year old release with no breaking changes? And if it's not, and you patch around that or freeze those packages, is your software still "supported"? What if there are unpatched critical issues? Is that a better idea than keeping up-to-date with a rolling 24/36/48 month release cycle? In the analogy of a roof or a basic appliance that's fine, but the long-term support equivalent of that is have a copy of the software on a couple of USB drives and disconnect the machine from the internet completely. As long as you don't do anything novel with it, it'll probably work for decades. There are still Windows 3.1 terminals in the wild somewhere.
- rightbyte 3y ago
  > software just moves way faster than that Which is the problem if you don't want to spend your days troubleshooting BS problems. Much of the movement is for no good reason at all.
  - BadBadJellyBean 3y ago
    There is a very good reason. It is hard to split bugfixes from features. Sometimes it is even very hard to fix a bug without changing the behaviour. It is unreasonable to expect everyone to backport their fixes to all old versions.

jb1991 3y ago

Since it’s not actually mentioned in the article and I found myself quite confused, “LTS“ means “long-term support“. A pet peeve of mine is when bloggers write articles without defining in a single simple parenthetical what the acronyms are.

ptico 3y ago

“We produce an extremely expensive hardware and bill millions for consulting and support but don’t want to spend a single dollar to update a firmware, so now, dear OSS developer, it’s your responsibility to keep my solutions functional for the half of your career years” Did I read this correctly?

crabbone 3y ago
> Did I read this correctly? No. Firmware upgrade is a risk that has no mitigations for certain kinds of systems. No amount of money will solve this problem. No sum of money will convince a sensible patient to upgrade firmware on their pacemaker or anything like that. But even for less critical systems -- what's the problem with wanting to pay less? This is like one of the primary economical drivers... You also for some reason think that software upgrades are some sort of a natural phenomena which others have to adjust to, and it just happens on predictable interval, and if you miss your cycle you have to pay. Which is obviously ridiculous. A result of industry conditioning you to expect this to work a certain way, w/o questioning the reason for it to work this way. What should drive software upgrades is in the large part the longevity of hardware. The author claims that the longevity of hardware has improved, even though industry didn't particularly invest into it. It's upsetting to have to generate a lot of e-waste just because we (as an industry) set our sights on a particular release schedule designed to maximize profits for those who provide releases and minimize them for those who consume them.
- ptico 3y ago
  It’s not about pacemakers at all here for the same exact reason you described: if you’re not able to update firmware, you’re able to update underlying OS as well The problem here is when you sell LTS solutions for $10M thinking you can pay $1000 for keeping your solution afloat for two decades. It doesn’t work this way. Operation systems as well as frameworks and runtimes, are constantly changing, because the industry is constantly moving forward. The only way to keep up is to constantly (and regularly) update YOUR software too (and plan the budgets accordingly). It’s your responsibility to fulfil your obligation. After all, you can still run an up to date Linux (or better NetBSD) on a very old hardware, the problem is that you didn’t update your software regularly to just keep up with changing API/ABI, means didn’t invested too much on a longevity of your product

andrelaszlo 3y ago

"Brew-ha-ha"? This must be an eggcorn! https://en.m.wiktionary.org/wiki/eggcorn https://en.m.wiktionary.org/wiki/eggcorn

mavhc 3y ago

Pre internet you would do the same thing with your computer every day for 15 years and then buy a new one, you could load the same version of MS Word 15 years later no problem. But when you're dealing with the rest of the world, a) you need to keep up, people send you Word n+15 compatible files, b) you want to access new websites, and c) you don't want to get hacked. If you want to run your offline computer for 15 years, that still works today

Dalewyn 3y ago
I use Office XP just fine to open documents sent to me that were made in Microsoft 365 or whatever Office is called these days. Yes, I greatly respect Microsoft's attitude towards compatibility.

aaron695 3y ago

[dead]

fragmede 3y ago

Red Hat will sell you support contracts for up to 10, more if you pay them enough and promise not to talk about it. That Ubuntu isn't as business focused as Red Hat is... Well, there's a reason Red Hat is a billion dollar company and Ubuntu isn't. Not that there's anything wrong with that.

Dalewyn 3y ago

Everyone commenting here how author wants 15 years support for free hasn't read the article. >Those of us creating medical devices, software for factory lines, and systems that matter need a minimum of 15 years for an LTS especially if you have it in your fool head we should pay money for it. Emphasis mine. Author is saying, rightfully, that "long term" support needs to be more than 5 years. Author is also saying, reasonably, that it should be at least 15 years if the developers in question want to be paid for support. Author is saying he will pay for long term support if that's what it takes, but not if it's any shorter than 15 years.

Arnavion 3y ago
They're implying they wanted to pay for 15 years support but found no takers. Is the problem that nobody wanted to support them for 15 years (their insinuation) or that they didn't pay enough? Given they keep talking about 5-year LTSes without bringing up any of the 10-year LTSes that do exist (Freexian, RHEL, etc), it seems clear to me that it's the latter. Also their requirement is nonsensical. They want support, ie bugfixes, which will require them to install updates. But at the same time they don't want a model that will update them to the latest supported version. Why do they care what the content of the update is? The point of the support contract is that they will be supported regardless. Also also, speaking as someone who works at a company supplying software to car manufacturers, we don't have 15-year LTS for our software either and the manufacturers don't have a problem with it. Their stacks are being designed around automatic updates, which again they had to be anyway to get bugfixes in general. Support contracts are support contracts. Whether an update changes v1.0.0 to v1.1.0 or v2.0.0 makes no difference to them. So what the author says about car manufacturers is also nonsense.

arianvanp 3y ago

I can run 30 year old programs on my x86_64 machine just fine. What the heck is the author talking about. X86 is one of the beacons of long term support. I upgrade computers every 10 years or so. And never had issues. Ever.

mduggles 3y ago

Backporting packages is a time-consuming process that actually requires skill. It is insane to expect people to do that for free on a volunteer basis because it makes your situation easier, especially as backporting gets harder the longer you go. RHEL offers 10 years, it costs money, that's your option. Or you pay for the staff to monitor and backport to your particular distro and foot the bill. It's also maddening to present the issue as "our time is expensive and your time is free". If your field is unable to commit any work at all to updates, fine. UBI Micro is as small as its gonna get and moves everything difficult to the host. That could conceivably run for 15 years if you are careful with how you build it.

mcv 3y ago

I need to read this article more carefully at another time, but it comes across as rather confused to me. > Some time near the end of the 1990s and beginning of the 2000s is when desktop/laptop computer quality began to improve. What does this mean? Computer quality has continuously improved since their inception. At different times on different axes, and sometimes some things got worse, but on the whole they've always improved. > Not one of those libraries has Internet. I can't figure out which libraries are referred to here. Tons of libraries have internet. The article also seems to be confusing hardware and software a lot. Lots of hardware is thrown away too easily because modern software often tends to assume it's run on modern hardware where it can waste resources. Software should be more frugal in its use of resources and if you do, there's no technical reason you can't have modern, secure software running on 15 year old hardware.

crabbone 3y ago
> Computer quality has continuously improved since their inception. Not really. For example the switch to LCD monitors from CRT was a step back in quality. LCD was just way cheaper and more convenient as in taking less space that regardless of worse quality it still took over. It took many years for the various aspects of image / video quality to catch up. There are plenty of similar examples where price decrease was what driving the industry rather than quality. In general, shrinking form-factor brought lots of drops in quality, because it's harder to make various electronic parts smaller and as durable. Opening markets to wider range of players (eg. "the PC revolution") is also bound to bring drops in quality as many inexperienced players will be seeking to enter the market and typically contest the lower bound of quality. It's only when the industry stabilizes on some standard and creates a group of experienced players who compete for the same niche is when it's possible for the quality to continuously increase. Did something like this happen in the 90s and 00s? -- I don't know. From software perspective, I think about those years as the time when the decline started to accelerate, and I see us still on the decline of software quality in general. But I don't know what the author is referring to.
- mcv 3y ago
  > LCD was just way cheaper and more convenient as in taking less space that regardless of worse quality it still took over. They were definitely not cheaper at first. But taking up less space is also a quality. You often get trade-offs like that. You often get things that are faster, but they produce more heat. Early SSDs were faster, but had less capacity than HDDs. It's still part of progress, and these technologies often exist side by side for a while before for a lot of people, the trade-off means they prefer the older tech, until the newer tech catches up on the attributes it was less good at. > In general, shrinking form-factor brought lots of drops in quality, because it's harder to make various electronic parts smaller and as durable. Again, different aspects of quality. The fact that computers now fit in your pocket instead of taking up an entire room is progress. It enables new ways to use them. Early laptops were not an attractive replacement for many desktop uses, but now they generally are. But still not quite for all (I just bought a new desktop PC).

BadBadJellyBean 3y ago

In this day and age it should be possible to not tightly integrate the computer into the device you are building. That way you can update the hardware and stay current with software. Building things with computers is just an ongoing investment into updates and staying current. Because the longer you push it away the harder it gets to update.

BiteCode_dev 3y ago

It's 5 years for free. You can have 15. You just have to pay for it.

kemotep 3y ago

The tone and quality of this article is atrocious. Let alone demanding that software developers (the very ones the author spends a chunk of the article belittling) work for free for 15 years. There is more nuance than upgrading everything 6 months/yearly versus being fine with still using Windows XP 20 years later. As an aside it feels not only blogs but news articles from places like the BBC and NPR have several glaring spelling and grammatical errors. The quality of writing either has gone down significantly the past few years or is it my standards of writing being higher now?

happymellon 3y ago

This piece seems very confusing. RedHat will sell you longer long term support if you want it, I believe they will do 15 years, Suse offer 13 years. What's the issue here? That you don't have to throw away a Mac that isn't connected to the internet, but they feel like they have to throw away a PC?

HeavyStorm 3y ago

The article is full of unjustified hatred for modern software practices. The author fails tô acknowledge the amount of failures of big projects and escalating costs, focusing only in the fact that today practices output less robust software.

crabbone 3y ago
Hatred for modern software practices is fully justified. Unfortunately we didn't have enough of historical evidence yet, nor did we have enough shifts in software development practices to tell if we had it much worse or much better before, but there are obvious shortcomings of what we do today compared to 20-30 years ago. The major shortcomings, the way I see them: 1. The overall software quality is on steady decrease since late 70's. This is, at least in part, due to more software being developed for less mission-critical systems and consequently by less qualified personnel. So, commercially, we don't need as much of higher-quality software as we did before. 2. Software industry is exceptional in the way it relies on multiple other players in the industry for individual production and as such is a lot more susceptible to trends and more influenced by majority than many others. I.e. of the majority of the industry decides they don't need long-term support, then the minority won't have it because the minority's survival is contingent on the policy and services (inadvertently) provided by the majority. 3. Software quality is exceptionally difficult to measure formally. This leads to big and small players, intentionally and unknowingly, mis-advertising and misunderstanding the quality of their own products. This makes it very hard to almost impossible to price your products or services based on quality. The realistic alternative to quality the companies are using is the ability of the product / service provider to support the customer in the case of failure. Which is a function of size of a company provider more than anything else. This leads to the situation where instead of focusing on understanding and improving software quality, companies develop reputation though marketing and customer support, which they later misrepresent as software quality. All the above is the result, at leas in the large part, of the modern software practices. We created the practices that emphasize speed of delivery over every other aspect of software because we don't know and don't want to figure out how to reliably increase any other metric. We created a lot of monopolies in software world by following the modern development practices which preach using commonly used third-party components, even of lower quality over bespoke alternatives. This is especially motivated by cost savings when it comes to human resources, which become more interchangeable (and cheaper in the short term for the employer) with this approach. Software monopolies stifle innovation and fix prices not only in the software field, but they also adversely affect the hardware field which has to adjust itself to the software practices. We could be doing better if we understand the shortcomings of our current process -- these aren't the necessary consequences of making software, but in order to effect a change initial good will is needed from multiple players, which is hard to accomplish w/o these multiple players, at least, first acknowledging the problems.

crabbone 3y ago

ITT: surprisingly many people think that software grows on trees and is harvested twice a year to get new versions of it. And that if you miss your harvesting cycle you might as well close your software farm and just kill over and die. The way I see it, the primary motivation for software longevity should be the hardware longevity. Ideally, software needs to outlive the hardware rather than the other way around. But we came to expect ridiculously short version iterations because this process was a major profit driver for software companies. If modern hardware happens to be more reliable than what was the norm 20-30 years ago, then, naturally, we should want the software to adjust to service the modern hardware. And if this doesn't happen -- it's a problem. In this instance, it seems to be an indication of companies big and small trying to sell worse quality software than what was reasonably possible while duping the audience into believing that the quality is still good. Well, of course it is upsetting! Why would you even think otherwise?

hnbear 3y ago

I got this far, wondering if this was satire or not, then realized they just have no concept of the world at large: > America, some of the EU, England, and some others are considered “First World” countries Some others? Canada? England isn’t a country. UK is the state, yes, there’s weird terminology, but even as a Brit we don’t class England as a country. I love the implication Wales, Scotland and NI are not first world. Some of the EU? There’s so much missing here it’s crazy. Yes, the article has many many flaws, that was my personal limit. Besides, when I’m half way through and still can’t tell if it’s a joke or not, I think that’s a red flag.