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

Tvix – A New Implementation of Nix

tvix.dev

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Tvix – A New Implementation of Nix

#91

Post by TheFuzzball »

aidenn0 wrote: post #47
Izmaki wrote: post #11

For somebody who hasn't used Nix yet, but heard good things about it, why use Tvix instead of Nix? The page didn't seem to mention the reason(s) behind the project.

I would recommend against using Tvix at this time, but if you are wondering why they wrote it, they wrote an article: https://tvl.fyi/blog/rewriting-nix The goals they list are: > Creating an alternative implementation of Nix that is fully compatible with nixpkgs. No explanation needed. > More efficient Nix language evaluation, leading to greatly increased performance. The Nix language is evaluated whenever doing the…

> > A builder implementation using OCI instead of custom sandboxing code.

> Hermetic builds require some sandboxing; Using OCI containers seems like an obvious choice, but didn't exist when Nix was first created.

Presumably this would make this implementation Linux-only, since OCI isn't natively supported outside of Linux?

Re: Tvix – A New Implementation of Nix

#93

Post by eviks »

tazjin wrote: post #89
eviks wrote: post #80

Earlier quoted context omitted.

Why would you remember anything from a hash instead of the infinitely more usable name+ version (a more-than-enough-unique combo?

If you have an actively used Nix system with a large disk, it's very likely that you have a large number of (unused) deriations with the same prefix in there. A derivation is also a lower-level thing than a package, so it's not guaranteed that you have a useful name & version in there. I just checked on my laptop and I have, for example, over 400 stdenv-linux build outputs in there.

That still doesn't explain how 400 hashes are more useful than name+version+hashes

(this'd still suffer from the common fail of flat folders, should've used proper nesting, but not as much as hash-first)

Re: Tvix – A New Implementation of Nix

#94

Post by tazjin »

eviks wrote: post #93
tazjin wrote: post #89

Earlier quoted context omitted.

If you have an actively used Nix system with a large disk, it's very likely that you have a large number of (unused) deriations with the same prefix in there. A derivation is also a lower-level thing than a package, so it's not guaranteed that you have a useful name & version in there. I just checked on my laptop and I have, for example, over 400 stdenv-linux build outputs in there.

That still doesn't explain how 400 hashes are more useful than name+version+hashes (this'd still suffer from the common fail of flat folders, should've used proper nesting, but not as much as hash-first)

To determine how useful something is it's important to look at the usecase.

My usecase for interacting directly with the store is that I want to look at some specific store path, so I already know the hash from somewhere and can autocomplete on the first characters with much higher precision than first completing drv names, and then moving on to the right hash.

You seem to have some other kind of use-case. What is it?

Re: Tvix – A New Implementation of Nix

#95

Post by otabdeveloper4 »

tazjin wrote: post #85
otabdeveloper4 wrote: post #79

Earlier quoted context omitted.

> A builder implementation using OCI instead of custom sandboxing code. A complete non-starter, never in a thousand years am I gonna use something that requires a Docker installation for building derivations.

Maybe once you learn what OCI is, you'll rethink that ;)

I know full well what OCI is. (Hint: it's a transparent attempt to be a NOT-docker and avoid infringing on whatever Docker Inc.'s latest monetization scheme is.)

Using this for what Nix is doing is absolute madness. Docker is madness in general, but dragging it into Nix's core is madness cubed.

Re: Tvix – A New Implementation of Nix

#96

Post by eviks »

tazjin wrote: post #94
eviks wrote: post #93

Earlier quoted context omitted.

That still doesn't explain how 400 hashes are more useful than name+version+hashes (this'd still suffer from the common fail of flat folders, should've used proper nesting, but not as much as hash-first)

To determine how useful something is it's important to look at the usecase . My usecase for interacting directly with the store is that I want to look at some specific store path, so I already know the hash from somewhere and can autocomplete on the first characters with much higher precision than first completing drv names, and then moving on to the right hash. You seem to have some other kind of use-case. What is i…

the usecase is described right there in the first comment

And 2_of_name + 2_of_hash is giving you higher precision in one match as it has more info to match against the full path vs just 2_of_hash

Re: Tvix – A New Implementation of Nix

#97

Post by flurie »

tazjin wrote: post #90
flurie wrote: post #78

Earlier quoted context omitted.

> Tvix explicitly targets stable Nix features, so supporting Flakes is a non-goal. Except that it rolls its own CA store[1], which is also not a stable Nix feature. One could argue that it has to roll its own store because Nix wants to own the store, but implementing a shadow version of an experimental feature makes the "they're just targeting stable features" part ring rather hollow. > The key point of Tvix _not_ ha…

Flakes are a misfeature that adds a complicated layer of abstraction over an already not very simple system. I follow some chats with lots of Nix beginners, and the amount of people that are now stuck in a flakes tarpit and have no understanding of the fundamentals of Nix (and no path to get there, really, in the course of normal usage) is depressing. Just the other day I saw someone post a 40 line Nix code snippet u…

Sure, and this is all fine, but it feels like this information gets buried or smoothed-over, and I think you strengthen your position by leading with it as a differentiator. Nobody new to Nix knows what targeting 2.3 means, but they likely know what flakes are, and you aren't doing a lot to make it clear why they should prefer a fast language evaluator to something that can handle flakes.

Re: Tvix – A New Implementation of Nix

#98

Post by gcr »

otabdeveloper4 wrote: post #95
tazjin wrote: post #85

Earlier quoted context omitted.

Maybe once you learn what OCI is, you'll rethink that ;)

I know full well what OCI is. (Hint: it's a transparent attempt to be a NOT-docker and avoid infringing on whatever Docker Inc.'s latest monetization scheme is.) Using this for what Nix is doing is absolute madness. Docker is madness in general, but dragging it into Nix's core is madness cubed.

"why yes, the open-source Apache-licensed implementation controlled by the linux foundation is just as commercial as the commercial thing! i'm so contrary and interesting!"

if you don't want docker-contributed code, here are some alternative implementations of the spec: https://github.com/opencontainers/runtime-spec/blob/main/imp... I believe nix could use one of these with some volunteer effort? Perhaps you could even be the one to purge the Docker heresy from the project!

Re: Tvix – A New Implementation of Nix

#99

Post by aidenn0 »

dlahoda wrote: post #72
Filligree wrote: post #68

Earlier quoted context omitted.

That’s a pity. IMO the lack of static typing is one of the biggest flaws of the language, and it persistently slows me down.

pure flake nix with nixos modules is strongly statically typed. in this case typing is evaluation. so tvix promises doing typing faster.

I guess it does depend on what you consider evaluation-time to be e.g. “Haskell is a dynamically-typed, interpreted language.”[1]

1: https://aphyr.com/posts/342-typing-the-technical-interview

Re: Tvix – A New Implementation of Nix

#100

Post by kmacleod »

otabdeveloper4 wrote: post #95
tazjin wrote: post #85

Earlier quoted context omitted.

Maybe once you learn what OCI is, you'll rethink that ;)

I know full well what OCI is. (Hint: it's a transparent attempt to be a NOT-docker and avoid infringing on whatever Docker Inc.'s latest monetization scheme is.) Using this for what Nix is doing is absolute madness. Docker is madness in general, but dragging it into Nix's core is madness cubed.

Would this be the equivalent of Mock (Fedora) or sbuild (Debian) pristine chroot builders? Containers are just fancy chroots.
Post reply on HN