How do people discover these services and these free-culture-supporting bands in the first place? Not everybody has a data plan
You must not be an American. Due to poor or nonexistent public transit in much of the United States and a perception that public transit is for people with poor hygiene, a lot of American workers end up driving a motor vehicle to and from work. You can't wander YouTube while driving, and even if you can take good public transit, you still need an expensive data plan to do so on the commute.
This means people keep discovering RIAA bands through the convenience-by-default of in-car FM radio.
There is an ancient device called a radio that plays all manner of music
In my experience, a radio doesn't "play all manner of music". It plays only music published by labels big enough to afford payola, and this music is inevitably non-free.
I am meaning, all the way back to when Apple started running the Apple 2 Clonemakers out of business with lawsuits.
The only reason those lawsuits happened in the first place is that the Monitor ROM (the BIOS of the Apple II) used entry points at fixed addresses in $F800-$FFFF. Fixed entry points mean that the implementations of BIOS routines have to be the same length in bytes as the existing routines, which pretty much ensures that only one specific copyrighted implementation will work. The IBM PC BIOS was more easily cloned because it used a proper syscall mechanism.
Not to mention the increasing popularity of copyright free music such as found on streaming services like Jamendo and Magnatune
How do people discover these services and these free-culture-supporting bands in the first place? Not everybody has a data plan, a car stereo with an AUX input, and the motivation to keep plugging an audio cable into the phone. This means people keep discovering RIAA bands through the convenience-by-default of in-car FM radio.
The move to 64-bit CPUs is more akin to the SNES using the 65816 as opposed to the NES' modified 6502
If you know what a "PHK PLB" is,* you'll see how the 65816 is still very, very PAE. The 65816's address space is 24-bit, but a machine register can hold only a 16-bit pointer, so pointers to anything bigger than 64 KiB have to be manipulated in a 3-byte variable in the stack frame.** The 24-bit address space on the 65816 is more like the "segmentation" on an 8086. I'd amend your claim slightly: the move to 64-bit CPUs is more like the move from 65816, Z80, or 6809 class CPUs to the 68000 family.
PAE seems closer in concept to the myriad of NES mappers that still give emulator authors and preservationists headaches.
* 65816 mnemonics to push the code segment (K) and pop the data segment (B).
** The stack frame or "direct page" replaces 6502's zero page.
Let's also not bring PAE into the discussion at all, since it's an x86-exclusive kludge
If ARM Cortex-A15 supports 40-bit PAE, I don't see how it's so x86-exclusive.
A 32-bit device can address 48-bit memory addresses with PAE.
Provided you're willing to split your application up into hundreds of processes, each responsible for managing a few GB of RAM.
If Verizon is the only carrier with reliable data coverage in one's area
This is Verizon Telecom (eg FiOS) not Verizon Wireless.
Same diff. In the wired market, the other carrier is cable. There are places that can get service from Verizon but are unserved by cable.
A great deal of effort has gone into the design of these Mobile OSs to free the users from having to be concerned with where their files are stored
Right now it's either on the device or in the cloud. And users have every right to be concerned because unless one subscribes to broadband at home and happens to be at home, files in the cloud are limited to a couple GB up or down per month. Does the OS attempt to hide whether files are in iCloud vs. Dropbox vs. Google Drive vs. the service formerly known as SkyDrive? If not, then inserting a memory card could be handled like logging in to one of these online storage services.
FORTUNE'S FUN FACTS TO KNOW AND TELL: #44 Zebras are colored with dark stripes on a light background.