kalmar

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

The care taken here to achieve aesthetically pleasing results reminds me of this post about creating nice transit maps in the Transit App: https://blog.transitapp.com/how-we-built-the-worlds-pretties...

I don't know of it's the reason, but inet_aton[0] and other parsing libraries that match its behaviour will parse 1.1 as 1.0.0.1. I use `ping 1.1` as a quick connectivity test.

[0] https://man7.org/linux/man-pages/man3/inet_aton.3.html#DESCR...

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.

Honest question: how do people use influxdb for monitoring and alerting? Our metrics feed into influx, and I cannot get answers to simple questions like “what is the failure rate” because arithmetic across measurements isn't possible [0]. I could shoehorn things into a schema to make it work, but in the limit I end up with one mega measurement.

[0] https://github.com/influxdata/influxdb/issues/3552

Some links I found: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... https://mailarchive.ietf.org/arch/msg/unbearable/QoybOl0cciD... https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

What are some more trusted alternatives to JWT for signed tokens with claims / expiry?

Will all links mentioning woman driving have to be removed worldwide because some middle eastern country tells them to?

Among "some middle eastern countries" that exist, only Saudi Arabia has that law, and they do not censor images of women driving.

Here's an issue: https://github.com/hashicorp/terraform/issues/15263

Oh interesting. Note to self: see if there's an option to disable `terraform apply` without a plan.

I always refresh when running the pre-apply plan, but while iterating I use that. Do you always run your `tffreshplan` command before applying?

I don't think it would work in this case, as the `ebs_block_device` block isn't a resource. In fact, the TF state doesn't even have the volume IDs for them!

An alternative to doing this was `terraform import` on all the volumes, then defining attachments, and hoping it all worked when you run `terraform plan`. I don't 100% remember now why we didn't do that.

That's pretty cool. So is the model that you don't manage the volumes in TF at all?

(Btw I think I know people you know... also in Montreal and I know a couple folks at AdGear!)

Woah can you comment on lines in a comment? /me dashes to investigate github

And thanks for the suggestion. So far it's been on a someday maybe list, but if it really does help that much, maybe we'll bump it to someday maybe soon.

Hey author here! Happy to answer any questions etc :-)

This is a better link, as it will include the discussion: https://github.com/rust-lang/rfcs/pull/1774

(OP here) I think that would be a useful thing to do in some situations, but it often won't get what you'd like. There's no guarantee that a view will ever call it's superclass' implementation, so inserting code has to be done a the leaf view classes not further up.

She wrote about it not long ago: http://jvns.ca/blog/2016/08/29/how-i-made-a-zine/

Short answer: she did the first zine on paper, and the second one on a tablet.

Now I want to learn about stack probes!

Ah so the idea is that there's already 8 KB of actual pages set for stack by this point. So when I try to get another (8 MB - 8 KB + 1 B), that blows things up? I wonder if I can watch this happen in /proc/$pid/maps or somewhere else around there.

Oh this is cool! I should have checked more pointers. On my machine, the single pointer was always null, and I read up on stack being initialized to zero. I didn't realize the things-before-main could mess up the stack so much.

In my view, for a language that bills itself as safe, there should not exist such things as undefined behaviors. As far as I am concerned, then, based on the advertising of Rust, this is false advertising.

The key thing from the reference [0]:

"Type checking provides the guarantee that these issues are never caused by safe code."

It's subtle, but I think the situation is that "some segfaults are caused by undefined behaviour, and some undefined behaviour causes segfaults". Neither fully contains the other. One thing I was trying to get across is that a segmentation fault has a very specific meaning, and that meaning is not "bad thing was done with pointers".

[0] http://doc.rust-lang.org/reference.html#behavior-considered-...

I should have made that clearer, thanks! If there were intervening function calls there would be garbage. Then it would only "most likely" segfault instead of always segfault.