jamesog

I'm curious if Solod https://github.com/solod-dev/solod would be a good fit. It's not "real" Go, but you write Go and generate C.

I was the original author of the cloudflare-go library (which I worked on in my spare time while working at Cloudflare), and I included a `flarectl` command with it, but sadly it didn't get much traction :-(

https://github.com/cloudflare/cloudflare-go/tree/v0/cmd/flar...

The bad change wasn't even a deployment as such, just an entry in the global KV store https://blog.cloudflare.com/introducing-quicksilver-configur...

Actual deployments take hours to propagate worldwide.

(Disclosure: former Cloudflare SRE)

Disclosure: Former Cloudflare SRE.

The short answer is "yes" due to the way the configuration management works. Other infrastructure changes or service upgrades might get undone, but it's possible. Or otherwise revert the commit that introduced the package bump with the new code and force that to rollout everywhere rather than waiting for progressive rollout.

There shouldn't be much chance of bringing the system to a novel state because configuration management will largely put things into the correct state. (Where that doesn't work is if CM previously created files, it won't delete them unless explicitly told to do so.)

> I collaborated a lot with a collage - James (Jog). I asked him loads of questions, from "how to login to a server", via "what is anycast" to "tell me how you mitigated this one, give me precise instructions you've run".

Hi, that's me! There were definitely a lot of fun conversations.

I liked that a culture of internal blogs became a thing too. It was good to see people brain dumping their experiments and findings. I think people learnt a lot from following all the internal blogs.

Children of Time needs to come with a huge content warning for those with arachnophobia. I got through it, but I didn't enjoy it, for that reason.

That's not from robots.txt, but their Bot Management feature which blocks things calling themselves Googlebot that don't come from known Google IPs.

"Aesthetic" gets even stickier! In the UK I tend to more commonly hear it pronounced as "es-thetic".

The Great Vowel Shift indeed makes written English much more confusing than it perhaps should be. English is already a messy hodge-podge of a language, then our writing system started to get standardised (or standardized, if you're American!) right as pronunciation started to change, leading to the written version of words suddenly no longer being anything like the pronunciation.

US English spells it as encyclopedia, British English spells it as encyclopaedia.

It should more properly be written as dæmon. The æ ("ash") character is usually pronounced more like "ee", as in encyclopædia. I've never heard anyone say "encycloPAYdia" :-)

The Isle of Man isn't part of the UK, but rather a Crown Dependency, as are Jersey (.je) and Guernsey (.gg): https://en.wikipedia.org/wiki/Crown_Dependencies

I'll add stern (https://github.com/stern/stern) to that - follow logs from multiple pods easily.

Since the introduction of APFS I've taken to creating a new APFS volume formatted as case-sensitive, and put my git repositories there.

This has mostly been useful for working on shared repositories where, say, a Linux user (or other user on a case-sensitive filesystem) pushes two branches, say `feature/foo` and `feature/Foo` which works fine for them, but on a case-insensitive filesystem, git gets very upset.

Managed Kubernetes exists because Kubernetes is so mind-bendingly complex.

Nomad, on the other hand, is pretty simple and easy to run, and a single binary. There's probably no benefit to having a managed offering.

That said, I wouldn't be surprised if HashiCorp add Nomad to HashiCorp Cloud Platform, which currently lets you deploy Consul and Vault to cloud providers via their system.

Salt states can very quickly/easily become unweildy as, unlike Ansibble, you can throw Jinja2 everywhere. It becomes far more tempting to create multiple states with a Jinja2 loop, or worse, macros, and before you know it you have a huge mess of what I like to call "spaghetti Jinja".

Templated YAML really isn't pretty to work with.

There was a proposal, which was declined: https://github.com/openssl/openssl/pull/8367

Proving my point that there's no _good_ UI for managing profiles with Firefox. And no, about:profiles doesn't count. Chrome makes it nice and easy and obvious.

I like the idea of multi-account containers, but I'm very used to Chrome's way of having separate profiles.

With MAC you get tabs for different containers mixed up in the same window and the URL history is shared.

I prefer the profiles approach where everything - extensions, history, etc. - is all nicely segregated.

Firefox does have profiles, but there's still no good UI for managing them.

On a somewhat related note, I'm curious what people think of having a remote manager? Either they're in another office/timezone, or you work remotely.

I work in an office, and prefer doing so as I like being around my colleagues. I find it easier to collaborate and, despite being an introvert, like being around other humans. I've had times when my manager has been on another continent and it's been the most frustrating thing for me as they're not just there, on the other side of the desk, when I need them.

What does a security team have to do with network routing?

This is why you should use their DNS-over-TLS or DNS-over-HTTPS service instead of standard DNS.

Route hijacks can happen to anyone, even Cloudflare or Google. If anything they're more likely to be targetted than a smaller player like Nextdns.

They have: nextdns.io

There was discussion a few days ago: https://news.ycombinator.com/item?id=20012687

By default mtr will do reverse DNS lookups on all hops. Several of the traces I ran showed the route to nextdns's /24 transiting over NTT and from the DNS name you can figure out where each router is.

There seems to be some routing oddities going on. I'm also in the UK (on AAISP). Sometimes I get ~48ms response, other times 200-300ms.

Looking at mtr I'm occasionally routed to Dallas, Texas. Other times it's correctly routing over my ISP's peering to Vultr.

It's not great as a DNS server. It has some really odd behaviour. One of the things which used to annoy me a lot when using it as a recursor is things like `dig +trace` would just stop at dnsmasq, so you'd have to bypass it by doing something like `dig +trace @8.8.8.8`.

Every DNS expert I know says to avoid dnsmasq.

It works fine as a DHCP server, though.

According to my nextdns analytics from the last few weeks my house has peaked at around 28,000 queries a day, 331k so far this month.

Nextdns is blocking somewhere in the region of 400-600 queries each day, mostly things like Google Analytics, Apple iAd.

I've been using nextdns since I saw it posted on Twitter a few weeks ago. It's been great.

I used to run something like PiHole on my home network but ultimately dnsmasq is not a good DNS server so I ditched it. I've been running CoreDNS for a while, forwarding to Google DNS and Cloudflare DNS (both using DNS over TLS) for a while and that worked fine. I'd augmented CoreDNS to serve a hosts file as a blocklist, similar to PiHole.

Nextdns has replaced Google and Cloudflare as forwarders in CoreDNS and it's working really well. I've been liking the proper network-level ad-blocking and being able to use the analytics to figure out what was blocked when something doesn't work.

The nextdns guys are also really responsive and helpful. One of them spent a couple of hours on live-chat with me debugging an analytics issue.

Cloudflare's replacement for KT that jgrahamc mentioned - Quicksilver - uses LMDB for storage.

I don't have numbers, but it performs great for our needs. It's heavier on the disk though because of fsync, however unlike KT we never get database corruption on disk.

And to add to point (4): as Marek says KT's replication is great... to a point. When Cloudflare was small and we only had to replicate to a relatively small number of machines it coped fine.

As we scaled out each data centre we quickly hit limitations in KT's ability to replicate to many clients. We ended up having to install many more replication points in each data centre or region just to allow KT to replicate to all downstream clients, otherwise it would regularly stall while trying to service all replication requests, massively slowing down replication, or sometimes even missing updates.

There's also two more points to be made:

(6) As our KC (Kyoto Cabinet) databases grew, KT had trouble keeping consistency of the file on disk. Sometimes a restart of the service would leave you with a corrupted KC database, causing us to have to resync the node from scratch. This was a huge operational burden - especially if corruption somehow replicated downstream.

(7) KT allows you to write to replicas. This one we always found crazy. You can write (or overwrite) a key on a downstream replica and that only ever stays on the replica - it can't propagate upwards (and nor should it). Until the top-level writes to that key again it will remain with this erroneous value. This made monitoring problematic because it would cause a keycount or replication diff if it ever happened.

https://cloudflare-dns.com/ works, however it redirects to https://1.1.1.1/