I'm not sure where you're getting the "Apple holds soft power over FreeBSD" thing from. Netflix is probably at the top of the list given all their performance and stability work -- and, you know, the fact they push a large chunk of all Internet traffic using FreeBSD -- and NetApp and Juniper are somewhere up there, but I'm not convinced Apple would even be in the top 10.
> I'm not sure where you're getting the "Apple holds soft power over FreeBSD" thing from.
The only thing I've ever heard from FreeBSD-land, not paying attention to users, but the maintainers and the tools. Apple comes up. In the same manner that RedHat and others come up for Linux. How to explain? It's an abstract pattern. Transparent, understandable.
I mentioned somewhere about the connection through ix systems. And honestly to project, if I was a maintainer of something used between Netflix and Apple, I'd prioritize Apple. Apple has outlived IBM. If you know your history, you know how serious that is. If you've got authority over something as large as FreeBSD? Yeah, you don't ignore that kind of actual power especially when it's personal. Like I say, all based on guesses. But some things are hard to mistake.
Apple did very important work making LLVM happen, but that was a long time ago. At this point there are lots of companies involved in that project.
As far as "power" is concerned... speaking as release engineer, I don't give special treatment to anyone; nor have I even been asked to. If anyone has a special relationship it's Netflix but if anything that's the opposite way around: "Can you please throw 10% of all Internet traffic at this TCP stack patch and let us know if anything breaks" is a thing. They're incredibly helpful with Q/A.
Consider me convinced. Like I say, it was never anything but empirical skepticism. Neither for or against until sufficient evidence has been collected, as painful as that can be. Thank you for your work on scrypt.
I may be wrong about OPs intention, but AFAICT, because no encoding is specified, the client gets to choose. For someone not using a default encoding that's a superset of ASCII (like ISO-2022-KR) the page appears as a �.
Current practice is to put a meta tag with your encoding, use a Unicode BOM, or less favorably, send the charset attribute in the Content-type header.
My understanding is that EBS has some heuristics for deciding whether to keep data cached; an AMI which has a cached snapshot as its root disk will boot much faster than an AMI where all the data needs to be pulled from S3.
What's the smallest size for which those heuristics keep the snapshot cached?
(I'm currently using 1GB snapshots, because my actual disk image is a tiny fraction of that size. But if bumping that to 2GB or 4GB would make it faster, that's a small price to pay.)
Do you have any other wisdom regarding mysterious reasons for fast or slow booting? EC2's boot process is deeply opaque, and any insight at all is better than nothing.
reply