"ERROR: could not open temporary file" after upgrade to Mac OS Big Sur
github.com
github.com
I did a quick check of the source of two other storage engines that run on both Linux and macOS to see how common this oversight is. They both had code for handling this case correctly for years. It was probably never used, but it was implemented because the syscall docs allowed for the possibility.
This is the kind of thing I would have assumed PostgreSQL handles correctly as a matter of pedantry. Given how syscall heavy PostgreSQL is, it will be a fair amount of work to fix it.
[1]: https://developer.apple.com/library/archive/documentation/Sy...
[2]: https://developer.apple.com/library/archive/documentation/Sy...
specifically:
> If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count).
https://pubs.opengroup.org/onlinepubs/9699919799/
Posix is happy with returning EINTR.
> AUTH means that the system call is blocked (on that condition variable I mentioned about), and the user mode daemon is asked about the generated event: "postgres, pid 999, open() on file /path/file with flags 0x400003" - something like that. The usermode can either allow or deny the event by replying.
The use of a user mode daemon to make decisions about whether file access is allowed reminds me of the way TOPS-10 on DEC PDP-10 did access control lists over 40 years ago. It's a method I'd like to see for ACLs on modern systems.
On modern systems the ACL is part of the per file metadata. On TOPS-10 the ACL information was in a separate file that contained the ACL information for multiple files. I don't remember if is was one ACL file per user or one per directory.
An ACL entry could specify file name (wildcards allowed), account and group requesting access (wildcards allowed), program that was requesting access, and what kind of access. The wildcards and the centralization of the ACLs for multiple files is what made this system excellent to use.
When an access was attempted the system first checked if it was allowed by the ordinary per file permissions. If it was access was granted and the ACL daemon was not consulted.
If the ordinary permissions denied access and the caller had not set a flag indicating it did not want to check the ACLs the access was denied. If that flag was not set the kernel would consult the access daemon, which would find the ACL file and check the ACLs within to find the ones that applied and make its decision.
This seems to be a case of not checking or allowing for all possible return codes.
Regardless, doesn't anybody at Apple use postgres? Breaking Postgres should be hard to miss.
[1] https://pubs.opengroup.org/onlinepubs/009695399/functions/si...
[2] https://developer.apple.com/library/archive/documentation/Sy...
This problem occurs if you use anti-virus that delays file activities, and is 100% API consistent. Anyone saying "well it didn't do it before!" is being idiotic, similar to saying you don't need to check the return of malloc because it's usually going to succeed.
pgsql runs perfectly fine.
https://stackoverflow.com/questions/4959524/when-to-check-fo...
> 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...
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.
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?
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.
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.
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.
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.)
Struggling to understand how this is a separate issue?
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?
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.
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...
Also these machines were on a seperate network with no share access for example - not on the corporate network with all the other machines.
Warning: NSFW!
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.
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.
> 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.
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.
Seriously? What is wrong with running programs natively without any layers in between?
Also, IIRC PostgreSQL isn't recommended to be run in docker due to a possible data loss?
Keeping things in containers keeps it from making a mess, and that alone makes it worth it, to say nothing about the advantages for handling dependencies or running multiple copies or versions.
It's only 'random' if you don't know what you are doing. Containers are fine and often good, but their existence/availability doesn't 'supercede' real knowledge.
Apple seems to intentionally break quite a lot of core APIs lately.
What is the point indeed.
It's a breaking change.
To me, it looks like Apple played fast and loose here, changing the expected behavior of something as fundamental as "open", without even mentioning it anywhere (and if they didn't even notice their changes would affect this behavior, that's another problem).
A change like this does not just break PostgreSQL, dotnet (and thereby anything running on dotnet), VirtualBox, and whatever else was mentioned by name, it will break almost everything in subtle ways, because almost nobody ever implemented correct EINTR behavior in the context of these APIs.
Take away good software and all that's left are Apple's "shinies". If it weren't for the potential game-changer that they have with the M1, I'd almost say that they wanted to kill off the Mac as anything other than an iOS development box.
I've no idea whether the behaviour Apple introduced is allowed by the standard, but it seems that it is at least quite common to not explicitly handle this EINTR error because there is an alternative way to just tell the OS to retry instead of returning this error. So I wouldn't be so quick to claim that the downstream apps are coded improperly.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...
https://pubs.opengroup.org/onlinepubs/9699919799/functions/r...
closedir may:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/s...
[2]: https://developer.apple.com/library/archive/documentation/Sy...
I remember when I was first learning Unix programming, and read about this stuff about signals and EINTR, I was baffled how much of a steaming pile of crap Unices are. Later learning about the inability to do truly non-blocking I/O was another similar moment.
Maybe it’s only the case when importing large datasets? Or when running antivirus?installed?
I value stability and autonomy over everything else - I expect the setups I work hard on scripting to work for years, freeing me of this continuous keeping up with the magical incantation du jour. As a hacker, it's particularly frustrating to feel at the whims of someone else.
I think my next setup will be using my (company-issued) macbook as a thin client against a beefy unix machine. That way I'd keep a number of affordances (trackpad, iTerm, fancy Emacs etc) while having my core tooling absolutely stable.
(I have the vague impression that Linux distros have also dramas and instability of their own... looks like the BSD family is more minimalistic?)
It's still all just Fire and Motion [0].
[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
And then goes the Ruby factor, of course.
It ticks all the important dopamine checkboxes of a MacBook-wielding, Starbucks-resident hipster type who has just purchased an .io domain and is ready to code their world-changing app.
Took me a while to figure out how to disable this stuff.
Note that I didn't want to take the time to try to determine which one had the better design and engineering.
(I didn't not know or want to learn Ruby when I made the decision.)
Isn't this the very definition of what a hacker is - somebody who finds creative ways to get things done with systems they didn't create and don't control. If you are pushing the boundaries of a system, you have to expect that sometimes the underlying system stop supporting you
A guarantee that the system you're "hacking" on will always continue to support your customizations in perpetuity as it updates seems to me to be the opposite of the hacker ethos. That's not hacking, that's using a system in a supported manner.
It did everything I needed and while you might argue that writing a Ruby formula is easier than packaging something for Macports, it was a feature I never really needed compared to the ability to easily install specific versions of software going as far back as I needed. Much more akin to the Debian approach, but with faster updates for newer versions.
But, as a hacker, I agree. If it's not neatly wrapped up for you by a package manager then you're perfectly equipped to pull down a prebuilt binary from a repo or compile it from source. If I felt at the whim of the apt package manager I'd still be complaining about the lack of XDG support in tmux, instead of wget'ing a tarball and doing a good old make && make install.
You mind going into a little detail on how you’ll go about this?
And while most would not fly that often, being able to code when internet is not available or in a bad shape is not only a 'nice to have' option, but almost a 'must have'
In the macbook I'd try hard to have no npm/rubygems/maven/... because these are all a security risk.
The unix box would be heavily firewalled so that no bad code could not talk home or reach my macbook.
Communication would happen primarily via ssh (e.g. macos iTerm -> unix box), but also as a NFS share so that I can edit files from my IDE flawlessly (I use Emacs which has a thing called Tramp which makes this unnecessary, but I'm hesitant about its effectiveness).
So, in my macbook I'd have a small number of trusted tools like iTerm and Emacs while everything else, like Ruby/node.js/Java/postgresql processes would happen in the unix box. My workflow would be typically:
- edit files to the NFS share;
- issue commands to the unix box via ssh (an IDE can abstract this away); and
- have some port forwarding for accessing e.g. the webapp I'm working on from macOS chrome.
In the end it would be a pretty vanilla approach and not tremendously different from using a virtual machine via Vagrant. The difference would be that the macOS machine would be thinner, and that the unix box would have greater focus on security and stability.
And of course performance - with a real box I don't have to worry about Vagrant/Docker/... making my macbook overheat.
That's not for everybody, but after ~1.5 year I can say I'm satisfied with my choice, WSL has really been a game changer.
The only thing holding me back is that it's just so much effort. It's frustrating that we need to work-around MacOS. That's why I decided to refuse to update and I want to sit out Mojave until EOL. There are a few known problems, but the workarounds are well known. My experience has been good so far.
https://dreamsongs.com/RiseOfWorseIsBetter.html
specifically the section discussing MIT vs BSD system call return codes.
correction: "PostgreSQL needs to be updated to comply with New macOS Big Sur security API"
The hardware is nice, but as a platform, I just don't get it.
So yes, security on macOS is anoying sometimes ("Do you want to allow App X to access your Downloads folder?") but I can see why allowing software just arbitrary disk/network access nowaday is not a good idea anymore.
My complaint with MacOS is less about the existence of SIP (though I can't say I enjoy it) and more about things like bash, python and even SSH being regularly broken. (These are all actual problems that I've spent hours solving, not theoretical issues.) I don't understand why technical users voluntarily put up with this.
Broken how? That's surprising - in my experience, the versions of these utilities on macos are often missing features relative to linux, but the differences are known and documented...
Reference needed re: SSH, but as to Bash/Python/etc, did you know Apple bundles “old” versions of both? You should not be using the system provided ones imho if you are a developer.
Simple solution:
brew install bash gnutools python
That will very likely solve all your complaints listed, the second of which listed is for those who don’t understand BSD vs GNU/Linux userland CLI options aren’t universal.
its because exaggeration
I regularly take/make phone calls from my desktop or laptop, routed via my phone. Same with SMS. All of my contact details (and photos/etc) are synced with my phone, tablet, desktop and laptop. My logins/passwords are synced between all devices. I can seamlessly switch devices and pick up open browser tabs. Plus I use Apple software that isn't available on other platforms (Logic Pro specifically here).
Sure many of these can likely be done on other platforms too, but on macOS these things (and more) are seamless and don't require any other software, nor configuration (beyond setting up one's iCloud login on each device).
Don't get me wrong: I'm a developer, and use Linux in local VMs and on local and remote servers. But all of these Apple features targeted at 'normal users' are quite nice, and one quickly gets used to them. But perhaps not everyone's cup of tea.
I’m not saying that’s what happened here, but I do know that Apple ultimately expects developers to pay attention to new releases and make sure their software behaves properly with them.
As for standard utilities being broken, I’ve never experienced that on macOS. I do know that Macs get their standard utilities from FreeBSD and not coreutils by default.
Yes, unmaintained software might or might not stay fully functional on macOS for long, but that's not an Apple priority.
The user-space ABIs are widely unstable. Try to run software compiled on Ubuntu 20.04 on 18.04 for example. On macOS, it's just the matter of using -mmacosx-version-min= to make sure that newer functions don't get used.
Or for that matter, even in the reverse case, things break.
The main problem with this is knowing which libraries have stable ABIs and which don't, which is only documented in a convenient way for enterprise distros (RHEL/SLES).
Therefore, correct code can also not handle EINTR as long as it uses SA_RESTART for all non-fatal signals. That's probably the most common case (nobody likes EINTR).
> lack of commercial software like Adobe CS / MS Office
Usually inconsequential for developers
> problems with hardware video decoding
Same
> desktop environments like GNOME3 that like to remove features periodically
This is subjective.
1) You can choose not to use Gnome
2) Personally, I've been using Gnome for the past ~6 years and I haven't noticed any significant feature reduction. I'm sure there've been many, I just haven't noticed (hence subjective).
> that they even can't understand why someone would use a different platform.
I fully understand why people want to use Apple for their consuming needs. I really don't understand why my fellow developers choose to go with Apple as their work machine. I then frequently see they have to fire up VMs/containers to do work that I can do natively. No idea what's the upside for work (dev, coding-heavy).
PS: I'm writing this from my personal Apple computer. When I'm up for my hardware refresh at work, I'll 100% go with another Linux-compatible Lenovo/Dell.
When you figure it out, let the rest of us know, because this is exactly what I think about every one of the breathless articles about how great WSL is. Speak of the devil... https://news.ycombinator.com/item?id=25965231
Once we get a Linux laptop with great and fuss free hardware, then developers will continue buying Macbooks.
Great app support might be inconsequential for software development but not for quality of life. Programmers are people too.
If a programmer who happens to do music production or art as hobby for example, which do you think he would choose, a Macbook or a Linux laptop?
Don't the vast majority of companies have clauses in contracts that say whatever you create on your particular work laptop belongs to the company? I certainly have that in my contract.
In general, I would say that you're getting your work laptop for work. Work-related things should have a priority from hobbies. Having to have a VM for various thing is a strange trade off when you say the upside is producing music as a hobby.
I’d also argue that the Adobe Creative Suite is a great grab bag of tools generally useful in communication and digital asset preparation crossing the gamut from bitmap, vector, video, and motion graphics, all of which have uses when working with software, especially user-facing applications.
What do you think the chances are of your company actually being able to enforce said clauses?
> What do you think the chances are of your company actually being able to enforce said clauses?
Moderate to Very high, depending on the jurisdiction you live in. Like I’ve seen it play out multiple times with colleagues even, and one took it to court even and lost.
You're really focusing on a certain type of developer at that point (systems/kernel only?). As a developer of both front end and back end systems, I use Adobe and Office all the time.
Wouldn't a better bar for judging software choices be "does this make you more or less productive?" rather than "is this an existential necessity as a software developer"?
> Usually inconsequential for developers
I agree that most developers view it this way, but I find this perspective hard to understand. Why would a developer, whose craft is software, go out of there way to not understand and use the software most people use? Including of course their own coworkers? I understand that a lot of developers are content, and able to function, in a bubble of their own creating, but I would find that incredibly limiting, both from a productivity perspective, and in an understanding software as whole (and by extension the world) perspective.
> I fully understand why people want to use Apple for their consuming needs.
You do qualify this as being only about developers a bit later, but statements like this seem fundamentally out of touch with creative work on computers (i.e., illustrating my point from the previous paragraph). Logic, Final Cut, Media Composer, Pro Tools, Cinema 4D, the Adobe Creative Suite, Max/MSP, Reaktor are just a small sampling of important creative software that run on Mac but not Linux. Saying it's about "consuming" is patently ridiculous.
The issue is that Linux is a free version of MacOS. I don't need a laptop to use it and I can just use a beefy desktop in my dev environment.
If I want to use a beefy computer my choices aren't Linux vs Mac, it's Linux vs Windows. And Windows is really annoying for a lot of us.
As for creative work, we are then forced to look for alternatives. With how costly Adobe is I wouldn't even use it on windows or mac tbh.
So no we're not trying to avoid anything. There's simply nothing for us.
Saying you'd rather spend less money, or just prioritizing other advantages of Linux over macOS, makes sense. But pretending it's not a big deal to give up most of the industry-defining creative and productivity software (notably excluding most developer tools) just doesn't make much sense to me.
You have to realize, that a lot of the software you listed is only relevant in the creative / media production industry. So, it is really not software that most people use.
The image and sound editing software is useful for development too, if you're working on an app or game and need to process any assets for it.
> I fully understand why people want to use Apple for their consuming needs.
So I listed creative apps in contrast to their point about "consuming", but I could have listed Microsoft Office, or the iWork Suite.
I also think you're discounting how popular these apps actually are. Affinity Designer, Affinity Photo, Logic Pro, Final Cut Pro, GarageBand, and iMovie are all in the top ten charts for the Mac App Store (an interesting tangential point here is about how mobile eating so many consumer software use cases has shifted laptops and desktops more towards creative use cases).
But the point is, familiarity with these apps is useful for software developers for a couple of reasons:
1. While they may not be developer tools, they are certainly related: User-facing apps all have a UI, and most involve media of some sort, whether it's photos, videos, icons, etc... Being able to work with those file formats is a great supporting skill for a software developer.
2. As a software developer, whose "art" is software, it's good to be able to use applications that other users prefer to use, just like, say, an interior designer might be interested in how people decorate their homes. As a software developer, I'm extremely interested in the what and why of the software people like to use.
The ones that don't aren't necessarily widely used software. They're just specialized software for specific fields. Another example is CAD, not necessarily something everyone uses.
I also wouldn't mind using my Mac as my main computer, the problem is that my 1080p 23inch monitors don't work well with them due to pixel density.
Because many of your fellow developers do not have and don't want a separate machine for just conding? Why is this idea so alien for some people?
I've been using linux distros (mainly Ubuntu before unity nonsense and then arch and even maintained a package in AUR) since around 2006 to 2013-14. Every now and then I install Fedora\Ubuntu\Manjaro etc to see if anything got better to allow me to use it as a universal device should be used. Every time the answer is a firm NO.
In fact sometimes the disto won't even install because of some weird reasons. For example I only managed to install Fedora on my current PC (build mainly for gaming) after changing some GRUB options (and spending two hours searching all over the web for a needed recipe). What the hell is this?
As a sibling commenter said - Linux is still only good as close-to-targed (server) work machine. And it also has a few OSS tools for musicians and painters (like MuseScore and Krita). But that's it.
Installation is still a mess, updates are still unpredictable. Software distribution is still a nightmare. General consumer software availability is ... there is almost none.
If at some point my mac will become too unfriendly to work with as a dev tool (I don't see it coming really. Some people on HN usually treat some minor things as a catastrophe) - I will build a small dev server (or rent one).
> Because many of your fellow developers do not have and don't want a separate machine for just conding? Why is this idea so alien for some people?
Well as a salaried employee, which I have been all my working life, you are generally required to have a seperate machine for work. So yes, this idea is pretty alien to me.
My first serious jobs in IT were in consulting (Hyperion Planning in oil and gas in Russia) and this one company (aside from Accenture were I've had a bit of experience) where the only places that required me to use the provided notebook for the job. Same for British Petroleum. Security reasons etc.
Not as single soft dev company I've worked since around 2012 required me to use their PCs (backend dev here) even though most of the do proived their macs or Thinkpads, or something else.
Anyway - many devs are self employed and\or work remotely. They don't use corporate tech at all. Corporate VPN to access the net? Sure. But that's it.
Honestly, I won't even consider a job offer that will restrict me to employer provided PC.
I still have mixed feelings about it.
I can 100% relate to your experience. It was painful. There were oddities all over the place. Some software I was used to use was simply unavailable. Package managers... oh I missed apt so much... And it was much slower.
Let alone the main compelling factor for Linux for me: that it is open source, and that I can inspect anything, even the kernel, if I need to. Surely, you occasionally need to fix some driver or configuration "CLI-style", but I'm more than used with this.
But basically, with Linux I feel I control and own the system. With Mac is pretty much like Windows: they own you, and for the most part you don't know what's going on --except that MacOS is still orders of magnitude better than Windows.
Or I can use Debian stable and everything is stable, but if I want something new I have to compile it myself, or hope there's a backport.
With macOS and Macports I get a stable base system that Apple keeps up-to-date security-wise with monolithic updates that I don't have to worry about, and Macports has the latest for things like Emacs or even the GNU coreutils.
In the past 8 years of regularly updating my rolling release Linux systems, I have spent significantly more time reading headlines about macOS releases breaking software, than I have spent staying up-to-date with dhcpcd, systemd and coreutils. They are ridiculously stable.
But my day-to-day development machine is a Mac, and has been for a long time. This was originally because I was both a graphic designer and a developer, and needed access to tools like Photoshop and InDesign while still having a UNIX development environment, and the Mac was great at both of these. This basically still applies – I have access to lots of really well-designed native applications that I use all the time, and a full UNIX development environment that I use every day.
I really haven't encountered the issues you talk about in a serious way – the most frequent thing is forgetting that I don't have the GNU version of some CLI tools and need to use different flags. Certainly no encounters with a "weird security system". I have a working development environment, running on nice hardware, that gives me access to everything I want – it's hard to find a reason to make a change to this.
I do sometimes come back to working with Linux in a desktop capacity – most recently Ubuntu on a NUC when I shipped my MacBook back for repair. It is broadly fine, but it's still just a bit more irritating. Multiple monitor support was buggy, as was high-DPI support and Bluetooth. No doubt a different distribution and/or some tweaking could resolve these issues and leave me with a development environment that was equivalent to what I already have – but I'd still be missing other tools that I like, not to mention all the niceties of the wider ecosystem.
Honestly it's more likely to be the hardware that makes me change. I don't have the same complaints as others do about recent product lines, but I'm definitely one of those people in Apple's market gap in the "high-end-non-workstation-non-integrated-desktop" area. I'd fork quite a lot of money for something like a 16-core desktop machine, but probably not the £8k Apple wants for the Mac Pro. We'll see what happens over the next few years though.
You didn't use mac during the notarization system outage? I coulndn't even use my keyboard and mouse (the one on macbook, NOT bluetooth one) for 2-5 minutes after lid was opened.
Never had such issue with Linux, yeah, bluetooth ones might stop working but wired keyboard (or laptop open) works always.
Yesterday out of the blue my wifes AirPods Pro stopped working with macbook AND iPhone at the same time - they rejected connection (or actually on mac it looked like they are connected but the sound was coming out of speakers not the pods) and the same situation with iPhone. I had to reset AirPods to make it work.
And don't get me started on the completly stupid difference between ctrl+c and cmd+c. One (the standard for everything except macos) is used in terminal and the other in every other app.
For me macbook would be great for one thing: installing Linux on it, if it only had the ctrl key in the correct place (that is at the left corner of the keyboard not next to Fn).
How do you copy text out of your virtual terminal?
The Fn key placement on the other hand... I’m with you.
Now how about Cut (Cmd+X vs Ctrl+Shift+X)?
with xsel(1x) or xclip(1)
The number of times I’ve accidentally obliterated important and hard-to-relocate paste buffer contents on Linux by a wayward mouse action easily numbers in the thousands.
Selecting text never copies anything. Selections are just metadata that points back to the X client app that "owns" the selection and presumably also has the selected data. Selecting text simply sets the owner of the PRIMARY selection to the current X client, and "pasting" with middle click is asks the current owner of the PRIMARY selection to copy the selected data into the window targeted by the click.
From ICCCM[1]:
>> Selections communicate between an owner and a requestor. The owner has the data representing the value of its selection, and the requestor receives it. A requestor wishing to obtain the value of a selection provides the following:
The name of the selection
The name of a property
A window
The atom representing the data type required
Optionally, some parameters for the request
Convert the contents of the selection to the requested data type
Place this data in the named property on the named window
Send the requestor an event to let it know the property is available
You're having this problem because you're using the PRIMARY selection when you should be using the CLIPBOARD selection which is more durable and intended[2] for data transfer and copy/paste-like semantics.
The Copy/Paste actions traditionally found in the "Edit" menu usually interact with the CLIPBOARD selection. This should be completely orthogonal to the middle-click feature and other interactions with the PRIMARY selection. You should be able to mix usage of both selections. Try this:
select text "foo"
use Copy from the Edit menu # CLIPBOARD now points to "foo"
select different text "bar" # PRIMARY now points to "bar"
move to an editable window
use Paste from the Edit menu # pastes "foo"
middle click the same window # pastes "bar"
[1] https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...
[2] https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...
If I have to read pages of documentation to understand how to do something that is utterly trivial and intuitive on every other major operating system, your approach is broken.
As I said at the end of the post, the actual behavior of some X Window System features are poorly explained and not obvious. The unexplained differences from the de fact standard behavior new users expect is as major usability problem. However...
> utterly trivial and intuitive on every other major operating system
It's worth remembering that when the standards document referenced in my previous [1] was originally written... a lot of those "major operating systems" didn't exist. In 1987, MS Windows was on version 1.0. I'm not sure it even supported any clipboard-like features. In that era, minimizing memory usage and network traffic were important, design goals.
> intuitive
"The only 'intuitive' interface is the nipple. After that, it's all learned." -- Bruce Ediger, on X interfaces
(ref: /usr/share/fortune/linux)
That's fine and I do appreciate the information, but from the perspective of the overall discussion I think the point stands that the X approach to this is completely broken from a user perspective.
> It's worth remembering that when the standards document referenced in my previous [1] was originally written... a lot of those "major operating systems" didn't exist.
That's completely understandable, but we've had over thirty years to adapt. This argument is the same one that keeps Emacs greybeards defending M-k and M-y despite the fact that there hasn't been a Meta key on a single keyboard I've used in my 30 years of computing.
At some point you have to accept that the rest of the computing world has agreed upon a different standard than yours, and you either need to take steps to accommodate that or die.
That's not to say you can't try out new things while still abiding by existing standards (for instance, with advanced features like pastebuffer history), but that's completely different from clinging on to inferior historical approaches when everyone else has moved on.
This has happened literally once in the history of macOS.
> And don't get me started on the completly stupid difference between ctrl+c and cmd+c.
Ctrl-C and Cmd-C are completely different actions. What is weird is that some OSes use the same keyboard combination for them.
I particularly hate the way GNOME terminal uses Shift+Ctrl+C/V for this, because if you accidentally hit Shift+Ctrl+C in Chrome then it opens Developer Tools.
MacOS is a large heavy object being pulled by a mysterious force in a direction no one is sure they want to go, but at least it mostly works, kind of, on good days. Except when it suddenly changes direction and runs you over.
Windows is a large heavy object with an embedded malevolent eyeball and a huge trail of wreckage behind it. People keep signing up for more wreckage, and it's really mystifying.
True that this is a good example of a security system that affected people negatively – though ironically I was unaffected by this because I was on-site with a customer, working on an annoying network without internet connectivity. But yes – it's fair to say the ecosystem is not perfect.
And don't get me started on the completly stupid difference between ctrl+c and cmd+c. One (the standard for everything except macos) is used in terminal and the other in every other app.
This is not "completely stupid" – it's just a difference between platforms. The command key sends commands, and the control key sends control codes. The cmd+c combination will copy text in both the terminal and all other applications; ctrl+c will send an interrupt. If anything, this is one of the things that keeps tripping me up working on a Linux desktop after so long – I keep inadvertently sending ctrl+c instead of copying, because the control key is overloaded with both text manipulation commands and control characters! But this is just a muscle-memory and familiarity thing.
This is completely backwards.
In Linux, Copy/Paste is Ctrl+Shift+C/V in various terminal programs, but Ctrl+C/V in other GUI programs
In MacOS/OSX/macOS since 1984, Copy/Paste has always been Cmd+C/V. ...because Copy/Paste are OS/GUI shell actions, and Control characters are not the same thing.
Microsoft broke this separation in Windows 1.0, and Linux has stupidly aped Microsoft ever since.
See also: Microsoft/Linux dialog boxes where the "Continue forward" option is located on the LHS (which in most locales notably including the original context, means "move backward").
Unluckily nowadays some notebooks don't have an insert-key, which makes me sad.
No. Mostly because Apple keyboards don't have an Insert key.
(They do have a "Clear" key, which I wish more developers would support. But I think so many are on the laptop or small keyboard they don't realize all the buttons that are available.)
debating with myself whether to remap keys (and then fumble on other linux terminals), or to just learn the new key habit.
Apple (really Xerox/PARC in this case) needed a key combination for "Copy" in their first GUI, and decided not to break the usability of that preexisting standard (and all of the other Control chars, some of which are still useful today).
Microsoft Windows came along shortly afterward. They copied Apple/Xerox's choice of C/X/V for Copy/Cut/Paste in the GUI, but they broke the well-established standard meaning of Ctrl+C in the process. (IIRC, this is especially ironic because they were also breaking the meaning of Ctrl+C from MS-DOS.)
And sure, Microsoft then went on to become dominant, and by virtue of their dominance created a huge number of people who believe that the misuse of Ctrl+C for Copy is "standard".
But it still breaks functionality. Then and today, 35+ years later.
"Copy" should be the same action in all applications. If it is not, the OS/GUI is failing the user.
If you want the same on Linux, it's available.
Ctrl+C is a signal to the running application inside the terminal, and should be passed without interference by the terminal emulator.
> Apple is busy breaking your things and trying to convince you that theirs is "the one true way".
If by that you mean "doing things the reasonable way and not needing to offer workarounds for their failures", then we are in complete agreement. :)
I want OneModifierKeyButNotCtrl+C to Copy in all GUI applications including terminal emulators. I would settle for SomeModifierKeyCombinationNotCtrlAlone+C to Copy in all GUI applications including terminal emulators.
I don't know if Microsoft offers that, but Linux does not. Copy/paste between a web browser and a terminal window is an exercise in frustration.
No, detecting when some text is selected and performing a copy instead of sending the signal is the correct way to do this in 2020.
If you don't like that, every OS lets you remap keys.
> If by that you mean "doing things the reasonable way and not needing to offer workarounds for their failures", then we are in complete agreement. :)
I guess next you'll be telling me that never implementing a real "maximize" feature for application windows in your OS is reasonable. :) (And no... Alt + click on the green button does not maximize every window.) As usual, with a Mac you have to continually work around Apple by using apps that will probably not work after a big update if you want to do anything out side of the "Apple way".
> I want OneModifierKeyButNotCtrl+C to Copy in all GUI applications including terminal emulators. I would settle for SomeModifierKeyCombinationNotCtrlAlone+C to Copy in all GUI applications including terminal emulators.
And you can absolutely have that in Windows or Linux [0]. That's because both of them are easily orders of magnitude more flexible and have more options than any OS offered by Apple. Heck, I can't even turn off that idiotic marketing tactic of old, the startup chime, in my old 2012 Mac Pro.
Anyway - whatever you think is correct about Ctr+C, there's no denying that Macs are completely inflexible in many, many, many ways and the only reason you're on one if you've got strong opinions is because your opinions happen to align with what Apple thinks. If your opinion differs at all, you'll be the one bending. Enjoy that!
[0] https://www.google.com/search?q=change+copy+paste+shortcuts+...
Ugh, that sounds awful! The Copy action should always be the same action, and it should always copy only, and never do unexpected, possibly harmful, things.
Re: Maximize. FWIW I have always preferred the OSX implementation -- it allows me two different window sizes that I can choose myself, and toggle between them. But I'll concede that if you come from Windows, having one of those choices taken away from you feels more natural. :)
Re: OneModifierKeyButNotCtrl+C. I can't speak for Windows, but this does not work on Linux. You can screw around with xmodmap and some apps to your heart's content, but you will never configure a GUI/DE-wide key combination for Copy that works in all apps. This is what you get, for free, on all versions of MacOS, ever.
Unless your argument devolves to "source code is available". In which case: OK I guess.
Re: macOS inflexibility. I mean, sure. And sometimes flexibility is critical. Other times, carefully-chosen defaults and strong consistency is more important. Anyway Linux's flexibility does not provide a path to solve this specific UX design error, so it doesn't help me here.
Don't get me wrong. Linux is great, and I choose it and use it happily for many things. I choose other OSes (all Unixes though!) for other purposes.
I have specific requirements for my desktop/console/terminal environment which might not match yours. MacOS meets them with default configuration plus some minor tweaks (e.g. focus follows mouse). Linux is not flexible enough to meet those needs, so I do not choose it for that purpose. All good.
You're trading one slight discomfort (in your opinion) for a thousand others because the rest of macOS is abysmal. There's hidden, undiscoverable functionality everywhere, the window management is absolutely disgusting, the file management is sorely lacking, the amount of tweaking you have to do to get decent terminal utilities is sickening, the hardware choices are extremely limited and the tyrannical company that builds it works regularly to own you.
No amount of rationalization will convince me that it's a good OS for anything other than building iOS apps.
Thankfully at least I can run a better OS on the hardware once Apple stops supporting it. Unfortunately I still must jump over many Mac hardware obstructions just to get something resembling a normal BIOS so I can even boot something else. It's just disgusting when I have to do it. At least I never gave Apple any money though since I buy it all used.
They are the China of the technology world and I wouldn't be proud to support them at all even if their desktop OS was actually desirable. Still, they own half (or more) of the phones in use in the US so I have no choice but to deal with them.
No, I didn't even know it was thing until I read about it here. However, I don't use a lot of apps from the AppStore, so I dont' know if that was a contributing factor. I'm also not one to close and launch apps regularly. Terminal, Browser, TextMate are open 100% of the time. I usually have Photoshop and/or Illustrator open in the background as well. Don't be a quitter, you don't have to be a starter.
>And don't get me started on the completly stupid difference between ctrl+c and cmd+c. One (the standard for everything except macos) is used in terminal and the other in every other app.
The Mac has had the Cmd key sincd the very first days of Apple. In fact, it was originally two separate keys: open-apple, closed-apple. It was around well before Linux was a glint in Linus' eye.
I don't have any from AppStore, besides those that are factory installed and as I wrote previously, after resume from suspend my keyboard and mouse werent' working I was thinking that this macbook just died (and it was only 1 week old).
Thank god I found out that it needed only simple block of notarization server to make this stupid "security" stop usability.
BTW. You could try to see what happens when you are far from WiFi (with poor connectivity) and try to wakup laptop from sleep - the same, keyboard and touchpad don't respond for 1-2 minutes.
To me, that’s backward. The hardware is okay, the platform is amazing.
Nothing even comes close to the full ecosystem. Phone, tablet, headphones, watch, computer.
Occasionally, quite rarely in reality, something goes wrong. However, I don’t use bleeding edge versions of macOS and so I can’t even tell you the last time I actually experienced one of these problems that everyone on HN gets in an uproar about.
On the data programming side of things I don’t see much issue with it either, though. The issue on this article would’ve definitely bit me as I run like a dozen Postgres instances but I haven’t updated to BigSur - I’m never in a rush to do so.
The only thing I miss from my Linux days is the package manager, maybe? Brew is third-party and doesn’t feel as tight as some of the Linux counterparts.
My non-development tasks... those things in life I use a computer for... are just harder on Linux desktops or have a poor experience.
MacOS, on the other hand, has a great experience for most of these everyday life kinds of activities. Even for many business activities it's better. Here I refer to the non-development parts of business.
If all you do is systems level coding than Linux is great. But, that's not the case for most folks.
Plus there is nothing equivalent to OmniFocus outside of macOS, and that is one of the tools I depend on most heavily.
For what it is worth, I found quite a few of the replies enlightening as to why others choose to use the platform. But: I take your point that it derailed the conversation.
What the hell, Apple?
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).
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.
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.
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?
Yes, certainly it should.
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.
No. First, it's not a rewrite but a bugfix patch. Second, you will want this fix because open can return EINTR. It's documented. The code (postgresql in this case) is wrong. It should be fixed. simple.
Apparanty it was on an open() call on local file which is certainly ... unusual
https://www.postgresql.org/message-id/20210115210548.zfbnulf...
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 :)
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.
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.
Now read the comments before. This borders on parody at this point.
It would be cool if all of the "this is the last straw!" and "welp, guess this is when I leave Mac" people who appear in each of these threads just, like, fuck off and leave then?
we develop on macos and deploy on linux, macos is supported as side effect, windows was not supported... a single policy change without a workaround... made us support windows and linux, and macos left to dust.
> For instance, this might happen if the program makes use of alarm() to run some code asynchronously when a timer runs out. If the timeout occurs while the program is calling write(), we just want to retry the system call (aka read/write, etc).
It's perfectly valid behaviour, and the solution is to retry in that case.
[1]:https://pubs.opengroup.org/onlinepubs/9699919799/functions/s...
[2]: https://developer.apple.com/library/archive/documentation/Sy...
I absolutely can't fathom how anyone could make Windows their daily driver. Having to unbloat, unspy, unfuck a brand new system, I mean...
Naturally I told them to use an open source operating system and declined to update my code to accomodate Apple.
[/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include]
-> % grep -r -n getline stdio.h
stdio.h:355:ssize_t getline(char \* __restrict __linep, size_t \* __restrict __linecapp, FILE \* __restrict
[/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include]
-> % grep -r -n fmemopen \*
stdio.h:356:FILE *fmemopen(void * __restrict __buf, size_t __size, const char \* __restrict __mode) __API_AVAILABLE(macos(10.13), ios(11.0), tvos(11.0), watchos(4.0));
In any case, it's a trend with Apple, even if this particular example is wrong. See also: Vulkan.
Honestly, I wouldn't expect even Linux or BSD from 2007 to work well with modern software.
Virtualization is killing the need to do that, sadly.
For Vulkan, MoltenVK works very well and is officially supported by Khronos directly. (Metal is a much more approachable API than Vulkan, but oh well...)
MoltenVK is a good workaround, but open standards > workarounds.
CI handles xCode. Otherwise, my 2x 42" 4k monitors, Gnome and works-here-same-as-the-cloud self reads these articles on puzzlement.
I can't count the times I've helped developers deal with oh-yeah-brew-is-weird-about-libpq. Now this? It's the avocado-toast of developer workstations...
I ran Linux on the desktop for 19 years, through years-long stretches of Slackware, RedHat, SuSE, Gentoo, and Ubuntu. Obviously, I was (and still am) a huge fan, but if you've managed 15 years of Linux on the desktop with "nary a problem," you have had the most unbelievable luck of any human on the planet, and should start buying lottery tickets.
After running Gentoo for several years, and switching to Ubuntu, I was amazed at how much time I was saving not dealing with portage. Fair enough. I mean, I was asking for it by using a source distro, but I had that same sigh of relief when I finally bought a Mac, and realized that I was still doing a lot of maintenance to keep Ubuntu happy, even though it was (obviously) a huge improvement over Gentoo. I just couldn't see it until it was gone.
Then after one of the kernel updates the "resetting rcs0 for hang on rcs0" bug started happening, I had to downgrade to an earlier kernel, then Ubuntu 20 came with Snap everywhere, then covid came and I started having Zoom meetings all over the place and my mic would randomly stop working and I started using a 4K screen and noticed how choppy scrolling is and that YouTube stutters hard in fullscreen, then there was a memory leak in Firefox, semi-functional display scaling, the machine sometimes wouldn't wake up from deep sleep...
Then the M1 Macs came out and I got an Air. I've been using it for a month and it's heaven. It's like coming home. It gets work done, lets me have fun, watch videos, play some games and gets out of the way.