itishappy

Doom, Quake, and assumedly your games don't use their command line as primary input like this.

> I break about 1 USB-C plug a week.

Wild. How often do you break the phone itself?

I explicitly do not mean "poor," that's why I choose "unknown." A better word would have been "variable." The point I intend to convey is that you need to use other signals to judge.

That's also why "closed-source" was mentioned in the same sentence. Two missing signals.

That's also why the author keeps pointing to the benchmarks and test suite, which is the signal they'd like us to judge by. Seems entirely reasonable to me!

Relevant section:

> 2.3. Privacy and data protection

> 2.3.1. The ADDW system shall function without relying on biometric personal data of any vehicle occupants. In this context, the biometric personal data is resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data. This requirement does not forbid the ADDW system to use data from the camera(s) equipped in the vehicle, it forbids the identification of the person by the ADDW system.

> 2.3.2. The ADDW system shall be designed in such a way that it shall only continuously record and retain data necessary for the system to function and operate within a closed-loop system.

> 2.3.3. Any processing of personal data shall be carried out in accordance with Union data protection law.

This doesn't appear to ban identification of the user by, say, the Advanced Driver Distraction Reporting System, which is triggered by and utilizes the same data streams as the Advanced Driver Distraction Warning System.

Why would ordinary cornering need to use the shoulder?

It's a strong signal of unknown quality. Caveat emptor. Closed-source makes that extra difficult.

We are used to this, hence why folks here point it out.

Yup, that's the exact video I had in mind!

I bet 5 million coupled oscillators, all slightly detuned, would sound freakin' amazing.

"I'm sorry we couldn't resolve things before they caused you to leave."

It can write some fascinating stuff, but you have to learn to think in it:

https://enkimute.github.io/ganja.js/examples/coffeeshop.html

A major problem is that its a very general theory. Most calculations turn into very large but very sparse matrix multiplications. To make them work fast requires code generation and an optimization pass.

These types of optimization problems show up all over graphics programming though:

* Representing rotations with matrices takes more space than quaternions.

* Sacrificing a dimension to projective geometry actually makes representing things like projections (duh) but also translations more efficient.

Keep in mind that the energy density of nuclear fuel is astronomically higher than that of coal, so even if the processes were equivalently wasteful (and I'm fairly certain they are not) coal would still cause significantly more damage. The process also differ significantly:

Uranium is often pumped out of the ground after being chemically extracted.

Coal is almost always carted out after being blasted.

Despite my background in color science, I find RGB more intuitive. With HSV I have to remember the chirality of hue and it's zero point, and when changing hue I find it difficult to reason about saturation. In practice this means I must "nudge and judge" with both systems. With RGB I can always make progress. With HSV I guess hue wrong about half the time. I could probably improve this.

To be fair, I'm also colorblind. That's probably relevant.

Anyway, I'd say the answer to both your questions is: "sometimes"

That is literally not true.

The feeling of disconnect between your comment(s) and the intent of the tool remains.

What defines a bad tech vs a good tech? Similar arguments can be made for most research including nuclear fusion, AI, vaccines, space, polymers, combustion engines, electric motors, semiconductors...

More art than spec. I can dig it.

I have always appreciated the concept of thinking of colors as a cube (even though I now view them as triangles or weird pyramid things). Thinking of cubes as a 10x10x10 cube composed of 1000 smaller cubes is another mental model I've returned to often. I actually kinda like this for hacking on stuff like terminal colors.

Getting mangled by the receiver appears to be part of the spec. They've implemented their a custom LUT and suggest others should do the same.

It feels like there's a fundamental disconnect between your comment the intent of the tool.

No worries, I understood your intent!

The impact is a lot less than you may expect. Brains are ridiculously good at filling in incomplete information. For example, did you know that you have a roughly sun-sized blind spot slightly off center in each eye (where the optic nerve attaches)?

Now imagine needing to switch glasses to read your dash. Inconvenient and unsafe!

The parent comment is not suggesting that Yon is about physics/metaphysics.

Understanding is important for readers. Demonstrating understanding is important for writers of both technical documentation and internet comments, and of critical importance in the era of AI.

It's cheaper for the AI provider to use your laptop instead of their datacenter.

Teslas spend a tiny percentage of their life at highway speeds, and a major selling point of the platform is that their compute would be used to pilot the vehicle.

If they could train using Teslas they wouldn't have needed Dojo.

Bifocals in general are quite useful. It's nice to be able to see the road and the speedometer using the same lenses.

Traditional bifocals and progressives are different beasts. The hard outline on traditional bifocals means you get essentially two different lenses, both able to function as intended. The soft blend on progressives means you get essentially one big blurry lens that does not have well defined properties anywhere.

Obviously you need to use air tight paint.

Would it leave a cool pattern?

When writing a high performance video codec avoiding defensive copies of objects is something you want always, not just often.

C makes it easy to be fast but hard to be safe. Rust makes it easy to be safe but hard to be fast.

Also note that video codecs tend to wrap C or Rust around handcrafted ASM. Performance is king.

This is a software decoder designed to run on general purpose hardware.

Adding custom hardware like tensor cores to the stack would serves a different use case.

The argument is that the ergonomics of using Python are worth the squeeze of learning two languages. Are the ergonomics of using Zig really enough to justify replacing Python on the happy path, or would it end up replacing just C?

> The true irony is that even SIMD text parsing would outperform this! SIMD is that powerful.

Can you explain this part a bit? I feel like intuitively (and therefore probably incorrectly) these should have the same difficulties.

Ohh, then combustion itself. Right. Thanks, lol.

Here's a fascinating postmortem analysis of two similar incidents, Styrene and Butyl Acrylate:

https://iomosaic.com/docs/default-source/papers/polymerizati...

From fuzzfactor's comment with lots of other great info:

https://news.ycombinator.com/item?id=48252245

It can actually make it more dangerous in some ways. When you go to use it, too much inhibitor and the conditions needed to start the reaction will start to get wild, so the reaction will occur faster once started.

> The use of high levels of inhibitor can cause the monomer system temperature to far exceed the onset temperature of thermal polymerization under external heating. Once the inhibitor is exhausted, the thermal runaway reaction proceeds at an elevated temperature with a substantial reaction rate and very little reactant/monomer consumption.

Source: This fascinating paper linked to by fuzzfactor in yesterday's (edit: 3 days ago, lol) thread:

https://iomosaic.com/docs/default-source/papers/polymerizati...

The comment:

https://news.ycombinator.com/item?id=48252245