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
  • 51 Comments
Joined 1 year ago
cake
Cake day: August 4th, 2023

help-circle






  • TOS: The Cloud Minders. One of the show's extremely heavy-handed message episodes, this time about classism and labor rights. It's quite dramatically compelling in addition to expressing its ideas eloquently.

    TAS: Beyond the Farthest Star. One of the more "normal" episodes of that series, but it really works for me.

    TNG: Contagion. One of the most tense and action-packed TNG episodes, featuring computer malfunctions both amusing and terrifying, but also a great showcase for all the characters, and their ability to combine their talents to solve what seems like an impossible problem, to the point that it's one of the episodes that got me into Trek in general (alongside Remember Me).

    DS9: Visionary. Pretty good episode of time travel weirdness, and one of my go to examples of what I think is best way to go about explaining time travel: don't explain it, just do whatever wacky shit you want and laugh off the paradoxes with a recurring joke. "I hate temporal mechanics!"

    VOY: Latent Image. In addition to being yet another fascinating exploration of the rights and sentience of artificial life, with a hint of an ethical dilemma in there, I really relate to how the Doctor's trauma responses are described.

    DIS: There Is A Tide. I love all of the scenes between Admiral Vance and Osyraa.

    PIC: The Impossible Box. I remember that being one of the more tense and well-made episodes of the show, especially Soji's existential crisis and Picard's Borg flashbacks, although I find it hard to think in individual episodes with this one.

    LD: Veritas. The show hadn't really clicked with me before this episode. I loved the whole theme about the lack of attention the command crew gives to the ensigns, and how this just adds to their problems.

    I've only really seen the consensus classics of ENT, and while I have seen SNW and PRO, my favorites are all consensus favorites that get a decent amount of buzz already.




  • There isn't an alsa command on my system either, so that's no surprise. But we'll need more information to track down the cause, such as:

    • What (sound) hardware are you using? (try lspci | grep Audio)
    • What happens when you try to play a sound? Does it get stuck loading / at 0:00, show an error, or just play silently?
    • Is your system using pulseaudio directly, or via pipewire? (try pactl info)
    • What shows up in pavucontrol? (Is it detecting your speaker, or just "dummy output"? Is sound muted, and can you unmute?) Try also alsamixer.
    • If you installed non-free firmware, you should have a few lines like deb http://deb.debian.org/debian/ bookworm main contrib non-free-firmware in the file /etc/apt/sources.list. If non-free-firmware is not present, then obviously you have no non-free firmware.

    1. I believe there is still an issue with Windows deleting Linux bootloaders during some updates. You'll be fine if you install Linux on a separate disk, and even if you dual-boot on one disk and the bootloader gets deleted, there are ways to recover it. You don't strictly need to have separate data and OS partitions, and I've gone back and forth on whether I prefer it - it makes distro hopping and disk encryption easier, at the cost of potentially inefficient use of space and serious consequences if your OS partition fills up.
    2. Disk encryption is very straightforward if you use separate OS and data partitions. You literally just tick a box during the install and enter an extra password. It won't upset Windows any more than a normal install does (i.e. Windows might think it's corrupted, but won't do anything without your input). With one partition for everything, it's still possible, but the encryption will be much weaker and handled by the bootloader in a somewhat clunkier way, and I'm not sure if Mint even supports that setup.
    3. I don't have much experience with this myself, and certainly not on Linux Mint, so I'll leave this one to other commenters.
    4. Synaptic is just a fancy frontend to APT, and I think Mint also has something called mintInstall, which was just an apt frontend back when I used it, but I think it also supports Flatpak now. It's entirely up to personal preference as to which UI you prefer. I do recommend you set up Flathub if it's not there by default, as it gives you access to a ton of useful apps that can't be packaged by Debian, Ubuntu, and Mint for various reasons.
    5. Don't download software from random websites unless it's absolutely necessary. Chances are, their version either won't work well, if at all, or will break your system. Try APT first, Flatpak second, everything else is a last resort option. If a program you used on Windows doesn't have a (working, native) Linux version, try finding and learning to use an alternative that is in the APT repositories before downloading the Windows version and using it on Wine. Back up your most important files from Windows before installing Linux in dual boot, just in case you make a mistake somewhere. To answer the last question, stick to the default terminal emulator and Firefox installation unless there's a feature you really want in another one; the distro's developers picked them for a reason, after all.

  • This is an interesting comment, actually, because instead of hating on the new shows and comparing them to the old ones, Matt's hating on the old shows for being politically correct and saying DS9 and Voyager, the shows that were currently airing as of 1999, are the good ones. Even though DS9 was more diverse and less subtle about its themes, compared to TNG.

    Imagine if Dave Cullen, Doomcock, Midnight's Edge, Nerdrotic, etc. dedicated their careers to saying that the new Star Trek shows were AWESOME because they were less woke than TNG and DS9. That's what this is.


  • I haven't had much experience with Kubuntu, but I do know it has more preinstalled apps, slightly older versions of those apps (where KDE Neon has the latest version of every KDE app the day it releases), but slightly newer non-KDE apps in the non-LTS releases, and is more beholden to Canonical's decisions, such as advertising Ubuntu Pro during upgrades or forcibly installing some programs as snaps. Kubuntu might hold your hand a bit more under certain circumstances, while KDE Neon keeps things simpler, but the difference in ease of use is not that significant, especially if you have any experience with Linux in the last ten years or so.


  • Any software that is in the Xubuntu repositories will also be available in other Ubuntu derivatives, and most likely Debian and all its derivatives as well. Only the official spins are likely to advertise Ubuntu Pro.

    Mint XFCE is a good replacement, but I'm also partial to KDE Neon, which keeps preinstalled software to a minimum and is by far the most performant KDE distro I have tried. I myself use regular Debian, with KDE, though you can choose XFCE during the install.




    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!