Hacker News Reader

Comment by msh | Hacker News Reader

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

View on HN

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.

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

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.

Ye if the code diverge much, ye. Depends on how mature the project is or how well thought out dependencies it has.

There is a very good reason: the maintainers want to make the change. They don't even need a good technical need to do it, but usually there is at least something that drives the change.

Maintainers wanting to make a change in itself is not a good reason for the users.

There seem to be this sentiment that maintainers owe the users nothing, but also the opposite is true.

There is no reason to give the maintainer some special status concerning "his" code.

That.. doesn’t make sense?

It’s something the maintainer made and licensed in such a way that you can use it for free. The special status concerning “his” code is that it generally is in fact “his” (or her) property.

If you don’t like it you’re free in most cases to fork it and suit yourself.

Either way, it still doesn’t change the fact that there are going to be upstream bugs and vulnerabilities that remain unpatched if you’re trying to keep something frozen for 15 years.

An open source maintainer is a person volunteering their time and resources to offer something usually free of charge. As such, they decide what usecases they want to support and for how long. You can't expect someone to do work for free to support you.

> Even then, I think 15 years of support for a Linux distribution is a bad idea anyway - software just moves way faster than that.

Have you asked yourself why this is the case and why it should be the default accepted case?

> Is that a better idea than keeping up-to-date with a rolling 24/36/48 month release cycle?

There are plenty of devices out there that exist for longer than 2 or 4 years. And those "rolling upgrades", how are you going to deal with "we're dropping 32-bit support"? Or "we're dropping support for CPUs that don't support certain features". Or a hundred other deprecations and the inevitable increase in bloat of software?

If it’s a device/setup that is self contained, and not exposed to e.g. the internet, then …. It’s already 32 years LTS! Just use it.

Ah, but occasionally you do need something new. Well, in most cases, the LTS support won’t help you - because they just fix bugs, but do not e.g. provide TLS 1.3 to replace the aging OpenSSL 0.96 which barely supports SSLv2.

Additionally, do you have LTS hardware replacement for 15 year old hardware running Linux? Iirc Dell, HP and friends only provide a 5 yr guarantee - and that guarantee is “we’ll give you a new machine if we don’t have replacement parts” which you also have with Linux (just install the latest)

Either pay someone to maintain it for as long as you need or engineer around whatever issues you encounter; it's a you problem, and possibly the development process or software stack you are using is not flexible or robust enough to support your own usecase. Unless you specifically pay for how many years of support you need, then you don't get to decide the terms of whatever support is offered for free.

This is a stupid advice.

In software industry we rely on the community to carry the large share of our "expenses". A company that manufactures medical equipment, let's say, pulseox, would normally need well... maybe five engineers working on the project. If suddenly, they also need to maintain a Linux distribution used for their device, they'd need like fifty. This would make pulsox prohibitively expensive and the company would go out of business. Only companies who'd be able to manufacture pulseox would be the companies who are already doing Linux maintainer work internally. Which would eventually lead to a monopoly, and the prices would still shoot through the roof.

But it doesn't have to be this way. If we collectively understand that there's a problem with the absence of real long-term-support releases, then many smaller companies can survive and produce cheap equipment.

Finally, there's no "natural" rate at which software needs to upgrade. There's no reason it shouldn't upgrade slower or faster. The claim the author makes is that hardware used to fall apart in about five years, and that could've been used to justify the short-term support it was getting from software... about 20-30 years ago. But things changed, and we learned how to make hardware that easily lasts 15 years and now we need to re-think how we are dealing with this fact.

I dont think its stupid advice to ask people to choose their tools based on their needs.

If you need 15 year support you choose software that will provide that and not something that does not promise that.

Just as if you are building a house in greenland you would choose different building styles and material compared to building a house in california. His complaints seem more like building a cheap california house in greenland and then complaining that its a bad house.

I just described why it's stupid. You ignored what I wrote and decided to write something unrelated... why even bother at this point?

Society or companies are paying in many cases for LTS <<15 yrs. So at least there should be a price tag to compare the options.

If I buy a car (which is a lot of software these days), I expect something like 20 yes LTS. So it is simple as that software support needs to be tied to reasonable hardware lifetime otherwise it is planned obsolecence (at least if you cannot run it air gapped). 5yrs is reasonable for servers, phones or toys I guess. But particularly many embedded systems that worst case have been certified need longer support (medical, automation, transport, ...). Maybe better circular economies for HW would be a better way out in the future. Maybe we could even safe resources if e.g. energy expensive computing parts of HW could be replaced. The problem is current certification proceedures ansld related costs I guess.

The cost of maintaining old versions is constant, spread over an ever-dwindling customer base which is why the price grows exorbitant. That said, Bull still maintains the GECOS mainframe OS that was already obsolete when it gave UNIX the pw_gecos field in the 70s, but you have to pay for it.

> The article is full of shit, the author wants free LTS support for 15 years so he can more easily make money...

The article doesn't say that. It says that proclaimed LTS releases aren't such. The article says that all we have is short-term-releases, it doesn't go into details on how much we should pay for the lengths of support of release at all.

I don't see why is this a problem to want to make more money, the easier the better, imo. The author never claimed that they aren't willing to pay for any services though, so you are putting words in their mouth. But, let's for the moment say they wanted to pay for real LTS releases instead of what we have today -- they need to convince many people to share the brunt of doing so, otherwise it's going to be very expensive for them. Their disappointment comes from the perception that a lot of those who would potentially benefit from sharing this expense with them don't do that by following short-term gains and disregarding long-term losses.

---

From my personal experience: we dig ourselves a hole with creating short release cycles. We ended up in a situation where every new iteration of software we release is of despicable quality and there's no hope of improving the quality because the next release is already on the horizon and most and best resources are dedicated to it. Releasing often is seen as a primary driver of profits. This acts to demotivate and devalue QA teams, who, in the present day are seen more and more as a waste of resource and are even sometimes repurposed to do things unrelated to QA, s.a. release management or even customer support. And, I think, this is what the author talks about when they talk about how agile is a bad thing.

The ultimate claim the author makes is that we don't really need short release cycles. Not the individual users neither the companies no matter how big. We'd benefit from higher quality software released less often. We don't need to pay extra for longer term support as you put it. What you perceive as longer term should be the norm. We chose the wrong driver for companies profits -- selling new versions works, but leaves customers more and more dissatisfied with the results. Perhaps, we should think about a different way to pay for programmers' work? Perhaps instead of version upgrades we need to sell maintenance? -- I don't know, and am not enough in the know of how the profit is made in this instance and where it's possible to take it.

I think his comments like "if you have it in your fool head we should pay money for it" says that he expects it for free.

I also think if the products he produces need 15 year support he should choose operating systems that provide that, for example QNX comes close. Instead he chooses to complain about a OS that have never ever promised anything like this and that he can get for free.

This has been shown to be bullshit times and again, but people keep repeating this as if it was a valid argument -- why do you think author or anyone else has a choice of an operating system they can install? Based on LTS policy? Really? On what planet do you live?

We don't live in a world with infinite supply of interchangeable operating systems that only differ in one interesting characteristic. For most software products out there there either isn't a choice at all, or the choice is between bad and worse.

But this isn't even the point. Someone, well, a group of people, made a decision about how long the support for the system should be. OP believes they were wrong. Telling them to try a different system solves nothing, even if that worked for them. The conflict is still there: someone made a bad decision, even if OP no longer actually needs to rely on their decision, it's still bad.

Reply on news.ycombinator.com