I'm preparing for a new PC build, and I decided to try a new atomic OS after having been with NixOS for about a year.

First I tried Kinoite, then Bazzite, but even though KDE has a lot of features, I found it incredibly buggy, and it even had generally poor performance, especially in Firefox. I don't really have time to diagnose these issues, so I figured I would put in just a little more effort and migrate my Sway config to Fedora Sway Atomic.

I'm glad I did. The vanilla install of Fedora Sway is awesome. No bloat and very usable. I haven't noticed any bugs. Performance is excellent. And it was very straightforward to apply my sway config on top without losing the nice menu bar, since Fedora puts their sway config in /usr/share/sway.

I'm also quite happy with the middle ground of using an OSTree-based Linux plus Nix and Home Manager for my user config. I always thought that configuring the system-level stuff in Nix was the hardest part with the least payoff, but it was most productive to have a declarative config for my dev tools and desktop environment.

I originally tried NixOS because I wanted bleeding edge software without frequent breakage, and I bought into the idea of a declarative OS configuration with versioned updates and rollback. It worked out well, but I would be lying if I said it wasn't a big time investment to learn NixOS. I feel like there's a sweet spot with container images for a base OS layer then Nix and Home Manager for stuff that's closer to your actual workflows.

I might even explore building my own OS image on top of Universal Blue's Nvidia image.

Hope this path forward stays fruitful! I urge anyone who's interested in immutable distros to give this a try.

Who are these for? People who use the terminal but don't like running shell commands?

OK sorry for throwing shade. If you use one of these, honestly, what features do you use that make it worthwhile?

More specifically, I'm thinking about two different modes of development for a library (private to the company) that's already relied upon by other libraries and applications:

1. Rapidly develop the library "in isolation" without being slowed down by keeping all of the users in sync. This causes more divergence and merge effort the longer you wait to upgrade users.
2. Make all changes in lock-step with users, keeping everyone in sync for every change that is made. This will be slower and might result in wasted work if experimental changes are not successful.

As a side note: I believe these approaches are similar in spirit to the continuum of microservices vs monoliths.

Speaking from recent experience, I feel like I'm repeatedly finding that users of my library have built towers upon obsolete APIs, because there have been multiple phases of experimentation that necessitated large changes. So with each change, large amounts of code need to be rewritten.

I still think that approach #1 was justified during the early stages of the project, since I wanted to identify all of the design problems as quickly as possible through iteration. But as the API is getting closer to stabilization, I think I need to switch to mode #2.

How do you know when is the right time to switch? Are there any good strategies for avoiding painful upgrades?

I just commented on this post and it got removed very quickly. Then I noticed that all of the comments had been removed and the post is locked.

I cannot understand why this happened, as the comments section had seemed pretty reasonable to me.

This seems like bad moderation and I'm now less inclined to post or comment in the world news community. What should I do?

I tried messaging a mod that is seemingly online and actively posting, but I got no response.

After moving from lemmy.ml to programming.dev, I've noticed that web responses are fulfilled much more quickly, even for content on federated instances like lemmy.ml and lemmy.world.

It seems like this shouldn't make such a big difference. If a large instance is overloaded, it's overloaded, whether the traffic is coming from clients with accounts on that instance or from other federated instances.

Can this be explained entirely by response caching?