Svaka cast :)

"bottom of the page that has the two images and a summary of the work to build them."

A picture + explanation below it would carry more weight than this entire article tenfold.

Completely unrelated to the article claims.

movement triggered on key release is incredibly frustrating

Surprised nobody here linked https://andrewmccalip.com/space-datacenters.

Good stuff. Having fp8/fp4 would be great, too!

There are too many fp8/fp4 formats out there, many with different trade-offs. At least fp16 is standardized...

Yes, all of them would be great.

Hmm, you successfully nerd-sniped me. AFAIK there are at least:

- 8-bit floating point types: (S1)E4M3 (finite only, has no-negative-zero variant), (S1)E5M2 (has no-negative-zero variant), E8M0

- 6-bit floating point types: (S1)E2M3, (S1)E3M2

- 4-bit floating point types: (S1)E2M1, NF4

- Block floating point types: MXFP8 (E5M2/E4M3*32+E8M0), MXFP6 (E3M2/E2M3*32+E8M0), MXFP4 (E2M1*32+E8M0), NXFP [1]

[1] https://arxiv.org/pdf/2412.19821

Do you have anything to add on?

Nothing to add, I was simply saying that it would be useful to have an FP8 toy website out there covering all of these formats.

Been using this since my Galaxy S3 days and is currently installed on my Nothing 2A. The switch will be painful.

Had a go at this a while back: https://github.com/elvircrn/bcomp.

"C++ Modules have been greatly improved."

It would be nice to know what these great improvements actually are.

Later in the article, it mentions:

    Improved experimental support for C++23, including:

        std and std.compat modules (also supported for C++20).

From https://developers.redhat.com/articles/2025/04/24/new-c-feat...:

    The next major version of the GNU Compiler Collection (GCC), 15.1, is expected to be released in April or May 2025.

    GCC 15 greatly improved the modules code. For instance, module std is now supported (even in C++20 mode).

In GCC 14, C++ modules were unusable (incomplete, full of bugs, no std modules, etc). I haven't tried 15 yet but if that changed, then it definitely qualifies for a "great improvement".

Still no std modules but otherwise likely useable. modules are ready for early adoptors to use and start writing the books on what you should do. (Not how to do it, those books are mostly written though not in print. How hou should as is was imbort std a good idea or shoule containers and algorithms been split - or maybe something I haven't though of)

those were the greatest improvements of all time. all of them. :D

Surprised there's no mention of Redpanda here.

Having used both Kafka and Redpanda on several occasions, I'd pick Redpanda any day of the week without a second thought. Easier to setup, easier to maintain, a lot less finicky ans uses a fraction of the resources.

In what way is it materially easier to maintain and less finicky? I read a lot about this but I haven’t seen a concise bullet point list of why, which leads me to naturally distrust such claims. Ditto for the resources - Kafka is usually bottlenecked on disk/network, and whether it’s c++ or not doesn’t solve that

I've been using Redpanda for a few years now and here's what I've noticed.

Its a compiled binary - no JVM to manage. Java apps have always been a headache for me. Plus, no zookeeper - one less thing to break.

The biggest benefit I've seen is the performance. Redpanda just outperforms Apache Kakfa on similar hardware. Its also Kafka compliant in every way I've noticed, so all my favorite tools that interact with Kafka work the same with Redpanda.

Redpanda, like Kafka, writes to disk, so you'll always be limited by your hardware no matter what you use (but NVMe's are fast and affordable).

YMMV, but its been a good experience for me.

same

Redpanda isn't FOSS. Apache Kafka is.

Redpanda community edition operates under the BSL license - https://www.redpanda.com/blog/open-source

IANAL, but it looks pretty open source to me.