Live data from Hacker News

NixOS 21.05

nixos.org

221–230 of 234 posts

Re: NixOS 21.05

#221
post #21

Earlier quoted context omitted.

The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative. Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system…

Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users. For the developer tools side I like what Shopify did but I would never recommend that t…

> For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.

I'm not sure I understand you. In their case this became the standard dev environment. Everyone in the company is using it and the true benefit is that it makes development predictable. You only need one command to set up dev environment. He also mentioned that it is much faster than the old way.

Re: NixOS 21.05

#222
post #193

Earlier quoted context omitted.

> Straying off the beaten path quickly leads to a terrifying abyss. The contrast is remarkable. When everything you need is packaged and it just works, it's amazing. Hands down the best system management experience I've had. And then one day you learn you've been dancing on the edge of a cliff. I'm hooked; there's no going back now for me. But there's at least one project (TidalCycles) that I simply gave up on ever r…

J/w, have you ever packaged software for other distros? If yes, what made Nix more difficult here? If no, have you tried asking for help packaging TidalCycles on Matrix or Discourse? I'm wondering whether that's some especially oddly-behaved software, or if what's lacking here is some onboarding (that maybe can solved for you with a little community engagement or something).

  Nix is the only OS I've used where the standard installation instructions available in, say, the READMEs of things I want to install are a bad idea. Granted, whenever something is in nixpkgs it's a piece of cake, and almost everything I need is. But to install something not part of nixpkgs, I had to look under the hood in a way that no other platform has made me do.
  I've never packaged software on another platform.
  I packaged serialoscd and monomeserial, and the Discourse channel was critically helpful. It looks like I never tried engaging the community about TidalCycles. I found an old package, tried to fix it, couldn't.

Re: NixOS 21.05

#223
post #193

Earlier quoted context omitted.

J/w, have you ever packaged software for other distros? If yes, what made Nix more difficult here? If no, have you tried asking for help packaging TidalCycles on Matrix or Discourse? I'm wondering whether that's some especially oddly-behaved software, or if what's lacking here is some onboarding (that maybe can solved for you with a little community engagement or something).

Nix is the only OS I've used where the standard installation instructions available in, say, the READMEs of things I want to install are a bad idea. Granted, whenever something is in nixpkgs it's a piece of cake, and almost everything I need is. But to install something not part of nixpkgs, I had to look under the hood in a way that no other platform has made me do. I've never packaged software on another platform. I…

Thanks for sharing your experience in more detail.

I think Nixpkgs is easier to package for than a lot of ecosystems/distributions, but the obligation of _having_ to package for the distro in order to get things working in an ideal way is (reasonably!) more than many people want to have to deal with. (There is also a gap, kinda like across the built-in vs. have-to-package barrier, inside the Nixpkgs world, between software with reasonable/standard build systems and software with unique or ill-designed build processes.)

I've been daydreaming about how this could be better for a little while now, and wondering what compromises it will require to the ‘purity’ of the system, how worthwhile they'll be for novice and advanced users, etc.

Re: NixOS 21.05

#224
post #220
post #105

Earlier quoted context omitted.

I'm out of the loop, what did Shopify do? EDIT: ah, you're probably talking about https://shopify.engineering/shipit-presents-how-shopify-uses...

I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1]. [1] https://github.com/Shopify/runix/

I think they wanted to avoid having people build on it before they stabilize its interfaces, since they still had some big changes planned. As I understand it, the plan is supposedly still to publish it at some point.

I hope that if that's true, they publish it soon, because its design is very relevant to ongoing changes in the ecosystem, and it could be a useful reference point. :(

Re: NixOS 21.05

#225
post #152

Earlier quoted context omitted.

I really can't believe they didn't finalize Flakes in this release. The difference between it and the "standard" way of doing things is night-and-day. these sort of "secret better ways of doing things" that are not the default really frustrate and drive away new users

The problem with this is that flakes are currently an experiment, and one which many people in the community think has flaws that need another iteration. Making it stable now locks Nix into the current flakes model forever - it's too early for that.

What part of flakes might be up for discussion?

The only quirky part I see is how one has to "rewire" inputs of your own inputs (e.g. nixpkgs from an input to one's current flake) via that `follows` directive, but overall it's been rather pleasant compared to channels!

Re: NixOS 21.05

#226
post #224
post #220

Earlier quoted context omitted.

I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1]. [1] https://github.com/Shopify/runix/

I think they wanted to avoid having people build on it before they stabilize its interfaces, since they still had some big changes planned. As I understand it, the plan is supposedly still to publish it at some point. I hope that if that's true, they publish it soon, because its design is very relevant to ongoing changes in the ecosystem, and it could be a useful reference point. :(

I don't think it is. The talk was a year ago and it still isn't available.

I created my own version, based on (I think they did that too) on NixOS modules system.

But I'm wondering how it compares.

Actually looking at https://gist.github.com/burke/72ca46c80e57a25907a75611ee5eb6... I think their goal is slightly different than mine.

There's also https://github.com/hercules-ci/project.nix but it wasn't touched for a year now.

Re: NixOS 21.05

#227
post #215

What are people's thoughts on running nix without nixos, using a base system such as Debian or Arch? It seems like it might be a nice way to get reproducible dev environments, without some of the headaches being discussed here. Is this a common use, or do people typically just do all-or-nothing?

That's how I started out with openSUSE + Nix, but I quickly found that I still had to learn about most of Nix's quirks, while only getting a small part of the benefits (namely, not the system configuration).

It may be worth it if you care a lot about having imperative escape hatches, but if you're willing to invest upfront work in getting past the learning curve and want to maximize the benefit you get from it, I would just recommend diving into NixOS directly.

Re: NixOS 21.05

#228
post #218

Earlier quoted context omitted.

That's a neat idea and improvement for sure. I'm pretty pessimistic about the outcome here, and perhaps what you said is a most realistic turn. There is a larger issue that still irks me: all this stuff is based off Cargo/Cabal/etc., but I think that's fundamentally the wrong model for our purposes. Historically every C package is a snowflake and we do need to package them individually. But as language-based ecosyste…

I agree with the general orientation in favor of the monorepo and transforming package definitions from repos that don't know/care about Nix, then aggregating them. I think the vision where we use Nix mostly by way of Nix code that has propagated into the source repos of various projects, and we simply use that code directly, probably gets it backwards. > callPackage-style "I am a function of my dependencies" is righ…

The TOML one? That might be might be nice, but we should fix the global namespace issues of NixOS modules first. (Sometimes there are scarse global resources to multiplex access too, but that doesn't mean we should only be able to e.g. run only one postgres instance.)

Re: NixOS 21.05

#229
post #215

What are people's thoughts on running nix without nixos, using a base system such as Debian or Arch? It seems like it might be a nice way to get reproducible dev environments, without some of the headaches being discussed here. Is this a common use, or do people typically just do all-or-nothing?

I would say that it is a good gateway drug. I used Nix + home-manager on macOS for a while. It was really nice for replacing the broken macOS userland plus having reproducible dev environments.

I liked it so much that I tried NixOS on a Dell Workstation that I still had. Configuring a full machine declaratively was so powerful that I slowly moved from macOS to NixOS pretty much full-time.

Re: NixOS 21.05

#230
post #23

Earlier quoted context omitted.

Yes this. I tried this a few times but always ended in me banging against some esoteric issue. For example I tried to nixify a project I had which needs ruby and node. If you think you can spin up any version of ruby you are mistaken. The project removes older versions from time to time. The wrapper to fetch the correct gems from nix to setup the nix-env had really hard problems when gems or npm packages started thei…

> But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix. I think one can do this separately, e.g. run NixOS for the host OS and then do LFS or Gentoo or Arch in a VM where you can easily blow things up and revert to a prior snapshot. Also, flakes takes care of the channels shenanigans by pinning input package versio…

Thanks for the resources! I switched from macOS to linux for my personal machine last summer. I played around with nix on some machines before and also used nix-pkg on macOS but ran into issues. There is a great community behind it and I read a lot about nix (the language) etc. My decision to go with arch was mainly practical. I don't want a huge desktop etc. I wanted to see what gnome etc actually automate for me. I have already a way better understanding what kind of features which I normally take for granted coming from macOS are not part in a base system.

I will give it a go again when I have time as I like the declaritive nature of nixOS.

edit spelling

Post reply on HN