Dylan16807

Okay, so they were not the LCD manufacturer (or in control of production) despite paying the NRE. That wasn't clear before.

I have a 13 year old CPU that needs 2 cores to decode 4K AV1. It's not that bad.

Maybe not 4K at 60fps but that's not a lot of content.

We could subsidize smaller companies, perhaps.

The big US car companies don't need subsidies. They can afford plenty of development costs but they don't want to advance into the cheaper electric space, they want to extract as much value as they can by pushing car prices as high as possible.

The problem with keeping this level of protectionism is that it encourages them to keep doing the same thing. The companies don't lose out but everyone in the US that needs to buy a car loses out. We need something to motivate them, and dropping their protection from "infinite" to "medium" or "medium-high" might do the trick.

> You can always take a look at the UI of a PAN device

I do not have a PAN device.

> it is not "one URL"

I never implied it was.

> it is an entire application, it does not have distinct "pages"

> the concept of a web application

Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.

If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.

> I'm sorry but why would that bother you? Is my experience not valid any longer?

What? Huh? I have no idea what you think I meant but it's not what I meant.

I'm making a simple point: His backlog is not the reason he's talking about a ticket like this in 2026.

Either he took this ticket this year-ish, or he wrote this year-ish about something that happened long before. It is not the case that he wrote this post years and years ago and it was sitting in the backlog for that long.

My bet is they're not a graphic designer. There's no reason to expect or even want them to mentor on blog aesthetics.

He's telling stories from the past either way. The blog backlog isn't very important.

In an interview he said the backlog has varied from 3 to 18 months. Pretty negligible in terms of his career advancement. This isn't something he wrote ages ago.

The current directory in the UI is the directory open in whatever window you're clicking on.

That's a purer form of current directory than cmd, which has one per drive.

I don't think this has anything to do with what you responded to?

It's just the configuration pages. It's not the core of the product and doesn't need to be a perfect clone.

Is there a reason one URL at a time wouldn't work?

> Checking-the-address is overhead.

In the same way that initializing a variable is overhead. But if you assume the variable will have a 7 in it because that's what it compiled to one time, it's not the compiler's fault when it compiles it to not be 7.

Except it's actually less overhead than that. You don't need to do any verification at runtime if your compiler cooperates. If it works like other pointers then you can get the same "base + delta * i" opcodes but without undefined behavior.

I shouldn't have used the word "check". A better way to phrase it is "knowing for sure". You need to know for sure where the goto is, which means using && and keeping track of what it tells you in some way.

> If the coder knows there will be four return values and writes them one after the other, the return (or MOV) instructions are distanced the same. The goto hack should work.

You can't know that. Sometimes other things will be in there, and sometimes the padding won't be so consistent.

Do what you're supposed to do. && every label you might jump to. And then you can check if they're spaced evenly at compile time. If they are you can treat them as spaced evenly at runtime.

> Screaming about using Lua instead is just nonresponsive.

The point of those comments is not to hype Lua, it's to show what a JIT can do.

The idea is that a python JIT could be just as good as Lua for the parts that aren't suited to numba.

> Lua is absolutely not faster than numba, nor will it ever be (absent a numba-like translation layer) and repeatedly trying to argue so is very much missing the point.

Nobody is arguing that. People are agreeing that numba is fast, but they also want other non-number-crunching things to be fast. It's "yes, and". They're not missing the numba point, they're agreeing and you're missing the additional point they're responding with.

General support is a good default, but they were specifically talking about the aesthetics. If you want them to support the aesthetics regardless of whether they like the aesthetics, that's something but it's not 'maturity'.

How did everyone clone the first generation with monochrome LCDs though, if they weren't off the shelf?