Very cool! A while ago I found that instead of using fractional scaling, things were smoother for me if I set Gome’s text scaling factor in accessibility settings. I think most GTK UI scales based off that value? It’s pretty helpful for me, even though I’m not actually using Gnome anymore. But if fractional scaling support has gotten better, maybe I’ll switch my approach.

I’m very glad I switched. One of the little improvements: IIRC last time I checked PaperWM didn’t have bindings to set a window to a specified width. It only had a cycle width option. With Niri I have shortcuts to set a window to ¼, ⅓, ½, ⅔, or ¾ of the screen width.

There are lots of other improvements. One of my favorites is the dynamic screen cast target.

Good question! I think this is distinct from split tunneling, but does a similar thing. But I’m not an expert - I don’t know how precise or broad the definitions are, so I’m not positive the concepts don’t overlap.

From some brief reading it looks like split tunneling is set up by configuring routing to determine which traffic goes through the VPN based on destination IP addresses. OTOH what I’m calling confinement determines VPN use based on which process sends traffic. So with confinement all traffic from select processes, regardless of destination, goes through the VPN.

I think there are differences in how inbound traffic works too. With confinement inbound traffic can only reach confined processes.

This is the BS I came to this thread for!

And as I just recently learned, network namespaces support! Those can be handy if you need a backup job to route through a VPN tunnel, or some such thing.

I can’t think of a good story from personal experience, so I’ll share a wild objection from some guy on the internet from, I think 2007. The story pops into my head from time to time. This guy insisted that it would be impossible to create an entire OS that can run from start to finish without the resources of a major software company. He argued that therefore Linux must actually be a pirated, reskinned version of Windows. https://danielandrade.net/posts/linux-windows-misconceptions-tech-story/

I checked the Wayback machine to try to find more messages from that thread because I think he kept posting and doubling down. But pulling up ancient ZDNet forum posts is slow enough that I gave up.

As a gamer myself I don’t think it’s appropriate to try to deprive someone of a hobby that they genuinely enjoy. As a long-time Linux user I stick to games that work well on Linux, like Overwatch. But unfortunately games aren’t interchangeable - if League is your thing, Dota might not be an acceptable substitute.

Better to argue for dual booting than to try to cut off a friend’s personal relationship with their game.

Ahhh, for some reason I had it in my head that rebooting cleared the syslog

To see logs from only the previous boot run,

journalctl -b -1

My family uses Discord heavily, and I’ve set up a number of different distros and window managers at different times, all using Wayland, and I have not seen this issue. I think that includes running in browsers using Xwayland, and using native Wayland - but I’m not 100% sure because I’ve been running browsers in native Wayland mode for a long time, while my family members usually use the Discord Electron app.

There might be some more specific issue on your system, like a pipewire misconfiguration? Do you use pipewire?

Oh yeah, I should clarify that - and I might have overstated the issue.

When you roll back, either by selecting an old entry in the boot menu, or using the nixos-rebuild command you do get an exact replica of the packages from the generation you rolled back to regardless of whether you use channels or flakes. So that’s good.

The issue comes up in scenarios like these:

• Something’s not working for you with the latest nixpkgs. You roll back to, and that fixes things. But the next time you run nixos-rebuild switch you get packages from the current channel state again, the one that wasn’t working, and things break again.
• You want to roll back nixpkgs, but keep your latest configuration changes.
• You want to go back to an earlier state by getting the old version of your configuration files instead of using the generation manager. For example if you keep your configuration version-controlled with git, reverting to an earlier commit of your configuration history, and running nixos-rebuild switch

In all cases if you’re using flakes you can roll back nixpkgs by using an older version of the flake.lock file which lets you time-travel nixpkgs independently of changes to other configuration files. With channels you can’t manage the nixpkgs revision with your configuration files. You have to go through some manual steps to reset the channel to the nixpkgs commit you want. It can get more difficult if the commit you want was garbage collected from your local system in the meantime. See https://discourse.nixos.org/t/how-to-roll-back-channel-to-currently-active-version/43161

In my experience upstream nixpkgs rarely break things, and reverting to an earlier nixpkgs revision is not the best answer. But every once something happens, like a failure in hydra means some package isn’t in the binary cache, and it’s too much for me to build locally (this happened with Electron a few weeks ago), so I can’t use the latest packages until hydra catches up; or there’s some configuration update I need to make for the latest packages, and I don’t have time to work on that for a bit.

I think there are arguments for NixOS for a casual user despite the learning curve reputation. But there are also downsides to consider.

The pros:

• There is a good, user-friendly installer that makes it easy to get a working system
• From what I can see setting up KDE is pretty easy - there are configs online that you can paste into configuration.nix without modification
• NixOS is good for gaming with proprietary drivers and Steam - again it’s a matter of pasting a few lines of configuration
• Like with other distros it’s easy to recover if something breaks
• Unlike with other immutable distros you get a lot of options for tinkering with your system, and experimenting. You can dip your toes into the advanced stuff, going from casual user to Linux expert at your own pace, with the safety line of being able to roll back changes at any time.
• If you stick to the basics you can have a very stable, very update-to-date system without much difficulty.

The cons:

• To get the full safety of rolling back a previous point in time you need to ditch channels, and instead use pinned nixpkgs revisions. The best way to do that is probably using flakes - but whatever strategy you use you need to depart from the setup the installer gives you, and learn enough to remake your configuration.
• You’ll find contradictory instructions depending whether they’re written for use of channels or flakes.
• Going beyond the basics of installing packages, and using premade NixOS modules gets you into the infamous learning curve. For example I’m guessing that managing kwin scripts declaratively in Nix config might be an adventure. But managing them by hand the way you do in Fedora might be the same. (I haven’t tried this, so I’m not sure.)
• There is some stuff you have to know, like if you want to run binaries that weren’t built for Nix you want to set up nix-ld first.
• If you’re building software you have to learn to do things the Nix way because of the lack of FHS. That’s great for Nix fans like me, but frustrating for some.
• There is no graphical software center, nor automatic updates. You have to use the workflow of installing stuff by editing your config file, and get used to using search.nixos.org to find stuff. This is a pro from the perspective of having a stable system that can be rolled back to earlier states, but might feel less user friendly than a GUI workflow.

Even if you set up flatpak (which is easy to set up tbf) you’re probably going to be managing flatpaks using the CLI.

It would be easier for me to recommend NixOS if the installer set up a flake configuration with more niceties pre-installed, like nix-ld. The next best thing would be a de facto standard flake starter configuration for people to copy. But like I said, I think there is a case.