I started using Synaptic Package Manager more after that Software Updater has become more unresponsive than usual and now that I was attempting to remove some packages that I don't need (like those related to cups, bluez and malcontent) I saw how wanting to remove some “simple” packages would force the user to remove some that it would never imagine being involved. I don't need parental controls so when I saw that I was going to install them I wanted to remove them. And it's incredible what I'm asked to remove to do so.
This is a thing I hate, to remove some things that I don't need I'd have to remove others that I need or that by logic aren't related to them. I expected the freedom of action that I read about Linux so clearly this is very disappointing.
This is a common misconception that I see repeated very often.
The freedom that Linux provides is in the form of an open source license. You are free to study and modify the source code. There are other technologies with similarly permissive licenses.
Distribution developers use this freedom to pick and choose components in order to come up with a concrete implementation of all the technologies that they want to use. Using a distribution means that you are bound by those decisions that someone else made for you.
It's not all that uncommon to create a dependency tree to ensure that some packages are always installed and are part of the system, if the developers think is core to their product. Which is not to say that this decision is always a good one, or even a conscious one, as they may have just included a few packages they deem useful only to make their lives a little easier.
I didn't know, but it's what would happen if I remove malcontent, zorin-os-desktop is listed for removal.
I had 2 ideas to work around this thing, the first was to simply reinstall the listed packages immediately after removing the unwanted ones and the second was to force the removal of the unwanted packages while retaining the others that would be removed
(Gemini suggested sudo dpkg -P --force-depends (package name)). The problem in the first way is that I might not have even the time to start typing the command to reinstall the packages that were removed as the changes take effect immediately or involve a critical package, one in use (for example the system GUI). The problem in the second way is that it can lead to GUI or system crashes, system instabilities, dependencies problems or feature losses. Looks like I've reached a dead-end .
The Malcontent package is built upon polkit, which handles user permissions and access.
So, removing it really would not free up much disk space at all. It is a tack-on to existing policy kit packages.
The applications you list all depend on user permissions (Installing or removing or modifying software).
The problem is that certain packages have inter-dependencies. So for example, Package A uses libraries that are also used by Package B. So when I remove package A it wants to make the system clean of all dependencies that Package A relies upon which just happen to be libraries needed to run Package B - so to solve this problem it removes everything that depends on those libraries used by Package A. This is probably where App Image wins out. Because App Images are effectively sandboxed and not part of the system you can safely remove them without upsetting the applecart. Other elements that influence this behaviour are systemd and pulse audio. There is no way you can remove pulse audio without losing the entire desktop, the same goes for systemd when it comes to Gnome. You can disable pulse audio by creating a 'pulse off' folder in /etc and dragging pulse into it. This doesn't mean other desktop environments are necessarily better. Plasma for example, if I wanted to remove kmail if it comes preinstalled with a specific OS, it just might uninstall the whole desktop, again due to inter-dependencies. The only advice is to check what is going to be uninstalled before removal - always worth expanding the 'To be removed' item in Synaptic.
An old article from 2022 but an interesting one about polkit:
Using Brave A.I. search engine to look for Linux without polkit came back with:
Linux OS without Polkit
Polkit is an authorization framework installed on every modern Linux distribution, providing API to allow privileged applications to expose services to unprivileged subjects.
However, it is possible to configure a Linux system to operate without Polkit, though this requires careful consideration and configuration to ensure security and functionality.
Void Linux, for example, allows users to configure their system without Polkit or other "bloatware" by using build options similar to Gentoo's USE flags.
This involves selecting base minimal packages and manually configuring services like seatd or runtime directories instead of relying on Polkit for managing user sessions and permissions.
Another approach is to use a terminal-centric distribution that focuses on a minimalist setup, where Polkit is not a requirement for basic functionality.
It's important to note that removing Polkit might affect the functionality of certain graphical applications that rely on it for privilege escalation, such as GParted.
Additionally, security measures that Polkit provides, such as controlling access to privileged operations, would need to be replaced or managed differently.
For a desktop environment without Polkit, one could consider using a lightweight window manager or desktop environment that does not depend on Polkit for its core functionality.
This is another case of a vulnerability existing only as long as the miscreant already has physical access to the computer.
So, once you have a series of security layers, then you want to add another layer on top of it (like PolKit), that inevitably will lead to allowing a security access point, as well.
How this relates to this topic: Realistically, let's say you have a user on a user account in your home, that is knowledgeable about hacking, and you want to restrict from accessing installation or package removal ability... This vulnerability would allow them the ability to elevate to root on a machine they already have access to.
Which is a moot point most of the time for two solid reasons.
If you have someone able to in your home that you want to restrict but is clearly capable of bypassing restrictions... You already have other problems.
Malcontent only affects packages/applications which explicitly support x-parental-controls parameter. So, this includes much of flatpak but leaves appimages entirely at the users beck and call. And there is a much simpler means that involves no security broaches or hacking anyway. I won't say too much about that for obvious reasons. But the short of it is; it is a quick means of managing beginner or intermediate average users so that they do not break the system or upgrade packages that the administrator does not want upgraded.
I remember working in the build area of an IT company I worked for as a Contractor and an employee engineer on another machine, without seeing my password could take over my credentials - we are talking Windows NT4 here! He wanted to show me that he could login using DOS commands. Boy he was an annoying know-it-all! He also told me that there are over a 1000 DOS commands that aren't readily documented.
Yes, in this case, the above package is meant to prevent a home user from having system breakage due to a 'trusted user in their home' from engaging in unwanted package installation or removal. It is not intended for hackers... There are other security measures in place for that.
I do not want to say too much since that can be counter-productive (As in teaching a Zorin Forum reader a means of bypassing parental lock out by accident). In short, a parental control is not the same thing as a System Security feature.
It is just a quick means of allowing users to prevent unwanted package manipulation in their home.
It took me a whole week to find the only actual difference: I had lost access to the settings menus. All of them. Otherwise, everything worked despite zorin-os-desktop being gone. Unfortunately, Zorin put PulseAudio back during the next update, while my settings remained broken. Disappointment.
The freedom of choice is much touted in Linux, but in my limited experience, everything I'd want to change has been blocked or impaired by dependency. There's a lot I like about Linux, but for reasons both absolutely legitimate and probably others much less so, the modularity has only been of use to me in removing snapd.
I, too, have experienced this and it is getting worse each year that goes by.
Using a VM, I have been doing so distro-hopping the last couple days, just exploring. I ended up grumpy and depressed by finding so many features now missing, as well.
I'd be curious what your opinion of Nobara would be, if not for being fairly confident it would rate very low with you, given your occasional mentions of RedHat throwing its weight around and Nobara being Fedora based. <_<
I think I have stated already whilst you cannot remove pulse audio you can create a 'pulseoff' folder in /etc and then move 'pulse' into the pulseoff folder. This will prevent pulse audio from updating during software updates. Then install all ALSA packages except OSS and JACK, plus QasMixer and two other Qas packages.
Well Red Hat is now owned by IBM. Fedora is the community edition. I remember visiting a college for the Blind and one of the students there used Fedora but I said I didn't like it. As far as RedHat based OS's go at the time I favoured Open SuSE. But now it's PCLinuxOS Debian editions with no systemd and no Pulse Audio, it uses Pipewire by default.
You will notice that you never see the statement phrased as "the freedom of Ubuntu", "the freedom of Fedora", etc...
A Linux distribution is the result of many decisions that somebody else made to get to that finished product. Just like with any other type of product, you are limited in what you can do with it based on what somebody else decided to do, or how.
Think of a house, for example. You may be able to change the wallpaper easily but other things, like certain walls or adjusting the ceiling height, might prove more difficult or even impossible. At least, without major modifications to the original project.
You might enjoy something like Arch Linux more. It serves as a base that you can build upon while leaving you in charge of making all the decisions as to what to install, how to configure it, etc.
Sure. And yet when the house is built such that the water heater is welded into the plumbing so every pipe in the house has to be replaced, requiring tearing open walls on every floor to replace that one part, it's not unreasonable to question some decisions.
Maybe someday. I have enough familiarity to follow decent instructions to replace PulseAudio or change a kernel, but was very quickly overwhelmed by Arch's instructions.
I'm just in agreement with @Aravisian that modularity is worth preserving as much as possible, even down to the user level, and my experience has been that it is often not. Unlike Aravisian, I can't speak to a trend over time, but I can see a tendency to need to replace the whole engine when you just wanted to change spark plugs.
Of course you should question the decisions that distribution developers made. That's healthy, and productive.
What I'm getting at is that people are oversimplifying things quite a bit when they say that you have freedom of choice in Linux. It's a true statement by itself, for sure. But when we are talking about "distribution X", there's so much more to consider that the statement no longer holds true.
This is the misconception that ultimately results in frustration.
.
.
.
, I just stop when a package there is critical or I don't know what it does exactly.
