Hacker News new | ask | show | jobs
by beagle3 2879 days ago
> 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.

3 comments

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.