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

Oh, kanata looks great! Good to know!

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?

In the earlier days of Wayland I was not able to reproduce the custom keyboard mappings that I set up with xkb. Xkb worked, but only in windows running under Xwayland. I know the common xkb presets, like changing caps lock to a control key, are reproduced in Wayland implementations. I had really custom mappings that required more general remapping capability.

I fixed my setup by building a keyboard with a microcontroller that I can program with ZMK. It’s a better setup, although it did take more time, effort, and money. The bottom line is I’m enthusiastic about Wayland, even though I had to find another way to reproduce one of my favorite features.

I got my kids started on Scratch - I recommend it! Syntax is communicated with puzzle block shapes. Statements have a tab on the bottom, and a matching slot on top; number and string values are pill-shaped; boolean expressions are diamond-shaped. If the pieces fit together, it’s a valid program.

As a NixOS user, any drama that might be going on doesn’t affect my use of the software

I use a chat interface as a research tool when there’s something I don’t know how to do, like write a relationship with custom conditions using sqlalchemy, or I want to clarify my understanding on something. first I do a Kagi search. If I don’t find what I’m looking for on Stack Overflow or library docs in a few minutes then I turn to the AI.

I don’t use autocompletion - I stick with LSP completions.

I do consider environmental damage. There are a few things I do to try to reduce damage:

1. Search first
2. Search my chat history for a question I’ve already asked instead of asking it again.
3. Start a new chat thread for each question that doesn’t follow a question I’ve already asked.

On the third point, my understanding is that when you write a message in an LLM chat all previous messages in the thread are processed by the LLM again so it has context to respond to the new message. (It’s possible some providers are caching that context instead of replaying chat history, but I’m not counting on that.) My thinking is that by starting new threads I’m saving resources that would have been used replaying a long chat history.

I use Claude 4.5.

I ask general questions about how to do things. It’s most helpful with languages and libraries I don’t have a lot of experience with. I usually either check docs to verify what the LLM tells me, or verify by testing. Sometimes I ask for narrowly scoped code reviews, like “does this refactored function behave equivalently to the original” or “how could I rewrite this snippet to do this other thing” (with the relevant functions and types pasted into the chat).

My company also uses Code Rabbit AI for code reviews. It doesn’t replace human reviewers, and my employer doesn’t expect it to. But it is quite helpful, especially with languages and libraries that I don’t have a lot of experience with. But it probably consumes a lot more tokens than my chat thread research does.

I haven’t used Forgejo, but from the docs it looks like it’s actions system is nearly identical to Github’s. And yes, that sounds like a good case for a scheduled workflow

Of course I did the troll voice!

I tried reading Men at Arms aloud to my tweens recently. I found it difficult to adapt the narrative and frequent scene changes to spoken word. Unfortunately that didn’t endear my kids to the series. I’d like to try again with a different Discworld novel.

Actually now that I’m thinking about it I had an easier time reading the Tiffany Aching books aloud some years ago.

I’ve done that too, and it’s not the same IMO. Ansible doesn’t put entries in the boot loader for older system states you can boot into in case you break something. It’s possible that Ansible configurations aren’t idempotent. The exact versions of packages that get installed can’t easily be managed with Ansible if you’re also regularly updating packages. There’s lots of stuff that is much easier to configure with NixOS and Home Manager. I found my Ansible configs were always out of date, which doesn’t happen with NixOS where editing the config file is how you make any system changes.

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.

Since timely updates are an issue, specifically Debian Testing is a good stable distro.

• It has a nice interface for searching history - nicer than the history search included with the shells I’ve used
• It has a “workspace” mode - it remembers which directory commands were run in, which gives you the option to limit history search to commands run in the same directory, which are often most relevant to the project you’re working on in that directory
• If you want you can back up, or sync history to multiple machines. I know I’ve been in situations where I know the command I want is in history, but it’s in history on my desktop, and I’m on my laptop at the moment

Yes, NixOS - and also Niri so your tiled windows don’t resize themselves, and you get the extra-fancy screen cast and screen shot features. That’s what I use, therefore it is the best.

I work with a very competent dev who uses Windows. I’ve even gotten him to the point of helping me to champion Nix dev shells. But he prefers to use those through WSL ¯\(ツ)/¯

The article doesn’t specifically mention DXVK which was the real breakthrough innovation IMO. Consider that Wine predates Proton by many years, and vanilla Wine is also fantastic for gaming since DXVK’s introduction. But Valve did fund DXVK by paying its inventor for full time work. So thanks Valve! Thanks Philip Rebohle! Thanks Wine devs! It’s been amazing!