tomberek

My main mission is to make Nix and Nix-based technology mainstream. Please reach out if you are interested, have thoughts or ideas. (plus we're hiring: https://floxdev.com/careers )

This involves improving Nix itself, as well as building tooling for teams and organizations to be successful.

Can you clarify what parts you don't like. I think it's important to distinguish so I know what portions to work on (and figure out how to fix it). Is it: the language syntax itself, the idioms used in Nixpkgs, the module system, the common frameworks used to create package sets, or something else?

I work for Flox and maintain Nix. AMA

I'm excited to see more interest in the core ideas this technology brings. Our vision is to make it accessible - bring this set of super-powers to the world.

Nix is a package manager. But it can weave together multiple package managers so it frees you from being locked in to any one particular language, OS, architecture. The proof of this that we also ended up making a full OS (NixOS). Then there are follow-on things one can do, such as using it to manage the configuration of things and people continue to build more tools for this.

Fundamentally the core technology is for it to be a correct and safe package manager. (eg: think about the engineering tradeoffs for memory-safety vs anything-goes) Once you have that basic primitive, lots of things can be "packages": software, data, configuration, dotfiles,......

I'm working on this project and constantly trying to find the right feature set to make Nix-based technology easier to adopt. We are still early in design and implementation so feedback for either `flox` or `nix` is valuable. AMA

Handling all cases of pre-existing Nix installations, (multi-user, single-user, incomplete, broken, etc) is something we are trying to improve. There is also upstream community work going into improving this experience and we will adopt that as it becomes available. The .deb installs Nix for you, so your best bet is to remove the existing installation (https://nixos.org/manual/nix/stable/installation/installing-...) and try the native installer.

Regardless, I'd like to fix the scenario you are in. Would you be willing to send in some logs or details?

    I tried once before on Mac, but never could get it working properly.

What do you think about our native OSX installer?

Very good question. How will we make money? What is our monetization strategy? We have nothing to hide here. Our monetization is focused on increasing corporate and organizational use.

  1. We love Nix and what we can do with it.
  2. We also know that it is not easy to learn or adopt Nix.
  3. Even if learning Nix would be easier, adoption of new tech becomes harder the bigger the organisation.
  4. The bigger the organisation, the “weirder” their requirements (from the perspective of an open source project). Not all of those requirements make sense to include in an open source version, but would make a big difference for enterprise adoption.
  5. We want to make it possible for you (the Nix user) to be able to bring Nix-based technology to your organizations and to be an effective ambassador.
  6. Enterprises require a different set of features than anyone else; and they will pay for them.

hypothetical Dockerfile:

    FROM python
    FROM nodejs
    RUN sh -c 'python ... | node ...'

Imagine this Dockerfile being valid. We want to express the idea of composing these two images into one and using binaries from both. Consider that those might have conflicting /usr/lib contents?! This is easy with flox+nix because that conflict doesn't happen.

There are other benefits such as: - minimal containers - automatic extraction of artifacts and their runtime-dependencies - no more pushing your compilers into prod - no cleaning steps (apt-cache clean) - declarative - reproducible - more fun!

We think the ability to hopscotch between projects and ecosystems without fear is a key value proposition of Nix-based technologies. Our approach is to address the entire user experience from installation and docs all the way to developing, building, publishing, orchestrating, and sharing your software. It is not all ready - we can't do all of it at once; we are laying down the framework.

Please give us a try and offer any feedback, we want to make it easy to adopt for even non-Nixers and enterprise.

We see a few tools that do a similar built-on-top-of-Nix approach, so we released a Rust library that makes using the "command line API" in a more type-safe manner: https://github.com/flox/runix

> This sounds in some ways pretty similar to something I'd been imagining for Nix, particularly for the purpose of grabbing package definition sources which have been known to work for a given version or range. (The use case is automatically grabbing or generating packages for given semantic versions instead of by Nixpkgs hash.)

Yes, this is something users often expect. We make this more efficient than grabbing a unique Nixpkgs hash for each package, which would mean lots of downloading and disk usage for each one - instead our catalog lets you bypass that need.

> I'm interested to see what all they've done with the catalog, and I wonder if it will ever be brought to Nix proper.

Some of the ideas need design iteration before it would be proper to bring into Nix. Some building blocks have already been incorporated (eg: eval-store, impure-derivations and fetch-closure were funded and inspired by flox).

What portions are of greatest interest?

(i'm on the flox team): A major point of feedback we got from non-Nix users were that they wanted something similar to other package managers. So we looked at the primary differences and focused on designing a user experience with few show-stopping blockers for initial adoption. The goal is to guide people into the declarative side and a gentle introduction to the Nix language and ecosystem.

> Even as a NixOS daily driver, I'm having a hard time understanding how Flox is more than a few shell aliases and a hosted backend.

That's exactly how this started, to "smooth out the rough edges" of Nix. Some of our changes are also being up-streamed into Nix itself, so these aliases and the wrapping can become thinner over time and we can turn our focus to the feature sets that enterprises and organizations want. We are still iterating on:

- easy access to semantic versions - access to a Catalog where each package is known to be built and cached - opinionated nix expression structure - make it easier for users to publish their own software for others to re-use - CLI interface provide interaction with the user - platform native installers (no more `curl | sh`) that use the upstream installer under-the-hood

As a teaser for things on our road-map: - imagine writing a Nix expression that is as simple as a Dockerfile - easy access to transforming your environments, packages, and derivations into different formats - opt-in centralized management of environments - visibility into the environments used by team members and colleagues - optimize AllTheThings(tm)

The most important thing to note is that this is our foray into developing flox in the open and we value all the feedback, thoughts, and especially criticisms.

Hi HN! From the flox team; today we’re thrilled to release the flox CLI beta to the public as an open-source project, to give developers seamless access to the powers of Nix. Try it now via the flox CLI (https://floxdev.com/docs) and check out the repo on https://github.com/flox/flox.

Ask us anything.

winning

Pretty sure I started with this: https://github.com/prest/prest/blob/main/cmd/root.go

And from there you can execute your own command and add handlers or other things as you wish.

I’ve used Prest (the Go reimplementation of PostgREST) because I could more easily customize or bring it in as a library in a larger application.

Yes! I did two years in awk (https://github.com/tomberek/advent) and loved the ability to dig in and truly grok the language. The performance wasn’t bad, but the multidimensional array support and ergonomics were…meh. I’m contemplating Elixir.

We are doing heavy re-factoring and re-design, so there isn’t much useful to see at this point. We are looking to refine the design and user experience. We do plan to have all the client portions open-source once we have less churn.

Most of what we are working on are either new concepts or don’t belong in Nix itself. As we see portions that are appropriate to upstream, we will do so. That being said, we have already done a fair bit of Nix development and continue to do so.

Thanks for posting! I am working on this, ask me anything.

Nix is the package manager that works on a multitude of operating systems. Then there was the thought “what if we use this same underlying technology to make a Linux distribution” and “we can manage services in a declarative manner” which became NixOS.

If something is well-maintained, it is usually pretty easy to make Nix derivation for it. The strict discipline that Nix imposes usually becomes an issue exactly when something is not well maintained or has fundamental issues with how it is managed, but this would be a problem for adoption or port to any other package manager.

That last proposal is mine! Thanks for the Go implementation, I’ll have to play with it some time. Looks like you’ve built something very close to my intention. Did you come across any additional changes needed to the spec? Any suggestions or results from going through the implementation that would help?

Another thought is if it is possible and how to coordinate te re-using dictionaries.

I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years ago. I can package large projects from different ecosystems (python 2/3, c/c++, go, Javascript, Octave, Rust) and be confident they will not interfere with each other. I can try bleeding edge software with no risk to it interfering with my system. It is faster and less hassle than juggling various Docker containers and VMs. It protects me from dependency hell. Using Nix to manage an operating system (ie: NixOS) then gives me those benefits for my entire machine. Then I get even more benefits when using Nix on any other (not even necessarily NixOS) machine by pushing around package closures and managing a simple binary cache.

But overall: it makes me more productive. It is my secret weapon to manage the complexity of software development. The benefit is not on day 1, but on day 100 and day 1000.

Is there any interest in a Forth-style approach?

SSE has been extremely useful for my purposes. And the issues with scaling it are similar in nature to scaling and getting a similar feature set out of any solution. But in terms of speed to PoC/MVP nothing has been as easy as SSE. The final reasoning is that it can easily be inspected, debugged, curl'd, and so forth.

Not sure how often this is done, but I've been sending query parameters along with the request and using it to stream results back to the client for low-latency initial responses to long-running API calls.

Okay. Looks like there is an issue for duplicate profile entries already; just hasn’t gotten attention. https://github.com/NixOS/nix/issues/5587 I’ll take a look.

The verbosity of “legacyPackages.x86_64-linux.ripgrep” in the search results may be too much. We can omit the default portions or provide the full detail somewhere less prominent.

This is an often unappreciated killer feature in Nix. (perhaps not well explained or documented?)

copy runtime requirements:

    nix copy --to s3://some-bucket ./result

copy full build description:

    nix copy --to s3://some-bucket ./result --derivation

copy runtime of the buildtime:

    nix path-info -r nixpkgs#hello --derivation | xargs -n1 nix path-info | nix copy --to s3://some-bucket

Then you set your substituter to s3://some-bucket either in nix.conf or in CLI with --substituters

Or if you don't like s3, point it to https, ssh, or a simple local file directory.

That article is merely making the argument that reproducibility on its own does not improve security. This is clearly true. Anyone can also claim that code-signing does not improve security because "well, you have to trust either this blob of software, or this certificate blob, or this signature, what's the difference?" The difference is when you start to compose these parts into a larger system. Dependable qualities of a system (eg: a specific hash function is one-way, or that specific problems are hard/easy to solve) can be used to create the security properties you want.

I doubt Tavis is saying that builds should not be reproducible; just that it is not going to provide security on it's own in a trivial manner. I'd argue that reproducibility can help create secure systems with properties otherwise unobtainable (or difficult).

profile removal: Fixed in https://github.com/NixOS/nix/pull/6086

search speed:

    $ time nix search nixpkgs ripgrep
    * legacyPackages.x86_64-linux.ripgrep (13.0.0)
      A utility that combines the usability of The Silver Searcher with the raw speed of grep
    
    * legacyPackages.x86_64-linux.ripgrep-all (0.9.6)
      Ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, and more
    
    * legacyPackages.x86_64-linux.vgrep (2.6.0)
      User-friendly pager for grep/git-grep/ripgrep
    
    real    0m0.514s
    user    0m0.494s
    sys     0m0.019s

We're trying to improve the UX with the new CLI. Precisely to improve the developer experience and quality. Any other major gripes?