Slashdot Mirror
Mark Shuttleworth Reveals Ubuntu 18.04 Will Get a 10-Year Support Lifespan (zdnet.com)
At the OpenStack Summit in Berlin last week, Ubuntu Linux founder Mark Shuttleworth said in a keynote that Ubuntu 18.04 Long Term Support (LTS) support lifespan would be extended from five years to 10 years. "I'm delighted to announce that Ubuntu 18.04 will be supported for a full 10 years," said Shuttleworth, "In part because of the very long time horizons in some of industries like financial services and telecommunications but also from IoT where manufacturing lines for example are being deployed that will be in production for at least a decade." ZDNet reports: Ubuntu 18.04 released in April 2018. While the Ubuntu desktop gets most of the ink, most of Canonical's dollars comes from server and cloud customers. It's for these corporate users Canonical first extended Ubuntu 12.04 security support, then Ubuntu 14.04's support, and now, preemptively, Ubuntu 18.04. In an interview after the keynote, Shuttleworth said Ubuntu 16.04, which is scheduled to reach its end of life in April 2021, will also be given a longer support life span.
When it comes to OpenStack, Shuttleworth promised again to support versions of OpenStack dating back to 2014's IceHouse. Shuttleworth said, "What matters isn't day two, what matters is day 1,500." He also doubled-down on Canonical's promise to easily enable OpenStack customers to migrate from one version of OpenStack to another. Generally speaking, upgrading from one version of OpenStack is like a root canal: Long and painful but necessary. With Canonical OpenStack, you can step up all the way from the oldest supported version to the newest one with no more than a second of downtime.
When it comes to OpenStack, Shuttleworth promised again to support versions of OpenStack dating back to 2014's IceHouse. Shuttleworth said, "What matters isn't day two, what matters is day 1,500." He also doubled-down on Canonical's promise to easily enable OpenStack customers to migrate from one version of OpenStack to another. Generally speaking, upgrading from one version of OpenStack is like a root canal: Long and painful but necessary. With Canonical OpenStack, you can step up all the way from the oldest supported version to the newest one with no more than a second of downtime.
This should be a feel-good story, but... I already upgraded one of my Ubuntu machines past 18.04 and I'm mostly annoyed.
Here's a crazy idea: Why not ASK THE USERS how much support they are actually willing to pay for? As long as there are enough users who are willing to chip in to keep a particular version alive, then it can stay alive. When there are too few users, then it just has to die.
My vision of the "chip in" is on the order of 10 bucks, which isn't much, but you would get to multiply by the number of users. Some users might chip in more, but I think the basic "chip" should be small. Better to call each chip a "charity share", and the wannabe users would buy charity shares in the projects required to keep the software running.
For example, there would be an annual project for kernel support, and as long as there are enough donors paying to support the kernel, then it would be supported. For something so essential, you would want to fund the next year in advance, so as the end of the year approached, you would start encouraging the users to pledge charity shares for next year's support. If too few people are willing to support the required kernel, then you still have various options, but basically you start putting on the pressure to pledge or switch to another kernel or even another distro that still has enough support going.
But won't the free riders be a big problem? No. As long as the actual costs are covered, then who cares how many free riders there are? The whole point is to divide things into reasonable projects to make sure all of the costs are covered. I admit I'd recommend ignoring the free riders when it comes to making decisions, but it should always be open for the free riders to chip in and become financial contributors, eh?
Anyway, time's up for now, but the "charity share brokerage" bids you ADSAuPR, atAJG.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
...so that any IoT device makers that use it are required to provide updates to their devices for the same period?
This sig left unintentionally blank.
At first glance, Canonical is only matching the 10 years Microsoft used to promise for Windows, counting extended support. But if you look closer, Microsoft already is weaseling out of some edge cases (the latest Intel CPUs and AMD's Ryzen on Win7).
So I'd bet on Ubuntu 18.04 being a safer option than Windows 10 for a system you want to keep for a long time. Let alone that Ubuntu 18:04 was released almost three years after Windows 10. So even if both companies keep their 10 year promises, Ubuntu 18:04 is the better long term option from today's perspective :)
C - the footgun of programming languages
While I do not use Ubuntu (I use Debian sans systemd-crap), this is good news, as it sets standards for everybody else.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Is that your best idea for a constructive solution? Seems really thin, but maybe you want to flesh it out? However you provoked me into solidifying one of my additional suggestions a bit.
Devices or software that need security support should have a fail-safe mechanism. Such a device should know how to check whether or not it is still supported for its security updates, and when it cannot confirm the positive status, then it should be designed to fall back to an unsupported status with whatever limitations its security threats require. In the worst case for a potentially dangerous device, the device would ultimately fall back to the single-function state of only being able to check to see if its support has become available again. When it finally gets a green light, then it can update itself and go back to work.
People who want to use those devices would have to decide what they want to do. They might chip in together to pay for the support. Or maybe one of them is rich and desperate for the device and will pay for all the support required? The users of the device in question also have the option to switch to other devices or look for alternative solutions for whatever problems the device helped solve.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
As an alternative to he madness of Windows as a Servce. Improve virtualization/Wine and give people an exit fom reboot hell.
You realise one of the key reasons for adopting systemd was that distribution maintainers have LESS work to do right? Not having to manage a shitload of nasty scripts was one of its great selling points to the maintainers.
Plus within the next 5 years systemd will have included the entire userland including a web browser and an office suite and will all be delivered via a single package that auto-updates regardless of whether you've set your system to do so or not. The engineers will only have a single package they need to test and everyone will be happy as pie.
Oh and systemd-mail will include adverts unless you subscribe to systemd-cloudoffice.
This.
You used to be able to buy extended access to repo for $250. Then they stopped responding and blocked me from the repo. This is AFTER they had promised the service would be available to buy for 4 years at least.
After continuously trying to contact them I found out they now have a minimum spend, and if you are below it they don't want to know about you. and don't even bother responding to you. There sales team is on a commission where only the new volume deal count for anything.
Ubuntu eventually updated there website to reflect this, but like 8 months after they just snubbed everyone.
So if you had a small number of servers you had literally zero notice, just one day you are not gets any security patches and you have no option but to upgrade instantly. Now what you thought you had years to do you must do on a Sunday before your get hacked by latest CVE, or pull yourself off the internet.
Mean while red hat will happily sell you 1 server for $349 per year and give your years of notice before they pull the plug on anything.
Even if you are happy to pay for 5 years extra, I wouldn't trust them to even deliver on it.
Nope - my best idea for any IoT devices that require connection to a vendor server is to hit them repeatedly with a hammer.
What about this: any IoT device should refuse to contact the wide Internet unless it can periodically contact an user-configurable update server?
This would handle all major use cases: 1. no network, 2. local network only, 3. Internet at large; provide a reasonable default for the uneducated crowd while giving control to those who want it, and provide a configurable compromise between privacy and updates.
Ubuntu uses apt, and there's a large selection of tools to set up your own mirrors, caches or own repositories. I for one prefer apt-cacher-ng and reprepro for my home usage, but there's more than ten tools in either category I can name out of the top of my head.
OK, so perhaps not "constructive" in the literal sense, but still...
Technically "deconstructive", but whacking misbehaving vendors with a hammer just can't go wrong.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
You realise one of the key reasons for adopting systemd was that distribution maintainers have LESS work to do right?
That's the only upside of systemd I know of: it reduces the work of maintainers if they ship upstream integration as-is. But if the maintainers try to improve it, it all falls apart (case in point: Debian systemd maintainers still didn't manage to split the package to put the kitchen sink, bicycle and fish bowl (aka different components of systemd) apart. As for benefits for the user... nope. But alas, when distribution maintainers and users disagree, the former prevail.
Not having to manage a shitload of nasty scripts was one of its great selling points to the maintainers.
Right. A typical init script is one line (using #!/lib/init/init-d-script), systemd usually requires you to edit 3-5 files.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Just a few days ago I was loading Python packages on my 10 old (but fairly fast due to a SSD) desktop for a development project. I accepted an upgrade message suggesting I move from Ubuntu 18.04 to 18.04.1. The computer has old built in graphics and the upgrade dragged in a package called ubuntu-desktop that dragged in something that completely broke my graphical desktop. It turned out the computer was running Linux just fine and I could ssh into it and get a shell prompt. All I needed at that time was information about how to roll the suite of desktop packages back to what I had previously.
I have been running Linux for at least 20 years and my observation is about once a year Ubuntu gets broken due to some simple little change that sometimes can't even be tested for. What is missing is documentation and support organized in a usable manner. The AskUbuntu system is not a success. The documentation does not explain simple stuff like rolling back a bad software package. Most Linux computer screwups are easily repairable and the so-called fresh install is a big mistake.
So on the ten year support proposal, my comment is the support staff should improve the troubleshooting and testing process. I have at least eight years of a filesystem that has not been trashed, but I have wasted between 2 days and 3 weeks every year due to both un-detectable hardware problems (like a USB chip coming un-soldered) and the Ubuntu install program that maroons your old /home in some dog gone un-mounted partition.
As an (one of the few?) Ubuntu LTS user; I welcome this. I am on 16.04 and had to look up that support ends at 2021; which by then I am fine with upgrading to another LTS version (next-next LTS of 20.04 would be out by then). So I think while 10 years support sounds good; in practice the current 5 years cycle is more practical and quite adequate.
That is an interesting idea. There are a lot of advantages of this. Especially if the device would know that it would be updated to a certain time/date, then from there, it is on its own.
I do see a few faults, knowing IoT vendors, and their callous attitude:
This can be used as a denial of service attack, if an device is isolated from the mother ship somehow, goes into fail-secure mode, and loses functionality. Or, it is used to ensure devices have an always-on Internet connection for slurping telemetry 24/7 for something else to sell.
This would force customers to have to buy new IoT devices. Instead of being able to run unsecured, the devices would pretty much shut down and be useless. There are a lot of IoT companies who would loved guaranteed, timed obsolesce, forcing people to buy new devices every few years, or even every few months.
IoT makers would use this "functionality" to start to charge for updates, just so people would have to pay them in order to use their own devices.
I like the idea of going into a "fail secure" mode, but I just fear the abuse, especially by so many companies who just do not care about security whatsoever.
Suse too. They provide a solid 10 years of support.
Cheap storage VM.