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.
Yeah, the US is trying to peddle massive missiles that individually cost as much as the entire defense budget for some small nations, as well as large boats that are just giant sitting ducks. Ukraine is showing that cheap drones are the best defensive asset to have and are currently difficult to counter. China is always flaunting their drone shows, and there's no doubt they've got a defensive/offensive fleet of them ready to go and the US seems to be making zero efforts at making any sort of defense against them. There's been plenty of time to learn from Ukraine and the US military industrial complex is just twiddling their thumbs and sucking up money for more of last century's tech
Because the total increase of the cake can mostly be transferred to those that receive the subsidies. It's not that hard to understand: if you redistribute 10% of total wealth from the top quartile to the bottom quartile for 1% in additional total growth, then even if that additional growth went completely to the top quartile, it would be a net -9% of total wealth for them. I don't say that's a bad thing per se. But it doesn't help to willfully ignore that fact.
Edit: I just now got the part "If the increase in cake size is bigger than the subsidies" – that's a ridiculous assumption. EU total growth in 2025 was 1.5% or 295 billion USD. From 2021-2027, the EU budget committed roughly 370bn € each for Agriculture subsidies and for Cohesion Policies, totaling 720bn € over 7 years; 2025 has seen ~130bn USD from those two buckets alone. Germany alone has paid another 60bn in subsidies the same year. Oh, and there has been a total of 417bn USD in energy subsidies in europe in 2023 (most recent data available). Even if we could attribute all total growth to subsidies alone, we'd have a factor below 0.5 – and that doesn't include any growth through private investmen, PPP, or any kind of increase of regular public spending.
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.
The poverty line is derived from the guidelines of the Conference for Social Welfare (SKOS). In 2024, it was on average CHF 2388 per month for a single person and CHF 4159 for two adults with two children.
I live in Zurich (by far the most expensive city) and while 2388 (or 4159) would be tight (depending on housing) it would still afford you a fairly comfortable life with access to top quality healthcare and public transport. Life quality wise one could argue that poverty in CH is a better option than a middle income in a lot of European countries.
Outside of Zurich rentals are not even that bad. You can easily get a nice apartment for 1500.- or even less. If one is struggling financially, rents are lower e.g. in Aarau district, starting from around 1000 and you can commute from there. Spending 1000 when the median salary is around 7000 is really not that bad. Low inflation in Switzerland meant other European locations are now at the swiss level or sometimes even above.
Yeah Switzerland has rather few poor people and very strong middle class. And poor ain't some US version of homeless/trailer park living, just lower income, less fancy clothes, shopping in cheaper supermarkets, less/no vacations abroad.
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.
Am I the only one who thinks that the AD bit is about as useful as the RFC 3514 evil bit?
We have this elaborate, complex, and extremely fragile cryptographic system behind DNSSEC and we distill it down to one single bit that we carry over unauthenticated links. Why?
At least WebPKI answers the right question: should I trust a particular claim to represent host.domain at the time in the following range? (Of course it defers determining the current time to some unspecified other mechanism.) DNSSEC tries to do everything and cannot survive an upstream error even within the downstream validity window. And yet, despite the fact that most of the spec leans heavily toward failing secure, the actual communication of validation status is entirely unprotected.
I can answer that! Because when DNSSEC was designed, it was believed that serverside compute could not keep up with per-request cryptography. DNSSEC contorts itself in several ways to maintain affordances for offline cryptography, which has been retconned into a security mechanism but was in reality just a bunch of non-cryptography-engineers making a terrible prediction about the feasability of cryptography.
(Source: I'm one of the few weirdos on Earth who has read the mailing lists all the way back to when DNSSEC was a TIS project).
The intention is clearly that the client is a minimal implementation that will only forward a request to a resolver it trusts. The fact that Cloudflare and Google have convinced us all to use Cloudflare's and Google's resolvers is the problem.
DNSSEC and WebPKI both rely on chains of trust. If the problem was that .de's keys expired, you'd have the same problem when Let's Encrypt's keys expired.
> If the problem was that .de's keys expired, you'd have the same problem when Let's Encrypt's keys expired.
Even this incident proves that’s not the case.
If LetsEncrypt has a temporary availability issue, my users don’t notice unless it spans longer than my need to renew a cert.
If LetsEncrypt has a CA cert expire, I can get a cert from another provider.
If DENIC’s DNSSEC records break, either due to an operational error or an expiry issue, my .de site becomes inaccessible and my users see a DNS lookup failure. My only option is to hope resolvers do what Cloudflare did, or move my site to a new TLD and just pray that TLD never has the same problem.
The WebPKI works end-to-end all the way to use devices; DNSSEC build an explicit client/server trust model into that. The former is obviously superior to the latter.
Yes, it's also quite damaging to DNSSEC's trust model that the world has transitioned to centralized resolver caches. But the fundamental problem we're talking about with the AD bit wouldn't vanish if 8.8.8.8 and 1.1.1.1 did too; instead, users would be even more reliant on ISP nameservers, which are literally the least trustworthy pieces of infrastructure on the entire Internet.
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.
You're right but it's broader than "C folks like terseness."
C is famously hard to read. Before Perl we used to joke that C is a write-only language: you can't understand what your own code means just weeks later.
Combine this with its lack of bounds checking, pointer arithmetic, and other dangerous features, and the result is a language that's macho for geeks: it's hard, it's dangerous, but it's small and it's fast.
It's a motorcycle for nerds. Ada is a tank.
Nerds get to establish dominance over lesser nerds by doing hard stuff in hard languages and making it fast. This bestows nerd street cred: geek cred.
Ada was used by contractors who needed stuff to work and money was no object.
C was used by hackers to do cool hacker stuff that was perceived to be fast and low level.
It's not low level: machine architectures haven't resembled the C abstractions since the 1970s.
I think this was a genuine generational change. I am pretty sure Rust would never have become popular 20 years earlier because the priorities back then were so different (that was the era of languages like Ruby and Pearl where conciseness and low verbosity were the most valued aspects).
When Ada came out a lot of programmers couldn't even touch type. You're right there's a generational change and a lot of of the Ada stuff won:
* strong typing
* lots of annotations
* keywords over syntax, support for long variable and token names
* object focus (Ada 83 had some limitations on inheritance so it wasn't OO strictly speaking)
* exceptions
* large standard library
These things were controversial in the 1980s. They are not today.
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.
Exceptions were controversial into the 90s which is why Java went down that whole checked-exceptions rabbit hole. The argument was that an exception was essentially a GOTO (or even COME FROM) which broke functional abstraction.
The Ariane 5 crash involved an exception and that was the central "Ada is unsafe actually" argument from C people.
In fact "exceptions are bad" is so baked into a lot of C people's brains that they left them out of Go!
Short variable names were a technical limitation in early languages but style guides were still arguing against long, descriptive variable names in languages like C into the 2000s.
Objects were also likewise controversial and you can see that in the design of Ada 83 where they were both inspired by OO languages like smalltalk but also hesitant to adopt stuff like inheritance. Inheritance was again, seen as a way to break encapsulation (it kinda is) but also a lot of object implementations were slow and memory inefficient in the 80s. Smalltalk was pretty much the reason why the Apple Lisa failed as a product.
OO became a massive buzzword in the 90s but by that time it had already been around for quite a long time.
By annotations I mean mostly type annotations, of course there's also aspect annotations and other stuff ex: Ada SPARK.
As Gen-X, in the Usenet flamewars, the C and C++ folks used to call Pascal/Modula-2/Ada advocates as straightjacket programming, whereas they would be called cowboy programmers.
Ironically the author of Fil-C calls classical C, YOLO-C. :)
not just the priorities, the overall skill and education of programmers.
in the 1980/1990's i was a dumb kid. problems of large systems were not in my mind. having to type begin/end instead of {} was, i thought, a valid complaint.
with experience, education, and hindsight, most of the advantages of the ada language were not understood by the masses. if ada came out today, it would have taken off just like rust.
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.
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.
The 286 worked perfectly fine as an improved 8086, for running MS-DOS, an OS designed for 8088/8086, not for 286.
Nobody has ever used the 286 "protected mode" in the way intended by its designers.
The managers of "extended memory", like HIMEM.SYS, used briefly the "protected mode", but only to be able to access memory above 1 MB.
There were operating systems intended for 286, like XENIX and OS/2 1.x, but even those used only a small subset of the features of the 286 "protected mode". Moreover, only a negligible fraction of the 286 computers have been used with OS/2 1.x or XENIX, in comparison with those using MS-DOS/DR-DOS.
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.
I don't think you said (or cited) what you think you said.
Leaving aside that you actually didn't cite a lattice attack paper, the "dual attack" on lattice cryptography is older than P-256 was when Curve25519 was adopted to replace it. It's a model attack, going all the way back to Regev. It is to MLKEM what algebraic attacks were (are?) to AES.
You know you're in trouble in these discussions when someone inevitably cites SIDH. SIDH has absolutely nothing to do with lattices; in fact, it has basically nothing to do with any other form of cryptography. It was a wildly novel approach that attracted lots of attention because it took a form that was pin-compatible with existing asymmetric encryption (unlike MLKEM, which provides only a KEM).
People who bring up SIDH in lattice discussions are counting on non-cryptography readers not to know that lattice cryptography is quite old and extremely well studied; it was a competitor to elliptic curves for the successor to RSA.
With that established: what exactly is the point you think those three links make in this discussion? What did you glean by reading those three papers?
He's obviously not saying that you can "trust blindly" any PQ algorithm out there, just that there are some that have appeared robust over many years of analysis.
He is assessing that the risk of seeing a quantum computer break dlog cryptography is stronger than the risk of having post quantum assumptions broken, in particular for lattices.
One can always debate but we have seen more post quantum assumptions break during the last 15 years than we have seen concrete progress in practical quantum factorisation (I'm not talking about the theory).
It's purely a matter of _potential_ issues. The research on lattice-based crypto is still young compared to EC/RSA. Side channels, hardware bugs, unexpected research breakthroughs all can happen.
And there are no downsides to adding regular classical encryption. The resulting secret will be at least as secure as the _most_ secure algorithm.
The overhead of additional signatures and keys is also not that large compared to regular ML-KEM secrets.
No it's not. This is the wrong argument. It's telling how many people trying to make a big stink out of non-hybrid PQC don't even get what the real argument is.
Perhaps you would care to enlighten us ignorant plebs rather than taunting us?
My understanding (obviously as a non expert) matches what cyberax wrote above. Is it not common wisdom that the pursuit of new and exciting crypto is an exercise filled with landmines? By that logic rushing to switch to the new shiny would appear to be extremely unwise.
I appreciate the points made in the article that the PQ algorithms aren't as new as they once were and that if you accept this new imminent deadline then ironing out the specification details for hybrid schemes might present the bigger downside between the two options.
I mean TBH I don't really get it. It seems like we (as a society or species or whatever) ought to be able to trivially toss a standard out the door that's just two other standards glued together. Do we really need a combinatoric explosion here? Shouldn't 1 (or maybe 2) concrete algorithm pairings be enough? But if the evidence at this point is to the contrary of our ability to do that then I get it. Sometimes our systems just aren't all that functional and we have to make the best of it.
"taunt" in the sense that you dangle some knowledge in front of people and make them beg, not "taunt" in the sense of "insult".
You said:
>"[...] don't even get what the real argument is."
and then refuse to explain what the "real" argument is. someone then asks for clarification and you say:
"It's definitely not [...]""
okay, cool! you are still refusing to explain what the "real" argument is. but at least we know one thing it isnt, i guess.
you haven't even addressed the "mistaken assertion". you just say "nah" and refuse to elaborate. which is fine, i guess. but holy moly is it ever frustrating to read some of your comment chains. it often appears that your sole goal in commenting is to try and dunk on people -- at least that is how many of your comments come across to me.
I was explicit about what the real argument isn't: the notion that lattice cryptography is under-studied compared to RSA/ECC.
I understand what your takeaway from this thread is, but my perspective is that the thread is a mix of people who actually work in this field and people who don't, both sides with equally strong opinions but not equally strong premises. The person I replied to literally followed up by saying they don't follow the space! Would you have assumed that from their preceding comment?
(Not to pick on them; acknowledging that limitation on their perspective was a stand-up move, and I appreciate it.)
You do "XYZ isn't the right argument, ABC is" on a thread like that, and the reply tends to be "well yeah that's what I meant, ABC is just a special case of XYZ". No thanks.
I'm not a professional cryptographer, but I _am_ really interested in opinions of experts in the field and I do have a lot of prior experience with crypto (the actual kind, not *coin). From my point of view, I just don't see what's the fuss is all about.
There's no shared understanding, just a snarky expert claiming (in effect) "I know better than all you simpletons but I'm not going to share". At best it's incredibly poor behavior. At worst it's the behavior of someone who doesn't actually have a defensible point to make.
As far as I know, the currently standardized lattice methods are not known to be vulnerable? And the biggest controversy seemed to be the push for inclusion of non-hybrid methods?
I'm not following crypto closely anymore, I stopped following the papers around 2014, right when learning-with-errors started becoming mainstream.
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.