The problem here is that computing three 3 NSEC3 records as you might need to return an NXDOMAIN was considered too expensive. It's just a choice to reduce their costs while increasing complexity for everyone else.
The situation in Europe is even more crazy. The US needs the bases in Europe to project power in the Middle East. If every country in Europe would ask the US to leave then the US would have a very serious issue projecting power around the world.
The US bases are also pretty expensive to set up. Lots of logistic support has to be in place to let those bases function. That require a lot of support from the host country. Normally, you would expect the US to be friendly with the host countries, but that seems lost on the current administration.
What is really wrong is that it is known that russia is fighting in Ukraine with drones designed in Iran. And we have seen how hard it is for US designed weapons to deal with those drones. To the point that a lot of development is happening in Ukraine to deal with this problem.
By attacking Iran, the US has shown the world that Ukraine is the weapon supplier of choice against future drone wars.
The Netherlands recognized the problems with the last-in-first-out system and requires that after a reorganization, the statistical distribution remains the same. How well that works is hard to say because the level of unemployment in The Netherlands has been quite low for many yours.
What I hear is that Switzerland is a bad example. Many people there struggle to make a living.
If DNSSEC is part of your security model, you want local validation. Not relying on third party resolver that you don't have a contract with.
Beyond that, DNS has the AD bit. If you need DNSSEC secure data (for example for the TLSA record), then when Cloudflare turns off DNSSEC validation, the AD bit will be clear and things will stop working.
I'd say that if the original Ada was introduced at the same time as Rust development started then people would pick Rust. Ada is also a product of its time would have to be modernized quite a bit.
Given how similar the syntax is of C, C++, Javascript, and Go, I think a language with the syntax of Ada would have a hard time.
One of the big differences between K&R C and C89 is the introduction of function prototypes. Strong typing was certainly considered positive for compiled languages. Of course C is a lot less strict than Ada.
If we compare the Rust subset that has similar functionality as C then there is not much difference. You get 'fn'. The is 'let' but Rust often leaves out the type, so 'int x = 42;' becomes 'let x = 42;' in Rust. Rust has 'mut' but C has 'const'. Rust introduced '=>' and removed '->' from object access and moved it to the return type of a function.
The C language has support for long variable names. Some early linkers didn't, but that's an implementation issue, people were certainly unhappy about that.
C++ started in the 80s. Objects were not controversial back then. The same applies to exceptions.
I don't have a metric for the size of a standard library. For its time, the C library in Unix system had a large number of functions. Later that was split in a C standard part and a POSIX part. But that was for practical reasons. Lot's of non-Unix systems have trouble implementing fork().
I have no clue what you mean with annotations. If you mean non-function annotations along with code, then generally Rust programs don't have those.
The article gives another reason "A second answer is aesthetic. Ada's syntax is verbose in a way that programmers with a background in C find unpleasant. if X then Y; end if; instead of if (x) { y; }. procedure Sort (A : in out Array_Type) instead of void sort(int* a)."
I think this should not be underestimated. There is a huge number of small C compilers. People write their own C compiler because they want to have one.
That doesn't happen we Ada. Very few people liked Ada enough that they would write a compiler for a subset of the language. For example, an Ada subset similar to the feature set of Modula-2 should be quite doable with a modest effort.
I agree. There are quite a few places where they author claims that Ada had a concept first and some language got the same concept later, but the two concepts are different enough that examples would help to show where they are similar.
Especially if we assume that most readers are not Ada experts and that enough languages are mentioned that most people don't know the details of all of them.
The 286 worked perfectly fine. If you take a 16-bit unix and you run it on a 286 with enough memory then it runs fine.
Where it went wrong is in two areas: 1) as far as I know the 286 does not correct restart all instruction if they reference a segment that is not present. So swapping doesn't really work as well as people would like.
The big problem however was that in the PC market, 808[68] applications had access to all (at most 640 KB) memory. Compilers (including C compilers) had "far" pointers, etc. that would allow programs to use more than 64 KB memory. There was no easy way to do this in 286 protected mode. Also because a lot of programs where essentially written for CP/M. Microsoft and IBM started working on OS/2 but progress was slow enough that soon the 386 became available.
The 386 of course had the complete 286 architecture, which was also extended to 32-bit. Even when flat memory is used through paging, segments have to be configured.
I think from the price people also expect a similar performance boost as going from 386 to 486. What made Pentium also confusing is that during this time Intel introduced PCI.
From a 486 with VLB to a Pentium with PCI everything became a lot nicer.
We can assume that organizations like NSA have collected a huge amount of traffic that is protected by RSA or EC. So they well have plenty of use for those quantum computers.
It is the paradox of PQC: from a classical security point of view PQC cannot be trusted (except for hash-based algorithms which are not very practical). So to get something we can trust we need hybrid. However, the premise for introducing PQC in the first place is that quantum computers can break classical public key crypto, so hybrid doesn't provide any benefit over pure PQC.
Yes, the sensible thing to do is hybrid. But that does assume that either PQC cannot be broken by classical computers or that quantum computers will be rare or expensive enough that they don't break your classical public key crypto.
The thing is, producing the right isotopes of uranium is mostly a linear process. It goes faster as you scale up of course, but each day a reactor produces a given amount. If you double the number of reactors you produce twice as much, etc.
There is no such equivalent for qubits or error correction. You can't say, we produce this much extra error correction per day so we will hit the target then and then.
There is also something weird in the graph in https://bas.westerbaan.name/notes/2026/04/02/factoring.html. That graph suggests that even with the best error correction in the graph, it is impossible to factor RSA-4 with less then 10^4 qubits. Which seems very odd. At the same time, Scott Aaronson wrote: "you actually can now factor 6- or 7-digit numbers with a QC". Which in the graph suggests that error rate must be very low already or quantum computers with an insane number of qubits exist.
What surprises me is how non-linear this argument is. For a classical attack on, for example RSA, it is very easy to a factor an 8-bit composite. It is a bit harder to factor a 64-bit composite. For a 256-bit composite you need some tricky math, etc. And people did all of that. People didn't start out speculating that you can factor a 1024-bit composite and then one day out of the blue somebody did it.
The weird thing we have right now is that quantum computers are absolutely hopeless doing anything with RSA and as far as I know, nobody even tried EC. And that state of the art has not moved much in the last decade.
And then suddenly, in a few years there will be a quantum computer that can break all of the classical public key crypto that we have.
This kind of stuff might happen in a completely new field. But people have been working on quantum computers for quite a while now.
If this is easy enough that in a few years you can have a quantum computer that can break everything then people should be able to build something in a lab that breaks RSA 256. I'd like to see that before jumping to conclusions on how well this works.
If we are looking at the RSA factoring challenge (https://en.wikipedia.org/wiki/RSA_Factoring_Challenge) then 768 bits is done. Breaking RSA 1024 is assumed to be possible but has not been demonstrated in public.
So maybe quantum computers should first complete some of these RSA challenges with less compute resources than done classically before considering any claims about qubits needs as practical.
All of this in the context of DNSSEC or other system using signatures. For encryption the story is different.
That's for offline signing. For online signing you can do different things.
But the point is, and that's what this discussion is about is that DNSSEC can evolve. It can get extra features to make online signing more efficient.
The problem is that getting all validating recursive resolvers and other validators to update takes a very long time, on the order of decades.
So we got this problem because people started using this feature without verifying that validator support had spread wide enough.