And everybody's favourite, apps that have been region-locked to local-inhabitants-only, because foreign visitors don't exist, right?

> The problem is the tracking and invasion of privacy, and that all traces back to ads.

The other problem is, what happens when your phone breaks? With more and more things slowly becoming app-only or mandating smartphone-based 2FA, we're slowly getting to a point where when your phone breaks, you're going to have major difficulties buying a new replacement phone in the first place.

At least partially that's actually the law as well – the default mode for new rail-road crossings is mandated to be grade-separation, with exceptions to that rule decided on a case-by-case basis, though primarily only in cases of low traffic (which in case of roads means ≤ 100 vehicles/day). Plus in actual practice the federal railway authority also having a reputation for a strict interpretation of that paragraph and tending to not grant exceptions has also done its thing, so in practice new level crossing on the federally-operated railway network (i.e. DB) are indeed a total rarity.

If you want to use the standard port, that's only true as of very recently, though, see https://issuetracker.google.com/issues/218578943#comment17

Problem is when there's multiple stations nearby and which one has the quickest connection varies depending on when exactly you leave. In that case manually checking every combination of stations could be somewhat cumbersome, especially if there's a choice of stations at both ends…

And +1 to the lack of railway lines when zoomed out, indeed another annoyance along the above lines.

Even a few years ago when phones with replaceable batteries weren't that rare and I was in possession of one – by the time I started thinking about a battery replacement, offers of original OEM batteries usually seemed to have vanished into thin air and it was having to find out which aftermarket battery seemed reputable enough…

Trains on the other hand are decidedly physical things that take up a significant amount of space on the infrastructure, and they do so as soon you start offering the service, no matter whether people actually use it or not. This means that railway networks can only support a very limited amount of competing companies before you start running out of capacity to run additional trains, and it's especially easy to run out of capacity when you're talking about mixed-traffic railways where fast long-distance services intermingle with slower regional and/or freight services.

And as soon as you run out of capacity, train operating companies have to start battling each other for train paths instead of passengers, a situation that can have completely different incentives which aren't necessarily best aligned with passengers' actual interests.

Another difference is that competing trains obviously cannot run at exactly the same time, which again makes competition less efficient because trains running at differing times cannot be perfect substitutes for each other, which becomes relevant once you add passengers' external schedule-constraints (having to arrive in time for work or whatever appointment they might have and maybe cannot really influence) into the mix. (Long-distance leisure travel is probably less affected by that, because people are regularly willing to flex their schedules for that, but other kinds of traffic aren't as flexible.)

This effect then only gets magnified further once connections come into play, because with different trains along the same route always having to be separated by at least a few minutes, it's impossible to offer equally attractive connections between e.g. a branch line (which might run only hourly or half-hourly at best) and all the various hypothetical competing services on the main line.

Which means you also need to battle the housing problem, too, though, plus changes in settlement patterns take years to decades to manifest. In the meantime, you might have to weather quite some griping about it or even serious pushback.

In simplified overviews, Windows counts file system caches (standby memory) as free (respectively available) memory, so if 77% of 32 GB is to be taken literally, it still sounds rather on the high side.

I think that's a bit optimistic. Right now, the only thing that has confirmed orders is the replacement for the 1973 stock (Piccadilly line). The same order also has options for further trains which would cover the Bakerloo, Central and Waterloo & City lines, but somebody still needs to come up with the money for it.

For the Bakerloo line trains (1972 stock) that's probably going to happen, since those trains really are getting long in the tooth now, but for the Central/W&C line stock (1992 stock) there's currently a refurbishment programme underway, so depending on how that goes, those trains will probably continue running for a while further.

That still leaves the Northern and Jubilee lines (1995 and 1996 stock respectively), whose replacement trains, whenever they might happen, will probably need a new tender – it could be that whatever train gets selected then will be a close relative to the 2024 stock, but I don't think it's automatically a given.

And the Victoria line – that one only got new trains in 2009, so those will continue for quite a while further and will be the last ones due for replacement on the deep tubes.

I've just measured the voltage in a socket my home (Germany) and the multimeter says 231 V. (And it's nighttime, so no solar generation from houses in the neighbourhood potentially distorting the local grid.)

Plus if you're using any dependencies, you're also bound by whatever minimum API version all your dependencies are using. (Even Google's support library – on the one hand that one does try to somewhat smooth over the API differences between various OS releases and make your life easier, but eventually it'll also drop old Android API versions – on the conservative side, but eventually it'll do.)

But – if you're prepared to somehow work around all that, there's no hard cut-off, and a modern Android toolchain will still happily produce APKs that would run on by now very old phones, too.

Like e.g. I've taken an old app that had initially been developed during the Android 2.x era (around 2010/11) in order to fix a few annoyances and add some features. Since I didn't do any kind of radical overhaul of the original code so far, the resulting app happily runs both on modern phones (albeit with a somewhat older look-and-feel), but also on the oldest emulator image I could still get to work on my computer (Android 2.3.3 / API10 from February 2011).

Only for turning traffic, though, i.e. as a pedestrian you still need to yield to traffic coming from the side street. There was some talk of having pedestrians participate more fully in right-of-way-rules, too, i.e. if the side street has a yield/stop sign, traffic would have to yield to crossing pedestrians, too, but so far that idea didn't get anywhere.

The problem with that approach however is that DCT-scaling is block-based, so for classic 4:2:0 subsampling, each 16x16 chroma block in the original image is now individually being downscaled to 8x8, and perhaps more importantly, later-on individually being upscaled back to 16x16 on decompression.

Compared to classic image resizing algorithms (bilinear scaling or whatever), this block-based upscaling can and does introduce additional visual artefacts at the block boundaries, which, while somewhat subtle, are still large enough to be actually borderline visible even when not quite pixel-peeping. ([3] notes that the visual differences between libjpeg 6b/turbo and libjpeg 7-9 on image decompression are indeed of a borderline visible magnitude.)

I stumbled across this detail after having finally upgraded my image editing software [4] from the old freebie version I'd been using for years (it was included with a computer magazine at some point) to its current incarnation, which came with a libjpeg version upgrade under the hood. Not long afterwards I noticed that for quite a few images, the new version introduced some additional blockiness when decoding JPEG images (also subsequently exacerbated by some particular post-processing steps I was doing on those images), and then I somehow stumbled across this article [3] which noted the change in chroma subsampling and provided the crucial clue to this riddle.

Thankfully, the developers of that image editor were (still are) very friendly and responsive and actually agreed to switch out the jpeg library to libjpeg-turbo, thereby resolving that issue. Likewise, luckily few other programs and operating systems seem to actually use modern libjpeg, usually preferring libjpeg-turbo or something else that continues using regular image scaling algorithms for chroma subsampling.

[1] Instead of libjpeg-turbo or whatever else is around these days.

[2] Which might be true in theory, but I tried de- and recompressing images in a loop with both libjpeg 6b and 9e, and didn't find a significant difference in the number of iterations required until the image converged to a stable compression result.

[3] https://informationsecurity.uibk.ac.at/pdfs/BHB2022_IHMMSEC....

[4] PhotoLine