5 ms·

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 dev

• 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.
      • rightbyte 3y ago
        Ye if the code diverge much, ye. Depends on how mature the project is or how well thought out dependencies it has.
    • petree 3y ago
      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.
      • rightbyte 3y ago
        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.
        • highwaylights 3y ago
          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.
        • petree 3y ago
          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.
  • troupo 3y ago
    > 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?
    • beagle3 3y ago
      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)
• petree 3y ago
  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.
  • crabbone 3y ago
    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.
    • msh 3y ago
      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.
• deleted 3y ago
  [deleted]
• riedel 3y ago
  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.
• crabbone 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 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.
  • deleted 3y ago
    [deleted]
  • msh 3y ago
• fmajid 3y ago
  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.