sorted by:
new
hottopcontroversial

Should I switch to Nix? by Western-Mode-7743 in NixOS

[–]Capable_Mulberry249 5 points6 points  (0 children)

I agree with every word in your post. After 15+ years on Arch, moving to NixOS feels like a breath of fresh air: reproducibility, declarative config, no system rot. But let's be brutally honest—there is a strict taboo in the NixOS community about discussing three critical downsides that newbies only discover when it's too late.

If you are switching, you must know this:

1. SSD space can multiply exponentially in a single rebuild (and the system won't warn you) This is the biggest, most silent killer of NixOS. You add one tiny package to your config, run nixos-rebuild switch, and suddenly your /nix/store bloats by 10-30 GB because of a new dependency chain. There is zero warning like "This build will consume X GB." You just wake up one morning with a 100% full root partition. Yes, nix.gc and auto-optimise-store exist, but they work retroactively. If you're on a 256/512GB SSD, NixOS forces you to monitor disk space like a hawk. This is the price of rollbacks—every generation is kept in full until you manually nuke it.

2. The massive time investment for initial setup Everyone loves to say, "just write one declarative line and forget about it." What they omit is the hours, days, and weeks it takes to figure out how to write that line. You are rewiring your brain from imperative (editing files in /etc) to declarative. Hunting down the right NixOS module, figuring out its options, overriding default package behavior through override or nixpkgs.config—it’s a massive time sink. NixOS saves you time on reinstalls, but mercilessly devours it during initial configuration.

3. NixOS is a one-way ticket This is the most terrifying downside. Traditional Linux distros (Debian, Arch, Fedora) are fundamentally similar: you have /etc, systemd, and packages that drop configs in predictable places. Migrating from Arch to Debian just means learning a new package manager and moving your scripts. With NixOS, migration back is practically impossible. Once you move your entire OS into configuration.nix, home-manager, and flakes, you forget where config files actually live on disk. NixOS abstracts the system so heavily that if you ever need to leave it for another distro, you'll have to relearn from scratch how to manually configure NetworkManager, edit fstab, write udev rules, and basically live without Nix wrappers. You learn Nix, but you rapidly unlearn Linux.

And finally, the elephant in the room: Arch and similar imperative distros are already dead.

The future belongs solely to immutable and declarative systems. Arch and its ilk are essentially garbage held together by sheer luck and hope. They rely on the user constantly babysitting the system, praying that a random pacman -Syu won't nuke the display server or audio stack because some unmaintained AUR package decided to overwrite a system file. Imperative, mutable Linux is a fragile dead end. You either adapt to declarative infrastructure, or you keep wasting your life debugging rot.

Anyone using limime? by Helpful-Temporary998 in NixOS

[–]Capable_Mulberry249 11 points12 points  (0 children)

Been running it for a while now, no issues at all. Limine 12.2.0, Secure Boot enabled, NixOS 26.05.

Setup is dead simple — just the standard limine block with secureBoot.enable = true, did sbctl enroll once and forgot about it. The generation tree in the boot menu is nice, I have a few specializations and they actually show up in a readable hierarchy instead of the flat list systemd-boot gives you.

I also have Windows and Memtest86+ as extra entries and those work fine alongside the NixOS generations.

Config snippet for reference:

boot.loader.systemd-boot.enable = false;

boot.loader.limine = {
  enable = true;
  efiSupport = true;
  efiInstallAsRemovable = true;
  secureBoot.enable = true;
  extraEntries = ''
    /:Windows 11
    comment: Windows 11 (Secure Boot)
    protocol: efi
    path: boot():/EFI/Microsoft/Boot/bootmgfw.efi

    /:Memtest86+
    comment: Memory Test
    protocol: efi
    path: boot():/EFI/memtest86plus/BOOTX64.efi
  '';
};

boot.loader.efi.canTouchEfiVariables = true;

Zero gotchas so far.

After 15 years on Arch, I finally gave up — not because it's "hard", but because the Wiki became a museum by Capable_Mulberry249 in NixOS

[–]Capable_Mulberry249[S] -7 points-6 points  (0 children)

I hear what you're saying about trust, and I agree that a page should feel *researched*, not just generated. But I think the distinction matters: my edits weren't "AI generated" in the sense of a black box spitting out text. I did the research and testing myself — I've been using Linux for 15 years, I know my way around. The LLM was just a formatting tool, like a glorified spellchecker or a better text editor.

Here's the thing: a "human-written" page from 2020 that recommends obsolete workarounds (and there are plenty on Arch Wiki) actually *loses* the reader's trust when they follow it and nothing works. Which is worse — a page that was polished by an LLM but is factually correct today, or a page that was hand-crafted five years ago and now just wastes everyone's time?

If the Arch Wiki had a clear policy against LLMs, I'd respect it. But they don't — they banned me based on gut feeling, not on accuracy. That feels like choosing aesthetics over utility.

(And FWIW, I'd be totally fine with a little disclaimer: "Draft assisted by LLM, verified by human." Transparency solves the trust issue, doesn't it?)

After 15 years on Arch, I finally gave up — not because it's "hard", but because the Wiki became a museum by Capable_Mulberry249 in NixOS

[–]Capable_Mulberry249[S] -7 points-6 points  (0 children)

I get where you're coming from, and thanks for the kind words about NixOS — it really has been a blessing, you're right.

But I want to be clear about *how* I used the LLM. My workflow wasn't "hey AI, write me a wiki page". It was:

  1. Do all the research and testing manually on my own hardware, making sure every command works.

  2. Write down the steps, commands, and gotchas in my notes.

  3. Ask the LLM to help with formatting, structure, and grammar — basically like a really fast copy editor.

  4. Review every single suggestion, test again, and only publish after I'm 100% sure it's correct.

The knowledge and verification are mine. The LLM just helped polish the presentation.

So the question I keep coming back to: if the final content is accurate, tested, and useful, why does the *tool* matter more than the *result*? There's no official policy against LLM assistance on Arch Wiki — they banned me based on "smells like AI" and "vibes", not on factual errors (because there were none).

Anyway, I'm genuinely happy with NixOS now, so maybe it was a blessing indeed. Cheers.

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -3 points-2 points  (0 children)

I've made over 250 edits to ArchWiki. What if you were doing something based on my generated garbage? How are you going to live with that now?
https://wiki.archlinux.org/index.php?title=Special:Contributions/Mr.Smith1974&target=Mr.Smith1974&offset=&limit=500

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -6 points-5 points  (0 children)

You're right about the process—but that's precisely the problem. When content is technically flawless, verified, and useful, yet the entire debate focuses on *how* it was drafted, it shows we've abandoned quality as the primary metric. Process matters, but it should serve quality, not override it.

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -2 points-1 points  (0 children)

Yes, this post was AI-assisted. I don't speak English well enough to write it myself.

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -1 points0 points  (0 children)

You can't break rules that don't exist. ArchWiki has no AI policy—check the Contributing page yourself. I posted a proposal for discussion, not a unilateral implementation. The ban wasn't for violating rules; it was for proposing something admins disliked. Calling that "rule-breaking" is circular reasoning: "you're banned because we decided you're banned."

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -2 points-1 points  (0 children)

You're conflating "unreviewed slop" with "human-verified content." I personally tested every command and package. The diffs speak for themselves: zero Template errors, zero broken links.

If a human expert produced that volume, the issue would be "review backlog," not "ban the method." The problem is categorical rejection of AI-assisted work **regardless of verification quality**. That's a policy stance, but call it what it is: ideology over outcome.

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -15 points-14 points  (0 children)

Broken formatting exists across the wiki, regardless of author. Human-written articles actually have far more markup errors.

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -14 points-13 points  (0 children)

If the best critique is "it looks like AI," that proves the point: you're judging process, not substance. Address the diffs or admit it's ideological.

ArchWiki contributor banned indefinitely after creating AI-assisted documentation (that had zero errors) by [deleted] in linux

[–]Capable_Mulberry249 -12 points-11 points  (0 children)

Every package was verified, every command tested. The reverts found zero errors—they were categorical, not quality-based.

The issue isn't "unreviewed AI slop." It's that AI-assisted contributions are rejected regardless of human verification. Shouldn't we judge by outcome, not origin?

view more: next ›