evanj

5 ms·

1.
by evanj 9y ago
Fair queuing is an interesting and complementary approach that I have not considered, thanks for the suggestion. I usually work with "internal" systems that don't always have an obvious "user" identifier, but it wou
2.
by evanj 9y ago
I agree that a universal solution sounds difficult. However, it seems like it should be possible to have something that works "well enough" for some (broad) class of servers. My example is TCP, which does a "good enough"
3.
by evanj 9y ago
Exactly right. I just enabled billing on this project. Oops!
4.
by evanj 9y ago
This is a good point, although I don't think I said "connections", I said "requests". The definition of requests is going to vary significantly. Yes, very slow clients are yet another problem that extremely robust s
5.
by evanj 9y ago
I use App Engine's static file serving to serve my site. It has a 1 GB/day bandwidth limit. It turns out Hacker News still moves a lot of traffic, so this is the first time I've crossed it! Oops. Billing is now enabled on thi
6.
by evanj 9y ago
Awesome this is exactly the sort of system I had in mind when I wrote that article, I'll take a look, thanks!
7.
by evanj 9y ago
Thanks for the link, the abstract seems relevant. I agree: a control algorithm seems like it should work. The challenge is figuring out the metrics and parameters to make something that works "well enough" for most applications, l
8.
by evanj 10y ago
You make an excellent point: probability says a 4-byte CRC32C provides much weaker guarantees as the length of the message gets longer. These CRCs are typically optimized for pretty short messages, and that is what I had in mind when I wrot
9.
by evanj 10y ago
See the previous Hacker News discussion from October 2015: https://news.ycombinator.com/item?id=10360108 I'm glad people are still interested in this subject. :)
10.
by evanj 10y ago
Ah thanks, that makes sense. Fun trade-offs: Either run out of memory when you call fork, or fight with the out-of-memory killer at a later time :)
11.
by evanj 10y ago
This is possible , but I find these restrictions to be hard to follow. As soon as you need to call a function, you now need to audit that function to determine that it only calls other async signal safe functions. When you come back to the
12.
by evanj 10y ago
Thanks for pointing this out! Interesting that the code states that part of the concern is increasing memory usage. I don't quite understand why it would "duplicate the memory usage" since fork uses copy-on-write? Anyway, I d
13.
by evanj 10y ago
Fair point. My opinion is that in today's age of multi-core CPUs, shared memory concurrency is extremely useful for making efficient use of computing resources. As a result, I find threads to be unavoidable in most large systems I&#x27
14.
by evanj 10y ago
You are completely correct! The thing that surprised me is how difficult that can be. For example, on Mac OS X if you want to read the system proxy settings, you magically get threads added to your program that you can't control.
15.
by evanj 10y ago
Part of my motivation for writing these things is because after I've wasted so much time, I'd love to help others not do the same. Hopefully the article shows up when you search for the right error message. Its also so I remembe
16.
by evanj 10y ago
You are completely correct: it is in fact possible to use fork if you can carefully control the state of threads in your program. My point is that can be difficult in large software projects, particularly when random APIs like "get the
17.
by evanj 11y ago
I've been trying to get Docker to include this workaround when it creates containers to ensure people don't run into it, but this has not gotten any attention: https://github.com/docker/docker/issues&#x2F
18.
by evanj 11y ago
It might. I don't know enough about them. Anything that routes packets without NAT to a veth device is affected.
19.
by evanj 11y ago
Yes, with some caveats: Lots of configurations that use veths use NAT to share the IP address of the host. For example, this is Docker's default configuration. In this case, the host kernel checks the TCP checksum no matter what, so th
20.
by evanj 11y ago
Thanks for the details! This is basically what Vijay and I were guessing by the fact that the MTU is something less than 1500 on Google Compute Engine. The demonstration that Vijay added to the post was done on Google Container Engine, usin
21.
by evanj 11y ago
Its actually very useful, although very weak. The link layer check, at least in the case of Ethernet, really only protects your data "on the wire". It doesn't protect it inside the switches. It turns out there are failure mod
22.
by evanj 11y ago
It turns out that hardware can fail in weird ways. Its not common, but it appears that it is not uncommon that the memory in a network device can go bad. When this happens, lots of packets are corrupted. I have a description of how I think
23.
by evanj 11y ago
Pretty much. It turns out that marketing is hard. :)
24.
by evanj 11y ago
There are some companies using it. It is possible that on-boarding a new person RIGHT NOW while they figure out their long-term solution is helpful. Small possibility, but I want to make this transition as easy as possible.
25.
by evanj 11y ago
Open sourcing things is hard, and yes we did the classic mistake of "throwing it over the wall" and not being able to give it the time and attention it would need to be successful. We guessed that would likely be the outcome, but
26.
by evanj 11y ago
Sorry for the delay. The monthly costs (which are actually closer ~$800-1000/month), are a small part. A bigger worry is if we take money from people, we really have some obligation to provide "reasonable" service. We've
27.
by evanj 12y ago
The Android app is in the mitro-core/android/MitroApp directory, and should build with the Eclipse ADT. See: https://github.com/mitro-co/mitro/tree/master/mitro-core/and...
28.
by evanj 12y ago
That is absolutely the intention. Currently the docs are lacking, but we will try to add directions about running your own server in the next few days.
29.
by evanj 13y ago
I second this recommendation. Its the best description I've found of how to systematically approach debugging. I read it after I already had lots of industry experience, but still found it useful because it provides a "formal&quot
30.
by evanj 13y ago
Awesome summary of JavaScript's dangerous corners. I wish I had read this about 6 months ago, before I started writing a lot of JavaScript. I think I've been burned by each of these.

More ›