OSM has a lot more data inside than the website shows - in dense shopping areas you can’t zoom in far enough to see all the POIs, much less business names.

I’ve read before that using cached previews was done to stay accessible to less-powerful mobile devices, which would have smaller CPUs that would be taxed by rendering the native vector data. I view it as a branding disadvantage that OSM appears, from desktops, to have less info than alternatives. But that’s a battle that’s been had many times before, one might as well argue over paper vs plastic.

The main URL points to this:

It exists, it’s called a robots.txt file that the developers can put into place, and then bots like the webarchive crawler will ignore the content.

the internet archive doesn’t respect robots.txt:

Over time we have observed that the robots.txt files that are geared toward search engine crawlers do not necessarily serve our archival purposes.

the only way to stay out of the internet archive is to follow the process they created and hope they agree to remove you. or firewall them.

https://blog.archive.org/2017/04/17/robots-txt-meant-for-search-engines-dont-work-well-for-web-archives/

Our map data is often downloaded and used offline on various devices for several weeks or months. For offline data to be useful, it should at least be expected to remain unchanged in the next few weeks when you map it.

yes, by this blurb, concession for offline users does supersede safety.

i’m an editor active enough to have been granted foundation membership but hadn’t known this rule; it indicates a view of osm as analogous to a paper map rather than for real-time navigation. if a change of less than weeks’ length is discouraged, i can’t in good conscience steer my friends away from google maps, as navigation is not a primary use case.

it is common practice in the u.s., at least, to use two nodes for big chain drugstores, where the shop, marked chemist, often has wildly different hours from the pharmacy. they have the same name and much of the same info

appimages just got less easy…

i don’t know which update did it - i think it must have been os-level (i run pop_os, derived from ubuntu) - but appimages silently stopped working. double-click, nothing. finally i looked in the log out of desparation, which said ‘appimages require fuse’.

more accurately, appimages require fuse 2 and the os had just upgraded to fuse 3. the fix is to heat-seek libfuse2, and don’t mess with any other fuse-related package as things can start wrecking themselves:

sudo apt install libfuse2

originally seen on an omgubuntu post

this is true. having said that - i follow a peertube-based french outfit called blast (can’t speak french, just look at the pictures). if i go to a different site (peertube.stream, liberta.vip) and look at a video, the streams are coming off video.blast-info.fr.

there’s no question video is a huge resource suck, and that nobody would want to host a lot of other people’s videos. i just wonder, if the model is federated indexes but owner-hosted video, i wonder if there’s a use case that can work at scale.

against which kitchen pots have proven surprisingly useful elsewhere. against all odds