4 ms·

So when do average developers just start considering macOS toxic and stop supporting it? About once a week, a story similar to this hits the HN front page: "$ma

So when do average developers just start considering macOS toxic and stop supporting it? About once a week, a story similar to this hits the HN front page: "$majorsoftwareproduct doesn't work on new OSX because they broke documented APIs in undocumented and unexpected ways, without any warning". What the hell, Apple?

cheph 6y ago
> So when do average developers just start considering macOS toxic and stop supporting it? Since forever ago? Nothing new here. I have 0 sympathy for people who use it. They paid dearly for their walled garden.
- treeman79 6y ago
  We love our walled garden. Don’t upgrade for a few weeks, and the hardcore fanboys will have fixes for all the annoying little breaks.
tpush 6y ago
> So when do average developers just start considering macOS toxic and stop supporting it? Presumably at the same time breathless and misinformed comments stop being posted to HN. In this case returning EINTR is documented behavior and the bug is thusly on PostgreSQL not handling it (correctly or at all).
tinus_hn 6y ago
How is returning EINTR undocumented? It’s part of the POSIX interface. It is true that typically Apple doesn’t care if they change things within the limit of the specification and 3rd party applications fail. That’s why they release beta versions.
- Sesse__ 6y ago
  Standards aside, returning EINTR on a write to local file is extremely rare in POSIX. Almost any syscall can return EINTR, but in practice, for all previous OSes, it has been reserved for those that can hang for an undetermined amount of time -- that is, anything from the network. Local I/O should complete in a bounded amount of time, so that kind of sleep is usually implemented as uninterruptable. There's one highly relevant edge case: NFS. NFS looks like local I/O, but if the NFS server goes away, what do you do? Traditionally, the process just hangs in the hope that the server will come back, which leads to the dreaded issue of processes being stuck and unkillable. On Linux, can add the “intr” flag to the mount (possibly via a remount) to allow signals to interrupt the syscall and break the deadlock -- but then you break a ton of software, because, again, EINTR on local file I/O is unheard of.
  - my123 6y ago
    This EINTR is returned here for attempts at file accesses trapped by an antivirus/security layer, which can indeed take an undetermined amount of time, without the OS knowing how long that is... Probably was a hard choice to make for Apple too. Should a thread be frozen for an undetermined amount of time while an antivirus does the check?
    - Sesse__ 6y ago
      > Should a thread be frozen for an undetermined amount of time while an antivirus does the check? Yes, certainly it should.
    - cesarb 6y ago
      The equivalent API on Linux (https://man7.org/linux/man-pages/man7/fanotify.7.html https://man7.org/linux/man-pages/man7/fanotify.7.html), AFAIK, does block for an undetermined amount of time, and doesn't make the open() system call return EINTR.
    - mmis1000 6y ago
      I'd surprise if a antivirus on windows would fail the read attempt from random software instead of temporary hang it. It will most-likely to be blamed as a bad AV here. Instead of just accepted because apple always do the correct thing.
      - my123 6y ago
        It isn't a failure code, EINTR is a code that explicitly tells you to retry.
    - temac 6y ago
      > Should a thread be frozen for an undetermined amount of time while an antivirus does the check? It certainly does on other OSes and on previous versions of this one? Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open, and can actually do something else, and that not on a specialized API but on good old syscalls? From a system design point of view that makes no sense.
fxtentacle 6y ago
About two years ago. I read all of these posts and think: I'm so glad that I dropped OSX support. A lot less entitlement and a lot less work :)
factorialboy 6y ago
Last summer I stopped using MacOS (and the MBP) as my primary development machine. My development happens on a Thinkpad X1 with an Arch inspired distro + XFCE desktop combine. I still use Mac OS and Macbook Pro for meetings, presentations etc. The development experience on Linux is sublime. I feel so much more productive. On the flip side, it took me two or three weeks to customize and setup the way I like it. In the end, it was worth it.
robntheh00d 6y ago
Of course we know for a fact the root cause is Apple It’s never EVER happened that the initial bug report overlooked possible side effects due to other software or customization the user is running Developers should never be inconvenienced by security Every commenter on the internet has surely done due diligence I find it hard to believe this hasn’t popped up sooner with Big Sur having been released months ago.
floatingatoll 6y ago
HN should not be considered representative, and is suffering a great deal of echo chamber self-affirmation here. Apple requires developers to keep up with major breaking changes on their platform, and some folks don’t like that. HN has at least one concentration of such people, seemingly used to Linux/Windows development, who bring an expectation that “code once written should work for years without needing to keep up with OS changes”. That expectation is well-known to be void when working with any Apple platform. open() was documented to be capable of returning EINTR. The Postgres team chose not to write code to handle that case. Now they’ll have to write code to handle that case, or drop support for macOS. That’s life on macOS. They’ll fix it or they’ll drop macOS support. Keep up or walk away. Repeatedly complaining about macOS being a moving target will not change Apple’s direction. Boycotting it will not either. Either target the platform on the terms provided or drop support for it. But for the sake of HN, please just let it go. If you don’t want to be macOS hackers, then just don’t be, and move on to another post. Let those of us who do want to be macOS hackers contribute value to HN instead, by talking about the minimum-viable workarounds and how to find other broken code in Homebrew, instead of driving us away. (For example, there’s an obvious way to solve this that doesn’t require disabling SIP.) The recurring outrage and the reposted miserable viewpoints framed as ‘questions’ with nothing new or curious in them makes HN look immature and unprofessional. Everyone that y’all might have swayed has already been swayed, everyone that hasn’t been swayed has stopped commenting about it, and all that’s left is the echo chamber complaining to itself.
dang 6y ago
Please don't take HN on generic flamewar tangents. Platform flamewars, like programming language flamewars, quickly suck up all the oxygen in a thread, but they're fundamentally repetitive and boring. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

cheph 6y ago

> So when do average developers just start considering macOS toxic and stop supporting it? Since forever ago? Nothing new here. I have 0 sympathy for people who use it. They paid dearly for their walled garden.

treeman79 6y ago
We love our walled garden. Don’t upgrade for a few weeks, and the hardcore fanboys will have fixes for all the annoying little breaks.

tpush 6y ago

> So when do average developers just start considering macOS toxic and stop supporting it? Presumably at the same time breathless and misinformed comments stop being posted to HN. In this case returning EINTR is documented behavior and the bug is thusly on PostgreSQL not handling it (correctly or at all).

tinus_hn 6y ago

How is returning EINTR undocumented? It’s part of the POSIX interface. It is true that typically Apple doesn’t care if they change things within the limit of the specification and 3rd party applications fail. That’s why they release beta versions.

Sesse__ 6y ago
Standards aside, returning EINTR on a write to local file is extremely rare in POSIX. Almost any syscall can return EINTR, but in practice, for all previous OSes, it has been reserved for those that can hang for an undetermined amount of time -- that is, anything from the network. Local I/O should complete in a bounded amount of time, so that kind of sleep is usually implemented as uninterruptable. There's one highly relevant edge case: NFS. NFS looks like local I/O, but if the NFS server goes away, what do you do? Traditionally, the process just hangs in the hope that the server will come back, which leads to the dreaded issue of processes being stuck and unkillable. On Linux, can add the “intr” flag to the mount (possibly via a remount) to allow signals to interrupt the syscall and break the deadlock -- but then you break a ton of software, because, again, EINTR on local file I/O is unheard of.
- my123 6y ago
  This EINTR is returned here for attempts at file accesses trapped by an antivirus/security layer, which can indeed take an undetermined amount of time, without the OS knowing how long that is... Probably was a hard choice to make for Apple too. Should a thread be frozen for an undetermined amount of time while an antivirus does the check?
  - Sesse__ 6y ago
    > Should a thread be frozen for an undetermined amount of time while an antivirus does the check? Yes, certainly it should.
  - cesarb 6y ago
    The equivalent API on Linux (https://man7.org/linux/man-pages/man7/fanotify.7.html https://man7.org/linux/man-pages/man7/fanotify.7.html), AFAIK, does block for an undetermined amount of time, and doesn't make the open() system call return EINTR.
  - mmis1000 6y ago
    I'd surprise if a antivirus on windows would fail the read attempt from random software instead of temporary hang it. It will most-likely to be blamed as a bad AV here. Instead of just accepted because apple always do the correct thing.
    - my123 6y ago
      It isn't a failure code, EINTR is a code that explicitly tells you to retry.
  - temac 6y ago
    > Should a thread be frozen for an undetermined amount of time while an antivirus does the check? It certainly does on other OSes and on previous versions of this one? Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open, and can actually do something else, and that not on a specialized API but on good old syscalls? From a system design point of view that makes no sense.

fxtentacle 6y ago

About two years ago. I read all of these posts and think: I'm so glad that I dropped OSX support. A lot less entitlement and a lot less work :)

factorialboy 6y ago

Last summer I stopped using MacOS (and the MBP) as my primary development machine. My development happens on a Thinkpad X1 with an Arch inspired distro + XFCE desktop combine. I still use Mac OS and Macbook Pro for meetings, presentations etc. The development experience on Linux is sublime. I feel so much more productive. On the flip side, it took me two or three weeks to customize and setup the way I like it. In the end, it was worth it.

robntheh00d 6y ago

Of course we know for a fact the root cause is Apple It’s never EVER happened that the initial bug report overlooked possible side effects due to other software or customization the user is running Developers should never be inconvenienced by security Every commenter on the internet has surely done due diligence I find it hard to believe this hasn’t popped up sooner with Big Sur having been released months ago.

floatingatoll 6y ago

HN should not be considered representative, and is suffering a great deal of echo chamber self-affirmation here. Apple requires developers to keep up with major breaking changes on their platform, and some folks don’t like that. HN has at least one concentration of such people, seemingly used to Linux/Windows development, who bring an expectation that “code once written should work for years without needing to keep up with OS changes”. That expectation is well-known to be void when working with any Apple platform. open() was documented to be capable of returning EINTR. The Postgres team chose not to write code to handle that case. Now they’ll have to write code to handle that case, or drop support for macOS. That’s life on macOS. They’ll fix it or they’ll drop macOS support. Keep up or walk away. Repeatedly complaining about macOS being a moving target will not change Apple’s direction. Boycotting it will not either. Either target the platform on the terms provided or drop support for it. But for the sake of HN, please just let it go. If you don’t want to be macOS hackers, then just don’t be, and move on to another post. Let those of us who do want to be macOS hackers contribute value to HN instead, by talking about the minimum-viable workarounds and how to find other broken code in Homebrew, instead of driving us away. (For example, there’s an obvious way to solve this that doesn’t require disabling SIP.) The recurring outrage and the reposted miserable viewpoints framed as ‘questions’ with nothing new or curious in them makes HN look immature and unprofessional. Everyone that y’all might have swayed has already been swayed, everyone that hasn’t been swayed has stopped commenting about it, and all that’s left is the echo chamber complaining to itself.

dang 6y ago

Please don't take HN on generic flamewar tangents. Platform flamewars, like programming language flamewars, quickly suck up all the oxygen in a thread, but they're fundamentally repetitive and boring. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html