kalmar

Separately from guix-the-distribution? Any chance your config in online somewhere?

This used to be me until I started using screenshot shortcuts that put images in the clipboard instead of files. You can paste directly into jira, slack, hangouts, whatsapp web, and many other places.

Author here. Those are great tips, thanks! I actually just installed evolve from pip last night. I'll probably borrow from your hgrc, or at least let it inspire me :-)

> I'm in the opposite boat where I've used mercurial for nearly 10 years but any time I try to use git I get lost.

Very interesting! Do you end up using it as a client to git repos?

And you get 4 extra cores and 24 gigs of ram "for free" vs i3.16xl (which is what we use). I think we looked into switching but it wasn't clear if the reservations could be switched over.

Yup, that's the blog post I mentioned in the intro. Sometimes obsessively reading HN pays off. Even if it's a year later... :-)

Back when we ran the Citus cluster on EBS, we lost some EBS volumes as well. This manifested as disk not responding, followed several days later by an email from AWS with the subject Your Amazon EBS Volume vol-123456789abcdef telling you the disk was lost irrecoverably.

But yeah, you need to be ready for your disks to go away no matter where they are: ephemeral, EBS, physical, whatever.

Post author here. It's ephemeral, yes. It survives reboots, so that's not a problem. It doesn't survive instance-stop, so if a machine is being decommissioned by AWS we do indeed lose its data. As for how we protect against it, the main thing is replication: the data is stored on more than one machine. If we lose a machine for whatever reason, the shards from that machine are copied from a replica to another DB instance.

Hi post author here! First off, we actually do use RDS for other databases. As you point out, having a lot of the operational stuff taken care of for you is great.

The post is specifically about our Citus cluster, which stores the analytics data for all our customers. Most of the reasons we do this have been given by other folks in the replies:

  * RDS doesn't support the Citus extension
  * data is stored on ZFS for filesystem compression
  * we get significantly higher disk performance from these
    instances' NVMe attached storage, which isn't available for
    RDS

Post author here, happy to answer any questions. Looking into this one was fun, especially actually looking at the vDSO source instead of just thinking of it as "the makes gettimeofday syscall fast thing".

I'm curious why chroot is used instead of mount namespace and pivot_root(2). This would let them get away without CAP_SYS_CHROOT, while also providing stronger filesystem isolation.