I thought x64 was better for perf per watt just because perf is so much better

I’d go a step further and say get a mini pc unless you need gpio

With a miniPC you can always use a Raspberry Pico (or Arduino that supports Device Mode) for your GPIOs.

China is coming online :(

Why the sad smily? I'm pretty happy Chinese tech is stepping up to break the current memory cartel.

I keep making the same mistake. How do you make intermediary planes?

Normally, I select a face and add a datum plane. It's button is in the toolbar with a the datum point and datum line buttons in light blue iirc.

That said, since v1.0, I've had far fewer instances of being affected, and have started doing some direct-on-face features (usually sketches) again.

This is described in the wiki page, at the section solution.

Isn’t that less efficient in power and can have different color?

It has to be an SMPSU in constant current mode, not a linear power supply. I'm sure it does still affect the colour, though.

It’s because building 500 units would be a non starter for many of them

Some of devices automatically lock once used on a carrier network

I don’t believe that’s true. Locking is entirely something done by carriers for promotionally-priced phones attached to active phone plans.

Can you point me to anywhere documenting your claim? That would definitely be a new low if true, but I really don’t think that’s how it works.

Sadly it is true. It’s called Flex Lock or US Carrier Flex Policy: https://www.usmobile.com/blog/what-is-flex-lock/

The gist is that it allows a third-party seller to stock a bunch of identical, not-yet-locked phones and offer a choice of carrier plans. The phone binds to whichever carrier the user first activated on.

So if you’re buying a phone, verify it is not one of these units.

If you buy them unattached? First time I hear of that, do you have an example or source?

Thats some lawsuit level bullshit.

Not in EU

No they don't

>If the goal is consistency, then wall-clock isn't the simple way to do it.

It’s simpler than doing a limit on number of states, and for some applications consistency isn’t super important.

Doing a time limit also enforces bot moving in a reasonable time. It puts a nice limit to set up a compromise between speed and difficulty.

Doing state limit with a time limit might be better way to do it, but is harder.

> It’s simpler than doing a limit on number of states

According to who?

A counter that you ++ each move sounds a lot easier to me than throwing off a separate thread/callback to handle a timer.

> Doing a time limit also enforces bot moving in a reasonable time.

It's designed for specific hardware, and will never have to run on anything significantly slower, but might have to run on things significantly faster. It doesn't need a time cutoff that would only matter in weird circumstances and make it do a weirdly bad move. It needs to be ready for the future.

> It puts a nice limit to set up a compromise between speed and difficulty.

Both methods have that compromise, but using time is way more volatile.

Why?

Does X even support hdr yet? When I looked last time the answer was none