Hacker News Reader

Comment by threatofrain | Hacker News Reader

Ouch.

> The issue seems to be caused by some new security APIs in Big Sur. Apple has apparently started returning with errno=EINTR from some system calls that previously never returned this error. Fixing this problem on the PostgreSQL side is not trivial, since it seems to require changes in both PostgreSQL itself and possibly in extensions as well, so it's unlikely to be fixed quickly.

> These are the possiblities:

> Try to disable security software (eg. Antivirus products) that might trigger the problem Downgrade to macOS 10.15 Send feedback to Apple that they should fix the issue. PostgreSQL is unlikely to be the only affected software. Hope that someone fixes the error in PostgreSQL

https://github.com/PostgresApp/PostgresApp/issues/610#issuec...

View on HN

Those proposed fixes don't make any sense for macOS. Nearly no one runs antivirus software on a Mac, and downgrading to prior OS version is basically impossible for most people.

We've been made to use Macs at work now and they have McAfee on that we can't disable, causes no end of performance issues

We also had anti-virus software on every Mac in large enterprise. Took a lot of effort to at least except source directories.

Oooh I wonder if I could get that here - things like npm install(presume any package manager, certainly homebrew) or git commands take obscenely long times.

Commands that download random 3rd party code and dependencies from the internet are precisely the kind of thing that should be included in a virus scan, surely?

Especially since any npm package can execute any code at install time in npm's default configuration.

On Linux this is extra juicy since you cannot globally install any package without root unless you explicitly changed the directory's permissions and/or location.

By default, npm installs into the local project directory, as it should. Only the OS package manager should touch system directories. Before using the "--global" flag, think about what you're actually trying to do, and what the better way to do that would be. One conventional workaround is to install commonly used tools to "~/bin". Root is not required for that.

Of course, it's a good idea to keep the username used for development separate from the one used for browsing the web. It wouldn't be surprising for rogue npm packages to search for e.g. credit card details. I'm sure the browsers try to obfuscate that somehow, but how much can they really defend against code that is allowed to read the disk?

On Windows npm is using %AppData%\npm by default (which is wrong btw, it should use %LocalAppData%\npm as %AppData% is meant for configuration files).

This means I don't require any elevation to install packages for my user without additional configuration.

Installing tools like yarn or @angular/cli globally is not uncommon.

I have no idea about windoze. I disagreed with the above incorrect statement about Linux.

It wasn't incorrect, you misunderstood. npm just uses silly defaults on Linux while using saner defaults on Windows and mac os. I am a Linux user and having to configure npm to use another path for global packages that I use in literally all my projects is just bad UX.

Sure, npm has bad UX. (For an actual example, see the stubborn refusal to follow XDG spec.) This is not an example of that. Defaulting prefix to "/usr/local" is what every well-behaved Linux package does.

It seems odd to install so many packages at the "global" (but not owned by root!) level, that using the "--prefix=~" flag would be a hardship. I just checked; I have three. You can't fault npm for this.

Only if you believe apps like McAfee are benign.

I'd say excepting source directories is less about engineers believing those are safe directories and more about engineers wanting to except their entire machine and source directories being the compromise management went for.

Only if you believe apps like McAfee are benign.

If sysadmins have installed McAfee on your workstation, then presumably they want to use it. Installing it and then excluding code downloaded from the internet defeats the whole point. (The effectiveness/safety/whatever of antivirus is a completely separate issue.)

> The effectiveness/safety/whatever of antivirus is a completely separate issue.

Struggling to understand how this is a separate issue?

If you have antivirus software installed, you presumably want it to scan stuff that is downloaded from the internet.

On the other hand, if you don't believe/trust in the efficacy of antivirus software, then there's no point taking half measures and excluding some things from its scans, instead why use it at all?

The problem is usually that AVs hook file operations to scan files. Unfortunately, software development performs a LOT of file IO by package management and compilers, and in the case of compilers those files are internally formatted as files containing code (eg obj files, libs or executables), even if they are only temporary during the build.

Because of this, an AV product could work fine for every department of the company, but have an extreme negative performance impact on software devs. To give you an idea, it could mean the difference between a 5 minute and a 1 hour build. These issues are inherent to a generic AV product so often the fix is simply to add those folders to an exclusion list.

Does it provide security for those folders? Nope. But the alternative could make it impossible to get work done.

> If you have antivirus software installed, you presumably want it to scan stuff that is downloaded from the internet.

I don't think you understood the original proposition. This is about corporate-controlled machines. Engineering teams didn't install this AV on their own machines. The point is they didn't install it; it's a company-mandated install. So no, there's no presumption that they want the AV to scan anything.

> if you don't believe/trust in the efficacy of antivirus software, then there's no point taking half measures and excluding some things from its scans

I 100% agree. Half measures / excluding some things IS pointless. But as I said in my above comment, that pointless half-measure may just have been the only compromise management would agree to.

> why use it at all?

Because it's mandated by company policy...

I'd agree. We had Java and used and enterprise package proxy to reduce the risks. Wouldn't do that for npm.

Also these machines were on a seperate network with no share access for example - not on the corporate network with all the other machines.

That’s hilarious. John McAfee himself has a useful video that you can search for on YouTube with instructions on how to disable it.

Link: https://www.youtube.com/watch?v=bKgf5PaBzyg

Warning: NSFW!

That isn't unique to macs though, most of the anti-virus crap is.. crap...

> Nearly no one runs antivirus software on a Mac

There are companies which put antivirus software (e.g. mcaffee) on the macs they provide do employees.

From what I've heard, they're even more detrimental there than on windows.

I got to use this combination a few months ago when I changed jobs. It was just incredibly unstable, MacOS would just crash all over the place, requiring reboots every other day or so. Macbook used to overheat too, spining up ventilator while just sitting idle. Windows ME level of instability while overheating lead to battery failures on some Macbooks.

While McAfee somewhat improved I now consider Windows 10 with WSL2 a better solution for people who don't want a desktop Linux but need/want Linux compatible development environment.

I mean, the fix is really to stop running McAfee on macs, but that aside

> Linux compatible development environment.

macOS is not, has never been, and will never be linux compatible. It's a unix, linux is a unix, if you're looking for a unix it will work just fine. It will not work if you're looking for a linux, you'll have to go through a VM with all that entails.

WSL2 is a Linux VM, and macOS also supports Linux VMs.

> WSL2 is a Linux VM

That is a singularly useless statement. WSL2 is a first-party deeply integrated VM-based system.

"All that entails" is very different between WSL2 and non-WSL2 hypervisors, even on windows.

Running docker with homebrew and on docker, no problems. I am not using antivirus as they produce many problems on mac (and are hellish slow), i guess the problem is really on triggered by antivirus software.

Reply on news.ycombinator.com