Hacker News Reader

Comment by majewsky | Hacker News Reader

> I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts

I don't know. I rather like the NixOS way, where a proper programming language generates the startup scripts (or, in that case, systemd units), but then those scripts are dumb and obvious. Many things are better when they're dumb and obvious.

View on HN

I agree, but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat.

Most shepherd service definitions are simple and stupid, but as always it is a matter of taste.

But the shell scripts are more or less portable across systems, whereas this way you were asking developers to re-implement the same cleanup logic in another language.

> but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat.

IMO this is usually the result of eg a Debian package that also ships sysvinit startup scripts, and thus they share some logic.

If it’s not that case I wonder why the cleanup can’t just be handled in the unit directly.

Perhaps the service being managed doesn't clean up after itself properly? It is a fairly common pattern for a program to ship without startup scripts, and then have startup scripts added by package maintainers.

Right that’s certainly a thing but what I meant is, why not just put the cleanup instructions in the unit file.

Because "cleanup" can be non-trivial. Maintaining scripts inside unit files is a pain in the ass.

The problem with Nix is that it's not a proper programming language. I'll take Scheme over yet another obscure language that manages to irritate me in many ways.

I setup and used a headless nixos box for about a year or so, it was fun to play around with but I did get tired after a while of the nix programming language. It was just too weird to figure out and google around to try and find what I needed to do sometimes. Trying to get virtualenvs of python packages, or using rbenv / bundler type installs for ruby was also just too much of a pain in the butt.

https://nixos.org/nixpkgs/manual/#sec-language-ruby

Trying to figure my way around installing ruby/python libraries just was too hard most of the time without a good amount of work that it wasn't worth it in the long run.

Guix has been on my radar to try and install and play with in-depth soon. If their installer will work with a VM without a days worth of research to work around any quirks I'm all in for checking it out.

Installing Guix in a VM has its own section of the manual:

https://www.gnu.org/software/guix/manual/en/html_node/Instal...

I think I remember trying that a while back and couldn't quite get it working, I'll need to try again soon.

If you want immutability with a traditional package manager, try Darch: https://godarch.com

Reply on news.ycombinator.com