I tried a git log --grep=claude but it doesn’t net much, basically just this PR (which in fairness does look vibecoded).

Maybe there’s some development branch in the repository that has a commit authored by Claude but if so it’s not on main.

The site works for me. This is the actual news:

Last week, the Fedora Infrastructure Team lifted the IP range block on IP addresses in Syria. This action restores download access to Fedora Linux deliverables, such as ISOs. It also restores access from Syria to Fedora Linux RPM repositories, the Fedora Account System, and Fedora build systems. Users can now access the various applications and services that make up the Fedora Project.

This discourse post has more details. Essentially: Nixpkgs is an 83 GiB repository with 20,000 forks that incurs a ton of API usage from CI and bots. It turns out this caused some scaling issues. It’s unclear to me if other forges would have run into exactly the same issues but if the repo can cause replication failures at GitHub it can almost certainly cause problem at Codeberg.

Edit: For comparison, the Gentoo repository is 20 GiB and has 2.2k forks (on GitHub). The largest repository on Codeberg is 30 GiB, but that’s just a blocklist data mirror with no CI.

Edit 2: Also, since I’m reading through Gentoo’s mail archives for this they also seem to be at least slightly worried:

So far I don’t think we really deliberated on [using Codeberg for the sync-friendly mirror]. The key point here is that unlike GitHub, Codeberg is running on community funding, and we don’t want to abuse their resources with the huge syncing repo.

Note that Nixpkgs doesn’t have a syncing mirror. Majority of Nix users pull directly from github.com/NixOS/nixpkgs.

I would expect Git forges (and other configuration control adjacent software) to be the easiest services to federate. Git is already decentralized, and the usual concerns regarding encryption and privacy are essentially irrelevant since everything is meant to be public anyways.

If you ask me it’s strange that the federated social media (which leaks PII everywhere) and federated messaging (which is a security nightmare) have taken off but decentralized Git forges don’t exist. My best guess is that the people who care are already using mailing lists?

I thought that was a solved problem on Linux. Is it the reluctance to use binary blobs?

Yes. For the same reason you also don’t get firmware updates on Guix. Or Firefox.

I feel like it’s actually not that hard… if you can tell what advice is bad and shouldn’t be followed. Which I realize is a major catch-22 for new users.

My honest advice on Neovim (for everyone) is to do this:

• environment.systemPackages = [ pkgs.neovim ];
• Configure Neovim as you usually would (hand-written init.lua, Lazyvim installer, whatever)
• Ignore/Disable Meson and use shell.nix to get language servers and formatters instead (alternatively: enable nix-ld for Meson or Mise)
• Completely ignore all the wrapper garbage like programs.neovim, nixvim, nvf, nixCats, and all the others

The last one is important. You can try all you want to make the garbage work and it eventually will, at least kinda, but IMHO the very idea of what they’re trying to do is bad, ultimately making them a colossal waste of time.

I have less strong but overall similar feelings regarding Home Manager, those newly hyped wrapper managers and libraries, the “Dendritic Pattern”, etc. The NixOS community loves coming up with novel ways to shoot themselves in the foot.

It does, that’s the home.file escape hatch I mentioned. But then you end up paying 10-30 seconds eval for a “config” that looks like this:

{
  home.file.".bashrc".source = ./bashrc;
  home.file.".bash_profile".source = ./bash_profile;
  xdg.configFile.nvim.source = ./nvim;
  xdg.configFile.sway.source = ./sway;
  # ...
}

I suppose there are fringe use cases where Nix attrset merging behaviour is useful, but in the average case I just don’t see much value here.

Yeah that’s a KDE classic. I think I had one KDE version a few years back that had no issues with my dock but it broke on a kernel update. Maybe it’s not entirely fair to blame KDE but I never had the same issues on GNOME, Sway or Niri…

I’m not sure that description makes a lot of sense. Nixpkgs/NixOS is a fairly large community project. Some of the contributors are certainly anti-woke (although quite a few of those were banned from official spaces a while back), and some are MIC employees (Anduril is somewhat infamous with a seat on the so-called “steering council”). That’s not especially unusual by itself, and you can definitely do worse than “one guy is a MIC employee” (just ask the GNU or suckless folks). What is unusual is the very public meltdowns that happened surrounding it, including the moderation team resigning. The community fortunately seems to have survived all of that though.

Anyone curious can read through the most recently active governance related thread and the rest of the discourse meta category. Outside of that the subreddit had an issue with Lunduke spam at the time, but this has since died down (and the posts were removed). I don’t frequent the Matrix (official) or Discord (unofficial) so maybe those are really bad and I don’t know about it, but from my experience I honestly have little to complain about.

There’s a manual, a discourse (forum) and a Matrix. And an unofficial subreddit and a Lemmy community. As well as two wikis and a large number of random people writing blog posts and tutorials.

This might be a hot take but honestly I think the documentation quality isn’t the problem. You can point to specific topics that aren’t well documented but that isn’t unusual. What’s unusual is how NixOS is designed and how working around its quirks requires close to distro maintainer levels of knowledge.

Most distros don’t require several pages of documentation on how to install a Python application. NixOS on the other hand…

This module is actually a bit of a pet peeve of mine and a big reason I soured on Home Manager in general…

You inevitably end up writing chimera configurations like this:

# home.nix
programs.sway = {
  enable = true;
  
  # not supported by module - need to use escape hatch
  # good luck getting your editor to syntax highlight this snippet btw
  extraConfig = /* swayconfig */ ''
    bindgesture swipe:right workspace prev
    bindgesture swipe:left workspace next
  '';
};

programs.waybar = {
  enable = true:

  # can't do that in Nix
  style = /* css */ ''
    window#waybar {
      background: #16191C;
      color: #AAB2BF;
    }
  '';
};

# configuration.nix
# need to enable Sway a second time so the display manager can see it
# this may also install a second Sway if you fuck up your HM setup
programs.sway.enable = true;

and in exchange for this you get:

• 30s+ iteration times for basic changes like keybinds
• No ability to copy paste config snippets from READMEs/Wikis (unless you use home.file/extraConfig escape hatches)
• No ability to edit configuration in scripts (breaks a lot of theming functionality in “shells” like DMS, Noctalia, etc.)
• More ways to write configs that look right but don’t quite work or just do dumb things (extra Nixpkgs imports, duplicated packages, WMs that aren’t visible to the DM, etc.)

Alternatively you could just use a dotfile manager like rcm or stow or chezmoi like everyone not on NixOS+HM and not have to deal with any of this.

Do you have some specific threads in mind? Maybe I’m lucky to never click on the bad ones but my experience is that nobody is more cynical regarding Nix/NixOS jank than the long time NixOS users. You might not always get the answer you want, because it is very jank and doing some things will get you into trouble. But people pointing that out isn’t the same thing as gaslighting.

Guix SD might be worth a look, it seems to be just straight up better in many technical regards. It has no flakes, comprehensive documentation and a blessed way to manage user homes. At least as long as you don’t really need WiFi of course…

These… don’t even remotely solve the same problem?

• (1) AshOS: Package managers are fragile, and partial or broken updates can break systems (up to not booting at all).
• (2) Nix: Package managers need to solve a SAT problem (which may be impossible) to resolve dependencies.
• (3) Distrobox: Containerized programs are annoying to work with.
• (4) Homebrew: Your system doesn’t have a package manager (e.g. MacOS).

Problems (1) and (2) (arguably also (3)) are quite difficult and don’t have trivial solutions. Fedora Silverblue solves (1) but has to jettison a reasonable package manager, creating problem (4) and the demand for Linuxbrew. NixOS solves (1) and (2) while avoiding (4) but at the cost of recompiling the world and breaking SELinux/AppArmor.

I wouldn’t consider running AshOS personally (even ignoring the abandoned status) as any package install or update requires a reboot (a variation of (4)), so the UX doesn’t appear to meaningfully different from just running Silverblue or MicroOS. I have doubts that the design space here has been completely explored, but you have to look back at the mediocre past attempts to understand why they were mediocre.

Pandoc actually does a reasonable job at turning (Pandoc flavored) markdown into man-roff. Sure it doesn’t work for arbitrary markdown but it’s good enough to avoid writing roff by hand.

The main reason I see for not doing that (and using something like scdoc instead) is that you end up with a Haskell toolchain in your dependency graph.

You can run the LXQt Wayland Session with Hyprland as compositor. You can also forget about the session and just run the panel in a startup command or a systemd service, although I’m not sure if all widgets will work correctly this way.

XFCE also has experimental Wayland support; Hyprland isn’t officially supported but IIRC it uses the same wlroots protocols as the supported Labwc so it should work. Documentation is fairly sparse even compared to LXQt though and it’s a bit buggy, I personally haven’t gotten it to work (but others have so it’s definitely possible).

Edit: Also, Waybar has task bar widgets too. But it doesn’t support any kinds of “popup” like start menus or control centers, you just have the bar.

Nix in single user mode can apparently work with SELinux in enforcing mode, although AFAIK binaries installed via Nix can not have SELinux metadata which could be an issue for some programs.

Determinate Nix claims to have seamless integration with SELinux (unlike upstream Nix and Lix, but it’s not a fork, alright whatever you say Eelco). Using that and removing the proprietary garbage their installer also adds might be easier than making regular Nix play nice with it.

My understanding is that most of this is down to ARM’s (relative) lack of standardization. Consumer ARM SoCs don’t even have ACPI, so you aren’t even guaranteed to be able to do things like powering off the system. Qualcomm pretty much has to add some minimum support for their SoCs to the kernel because most of their consumers will want to get Android working on them, but that doesn’t mean they’ll do more than they have to for that.

There’s a reason you can install Linux on any x86 PC and it will mostly work, but you can’t install an ARM Linux on a phone. Even Android forks like Lineage don’t support all Android phones, even though they’re shipping basically the same thing the manufacturers are.

I have this in my config:

function lastcmd
    echo $history[1]
end

abbr --add "!!" --position anywhere --function lastcmd

I believe I originally got this implementation from the GitHub issues. The key is that abbreviations can also call functions, which can in turn index into the history list. We also need to specify that we want the expansion even if we’re in an argument to another command, such as in sudo !!.

This is by no means complete, but the features that I value would be:

• <Tab> cycles though completions as it should instead of duplicating the prompt.
• Completions also show help text (if there’s a provider for one). For example on git <Tab> it shows a short message describing what the command does. JJ goes further: jj diff -r <Tab> shows part of the commit message for the offered commits.
• There are just more completions than in any other shell I know. Aside from JJ the new Nix CLI also has great Fish completions and can dynamically complete flake outputs like package names.
• Entire commands can be history completed with <C-E> or <Right>. This completion is also directory-aware and can usually avoid suggesting commands with paths to files that don’t exist. In practice I find that it’s really good at suggesting the command I actually want to run, to the point that I rarely invoke FZF anymore.
• Abbreviations are in most cases better aliases since they do the same thing but don’t obscure what you’re actually running.
• No word splitting when expanding variables, because it’s never what you intended.
• Globs that fail to match anything are errors instead of silently doing the wrong thing.
• Control structures are a bit nicer (but that is subjective).

You can get most of these with liberal use of shell options, installing blesh, or alternatively installing zsh with a bunch of plugins, but Fish just has all of them out of the box. You don’t even need bash-completions.

how hard is it to transition?

It has a reputation of being very difficult from the past when it didn’t have &&/|| but I think today plenty of Linux users would not even notice. The most notable remaining differences are setting variables (requires the set builtin unless used to modify the environment for a single command), control structures (irrelevant in interactive use) and lack of !! (but you can make an abbreviation to bring it back).

I hear a lot of people talk about the CachyOS kernel, but from this benchmark it seems like the optimizations used for the packages is as relevant (or even more so). It’s also interesting that while distro-wide -O3 is basically useless, x86_64-v3 actually makes a significant difference. Unless openSUSE is doing other things that Phoronix doesn’t highlight?