I went for the simplest option

1. Installed a distro (in this case Debian)
2. Installed tailscale on the server, logged in
3. Installed tailscale on my other devices, logged in
4. Used sshfs to mount the desired directory on the server to my client
5. SSH in once a week or so to run updates

Found it very simple. Avoided the tedious setup of samba and samba had weird reliability issues for me when copying large files. Took a bit to learn how ssh works, but very much so worth it.

Flatpak recently got a method of preinstalling flatpaks.

A flatpak cannot install a snap on your system. Apt can install a snap because when apt installs and updates packages, it can also run scripts as root. That’s insecure and potentially dangerous, so flatpak doesn’t have that ability.

All of those, apart from loop devices, are not technical limitations, but results from Canonical’s poor management and monopolistic desires.

Snap is interesting for me it can do more things than flatpak and has some really interesting sandboxing features coming up such as permission prompts for filesystem access.

But Canonical management is a significant hindrance. The Snap Store simply cannot be trusted after so much malware got in and they still have not improved their processes. So many snaps including Canonical’s own, are still using core22 for some reason. And there’s the broken snaps Canonical pushed on users.

I would love to see a snap repo that takes the best parts of Flathub and Fedora Flatpaks. Because as a technology, I think snap beats flatpak (if you’re using AppArmor). But it’s Canonical’s poor management that really drags it down.

But as an actual option or not? I think OP is referring to those who say “I’m going to switch to Linux” like those politicians to pay so much lip service to freedom, democracy, privacy while at the same time voting to erode all of those. The implication being that they won’t actually ever switch to Linux.

You can tinker for the most part, it’s just done differently. In the Universal Blue world, that would be creating your own OCI container using their image template or blue build.

The nice thing is that it makes the OS much more reproducible than imperative commands and scripts.

Not a security issue, copyright/license issues.

In my experience, many Gnome apps make doing complex tasks pretty easy compared to third party apps. However, it is at the cost of customization and questions like “why can’t I do this???”

But in general, Gnome’s simple design works for me, most things feel clean and polished. I don’t need the vast majority of features offered.

In the cases where Gnome’s default aren’t powerful enough, often times the KDE equivalent isn’t good enough for me either despite offering more features and customization.

As an example, Gnome Text Editor vs Kwrite and Kate. GTS has the basics I need like line numbers (Apple’s text editor does not have this…) and that fits 80% of my needs. But what about more advanced things? Well, no markdown support but I don’t think Kate has that either. What about coding? I’d rather use a dedicated IDE than Kate or GTS.

The bar is meant to be very minimal and not distracting.

It takes up space, sure, but it’s close to the minimal height while still having easily readable time up top

No, it’s a limitation with swaybg so they created a tool that doesn’t have that limitation.

“We do <thing > because we always did before <thing 2>” is not a good point

I didn’t mean it in a “this is better way”. I’m just saying that Wayland was designed around the idea of client side decorations, not server side decorations. Gnome has stuck to the more purist vision of Wayland, which makes sense since I believe they were its biggest proponent.

That can be dropped eventually too. Compositors like Niri don’t implement Xwayland support directly, and instead use Xwayland Satellite.

The for argument is basically the following

• Wayland as a protocol was designed around CSDs, protocols for SSDs came years later
• Having the client control the CSDs simplifiies things for the compositor and apps
  • The compositor has less things to implement and test
  • Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows
  • It’s difficult to coordinate things between the client and compositor.
    • Something that annoys me about KDE is that they do this headerbar look where the top part of the application will match the color of the the titlebar. However, the top part of the application is drawn by the application and the titlebar is drawn by the compositor. But when the color changes (such as going from unfocused to focused), they do not update at the same time, so for a frame or few the top part of the application is a different color than the titlebar. That wouldn’t happen under CSDs.

I hope the performance significantly improves by then. Beta 1 felt pretty rough to me. And also, animations.

The main reason I hear is that it maximizes screen usage and helps avoid/limit the tediousness of having to manage windows.

Not what you’re asking for, but I’ll give you my perspective as someone who’s tried tiling on and off and overall don’t like it.

1. Applications work best at certain aspect ratios, having them automatically tiled to different aspect ratios can be annoying
2. Some windows windows/pop-ups have no business being tiled. Like some Yes/No dialogs (not all windows specify a max size which would avoid triggering the tiling) or a simple calculator. And you can specify which ones to have floating, but it requires setup.
3. Sometimes it ends of causing more work than floating environements. Most of the time I only have a max of 2 windows open, but occasionally I’ll quickly try to do something then end up with 4-5 windows, at which point that’s too many windows and I need to reorganize stuff to continue working. But that usually wouldn’t be an issue in a floating environment.
4. Worst of all, just setting up a tiling environment is a nightmare. You have to configure the actual compositor/WM, which tools you want to use with it (bar, launcher, screenshot tool, notifications, screenlocker, etc) and configure all those too, ideally with some basic theming to make them look coherent. But inevitably you end up with missing functionality especially in the modern area where an app might be sandboxed or expecting all xdg-portals to be implemented, which most compositors don’t do.

As it stands today, sudo-rs is the default sudo implementation on Ubuntu 25.10, and uutils’ coreutils has mostly replaced the GNU implementation, with a few exceptions, many of which will be resolved by releases in the coming weeks. These diversions back to the existing implementations demonstrate that stability and resilience are more important than “hype” in our approach: I expect us to have completed the migration during the next cycle, but not before the tools are ready.

https://discourse.ubuntu.com/t/ubuntu-25-10-a-retrospective/69127

Yes. They also reverted some of the still unfinished stuff to use the Gnu versions until the Rust versions are ready.

True, but my issue with OpenBSD is that the performance is really lacking in terms of desktop smoothness. It feels like sub 60 fps compared the smoothness of Linux and FreeBSD.

I hope it’s just a current driver incompatibility and not related to their hardening. Will try again once 7.8 releases.

Maybe Secureblue?

That also comes with its own hardened browser based on GrapheneOS’s.

And if you don’t go with Secureblue and its browser, I’d recommend using a browser Chromium based, probably Brave. I know that’s a controversial choice, but in terms of security and ad blocking, it’s one of the better options. And disable JIT for V8.