> This is what happens when the market for phone batteries only exists for OEMs who buy millions at a time, custom.
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…
No indoor smoking makes a major difference, but there still are enough semi-stationary semi-close-up situations where smokers can be still rather annoying, e.g. outdoor seating in cafes and restaurants, popular lunch break spots in parks and plazas, public transport stops, next-door neighbours… And even if you manage to position yourself upwind of all pre-existing smokers, there's no guarantee that a few minutes later somebody upwind of you suddenly won't light up…
Another crucial difference is that energy supply (as in selling energy to end users – physically providing electric energy to the grid on the other hand does require sufficient physical transport capacity in some ways) and internet access are much more virtual things – the mere existence of an additional company offering those services doesn't directly congest the infrastructure as such.
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.
> Unused memory is wasted memory. 77% is basically caches + private process memory + shared memory.
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.
> The deep tube lines will all get variations on the 2024 stock
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 never actually seen 230 V, the supposed standard, in real life.
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.)
With Android that's definitely not the case. Supporting older phones might get harder over time because you can't use any new APIs introduced in more recent OS releases, respectively always have to provide some fallback code path, and occasionally (at least if you want to publish on the Play Store) you're forced to use the new APIs, so you can't avoid the complexity of supporting both old and new APIs.
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).
The other factor would be driving away potential users – even when giving away an app for free, some people might derive satisfaction from knowing that other people find it useful and are actually using it, too.
> And every time a car makes a turn, pedestrians automatically have priority. Which creates an implicit zebra crossing.
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.
Also if your software for whatever reasons is using the original libjpeg in its modern (post classic version 6b) incarnation [1], right from version 7 onwards the new (and still current) maintainer switched the algorithm for chroma up-/downsampling from classic pixel interpolation to DCT-based scaling, claiming it's mathematically more beautiful and (apart from the unavoidable information loss on the first downscaling) perfectly reversible [2].
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.
I poked at the app, which surprisingly enough isn't even obfuscated, and as far as I can tell, it's mainly relying on Play Integrity's verdict. I didn't investigate it in detail though, so I don't know absolutely sure if that's really all or whether they're also running some additional custom checks, and I also don't know which integrity level they're requiring.
Sarcasm aside, it depends on whether your employer has configured Entra to allow classic TOTP (in which case Microsoft will try to push its own app as the default option, but you can in fact use anything that supports TOTP if you insist), respectively has set the option to only allow Microsoft's proprietary 2FA, which only works with the Microsoft app.
> That is an issue with the capabilities the os exposes to you. The answer to every security issue not "add a backdoor".
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.
A transcript for a half-hour radio comedy show with some formatting takes up about 60 kB. The English Wikipedia page for Monty Python is about 130 kB in pure UTF-8 text and the actual HTML page takes up around around 660 kB (plus/minus, depending on which Wikipedia theme exactly you use).
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 <p> tags.
I think Apple's implementation in macOS is the only one that offers some slightly more advanced features, but even those don't get you that far
(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.
> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside.
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.