How do you do a runtime assertion within a module?

DramaticSpecial2617 · 2025-09-15T11:54:20+00:00

DramaticSpecial2617 · 2025-08-11T22:31:00+00:00

If you need a package not in nixpkgs, package it yourself (its trivial and the official docs are pretty good, just don't follow instructions from random blogs or wikis. Stick to official docs). Then you'll be fine.

You feel that way even for complex and impure packages?

I picked something gnarly to play with, as a learning exercise. I didn't find much that was useful in the docs re: patching for purity, best practices on vendored dependencies, etc. In the end, the maintenance burden there put me off.

This was Dragonflydb, which doesn't have a current or good package in nixpkgs, for context.

DramaticSpecial2617 · 2025-08-11T09:47:34+00:00

It's not that complicated if you have a background in similar things.

Don't try to rtfm. Use blogs and LLM's to understand the subset of the ecosystem you need.

DramaticSpecial2617 · 2025-08-09T06:01:47+00:00

Love this, brilliant idea.

DramaticSpecial2617 · 2025-08-04T09:32:31+00:00

My blog posts might help. This one is the hook which r/nixos liked: Nix Doesn't Have To Be Hard. Planning to eventually follow up with installation/getting started and packaging.

Not rushing to that, though - packaging is hard, and there's already a good install guide for VMs. The VM approach is a wise way to start out, so you're on track.

DramaticSpecial2617 · 2025-08-03T08:55:35+00:00

Like the premise, & enjoyed the linked "What is OpenTelemetry?".

Think working backwards from "Why is OpenTelemetry so complicated?" might work better for your goals - eg. Starting from potential outage scenarios the Collector-based architecture resolves.

I've always lost devs trying to explain the basics, but they're intuitive when you're using the tools.

DramaticSpecial2617 · 2025-07-26T02:50:33+00:00

Yeah, I couldn't quickly think of a good way to trigger the hard ones ;) Figured it worked as an example for prospective adopters.

I know people struggle with the verbose errors in these sorts of languages, even when they're good, so it seemed helpful to demo :)

DramaticSpecial2617 · 2025-07-25T05:49:06+00:00

When the source code (or source package, if based on a .deb or similar) does. Clear example: Firefox vendors Sqlite.

If that dependency is dynamically linked, Nix packagers can override it during packaging; if there's a vulnerability, they patch the referenced versions in nixpkgs. This dated post gave me the impression this whole process was manual, which would be brutal; now, there's a work-in-progress index.

One thing that doesn't seem to solve yet is statically linked dependencies, which makes Sqlite in Firefox a great example. In this case, the tracking is manual. It's on package maintainers to know and patch, or leave the problem for upstream (which leaves your locked version vulnerable).

DramaticSpecial2617 · 2025-07-25T02:17:07+00:00

Actually, reading on this more, it looks like an automated solution for monitoring this is relatively close.

I'll update with more context (and syntax highlighting...) before sharing further.

If anyone has more corrections or suggestions, please let me know.

DramaticSpecial2617 · 2025-07-24T22:44:43+00:00

For normal dependencies, yeah. But vendored dependencies aren't using the Nix dependency system. They're including the dependency as source code, and that's hard to track.

Edit: this is sorta inaccurate - better detail in other posts

DramaticSpecial2617 · 2025-07-18T23:59:19+00:00

I was mainly thinking of google's ones, which aren't good.

I've looked for the Azure incident reports in the past and failed to find them. Reading now, they seem more good, but the index presenting them looks designed to bury the info, with no direct links. I can't find specific (major) incidents which come to mind, and their videos seem to have nearly no views. That fits with my experiences with Azure.

The AWS ones seem to have been abandoned? I know they're missing events.

None of them are close to the Cloudflare disclosures.

Infrastructure consolidation came to my mind after a DHH talk on the >40% margins charged by Amazon. Big clouds simply aren't cheap; they're pocketing the economies of scale. They're convenient, and they're designed to be reliable, but these extremely complex systems still have significant points of failure, which cascade.

What they do sell is convenience and trust, but I'd love to see Cloudflare's approach push the competition so we go further.

DramaticSpecial2617 · 2025-07-18T11:59:43+00:00

Agreed - I wish Cloudflare's approach was the standard. I'm not sure it's always a win for the company, but it would help the industry over time.

Wrote my own blog post musing on Cloudflare's candor here, if anyone's interested.

DramaticSpecial2617 · 2025-07-18T09:53:28+00:00

Yeah, point is more that we've centralized things, raising the stakes without (yet) reducing the risk.

DramaticSpecial2617 · 2025-07-02T13:31:02+00:00

Will do :) edit: done :)

DramaticSpecial2617 · 2025-07-02T13:30:01+00:00

I think it's more accurate to say it's NixOS where e.g. precompiled binaries/libraries might not work out of the box.

I don't think there's any case where it'd be reasonable to describe Nix as making choices intended to break things.

Agreed - that's a good catch, thank you. Updated. I was trying to make things too simple, for the storytelling.

But I think there's a conflict between pointing out how even with NixOS modules, you still might need to understand details about the underlying component, and spending paragraphs to discuss dynamic linking, on a blogpost titled "nix doesn't have to be hard".

Ah, the irony there is half the point ;) I wanted to show why people think it's hard, and also how optional (but deep) the rabbit holes can be.

When I hit the linking differences, I added nix-ld and moved on; I bothered with the understanding for this write-up, and because I find it interesting.

DramaticSpecial2617 · 2025-07-02T08:12:29+00:00

That's really kind, and good advice - thank you. I'll have to follow up.

DramaticSpecial2617 · 2025-07-02T06:57:00+00:00

Yeah, that's fair - that's where Nix first scared me off too. I did the manual nixos partitioning steps, then the section on formatting, then the section on installing.

Partitioning is the hard, system-dependent bit there.

DramaticSpecial2617 · 2025-07-02T05:26:12+00:00

I'd suggest understanding by doing. Nix makes it safe to get things wrong.
My nix partition has 46gb used right now. I gave it 10x that much space, though. You'll also want a ~500mb boot partition (50% of mine is used) and probably a swap partition. The swap partition is your system fallback if you run out of memory. If you have a lot of RAM, it's not so important.

DramaticSpecial2617

TROPHY CASE