5 ms·

I feel like most of these systems tradeoff too much simplicity. I've been using ArchLinux for ~14 years now, previous to that I used Slackware and Gentoo. IMO

by jpgvm 2y ago

I feel like most of these systems tradeoff too much simplicity. I've been using ArchLinux for ~14 years now, previous to that I used Slackware and Gentoo. IMO it's better to be simple, yes there aren't any guarantees but worst case scenario I can rebuild, run my install script (which might require a few tweaks if it's been a while since I setup a new system), push new keys etc and then I'm up and running again in ~15 mins. i.e I think it's easier to repair or replace a simple system than it is to try work out how to do novel things on a complicated but safe system. I intend to try NixOS at some point as a foray into these more complicated but "safer"/transactional/immutable/deterministic systems but I just haven't found the motivation yet.

m1n7 2y ago
i think it's possible to have both. we just haven't decided how to implement these improvements, that's why we see so many different immutable/snapshot/… distros with lacking ux — for now
struanr 2y ago
Personally I went from Arch to NixOS and now back to Arch. Whilst I can appreciate the power of NixOS it felt like such a huge amount of abstraction and secret sauce it made it impossible to fit in my head. In addition, the documentation and debugging experience of the Nix language were very poor. Nix shell was useful for trying out programs temporarily, however I found it a poor substitute for native Python and Julia package managers, especially for scientific work where a requirements.txt is useful to a lot more people than a flake.nix Going back to Arch has felt like a breath of fresh air. Everything is simple, easy to understand and incredibility well documented. Using a snapper pacman hook I can now revert my system to undo updates, which was the main functionality I found useful in NixOS.
- sandbach 2y ago
  It's worth noting that the benefits of Nix shell you mention can be enjoyed from the comfort of another distro with the Nix package manager.
leetnewb 2y ago
To be fair, Tumbleweed has had snapshot/rollback built in and generally triggered at important points for years. There are exceedingly few scenarios where you can't just move to the prior snapshot to get a working system again - talking a minute after failure. Aeon takes it further, but that's where it started. Hard to argue the speed of repairing by rollback vs reinstall. Also, Aeon has first party support for running cli and gui things in distrobox. You can pull down an OCI container of virtually any distro and do whatever you want in it. Distrobox lets you expose applications from the container environment to the Aeon desktop. Hypothetically, you could use Aeon as your rock solid core and tinker in distroboxes, including refining the install script to making a custom OCI container. Not trying to convince you - just saying there is a lot of easy to access flexibility there.
- jpgvm 2y ago
  Yeah I should give Tumbleweed a try at some point. It's hard to give up the Arch PKGBUILD system though, it's an even simpler ebuild which was originally why I loved Gentoo so much.
  - bboozzoo 2y ago
    I'm always puzzled how folks praise PKGBUILDs when it's mostly irrelevant for a regular user. Unless by 'PKGBUILD system' you mean AUR, a place where random people push random build scripts and other folks are happy to execute said build scripts locally, quite often without any real sandboxing or even a quick glance at the actual code.
    - Avshalom 2y ago
      what do you think "a regular user" of ubuntu/suse/fedora/arch/etc. looks like? back when I was using arch I wrote pkgbuilds instead of configure/make/installing to my home folder. kept my ./local/(bin|lib|share) clean and meant I could update it easier or uninstall it with pacman. As to runnning random build scripts, well I already do that anyway. Any software that isn't provided by my package manager requires me to run random build scripts from random people. I sure as hell am not reading through every line of code in say... trealla prolog before make-ing it.
abc123abc123 2y ago
I use opensuse leap 15.3 and it just works. No fiddling around and install takes 15 minutes. Then I have a home cooked backup script that runs daily to a remote server, so in a worst case situation, I reinstall, 15 minutes, and then copy my dot files and other stuff which might take another 5-15 minutes. So for single person use, or small environments of 20-30 servers or so, the traditional old model works well.
- bboozzoo 2y ago
  FYI, in case you missed that, Leap has been EOL since late 2022.
  - doubled112 2y ago
    Leap 15.6 was released on the 12th of this month. https://news.opensuse.org/2024/06/12/leap-unveils-choices-for-users/ https://news.opensuse.org/2024/06/12/leap-unveils-choices-fo... It might be the last OpenSUSE using the traditional release model, but it's not EOL.
    - LinAGKar 2y ago
      I think they meant to say specifically Leap 15.3
      - doubled112 2y ago
        Definitely possible, but there was considerable talk about the end of Leap. Thought it was still worth mentioning.
fao_ 2y ago
> i.e I think it's easier to repair or replace a simple system than it is to try work out how to do novel things on a complicated but safe system. I mean, that's the point. If the configuration of the machine is declarative it's easier to replace it with a duplicate that works. Declarative in this context literally just means "the entire state is declared in a way that you can roll it back"
myaccountonhn 2y ago
Nixos is pretty slick for servers. Everything from users to nginx to system services to firewall is defined declaratively in 1-5 files, and deployment is as simple as `nixos-rebuild switch -—target-host deploy@host`. For me that’s pretty wild. It makes it trivial to have both staging and prod in sync by just pushing to a repo. That means you get a better overview of the system state, and can experiment more freely knowing the machine won’t end up in a weird state. And while Nixos is hard to debug and occasionally hard to write, I find the format very easy to read. However for my personal computer, I found that it’s overkill and now I just use a dotfile manager and save my installed program names in a list. I do think nix really lacks documentation for very basic things, and for that guix is better (but I found guix harder to write and read).
Timber-6539 2y ago
I was in similar situation. Arch user that bought the sell from NixOS. It worked great after a painstaking setup (everything you think you know about Linux systems in general is wrong!) and was a joy to use but when it broke, it was a complete mess due to how quirky the whole OS is. P.S There's nothing simple about NixOS and the documentation could use some work.
kenmacd 2y ago
> I just haven't found the motivation yet. I moved from Arch to NixOS. In case it helps these are my main motivations: * In Arch, very rarely, I'd apply an update that would break things. Going back to a stable system was a pain. I ended up with some snapper setups and a list of commands to convert the latest snapshot to a r/w 'root' that worked well enough. With NixOS I just reboot to the previous generation on any issue. * For development I'd often use third-party tools to manage multiple language versions. For example I used pyenv. With Nix it's much easier to just use python39, or nodejs-18_x, or whatever as Nix makes this really simple. If you do decide to try it out I'll recommend using the github query 'path:*.nix ___' to copy off others, as the main complaints about Nix seem to center around the language.

by jpgvm 2y ago

m1n7 2y ago

i think it's possible to have both. we just haven't decided how to implement these improvements, that's why we see so many different immutable/snapshot/… distros with lacking ux — for now

struanr 2y ago

Personally I went from Arch to NixOS and now back to Arch. Whilst I can appreciate the power of NixOS it felt like such a huge amount of abstraction and secret sauce it made it impossible to fit in my head. In addition, the documentation and debugging experience of the Nix language were very poor. Nix shell was useful for trying out programs temporarily, however I found it a poor substitute for native Python and Julia package managers, especially for scientific work where a requirements.txt is useful to a lot more people than a flake.nix Going back to Arch has felt like a breath of fresh air. Everything is simple, easy to understand and incredibility well documented. Using a snapper pacman hook I can now revert my system to undo updates, which was the main functionality I found useful in NixOS.

sandbach 2y ago
It's worth noting that the benefits of Nix shell you mention can be enjoyed from the comfort of another distro with the Nix package manager.

leetnewb 2y ago

To be fair, Tumbleweed has had snapshot/rollback built in and generally triggered at important points for years. There are exceedingly few scenarios where you can't just move to the prior snapshot to get a working system again - talking a minute after failure. Aeon takes it further, but that's where it started. Hard to argue the speed of repairing by rollback vs reinstall. Also, Aeon has first party support for running cli and gui things in distrobox. You can pull down an OCI container of virtually any distro and do whatever you want in it. Distrobox lets you expose applications from the container environment to the Aeon desktop. Hypothetically, you could use Aeon as your rock solid core and tinker in distroboxes, including refining the install script to making a custom OCI container. Not trying to convince you - just saying there is a lot of easy to access flexibility there.

jpgvm 2y ago
Yeah I should give Tumbleweed a try at some point. It's hard to give up the Arch PKGBUILD system though, it's an even simpler ebuild which was originally why I loved Gentoo so much.
- bboozzoo 2y ago
  I'm always puzzled how folks praise PKGBUILDs when it's mostly irrelevant for a regular user. Unless by 'PKGBUILD system' you mean AUR, a place where random people push random build scripts and other folks are happy to execute said build scripts locally, quite often without any real sandboxing or even a quick glance at the actual code.
  - Avshalom 2y ago
    what do you think "a regular user" of ubuntu/suse/fedora/arch/etc. looks like? back when I was using arch I wrote pkgbuilds instead of configure/make/installing to my home folder. kept my ./local/(bin|lib|share) clean and meant I could update it easier or uninstall it with pacman. As to runnning random build scripts, well I already do that anyway. Any software that isn't provided by my package manager requires me to run random build scripts from random people. I sure as hell am not reading through every line of code in say... trealla prolog before make-ing it.

abc123abc123 2y ago

I use opensuse leap 15.3 and it just works. No fiddling around and install takes 15 minutes. Then I have a home cooked backup script that runs daily to a remote server, so in a worst case situation, I reinstall, 15 minutes, and then copy my dot files and other stuff which might take another 5-15 minutes. So for single person use, or small environments of 20-30 servers or so, the traditional old model works well.

bboozzoo 2y ago
FYI, in case you missed that, Leap has been EOL since late 2022.
- doubled112 2y ago
  Leap 15.6 was released on the 12th of this month. https://news.opensuse.org/2024/06/12/leap-unveils-choices-for-users/ https://news.opensuse.org/2024/06/12/leap-unveils-choices-fo... It might be the last OpenSUSE using the traditional release model, but it's not EOL.
  - LinAGKar 2y ago
    I think they meant to say specifically Leap 15.3
    - doubled112 2y ago
      Definitely possible, but there was considerable talk about the end of Leap. Thought it was still worth mentioning.

fao_ 2y ago

> i.e I think it's easier to repair or replace a simple system than it is to try work out how to do novel things on a complicated but safe system. I mean, that's the point. If the configuration of the machine is declarative it's easier to replace it with a duplicate that works. Declarative in this context literally just means "the entire state is declared in a way that you can roll it back"

myaccountonhn 2y ago

Nixos is pretty slick for servers. Everything from users to nginx to system services to firewall is defined declaratively in 1-5 files, and deployment is as simple as `nixos-rebuild switch -—target-host deploy@host`. For me that’s pretty wild. It makes it trivial to have both staging and prod in sync by just pushing to a repo. That means you get a better overview of the system state, and can experiment more freely knowing the machine won’t end up in a weird state. And while Nixos is hard to debug and occasionally hard to write, I find the format very easy to read. However for my personal computer, I found that it’s overkill and now I just use a dotfile manager and save my installed program names in a list. I do think nix really lacks documentation for very basic things, and for that guix is better (but I found guix harder to write and read).

Timber-6539 2y ago

I was in similar situation. Arch user that bought the sell from NixOS. It worked great after a painstaking setup (everything you think you know about Linux systems in general is wrong!) and was a joy to use but when it broke, it was a complete mess due to how quirky the whole OS is. P.S There's nothing simple about NixOS and the documentation could use some work.

kenmacd 2y ago

> I just haven't found the motivation yet. I moved from Arch to NixOS. In case it helps these are my main motivations: * In Arch, very rarely, I'd apply an update that would break things. Going back to a stable system was a pain. I ended up with some snapper setups and a list of commands to convert the latest snapshot to a r/w 'root' that worked well enough. With NixOS I just reboot to the previous generation on any issue. * For development I'd often use third-party tools to manage multiple language versions. For example I used pyenv. With Nix it's much easier to just use python39, or nodejs-18_x, or whatever as Nix makes this really simple. If you do decide to try it out I'll recommend using the github query 'path:*.nix ___' to copy off others, as the main complaints about Nix seem to center around the language.