i’m no expert — consensus sounds like putting disused only on the main tag, and when i’ve encountered this, i haven’t marked anything disused at all. i’ve only looked at the stop/platform to make sure they weren’t in any relation (transit line relations may include the passing way but shouldn’t include the disused stop/platform). and i make sure route_ref isn’t set on the stop/platform. were the stop to be used again, i figure it would have the same ref/stop id and operator, so i don’t remove them. listening for better ideas though

I’m torn, because on the one hand, yes! — the hour I spent figuring out which PGP XEP was the right one is an hour I won’t get back. But, “only the XEPs you need to implement for a modern messaging application, ignoring historical cruft and excessive backwards-compatibility” sounds so much like the beginning of an extend-and-extinguish cycle.

thank you… more of a thought experiment now than a true need, but it seems like if it became a need, i’d be better off building a matrix account. i suspected this but had hoped for more :/

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’s perhaps interesting to see what existing apps ZipoApps has on the Android Play Store.

if your threat model were ‘encrypt everything at rest’, invitations to people outside your own service would be tricky as they have to be machine-readable text in a specific format. i’m sure it’s possible but you’d have to be specific in looking for that as a feature.

my needs are more modest - don’t store email in GAFAM or particular regimes - and i use runbox, which is bog-standard except for being stored somewhere else, being paid, and having slightly more homely webapps. using ‘evolution’ on linux, a bog-standard email program that’s also a bit more homely than alternatives, invitations go out to whomever i choose and look normal. i make recurring events for myself all the time and remove individual occurrences. i’ve added on ical subscriptions for things like country holidays, which are the first thing you’ll notice missing when you leave outlook.

the mail’s just imap and the calendar’s just caldav. when you get into providers that don’t provide imap or caldav for (valid) security reasons, that’s when you’re more likely to get integration issues with regular people.

again not foss so won’t dwell at length — but i use fund manager from beiley software. commercial, but works double-entry and handles more investment complexity than a human could ever need. windows app, i run it under wine on linux and crossover on mac. (i don’t own a windows box — that’s how irreplaceable it was for me.)

i am not sure it’s a flaw at all. the conditional tag syntax is based on opening_hours, which should be able to express ‘closed at these times until that date’. there are ways to finesse this. but as long as the published guideline is ‘don’t do this’, there’s little point pondering practical solutions.

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

looks great! the catch for me is that my current host doesn’t have docker support. your dependencies don’t look crazy so in theory i could burst it and install directly to the host environment, but at that point i’m giving myself grocy-level headaches.

reading about docker-capable hosts, i was surprised to see them starting at 1GB RAM - i couldn’t run pac-man in that. what would be a reasonable expectation for kitchenowl?

i haven’t tried the docker route - it seems fairly new. it also doesn’t seem like it would fix the issues i ran into. containerization is great for insulating the app from external dependency hell and environmental variation. but the problems i’ve had involve its own code and logic, and corruption of a sqlite database within its own filesystem; wrapping issues like that in a docker container only makes them harder to solve

osmand has great map support. real-time nav for transit isn’t an osm strength - i haven’t seen an osm app that integrates live traffic or transit

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

i’d never heard of this concept! i have a disorganized stack of markdown files - notes, to-do and packing lists - that this looks ideal to tame

thanks to this post, i’m trying out searxng and then kagi, neither of which i knew. hopefully there’s a searx instance configured roughly to how i’d want. i’m not philosophically opposed to paying, but search is a delicate thing to be personally identifiable - and i don’t care what your privacy policy is, if you’re taking my money, you can connect me with my clicks

is that somewhat new?

it’s somewhat… janky.

you can ‘migrate’ an account, to use the masto term that will make it easier to search. this:

• makes it so your old account can’t post
• puts a ‘pointer’ on that account so that you get its mentions (i think)
• puts a note on that profile that you’re really you-at-new-place now
• causes all accounts following you to auto-follow the new place

it does not:

• remove you-at-old-place from other people’s follower·ing lists; old you eventually shows as dormant, but you’re still in their lists until and unless they clean house
• take any posts with you; you-at-new-place starts with an empty profile
• copy over any profile information
• copy over any post filters

i’m not clear on how long your old posts linger at old-place, and you might have to export/import your following list.

it’s possible, i’ve seen lots of people do it, but it gets more unappealing the longer you’ve been actively using the account. unless you’re like me and have posts set to self-destruct within days. and you can imagine the difficulty of actually moving the posts - if i were an avid shitposter and i moved house to noshit·social, then all my garbage would be dumped in the yard in violation of policy.

this political stuff is a mess that i hadn’t been aware of when i jumped into this ecosystem. the two fortunate things are

• that tankie stuff is stuff i don’t see in /all, and if they’re just unreasonably disappearing content, i wouldn’t have known what was missing; and
• i arrived in an instance whose admin’s main and self-proclaimed myopia is being a swiftie, which completely lacks the global thermonuclear war of tankie, though the incoming could eventually be a different tune

i’ll definitely be watching for this though, and wonder if it will become like masto where they actively try to funnel all noobs into their instance

mastodon struggled with scaling in the beginning, everytime elon strung more than four syllables together. a lot of admins there didn’t know what the spikes would do - this is not a criticism, i would have had no idea either - and most new users piled into one or two big instances, as is happening here.

the more tech-savvy of the initial waves migrated to smaller instances, the instance admins figured out where the pain points were, and i think there were changes to mastodon itself. i expect all of these are coming for lemmy, and it’s going to be lumpy here for a while just as it was in masto.

having lived through that, i came into a smaller instance here immediately. federation issues here are a bit gnarlier than on masto, but i trust that also will be sorted.