The part I find very interesting is that it provides three ways to ‘restore’ itself (see the coverage of these in the linked article) if things get bollixed up. 1. It can restore itself to its initial configuration/state, removing any user, files, or configuration changes that have been made since initial installation (the initial username is ‘linux’, and the initial password is ‘linux’). 2. It can restore itself to its initial configuration/state, retaining all users and their files that have been added or changed since the initial installation. 3. It can restore all icons. I find the first two options very interesting. I suggest that any distribution that intends to be newbie-friendly should use these functionalities to help newbies more easily recover from the errors they make along their learning journey.
Hi Ernie,
I read your link.
There are things there that would be useful outside of the
school envirinment.
It is not the same as an immutable Linux, but it is similar in
that the system files are inaccessible.
To selectively restore parts of a system is something new.
That’s about what I was thinking. I’d like to see user-friendly GNU/Linux distributions add similar functionality, albeit a bit differently. Since these distributions aren’t intended for use in enterprise/educational environments, only the first user created on a multi-user system should be given administrative/sudo privileges by default. For all subsequent users, sudo powers should be optional, perhaps with a question asking for a yes/no answer, or a check-mark. All users should be able to save their configuration after they get things set up the way they want for future restoration. Since regular users don’t have access to make system-wide changes, the restoration functionality could be user by user. This functionality could be enhanced with my next idea (below).
Another change I’d like to see is the option to allow regular users (without sudo privileges) to install apps in their user space (not system-wide), using the distribution’s app-store. Apps like games would be good candidates for this type of installation. If one user on the system wants to install every game in the app store, other users won’t have to wade through all those games to find what they want. Additionally, if every user wants a different office suite, they don’t have to wade through everyone else’s choices to get to theirs. Of course, there are some apps that do, and should continue to, require administrative authorization for installation and use. That shouldn’t change.
One can do that now if you download the source code and compile it in your home directory… but it is not convenient.
I do it with R, because I want some special libraries. Any user can make their own binaries. Some administrstors consider that a security risk.
The old idea was that /usr/local was for locally installed software outside the package system. BSD is still like that.
Linux has almost abandoned /usr/local.
I know about that possibility, but what about newbies? What you describe here is beyond what most of them can do, at least, at first. What I’m thinking about (in general terms) is ways to flatten their learning curve. On Windows, a user account has Administrative privileges by default. That’s insecure, but it’s how Microsoft decided to make software installation available to all users (among other things). I’d like to see GNU/Linux do something similar, but in a secure manner. As I see it, one possibility is adding an option to allow regular users to install apps locally, in their user space. Since GNU/Linux already has that ability, I suppose what I’m getting at is a newbie-friendly way to implement it.
You would need to move the package system from system space to user space, or perhaps have both .
That would lead to some dupliplication in multiuser systems.
You could not have multiple users operating the system space package system. There woild be clashes.
Too bad. I’d hoped it would be a simple matter of requiring administrative authorization for system-wide, but not for local installations. In that case, perhaps App Images could be an option. I’ve saved App Images to my user space, added their information to my Software launcher, and have been easily able to use them as if they were installed system-wide. Another possibility could be by using flatpak apps. Either option would require a second software manager for regular users. Could either option work?
I was thinking along the lines of Snap packages for installation by non-admin users. They are somewhat sandboxed and most are independent between users. Some are system wide, but you’re not referring to those. Office suites, games, and various utilities would work just fine as Snaps.
I also use flatpaks and AppImages for myself too. Mostly those aren’t well integrated into an app store, but probably could be. Snaps are better integrated into the Ubuntu app store and should improve over time. I haven’t used Snaps on other distros, but I read that it is possible. It wouldn’t be integrated into the foreign app stores for sure I’d think.
I suppose I should overcome my bias against Ubuntu/Snap packages. I have an aversion against distributions/projects that are dependent on commercial entities for their existence. The first distribution I was able to get working correctly on the computer I had in the late 1990s was Mandrake Linux. It was developed by a commercial entity of the same name. I used it through all its iterations until Mandrake stopped developing it. It was named Mandriva at that time. It made no difference to me that several members of the Mandriva development team created a fork of Mandriva, renaming it as Mageia. The damage had been done, and I avoid such distributions/projects as much as possible. The single exception for me is the Linux kernel. While it benefits greatly from corporate support, it’s not dependent on it. Even if it lost all support from commercial entities, that project would continue on.
Ubuntu and its derivatives are the only distributions I’ve ever seen snap packages on, and other distributions seem to ignore/avoid snaps, so I don’t think they would be a good choice for this. The flatpak packaging system would probably be the best one for what we’re talking about.
I think maybe if Canonical were to disappear things would be different today. It has been 20 years after all. Things have changed. There are so many distros based on Ubuntu I would think more than a few would continue on. They could also rebase on Debian rather than Ubuntu. There is a Linux Mint Debian Edition for example.
I think flatpaks work well for the packages I have using them. Being on Pop!_OS there are quite a few system packages supplied that way. It does seem like flatpak updates are larger than “normal” updates or Snaps.
Personally, I prefer app images. The main problem with them is that not enough projects offer them as an installation option. One thing that might make them more popular is an app image store. Then there’d be one best place to look for them. Maybe I’ll ask the Solus developers if they’ll add support for App Images to their software manager. I know it already supports flatpaks, because I can look for a few of them in there. I know I’m getting off-topic here, but I’d like to see app images become more popular, and support for them become more widespread.
As for making locally installed apps easier for newbies, even though I’d like to see that become a thing, I’m not sure what the best path forward would be. I’ll probably add it to the list of things I want to investigate at some point.
Essentially, what I’m looking for is a way for newbie-friendly distributions to allow regular users to install apps locally, in their user space/home directory. I think App Images would be the best packaging format to use, but they’re not popular enough. Flatpaks could be a good choice if a graphical software manager was available to install them locally (in the user’e home directory), and integrate them into the desktop.
I haven’t considered that yet. Maybe there could be a new directory under /usr/share (/usr/share/bin ?) where apps installed by regular users can be stored, and with limited permissions, so the rest of the system remains secure. Could something like that work?
There is kind of a “Catch 22” here. It’s very common to bash big corporations because they are in business to make money. On the other hand, I see 80-plus percent of Linux kernel contributions are from corporations.
It takes all of the community.
We all have our biases. I prefer Chevy to Ford and Pepsi to Coke, but other should be free to choose their favorites.
Where, in anything I’ve ever written on this site, have I ever intimated that others should not be free to make their own choices. My previous comment mentioning my aversion for GNU/Linux distributions that depend on corporate/business financial and/or man power support for their continued existence/success, and my previous experience with one such distribution, was intended to explain why I had not previously included projects such as Ubuntu’s snap packaging system in my list of potential candidates.
If anyone interpreted my comments in any other way, that’s their issue, not mine. I believe that I made my intention obvious by prefacing my comment with the suggestion that I should work to overcome that aversion. Furthermore, I wasn’t “bashing” big corporations, I was criticizing Open Source’s ever-increasing dependence on them, and their ever-increasing influence on Open Source, as well as describing the inherent dangers of doing so. The fact is that businesses will only continue their support for Open Source as long as they perceive a tangible/financial benefit. When that perception ends, they’ll drop Open Source like a hot potato, and the organizations/projects depending on them may well cease to exist. In my mind, this is a clear and present danger to Open Source as a whole.