RE: https://mastodon.social/@blogdiva/117422866823337275

And the progenitor of all of this: (careful I do not summon a troll army) that gate thing to do with people who play games. The test run.

All of this cost Russia *peanuts*. They were about to go bankrupt, and end up with Putin being weakened to the point where he might go, due to sanctions. Then they started the social media ops, buying politicians for a rounding error away from zero, and got close to infinity returns.

Ultimately this is why you can’t allow power or money concentration.

Anyway, this is definitely a nuance that has been totally lost to the slop-brained folks building out data centers. Or rather, power is not a constraint to them at all, because they feel no remorse at cranking up performance at ever-decreasing efficiency and ever-increasing number of gas turbines.

It's a shame, because otherwise we would at some point have seen data centers *shrink* in their power usage, over the course of years.

Why is making your service faster actually...er... slower? Because modern data centers are *very dense* to the extent that they need to balance power allocations. You're likely cramming as many instances into a server as possible, up to its resource limits—often the power limit. So that 20% increase in power loses 20% of the instances you can fit, and overall it's now 10% lower rate of task completion.

So guess what happens when you make the server more efficient? Yep, faster.

Little not-very-secret thing I learned from my time designing servers:

Efficiency is performance.

Huge ramifications, but not really a secret, because this is exactly why things like AWS Graviton exist. And yet, it still seems to be a really alien, contrarian thing to say, in this field. Especially in today's "AI" craze, which goes 100% against this.

So, let's say you improve your service's performance by 10% with a neat trick. But it increases power by 20%. This made your service *SLOWER*.

It really is every 5-10 years this keeps happening: https://en.wikipedia.org/wiki/DRAM_industry_price_fixing

They come up with some deniable excuse why they're unable to fulfill demand, and depending on how strong global governments are at the time, they either get away with it; or pay huge fines, have their executives jailed, and then promoted to President of Samsung Europe. (Yes that is real)

Here we are with another round, and seriously, please think twice about coming to their defense.

While it is monumentally expensive to build a fab, this is very much an overstatement for a number of reasons:

* The "expensive" part is mostly the R&D and large scale tuning/yield of a whole new process node. But this doesn't apply.
* The timescale involved is likewise for a whole new node and/or building in a new territory. Also doesn't apply.
* They would be well on their way to completion by now if they started back in 2024.
* Even DDR4 would be relieve some demand.

Any time you ask, "Why aren't DDR manufacturers at least half way to building extra capacity already?" some reply-guy pops up with "It's not simple building a DDR5 fab". And that is the manufacturers' scheme working perfectly.

It strikes me that the reason I'm running into all these basic quality of life (and C++ support) issues, is related to my previous comment about how all the C-based RTOS out there have _suspiciously similar code_. They're all written by the same people, or cross-pollinated by people who moved between places.

The last few RTOS I've worked on were internal, and I (eventually) won battles to make this shit work.

I haven't done that here, and I'm not going to invest in a slop repository.

It is apparently a deliberate design choice in Zephyr that C++ static constructors are called _after_ kernel and driver init, so you can essentially only safely use C++ in "application code".

I can say with 100% certainty this is the wrong choice.

About ready to give up on this shit.

Well, that was a whole bunch of debug just to discover the Zephyr calls driver init functions before it calls C++ static constructors. Infinite sigh.

It's no accident that every "grass roots" open source project got captured by corporations. I very much blame the loud folks who pushed for as open licensing as possible, and encouraging corporate membership, because the code would do the talking, or other such nonsense. Of course everything of value was taken.

Glimmer of hope is that at least some small fraction of engineers is now savvy to this.

No, I don't think I'm ever going to get over amazon having "stewardship" of FreeRTOS. It's an existential risk in any case.

Every attempt at making one of these (SGX, various AMD/ARM equivalents) has holes, because you're attempting to share state at the _microarchitecture_ level. Even if you don't share state (more expensive), there's still a mountain of complexity involved in having the remote (server) side attest to being secure, and a giant leap of faith for the user to _trust_ that it is doing what's advertised.

These designs exist because you're being made to _rent_ compute.

Everyone keeps reinventing "enclaved VPS", where you run a service on behalf of a user on a server, such that the internals and data in the service are fully opaque to the rest of the server—including higher privilege (root/kernel/etc).

I've never been sufficiently convinced these are actually _good_ to include in a design, especially if it's 100% vital to its success. They're always leaky. This isn't "just spawn a million HSM VMs" because an HSM does limited things. This never works.

You should treat the suggestion of an Orbital Data Center the same as someone suggesting the best place for a gaming PC is the inside of a thermos flask.

RE: https://mastodon.world/@davidnjoku/117326286531341193

Something I found really jarring in my recent trip to UK/EU. So many smokers. Everywhere. Especially vaping. (Compared to SF)

Guess who just got a street cleaning ticket because they failed the visual illusion check. Protest filed... sigh.

I'm gonna have to scope out the cc1/cc2 lines aren't I. This doesn't bode well.

Mood: Trying to get the first triangle out of the USB-PD chip (fusb302).

Noob tip nobody warns you about but is obvious when you think about it: Never push more than half a meter (foot or two) of ethernet cable into a wall cavity, without pulling the slack out the other end. It will end up forming loops, and when you pull the other end, it'll end up knotted.

Not a real knot, but the friction, thickness, and fragility of ethernet cables will make it impossible to simply pull the knot out.