Nothing came close to OSX’s Expose 15 years ago.

OSX has gone backwards in terms of windows management since then.

Linux is far superior. Even Windows is slightly better because at least windows snap to edges.

They could have gone down the path of translating the windows UI APIs, though I think it's better that they left it as is. The bigger issue however, is that there are different systems depending on what it is you want to configure, and it's all ducktaped in an ancient registry that I'm just amazed only breaks as often as it does.

Not to mention that the thing Windows was supposed to always be better at, was driver support. On windows, you have to manually source them, and try as best to avoid all the bloatware that comes with. Windows itself might also decide to replace a driver with an older one (version, release date...). WiFi drivers didn't work last time I upgraded the mobo either.

As for Linux. Completely agree. Gnome is consistent, and gets out of the way often enough. There are some annoyances there too. I have my 90 y/o grandma use Linux/Gnome, because that's what Just Works these days.

So you have to disable signals prior to doing anything "non-async-signal-safe" and re-enable them thereafter? That's a pretty big "but"...

At least Dell supports their hardware: have you tried updating the monitor firmware or submitting a report?

In that case, I 100% agree with you, the Oracle article seems much better than the Apple Insider article.

As you know, subpixel rendering only works when you have a very specific display (i.e. LCD) since it takes advantage of, and hence relies on precise characteristics of how the pixels are physically laid out in the display.

This means that subpixel rendering fails to work on displays that have different layouts, the most recent example of this have been newer OLED displays (I think QD-OLED) which has a different pixel arrangement and then you ironically had Windows users complaining that the text looked jagged (although you are able to change the algorithm for subpixel rendering to match the QD-OLED, the unfortunate problem here is that its not really possible for this to work all for applications as it depends on which UI engine you are using, Windows is a giant mess here).

Long story short, I can see why Mac removed sub pixel rendering, its basically a workaround that reflected a time when you had less dense displays which were all LCD and had the same physical layout. Nowadays though high pixel density displays are a lot more common and then you don't need sub pixel rendering at all (and it works with all of the different physical pixel layout arrangements)

I use the command line almost exclusively for file management and avoid it like the plague.

How to lose your work using Undo Copy in Windows

https://news.ycombinator.com/item?id=35927413

The answer to most "it's a bit dumb that MacOS doesn't let you / forces you to" is "install app X, Y, Z".

- Don't like that apple's "Music" app pops up when you connect a Bluetooth headset? => Install an app.

- Want to be able to "alt tab" through windows of the same program, or in general not be uselessly flawed? => Install an app

- Want to be able to move and resize windows without aiming at the exact edge pixels of the window? => Install an app.

- Want to move & resize windows to very common places and sizes on a screen? => Install an app.

- Want global hotkeys for whatever? => Install an app

- Want a software package management system a'la apt? => Install an app.

- Want to rebind keys or make things like Home/End not be dead keys... because apple keyboards don't have that, and they cannot be bothered with it. "you should be using "⌘ + →" anyways... or, I suppose it depends on the window"? => Install an app.

- etc....

You don't get any of these annoyances with Linux / Gnome. "Why not use that if you hate MacOS so much?" I pretend to hear you say. First of all, because of anti-competitive reasons by Apple, I sort of have to. Secondly... something something angry old man yells at clouds.

This is opposed to calling `sigwait` or similar to actively suspend and wait for a signal, which is not possible to do here.

Granted, it may be that the stars align and their implementation works in practice, but that does not make it any less bizarre.

So far I haven't managed to turn off the firewall scare popups, I did manage to remove that crap in the task bar that pops up the weather and selected news covering half the screen if you hover in the wrong place, I may or may not have turned off the OneDrive upsell, and I also got a full screen message to upgrade to 11 for free when booting once.

Great user experience overall. And don't tell me I can spend another week to turn those off, is Microsoft paying for that wasted time?

I think the display resolution market suffers from some opposing directions: people who do productivity work like high resolutions, but since Windows (majority of the market) still seems to struggle to scale UI elements correctly some people prefer lower resolution. Also, gamers associate high resolutions with heavy GPU requirements or lower framerates. And then there are companies that are used to spending the absolute minimum on screens that are barely 1080p.

1. There's a button on my M3 Mac keyboard that says 'delete'. It deletes stuff everywhere else, but welcome to Finder, this simple button doesn't delete a file or a folder. They thought giving it a two/three keys combination was a better idea.

2. Similarly, they thought you rename file/folders more often in a day than you open them. Why else would they make you press two keys to open one, and the most common single button in the world to open files (Enter/return) to rename one instead?

3. No 'Cut' (I know the alternatives). One might find it surprising but there are fans that defend even this move - they say it's because this is more "intuitive". You only copy everything first and only at the time of pasting you decide whether you want to move it or copy it. I say, if that's really the case, why does every other app and Editor (including the ones made by Apple) have a Cut option? Why don't we always follow this more intuitive method of "copying" first and then pressing the Option button while pasting. Let's remove Cut from everything and see how intuitive people find it.

4. By default, the Finder doesn't even tell you where you are. That's a basic requirement from a File Manager. Sure, fiddle with the settings and at some place you'll find an option to kind of enable that.

5. No option to quickly create a text/other file in a given folder. If you've struggled enough and enabled the view where you're able to see where you are at the moment, there's a _chance_ you'd also see that from that view you can actually go to Terminal directly in that folder. Go there, and type `touch <filename>` to create a file in that folder.

6. You got a full path to go to somewhere on the disk. You quickly open Finder. Oh, the default view doesn't even have a place to paste it and hit Enter. Who could have thought to hide it? Same problem with the native 'File Open' dialog that's used by all the other apps on the system. Even if you have the full file path, unless you go to settings you won't find a way to go to that file directly.

7. No easy (if at all) way to persistently map a network drive that automatically remaps when the network drive is available. You have to keep connecting to the SMB server again and again.

8. Side bar folder shortcuts get removed when the folder is deleted and recreated for any reason. You have to recreate them. Not sure who made all these decisions or if they were even thought about.

9. No straight way to even 'Refresh' the files in a folder. Try going out and in, closing and reopening Finder and just 'hope' that it will update and show the newly created files or changed file properties outside. Many times it just doesn't.

10. 'Get Info' allows you to also 'Set' (a lot of) Info. This is UX 101. They could have just named it `Properties` instead.

11. Hell, you can't even maximize this app window by double clicking on the Title bar, unlike for example another Apple made app 'App Store'. No consistency.

12. In List view there's no padding, I can't even find a place where I can right click and paste a previously copied file in the 'current folder', without it hitting a subfolder and pasting the files into that instead (assuming the folder has many folders inside). I'm surprised no one found it in internal user testing.

These are just off top of my head, I'm sure I can find more if I spend some time. There might be involved solutions to these, but there's no way we can call this an 'intuitive' interface. And this is just one application in the whole Operation System.

I use it undocked very rarely, to the point that those hardware advantages are irrelevant.

The downsides are still there when docked however (the horrible glossy screen and the awful OS I have to handle).

Do you use full screen windows ?

Yes, the OS could do that. I'd prefer if Apple made that key configurable. But the problem isn't Apple and Bluetooh Headsets, it's that Apple made the play/pause button unconfigurable (without additional software).

>It's the headset doing something wrong. What a fascinating take. You wouldn't happen to be working at Apple R&D?

IT IS THE HEADSET DOING SOMETHING WRONG! No one asked it to send play when it connects, the manufacturer decided to do something brain dead there. It still messes with Windows and Linux machines too if you set the play/pause button to launch an app.

Do you happen to work for a bluetooth headset manufacturer? It sure sounds like you're excusing their broken behavior.

2. Ctrl+C works for copy when text is selected otherwise SIGINT.

It is subpar, however, when compared to Windows Terminal.

Can't compete with the streamlined easy of highlight-to-copy. I never use a keyboard shortcut to copy text from a terminal (except for yanking in vim / evil-mode)

2. I remember the XFCE4 Terminal using Ctrl-Shift-C and Ctrl-Shift-V for copy/paste and liking it, no more SIGINT by mistake. But IMO a minor gripe, you can remap keys for copy/paste in most self-respecting terminal emulators anyway.

3. I agree on that but passwordless sudo saved my sanity and I don't care anymore. If I install a virus then I had all the troubles coming and I'll take responsibility. ¯\_(ツ)_/¯

> This did not improve performance, it was just an unnecessary hack

Well, the Android VM certainly uses a signal mechanism for safepoints and stack overflow checking, for a reason (https://android.googlesource.com/platform/art/+/master/runti...) (both latency and code size), so don't sit there and tell me that the VM running the world's most popular OS is pessimizing itself pointlessly.

> The kernel handles hardware traps, which may or may not lead to UNIX signals.

Not all traps result in signals, and not all signals are traps. Nevertheless, the POSIX signals API is the means through which Unix OSes provide user programs the ability to interact with CPU traps. (Windows does the same thing, morally, with SEH and vectored exception handling --- https://learn.microsoft.com/en-us/windows/win32/debug/vector...). Any decent OS should provide applications with the tools they need to make full use of the underlying hardware. All these anti-signals people are just arguing that programs be bigger and slower, because they can't make full use of all the hardware features of the system, out of, ultimately, an aesthetic objection to signal handling.

I did. You just didn't want to listen.

> Speakers bad in a MacBook? Come on man at least try to be objective.

Mac users that list the laptop speakers as good are really digging in. It is marginally better than regular shitty laptop speakers, but it is still very shitty. Any cheap proper speakers are much better, to the point that listing it as a positive is misleading.

And I can use my boring Dell with my windows open on a sunny day without issues. MacBook requires me to close the blinds.

Installing root certificate into my system without any explicit verbose flags is something malware would do. The developer who thought that's a good thing is the one whose software I'd avoid. His views on usability are completely opposite to mine. What else will he do by default? Listen on 0.0.0.0? Add firewall exception for usability? Create tunnel to the Internet automatically so I can share my work with others without those pesky port forwardings? Some people might like it, but not me, I prefer things as explicit as possible, when it comes to questionable features.

compare with what?

I strongly disagree. I feel that Windows Terminal suffers from a bloated UI and completely asinine organization of the configuration options.

Also I find a simple Konsole on KDE+Linux superior for every Windows and macOS setup (including iTerm2).

This whole thread is about SIGSEGV, and specifically their SIGSEGV handling. However, catching normal signals is not about efficiency.

Some of their exception handling is still odd: There is no reason for a program that receives SIGILL to ever attempt continuing. But others is fine, like catching SIGFPE to just forward an exception to the calling code.

(Sure, you could construct an argument to say that this is for efficiency if you considered the alternative to be implementing floating point in software so that all exceptions exist in user-space, but hardware floating point is the norm and such alternative would be wholly unreasonable.)

> The wonderful thing about choosing not to care about facts is having whatever opinions you want.

I appreciate the irony of you making such statement, proudly thinking that your opinion equals fact, and therefore any other opinion is not.

This discussion is nothing but subjective opinion vs. subjective opinion. Facts are (hopefully, as I can only speak for myself) inputs to both our opinions, but no opinion about "good" or "bad", "nasty" or not can ever be objective. Objective code quality does not exist.

For example, one kind of program organization that used to be more common in Unix but that remains legal involves keeping signals masked all the time except around certain blocking system calls, e.g. ppoll, that atomically unblock signals and wait. In such a program, a signal can arrive only inside the blocking system call and so the handler can call regular functions without the usual strictures of asynchronous signal safety. (Consider responding to SIGWINCH, which tells you about changing terminal size.)

Synchronous signals are also special in that they're, well, synchronous. That means that in the signal handler you can examine the target memory address or instruction pointer and take action specific to a given spot in your program --- e.g. longjmp to an error handler.

All of this is useful, safe, and legal under POSIX. The main problems with POSIX signals are that, 1) as this thread underscores, most people don't understand them, and 2) signal handlers are process global and hard to share. (Consider if you're running two VMs in a process and each wants to use a SIGSEGV GC safe point trick.)

(userfaultfd, sadly, requires more system calls than a synchronous signal handler to handle anomalous memory access.)

We should be enhancing POSIX signals to make them easier to share, not casting aspersions on them.

If you have a single-threaded program sitting in ppoll, you cannot ever receive a SIGSEGV during said ppoll unless you passed it bugus fds, timeout or sigmask pointers. A sleeping process cannot segfault.

If you register a SIGSEGV handler, you have zero guarantees that it will only fire at a particular time in your code as it is delivered on any pagefault from any code accidentally generating it. This is why the async-signal-safe rules apply.

If you try handling such fault, what needs to be reentrant is the full call stack that lead to the fault, and every call made from the handler. If, for example, the fault is generated from an event loop handler (in case of a single-threaded example, most things run off event loop handlers), the signal handler must in turn not touch the event loop (no adding/removing/adjusting events, no dispatch) unless the event loop is fully reentrant.

ppoll is a real system call on all Linux systems and has been for over a decade.

> It is true that you could try to figure out whether the faulting address is within a range you thought belonged to a particular thing,

Which programs do, reliably, all the time.

> You won't get false negatives, but will get false positives.

No, you won't. Once a program wanders into la-la land of memory corruption, all bets are off anyway.