One that Linux should’ve had 30 years ago is a standard, fully-featured dynamic library system. Its shared libraries are more akin to static libraries, just linked at runtime by ld.so instead of ld. That means that executables are tied to particular versions of shared libraries, and all of them must be present for the executable to load, leading to the dependecy hell that package managers were developed, in part, to address. The dynamically-loaded libraries that exist are generally non-standard plug-in systems.
A proper dynamic library system (like in Darwin) would allow libraries to declare what API level they’re backwards-compatible with, so new versions don’t necessarily break old executables. (It would ensure ABI compatibility, of course.) It would also allow processes to start running even if libraries declared by the program as optional weren’t present, allowing programs to drop certain features gracefully, so we wouldn’t need different executable versions of the same programs with different library support compiled in. If it were standard, compilers could more easily provide integrated language support for the system, too.
Dependency hell was one of the main obstacles to packaging Linux applications for years, until Flatpak, Snap, etc. came along to brute-force away the issue by just piling everything the application needs into a giant blob.
Only one of the interviewees said location. That would be key for me. If the theater was close by and integrated integrated into daily life, I’d probably go a lot more often. Instead, all of the theaters are way out on the edge of town, often in some grotty commercial area where the land is cheap enough for the obligatory huge parking lot. It’s a commitment to get there, as in, you intend to go to a movie and only to a movie, because there’s nothing else to do nearby. No dinner and a movie, no random matinee as a break from the office grind, no movie followed by hanging out with friends at the bar across the street. I might as well watch at home.