Only one thing: never give up. You’ll get things fixed by copy and paste until one day youll have a broken system and think wait I actually know how to fix this because I’ve been through it five times before.
Who needs time shift when you can just slowly break your system while trying to fix a bug and then just either reinstall the os or switch to a different distro bc might as well
Appimages are nice. I just would like there to be some hub for them which also enables the appimages to be updated through it. I know about zap for example but it’s not up to par with flathub or the snap store.
I used FreeBSD as my OS on my laptop a few years ago and It’s pretty good but with the advancements and huge support that Linux gets, FreeBSD has to play a forever game of catch up. I’ll use it again someday
Alma and Rocky have been around for a while already. Most people I know moved over to those after Centos went EOL. Not sure what Suse will do that these don’t already do.
Interesting. The place I work at mostly use RHEL, with Rocky as an option for customers not wanting to pay for RHEL support. Will look into Suse’s offering once it arrives.
Flatpaks (and Snaps, and Appimages and Docker containers for that matter) are essentially designed for app developers who grew tired of distro maintainers demands to fix certain things about their build systems and their applications that broke when their apps were used on distros other than the exact distro and version the developer was using. They are designed to take a “kill the messenger” approach to the problem and now people are wondering why the work that the distro maintainers did before doesn’t get done any more.
Theoretically I like the idea but in practice too many bugs, too much disk space, not really clear how to change font size for example… and after all that, some apps are not in flatpak. It is not ready for me yet.
I must be lucky to not have run into drugs, but damn it is probably inevitable. Okay, I will find a better solution. Appimages are apparently the superior version of this concept.
Well… not really. I like them, but flatpak has sandbox and much wider scope. Flatpak also has official repository you can trust, while app images are usually created by random people. Use only ones from original developers or sources you trust.
I am definitely using Flatpaks for large, basically institutionalized programs like Blender, Godot engine, Cura, Prusaslicer… Still, I should double check.
Authoring seems very easy, and I have no idea if there is a filtering/auditing policy, so thank you. I will be more careful.
It’s not this significant (3x). it should be closer to 7%. My guess is that OP is using something like btrfs, whose data used is calculated differently due to the CoW nature, and btop++ is using using a generic tool to estimate disk usage rather than the btrfs utility that DUA is almost certainly using.
It is curious cause I also had a very bad experience with flatpaks, a lot programs just won’t work and the terminal integration… is just bad, really bad.
I think the container idea is not for everything and ppl should stop pretending that is marvelous. It actually work for most apps after a big improvement in usability but not for everything.
The very concept of them is that they bring along basically everything but the kernel - all their library dependencies, all their config, everything. So they’re ‘reliable’ and ‘easy to start’, but also bloated, slow to start, resource hungry, don’t depend on system libraries that can be updated independently, and as you see, look like crap. Working as intended, nothing to see here.
This ^ I ended up loading up NixOS and Gnome desktop for my wife’s old computer. She is not a computer person and was struggling with the slowness of W10 but also how complicated and inconsistent the interface became. She seems placated now.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.