ardel95

My bet is that OpenRouter began steering GPT-5.6-sol users towards flex tier, which is already 50% off.

So this isn’t really a price cut. As to why, lots of possible reasons. Perhaps an agreement with OpenAI to help them drive up more diverse traffic priorities.

CSAM, and other harms, are typically detected using a set of specially trained, faster and cheaper models (and out of band matching techniques) that run before and after the main model.

Any mention in the system prompt is mostly defense in depth, and to make refusals more graceful.

Is it really that unusual? When you attach an image or a video, it gets converted to tokens you don’t see, at a rate that is proprietary to the model. You pay for those tokens, but don’t see them. Even how text is converted to tokens is a property of the dictionary, which is opaque for proprietary models.

There are features of input and output that are opaque to you, but that you pay for. Part of how model providers chose to run their service.

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.

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.