ardel95

Demoiselle crane flies over Himalayas and over Everest during its yearly migration, so it'd be flying at least 30k feet high.

I only know that from Planet Earth documentary, which was such a great show!

Unless I screwed up the math, they would be quarter of a light year apart. Plenty of space for each black hole to form its own accretion disk.

Kepler’s laws should still provide a pretty good estimate, at least until black holes get much closer. I did a quick back of the envelope calculation, and looks like they’ll be roughly 14k astronomical units, or 0.22 light years apart.

1604. One could say we are overdue. I’m not sure about dust or other obstacles blocking it, but based on brightness alone a supernova in our galaxy should be visible with naked eye.

It would be. Which is why any pair of orbiting bodies will eventually collide.

It’s just that for black holes this effect is insignificant (a merger would take much longer than the age of the Universe) until they get close to each other, much closer than 1 parsec.

The potential to detect Supermassive Black Hole mergers is one of the reasons I'm really excited about the LISA project [1], and hope it actually gets funded and doesn't delay too much.

[1] https://en.wikipedia.org/wiki/Laser_Interferometer_Space_Ant...

In quantum mechanics, bosons are (often massless) force carrying particles like photons or gluons. Fermions are the massive matter particles, such as electrons or quarks.

So, while I’ve never heard this saying before, I assume it’s meaning is that massless particles like photons are best for carrying information around (rather than electrons we are using in circuits today), while the electrons are best for carrying state, like in a switch.

Note, that in networking we have already made that transition by using fiber optics, rather than electric wire to transfer information over longer distances.

So that xkcd “daylight savings time” meme was an actual movie?

The article didn’t mention this, but don’t u128s get mapped to SSE2 registers on most modern x86_64 processors, and not regular 64-bit ones?

That’s a pretty pedantic interpretation of the word application. In the context of software owned by most teams, that they may decide to run on single vs multiple hosts most applications are absolutely stateless. Most applications outsource state to another system, like a relational database, a managed no-SQL store, or an object store.

And so no, most teams don’t need to worry about the hard problems you bring up.

Totally. But most applications are not stateful.

If you have the ability to spin up a new machine when the old one fails, and deploy your app onto it in one minute, it’s not a big leap to also run your app on two machines and avoid that downtime altogether.

Almost every modern router in a multipath network peeks at the next layer to implement flow hashing correctly.

One of the biggest misses with IP fragmentation was not requiring each fragment to carry the higher protocol header. Or at least do that for UDP.

That decision alone would’ve made fragments so much simpler on network devices and appliances, and much less likely for them to get dropped.

That would effectively kill software patents. Which is a fine outcome.

The absolute performance isn't very important for the stock price. What matters way more is the performance vis-a-vis market expectations. So in this case, the market was expecting something better (or there was some other guidance in the report that spooked investors).

This is a good example of the type of challenges you face as an author of widely used library. I can see a lot of scenarios where an optimization like this would bring benefits. But there are also many where it would hurt performance (not to mention memory usage), including most "collect once read many times" use-cases.

But I think the real thing for me is that this violates the principle of least surprise. If I wanted the type of memory reuse / lazy transformation behavior this optimization introduces, I would be looking at working with an iterator with a bunch of functinoal transforms. And if I'm calling .collect() it's because I want to convert the iterator into a data structure optimized for reads.

But I can also see how others would land on the other end, and hence the challenges for the library authors.

I think Apple is fully capable of getting there too. They have a high enough price point, and a loyal enough customer base, that even if getting there required additional hardware or shipping with more RAM by default, they could make it work.

The story of what happened in the cockpit during the failure is just as interesting! The captain made a number of right decisions in a very challenging situation that allowed the plane to safely land.

Mentour Pilot did a video on that: https://youtu.be/JSMe1wAdMdg?si=YSgbqFpR_EBe-FvX

I think one of the most desirable and under-appreciated goals of schema languages and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs.

My read of Cap’n’Proto didn’t make it sound that safety was the highest priority. At least not above performance.

An example of this already happening in a way that is transparent to the applications: https://aws.amazon.com/about-aws/whats-new/2022/11/elastic-n...

There is a huge difference between running infrastructure on behalf of a single, well-intentioned business and running infrastructure that needs to deal with high density, adversarial multi-tenancy.

Not saying they can’t do it if they really committed, but the premise of the question that “they already have technical expertise” is flawed.

Btw, this is the similar learning curve that Google went through (and arguably still going through) when they decided that they could expose their awesome infra to external customers.

I admit, I’m having a hard time holding back a sarcastic reply to this article. Was there really any doubt ever that a button, which one can usually push without looking is superior to touchscreen, which for an average human requires both hands and eyes?

I really enjoyed the article.

The only thing that stood out was that the argument the author set out to dispel had a much simpler flaw. In the original argument, point number 3 (having less skin in the game leads to bad decisions) is the weakest one.

That statement isn’t really a first principles fact, but at best a hypothesis. IMO, not even a good one. For all we know, having less extreme exposure may lead to better decisions, as the founder may be open to more calculated risks. And even IF true that statement doesn’t address the tradeoffs: maybe bad decisions are outweighed by the ability to outrun the competitors due to influx of extra cash.

While there is certainly some correlation in such arguments, the bar for proving causation needs to be much higher than a pithy statement.

All that being said, I really enjoyed the rest of the argument.

Minor nit: many of the differences in the article aren't really specific to the Rust vs C++, but rather differences between llvm vs whatever compiler backend is used by msvc.

How is that semantically different from Rust?

in - regular function arguments

inout - mut function arguments

out - function return

Is there any additional information that a compiler can infer from Ada’s parameter syntax?

My first home computer had a sound blaster 500 sound card (remember when computers needed sound cards?) which had built-in MIDI support. The thing that absolutely stood out about MIDI is the small file sizes and crystal clear sound quality. All it effectively needed to encode was the meta data about the instrument - it’s analogous to encoding sheet music into a file format! What a blast from the last.

While you are right, we are where we are and there is tremendous leverage in making an extremely common (even if undesirable) thing more efficient. It kind of doesn't matter why millions of lines of code perform memcpys - they do, and we're unlikely to change majority of them anytime soon.

P.S. I work on the type of systems where we obsess over unneeded memory accesses and copies. Minimizing those is not as trivial as it may seem, especially if you care about memory safety.

So New Zealand is about to prop world’s first an underground cigarette market.

So the whole 5 year process with thousands of human years of effort boiled down to: We’ll use some cloud.

Fascinating.