[HN Gopher] Ubuntu 14.04 and 16.04 lifecycle extended to ten years
___________________________________________________________________
Ubuntu 14.04 and 16.04 lifecycle extended to ten years
Author : input_sh
Score : 159 points
Date : 2021-09-21 15:21 UTC (7 hours ago)
(HTM) web link (ubuntu.com)
(TXT) w3m dump (ubuntu.com)
| superflit2 wrote:
| Thanks
|
| I got the gist that "We cannot support old SW for so long" but
| that action makes things more manageable to upgrade.
|
| I have several SWs that are hard-depended on the OS version.
| theandrewbailey wrote:
| I like Ubuntu's LTS releases, and prefer upgrading from/to each
| one. For some reason I skipped 18.04 though.
| awill wrote:
| I'm not an Ubuntu user (CentOS 7 on my server, will probably move
| to Rocky 9 when that releases), but it's easy to see why Ubuntu
| has been successful.
|
| RHEL has 10y support, but historically has released their OS
| every 4-5 years, which is far too long. Imagine you're releasing
| a new product 4 years after the last RHEL. If you're doing
| anything with an area that has a lot of kernel/OS innovation,
| you're miles behind.
|
| With Debian, I believe it's confusing what their extended support
| is. They don't guarantee more than 3 years, but usually extend it
| later. That makes sense for Debian, but not for businesses that
| need to decide on an OS for their project.
|
| Then comes Ubuntu. Totally free without having to resort to third
| party rebuilds (like Rocky) with 5 years of support. And you can
| pay for 10y support. It's not surprising Ubuntu is way ahead of
| RHEL on public clouds. Red Hat should be doing more to target the
| startup scene. Those are the enterprises of the future.
| ikiris wrote:
| Red hat set their user base on fire with their centos debacle
| whether they admit it or not.
| thedracle wrote:
| The original debacle was splitting off their non enterprise
| users to Fedora.
|
| It set me on the path of experimenting with Gentoo, Debian,
| and Ubuntu.
|
| Redhat has some excellent engineers, and I have made heavy
| use in the past of eCos in particular for embedded systems
| --- I've never understood why they continue to make grand
| decisions that alienate their customers.
| petre wrote:
| You should really try openSuSE if you were using CentOS.
| Only 18 months of support but it's quite good. We are using
| that and Debian, and Ubuntu 18 on the dev machines but will
| also switch those to Debian, since Ubuntu 20 is quite
| annoying with snaps, cloud config and all that crap.
| da_chicken wrote:
| Look, IBM has to start navigating that product into a
| mountainside at some point. It's always best to start with
| user goodwill so the knowledgeable individuals start bailing
| out. They have to get the number of experts down to a level
| where IBM has most of them under contract to their customers.
| That way in 20 years they can cease _real_ support and
| development while still getting millions in annual revenue.
| hughrr wrote:
| This is sickeningly accurate and hurt to read.
| rleigh wrote:
| I personally ended all my projects' support for RHEL and
| CentOS a few weeks after that went down. They were already a
| massive pain in the ass to support, and had a smaller
| userbase than other Linux distributions (<10% for RHEL and
| CentOS combined is typical). For me, that was the straw that
| broke the proverbial camel's back.
|
| I don't really think that IBM/RedHat really saw CentOS as a
| gateway to RHEL, but as a source of lost sales. I think
| CentOS had great indirect value to them. It let people like
| me create, test and support software on RHEL without having
| RHEL licences. I neither want nor need them, nor could I
| justify them in the absence of paying customers to underwrite
| the cost. CentOS gets used for test environments, home use,
| self-supporting commercial use etc. I don't think many of
| those would really result in conversions to paying RHEL
| subscriptions. But they do serve to introduce people to the
| RHEL ecosystem.
|
| Maybe the strategy makes commercial sense. I don't know, or
| particularly care. But as an exercise in destroying a
| community which provided the extended support and software
| ecosystem around your core product, I think that was a
| strategic blunder. There are an awful lot of people who now
| won't be recommending RHEL to their customers, and the
| willingness of third-parties to test and support their
| software on RHEL has taken a hit, and that in turn reduces
| the value of using RHEL.
| throwawayboise wrote:
| Where I work we had an enterprise RHEL license but it got
| too expensive. So I converted all our systems to CentOS.
| Then CentOS went away, not doing it again. We're moving to
| Ubuntu.
| sjtindell wrote:
| In my opinion Ubuntu's success also has a lot to do with ease
| of usage. Getting into Docker, Kubernetes, etc. years ago it
| was very clear that development for the whole cloud native
| ecosystem was happening on Ubuntu just from how easy it was to
| "apt-get install" everything. I think that focus for
| development created a smoother user experience that led to
| enterprise usage as well. Both were solid, both had the tools
| supported, but one required a little less setup sometimes.
| dan_quixote wrote:
| So, lack of SELinux and the like?
| jmnicolas wrote:
| I'm still salty about the Centos 8 debacle, this increased my
| work load a lot. Will never touch anything Red Hat again.
| 0x000000001 wrote:
| Terrible news. This will hold back progress like usual. We need
| shorter release cycles with less risky upgrade paths, not this
| nonsense.
| ghshephard wrote:
| Good lord no - if I can run my current laptop for 10 years on
| 20.04 - I'll be more than happy to do so. I want innovation in
| my own code, my applications, browsers - not my Operating
| System/BIOS/UEFI/etc...
|
| Save the new operating systems for new hardware, bus standards,
| innovative GUIs, etc... Let me just keep pounding away
| 12-hours/day without a hiccup on my current gear.
| Arnavion wrote:
| >I want innovation in my own code, my applications, browsers
| - not my Operating System/BIOS/UEFI/etc...
|
| So either your applications and browsers come from the
| distro's package repo, in which case when their upstreams
| update to newer versions that require newer dependencies your
| distro doesn't have, your distro will be stuck on older
| versions lacking the innovation you seek.
|
| Or you use flatpaks or snaps, which don't have that problem
| because the flatpak / snap bundles the newer libraries, but
| then the stability of the OS doesn't help you. And you're
| still stuck with an old flatpak / snap daemon that could
| cause problems with new flatpaks / snaps, and with an old
| kernel that could be missing syscalls that the newer libc's
| inside the flatpaks / snaps require. Eg I remember
| discovering that 16.04 and earlier don't have the getrandom
| syscall, which made it impossible to run a newer OS's Docker
| container since its libc expected it.
|
| To be clear, I'm all for people wanting to remain on
| supported OSes for a decade. I'm just pointing out that
| expecting "innovation" is incompatible with that.
| The_Colonel wrote:
| > I'm just pointing out that expecting "innovation" is
| incompatible with that.
|
| No, it's not. There's a huge difference between "let me
| update these 2 apps which I care about" and having to
| upgrade the whole system to get those 2 new updated apps.
| Arnavion wrote:
| Perhaps you should read the two preceding paragraphs to
| see the problem with that expectation instead of assuming
| the third paragraph was written in isolation.
| The_Colonel wrote:
| Of course I read them. But the very special case of
| docker and some hypothetical problems don't invalidate
| the concept.
| MeinBlutIstBlau wrote:
| The majority of commercial enterprise doesn't upgrade on a
| whim. My company was still using Windows 7 this year.
| amalantony06 wrote:
| Doesn't Debian do exactly what you've said?
| JshWright wrote:
| This way Canonical can keep charging for ESM contracts... Gotta
| get that sweet legacy maintenance revenue.
| ch_123 wrote:
| This way, Canonical gets paid by the people who want to stay on
| old versions - meaning more investment in new versions. I
| strongly suspect that this long-term support costs the customer
| a lot more than it costs Canonical to support the old versions
| cies wrote:
| > We need shorter release cycles with less risky upgrade paths
|
| Either you speak for yourself or you have no clue how a market
| works.
|
| Long term support i know to be paid for by enterprise: hence
| there IS demand.
| kyrofa wrote:
| You have options if you want something like that. Use a rolling
| release distribution like Arch. For commercial use, this ESM
| model is spot on.
| zamadatix wrote:
| Companies on extended support releases of versions distros want
| a specific version of packages with security patches for a
| product lifecycle not an increased frequency of OS changes.
| moralestapia wrote:
| Sorry to break it to you, but plenty of people prefer stability
| over novelty.
| awill wrote:
| I think it's a little more nuanced than that.
|
| If I'm building something new, I generally want a new
| kernel/OS underneath. Especially if what I'm building can
| take advantage of it (improvements to filesystems, networking
| stack etc..).
|
| After I've launched my service, I want stability over
| everything else. So here, I'd launch on the newest Ubuntu
| available, and stick with it for quite a long time.
| moralestapia wrote:
| >I generally want a new kernel/OS underneath
|
| Huh? That's weird, Linux, OSX and Windows kernels have been
| battle-tested and hardened for like 30 years or so now. I
| can't imagine what kind of application would _need_ a
| different kernel to start with.
|
| Aside from security concerns (which you didn't mention,
| plus one could argue an LTS is safer), could you give a
| specific example of:
|
| >what I'm building can take advantage of it (improvements
| to filesystems, networking stack etc..)
| sbuttgereit wrote:
| I read those comments as assuming new versions of those
| battle tested lineages... not newly created kernels or
| OSes. The last statement seems to make that intent clear.
| moralestapia wrote:
| I read those comments as "OP doesn't even know the
| difference between a kernel and a distro".
|
| The whole statement seems to nake that premise clear :^)
| orf wrote:
| io_uring is one example, among many.
| moralestapia wrote:
| https://news.ycombinator.com/item?id=26745275
|
| Is it really worth it to jump into a completely new
| feature to get marginal improvements on the most basic
| stuff (io, networking, etc...), all of this, in exchange
| of working with unstable APIs and unproven security
| vectors?
|
| My answer is no but I can picture people who would say
| yes. I guess it's a matter of personal preference (plus I
| work on stuff that has to be reliable, above everything
| else).
| orf wrote:
| It depends on what you're building?
| jklinger410 wrote:
| Novelty? Fixes roll out constantly with new software. Wanting
| the latest best-working software for desktop is not novel.
| marssaxman wrote:
| If fixes were all that rolled out, I'd be happier about new
| software. Since the fixes invariably come bunded up with a
| lot of other changes I neither need nor want, it's rarely
| clear that the "latest" software is the "best-working".
| dleslie wrote:
| On the Linux Desktop, we'd have shorter release cycles with
| less risky upgrade paths if it weren't for the belligerence of
| the Gnome development team.
| stusmall wrote:
| You have the option to do that. Keep up on the most recent
| Ubuntu. It's easier and saves you money and pain in the long
| run. Hopefully whatever train wrecks of organizations that need
| 14.04 are paying enough in support contract to help subsidize
| Canonical for the rest of us.
| Zababa wrote:
| > We need shorter release cycles with less risky upgrade paths,
| not this nonsense.
|
| Why do "we" need shorter release cycles?
| tomc1985 wrote:
| Dear god no. If upgrade cycles slow down to like 3x what they
| are I'd be quite happy
| handrous wrote:
| What progress is it holding back?
| janmayan wrote:
| Nice one!
| salamander014 wrote:
| Generally speaking I agree we need to force the rest of the
| industry into a more ephemeral mindset for infrastructure.
|
| BUT this looks like it is only for ESM, which you need an Ubuntu
| Advantage subscription for.
|
| If that's the case, then this makes sense. Let Canonical make
| some more money off those who are willing to pay, big enterprises
| are slow to do anything.
| bluGill wrote:
| My company still has machines we made in 1950 that customers
| use in their business. They buy replacement parts from us.
| While we would love if each of those customers spent half a
| million dollars every few years to replace those old machines,
| we can't force them to do that. We can make some money from
| replacement parts though, so long as we are willing to set out
| sights low enough. Things that old are mostly mechanical so it
| is easy for someone to learn how to support them, and it saves
| the customers a lot of money. In the end we are proud that
| things we made 70 years ago are still being used in the real
| world for their original purpose.
|
| You should learn the same: take pride in the fact that things
| you wrote years ago are still useful. Part of that means write
| good code so that it is easy to fix any newly discovered hack,
| without having to update everything else to the latest.
| klelatti wrote:
| This is very interesting - and bravo for making something
| that lasts so long. Can you share anything more about what
| those machines do and why they are so durable?
| throwawayboise wrote:
| In general most older machinery was designed to be
| repairable. Often using industry standard sizes for things
| such as motors, bearings, relays, screws, etc. As long as
| you can get (or make) the parts and are willing to maintain
| the equipment, you can keep using it.
| klelatti wrote:
| Indeed. It's often the case too that it becomes outdated
| - more modern designs are more efficient etc. I'm
| probably more intrigued / surprised that it's
| economically effective to keep a seventy year old machine
| working.
| salamander014 wrote:
| Using physical hardware for as long as possible is absolutely
| the right mindset. For cost, reliability, environmental
| reasons, and many more.
|
| This post was about an operating system (Software).
|
| People shouldn't be using code that is no longer supported
| (support it yourself or don't use it, it's dangerous).
|
| And people should be rebuilding their infrastructure from
| scratch as often as possible. That's the only way to prove
| you've built something reliable, auditable, and correct.
|
| VMs and containers make that very easy and achievable for
| even the smallest of teams.
|
| Linux goes to great lengths to support lots of different (and
| old) hardware. Linus has said many times, if you maintain it,
| it can stay.
| dnautics wrote:
| Maybe moving forward that's true as efficiency hits limits,
| but you really shouldn't use old hardware if the new
| hardware so outstrips it's efficiency that switching to the
| new hardware amortizes the cost of the new hardware plus
| the cost to decommission the old hardware
| johannes1234321 wrote:
| The issue with software is that software is still in its
| infancy and we have a hard time to build software, which is
| "nice" to use and will work in 10 years time. This becomes
| especially worse with modern stuff connected to a network,
| where security plays a major role. And it is bad with Web
| stuff, where compatibility with "advanced" features can be a
| problem with future clients.
| bluGill wrote:
| Very true. It is something we as an industry need to learn.
| bityard wrote:
| > we need to force the rest of the industry
|
| Or we could, you know, not force anything and just work
| together to solve problems instead.
|
| Different industries, environments, and individuals all have
| vastly different requirements and _your particular_ mindset and
| methods do not fit all use cases.
| salamander014 wrote:
| In what use case is non-ephemeral IT infrastructure
| necessary?
| gberger wrote:
| Embedded systems
| 0xffff2 wrote:
| Spacecraft come to mind. Missions take a long time to come
| to fruition and there are already enough variables to
| consider. Fixing the mission control computer configuration
| as far in advance as possible removes one more variable
| from the equation.
| salamander014 wrote:
| That entire industry _needs_ a level of reliability
| several orders of magnitude more than any other industry.
| They couldn 't redeploy servers even if they wanted to.
| I'm by no means an expert Space Systems Engineer. But any
| NASA technicians reading my original comment would
| probably agree with me in the general case. Space stuff
| certainly does not fall under the general case, because
| it's not possible.
| 0xffff2 wrote:
| Hi, spacecraft flight software engineer here. If I agreed
| I wouldn't have commented. It's not that we need several
| orders of magnitude more reliability than any other
| industry, it's that for some reason most other industries
| have decided to accept several orders of magnitude less
| reliability than they need. The day-to-day pain of
| dealing with a constant barrage of bugs that never get
| fixed and forced updates that introduce new bugs on top
| of the old ones makes me consider just giving up on
| technology and living in a cabin in the woods semi-
| seriously on at least a monthly basis.
| [deleted]
| input_sh wrote:
| Ubuntu Advantage is also free for personal use (for a few
| devices), so you can take advantage of that if you're not a
| business and are too lazy to update every couple of years.
| superkuh wrote:
| I'm a home Ubuntu and Debian desktop user. I've been using
| the free Ubuntu 14.04 ESM support since LTS support dropped.
| I've been fairly happy with it.
|
| Using an old distro with it's old shared libs and old
| compilers is definitely not for the normal home user ubuntu
| demographic that wants things to work easily. But for
| curmedgeons that hate change and can deal with editing some
| cmake/etc and source header lines here and there it's
| liberating. I'd like to use Debian more but 5 years just
| isn't enough.
| darkwater wrote:
| May I ask for your line of reasoning here? I always thought
| people don't want to update to avoid doing the extra work,
| but if you go down manual patching and compiling a software
| to make it work with an older OS version, that doesn't look
| like saving time, at least at first sight.
| bachmeier wrote:
| Wish I had known that earlier. I spent a bunch of time
| updating a non-critical server over the summer. I even
| debated shutting it down rather than updating.
| jstsch wrote:
| Wow, I didn't know that. Also, only 75 USD per virtual
| server. For some reason I had a much higher number in my
| head. Happy to pay this (and support the Ubuntu team) to keep
| some old boxes up for a couple more years.
| nottorp wrote:
| Yep, I had no idea until reading this announcement that it's
| free for 3 machines (or 50 if you're a "community member",
| whatever that is). I promptly registered and added my home
| server.
|
| If I had an Ubuntu desktop I'd pay for the first tier of
| Advantage since it's pretty cheap, but sadly their physical
| server pricing is too much for home use (225). Maybe they
| could make it 25 for the first server or two or offer a more
| crippled tier... dunno.
| cxr wrote:
| > we need to force the rest of the industry into a more
| ephemeral mindset
|
| What a despicable position. 5-10 year stability is something
| the tech industry should be aiming for, minimum--not trying to
| stamp it out as if someone who achieves it is doing something
| _wrong_.
|
| Consider the Dell Chromebook 13 (7310; Lulu). It blew me away
| last summer to realize that this 2015-era notebook which could
| be had for $200-300 was still the best option among everything
| else I evaluated in 2020. Five years to make progress in
| hardware and yet _every_ other option promised only to be a
| step backwards. (A phenomenon separately documented here:
| <https://drewdevault.com/2020/02/18/Fucking-laptops.html>)
| Manufacturers of course do offer systems today are offering
| systems with slightly better CPUs or more RAM, but invariably
| they demand compromising on the ergonomics of either the Lulu's
| MacBook-quality touchpad, the 67Wh battery that lasts 6-10
| hours, the form factor of its 13-inch matte screen and carbon
| fiber body, the silent fan, or on price--these are companies
| that expect you fork over at least $1000 _more_ than the
| putative value of the one already unpacked sitting on the desk
| --just to have a system that is worse!
|
| Against every signal saying that it would be a mistake, I
| actually swallowed my reservations about paying the price for a
| newer system. I was partially reassured by the support lead of
| one prominent Linux laptop vendor saying that they "promise"
| that I'd be happy with the purchase, and that it would be
| better than the Lulu. Sure enough, it gets here; the touchpad
| is dogshit, the fan is only able to modulate between "screaming
| loudly" and "screaming _very_ loudly ", and I'm left feeling a
| mixture of horrible dread/remorse while asking myself "is this
| a joke?" It got packed up and sent back and refunded, and I
| promptly turned around and spent 1/3 of the refund on a second
| refurbed Chromebook 13 and left the remaining 2/3 in my bank
| account.
|
| Aside from the goofy Chromebook keyboard layout, the only
| downside to these devices? It's that, despite being on par with
| Purism's flagship notebook at the time (that also sold with a
| 50+% higher price tag in comparison to this notebook's original
| retail price), Lulu went largely unnoticed by the community. So
| newer Ubuntu releases silently broke the graphics, which means
| upgrading to 18.04 and 20.04 is a non-option. In the midst of
| this, we get unqualified opinions in the comments here that
| implicate people who want to stick with 16.04 (because a system
| that boots is better than one that doesn't) as threatening to
| "hold back progress" (clearly we've got different definitions
| of progress) and others cluelessly pontificating that upgrading
| is "easier and saves you money and pain in the long run"
| (again, somehow we have a different ideas of how to measure
| which numbers are bigger than others).
| pacman2 wrote:
| "Dell Chromebook 13"
|
| I think there are enough Laptops that don't suck. And Ubuntu
| should basically run on most laptops. Fingerprint reader? I
| don't care.
|
| For the older ones, how about a DELL XPS 13? Or Thinkpad?
| lenovo carbon x1?
|
| You can get a decent latop for 200-800 USD. I love the DELLS
| XPS 13/14. But sometimes I get greedy and wish I had 16GB
| instead of 8GB.
| AdmiralAsshat wrote:
| Does that mean there will be another ten years of 32-bit support,
| or is that already out of 14.04 at this point?
| Blueskytech wrote:
| Just like everyone else seems to think, this is the monetization
| model I can get behind.
| marcodiego wrote:
| This is microsoft-like in terms of how long the system is
| supported. Hats off to Canonical.
|
| Also, there is a way to "cheat" if you have 16.04 on your desktop
| and still wants security updates:
| https://www.omgubuntu.co.uk/2021/09/ubuntu-16-04-security-up...
|
| Note that 16.04 is reasonably well supported on modern hardware
| because of hardware enablement updates and you can use modern
| software with snaps, appimages and flatpak.
| underscore_ku wrote:
| great!
___________________________________________________________________
(page generated 2021-09-21 23:01 UTC)