Its all a bit hand wavy nonsense. Own a physical copy? How long until its unplayable because either the media corrupts or the player isn't available? The only real "ownership" is the IP, everything else is just renting.
All information is ephemeral, but I don't honestly think that argument holds much weight here.
I'm currently listening to a record which was pressed before I was born, and that will outlast me. My CDs were ripped around 2000 to a drive and i've streamed then since. I've still got the CDs though, and the last time I played one it worked fine on my 1989 vintage transport.
The DVDs I got in my childhood 20 years ago still work just fine, the drives to read them are $20 or less, and ripping them to a format I can use more conveniently and backup however I want is a single button click.
Plastic discs are the optimum data distribution format. They degrade in the same time frame as a paper book, essentially lifetime, you retain legal rights like the first sale doctrine, you can easily format shift for safety and storage, and nobody can take any of that from you ever, and you can use that data however you like, as long as you aren't trying to sell bootlegs.
Books and plastic discs are infinitely better than the digital realm. The consumer rights are so much stronger and better.
Why wouldn't a player be available though? CD/DVD players won't just suddenly stop working. My CDs and CD players at home from the 1990s are still working completely fine.
If they do want to posit it as this, I'd personally be fine if they said "a CD will work for 100k plays before corrupting" so you'll have 100,000 credits to stream The Wizard of Oz before you need to purchase it again.
I trust the pressing on a CD or vinyl to remain readable SIGNIFICANTLY more than I trust any corporation to do literally anything, including "continue to exist".
Thats a pretty snarky thing to say about Apple. They were arguably the pioneers in OS UX... granted, its not the end all, be all, but still. You could do worse.
Who is "they"? The employees at Apple when the HIG was first published in 1986, 40 years ago? That Apple is dead, what you see before you is an empty and rotted husk.
When I began at Apple in 1995, we followed "Tog on Interface" to the letter. It was not uncommon to expect arguments over what the Right way was during lunch.
I watched as Steve Jobs came back to Apple—he really took hold of the reins of UX (aided by his team of designers).
Personally, (and I say this as it is often a matter of taste) I didn't care for a lot of it.
A simple example: the URL field of Safari should have been, to my Tog sensibilities, an editable text field only. Perhaps somewhere (below?, to the right?) you might include a progress bar to indicate the page loading. But a designer (I will not name, ha ha) came up with a combined textfield/progress bar. It looked to my eye as though, as the page loaded, the text was being selected!
Jobs loved it though.
It was then I think that Apple departed "Tog" for these "one-off" UX experiments.
I have rationalized this move away from a standard since, with the advent of the web, the customer is now being bombarded with all manner of UX—ought to be comfortable with one-off UX.
(Thankfully I see that now we have a thin line that seems to grow along the lower edge of the URL field.)
First is not the same as best. First is not even the same as good. First is only first. Just because someone was the pioneer doesn't mean they should be considered a positive example.
Introduced a concept decades ago in no way implies that their current implementation of the concept is at all ideal or market leading.
“I would argue that…” is a weaker statement, because it ends with an implied “…but since I don’t care that much, I’m not ‘seriously’ arguing that.” It’s not at all equivalent to the strong statement “I argue that…”, which has no such qualifier.
Why cure yourself of useful conversational nuance?
Even though I run it full time now personally; I still think Linux has massive problems something like Windows or macOS don't have: app development. You can't target a thing, you have to target all the things and bloat your app like crazy so you might as well just ship a chromium based app because its practically the same thing anyway (shipping an entire userland because its not stable anyway)
If there were instead 10 viable and competitive desktop operating system with no clear leader, and macos and windows were there just among the others.. wouldn't you try to target as many as you can? Maybe we can think of linux itself as a microcosm of OSes we never got to have, and you have to target as many variants as you can in order for no dominant force to emerge. It ain't pretty but its what we have..
The part of the "microcosm" that prevents you from being able to easily compile a binary and have it run on a wide variety of distros doesn't have any upside I can see. The fact that you have to jump through hoops to target particular glibc symbol versions and that a stable OpenSSL ABI gets rug-pulled in new distro versions every few years aren't key to any benefits of distro/OS diversity. What would suffer if gcc/clang had a `--min-glibc-version=...` flag and OpenSSL settled on a long-term stable ABI subset for establishing TLS connections?
The way this all gets worked around is that people come up with stuff like Docker or Flatpak that ship their own copies of as many dependencies as possible. The disadvantage is that now I can't just patch an OpenSSL vulnerability by updating the system's copy of OpenSSL, the way Windows can for all software built on SChannel.
This is just not true. You can still write GTK2 or SDL apps, you just need to package your app for the target distro or open source it because it's an open-source-first ecosystem.
If you're looking for binary stability and to ship your app as a file, ELF is extremely stable. If your app accesses files, accesses the network through sockets, and use stable libraries like SDL or GTK it will work fine as a regular binary and be easy to ship. People just don't want to write their apps in C, when the operating system is designed for that.
Many native apps like Blender, Firefox, etc ship portable Linux x64 and arm64 binaries as tar gz files. This works fine. You can also use flatpak if you want automatic cross platform updates but yes, the format is unfortunately bloated.
It's not that easy to ship a JavaScript app on other OSes either and electron apps abound there too.
What does ELF being stable or people not writing apps in C have to do with Linux binary compatibility? No matter what language you use, it’s either dynamically linking to the distro’s libc or using Linux system calls directly.
Also, I recommend taking a gander at what the Linux build process/linking looks like for large apps that “just work” out of the box like Firefox or Chromium. There’s games they have to play just to get consistent glibc symbol versions, and basically anything graphics/GUI related has to do a bunch of `dlopen`s at runtime.
Flatpak and similar take a cop-out by bundling their own copies of glibc and other libraries, and then doing a bunch of hacks to get the system’s userspace graphics libraries to work inside the container.
