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.
Happy to see I put my money on the right horse this time around. Running 18.04LTS right now. :-)
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.
This must be a systemd thing.
If Canonical keeps their release cycle of an LTS version every two years, it might be a lesser PITA than the forced updates on Windows10.
You could take every second LTS version, 4 years apart, and probably have less troubles than with Windoze. Right now, there is a Win10 company laptop behind me that has mysteriously "lost" WLAN a while ago. It also says in Settings => Windows Updates that it cannot search for updates because it is not connected to the internet. Actually it is on Ethernet right now and I'm downloading a set of offline updates on it.
Our company admin told me that shit like this sometimes happens with Win10 updates, it "forgets" about some hardware which then becomes unavailable.
C - the footgun of programming languages
"don't be evil" - google
"we don't share your data" - Face book
"don't be silly on bear stearns" - Jim Cramer, Mad Money
" We can't be sued for lying to shareholders because it was obvious we were lying" - Wells Fargo CEO
"you can't possibly use all that 10Mb hard drive" - someone said about the 10Mb PC hard drive
"we'll support it 10 years!" - Ubuntu....
The real question, "how big a sucker are you?"
Is that your best idea for a constructive solution?
Nope - my best idea for any IoT devices that require connection to a vendor server is to hit them repeatedly with a hammer.
The same approach should be used on the vendor.
OK, so perhaps not "constructive" in the literal sense, but still...
This sig left unintentionally blank.
As an alternative to he madness of Windows as a Servce. Improve virtualization/Wine and give people an exit fom reboot hell.
This is cool because it means I can put 18.04 on a friend or family member's computer and just not worry about upgrades. I can say it's good for the realistic life of the computer. Where a 5 year OS was probably not going to outlast a desktop computer, especially for a non-technical person who doesn't get excited about upgrading their system.
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.
Only in this case a reboot does not help.
C - the footgun of programming languages
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.
Mostly just noting that I think we are basically in agreement, though you also seem to be feeding or supporting YuppieScum in some way. I can only see his latest contribution as justified if it's a bid for "Funny" mods, but if so, it's a rather low bid.
Your [KiloByte's] contribution is one implementation approach. My perspective is sort of higher level. Basically I'm trying the say that any device (but especially Internet-connected devices) should not do dangerous things. In the case of a device that needs software updates to be safe, it should check for the updates first BEFORE doing the potentially dangerous things, and the design of the device should include considering what to do when the device or its environment becomes unsafe. Doing nothing is usually relatively safe (but I think there are cases when the safest behavior will be different from nothing (but also different from full functioning)).
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
And every release just got better.
Sad.
So you don't know what LTS stand for?
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.
I partly agree with you, but my main disagreement would be about the DoS attacks. There has to be a motivation for a sustained DoS attack, and just shutting down someone else's systems has limited benefit. If the goal is simply to deny service, then there are lots of ways to do it, and I don't that forcing devices into their safe modes is likely to be especially effective or damaging (as long as the devices also recover gracefully when communications are restored). In any case, the source of the DoS needs to be found, targeted, and taken off line.
In terms of the IoT device makers, I think it should be addressed via a safety standard. Non-compliant devices would become much harder to sell. At the same time specifying how long the devices are guaranteed to be safe should be a positive sales feature. Actually, there are already a number of safety standards in place, and it's quite likely that I am simply unaware of the ones that are relevant to what I am advocating. It's been a couple of years since I pretty much got out of the business. (Not really my idea, but my age got up there, and if they really insist on kicking me out of the rat race, I can't pretend any enthusiasm for rejoining. I'm happy enough to be doing a bit of teaching and a lot of relaxing these years.)
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
(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.
Still didn't manage to implies they were actively trying. Do you have evidence to back up that statement?
Right. A typical init script is one line (using #!/lib/init/init-d-script), systemd usually requires you to edit 3-5 files.
Sorry but that is known horseshit. No major distro used that method, including Debian due to shitton of customisation used by each package. I remember this argument when systemd came out. The *average* init file used by Debian at the time was over 150 lines, though some of those were comments.
Also if you're editing more than 1 file to create a systemd unit then you're doing something very wrong. Though that one file could be as short as 5 lines including specifying when and how to start and its dependencies. So maybe you just mistyped?
SystemD is kind of like LSB. So many other packages have come to depend on SystemD because package maintainers love the fact that they can count on it providing the entire set of utilities and not some unpredictable selection chosen separately by each distro. If it were just an init system it wouldn't have gained so much traction, it's the way it gobbled up everything else that made it the easy lazy thing to require.
This space intentionally left blank
What would be an ideal is a UL-like entity, but for IoT stuff. This entity would have standard security measurements, and would enforce security [1] updates for "x" amount of time, perhaps with some surety presented if a company fails to live up to their promises.
[1] Security as in protection from remote attacks, not just jailbreak resistance, which often get confounded. In general, IoT makers love jailbreak resistance, but hate having to work on protection from remote attacks, since it means fewer features.
I think UL is a testing organization? Let me see. Ah, yes. Underwriters Laboratories. Not a bad approach.
However I think in the terms of this discussion you basically need a way for the device to run a checksum on it's own code and compare it with the checksum it gets from its home server. If they do not match and the device cannot update itself to make them match, then the device should only be able to do "safe" things. Arbitrary example, but if it was an IoT refrigerator, then it would fall back to normal "traditional refrigerator" functions.
I'm using the IoT example because someone else brought it up, but I am actually thinking at a higher granularity than that. It should even apply to software features within larger systems, and that granularity should be related to the financial support. The original topic was about all of Ubuntu 18.04, but I think that's just too big and the problem needs to be divided and conquered all the way down to the level where individual donors could help decide which features live and die (or evolve or mutate or get replaced or ...).
Perhaps it will help to extend my suggestion to the IoT refrigerator example? Your "smart" refrigerator might outlive its support. Let's assume that a smart feature requires an external server, but the funding for that server has expired. Even worse, the funding for the update server has also expired. In that situation, when you tried to use the feature, you would get an error message telling you what was wrong, and you would have the option to help pay for the feature if you want to use it. Most likely you would also be faced with a similar option for the update server. However you would not be expected to pay for the entire thing, but only asked to pledge $10 for a charity share, and your share wouldn't actually be committed until enough people have joined in.
These numbers are just for this arbitrary and imaginary example, but... The feature server might be inexpensive, say $500/year, while the update server is probably going to be much more expensive (because of the programmer support required), say $20,000/year. You could see that the update server is almost funded and buy a share there to support that server for the next year. That translates as 2,000 donors, but if there are 50,000 refrigerators out there (perhaps including different models sharing the same update server), you only need a small percentage of participation to keep it running. It might be more difficult to find 49 more people who agree with you about using the more esoteric feature.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
They can hardly support stuff properly that they didn't even make.
Suse too. They provide a solid 10 years of support.
Cheap storage VM.
For those of us who don't have $75,000 to install OpenStack, you can do it yourself, https://www.ubuntu.com/opensta...