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.
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.
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.
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.
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.
> 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.
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.
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".
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.
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.
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.
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.
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.
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)
> 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?
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)
Are you thinking of a safari exploit that allows JavaScript to get out of the safari process? What’s the attack scenario?
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?
I currently use M3 Max MacBook Pro. Mac OS 14.6.1（23G93).
Firefox 130.0.1
Safari 17.6 Seems like a Google Chrome-specific behavior, but I don't have Google Chrome installed to test.> Intel Mac OS X 10_15_7.
This is on an M4 MacBook Pro running 15.0.
So not correct.
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
Why would they want to do that?
To be honest, I’m not entirely sure.
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!
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.
Bummer. Agree w/workaround solutions. I've just flipped to other browsers for most situations.
What's your particular use case to keep using Safari if it's not working for you and there are alternatives available?
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.
Not GP, but:
iOS Safari dev tools
Testing for compatibility
I get this too
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.
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.
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.
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)
> 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.
In the five years I have used Arch, I have not had a single issue.
> Debian is stable and conservative/slow in updating?
Sid isn't.
Oh I can’t change distros now because of philosophy?
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`
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.
Better never navigate through AOSP source code.
Sure there is, 3 reasons:
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.
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.
I remember this, how annoying! I think you'd work around it by pasting.
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".
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 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?
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)
It can require it if it is enabled. Which is not mandatory.
No, even if you have it disabled, google will occasionally ask for a second factor anyway. This often outright locks people out of their accounts.
(see this for example: https://support.google.com/mail/thread/14768952/how-to-turn-...)
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.
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
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.
The MacBook keyboard is atrocious. I always mess up the passwords a bunch of times.
Users are beta testers, and always have been.
Are you sure you can't remap the keyboard shortcuts? I believe you can change them in System Settings -> Keyboard -> Keyboard Shortcuts
AFAICT You are able to remap the 'Globe' key to another key, say CAPSLOCK.
But you can't remap the key combinations assigned to the new Tiling feature!
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.
I think they’re on the windows menu. If so, I believe you can. I’m staying away from Sequoia for awhile though, so I can’t test it.
How about that, so they are!
I didn't think to look there LOL
Thanks for the heads up, you've made my day!
:)
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.
Temporary workaround: write nothing else but assembler source
Low Assembly strikes again. They are really pushing their marketing budget these days.
"Working as intended. Won't fix."
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.
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.
Oh yeah. For example:
I may have a method in my class:
The "helpful" autofill might give me: If I'm lucky, but it's more likely to give: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.
> 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.
How is this passing QA? Did no one try to save a file during the whole beta?
File saving dialog doesn't have functionality for purchases or subscriptions, so it may have a lower priority in the eyes of upper management.
I can understand people thinking it’s a misguided feature considering my own experiences.
A feature to accomplish... what?
It isn't "autocomplete" as the original title implied; the .s never appears in the save dialog even if you tab away from text entry.
Apple has been deprecating global access to the universal type system, so it is certainly possible this was an edge case falling out from that.
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.
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.
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.
That's a great way to drive someone insane.
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".
Wow. Coming from DOS times, supporting double quotes in a filename is wild. I _still_ tend not to use whitespaces in filenames!
pretty common on UNIXes; you can also have forward slashes in filenames. They just have to be escaped to differentiate.
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...
Did you upgrade to Sequoia?
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.
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.
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;
It doesn't make much sense. The only files I know of that are .s are assembly.
In Windows land, you can put quotes around your file name to prevent the default extension from being added to the filename.
In Linux land you tell your computer what to do, not the other way around.
Wow, this is truly some "Staff Engineer, Level 7, TC: 900k" stuff.
I wonder if this also happens if a partition is formatted case-sensitive?
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?
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.
Replaced is doing some work.
Rebranded is more apt. It’s still iTunes.
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.
:w ~/my/path/thing.txt
Works every time.
Actually no. We got a `CHANGELOG` file in Git, which's last 10 lines consist of variations on `:wq`, `:x` and `:q!` :D
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...
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.
> must be some odd interaction between Sublime or Zed and Sequoia
The same happens with MacsOS' own TextEdit. All "unknown" file suffixes are a problem
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
I'm not the only one who found this UX to be shit
https://discussions.apple.com/thread/255195309?sortBy=rank
https://www.reddit.com/r/MacOS/comments/16wzdk9/is_there_a_w...
https://apple.stackexchange.com/questions/465132/how-do-i-tu...
https://apple.stackexchange.com/questions/464877/how-can-i-d...
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.