QGIS is the rare open source product that made great improvements in usability. It's still got lots of warts and lack of polish but a lot of the core features are quite accessible in a way they weren't 5 years ago.
Long story short he got lucky in the 90s with an inheritance and a publisher and can now devote his life to researching and publishing English slang. It's also interesting to me because it's a project that started as a book but has now migrated successfully to the Internet, both for publishing the dictionary and for doing research for updates to the dictionary.
I agree this is the interesting part of the project. I was disappointed when I realized this art was AI generated - I love isometric handdrawn art and respect the craft. But after reading the creator's description of their thoughtful use of generative AI, I appreciated their result more.
Niagara is amazing. It's quite different from other launchers, so either it works for you or doesn't. It perfectly matches what I was doing before, which was searching for apps by name to launch them.
Haven't tried KISS, just looked at screenshots. Niagara tries to be slightly customizable and aesthetically pleasing. I've been using (and paying for) it for years. Its plenty lightweight to be snappy on even older model phones.
The article has a quote from the investment director saying it is not symbolism. "The decision is rooted in the poor U.S. government finances, which make us think that we need to make an effort to find an alternative way of conducting our liquidity and risk management"
Wow they were flying at 27,000 feet for a lot of that. I was wondering how they'd get over the Rockies but had no idea they'd go all the way up there. Obviously they need oxygen and the plane has to be designed to fly in that thin of air, but just how hard is that?
Not hard and the glider needn't be special; most already have a stunning glide ratio. I've been up in lesser wave in a clunky old trainer. You do need to coordinate with ATC to keep separation from jets. And the oxygen rig does has to be more serious than a nasal cannula above 18000 ft.
It's remarkable that the ordinary DNS lookup function in glibc doesn't work if the records aren't in the right order. It's amazing to me we went 20+ years without that causing more problems. My guess is most people publishing DNS records just sort of knew that the order mattered in practice, maybe figuring it out in early testing.
I think it's more of a server side ordering, in which there were not that many DNS servers out there, and the ones that didn't keep it in order quickly changed the behavior because of interop.
(Yes, there are other recursive resolver implementations, but they look at BIND as the reference implementation and absent any contravention to the RFC or intentional design-level decisions, they would follow BIND's mechanism.)
It’s not remarkable, because it’s the way all DNS servers work. Order is important in DNS results. It’s why results with multiple A records are returned in shuffled orders: because that impacts how the client interprets the results. Anyone who works with DNS regularly beyond just reading the RFCs ought to recognize this intuitively.
People probably ran into this all the time, but no single party large enough to have it gain attention produced the failure state.
If a small business or cloud app can't resolve a domain because the domain is doing something different, it's much easier to blame DNS, use another DNS server, and move on. Or maybe just go "some Linuxes can't reach my website, oh well, sucks for the 1-3%".
Cloudflare is large enough that they caused issues for millions of devices all at once, so they had to investigate.
What's unclear to me is if they bothered to send patches to broken open-source DNS resolvers to fix this issue in the future.
The last time this came up, people said that it was important to filter out unrelated address records in the answer section (with names to which the CNAME chain starting at the question name does not lead). Without the ordering constraint (or a rather low limit on the number of CNAMEs in a response), this needs a robust data structure for looking up DNS names. Most in-process stub resolvers (including the glibc one) do not implement a DNS cache, so they presently do not have a need to implement such a data structure. This is why eliminating the ordering constraint while preserving record filtering is not a simple code change.
Doesn't it need to go through the CNAME chain no matter what? If it's doing that, isn't filtering at most tracking all the records that matched? That requires a trivial data structure.
Parsing the answer section in a single pass requires more finesse, but does it need fancier data structures than a string to string map? And failing that you can loop upon CNAME. I wouldn't call a depth limit like 20 "a rather low limit on the number of CNAMEs in a response", and max 20 passes through a max 64KB answer section is plenty fast.
I don't know if the 20 limit is large enough in practice. People do weird things (after migrating from non-DNS naming services, for example). Then there is label compression, so you can have theoretically have several thousand RRs in a single 64 KiB response. These numbers are large enough that a simple multi-pass approach is probably not a good idea.
And practically speaking, none of this CNAME-chain chasing adds any functionality because recursive servers are expected to produce ready-to-use answers.
For anyone not reading the article, she did fundamental work measuring the geoid, the non-spherical corrections to Earth's shape that is fundamental to very accurate GPS positioning.
reply