Agreed, there should not be a tight (temporal) couple.
But it's a trade off. Long-lived TLS certificates have always had the cert revocation problem. OCSP stapling never took off, so in the end the consensus seems to have been to decrease expiry date. (Mostly fueled by Let's Encrypt / ACME).
Relying on expiration rather than explicit revocation of course also assumes (somewhat) accurately synchronized clocks which is never trivial in distributed systems. In practice it put's pressure on NTP, which itself is susceptible to all kinds of hairy security issue.
I like to think of the temporal aspect as a fail-open / fail-close balance. These centralized solutions favour the former, and that's why we see this resulting outage.
> Polling booths are run by volunteers and they have hard enough of a time already checking the validity of Dutch ID, adding 27 other forms of ID will only make it easier to bypass the electoral protections we have.
Not sure about this one. For municipal elections in the Netherlands, you need to live in a particular municipal to vote. That means: even non-eu expats are eligible. I have had colleagues with UK, US and Turkish passports that voted (or could have voted) in Amsterdam for local representatives.
They can definitely vote in most local Dutch elections, though that ability differs per EU member state. As long as you have a valid registration with the municipality, you're eligible.
The example given wasn't about casting their own vote, though, but voting for someone else by proxy (volmacht). For that, you need to take someone else's voting pass, a copy of their ID (may be expired up to a certain amount of years), and a form of your own, valid, Dutch identification.
That last part is where it went wrong: they didn't have valid Dutch ID so the vote by proxy was rejected.
I'm frankly amazed that the majority of new laptops still come with Microsoft Windows.
To be fair, over the years there have been sincere efforts to re-architect the OS with a security, privacy, reliability for peristent storage, graphics, multi-tasking, multi-user, networking etc. But those efforts never caught up with the speed at which bloat was added.
At the heart, its design still has remnants that have the naivety of a stand-alone, stateless microcomputer that boots straight off a floppy after BIOS POST.
Not a geologist, but interesting that many of these sites are close to equator. Suppose that's where mountains are higher because tectonic plates are more active?
Not a geologist either but an astronomer. Never heard that tectonic activity has any association with proximity to equator.
Mountains can rise higher near equator because you have the least gravity there. The whole Earth bulges along the equator. But I don't think it's measurable.
While Everest (8849m) is the highest point above Sea Level, Chimborazo (6267m) in Ecuador is further from the centre of the Earth (about 2000 metres further), due to the equatorial bulge. It's very measurable.
Well that's not what the claim and clarification was about. The question was: can a mountain rise higher in the equator as compared to higher latitudes?
It is not about highest point from centre of Earth. That's is related to equatorial bulge but irrelevant to the discussion.
It's also interesting because the radius of curvature is smaller, meaning the distance to the horizon is shorter north south, and a lot of these views are north south. So the increase in mountain height more than overcomes the other effect!
The earth is an oblate spheroid to an approximation. It's not that they're not symmetric, but at the equator the north south axis has higher rates of curvature than anywhere else (but the east west has somewhat lower rates because of the larger circumference due to the bulge).
So that large lines of sight are near the equator on a north south axis (or symmetrically south north) is crazy because the high rates of curvature in that direction at those latitudes should give the shortest distance to the horizon on earth, making those lines of sight even that much more impressive!
Your last sentence makes a very good point. And Uncle Bob's tool is to have loads of tests.
I suppose it's all just a balance: simplicity versus expressiveness, foot guns versus inflexibility, conciseness versus ceremony, dev velocity versus performance in production.
I'm okay with shifting some of the burden of common errors from developer into the language if that improves reliability or maintainability. But Martin has a point in that no guard rails can ever prevent all bugs and it can be annoying if languages force lots of new ceremony that seems meaningless.
I suppose it's somewhat accurate to claim that Haskell and Ocaml historically preceded Java (or even Objective-C). But Java wasn't inspired by those academic languages, but C: a then widely used real-world language with only partial static types.
(Not saying Java's attempt to remedy C's problems wasn't half-assed — it was.) The trend to plug holes is primarily motivated by empirical evidence of bug classes. Not by elegance of academic research.
As Bjarne Stroustrup famously quipped:
> “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
Swift, Kotlin, Rust, C++ are attempt to become languages that everyone complains about, not Haskell or Ocaml.
> Also, the other side of it is that evolutionary projects are just more fun. I’ve preferred them. You’re not loaded down with all those messy dependencies. Way fewer meetings, so you can just get into the work and see how it goes. Endlessly arguing about fiddly details in a giant spec is draining, made worse if the experience around you is weak.
IMO the problem isn't discussing the spec per se. It's that the spec doesn't talk back the way actual working code does. On a "big upfront design" project, there is a high chance you're spending a lot of time on moot issues and irrelevant features.
Making a good spec is much harder than making working software, because the spec may not be right AND the spec may not describe the right thing.
I suppose it's primarily a matter of experience. And as the article alludes, it's very important to deeply understand the subject matter. I highly value some of my non-programmer colleagues responsible for documentation. But can't put my finger on what exactly they brought to table that made their prose exceptionally good (clear, concise, spot on)...
But it's a trade off. Long-lived TLS certificates have always had the cert revocation problem. OCSP stapling never took off, so in the end the consensus seems to have been to decrease expiry date. (Mostly fueled by Let's Encrypt / ACME).
Relying on expiration rather than explicit revocation of course also assumes (somewhat) accurately synchronized clocks which is never trivial in distributed systems. In practice it put's pressure on NTP, which itself is susceptible to all kinds of hairy security issue.
I like to think of the temporal aspect as a fail-open / fail-close balance. These centralized solutions favour the former, and that's why we see this resulting outage.
reply