fweimer

I didn't intend to make a statement about the programming effort required. I wanted to contrast it with corporate politics at CPU vendors, from which it is largely decoupled. Given the size of the task, it needs corporate funding, just not from x86 vendors. For example, we're fairly strongly incentivized to make valgrind support for any potential future x86-64-v4 transition because our development community really expects valgrind support as part of the core toolchain.

Do you have a public reference for the “all future Intel CPUs” aspect? The AVX10 change (no more 256-bit-only EVEX tier) is well-documented in compiler patches and whatnot, but what I haven't seen so far is an unambiguous commitment that starting with 2027 (say), all new CPU models will support AVX10.

For example, Intel stated this:

> Intel® Advanced Vector Extensions 10 (Intel® AVX10) introduces a modern vector Instruction Set Architecture (ISA) that will be supported across future Intel® processors.

They don't actually say “all”, and it is probably meant to apply to future microarchitectures anyway. Depending on various factors, Intel may end up designing new CPUs based on existing microarchitectures well into the 2030s.

SME (like AMX) are easier in this regard because there is a clear expectation that they are used in dedicated code blocks only, so run-time dispatch becomes feasible. In contrast, with auto-vectorization, general-purposes vector ISAs such as AVX-512 and SVE tend to get used all over the place.

Wide (especially unconditional) use of AVX-512 faces two main issues today: There's no public commitment from Intel to phase out CPUs that don't support it. And some emulation-adjacent tools (the prime example is valgrind) do not support it.

The latter could at least be solved with some community effort, although the relevant set of instructions is quite large. It's also not specific to AVX-512. Any comparable vector ISA faces the same challenge.

It's certainly possible to make different arrangements. Some European countries do that for local elections, for example.

Interesting. Is this a full system and not just a board? This is still not quite clear to me.

Hopefully, one of these systems gets produced in such large quantities that there's some pressure to add mainline Linux support.

Long before GenAI, I saw people using meme generators a lot in corporate presentations. I found that equally jarring. Replacing that with GenAI stuff is probably an improvement. At least it's reducing legal risk. It seems more understandable to a global audience, too.

I still don't have an explanation why people are doing this. Is it part of leadership training? Or do presenters have their own theory that including this stuff makes the presentation more memorable and enjoyable?

The article from this subthread contradicts this, though. Regarding recoverability of the situation, it says this:

> By now the airspeed indications had returned to normal, but the pilots had already set in motion a sequence of events which could not be undone.

That was before the prolonged stall warnings. But maybe this phrasing is just an embellishment?

But further down, the article is pretty clear that the training was inadequate for this type of unreliable airspeed indication:

> Although procedures for other phases of flight could be found in the manual, the training conditioned pilots to expect unreliable airspeed events during climb, to which they would respond with a steady nose-up pitch and high power setting that would ensure a shallow ascent. Such a response would be completely inappropriate in cruise.

What's the practical impact of choosing eMAG as the baseline CPU? Does it alter the weighing of the components in the final score?

The Arace purchase link for the Jupiter 2 kit says it's “in stock“, but it's actually for a discount coupon. The actual system can only pre-ordered. The Sipeed web site does not say anything about shipping timelines, and the products are not offered in their AliExpress store. I think the Sipeed boards are in preorder, too.

Of course, neither of these are machines. And the average bystander probably isn't used to importing computer parts directly from China, either.

I'll bring it up with some folks. It probably won't change much because the z13 transition has finished by now. It's still good to know because RISC-V is in the same boat regarding Highway support today: we need scalar fallback in Highway until we get RVA23 hardware deployed.

How does the average bystander buy an RVA23 machine today?

People reported challenges building V8 (whether upstream or the Node.js variant) on s390x with z13 support. I don't know if it was discussed on the porters mailing list because it's not public: https://groups.google.com/g/v8-s390-ports

Elsewhere, some people interpreted https://github.com/google/highway/issues/1895 as meaning that Highway code does not work on z13 at all.

Does it have fallback paths for everything, though? Scalar if necessary?

Projects that depend on Highway drop support for CPUs not listed in the Highway documentation, saying that they can't support these CPUs because they are incompatible with Highway: https://google.github.io/highway/en/master/README.html#curre...

Are these projects somehow mistaken?

Sethi-Ullman register allocation reorders subexpression evaluation to achieve efficient register allocation: https://dl.acm.org/doi/10.1145/321607.321620

With modern register allocators and larger register sets, code generation impact from following source evaluation is of course lower than it used to be. Some CPUs can even involve stack slots in register renaming: https://www.agner.org/forum/viewtopic.php?t=41

On the other hand, even modern Scheme leaves evaluation order undefined. It's not just a C issue.

As kbolino said, value objects are immutable. If you can get a reference to a value object in an array, the array has to be immutable.

If you cannot get a reference, it's possible to maintain mutability, but all access would involve copies. But it's not clear that this is what most people want because it's rather similar to what you can do with library-based solutions today (involving ByteBuffers and whatnot).

What do people in countries where chargeback is only possible for unauthorized transactions (which wouldn't apply in this case)?

That mentions 4.98.2-1+deb13u2, and its changelog has:

    exim4 (4.98.2-1+deb13u2) trixie-security; urgency=high
    
      * Backport fix for Use-After-Free in GnuTLS BDAT/CHUNKING code path.
        This is Exim-Security-2026-05-01.1, fixed upstream in 4.99.3.
    
     -- Andreas Metzler <ametzler@debian.org>  Mon, 11 May 2026 19:14:46 +0200

The ID is now in the CVE database, but it was missing from the upstream advisory, too: https://exim.org/static/doc/security/EXIM-Security-2026-05-0...

Not ideal, but at least we got the fix.

I doubt value classes will be helpful here because the array would have to be immutable. Context: https://openjdk.org/jeps/401

IR description here: https://c9x.me/git/qbe.git/tree/doc/il.txt

It looks like it doesn't have native support for identifying GC roots, so it's either conservative GC or explicit stack management. I would really like to see something that is (mostly) memory-safe and has string-as-bytes. It's a bit wild that people use Chez Scheme as a target IR for lack of better options.

This works:

    $ unbound-host -t A www.denic.de
    www.denic.de has address 81.91.170.12

This does not:

    $ unbound-host -D -t A www.denic.de
    www.denic.de has address 81.91.170.12
    validation failure <www.denic.de. A IN>: signature crypto failed from 194.246.96.1 for DS denic.de. while building chain of trust

So it does seem DNSSEC-related.

EDIT My explanation was wrong, this is not how keytags work. The published keytag data is consistent:

    de. 3600 IN DNSKEY 256 3 8 AwEAAfRLmzuIXVf7x5A0+U7hke0dS+GEJG0EdPhnOthCCLhy0t0WqLyoXJOhnfsTJ8vQX5fd9qOJc9gyr3SWJZkXAhPm3yPSC7FWWHF70WZTKKM9CekmKdqwMwq6ZCjMSUcecCuSF4Sbt1MRszV7rFmfGVklA1l5UzNbqwD+Dr5vfcLn ;{id = 33834 (zsk), size = 1024b}
    de. 3600 IN DNSKEY 257 3 8 AwEAAbWUSd/QN9Ae543xzdiacY6qbjwtZ21QfmdgxRdm4Z7bjjHWy249uqxCyjjjoS4LDoRDKmj7ElffMKvTWKE1qFKu0p8TUy4wyhX0M+m5FUjvQ3CiZMi+qY7GSHA5B+Zd73cidmnTeb3e8lso6jEsXg05/VZ2AyAqWF6FexEIFxIqiwwLk4UP0BwZ17Ur3q1qx9VSbPMyHgQ9d6nHUN1EEJsTDA2v0vKumsUyp74ZanRZ/bB/6IzpaaZyr5BLF5pSCNdbRNjVmkwYD0993vm79LueyOeibsoHRc16jhALrIJou1PFjdq7YQsYN0KtqRiJtaAfPprDBREpeamPuW/MnW0= ;{id = 26755 (ksk), size = 2048b}
    de. 3600 IN DNSKEY 256 3 8 AwEAAbTe1PJi8EgIudNGb+KRTxBL2aCu5rXkZ+aIe/TC88pwRdrXYeXODp1ihZWFop5CrbWRBLrk/YUPBE8aBc6oJP+58dSkdMLYkjSkmvdvYx+zXnRLWlF2bapxvZxshATJDfGjGbCiWxKEOoyRx3UhICtHC+cUSddsEvzfacUcBb6n ;{id = 32911 (zsk), size = 1024b}
    de. 3600 IN RRSIG DNSKEY 8 1 3600 20260519030655 20260505013655 26755 de. ke56T5GZt/X6zMBAF+ouyCTnAd7RY7MsnDcfa9jyyOwSouRXhvzim/V13JDTMBAnpAHxWQXoruXrAZ6A6re5N+8Pp2utVkAEKTWs0r4UOLNKoZ2+zMwNplKjNNnY5PJIbHfa5myyziLiIsi//qDIgQEACFk+pZcHXrRdqRoXPCL3UtfaXjk3+duDQdlPnYsJys5UshjVpkALSMChW7J0anzr0sG+f9ytstBneymMwFYOUC3NqbejbLPZsXGPZBQKPAoVJuV5q3znopbcqrDFfjI7bmX3QPYNvOaiT1ElBfi2piJVpDzMaMAmm2jCmvrf5VeTOBccMroh8sBtDPsaEg== ;{id = 26755}

The signature on the SOA record still does not verify:

    de. 86400 IN SOA f.nic.de. dns-operations.denic.de. 1778014672 7200 7200 3600000 7200
    de. 86400 IN RRSIG SOA 8 1 86400 20260519205754 20260505192754 33834 de. aZoiAJ+PaHUDVSHNXfV/R26ZK3GpFB7ek2Z46VnZdmPEDaTww+a7PkiQ98W83xohUunXYSvQCMeGYfUre5UT76eBKThdxW2a6ImX9/x/oEzQ9x/69Y/NSeTckOv9m3HCLBOug01op1koiHOIAVEvonOmXEHHqo1P4sR/fNbcVg4= ;{id = 33834}

There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507

It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.

If you just want to get a bug fixed that annoys you, it's of course out of scope.

If researchers want to showcase their ability (either individually or as an organization) to identify and address security vulnerabilities in complex multi-stakeholder environments, I very much expect them to figure this out. After all, it doesn't make much sense if a company, after commissioning a security review, needs to hire a different firm to handle the vendor interactions, so that identified issues are resolved with minimal impact to the business.

The libsanitizer library is imported from the LLVM sources into the GCC source tree. There are probably more examples of code sharing. Both projects are quite large.

You probably would prefer to use SUB with fault-checking to clear registers in general-purpose code, and only use XOR in early startup (and perhaps fault handlers), where error checking has to be suppressed. So both observations seem to align well?

Many of the conversions so far have been clearly faster. I don't think anything has been merged which shows a clear performance regression, at least not on CPUs with FMA support.

A lot of C++ programmers use C++ and garbage collection daily because their C++ compiler uses a tracing garbage collector.

https://gcc.gnu.org/onlinedocs/gccint/Type-Information.html

Limited controlled types probably come closest.

https://learn.adacore.com/courses/advanced-ada/parts/resourc...

I find this puzzling. It does not seem to allow to stack PRs on top of other people's PRs?

There is already an option to enable review comments on individual commits (see the API endpoint here: https://docs.github.com/en/rest/guides/working-with-comments...). Self-stacking PRs seem redundant.

While I don't disagree about (2), my experience suggests that LLMs are biased towards generating code for future maintenance by LLMs. Unless instructed otherwise, they avoid abstractions that reduce repetitive patterns and would help future human maintainers. The capitalist environment of LLMs seems to encourage such traits, too.

(Apart from that, I'm generally suspect of evolution-based arguments because they are often structurally identical to saying “God willed it, so it must true”.)