 Hello, everyone, and welcome to the second day of talks at Academy 2022. My name is Hector Martin, and I've been a Linux user and KD user for over 20 years now, and I've also been hacking on embedded devices almost as long and messing around with weird hardware. So I'm afraid I couldn't be here with you today physically at the venue, but I'm giving this talk remotely, and we will be having a live Q&A session at the end, so please do stick around. So I'm going to be talking about a little project of mine that is called the Zahi Linux, you may have heard of it. And instead of giving you the marketing grub, let's just go straight to a demo. So if you have, does anyone have one of those Apple Silicon, you know, fancy a new Macs that Apple released in 2020 and later? Yeah, so if you have one of those, you can pull up on my web, pull up a terminal and just type in this command here. And after you follow a few simple instructions and reboot a couple of times and follow a few wizard steps, you will find yourself at a fully functional, plasma desktop environment that you can use on your Mac, ARM64, Apple Silicon machine. So we have working Wi-Fi, Bluetooth, the multi-touch trackpad works. You can use the SD card reader on the models that have that. We have battery statistics, the USB 2 mode on the USB ports works. USB 3 works on the Type A ports and systems that have those. The headphone jack works on the latest kernels. And work is in progress on USB 3 display port and Thunderbolt on the Type C ports. There's some very good news this week from Sven. He just got this report output working a couple of days ago. And we also are working on the speakers, which are actually working, but need some user space tooling and safety stuff to be to sound good and be safe so that you can't blow the speakers. Also, we're working on the GPU and some other very good news this week. Our developer, Sahilina, got the GPU to boot up a Nome environment. You know, fully hardware-accelerated and you can use Firefox, you can use Nomaps, and you can use KDE apps. I hear the only reason that you can't actually start Plasma yet is that Xorg doesn't work and Plasma has a hard dependency on Nex Whalen still, even in Whalen mode. But I'm sure we can get that fixed up. So it's working. It's looking pretty good. We're also working on Sleep mode. So, yeah, you get, even without Sleep mode, you get upwards of 16 hours of battery life just idling on the Nex with the lid closed. And the best part is that you don't need any jail breaks. You don't need any weird hacks. This is all fully supported on the platform. And, you know, you can install it and be confident that it's going to keep working and you can use it as your main machine and you can do a boot with macOS. So we're going to talk about how we got there. If we go back to November 24, 2020, that was a little bit after Apple released these new machines. And yeah, at the time, you know, it was a completely new hardware platform, which only supported macOS. And there was an article on that date by Linus Torbott's and he said, the main problem with the M1 for me is the GPU and other devices around it because it wouldn't have any Linux support on this Apple opens up. That's what he said at the time. And if you fast forward to July 31, 2022, Linus Torbott's released the Linux kernel 5.19 from an Apple M1 MacBook Air, sorry, Apple M2 MacBook Air running our downstream kernel patches. All right, let's talk about how we got here. So in the beginning, quite a few years ago, Apple obviously decided to move to ARM64 and they started with the iOS architecture, which had been using ARM64 for several years now. So they were using Intel for their MacBook hardware on their Macs. And I guess it wasn't, you know, meeting their expectations. They wanted to move to an in-house architecture. But how do you turn an iPhone into a Mac? Because an iPhone is a lockdown device. You know, they can only run a single OS version. You cannot downgrade them. You have to phone home to, you know, flash the new firmware. So you can only use the latest version. But they are very secure and robust. So, you know, that's a plus. There's good reasons to own an iPhone. I think it's the most secure hardware platform in existence right now for consumers. But, you know, if you want a Mac, developers expect Macs to do things like support having multiple Mac OS versions installed. So you can test software in different versions. And kernel developers expect to be able to run and debug kernel extensions. Or, you know, that's like kernel modules for Mac OS. So, you know, if you look at Macs until that point, they had been using EFI as a bootloader. And that gave you an open boot environment, effectively. Very good install, whatever you want. But EFI is kind of a security nightmare. You know, EFI is like a whole operating system all into itself. It can run drivers from, you know, ROMs inside hardware devices that are attached. It has a huge attack surface with like USB support and all this crazy stuff and networking and graphics and all that. And it's been the source of a lot of security vulnerabilities on, you know, X86-based machines to this day. So Apple didn't want to use EFI. And instead, they went ahead and said, okay, we're going to take the iOS version. We're going to take the iOS design. And we're going to instead add stuff to it until it is something that we can use on a Mac. And so they came up with this thing called Boot Policy. And what that does is it basically lets you install multiple Mac OS instances on a single Mac. The boot process is still basically the same as, you know, an iPhone. But there's this actual layer that lets you, you know, select between different OSs. And the cool thing is that for every single OS install, there are three security modes. And one of them, the first one is called Full Security. And that's basically the same as iOS. It does the phone home thing where you install a new OS version. And it's, you know, fully locked down. You basically can't, you can't even install third-party kernel extensions. But it's the most secure mode, if that's what you care about me, trust Apple. And then there's a mode called Reduce Security, which lets you install on-sign software and third-party kernel extensions. But it, you know, it's still somewhat locked down. But most interestingly, there's a mode called Permissive Security. And Permissive Security mode can run untrusted operating systems. But you still need to authorize them as the user of the machine. So it's not like it's, you know, turning the machine into an insecure, you know, secure boot-off EFI machine. It's actually more secure, even in Permissive Security mode, than probably any EFI machine today, just because the firmware is, you know, a lot less complicated. And because of this, you know, authorization process, it's actually user-controlled. The user decides what they want to install in their machine, and that's really important. So Permissive Security, if we quote Apple's documentation on this, they say Permissive Security also provides an architectural capability for running an arbitrary, fully untrusted operating system kernel. And there's a little asterisk here at the bottom saying, important, Apple doesn't provide or support custom XNU kernels. XNU is a Mac OS kernel, and it is actually open source. So when this came out, just I think it was about a month later, after the release of the machines, there was a blog post that showed up and, you know, it was a blog post telling you step-by-step instructions on how to compile and run your own XNU kernel on one of these Apple Silicon machines. And if you look at the author of this blog post, you'll find that it was Jeremy Andris, who at the time was the kernel engineering manager at Apple. So, yeah, they don't provide or support the kernels, but at least the engineers clearly think this is a good idea. So if we can install multiple OSes in different security levels, which is really cool, by the way, and with custom kernels, can we put Linux on it? If you dig around Jeremy's website a little bit, you'll see that they're in a little corner. It says, I am a historical fan, user and hacker of the Linux operating system. So, yeah, Jeremy probably thinks this is a good idea. Let's give it a shot. This is a really interesting situation because Apple is basically saying, okay, you can boot whatever you want. And, you know, we basically promise that you can boot whatever you want. This is part of the design of the system. It's engineered to be like this, but we're not going to port Linux for you. We're not going to give you any documentation. We're not going to help you at all. Have fun. And this is really something that has never happened on any platform to this day. Because if you look at platforms that have Linux running on them, it's either officially supported or it's something like Android, which is originally Linux anyway. And so using third-party OS on those Android phones is more of an integration job than importing from a scratch job. It's so much similar with things like consumer routers, which usually don't have, that manufacturers usually don't condone third-party OSes, but they do allow it and they don't really sign their bills or, you know, lock everything down to make that impossible. But then, you know, you can usually get the kernel source and all that. So this is very interesting, because it's like a brand new platform that is completely unsupported other than the CPU. And yet, you know, the manufacturer is saying, feel free to put whatever you want on it, but we're not going to help you. So how do you put Linux on this kind of platform 101? I'm going to give you a four-step guide to how to make something like a Sahil Linux possible and successful. Step one is to realize that this is a big project. So I've done Linux ports to weird hardware before. I put Linux on a PS4. And one thing I know is that, you know, if you're doing this as a hobby on your spare time, you might get a tech demo out. But there's a very big difference between a tech demo and something that is stable, well-supported, and upstreamable into the Linux kernel and actually getting upstreamed. So I knew that, you know, if I was just going to be working on this on the weekends and my spare time, it was never going to get anywhere. And even as a full-time job, I would need other people's help to make this a reality. So I said, okay, are there enough people actually interested in this to let me turn this into a full-time job? And so I asked Twitter, you know, would you support this kind of effort? And if you look at the numbers, if you look at the percentages and the, like, vote counts there and the, you know, the math, don't worry about the, you know, the relative winner or anything. But if you do the math, you'll see that it works out even if you factor in, you know, a lot of overhead. So I was very surprised and pleased by that. So I said, okay, let's give it a shot. And I opened up a Patreon and they took GitHub sponsors. And honestly, the response has been incredible. I'm very grateful that so many people think that, you know, this is something worth doing and worth supporting and that they trust me to push it forward. So with that, you know, with enough funding to turn this into a job and not just, you know, like a spare time project, it's time to see how we make it a reality. Now, I've been working on embedded systems and hacking stuff for a long time. And one thing that I've learned is that the most important part to make it a success besides the time is the tooling because every hour that you spend working on tooling is, you know, going to save you many, many hours after that in development. So if we start at the beginning and see what we get on a Mac, if you open up the man page for a tool called KMUtil on one of these machines, there is a command that has KMUtil configure boot and it is described as configure a custom boot object policy. This command can be used to install a custom Maco file. A Maco is the executable format for Mac OS from which the system will boot. So there you go, there you have it. This is the insert your own kernel here command. And how do we go from here to being able to reverse engineer, you know, a complicated system like this? So what I did is start using some existing tooling that I have and improve it because if I know one thing from my wee days and you know, how I did reverse engineering back then is that not just for myself, but also when you have other people helping you, there's a big difference between having, you know, a system where every time you wanna try a new binary or a new version of something or a new experiment, you have to reboot and spend five minutes, you know, juggling SD cards and a system where I can tell someone, hey, if you help me with this, the reboot cycle is seven seconds and you have this interactive shell where you can run things in real time against the system and mess around with everything and you know, upload kernels and do all kinds of crazy stuff. That's a really big help both for myself and to get other people interested. So from those wee days, I took a tool that is called Mini, which was both a sort of kernel and experimentation tool for the wee security CPU, which is an ARM32. I ported it to ARM64 and renamed it Mini spelled M1 in one. And yeah, when Mini started, when I started running this on my first Apple Silicon machine, it was really just a very dumb remote control proxy basically. It was, you plugged into the Mac through a serial port because there's a sort of secret serial mode on the Type-C ports. So if you have some special hardware for that, you can get a serial console and then if you install Mini, it would let you remotely control and read and write memory from a host machine. That was how it started. These days, it's actually the first stage bootloader for a Saki Linux. So it's what you get if you just install it. But if you enable the proxy mode, you get a USB-based proxy and you can experiment with this from a host machine using a very, very full-featured Python tool set. So what this Python shell allows you to do is the lowest level, you can read and write memory and IO registers, of course. But you can also parse Apple's device tree to get metadata about what devices exist. And because it's Python, it makes it very, very easy to both experiment in real time and write scripts to test things about the hardware or effectively write prototype drivers in Python. So some of the things you can do are, simply flip a bit to enable an interrupt, for example, that's just one write. But you can also ask it to power on this device and all parent devices that require power in order for this device to work. Or you can even say, okay, please establish a communications channel to the system management controller on the machine and ask it how much battery charge is left. So these are some of the obstruction levels at which you can talk to the machine with this tool set. And of course, you can also load kernels over USB. So if you're working on Linux, you can just upload a new kernel in the NetRamFS over USB. It only takes a few seconds. And the test cycle is like seven seconds to reboot the machine back into USB mode and then a few seconds to load the new kernel. So yeah, it doesn't matter if you crash the machine, you don't have to mess around with reloading modules or trying not to crash the box. You just reboot every time and it's fine. Like, even if you crash it by the time you've looked at the code and figured out what you want to do next, the machine has rebooted. So it doesn't matter. And many can also reload itself for updates. So you don't even basically ever have to reflash it after you flash it once. And you can add as many features as you want and just do a little extra fast reload step before you want to use them. So that's all really cool. But Mini's biggest feature and most important tool is that it is also a hypervisor. And it can run both Mac OS or Linux or really anything else as a guest in a VM. But this VM isn't really the kind of VM that you're used to in NOS where you have virtual hardware that the guest sees and it has nothing to do with a host. This is a bare bones, very thin VM that actually passes through all the real hardware. So the guest, even though it's running in a VM, effectively he thinks it's running on bare metal and runs all the same bare metal drivers and everything else. So when you run Mac OS on this, you're using the same Mac OS kernel binary that you would normally boot bare metal on the machine, which is not what you would use if you're running a VM of Mac OS in Mac OS, which Apple supports, because that uses a special Mac OS kernel that is built for VMs. But this runs the real Mac OS kernel. And the one virtual peripheral it gives you is a virtual serial port. So all you have to do is plug in a USB cable, no special hardware, and you get a debug serial port out of it. But then of course, because it's a hypervisor, you can use it to debug the guest. So of course you can pause the guest and get back traces and load symbol files. And there's even a GDB server mode. So you can plug in a GDB instance to it and use GDB with all of its features to debug something. And though that's not even the most important part because the killer feature of this hypervisor is that since it sits between the OS and the hardware, even though it's passing through the hardware, it can snoop on all of that communications. So the mini hypervisor lets you trace any hardware or memory accesses that you want and feed that data into Python. And then your Python scripts running on the host machine, which are very easy to write, can do whatever they want with it. And so what we do to reverse engineer these machines is that we start a Mac OS guest in the hypervisor and we log what it's doing with the hardware and we figure things out step by step. So if we do that and we tell the hypervisor to trace every single read and write to the display controller, we will find a giant list of hex numbers and memory addresses. And if we just sort of look at the addresses and the pattern that is going on there, over time we can deduce that this is a mailbox protocol because it's mostly writing and reading the same registers. And so then we can describe those registers in Python, something like this, and when we run that in the hypervisor, then we get a verbose description of all the registers being written, which is really cool. But okay, now we're staring at these mailbox messages and we can realize that on top of that, Apple built a protocol called RTKID, which is the name of their firmware OS, and it has the standard for initializing and sending out syslogs and stuff like that. So we can reverse engineer this and build a tracer for it. And once all of that is done, then we get all these system messages pretty printed and we can even see syslogs from the display controller. And then looking at some of the extra data that's going through and again digging deeper, we can find and figure out that actually Apple runs remote procedure call interface, sending buffers of data back and forth between the OS and the display controller firmware. And so we can figure that out and have the Python site read memory to dump all of those buffers and we get a dump of hex dumps of messages. And then if we dig deeper into that, we'll find that actually it's a remote procedure call interface that basically calls C++ methods. So when we figure out how these are marshaled and how the arguments are passed and all that stuff, now we have a trace of every single function call and callback between the OS and the display controller firmware. And yes, this is crazy ridiculously complicated and I have no idea what Apple was thinking, but this is how we can reverse engineer this stuff. We build the layers in Python. And all this is done using Python scripts on the host machine, which can be live reloaded. So you don't even have to reboot the guest. If you mess up, if the Python, there was an exception, you can fix it, reload it and keep going and you can debug it. And if it does crash, it's not that bad to reboot the guest anyway. Mini has a lot of other goodies besides this. You can build and upload assembly or C code snippets to the target. If you want to just run something bare metal, you can tell it to watch memory ranges and report any changes visually, color coded. You can even have declarative definitions of structures in memory for complicated stuff like the GPU. This is based on Python construct, but it has more features. You can even diff these structures so you can see all this field change from this to that. And there's even a logic analyzer for GPIOs and memory locations. So if you're missing with like spy or escritzy, you can see what the pins are doing and or you can see what the registers or other memory locations are doing. There's a lot of cool features like this and it's all of this tooling that makes all of this reversion engineering possible. So with the tooling in hand, let's move on to step three, which is recruiting more people. What I found when dealing with this kind of project is that if you make it interesting, people will come. And my approach to this is that, okay, if you want to help us out, you can work on whatever you want and I'll just work on things nobody else is working on. You do have to learn to delegate and trust your fellow developers because there's no way you can micromanage anything and it's no fun if you try to do that. But it does help that these are cool machines. So people are interested in hacking with them and messing around with the hardware and figuring these things out. Another thing is that you need to keep the community welcoming and inclusive because it's no fun if people just don't feel like they belong or are not having a good time here. And there is a bit of an art, the community management I found that could be a whole talk on itself, but it's something you pick up after kind of doing this for a while and they have some experience being sort of a de facto somewhat community lead in the We Home Bruce scene. So yeah, be aware of that, that there is some finesse to leading this kind of project. And but yeah, people are different and you have to learn to work with people and make them all work together. And another thing is that this will take more of your time than you expect. I honestly, I think I spend more time talking to people these days than actually writing code. And that's fine, that's the way it goes with these projects. But it's always important to keep people together and everyone happy and working on the one to work on. Sometimes you do have to put your foot down if something is going wrong, but hopefully that doesn't happen too often. Just be aware if it does. But yeah, if you make it fun for everyone, things will work out. It helps if you can get experienced folks and maintainers hooked. Early on we ended up with Mark Zinger from the Linux ARM64 KVM fame. So he did our PCI Express driver and some IRQ and KVM changes that we needed to make this whole thing work with the Linux kernel. But also recently Russell King, the original ARM Linux maintainer started helping us upstream stuff, which is really cool. We also have Melissa Rosenzweig, who is the panfrost driver developer for Mesa, which is a reverse engineered ARM Mali driver. And she is now writing the reverse engineered Apple M1 driver for Mesa. And then we also have some other cool kernel people in the IRC channels, Rob Herring and Aaron Bergman. They also work on related embedded stuff for Linux. And it's really cool just having them around to ask questions and help out. And Mark, a tennis from the OpenBSD project, is leading the OpenBSD port to the M1 and also doing the U-boot port, because we use U-boot as one of the boot loaders in a boot chain. It's kind of complicated. But yeah, U-boot is one of the core pieces there and Mark is doing that. So that's also really cool. You can actually boot OpenBSD, even official OpenBSD actually is supported on the M1 faster than any other distribution of Linux. So that's really cool. I also want to give a shout out to some of the Asahi devs. Sven is a good friend of mine and he works on USB, external displays and other crazy Apple stuff like custom CPU features. Jan Grinnell is hacking on the display controller, IOMM use, device trees and input devices and more. We also have nothing publisher. I don't have to pronounce that right. But he's single-handedly doing all of the kernel audio work, including a bunch of new drivers. And we have James Caligueros who is building the usual space audio stuff. And he's like a proper scientist. He takes like calibrated measurements of the speakers and everything. And we need this and a lot of work on the usual space side because it turns out Linux audio is still not quite there for modern machines. So there's quite a lot of work to do to make it something that people would want to use. And Dina is writing the GPU kernel driver for these machines and she's doing it in Rust. So it's probably going to be the first sort of really complicated Rust driver now that Rust support is getting merged into the Linux kernel in just a few weeks probably. And I also hear, oh yeah, as I mentioned, she did get GNOME working just this week. So things are progressing quite nicely. And I heard that she's giving a talk with Alyssa at XDC next week. So if you're interested in the GPU stuff, you should watch that. And finally, I need to give a shout out to Joy Goli who is helping out the GPIO and Rust stuff. But he's also just the nicest guy ever, helps out all the newbies, talks with everyone on IRC, is always helping everyone else out. You need people like that too. Like we need more people like Joy. All right, so once you have a community and you have some tooling, finally, step four is to make it look good. Because if you have this kind of project and you are going to be getting some press coverage and that kind of stuff, for better or for worse, it helps if you have logos and things like that. But also you need to make the actual product look good because it's no fun if users need to follow like a 20 page Wiki document in order to install all of this. So what we did is we built a user from the text mode installer. And this has to actually set up a whole sort of fake macOS partition so that the boot loader recognizes this as an OS that it can boot. It's kind of complicated because it's not really designed for third party OSes, even though like it's allowed the design of the requirements for the setup of an OS is very much tailored for macOS. So we have to work with that. And so we have to reverse a neural that we made the installer do all of that automatically for you. So the users don't have to worry about that. And once you get the machine installed and it downloads a Linux image for you, we ship those Plasma images. And yeah, once you get it installed, you get, as I said, a KDE Plasma desktop and a Calamars-based first time setup wizard. But there's also some other nice things like we have some tweaks to pre-configure the touch pad. So it works like you expect in a MacBook and the keyboard layout is automatically detected on the MacBook. So you don't even have to think about that. And also high-GPI is automatically turned on on the MacBooks and turned on on the desktops if you have a display that has enough resolution. So it's these little details that help make it feel like the OS belongs on these machines and isn't just something foreign that you install then have to configure everything by hand. And I think these things matter, right? For first time users and people kind of thinking to try and figure out if this is usable or not that you make these things work out of the box and it feels like a polished product, even though it doesn't actually take that much time to do these things. Another thing we did is that we future-proofed it. We have some meta packages so that when we add support for new hardware, users can just upgrade their system and everything just works. So we first tried this when we added Bluetooth support because that required some extra firmware copying and some demons had to be enabled and some things configured. And we did that with the meta packages and in the end, any previous existing user could just update their packages, reboot their machine and they get a Bluetooth icon in the taskbar. And I also think that's very important because you have these early adopters and you don't want to make this a drag for them to have to keep adding things in order to make it work. It's so much cooler if it just like magically works. You update and your system gets better. Yeah, as I mentioned, marketing matters. Kind of cool logo, website, all that stuff. It does help. And finally, you need to care about your users. This is also something that I learned from the Wii days. So not just make their lives easy but make sure they don't destroy their machines, make sure they don't break something in a way accidentally, in a way that they couldn't have predicted. We can't stop people from deleting their partitions, obviously, but that's why, for example, we have had the speakers disabled on these machines even though they have technically worked for months now because we need to have a safety and EQ model that we know prevents users from destroying them by setting the volume too high. And this turns out to actually be a difficult problem. So we're still working on that. And until we're confident that you can't destroy them, we're gonna keep them disabled. And also for USB-based recovery, Apple provides a tool to recover these machines over USB. And we have an equivalent tool called iDeviceRestore. That already existed a long time ago. I was actually somewhat involved with parts of that way way, over 10 years ago. But yeah, we made sure that actually works for these brand new Macs and not just iPhones like it originally was meant for. And that means that if you do screw up one of these machines, if you quote, brick it, but not really, then you can just plug into another machine, could be a Linux machine, doesn't have to be a Mac and hold down some keys, run some commands and then your machine is back to life. You'll notice that I haven't talked about actually writing the driver's part. And that's because people think that's the most important part, but actually the most important parts are everything, these four steps that I have just mentioned. If you can get these things right, actually writing the code sort of comes naturally, right? But if you don't have a good community, if you don't have good tooling, if you don't have a polished user experience, then you're not gonna be able to succeed as a project that is aiming to offer a real OS that people might actually want to use on a machine like this. So, assuming you've followed steps one through four and you've got some hardware support you wanna show off, finally, step five is to just release. You should be prepared for an avalanche of users. I think I spent the first couple of weeks after our first Alpha release, just fixing endless installer bugs or like 16 or 18 releases and things like, oh, it doesn't work on four terabyte systems due to a timeout because the SSD takes longer to come up. There's gonna be crazy stuff that you couldn't foresee. So be aware of that and make sure you get some sleep. But yeah, if you get there, congratulations. That's how you launch a reverse engineering operating system port project. And there you have it. That's the story of how ASAHI Linux came to be. There's still a lot of stuff to do. As I said, we're working on USB three thunderbolt, display port, the speakers, the GPU, so much stuff having. And I'm pretty confident that in the next few months, you know, before the end of the year, we're gonna have a lot more cool stuff to show off. But even so today, it's actually usable as a data driver for a lot of people depending on what you're doing with it. Linus Torvald used it on his trip. And yeah, I hope you enjoy the presentation and if you have a Mac, I hope you give it a try. And I will be taking questions and answers now. So thank you so much for being here. Thank you very much, Hector. Do we have any questions from the audience here? So when will you consider it done? I mean, these things are never done, right? Like they're gonna keep releasing new machines. We're gonna have work cut out for us for a while, I think. But I mean, when is it done? Is really a question for like the individual user, right? Because, you know, if you're just interested in like, you know, browsing using an SSH client, using the CPUs, building stuff and that kind of stuff, it's already good enough for that. You know, if you want not 3D acceleration to run the desktop more smoothly, then that's gonna come a bit later. If, you know, you want sleep mode, that's also coming soon. You know, if you want the neural engine to work, that's probably gonna take longer because there's a lot fewer people interested in that. So yeah, I mean, these things are never done, done, done, right, is all I can say. But I do hope that over time, you know, more or more people consider it done enough that they can just make it their main machine. So it looks like Apple was nice enough to add this unsecure boot mode. Is that something that they can remove at some point and then we are all screwed? I don't think that it's realistic to expect them to remove it from existing machines because, first of all, it would probably be illegal because a certain other company tried that and got sued for it. But, you know, it's also terrible marketing and they actually put a lot of development work into making this possible and they have work from Apple employees that like this is official company policy, right? So technically they could remove it. I don't think that's actually gonna happen. Hi, given that now iPhones and Macs are kind of otherwise quite similar, is there like any reason why you think that like iPhones are super locked down while on Macbooks, you can just unlock them and you can sort whatever you want on them? So I think Apple kind of sees the two product lines as different in some fundamental ways. I don't know exactly what the rationale is for the very different security models that they have, but like there's, you know, Macs have always been open and iPhone devices have always been closed and I guess it's not really about the hardware but it's more about the product line. So I would love to have good policy on an iPad with the M1 because like that would be amazing but yeah, I don't know. I mean, it's kind of a management decision on Apple, right? I don't know what's in their heads. Any other questions? Nothing online as well. So thank you very much Hector. Thank you very much.