Such as high-resolution image editing and high-definition video editing. Compared to a web browser, these aren't quite as amenable to splitting an application into numerous "content processes," each with their own separate 2 GB RAM.

For a while, Linux supported an x86-64 ABI called "x32" that limits each process's address space to 2 GB so that more pointers will fit in the processor's data cache. It didn't become popular, in part because of a need to load three versions of the system libraries: 32-bit i686, x86-64, and "x32". In addition, porting x86-64 applications to use less pointer-heavy containers gave most of the cache advantage that "x32" would have provided. This includes switching from linked lists to gap buffers (or other dynamic arrays), from B-trees to T-trees, or from pointers to indices in a pool. Rust in particular has encouraged use of appropriately sized indices as a workaround for the borrow checker.

There's a widespread misconception that a 32-bit operating system is limited to 3 GB of physical RAM. I think this comes from Microsoft's practice of requiring drivers for 32-bit Windows Server to support PAE as a condition for certification, but not drivers for 32-bit Windows desktop. I seem to remember 32-bit desktop Linux being more PAE-friendly. PAE and content processes are how Firefox for 32-bit Linux managed to hang on this long.

Each function could be loaded the first time the user uses it. The device has to be online to query what is in stock at any given moment anyway. And I'd be interested in others' speculation about why the client side of the most widely used functions can't all fit in (say) 5 MB, which is twice the size of Doom.

I accept that, adding a clarification that I suggested the solution for the purpose of asking other people what these companies might know that I don't.

Wikipedia officially requires articles to summarize their sources from a neutral point of view. However, Wikipedia did become overtly political with the PROTECT IP blackout of January 18, 2012, in protest of a proposed law seen to threaten Wikipedia's existence.

The first time you add a website to your home screen, it installs the website's service worker. You have to use the Internet for that, just as you have to use the Internet to download an application from Apple's App Store.

And I'm curious about what the blockers for even a partial PWA implementation have been during each of these 12 years.

All I've been asking is what features of Grab combined with missing features of PWA likely led to their continuing to choose native apps.

I don't see where I "assume[d] to know better than Grab".

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.

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.

China calling Elon. Come in, Elon! :)

bah.

Let me know when they start making *autographic* 120 film again. I have the camera, and am dying to shoot a roll!

The last rolls were apparently made in 1932. The cameras had a flap that could flip up and allow writing directly onto the film with a stylus. When you see handwriting on an old picture print, it was likely shot on autographic.

[and, yes, in fact my autographic camera *does* have bellows!]