I'm just glad and grateful there's super smart people out there volunteering their time on worthwhile causes.
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.
Then why do I have "black magic" on my LinkedIn profile???
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'.
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.
Another time, I read a Brainfuck wikipedia entry for about 30 seconds.
I still haven't recovered.
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 :)
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.
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...
It is black magic to people who read and don’t understand a thing. :|
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.
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.
Only 14/16-inch models where users have explicitly disable ProMotion and are desperate to boot into the RecoveryOS.
To ship this severity of bug in an X.6 release too is definitely very eyebrow raising.
I hope this was a joke :)
The worst thing that Apple did to themselves is force everything and everyone into a yearly release cycle
This is actually the best of both world, they stay independents, they get paid, Apple fixe the reported exploit.
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-...
You can often use technical solutions (e.g. JTAG) to fix "bricked" devices.
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.
Soft bricked == here's how you can fix it.
Hard bricked == here's how we can fix it.
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.
The results differ immensely, and neither approach are perfect.
A big part of the reason people are paid multiples of six figures is to put up with an unhealthy amount of stressful bullshit.
There’s no public information yet as the patch didn’t make it in time for the 14.1 release.
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.
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.