Frankly, I welcome multiple unixporn communities, as the largely singular community on reddit was too strict, in my opinion, and many screenshots went unshared as a result.

I can’t provide specific advice for tailscale, but I can share my notes for my own use case, which is for PCs that are safely behind the home firewall. You’d want to adjust your ssh/smb settings accordingly. You shouldn’t need any rules for ProtonVPN, as you’re likely just trying to block incoming connections, not outbound.

It’s my understanding that Fedora opens ports 1025-65535/tcp and 1025-65535/udp by default.

To lock down to sane defaults (--permanent saves the settings directly, avoiding the need to run firewall-cmd --runtime-to-permanent separately):

sudo firewall-cmd --permanent --remove-port=1025-65535/tcp
sudo firewall-cmd --permanent --remove-port=1025-65535/udp
sudo firewall-cmd --permanent --add-port=27031/udp  # steam remote play
sudo firewall-cmd --permanent --add-port=27036/udp  # steam remote play
sudo firewall-cmd --permanent --add-port=27036/tcp  # steam remote play
sudo firewall-cmd --permanent --add-port=27037/tcp  # steam remote play

Ensure that ssh and samba-client are listed as allowed services too (sudo firewall-cmd --list-all).

• Firewalld must be reloaded before rule changes will take effect: firewall-cmd --reload
• Changes will reset upon reboot unless made persistent by using --permanent or by committing all changes with --runtime-to-permanent

Common commands:

sudo systemctl enable --now firewalld   # enable and start firewalld service
sudo systemctl disable firewalld
sudo systemctl stop firewalld

sudo firewall-cmd --state               # show running state of firewalld
sudo firewall-cmd --get-active-zones    # list active zones
sudo firewall-cmd --get-zones           # list all zones
sudo firewall-cmd --get-default-zone    # list default zone
sudo firewall-cmd --list-ports          # list allowed ports in current zone
sudo firewall-cmd --list-all            # list all settings
sudo firewall-cmd --reload              # reload firewall rules to activate any rule modifications

Add/remove ports, services, IPs:

sudo firewall-cmd --add-port=port-number/port-type      # allow incoming port  (tcp,udp,sctp,dccp)
sudo firewall-cmd --remove-port=port-number/port-type   # block incoming port
sudo firewall-cmd --add-service=<service-name>          # allow incoming service (see /etc/services)
sudo firewall-cmd --remove-service=<service-name>       # block incoming service (see /etc/services)
sudo firewall-cmd --add-source=192.168.1.100 (or 192.168.1.0/24)    # whitelist incoming IP or IP range
sudo firewall-cmd --remove-source=192.168.1.100 (or 192.168.1.0/24) # remove whitelisted IP or IP range

Block an IP or IP range (rich rules):

sudo firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.100' reject"
sudo firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='192.168.1.0/24' reject"

Whitelist IP for specific port (rich rule):

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

Removing a Rich Rule

sudo firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'

As a fellow Atomic user, my completely biased opinion is that you’ve made a good choice of distro for switching from Windows.

Don’t sweat the need or desire to layer a few packages. I see a lot of folks stress over this as if it’s a hard rule they are breaking. It’s a general recommendation and little more. I would be surprised if most users don’t layer at least one package (or even a few).

On my main workstation, running Kinoite at the moment, some of the layered packages include:

• distrobox
• gdm (sddm refuses to respect autologin)
• kate
• ksystemlog
• syncthing
• vim-enhanced
• virt-manager
• virt-viewer

Same, I’ve switched all of my workstations to Kinoite and Silverblue over the past 18 months, and couldn’t be much happier about it.

That’s a great post too, thanks for sharing it here. My hope is that folks might still manage to find this info through search engines, even if Lemmy isn’t yet as highly indexed as other platforms.

And I don’t even care if they keep it as a “tray”. I’d be content with integration into the dash if they can make it work smoothly. For example, just having the app start minimized as a regular icon (or segregated icon) in the dash…just something at this point.

I’m happy to see it’s finally happening, and I hope they left its implementation flexible.

What I’d really love to see (aside from triple buffer) is a real solution to the system tray situation. AppIndicator is problematic for some apps and under certain X11/Wayland desktops, and even when it works well it is cumbersome to use compared to traditional tray implementations. Hoping we see a new approach soon.

In the meantime, I’ve been enjoying a revisit to KDE Plasma under Kinoite and I have to say I’m really impressed with both DEs!

No worries, the screen should always lock after sleep or idle regardless of SDDM. KDE uses a separate kscreenlocker app for that functionality once your desktop session has started. It’s worth noting the kscreenlocker doesn’t rely on the SDDM theme in any way, as the two are completely separate processes. So, your lock screen will always match your active KDE theme.

Just a suggestion…if you’ve enabled disk encryption during installation, consider enabling autologin for SDDM so you’re not having to enter two credentials at boot. You’ll rarely ever see your greeter again, so it won’t really matter which theme is used.

And if you did not enable disk encryption, consider doing so as the security and privacy benefits are significant for most users.

Like X11, xwayland is not as secure as a pure Wayland environment but I think it’s important to note that hundreds of thousands of desktop Linux users are likely still running X11.

So, in my opinion, it is not ideal to run xwayland but still completely acceptable for most users who don’t have special security requirements.

Yep, you would just run a couple of commands in a terminal which would reset your layered apps and rebase to a ublue build of your choosing:

https://universal-blue.org/

Oh I’m well aware of X11’s shortcomings, and it’s a band-aid fix until Wayland and/or the DEs sort these capabilities out. If that day doesn’t come within the next year or so, I’ll consider other options then.

I don’t know the answer offhand, but one thing I would do is see whether Mpv is equally effected. By default, the number keys 1-8 will control those settings.

I run the flatpak versions of KeepassXC and Firefox. In order to enable auto-type, I disable Wayland for both apps via Flatseal (enabling fallback to X11). Works fine in KDE and GNOME, though GNOME now prompts to share the display once per session…something to do with how the portals work now.

I have to admit one of the first things I do when setting up a Fedora atomic distro is disable the Fedora flatpak repo and replace all existing apps with Flathub equivalents. Still, good info to keep in mind!

I’m sorry to hear of your bad experience. Four of my Intel/AMD workstations are running Fedora Silverblue and Kiniote and I’ve thankfully never experienced the same. Either way, I’m glad you’ve found some success with Arch. It’s still my go-to for the command line and all container work.

And if you already use uBlock Origin for adblocking, you can simply enable the cookie-notice filters and avoid needing to install another extension:

This is old news and long-since resolved by RPM Fusion and/or flatpaks.

They’re probably talking about Fedora dropping the h.264, h.265 and VC1 VA-API support back in 2022 for legal reasons due to patents:

https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API

It’s largely a non-issue as you can easily install the patched Mesa from RPM Fusion, and I believe all Flatpaks incorporate the codecs already.

Don’t get me wrong, Arch is great and it will always have a place in my heart, but I also think Fedora is a top-tier project and I completely understand why they weren’t comfortable risking patent law unnecessarily.

I can’t speak to Nobara, but Arch with KDE would be my vote if tweaking, documentation, and freshness (with potential instability) are the priorities.

Arch wins with respect to documentation; hands down, it’s the best documented Linux distro in existence. KDE provides a ton of customization via GUI, and gaming is easily obtainable and quite good on any distro, largely due to Flatpak.

Where you might run afoul is the command line. I couldn’t imagine running Arch without regular terminal use, but I’m sure you could get by for most tasks once KDE is up and running.