> how awful macOS is
just curious, but what parts are awful? customization? or just generally bugs? > how awful macOS is
just curious, but what parts are awful? customization? or just generally bugs?- I've given up getting the permissions on my folder share (Samba) to stick. MacOS keeps reverting to defaults, with means everyone has full read/write permissions. Network files sharing should be a fundamental feature without hassle. Not I'm forced to read up on how to share using NFS.
- I created a FAT32 partition to share files with Asahi. I also setup GDrive syncing on it. Unfortunately, MacOS keep creating these annoying files starting with ._xxx for each single folder and file (and there are hundreds of them). I'm not sure why.
- I had to wipe the machine and do a re-install to enable third-party kernel extensions to load
- The system volume (the primary SSD) on the system does not appear in finder. I keep dragging it to the finder side-bar, and it keeps disappearing under unclear circumstances.
- I just now got a black screen of death after ejecting some mounted drives on my other Mac, an intel running Mojave.
- When I maximize windows, they don't fill up the screen. Usually they increase in size by what seems a random amount. Most times I have to manually drag the edges to fill up the screen. Even after that, a lot of time there is some small margin below the window that cannot be fixed. it's a small issue, but very annoying.
- And too many other weird stuff to list here.
There are a ton of background services that periodically spin up for no obvious reason, consuming a ton of CPU for a few minutes at a time, then go back to idle. I don't know what they're doing or why. Luckily since they're background services, they're bound to the efficiency cores on Apple Silicon, so they don't hurt battery life or thermals too much most of the time.
And as far as bugs go, the worst part is that bug reports through the Feedback app go largely ignored and bugs seem to keep accumulating. Even for bugs with clear and well-documented repro cases, Apple doesn't seem to pay any attention.
I'm a game developer, so the majority of my bug reports come from issues I've experienced with the graphics drivers or with Xcode. Here's a few examples:
- On macOS devices with > 60Hz displays, there is some awful stuttering with Metal apps in full screen mode. For some reason, CAMetalLayer nextDrawable sometimes just takes a very long time whenever it uses direct-to-display mode for presentation. That mode is implicitly enabled for full screen Metal apps, in order to bypass the display compositor and theoretically reduce latency. This bug also applies to MacBooks with the built in "ProMotion" (120Hz) displays. I'd be perfectly happy if there was just some flag to say "don't use direct-to-display", but if there is one, it's not documented anywhere. I haven't found a workaround yet. I originally reported this in August 2022. Apple replied once in October 2022 to say "we can't reproduce this, please provide a demo app". I provided the app that reliably reproduces the problem within an hour of their reply, but they've been silent since.
- Metal and OpenGL (the latter is emulated via Metal on Apple Silicon Macs) both exhibit a bug with triangle merging that causes partial derivatives to go very wrong along primitive edges. There's a usable workaround for this on the Metal side (just enable a [[sample_mask]] even if you're not doing multisampling). There's no such workaround for the OpenGL side, unfortunately. I was able to work with Asahi Lina to fix this for Mesa on Asahi Linux, and the fix itself was actually really trivial and didn't require a sample mask hack (it took a lot of debugging to figure out, though -- but that's how reverse engineering goes). To solve it, Apple would simply need to set a particular bit to disable triangle merging whenever the fragment shader uses derivatives. I reported this issue in December 2022, and Apple hasn't replied.
- This one is not as egregious as some of the bugs I've reported, and the Xcode team has responded reliably in the past. This is the first Xcode bug report I've had where they didn't acknowledge the report within ~14 days or so. In the current Xcode beta, using the graphics debugger will suspend the app but hitting "resume" leaves the app stuck suspended. The normal application debugger path does not do this, just the graphics debugger. I reported this in mid-June 2023, but haven't heard anything yet.
This came up on the ATP podcast recently. Feedback is a very, very crappy front-end for Apple's internal bug tracker Radar (which itself I've heard is not great).
Long story short, you have to submit an entirely new bug report through Feedback with the sample project attached. Apple's developers basically can't see replies to Feedbacks.
I believe the reason has to do with fears over GDPR and data collection. The Feedbacks are scrubbed of any kind of personal or identifying information before they are re-entered into Radar. I don't understand all the reasons, but I 100% agree this is absolutely nuts and not an appropriate way to manage bug reports.
Then you realize you want your mouse and trackpad to scroll in reverse directions. So you download an app for that, which comes with its own updater.
And then you want a flat acceleration profile for your mouse, and you download an app for that. That, too, comes with its own updater.
Next, you realize that the Mac app-based cmd-tab sucks and you'd much rather have Windows-like behavior. So you download an app for that, which also comes with its own updater. (Yes, yes, I know the arguments Apple users bring out, it's always been done this way on Mac etc etc. Still really bad.)
Then you get a taste of auto-tiling on Linux and spend a couple hours setting up yabai and skhd (thankfully updated via homebrew), before realizing that you'll need to turn off SIP [1] for a semi-usable experience.
Then you do go and turn off SIP, and you realize that your iOS apps no longer work because macOS has DRM built into its hardware that detects if you've turned off SIP.
And then, one of those apps prompts you for an update, and in doing so it steals your keyboard focus while you're typing. And you say "is this what I spent $2500 to experience", and cry.
[1] https://github.com/koekeishiya/yabai#requirements-and-caveat...
I come back from lunch and my MacBook sounds like a jet turbine and is nearly on fire. Something needs a whole CPU just to show me a freaking dialog.
No, I don't. I want it to be like pushing or dragging a virtual piece of paper. That's what it is and how it feels the most natural to me. That being said I'm pretty sure you can already configure this without an app, in the system preferences.
> Next, you realize that the Mac app-based cmd-tab sucks and you'd much rather have Windows-like behavior.
No way. I love the cmd + tab and pairing that with keyboard shortcuts for navigating browser tabs is super powerful and doesn't require compromising the beautiful giant amount of screen real estate by inducing multitasking with multiple windows open. It's okay if it comes as a configuration but I would hope the default behavior stays this way.
Yes, that's what makes sense for a trackpad. Many people want that behavior for their trackpad, and also for their mice to scroll in the traditional direction, which is the opposite that of a trackpad.
> That being said I'm pretty sure you can already configure this without an app, in the system preferences.
Have you actually tried it out?
> No way. I love the cmd + tab and pairing that with keyboard shortcuts for navigating browser tabs is super powerful and doesn't require compromising the beautiful giant amount of screen real estate by inducing multitasking with multiple windows open.
I really don't know how macOS-style application vs Windows-style window switchers have any bearing on this. Why should two Firefox windows next to each other be treated differently from a Firefox window next to Safari window? A browser window is a browser window.
Not parent commenter, but yes, there is literally a single tick you can turn on to reverse the direction since forever.
Window snapping, tiling and screen navigation is a HUGE deal. I basically don't use my mouse when programming in Linux and it's really difficult to do the same on Mac.
I use Hammerspoon for this and I have keyboard shortcuts that will move the window and resize it to a predefined position. And I have shortcuts to select certain apps quickly.
Hammerspoon is scripted in lua so I don’t feel very constrained in what I can do.
There is also Phoenix, it uses JS.
https://gist.github.com/NayamAmarshe/c8dfabefc5a25df518edd34...
How is it worse? Ctrl + C, Ctrl + D, Ctrl + Z all work as expected in the terminal.
Now you want to copy something, which is obviously not going to work with Ctrl + C, so you just add a Shift to it instead of moving to a totally different key (which you absolutely still could, btw).
The mac way is less efficient & less flexible.
I've never had an issue with Ctrl+Shift+C. I also don't press Ctrl+C accidentally because I know when I'm using the terminal.
Even on macbook, I don't have issues with accidental presses but I don't like that I have to press an entirely different key on the keyboard to use the terminal.
Practically everything is handled with Cmd, with Option/Shift/Control being modifiers. It's the exception if something is handled exclusively with Option/Shift/Control, example being web browsers and Finder for tabs. Text selection is superior in macOS, and anyone who argues PgUp/PgDn/Home/End being a better solution in combination with Shift and Ctrl is insane. Depending on the port of a 3rd-party application, it may adopt macOS shortcuts and be consistent with everything else, or keep IBM/Windows-style shortcuts and break compatibility with other apps.