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.

From sled tests done by Australia in 2022:

> A lap-belt restrained adult dummy in an aircraft seat, with an infant dummy in a carrier, was subjected to a 9G dynamic sled test. The severity of the pulse was based on the results of a static load test. The commercially available infant carriers tested were not able to restrain infants under crash situations.

https://www.atsb.gov.au/publications/research-and-analysis-r...

Location: SF

Remote: OK

Willing to relocate: No

Technologies: go, python, postgres, ClickHouse, kafka, K8S, and various other things tied to high throughput backend systems. Also have an MSc in stats from LSHTM.

Résumé/CV: https://drive.google.com/file/d/1BQUA3tVHzEZKyUQjOBIZKf453m9...

Email: (see CV)

I'm a career backend engineer who's worked most lately as a technical lead/manager delivering reliable, high throughput, containerized job scheduling to enterprise customers. Ex Twilio, Cloudflare, Segment. Looking for a long term opportunity in anything tied to high performance backend services or data infra, be that in a lead, EM, or IC role.

I've done a lot of early stage work and am a generalist at heart, though these days I'm most interested in post series A (including public) companies.

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!

I also think his thesis isn't to celebrate poverty but to consider that development (or modernity, globalization, pick a term) comes with its own problems.

https://en.wikipedia.org/wiki/Age_of_Anger , his book from 2017, isn't perfect but it's a good read of what he's about.

(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).

Cf. William Deresiewicz's address to the cadets of West Point in 2009 (https://theamericanscholar.org/solitude-and-leadership/).

I think the most surprising insight is his commentary on Heart of Darkness as a novel about bureaucracy -- it's worth a read.

You don't have to agree with her politics, but I think Peggy Noonan had the right answer on this one: it's a show and there's no good to be found in taking part.

Just say no and hit send.

> In February 2018 Nicholas Thompson and Fred Vogelstein of Wired wrote a deeply reported piece that mentioned the 2016 meeting. It was called so that the company could “make a show of apologizing for its sins.” A Facebook employee who helped plan it said part of its goal—they are clever at Facebook and knew their mark!—was to get the conservatives fighting with each other. “They made sure to have libertarians who wouldn’t want to regulate the platform and partisans who would.” Another goal was to leave attendees “bored to death” by a technical presentation after Mr. Zuckerberg spoke.

(http://peggynoonan.com/overthrow-the-prince-of-facebook/)

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

I've not spent enough time on Pearl, but Migual Hernan and Jamie Robins have a free textbook on causal inference at https://www.hsph.harvard.edu/miguel-hernan/causal-inference-... ; parts of it were pretty useful for a causal inference assignment I did earlier this year.

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.

Michel Foucault also wrote about this essay. His essay starts thus:

> Today when a periodical asks its readers a question, it does so in order to collect opinions on some subject about which everyone has an opinion already; there is not much likelihood of learning anything new. In the eighteenth century, editors preferred to question the public on problems that did not yet have solutions. I don't know whether or not that practice was more effective; it was unquestionably more entertaining.

> In any event, in line with this custom, in November 1784 a German periodical, Berlinische Monatschrift published a response to the question: Was ist Aufklärung? And the respondent was Kant.

(https://www.libarts.colostate.edu/leap/wp-content/uploads/si...)

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.

We're using it internally, and also for a relatively small customer-facing analytics API, on the order of 10-30 nodes.

It's been good so far. Good support from the maintainers, too.

If you haven't read it, you may find Hannah Arendt's Origins of Totalitarianism a worthwhile read. She offers a lot of analysis on the rise of a classless society, paired with a deep sort of aimlessness in state leadership.

It doesn't end well.

Or the excerpt of the book printed in Harpers: http://harpers.org/archive/2016/08/the-origins-of-speech/

Macheath [Mac the Knife]: "If the poor are so powerful, then why do they need us?"

Peachum [The Beggar King]: "Because they don't know that we need them."

--Die Dreigroschenoper (1931 Film)

Correct. CTEs are pretty much a no-go, and you also can't do things like join between distributed and non-distributed tables.

Your queries tend to break down into ones where you're hitting a small number of shards (such as when we serve data for the analytics page), or else ones where you tend to aggregate up into temporary, non-distributed tables for further analysis (such as you'd do for infrequent business reporting).

All told, it's been one of the easier tools for us to operationalize, largely thanks to the fact that it's "just PostgreSQL." The one thing I wish we had was better documentation of what kind of consistency guarantees to expect, although for an append-only store like our current use case, that's less of a concern. And to be fair, Ozgun and the other guys at Citus have always been really happy to answer any questions we have.

With this code now going open source, it should be pretty easy to look into these sorts of internals.

We've been running CitusDB for a couple years now at CloudFlare for serving aggregated analytics to customers (cf. https://blog.cloudflare.com/scaling-out-postgresql-for-cloud...).

It's a good product, and it was even fairly easy to do a major version upgrade / cluster relocation. At least as easy as such a thing can be. :-)

Maurice Blanchot, you are still waiting for us to catch up.

"Un récit? Non, pas de récit, plus jamais."

This is all a bit reminiscent of Double Helix (https://en.wikipedia.org/wiki/Helix_(database)).

The best part of using Helix was that the people doing data entry, and the people who worked closely with them, really could and did update the forms themselves.

I like paper for a lot of things, but in software, I've always hoped we can arrive at systems where users get more of a hand in shaping the tools they use. We're not there yet.

Who works with someone like this today?

What a pleasure this interview was to read. And plain spoken, too.

Many here have complained that Derrida is hard to read, or worse, simply makes no sense. You may take a side in this, if you like. But I would encourage you to read some short piece of his instead. In so doing, and as the interview itself remarks on reading, you may make your own interpretation.

@mbrock has listed several items. To these, I add what my instructor for composition at Deep Springs (himself a student of Derrida) assigned us, "Declarations of Independence." It is but a nine page talk on the US Declaration of Independence. But within it, many of Derrida's persistent concerns on language and action come to light.

You can find it online, starting at page 5 in this PDF: http://blog.lib.umn.edu/cole0384/academics/files/Derrida.PDF

These are the numbers in Sierra Leone from Les Roberts, WHO Foreign Medical Team Coordinator.

Les is a long-time epidemiologist and sanitation engineer; he's served in dozens of outbreaks and conflict situations including both of the cholera epidemics in Goma following the Rwandan genocide.

Golly. I thought this was going to be about a hospital ward in sub-saharan Africa, some abandoned corner of Asia, or even a VA hospital here in the US.

I'm glad people care, but for me, these are first world problems compared to drug shortages, inadequate facilities for water and sanitation, missing diagnostics, payroll shortfalls, and so many things.

Sadly, though, these are not problems that programmers can do much to fix.

Lobste.rs, of course, toplists the original citation in place of Yann's response. I find it better reading.

Even Linux only started using VCS in 1998. It was only tarballs maintained by Linus and e-mailed patches before then.

Rebel Code (http://books.google.com/books/about/Rebel_Code.html?id=kIU1s...) does a pretty good job summing up how Linux migrated from tarball source releases to BitKeeper (and eventually, of course, git). It appears that Steve Weber also writes on this, in a format that may be easier to read. (http://books.google.com/books?id=78SLSiWqy14C&pg=PA117&lpg=P...). The e-mails sent at the time around this make this thread seem, well, pretty friendly, actually. (http://lkml.iu.edu/hypermail/linux/kernel/9809.3/0493.html)

To the Postfix maintainers' point, Linus appears to have had quite reasonable reasons for maintaining the changes himself in the years up to then. Only when the number of active contributors got large (I suspect significantly larger than Postfix's) did this model break down. It's not the best for everyone, but I'm really glad they're maintaining a great open source product. The early 2000s in particular were not an easy time for MTAs.

Thanks John Graham-Cumming! It's neat to see (what at least might be) some part of the Railgun making it back into the go community.

I said this elsewhere already, but I've been really proud to see Twilio take steps such as this one to bring more people (and more women in particular) into programming. Not being a part of the web team, I've only watched from the sidelines as Renee, who's consistently been in the office before I arrive in the morning and after I roll out in the evening, has worked to master a whole slew of technologies, and to ship new, non-trivial features for our customers.

I'm really not sure how the two facts we see here -- of people working exceptionally hard to better themselves, and of a company going out of its way to help people do that -- have to do with a bubble. It's hardly a new idea that companies do better financially when they help their employees learn to do work that they couldn't do before, or to do it better.

As the technology community, it's in all our interest to help people learn things they couldn't do before. Twilio's story is one example. Other great ones include RailsBridge, PyLadies, the Boston Python Workshop, and PyStar. Let's do more of this!