Breaking: Update Manager in 19.2 will no longer feature a protective level system

[Pjotr]

Update Manager (mintupdate) in Mint 19.2 will no longer feature the protective level system (levels 1-4/5). Not even as hidden option. The dev team has decided on that, and has implemented this change:
https://github.com/linuxmint/mintupdate ... e7086c04e7

System protection against bad updates (rare, but not non-existent) will then rely entirely on making snapshots with Timeshift. Which I find unfortunate, because in my opinion prevention is better than curing.... Anyway: it's a fact. We'll have to live with that.

EASY WORKAROUND:
Thankfully you'll still be able to freeze essential system parts like this:
https://easylinuxtipsproject.blogspot.c ... html#ID3.1
(item 3.1)

That should take care of the most vital system parts.

[Portreve]

Is there somewhere in that page you linked to, Pjotr, which has a discussion of some kind, or at least a statement, which explains their rationale? I ask because after scrolling and scrolling, I couldn't find one.

I agree with you since I am a massive fan of the old adage.

[Lanser]

I guess if we don't like the change,.... we can always use Timeshift to roll back to 19.1

Lanser

[Pjotr]

Is there somewhere in that page you linked to, Pjotr, which has a discussion of some kind, or at least a statement, which explains their rationale? I ask because after scrolling and scrolling, I couldn't find one.

No, that GitHub page only shows the commits.... By Clem himself, in this case.

But I've talked about it with a developer. The reason is, that snapshots with Timeshift are being regarded as sufficient protection.

[gm10]

No, that GitHub page only shows the commits....

It also links to the original pull request, which has Clem's reasoning: https://github.com/linuxmint/mintupdate/pull/492. He will no doubt discuss it in the next blog post, too. I can also refer you to my own reasoning on the matter, as detailed across several posts in this thread from January where this upcoming change was already discussed: viewtopic.php?f=90&t=286061.

[Portreve]

Pjotr and gm10: thanks to you both. There's no way I would have found any commentary on GitHub, obviously.

I think I'm going to have to sit and think about this a while and mull it over. I don't know about the degree to which levels have a bearing on regressions or other factors which cause things to break when an update is applied, so I'd really like to entertain your comments on that.

My gut instinct is levels have no bearing, except in the sense that the more "core" a given update is, the greater the opportunity it has to wreck a system, the converse to that, of course, being that the more peripheral an update, the less it can break.

I'd like to point out something else, which again I will leave to you gentlemen to comment as you will.

One of the biggest reasons I do not use, for example, Fedora, is it's too bleeding-edge of a distro for me to ever consider seriously for a production machine. Thus far, Linux Mint has occupied that portion of the spectrum which for me is the ideal sweet spot: Debian-enough to be sufficiently stable, Ubuntu-enough to have rough edges knocked off to make usability nice, and Fedora-enough to be reasonably up to date.

Within the bounds of common sense and reasoned good judgement, I don't care what Clem & Co. does, so long as it never leaves the sweet spot as outlined above.

[Pjotr]

One of the biggest reasons I do not use, for example, Fedora, is it's too bleeding-edge of a distro for me to ever consider seriously for a production machine. Thus far, Linux Mint has occupied that portion of the spectrum which for me is the ideal sweet spot: Debian-enough to be sufficiently stable, Ubuntu-enough to have rough edges knocked off to make usability nice, and Fedora-enough to be reasonably up to date.

Within the bounds of common sense and reasoned good judgement, I don't care what Clem & Co. does, so long as it never leaves the sweet spot as outlined above.

No worries.... With the how-to that I linked to in my first message, you'll be able to limit the impact of this change considerably.

[gm10]

One of the biggest reasons I do not use, for example, Fedora, is it's too bleeding-edge of a distro for me to ever consider seriously for a production machine. Thus far, Linux Mint has occupied that portion of the spectrum which for me is the ideal sweet spot: Debian-enough to be sufficiently stable, Ubuntu-enough to have rough edges knocked off to make usability nice, and Fedora-enough to be reasonably up to date.

We are not changing anything about the type of update you will be receiving, the change is only to ensure that you'll actually be seeing and hopefully applying the updates instead of potentially hiding them away behind arbitrary levels.

[Moem]

I'm okay with this, but then Timeshift becomes much more central to Mint than it already is, and so it will really need a better interface and defaults. As it is, I can easily see it scaring newcomers away... some of them will think 'You know what, never mind all that... I'm hopefully never going to need that.'
And with the current iteration, people run into trouble often enough.

[MrGrimm]

agree 1,000,000% with

"System protection against bad updates (rare, but not non-existent) will then rely entirely on making snapshots with Timeshift. Which I find unfortunate, because in my opinion prevention is better than curing.... Anyway: it's a fact. We'll have to live with that."

there are plenty of us that let mint install to the entire drive after doing a proper wipe, and allowing mint to auto partition and right out of the gate timeshift refused to do it's job cause it didn't like the drive partitioning.

[BigEasy]

I want only to say that Mint will not have any formal competitive advantages after that. On my second disk I have already installed MX Linux which most probably will become the my production system.

[Pjotr]

I want only to say that Mint will not have any formal competitive advantages after that.

Well, there are more nifty tools.... Like mintstick, mintsources and mintbackup. And of course Cinnamon. Stuff you won't find in the *buntu's....

Apart from this feature loss, in other respects mintupdate has been improved noticeably.

For me, it's a loss. But not enough of a loss to consider a switch to another distro.

[BigEasy]

I did not mean to leave Linux Mint. It will remain on the first disk and I will boot from it from time to time to do updates, and upgrates and check how things going on. If during one year there will no a single disaster due to updates, then I will begin to trust again.
Timeshift this is not a way to make reliability. It is a way to repair after crash because not enough reliability.

[Portreve]

Timeshift this is not a way to make reliability. It is a way to repair after crash because not enough reliability.

I think this is very well said.

Here's something I'll add that is liable not to make me too popular with LM devs:

If it came to it, would you be willing to bet your life, or that of your family's, on the stability of updates you're making or contributing to? If not, then you probably shouldn't make those updates, or be willing to see them released until a point where life and limb could no longer possibly be in danger from, for example, regression bugs.

[gm10]

Here's something I'll add that is liable not to make me too popular with LM devs:

If it came to it, would you be willing to bet your life, or that of your family's, on the stability of updates you're making or contributing to? If not, then you probably shouldn't make those updates, or be willing to see them released until a point where life and limb could no longer possibly be in danger from, for example, regression bugs.

I'm not gonna grace that load of nonsense with a response other than to quote myself from the older thread that I had already linked:

Still, even if there are potential issues, it's always better to install the updates and handle the fallout later rather than sit on a number of public and open-source security vulnerabilities that anyone can exploit, or critical bugs that can cost you your data (there have been a few in various kernel versions, for example).

And that's really all there is to it. If you cannot accept that simple truth, nobody will force you to install 19.2, plus you can still re-create your beloved levels via the blacklist, so take it or leave it.

[Portreve]

No, I don't mean I won't install 19.2. I'm just saying I agree with the prior post that relying on Timeshift (or any other such system) to contend with regressions is nothing more than a crutch.

There's no need to cop an attitude about it, gm10, nor is there a need to insult users like that.

[michael louwe]

The Win 7 and LM 17 days and earlier allowed computer operators/users to control the updating process through individual security updates. Nowadays, it is the trend of OS software developers to remove such control from computer operators ala "we know what is best for you" or developers have become like control-freaks - similar to how Boeing put in the computerized anti-stall MCAS in her new B737-MAX airplanes which removed flight control from the pilots/operators when activated, causing 2 deadly crashes with the loss of 346 lives due likely to the MCAS being activated by faulty/buggy sensor readings/data. ...
https://www.news.com.au/travel/travel-u ... b11f452f0f
www.b737.org.uk/mcas.htm

Win 10's buggy forced auto-updates/upgrades is stark proof about what happens when control of the updating process through individual security updates has been fully taken away from the computer operators. I guess Linux Mint 19.2, LM 20, etc will be next to go on this "warpath" against computer operators/users.

Even though buggy updates only cause computer crashes without loss of lives, regular crashes followed by system recovery(Timeshift, etc) are still undesirable for most computer operators, especially newbies. Imagine self-flying airplanes and self-driving cars crashing regularly because of buggy updates. Until all security updates are guaranteed 100% non-buggy or non-faulty by the software developers, control of the updating process through individual updates should remain in the hands of computer operators.

[Pjotr]

control of the updating process should remain in the hands of computer operators.

It still will be. Automatic updates aren't enabled by default, and won't be so in 19.2 as well.

You choose when to update, and you can deselect the updates you don't want. That won't change.

[gm10]

Automatic updates aren't enabled by default, and won't be so in 19.2 as well.

And should you enable them, I'll even be giving you the same blacklist features in mintupdate-cli that you'll have in the main client, namely full wildcard support and the ability to specify a specific version to blacklist. Additionally, I'll let you export your user's blacklist to mintupdate-cli's blacklist file at the press of a button. Blacklisting has never been easier.

[Night Wing]

When I install a new Mint version, I always use the kernel provided by default. If that kernel works without giving me any problems, I don't install any other kernel and this is the reason why I always hide Level 4 updates because kernel updates were Level 4. I like the old adage, "If it ain't broke, don't fix it".

Looks like when 19.2 is released, without any more levels, I'll have to look for updates which have a new kernel in them, then right click on the new kernel and left click on "ignore" from then on.

Sometimes I wish developers, when things are running like a well oiled machine, would just leave things alone.