> There's a difference, in almost every piece of software, between closing the last window and quitting. In a browser, just pressing the "close" button would lose all your tabs, whereas "quit" will preserve them. That makes no sense to someone coming from Linux or Windows;

MacOS distinguishes between closing an application's window and closing the whole application. Therefore, closing the last window will not automatically close the application as well. Consequently, in a browser pressing the close button results in all tabs getting closed, with the browser still running. Quit however closes the whole browser and, hence, preserves the tabs. This is the action triggered by pressing the close button on Windows and Linux.

I can understand that this is counterintuitive coming from Linux or Windows. But it is a design-choice coherently implemented throughout MacOS.

I understand where it comes from, and in the days of floppy disks and 128KB memory, it made sense (I know, I'm that old). But it's been making progressively less sense over the last 30 years, with the advent of hard drives, faster hard drives, SSDs and GBs of memory.

It used to be the terminating a process you were going to reuse would cost you tens of seconds. That's no longer the case. The fact that it was a rational, consistent, design decision made 35 years ago doesn't mean it still makes sense. Apple killed the phone jack and the replaceable batteries, two things which are even older than that - things change.

I've been eaten by this when Firefox once didn't give me back all my tabs when I reopened. For earlier versions of MacOs there's Redquits, but it doesn't work now :(

Some of your issues makes me wonder... i.e.:

>Beggining/end of line: Option+Left, Option+Right; high frequency of use.

on macOS you can just use the 30+ years old Unix convention of Ctrl+A and Ctrl+E to get to the beginning and end of every line everywhere in the OS.

> "apt install"

That is because no generic consumer in the world actually uses a text-based package manager. That's only the CLI users, Linux/Unix/BSD users and the like. At the same time, software distribution isn't a one-size-fits-all approach. In line with apt, on macOS there is a packaging format much like .deb and it's called .pkg. It is compressed, has a manifest, some pre/post install scripts and the actual files. The .app distribution method is much more like a snap or container, which is what the world has been moving to for decades. In one way, it's even more comparable to nix, since applications and their dependencies live in their own location independent namespace. On top of that, there used to be a package manager that actually proved apt and dpkg for macOS, but almost nobody wanted to use it because that method doesn't actually fix anything.

> There's a difference, in almost every piece of software,[..]

> OSX puts one small dot next to an icon of the app that's open. [..]

> OSX litters all the (local) directories you visit with finder preview files. [..] (<-- actually nothing to do with previewing anything)

Those three are pretty much all the same thing: preservation of state. By default, the concept is that it doesn't really matter if a piece of software is 'open' or 'running', what matters is that when a user takes an action (i.e. start browsing the web), it continues from the last state the user left it in. That is a really hard problem to solve and something Linux will probably never be able to solve due to the difference in even basic GUI SDKs like GTK, QT, WxWidgets etc. and that's not even considering X11 which is a whole different mess by itself (data exchange via atoms on window objects? wtf?) There is a setting that will undoubtedly become default where the dock will no longer show a difference between 'open' and 'closed' since the difference will pretty much be to small to be relevant (i.e. is it in the process table or not will be about as much as a difference that will be left). Currently, there are a number of frameworks in place that do almost all of this, some are purely for managing state of the UI, some are for document-based programs that offload revisions, storage etc. to the OS, some are for managing idle time (i.e. AppNap). The idea that an Application is just a binary that hooks into the UI thread to dump some pixels on the screen hasn't been a reflection of reality on macOS for about 15 years. Having this information in mind might make all of your observation a lot more sensible.

Regarding .DS_Store files: they are data files containing the settings you set for a directory. So if you don't change anything for a directory, then no .DS_Store file is made. But when you say, change to icon view, move stuff around, go to list view, and setup custom sorting orders, then the OS will store your settings inside that directory. If you then open that directory on another Mac, you will get the exact same representation (be it via network, mass storage or target mode).

> Global menus

This often boils down to taste, but regarding those studies: they were about 'how hard is it to aim', which is relevant today, even (to an extent) for touch screens. The idea is that the global menu is at the top, and if you throw your mouse pointer at the top of the screen, you are always at the global menu, no aiming required. You basically completely remove an axis of aiming from the process. You can't overshoot either as the screen simply ends there. If you take the 99% of users, this is much easier than trying to aim for a strip of pixels at a random location somewhere in the top half of your screen. On top of that, multiple menus make little sense, you can't use more than one as you can only focus one, you only have one pointer, and you can't (on any implementation i've seen) use them without losing focus of your current window. Maybe this background information alleviates some irritation ;-)

> A kernel update

There are no stand-alone kernel updates on macOS, at last not by default and not planned. The type of updates that require a reboot are pretty much always those system updates, which are run as transactions instead of copy+replace. They aren't small or as insignificant as a single package either, most of them are comparable to complete distro upgrades like FC27 to FC28. And yes, I'm talking about those point releases (i.e. 10.13.3 to 10.13.4). Just because the semver delta isn't that high doesn't mean that on the scale of operations the content doesn't have a big delta either ;-) Most of them are a few GB in size and comparable to a reinstall of the complete OS (because again, it is a single, reliable transaction). Keeping that in mind, isn't it great that this can be done in under an hour, only breaks if you have made extreme system modifications and basically doesn't touch your own user data or programs? While not-touching-anything-it-doesn't-need-to-touch is standard, just like it is on Linux packaging systems (well, most of them), doing a complete distro upgrade on the fly isn't always that easy and reliable on other operating systems. Windows mostly just fails or takes forever, on Linux distros you have to do things like 'sudo apt-get update; sudo apt-get upgrade; sudo apt-get dist-upgrade; sudo reboot;' and hope nothing broke. Same with yum and dnf, I've had simple upgrades (bare FC install upgrades) fail and leave it in an unworkable state, mostly when libc was upgraded, or kernels (and the modules failed to update in the initramfs) or when the packaging tools themselves were upgraded (when they break, good luck fixing anything).

Somehow your notes about global menus and kernel update were not there when I first replied .. either a late edit or a network glitch of some sort.

Re: global menus, as I mentioned, I'm well aware of the original Apple studies. I admit I'm a power user, but many professional (not necessarily power) users these days have more than one app open on the screen, and I've observed the pattern of "click app to get the right menu, then locate menu item" with a few co-workers -- whereas on Windows (and linux), they only have to locate the menu inside the right window.

When Apple did their tests, they focused on use in a single app, IIRC -- which, back then, was justified. That's why I wonder if anyone repeated that with a modern workload.

Re kernel updates: No, it isn't great that it can be done in under an hour. I often install ubuntu or debian from a very old DVD, and then, within just a few minutes, it is all up-to-date, kernel and all. Never failed once.

I haven't used dnf or yum in a while, so can't comment; I know window breaks. But debian-stable is rock solid, and even ubuntu is (with the exception of the OOM kernel that did byte -- but still took just 5 minutes to update, and left you a copy of the older kernel to boot to if you wanted - which, once you got bitten by the oom bug, you obviously did).

I agree Apple updates are miraculous if you are coming from Windows. But compared to debian ... not so much.

> on macOS you can just use the 30+ years old Unix convention of Ctrl+A and Ctrl+E to get to the beginning and end of every line everywhere in the OS.

... which appears nowhere in the keyboard help or shortcuts. I actually used this in shells, from muscle memory, but never actually tried in editors or input fields.

> > "apt install"

> That is because no generic consumer in the world actually uses a text-based package manager.

I did mention the variety of GUIs; I like the CLI better, but I know people who prefer synaptic. Regardless of the interface, once you've decided to install a piece of software, Modern Linux does it much, much better than MacOS; It's possible that your use case requires packages unavailable in the repositories, in which case it doesn't matter - but the breadth of packages in debian/ubuntu/fedora repositories covers 99% of the users 99% of the time. No app store or repostiory on the mac does as well.

> Those three are pretty much all the same thing: preservation of state.

No, they aren't - two dots for two windows vs. one dot for one window is purely informative but hugely helpful. And while it might at some point converge to the "binary loaded or not doesn't matter", it's not there yet by a long short - and likely won't be for a decade.

The "quit vs. close" difference on OSX goes directly against the "preservation of state" concept you are promoting, in my opinion. In Ubuntu, whichever way I closed my Firefox (closing the window, shutting down the computer, upgrading the kernel, killall firefox, etc.) I get my state back. On the Mac, if I press the red button it doesn't, but if I choose "quit" on the menu it does ?!?

I mentioned them as things in which the MacOS fails compared to modern Linux, whereas somehow you took it as if the Mac does better.

Linux does preservation of directory view state as well. Except it is centralized and not all over the place. Windows does most of it in the registry (but put previews in the directory). These make much more sense -- and I think come because of Linux's Unix legacy of serving multiple users and having a lot of remote, read-only file systems often mounted. OSX is Unix, but is almost entirely single-user-at-a-time-and-they-own-everything-they-see from the day Apple adopted it.

Personally, I have configured my linux to automount every USB or network share read only unless I specify otherwise - I hate to accidentally modify files or directories, and many software allow themselves to drop swap/lock/backups even if you're in read only mode. MacOS is a huge offender from this perspective.

Preservation of state from the user perspective, not from the application functional perspective. If I as a user quit an application, I'm not telling it to lose my state, but if I close the state (i.e. one or more tabs/windows) that's what I want it to do. Closing/Quitting an application isn't analogus to killing a process. It is/was on some (but not all) other platforms, but not on macOS.

Quit and Close mean two different things. The state that is preserved is the state you put it in. So if the state is: I have a window open with a site loaded, then the next time I visit this task, I want that same state. If I tell a program that I wish to not see a window or site, then that is the state I put it in, and the next time I visit that same task/program, I want it to return to that state as well. While you might not agree with that logic, that is what the HIG describes and how it is implemented. The logic is there, and it is documented and followed, both on the desktop and on the ~1 billion mobile devices where much of the same HIG applies.

Let me add a car-analogy here:

Say you are in your car with the doors open and the engine running. If I turn off the engine, I don't expect my doors to close. And when I close my doors, I don't want my engine to turn off by itself. And when I open my doors, turn the engine off, go for a walk and come back, I expect my doors to remain open when I turn the engine back on.

Regarding the view state, Linux and Windows do this for the local machine, where as macOS does it for the directory. From a UX perspective both ways are with their own good and bad elements, but if you use multiple machines or manage multiple machines and share view states across machines and accounts, this is the way to do it (short of exchanging view state across other methods like a network or integrated into the filesystem).

Regarding your read-only mounting of mass storage and remote filesystems, that makes total sense to me, but makes zero sense for the general user. While it is nice to reconfigure your local system to do this (and macOS has this as well via autofs if you want it -- it's built in), this would make your environment completely unportable to anyone else.

> It is/was on some (but not all) other platforms, but not on macOS.

I know why it's there. As I wrote in another post, this was a great choice in the 128KB/floppy days of the early macs. It no longer is - for the general user, on a computer (unlike a car) it feels like a distinction without a difference. The fact that it is consistent and based on consistent logic (albeit one that was prescribed 30 years ago) does not matter, IMO.

> Regarding the view state, Linux and Windows do this for the local machine, where as macOS does it for the directory.

I think you're rationalizing a poor design choice. For local files, the end result is mostly the same (except Linux preserves the directories mtime) -- as local files are rarely if ever accessed across the network by someone with write permissions for that directory. And those permissions often make it seam dysfunctional on a shared directory - you can't store settings, so it doesn't stay the same between visits.

How does your explanation sit with the fact that there's a way to disable this for network/remote directories, but not for local ones?

> and macOS has this as well via autofs if you want it -- it's built in

I'm aware that's a power-user preference, I couldn't figure out how to do it on the mac; I'll look up autofs permissions - any recommended documentation?

> ... which appears nowhere in the keyboard help or shortcuts.

This is a weird omission in OS X. For what it's worth, they are documented here: https://support.apple.com/en-us/HT201236

> No app store or repostiory on the mac does as well.

Homebrew?

Maybe the most recent homebrew is better, but in my experience it is brittle, breaks often with underlying OS updates, occasionally has weird permission issues (heard that's solved now); I mentioned in another post it is close, but no cigar.

Part of ubuntu's and debian's "apt" magic is not just in the code; It's in the meticulous curation of the main repositories - which brew can't really compete with.