> To ensure monotonicity, retrieval of the idempotency key and emitting a message with that key must happen atomically, uninterrupted by other worker threads. Otherwise, you may end up in a situation where thread A fetches sequence value 100, thread B fetches sequence value 101, B emits a message with idempotency key 101, and then A emits a message with idempotency key 100\. A consumer would then, incorrectly, discard A’s message as a duplicate.

Also check out Lamport vector clocks. It solves this problem if your producers are a small fixed number.

I think it's because the docs say "If there isn't enough memory, you can't run a JOIN." . While SQL on Hadoop solutions work also without enough RAM by spilling on disk. I don't think a comparison with JOINs would be fair in this case.

You are right. It's unfair, I'm going to modify the post to mention alpine.

The post is both about tiny images AND how to build docker images with nix. I think it was an interesting tooling to make for our community. Some Nix people are already using it for obvious reasons.

I commented on the original post, but actually I believe the strength of the Nix-based approach is to provide package management capabilities outside of the target image. In other words, it makes the "scratch" image actually usable.

So now, if you take an Alpine-like approach to the problem (musl, no extra stuff) in Nix, you can get much smaller images. And the reason is you don't have to pay for the limitations of the Dockerfile-based approach.

As a proof of concept, here's an extension of the Nix recipe to produce a 1.2MB redis image: https://gist.github.com/sigma/9887c299da60955734f0fff6e2faee...

Now, the numbers start getting a little bit meaningless (although that's still an order of magnitude...), but the point is that regardless of how great Alpine is (and it is definitely great), as a base image for a Dockerfile it'll always contain way too much stuff compared to what's really needed for the application itself.

The blog post code is supposed to run with latest master since a few days. We've merged a big change that leads to reducing a lot the closure of our packages.

Nix moves fast enough, in the sense we usually do a good job at not breaking things. Yet we have to necessarily introduce innovations in our frameworks.

You don't need in fact. But sometimes you are forced to use Docker anyway.

Always liked and used LyX, and never looked back. LaTeX is not for humans in my opinion, nobody should ever write LaTeX by hand.

I was introduced to latex by a German student in my telecoms lab. Armed with a handful of examples I wrote all my papers from then on in Tex. The thing that really struck me, I concentrated on the content not the formatting. Word etc require so much fiddling to get it looking right, it takes energy away from actually writing your paper!

How Nix solved the issue:

1. Each go package has an attribute name in nix, like anything else, that is not tied to its url.

2. Each go package has an url where to fetch the source from, which is not the import path to use the package.

3. Each go package has a number of old import url aliases (e.g. "code.google.com/...")

4. Whenever a package X depends on Y with an old import url, then X is rewritten to use the new url path of Y using govers.

So the problem is solved at our packaging level.

This is not to say it's the best solution, but certainly a good alternative solution.

Sorry, where is it said they will stop development of Persona? The homepage and the service seem to be in full health, there's no warning anywhere for users of Persona.

Is there any official statement that Persona will shut down?

I've looked at knex. But I felt it not to be as composable as sqlata.

In knex operators are written with .where() itself. Also it doesn't manage table aliases apparently. And it's quite tied to an underlying connection as I can see.

But yes, all the sql bulders out there are quite similar, but there are notable differences compared to sqlata if you look deeper.

Things you must be afraid when using nix:

1) If you install a bad grub, you cannot rollback it using nix. That means, not a wrong grub line, but if grub itself is broken.

2) Anything that is not under nix control, the data: like desktop configurations, databases, ecc.

But after the first successful install you shouldn't have to worry about GRUB anymore. I don't know what it's like on NixOS, but on GuixSD we just change the grub.cfg.

You also upgrade grub versions I hope :) Or maybe improve the grub installation scripts.