nocarrier

I loved how the Windows 95 install CD had Weezer's Buddy Holly video on it. I remember finding it and thinking it was so cool they did that.

That article on rapid Rust prototyping matches my experience with using Rust as the backend for a web and iOS app. I used clone() and Vec and String and other shortcuts from that article as much as possible since I was building a backend application versus an operating system. It enabled a lot more velocity and made it fun to add features. And it was still blazing fast.

If anyone is considering using Rust and is nervous about lifetimes and bare metal, check out that article and try its guidance. I learned these things on my own the hard way and would have loved to read this article 18 months ago. It's really quite good.

“During the period 2018-20, Space Norway carried out significant security related upgrades to the fibre connection.”

Sounds like someone was tapping cables with submarines?

Once Colin's patches land on FreeBSD and Firecracker, the total boot time for the kernel is under 20ms. Absolutely incredible times that we live in.

It was actually Rainbow's End by Vernor Vinge that really got Zuck excited about the possibilities of VR—he read it a few years before he bought Oculus and talked about it a lot at the time.

I was at FB from 2006-2015, and Scuba caused a phase change in how Facebook's performance was analyzed and how quickly insights were gained. For many of us in Infrastructure, we spoke of the pre-Scuba, post-Scuba eras. It was such a joy to have aggregated realtime performance metrics for our internet scale services and have the ability to drill down on just about any dimension when doing perf investigations. It gave us so much more confidence in our systems, both in our ability to detect issues, as well as pinpoint what was causing them.

I'd also like to echo what spicyj said about the UI, it is very usable. It was common for managers, PMs, and even people in completely non-technical business roles to use Scuba. It was my favorite internal product at FB and the one I miss the most.

Cartographer ingests BGP topology and POP and datacenter health (and other things), and then pushes what is basicially a lookup table to tinydns. None of the dynamism is inside the DNS server itself, which lets it focus on what it is good at--responding to a crap ton of DNS requests per second.

Cost was a smaller factor than politics; the Indian government wanted the private keys for our certs in order to let FB put a POP there. That was an absolute dealbreaker, so we served India from Singapore and other POPs in nearby countries.

Regarding building a datacenter, that's much higher risk since it's a $100M-1B capital investment. I'm guessing both Facebook and Google see too much volatility to make the risk worth it. It could be an expensive paperweight if the Indian government changed their minds.

I joined FB in 2006 and had never been in an open office environment before. It was quite an adjustment. I didn't like working in the office until I had been there for about six months. The office on University Ave was packed tight and didn't have a lot of creature comforts--it was cheap desks arranged in groups of four, some conference rooms, a break room with snacks, and that's it. And I had come from a cubicle farm at Apple.

There were definitely large benefits to the open floor plan back then since we were working on so many things and each person was wearing so many hats. It made staying in touch with people's progress really easy. We were also working 80-100 hours a week back then, so it was good to constantly stay in touch since there was so little structure and process back then.

I have mixed feelings about FB being held up as one of the models for open floor plans today though. While I think it was definitely useful at the time, I think the open floor plan has become less important as tools have gotten better. We didn't have tools like FB Groups, Phabricator, etc, so you had to be within earshot of your collaborators in order to make sure everyone was in sync.

My sweet spot would be team sized rooms if I was starting a company today. I used to be so jealous of teams that had to grab war rooms and ensconce themselves in there with a bunch of laptops and displays. Even though they were working super hard to meet deadlines, they looked happy as can be.

Indeed, but there is something to be said for sane defaults--look at the thread on HN a few weeks ago about SSH cipher defaults. Yes, TLS and the CA ecosystem has its faults, but my stance is that any chat protocol should be using auth and encryption, especially group chat protocols like IRC. I'm less upset now after seeing that the proposed spec for IRC 3.3 includes something similar to HSTS.

I read IRC v3 and assumed they were making major changes to the wire by bumping the major version, which is why I said what I said. I've been using IRC for 24 years but haven't implemented it before, maybe I'll do that now so I can have a better idea of what I'm talking about.

Hmm, I didn't see the 3.3 spec which is still being developed, it looks like they are doing strict transport security as a base extension. So that would address most of my concerns I think. I would still prefer to see TLS required no matter what.

Fair enough, but I feel you're being a little pedantic since there are base extensions described which are required, and optional extensions which are not required. TLS is one of the optional extensions.

So I'll reframe my question and ask: Why isn't TLS a base extension?