#1

One of the aspects I like so much about Silverblue is the compartmentalization of workloads. I think it keeps my install much cleaner. I am so far a huge fan of the toolboxes concept I wasn’t expecting to enjoy it this much. I can’t tell you how many times I have installed a package and its 30 dependencies just to try out one thing and then forgot to clean it up. Those packages would then just sit on my machine after I forgot about them. I feel silverblue promotes(and pretty much forces) the use of containers for the one off jobs where I can runa test or try out a package, then throw out the container after that one off test/task is done.

Do you all feel that this methodology of containerizing or having a toolbox for your certain tasks keeps your OS cleaner? Was this how you were working on the typical workstation anyway?

2 Likes
#2

I think for the most part it has been helping me to keep my PC cleaner… at least the system. Does my ~/Downloads/ directory still need help? Yup. But that’s just data :P.

I’m trying to use the containers approach to force the mentality of having “throw-away” environments for testing stuff, like you mentioned. However, I am also trying to automate/define my real work environments. This way, they also become “throw-away” in a sense, as they are trivial to spin up.

This combination should allow for a very clean system, as I can trash test containers, or even re-pave the entire system without much effort or time.

TLDR: I Agree. Silverblue is great for keeping a system cleaner.

2 Likes
#3

I have been enjoying the “Flatpak everything” methodology for keeping installed apps from creating cruft on my system.

You hit it right on the head. It’s the throw-away containers that have been really changing the way I look at things on my laptop. I don’t think I yet have a solution for quickly provisioning my “real work environments”. Do you have a way of quickly provisioning all the toolboxes you use?

#4

I’ve used ansible to provision my host systems in the past.

For the container side, I’m still in the planning/experimenting stages but I think I have an idea of what I plan to do.

I started to define my work environments in Dockerfiles, but decided to switch over to writing buildah. It turns out buildah is very powerful and should provide a bunch of flexibility. Using the scripts, I can build container images which define my work environments. I can then simply pull these images down and run them with podman, whenever I want.

The goal, is ultimately to define build scripts in a repo, and then set it up with Jenkins or some other CI/CD system. That way, whenever I change a config, Jenkings can automatically rebuild the chain of images (I’m trying to layer them), test them (maybe?), and then push the images to a registry. Then when I start to work, I can “throw away” a build environment and just jump into the latest one built and deployed to the registry. < Insert benefits of immutable infrastructure here :stuck_out_tongue: >

So I guess I’m not working to quickly provision containerized work environments, as much as I am setting up the infrastructure to have them pre-built, and instantiated later, as needed…

#5

I do. I know whats in /usr is exactly what came with the OS + layered packages (w/dependencies) that are listed separately, nothing more, nothing less, no un-needed packages laying around etc. Additionally, doing development work in containers just enforces healthy practices that make your environment portable and reproducible.

I’ve always liked how macOS kept the operating system and user data separate, Silverblue does that perfectly. I do make heavy use of /usr/local, but only for the odd binaries/tools.

#6

There’s a Flatpak for that. :wink:

https://flathub.org/apps/details/org.librehunt.Organizer

First, I use Nautilus to select the files I do want, then right-click and select “New Folder with Selection”. If they start with the same text, it’ll even prefill the folder with the shared part of the names.

Then I use Organizer to sort the rest of the files into different subdirectories. I trash the subdirs I don’t need. As for the remaining directories, I will move elsewhere for longer term storage or sift through to find anything worth keeping.

This all allows me to keep my homedir almost as non-messy as the Silverblue install. :grin:

1 Like
#7

Cool! I’ve been doing the same, both with Docker and then with Buildah.

For some projects, I now have started to use toolbox in simple scripts (thanks to its run command) to build a container too.

Here’s an example where I use toolbox, not buildah, to create a working environment (for running Jekyll locally for Cockpit’s website):

And then I pair this with a run command too:

(This could easily be an alias instead, but I’m sharing it with the team and want to make things super-simple for everyone.)

The reasons why using toolbox is better than buildah for this case:

  • With buildah I had to not commit the container, as I needed to install gems inside and wanted to update them from time to time (instead of rebuilding everything).
  • With toolbox, I don’t have to do anything special to map in filesystem access, mess with SELinux, or map ports to the host. (I had to do all of these things when using buildah.)

For a lot of things, buildah or podman are still the right choice. But at least in some cases, toolbox simplifies scripting together a container.

1 Like
#8

While I do feel it’s somehow cleaner, it’s not clean at all. The .local and .config directories in $HOME are easy to cleanup tho. But then /etc remains (I was giving a try to moby-engine as a layered package and after removing it some files where left behind there)

#9

A co-worker who is also using Silverblue gave me this tip:

sudo diff -Nur --no-dereference /usr/etc/ /etc/

The above command will give you a diff of everything that has been changed in /etc/.

You could then look through the diff and modify things to remove cruft or use it to recreate your configuration setting later on.

2 Likes
#10

Oh wow. That’s really cool. but /etc has lot of stuff I have no idea what is or where does it come from. But the only layered package that I have added has been zsh (Appart of moby-engine). So I’m expecting to keep /etc pretty clean. (I just removed all non-read-only files that had references to docker or moby)

#11

You could do something like this extremely hacky, quickly thrown together bash script as root on your system:

#!/bin/bash

for i in $(diff -qNur --no-dereference /usr/etc/ /etc/ &>/dev/null | grep "differ" | cut -d" " -f4 | grep etc | sort -u); do
  rpm -qf "$i" | grep -v "not owned" >> /tmp/etc-owners.txt;
done;

sort -u /tmp/etc-owners.txt;

As always, don’t run random scripts from the Internet without understanding what they do.

I’m sure the script can be implemented much better, but it is probably mostly fine — and it works here — but it makes some wild assumptions, such as files not having spaces and currently having packages installed for the various files. It also will definitely show you files owned by packages that are part of Silverblue itself, so don’t try to remove everything that has a file changed. :wink: It also doesn’t directly answer your question, nor does it show you orphaned files… but might point you in the right direction to know what currently-installed software has modified files.

If you cross-reference the output with rpm-ostree status, you can probably tell where many of the changes come from.

Edit: Actually, the first part of the command is probably even more useful, as it shows you the files that differ:

diff -qNur --no-dereference /usr/etc/ /etc/ 2>/dev/null

The paths and filenames are probably useful enough to indicate what they do.

1 Like