- iggldigglThanks for linking that page, interesting rabbit hole that I hadn't heard about until today…
- Yup, although who knows when/if ever shared hosting adds support for that, too. Still, at least it's something, that's true…
- > Imagine some future hotel service trend where, right after the customer checks in, the checkin agent punches the customer in the face, by policy. I shouldn't have to check beforehand whether this is a "face punch" hotel or a "non face punch" hotel.
Reminds me of that Burkiss Way sketch where somebody wants to book tickets to a West End show, but they all involve the spectators being poked in the eye with a pencil:
https://www.buttercookie.de/The%20Burkiss%20Way/Transcripts/...
- > This is cheaper than most petrol cars.
Still somewhat more expensive than petrol cars in the same category, though.
- The problem is that this breaks down if you don't want to leak any obscure subdomains you might be using via CT-logs – shared hosting rarely supports DNS-based certificate renewals for wildcard certificates, and even less so for domains hosted by an external registrar.
(Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not as easy to set up as individual certificates for each subdomain.)
- > I know that read/write conflict concerns are what got USB Mass Storage mode removed from Android, but surely there's some way to resolve that.
Depending on whether the respective kernel supported it, you were still unofficially able to switch removable SD cards into mass storage mode (though only with a rooted phone), although somehow, even if I remembered to officially unmount the SD card from Android first, it somehow still often led to mild filesystem corruption (luckily never anything fatal, though) that required regular chkdsk-usage.
> Or they could have figured out a new version of MTP that supports basic features like concurrent access and normal metadata. Or they could have gone for SMB/NFS over a virtual network link.
My current phone no longer supports the above mass storage mode-hack for the removable SD card, which annoyed me enough that I actually wrote my own SMB server app (https://github.com/buttercookie42/SimbaDroid), because all other SMB servers for Android that I'm aware of were either outright broken, unsupported, buggy or fiddly to use. Sadly the only open source Java-based SMB server only supports SMBv1, so you're stuck with that, and you still need root for full comfort, but within those limitations it works quite nicely.
- Competition dynamics for air traffic are different. Railway infrastructure can only support a very limited number of competing companies before you run out of capacity, and especially on classic mixed traffic routes it is very easy to run out of capacity. Once that happens, rail operators have to start competing for paths instead of directly for passenger, which can definitely lead to misalignment of incentives.
On top of that, there's the problem that it's physically impossible to run competing services at exactly the same time. This means that for customers with schedule constraints (i.e. you need to arrive somewhere specific by a certain time at latest), competition becomes much less effective, because you're no longer able to freely choose among the competing operators, but are instead forced to simply take the train that arrives at the right time.
A similar thing is for journeys that involve changes of trains – it's physically impossible to have attractive connections (i.e. without hanging around the station for ages) between more than one or at most (if that) two operators per route, because trains running along the same line always have to be separated by at least two or three minutes.
With air traffic it's different. While airport and air space capacity isn't quite unlimited, it's still not as limited in the way a mixed traffic railway is. Plus a much higher proportion of air traffic is holiday traffic and other long-distance journeys where even a few flights per day would be considered frequent service, so competition is much less limited by that fact.
- > May be of note also that the best train in London (the Elizabeth line) is run by a tendering process
But that tendering is just internal between the state and the operator – fares and service levels on the other hand are set by TfL (and probably also the DfT to some extent, especially on the GEML and GWML sections).
- > despite taxpayer money investment logically dropping
Did it?
https://en.wikipedia.org/wiki/File:GB_Rail_Subsidy,_1985-201...
paints a slightly more complex picture.
- > The other is some of the ticketing options
And despite privatisation, a national fare system with through ticketing between operators was maintained.
- > In many European countries trains do make money.
Only if you discount the infrastructure subsidies, I think.
- > and if you maintain the roads to track standards they are just as comfortable
If you maintain a road to track standards, it's likely also just as expensive. (Definitely not cheap, because an intensive bus service will hammer a road quite nicely.)
- > Countless reviews have made it clear that essentially the only thing that BRT has going for it is lower up-front investment.
Plus maybe another legitimiate niche in developing countries where drivers' salaries are cheaper relative to capital investments cost.
- > AWS / TPWS are somewhat rudimentary and deployed - by far - not everywhere
I don't think that's quite true. AWS is rudimentary, true (only forces acknowledgement of warning signals, but otherwise no speed supervision, braking curves or trainstop functionality), but AFAIK deployed almost everywhere, the only major exception I'm aware of being some complex but slow-speed station layouts.
And TPWS… while it doesn't do everything that a truly modern train protection system could do, together with the British practice of long enough overlaps (i.e. an additional safety distance beyond a stop signal that needs to be kept clear, too, in case of an overrun) it's still quite reasonably effective at preventing dangerous overruns. And its deployment has been indeed more gappy, but AFAIK junctions and major speed restrictions, where the biggest risks are, are still quite comprehensively fitted. The biggest gap are automatic signals on the plain line, but then again there haven't been many accidents at those.
> If I remember correctly they do not even have something as basic as an electronic coursebook - which became mandatory in Germany in the 90s already.
Part of that goes a long way back. One of the most fundamental differences is that the UK still does route signalling, whereas Germany completely switched to speed signalling at the beginning of the 1930s.
Route signalling means that the signals indicate the route the train will take, but not the exact speed, so if you want trains to operate safely but without excessive dawdling, route knowledge is a must.
Whereas with speed signalling, the signals directly indicate the safe speed for proceeding, so route knowledge, while still useful and necessary for other purposes, is no longer quite as crucially relevant. Consequently, in the UK ad-hoc diversions without route knowledge are quite taboo, whereas in Germany, emergency diversions due to short-notice incidents are mostly (except for some specific lines with more complex requirements) allowed, albeit with a speed restriction of 100 km/h.
- The student/hobbyist account type will most likely literally only be useful for that strict purpose, i.e. very small-scale distribution to a known quantity of people.
I think it was mentioned somewhere else that that account type would require manually authorising each individual installation, so it'd still be useless for small freeware developers, who are only in it for the fun, too, but want to give away their software to everybody who might find it useful.
- Banning all apps signed by the same key is already possible. Requiring signing keys to be anonymously registered with Google would add some friction to simply rotating your signing keys when you get caught doing something naughty (depending on how much Google account creation and key registration can be automated against Google’s anti-bot protection, though), but definitely not as much as full identity verification and payment of 25 USD (even if that isn't foolproof, either, and has the annoying side effect of unfortunately slowing down small-scale freeware developers at the same time, too).
- > See that's what the intent system was originally designed to prevent.
> Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
On the one hand, yes, good point, but it runs into the usual problem with strict sandboxing – it works for the simple default use case, but as soon as you want to do more advanced stuff, offer a nicer UI, etc. etc. it breaks down.
E.g. barcode scanners – yes, technically you could send a media capture intent to ask the camera app to capture a single photo without needing the camera permission yourself, but then you run into the problem that maybe the photo isn't suitable enough for successful barcode detection, so you have to ask the user to take another picture, and perhaps another, and another, and…
So much nicer to request the camera permission after all and then capture a live image stream and automatically re-run the detection algorithm until a code has been found.
- Working in infrastructure design (specifically railways), cab ride videos are often useful to fill in gaps in as-built plans or the pictures you took on a site visit (you'll always miss out to photograph something that'll be of major interest later), especially in early planning phases. Plus there's the odd software tutorial video here and there, too, of course.
- … launcher shortcuts, launcher widgets, storage management, multi-process set-ups or even services (those need to be declared statically in the manifest), so yeah it would.
So interesting as a fun exercise, but not really useful for probably quite a few apps.
- > Yes, if it was a measure of device security they would revoke attestation of devices that are behind on security updates.
The new attestation system Google introduced recently (which I think also more strongly forces hardware-based attestation for phones that support it and is therefore more difficult to bypass) actually does that – the very highest attestation level requires running a security update not older than one year if I remember correctly.
What remains to be seen how much that'll get used in practice – users with rooted phones or custom ROMs are rare enough that a lot of vendors seemingly have no qualms excluding them, whereas users with outdated phones are probably a somewhat more sizeable number.
