Maybe this is the kick in the ass Debian needs to upgrade the embarrassingly ancient dnsmasq in "stable" because while I can't think of any new features, the latest versions contain many non-CVE bug fixes.
But I doubt it, they will lazily backport these patches to create some frankenstein one-off version and be done with it.
Before anyone says "tHaT's wHaT sTaBlE iS fOr": they have literally shipped straight-up broken packages before, because fixing it would somehow make it not "stable". They would rather ship useless, broken code than something too new. It's crazy.
They're not going to put a newer version in stable. The way stable gets newer versions of things is that you get the newer version into testing and then every two years testing becomes stable and stable becomes oldstable, at which point the newer version from testing becomes the version in stable.
The thing to complain about is if the version in testing is ancient.
Yeah was about to comment, parent says "if it is ancient", it is not. So the root comment is nothing burger. Stable has 1 release cycle old, and depending on how things play out, testing may have 2.93 or later anyways.
That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C?
And the disadvantage is that backporting is manual, resource intensive, and prone to error - and the projects that are the most heavily invested in that model are also the projects that are investing the least in writing tests and automated test infrastructure - because engineering time is a finite resource.
On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport. And then things just get worse and worse.
We'd all be a lot better off if certain projects took some of the enthusiasm with which they throw outrageous engineering time at backports, and spent at least some of that on automated testing and converting to Rust.
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time.
That's not what it's about.
What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it will break in production for anyone who is actually using it. So instead the change goes into the testing release and the user discovers that in their test environment before rolling out the new release into production.
> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport.
They're not alternatives to each other. The stable release gets the backported patch, the next release gets the refactor.
But that's also why you want the stable release. The refactor is a larger change, so if it breaks something you want to find it in test rather than production.
You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...
So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun.
And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.
So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.
> You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...
Updated what, specifically in production?
If you need a newer version of Python or Postgres or whatever it is possible to install it from third-party repos or compile from source yourself. But having a team of folks watch all the other code out there is a load off my plate: not worrying about libc, or OpenSSH, or OpenSSL, or zlib, or a thousand other dependencies. If I need the latest version for a particular service I would install that separately, but otherwise the whole point of a 'packagized' system is to let other folks worry about those things.
> So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun.
I've done in-place upgrades of Debian from version 5 to 11 at my last job on many machines, never once re-installing from scratch, and they've all gone fine.
Further, when updates come down from the Debian repos I don't worry about applying them because I know there's not going to be weird changes in behaviour: I'm more confident in deploying things like security updates because the new .deb files have very focused changes.
One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now. These are the updates stable gets.
The other is changes and additions. They're both more likely to break things and less important to move into production the same day they become public.
You don't have to wait until testing is released as stable to run it in your test environment. You can find out about the changes the next release will have immediately, in the test environment, and thereby have plenty of time to address any issues before those changes move into production.
But I have noticed far more broken in distro that DOES backport features, RHEL/Centos. So many that we migrated away from it, when they backported a driver bug into centos 5 and then did the same backport of a bug for centos 6.
Also rebuilding package is trivial if you don't agree with what should and should not go into stable version
You definitely need different channels for high priority fixes and normal releases, stable and testing releases and all that.
But two years is impractical and Debian gets a ton of friction over it. Web browsers and maybe one or two other packages are able to carve out exceptions, because those packages are big enough for the rules to bend and no one can argue with a straight face that Debian is going to somehow muster up the manpower to do backports right.
But for everyone else who has to deal with Debian shipping ancient dependencies or upstream package maintainers who are expected to deal with bug reports from ancient versions is expected to just suck it up, because no one else is big enough and organized enough to say "hey, it's 2026, we have better ways and this has gotten nutty".
Maybe the new influx of LLM discovered security vulnerabilities will start to change the conversation, I'm curious how it'll play out.
> ...upstream package maintainers who are expected to deal with bug reports from ancient versions...
They are not expected to deal with this. This is the responsibility of the Debian package maintainer.
If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it.
If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.
If package maintainers were always fine upstanding package maintainers as you imagine them to be I wouldn't be complaining, but I have in fact had Debian ship my software and screw it up and gotten a flood of bug reports, so... :)
I think you need to chill out. Relicensing the way you suggest would be _quite_ the hostile act, and I'm not going to that either. But I am an engineer, so of course I'm going to talk about engineering best practices when it comes up.
You don't have to take it as an attack on your favorite distro - that really does pee in the pool of the upstream/downstream relationship between distros and their upstream.
> I am an engineer, so of course I'm going to talk about engineering best practices when it comes up.
The trouble is you seem to be assuming that best practices for you, in your opinion, also apply to everyone else. They don't. Not everyone sees things the way you do or is facing the same issues or is making the same set of tradeoffs. There are downsides to what debian does but there are also upsides.
At this point, given the plethora of high quality options available as well as how easy it is to mix and match them on the same system thanks to container-related utilities and common practices I really don't think there's any room for someone who doesn't like the debian model (ie in general, as opposed to targeted objections) to complain about how they do things. If you want cutting edge userspace on debian stable at this point you have at least 3 options between nix, guix, and gentoo. There's also flatpak and snap which come built in.
We're in the middle of a huge spike in LLM discovered security vulnerabilities, which means not everything will get assigned a CVE, a lot of people are watching repositories to look for exploitable bugs, and in the frenzy of backporting that people are now having to do things will get missed.
I wager it's only a matter of time before we see a mass rooting event that hits Debian hard while everyone running something more modern has already been patched.
I think that might be what cuts down on the grandstanding about "freedoms" and "that's how we've always done things". You certainly are, up until it becomes a public nuisance.
No one is grandstanding about freedom here though? I claimed that the approach debian takes has both upsides and downsides. I stand by that. Personally I pull my networked services from testing while running stable on the host. I absolutely do not want constant churn of the filesystem code or drivers on my devices but I would also prefer not to run some franken build of ssh or apache or what have you. However I can also sympathize with others who need a more structured process and substantial lead time in staging prior to making major changes to production.
Why would you expect LLMs not to be simultaneously leveraged to catch backports that were missed or inadvertently broken?
Given recent headlines I think it's far more likely that we see a mass rooting event hit one or more of the bleeding edge rolling release distros or language ecosystems due to supply chain compromise. Running slightly out of date software has never been more attractive.
Good grief, you are not forced to uae Debian! Please leave the only stable distro alone, and just use one more to your style.
I assure you, enormous sums of people prefer Debian the way it is. I do not, ever, want "new stuff" in stable. I have better things to do than fight daily change in a distro, it's beyond a waste of time and just silly.
If you want new things, leave stable alone, and just run Debian testing! It updates all the time, and is still more stable than most other distros.
Debian is the way it is on purpose, it is not a mistake, not left over reasoning, and nothing you said seems relevant in this regard.
For example, there is no better way than backporting, when it comes to maintaining compatibility. And that's what many people want.
If you don't like the debian model, didn't use debian. There are people that like the debian model, it seems like you aren't one of them, though. That doesn't make them wrong.
> You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...
Doing terrible work every 2 years is better than doing it every day?
I've brought this up with leap second adjustments; a process you do once every two years is one you'll never get good at. If you want them to go smoothly, do them monthly.
LetsEncrypt has been a great example of this in certificate management.
Personally I'd rather have a manageable stream of little bad things consistently over time rather than suddenly having a mountain of bad things one day.
Debian Testing works entirely fine for that use case. Each package gets ~2 weeks of shakeout in Unstable before it gets there so there is chance most of the teething issues with new version is handled already, and is more than most rolling distros do
> Doing terrible work every 2 years is better than doing it every day?
And by skipping some releases, you will have less of that work. When something is changed in one release, then changed again on the next one, by waiting you only have to do the change once, instead of twice. And sometimes you don't even have to do anything, when something is introduced in one release and reverted in the next one.
Get thru the issues once every 2 years is entirely fine. Farther than that and you get problems. We do that for ~500 systems of very varied use. I wouldn't want to do it yearly (or dread on rolling release) but I also wouldn't want to do it any less often coz of issues you mentioned.
> And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.
Having that sprung on you because you decided to run everything on latest is worse.
"Oh we have CVE, we now need to uproot everything because new version that fixes it also changed shit"
With release every year or two you can *plan* for it. You are not forced into it as with "rolling" releases because with rolling you NEED to take in new features together with bugfixes, but with Debian-like release cycle you can do it system by system when new version comes up and the "old" one still gets security fixes so you're not instantly screwed.
> So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.
It exists in that format because people are running businesses bigger than "a man with a webpage deployed off master every few days"
Clearly you disagree with the debian stable perspective. That's fine, it's not for everyone. You can just run debian unstable or debian testing, depending on where exactly you draw the line.
If you want the rolling release like distro, just run debian unstable. That's what you get. It's on par with all the other constantly updated distros out there. Or just run one of those.
Also, Debian stable has a lifetime a lot longer than 2 years, see https://www.debian.org/releases/. Some of us need distros like stable, because we are in giant orgs that are overworked and have long release cycles. Our users want stuff to "just work" and stable promises if X worked at release, it will keep working until we stop support. You don't add new features to a stable release.
From a personal perspective: Debian Stable is for your grandparents or young children. You install Stable, turn on auto-update and every 5-ish years you spend a day upgrading them to the next stable release. Then you spend a week or two helping them through all the new changes and then you have minimal support calls from them for 5-ish years. If you handed them a rolling release or Debian unstable, you'd have constant support calls.
...or just leave grandparents on the previous version of Stable until they get a new computer. Honestly not a huge fan of upgrading software at all, if I'm the one supporting the machines.
Just depends on if that's something grandparents/kids can/want to afford.
Personally, If the hardware is working great, seems like a waste of money replacing it, just to upgrade software. Especially with Debian oldstable -> Debian stable where it's usually quite easy and painless.
> You don't want that as an automatic update because it will break in production for anyone who is actually using it
The problem with this take is that it’s stuck in the early 2000’s, where all servers are pets to be cared for and lovingly updated in place.
It’s also circular: you have the same problem with the current model if you don’t have a test environment. And if you do have a test environment, releases can be tested and validated at a much higher cadence.
If you want that, you don't want Debian. Other people do.
Some people will even run Debian on the desktop. I would never, but some people get real upset when anything changes.
Debian does regularly bring newer versions of software: they release about every two years. If you want the latest and greatest Debian experience, upgrade Debian on week one.
From your description, you seem to want Arch but made by Debian?
> From your description, you seem to want Arch but made by Debian?
Isn't that essentially Debian unstable (with potentially experimental enabled)? I've been running Debian unstable on my desktops for something like 20 years.
Refactoring and rewrites prove time and time again that they also introduce new bugs and changes in behaviour that users of stable releases do not want.
For what you want, there are other distributions for that. Debian also has stable-backports that does what you want.
No need to rage on distributions that also provide exactly what their users want.
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C
The automatically tested Debian release is called Debian Testing. And it is stable enough.
Debian Stable is basically "we target particular release with our dependencies instead of requiring customer to update entire system together with our software". That model works just fine as long as you don't go too far back.
> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport. And then things just get worse and worse.
Narrator: It turned out things were not getting worse, they were just fine.
> We'd all be a lot better off if certain projects took some of the enthusiasm with which they throw outrageous engineering time at backports, and spent at least some of that on automated testing and converting to Rust.
That project is RedHat, not Debian, they backport entire features back to old versions (together with bugs!)
Don't get me wrong, I use and encourage extensive automated testing. However only extensive manual testing by people looking for things that are "weird" can really find all bugs. (though it remains to be seen what AI can do - I'm not holding my breath)
You don't have to use Debian stable, if you'd prefer Ubuntu every 6 months, or Fedora (6 months? 9 months?), or even Arch Linux updated daily ...
I use Arch on my laptop, when I got it 2 years ago the amd gpu was a bit new so it was prudent to get the latest kernel, mesa, everything. Since I use it daily it's not bad to update weekly and keep on top of occasional config migrations.
I use Debian stable on my home server, it's been in-place upgraded 4-ish times over 10 years. I can install weekly updates without worrying about config updates and such. I set up most stuff I wanted many years ago, and haven't really wanted new features since, though I have installed tailscale and jellyfin from their separate debian package repos so they are very current. It does the same jobs I wanted it to do 8 years ago, with super low maintenance.
But if you don't want Debian stable, that's fine. Just let others enjoy it.
About a decade ago I switched to Ubuntu LTS because of Debian’s “policy?” of having pretty old packages in “stable” and a long release cycles.
Nowadays, even with Ubuntu’s two year or so release cycle I have to use 3rd party packages to have up to date software (PHP being one) and not some version from three years ago.
We no longer live in a world (with few exceptions) where running a 3-5 year old distribution (still supported) makes sense.
I am running debian oldstable on two rpi-based appliances i built at home. They have been working fine for several years.
I'll have to update them because eventually security updates will stop. That means that the python code on them no longer works on current python versions, C++ needs some tweaks because some library changed API.
Better to do these things every few years than every 6 months for no reason whatsoever.
> That means that the python code on them no longer works on current python versions, C++ needs some tweaks because some library changed API.
And this is why you update often, to keep up with the programming language ecosystem too. I have seen way too many times software unmaintained for years and then when it was actually time to upgrade it would take much more time to bring it to current framework versions than it would have taken if it was updated regularly throughout the years.
And I was not referring to hobby projects you do at home.
It depends on how you look at it. I use Debian stable in the smallet possible configuration because it is, well, stable. A rock on which I put docker to run actually useful services, which are upaded the way I want.
If I was to run dnsmasq on Debian, it would be in a container. Since I run Pihole (in a container), it kinda is.
What if the new release which contains the fixes has new dependencies and those also have new dependencies? I assume they have to Frankenstein packages sometimes to maintain the borders of the target app while still having major vulns patched right in stable.
And no "good faith" assumption here, since you literally claim debian stable ships broken kernels, according to you nobody should be able to even boot a computer.
That's what stable is for though. Like, sure, stable's policy is ludicrous and you would have to be insane to run stable. But the remedy for that isn't to try to change Debian policy, it's to get people to stop running stable. Maybe once no-one uses it Debian will see sense.
It's more of a good thing that, in most cases, it's on devices that won't send it any packets unless a client first authenticates to a Wi-Fi station or physically plugs into an Ethernet port.
> This sort of worked when the opinionated manager was Steve Jobs.
Steve indirectly had a hand in this, by emphasizing the humanities. That, unfortunately, backfired as a sort of positive feedback loop.
Someone hired a few underemployed artists onto the team, and the artists invited all their friends and soon took over the department.
People that in an alternate timeline would be smoking weed whilst sculpting wood in a derelict loft somewhere are now the lead designers, using our software as the canvas of a perpetual avant-garde art piece.
They also need to look productive to justify their jobs, so the need to change things is constant.
That's why in 2026 you could have a PhD in CS and still need to watch a YouTube video to learn how to change the volume.
Can anyone name a single substantive UI improvement in the last 20 years? They're simply hiding or moving stuff around at this point while no one has even touched accessibility.
You are so very spot on with this. All of it. Literally nothing is better in the UI world in the past 20 years. Zero. We already had multitouch scrolling on laptops back then.
I don’t think it’s a stretch to say that most of the problem can be traced back to the transition to Mobile first design. The motivations were arguably pretty innocent in general. If there were no downsides, it’s nice that there isn’t a separate code base and an entirely separate set of capabilities for desktop and little 5-inch phone screens. However, the way that we have achieved that - nearly across the board - is by lobotomizing the experience everywhere.
And because of fashion (those artists who control the UX can’t resist it), even in places where that doesn’t even make any sense because there is no mobile version (say, B2B SaaS products that only get used on a desktop), they still feel the need to cosplay as a mobile app by using all the same stupid design elements (the ••• and “hamburger” menus, the giant grids of “tiles” that should have been a table, etc.
That's basically the curse. Fucking fashion. If that human concept wouldn't exist, UIs today would be way way better. But no, we have to keep changing it forever and with each iteration worse and worse. UI enshittification at its pinnacle.
> Can anyone name a single substantive UI improvement in the last 20 years?
That thing Windows has where you can drag a window to the top of the desktop and it pops up a few quick options for resizing. I would love it if KDE Plasma had this.
idk, i think your underestimating the ubiquity and resources behind stuff like A/B and usability testing nowadays. Certainly a much more sophisticated way of determining whether people are able to find what they need.
> a single substantive UI improvement in the last 20 years?
On the desktop? No.
In human-computer interaction? The multitouch UI using a capacitative touchcreen, as used in the iPhone (2007, so 19 years ago) and iPad (2010).
This redefined how UIs work, so yeah, it's vastly significant.
The trouble is that now there's a whole generation of developers and desighers who literally grew up with it and its imitations, and they're trying to apply its "simplicity" to desktop WIMP GUIs. In the process they are removing things like, you know, the "M" of WIMP (whether it's "mouse" or "menu") because they don't see it as important.
Guess they've never been on the phone with an elderly relative in tears because she can't figure out basic tasks on an iPad anymore after years of learning how.
That's when you realize you, as a highly-skilled technical person, can't either, because they've moved, hidden, or otherwise obfuscated them.
Yesterday I learned there are two icons in the Files app called "..."
Yes, two.
Incidentally I was looking for how to delete a file, which is now deliberately missing from the object's context menu, and intentionally hidden under one of these.
A few weeks ago I was co-hosting a live coding session (in front of a crowd, it was pretty collaborative, back-and-forth).
I had to authorize something with Firebase, for which I had to auth with Google, for which I had to do a MFA with my (Pixel) phone.
Usually it's "are you trying to auth" and finger-to-the-scanner, but around that time this particular way didn't work. It also didn't want to send me a text or a call to auth me.
No, I had to find an OTP code. Easy, right? Wrong. The instructions, and the docs, don't match where it was in that particular version of Android, and there were a bunch of blind alleys that were named basically the same.
It took me like 10 minutes, on stage, browsing my phone (thankfully, not casted to screen) to find the friggin' option. Thankfully the cohost was doing the presenting at that time, but it was pretty lousy.
And this is using Google's OS on a Google phone doing a Google auth flow for a Google property. And I'm a techie who's been using Android for 15+ years now. And I did the exact same dance a few weeks before that - also so roundabout I had no idea how I stumbled on the correct page.
User experience my ass.
PS. The regular "are you trying to sign in?" flow works again. No idea what happened - wasn't me.
Even with screen sharing, I've said "click the three dots" and then "no, not those, not that one, wait there's another one, no that's the wrong one ..."
But if we didn’t use ••• menus everywhere then some parts of the UI might be cLuTtErEd!!! The worst sin of computing.
To think that we used to trust mere mortals - without even a signing certificate or developer membership - with the power to customize every toolbar in a Microsoft application, and to set every font and color for the whole UI of the system. People made their computer environments ugly in some cases. And it was fine, because they owned those freaking computers, so who the heck has any business telling them not to?
Sorry, clearly it bugs me a lot how much we’ve lost.
It's not just what we've lost, it's an incredible disservice to "non-nerds" - old DOS programs may have been annoying and cluttered, but everything was right there and more importantly, it didn't change so you could learn what you needed and just work with it.
We could go back and forth on things like "the ribbon" being better or worse, but the fact that it changes depending on window size is an incredible sin. Hello, everyone! Learn how to click a tiny 5x5 pixel arrow or lose your menu items forever!
It's like a compromise was made at some point where they decided that in order to get what they predicted would be slightly higher adoption, it's okay to usher in a world where most consumer-facing software is essentially impossible to become a 'power user' of, because of abridged ('decluttered') functionality, lack of keyboard shortcuts, extreme lag caused by excessive animation, and a UI that changes for fashion reasons every few months.
I look at retail for examples of this. If you watch an experienced cashier who interacts with a system all day, they have perfect muscle memory of the keyboard or keypad, and operate it so fast that you would have to ask them to slow down to understand what they're doing.
Now many of those have been replaced with touchscreens, which are noticeably worse -- since the UI is never fast, you have to stop and wait for the next UI to appear after many of the steps, instead of letting the keyboard buffer do it for you, which worked great on a decades-old system. But, I assume the companies who allowed that replacement believed it was worth it to be able to onboard a new cashier just a bit quicker, with a UI that looks just like the iPads that they were raised on, complete with big unlabeled icons and "three lines" or "•••" buttons.
I’m always reminded of the old text UIs at Fry’s Electronics - a salesman could slam in all the keystrokes necessary to print your pick slip before the screen had even finished loading the first inventory. It was pretty impressive.
Meanwhile I live in a world where opening five Salesforce tabs locks them all up.
The UI wouldn't be cluttered if the keys on the...keyboard...did stuff. Now that vibe-coding has broken me out of my decades-long irrational fear of GUI programming, I've recently been circling back on all the UI patterns I have just accepted. One missing one is all those F1...F12 keys. I remember those doing stuff in the DOS days. I fantasize about a computer where the menus are at the bottom of the screen and line up with the Fn keys on the keyboard. I know...it might be possible for even grandma to figure that one out.
Arguably the trend to touchscreens could have given a lot of help to the novice user by having labeled buttons - onscreen FKeys if you will. But we seem to have used touchscreens to show pictures fullscreen, with controls that disappear until you swipe or touch something just the right way.
Fkeys are arguably a huge tragedy, here we have keys, twelve of them, that could have been used for simple one-fingered operation, but they were put to use pretty sparingly for a long time (basically F2 and Alt-F4 were the only common ones most people used, with F1 for Help and F11 often used for Full Screen as honorable mention) so the laptop manufacturers reused them, leading to a world where they go from being the easiest and best keyboard shortcut keys, to one of the worst, since you probably need to teach people how to find and use a 'Fn' key to use them.
Touchscreen UIs definitely could be made a lot better. For example, long-press has always annoyed me. Why isn't there a modifier button that allows selecting the interaction mode before touching (e.g. a mode button separate from the thing being clicked on, that can also be clicked on with one finger)? Similarly, wouldn't it be nice if there was a way to know, before clicking, what a button might do, and whether that could be undone? Steep, steep asks, I know.
I’d love to use those keyboards that can light keys to flash the key combo for the menu items.
It seems now it’s not worth learning the keystrokes because everything is a website or changes randomly. Ah, for the days when Excel supported Lotus 1-2-3 shortcut mode for decades.
Public keys go over untrusted channels. That's why they're public.
I'm not confident you understand how crypto works.
You do realize the entire threat model here is a house of cards perched atop someone else's software hosted on someone else's hardware all of which you implicitly trust and discard in favor of some unlikely cloak and dagger interception scheme.
Public keys can go over channels that an attacker can read. They cannot go over channels that an attacker can modify. (Which would include the SSH connection itself, until such time as you’ve verified the key through a trustworthy channel.)
I've stopped submitting quality reports to Apple Maps because they're all met with "while we couldn't make the change you suggested, we hope you continue to waste your time reporting these".
The issues are egregious too, like blatantly incorrect lane guidance that would send you in the wrong direction, or diverting me off a highway onto an unmarked, narrow country road that no one with any knowledge of the local roads would take ever.
Though I'm confident whatever BPO slaves they have processing reports 5000 miles away have a better understanding of the roads than I, as they are wholly incapable of even using Google Street View to confirm details (probably by policy) so they always demand I provide a photo or video a month after the fact. Because when you're lost in the middle of nowhere your first thought should be "Let's backtrack so I can grab some pictures for Apple".
Google Maps isn’t much better. Outside of major population centres, you have to fight with it to keep you on major highway.
Google and Apple both prefer “efficient” routes with unsealed roads that are 4WD only, impassible when wet, have no services, no mobile coverage, and where if you need medical help it literally comes by aeroplane.[1]
