At least changing mouse button order (and much more complex keyboard modifications such as remapping keys, assigning different commands to F keys, making a hyper key, turning on super-duper mode etc.) is possible with Karabiner Elements.
I understand, and even appreciate, that they don't let too much customization on their default programs. But why can't you run a different program? It makes no sense.
The window manager is definitely a "default program" that is probably tightly integrated in various points of the OS. AFAIK, you can't even use the OS without having Finder running (not the actual window "Finder" but the process) as it's also involved in lots of things, like the desktop and such.
I believe Finder is not technically necessary, as seen on Apple's installers and restore mode (which are a smaller version of macOS). You can kill it with Force Quit, for example. It is indeed also the provider of the Desktop, but everything else works: Dock, Menubar, Command+Tab.
It is launched via /System/Library/LaunchAgents/com.apple.Finder.plist
Depends on what you mean by "run a different program". You can't really replace WindowServer on macOS, as it is pretty much macOS itself. macOS is not really as modular as Linux or even Windows. There are things that hook into it to give extra behavior (Helium, Afloat, Magnet, Amethyst, chunkwm, several others in the AppStore), but replacing it is not really practical, I believe.
> You can't really replace WindowServer on macOS, as it is pretty much macOS itself.
I find this very foreign. As if a unix system didn't let you change the shell!
This is sad to hear, because I'm a happy user of a headless macOS (not set up by me), to which I ssh almost daily for testing purposes, and it is a fairly decent unix system. It has a few idiosyncrasies, sure, but those help to make your pipelines more portable. I always supposed that the GUI would be just a regular program running on top of that unix.
No...macOS doesn't work that way. There are a few hacks (Afloat, Helium) but all require disabling SIP, which is not desirable. And even if they didn't require disabling SIP, they only work part of the time in my experience.
Windows does not use a window manager like X does; the frames are drawn and managed by a library used by all applications, it’s not a separate program.
I’m not 100% sure but I’d say it’s pretty likely Mac OS works the same way, just like on Mac OS the left part of the menu bar (including the system menu) is drawn and managed by the current application (using a system library so the application developer doesn’t have to worry about how it works).
> on Mac OS the left part of the menu bar (including the system menu) is drawn and managed by the current application
IIRC it is not drawn by the application, it's a system app that gets the focused (or rather, activated) app menu hierarchy as the app instructs through some IPC, but it's not the app process itself drawing there. The only part where an app actually can draw is on the right part, when one implements menu bar extras (which previously required hacks to inject into because the menubar extra API was severely limited, but IIUC now has a dedicated, managed API to replace the hacks)
Out of the box macOS doesn't have a button to maximize the way Windows does. The green button in modern macOS is for full-screen and option-clicking that button will bring back the old "zoom" behavior which expands the window to fit the content being displayed. It's a lot less frustrating of an experience when you realize that the button doesn't do what you assume it does.
I suspect that'd play absolute hell with either their UX concept or the underlying UI abstractions / implementations.
This would create a situation where an application has one window foreground above the foreground application while it is not the foreground application.
On the UI / implementation side: I don't think it's possible to have any windows of an app foregrounded past the foreground app's frontmost window if that app isn't itself foreground. They'd have to create a new category of window (and probably move a bunch of internal data structures around) to make that possible. I know, "it's just code," but it's code based on some very deep and old assumptions about the way the window manager works that probably have hard-to-predict consequences if violated.
On the UX side: having a window floating foreground when the top-of-desktop menubar says another app's name in the corner is going to trigger a "WAT" for a lot of users, and I think Apple is deferring to them.
As I've started to move my collection of music from Spotify to downloading FLAC from Bandcamp, I found that libimobiledevice + ifuse (https://wiki.archlinux.org/title/IOS) seems to do the job good enough. Only thing that took some time to figure out is that I need to move the music files into a directory specific for the application I use (VOX) rather than the general "Music" directory, as it seems files are not shared between applications and the music app doesn't have any directory exposed for me to put them in.
I'd love to be able to just plug the damn phone into USB and transferring files like a normal person though, but Apple doesn't seem to want to play that game, sadly...
This is really the only issue from that post that I would really like on macOS. SSH mounting as well, potentially. The rest are annoyances that while I believe are very important to the author, they feel rather irrelevant to me.
Right now, Android File Transfer of macOS is so bad I basically just use adb for everything.
In my experience, Android MTP worked semi-reliably on Windows (I'd often encounter "ghost files" which couldn't be renamed or accessed, since MTP and Android's media cache desynced from the underlying Linux filesystem), and often failed entirely on Linux (trying to open the phone hung or caused the Linux MTP daemon to crash immediately or after some time). I much prefer adb push/pull, which has always been rock-solid as long as adb can see your phone.
MTP is a clusterfuck of epic proportions for anything involving more than a hundred files, much less 1000+, no matter the platform of either the host or the device.
Seriously I have utterly no idea why no one has bothered to create a new protocol that is designed with the capabilities and capacities of modern devices in mind, not with "fits for managing a 256MB-sized MP3 player or a point and click consumer camera with a 2 GB SD card".
Some things in that list are pretty silly (can you really blame Apple for not letting you swap the mouse button order or have the insane focus-follows-mouse option?)
Here are some others anyway:
* Record system audio.
* Control HDMI audio volume (have to use Proxy Audio Driver which is somewhat buggy).
* Set mouse acceleration (you used to be able to but they removed the option and now you can only set sensitivity).
* Disable scroll wheel acceleration (needs a paid third party app).
RSI issues are also a reason why I won't ever use a macbook - the only laptop input method that doesn't hurt me after a few hours of use is a trackpoint.
In the past I've used mice and trackpads on Mac that had their own control software that allowed remapping the buttons, mapping macros to buttons, etc.
> can you really blame Apple for not letting you swap the mouse button order
Why not?
> Or have the insane focus-follows-mouse option
On Linux where your application menus are (usually) part of the window it works great.
Apparently so ... I usually like insane, but I think click-to-focus is the actual insane thing. In the Mac case this is tightly coupled with mandatory raise-on-focus.
That's my biggest pain when I try to work on a Mac. I bet no-raise-on-focus also sounds insane to the same people, but I only want a window to come to front when I as for it. The article even touches on a simple case of this in "Sometimes I want to keep the calculator on screen while I type an email. Is that too much to ask?"
> * Set mouse acceleration (you used to be able to but they removed the option and now you can only set sensitivity).
Using MacOS is such a miserable experience for this exact reason. I'm sure it's fine when using the trackpad but trying to use a mouse on macos is borderline torture.
I fundamentally do not understand why anybody would ever want mouse acceleration. It just makes it harder to use the mouse.
Maybe. I mean, I've never wanted to do most of the things he lists as impossible (on either my macOS machines or my Linux machines). But if that's a list of stuff that annoys him when using macOS, I guess they're not "silly" to him.
Since my main daily driver for probably 2/3rds or more of the last three decades has been a Mac, I'm more familiar with it, so things like focus-follows-mouse takes a bit of getting used to when I open up my Pinebook or my RasPi400 - but I gt over myself and get used to it pretty quickly.
People who complain that macOS isn't exactly the same as Ubuntu (or Windows or $randomLinuxDistroDeJour) seem, to me, to just be wanting to complain about stuff.
I did try Soundflower but it didn't work. Hadn't heard of AudioHijack, thanks! Sucks that you have to pay to work around a restriction that Apple have added though.
Yea, it's annoying. It's worth it if you need it though, there is a trial time limited to test if it'll fit in your workflow. Soundflower has been a bit buggy since it's inception tbf.
Should this functionality be included in the OS itself? Sure. Is it a big problem? Not really.
Every OS has its quirks, doesn’t take more than hour to smooth the rough edges off a new machine if you’re comfortable with the ecosystem. You have to do the same on Ubuntu or Win10 or Pop.
There's always going to be software that supports some platforms but not others.
For example, in the EDA world it's very common to have Linux/Windows support but not macOS support (eg.: Intel Quartus, Xilinx Vivado, Cadence Virtuoso and others, Mentor Graphics Calibre and others, ...).
Yes, this is a big one. I run full system containers on my Linux boxen with systemd-nspawn, and on macOS, with their system level protections, I suspect even chroots would be too much to ask. (Maybe it's possible, I just haven't had that many disposable hours to check just how much pain it would be for quite a while.)
And then does magic when you want to expose a volume from your macos host to your docker container. And that magic can slow down things. They improved things recently though [1]
OSX is a distant third for a developer who is deploying docker containers. Microsoft and WSL2 are trying, but nothing beats a linux distribution for that.
Try running a docker container whose executable is called “foo” in macOS. Then go to activity monitor and try to find “foo”, or try to attach to it from the host with lldb, or try to profile it with the Xcode profiling tools. You can’t.
This is because it’s running in a VM, not natively on the host. On Linux you can do any of those things from the host directly, without needing to shell into the container.
I actually found this so incredibly frustrating when I started working at a job that uses docker that I argued in vain against using docker at all, and then when that failed, I switched to doing all my coding and other technical work on a Linux VM and only using macOS for email.
That is true, but containers are the most pervasive in macOS of all desktop OSes.
That is something I do actually like there. And Apple isn't even forcing developers to do it (unless they want to publish in the app store which most apps I use don't do), just more and more app developers sandbox themselves.
While technically, yes, you are correct. It kinda misses the point - developers are more and more working with containers. Doing this on a Mac is an awful experience compared to doing it on Linux (or, Windows - I hear docker + WSL2 is pretty decent - but I've not tried it!)
I understand the point and totally agree, but in my opinion it doesn't fit to this kind of list in the article which is about features of the OS that don't work on macOS but on Linux. "Linux can't ran Adobe Creative Cloud Apps natively which a lot of designers use" would also not fit this kind of list.
While it's a good reason to choose macOS or Windwos over Linux it's not a valid criticism of Linux because they can't do anything about it. It would be valid criticism of Adobe. Like I said the list of the posted article is about OS features and explicitly not about third party software
Yep. WSL and WSL2 are great. I used Windows with WSL, upgrade to WSL2 then noticed I don't need the "Windows" part of the system anymore and WSL2 cross-boundary file access is slow, so I deleted Windows and finally installed Linux again on my work laptop. (Used Linux up to 2007, bought a Mac, another Mac, switched to Windows after Apple locked down the system because "Windows has WSL, so I can do my work stuff" and switched back to Linux due to a slow Filesystem under Windows - for my use case).
The only thing that pisses me off, is that the MS-Teams client for Linux is roughly 5 decades behind the Windows client, feature and stability-wise.
(And still have Windows on my private laptop for Fusion360 and games)
If I wanted a duct-taped inconsistent UI, with advertising, "telemetry", forced updates when I am in the middle of something important, 30 min software installations and being the target of most existing malware on planet Earth and spending 10 min to copy a file, by all means I would use Windows.
With Windows, put simply, you don't own your computer.
I haven't used Windows in over a decade and cannot be happier about it.
Windows at this point is a games console for keyboard and mouse games. Nobody uses Windows for anything serious, except old ATMs running Windows 95 and airports that want to embarrass themselves with blue screens of death. Most of the stuff on Azure including Azure itself is Linux based.
I like this post. For the first time someone actually provided a list of things and more so jumped right into them! Most of the apple posts go into a long philosophy rant about walled gardens and other bs. Glad to see a legit list and they have a legit point.
Exactly, both informative for MacOS users and those who never used it.
MacOS users can quickly scan and think yeah I don't care about this feature, or think huh this is something that could be useful and maybe I should look for a 3rd party app which has this.
Those considering switching to MacOS can compare to their existing environment and have a greater picture of what possible pain points to expect.
I would like to see more of posts like this for all Desktop environments. Like things you can do in MacOS but not in default Ubuntu setup.
This list is personal and far from exhaustive (which is fine). If I quickly scanned looking for things I care about, I'd find very little. However, as a Linux user I could very quickly come up with an equally long list of things that I do care about and that does not overlap much with this one.
I think the larger point is: in Linux, some things are complicated but most things are possible. On Mac and Windows, some things are easier but many things are impossible.
So there's definitely a tradeoff. But since I have to use this tool for the majority of my waking hours in order to make a living, the ROI from taking a bit longer to solve an issue and then having it solved virtually forever makes Linux a better proposition IMHO.
> Why do we need a trade off between stability and control?
There isn't infinite time and money in the world. Every hour making one feature more stable means an hour not invested in another. Flexibility and control are just additional features. If you want to change the system font, you have to test (and support) a much wider array of things, especially if your UI guidelines are as restrictive as Apple's. Every piece of control you expose to the user increases the engineering cost of writing and maintaining the software.
And frankly, if more people wanted that level of control, this year TRULY would be the year of linux on the desktop. But they don't.
It's not just control. It's control plus stability, as we said.
Control is deliberately withdrawn to preserve the commercial interests of the producer, not because it is technically impossible to add it to stability.
You want stability? Provide a perfect default configuration. You want control? Allow tweaking that configuration in detail for users that are willing to do it.
> On Mac and Windows, some things are easier but many things are impossible.
The obvious caveat is that many things are impossible out of the box. There are plenty of tools available to address a good number of the shortcomings mentioned in the story.
I was actually a bit disappointed in the article. I thought it was going to explain some kind of substantive work or task that the author can do on Linux but not Mac OS. Instead, the things he lists all boil down to Mac OS being a lot less customizable.
That absolutely true but I feel like we all already knew it.
Trivial to you, and many people, perhaps. But this user is citing problems such as being able to read the menu, and to accommodate for RSI. So in this user's case, these things are sort of blockers.
I don't think the user is aware that you can change the entire display scale for readability if you need to. There are also numerous mouse button remapping utilities out there.
Way back when (2006), chromatic posted a "switching back" article at O'Reilly Radar. Sixteen years (!!!) later, it still holds a great deal of truth. You'll have to dig it up on the Internet Archive though.
Focus-follows-mouse, UI customisability, package management, second-hand citizen status of Linux apps, and a few others. It's also interesting to see what has appeared as supported / possible, on both operating systems.
> I have multiple screens and multiple windows. I want to be able to hover over a new one and start interacting with it without clicking.
Having attempted to implement this once, doing this is nontrivial. If you try to focus anything under your mouse then you can end up changing the selection state of tables and controls, which is generally undesirable.
This is about _window_ focus, not focus on individual controls within a window. The former is useful (I tried GNOME for a while but went back to i3 for, among other things, this reason), but the latter is (as you found out) probably not a good idea.
They are one and the same, because when you are interacting with a window you are actually interacting with controls inside the window. It is easy to forward cursor events to the target window (hover and scroll already do this, FWIW) but when you want to say type something you'll need to focus the text element under the cursor before you can just blast key events to that application.
Doing this in a way that feels intuitive is non-trivial. If you go the simple route and focus every control (so you can do things like tab between them) you run into the issue of the mouse activating some of them as you go over the element and giving it focus–for example, if you do it on a window sidebar, you'll switch between the tabs. I didn't get a chance to really thing about it, but I was thinking of just giving text elements focus and considering it to be good enough; but there are still challenges there: should you be able to focus on a search field (which might blow away the current context and replace it with a "searching" screen)? How should I handle keyboard shortcuts?
There's a much deeper reason that MacOS doesn't make focus-follows-mouse easy.
In most window managers (including Windows), the first-class entity is the window. Windows are related to applications (or processes), but they exist as their own thing, operate independently from most other windows without special handling, and usually have their own menu bar.
Apple took a severely different tack on this fundamental abstraction: the first-class entity is the application. At all times, there is at most one application with foreground context and all others are background, and it's actually a pretty expensive operation to switch between them. They did this for a couple reasons (some accident of history and some practical... for example, Apple's decision to put the application's menu at the top of the screen to coincide with the original usability studies on how the edges and corners of the screen were the easiest to mouse to implied there'd be at most one application at a time owning a global menubar context).
This had huge consequences for the constraints put on applications. For a long time, it was hard to write a tiling window manager for Mac OS X because there was no language by which you could describe all windows; you'd have to query every app for the geometry of its windows, then compute a new global layout, then foreground each app so it could update its window positions. This is no longer the case, but it made any TWM implementation a toy for years.
The upshot of this design for focus-follows-mouse is it has a lot of unintended consequences and can make the system actually quite hard to use in a focus-follows-mouse configuration. For one, it induces latency in all your mouse operations if you're constantly toggling the foreground app as you mouse around. For another, it actually makes it quite difficult to mouse to the menu bar if the menu bar is going to change when your mouse drifts over another window.
(It is interesting to observe how, while at some level "they're all just window managers," the detailed decisions made by the different OS developers led to some things being subtlety much harder in one or the other).
KDE Connect almost works on Windows, but spawns background D-Bus processes (nitpick) and crashes on sleep-wake (near-dealbreaker). I hope to someday diagnose and fix the problem, but even building KDE Connect is a nonstandard process involving using Craft to install libraries and build the program (rather than building from an IDE directly).
- No way to fullscreen a window without moving it into a separate workspace. All a new workspace achieves is making it difficult for me to switch between this app and my other apps! (individual apps can implement this, and some like VLC do, but most apps don't)
- No native support for containerisation. Containers/Docker are a great technology, but even on my M1 mac where literally everything else is super speedy, they're really slow.
Holding Option when you click the green window button will maximise the window - rather than make it full screen - for most, but but not all, applications. For some reason Safari only maximises vertically when you do this.
macOS has never had full-screen maximisation. It maximises "for the content". Which means some windows will never be full screen because they don't have more to show.
What you get when you hold Option is the way that was the previous "maximisation" option, before they added the full screen mode which I also abhor.
We can split hairs and hold our breath til we're blue discussing design decisions we don't control.
I'm just trying to be helpful, possibly barely pointing out that things claimed to be impossible are not (and not argumentatively, only because folks may stop at that and have to endure something when there are solutions that would fit their use case)
Which is annoying for some applications which don't maximise, because the content isn't there but could be. I can't think off what does this off the top of my head since I installed Amethyst, but I think I remember Excel used to do this back in the day.
I hate the thought behind this. Often I don't maximize to see more content, but to hide everything else. Why does Safari decide for me that the window can't be any wider? That doesn't make any sense at all.
Note that this concept predates the concept of maximisation, and comes from an era when single apps would be implemented in multiple windows. E.g. the content area the toolbar in photoshop were separate windows. Back then it made a lot of sense. But I agree it's just annoying now.
Interesting. I recently started using an M1 Mac and found the fullscreen workspaces a bit weird (coming from i3), but kinda grew to like it? I got the external trackpad and use gestures a lot (before it was Control + arrows) to navigate the workspaces.
My main issue is that all the different "Terminals" have subsets I like on them, but none have all the features I like lol. It's not a big deal though. FWIW I'm trying out the Warp term now (used wezterm on linux) and it's been mostly enjoyable so far.
For me, those gestures are next to useless because the animation is just waaay too slow. It's literally a whole second (exactly; I just timed it) of waiting for window focus to switch.
The animation is shorter when you're on a model without a 120Hz screen, so it gets a little more bearable there.
Also, try to use keyboard shortcuts: the animation is muuuuch faster than with gestures. In Keyboard prefpane, Shortcuts, Keyboard, Mission Control (make sure to have many desktops created). I have desktops set to ^1..^0 and left/right to ^left and ^right (which is sadly the only way to move to fullscreen apps), and disable MRU automatic space reordering in Mission Control prefpane.
It's got nothing to do with gestures, the key combo has the same switch delay as a quick gesture swipe (Which seems to have the same delay as mission control selection) when switching workspaces.
I've spent more time than I'd like to admit trying to get rid of this workspace switch delay. The tipping point for me on it was switching to a 16" Pro with a 120 Hz screen and finding out that means it now takes longer to switch.
Got it. In my experience switching with shortcuts takes half a second (which I understand can be annoying, being an i3wm user myself) and is visibly faster than evn quick gestures, which have a slower ease-out for me (but that may be due to how I swipe)
I don't mind the animation, I actually really like the animations in macOS. I just don't want it to take a full second to switch the active window. "Reduce motion" keeps the full-second delay but replaces the nice animation with a less nice fade animation, which is kind of the opposite of what I want.
Yes, iTerm2 is one of the best macOS apps. It's the first thing we have new developers install if they're new to macOS.
On the 120Hz MacBook Pros, there's an advanced iTerm2 setting that lets you change the maximum frame rate to 120 or above (adaptive frame rate also needs to be disabled).
For monitors with a high refresh rate, it's worth checking out. You can see the difference by running:
I used it for a long time but switched back to regular Terminal for the lower latency, because I realized I couldn't even name an iTerm2 feature I used that Terminal didn't have. I'd just been using it because it was so widely discussed.
That's completely fair. For me the killer feature is it's multi-pane support. Being able to have several terminal panes side-by-side on screen at once without having to fiddle about with something like tmux is wonderful.
> Containers/Docker are a great technology, but even on my M1 mac where literally everything else is super speedy, they're really slow.
Either you're using Docker for Mac which itself is slow on IO mostly due to the macos-linux file share syncing every single fseventsd<->inotify or you end up running intel images on aarch64, which uses non-virtualizing qemu to emulate the foreign CPU (see github.com/tonistigii/binfmt)
I'm using Docker in a Fusion instance, sharing /Users through vmhgfs (which in my tests performs better than DfM shares) and it's plenty fast as long as I stick to native images (intel on intel, aarch64 on arm64) and don't outrageously reach out to the shared dirs (notably DfM shares /tmp by default which is ridiculous)
Container tech on Darwin would bring little in most cases since it would containerize a darwin userland, which, while cool, is probably not what most people want. There's no shortcut from running a Linux kernel in a VM to run a Linux userland on Darwin.
Or they could do what windows did. Support windows docker for whatever use case that supports (never used it) and creating WSL which has Linux roots deep in the OS. I find WSL docker works great for development. Certainly wouldn’t use it in production.
WSL2 doesn't have Linux roots deep within Windows anymore, it's literally running a Linux VM with a full kernel under the HyperV hypervisor, so it's exactly like DfM (IIRC save for the fact that Windows then also runs under HyperV with the hypervisor sitting on top, Xen-like, and as is achieved on Xbox, and Linux running side by side instead of being handled by an OS process underneath the main OS)
> Either you're using Docker for Mac which itself is slow on IO mostly due to the macos-linux file share syncing every single fseventsd<->inotify
If you haven't tried the new VirtioFS accelerated directory sharing in Docker for Mac, it makes a _huge_ difference to I/O performance of mounted volumes.
Admittedly I didn't, not the least because I expect it to be at best equal in speed to my current setup, plus my current setup gives me better control on the virtualised OS + memory ballooning of the VM (... and that there are other things with DfM that rub me the wrong way).
Nonetheless, I salute the years-long effort from the Docker team on that one.
I'm using Docker for Mac on an M1 Pro and it's stupidly fast, to the point that my dev environment runs faster than the Intel production servers on some things.
How well does it handle a large amount of writes to small files (say 1000 files, each about 8KB)?
Edit: the static blog generator I wrote [1] takes 11 seconds inside a Ubuntu virtual machine with the directory shared with MacOS on an Mac mini late 2014. Docker, on the same machine, takes 1m13 seconds using gRPC FUSE for file sharing. 1866 HTML files are being generated.
I have no idea I'm afraid, I don't work on anything that would ever do something like that. As a real world benchmark, the project I'm working on at the moment (Python / Django) runs the test suite in ~10.2 seconds on my Mac inside Docker, on GitHub CI it takes 35 seconds.
You can stop it hiding the menu bar in full screen. System Preferences -> Dock and Menu Bar -> Automatically Hide and Show Menu Bar in Full Screen (at the bottom of the window).
Yes the enlarge is a thing which unnerves me as well because some apps insist on keeping a specific aspect ratio and so on. I still use Better touch tool which has support for screen zone snapping. And I have a custom key binding to maximize windows setup via better touch tool.
For those who don't mind "full screen" still including the top bar, I find https://www.hammerspoon.org/ to be a good compromise. I set up option+shift+f to full screen my window instantly.
+1 for this. Hammerspoon is a godsend. I have keyboard shortcuts to switch to my desired apps instantly (around 10 or so, hyper+I is IntelliJ, hyper+A is Atom, hyper+F is Firefox etc.)
The '+' button and double-clicking the title-bar doesn't maximize windows—it zooms them in Apple's terminology. It should just make the window big enough to display its contents, although some apps don't cooperate (Chrome). Hammerspoon can be configured to maximize windows, i.e. make them fill the screen.
> No way to fullscreen a window without moving it into a separate workspace.
One of the reasons why I almost never use the full screen feature. You can click on the full screen button on the too left-hand corner of each window whilst holding Option, I think that’s the closest you can do out-of-the box. You can assign a keyboard shortcut for this very easily (seriously, the way we can define keyboard shortcuts for almost anything and have them work in almost any app is amazing; nothing comes even close on the Linux side).
Otherwise, you can use something like Magnet or Rectangle, which enable exactly what you want.
What keyboard shortcuts are you missing in Linux? At least with KDE, I can go the entire day without touching the rodent. And on the rare occasions that I do use the mouse, I'm mostly touching it only for webpages that don't work with Tridactyl, or for highlight-middle-click copy-paste.
I miss the ability to set arbitrary shortcuts and bind them to arbitrary menu items. Also, shortcuts are not very consistent across Linux applications, compared to macOS, which is much more homogenous and less surprising. OTOH, that's not a deal breaker and I keep using both Linux and macOS daily.
macOS is frustrating to use without a mouse. On one side the shortcuts are consistent, work everywhere, and are very deeply customisable. Really much better than anything I have tried on other platforms. All the menus are very easy to use without a mouse once you know the shortcuts (which, granted, are not obvious if you don't know they exist). Emacs-like shortcuts in all text fields are absolutely fantastic. The fact that Command is used throughout the GUI leaves Control available for things like terminals, which is awesome (e.g. there is no conflict between Control-C to kill a process and Command-C to copy some text). But at the same time there are things like window management that pretty much require a mouse, but really should not.
> I miss the ability to set arbitrary shortcuts and bind them to arbitrary menu items.
In each application? Interesting that the OS provides that.
> macOS is frustrating to use without a mouse.
My experience confirms this as well. I was really expecting an ergonomic, well-polished experience but I found that the Mac is polished like shark skin. It's nice and smooth if you do things - or can force yourself to do things - like the engineer in California does things. But if you like to keep your hands on the keyboard, or organize your applications (not just windows but applications), or anything else then you are going against the grain and that smoothness turns into obstacles and pain points.
I do use magnet. But something I do want something to be truly fullscreen (no menubar or anything else visible), but without being on another workspace. I think the most common use case for this is with videos. I often want to fullscreen a video, but still be able to quickly switch between windows so that I can for example reply to a message.
Note that with any non-fullscreen window I can continue to see live updates to the window in the mission control view. So I could for example continue to watch a video (albeit smaller) while watching chat messages arrive in another window as my friend sends them. But with a macOS fullscreen window I can't do that. If I open mission control then I can only see the fullscreen window (because it's the only window in the workspace), and if I switch to another workspace to the see the contents of those windows I can no longer see the fullscreen window. Infuriating!
Try exiting full-screen in the video player (green button) back to windowed mode and then double clicking the title bar. It’s not full, full-screen, but it’s the largest window you can get.
I’m still not sure why you can’t switch between applications even if they aren’t on the same workspace though. Cmd tab, Cmd tab takes me from a full-screen video to the last app on a separate workspace, and right back to the video.
And if you want to see other apps at the same time as the video, no wonder full-screen gets in the way.
The problem is if it isn't a dedicated video app. Say for example a video embedded in a webpage. Then you can maximise the browser window, but the video itself still takes up a small part of the screen.
> And if you want to see other apps at the same time as the video, no wonder full-screen gets in the way.
You say that, but is doesn't on windows or linux. And it didn't used to on macOS either until they changed things around a few years ago.
Hold Option and double-click the window corner. This will probably do what you want (fill all of the available space). You can also do this with the sides of the window and have it grow only horizontally or vertically.
I would also recommend trying out if BetterTouchTool can't change the behaviour of the green (+) button as it's pretty powerful.
You forgot "spend three days trying to get a Bluetooth keyboard to pair at boot every time". :-D
I love Ubuntu and I use it with Cinnamon desktop on the daily alongside my Mac, and I love the customizability, but I also like just being able to turn on my laptop and do stuff without having to fiddle with a terminal unless I want to, or install a new app by just downloading a thing and clicking on it and agreeing that, yes, I'm trying to do this thing. And that's just not quite there with Ubuntu yet.
(Also, trying to do music stuff is mostly a nightmare of JACK and Alsa headaches. I can write generative music code in at least two languages, but I just wanna plug my guitar in and record things and use plug-ins without having to recompile shit.)
There's places for both. Use whatever works for you.
For realtime audio, Pipewire basically solves this problem on Linux. It appears as JACK, Pulse and ALSA to client programs and allows seamless interop between all of them. It's slowly landing in mainstream Linux distros as the default audio solution.
This means that without any special setup, both real-time audio software (which uses JACK) and 'normal' software (Pulse, ALSA) can co-operate on a single system with a single digital patchbay between all of them and the system output devices (including Bluetooth audio devices).
I use a pair of BT headphones (paired to 2 devices) and a keyboard. Both have worked without a hitch since day one on Ubuntu Mate. Funny enough, it's the only device I own that will work with my prehistoric HP printer from 2005 without any hacks. Newer versions of Windows don't work with it (I probably need to fish out the CD with the drivers), MacOS never did.
I can echo the HP printer comment, mines a printer/scanner. Every time I print or scan on Ubuntu I'm expecting it to not work, as that was my experience on macOS, but it works flawlessly. On macOS the driver was abandoned 6 OS versions back, and I had to do some pkg command line trickery running as root just to get the thing to install.
Sorry, I just want to get this straight. We're comparing Linux and MacOS, and having to do command line trickery to do something is a knock against MacOS? Really?
I mean if that's a legitimate black mark, that's 1 ding against MacOS and we can bury Linux under a thick pile of back marks.
It does not have to be ancient printer; I present you Samsung SL-M2070W, which HP is still selling under some other designation.
I can print in MacOS, but I cannot scan. It used to work, but color scanning was broken few years ago, and about two years ago b/w scanning was broken too - Preview or Image Capture will just produce something malformed.
There used to be a workaround using Samsung scanning utility, but it doesn't work since Catalina, due to the utility being 32-bit app.
So what I do? RDP into other machine that does not have such problems (either Linux or Windows) and then transfer the scanned file.
> Also, trying to do music stuff is mostly a nightmare of JACK and Alsa headaches. I can write generative music code in at least two languages, but I just wanna plug my guitar in and record things and use plug-ins without having to recompile shit
This hasn't been a problem in a while. You definitely don't need Jack for recording your guitar into a DAW with a backing track (I have a studio full of synths that I record - 24 tracks in, 24 tracks out, via a class compliant USB audio interface). And as the sibling comment points out, Pipewire makes things better still; you can point your DAW at "ALSA" (really Pipewire under the hood) and also play Youtube vids in a browser at the same time - this was of course possible with Pulseaudio or Jack, but both of them had their own quirks. Pipewire is overall really nice and just works cleanly.
Does pipewire solve your problems in recording? I'm planning to get into the music making rabbit hole and I wonder if my Pop_OS! laptop is up to the task.
> "I find the menu bar at the top too small. The only way to do this on MacOS is to lower the resolution of the entire screen!"
System Preferences -> Accessibility -> Display -> Menu bar size
(This doesn't let you change the menu bar to a different font, but it does make the whole menu bar including the font bigger, without changing the screen resolution, which seems to be what the author wants?)
Have you tried it recently? The difference it makes is - at least on my Mac - only a couple of pixels. The "large" size is hardly bigger than the regular one.
> If I stick a USB cable between my phone and Linux laptop, I can see the Android files on my laptop. I can open them, move them around, etc. On a Mac I need to install some shonky 3rd party software which rarely works.
You didn’t used to have to do that in macOS? I remember plugging in my android phone and it mounting my memory card. Is OP referring to accessing something else?
> Mount an SSH or NFS drive
> In Ubuntu, I get a nice little GUI for picking network shares. Impossible on Mac.
I’m a little curious what the difference is between macOS and Linux here.
There’s definitely a lot of legitimate points here and a few questions on others.
Mass Storage devices are attached as block devices. MTP devices are attached as file devices. As long as the OS understands the filesystem on a block device, it can mount it. For file devices, it needs to speak the protocol (in this case MTP). MTP is similar to how Apple handles attaching of its devices, just a different protocol.
Mass devices can be easily corrupted and have to be unmounted from the current device. MTP can stay mounted and accessible by the mounting OS and source device simultaneously and are much more difficult to corrupt.
It also allows the host device more security and control over what the guest can do.
Older versions of Android used to allow mounting as a mass storage device, but there are several problems with this:
- You can't allow apps on the phone access to the filesystem at the same time as it is mounted as a mass storage device (because you may corrupt the FS).
- It doesn't work with full-disk encryption used by newer Android versions, because your computer doesn't have the key (and the key is probably stored somewhere in the TPM of your phone, encrypted by your password).
- It requires the computer to support the FS used by the phone, which means necessarily using something that Windows/macOS supports (which mostly limits it to FAT/exFAT/NTFS)
So starting from Android... 5 or so? you can't mount as mass storage anymore. This probably consists of 99.5%+ of currently functioning Android phones.
This refers to MTP (Media Transfer Protocol). Very old Android devices (with Android 2.x) used to pass-thru the SD card to the host as a USB Storage Device, but that solution was clunky as it requires detaching the SD card from the phone itself.
MTP is file-level protocol and you can continue accessing all files on the phone at the same time as accessing them from your computer. MTP is part of the "Windows Media" framework and so works out-of-the-box in Windows. Linux supports it for 8+ years through GVFS and KIO, while Apple doesn't to this day.
I remember I used to be able to force-quit an app by two-finger tapping on the red "close" button. Then suddenly after some update, the feature is gone. I hate when they change shit for no reason and dont think for a second about breaking peoples workflow.
The line of thinking that they decide what should be part of my workflow is exactly what bothers me so much about macOS.
For me it's also ingrained Command-Q into my brain to close an app. Especially because even before this change apps often didn't close when you closed the last window. It's always been like that. Only some apps like System Preferences do it.
Well my thinking is that homelessness shouldn't be a thong in a first world country, and but this'solution' is like making homelessness illegal and declaring that you solved the problem.
Clearly the appropriate solution would be to somehow make sure that I never need to force close the application, but the damn thing won't even let me restart if some app has hung (I am looking at you MS teams!)
740 comments
[ 3.6 ms ] story [ 329 ms ] threadSo many ways on windows / linux.
> Can't you just use a different X?
Lol, this is Apple we're talking about, the company famous for not allowing people to customize things to their own liking (for better or worse).
It is launched via /System/Library/LaunchAgents/com.apple.Finder.plist
I find this very foreign. As if a unix system didn't let you change the shell!
This is sad to hear, because I'm a happy user of a headless macOS (not set up by me), to which I ssh almost daily for testing purposes, and it is a fairly decent unix system. It has a few idiosyncrasies, sure, but those help to make your pipelines more portable. I always supposed that the GUI would be just a regular program running on top of that unix.
I’m not 100% sure but I’d say it’s pretty likely Mac OS works the same way, just like on Mac OS the left part of the menu bar (including the system menu) is drawn and managed by the current application (using a system library so the application developer doesn’t have to worry about how it works).
IIRC it is not drawn by the application, it's a system app that gets the focused (or rather, activated) app menu hierarchy as the app instructs through some IPC, but it's not the app process itself drawing there. The only part where an app actually can draw is on the right part, when one implements menu bar extras (which previously required hacks to inject into because the menubar extra API was severely limited, but IIUC now has a dedicated, managed API to replace the hacks)
Also through dock you can configure a window to be on all of the screens
*<-using macos 10.14
I'd already be happy if maximizing a window on macOS worked reliably.
I've referred to macOS's "maximize window" feature, which you trigger by double-clicking a window's title bar.
This would create a situation where an application has one window foreground above the foreground application while it is not the foreground application.
On the UI / implementation side: I don't think it's possible to have any windows of an app foregrounded past the foreground app's frontmost window if that app isn't itself foreground. They'd have to create a new category of window (and probably move a bunch of internal data structures around) to make that possible. I know, "it's just code," but it's code based on some very deep and old assumptions about the way the window manager works that probably have hard-to-predict consequences if violated.
On the UX side: having a window floating foreground when the top-of-desktop menubar says another app's name in the corner is going to trigger a "WAT" for a lot of users, and I think Apple is deferring to them.
I'd love to be able to just plug the damn phone into USB and transferring files like a normal person though, but Apple doesn't seem to want to play that game, sadly...
Right now, Android File Transfer of macOS is so bad I basically just use adb for everything.
brew install sshfs
Seriously I have utterly no idea why no one has bothered to create a new protocol that is designed with the capabilities and capacities of modern devices in mind, not with "fits for managing a 256MB-sized MP3 player or a point and click consumer camera with a 2 GB SD card".
Here are some others anyway:
* Record system audio.
* Control HDMI audio volume (have to use Proxy Audio Driver which is somewhat buggy).
* Set mouse acceleration (you used to be able to but they removed the option and now you can only set sensitivity).
* Disable scroll wheel acceleration (needs a paid third party app).
So is MacOS only for people in perfect health?
Wait, doesn't your preferred mouse have exactly that?! https://shkspr.mobi/blog/2018/05/review-evoluent-veritcal-mo...
What is missing from this mapping control?
Are there only 2 classes of people: people in perfect health, and people unable to use their index finger?
Is it that hard to believe some people prefer this behaviour?
Not at all. But it's also really easy to see that giving someone used to one of those behaviours the opposite one - would make them unhappy.
That's my biggest pain when I try to work on a Mac. I bet no-raise-on-focus also sounds insane to the same people, but I only want a window to come to front when I as for it. The article even touches on a simple case of this in "Sometimes I want to keep the calculator on screen while I type an email. Is that too much to ask?"
Using MacOS is such a miserable experience for this exact reason. I'm sure it's fine when using the trackpad but trying to use a mouse on macos is borderline torture.
I fundamentally do not understand why anybody would ever want mouse acceleration. It just makes it harder to use the mouse.
The problem is Mac's acceleration code is pretty awful.
As the other comments have pointed out, SteerMouse works fine at the cost of $20.
Maybe. I mean, I've never wanted to do most of the things he lists as impossible (on either my macOS machines or my Linux machines). But if that's a list of stuff that annoys him when using macOS, I guess they're not "silly" to him.
Since my main daily driver for probably 2/3rds or more of the last three decades has been a Mac, I'm more familiar with it, so things like focus-follows-mouse takes a bit of getting used to when I open up my Pinebook or my RasPi400 - but I gt over myself and get used to it pretty quickly.
People who complain that macOS isn't exactly the same as Ubuntu (or Windows or $randomLinuxDistroDeJour) seem, to me, to just be wanting to complain about stuff.
Every OS has its quirks, doesn’t take more than hour to smooth the rough edges off a new machine if you’re comfortable with the ecosystem. You have to do the same on Ubuntu or Win10 or Pop.
Run Logic X and all the AU's.
For example, in the EDA world it's very common to have Linux/Windows support but not macOS support (eg.: Intel Quartus, Xilinx Vivado, Cadence Virtuoso and others, Mentor Graphics Calibre and others, ...).
They're important to me, moreso than what's in the OP's list.
Seems a bit disingenuous.
Maybe one day.. https://www.darlinghq.org/ :D
[1] https://www.docker.com/blog/speed-boost-achievement-unlocked...
Not as good as native linux though.
This is because it’s running in a VM, not natively on the host. On Linux you can do any of those things from the host directly, without needing to shell into the container.
I actually found this so incredibly frustrating when I started working at a job that uses docker that I argued in vain against using docker at all, and then when that failed, I switched to doing all my coding and other technical work on a Linux VM and only using macOS for email.
But yeah, otherwise it will be a Linux VM running on top of Hyper-V.
If it was built against a different Unix (say Solaris) it still wouldn't help MacOS
That is something I do actually like there. And Apple isn't even forcing developers to do it (unless they want to publish in the app store which most apps I use don't do), just more and more app developers sandbox themselves.
As a developer who needs docker, OSX is not the best choice. If I was a designer, OSX is a better choice.
The only thing that pisses me off, is that the MS-Teams client for Linux is roughly 5 decades behind the Windows client, feature and stability-wise.
(And still have Windows on my private laptop for Fusion360 and games)
With Windows, put simply, you don't own your computer.
I haven't used Windows in over a decade and cannot be happier about it.
Windows at this point is a games console for keyboard and mouse games. Nobody uses Windows for anything serious, except old ATMs running Windows 95 and airports that want to embarrass themselves with blue screens of death. Most of the stuff on Azure including Azure itself is Linux based.
Also, I hate Hungarian notation.
I would like to see more of posts like this for all Desktop environments. Like things you can do in MacOS but not in default Ubuntu setup.
I think the larger point is: in Linux, some things are complicated but most things are possible. On Mac and Windows, some things are easier but many things are impossible.
So there's definitely a tradeoff. But since I have to use this tool for the majority of my waking hours in order to make a living, the ROI from taking a bit longer to solve an issue and then having it solved virtually forever makes Linux a better proposition IMHO.
I'd argue we could have both if not for commercial reasons. Apple deliberately chooses to limit control, Microsoft too.
With all the resources they have, you really think they couldn't give you more control without sacrificing stability?
There isn't infinite time and money in the world. Every hour making one feature more stable means an hour not invested in another. Flexibility and control are just additional features. If you want to change the system font, you have to test (and support) a much wider array of things, especially if your UI guidelines are as restrictive as Apple's. Every piece of control you expose to the user increases the engineering cost of writing and maintaining the software.
And frankly, if more people wanted that level of control, this year TRULY would be the year of linux on the desktop. But they don't.
Control is deliberately withdrawn to preserve the commercial interests of the producer, not because it is technically impossible to add it to stability.
You want stability? Provide a perfect default configuration. You want control? Allow tweaking that configuration in detail for users that are willing to do it.
The obvious caveat is that many things are impossible out of the box. There are plenty of tools available to address a good number of the shortcomings mentioned in the story.
That absolutely true but I feel like we all already knew it.
Oh and Lightroom, Pixelmator and Excel don't work on Ubuntu.
Focus-follows-mouse, UI customisability, package management, second-hand citizen status of Linux apps, and a few others. It's also interesting to see what has appeared as supported / possible, on both operating systems.
https://web.archive.org/web/20060613222321/http://www.linuxd...
Page 2: https://web.archive.org/web/20060613222321/http://www.linuxd...
Page 3: https://web.archive.org/web/20060613222321/http://www.linuxd...
Page 4: https://web.archive.org/web/20060613222321/http://www.linuxd...
Best I can tell, that was never actually discussed on HN.
> I have multiple screens and multiple windows. I want to be able to hover over a new one and start interacting with it without clicking.
Having attempted to implement this once, doing this is nontrivial. If you try to focus anything under your mouse then you can end up changing the selection state of tables and controls, which is generally undesirable.
https://github.com/sbmpost/AutoRaise
Doing this in a way that feels intuitive is non-trivial. If you go the simple route and focus every control (so you can do things like tab between them) you run into the issue of the mouse activating some of them as you go over the element and giving it focus–for example, if you do it on a window sidebar, you'll switch between the tabs. I didn't get a chance to really thing about it, but I was thinking of just giving text elements focus and considering it to be good enough; but there are still challenges there: should you be able to focus on a search field (which might blow away the current context and replace it with a "searching" screen)? How should I handle keyboard shortcuts?
With multiple monitors it makes much more sense to me than click to focus.
I tried it on windows but a lot of programs don't expect it and raise themselves when they get focus. My mac has only one monitor.
In most window managers (including Windows), the first-class entity is the window. Windows are related to applications (or processes), but they exist as their own thing, operate independently from most other windows without special handling, and usually have their own menu bar.
Apple took a severely different tack on this fundamental abstraction: the first-class entity is the application. At all times, there is at most one application with foreground context and all others are background, and it's actually a pretty expensive operation to switch between them. They did this for a couple reasons (some accident of history and some practical... for example, Apple's decision to put the application's menu at the top of the screen to coincide with the original usability studies on how the edges and corners of the screen were the easiest to mouse to implied there'd be at most one application at a time owning a global menubar context).
This had huge consequences for the constraints put on applications. For a long time, it was hard to write a tiling window manager for Mac OS X because there was no language by which you could describe all windows; you'd have to query every app for the geometry of its windows, then compute a new global layout, then foreground each app so it could update its window positions. This is no longer the case, but it made any TWM implementation a toy for years.
The upshot of this design for focus-follows-mouse is it has a lot of unintended consequences and can make the system actually quite hard to use in a focus-follows-mouse configuration. For one, it induces latency in all your mouse operations if you're constantly toggling the foreground app as you mouse around. For another, it actually makes it quite difficult to mouse to the menu bar if the menu bar is going to change when your mouse drifts over another window.
(It is interesting to observe how, while at some level "they're all just window managers," the detailed decisions made by the different OS developers led to some things being subtlety much harder in one or the other).
- No way to fullscreen a window without moving it into a separate workspace. All a new workspace achieves is making it difficult for me to switch between this app and my other apps! (individual apps can implement this, and some like VLC do, but most apps don't)
- No native support for containerisation. Containers/Docker are a great technology, but even on my M1 mac where literally everything else is super speedy, they're really slow.
What you get when you hold Option is the way that was the previous "maximisation" option, before they added the full screen mode which I also abhor.
I'm just trying to be helpful, possibly barely pointing out that things claimed to be impossible are not (and not argumentatively, only because folks may stop at that and have to endure something when there are solutions that would fit their use case)
My main issue is that all the different "Terminals" have subsets I like on them, but none have all the features I like lol. It's not a big deal though. FWIW I'm trying out the Warp term now (used wezterm on linux) and it's been mostly enjoyable so far.
The animation is shorter when you're on a model without a 120Hz screen, so it gets a little more bearable there.
But some of these may help. There may be more (or less), it's been a while.
Also, try to use keyboard shortcuts: the animation is muuuuch faster than with gestures. In Keyboard prefpane, Shortcuts, Keyboard, Mission Control (make sure to have many desktops created). I have desktops set to ^1..^0 and left/right to ^left and ^right (which is sadly the only way to move to fullscreen apps), and disable MRU automatic space reordering in Mission Control prefpane.I've spent more time than I'd like to admit trying to get rid of this workspace switch delay. The tipping point for me on it was switching to a 16" Pro with a 120 Hz screen and finding out that means it now takes longer to switch.
On the 120Hz MacBook Pros, there's an advanced iTerm2 setting that lets you change the maximum frame rate to 120 or above (adaptive frame rate also needs to be disabled).
For monitors with a high refresh rate, it's worth checking out. You can see the difference by running:
But it has Cmd+Shift+E, which I wish some other emulators I like would just wholesale copy that feature.
Honestly, it's one of the better emulators out there; it's my recommendation if you're otherwise stuck on macOS.
Either you're using Docker for Mac which itself is slow on IO mostly due to the macos-linux file share syncing every single fseventsd<->inotify or you end up running intel images on aarch64, which uses non-virtualizing qemu to emulate the foreign CPU (see github.com/tonistigii/binfmt)
I'm using Docker in a Fusion instance, sharing /Users through vmhgfs (which in my tests performs better than DfM shares) and it's plenty fast as long as I stick to native images (intel on intel, aarch64 on arm64) and don't outrageously reach out to the shared dirs (notably DfM shares /tmp by default which is ridiculous)
Container tech on Darwin would bring little in most cases since it would containerize a darwin userland, which, while cool, is probably not what most people want. There's no shortcut from running a Linux kernel in a VM to run a Linux userland on Darwin.
If you haven't tried the new VirtioFS accelerated directory sharing in Docker for Mac, it makes a _huge_ difference to I/O performance of mounted volumes.
Nonetheless, I salute the years-long effort from the Docker team on that one.
Edit: the static blog generator I wrote [1] takes 11 seconds inside a Ubuntu virtual machine with the directory shared with MacOS on an Mac mini late 2014. Docker, on the same machine, takes 1m13 seconds using gRPC FUSE for file sharing. 1866 HTML files are being generated.
[1] https://github.com/john-bokma/tumblelog
When you hold ALT while clicking the maximize button it should work. There used to be a setting for this when they introduced it.
One of the reasons why I almost never use the full screen feature. You can click on the full screen button on the too left-hand corner of each window whilst holding Option, I think that’s the closest you can do out-of-the box. You can assign a keyboard shortcut for this very easily (seriously, the way we can define keyboard shortcuts for almost anything and have them work in almost any app is amazing; nothing comes even close on the Linux side).
Otherwise, you can use something like Magnet or Rectangle, which enable exactly what you want.
macOS is frustrating to use without a mouse. On one side the shortcuts are consistent, work everywhere, and are very deeply customisable. Really much better than anything I have tried on other platforms. All the menus are very easy to use without a mouse once you know the shortcuts (which, granted, are not obvious if you don't know they exist). Emacs-like shortcuts in all text fields are absolutely fantastic. The fact that Command is used throughout the GUI leaves Control available for things like terminals, which is awesome (e.g. there is no conflict between Control-C to kill a process and Command-C to copy some text). But at the same time there are things like window management that pretty much require a mouse, but really should not.
Note that with any non-fullscreen window I can continue to see live updates to the window in the mission control view. So I could for example continue to watch a video (albeit smaller) while watching chat messages arrive in another window as my friend sends them. But with a macOS fullscreen window I can't do that. If I open mission control then I can only see the fullscreen window (because it's the only window in the workspace), and if I switch to another workspace to the see the contents of those windows I can no longer see the fullscreen window. Infuriating!
I’m still not sure why you can’t switch between applications even if they aren’t on the same workspace though. Cmd tab, Cmd tab takes me from a full-screen video to the last app on a separate workspace, and right back to the video.
And if you want to see other apps at the same time as the video, no wonder full-screen gets in the way.
> And if you want to see other apps at the same time as the video, no wonder full-screen gets in the way.
You say that, but is doesn't on windows or linux. And it didn't used to on macOS either until they changed things around a few years ago.
I would also recommend trying out if BetterTouchTool can't change the behaviour of the green (+) button as it's pretty powerful.
I love Ubuntu and I use it with Cinnamon desktop on the daily alongside my Mac, and I love the customizability, but I also like just being able to turn on my laptop and do stuff without having to fiddle with a terminal unless I want to, or install a new app by just downloading a thing and clicking on it and agreeing that, yes, I'm trying to do this thing. And that's just not quite there with Ubuntu yet.
(Also, trying to do music stuff is mostly a nightmare of JACK and Alsa headaches. I can write generative music code in at least two languages, but I just wanna plug my guitar in and record things and use plug-ins without having to recompile shit.)
There's places for both. Use whatever works for you.
This means that without any special setup, both real-time audio software (which uses JACK) and 'normal' software (Pulse, ALSA) can co-operate on a single system with a single digital patchbay between all of them and the system output devices (including Bluetooth audio devices).
I mean if that's a legitimate black mark, that's 1 ding against MacOS and we can bury Linux under a thick pile of back marks.
I can print in MacOS, but I cannot scan. It used to work, but color scanning was broken few years ago, and about two years ago b/w scanning was broken too - Preview or Image Capture will just produce something malformed.
There used to be a workaround using Samsung scanning utility, but it doesn't work since Catalina, due to the utility being 32-bit app.
So what I do? RDP into other machine that does not have such problems (either Linux or Windows) and then transfer the scanned file.
So much for "just works".
This hasn't been a problem in a while. You definitely don't need Jack for recording your guitar into a DAW with a backing track (I have a studio full of synths that I record - 24 tracks in, 24 tracks out, via a class compliant USB audio interface). And as the sibling comment points out, Pipewire makes things better still; you can point your DAW at "ALSA" (really Pipewire under the hood) and also play Youtube vids in a browser at the same time - this was of course possible with Pulseaudio or Jack, but both of them had their own quirks. Pipewire is overall really nice and just works cleanly.
I am really curious what you had to recompile.
System Preferences -> Accessibility -> Display -> Menu bar size
(This doesn't let you change the menu bar to a different font, but it does make the whole menu bar including the font bigger, without changing the screen resolution, which seems to be what the author wants?)
You didn’t used to have to do that in macOS? I remember plugging in my android phone and it mounting my memory card. Is OP referring to accessing something else?
> Mount an SSH or NFS drive
> In Ubuntu, I get a nice little GUI for picking network shares. Impossible on Mac.
I’m a little curious what the difference is between macOS and Linux here.
There’s definitely a lot of legitimate points here and a few questions on others.
Mass devices can be easily corrupted and have to be unmounted from the current device. MTP can stay mounted and accessible by the mounting OS and source device simultaneously and are much more difficult to corrupt.
It also allows the host device more security and control over what the guest can do.
- You can't allow apps on the phone access to the filesystem at the same time as it is mounted as a mass storage device (because you may corrupt the FS).
- It doesn't work with full-disk encryption used by newer Android versions, because your computer doesn't have the key (and the key is probably stored somewhere in the TPM of your phone, encrypted by your password).
- It requires the computer to support the FS used by the phone, which means necessarily using something that Windows/macOS supports (which mostly limits it to FAT/exFAT/NTFS)
So starting from Android... 5 or so? you can't mount as mass storage anymore. This probably consists of 99.5%+ of currently functioning Android phones.
MTP is file-level protocol and you can continue accessing all files on the phone at the same time as accessing them from your computer. MTP is part of the "Windows Media" framework and so works out-of-the-box in Windows. Linux supports it for 8+ years through GVFS and KIO, while Apple doesn't to this day.
For me it's also ingrained Command-Q into my brain to close an app. Especially because even before this change apps often didn't close when you closed the last window. It's always been like that. Only some apps like System Preferences do it.
Clearly the appropriate solution would be to somehow make sure that I never need to force close the application, but the damn thing won't even let me restart if some app has hung (I am looking at you MS teams!)
I’d put more money on people on Touchpad devices force quitting more often than anticipated, so they removed it.