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

Problem is, I strongly suspect we'd still be having the same discussion even if we were talking about "allow the user direct access to all files*" instead of "allow the user full root rights".

Because while some of those missing capabilities are "simply" a matter of it being too much effort to provide a dedicated capability for each and every niche use case (though that once again raises the question as to whether you prefer failing open, i.e. provide root as an ultimate fallback solution, or fail closed), with file access I guess that this was very much an intentional design decision.

https://publications.rwth-aachen.de/record/95066

So large, text-heavy pages don't seem too unlikely to exceed 250 kB, especially if they also include some amount of formatting that's more substantial than just a minimal bunch of

tags.

(Some sort of way to store permission references with relatives paths in a file, but which most probably wouldn't work with files being exchanged cross-platform, and other than that mainly being able to get automatic access to 'related' files, i.e. same file name, but a differing extension – that solves some sidecar files, like video subtitles, or certain kinds of georeferenced images, but large capability gaps still remain – even the video subtitle example stops working if the file name is no longer 100 % the same, like if you have multiple subtitle files for differing languages, where VLC for example supports prefix-matching the video file name with the subtitle files.)

And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.

The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)

So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?

Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.