hblanks

I'd read the report. It had more to say on how carriers could cause worse injuries due to vertical orientation of the child.

To summarize something from a little over a year after I joined there: Cloudflare was building out a way to ship logs from its edge to a central point for customer analytics and serving logs to enterprise customers. As I understood it, the primary engineer who built all of that out, Albert Strasheim, benchmarked the most likely serialization options available and found Cap'n Proto to be appreciably faster than protobuf. It had a great C++ implementation (which we could use from nginx, IIRC with some lua involved) and while the Go implementation, which we used on the consuming side, had its warts, folks were able to fix the key parts that needed attention.

Anyway. Cloudflare's always been pretty cost efficient machine wise, so it was a natural choice given the performance needs we had. In my time in the data team there, Cap'n Proto was always pretty easy to work with, and sharing proto definitions from a central schema repo worked pretty well, too. Thanks for your work, Kenton!

(Yes to the earlier post - had a similar experience with an early metrics system for Twilio in 2012-2013)

The 1st issue is that ZMQ implementations generally have an IO thread handling all socket IO. REQ/REP patterns tend to work out just fine, because the client is going to wait for a reply from the server. But things like PUSH/PULL become...harder to follow. You can push things in the client, but how do you know when they've flushed out of the IO thread and made it to the server? Those sorts of things matter when shutting down a process, running integration tests, etc. In contrast, with an HTTP request, you're basically always doing REQ/REP, and so you know when the data has been pushed.

The 2nd issue is that ZMQ implementations tend to be harder to observe / operate than a more common path like HTTP requests. (HTTP requests can go through a load balancer, have standard response codes, use headers for authorization, etc.) For these reasons, I've tended to avoid ZMQ ever after -- it seems like often, you're best off either using REST or GRPC if by HTTP, or raw TCP if it's purely a data push kind of operation (e.g. forwarding structured logs, with framing, to a remote TLS endpoint).

Or similarly toxic chloramine gas, when combined with cleaning agents containing ammonia, such as Mr. Clean.

It'd be hard to understand without feeling it for yourself, but in actual instrument conditions (IMC), it's easy for your sense of balance to mislead you into thinking you're level, when in fact you're turning.

There's some physiology to explain this, but one key point is that once you're in a coordinated turn, even a descending one, your weight is still going straight down the vertical axis of the seat. So, you'll think you're doing fine, and possibly even pull the turn tighter (the graveyard spiral), and fixate on things other than the attitude indicator and your plummeting altitude.

A couple things to consider:

* Hour restrictions for passenger transport are significantly more stringent than for freight.

* Southern Air's fleet consists 737s and 777s -- not small planes.

* These plans have to fly over and into major metropolitan areas.

* Many parts of flying can be automated, but in the end, and for aircraft this size, you probably want a human operator in the plane for the sheer reason that they are better equipped to handle unplanned emergencies.

It's a tough call whether flying freight or regional airlines pays worse -- but in either case, you're anywhere from a quarter to half of what a software engineer of similar years experience in the bay area would make. The hours are in a lot of ways worse -- mostly because you're away from home a lot of the time, and you have really limited control of your schedule. (As someone who's worked as an on-call engineer for ten years, and who also flies, I'd take the on-call responsibilities over flying freight any day of the week.)

I'd agree that the article lacks for details. But, a relatively quick reading through things like airliners.net will give you an idea of the kind of hours and pay these guys typically work -- it's not an easy job. If we care about their safety -- and our own, given the number of freight aircraft flying over us every night -- we shouldn't write them off as just asking for money they don't deserve.