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.
> Apple's release notes show 79 security issues fixed in Sequoia, and only 37 fixed in Sonoma 14.7.
Not an Apple fan myself (don't touch the stuff at all) but my first thought there would be to check if the "missing" fixes are for things broken in the new release that don't need fixing in the prior one.
> still includes vulnerable years-old binaries
Are these stock builds, so definitely have the problems you are concerned about, or could there be security updates backported as Debian do with older versions in their stable release?
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)
Heya, I couldn’t find a way to contact you privately but I’d assume you want to delete your comment until (presumably) next month! Correct me if I’m wrong tho :)
Alternatively, a mod could help to edit it instead
It’s a product that isn’t officially announced yet. Anyone could mention that they own that device of course, but it’s the extra credibility of him being an ex-Apple SWE (judging from his comments) that convinced me to drop that comment.
Dunno if there could be any legal implications, if not - all good!
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.
The only reason of having a Mac (sorry "real" Mac fans ;) is to be able to test your stuff with MacOS. Especially using Safari and the Iphone and Ipad simulators.
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.
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.
Really? I have had package manager failing experiences since I installed Arch. About 1-3 times per month yay will fail requiring me to use pacman to update. Once I run pacman I can run yay to update my AUR deps when the selling point of yay is that it’s a completely pacman-compatible interface. It’s package situation is so fuzzy though that the community actively encourages you to install multiple package managers. There’s a 3rd pm I can’t remember the name, just a lot of effort for simple things. Often the advice is to read the wiki pages which is nice but Debian I rarely have to read a wiki page or search because everything installs with sane defaults, doesn’t require building for the most part, doesn’t ask me if I want to keep make dependencies when I do build with a default to yes. Arch leaves files behind when I uninstall. Arch doesn't let me know I have extra dependencies I don’t need. Pacman requires reading quite a bit of manpages to understand how to do simple tasks. Arch just feels like a messy experience.
Yes, there are some wrinkles in upgrading packages on Arch, like you said. I've had to manually install archlinux-keyring with pacman. Ive had to manually upgrade yay because a shared library it is dynamically linked to was upgraded. I've had to rm -rf my gpg cache due before.
But my post was primarily focusing on the experience of building / modifying packages. To elaborate just a bit more as an example, the Debian docs claim one can use this environment variable to control certain things when building a package.
DEB_BUILD_OPTIONS='nostrip noopt debug'
What they don't mention, is that these environment variable values are only enabled on a case-by-case basis for every package. Which means, you can't just expect to be able to easily rebuild an arbitrary package without cleaning first, i.e. doing an incremental build. You have to look at debian/rules, which is highly unstructured (unlike PKGBUILD), uses tons of DEB_ makefile variables which I have no understanding of.
To a great extent, the experience of using Arch is the experience of reading the Wiki and doing what it says. I say this without any judgement implied: if you don’t want to read the Wiki, Arch is not for you. Debian is an excellent distribution.
Personably I started using Arch because of its excellent Wiki, after three Fedora updates in a row failed on me and I found myself over and over in the Arch Wiki getting answers.
Yeah Arch is fine if you don’t mind stopping to search for an answer. Most times it’s in the wiki, a lot of times it’s a library upgrade that just causes the pm to fail. Fine if you know what to bang on but I got tired of having to bang.
> Arch is bleeding edge yet permanently issue prone
What were you doing with Arch where you had this experience? I’ve been using it for more than ten years on a variety of hardware and everything has always just worked, but I see this complaint a lot and I’m confused about where it comes from.
It’s funny, this really isn’t my complaint with Arch. It’s more, “ugh, didn’t you just update LibreOffice last week? Another 2 gigabytes?” I want to be clear that Arch has been fantastically stable for me on a variety of hardware, for over a decade.
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`
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.
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.
1) No one writes unit tests for old code until it breaks the first time, because they're too busy working on new stuff.
2) No one gets assigned to write unit tests for old code until it breaks the first time, because there's always more work to do than you have time to do it in and if its not broken, its not hurting anyone enough to get resources and time diverted to it
3) Even if you write a mess of unit tests for stuff, it's always possible to miss unit testing a specific scenario. 100% line and branch coverage is not 100% bad outcomes or 100% possible inputs.
I've never worked anywhere that had 100% of their code tested with automated tests around 100% of the possible inputs and outputs. And the older the code and the longer it had been running stably, the less likely it was to have that testing if the testing wasn't written with the code. Like everything else in development, tests add up in the technical debt pile too.
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.
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.
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".
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 can require 2FA more or less at google's whim, regardless of user preferences (and if you don't have a method set up, you'll be locked out of logging in, at least through that particular device/connection)
If Google detects something strange or is just feeling particularly chaotic that day, they will lock the account and require you to verify it using the phone number. Even if you don't have 2FA enabled.
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.
Not a developer at Apple, but I've been using Magic Keyboard's (without numpad) for about ten years now exactly because it has the same layout as every Macbook I own(ed). If they were to ever make a numpad version with the fn key at the same place I probably wouldn't switch either because I would just be trying to hit the numpad when I'm on the laptop's keyboard.
You can enter new keyboard shortcuts to replace the existing ones in Preferences -> Keyboard -> Keyboard Shortcuts -> App Shortcuts -> All Apps (or just the specific ones if you only want it in certain apps). Just be sure to use the full menu item path. So your menu item should be `Window->Move & Resize->(Left|Right|Top|Bottom|etc)`. I had to close out of the shortcuts dialog and switch to another app for it to take, but it works.
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?
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.
How can anyone come to the conclusion that it's a good idea to use imprecise generation on the go in the tool made to refer to specific already defined things?
Year 2024. Now we use more computing power to make computers remember things worse.
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.
I just saw macOS Sequoia 15.0 today on my Mac and thought "gonna skip the .0 version as always on this one". Now I find this thread to just prove my point. iOS is not nearly as bad imho, but with macOS, some stuff like this happens every year.
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.
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.
1. Put some of the forbidden symbols in the file names of, let's say, a bunch of photos.
2. ZIP them
3. Send to someone who ordered those photos with Windows/Linux computer.
4. An hour later tell them that everything works on your computer and you don't see the problem. As a bonus you can film unpacking the zip file and saying: "You see, it works. There's something wrong with your computer".
I don't know of any Unix that allows forward slashes in file names. On macOS you can use : which is displayed as / in Finder, but in exchange you can't put a : in file names...
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.
Yes, and it specifically is more noticeable in applications that let you open any file type; if you open and save a list of specific types, you have described those types to the system (and so there is a registered full extension to use).
That said, I doubt it is something Sublime and others missed in terms of API - TextEdit has the same issue.
For comparison, Xcode actually does register every filetype it supports, so it would be difficult to hit this issue in the official IDE.
But this isn't DOS with a hardcoded 8.3 filename. You can have any number of dots in a filename on a Unix-style OS, and there's nothing special about whatever follows the final one.
What you think of as file extensions are merely a matter of convention. Some applications may treat them more seriously, but that should be up to the app to enforce - not the OS.
I can see no reason why a system-wide file dialog should ever be altering this.
I think this is a combination of a bug interacting with two different things. One is the extension change checker, and the other is the system that adds extensions invisibly in order that the OS can still pretend 23 years later that extensions don't matter. Because while you're right about the fact that extensions shouldn't matter, you're wrong about the fact that they do. Because unlike classic mac os, we don't have file types encoded in the metadata of the file anymore. The only way for an application to specify the types of files it can or can't handle is the extension. And likewise for telling the OS which applications should open a given file type by default. The extension does matter, because it's important metadata the OS and applications use to determine how to handle the file. macOS tries to hide this importance by default and won't show extensions if you don't want it to. But in order for that to work and for files to still be the right type so other apps can know what to do with them, the OS save dialog MUST put a proper extension on the file, even if you don't display it. But now because that's something that can (and will) be changed in the save dialog, it also has to check if you're applying a new extension to a file that already has an extension. Because it needs to confirm if you meant to change the extension or just (as you point out is possible) add another dot separation to the file name. So there's probably a bug in the part that's supposed to be checking for whether it needs to add the extension. Some default case path got broken, and it's taking the case where you save, but include an extension as being saved without an extension because it didn't recognize the extension from its list of "proper" extensions.
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?
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.
Up until recently it was still named the "iTunes Classic Visualizer" even though it was in Music.app. It's buried under Menubar > Window > Visualizer > Classic Visualizer now.
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.
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.
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.
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.
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).