Even apart from costs associated with proprietary software, the other reason to avoid vendor lock-in is to avoid self-propagating backdoors in the compiler. Ken Thompson described how to make such a backdoor with C in his 1983 "Reflections on Trusting Trust" speech. David A. Wheeler described "diverse double-compiling", a defense against compiler backdoors that relies on the existence of independent implementations of a language. Stable Rust doesn't have that because it's such a moving target, with widely used programs relying on language and library features less than half a year old.

See also "Reflections on Rusting Trust" by Manish Goregaokar

They knew this and decided to maintain Perl 5 alongside Raku (formerly known as Perl 6) for what is looking to be noticeably longer than the 11-year transition from Python 2 to Python 3.

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.

People expect to be paid for commute time too, at least in the sense that they will want more money if the commute is longer. Work from home made just coming to the office at all something which people want more money for.

$6 billion could do a lot to end hunger in many parts of the world. Instead, Musk bought Twitter and turned it into a hellsite, and told people to have more kids.

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

Knowing them, they hired some AI wiz kids who wanted to move fast and break things. Meanwhile the poor engineers who are slowly making really important and valuable improvements to the core browser aren't getting any help. Maybe some vibe coded Javascript engine updates are next on the list.

You can't trust these billionaires. Musk said if someone explained how he could end hunger for $6 billion, he would do it. He was presented with a credible plan by the United Nations' World Food Program, and quietly forgot about it his promise.

This feels self serving. What are the chances that if they discover some miracle cure for cancer, they charge top dollar for it?

Clearly some of their customers want EV trucks. But why don't more of them want them?

Could it be because Trump doesn't like EVs, and because Republicans have done everything they can to stifle installation of the infrastructure that makes owning an EV convenient?

It seems to be the way they went about it, as much as anything. The volunteers would probably have accepted first drafts created by AI, or suggestions for changes, but Mozilla just overwrote their work, bypassing them entirely.

It's about half the size of the larger cargo ships too, but still quite competitive. I'm sure they can scale up, Running costs should be lower due to less fuel use (it still uses some around ports).

Speed isn't such a big deal for this sort of thing, that can be worked into the logistics. Maybe they will have drone ships eventually anyway, so it's not even costing any more in wages.

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...