![](https://beehaw.org/pictrs/image/1be75b15-2f18-429d-acf7-dcea8e512a4b.png)
If we talking about modern Android, good to know. I used to run a launcher on a modded Samsung Galaxy Young (CyanogenMod11) that had a fixed notification option to prevent Android from killing it (the device had 512MB of RAM).
a fat italian
Accept people for what they wanna be, its not that hard…
If we talking about modern Android, good to know. I used to run a launcher on a modded Samsung Galaxy Young (CyanogenMod11) that had a fixed notification option to prevent Android from killing it (the device had 512MB of RAM).
You used to be able to just create a fixed notification and Android would never kill the app. This is not the case anymore?
Maybe because that actually stopped getting updated, and a fork continuing it exists?
I use Newpipe
Flatpak is definitely a possible solution. We will see how it will be managed in the future
To allow modern windows to run legacy applications a lot of caution is given to updating libraries or fully new ones are given while keeping the older ones. Also static builds are more common on Windows, or come bundled with a copy of the required libraries as .dll files.
libexample1
. It works, the library is available too.libexample2
gets released that drastically changes how the library works. The program doesn’t work on this version. The older release of the library then get’s abandoned.Aplication could have still worked if it came bundled with its own copy of libexample1 and of its dependencies, or was statically linked.
An example of this is Nero, a software kit for managing CD/DVD disc media. They made a build of some of their tools for Linux, meant to run on Debian 7. This builds were an experiment and got abandoned because of the very few users it had. Yet, these tools still work perfectly fine on Debian 12 despite being based on ancient libraries because it bundles all its requirements as a copy in its own proprietary blob.
I talked about caution on updating libraries on Windows. You can find many deprecated methods in any native Windows library that will likely never be removed from the library binaries, as many applications require it. The new, better and more feature rich method is given a different name instead, and is pointed out in the documentation for the older method.
Projects like FUSE are very nice for this, where an AppImave bundle of prebuilt binaries is given and can potencially not only be ran everywhere that can run FUSE but also in the future too.
Shows how useless those “image poisoning” services some artists boast about really are
You might have to due to licensing, if the technology is patented. I don’t know about this
It has the weakest hardware of its generation. During those years you had the Sega Dreamcast, Microsoft Xbox and Nintendo Gamecube. All this consoles had a more powerful hardware than the Sony Playstation 2
What does this have to do with anything
uname -a ?
No 🥲
I tried just now as it happened again. Killing the app in use doesn’t make the keyboard work again in X11 apps.
Are you sure its a similar issue? Because usually closing the window actually doesn’t solve it, as then reopening another X11/XWayland window will still not register keyboard presses. I am adding some more info to the post right now.
I was much more inexperienced in Linux at the time, I could probably fix it now if the same thing happened again.
Removed by mod
Debian sid a few years ago: Uninstalled Python2, system became unusable and couldn’t neither reinstall from APT neither recompile it
A TAS to game crash already existed.
Compiling a personal project of mine with Windows 2000 as minimum Windows platform right now
I miss the days of Android 4.4 so much