The only strong holdout is glibc (musl is no match, and doesn’t pretend to be anyway).

Chimera Linux patches musl to use mimalloc and that allegedly mostly closes the performance gap. With notable glibc stronghold systemd supporting musl in recent versions I wouldn’t be too surprised if it catches on eventually, like clang arguably already has.

The infix syntax is not great, but you can at least write frac(n (n + 1), 2) and it renders the way you would expect.

Edit:

This is not even an option in typst, which uses the space as an escape character.

Technically LaTeX does this too with omitted curly braces:

\sum_{n=1}^9   % works
\sum_{n=1}^10  % doesn't work

Everyone just quickly learns to not do that.

I can only speak for myself but I like Typst a lot more than LaTeX. Typst compiles instantly and the markup language is very reasonable. LaTeX by comparison is slow and arcane, with a macro language that is unlike anything else in common use today. It also has pretty awful defaults to be honest, especially if you’re writing in a language that isn’t English. There are a few things that Typst can’t quite do, but that gap is shrinking as well.

Edit: This blog post has some examples and showcases a lot of the core functionality, including the scripting. Typst has a playground which you can use to get a feel for the basics (though installing it locally isn’t a massive pain either, unlike LaTeX). Overleaf allows trying LaTeX in the browser for free as well, although only with an account (partly because LaTeX tooling is a pain and expensive in CPU resources).

I’m not so sure about that. Vim has syntax highlighting, programming language support (assisted via ctags), two terminal emulators, a window manager, two (arguably three) programming languages, transparent remote file editing…

So anyway, I use an editor that doesn’t waste my time: Ed, man! !man ed.

This is made by an AI company (Kagi) so that checks out (although Kagi’s own logo defies the trend).

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.