[00:00.000 --> 00:15.520]  I'm talking about Fidora Sahi, which is Fidora for Apple Silicon.
[00:15.520 --> 00:16.520]  It's funny.
[00:16.520 --> 00:24.880]  I was in the bar the other night talking with David and Neil about doing this presentation.
[00:24.880 --> 00:32.560]  And I said, yeah, on that Mac Mini, on about one in ten displays, it just doesn't work.
[00:32.560 --> 00:40.200]  So there is a small chance that I arrive on the day and hate you, my output won't work.
[00:40.200 --> 00:43.560]  So yeah, we hit that issue.
[00:43.560 --> 00:50.320]  So I was hoping to do the whole demo directly on the Mac Mini, but we had to go to Plan
[00:50.320 --> 00:52.560]  V on my Chromebook here.
[00:52.560 --> 00:57.400]  But I still got through it, and we'll still do all the Q&A.
[00:57.400 --> 01:06.760]  I was hoping to show you a couple of things live, but yeah, we'll have to shelve that.
[01:06.760 --> 01:11.280]  So yeah, I'm Eric Orton.
[01:11.280 --> 01:12.680]  I work for Red Hat.
[01:12.680 --> 01:14.840]  I work in the automotive org.
[01:14.840 --> 01:21.640]  So that's what I kind of work on.
[01:21.640 --> 01:29.360]  I had a competition, but I have to shelve that because it required the hardware.
[01:29.360 --> 01:30.360]  We'll see.
[01:30.360 --> 01:34.760]  If we have time at the end, I might try and plug in the HDMI one more time.
[01:34.760 --> 01:41.920]  So why do we care about Fidora and Apple Silicon?
[01:41.920 --> 01:50.480]  So Apple released new Android, Apple Silicon devices, I think it was late 2020.
[01:50.480 --> 01:56.040]  And there's actually a shortage of well-upstreamed devices.
[01:56.040 --> 02:01.040]  What's cool about this one is the firmware is unlocked out of the box.
[02:01.040 --> 02:08.160]  So it's actually a feature of the Mac devices to run alternative operating systems.
[02:08.160 --> 02:12.080]  And virtualization is also unlocked in the firmware as well.
[02:12.080 --> 02:14.960]  That's actually a feature I find quite handy.
[02:14.960 --> 02:19.360]  I run KVMs a lot on this Mac Mini.
[02:19.360 --> 02:22.640]  Yeah, and it's pleasantly fast.
[02:22.640 --> 02:29.720]  And I suppose Apple will be known for selling, marketing their hardware as premium, which
[02:29.720 --> 02:38.720]  it is, but it's also great value, great bang for a buck in terms of performance.
[02:38.720 --> 02:39.720]  So why do I care?
[02:39.720 --> 02:40.720]  Why did I get involved?
[02:40.720 --> 02:46.160]  I'm repeating what I said earlier, I work in the Red Hat on the automotive org.
[02:46.160 --> 02:52.320]  The automotive boards are ARM based, so I end up doing quite a bit of work that requires
[02:52.320 --> 02:58.040]  some kind of an ARM environment, and working on the Mac Mini allows me to iterate quickly.
[02:58.040 --> 03:04.640]  And then as a bonus, I learned more about ARM hardware and software implementations
[03:04.640 --> 03:11.400]  and things like kernel space rust and that kind of thing.
[03:11.400 --> 03:12.400]  So these were benchmarks.
[03:12.400 --> 03:14.440]  I did these well over a year ago.
[03:14.440 --> 03:19.280]  I was working a bit, I know it might be quite small and difficult to see.
[03:19.280 --> 03:29.360]  I was working with lib camera at the time, and I just used it as a program to profile
[03:29.360 --> 03:32.880]  different pieces of hardware I had around the house.
[03:32.880 --> 03:38.600]  So it's basically minutes it takes to build lib camera or seconds even.
[03:38.600 --> 03:45.480]  So the bar on the very left is Raspberry Pi 4.
[03:45.480 --> 03:49.760]  The green one is interesting, that was my phone, it was like a mid-range Motorola.
[03:49.760 --> 03:55.280]  I'd like a fedoresh P-Root, it's called, the piece of software.
[03:55.280 --> 03:59.800]  So I'd like a fedora container running on my phone.
[03:59.800 --> 04:01.360]  So that's the green one.
[04:01.360 --> 04:06.880]  The yellow one is also a fedora container running on my phone, but yellow is when my
[04:06.880 --> 04:11.920]  phone is routed, so I can get an extra little bit of performance out of that.
[04:11.920 --> 04:15.760]  That was using Sheroot rather than P-Root.
[04:15.760 --> 04:25.160]  And the yellow is my company-issued laptop, which is like an Intel i7, and the small blue
[04:25.160 --> 04:32.160]  bar at the end is how long it was taking me to build lib camera on my Mac mini.
[04:32.160 --> 04:39.400]  And finally, the orange bar, my company-issued laptop is twice the cost of the Mac mini,
[04:39.400 --> 04:48.920]  so that's kind of going back to, there's great bang for a buck with the Apple device.
[04:48.920 --> 04:57.400]  So what makes the project great, we've really great upstream folk and we collaborate with
[04:57.400 --> 05:00.600]  these quite frequently.
[05:00.600 --> 05:12.680]  So Hector, Alyssa, Sahelina, Dugal, Sven, Mac, and there's many more as well.
[05:12.680 --> 05:18.800]  So we've great downstream folk as well, Neil and Davide are actually here, they're big
[05:18.800 --> 05:22.840]  in the whole fedora ecosystem, they're big contributors.
[05:22.840 --> 05:31.960]  Michelle, Leif Liddy is another guy, helps out quite a bit, and there's many more.
[05:31.960 --> 05:38.240]  So this is another thing that I really love about the Asahi community in general.
[05:38.240 --> 05:43.720]  They have this kind of upstream everything attitude, so like absolutely everything we
[05:43.720 --> 05:49.120]  send to the various upstream projects, if at all possible.
[05:49.120 --> 05:54.960]  And that's one thing, there's various certifications around ARM devices, like Alyssa did just
[05:54.960 --> 05:58.440]  three there, I could find.
[05:58.440 --> 06:04.640]  One is work through a Chromebook, and one is the Red Hat Enterprise Linux certification,
[06:04.640 --> 06:10.560]  and the third is system-ready, but one thing that's in the spirit of all those certifications
[06:10.560 --> 06:13.440]  is upstream everything.
[06:13.440 --> 06:21.120]  And yeah, that's one of the kind of core values we have.
[06:21.120 --> 06:28.560]  And that's actually not as common as you would think with ARM devices, it's almost an exception
[06:28.560 --> 06:37.960]  when absolutely everything gets upstreamed.
[06:37.960 --> 06:45.280]  So in Fedora Asahi, this is a further workflow, so most of the time things will hit upstream
[06:45.280 --> 06:53.560]  first, and then Fedora will package that up, and then the Fedora Asahi remix will use those
[06:53.560 --> 06:59.960]  packages, so that's the common case.
[06:59.960 --> 07:06.880]  We also use this workflow, because sometimes submitting things upstream, it can take a
[07:06.880 --> 07:17.600]  bit of time, so that's a lot of our work as well in the Fedora Asahi community, so sometimes
[07:17.600 --> 07:22.000]  work will be submitted upstream, but it might not be accepted yet.
[07:22.000 --> 07:28.880]  So in Fedora Asahi, we'll take those patches, and we'll fork whatever packages we need to
[07:28.880 --> 07:35.120]  make sure you have the best experience possible while things are still being upstreamed, and
[07:35.120 --> 07:44.000]  eventually that will make its way to Fedora when it gets upstreamed, and yeah, I'm going
[07:44.000 --> 07:50.480]  to explain that further in the next few slides.
[07:50.480 --> 07:57.280]  So yeah, AbsolutelySense is a success when it comes to Fedora Asahi, so ultimately we
[07:57.280 --> 08:02.600]  plan on getting as much as possible into the main Fedora repository, so every time a forked
[08:02.600 --> 08:08.680]  package is obsolete, I would regard that as a success.
[08:08.680 --> 08:13.880]  So what do we fork?
[08:13.880 --> 08:23.440]  We fork Ubooth, that's kind of one I'm kind of expecting could be forked almost forever,
[08:23.440 --> 08:52.200]  because we have some Apple Silicon specific stuff in there, I knocked off my mic, 2 seconds.
[08:52.200 --> 08:59.240]  So we have Ubooth, we have a package we call Kernel, which is our own kernel, it's separate
[08:59.240 --> 09:07.040]  to the normal Fedora kernel, we have another kernel we call Kernel Edge, we fork Mesa,
[09:07.040 --> 09:15.720]  we have this kind of firmware package that Hector and the Med called M1N1, and there's
[09:15.720 --> 09:17.720]  a handful of others.
[09:17.720 --> 09:28.120]  What were the reasons Ubooth is going to be forked?
[09:28.120 --> 09:39.160]  I think we have some flags, build time flags, and we don't have a way of changing how it
[09:39.160 --> 09:43.280]  behaves at runtime yet.
[09:43.280 --> 09:49.520]  I could be wrong, it may not remain forked, the other thing about Fedora as well, we generally
[09:49.520 --> 09:58.240]  try and avoid maintaining firmware and focus on the operating system side, so if you notice
[09:58.240 --> 10:06.800]  our Fedora ARM images, they generally don't get packaged with firmware, we try and avoid
[10:06.800 --> 10:16.240]  getting into maintaining firmware, because I can scale quite badly at the lower level
[10:16.240 --> 10:21.920]  pieces of software.
[10:21.920 --> 10:30.480]  So Fedora kernel, it has Apple Silicon support, it boots, we continually test and enable
[10:30.480 --> 10:40.560]  more kernel cotton figs as support gets propagated upstream, it's built with 4K page size.
[10:40.560 --> 10:49.760]  So that's something interesting in Fedora, we try and just build one kernel per CPU architecture,
[10:49.760 --> 10:57.440]  so at least the way things currently are, we don't build a kernel for 4K, for 16K, 64K,
[10:57.440 --> 11:08.200]  because yeah, against scale, it's easier to maintain one kernel per CPU architecture.
[11:08.200 --> 11:15.840]  So something interesting about this kernel is not everything at the moment is upstream
[11:15.840 --> 11:23.040]  to its support for 4K page size, that's something that's continually in progress and the upstream
[11:23.040 --> 11:32.160]  folks are working on, but hardware is designed to work with 16K page size, so we'll get there.
[11:32.160 --> 11:38.400]  Getting everything working with 16K page size upstream is definitely the priority first.
[11:38.400 --> 11:44.400]  The other thing about 4K page size is you take a performance hit because the hardware
[11:44.400 --> 11:53.000]  is kind of tuned for 16K page size, so that's something to bear in mind.
[11:53.000 --> 12:00.640]  So yeah, the Fedora ASAHI SIG then maintains two kernels and this is the first one, I called
[12:00.640 --> 12:08.440]  it the Fedora ASAHI kernel here and so it uses the Fedora kernel as a base and we didn't
[12:08.440 --> 12:15.720]  add extra yet to be upstream patches from like the ASAHI Linux repos, we enable even
[12:15.720 --> 12:28.760]  more kernel configs, we build with 16K page size and it uses simple DRM, which is software
[12:28.760 --> 12:34.960]  rendered graphics and that's actually surprisingly fast, I'm always amazed at how fast simple
[12:34.960 --> 12:42.840]  DRM is on hardware like this, so if you're interested in Fedora ASAHI from a user perspective
[12:42.840 --> 12:48.480]  I would recommend this kernel or the next kernel I'm going to talk about because just
[12:48.480 --> 12:58.200]  the user experience is a bit better, more things work basically.
[12:58.200 --> 13:03.120]  So this is another kernel we maintain, we create this one not so long ago, just before
[13:03.120 --> 13:12.200]  Christmas, so this uses the Fedora, the last kernel I talked about basically as a base
[13:12.200 --> 13:18.920]  and we add even more patches and we enable even more kernel configs.
[13:18.920 --> 13:26.240]  So it uses accelerated graphics, what I had intended to do for this talk is that we would
[13:26.240 --> 13:32.520]  have a little competition of two people playing SuperDoc's cat just to show off the accelerated
[13:32.520 --> 13:37.760]  graphics but yeah, HDMI issues.
[13:37.760 --> 13:43.120]  So I found this kernel interesting to work with because it's built with the Rust for
[13:43.120 --> 13:54.120]  Linux kernel space port and yet the DSAHI GPU driver is one of the first fully fledged
[13:54.120 --> 13:59.000]  Rust for Linux drivers and it's pretty neat, it works well.
[13:59.000 --> 14:10.720]  And another difference is we build this kernel with Clang LLVM because basically GCC Rust
[14:10.720 --> 14:17.160]  support is a little bit behind so at a minimum you have to build a Rust code with Clang LLVM
[14:17.160 --> 14:22.360]  and I remember playing around with that package at the time and at that point it was just
[14:22.360 --> 14:28.240]  easy to build the whole code base with Clang LLVM including all the C code.
[14:28.240 --> 14:33.120]  But I think it is possible if you kind of want the hybrid builds to build the C code
[14:33.120 --> 14:41.400]  with GCC and the Rust code with Clang LLVM but we switched everything to Clang LLVM at
[14:41.400 --> 14:47.720]  least temporarily because it's easier and we also use a forked method package so that
[14:47.720 --> 14:55.240]  works with the Rust GPU driver.
[14:55.240 --> 15:03.000]  So what's our official release date, Davide, he's here somewhere, I was talking to him
[15:03.000 --> 15:12.800]  before the talk, he's presenting this stuff at scale in March in about a month's time.
[15:12.800 --> 15:20.360]  I hope he has better luck with his CMI output and that kind of thing than me.
[15:20.360 --> 15:26.720]  So yeah, Davide is handling our release so we think we should have an official release
[15:26.720 --> 15:32.320]  out before that.
[15:32.320 --> 15:40.320]  So most of the people working on this are kind of doing it part-time except for the upstream
[15:40.320 --> 15:47.680]  folk, they're more or less, some of them are full-time jobs so we're always welcome
[15:47.680 --> 15:50.720]  and open to have new contributors.
[15:50.720 --> 15:56.480]  So if you're interested to reach out to us on Matrix, Apple, it's actually pretty impressive
[15:56.480 --> 16:02.800]  they seem to be releasing new hardware pretty frequently and every time they release new
[16:02.800 --> 16:10.240]  hardware there's new things to do because every piece of hardware has its own nuances.
[16:10.240 --> 16:14.760]  Like this is something we were talking about in the last month or two, I don't actually
[16:14.760 --> 16:23.880]  have an M2 device so I can't test it personally, but WebKit is basically broken because there's
[16:23.880 --> 16:30.680]  this thing, it's a new feature of Armacam and Arm version 8.5 and it's called branch
[16:30.680 --> 16:38.760]  target identification and basically WebKit, basically someone has to write the code in
[16:38.760 --> 16:44.720]  WebKit to say if BTI do this but nobody has done it.
[16:44.720 --> 16:51.160]  Which is interesting, I remember yesterday at an ampere talk somebody asked a question,
[16:51.160 --> 17:00.040]  can new Arm versions break user space and I didn't want to answer because I wasn't speaking
[17:00.040 --> 17:09.360]  but yes they can sometimes because this is one of those cases.
[17:09.360 --> 17:16.040]  And that's kind of it, I have a couple of links there to our Matrix, our Wiki, our Project
[17:16.040 --> 17:24.120]  Tracker, the upstream, Sahil Linux.org page and this Git and Copper, you'll find some
[17:24.120 --> 17:31.840]  of our PM's in there if you're interested.
[17:31.840 --> 17:36.320]  Yes so that's kind of it, I'll take Q&A now if anyone has questions and answers and if
[17:36.320 --> 17:41.240]  we don't and we have a little bit of time, I might plug in the history, might cable one
[17:41.240 --> 17:50.560]  more time to see if we get very lucky.
[17:50.560 --> 17:59.560]  Still anybody have questions?
[17:59.560 --> 18:04.600]  At the beginning you mentioned that Apple Silicon is well upstreamed on ARM device,
[18:04.600 --> 18:07.320]  what do you mean by being well upstreamed?
[18:07.320 --> 18:09.920]  As in like does it have work to put back into it?
[18:09.920 --> 18:11.160]  Could you repeat the question?
[18:11.160 --> 18:15.560]  In the first slide you said that Apple Silicon is a well upstreamed ARM device, which is
[18:15.560 --> 18:19.080]  why you work on it, what does that mean exactly?
[18:19.080 --> 18:23.920]  So that's all thanks to the upstreamed fork, the Sahil Linux fork.
[18:23.920 --> 18:32.400]  So Hector Martin is the leader of that and he really believes in upstreaming.
[18:32.400 --> 18:40.640]  So like he tries his best, sometimes certain piece of code, yeah he does get difficulty,
[18:40.640 --> 18:45.480]  that's normal, it spends so many subsystems and so many different projects.
[18:45.480 --> 18:49.280]  So the world is top-streamed, absolutely everything.
[18:49.280 --> 18:56.600]  I pointed that out, there are like plenty of ARM SLCs that publish their code, so they
[18:56.600 --> 19:04.640]  like put a Git hub repo out and they'll publish the code there, but they'll never, often they
[19:04.640 --> 19:10.440]  don't code a final hurdle and get it like into Linux history, so like it runs out of
[19:10.440 --> 19:16.400]  the box with Fedora, Debian, Ubuntu, all the various distributions.
[19:16.400 --> 19:21.360]  And that's one of the things I love about the Asahi guys, because they go that extra
[19:21.360 --> 19:27.880]  mile to try and upstream everything, so that's what I meant for that.
[19:27.880 --> 19:38.280]  Hi, you mentioned that you think that might not be upstreamed, would it make sense to
[19:38.280 --> 19:44.440]  have a separate project to create an UEFI layer on top of that, to harmonize Fedora in
[19:44.440 --> 19:45.440]  that way?
[19:45.440 --> 19:56.080]  Yeah, I'll be honest, I did not work on the Ubuntu stuff myself, I think Hector did most
[19:56.080 --> 20:06.360]  of that, he calls it EFI like and not exactly EFI, so that might be the reason why it might
[20:06.360 --> 20:09.760]  remain a fork.
[20:09.760 --> 20:13.520]  To be honest, I work more with the downstream folks, so you'd probably have to talk to the
[20:13.520 --> 20:16.160]  upstream Asahi guys about that.
[20:16.160 --> 20:41.880]  I think it was Hector working on the Ubuntu stuff, but I could be wrong.
[20:41.880 --> 20:46.400]  I'll try and plug in the heads to my...
[20:46.400 --> 20:52.080]  Hi, thanks for the talk, I would like to know how it is to use a new programming language
[20:52.080 --> 21:00.240]  which is Rust in the kernel and in Mesa, is it going to be supported upstream?
[21:00.240 --> 21:04.560]  I think it's amazing, I'm not going to lie to you and say I've written thousands and
[21:04.560 --> 21:15.720]  thousands of lines of Rust, because I haven't, but building it is easy as long as you're
[21:15.720 --> 21:26.280]  applying LLVM at the moment, and I believe GCC started to release Rust support recently,
[21:26.280 --> 21:32.560]  so I expect GCC to get there as well eventually, so building it isn't too bad now.
[21:32.560 --> 21:42.760]  Building it, it works solidly, I've never had any crashes or anything.
[21:42.760 --> 21:51.000]  Hector and all those upstream guys swear by it, they reckon like they got that GPU driver
[21:51.000 --> 21:57.680]  written twice as quickly just by using Rust, and by not having to handle memory management
[21:57.680 --> 22:02.880]  manually always and all these things, and they handle trade races and stuff.
[22:02.880 --> 22:09.280]  I think another reason they chose Rust is I think when Rust engineering the Apple GPU
[22:09.280 --> 22:16.720]  driver I think it was written in C++, so I think it made a little bit easier for them
[22:16.720 --> 22:26.080]  because Rust has some of the features of C++, but they swear by it and they're the guys
[22:26.080 --> 22:38.400]  that actually write the Rust kernel of Hatches not me.
[22:38.400 --> 22:47.080]  Do you see a need or a demand for or use for Apple Silicon to run Linux servers in real
[22:47.080 --> 22:50.880]  scenarios in companies and this kind of stuff?
[22:50.880 --> 22:52.520]  Like in enterprise?
[22:52.520 --> 22:53.520]  Yes.
[22:53.520 --> 23:03.120]  Enterprise is tricky because we're very much a community supported effort and we don't
[23:03.120 --> 23:09.640]  have any, Apple don't really have an issue with us doing this, but we also don't have
[23:09.640 --> 23:20.920]  an official relationship with Apple, so it would be hard to deploy Linux and Apple Silicon
[23:20.920 --> 23:28.640]  in a data center when you don't have support, official support from the hardware manufacturer.
[23:28.640 --> 23:37.640]  So at the moment I don't see that happening, unless Apple all of a sudden are like, yeah,
[23:37.640 --> 23:56.200]  we'll support that configuration like in an enterprise environment, yeah, could happen.
[23:56.200 --> 24:05.680]  Where did the HDMI cable go?
[24:05.680 --> 24:15.680]  I'm just going to plug it in there.
[24:15.680 --> 24:16.680]  Sorry guys.
[24:16.680 --> 24:17.680]  Hi.
[24:17.680 --> 24:22.080]  Sorry, I was just going to wonder, you mentioned that for Uboot you weren't going to push
[24:22.080 --> 24:27.440]  things upstream from your fork, is that a licensing issue, like is it a GPL conflict
[24:27.440 --> 24:31.200]  or something like that or what's the problem?
[24:31.200 --> 24:33.120]  Could you repeat the question a little bit louder?
[24:33.120 --> 24:39.600]  I think earlier you said that for Uboot you would be maintaining a fork, is that a licensing
[24:39.600 --> 24:47.400]  issue, like is there something you can't commit back to Uboot that they wouldn't accept?
[24:47.400 --> 24:57.040]  Yeah, I didn't, again I didn't write the Uboot patches, I'm pretty sure that was Hector.
[24:57.040 --> 25:06.160]  I think it's because it's written in a non-standard way, like he often calls it UEFI-like and
[25:06.160 --> 25:10.920]  I think there's certain hacks he had to do to get it working on Apple Silicon that the
[25:10.920 --> 25:21.640]  maintainers may not accept, but I will repeat, does upstream, the upstream Asahi community,
[25:21.640 --> 25:28.920]  they really care about upstreaming into the real projects be it Linux, kernel, Mesa, etc.
[25:28.920 --> 25:32.920]  So if all possible, I'm sure they will, you know.
[25:32.920 --> 25:41.880]  Sometimes there's just hacks required because it's built around macOS at the end of the
[25:41.880 --> 25:56.280]  day.
[25:56.280 --> 25:59.280]  Some questions?
[25:59.280 --> 26:11.680]  I'll be around for the day, if any of you see a monitor around the campus or whatever
[26:11.680 --> 26:18.040]  and you want to see it in action, we can hook it up and try, I'm all into that.
[26:18.040 --> 26:25.160]  So yeah, it's about, I've seen this happen before, 90% of monitors work, so if you find
[26:25.160 --> 26:32.000]  a random monitor, yeah, we can do it.
[26:32.000 --> 26:34.000]  Okay, so thank you, Eric.
[26:34.000 --> 26:35.000]  Thanks guys, thanks very much.
[26:35.000 --> 26:36.000]  Thank you.
[26:36.000 --> 26:37.000]  Thank you.
[26:37.000 --> 26:38.000]  Thanks, Eric.
[26:38.000 --> 26:39.000]  Thanks, guys.
[26:39.000 --> 27:02.680]  Thanks, Eric.