Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixCon Live

2020.nixcon.org

Post reply on HN
Print view View original

31–40 of 50 posts

Re: NixCon Live

#31

Post by catern »

est31 wrote: post #26
catern wrote: post #22

Earlier quoted context omitted.

Note that the source code is referenced by a hash, so it can't change without changing the package. Also, the source code of all packages built by Hydra is on cache.nixos.org alongside the resulting binaries.

Are those sources target independent or specific for each new build of the package? That is, is there a new source code package on hydra when one of the dependencies changes? Or does it only change if the package itself changes? Also, they are only available when hydra builds the package anyways, right? So if some package is not built by hydra (like how it used to be for the texlive packages), it'll still download th…

A sibling comment replied to your first paragraph, so just about the second two:

>Also, they are only available when hydra builds the package anyways, right? So if some package is not built by hydra (like how it used to be for the texlive packages), it'll still download the sources from the various places they are hosted.

Yes.

>As for the hash, it's good that the source code is hashed, but my main concern was that it was downloading from external sources in the first place. This is bad for privacy, as those hosts know I'm downloading from them, as well as for reliability, because the hosts might not have as good uptime as a debian package mirror.

That's a true and valid concern, but note that it's the same situation as with Debian: If the package is built upstream by Debian/the NixOS Hydra instance, then you have reliable, private access to its source code so you can rebuild it. If it's not built/packaged upstream, then you need to get the source from somewhere else.

The discrepancy is just that there's packages in Nixpkgs which are not built upstream, and which get built only locally on your machine or your own Hydra instance. There are not many of these, but yeah, it would be nice to fully get rid of them.

Or, an interesting option would be to build the source for more packages on Hydra, without actually building the binary for the package. That wouldn't be too hard, if someone adds an expression for doing it.

Re: NixCon Live

#32

Post by the_duke »

It's important to note that Nix(OS) is really 3 things:

A functional language, a package manager and an operating system.

I switched all my desktops and laptops to NixOS at the beginning of the year, and I'm starting to use introduce it at multiple companies for data science / ML work environments with full reproducibility and Kubernetes bare metal deployments.

Main benefits:

* pure build system

* extremely easy way to set up and switch between custom environments with their own sets of dependencies (nix-env, nix-shell)

* nix (the package manager) is cross-platform and works on MacOS and other Linux distros (although that's not always smooth sailing...)

* Ephemeral environments that are quickly set up and torn down, like the `nix-shell --packages vlc --run "vlc https://dash.nixcon.net/dash/master.m3u8"`

* (mostly) fully reproducible OS and user environments

* patching and/or locally building dependencies without ending up with a messy system

I can now finally get a (almost) 100% reproducible user environment including hardware configuration (kernel modules, disks, ...), installed packages, configurations, ...

home-manager [1] even enables declarative configuration of things like VS Code/Vim/Firefox plugins, and provides statically typed configuration options for many applications. The package repo is also very comprehensive.

For manually managed servers that aren't just bootstrapped from VM/cloud images the benefits are also wonderful.

It's definitely not all smooth sailing though:

* There is documentation, but it's spread across a lot of pages, disorganized and sometimes quite outdated or incomplete. I often have to read the source code - which is also mostly undocumented.

* Running unpackaged software: you can't just download binary releases and run them, unless they are fully statically linked (like most Go binaries). Instead you either have to whip up a package definition, or manually try to get the binary working (eg with patchelf)

* The language is somewhat quirky. As often the case with such niche languages, documentation and tooling are very subpar and debugging is not exactly a joy. I wish Nix was built on a more common language with good tooling around it. I bet it would be quite a bit more popular, due to the lower barrier of entry. You get used to it though if you are willing to put in some effort.

* Package ecosystem: the package repo is really comprehensive, but maintainership for some less popular ones is not up to Arch + AUR levels. Also the auditing for a lot of the packages is very limited. For any security critical environments or server deployments I would definitely limit myself to a hand full of core packages and/or be prepared for manual auditing. I wish the repo was split up more like Arch into core and community, with different guarantees for auditing and maintenance. (the Flakes effort will hopefully help here quite a bit)

All in all Nix is great though, and it's impressive how stable and featureful the ecosystem has become, despite being somewhat of a niche "product".

[1] https://github.com/nix-community/home-manager

Re: NixCon Live

#33

Post by X6S1x6Okd1st »

I've been using it on my main computer for about 6 months now.

It's been the steepest learning curve, but yeilded the biggest dividends so far.

The other day I needed to install some software from a specific 3 year old branch. Copying the default.nix for the up to date version and changing a few of the options got it up and running with minimal fuss.

There are certainly some rough edges around usability, but the fundamental value prop is immense.

Also just using nix as a secondary package manager on mac or some other Linux distro is great, I'd expect shell.nix to start showing up in an increasing amount of OSS projects. It showed up in hashicorp's latest project

Re: NixCon Live

#34

Post by garethrowlands »

steveklabnik wrote: post #19
nikivi wrote: post #9

Earlier quoted context omitted.

Is this harder to achieve for the Rust ecosystem (due to some properties of Haskell perhaps)? Or just no one put in the effort in doing it? Is it expensive to maintain all the binaries for all of Hackage?

There's a couple of challenges here with Rust. None are insurmountable, but there are just other things that are higher priority. There are 15,000 packages on Hackage, but 48,000 on crates.io. According to http://www.modulecounts.com/ hackage is getting about four new packages a day right now, and crates.io is getting 54. This means that expense is more of an issue. I don't know about Haskell, but in Rust, many proje…

If Rust does more inlining than Haskell, it does _a lot_ of inlining! Haskell doesn't monomorphise (it calls it specialise) much by default though.

Re: NixCon Live

#35

Post by garethrowlands »

nikivi wrote: post #12
zaphar wrote: post #10

Earlier quoted context omitted.

It's not inherent to the language. It's inherent in the build tooling. Back in the cabal days haskell had the same problems. Nix is a more hermetic build and packaging tool which is why it's better at it.

Very curious to read about what it means to have a `hermetic build and packaging tool`. In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.

I think that 'hermetic' here means that the build cannot depend on anything other than its input - it's built in a sealed environment where nothing other than the inputs is available. This property makes it more likely that the build products do indeed depend only on their explicit dependencies and not implicit dependencies.

The problem with caching just on package name and version is that there are many different possible flavours. For example, multiple different versions of the sourcecode may have the same given version number. Things such as target architecture, optimisation level, and optional features confuse things further. Nix therefore uses a hash of all the inputs as the cache key.

Re: NixCon Live

#36

Post by est31 »

catern wrote: post #31
est31 wrote: post #26

Earlier quoted context omitted.

Are those sources target independent or specific for each new build of the package? That is, is there a new source code package on hydra when one of the dependencies changes? Or does it only change if the package itself changes? Also, they are only available when hydra builds the package anyways, right? So if some package is not built by hydra (like how it used to be for the texlive packages), it'll still download th…

A sibling comment replied to your first paragraph, so just about the second two: >Also, they are only available when hydra builds the package anyways, right? So if some package is not built by hydra (like how it used to be for the texlive packages), it'll still download the sources from the various places they are hosted. Yes. >As for the hash, it's good that the source code is hashed, but my main concern was that it…

> That's a true and valid concern, but note that it's the same situation as with Debian

Good point!

> an interesting option would be to build the source for more packages on Hydra, without actually building the binary for the package. That wouldn't be too hard, if someone adds an expression for doing it.

Yes, that would be awesome!

Re: NixCon Live

#37

Post by abathur »

wtetzner wrote: post #30

> To watch the stream from VLC on your computer, run: > nix-shell --packages vlc --run "vlc https://dash.nixcon.net/dash/master.m3u8 " I thought this was pretty cool, but unfortunately, this doesn't work on macOS...

Won't really save you today, but you should be able to replace vlc with mpv; I'm currently viewing the presentations from macOS in this manner.

Re: NixCon Live

#38

Post by DenseComet »

wtetzner wrote: post #30

> To watch the stream from VLC on your computer, run: > nix-shell --packages vlc --run "vlc https://dash.nixcon.net/dash/master.m3u8 " I thought this was pretty cool, but unfortunately, this doesn't work on macOS...

That command temporarily installs vlc and launches vlc from the command line. If you already have vlc installed, you can do "vlc https://dash.nixcon.net/dash/master.m3u8"

Re: NixCon Live

#39

Post by JamesSwift »

Nix (specifically nix package manager on MacOS) sits in a weird spot where it is absolutely indispensable for me personally but I am absolutely hesitant to recommend it to others without extreme caveats. I really wish the UX of it were much better, which ideally then would lead to higher adoption and less frequent 'osx-isms'.

Re: NixCon Live

#40

Post by wtetzner »

DenseComet wrote: post #38
wtetzner wrote: post #30

> To watch the stream from VLC on your computer, run: > nix-shell --packages vlc --run "vlc https://dash.nixcon.net/dash/master.m3u8 " I thought this was pretty cool, but unfortunately, this doesn't work on macOS...

That command temporarily installs vlc and launches vlc from the command line. If you already have vlc installed, you can do "vlc https://dash.nixcon.net/dash/master.m3u8 "

Yes, I know. nix-shell on macOS works fine for me, but vlc fails to install because the Nix package is not supported on macOS.

I was just sad that I couldn't use the cool Nix magic to view the stream.

Post reply on HN