tomberek
Joined 13 years ago
Karma
340
Submissions
143
Member since
Oct 21
[ my public key: https://keybase.io/tomberek; my proof: https://keybase.io/tomberek/sigs/9p1R93wG3L4zZV8AEfIzPqzwtX34Im0PT09B8ykMkJI ]
View on Hacker NewsRecent submissions
Comment · 1 month ago
The ability to quickly try out and verify ideas is valuable. This would have taken immensely more time to get to a stage to reasonable verify or dismiss as an idea otherwise. This saves time for builders.
The author cares; this is not a post-a-quick-project-as-slop-to-get-cred situation.
Comment · 2 months ago
The Nixpkgs Core team was established in Sept 2025 (https://discourse.nixos.org/t/establishing-the-nixpkgs-core-...), so it is a fairly new concept and idea. They've accomplished some good things as highlighted in the post, but are now stepping down. Yes, we'd prefer for the team to exist, but we've also functioned without one for ~20 years. It may take multiple iterations to bootstrap the concept and to figure out the right structure - or we may find it isn't needed. So no, this is not a critical emergency. It's a return to the status quo of late last year.
That being said, I think it is still a concept worth pursuing.
Comment · 4 months ago
Perhaps give boats some advantage in capacity.
Comment · 1 year ago
Presumably this would support a big improvement to both SBOM generation as well as various UX features and workflow improvements.
Comment · 1 year ago
Trading perfect reproducibility for usability: a pragmatic look at Flox's new features
Comment · 1 year ago
This is exactly how I can rapidly prototype things. Once proficient with this tooling is becomes very easy to quickly spin up services and PoCs. Managing it and iterating is also a breeze.
Comment · 1 year ago
Random thought. Another commenter worried about the runtime of the program becoming mangled and performing destructive operations on your machine. What if you run the reducer as a source-to-source Nix derivation? Protects against dangerous things, and can be easily distributed to remote builders.
Comment · 2 years ago
Agreed. Packaging is different than deployment. Devs should return to the art of packaging, such that their software can be then deployed into containers, VMs, micro VMs, whatever. That is what packaging allows, re-use.
This is the sort of behavior Nix encourages (disclaimer: I work at https://flox.dev , using Nix as our baseline tech). Docker as both a packaging and deployment format can carry a bit of weight, but can quickly get out of hand.
Comment · 2 years ago
This is excellent. Have you considered making a presentation or a write-up of the experience?
Comment · 2 years ago
A similar article for bringing Ruby into the Nix ecosystem: https://flox.dev/blog/flox-and-ruby