According to its documentation, the app Go Map!! can pull from “quests” (small questions, like “are this store’s hours still up-to-date”) used by the beginner-friendly Android app StreetComplete.

IIRC it does this via an overlay. Keep in mind that Go Map!! is normally a fairly robust editor and kind of does this as a side hustle.

🎵 Well I’m a peanut bar, and I’m here to say 🎵

It reminds me of this conspiracy that was circulating a few months back that Apple Maps had “deleted” cities and places in Lebanon to culturally erase it for Israel’s invasion.

In reality (which you could see by e.g. looking at Reddit posts from a few years ago), Apple Maps’ coverage of Lebanon was absolute unusable dogshit the entire time. There were complaints about how it wasn’t even usable for basic navigation in Beirut. The city of Tyre (which was misspelled “Tyr”) was still there despite being one of the hardest-hit cities by Israel’s invasion.

Which was, to be fair, staggeringly incompetent, but it was provably true. Apple Maps’ coverage sucked so badly that, at a surface level, it looked like somebody took an erase tool to a competent map.

I think a lot of people don’t realize how automated corporate maps applications are. Which can be a weakness for crowd-sourced data like OpenStreetMap when there aren’t enough contributors, but that democratization is also a huge benefit that anyone can see and fix issues. The main parts of Google Maps that aren’t automated are points of interest, and those are kept up-to-date thanks to the network effect where e.g. business owners see value in maintaining their information or users feel like they’re helping out (read: doing free labor for a trillion-dollar corporation).

So fwiw, the change was made official and updated in GNIS the day it changed on Google Maps, which uses GNIS behind the scenes. That same day, USGS said the name had taken effect in GNIS but that it was waiting for its maps to visually update.

I think this is a product of Google’s infrastructure being faster to automatically update with GNIS changes. The fact they didn’t step in to override it already shows that they’re willing to go along with this; I don’t think the fact it changed before USGS adds any significance to that bootlicking.

That is, I don’t assume Google manually intervened to make this happen faster.

Still, fuck Google Maps. I’m glad people are waking up to how this level of hegemony over maps gives corporations too much power.

Aaaaaa!

Well in that case, it’s cool to see Fairphone using /e/OS!

Sorry, I realize that question could be interpreted in two ways: I meant for Fairphone not to try to get Graphene working on their phone. I know Motorola is trying to do that right now, for example.

Love me jews

Ahoy, SpongeBoaz!

ELI5: Why use /e/OS over Graphene? This isn’t a rhetorical rant; I’m genuinely curious.

Edit: See below. I misphrased this question.

“… appears to work on Linux with Proton 11 as captured in my screenshot above”

The emphasis in that point was the word “finally”, not “playable state”. As in “it’s finally working after x amount of time” like you’d expect with a project that takes any appreciable time to get working.

before hearing about it

while* hearing about it. The only introduction is a bulleted list of what the project is and isn’t that Liam copy–pasted from their docs. Nothing about any anticipation; nothing about how long it had been in the works; nothing about the authors; no link to a release blog or previous story discussing it in any way; nothing about finally being in a playable state/anything related to the dev cycle. Liam talked about it like it popped into existence (true) and they were just hearing about it for the first time (true).

Combined with what I said above, it’s just basic media literacy that I’m reading about a dead-end throwaway project.

it’s deeply cynical

I gave it a shot by reading the article, which was more than it deserved.

Yeah, “as expected”. The project showed up out of nowhere five days ago and is clearly vibe-coded to fuck and back. The talk of how “oh, it accelerated development, but we checked everything, we swear” is obvious bullshit like it is with basically all of these dime-a-dozen, dead-end slop projects that are showing up everywhere.

No, it would not “just as readily have been an entirely human passion project”, because those take months to years, and you therefore hear about them organically as they’re in development; they don’t show up out of the aether to get a few paragraphs’ mention on an obscure Linux blog. Even from a statistical point of view, those passion projects are vanishingly few compared to the slop projects.

“AI models — Codex, Claude, and DeepSeek — substantially accelerated the final phase. They were given disassembly, decompiled pseudocode, surrounding reconstructed source, engine context, compiler errors, and binary-diff feedback, and helped interpret functions, generate candidate implementations, and iterate toward closer matches. Their output was never treated as authoritative: every candidate was reviewed by developers, compiled, compared against the reference executable.”

As expected: slop.

If you’re using Organic, it’s worth considering Organic’s fork CoMaps, which was created by major contributors in response to these grievances.

Mr. Sandman, sam me a handwich.

Yeah, and?

1. If you actually edit OSM, you know there’s zero compelling reason to make an application that prefers official_name:en-us. Want to know how I know? Because instead of wasting my time making something up to be outraged at, I went and looked up how often this key shows up. It’s six (it shows five, but it hasn’t updated for Lake Ontario yet). In the entire world among billions of key uses, this one is used on six objects. This will not ever happen; it’s complete nonsense.

Even if it were made (it will not be),

2. Nobody would use it. Literally what on Earth usefulness could it possibly have within the already niche ecosystem that is OpenStreetMap? My dude, my guy, if they were targeting bullshit names Trump made up with an EO, they could just soft fork an existing OSM application and then hardcode in “Gulf of America” and “Lake America”.

And most importantly,

3. It doesn’t matter. That’s what the official_name key exists for – to distinguish it from the name people actually use. That’s why it’s a separate key to begin with.

You’re complaining about OpenStreetMap being accurate, and in order to do that, you have to invent some fever dream application that nobody would ever create and nobody would ever use – and that even were they to create it, they could’ve accomplished it more easily by just hardcoding six values.

“When available”. lol, lmao even

The scene is cut in a way that you don’t know for sure they aren’t paying him. They’re probably pretty loyal, long-time customers given the way they all run right there after school, so he can take it on the honors system that they’ll pay for what they’re taking. (And he’s probably able to keep track of it pretty well on his own given he knows their names and preferred candies by heart.)

As for the candy he throws aimlessly into the crowd, I’m sure he can afford to blow some pennies’ worth of money on customer retention by literally throwing candy at them.

Look around you.

it’s in the data

Correct, because that’s what official_name means. The US government, one of two countries encircling it, officially calls it “Lake America”. That’s why it’s official_name:en-US specifically, not official_name=. The name= key, the “primary name of the feature in the real world”, remains and will remain “Lake Ontario”.

It’s not the name that is likely to show when viewing the map

I’ll correct you and say that there’s no “likely” about it: it’s not the name that will be shown when viewing the map. That’s the name= key, which is “Lake Ontario”.

The remaining 0.4 stars are from those who failed assimilation.