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

  • 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: August 4th, 2023

help-circle





  • For me, the outdated packages in stable have actually gotten better over time, as DEs get closer to a place where I don’t need any major updates to enjoy using them, Flatpaks become more readily available, and on a subjective level, I get less and less invested in current Linux news. Before Debian became my “forever distro”, I’d hopped to it a few times, and often found myself wishing for a newer piece of software that wasn’t in backports or flathub, or simply being bored with how stable it is, but that’s been happening less and less. And I feel like Debian 12 in particular left me with software that I wouldn’t mind being stuck with for two years.

    I’ve gotten warnings to upgrade my browser with Debian’s Firefox ESR, but they never affected a website’s usability in a way that a newer version would fix, and they do provide security updates and new ESR series when they come out; even if you must have the newest Firefox, you can use the Flatpak.

    Additionally, I’m currently on testing in order to get better support for my GPU, and each time I’ve tried to use it, it’s worked for me for a longer time than the last as I get better at resolving or avoiding broken packages. If you do experience issues like the one you described, and can replicate them, and no one else has already reported them, you should report them to Debian’s bug tracker. The whole point of Testing is to find and squash all the critical bugs before the next stable releases.



  • 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.


  • There was still Wine, and PlayOnLinux helped further, but when I looked for a game I wanted to play on WineDB, there was no guarantee it even had an entry, and if it wasn’t listed as “platinum”, the chance of you experiencing any reported issue was very high.

    Not to mention, playing Steam games that weren’t native was an impossibility.

    Thankfully I was more of a console gamer at the time, and I got a lot of enjoyment out of the few games that received Linux ports - like Team Fortress 2!



  • Most regular distros are good enough for gaming. The only issue you’re likely to run into is with graphics drivers (I recommend going for AMD graphics on that build), and the availability of certain software in certain formats (gaming software is more likely to be available for Debian or Ubuntu based distros).

    If you like the Steam Deck’s desktop mode, you might enjoy another distro with the same desktop environment (KDE Plasma). I’m partial to KDE Neon, a snappy Ubuntu LTS spin with all of the latest KDE software.






  • Depends on a few factors, AFAIK as a non-lawyer. If the license allows closed-source derivatives (i.e. is permissive rather than copyleft), then anyone can create a closed-source version with all of the contributors’ changes, including the original maintainer. And anyone can choose to keep it open-source. The community contributions still to some extent belong to the contributors, though the license waives most of their rights.

    Some projects are copyleft, but contributors are required to sign a license agreement (a CLA) which allows a single entity to change the license as they desire, including to closed-source - this is a good reason to avoid such projects. The contributors don’t own their work in such a case, but they can still fork the old project as it was before being taken closed source.

    In a copyleft (e.g. GPL) project with no CLA, it’s illegal for anyone to make a closed-source version, and a major contributor could sue even the maintainer for doing so.

    In all such cases, the change to a closed-source model does not erase the existence of the open-source code with community contributions. A fork is always possible.