I've recently come across a spectacular number of regressions on my M3 Max MacBook Pro, Sequoia as well as previous versions included.
The most workflow breaking one (which really tempts me to throw the computer out of the closest window I can find in the room) is a Safari bug that basically randomly fails to open any website with a
> Safari can't open the page. The error is: "The operation couldn't be completed. No space left on device" (NSPOSIXErrorDomain:28).
Which is embarrassing, as this is a clear regression and it breaks all functionality in the browser - restarting it doesn't fix it, and I need to restart the whole machine for it to _maybe_ get fixed (and it's not really a space issue, both RAM and disk I'm nowhere near their limits).
Some other things that devs should know about Sequoia:
- If you're sticking to Sonoma for stability, be aware Apple doesn't backport all security patches. Apple's release notes show 79 security issues fixed in Sequoia, and only 37 fixed in Sonoma 14.7. Maybe some vulns were only introduced in the Sequoia betas, but based on previous years, that's mostly not the case. Apple only keeps you safe on the latest version.
- macOS Sequoia, released days ago, still includes vulnerable years-old binaries like LibreSSL 3.3.6, curl 8.7.1, and python 3.9.6. https://www.intego.com/mac-security-blog/apple-still-leaving... (I've tested it's still true on the final 15.0)
I promise, you will be just fine without the security updates.
This is probably misguided. Apple includes the OS version number in the user agent, so an attacker can actually pay to have code delivered only to users with vulnerable versions of MacOS. (advertising marketplaces allow bidding by user agent)
The user agent is defined by the browser.
And it only contains: Intel Mac OS X 10_15_7 irrespective of what Mac you are using.
I’m seeing Mozilla/5.0 (Macintosh; Intel Mac OS X 14_7). What do you think the 14_7 stands for on MacOS 14.7?
That issue apparently goes back a couple years.
https://osxdaily.com/2022/01/28/fix-safari-cant-open-page-ns...
https://old.reddit.com/r/MacOS/comments/qna5js/safari_issue_...
I had a very similar issue some time back that was caused by LSP.
Long story short I had multiple long running LSPs (fragmented projects) in Emacs that would open many handlers and keep them open. At some point same error started happening and I thought only restart could resolve it.
But then I was at the hotel where merely switching network made this issue to appear (I suppose binding was somewhat related to and switch made pool exhaust pool quicker) so I decided to debug it.
It turned out that restarting Emacs was enough to close file handlers and resume operations.
I (think) I have a fix for you.
1. Open Activity Monitor 2. Find "Safari Networking" 3. Force quit 4. Refresh Safari tab (that didn't work)
Works on M1 MBP w/Sonoma 14.5
Have same issue. The above solution did not resolve the issue. It doesn't bother me much because I mostly use Firefox, but it causes problems when I'm testing front-end stuff on Safari.
I get this too
What's your particular use case to keep using Safari if it's not working for you and there are alternatives available?
Not GP, but:
iOS Safari dev tools
Testing for compatibility
Hot Damn!
Is that what is happening!
I've been experiencing this with SublimeText and VSCode!
I've taken screenshots, and a video, but had not submitted any bug reports yet.
Whenever I make a new file, say 'foo.html.haml' the system will append .h to the file.
I'd guessed it was a system wide issue, and uninstalled the new XCode just on the off chance, but that made no difference.
Maybe Apple should have held back the Sequoia release like they often do!
Edit:
These sorts of ridiculous issues are not doing anything to stop me considering moving my dev environment to Linux full time :-/
It’s great over here in the Linux world, I run Debian and Arch. Arch may give you regressions, but Debian is pretty smooth sailing functionally.
Maybe I’m getting old, but my long time preference for Arch is slowly being overtaken by my appreciation for Debian. It’s not the usual complaint about stability — I’ve had one issue in a dozen years with Arch — I just reached a point where I feel like I’m living in the future running Linux software from five years ago, so maybe I don’t need to upgrade quite so relentlessly. Anything I don’t have, I can compile.
What Debian has nailed in the last 10 years is the package management situation that is so smooth. This is why I’m leaving Arch, everything breaks sometimes or a dep won’t upgrade for this or that reason. Debian you install and the package probably has a pretty good initial config and works. Any packages that aren’t recent enough can be built usually because the toolchain versions are probably recent enough. So it really is a nice experience.
Not even Apple products have that solid of a package situation.
I always have such a difficult time messing with packages on debian. On arch, there is a single PKGBUILD file, and it's basically the simplest thing anyone could think of which makes it bliss to work with. On the other hand, debian/rules is a complete mess, apt-get update is notoriously slow, and I have not had good experiences with dpkg-buildpackage compared to makepkg.
Aren’t Debian and Arch philosophic opposites though?
Arch is bleeding edge yet permanently issue prone, Debian is stable and conservative/slow in updating?
Seems odd to jump from one end of the spectrum to another (I use Debian and Mint mostly but have respect for the Arch project’s aims)
In the five years I have used Arch, I have not had a single issue.
I will never understand how a bunch of technically-inclined people can look at an obvious bug and think it was put in intentionally.
This happens everywhere in Apple products. It thinks it knows better than you, and completely screws power users.
Try manually adding IMAP/POP/SMTP servers in Mail in both iOS and MacOS. First off the process is nowhere near consistent. Second, they both try to be clever if they detect supported hosts like gmail. It'll kick off different flows because it thinks gmail is gmail. So for things like custom reply-to's, it's a massive pain in the ass.
Gmail requires a different login flow, because they're dropping password authentication in favor of OAuth, for pretty reasonable security reasons.
And entering my password in a different kind of text box is more secure how?
Because you are entering it into a Google login flow.
Which usually will have MFA and sometimes not a text box at all (passkey).
2FA support. Gmail requires 2FA.
It doesn't "require" it. Users might enable it or disable it.
If it's disabled, can you explain to me how is it safer?
It bonkers isnt it!
Do none of Apple's developer team use any other editor at anytime other than XCode! How was this not picked up in beta testing!?
Here's another gripe:
The tiling feature maddens me!
You cant disable it completely or remap the key bindings.
Did anyone at Apple even test this using a full size Magic Keyboard?
Using the FN key to move windows is fine when the key is down next to the Control key. Which it isnt on the full size keyboard.
And I assume the developers at Apple use the big Magic Keyboard?
So did anyone of them even think for a minute about how useless it is to bind the window tiling feature to the FN key?
Plus, you can't fully disable Sequoia's tiling, so it interferes with my 3rd party tiling tool :-/
To answer your questions, no, they do not use an editor that isn't Xcode. And I would also suspect none of them use desktop macs daily and instead use macbooks.
But surely they must tether their MacBooks to external displays and desktop Mouse’s and Keyboards!
I didn’t think they’d be using Mac minis, Studios or Pros as such.
They can’t all be using the little mini Magic Keyboard or working directly on their laptops?
Can they…. :-O
The MacBook keyboard is atrocious. I always mess up the passwords a bunch of times.
Are you sure you can't remap the keyboard shortcuts? I believe you can change them in System Settings -> Keyboard -> Keyboard Shortcuts
Yeah, this is one of the old things going way back. Native apps never offer remapping of anything because they don't have to; as long as something has a menu item entry you can change the shortcuts at the system level.
I don't understand why and how does Apple keep breaking stuff that has worked perfectly fine for the previous 24 years. Like, just don't touch it maybe if it already works?
Also yearly major OS updates are beyond stupid.
I will never understand how Apple doesn't have automated testing that catches all these basic bugs before shipping.
In my original comment I put "feature" in quotes. I do think a change was intended, it's just not working as it should.
My guess, having never used OSX:
1. In the save dialog, filetype can determined in multiple ways (maybe selected from a dropdown, or be set by the program opening the dialog) and not necessarily just inferred from user-entered filename
2. So when returning the path to the program, it appends the filetype's extension to the path iff it doesn't already end in it (so user can enter just `notes` and file gets saved as `notes.txt`, if that was selected in the dropdown or the program's default)
3. Probably unintentionally, they've started allowing partial matches when inferring filetype from the user-entered filename
e.g: User enters `database.sql`, it matches against `.s` extension of assembly filetype, but `database.sql` doesn't end in `.s` so becomes `database.sql.s`
That explanation actually makes some amount of sense. So if the application doesn't supply a file type, the dialog Ingers the file type from the filename. So when the user has typed "database.s", the dialog sets the file type to assembly, and it keeps that setting even as the user goes to add "ql".
It's just a bug.
The system save panel (NSSavePanel) is only supposed to infer the file extension when it has been given a list of supported file types/extensions. If the user does not specify a file extension, NSSavePanel will use the first extension in the supported list. If the user specifies an unsupported extension, they see an error message.
Text editors like VSCode and Sublime Text would configure NSSavePanel to allow any file type/extension, which means it's supposed to just accept whatever the user types.
> It's just a bug.
It's an unforgivable bug.
File save dialogs have been around for decades. There's no reason whatsoever to not have very extensive unit and integration tests around it.
Exactly, and when you interview for companies like this you have to basically prove that you are in the top 1% developers in the world, just to find shit like this being released in the wild for millions of devices. It is absurd.
I iTunes had a very similar "autocomplete tries to be helpful but causes chaos" bug a few years back. If you clicked to edit the artist column it would autocomplete from the list of other artists in your library. However, if your desired artist name was shorter than one it's trying to autocomplete, it would forcibly append the rest of the name from the longer artist.
e.g. if you typed "Ross" and wanted it to just be "Ross", but you have any track by "Ross from Friends" in your library, it would always append " from Friends" no matter how many times you tried deleting it.
Good guess! This has always seemed like a tricky edge-case-ridden feature, so I’m not super surprised it eventually broke. I mean, this is the kind of thing that should be covered by automated tests, but who knows what’s going on internally…
Personally, I’m putting good money on someone “fixing” some regex constant while doing another bug by either disabling full-match or taking off the “useless” $ at the end. This is why you don’t do unrelated fixes!! Otherwise, I don’t see any way this would get past ticket review as an intentional change in any half-awake dev team.
Xcode's new autocomplete is pretty awful. It tries to be smart, but keeps hallucinating nonexistent API methods, and makes up stuff from my own codebase.
Is it actually making stuff up or is it falsely believing that some type conforms to a protocol it doesn't?
It fully makes things up, like nonexistent parameters to real functions. In the areas where it's accurate it's barely better than the existing autocomplete, though I have noticed it seems to deal a bit better with broken code (which also breaks Swift's compiler-based tooling). It can also generate larger things like type definitions a bit better, but Apple never really invested into autocomplete, so it's not really anything better than what other IDEs already had.
:w ~/my/path/thing.txt
Works every time.
In Windows land, you can put quotes around your file name to prevent the default extension from being added to the filename.
Try to add a directory named mything.service - no service for you!. You can even try creating it in a terminal and then looking at it in finder.
Ooof.
Who thought this was a good idea? Is there any actual documentation on this or is it just a thing they added?
Isn’t this almost certainly a bug? I’m pretty sure the MacOS developers don’t really want to add a .s extension to files.
I can understand people thinking it’s a misguided feature considering my own experiences.
Thanks Apple for proving yet again why I should never upgrade to the latest macOS/iOS.
this company is worth a trillion dollars yet can’t get basic shit right.
Holy shit Sequoia is the biggest dumpster fire OS I think I've ever seen Apple release on the Mac.
They would have been better off just skipping a year instead of releasing... whatever the hell this even is.
Every time Apple shits the software bed hard like this I hope it will be something of a Vista moment for them and they'll clean house with the MacOS software team, but it never happens and things just get worse.
I just pray they never fire whoever maintains the iTunes Classic Visualizer, that thing is a gem and it still gets updates sometimes.
Isn't iTunes already dead and replaced with music?
I don't understand. What adding ".s" to the file name is supposed to correct?
It's some sort of bug around saving "non-standard" extensions. And it seems to grab as many of the original characters as it can that match a known extension, so `test.foo` becomes `test.foo.f`, `test.solo` becomes `test.solo.s`, but `test.executive` becomes `test.executive.exe`, and `test.asm` becomes `test.as`
And it affects their code that they run to validate when you change an extension. Normally if you open a file with an extension already (like say `test.txt`) and try to save it with a new extension (like `test.asm`), it prompts you asking something like "you've entered the extension ".asm" but the standard extension for this file type is ".txt" and gives you the options to change to the original extension or use the one you typed. If you try to change `test.txt` to `test.asm` with this bug, it tells you you've entered the ".as" extension, and not ".asm" like you actually entered.
I'm not convinced it's ".s". Of the two examples (2nd is the GitHub link in TFA), both file name extensions start with "s". Ergo, the OS dialog is doing file_name_extension.substring(0,1), perhaps?
Still on Sonoma, or I would answer this question myself.
Wise, it seems! Surprising to see no one think that maybe their recent OS upgrade would be at fault. Hindsight is 20/20 I guess, and at least they were nice about pushing the subject;
This is what happens. I'm sorry you can't reproduce it. Are you using mac for this?It doesn't make much sense. The only files I know of that are .s are assembly.
I wonder if this also happens if a partition is formatted case-sensitive?
Has anyone in any of these threads filed a feedback report with Apple? It takes 30 seconds to do and since this seems to be new in macOS Sequoia it would definitely be worth it.
Wow, this is truly some "Staff Engineer, Level 7, TC: 900k" stuff.
In the Save File As dialog of most Windows apps, you can enclose the filename in double-quotes to force it to not add an extension. I wonder if that will help with the issue in macOS?
No, macOS will just put quotes in the name. I just saved file from vscode as "testfile.sql", including the quotes, and wound up with a file named "testfile.sql".s.
Did you upgrade to Sequoia?
Python does something similarly annoying with shelve files. I will never use that module again.
> The shelve module is implemented on top of the dbm module. This module acts as a facade for 3(* different specific DBM implementations, and it will pick the first module available when creating a new database, in the following order:
> It is this range of choices that makes shelve files appear to grow extra extensions on different platforms.
https://stackoverflow.com/questions/16171833/why-does-the-sh...
apple also failed at using autocorrect for emoji.
Type: "sorry I was late. I ran" and you want to put :sweat: but I assume you want :running:
Put "I hope tomorrow is sunny" and want :pray: but it puts :sun:
I guesses wrong 4 out of 5 times for me and ab unpredictable ux is a shit ux
It’s actually not _predicting_ what emoji you want. There’s aliases assigned to each emoji and you are presented with the options based on the last word you typed.
You might know this already, but how Apple has coded it is it’ll replace the last word with an emoji unless you put a trailing space. But if you put down a space first it’ll add the emoji. So in your examples you would write “I hope tomorrow is sunny pray” and choose the emoji and it will be “I hope tomorrow is sunny :pray:”
This is a very reasonable way for it to work IMO. OP wants it to.. guess based on context? That’s going to be wrong more often than right.. Reasonable ask if they want it to auto-suggest emoji based on message history though.
the OP doesn't want it to guess at all
Obviously this is only two datapoints, but it seems like it's overweighting the last word instead of basing it off of the full content
I don't think it's actually auto-correcting, it's offering an emoji option in the word suggestions that matches your last typed word (if there is one) and allows you to select it to replace the previously typed word. As far as I know it doesn't auto-replace anything you typed with an emoji with the exception of the old basic smileys.
Title here should be "Sublime text started adding a “.s” to new files. Very annoying".
I understand the urge to remove editorializing but I don't think that extends to incorrectly blaming Sublime text in the title when we know better.
For that to be the case you’d need two posts: Zed is apparently following the same convention: https://github.com/zed-industries/zed/issues/16969
It’s a tiresome exercise to enumerate all of the ways in which Apple is eating the seed corn by making their platform hostile to the type of people who build the highest margin part of their platform. The first time I remember being irked was when it was some obscure incantation to get aarch64-darwin to accept bash instead of zsh without complaint, but the endlessly tightening screws around quasi-documented “quarantine” permission bits on executables that no one paid 30% tax on to do an HTTP request was when it started getting concerning. It’s been going downhill since. sudo not meaning sudo is pretty much the point when it went to “actively fight upgrades, even security patches, because the dominant threat actor is the vendor”. The rootkit is coming from inside the house.
I don’t even understand this as a pro-business bias: the people who build Sublime and Zed run businesses. Small (relatively) businesses, the kind we ostensibly cheer for.
It’s like a pro-my-retirement account bias or something. When did OG hackers start taking the side of the guy on the screen in the Orwell ad against the side of the gal with the hammer?
Strangely, it’s not doing this to me, at all, with the non-beta Sequoia and using Nova. I’ve been happily coding away without that happening.
Not saying this isn’t happening for other people, of course! But it must be some odd interaction between Sublime or Zed and Sequoia, not a new intentional feature affecting everyone or every editor.