• 0 Posts
  • 78 Comments
Joined 2 years ago
cake
Cake day: June 22nd, 2023

help-circle

  • I would be more interested in themed favicon sets like on Android or Linux DE’s, and any way that would avoid Google or lock-in/forced updates to such as with the Play store or Windows I would avoid like the plague.

    Gimme back .dll’s full of icons I can create and edit to my liking. For modernization, meta-text(url or application name) for each icon instead of referencing “icon #x in this .dll”, and a format more usefull than .dll’s full of icons that all have to be the same size(and .tiff, .giff, or bitmaps at that, when jpeg and vector formats exist), but that’s about it.

    All this re-inventing-the-wheel/web2.0/3.0 shit is geared towards creating dependency and lock-in in the stupidest ways possible.






  • https://guardianproject.info/fdroid/

    Basically, if the app developers bother to maintain their own repository, there is no reason for other f-droid repositories to waste storage and bandwidth on duplicating them and constantly checking to be sure its the latest versions of those apps that have been copied. This is a feature, not a bug, in systems like f-droid.

    That said, f-droid could stand to add a directory for known-good repositories, or listings for apps that pull from such repositories without requiring you or I to manually type in a url or scan a QR code, but end of the day, its free softwaree maintained by volunteers.

    Many apps on Linux work the same way; However, in my experience, once you’ve downloaded and installed an application’s .deb, tar.gz, whatever, it will offer to add its repositories to your package manager’s sources, whereas on Android, once you install an .apk, it stays that version until you install a newer version manually or let the Play store or whatever over-write it.








  • I think its less a question of the technical feasibility, and more of an issue that we, as users, don’t want more closed-source blobs in our kernels. Meanwhile, the publishers insist that they can’t open-source their anti-cheat code; Their idea being that if we know what’s in it, it will be easier to bypass.

    Basically, one distro or a few(at most) may get anti-cheat integrated one day(like, say, SteamOS), but it will likely never be in your standard Linux kernal.

    They could go the rought of kernel modules, I would think, but for whatever reason, we’re still having this conversation.