Well, it´s still in beta phase but once it´s good to go … what do think of it
What seems particularly interesting to me is:
A free Ubuntu Pro plan for everyone to get 10 years of security updates […]
The main advantage of Ubuntu Pro over the standard distribution, are the constant security patches.
[…]
security patching (coverage for both critical , high and selected medium CVEs)
Over 2,300 packages in Ubuntu Main repository: 10 years updates
Over 23,000 packages in Ubuntu Universe repository: 10 years updates
Now my question to you is:
The articles talk about Ubuntu and don´t mention derivatives. As I´m using Lubuntu 20.04.5 LTS I´m wondering whether I could benefit from it as well.
At least I can do the following on my system:
pro --version
27.11.2~20.04.1 # which indicates I´m running the latest version of the pro client
dglob ubuntu-advantage-tools
ubuntu-advantage-tools:amd64 # o.k., it´s installed then
pro security-status
2789 packages installed:
1792 packages from Ubuntu Main/Restricted repository
989 packages from Ubuntu Universe/Multiverse repository
6 packages from third parties
2 packages no longer available for download
To get more information about the packages, run
pro security-status --help
for a list of available options.
This machine is not attached to an Ubuntu Pro subscription.
Main/Restricted packages receive updates with LTS until 2025.
Try Ubuntu Pro beta with a free personal subscription on up to 5 machines.
Learn more at https://ubuntu.com/pro
Looks good so far…
If I can take advantage of the ubuntu pro plan on my Lubuntu system I guess I wouldn´t have to do a fresh install next April and could use my present system a bit longer. At least that´s my hope.
Thanks for your opinions in advance and many greetings.
Rosika, I am not sure how Ubuntu works, but if this were Debian you would get security updates for longer, but not the kind of updates of packages you get with a new release.
If Ubuntu is like Debian, you would eventually run into a problem of some software not working because it required more recent versions of some packages.
I dont want to be negative, but that us what will ultimately force you to do a release upgrade. Enjoy it while you can.
I see. I certainly wasn´t thinking in the right direction then.
That makes perfect sense, Neville.
I guess I was “blinded” by the 10 years-support of the plan: ubuntu-pro-benefits , which in itself looks good, I think.
But - apart from your considerations - the question remains:
Would the free ubuntu pro plan work on ubuntu derivatives as well (like on Lubuntu)
I think so but really want to make sure…
I only wonder: What might be the benefits for a private user?
I mean: I understand the reason for having a 10 years support if you’re running a critical production server which is expected to run 24/7 but hardly needs the newest features and gimmicks.
This is an area where Ubuntu is not very present.
But as a private user, I would rather go for upgrading with the long term releases, at least every other one.
I agree that going with the LTS is a good way to go. Even going that route, you have 5 years of support.
With Mint, they even offer an upgrade in place from going from release 20 to 21. I took that option with my laptop and it went very well. On my desktop, I perform a fresh install of 21. Something about doing a fresh install feels better to me.
I’m lazy… I’ve been doing the release upgrades (Kubuntu) on my Desktop-PC for more than a decade now (even when migrating from one machine to the other, I didn’t do a fresh install, just cloned the hard drive and hoped for the best).
Until … very recently, I got the clever idea to upgrade to a non-LTS version and passed the point where a hot upgrade was possible. Now, I will have to wipe and clean…
I’m only unsure whether to stick with the known or finally switch to something different (Thinking about Debian, Neon and Pop - for more exotic distros I have my laptop).
Hi Rosika,
That is fine. Get all the use you can out of it
The questiom I cant answer is…
With Ubuntu or its derivatives, do you get normal updates of packages within a release , or are all the updates security updates?
In all the derivatives I have tried, they all got not only security updates, but also packages update and new kernels. I added a screen shot form my last update.
Thanks Howard,
That means Ubuntu family is different from Debian. Not knowing Ubuntu makes it difficult for me.
@Rosika should be happy to hear that. It means she is not too likely to get package incompatabilities is she holds onto her current release beyond the useby date
Not sure where you get that info - there’s hundreds of thousands, probably millions, of Ubuntu instances out there running production 24x7 workloads… There’s also 100,000’s or 1,000,000’s of virtual appliances out there “in the cloud” running “cloud stuff” ontop of a Canonical derived Linux (i.e. Ubuntu). Canonical are right on top of this stuff… e.g. nearly every customer of OpenVPN pro, is purchasing a virtual appliance that uses Ubuntu 18.04 as the “back end”…
Hi Mina,
What you call release upgrades, I think is what I call cross-release upgrades and most people seem to all it inline upgrades.
Yes they work, but there are hazards.
One way to avoid release upgrades is to use a rolling release. In my opinion it needs to be a well managed rolling release.
I have been experimenting with what it is like having a rolling release in charge of grub configuration. It seems OK. I have Void in charge of grub . I roll it at least once a month. If the monthly upgrade includes an upgrade to grub itself, it copes with that… it does an update grub and remakes all the config files.
So why not try a rolling release… there are plenty to choose from. Ubuntu even has a rolling release. I have only used Solus and Void. They are both OK. Also I hear good things about Manjaro. The really extreme ones like Gentoo and Arch are another matter - I dont think the management is good enough.
I have tried rolling releases with Arch based distros on my laptop, and you’re right: It’s also possible (though I occasionally had a few issues with insufficiently tested updates), and I will continue to experiment from time to time with new distros.
However: For my workhorse desktop, I want to install something and forget, it exists. Just applying the normal updates and once a year (or every other year) typing
sudo do-release-upgrade
is about as much as I want to deal with the internals of my OS.
Reminds me of the old saying “If it’s not broken, don’t fix it.”
But for your “workhorse”, you want something that you can depend on knowing it is going to work for you every time. And have as few problems as possible. Kind of like in a production (business) environment.
I deal with that by going multi-user. One nice stable Debian, and a couple of experimental rolling releases (void and solus).
What I am finding is it does not matter.
They are all stable and usable.
occasionally had a few issues with insufficiently tested updates
That is what I mean by choosing a well managed rolling release
sorry I couldn´t reply earlier.
I was outside yesterday all day long. Had to take advantage of the nice weather in order
to attend to so many things in the garden and mowing the lawn etc. .
But thanks so much for your latest views on the matter .
Hi Mina. How nice to hear of you again. I hope you´re well.
Yes. That´s what @Neville suggested as well.
I also see your point. But for me I think I´m a bit modest in the respect of needeing the newest features and gimmicks. So that would not be my first consideration.
That said what you and Neville suggest certainly makes a lot of sense.
That´s great. I think I wouldn´t be bold enough to do things like that. Therefore I always performed a fresh/clean install. But good to know that the inline uprade process has become more reliable.
Yes, Howard, you´re right.
But with the derivatives it´s a slightly different matter. The official wording is they get 3 years of support, unlike Ubuntu itself.
LinuxMint is certainly better in that respect with its 5 years of updates. Therefore I consider LinuxMint (Xfce) or LinuxLite as my next system.
My initial thought was: why not keep my present installation of Lubuntu 20.04 even longer in case I can get the 10 years-support…
As I already have an Ubuntu One Account I could readily go on with it.
I logged in to Dashboard and was immediately presented with
my “Free Personal Token”.
I proceeded thus:
sudo pro attach [my personal token]
Enabling default service esm-infra
Updating package lists
Ubuntu Pro: ESM Infra enabled
Enabling default service livepatch
Installing canonical-livepatch snap
Canonical livepatch enabled.
Unable to determine current instance-id
This machine is now attached to 'Ubuntu Pro - free personal subscription'
SERVICE ENTITLED STATUS DESCRIPTION
esm-infra yes enabled Expanded Security Maintenance for Infrastructure
fips yes disabled NIST-certified core packages
fips-updates yes disabled NIST-certified core packages with priority security updates
livepatch yes enabled Canonical Livepatch service
usg yes disabled Security compliance and audit tools
NOTICES
Operation in progress: pro attach
Enable services with: pro enable <service>
Account: [my account]
Subscription: Ubuntu Pro - free personal subscription
rosika@rosika-10159 ~> echo $status
0
As can be seen everything went well.
The only thing which I don´t like is that livepatch is installed as snap.
snap list --all
Name Version Revision Tracking Herausgeber Hinweise
canonical-livepatch 10.2.3 146 latest/stable canonicalâś“ -
core 16-2.57.2 13886 latest/stable canonicalâś“ core
Wouldn´t have done this if I knew it beforehand…
Well, I think I´ll leave it at that for the time being.
Snap installs are containers like Docker. When you run a container, it makes a loop mount… so Linux can treat it as a disk. I am not sure how much resources that consumes , but it must be considerable
That seems an overly complicated setup, just to access some repository for some extra support that is free anyway
I see.
So I took a look at mount and here are the snap-related entries:
mount | grep snap
/var/lib/snapd/snaps/core_13886.snap on /snap/core/13886 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/canonical-livepatch_146.snap on /snap/canonical-livepatch/146 type squashfs (ro,nodev,relatime,x-gdu.hide)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,noexec,relatime,size=394264k,mode=755)
nsfs on /run/snapd/ns/canonical-livepatch.mnt type nsfs (rw)
But - like you said -
Right you are again, Neville:
sudo losetup -a
/dev/loop1: [2065]:711802 (/var/lib/snapd/snaps/canonical-livepatch_146.snap)
/dev/loop0: [2065]:712799 (/var/lib/snapd/snaps/core_13886.snap)
Hmm, I´ll watch my system for the time being.
I could (hopefully) still undo what I did if I´m not completely convinced or satisfied…
I just entered the command canonical-livepatch status and got this:
canonical-livepatch status
last check: 8 minutes ago
kernel: 5.4.0-126.142-generic
server check-in: succeeded
patch state: âś“ no livepatches needed for this kernel yet
tier: updates (Free usage; This machine beta tests new patches.)
machine id: [my machine-id]
Seems to work so far.
The command canonical-livepatch yielded this:
canonical-livepatch
canonical-livepatch - Canonical livepatch client
USAGE:
canonical-livepatch <command> [options]
VERSION:
10.2.3
AUTHOR:
Canonical Livepatch Team
COMMANDS:
config - configure livepatching on the machine
disable - disable livepatching on the machine
enable - enable livepatching on the machine
help - display help
kernel-upgrade-required - indicate whether a kernel upgrade is required
refresh - immediately download and apply any available livepatch
status - show kernel's livepatch status
FLAGS:
-v, --version (= false)
print the version
So it should be able to disbale livepatch if one wants to do that.
Reminds me of the old saying “If it’s not broken, don’t fix it.”
