4 ms·

> If I had to shift to MacOS now it would be far far more painful than the shift from Mac to Linux. Wholeheartedly agree. I've been slowly moving from Linux (

• tnova 8y ago
  > 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.
  • beagle3 8y ago
    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.
    • amaccuish 8y ago
      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 :(
• oneplane 8y ago
  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).