The part of macOS I miss when using a Linux desktop isn't how macOS looks, it's how you interact with it. • I miss the keyboard shortcuts. Not only what they a

The part of macOS I miss when using a Linux desktop isn't how macOS looks, it's how you interact with it. • I miss the keyboard shortcuts. Not only what they are, but also the strict conformity macOS apps have to using the same set of keyboard shortcuts for everything. (Did you know that Cmd+[ and Cmd+] work as "Back" and "Forward" in the Finder; in both Safari and Chrome and Firefox; and even in the iTunes Music Store views in Music.app? Did you know that Cmd+Shift+[ and Cmd+Shift+] work to move between tabs in literally every app that has tabs — including things you wouldn't normally think of as "tabs", e.g. the sheets of a spreadsheet in Numbers?) • I miss the Menu Bar. Specifically, I miss app menus in the Menu Bar. I know there are some themes with UI hacks that can trick Linux applications into disgorging their toplevel menu bars into some global faux Menu Bar — but that assumes that apps even have toplevel menu bars. Many Linux apps don't; they have top-level right-click menus, or top-level hierarchical modal navigation sidebars. And because of this, Linux apps also mostly just "have" keyboard shortcuts — toplevel window keyboard listeners. Whereas in macOS apps, all keyboard shortcuts are really keyboard accelerators for app-menu entries. Which means that everything you can do with the keyboard, you can also find in app's menu; the app's menu is an exhaustive access-point for all of the app's behaviors. And everything you can do in the menu, can be bound to a custom accelerator, or wired up with shell automation/scripting, or exposed to an accessibility device, or full-text-searched using the now-universal search box that appears under the Help app-menu. (Also, for those with not-so-tall screens, having the app's top-level menus pulled out into the Menu Bar means that if you 1. make an app full-screen and 2. set the shell to hide the Menu Bar when an app is full-screen, then you can reclaim the vertical screen real-estate of the app's top-level menu, with them just appearing — along with the rest of the Menu Bar — only when you hover the top of the screen. There'd be no sensible way to reclaim this same chunk of screen real-estate in fullscreened apps with internal top-level menu bars.) • I miss the carefully-thought-out filesystem organized around bundle directories. Apps are bundles; plugins are bundles; libraries/frameworks are bundles. There are no installers, no package managers; bundles just sit where they sit, and then their Info.plist metadata can be auto-discovered by the OS (through Spotlight indexing, gated by Gatekeeper allow-listing), and registered with weak-reference semantics. (That is: drop an app that opens filetype X onto your computer — suddenly that filetype knows it can open in that app. First time you actually try it, Gatekeeper notices you haven't actually said you trust the app yet, and warns you. Remove the app, and the filetype associations automatically get purged — they were technically just a cache/index of the app-bundle's Info.plist, after all, so if the canonical association entries go away, the cache entries go away too.) This also means that macOS "libraries" and "plugins" don't have to spew themselves across half the filesystem; they both just bundle everything up and present themselves as a single file — one that has no default interaction verb, and so "tucks its protected members away", without actually being inconvenient to dig into, the way a shared object with embedded resources would be. • A specific point of the above: I miss disk images. Not so much the ones apps come in — Apple themselves invented a better alternative to those with integrity-verified .xip files (with support, through Safari, for auto-self-extraction, and for auto-Gatekeeper-vouching when the archive is Apple-signed. Sadly these never spread to third-party support, and Apple themselves stopped using them in favor of just distributing things like Xcode through the Mac App Store.) Rather, I miss the deep UI integration with sparsebundle disk images. When I use macOS, I use sparsebundles for everything — they're technically disk images, but in practice, they just act like archive files, growing in size along with your usage rather than having a preallocated size. Unlike your average Linux loopback image, they're actually directories (bundles!) consisting of a bunch of 4MB "band" files. The "sparse" part is "sparse" like sparse-file support, but it works in a completely filesystem-oblivious way: the sparsebundle block-device layer notices whenever a given band would be updated to contain entirely zeroes — and just deletes the underlying band file instead. Mounting a sparsebundle that lives on a remote SMB share is the most low-latency, IO-efficient way I've ever seen of interacting with many small files (such as a remote git worktree.) It's no wonder macOS internally uses sparsebundle-mounts-over-SMB for Time Machine backups. (And they can be encrypted easily, too — not just with a custom passphrase, but also with a key held in a macOS Keychain — which doesn't have to be your default one!)