Lisps aren’t necessarily functional, but don’t need semicolons either.

The syntax of languages like Lisp and Forth are so fundamentally different that they don't need an explicit statement separator. You don't have to think about many other things either, or I should say you don't have to think about them in the same way. Consider how much simpler the order of operations is in those languages.

Lisp has explicit "statement" terminators (just aren't semicolons)

All the lisps I know of have only expressions (no statements).

It seems like PC makers just don't want to invest in quality trackpads.

It's criminal that my now almost decade-old Pixelbook still has a better trackpad than 99% of PCs (including ones that cost way more money).

SIMD workloads on CPU tend to be bursty. If your workload is all SIMD with few other instructions or branches, it's almost certainly going to be faster on a GPU or SME co-processor.

If there's space between the SIMD instructions, then double-pumping or even quad-pumping isn't very expensive (and with 6 SIMD ports, it might even be basically free).

This core was released in the MediaTek 9400 in October 2024 some 16 months ago.

The successor of x925 is C1 Ultra and even that was released 6 months ago in September 2025 with the MediaTek 9500 and GeekerWan even has a phone review they did with that chip last year.

Chips and Cheese covers Apple products in a LOT of their posts.

The real reason is probably because they are supported by patrons and can only get new equipment to review when people donate (either money or sometimes the hardware itself).

If you like what they do (as pretty much the last in-depth hardware reviewers), consider supporting them.

The biggest problem is a failure of trust. I won't donate to the Mozilla foundation because I have zero faith in them using that money wisely.

Wider SIMD is a solution in search of a problem in most cases.

If your code can go wide and has few branches (uses SIMD basically every cycle), either a GPU or matrix co-processor will handily beat the performance of several CPU cores all running together.

If your code can go wide, but is branchy (uses bursts of SIMD between branches), wider becomes even less worth it. If it takes 4 cycles to put through a 256-bit SIMD instruction and you have some branches between the next one, using a 128-bit SIMD with 2 instructions will either have them execute in parallel at the same 4 cycles or even in the worst case, they will pipeline to 5 cycles (that's just a single instruction bubble in the FPU pipeline).

You can increase this differential by going to a 512-bit pipeline, but if it's just occasional 512-bit, you can still match with 4 SIMD units (The latest couple of ARM cores have 6 SIMD units) and while pipelining out from 4 to 7 cycles means you need at least 3-cycle bubbles to break even, this still doesn't seem too unusual.

The one area where this seems to be potentially untrue is simulations working with loads of f64 numbers which can consistently achieve high density with code just branchy enough to make GPUs be inefficient. Most of these workloads are running on supercomputers though and the ARM competitor here is the Fujitsu A64FX which does have 512-bit SVE.

It's also worth noting that even modern x86 chips (by both AMD and Intel) seem to throttle under heavy 512-bit multi-core workloads. Reducing the clockspeed in turn reduces the integer performance which may make applications slower in some cases

All of this is why ARM/Qualcomm/Apple's chips with 128-bit SIMD and a couple AMX/SME units are very competitive in most workloads even though they seem significantly worse on paper.

Video encoding and image compression is a huge use case, and not at all uncommon, so much so that a lot of hardware has dedicated hardware for it. Of course, offloading the SIMD instructions to dedicated hardware accelerators does reduce usage of SIMD instructions, but any time a specific CODEC or algorithm isn't accelerated, then the SIMD instructions are absolutely necessary.

Emulators also use them a lot, often in unintended ways, because they are very flexible. This is partially because the emulator itself can use the flexibility to optimize emulation, but also because hand optimizing with SIMD instruction can significantly improve performance of any application, which is necessary for the low-performance processors common in videogame consoles.

GPL for open source and commercial license for the enterprise lawyers.

Unfortunately, a majority seems to hate GPL these days even though it prevents most of the worst corporate behaviors.

Minio was AGPL, which was a perfectly fine tradeoff IMO. But apparently that wasn't good enough.

AGPL doesn't help when you want to kill your free offering to move people onto the paid tier. But quite frankly, that isn't a problem GPL is meant to solve.

I'm pretty sure someone already compiled Linux to asm.js a few years ago. As asm.js is/was a subset of JS, you could say it's already been done. In theory, you could continue work from there in JS.

https://medium.com/@retrage/lkl-js-running-linux-kernel-on-j...

Everyone was trying to pretend the bottom of the market back in 2007 right up until they couldn't keep up the farce and everything collapsed.

I believe that's what we have today. The economic indicators are all worse than they were in 2008. Our economy is Wile E Coyote running at full speed in midair until he realizes the truth then falls.

The fed was taking action by increasing rates up until the housing market collapsed, so at least some were taking the issues seriously.

I don't have the full context of what the thinking was back then since I was in highschool.