iggldiggl

That's not actually true. True, with computerised technology it might be more convenient to implement it that way and it also allows some additional optimisations and bonus features, but it's not an absolute requirement.

At a minimum that's acceptable enough even by modern-ish safety standards, the signalling system only needs to know which sections of track are occupied and which are free, and it only needs to know that at the granularity of individual block sections between subsequent signals. It also doesn't necessarily need to know about the identity of the train, even though in practice you'll want to track that, too, for the convenience of the signallers.

The train in turn doesn't need to know where exactly it is – in terms of safety, it's enough knowing the local speed limit and the state of any upcoming signals, but for that, it doesn't need to know where it is in relation to the outside world. The classic implementation is simply fixed trackside infrastructure telling the onboard safety systems all they need to know.

Historically, any demands for knowing where the train is exactly in relation to the outside world were rather driven by automated passenger information systems and the like rather than the safety-critical parts of the signalling system.

One problem I've run into with that approach is that Akamai uses DNS for steering you to the correct portion of its CDN and the default servers you get from public DNS have abysmal peering with my ISP. So simply switching the default DNS in my router isn't enough, I'd actually have to run my own custom DNS resolver in order to special case Akamai there.

Not being logged in to Google and not keeping cookies between browser sessions, most of the time Google gives me the standard cookie permissions popup (where you can enable or disable search personalisation and targeted advertisting), but occasionally I seemingly at random I get the "we can't determine whether you're over 18 yet?" variant instead. I wonder what's causing it to flipflop between the two states…?

In a similar vein, there's also the Wireworld computer:

* https://www.quinapalus.com/wi-index.html

* https://wiki.logre.eu/index.php/Projet_Wireworld/en

The Windows emoji picker is also useful for entering all sorts of completely legitimate and well-respected typographical symbols…

> Some of the stations in the surrounding area are absolutely mental (Durmersheim for example), you have to walk over rails where ICEs and cargo goes through.

That's not the fault of the tram-train system, though - without the tram-trains, you'd still have the same platform access situation if you wanted to take the heavy rail regional train instead.

> Sure, technically the tracks are separated from streets, but every so often cars cross anyways or park etc. Those delays propagate to inner-city schedules.

I don't follow your point. It's not like the inner-city tram lines are all perfectly segregated from road traffic and no accidents ever natively happen inside the city limits.

Checking some random apps on my phone, it's very much not just games, and not just apps you'd naively suspect of being "heavily performance critical", either.

I suspect that code reuse of existing libraries not written in Java is another important use case.

In practice I've sometimes encountered that in the form of "either waive your right of withdrawal or else wait 14 days to download your content/activate your licence/etc.", though.

> Because nobody wants a .FLAC that starts with a few seconds of silence, inter-track gaps need to be appended to the end of the previous track

Side digression: For regular albums, where the pregap is just two seconds of silence I can absolutely understand that and prefer to put the pregap at the end of the previous song myself.

However for live albums my feelings are a bit more torn – on the one hand there is something to the music starting immediately when playing a random track, but on the other hand any stage patter that might be present in the pregap usually refers to the upcoming track, and having that incongruously stuck at the end of the preceding track is at least to me somewhat annoying during random playback, too.

There's also an intermediate category where an online/streaming version is available, but it's defective – a number of live Bob Dylan (!) albums from the Bootleg Series are missing the track transitions between the individual tracks. It feels like somebody forgot to include the pregaps when ripping the discs for digital distribution, and it's been like that for years…

It's arguable for modern rapid transit signalling systems, because those tend to be a bit more bespoke than mainline railway systems and you might not be able to switch to a different supplier without swapping out all the interlockings, and the trackside and train-borne equipment in one go, but for the trains I don't follow your point – switching manufacturers when ordering the next generation of trains is par for the course, and having the signalling system of your choice plugged into the train of your choice is standard procedure even on rapid transit and light rail systems.

Sure, but even in the US that infrastructure state is usually only found on minor branch lines (shortlines), not on the main lines.

Yes, those kind of track relaying machines exist, and they could most likely be adapted to work for the gauge change (one end of the machine would have to be set up for broad gauge and the other end for standard gauge), but they still manage only a few kilometres of track per day, and they're comparatively rare and expensive – basically there are only enough of them around for the amount of track relaying required during routine maintenance.

So repeats of the famous 19th century gauge change by converting large swathes of the network in just a few days (thousands of miles of track as in the US in 1886, or even just the 177 miles west of Exeter in the UK in 1892) remain rather unlikely.

While narrower gauges are somewhat more favourable to tighter curve radii, ultimately the difference is negligible enough that it can be ignored. At the extreme end of the range, curve radii for standard gauge trams can go down into the 10 – 15 m range just the same as metre gauge networks, and for mainline railways curve radii instead are usually limited by vehicle geometry and mostly line speeds (centrifugal forces), which (especially the latter) aren't related to the track gauge.

You're right about switches though – if you keep the rest of the switch geometry (angle, radius) the same (and to some extent you have to if you want to keep existing speeds across switches), the large track gauge alone will make the switch somewhat longer, which at least in complex stations with huge clusters of switches (like e.g. https://www.google.com/maps/@50.1039604,8.6563677,197m/data=...) could potentially cause some headaches.

> unless concrete sleepers are in use

Which they are, as even a quick search would have shown.

> There were a number of gauge changes, but they were usually quite early on, when the infra was less critical and you could get away with closing lines for months.

It was also a time when railways used wooden sleepers, so you could simply drill new holes at the new track gauge for moving the rail fasteners, thereby minimising the work required for changing the gauge, at least on the plain line, switches and crossings excepted.

Plus it was a time when a lot more manpower for that kind of massive manual work was available, plus railways were the dominant transport mode and could actually commandeer that kind of manpower.

But they are set into prefabricated concrete sleepers, which cannot be modified to a new track gauge and instead need to be swapped out completely. Whereas during the US gauge change, the railways used wooden sleepers, with the rails fastened simply with nails hammered into the sleepers, so it was simply a matter of pulling out the nails and hammering them in again at the new track gauge.

A ballast cleaner wouldn't be enough, because you basically need to swap out the sleepers, too, so you need a complete track-relaying train. And anything involving switches and crossings needs to be done conventionally, because those cannot be rebuilt by simply switching out the sleepers for standard gauge ones.

Where? Finland specifically, or elsewhere? Both my local tram system in Germany as well as DB as the national infrastructure operator in Germany have construction tolerances of only +/- 2 mm. Maintenance tolerances on the other hand can be quite a bit larger, at least in the plus direction (on the order of 15/20/25 mm).

> Train tracks are normally not precise to within 4mm anyway

Yes they are. Of course practical tolerances including allowances for wear and there are large enough that things can be made to work, but in terms of nominal construction tolerances for example, 4 mm can easily eat up all your construction tolerances or even exceed them.

> a 20 minute drive usually takes about 20 to 30 minutes due to the detours

That variability makes the whole system much less interesting once a change is involved, e.g. if the on-demand shuttle is only supposed to operate across the local area, but not for longer journeys traversing the whole city, especially if the connecting fixed-route transport runs less than every few minutes…

Or even without changes, but when you have some other external schedule constraints, because in those cases you always have to budget for the longer journey time, negating the benefit of direct routing somewhat.

> j-n: So... you go a day or two without a phone, replace it, and then things work again.

Which still is an option right now, where a lot of things haven't yet been app-ified, but if you follow "Why should we handicap new, shiny things to make them usable without a phone?" to the maximum, things could end up rather difficult in the future. Like if you've been commuting by public transport and public transport is no longer accessible without a smartphone, how would you continue going to work until the new phone arrives?

They did a study for a small- to medium-size town in Germany – based on traffic modelling, it was estimated that an extensive on-demand system with almost 500 on-demand vehicles would only have about the same effect on passenger numbers as simply extending all existing fixed-routes bus routes to run every ten minutes all day (which for a town of that size is a rather good service), but operating the fleet of on-demand vehicles was so expensive that even fully automated on-demand vehicles were significantly more expensive than driver-operated conventional buses (never mind automated conventional buses).

I think certain performance issues have persisted until today, though?

With file access, the sensible solution would have been of course to just overlay the permissions onto the regular files API (like I think every other sandboxing solution does), so everything that uses files could keep working as usual and you'd just have to add some limited code to request the appropriate permissions [1], but I guess that would have been too sensible, and when all you've got is a SAF, everything looks like a nail or something…

From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that, doubly so when you're using a library that expects regular files, plus performance is somewhat lacking, too (judging from complaints and bug reports I've seen, both in that it is easy to run into performance pitfalls, but also that even best-case performance is still worse than classic file access).

[1] I think something like that was actually implemented for Android 11 onwards, judging from https://source.android.com/docs/core/storage/scoped#using-sc...? Although possibly still at some noticeable performance cost.

> Android 14 doesn't support 32bit apps even when running on an older SOC

Huh? Tell that to my phone. Maybe Google dropped support from their own OS builds even for older phones, but I don't think AOSP as such has dropped 32-bit-compatibility yet, and other OEMs have kept 32-bit-support for those phones whose hardware still supports it.

(And at least one or two Chinese OEMs have been shipping some sort of compatibility layer for phones without hardware support, though possibly only for the domestic market, not export models/OS builds.)

It's true though that Google isn't too heavily invested in binary compatibility for native code, though to some extent their hand might have also been forced by the SOC manufacturers, because apparently 32-bits hardware compatibility is more expensive to provide on ARM.

There's that Paul McCartney anecdote how he thought he'd found the meaning of life during one of his first drug experiences and the next morning he found a piece of paper on which he'd written "There are seven levels".

As also pointed out in a sibling thread, there's https://apt.izzysoft.de/fdroid/ though, which is somebody's curated collection of apps with Github releases in the form of an F-Droid repository.

The main goal of SP, DKIM and DMARC wasn't to slow down spammers by setting up "bureaucratic hurdles", it was to prevent domain spoofing, though, and arguably it's succeeded at that.