That’s very helpful because glusterfs and ceph are probably my top two candidates. Will probably try it out.

the biggest selling point for me is that I’ll have a mounted folder or two, a shell script for creating the container, and then if I want to move the service to a new computer I just move these files/folders and run the script. it’s awesome. the initial setup is also a lot easier because all dependencies and stuff are bundled with the app.

in short, it’s basically the exe-file of the server world

runs everything as root (not many well built images with proper useranagement it seems)

that’s true I guess, but for the most part shit’s stuck inside the container anyway so how much does it really matter?

you cannot really know which stuff is in the images: you must trust who built it

you kinda can, reading a Dockerfile is pretty much like reading a very basic shell script for the most part. regardless, I do trust most creators of images I use. most of the images I have running are either created by the people who made the app, or official docker images. if I trust them enough to run their apps, why wouldn’t I trust their images?

lots of mess in the system (mounts, fake networks, rules…)

that’s sort of the point, isn’t it? stuff is isolated

I get the same all the time. OP reminded me to check today and Jetbrains toolbox had cached a lot of downloads that took up 42 GB in total. yarn folder with 2.3 GB. bazel folder with 15 GB (apparently used for building Anki),7 GB paru clones.

All in all it added up to 82 GB.

I generally don’t understand why people go for the smaller ones at all. I guess it’s good that someone does to prevent the whole scene being dominated by a single distro, but with some exceptions (e.g. you hate systemd for some reason and really want systemd-less arch, or you have a super niche preferences). For 99% of distros it makes very little difference which one you use, except that you’ll have fewer resources at your disposal (fewer packages, fewer stack overflow threads, fewer everything).

Given your background it should come to no surprise that it doesn’t really matter much.

That said, I recommend Arch with some caveats, mainly with regards to the “very little effort to start using” requirement. If you know how to follow instructions, it should only be about 30-45 minutes to install it. It will on the other hand fit your other requirements of good defaults and not shipping with loads of applications. When you install an app you will get that app and nothing else, and the defaults will either be exactly what the upstream defaults would be if you built it yourself or something very close to that. You also have everything available through the AUR, and after using it for years I’ve yet to run into an update not going smoothly.

If a directory has multiple words in it I usually do kebab case: i-like-mine-in-a-way-i-can-read-them-properly. Both easier to read and type than pascal case.

For more complex filenames I use a combination of kebab-case and snake_case, where the underscore separates portions of the file name and kebab-case the parts of those portions. E.g. movie-title_release-date-or-year_technical-specifications.mp4

Reasonable and sane behavior of cd. Just get into the habit of always using lower case names for files and directories, that’s how our forefathers did it.

That’s a promising idea, apparently my $TERM is not foot but xterm-256color by default. However starting with TERM=foot br or TERM=foot broot doesn’t seem to enable high res previews. :(

Anyone know if I can get the highres image previews in foot? I think I saw something about foot supporting the kitty graphics protocol, but I can’t get it to work. If I start it like normal I get low res previews, if I start it with TERM=kitty I get no previews.