Whooping_Seal

joined 1 year ago
[–] Whooping_Seal@sh.itjust.works 1 points 2 months ago

Some older consoles have very negligible size libraries in modern day terms, and who knows what sources of ROMs will be taken down by lawsuits in the next few decades. I feel like there is some sense in making a complete archive of a systems game library, but for my personal use I usually just download / dump / rip what I need specifically.

[–] Whooping_Seal@sh.itjust.works 8 points 2 months ago* (last edited 2 months ago) (1 children)

Whatever file format I use them in is also how I back them up, I backup my entire desktop's and laptop's data to an external hard drive and an online service provider. I'm sure a compressed format would be more space efficient but that would take much more time given my use case.

In the case of my laptop it runs Linux and the filesystem I use supports "transparent compression" (almost all contents of the drive are compressed with zstd), so I'm guessing any of the ROMs on there will have already been compressed as nuch as they can (but I'm not knowledgeable enough on the file format specs)

[–] Whooping_Seal@sh.itjust.works 8 points 9 months ago

I understand why they wouldn’t want to suddenly change the branding of existing projects though.

I'm not sure if I agree, I feel like the long term damage of keeping the names is greater than changing them now to Fedora Plasma Atomic (Formerly Kinoite) / Fedora Atomic Workstation (Formerly Silverblue). Leaving them as is, is just going to create more confusion in the future to new users who won't immediately understand why the naming convention is different for the other spins and will create more confusion for documentation / support threads online.

[–] Whooping_Seal@sh.itjust.works 6 points 9 months ago (2 children)

I feel that I am 50:50 on it, immutable at least conveyed more information about what it is while Atomic feels a lot more "buzz-word-y" and does not convey as well what it means. Regardless, I'd say the bigger issue is keeping the old Silverblue & Kinoite names, they really should change them even if it means having a ~2 year period of having "Formerly Silverblue / Kinoite".

[–] Whooping_Seal@sh.itjust.works 2 points 9 months ago* (last edited 9 months ago) (1 children)

Thank you for the very thorough reply! For god knows what reason I get this error: error: app/org.mozilla.firefox/x86_64/stable not installed when running the xdg-open firefox-reader command, yet manually running flatpak run --user org.mozilla.firefox about:reader?url=https://example.com works just fine. I'll have to troubleshoot it when I have a bit more time ;p

Thanks again for your very thorough write up and the linked articles. Have a good day :)

Update: It seems like on my system, the --user flag was the issue, removing it made the script function. I am using Fedora Kinoite (Immutable version of KDE Plasma), so perhaps it is just a difference in how flatpak is configured between distros? I'll have to read into it more later.

[–] Whooping_Seal@sh.itjust.works 2 points 9 months ago* (last edited 9 months ago)

I'll keep my answer focused on KDE Connect as I no longer use a TWM. You can most definitely use KDE Connect in non-Plasma environments. For non-Plasma (and non-Gnome ^*^ ) environments you can just install the kdeconnectd package. Then, to start the KDE Connect daemon manually, execute /usr/lib/kdeconnectd. You can schedule this to autostart as a systemd unit, or in the config for your TWM (I know in sway/i3 you could start it, I'm assuming it is similar for many other options)

If you use a firewall, you need to open UDP and TCP ports 1714 through 1764. If you use firewalld specifically, there's an option to enable KDE Connect rather than manually specifying it. This also let's you have it only work on private networks and not public if you so chose.

See Arch wiki for more details

*For gnome I would recommend using gs-connect even if you have a tiling extension

£ KDE-Connect: does that work on TWMs? Is there a good implementation? Can I use GSConnect elsewhere too?

 

I was wondering if anyone else has encountered the same issue as I have. I know how I would approach this if Akregator was installed on the system rather than as a flatpak, I would just change the command run by the app when opening in an external browser to flatpak run org.mozilla.firefox about:reader?url=%u which just appends the about:reader portion to automatically open it as such. This command does work from my terminal but naturally does not work with Akregator.

Any help would be greatly appreciated!

 

Update: The guide on github has been updated and has addopted a different method. Notably, it: A) still accomplishing my goal of avoiding running the process inside as root. B) uses the linuxserver.io image rather than the syncthing/syncthing one (my method does not allow for the linuxserver.io image to run), the linuxserver one is based on alpine, I truly forget what the other one is based on.

An archived version of the guide I followed to create my setup has been placed bellow, the updated (and all subsequent version) can be found here

I saw this guide discussing how to run Syncthing in a podman container on immutable OSes and decided to try and create a better solution that avoids running the process inside as root. I am new to podman and it's been a few years since I used docker so I am a novice in this side of system administration and I guess I am writing this as a "sanity check" for what I have done.

Below is the podman run arguments I used in place of the ones found in the article, I also manage it with systemd as shown in the article.


podman run -d \
  --name=syncthing \
  --hostname=syncpod \
  --label io.containers.autoupdate=registry \
  --userns keep-id \
  -p 127.0.0.1:8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v ~/.config/syncthing:/var/syncthing/config:Z \
  -v ~/SyncedDirs/:/SyncedDirs:Z \
  -v ~/SyncedDirs2/:/var/syncthing/SyncedDirs2:Z \
  docker.io/syncthing/syncthing:latest

Note: I feel the original guide does not explain what the :Z flag does very well, it should at least emphasize unknowing users that it is telling podman to change the SELinux label of a dir to match that of the container.

The notable changes in my arguments is the --userns keep-id option and switching from the linuxserver.io version to the syncthing image. The keep-id option from my understanding tells Podman to create a user namespace where the user and container map to the same UID:GID values. Allowing all files the container touches to still be used by me, the user. I had to switch from the linuxserver.io version to the syncthing official one because the former did not allow the --userns keep-id option to work (perhaps because it is based on Alpine Linux? I have to investigate more. It failed on running an add-user command if I recall)

Below is an excerpt from a RedHat article describing the --userns keep-id option, square brackets are mine:

User namespace modes

I can change this default mapping using the –userns option, which is described in the podman run man page. This list shows the different modes you can pass to the –userns option.

  • Key: "" (Unset) [Effectively what the original guide did]

      Host user: $UID
      Container user: 0 (Default User account mapped to root user in container.) (Default)
    
  • Key: keep-id [What I am doing]

      Host user: $UID
      Container user: $UID (Map user account to the same UID within the container.)
    

(Source)

So far this method seems to work quite well, and has replaced the syncthing package I had layered for a while. Is this the best way to run it on an OS like Silverblue / Kinoite, or is there a more sensible route to go? Any feedback is appreciated!

Edit: Clarity and grammar, and some more detail in a few spots.