> Roundabouts come with this otherwise unused patch of land in the middle. Apparently, it has become common practice around the world to put some random art there, or a little green space, or a fountain, or a "welcome to this town" sign.
According to Wikipedia, these shrubs are there for a reason. Denmark has found that blocking the line of sight significantly reduces the accident rate by forcing the drivers to slow down and consider only their immediate surroundings. Danish drivers hate them, anyway.
Agreed, it can be really hard to get around a roundabout as a pedestrian if it's not designed for it, and then they make it so both you and people entering don't know each other are there until you're about to get hit.
It’s something I have seen becoming the norm nowadays. Articles about art or photographs without a single image. Political articles about borders without a single map. Articles about some thing some scientist has done, maybe with a picture of the scientist, but not of the actual thing. And it’s not a technical limitation of the medium; most articles will have numerous (but irrelevant) images.
I suspect that SEO measurement has told people that it doesn’t matter what images an article has, as long as it has some images, optimally interspersed with the text. Spending any money on getting relevant images thus becomes an unnecessary expense. Readers will still click on the article (because of the click-bait headline), and will still read (or at least scroll through) the article if the text is broken up by images by an optimal amount.
So does any other language which wants to be useful; being able to call C functions is table stakes for a systems programming language. But Rust itself can still only generate static binaries, because Rust doesn’t have a stable ABI.
For those who actually need something like this in production, there is Snek: <https://sneklang.org/> “Snek is a tiny embeddable language targeting processors with only a few kB of flash and ram.”
Yes, but compiling or modifying Snek from source is very challenging. I wish it was one single C file for an example base like Posix, instead of many files for many platforms plus a custom parser in Python (Lola).
From: hermann@cpsc.ucalgary.ca (Michael Hermann)
Subject: Programmming awards
Date: 10 Feb 89
At Calgary, the computer science department has an award called
the Williams Cup (as in old stained coffee cup), which is given
yearly to the student who hands in the most imaginative
rendition of a regular programming assignment. Anyway, as the
story goes, the cup was awarded to a student who'd done a desk
calculator assignment. Seems that the prof hadn't specified
that you had to do it in decimal, so his/her program did math
with _roman_numerals_.
The clincher for the award must have been his/her programming
style, since of course, the documentation was in _latin_.
That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then.
DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents.
We have since committed entirely to transport security in the form of DoH and friends. It solves the vast majority of problems we actually have.
DoH only secures the connection between the DoH provider and the client, not the response from the authoritative DNS server. It also isn't sufficient for DANE or similar. So DoH doesn't completely solve the problems DNSSEC tried to.
Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.
TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.
This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.
And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.
The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.
”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.
It is not surprising that European registrars have added millions of new names nobody is ever going to visit, all of them signed by default at their registrars. That's not meaningful.
You said “Adoption of DNSSEC has barely budged”, and that is what the graph which I linked shows to be hilarously false. I remember that you often used to link the same graph – until it stopped showing what you wanted, that is. Now you come peddling a different, explicitly biased, graph, which only shows what the top 1% is doing, but I really don’t care about what the top %1:ers are doing. Most people are concerned with popularity in general, not what Google and Amazon are doing. Most people are not Google and Amazon, and consequently should take no lessons from them concerning their own systems.
(2) It's live: everything in the Tranco Top 1000 gets checked several times a day. I can tell you every site in that last that has changed DNSSEC status (turned it on or off) in the last year. Spoiler: you can count them on the fingers of two hands.
I don't know why you push on this statistics argument! It's really rough for you. If I was in your shoes I'd be trying to decrease their salience, not increase them.
What is this graph a reply to? Those graphs are for how many resolvers validating DNSSEC, not domains using DNSSEC. And here, your frequent pointing to Google and other large operators works against you, since all of them already validate DNSSEC!
Also, I find it highly questionable of you to link to a graph as part of an argument, without disclosing that you also made the software which makes the graph. (But the graph also wears its bias openly, so it’s at least honest about not being biased.)
> I don't know why you push on this statistics argument!
Notably, I did not bring it up. You brought it up, when you wrote “Adoption of DNSSEC has barely budged since [2015].” Which the graph from Verisign – which you also used to link to – shows to be utterly false.
The argument about DNSSEC with you always goes in circles. You claim that DNSSEC adoption is not rising. But the Verisign statistics show that more domains are DNSSEC signed than ever before, every day, both by numbers and percentage. Then you claim that the large masses of domains don’t count, but only the top 1% of 1% of popular domains, which are, notably, with some exceptions, not commonly DNSSEC signed. But those domains are used by Google and other infinitely large and alien actors, which have very different security models and threat models than most people with a domain name. Then you try to argue against the Verisign graph by posting a link to other graphs which claim to show “DNSSEC adoption”. But the graph you link to is not about domains, but about resolvers. However, the large and most popular resolvers are from Google, Cloudflare and the like, and all of those have done DNSSEC validation for a long time.
At this point I think if you want to keep talking you should just email me, because we're the only two people reading this. I don't understand either of your arguments here.
I don’t see why I should email you; you haven’t given any new arguments here in this thread, why should I expect any better by email?
My arguments can be summarizes as follows: 1. The usage of DNSSEC is, contrary to your claim, going up, steadily. By number of domains signed, percentage of domains signed, and usage of DNSSEC-verifying resolvers. 2. Your argument seems to be that a) The increasing number and ratio of DNSSEC signed domains do not count, only big-name domains like Google are important (since many of those are still not DNSSEC signed), but b) big-name resolvers like Google are simultaneously not important, since those all do verify DNSSEC signatures. This argument is inconsistent. 3. Linking to, and trying to prove an argument by, your own biased graph using your own software, without disclosing that it is your graph and software, is scummy.
Or a dog: <https://en.wikipedia.org/w/index.php?title=Roundabout_dog&ol...>
reply