I'm working on a voxel space renderer homebrew for the PlayStation. I only have so many cycles to spend on rendering before it becomes a slideshow, so I count them in my hot rendering loop and parallelize work as much stuff as I can, even across memory load stalls from main RAM.

I've worked on a basic network accessory card with a STM32 MCU that is extremely overkill for what it needs to do. We haven't bothered making any performance or memory optimizations whatsoever, writing plain C++ almost as if we were on server-class hardware because we had such egregious margins.

The first question to ask is not whether something can leverage SIMD, it's whether the performance requirements are met or not (although it's far too easy to not care when it's not your hardware that's struggling...).

Turns out there are tons of stuff that sip power (set-up boxes, Ethernet switches, NAS...) that can either be powered directly by Power-over-Ethernet or through a splitter (DC-DC converter). That can be handled by a PoE Ethernet switch, which itself is usually powered at 54VDC, so it's also an excuse to run a homelab on 48VDC and get rid of tons of power supplies.

However, DC isn't well suited for the entire home for several reasons, mostly due to cheapness and historical reasons. For example, AC breakers are dirt cheap because arcs naturally extinguish when current crosses zero volts, whereas DC doesn't.

There are areas where DC is used. I work on telecommunication gear where nearly everything is -48VDC, but the beefy copper busbars needed to push large amounts of power through them would make a homeowner cry at the expense. Higher voltage is possible to compensate, but you enter not-safe-for-touch territory and I'm not knowledgeable about that.

I'm no Zig expert, but if you want endian-dependent semantics I'd assume either @ptrCast or a packed union would do the job.

I've had deep technical exchanges with smart people all across the world I would've never met otherwise. I've seen people using my tool for completely insane projects successfully. I've even had a data scientist from India who was inspired and motivated by my story of presenting at ACM 2025 as a hobbyist to put his work out there.

Interacting with all these people has broadened my horizons - literally going halfway across the globe in one instance. All of that happened despite me being an introvert, who hates initiating any form of social interactions with people and sounds like a raving lunatic on my blog.

Maybe I should be the one to send out more emails...

(hint: I showcase Mad Max-driven software development on it)

In theory, it's really not suited for this because (at least back then) this was designed for computers with:

- relatively large amounts of RAM (uncompressed color+heightmap data takes a lot of space),

- fast CPUs with data caches (it's a 2D trapezoidal walk of a top-down projected fustrum with plenty of additions, multiplications and divisions),

- memory-mapped linear framebuffers (for software rendering).

The PlayStation has none of these things: only 2 MiB of main RAM; an in-order scalar 33 MHz MIPS III processor without a FPU or a data cache, where any CPU load from main RAM stalls the pipeline for 5 cycles, multiplications have a 6 to 13 cycles latency and divisions have a 36 cycles latency; and the only way to touch VRAM is to send commands to the 2D GPU.

What it does have is 4 KiB of I-cache (direct-mapped), 1 KiB of scratchpad with no wait states and a fixed-point GTE coprocessor which is mostly geared towards projecting 3D points onto a 2D screen and not general matrix/vector processing. Meaning that if I get my hot loop within 1024 instructions (and no function calls), fit my working set+stack within 1 KiB and can pipeline the GTE for transformations and the CPU for map scanning/GPU submissions, it might just work.

So far I'm getting decent framerates (like 10-15 FPS at 256x240) with just software projection and GPU line rendering. Right now I'm wrestling with the GTE and various ways to trick it into transforming more points than it's supposed to be able to do, by looking at the fixed-hardware math equations for the various instructions and trying to fit my equations into them (doing stuff like putting relative altitude into X/Y vector registers instead of coordinates and massaging the rest of the values to get screen Y coordinates out of it).

Kind of a hardcore topic to pick for my first homebrew ever, but I craved a simpler, low-level optimization challenge as a pipe cleaner, after working on ghidra-delinker-extension for so long.

Us rolling the dice whenever we have a major political crisis is a meme at this point, for better or for worse we're just not the kind of people to keep the same constitution around for 250 years.

If anything, the longevity of the Fifth Republic is starting to become unusual (only the Third Republic and the Ancien Régime have lasted longer). Maybe we're overdue to flip the table again as per tradition.

Incidentally, that lineage has finally come to an end as TI has released the TI-84 Evo-T, which uses an ARM Cortex-M core and a firmware apparently rewritten from the ground up.

It's refreshing to dust up trigonometry and good old low-level optimization tricks. When the scratchbuffer has 1 KiB and the stack can only use a fraction of that, it makes me realize how spoiled I'm at work with the microcontrollers we have, with threads being allocated 8 KiB of stack and backtraces with over 50 functions of C++ templates on it.

I'll push back on that point.

The FCAS program was originally conceived as a French-German joint political initiative by Macron and Merkel. The NGF plane within it has been dead in the water for years because Airbus and Dassault can't work out their disagreements. It's a conflict between two industrial companies that's blocking forward progress, with the Airbus and Dassault CEOs duking it out across press releases and shareholder meetings.

If Dassault was a French state puppet, Macron would've strong-armed Dassault into working with Airbus on this €100 billion project by now. Yet, the French President seems to know better than to try and do that. One does not get to be basically the only major private independent defense company in a famously nationalized French defense industry during the Cold War without managing to hold the French state at arm's length, especially during the nationalization years of Mitterand's presidency.

Though your concerns about ownership of the Dutch defense industry are certainly valid, I don't see how the European defense industry could have completely avoided consolidation after the end of the Cold War, given the budget cuts to defense. The Americans went much further on that front and nowadays the lack of internal competition is causing them all kinds of problems for them.

The commentary section starts with "The retail PlayStation BIOS code is a constellation of bugs and bad design." and it gets worse after that. There are hidden gems inside the source code comments of that simili-reconstruction.

GIAT was privatized, then renamed to Nexter, then merged with German KMW to form European KNDS and now it's about to do an IPO.

All of the French aerospace industry (including missiles) bar Dassault and Thales is inside Airbus.

Arquus was bought by Belgian John Cockerill.

I could probably cite more if I dug deeper, but while we still have French defense companies like Dassault, Naval Group and Thales, a fair amount of our defense industry is no longer exclusively French owned.

And if the French government or owner starts getting uppity, you could always take a page from the Swedes and how they Kockums the shit out of ThyssenKrupp.

For the non-government/private business however, it is indeed a matter of privacy. France rolled out a while ago the requirement to establish the user's age when accessing porn sites. I refuse to do that.