Here to follow content related to Star Trek, Linux, open-source software, and anything else I like that happens to have a substantial Lemmy community for it.

Main fediverse account: @f00fc7c8@woem.space

  • 1 Post
  • 28 Comments
Joined 2 years ago
cake
Cake day: August 4th, 2023

help-circle
  • I’d say they all offer different types of customization. It’s less a matter of how much you can do, and more a matter of what you want to do and how much time you’re willing to spend working on it. KDE is for people who want to customize their desktop, and want it to be easy to do so. GNOME is for people who just want something that works, but it still offers a lot of customization, it’s just not as well-supported (their philosophy is “if theming breaks an app, it’s not our fault”).

    KDE doesn’t support full CSS customization on its own, but there are theming engines like Kvantum and QtCurve that address the limitations that arise from this. I’d say it’s on almost equal footing with GNOME in that regard, since both GTK4+libadwaita and Qt6+KF6 are designed for color scheme customization, but require various workarounds and obscure settings for anything more than that. If anything the workarounds are easier in KDE.

    Similarly, KDE supports layout customization through widgets and graphical menus. GNOME also supports layout customization, but through extensions instead.

    And then you can do all of the above and more if you use a window manager, or an LXDE/LXQt-style desktop that lets you disable or replace all its components in settings - just mix and match components like panels, file managers, display managers, polkit agents, etc. You can basically build your own DE that way, and it doesn’t get much more customizable than that. But maybe you don’t want to spend your time choosing every component of your custom DE. That’s what something like KDE is for.









  • Debian! It’s stable, elegant, and doesn’t impede customization. I distro-hopped a lot over the years - some that I ended up disliking included KaOS (severely limited software repository), Clear Linux (only way to get ffmpeg was to compile it from source) and Fedora (very slow); most I liked, and just decided to move on at some point. But I kept coming back to Debian, and eventually got to a point where instead of trying a different distro when Debian broke, I would just reinstall Debian.

    I’d be interested to try VanillaOS or another “immutable” distro at some point in the future. See if they’ve matured enough for my day-to-day use.


  • I was quite satisfied with Debian Stable for a few years on at least two different laptops, and felt I had found my “forever distro”, until I got a Framework laptop whose AMD graphics were quite buggy on it. In order to get rid of all the issues, I had to upgrade to Testing and install a mainline Liquorix kernel (and along the way, I briefly made a Frankendebian and fiddled with kernel parameters). While my years of experience with Debian and derivatives has prevented me from breaking anything, I do wish I didn’t have to use all of this beta-quality software just to prevent games from freezing and crashing constantly, just because I bought “new” (about a year old) hardware.

    I still want to keep Debian, because I’ve found nothing else that works quite as elegantly or stably, but I’m hoping to find ways to get the performance I need without Liquorix, and if something forces me to reinstall between now and the time Debian Trixie becomes stable, I’ll probably give Fedora or KDE Neon another try.



    1. Create a source control repository containing all your code, and publish it to an online code forge. GitHub’s docs might help with this: https://docs.github.com/en/get-started/start-your-journey
    2. Choose an open-source license and add it to the repository as a LICENSE file. If you want to require any projects that build upon yours to be open-source too, the GNU GPL is a good choice. If you want to allow proprietary programs to include your library without releasing any source code other than that which is directly based on yours, the GNU LGPL is good for that. If you want to allow people to do whatever they want, even use all your code as the basis of a proprietary program without credit, the Unlicense is a good choice. There are a lot of licenses with different degrees of “copyleft” and attribution requirements in between. Technically publishing with a license file is all you need to do, but there are more things you should do.
    3. Create a README text file describing what your program does, and instructing users on how to compile and run it. Consider including more detailed documentation on how to use it, as well.
    4. Clean up your code and file layout so that it’s as easy as is feasible for other programmers to understand.
    5. Promote your project to whoever you think might find it useful!



  • Unfortunately, the state of Android music players is not great. Currently I have two FOSS music players installed: Metro Music Player (the F-Droid version of Retro Music Player) and mucke. mucke has a ton of really cool features that improve the shuffle experience but it’s actually worse than most apps at pulling album art. Retro/Metro has beautiful UI, and has pretty good features for customization, but lacks the cool features mucke has and is less stable. Both have more than one annoying bug, but it took me a while to find music players that had this few dealbreakers.