3 ms·

The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of a

by Phlebsy 6mo ago

The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on a fresh install then there's a big risk. NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.

michaelmrose 6mo ago
Actually desktop environments are entirely modular and even audio stacks are just a few packages and enabling a few services
- codethief 6mo ago
  Man, I still remember what a pain the migration from PulseAudio to Pipewire was. Sure, it's only a couple packages, disabling a few services, enabling a couple others. But I had to do this almost on the daily, while bugs in Pipewire/Wireplumber were still getting ironed out and were rendering my audio stack temporarily unusable.
sidkshatriya 6mo ago
Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that: (1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS) (2) Make destructive changes like install a new windows manager, some drivers etc. (3) If everything worked out well, continue (4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed. Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.
- computably 6mo ago
  Fedora also offers immutable distros which are (I've heard) much more user-friendly than Nix. Sure you can make a hacky pseudo-immutable workflow on a mutable distro but that's literally more effort for a worse result.
- exitb 6mo ago
  It’s like saying you don’t need a version control system for coding, as you can just make a copy of your sources before making important changes.
  - sidkshatriya 6mo ago
    I like your analogy and it does make sense. But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."
  - arianvanp 6mo ago
    A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code. There is no distinction between package maintainers and end users. They have the same power. In the meantime i dont expect Debian users to ever write a package themselves or to modify one. In nixOS you do it all the time
    - sidkshatriya 6mo ago
      FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes: # clone the package definition $ fedpkg clone -a <name of package> $ cd <name of package> # install build dependencies $ sudo dnf builddep ./nameofpackage.spec # Now add your patches or modifications # now build the package locally $ fedpkg local # install locally modified package $ sudo dnf install ./the-locally-built-package.rpm

by Phlebsy 6mo ago

michaelmrose 6mo ago

Actually desktop environments are entirely modular and even audio stacks are just a few packages and enabling a few services

codethief 6mo ago
Man, I still remember what a pain the migration from PulseAudio to Pipewire was. Sure, it's only a couple packages, disabling a few services, enabling a couple others. But I had to do this almost on the daily, while bugs in Pipewire/Wireplumber were still getting ironed out and were rendering my audio stack temporarily unusable.

sidkshatriya 6mo ago

Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that: (1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS) (2) Make destructive changes like install a new windows manager, some drivers etc. (3) If everything worked out well, continue (4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed. Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.

computably 6mo ago
Fedora also offers immutable distros which are (I've heard) much more user-friendly than Nix. Sure you can make a hacky pseudo-immutable workflow on a mutable distro but that's literally more effort for a worse result.
exitb 6mo ago
It’s like saying you don’t need a version control system for coding, as you can just make a copy of your sources before making important changes.
- sidkshatriya 6mo ago
  I like your analogy and it does make sense. But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."
- arianvanp 6mo ago
  A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code. There is no distinction between package maintainers and end users. They have the same power. In the meantime i dont expect Debian users to ever write a package themselves or to modify one. In nixOS you do it all the time
  - sidkshatriya 6mo ago
    FWIW... I have modified packages on Fedora and installed them. The workflow is very simple... of course, not as simple as NixOS but here goes: # clone the package definition $ fedpkg clone -a <name of package> $ cd <name of package> # install build dependencies $ sudo dnf builddep ./nameofpackage.spec # Now add your patches or modifications # now build the package locally $ fedpkg local # install locally modified package $ sudo dnf install ./the-locally-built-package.rpm