2,937 karma · joined March 25, 2009
Computers are cool
That said, being an eager doc writer in an effort to claim credit or inflate the perception of your own work is a great way to lose friends and alienate people.
And then I looked over and Mario had implemented a graphing calculator (as in, take "y = x^2 + 4x -10" and emit a graph) in the windows command prompt. Then, when that was boring, he started researching and implementing the graphics algorithms for drawing lines at various slopes with minimal distortion. And then, when that was boring, he made his graphing calculator support polar coordinates (something I understood only as "oops, my graphing calculator is misconfigured").
Also, he was ~12 years old (IIRC) having skipped a few grades.
I've met a lot of smart people between Carnegie Mellon, Facebook Infrastructure, and the Linux Kernel community, but Mario's one of two or maybe three at the absolute top in terms of intellectual horsepower.
Original bpf is a much simpler bytecode. Ebpf extended it and made it essentially x86_64 assembly (semantically). Then we all decided to call ebpf bpf for reasons.
But the worst case will be dismal and not unlikely.
In this case, beyond the patches, we built oomd and ran the whole contraption in production on hundreds of thousands of servers. When it meaningfully improved metrics there, it became an easier thing to sell.
Second, I don't actually agree. JIT compilation is a generally accepted approach -- who cares what the IR is? And the bpf runtime is ULTRA constrained, so you can't slip a `system("rm -rf /")` in there (by a long shot).
I did good but not great on the SAT and only got into CMU because I was a student athlete. But once I had my foot in the door I did very well (high gpa, TA'ed, graduated w/ honors and awards) and then continued to do very well in industry (arguably).
If an adversity score can help out other kids like me who don't happen to be "impressive-for-a-D3-school" level athletes, then I think it's a great thing.
I don't necessarily think you're wrong; I just think your argument, as stated, is weak.
Probably worth adding that we ultimately created a python foundation team, of which Jason is a member.
Here's something dumb I created in my "within working hours" free time that Facebook let me open source: https://github.com/facebookresearch/py2bpf
The drawback to this though was that the best are easily bored. FogBugz was an important cash cow for the company, but there were few truly novel problems to solve. This was not a "web scale" effort -- it was self-hosted software for tens to hundreds of seats.
So I speculate that they okay'ed the project just because it was an interesting thing to do that solved the underlying problem (albeit in a bit of a convoluted way). The simple cost/benefit analysis from a management point of view is simple; pros: your devs are happy and you get linux support; cons: it's a little more complicated and people make fun of you on the Internet.
Over time, Fog Creek came up with better outlets for this kind of nerd energy -- kiln was fun because there were mercurial nerds around; trello was a foray into server-side javascript. There was still a bit of that "the nerds rule" bad decision making that made FogCreek an awesome place to work, but it was more constrained.
Since then (and I'm way out of it now), a lot of the old school "just badass" programmers have kind of gone their own way and Fog Creek has hired folks who are better aligned with what they do and how they do it. I'm not sure if this is because of a masterful shift in recruiting philosophy or if the diminishing recruiting brand (due to Joel's blogging pause) led to the right kind of developers becoming interested naturally.
In either event, it was definitely a very interesting culture, and I'm happy to have been able to play along for a summer :)
int fd = socket(...);
if (fd < 0) return false;
SCOPE_EXIT { ::close(fd); };
if (ioctl(fd, ...) != 0) return false;
if (ioctl(fd, ...) != 0) return false;
...
return true;
Personally, this has lead to me getting messed with my managers ~never, which is a very high-order bit in my work happiness.
> Those long nights,
What nerd hasn't spent all night building something cool? I've /never/ been asked to stay at the office after hours and it's not an expectation that any of the big tech firms have.
> long commutes
No one gives a crap when you get in. I usually leave for work at like 10 AM and complete my 30 mile commute in about 40 minutes -- it's no big deal.
> (if you don't live a block away),
I used to have a shorter commute but I think SF is more fun and it's not that big of a deal...
> they can all wear you down.
I suppose if they were as you've stated them, but they're not.
> You're pressured into working more
You're really not. Also, we get like 21 full days of PTO, and I'm eligible for my sabbatical in another 6 months, which is just an additional month of free PTO.
> and you have less time to spend with friends and family
In addition to the fact that I get to hang out with friends pretty much whenever I want (no one cares about the 9-5 thing), I'm able to use my generous PTO to go visit family, which I probably do 3-4 times a year (honestly, love my family, but more would be too much)
> (work IS your friends and family! :')),
I get to work with a lot of smart people who I deeply respect and do consider to be exceptional friends. I also have friends who work at different tech companies and even outside of tech, and I get them the same was as anybody else, hanging out.
> less time for dating
We've got plenty of time for dating. My friends are going on dates all the time actually. Dinner, Drinks, Hiking... they're all totally possible thing to do.
> (and let's be honest: if you're a single man in the Valley, you're not getting laid).
Not going to dignify this with a response.
> It just sucks.
You are incorrect
> Is that worth it?
Beyond the shadow of a doubt :)
But, even assuming you handle every failed page allocation perfectly and your stack does the right thing, you can still screw yourself /trivially/ by blowing out the network stack, or because the writeback daemon can't keep up with your filesystem writes. So now we're talking about clamping kernel resources with userspace logic that does things like periodic fsyncs and userspace tcp acks before attempting to send more -- good luck.
If the # of ports is the bottle neck, you can configure more IPs on a single host.
Casually looking at strings /usr/sbin/sshd on my devserver reveals that there is a mode to create a tun device, which sets up a more traditional VPN-ish thing (basically, your computer sees a new interface and routes certain sections of IP space to that prefix. sshd sucks in these packets and forwards them as is). This results in two layers of congestion control, which (IIRC -- I'm not a TCP guy) Congestion Control Algorithms aren't set up to handle very well.
The more traditional mechanism for tunneling though (the one most often referenced in the posts and things I've seen) is a layer 7 forwarder. Basically it creates sockets to listen for connections on either ends on a specific port, recv's data as a traditional network user, and then turns around and sends the data over the multiplexed transport to the end server. It essentially strips away the congestion control on the first hop (because you're just going to localhost anyway) and there's no TCP/IP packets in TCP/IP packets thing going on anymore, just your application stream in their header transport thing. It's less flexible, but is good enough if you want to set up a simple proxy or something and doesn't have the same pitfalls.
If you need the flexibility, something like OpenVPN might be good (though I haven't used it myself).
And you might also want to look at stunnel as an ssl tunnel alternative that lets you have more control over what certs go where without archaic and dangerous /etc/ssh/*_config meddling
Mcrouter was the first piece of software I worked on at facebook. It's nice to see that you like it! (Though the only thing that lives on from me is the umbrella protocol)