brian_cunnie

I hope IP-based certificates will ease the pressure on nip.io/sslip.io.

I also hope I get fewer takedown requests. I currently get ~25 takedown requests every week (phishing, copyrighted material, illegal drug sales, unauthorized mirrors, command & control servers).

> Let's Encrypt applies per-domain name rate limits and these domain names see lots of issuance requests. There's a process to lift those limits.

I'm familiar with the process to lift those limits, and Let's Encrypt has been amenable to bumping the certs as high as 250,000 but balked at 500,000, saying, "This is too large for us to support"

(I run a DNS service nip.io / sslip.io, and lots of my users request certs, so I'm always bumping into the limits)

It was my service that the agent used: nip.io / sslip.io

OpenAI emailed me to let me know that their agent used my service to break out of test containment. OpenAI was quite polite (shout-out to Steven), and let me know they'd keep the name of my service out of the blog post.

nip.io is a simple DNS service: when queried with a hostname with an embedded IP address, returns that IP address, e.g. 127-0-0-1.nip.io → 127.0.0.1

The nip.io service is airtight with one exception: the "_acme-challenge" subdomain. In that case, rather than returning the IP address (or whatever record was queried), nip.io would return an empty "answer" section but an NS authority & not authoritative. In other words, nip.io would delegate DNS queries to that IP address.

That was the escape hatch.

In a couple of weeks I'll close that escape hatch. It was originally intended as a mechanism to allow savvy uses to procure wildcard certs (e.g. "*.64-176-22-9.nip.io") from certificate authorities such as Let's Encrypt. But experience proved that the it was an undue burden trying to support unsophisticated users attempting to procure a wildcard cert. "Wildcard certs are not supported" became my new mantra.

But I had neglected to remove the old code.

(the late Roopinder Singh created nip.io, and he was a good guy. I miss him)

> For me it's that writing code is really enjoyable, and delegating it ...

This.

On my fun side project, I don't accept pull requests because writing the code is the fun part.

Only once did someone get mad at me for not accepting their pull request.

My work has IPv6, and my home has IPv6.

If I need to connect to my home Fedora machine from work, a simple "ssh fed.nono.io" works just fine — I don't need to activate my Wireguard VPN; I don't need to worry about address space collisions.

Thumbs up on Concourse CI: I like seeing all my builds at once on any easy-to-read dashboard. That’s why we switched from GitHub actions: the dashboard.

> ascetic tech monks where we did this for the love of the work and not purely for status or money

And this is not limited to 2010s! My father worked as a software engineer in Poland in the 1960s, and the communist party had a problem: every profession had at least one member of the communist party except the programming profession. But the Polish programmers weren't interested in joining, not even with the perks of a bigger apartment or cars. Finally they got one programmer to join the communist party, but he wasn't interested in programming, and only became a programmer so he could join the communist party & get the perks.

> not a single person has ever said to me "I'm doing this for the love of it".

I'm doing this for the love of it.

Maybe "love" is too strong a word, but I certainly "like" what I'm doing, and I "like" computers, and I have a computer side project that I "like" doing and don't get paid for. Heck, when I was a summer student at IBM I couldn't believe they were paying me for something that was so fun!

Measuring oneself as an engineer by the title of the salary band you're in is a disservice.

I remember at Bell Labs they had one title: MTS (Member of Technical Staff). You were an engineer, and that was that. (disclaimer: there were a handful of DMTSes (Distinguished Member of Technical Staff)).

No one said, "I'm an E7" or "I'm a Staff Engineer II". Those statements strike me as distasteful. And begs the question if we're being suckered by Human Resource's gamification of work.

I worked at a company, Pivotal Labs, where everyone's title was "Pivot". It made for an egalitarian workplace. That changed after the acquisition, and we got titles. My proudest moment? Not when I was promoted from Senior Engineer to Staff Engineer, but rather the after-hours work I did with Dimtriy to expand our offering to include IPv6.

At my current startup, there are no titles, and I'm grateful for that.

Sometimes I log into the root account to see the billing information.

I created an "administrator" account, but apparently it can't see the billing information, including the very-important amount of remaining cloud credits.

Maybe I could spend time fiddling with IAM to get the right privileges, but I have more pressing tasks. And besides, on my personal AWS account I only log in with the root account.

> [IPv6] only exists in datacenters

My experience is different: Comcast has been doling out IPv6 addresses for at least a decade, at least in San Francisco.

My T-Mobile phone gets IPv6 addresses.

My work and my swim club also have IPv6. It's pretty awesome.

A year ago I changed my CONTRIBUTING document to say that I don't accept pull-requests on my very modest open source project (a special purpose DNS server)

I like coding, but am not fond of reviewing other people's code.

Also, the few PRs I received weren't up to snuff: for example, they included code changes but not tests. If they included tests, they weren't comprehensive. And they never included documentation changes.

> I have personally been bitten once (about 10 years ago) by btrfs just failing horribly on a single desktop drive.

Me, too. The drive was unrecoverable. I had to reinstall from scratch.

Agreed. It takes more than a few developers to support older operating systems.

At my old job we supported only two versions of our software product, Tanzu Operations Manager versions 2.10.x and 3.0.y), and we cut new patch releases every few weeks (similar to Apple's cadence). Bumping dependencies was a pain. Well, usually it went fine, but sometimes you'd hit a gnarly incompatibility and you'd either pin a Ruby package to a known version or try to modify the code just enough to make it work without making a major change.

If I had to put a number to it, I'd say it cost us 2 developers to keep our older product line consistently patched, and our product was a modest Ruby app, much less complicated than an entire OS.