ris

Implementing a very cut-down and basic sketch of the business rules of a particular observable effect can allow you to cover a lot of cases in a very compact and digestible form without falling into the traps that your actual business rules do. This is fairly fundamental to property-based testing.

If you use literal expected results for all of your test cases, you're probably either not covering enough cases or making your tests so verbose and long that they will start to diverge in weird ways.

Essentially no, but

- most Linux distributions don't reach very far into e.g. the python ecosystem (python packages that exist are generally there to support packaged applications)

- nixpkgs isn't linux specific - most packages work on macos, and nixpkgs happily works on top of other distributions.

Great and now the top thread on the HN discussion is about that drama only tangentially referenced in the article.

> It's as if everyone just says "dependency = ${exact_version_I_have}" and never considers anything else.

This is what I call "version soup".

The idea that every project can choose an near-arbitrary set of very exact version numbers of dependencies and expect it to work. And that every project on earth has the burden of continually stirring their soup, often through a tool like dependabot, hoping (cross fingers) no compatibility problems come about.

Of course, there's no guarantee that those versions will work together. The extremely limited abilities packaging tools have for expressing dependency restrictions (>= this or that version) generally lack the ability to even handle the concept of stable branches with backports. i.e. "No, it must be >= 1.2.3.. what do you mean they backported the relevant fix to 1.1.4? 1.1.4 < 1.2.3 so it's unacceptable". The way these specifications are then used by authors brings an extra layer of noise to the compatibility situation - very few (understandably) will actually go and check the limits of version compatibility.

In nixpkgs we attempt to address this situation for the python ecosystem by providing one version of each package (with few exceptions) per release. But in return, we put in work to make sure those versions actually work with each other - generally by getting the projects' test suites integrated into the build system. The idea is that an app built to depend on nixpkgs packages should be able to expect to do dependency upgrades as a "jump" every 6 months when there's a new nixpkgs release, but otherwise be able to depend on a stable suite of packages that still receives security updates & backports.

Works extremely well. Just don't expect to do version soup of random versions of everything. nixpkgs provides one of each that are chosen and known to work together.

Surprise! In-app plugin repos are a supply-chain disaster zone. I had to walk away from a project that wouldn't take the threat seriously lest I get caught up in the fallout when it all goes horribly wrong.

I wouldn't blame people if they sat this round out and waited for 2026's iteration of "Python Package Managers: we've really solved it this time!"

(still a happy Nix user)

I've previously used pagmo2 for this kind of thing with some amount of success. Might be worth giving this one a try as pagmo2's c++ patterns can be something of a mindfuck.

Read the paper which fully explains the subtle cleverness that sets it apart:

https://arxiv.org/abs/2011.13127

I thought they "really going to get it right this time" N-1 python packaging tools ago.

(happy Nix user)

1. The main reason I want to use otel is so I can have one sidecar for my observability, not three, each with subtly different quirks and expectations. (also the associated collection/aggregation infrastructure)

2. I honestly think the main reason otel appears so complex is the existing resources that attempt to explain the various concepts around it do a poor job and are very hand-wavey. You know the main thing that made otel "click" for me? Reading the protobuf specs. Literally nothing else explained succinctly the relationships between the different types of structure and what the possibilities with each were.

> You call blaze side janky and ad-hoc but to me (as complete outsider) using monorepo+build tool seems more principled and working more with fundamentals, while nix feels more ad-hoc and trying to fix stuff post-facto.

The Nix side is a maintained software distribution, which is a lot more than a bunch of random versions of tarballs pulled down from random urls, wrapped in minimal build scripts and forgotten about for years on end. It's also work that is shared across packages in the distribution and it produces consistent results that don't have dependency conflicts - if you have two bazel projects that each build against their own cpython, I can guarantee that they will have chosen different versions of cpython. Which one wins when they're used together? Who knows...

Every project building-out their own separate pseudo-linux-distribution cannot produce good results.

> The whole starting point for bazel is having full control (via monorepo) of the dependency stack

I'm not aware of a bazel project that builds its own glibc (I imagine there are some which people could point out...). But then.. do they ship that glibc with the end result? Or just shrug and hope it works fine on whatever glibc the target system happens to have?

So.. it's sort of a battle over territory between build system and package manager.

Bazel is there becoming ever more complex and unwieldy in an attempt to provide supposed reproducibility - taking control of the provision of ever more of a project's dependencies (in often very janky ways). But to Nix people it's clear that what people are actually doing here is slowly building a linux/software distribution around their project, but in a very ad-hoc and unmaintainable way. And bazel projects will continue to grow in that direction because until you have control of the whole dependency stack (down to the kernel), you're going to struggle to get robust reproducibility.

I don't think many Nix people would suggest actually using Nix as the build system, but probably to use a comparatively simple cmake/meson/whatever build-system and use Nix to provide dependencies for it in a reproducible and manageable way.

I love this case, because every time someone cites it as a reason packagers shouldn't patch upstream software I get to point out that they had to go back over a decade to find an example of it going bad. Soon it's going to be two decades.

Unfortunately make's behaviour around dynamically setting variables/environment variables is insane and quickly leads you towards hairy eval commands with extremely tricky quoting & escaping.

Weren't Marcus Aurelius' writings only ever written as personal notes and never intended for publication?

HCL is the most ramshackle, poorly thought out "languages" I've encountered. The only thing it has going for it is it attempts to implement a declarative/functional model instead of the lunacy of pulumi encouraging people to have a go with (various) imperative languages.

If you need convincing of the ill-considered nature of HCL, go look at the discussion around adding deep map merge support to terraform and the suggestions to use a third-party provider for this.

> Meanwhile, when I use CUDA instead of Vulkan, I get serenity back. CUDA FTW!

Just because the complexity is hidden from you doesn't mean it's not there. You have no idea what is statically bundled into the CUDA libs.

Except the debug environment isn't _quite_ like the production environment, is it? Now you've got it working on the debug environment but weirdly broken on prod still..

> Production servers should be hardened immutable appliance kernels with read only root filesystems that verify and run signed containers, or run a tiny shim init system in a couple hundred lines that spawns a single application specific binary you trust.

And then you need to debug something. What do?

Ultimately the true bellwether of compatibility is the package's own test suite, which we try to get working (and integrated into the build process) for as many packages as possible. For packages which have poor/non-existent test suites, often a downstream package's test suite will expose compatibility problems (we've found bugs in zlib security patches using curl's test suite for instance).

nixpkgs maintainers are frequently the first to notify a project author of incompatibility with new versions of another package.

I read this blog for years but more recently got tired of its gimmicky contrarianism.

I've lost count of the number of "alternative" energy solutions it has breathlessly presented which, to anyone with a calculator and a basic understanding of physics, can't possibly make sense. e.g. the sister no-tech magazine still has an article up on the GravityLight https://www.notechmagazine.com/2013/01/how-to-design-more-po...

That's not to say it's not occasionally informative about obscure technologies of the past.

Really appealing idea until you look at the language. An imperative language for something whose principal job is to declare some kind of configuration. I strongly encourage anyone who's considering designing a "custom language" for something to get in touch with someone who really understands programming language design, otherwise you frequently end up with abominations like HCL.

> Framing Nix as a solution to complexity seems to be a tenuous claim.

Disagree strongly. Building a large and varied set of software packages in a generalised and reproducible way is a fundamentally complex endeavour, and nixpkgs is the most successful effort I've encountered to simplify it.

In contrast, build & packaging systems that try to present apparent "simplicity" are usually ignoring a lot of the subtle difficulties in building software in a reproducible and robust manner, leading to extended and vague debugging sessions. See for instance almost any non-trivial Dockerfile-based build procedure.

There's also https://matrix.to/#/#review-requests:nixos.org

This x100.

If you take a function and tell someone it's "too complex" and tell them to "fix it", that person will usually end up splitting it into, say, three functions. And now, you've just multiplied that complexity by all the different possible permutations of how/where the different functions can call each other. Corner cases that you could previously rule out because the control flow made them impossible are now fair game.

I'll bet that wasn't across AWS accounts though.

They do, but those recommendations are buried quite deep in the documentation, well behind all the marketing guff that suggests that DMS is all things to all people, and wonderful magic that is ideal for all situations.

> This isn't a startup hacking away trying to find PMF, or dealing with unpredictable marketing-driven traffic spikes. We know we need these services running long term, and can make solid predictions about usage patterns.

If you think government needs and demands are predictable, you don't follow politics (particularly uk politics in the last decade).

And then there are these things like pandemics that completely come out of left field. Being able to scale things on demand over the pandemic was one of the key demonstrators for use of the public commercial cloud by the public sector.

FWIW GOV.UK Notify is part of a suite of services offered by GDS to UK public sector bodies (along with GOV.UK Pay and GOV.UK PaaS) that was originally known as "Government As A Platform".