part 2/2

“You can do the same things with the aur as without” is the dumbest shit I’ve ever heard (sry) Its like saying you can do the same thing with a guitar as with a CD.

Nah, that's coming right up:

For flatpack: I avoid it, as people who are far more deep into the topic than me said its basically snap with extra steps, bloated, insecure, against the Linux philosophy of interlocking FOSS software blah blah. Didn’t understand most of it but followed the advice.

1. Argument from authority is a logical fallacy, and I don't think basing your entire argument on willful ignorance requires further comment

2. People have issues with snap due to following reasons, and none of them apply to flatpak:

• snap is forced on ubuntu users and apt randomly installs snaps instead of deb
• snap slows down boot times because it mounts virtual FS'
• snap store and packages are closed source, and while snap is open source, the snap store is hardcoded

3. Additional package managers are bloated in the same way cars are bloated for having seatbelts and airbags. The only way to reliably prevent dependency mismatches is to have a separate set of dependencies.

For example: you want to install the newest obs, but it requires a higher version glibc than your KDE. Installing the newer glibc in the exact same location as your system could possibly break your system. Pacman simply errors out, on the other hand flatpak provides the correct version to each of the packages it installs. And that's possible because:

4. Everything is isolated, and generally not only more secure, if the package is published by the developer, but could be even further improved:

• each package gets its own private sandbox with a filesystem, libraries, dependencies, runtimes, etc.

• there are built in systems to further isolate packages from each other and your system

• you can use tools like flatseal to control permissions on top of whatever the base system uses (AppArmor/SELinux).

• no sudo privileges required

Pacman can only use AppArmor/SELinux, and AUR is the riskier version of community flatpaks.

5. The thing is, you can't get better security and reliability without breaking FHS a bit. You also need to consider that they still try to follow it within the additional restrictions imposed on them. You get the same structure, but in respectively consistent places. It's a pretty good trade-off in my regard.

For btrfs: OK, give me the Debian bookworm installer where you can select ANY enrcrypted format that is not luks–>lvm–>ext.

The default one, and therefore essentially everything downstream: guided partition -> change from ext4 to btrfs and set to mount to / -> run the encryption wizard. Do read the maintenance section though, there are reasons why stable distros don't default to it. Besides that, rsync does the job more than well enough. You can use the timeshift gui to have it periodically take snapshots, or easily automate it in different ways.

Honestly, monthly snapshots are going to be just fine. That's the whole benefit of this kind of a setup. Your base system almost never changes, while everything you need to be up to date is completely separate. Half of my packages are nix unstable and just as bleeding edge as on arch, but my system is not at real risk of failing to boot due to an update because it's still Debian, and quite close to vanilla at that. You don't need btrfs and snapshots on every update because both flatpak and nix support rollbacks, and that's the only scenario where updates could be risky.

There are downsides, and possible complications during setup though, but I'd say the trade is more than worth it, especially if you depend on your device and can't have it break down because you ran a system update or installed a package without updating the whole system. Working abroad with bad internet really drew it home for me, and caused me to finally drop arch.

Kvantum was choosen arbitrarily to make it tangeble what I mean, I don't know what specific customization option is was missing I. Ubuntu gnome 5 years ago exactly.

I guess you misunderstood my point, Its not that the specific team speak package is not in the apt repo (but available via flatpack) its again only chosen for illustration. My point is that in my Ubuntu experience I came acroos many different packages only available in certain stores/repos/as sourcecode/flatpack/snap/appimage/wine/bottles/lutris etc. Pp. Which package is available in which formats is secondary, my point is that there are a lot (especially coming from win where there is 1 [plus the win-store]).

Those behave very differently under the hood and in the beginning it feels like for every second program you need to learn about a new format/store/manager/package, which is exhausting quickly, because while appimages are quite close to .exes and easy to understand, flatpacks, snap, apt wine etc. Are not. Nearly All of those are available in one place if u use arch: the aur. It really doesn't matter if the aur package really only also installs and configures bottles for you, the fact that you need one command and one command only to get all your stuff (yay xyz) instead of 5 [to be honest maybe less or more, I still haven't found how to configure bottles, wine, lutris etc. Myself for things like league, on Debian I just download lutris, the league install script fails and I have no idea what to do and just play other games, and even if I would know how to do it, there's a chance it would break every league update and I would need to get Into it again, while on arch I type yay league-lutris or smithing like that, and it works ]

I didn't know kubuntu was part of Ubuntu, I thought its more or less another Debian derivative made by different people... or is there literally an Ubuntu with kde (which is not kubuntu) I have never heard of?

I think your description of the file structure proves my point of it being hard to grasp for a beginner and some programs just handling it differently because they can. And you didn't even touch on program files, custom temp directories or trying to install a programm to a different location (like an HDD instead of an the main ssd etc.) Stuff like symlinks doesn't make stuff easier but harder for a beginner in my opinion.

With your descriptions of the different stores/package managers/packs/etc. I again think it proves my point of being difficult, especially when just coming from win where you just double click on the .exe Not needing to know any of this and just typing yay xyz is a huge bonus on terms of ease of use and low starting threshold.

For discovery: it frequently crashes on my system so I tend to use apt, but sure with flatpack you could get team speak there, but again for league you would need lutris and understand wine settings and so on. Its not about the specific package, its about needing to understand many different installation methods and background systems, and even when understanding most, its not enough to get all programs.

I agree with you that the config file approach might be more customizable friendly for experts than the registry, but for a beginner? On win I never ever in over 10 years needed a setting which wasn't in the settings (at least before the hyper enshityfication that is win 11) On Debian you can't even change the fucking input method without using commands. (There is an option in the kde settings but it just displays "cannot connect to fcitx dbus" which is like Chinese for me and would require an evening of tinkering and reading docs or more to fix. I also ran into stuff I could not find in the settings (in like only some months of usage) and needed commands for, but can't remember what it was. But IF KDE settings would cover everything and work reliable, it would be as good (and better) than windows. This just isn't the case.

Sure the win programs may don't have configs for everything, but every intended function works. In 97℅ the time it is just available from the gui of the program, and even If someone tells me to run the forge installer and select the Minecraft mods folder, its at least the same on every win system. With every second guide for Linux the (official) website tells me "locate foo under /usr/foo/bar and append allow online = true" and the file just doesn't exist in this location for me. For an intend function of the program I never ever in 10 year of windows needet to open the console. Its always just in the GUI which makes the underlying system and its complexity irrelevant for the casual user. With Linux half of the stuff I can only do from terminal so I need to understand the folder system, config files, fhs etc.

Its not that fhs and having multiple locations which get used more or less consequently in more or less most of the cases is a bad thing in general. I am sure a lot of smart people have had very smart thoughts about this, but from a user perspective learning about all off it is way harder than not needing to know about it at all.

For the datetime thing, I don't wanna make it look bad or be ignorant and say there is no reason for it to be complicated. Of course you can't have the same expectations for a Foss project as for a commercial project, I am just stating, that there is stuff like this and that it is way harder from a user perspective so there are no wrong expectations set. That the local stuff from KDE settings won't work (at least for me) because of some fcitx dbus I already told you, but also other stuff like trying to change the username won't work as expected. I did it without knowing you should never change the username on Linux... It didn't tell me that the option is experimental or won't work for some stuff so I expected it to just enter new name and that's it, like on win or Mac, but it wasn't and stuff broke all over the place (desktop entries, file locations, automatically generated vs code scripts, default locations, some programs entierly,) and I still haven't got my taskbar panel to acknowledge the new path, it was always trying to open from the old path, even after regenerating the shortcuts and uninstalling and reinstalling panel. Maybe if I would understand fhs better I could know the place where some cofig lies where I need to change the path in line 253 and it would be clear to me that this isn't regenerated when reinstalling the programming, but as a casual user, I (didnt know (and still dont know) how i could have fixed it and just gave up at some point and reinstalled Debian fro scratch with The correct username.

Sure, I theory thing could be a lot better, but for someone without an degree in IT stuff like this is far from trivial, especially when you just wanted to correct the typo In your username before starting to work and instead spending one day trying to fix changing the name and two days reinstalling and reconfigurating Debian after giving up. Sure, a texfield in the windows settings might not give you the same freedom, but it does what you expect and works (again, at least before win 11).