yukijoou

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

imo, those are pretty weak reasons to criticise valve -- they've definitely done worse

afaik, they took years to crack down on csgo gambling websites, and still massively benefit from it. the whole portal64 thing still feels wrong to me. i don't like the fact that they walked back on their anti-ai content stance. the people make game documentary on working at valve highlights some pretty bad discrimination stuff happening behind the scene imo.

i don't think it's fair to criticise them on not providing an open-source client to download games, or open-source library to access their features - you wouldn't gain much from those being open-source anyways, since the games you play on stem are pretty much always closed source. i don't think it's fair either to say that it's bad that they ship devices with a "proprietary os" - they are the game console manufacturer selling them most open-source device on the market currently, they're doing much better than the alternatives in that regard. i don't know where they've said or suggested they've "invented wine", but i've never heard of that - they could probably disclose more openly how proton works and its relationship to wine, but i don't think they are maliciously behaving as if they created wine/vkd3d/…

i don't think valve's a perfect company, but they're still probably the best one to get most games from. and i don't think it's fair to hate on them for exaggerated reasons, it's much more productive to scold them for stuff they actually did wrong.

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