Asahi Linux goes from Apple Silicon port project to macOS bug hunters | Hacker News Reader

Asahi Linux goes from Apple Silicon port project to macOS bug hunters

theregister.com

339 pointsBender148 comments

This is a huge embarrassment for Apple, because a team of unpaid volunteers are superior to the supposed talent you are shelling out multiples of six figures to.

Oh yes, multiple six figures have always caught bug every single time at every other place than Apple.

Bricking your own devices with your own update is extremely amateurish and embarrassing. If Apple knew about shame that is.

Ok, let’s see your processes for shipping an update to a hundred million devices.

This wasn’t an issue in their rollout process, but in their QA that needs to test orders of magnitude less setups.

Presumably they'd need to test more? Because I assume that whatever they tested passed QA and didn't include what Asahi is reporting.

Semantics. Seems to me like OP was talking about the entire project of making and releasing the newest version. QA would most definitely be apart of that.

*billion

Definitely not that many Macs in use

Not do yearly release cycles.

It’s not bricking.

By that definition, neither is bricking bricking.

You can often use technical solutions (e.g. JTAG) to fix "bricked" devices.

If you own a soldering iron, nothing is bricked until the magic smoke gets out!

I would say it's soft-bricking, but not hard-bricking.

The average user is going to have a heck of a time fixing it. They may not have a spare Mac, or a friend with enough tech know-how to help them. It is effectively bricked since they'd have to go to an Apple Store.

From the horse's mouth:

https://social.treehouse.systems/@marcan/111337509620995637

There are often arguments about what is "bricking" when these things happen, so here's my take (having dealt with embedded device ecosystems for a decade+): "Bricking" is when a device is put into a state that can only be recovered from by using specialized repair/recovery tools, opening up the case (for non user-serviceable devices), or software not legitimately available to the public. Apple Silicon devices are mostly "unbrickable" because you can always recover using DFU mode. In fact they are probably the most unbrickable consumer computing devices in existence, due to how thoroughly a DFU wipe restores everything (not just all software, but even device calibration and settings get downloaded from a server). DFU wipe is documented, relatively user-friendly, and requires only publicly available software and another Mac, which makes these unbootable states not a "brick". In contrast, most PCs are brickable: just wipe or corrupt the BIOS Flash. Most of the time this isn't super easy to do, but it's rarely fully protected and there have been many instances of something as simple as setting UEFI variables wrong bricking x86 machines. The exception here is x86 motherboards with a "BIOS FlashBack" type low-level recovery feature, which is as close as you get to DFU mode in the x86 world. Most Android devices are brickable too, and very easily at that. Just deleting/corrupting the wrong partition on disk will make your device unrecoverable. While in principle they have DFU-like recovery modes, the tools to use them are almost never made available to the public (you need vendor-specific tools, fastboot won't work) nor are they intended for use by end-users, which makes this qualify as a "brick". There is also no mechanism to recover calibration data like Apple has. There is, however, a tangential aspect: data loss. Any mention of bootability issues should qualify whether the fix makes you lose all your data or not. For example, on Apple Silicon, deleting the first partition on the disk is a very quick way to end up with an unbootable device where the fix requires a full wipe and losing all your data, even though it's not a "brick". For this reason, I would say Apple Silicon is much better than x86 at system recoverability, but is worse than x86 at data recoverability.

I call them "hard" and "soft" bricks. The people reporting issues usually don't care about the distinction, only whether it's fixable or not by them.

Soft bricked == here's how you can fix it.

Hard bricked == here's how we can fix it.

I like that distinction and verbiage.

If you can fix it, it's not a brick. C'mon people, it's not that difficult.

Also, soft brick is as oxymoron as dry water.

I've had a camera firmware update go wrong and not even Fuji was able (or willing) to fix it. That's a brick.

Speaking of bricking devices. One of Apple’s greatest shames was releasing Apple TV 4K, which lacks a USB port. This model could only be unbricked by Apple, until iOS 17 made it possible to do so via the iPhone recovery feature.

If you were talking about the goof troop at Microsoft that is openly user-hostile, I'd agree. Their users are essentially captive. But Apple's fetish for design and user-harmony is what makes this so absurd.

I hope this is a joke.

This unpaid team of volunteers is composed of some of the best and most productive hackers in the world.

If there ever was a team of 10x OS devs, this would definitely be one of them.

I look at some of this code and can't imagine even being a 0.1x OS dev. How do people learn this stuff? It's incredible.

I'm just glad and grateful there's super smart people out there volunteering their time on worthwhile causes.

Every specialisation is specialisation. It's just that more people are into (for example) web apps than OS development. If you spend some time in embedded dev land, things like that make sense. You just get better at thinking at hardware level / synchronising devices, etc.

I mean, they're still super clever, but people learn that stuff by reading about it and practicing. You could go that way too, it's not black magic.

> it's not black magic.

Then why do I have "black magic" on my LinkedIn profile???

My guess is you invented the ATEM Mini.

Heh, I got the joke, at least.

Sure seems like it to me, lol.

I learned web dev first by using Geocities and Frontpage, then Dreamweaver. These days I actually get paid to write Javascript (something young me would've found unbelievable enough already), but to me that's still a huge difference from "real" programming, especially in C or assembly.

Web dev (at least the kind I do) is mostly still just declaring UI in a XML like syntax, then wrapping it up in some events and state management. It's not that different from, say, Visual Basic. At its core it's a bunch of event driven reactions and API calls based on UI clicks. Once upon time that was Perl or PHP or jQuery, now it's usually React, but the fundamental process of "declare UI, add event handlers, send to APIs" hasn't changed much IMO.

But an OS? Man, how do you work with memory access? Overflows? Garbage collection? Device drivers? Caching? Graphics pipelines? USB? Lightning? I don't even know where to start with any of that, and an OS is ALL of that and then some.

Mad props, is all I'm sayin'.

It's almost exactly the same, except the building blocks are much simpler (=more primitive) so you have to spend more time per useful thing you want to get the machine to do.

If you want to get a taste of what that means that is definitely 100% within your abilities, try to write a Brainfuck interpreter in JS, and a Brainfuck to JavaScript compiler (that yields a string that you can eval() to run the program).

Then try to write some simple Brainfuck programs, then try to write a Brainfuck interpreter in Brainfuck. At this point you won't yet know how to write an operating system, but you'll definitely know how it feels to write one.

Heh, that seems like a perfect weekend project for whenever I feel like I'm missing a swift kick in the nuts.

Not sure why I'm getting such negative reactions. I've given these exercises to many developers, some of them very junior, and seen them complete them successfully. It's not that hard to do each step after the previous ones, and very rewarding to complete the entire thing.

It might not be "hard", but it sure sounds very tedious to put it lightly

Not too much work, either. I once live coded a Brainfuck interpreter in 30 minutes for PyCon IL, and there aren't really any tricks involved, just work, so it should take the average dev that didn't just practice it maybe 2-4 hours: https://www.youtube.com/watch?v=F5P6Q7vs_-Y

I once live coded a vertically centered image in 30 minutes. My coworkers were pretty impressed. We had low standards...

Another time, I read a Brainfuck wikipedia entry for about 30 seconds.

I still haven't recovered.

It sounds doable, just painful! I'm not sure I'm masochistic enough. Like I could do that, or maybe go on a bike ride, or get some ice cream...

I think I have pretty underwhelming dreams relative to OS devs, lol. I feel a ping of reward when a web page loads without crashing, or a npm audit passes without red, or I finish a level in Mini Motorways.

Generally, my secret to a happy life is to aim low, and then be satisfied once I hit half that :)

I promise you it isn't. It's a fun challenge, and not too hard. Smaller and easier, say, than delivering a full eCommerce website end-to-end. I'm not an OS dev myself, I just love playing with technology of all kinds and picking up elegant ideas, and this is one kind :)

Thanks for the laugh.

> But an OS? Man, how do you work with memory access? Overflows? Garbage collection? Device drivers? Caching? Graphics pipelines? USB? Lightning?

You start much simpler. Grab some ESP32 or ARM development board and start with trivial things on them. Simple devices also have simple drivers - sure, trying to connect to an NVIDIA card is hard, but an 128x128 LCD display is trivial. Then you build more complex things on top of that. Same with PHP - you start with 'echo "hello world"' rather than full reactive page with many server routing endpoints.

Technologies become more complex as people accumulate experience.

Web only started in the 90s, and was intentionally designed to be simple (html and stuff). Even so, it's morphed into a very complex thing already. It doesn't feel like so because you (and to some extent, I too) have been witnessing its evolution as it happens, so it's all incremental, but I can imagine a total newbie coming into the field and feeling overwhelmed.

Like, try to explain things like CSRF tokens, Web Assembly, HTTP/3...

> but people learn that stuff by reading about it and practicing. You could go that way too, it's not black magic.

It is black magic to people who read and don’t understand a thing. :|

Remember, so is centering a div.

I thought flexbox pretty much fixed that

osdev.org and lots and lots of reading code and manuals.

And here they are, doing charity work to the benefit of the largest corporation in the world.

I don't understand why they don't just pay them to work on Asahi and then they can learn directly from all their findings?

Apple would want them to sign an NDA and that would be incompatible with them doing as much as they do in Linux.

Apple can decide to not let them sign an NDA and just pay them for the excellent work that they are doing now and give them a good priority channel for reporting issues.

why would apple pay them to do something they already do for free?

I very much doubt the math for the PR-to-cost ratio works out to justify hiring them, but presumably the reason would be so that Apple wouldn't have to see articles like this or to have the top comment on tech threads be "this is a huge embarrassment for Apple".

Similar reason as to why companies have bug bounties; they want to incentivize hackers to report bugs through official channels early enough in development that they can get patched before release and before tech journalists write articles about them. They don't want to find out that their products have bugs via social media. Even if that process happens out in the open via a Github issue, getting giant problems like this caught before release and quickly escalated internally through official channels would go a long way towards mitigating article titles like this.

Having said that, does Apple care about the Register or HN? Probably not? And assuming that Apple did care about bad PR among extreme power-users, would Asahi Linux want to be paid by Apple to do testing on their releases? That's also not necessarily a given, the team would have to decide if they wanted to have a more official relationship with the company or not.

Pretty sure TheReg has been on the Apple blacklist for PR and industry events for some time. Like TheReg, I think it'd be a badge of honor...

Because having worked at Apple and seen Radar.

The issue has never been finding the bugs. It's having the capacity to fix the bugs.

And when you are this early in the OS release cycle (we are only at 14.1) there are inevitably a lot of P1 issues that limited resources are competing to fix.

But I have to imagine an issue that renders Macs unbootable would have been considered blocking, had Apple known about it.

It's an edge case with a workaround. P2 and definitely not enough to prevent a release.

Only 14/16-inch models where users have explicitly disable ProMotion and are desperate to boot into the RecoveryOS.

My understanding was that if you disable ProMotion you can become unable to boot into your main OS.

Like the other user said, this bug effects a much larger set of customers.

To ship this severity of bug in an X.6 release too is definitely very eyebrow raising.

Who/what is limiting those resources? It certainly isn’t a lack of US Dollars. Is it executives on the financial team requiring a never ending increase in profit margins even though the margins from two years ago were also infinitely sustaining?

Most likely people. As large as Apple is, there’s only so many programmers writing code. If you’ve ever read The Mythical Man Month, you know that throwing more programmers at a project does not nessesarily make it go faster.

QA is somewhat scalable than development. More test to find more bugs.

> And when you are this early in the OS release cycle (we are only at 14.1)

I hope this was a joke :)

The worst thing that Apple did to themselves is force everything and everyone into a yearly release cycle

Asahi Lina (one team member) recently got a 6 figures paycheck from Apple through their bug bounty program for CVE-2022-32947 https://news.ycombinator.com/item?id=37543664

This is actually the best of both world, they stay independents, they get paid, Apple fixe the reported exploit.

More information:

Here's the clip where Asahi Lina says she received $150,000 for CVE-2022-32947:

- https://youtu.be/hDek2cp0dmI?t=11451

And Apple credited them under GPU Drivers for macOS Ventura 13:

- https://support.apple.com/en-us/HT213488#:~:text=CVE%2D2022%...

Related coverage:

- https://secry.me/explore/news/cve-2022-32947-first-critical-...

- https://nvd.nist.gov/vuln/detail/CVE-2022-32947

For one thing, when you're paid, you don't really get to choose what you work on, unlike an unpaid volunteer. There are feature lists to check off, deadlines to hit, and you work on what needs to be done, which isn't even always what you're good at. In contrast, the volunteer can choose to spend as much time as they want digging into whatever topic they want.

The results differ immensely, and neither approach are perfect.

This is essentially what I was going to say. Being paid can actually reduce motivation because deadlines are stressful and there's plenty of work to get done that you won't find interesting or maybe will just get bored with after the initial excitement.

So we should push for UBI, people can really do stuff that matters.

UBI doesn't eliminate the requirement for jobs...

It eliminates the requirement to be homeless to pursue passion projects. It doesn't stop people fundraising through other means.

I don't think people are seeking to be housed (only) and working on passion projects. More people have passion in a comfortable lifestyle.

Yes? That's what makes the system work. But it becomes an option, which is pretty good.

Big companies are pathologically inefficient and bureaucratic.

A big part of the reason people are paid multiples of six figures is to put up with an unhealthy amount of stressful bullshit.

Some incentives work better than money specially for white hat hackers.

That logic doesn't make much sense. They didn't even announce a release date for the software until recently. Why not push it back for QA? It's not like they have to ship everything on time (AirPower, original HomePod come to mind)

That's pretty embarassing, customers may end up with a soft-brick if an organizational problem delays communication about a known issue of this severity by over two weeks

Which it seems they did, since Apple's reaction comes after the Asahi publication of the bug

There are better ways to communicate about a black screen bug on boot than leaving people with the fait accompli, one would naïvely think.

Did you mean twitter?

I hired a dev from that team and he was asking for 7 figures. It was a steal.

That's what you get when you hire people for who they are and not what they can do. It's been happening to all the big tech companies and the decline is obvious to see.

On the contrary, that is quite some money they are saving on work time for their own employees.

This is what I thought when I first saw xbox media center, which was so much better than anything Microsoft had done in a similar line and fulfilling an obvious need. Not so much that it was embarrassing for the company but that any company that can reasonably hope to inspire people to do free work to make their product better is insane to try to put roadblocks in the way. Also that there are lots of things you could just leave to the community. Build a good api and let the community build the ui and glue.

Nearly everyone on this thread could pick off something Big Tech hasn’t built.

Companies exist to make money. That means they naturally deprioritize a lot.

Asahi is doing a pretty common pattern of the loud, young new comer. They tackle something that’s low hanging fruit. It’s typically a pretty small issue. Then make a lot of noise.

Everyone focuses on the small problem they’ve solved while ignoring everything else that still doesn’t work.

> We do not understand how Apple managed to release an OS update that, when upgraded to normally, leaves machines unbootable if their display refresh rate is not the default. This seems to have been a major QA oversight by Apple.

This sounds like a very weird edge case and it's very easy to say this sort of statement in retrospect, but I wonder what percentage of engineers would think of testing this specific combo beforehand.

> This sounds like a very weird edge case and it's very easy to say this sort of statement in retrospect

As someone who works on embedded devices with a lot of experience with Hardware-in-the-loop testing, this is 100% a QA oversight.

The way this feature is implemented screams "test it from boot to reboot". I wouldn't pick too much on a small company doing some basic BSP/application work for some HMI device or something like that, but this is the richest company in the world with major funds/infrastructure to be better than this.

> The way this feature is implemented screams

Do we have info about the implementation somewhere?

Yes, we know the setting is persisted by storing the display configuration in nvram.

>> This sounds like a very weird edge case

It's a single setting prior to a standard update. Now I'm not saying they should test every combination of settings, or even every individual setting. I'm more curious how there is any interplay between this setting and the update, and why that has any effect. On the surface it smells like a system design issue to me - like something is going in there on that shouldn't be.

> I'm more curious how there is any interplay between this setting and the update, and why that has any effect. On the surface it smells like a system design issue to me - like something is going in there on that shouldn't be.

There is (probably) a logic behind it.

https://mstdn.social/@marcan@treehouse.systems/1113296141101...

> Why [does disabling ProMotion cause this problem]? I can tell you why: because Apple hates display modeset flicker, and switching modes between ProMotion on/off causes a modeset flicker, so of course they made it so that is stored in nvram somewhere and applied when the screen is turned on during early boot, so when macOS boots it doesn't have to flicker again.

In other words, Apple was so insistent on one tiny aesthetic point that it ended up breaking things for a lot of others who likely didn't care at all?

Well, only because there was a bug.

I personally appreciate how Apple prioritizes these little details—and I'd argue it's a huge part of what has made the company successful. This is the company that put a speaker in the iPod just to have a clicking sound for the scroll wheel.

I think the polish matters, especially considering that the majority of users with the default setting will be just fine appreciating the benefit. It wasn't intended to be a trade-off either. Just an unfortunate side effect of the additional complexity. It's accurate to cast it as an engineering tradeoff between complexity and aesthetics but IMO would be wrong to say they broke for a certain set of users in favor of aesthetics.

All it would take to find this bug is trying the install the update with an external Studio Display connected to a Mac with a built-in ProMotion display. Not even a third-party external display, just the display Apple currently sells along with the Mac Studio.

Why would this be a very weird edge case on a professional machine?

For context, I hate it when the built-in display is not consistent with my external displays.

Few displays actually support ProMotion rates. So chances are that if you use any external display, you’ll have this jarring asymmetry. So you’ll want to set your rates manually.

Using an external display with your MBP doesn’t seem like a weird edge case to me.

Lots of displays support 120Hz or above. That's actually something Apple has been late to the party with.

On the other hand, Apple has problems with the M series chips and high refresh rate mode timings on external displays, so you're technically correct about the compatibility.

If only they could find a bug/vuln that makes it possible to bypass the "Dead/Corrupted SSD? Dead Machine feature" and make it possible to boot externally, no matter the state of the internal drive.

Wait, so you can't recover data off a drive if you analyze it from another machine? Surely this is only if the drive in encrypted right?

> If you have a Mac with Apple silicon or an Apple T2 Security Chip, your data is encrypted automatically.

Even if you don't have FileVault (macOS disk encryption) enabled, data on SSD (or NAND chips with Apple silicon) is encrypted, so it's quite unlikely that you would be able to recover anything.

Not to mention that SSD/chips are soldered on the motherboard.

If the computer still turns on you can at least get to recovery and use USB-C/Thunderbolt disk sharing.

This thread is referencing if the SSD fails. If the SSD fails, the computer won't turn on, and even if it could (which we wish were the case, but the T2 chip prevents), you couldn't use get anything off the disk because it's a dead SSD.

In the event of an OS crash/issue, or just minor corruption, that might be an option. Related to the original article -- I'm not sure what is meant by DFU mode on a MacBook (only have heard of that on iDevices) so it's unclear to me if you can EFI boot into another OS. Given that it also affects Asahi Linux, sounds like you can't EFI boot into anything, even OS Recovery for Mac Sharing mode.

The architecture of Apple Silicon Macs is shared with iPhones and iPads and there isn’t an EFI environment. DFU mode on a Mac works the same as an iPhone and lets you restore from another computer.

https://support.apple.com/guide/apple-configurator-mac/reviv...

There is no EFI on Apple Silicon. It's a more iOS-ish pre-boot environment (based around iBoot and some other Apple-y things).

There's also not exactly a boot picker in firmware-- that lives in the recovery OS. Which will also be unbootable if you're impacted by this issue because it's a minimal macOS environment; if your only OS is 13.6/13.6.1, that recovery partition will also be 13.6/13.6.1, and, if you have upgraded to 14.0/14.1, that installer can fail to update the recovery partition and leave it at 13.x (whatever you were on when you upgraded).

In this case what is the point of FileVault?

The data is encrypted at rest regardless, but if FileVault isn’t enabled it unlocks without a password when you power on.

Makes sense, thanks!

unlocks without a password

That suggests its only goal is to frustrate right-to-repair and data recovery. Also as a way to sell their cloud backup solution.

"Sorry, we can't recover anything, but you should've used iCloud!"

Aren't there laws against these sorts of business practices?

It makes the “factory reset” button work instantaneously instead of taking several hours. Supporting the secondary market with convenient wiping should be encouraged from an environmental point of view.

Does this really "support the secondary market"? Are there people who want to sell their machine but would be discouraged by the "several hours" it takes for it to reset?

This isn't really an Apple exclusive feature or anything, it's basically the same as self encrypting SSDs.

Much better than the OSnews article that related Asahi[1] to the bug and when called out by marcan they stated that the headline would stay [2].

The article seems to have been deleted[3] at some point since the link from marcan goes to a 404

[1] https://social.treehouse.systems/@marcan/111334488235016591

[2] https://mstdn.social/@osnews/111334720022394898

[3] https://www.osnews.com/story/137678/apples-macos-sonoma-make...

OSNews author seems to have something personal against Apple, it reads like a personal blog when it comes to Apple related news with completely biased writing and I stopped reading years ago.

I mean at this point I’m pretty sure it is a personal blog but with an archive of OS-centric news from back when there was more variety in the field. But yeah, quit reading for the same reason. It’s one thing to be biased against a company, I have my biases too, but this was on another level.

Looks like the OSNews article has been removed now. I just get a 404.

The author did say he's removing the article for now, and he'll upload a fixed article later [1].

[1] https://mstdn.social/@osnews/111335189028196715

I’ll chime in with something a blogger once wrote.

Paraphrasing here: “The current macOS (macos 11 at the time it was written) looks and feels like it was designed by someone who never used macOS and has only used an iPhone.”

Apple Pro M1 16-inch User here.

I went to restart my machine (was plugged into a lightning hub with 3 monitors, I don't ever recall messing with refresh rates) and it went to update. At some point in the loading bar, the screen went black and then flashed an apple logo. When I pressed power, I could sometimes get the apple logo to display on boot, then it went dark. To me it looked like it wasn't booting at all but the machine is pretty quiet even when it's on so it was hard to tell what was happening.

We went to do the firmware revival process using another mac and it would barely recognize the device depending on what we tried. Eventually we were offered the option to do a full system restore, and after many hours battling this, we decided to just lose the data on the machine.

Luckily I keep most major stuff in cloud or in github, but I lost a significant amount of work from the previous 24 hours that ended up delaying a release and causing significant pain. For how much these machines cost, this is completely unacceptable. I know windows machines have their fair share of issues, but in 15 years of working on various windows and mac workstations this is the only time I've lost an entire drive.

This is insane, was there additional software installed by your employer that might have conflicted with the updating process? In my case we have lots of remotely controlled macOS updates that get triggered and supervised by the company I work for.

I wouldn't be surprised if MDM policies caused some funky shit to happen. I couldn't use the migration assistant on one machine because the policy blocked the recovery OS; it just silently failed and booted you back up into your main account.

This is a now well-known bug having to do with multi-monitor setups or changing the refresh rate of the internal panel. MDM policies and other software couldn't write to NVRAM in a way that would cause this issue without the help of a bug in Apple's code.

This sucks, sorry. Things like this are why I tend to wait until downtime (usually Christmas holiday) to upgrade to the latest macOS each year. This gives time for bugs to be discovered and fixed, and if there is a major problem, I have time to fix it.

And, if you can, always wait until X.1 or X.2 at least to upgrade.

Me I just yolo the beta on my daily driver right after the wwdc keynote. If there are any issues I prefer to know straight away. Surprisingly I’ve never run into any major issues, only minor glitches.

Yeah, I always wait until at least X.1. There’s a bunch of people in my company’s Mac users slack group that have been complaining since 14.0 about WiFi/connectivity bugs (often having to reboot to get WiFi to reconnect). It was bad enough for the company to block 14.0 upgrades until 14.1 came out.

Hi, in case you face these challenges again, put the target system into DFU mode and connect the configuring system using the appropriate USB-C port (only one will work).

The DFU key combination is finicky for portable machines: connect a charger (preferably Magsafe so you can watch the power LED) and your configuring system, press and hold power to be sure the system is off (if doing this turned the system on, repeat this step), press left ctrl+option and right shift at the same time as the power button, count ten seconds, let go of everything but power until the device shows up as "DFU" in Configurator (you may be prompted to allow more accessories to connect to your configuring system before it does).

If asked to perform a software update before/during reviving, choose "Quit and update" and start the process again. If you upgraded to 13.6 or 12.5 before facing these issues, you may have to enter recoveryOS instead of booting normally and perform a system upgrade to Sonoma.

If done correctly (without choosing Restore), you will not lose data. If you can't do these steps yourself or think you will have trouble walking a family member through them, the Apple Store can do a revive for you (be explicit that they are only to revive the machine, not restore or replace).

Full details at https://support.apple.com/guide/apple-configurator-mac/reviv...

My 16" M1 MBP was bricked by the Sonoma update and had to be wiped by Apple. Fortunately, I keep most things on external drives. But it's still an egregious QA failure on Apple's part, as witnessed by the increasing number of reports.

And Sonoma appears to be riddled with odd little bugs, manifesting as UI failures. Windows don't come up, or they come up behind others when previously they didn't. For example, disk images, when mounted, open a window as usual but that window appears behind others on the desktop so you're left wondering what happened.

I just had keyboard input rejected with "boink" noises in a dialog raised by Safari, over and over. In the end I couldn't log into the site.

The "About this Mac" item in the Apple menu did nothing, over and over...

and sure enough, I just tried this, and it happened again. But when I started Screenshot to capture it and file a bug, it started working. This is the second day in a row this has happened.

It's looking like a shitty Mac OS release.

I feel like I live in a parallel universe sometimes when I complain about things randomly breaking or never actually working and they say ‘I’ve been using MacBooks for the past ten years and literally nothing bad happened ever’ and here I am just about to break the one year milestone and I just don’t see the mythical Apple level of quality.

The thing is that Apple devices are so widely used, that even if 0.1% of the users encounters an issue, it's still a huge number of people. Added to that, people who run into issues are more likely to complain online than people who don't. So, you don't live in a parallel universe, you're just one of the unlucky 0.1%.

And yes, I have been using Macs for 16 years and have never had a catastrophic issue and neither one of my friends of family. The worst problem was kinda self-inflicted, pre-SIP I was once typing something along the lines onf sudo rm -rf /Library and then accidentally pressed enter. Yay for backups.

> It's looking like a shitty Mac OS release

No this happens every Mac OS release for the last 20+ years.

Sonoma has literally just been released and we only recently had the first major patch. So there will be bugs both known and unknown. Almost all by definition not fixed.

As always if you are doing mission critical work then for any piece of software you should always hold off upgrading until at least a few major patches have been released.

This bug affects Ventura patch as well though.

Some releases are way worse than others. One was truly embarrassing; I can't remember if was Jaguar, Leopard, or some other member of that litter.

>My 16" M1 MB was bricked by the Sonoma update and had to be wiped by Apple.

If it could be restored by wiping the SSD, it’s not bricking. It’s terrible, for sure, but bricking means your device turns into one and you might as well throw it away. If it’s recoverable via software, it’s not bricked.

But what if the SSD contains critical boot components which can't be recovered without the aid of a secondary laptop?

There is no scientific definition of "bricking", and I agree this is a bit of a gray area, but I think it's fair to use the term.

On its own, it was inoperable and unrecoverable. Close enough for me.

https://news.ycombinator.com/item?id=38107238

Oh, I can reasonably consistently kernel panic sonoma on m1, simply by using fullscreen zoom in accessibility and streaming video.

I think that's my last bug report, as none of my feedback/bug reports, which are very detailed, and some cause data loss/corruption.

0 feedback, 0 fixes. Total waste of time.

I wonder where their software quality and consistency team went to. If you'd release similar buggy software when the AppStore on iPhone became available, your app would simply not pass the quality criteria.

Debian looks awfully nice these days, especially combined with proxmox / passthrough devices

> Windows … come up behind others when previously they didn't.

m1 16" MBP here, this happened to me on the last OS version too. Still happens on Sonoma.

For about 1 year (a few years back) I had an issue where on my three external Samsung monitors (all in portrait orientation) there was a strip about 4cm all across the bottom of all of them, and up the right side of the right monitor where the mouse wouldn't go. Apple couldn't work it out, spent hours talking to them about it. In the end an OS update fixed it.

but the machine is pretty quiet even when it's on so it was hard to tell what was happening.

This is why I hate the loss of HDD and other activity lights. It's unfortunately not specific to Apple, but they're a leading offender of this "opaqueness" trend.

I admittedly have little Mac experience but it sounds like you weren't able to boot from a USB and copy the files you needed off the drive? That's the usual approach when something like this happens with a PC. I've even done a bit of Hackintoshing and you can certainly boot the macOS installer and use the terminal there. There's currently a gray comment at the bottom of the discussion here lamenting the "smartphonization" of computing, and this is a great example of that. You're expected --- or rather, forced to be --- helpless and treat the machine (or "device") as disposable when something goes wrong, and the same goes for your data; unless you give up some ownership by letting some thirdparty store it for you, that is. (Then again, I own an Android where I can backup and restore the whole eMMC, so it's not a complete characterisation.)

Relevant Douglas Adams quote: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair."

For MacOS, iStat Menus, the replacement of the older open source MenuMeters is a hard requirement that should really be built into the OS.