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.
How does this compare to Linux on Firecracker? I can find some numbers with a basic internet search, but I'm not sure if these numbers are comparable for various reasons (they're a few years old, it's unclear if they use the same method to measure boot times, or even have the same definition of "boot time").
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 suppose we should just be thankful he didn't pick up Vinge's "Deepness in the Sky" instead; it would be quite disconcerting if Facebook was trying to develop talking spiders.
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.
> "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"
In a previous job we used to find conference rooms that weren't bookable in the system and move into there until someone kicked us out. You can get a ton of work done in a small meeting room with 4-5 devs, when absolutely no one is bothering you.
Collaboration has definitely got a lot better than it was years ago; FB has probably managed it better than anywhere I've worked before. The amount of money and effort they've invested into video conferencing facilities is huge because it really is such an important factor. This is why it always baffled me that they didn't treat remote working as a first class citizen, especially given the crazy prices of real estate in the Bay Area.
I was also always hugely jealous of people in war rooms as they seemed to have the perfect balance.
Why isn't encryption baked in by default? It's optional from what I can tell. I don't know how you can design a new protocol and not include encryption.
> The IRCv3 Working Group is a collection of IRC client and server software authors working to enhance, maintain and standardize the IRC protocol using backwards-compatible extensions.
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?
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.
The 'tls' extension is not actually TLS support. It is a method of upgrading plaintext connections to TLS via the STARTTLS command. It has some design problems and is going to be replaced with something that works similar to HTTP Strict Transport Security in the upcoming IRCv3.3 release which will be a base standard.
We strongly believe that the future of IRC is TLS-only.
There have been lots and lots and lots of discussions about that, but considering it’s just an extension to the existing IRC protocol, it’s not that easy.
But it’s easily possible to enforce SSL over IRC already.
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.
I agree. Even if it's as simple as having a way to exchange public keys baked into the protocol and allowing cyphertext in messages. Even better would be if certain channels could have their own encryption key (exchanged securely between people allowed to join the channel, and changed if someone leaves/joins).
This is like the email situation where encryption options exist, but it's too hard for mere mortals to use. If it's built into the base protocol then there's a chance that clients would implement the standard and actually use it.
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.
