The most prolific poster on my Mastodon feed is a retrocomputing enthusiast who uses a decades-old (pre-Intel) Macintosh PowerBook G4 as their daily driver.

GCC has tended to support more historic instruction sets than LLVM. If a device's instruction set is supported by GCC and not by LLVM, it can run programs written in C, C++, Fortran, and other languages supported by GCC. It can also run programs in an interpreted language whose interpreter is implemented in a language supported by GCC, such as Python and PHP last I checked. It cannot build programs written in languages supported only by LLVM and not by GCC, such as latest stable Rust. What keeps gccrs (the Rust front end of GCC) from entering production is that the Rust language is still a rapidly moving target, with popular programs routinely requiring features added to the language or the standard library less than six months ago.

The service worker API is explicitly designed to avoid downasaurs in "offline-first" use cases. It acts as a proxy to serve the shell document, style sheet, scripts, and stale data, even without an Internet connection. That's why I asked what obstacles there are other than a downasaur.

I have not presented my ideas to Grab because I am not a user of Grab. I would imagine that most readers of Slashdot are likewise not users of Grab.

I was expecting someone who has used the product to help others in this discussion understand why Grab probably chose and continues to choose to develop iOS apps instead of PWAs. The answers might have taken the form:

A. PWAs weren't capable enough 12 years ago for X, Y, and Z reasons, are now, and the engineering resources to port the native app to a web app would exceed the cost of acquiring and maintaining Macs capable of running the latest macOS
B. PWAs still aren't capable for X, Y, and Z reasons

And the right decision would be for phone operating system publishers to provide functionality in the included web browser to let a website act as a progressive web application. Safari for iOS has a history of lagging behind other platforms' browsers in PWA features.[1] This is particularly evident with respect to what the browser allows websites to do in the background. For example, Apple implemented Push API seven years after Mozilla did, and it requires the user to add the website to the home screen to enable PWA features.[2] Do you want Nintendo Music to pause when you switch to another application? Or if you've chosen to let Nintendo's website notify you when something becomes available, do you want to miss the notification if Safari suddenly decides that your domain's notifications shall be silent (without vibration, without sound, and at the bottom of the list)?

[1] "Progress Delayed Is Progress Denied" by Alex Russell
[2] "Push API" on Can I use...

With two exceptions I can think of. Correct me if I'm wrong, but as I understand it:

1. For lightweight web hosting, a low-end VPS from a company like DigitalOcean is likely to be less expensive than upgrading a home office from home-class home Internet to business-class home Internet to unblock inbound ports 80 and 443.
2. SMTP is still an old boys' club, with major mailbox providers (such as Gmail and Outlook) blocking connections on port 25 from on-premise IP addresses as likely sources of spam.

The alternative is developing a progressive web application (PWA) that runs in Safari instead of a native iOS application.

Does "too lazy" include no budget for a domain name before the proof of concept is complete? Let's Encrypt doesn't work unless you buy a domain name and keep it renewed. To satisfy a DNS-01 challenge, you need to host the domain's DNS at a provider with an API that an ACME client can use. To satisfy an HTTP-01 challenge, you need to be on an ISP that allows incoming connections on port 80. A lot of home ISPs block inbound port 80 because they use carrier-grade network address translation (CGNAT) or want to upsell business-class service or both. Nor does HTTP-01 work for wildcard certificates.

For sure. And that's why I think it's important to distinguish harm caused despite good intentions and reasonable practices being followed from harm caused because someone did not follow reasonable practices or actively chose to cut corners.

Just my personal opinion, but given the track record in this particular industry, I think there should be demonstrable intent by decision-makers to follow good practices, not merely a lack of evidence of intent to circumvent or cut corners. This is expected in other regulated industries, compliance failures are a big deal, and for good reason. I see no reason why similar standards could not be imposed on those developing and operating autonomous vehicles, and every reason they should be given the inherent risks involved.

Maybe this will be an area where the US simply gets left behind because of the pro-car and litigious culture that seems to dominate discussions there.

Reading online discussions about driving -- admittedly a hazardous pastime if you want any facts to inform a debate -- you routinely see people from the US casually defending practices that are literally illegal and socially shunned in much of the world because they're so obviously dangerous. Combine that with the insanely oversized vehicles that a lot of drivers in the US apparently want to have and the car-centric environments that make alternative ways of getting around much less common and much less available, and that's how you get accident stats that are already far worse than much of the developed world.

But the people who will defend taking a hand off the wheel to pick up their can of drink while chatting with their partner on a call home all while driving their truck at 30mph down a narrow road full of parked cars past a school bus with kids getting out are probably going to object to being told their driving is objectively awful and far more likely to cause a death than the new self-driving technologies we're discussing here. You just don't see that kind of hubris, at least not to anything like the same degree, in most other places, so we might see more acceptance of self-driving vehicles elsewhere too.

IMHO the only sensible answer to is separate responsibility in the sense that a tragedy happened and someone has to try to help the survivors as best they can from responsibility in the sense that someone behaved inappropriately and that resulted in an avoidable tragedy happening in the first place.

It is inevitable that technology like this will result in harm to human beings sooner or later. Maybe one day we'll evolve a system that really is close to 100% safe, but I don't expect to see that in my lifetime. So it's vital to consider intent. Did the people developing the technology try to do things right and prioritise safety?

If they behaved properly and made reasonable decisions, a tragic accident might be just that. There's nothing to be gained from penalising people who were genuinely trying to make things better, made reasonable decisions, and had no intent to do anything wrong. There's still a question of how to look after the survivors who are affected. That should probably be a purely civil matter in law, and since nothing can undo the real damage, the reality is we're mostly talking about financial compensation here.

But if someone did choose to cut corners, or fail to follow approved procedures, or wilfully ignore new information that should have made something safer, particularly in the interests of personal gain or corporate profits, now we're into a whole different area. This is criminal territory, and I suspect it's going to be important for the decision-makers at the technology companies to have some personal skin in the game. There are professional ethics that apply to people like doctors and engineers and pilots, and they are personally responsible for complying with the rules of their profession. Probably there should be something similar for others who are involved with safety-critical technologies, including self-driving vehicles.

The perfect vs good argument is the pragmatic one for moral hazards like this. IMHO the best scenario as self-driving vehicles become mainstream technology is probably a culture like air travel: when there is some kind of accident, the priority is to learn from it and determine how to avoid the same problem happening again, and everyone takes the procedures and checks that have been established that way very seriously. That is necessarily going to require the active support of governments and regulators as well as the makers of the technology itself, and I hope the litigious culture in places like the US can allow it.

Step two is a GM app store
Step three is subscriptions for all the apps in your car. Cruise control? There's an app for that. Aircon? App for that too.

Buy a second hand car? You'll need to pay for all the options the original buyer already paid for.

In the mobile space this is basically why Valve (unlike their competitors) is not releasing a new console with slightly bumped up specs every few months, or why the line-up of Steam Decks only vary in specs (storage, screen type, cosmetics) that don't affect performance (same APU for all, the gains from the newer process used in newer OLED's APU is used to reduce power consumption, not make the APU go faster. The entry level and the top of the line Steam Deck will give you the same FPS) (unlike, e.g, Ally vs Ally X which have different APUs).
This means that the Steam Deck has been a stable target to optimize for.

(And the Steam Deck is also useable as a portable computer, too).