jljljl

You should check out Devbox (https://jetpack.io/devbox) if you want local dev without the container overhead.

It provide a nice interface for creating native, local dev environments using the Nix package manager, which is especially helpful if you or your friends struggle with the Nix language. It also lets you use your local tools with your dev environment.

I think the split between Flakeful and Flakeless Nix that the article mentions is a big challenge for developers coming in new to the ecosystem. There's a video that recently circulated of Geohotz trying Nix from scratch[0], where the mixed messaging on whether to use Flakes caused a lot of initial confusion.

We've gone pretty all in on Flakes with our Devbox product[1] -- We think they simplify a lot of confusion on how to package and use Nix once you embrace them. I hope they become a more accepted standard in the future.

[0]: https://youtu.be/v7lIGYU0onA?si=3Wpbx82GcZVxwKY6&t=5256 [1]: https://www.jetpack.io/blog/why-did-nix-adopt-flakes/

The 2% is the amount spent specifically on the Linux _Kernel_. The top 3 categories are:

- Cloud, Containers, and Virtualization: 25%

- Networking and Edge: 13%

- AI, ML, Data & Analytics: 12%

Also worth noting: 72% of the revenue is spent on Open Source Software, and 20% is Spent on Open Source Specifications. Full report is here: https://www.linuxfoundation.org/hubfs/Reports/2023_lf_annual...

I don't know what projects fall into those categories, but it's reasonable that supporting Virtualization and Networking could support Linux adoption and stability, without directly contributing to the Linux kernel itself.

You can play Mad Libs with any paragraph, but it doesn't mean the argument has been applied correctly.

My point is that any project needs to properly balance the goals of the project with the freedom and autonomy of other people. This is not saying that the goals always triumph, or that autonomy always triumphs, but that there is a balance.

You asked what this has to do with e/acc -- if e/acc is claiming progress at all costs, build at all costs, but then imposes carve outs for the freedom/autonomy of only certain people (particularly it's adherents), it's a contradiction in the project.

This response is literally NIMBYism: "Build build everywhere, just Not In My Back Yard. My neighborhood is special".

If you believe that acceleration is critical, then you should be willing to take some sacrifices yourself in order to build or expand. If you start making exceptions, then you are saying that acceleration and growth itself is not inherently good, but only good in _some_ places when it impacts _some_ people.

People generally want to program to accomplish goals, and they want to minimize the amount of setup time and yak-shaving needed to start working on those goals.

Nix does solve a lot of complex problems and gives you a lot of control over your dependencies. But if the complexity to start using Nix for your project is too high, then you're going to opt for a less powerful solution that lets you get stuff done.

I say this as someone who really loves Nix and the power it provides -- the UX is a huge challenge for adoption. It's better to confront that fact if we want Nix to succeed.

If the emergency disrupts cell service, there would be no way to remotely take control of the vehicle.

Flakes have a set of default outputs they can generate, like packages, devShells, templates, and NixOS configs. Nix knows how these outputs work and can validate them using `nix flake check`, or list them with `nix flake show`

But what if you want your flake to output a library? A Dockerfile? A Terraform or Kubernetes config? Nix doesn't know about those custom outputs, and doesn't have a way to validate that you're using them correctly.

Now with Flake Schemas, you can provide a schema so that built in tools like `nix flake show` and `nix flake check` can properly validate the new output. This makes it easier for Flake developers to communicate the interface of their custom output to Flake consumers

This is awesome! We used a similar SemVer interface for installing standard nix packages on Nixhub (www.nixhub.io), and a lot of users told us it was a killer feature. Having a nice search interface should help a lot with Flake discoverability, which is currently a big challenge.

Great work from the Determinate Systems team!

That's really cool! Was it as simple as running `devbox add livebook@latest`? Or did you need to configure it in any way?

Finally, physical NFTs

Hey! Cofounder of Devbox here.

One aspect I would emphasize about Devbox is that we're focused on providing some of the best properties of Nix (easy to install packages, reproducibility, and ephemeral dev environments) without requiring developers to master the Nix DSL.

We've also added features that help with some rougher parts of Nix, like the ability to search and pin specific package versions using `pkg@version` in your config. See our post here for more details: https://www.jetpack.io/blog/0-5-0-install-nix-packages-by-ve...

We've heard from teams that adopt Nix and Devbox that this simplified JSON config helps with onboarding developers. If you're looking for a way to share your local dev environment with other developers, Devbox could be a good choice.

We're parsing periodically (though our index is more up to date than Nix Package Versions at the moment). We've also truncated pre-Flakes commits, though we are planning to include those in the future

Thank you!

We're planning a longer post that explains the architecture and process of building the index. An extremely basic description of what we do can be found here: https://www.jetpack.io/blog/0-5-0-install-nix-packages-by-ve...

  First, we processed build outputs from Hydra to map package names + version numbers to commits in the Nixpkgs repo. We then created a service that stores this index as a prefix tree, making it easy to search for a specific package and version in Nix.

There's some extra cleanup required to make the index really usable, which we'll share in the follow up post

For the merged packages -- we have a hardcoded "canonical names", which map the various attribute paths like `nodejs_20` and `nodejs_18` to a single, easier to search name (like `nodejs`). We originally designed this so that Devbox users (who may not be familiar with Nix naming conventions) can just type `devbox add nodejs@20` and get the right package version.

Hey! Author of this post here, happy to answer any questions about Nixhub!

Fuzzy search is definitely on our todo list!

We haven't open sourced it, but we are planning to write a deep dive on how we built the index and how the search service works.

I suppose they could, but for various reasons they haven’t.

We originally built this for Devbox users because it was a common request, and realized that it could help Nix users as well.

https://search.nixos.org/packages only shows packages that are available on the latest stable and unstable releases of Nixpkgs. The means they only have a limited number of versions for a given package available. For example, Python on unstable only has 5 versions to choose from:

  - 2.7.18
  - 3.9.17
  - 3.8.17 
  - 3.11.4
  - 3.12.0b3

If you need something different, you need to find a specific commit of the NixOS/nixpkgs repo that has that version. This information is not indexed or searchable on the official package search. Nixhub.io provides an index of these older released commits, so you can find and install versions that aren't available in the latest Nix releases.

If you visit https://www.nixhub.io/packages/python, you can see we have a lot more versions available. Developers can use the Nix or Devbox references on that page to install the version they need.

Cool bonus feature of Nixhub.io I wanted to share -- Package pages are linkable/bookmarkable!

So if you want to view all the versions available for NodeJS, you can visit https://nixhub.io/packages/nodejs

You can even link to a specific version with an anchor link. For example, you can see NodeJS 19.8.0 at https://nixhub.io/packages/nodejs#19.8.0

You can use 2 spaces after a newline to format it:

  let 
     pkgs = import nixpkgs-old { system = "linux-x86_64"; } 
  in 
     pkgs.mkShell { packages = [ pkgs.node ]; }

Combine this with the input statement in the comment below to get a decent flake. You can mix and match multiple inputs if you want to install different versions of packages

A few ways to use it are:

1. Install in your global profile with the CLI:

  nix profile install nixpkgs/3276b62e6639096014652132f4824ac2b4f2a2c4#nodejs

2. In a flake.nix, you can set an input with the nixpkgs commit hash, like:

  inputs = {
    node-nixpkgs.url = "nixpkgs/3276b62e6639096014652132f4824ac2b4f2a2c4";
  };

...and then use nodejs from that `node-nixpkgs` input to get the exact version you wanted

Two benefits to Nix that I can think of:

1. It has a wider range of packages available vs asdf. Asdf can support runtimes that have an asdf plugin, whereas Nix has over 80,000 packages available in it's registry

2. Nix also handles the dependencies for the packages you want to install. If you runtime requires a compiler, specific libraries, etc, Nix will ensure those are installed.

Of course, Nix can be challenging to get started with. If you want to try Nix but find the language intimidating, you can try something like Devbox first.

The comment in the README was tongue-in-cheek, but we've updated to clarify that not all the configuration languages listed are turing-complete.

TySON (TypeScript Object Notation) is a subset of TypeScript, chosen to be useful as an embeddable configuration language that generates JSON. You can think of TySON as JSON + comments + types + basic logic using TypeScript syntax. TySON files use the .tson extension.

Thank you for commenting! I didn't get those details in the first read of the report, but looking through now I can see what you mean.

It definitely does convey that once things were going wrong, the relationship broke down quickly, and it was hard to adapt once the trust was lost.

The issue was that in this case they couldn’t — a lot of the BRT benefits came from creating a center lane, and that center lane was infeasible unless they did the utility project first.

There was a Grand Jury report analyzing the causes of the delay in the Van Ness project. While the unexpected conditions of the underground utilities is cited as the primary cause, it does touch on some project management aspects that you mention as opportunities for improvement:

https://civilgrandjury.sfgov.org/2020_2021/2021%20CGJ%20Repo...

Ironically, more planning and analysis at the beginning of the project (e.g., by potholing and inspecting the condition of utilities underneath Van Ness may have avoided the construction delays.

Yeah, this is a much better example and reflection of how weakened institutions and process can drive up costs.