phicoh

Browsers happily killed EV certificates. With EV such a hack would take quite a bit more effort.

A linked list of each authoritative name in the zone. Not a list of zones.

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.

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.

At the time it was well known that messing around with NXDOMAIN would cause problems. But some companies wanted to do it anyhow.

The solution is simple, if you want to use this DMARC feature then don't host with companies that do weird stuff with NXDOMAIN.

I think it is a marketing failure. The web was mentioned before, but ARM, Wifi, Bluetooth, the CD, all European inventions. There are core parts of the internet that are completely dominated by a European company but nobody knows. If we go back to the past, everyone had a Nokia phone at some point. There are services companies like Booking and Spotify. Then Linux and Python are from Europe as well.

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.

I think what matters is the size of (for example) the German economy with and without the EU.

Futhermore, what matter is the amount of tax collected by the EU. Energy subsidy is not money collected by the EU and distributed.

Why not? If the increase in cake size is bigger than the subsidies then it can be a net win, even for the people paying the subsidies.

It also ignores the fact that absent the EU, countries would still have a lot of subsidies.

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.

I think that is not correct.

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.

I'd say that is even more so with Rust and Rust got popular in a very short amount of time.

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.

Something doesn't add up here.

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.

The problem is that these laws tend to escalate. Once a government starts regulating, it doesn't stop.

It is also the wrong model. Instead of creating child-safe devices, just like there is a difference between toys and power tools, this regulation pretends that all devices are child safe and parents have to figure out which ones really aren't.

There is a huge attack surface for this. For example, kid manages to buy an old phone. Resets the phone and creates an account. Kid buys something like a Pi 3 manages to get a regular phone to become an access point. Etc. If a laptop is not completely locked down, a kid might boot a live USB stick.

The problem with TAI is that the rest of the world uses UTC. So you can use TAI on a small island and then you have to convert to and from UTC. My hobby kernel is based on TAI internally. And it constantly converts to and from UTC.

Which means that time changes slowly enough that we don't notice. At some point everybody goes work half an hour earlier because it makes sense. Schools start earlier, shops open earlier. It doesn't have to be coordinated worldwide. Every region or even town can have its own customs. Then people notice they are in the wrong time zone and a country moves to a different time zone.

Statistically, nobody on Earth knows what UTC is. People know about their local time zone and how it related to time zones in other countries. Where the position of the sun is relative to UTC, almost nobody knows.

It is way more easy to let UTC (without leap seconds) just drift away from the zero meridian and move countries to different time zones when convenient. We mess around with daylight savings time often enough that nobody will notice if we have change local time every couple of thousand years.

I remember back in the day when Google+ was just launched. And it had promoted content. Content not from my 'circles' but random other content. I walked out and never looked back.

Of course, Facebook started doing the same.

The thing is, anything from people not explicitly subscribed to should be considered advertorial and the platform should be responsible for all of that content.

In Rust you can do "fn new(field: Field) -> Self { Self { field } )" This is in my experience the most common case of initializers in Rust. You don't mention one of the features of the Rust syntax, that you only have to specify the field name when you have a variable with the same name. In my experience, that reduces clutter a lot.

I have to admit, the ..Default::default() syntax is pretty ugly.

In theory Rust could do "let x: Foo = _ { field }" and "Foo { field: _ { bar: 1 } }". That doesn't even change the syntax. Its just whether enough people care.

In general it would help if you would spend some text on describing what features of C99 are missing in other languages. Giving some code and assume that the reader will figure it out is not very effective.

As far as I can tell, Rust can do what it is in your example (which different syntax of course) except for this particular way of initializing an array.

To me, that seems like a pretty minor syntax issue to that could be added to Rust if there would be a lot of demand for initializing arrays this way.