KDE Discover gets update to prevent you breaking your Linux system

Quoting: Glog78I think we should discuss those solutions not agree to them by default or hype them. All what we have currently presented is in my eyes just "acitvism" which in the end we all might more suffer than win.

I agree with the solution because I see no obvious flaw that would lead to harm. The solutions implemented in Discover and apt seem to address a real, although somewhat niche, problem. They don't measurably increase complexity nor do they meaningfully harm usability, because the protection essentially only applies in situations where things are likely starting to go wrong already.

I've yet to see a convincing argument against the current implementation. The only arguments I've seen is that this somehow negatively affects the ability to tinker, which it doesn't, or that it doesn't solve every problem in the problem space of problems. It would be great if Discover and apt updates solved the world hunger, but I think expecting them to do that is maybe a bit unreasonable.

I don't know what to do with that activism comment. You seem to be vaguely gesturing at some sort of a slippery slope, but all I am seeing is developers looking at a problem and writing a small fix to prevent it from happening. I guess we could consider this activism of some kind, but that probably makes an activist of all of us programmers.

Quoting: Liam Dawe

Quoting: NociferDon't know if it was intentional or not, but this tidbit here kind of blatantly equates "Linus Sebastian" to "idiot", heh :P

Eh it's a standard saying, does not mean the person is an idiot at all https://dictionary.cambridge.org/dictionary/english/idiot-proof

I know it's a standard saying and that it's not meant to be insulting, but the analogy between "Linus-Sebastian-proof" and "idiot-proof" still stands, both in your and Nate's quote. Not that I'm judging the choice of words, mind you :)

Quoting: fabertawePacman doesn't prevent you forcibly doing this. I sometimes remove a package that is a dependent/dependency of something else, then do my tinkering and install it again. Of course if I were to forget (hasn't happened yet!) to reinstall said package then that would be my fault and I'd rightly call myself an idiot But I should have that choice.

Quoting: mr-victoryOn Arch in file /etc/pacman.conf
[options]
...
HoldPkg = pacman glibc
...

Thanks; I know Arch doesn't and likely won't ever try to hold a user's hands, but I was asking rhetorically about Linux as an OS in general. What we're discussing here is so far only limited to a Debian-derived distro + KDE combination, but since this is a (mostly welcome) change that could very well propagate and end up affecting more distros and package managers, I'd love it if it could be made at once user-friendly but also configurable and/or toggleable for the sake of the more advanced users out there.

Quoting: AussieEevee

Quoting: NociferDon't know if it was intentional or not, but this tidbit here kind of blatantly equates "Linus Sebastian" to "idiot", heh :P

To be entirely fair, Linus does have a habit of breaking... I mean, dropping... things.

Well, dropping things makes for more views, amirite? It's the hard life of a professional "influencer" :)

Quoting: BeamboomThose who just want a consumer box to do their gaming on - why on earth should they install Linux to begin with?

For the same reasons they use Windows maybe, but without the added hurdles of e.g. license costs and telemetry spying? Not all consumers (i.e. non-techheads) are gamer drones who can satisfy their computing needs with consoles (or tablets, or smartphones, or other such appliances). So for these consumers there should exist a solution besides Microsoft's and Apple's closed source, spying, bloated and insecure crap; there should be an OS that allows them to use a PC in a manner as advanced or as noobish as they desire. And that's what Linux is (trying to be) all about.

Quoting: 14Linus mentioned some gamer-oriented distros that they found but decided against those on purpose so that they could act like a regular Joe searching the 'net and trying out a popular one. So, he purposefully decided against the distro he probably should have tried out.

As per your quote (I wouldn't know myself because I don't watch Linus's streams) he did the exact opposite: he tried to act as an average Joe and install whatever a Google search for "Linux" would get him to install, instead of purposefully downloading and installing a virtually unknown (currently; because it's newer) "gamer" distro which the average Joe out there would never find and install on their own. That's exactly what I'd do myself if I were in his place (streaming tech videos for average Joes).

Quoting: BeamboomThose who just want a consumer box to do their gaming on - why on earth should they install Linux to begin with?

For the same reasons they use Windows maybe, but without the added hurdles of e.g. license costs and telemetry spying? Not all consumers (i.e. non-techheads) are gamer drones who can satisfy their computing needs with consoles (or tablets, or smartphones, or other such appliances). So for these consumers there should exist a solution besides Microsoft's and Apple's closed source, spying, bloated and insecure crap; there should be an OS that allows them to use a PC in a manner as advanced or as noobish as they desire. And that's what Linux is (trying to be) all about.

Quoting: Purple Library GuyIf you intentionally want to delete something, wouldn't you normally do it by, I dunno, using a "delete something" command of some sort, not by trying to trigger the deletion by installing a package? As far as I know, nobody's done anything to the stuff you do when you're trying to delete things.

No, there is no actual difference between explicitly trying to remove a (critical) package, and a misconfigured package inadvertently launching the same process for removing a (critical) package. It's the same "piece of code" as far as apt is concerned, it's just that you've arrived there by following two different paths. So whatever alterations are made to the destination will affect both paths.

Quoting: Purple Library Guywhich would mean those approved-of people would be in a position to know they needed to add "--let-it-hose-my-system"

At least in my case no, I wasn't aware, hence the *hint*/*wink* part of my previous comment. As long as this override switch does exist, then it's pretty much my ideal situation as far as functionality is concerned (i.e. it's a much better solution than having the user type out that cheesy phrase).

Quoting: Purple Library GuyI know that because I read about Linux, not because I use Linux. As a Linux user, I have no awareness of that. I have an applet for sound stuff on my taskbar; if it isn't in the setting when I right click that applet, I don't know about it. So no, that fact isn't relevant at all.

That's an example of great UX, and it's what I'd love Linux to become in its entirety: an OS that behind the scenes allows you full choice in how to configure your system and what components to install or leave out if you so desire, but that on the surface it handles those things for you and it Just Works™ so that even my grandmother can use it.

As an analogy for anyone who may have watched the WALL-E film, I've always dreamed for Linux to become a beautiful, polished, Mac-like EVE with a simple and intuitive interface and two (figuratively speaking) buttons: one large one in the front for "power on and let us handle everything for you, enjoy your stay dear user" and one small one in the back for "open hatch and enter WALL-E mode".

Quoting: gradyvuckovicThese are exactly the kinds of positive UX changes we need more of in the world of Linux and which I am glad to see the Linus Linux Challenge has resulted in.

As a rule, any time a user asks a piece of software to do anything, whether it be simply starting or closing the application, or asking it to perform any kind of task, there should be clear communication of the outcome.

For example, an action that refreshes a view in a user interface:
- If the action was successful (refreshing a view), hint at that visually by flashing the display area.
- If the action was unsuccessful, present a message box with a description of exactly what went wrong.
- If the action takes longer than 400ms, present a loading indicator on the view.

The number one thing that causes UX problems, is 'lack of communication'. If you don't know what's happening, or what went wrong, trying to fix the problem is that much harder.

A simple thing like an error message saying "Error: This action cannot be completed as it would remove the following software which is critical to the system's operation:", does not take that much effort for a developer to implement, but makes a massive positive difference for users.

New users aren't 'idiots' (necessarily, I mean in some cases..), they are just new. It's not their fault if they are left confused because the software didn't fully explain itself.

This should be a minimum UX standard that should be implemented across all DEs for all 'failable' actions.

Kudos to the distros for taking onboard the feedback of the Linux Challenge and making great changes as a result. Hopefully we see more of this.

Just a lucky guess here, but you sound like a web designer or at least an experienced UX guy. Kudos to you, we desperately need more UX guys in the open source part of the world.

Quoting: elmapulpeople shouldnt be forced to chose between all the benefits of linux or having to deal with something like windows.

Exactly this! As the Linux community we should be striving for the best of both (or three if we include the Macs, as we should) worlds.

Quoting: SamsaiWhat even is the use-case for a package manager to totally uninstall essential packages upon install of an unrelated package? I can get behind being able to tell the package manager to uninstall essential packages when told to do so explicitly, but installing regular application software should never make massive alterations to the foundational parts of my system to begin with.

Well, this change is actually all about completely preventing the package manager from uninstalling essential packages when told to do so, either explicitly or implicitly. What produced the error Linus faced was trying to install a misconfigured package combined with his/the system's failure to first update the package listings before he tried to install it; it's just that this misconfigured package ended up firing apt's "remove essential package" routine and from thereon there was nothing to prevent apt from doing exactly as ordered, beyond that one silly "fail-safe" (which shouldn't ever have been implemented in the first place).

PS - Damn, reading a thread with so many comments and wanting to reply to so many of them is really a b*tch to manage without ending up with a small essay instead of a comment... Sorry about the real estate abuse.

Quoting: Samsai

Quoting: Glog78I think we should discuss those solutions not agree to them by default or hype them. All what we have currently presented is in my eyes just "acitvism" which in the end we all might more suffer than win.

I agree with the solution because I see no obvious flaw that would lead to harm. The solutions implemented in Discover and apt seem to address a real, although somewhat niche, problem. They don't measurably increase complexity nor do they meaningfully harm usability, because the protection essentially only applies in situations where things are likely starting to go wrong already.

I've yet to see a convincing argument against the current implementation. The only arguments I've seen is that this somehow negatively affects the ability to tinker, which it doesn't, or that it doesn't solve every problem in the problem space of problems. It would be great if Discover and apt updates solved the world hunger, but I think expecting them to do that is maybe a bit unreasonable.

I don't know what to do with that activism comment. You seem to be vaguely gesturing at some sort of a slippery slope, but all I am seeing is developers looking at a problem and writing a small fix to prevent it from happening. I guess we could consider this activism of some kind, but that probably makes an activist of all of us programmers.

Ok very slowly ... if someone of you can tell me how you want to solve the problem which programs are essential to a user in the user environment i would agree with this solution. Here again some question which might make it more obvious from a "scenario" which can happen:

Quoting: Glog78...

If someone removes Network Manager -> is this package essential with systemd networkd still being around or not ?

Just a question :)

Question 2 to make it hard -> if one distribution says it is essential and the other says it isn't -> what would you as an developer of a none distribution package choose as an answer ? (in this case kde discover?)

Question 3 to make it completly lost -> what if the user wants to exchange network manager against wicd ?

Last edited by Glog78 on 21 November 2021 at 11:51 am UTC

Quoting: NociferWell, this change is actually all about completely preventing the package manager from uninstalling essential packages when told to do so, either explicitly or implicitly. What produced the error Linus faced was trying to install a misconfigured package combined with his/the system's failure to first update the package listings before he tried to install it; it's just that this misconfigured package ended up firing apt's "remove essential package" routine and from thereon there was nothing to prevent apt from doing exactly as ordered, beyond that one silly "fail-safe" (which shouldn't ever have been implemented in the first place).

I am aware of the scenario. Apt still retains the ability to uninstall essential packages and that counts as having the ability to explicitly order such a removal for me. The only difference is that now the fail-safe mechanism is stronger and will better dissuade users who don't actually know what they are doing.

Quoting: Glog78So KDE Discover now prevents you to deinstall kde plasma but you can go on and deinstall xfce or gnome which might used on a second user of this pc ? (Linus usecase ->) He doesn't liked dolphin as far as i got it and used another filemanager which can be in this scenario still be deinstalled ...

Ah yes, that's another point I read and wanted to reply to but then forgot, so I'll reply to this instead: IMHO it makes absolute sense for a GUI tool that is part of a GUI family of packages and is not meant to work on its own to actually prevent you from uninstalling said GUI family of packages, including itself.

If you really want to uninstall your DE (or other GUI-related stuff like Xorg) you should be doing so via CLI, i.e. a tool/environment independent of your DE, in the same way that e.g. reformatting your root should be done via a second system independent of your root device.

Regarding Gnome or XFCE, they're just non-essential packages from the point of view of an active KDE environment.

Quoting: Nocifer

Quoting: Glog78So KDE Discover now prevents you to deinstall kde plasma but you can go on and deinstall xfce or gnome which might used on a second user of this pc ? (Linus usecase ->) He doesn't liked dolphin as far as i got it and used another filemanager which can be in this scenario still be deinstalled ...

Ah yes, that's another point I read and wanted to reply to but then forgot, so I'll reply to this instead: IMHO it makes absolute sense for a GUI tool that is part of a GUI family of packages and is not meant to work on its own to actually prevent you from uninstalling said GUI family of packages, including itself.

If you really want to uninstall your DE (or other GUI-related stuff like Xorg) you should be doing so via CLI, i.e. a tool/environment independent of your DE, in the same way that e.g. reformatting your root should be done via a second system independent of your root device.

Regarding Gnome or XFCE, they're just non-essential packages from the point of view of an active KDE environment.

While i understand the arguments i still want to ask a question here too:

kdiscovery considers kate to be an essential part for editing text
gnome software center considers gedit to be an essential part for editing text
..... (you see a pattern here)

Now the question ->
What is the essential part of editing on the distribution for the package manager ?

Quoting: Glog78Ok very slowly ... if someone of you can tell me how you want to solve the problem which programs are essential to a user in the user environment i would agree with this solution. Here again some question which might make it more obvious from a "scenario" which can happen:

The questions you present are edge cases that might not be solved by the existing solution, but that doesn't negate the value of the solution. But sure, I'll take a stab at the issues.

Quoting: Glog78If someone removes Network Manager -> is this package essential with systemd networkd still being around or not ?

If a user explicitly removes Network Manager, there is no issue. The package manager may employ some fail-safe mechanisms to dissuade users from uninstalling it, since it can be vital for the existence of networking, but when the user explicitly orders the removal of NM then that becomes their problem. No user-level application should be able to uninstall Network Manager as part of its dependency resolution process, particularly if NM is active.

Quoting: Glog78Question 2 to make it hard -> if one distribution says it is essential and the other says it isn't -> what would you as an developer of a none distribution package choose as an answer ? (in this case kde discover?)

Make the best and probably most conservative decision the default, provide mechanisms for distributions to provide better information about which packages to consider essential. Since Discover uses the distribution's package management tools underneath, we can probably defer some responsibility to the underlying tools.

Quoting: Glog78Question 3 to make it completly lost -> what if the user wants to exchange network manager against wicd ?

If two packages provide roughly equivalent functionality which would cause them to conflict at installation time, then I would be okay with the user being able to swap one essential package for another if the user has explicitly ordered an installation of that essential package. Package managers already exist which allow one package to cover other packages as dependencies. For example, the pipewire-pulse package provides the pulseaudio dependency under Arch Linux, allowing you to fairly seamlessly switch between the two without breaking the dependencies of all applications that depend on Pulseaudio. We could also decide to require satisfying the fail-safe mechanism in this instance, since switching from NM to wicd is a fairly niche use-case and people that would actually want to knowingly do that can probably figure out what they need to do to accomplish it. Alternatively, we could simply say that NM and wicd should not conflict in the first place and have the issue be resolved on service management level. I've got Network Manager installed in parallel with systemd-networkd, but I simply have the NetworkManager service disabled.

So, really, none of these scenarios is somehow impossible to overcome and solving these three arbitrary scenarios isn't even a requirement for the existing solution to be valid.

Quoting: Guest

Quoting: AussieEeveeI agree in part. the CLI is not intended for newbies, but Linus was able to find a guide online and managed to bypass the protection offered to him by the gui, with only a single command and a verify command.

Adding protections doesn't make this dumbed down like Windows. It just adds protections.

Actually this raises a good point: what does the apt change do that would have made anything different for a youtuber who wanted page views? Type this, then type that. It doesn't matter if it's one line or ten - he would have followed everything written. So the change to apt? Yeah, wouldn't have done anything in this case.

Also, the original error message from the gui was exactly stopping critical packages from being removed! The original gui error message was stopping the very thing that was then done explicitly from the command line.

Well the problem was that the error from the Pop Shop was presented in such a way that Linus believed the problem to be with the Pop Shop and not with the Steam package. I think that is something that we can put down as a hard fact.

The problem is how we solve that misconception, will a more helpful error message in the shop help? Perhaps not, but then again a better message like the one KDE uses here (which matches what I requested in the earlier thread) will hopefully prevent a lot more of others in the same situation even though it would not have prevented Linus from continuing.

Because IMHO the major issue behind the LTT fiasco is that he (and his fellow Windows users) have a prejudice against Linux in that the graphical shops are unstable / don't work and that you have to use the terminal to get anything to work in Linux. That is not something that a new warning message will solve, at least not initially, perhaps on a long term though.

I think that it's important that we don't lock ourselves down in a nirvana fallacy where we will only accept a change if it solves 100%, every improvement is an improvement.

Quoting: Samsai

Quoting: Glog78Ok very slowly ... if someone of you can tell me how you want to solve the problem which programs are essential to a user in the user environment i would agree with this solution. Here again some question which might make it more obvious from a "scenario" which can happen:

The questions you present are edge cases that might not be solved by the existing solution, but that doesn't negate the value of the solution. But sure, I'll take a stab at the issues.

Quoting: Glog78If someone removes Network Manager -> is this package essential with systemd networkd still being around or not ?

If a user explicitly removes Network Manager, there is no issue. The package manager may employ some fail-safe mechanisms to dissuade users from uninstalling it, since it can be vital for the existence of networking, but when the user explicitly orders the removal of NM then that becomes their problem. No user-level application should be able to uninstall Network Manager as part of its dependency resolution process, particularly if NM is active.

Quoting: Glog78Question 2 to make it hard -> if one distribution says it is essential and the other says it isn't -> what would you as an developer of a none distribution package choose as an answer ? (in this case kde discover?)

Make the best and probably most conservative decision the default, provide mechanisms for distributions to provide better information about which packages to consider essential. Since Discover uses the distribution's package management tools underneath, we can probably defer some responsibility to the underlying tools.

Quoting: Glog78Question 3 to make it completly lost -> what if the user wants to exchange network manager against wicd ?

If two packages provide roughly equivalent functionality which would cause them to conflict at installation time, then I would be okay with the user being able to swap one essential package for another if the user has explicitly ordered an installation of that essential package. Package managers already exist which allow one package to cover other packages as dependencies. For example, the pipewire-pulse package provides the pulseaudio dependency under Arch Linux, allowing you to fairly seamlessly switch between the two without breaking the dependencies of all applications that depend on Pulseaudio. We could also decide to require satisfying the fail-safe mechanism in this instance, since switching from NM to wicd is a fairly niche use-case and people that would actually want to knowingly do that can probably figure out what they need to do to accomplish it. Alternatively, we could simply say that NM and wicd should not conflict in the first place and have the issue be resolved on service management level. I've got Network Manager installed in parallel with systemd-networkd, but I simply have the NetworkManager service disabled.

So, really, none of these scenarios is somehow impossible to overcome and solving these three arbitrary scenarios isn't even a requirement for the existing solution to be valid.

So in the end ... the user still needs to decide what he wants and not wants -> if a user can't decide in the first place if something is harmful how can he decide now? Will it stop him from doing harmful things ? Will it help him to understand the dependencies and why they are used ? Will it make him understand what is happen right now ? ... Most likely not and we might become a situation like under windows where user don't check anymore if they get an admin promt at all ... they just click it's fine someone on the internet told me to do so ... I would go so far that since you as someone who want to help can't be sure which packages are blocked by which frontend -> we will tell them to do on the commandline overruling the distribution protection ... Thats why i think we are on a complete stupid path currently ... we don't fix anything but we make it more overhead for people who are able to support those systems.

Quoting: Purple Library Guy

Quoting: NociferBut I do have one question: what if I intentionally do want to remove a "system critical" package like Xorg or my DE - how do I do it if package managers, both GUI and CLI, prevent me from doing so?

If you intentionally want to delete something, wouldn't you normally do it by, I dunno, using a "delete something" command of some sort, not by trying to trigger the deletion by installing a package? As far as I know, nobody's done anything to the stuff you do when you're trying to delete things.

Well it would happen if you where trying to replace say xfree with xorg or pulse with pipe-wire. Then you would remove what the disto have marked as an essential package and replace it with another which is what the Steam package tried to do here, the main issue of course is that there where no i386 version of the desktop or xorg available so apt replaced it all with nothing.

And that is something that the apt (and possible also yum/dnf/pacman) devs should take a hard look on, if a package have a hard dependency that requires it to remove packages but where the actual dependency doesn't exist it should straight out refuse to perform the action regardless of any "do as I say".