91–100 of 144 posts
Nix strikes me as an incredibly well thought out solution to a set of problems that should not exist. The OS should be immutable. Apps and services and drivers/extensions should be self contained. Things should not be installed “on” the OS. This entire concept is a trillion dollar mistake.
Looks like they are trying to force versions into where there are none. Just like trying to force a square cube into a round hole. "Default versions" breaking things that depend on them? What is that? It is like using docker's ":latest" tag and being surprised each time that a new server falls on its face because the "default" image is actually a different version from the previous "default" image. I don't understand…
What works better to raise VC (which for many is the goal) A nix wrapper or a deployment platform
>The biggest problem with Nix is its commit-based package versioning. I am naive about Nix, but... ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4 Odd to attach yourself to Nix then blog against its USP.
Eh. I've been using nixOS for years now and still find that I often desperately, desperately wish I could upgrade just one program that I need a new version of without risking that, you know, any individial single one of my installed packages has a change between the last update and now that messes up my workflow. Or that I could pin a version of a software that I'm happier with that version of without essentially ro…
Now compare the above with how you would customize a version in other systems, like Debian with apt-pkgs ...
>The biggest problem with Nix is its commit-based package versioning. I am naive about Nix, but... ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4 Odd to attach yourself to Nix then blog against its USP.
Eh. I've been using nixOS for years now and still find that I often desperately, desperately wish I could upgrade just one program that I need a new version of without risking that, you know, any individial single one of my installed packages has a change between the last update and now that messes up my workflow. Or that I could pin a version of a software that I'm happier with that version of without essentially ro…
Maybe we were holding it wrong, but, we ultimately made the call to move away for that reason (and more)
>The biggest problem with Nix is its commit-based package versioning. I am naive about Nix, but... ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4 Odd to attach yourself to Nix then blog against its USP.
Eh. I've been using nixOS for years now and still find that I often desperately, desperately wish I could upgrade just one program that I need a new version of without risking that, you know, any individial single one of my installed packages has a change between the last update and now that messes up my workflow. Or that I could pin a version of a software that I'm happier with that version of without essentially ro…
$ nix run nixpkgs#firefox -- --version
Mozilla Firefox 138.0.1
$ nix run github:nixos/nixpkgs/nixos-unstable#firefox -- --version
Mozilla Firefox 139.0.1
$ nix run github:nixos/nixpkgs/b98a4e1746acceb92c509bc496ef3d0e5ad8d4aa#firefox -- --version
Mozilla Firefox 122.0.1
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";
nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";
nixpkgs-b98a.url = "github:nixos/nixpkgs/b98a4e1746acceb92c509bc496ef3d0e5ad8d4aa";
};
outputs = { self, nixpkgs, nixpkgs-unstable, nixpkgs-b98a }: {
nixosConfigurations.yourmachinename = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
specialArgs = {
nixpkgs-unstable = import nixpkgs-unstable {
system = "x86_64-linux";
};
nixpkgs-b98a = import nixpkgs-b98a {
system = "x86_64-linux";
};
};
---snip---
packages = with pkgs; [
dillo # from stable nixpkgs
nixpkgs-unstable.firefox # from unstable
nixpkgs-b98a.whatever # from some exact commit of nixpkgs
]
Earlier quoted context omitted.
Both languages have enormous cargo-culting issues when you try to do anything that isn't fizzbuzz. The bigger difference that I'd expect people to identify is that Rust generates freestanding binaries where Go software requires a carefully-set runtime. There are pros and cons to each approach.
None of them generate true freestanding executables by default. Both Go and Rust require glibc. And Go's runtime is built-in by default. Unlike Java so there's nothing to "carefully set".
In Go you run this to build:
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' .
From the headline I thought they were making a single incremental change (Nix) but the article sounds like they’re doing an entire rewrite under a new project name: > Since we transitioned away from Nix, we also transitioned away from the name Nixpacks in favor of Railpack. We also changed the codebase from Rust to Go because of the Buildkit libraries. Suddenly the move away from Nix seems less like an incremental ch…
Edit: Although looking at it, maybe not?
Both the new project railpack[0] and the older one nixpacks[1] are both started by and mostly written by the same person[2], who is also the author of the article in question. So it doesn't look like a team change.
It still feels... odd? Less that they made the change, projects go from Rust to Go all the time. But usually it's because of issues with Rust (hard to hire for, learning curve, etc.), describing it like this feels unusual?
[0] https://github.com/railwayapp/railpack
Okay I'm a Nix enthusiast but you'll have to trust me when I say that I'm not criticizing them for moving away from Nix; it isn't that strong of an emotional attachment. However, I'm not really sure I understand some of these complaints and they really could use more explanation. For example: > The biggest problem with Nix is its commit-based package versioning. Only the latest major version of each package is availa…
I don't use Nix, however this seems dismissive: > While Nixpkgs is an amazing resource, Nix != Nixpkgs. If Nixpkgs is the default and alternatives require additional research and effort then for most users it _is_ Nix. > That doesn't make any sense. You can literally just split them into separate layers in whatever arbitrary fashion you'd like. The built-in Nixpkgs docker tooling has some support for this even. Is th…
In the documentation[0] they're right next to each other, and `buildImage`[1] (builds a single layer) specifically calls out that you probably want to use `buildLayeredImage` or `streamLayeredImage`[2] (both produce a separate layer per dependency) instead.
Neither should cause the final image to include build dependencies, that sounds like they were doing something silly like running `nix-build` from inside a Dockerfile and just taking that as their final image. Which.. yes, would include build cruft. Oh,[3] I guess that was exactly what they were doing after all. And mixing in Debian packages... for reasons, I guess.
[0]: https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTool...
[1]: https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...
[2]: https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...
[3]: https://github.com/railwayapp/nixpacks/blob/205b33b515282cdf...
Earlier quoted context omitted.
Nixpkgs isn't Nix and in production you rarely just use Nixpkgs verbatim. It's trivial to overlay whatever versions you want (including forks), and I'd say it's expected for any company in production to manage their package set. We are talking about a company full of professionals. If they need something obvious, simple, and default to manage their build - the core business function that turns their text into deploya…
> The industry is full of ineptitude though. While I disagree with the person you're replying to, I find your reply dismissive. I don't know the behind-the-scnene reasons for this, but I can very very easily apply a very similar situation to this from my experience. Nix is a full blown functional programming language along with a very rich (and poorly documented, niche, only second to C++ template in error comprehens…
Nix is a package management system with a little bit of programming tucked onto the side. "Nix stack" is not the same type of thing as "Go/Rust stack". If you try to move things over to Go/Rust, you'll spend a little bit of time rewriting the code and a whole lot of time reinventing the wheel on everything else involved. You're not moving between implementations, you're building your own implementation. That's almost always a bad idea, and it's a much higher cost than learning the syntax.
Moving from a Nix stack to a Go stack only makes slightly more sense than moving from a docker stack to a Go stack. Which is to say, very little sense.