KDE Discover gets update to prevent you breaking your Linux system

So 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.

So 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 ?

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:

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.

If 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.

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?)

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.

Question 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.

I 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.

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:

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.

If 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.

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?)

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.

Question 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.

But 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".

[
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.

There is only so much you can do to prevent PEBCAK, but on this level I think we had room to push a bit further without any meaningful harm to any existing users, so I don't really understand all the push-back. None of this has ever been about preventing all wrong decisions or making the user learn things they don't want to learn. We are incapable of those things. But what we can do is deploy reasonable measures that make certain classes of stupid mistakes less likely to happen.

Also, I don't see how we are increasing the amount of overhead. The vast majority of situations where we support users don't involve removal of essential packages. In fact, regular users who just want to use their computer should be able to do so basically completely without ever worrying about a single essential package. They should only need to lift the veil if they are actually curious. If a user just wants to install Steam, that should never involve the removal of essential packages and we can make sure that doesn't happen either by deploying sanity checks that make sure those kinds of packaging mistakes don't happen or by having sanity checks performed by package managers so that they don't install faulty packages.

But 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".

i can say for pacman --> unsatisfied dependencies are nearly impossible to install ...

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).

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.

I still disagree that the apt change was useful. The KDE Discover change, absolutely, but for apt people are still just going to follow something they found online to force modifications without fully understanding it. It's a knee-jerk reaction, and doesn't actually fix anything in my view.

So is your only argument against the tiny apt change that it happened too fast? You say it doesn't fix anything, but does it break anything either? Do you actually think the UX is worse now, instead of better?

People making a mountain out of a molehill, as is tradition.

[
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.

There is only so much you can do to prevent PEBCAK, but on this level I think we had room to push a bit further without any meaningful harm to any existing users, so I don't really understand all the push-back. None of this has ever been about preventing all wrong decisions or making the user learn things they don't want to learn. We are incapable of those things. But what we can do is deploy reasonable measures that make certain classes of stupid mistakes less likely to happen.

Also, I don't see how we are increasing the amount of overhead. The vast majority of situations where we support users don't involve removal of essential packages. In fact, regular users who just want to use their computer should be able to do so basically completely without ever worrying about a single essential package. They should only need to lift the veil if they are actually curious. If a user just wants to install Steam, that should never involve the removal of essential packages and we can make sure that doesn't happen either by deploying sanity checks that make sure those kinds of packaging mistakes don't happen or by having sanity checks performed by package managers so that they don't install faulty packages.

Thats exactly why i want to know what will be "essential" in the future ? ... For a "newbie" compatible distribution i would mark all packages essential (to say it very hard). But this distribution won't be able to really let you choose anymore without being "midly" annoying with questions if you really want to do what you want to do and don't allow it on the gui but force you to override something and use the terminal. So i go back to my question above -> how do we determine what is essential and if we have determined what is essential does it really help or does it start to annoy and be contra productive. Also is it good if every package manager frontend now decides on his own what is essential ?

Btw the last time someone tried to define what is an essential linux distribution was -> https://en.wikipedia.org/wiki/Linux_Standard_Base

Hmm i would guess most currently used distributions aren't per default compatible with the lsb... it also had alot of reasons why this project (from my point of view) basically died.

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.

With Discover if you blindly click OK, you'll start reporting a bug. That might persuade at least few people not to google the command line alternative. After a while first hit in Google might even be that bug report. Discover doesn't tell you to google for command line alternative at all.

Discover of any GUI package manager doesn't really need to support use case of intentionally removing essential packages, result might be just black screen like what happened to Linus. Yes, APT has a roadblock which hopefully doesn't hinder normal operations as has been said already at least once. And it still has override for the cases where you actually want to break things.

Path of educating people to be more informed doesn't have to happen right away. Tinkerer distributions are also not going away. If you're curious you can still look under the hood, Linux still won't be Windows.

So in short, I would not be worried about stupid path yet.

You led off with "I simply do not subscribe to the idea of "Linux for everyone"". Then you started talking about all the "everyone" it was not for, and I recognised myself among them.

I know I tend to paint with quite broad brushes when I express myself, so this is probably my fault. :)

But let's talk about you:
How long have you been using Linux now, and what's your opinion on the OS thus far, generally speaking? What made you install Linux the first time, how was that installation process for you, and what made you decide on distro?
Have you ever experienced anything that made your system unstable or did something you had to revert?


Last edited by Beamboom on 21 November 2021 at 1:26 pm UTC

But 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".

i can say for pacman --> unsatisfied dependencies are nearly impossible to install ...

I should perhaps have worded that differently. APT will not continue with a missing dependency either, the bug that happened was a bit more complex than that. What I really meant that the package manager should detect that a dependency wants to remove essential packages without replacing those with something else.

Now this is an extreme edge case, but since edge cases do sometimes happens which LTT is evidence of, if I was an APT developer I would have gotten hold of that broken steam package to see why things went the way they did and analysed if there was a way to detect it and avoid it altogether.

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).

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.

I still disagree that the apt change was useful. The KDE Discover change, absolutely, but for apt people are still just going to follow something they found online to force modifications without fully understanding it. It's a knee-jerk reaction, and doesn't actually fix anything in my view.

So is your only argument against the tiny apt change that it happened too fast? You say it doesn't fix anything, but does it break anything either? Do you actually think the UX is worse now, instead of better?

People making a mountain out of a molehill, as is tradition.

I think it was a change that can potentially impact everyone, made without due consideration, all because a youtuber wanted more page views. If distros are going to start doing such things then it can't be a good road to go down, no matter what change is made.

And yes, the more I think on it, the worse the change is. As I wrote - anyone forcing things through by putting in a configuration override (which is almost certainly going to start to be recommended on random internet comments) now won't be warned of potential breakage.

Note that I'm not saying nothing should have been done, I'm instead saying that (in my view) the change wasn't an improvement and doesn't fix anything.

100% agree with you mirv. In all those talks most people only see that goal that it should be "newbie" safe get more market share. I am sure i didn't change to linux because i wanted a system which does something "newbie" safe. I could have choosen such an OS with mac os or windows. There is some kind of DNA inside of linux which in my eyes prevents it from being streamlined. We call it usually freedom and are about to give up on "freedom" and easy to try for some kind of false "security" idea (imho). If i want another "streamlined" "linux" distribution -> chromeos / android are totally valid alternatives. I guess steamos will fit into the same. Maybe some other distributions will go this road. But changing upstream which have an impact on everyone ... i dunno ... Seeing kde discovery (the one desktop which always wanted to let the user do whatever the fuck they want) go for such a change makes me honestly scared.... If they would have done this change without LTT -> i can see the headline -> "kde discovery forbids user to deinstall kde" and the shitstorm which would had happend would be crazy.

tayshady]I don't want to dumb down Linux for less inexperienced users, but Pop OS or Ubuntu are not good distros for beginners, Linux Mint is because it's made by people who know what they're doing.

You have two companies like System 76 and Canonical behind these distros and there's still so many bugs and issues with them. I would never recommend any GNOME based distro to any beginner, what a joke. Anyone who recommends these distros to beginners has no idea what they're talking about.

Just recommend Linux Mint, that's it.

There was this dumb shift from the community that Pop OS was the new defacto beginner distro and that was a huge mistake IMO. I heard that the developers of Pop OS want to move away from GNOME about time, GNOME3 needs to just die, fork off GNOME2 like Cinnamon did or just make something else. GNOME3 is a catastrophe and needs to be abandoned, and we need new toolkits to replace GTK so we no longer rely in anyway on the abomination that is the GNOME team. They are the worst thing to have ever happened to Linux IMO.

Sorry but that is just useless distro bashing. There is nothing inherently work with either Pop!_OS, Ubuntu or Gnome that makes them unsuitable for beginners, far from it and both Pop and Ubuntu are being successfully used right now by thousands of beginners the world over.

Gnome3 was a disaster at 1.0 but have been quite usable for several years now and while perhaps not perfect, far from "a catastrophe" and doesn't need to be abandoned. Such hyperbole is just silly and does not move any discussion forward.

Oh one more headline and view it without the ltt video -> "APT makes it harder to deinstall packages..."

Those 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?

Those added "hurdles" are nothing compared to the hurdles of subpar performances, limited multiplayer support and core titles that just won't run. Or the hurdles of custom configurations, additional launch parameters or manual corrections of config files in the install.

If your focal point is gaming - a machine to game on, that's the primary function - if you want to get the most out of your games then I guess this is another controversial claim but here goes:
If you just want to play Windows games, install Windows.

There are no rational technical reason to install Linux on your PC just to play Windows games, especially not if you're not even familiar with Linux. If you are a normal PC gamer with no tinker interests you should do what the vast majority already does: Use the OS all the games are built for.

Gaming on Linux is for those of us who use Linux for reasons outside of gaming.
Those reasons might well be of ethical/philosophical character, political character (anti-mainstream, anti-corporation, political statement), it doesn't need to be of technical character. But the majority of "regular" users do not share that political focus - they want a machine to game on.

Now, this is the point where of course the Steam Deck is interesting to introduce in this dialogue. How will that affect the game market? Too early to say for sure but it's already interesting things happening.

However, at the current state Windows gaming is best on Windows. And tbh I don't see that changing in quite a long time yet.


Last edited by Beamboom on 21 November 2021 at 1:32 pm UTC

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).

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.

I still disagree that the apt change was useful. The KDE Discover change, absolutely, but for apt people are still just going to follow something they found online to force modifications without fully understanding it. It's a knee-jerk reaction, and doesn't actually fix anything in my view.

So is your only argument against the tiny apt change that it happened too fast? You say it doesn't fix anything, but does it break anything either? Do you actually think the UX is worse now, instead of better?

People making a mountain out of a molehill, as is tradition.

I think it was a change that can potentially impact everyone, made without due consideration, all because a youtuber wanted more page views. If distros are going to start doing such things then it can't be a good road to go down, no matter what change is made.

And yes, the more I think on it, the worse the change is. As I wrote - anyone forcing things through by putting in a configuration override (which is almost certainly going to start to be recommended on random internet comments) now won't be warned of potential breakage.

Note that I'm not saying nothing should have been done, I'm instead saying that (in my view) the change wasn't an improvement and doesn't fix anything.

But no warnings were removed. The wishy-washy "You are about to do something potentially harmful." was changed into "Removing essential system-critical packages is not permitted. This might break the system." and the silly prompt was removed in favour of a flag. You'll still see the list of relevant packages and unmet dependencies.

You can easily check the relevant changes in their Gitlab. You're arguing against a strawman.

Wow, some of you actually complain about Linux becoming more user-friendly. How have you not outgrown this edginess? I was like that as a teenager. I cringe hard thinking back on that time. Maybe you should try something more obscure than linux eh? Have you heard about the anti-mainstream super edgy OpenBSD? No apt nor discover you need to worry about. And I guarantee that Linus won't even consider using that ever. How does that sound?