well, the point of flatpak is to have bundled dependencies so they run predictably no matter the distro

if one of your software’s dependency gets updated, and your software isn’t, you may run into issues - like a function from the library you’re using getting removed, or its behaviour changing slightly. and some distros may also apply patches to some of their library that breaks stuff too!
often, with complex libraries, even when you check the version number, you may have behavioural differences between distros depending on the compile flags used (i.e. some features being disabled, etc.)
so, while in theory portable builds work, for them to be practical, they most often are statically linked (all the dependencies get built into the executable - no relying on system libraries). and that comes with a huge size penalty, even when compared to flatpaks, as those do have some shared dependencies between flatpaks! you can for example request to depend on a specific version of the freedesktop SDK, which will provide you with a bunch of standard linux tools, and that’ll only get installed once for every package you have that uses it

it sure seems like it though

i mean, they’ll never replace system package manager, but for desktop applications, flatpak is honestly quite good

i mean, the main issue is that theologues base their beliefs on the belief that some old texts hold universal truths

according to the github readme, you can just run sudo pro config set apt_news=false to disable those

if you have things set up the way you like on xubuntu, it’s maybe worth it to just do that rather than start fresh

iirc, postgresql renames itself in htop to show its current status and which database it’s operating on

you probably got a kernel panic, which froze the system. it’s like a BSOD on windows, except on linux, there isn’t a proper stack to handle them when they happen while you have a graphicam session running, so it kinda just freezes

i don’t think reisub would do anything, because the kernel was probably already dead

you don’t risk corrupting much data by hard-reseting your pc on linux – journaling filesystems, like ext4 or btrfs, are built to be resilient to sudden power loss (or kernel crashing). if a program was writing a file at thz time the kernel crashed, this one file may be corrupted, because the program would get killed before it finished writing the file, but all in all, it’s pretty unlikely. outside of fs bugs, which are thankfully few and far between on time-tested filesytems like ext4, you shouldn’t have to worry much about sudden power loss!

unfortunately, figuring out the cause of these issues can be challenging – i’ve had many such occurences, and you have no logs to go off of (because the system doesn’t have time to save them), so you’d most likely need to figure out a way to send your kernel logs onto another system to record them

as general mitigation steps, you should try monitoring your cpu temperature a bit closer - it could be high temperature tripping the safeties of your motherboard/cpu to avoid physical damage to them - in which case, try installing a daemon to control your cpu frequency, like auto-cpufreq, or something like thermald specifically made to throttle your cpu if it gets too hot (though i think that one is intel specific)

there seems to be qt qml bindings for Zig

qml is a language made to build UIs, and is very easy to use in my experience - you can build your logic that needs to be high-performance (file loading, audio effects, etc.) in zig, and expose it to qml so it’s available in the UI.

i’ve never used zig, but i did do a similar thing using c++ & qml, and it was great to work with, so i think you should be fine going that route

i was talking about intents! this is a specific API for one app to start & send specific data to another app on the system

They can probably even ease that out if they implement some API in K9 to let another app request data from it - Android has a system for letting apps send data to each other securely

is the last picture a lockscreen? looks so cool!

not sure about the path, you should check flatpak’s docs for more accurate informations

but i believe so, yeah

on one had it’s a shame they’re not using xdg dirs, but on the other, i kinda get why – it’s neither config files, nor just data – it’s both, it’s a container

i think those kids got a point – app stores are easier than finding random executables on the web

it can sometimes be a pain to find the original developper’s website to get a legitimate copy of the software from, especially for non-technical users.

the main issue with app stores is that they’re often closed ecosystems, where there’s only one app provider. that’s not the case with flatpatk!

AppImages can be double clicked and executed. They are not a pain to use.

i can understand that, but flatpaks are easier to upgrade and automatically integrated into your package manager, which (i believe) isn’t as straight forward for appimages. also there’s one major repo where you can find most apps (flathub) making app-hunting less daunting i feel like.
also, once your app is installed, it’s always in your system menu, so that doesn’t change much in the long run

Comfortable setup that carried over from Ubuntu LTS.

can’t you carry over flatpaks as well? you can probably copy /var/lib/flatpak or wherever they store their stuff from one system to another, or failing that, save all the app IDs you have installed, and re-install them onto your new system, backing up ~/.var to keep all your data!

because they require more access to the system

afaik, you can allow more system access to flatpaks

Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing

i believe flatpak also does that, you can specify some paths from the host to be available to the flatpak

and some native japanese words get katakana-ised too!

e.g. バカ, most animal names, etc.

what’s your point? if flatpak makes it easier for developers to package their software and easier for users to install it, there’s nothing wrong with it being famous

the package is maintained (will continue to install on modern ubuntu versions), but the software is unmaintained (no bug fixes, no new features, will stagnate and eventually become obselete as incompatible with future desktop standard modifications)

the desktop shell is mostly javascript though

it’s that wayland wasn’t ready, and now is ready. it took a long time, because building a new protocol like that takes a while if you want to do it well, and lots of coordination between many people. it still has issues, but they’re being adressed. slowly, because x11 was full of half-assed solutions done quickly, and they don’t want that to happen again

X11 being reliable because Xorg devs aren’t stupid

xorg devs are wayland devs. nowadays, most of the people that used to work on xorg now work on wayland. they’re not stupid, they realised that x11 is too dated for modern systems (see asahi linux) and now are working on a replacement