iggldiggl

openBVE's not directly Japanese, it's an open-source re-implementation of the original BVE 2 and 4, which is.

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.

or live closer to work

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.

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

[4] PhotoLine

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.

Also time references in stories would become much more cumbersome, and never mind how you'd handle fictional locations…

If you can read German, somebody also wrote a whole dissertation on the subject of the CD's development history:

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

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.

See https://www.thecontactpatch.com/ for some interesting reading material related to that.

Those are for the opposite problem – detecting defective trains (overweight respectively otherwise faulty weight distribution as well as wheel flats).

I vaguely recall it not being compatible with either 25kV electrification or high-speed rail in general, and most modern tracks therefore using axle counters instead.

Track circuits aren't incompatible with that per se, but axle counters are simply easier to install and much more maintenance-friendly – no longer having to worry about

- mixing track circuit currents and traction return currents together

- having to keep the rails sufficiently isolated from the ground and each other to prevent the track circuits from falsely showing occupied

- insulated block joints

- having to use each bit of track once every twenty-four hours to prevent rust from falsely showing a track as clear

- extreme leaf fall and/or sanding potentially causing false clears, too

- length restrictions on the maximum length of a single track circuit, although that's only really a problem on more sparse trafficked lines with long block sections

In return, axle counters have the drawback that they

- don't detect broken rails (although it needs to be said that track circuits very much aren't perfect broken rail detectors, either)

- can be falsely reset (with more or less protections, depending on local operating practices)

- don't detect maintenance vehicles freshly placed upon a track until they enter the next axle counter section

but since most to almost all new installations seem to use axle counters, the trade-offs are apparently worth it to infrastructure operators.

Airplanes might be designed in mm, but airports are most likely designed in metres, and whoops, suddenly you need to convert between the two.

Actually civil engineering as a whole is probably a relatively mixed bunch – vehicles drawings (when you need to design the infrastructure to fit specific vehicles for example) and other small-scale details might be dimensioned in mm, the standard curbstone naming system in Germany is based on centimetres, while infrastructure design itself (definitely including the CAD drawings) usually works in metres.

Vehicle drawings (maybe mechanical engineering in general) might be in millimetres, but a lot of civil engineering works in metres, so when designing some bit of infrastructure to fit certain kinds of vehicles, I do need to convert between the two, and the easier, the better.

Nobody forces you to use the peer DNS.

For practical purposes there's the problem (at least a few years ago?) though that Akamai in particular uses DNS to steer you to the correct portion of its CDN and the default IPs returned by independent DNS resolvers tended to have relatively abysmal peering with the Telekom network that was getting completely overloaded at peak times.

Unfortunately "use <insert favourite DNS provider here> everywhere except for Akamai CDN, for which use the Telekom DNS" isn't something that consumer routers support, so you'd have to start running your own custom DNS resolver to work around that problem…

Even in the US I'm doubtful about 2 minutes per mile being true for actual "city" driving if you live in a bigger conurbation.

Miles are great to estimate time of travel by car, take 1 minute per mile of distance on a highway and 2 minutes in the city and you will be pretty close.

That might be true where you live, but it's hardly a universal constant. 1 minute per mile might be sort-of-universal for long distance Interstate driving, but then again, you can just as easily phrase that as ~1 hour per 100 km in metric.

I'm rather doubtful about your 2 minutes per mile (= 30 mph average speed) figure for "city" driving, though – how's that even possible when urban maximum speeds are usually in the 25 – 40 mph range, and that's not counting time lost for traffic lights and other intersections, general congestion and parking?

Checking a few destinations around where I live in Germany, non-Autobahn cross-country driving is closer to 2 minutes per mile rather than 1 minute per mile (and highly variable depending on your exact destination, so no point trying to estimate driving times to the nearest minute, anyway), and never mind actual urban driving.

On Exactitude of Science - Borges.

And based on that in turn, Umberto Eco's "On the Impossibility of Drawing a Map of the Empire on a Scale of 1 to 1": https://s3.amazonaws.com/arena-attachments/881694/cb6119367b...

Thanks for linking that page, interesting rabbit hole that I hadn't heard about until today…