Thank you for your silence and your full attention. Hi, so I'm Samuel Dior, Samuel Dien-Riel. You might more recognize this avatar than my name, I hope, maybe not. And I work on mobile Linux OS.

What's mobile Linux OS? Mobile Linux OS is a normal Linux distribution for your phone. Well, some conditions may apply. The goals are with integrating an heterogeneous ecosystem, which means different kinds of phones, different line age of phones,

and all of this in one repository. And its goal also is to make full use of the hardware. This means calling SMS data, acceleration, everything. If you can't call from your phone, it's not a phone. It's just a screen.

And then if you can't use internet from your screen, it's just a useless screen. Then it should work like Nix OS and work with Nix OS. I think it's easier to start with some things that I don't aim to do right now, or maybe not ever under the project name.

Like, I don't want to prescribe any kind of graphical environment. So, just like with Nix OS, you're free to choose whatever you want to run, as long as it's packaged, and if it's not, then come and contribute. I don't intend to make it particularly easy to run Android apps, but it's just something that can be done via software,

since there's projects like Endbox that already do this. Then, porting devices to Mainline Linux. I know it's not nice to say that I don't have a goal to port devices to Mainline Linux, but it's Mobile Nix OS that doesn't have this goal, because I think it's a fun side project that's probably going to happen for at least those that I can try it on.

Let's start with some history. In June 2018, that's when I made the first commit, and it's also when I announced the project under this course. In July 2018, I had a second device ported.

This is nice, since this allowed me to check if there were some bad assumptions in there. Some, but not that much. And then, from July to November 2018, I got busy releasing Nix OS, the 1809. Then an uncomfortable long pause.

January 31st, 2019. There was a pause on the discourse from Armin, introducing the NGI0 on the... The pause was on the discourse. So, on January 31st, I wrote and sent an application for a grant.

And the deadline was the 1st of February. So, it didn't take that much time to write up. More on that later. I was selected for second round. This is good.

And in March, I received some questions from NLNet. Turns out, my application was too narrow in scope. They wanted me to expand the scope, thus expanding the grant. So, I did, and after back and forth, the project was accepted.

In April. Then, the more important bit for me, it's that in August 2019, I left my job, and now I'm working full-time on mobile Nix OS. The current state. Right now, we have three devices booting mobile Nix OS,

and I think I didn't hold power long enough on the other. I hate phones. I know it's just way too small to see,

but it's just for flair. There it is. It's booting on two different devices, and those devices, there's the Asus Zenfone 2 laser. It's the one on your left. It's much older than the other devices. The Zenfone 2 laser is pretty much in the first

or maybe second round of AR64 devices for Android. And the Xiaomi Redmi Note 7 is the one on the right, which is fun since it's pretty new. It released, I think, in the beginning of this year, so this allows me to just check that,

okay, this works on both old and new hardware. This is just amazing because it works on old and new hardware. The OnePlus OnePlus 3, I don't have it with me, but this one was just trivial to port. It's probably about in between in terms of age, but about three hours since I received it in the mail,

it was already ported and booting just to the same state as you can see maybe, I hope, probably not on those phones. I have other targets like the Asus CT100. This one is interesting since it's not an Android target. This is a Chrome OS-based tablet.

This allows me to test whether I made assumptions that were only for Android-based, for Qualcomm-based Android devices even, and turns out not much and I added the target, so I've got an example for two different kind of targets. There's the Google Nexus 7 2013.

This one is special since it's the second device I ported it to, but it's not AR64. Since it's not AR64 as with standard Nexus OS since it ends up being a standard Nexus OS system once booted, there's no binary cache, so I did not test stage 2 yet,

but I have strong assumptions that it's going to work once I've got a full build of the stage 2 working, not working, but building. Motorola is at play. This one is not working entirely, but you see there's a DD after work in progress. That's because it's my daily driver. I can't spare the phone for now to test,

so this one is currently yellow, but it might stay yellow just as the Nexus 7. This is because Motorola, they are not alone, has OEMs to do this. They released an AR64 device with a 32-bit ARMv7L user end.

So depending on how access to hardware works, like Wi-Fi and maybe not Wi-Fi, but probably some other hardware, it might not be possible to run a 64-bit system using the proprietary bits. Let's see how it goes. Then there's the Google Pixel 2 XL.

This one is just work in progress since I don't have it on hand anymore, but I was able to get one for a couple of days and just work, and it's almost working. There's just one little bit, and it might be trivial to fix. And AQMUVM. This one is not AR64. It's used mainly to test the system image generation

and check the graphical applications since you don't want to first build for AR64 and then transfer it to your phone, and this takes quite a while. So DVM is for developers to develop applications. So stuff that's currently work in progress,

meaning hacks I'm currently using to make it boot, the kernel is built in and without model support. Built in means it's built into the boot.img file that's flashed to the boot partition. More on that and why it's an issue soon.

And without model support, it's not much of an issue. It's just way easier to start porting when you don't have to bother with module resolution. Is it loading right modules in your custom stage one that you currently can't access via serial since there's no serial access on most phones.

So you always boot the current generation. That's another hack. You can't choose the generation at boot. There's not some of your usual grub or system reboot or anything as a bootloader. It's ABL or ABoot for the Android devices. This means that there is no choice for the generation.

So if you make a small accident with your next OS rebuild switch, you might need to reinstall for now. But that's just for now. And there's limited hardware support, meaning that there's not much of the hardware working.

There's sound lacking, which might not be much of an issue to fix. There's Wi-Fi not working, but everything is known. It's just I've been lacking time to finish working on that. There's no GPU acceleration, but I've got a contribution which might do all that already.

And there's no cellular communications, so no calls, no SMS, no data. And then there is no proper phone interface. What I mean by that is there is no Plasma Mobile or file show. It's just your usual X11 desktop, which, well, it's not made for touch,

even on a real big screen like a tablet. So it's all room for improvement. So let's see how I'm going to improve. I'm going to write documentation. I know it sounds weird, writing documentation, but it's important. So the basic structure, so you know how everything is put together.

Then a porting guide, since currently the only way it works for porting is I try to port to a new device and I see, oh, right, I fixed that on the other device by switching which options, and that's not a great guide. And a list of devices and their status.

Just for, like when you're going on the LAN, HOS website, you've got a list of devices and their status, same thing. And a website tying this all together. I know this is not the fun bit.

I need to work on enhancing the boot process. There's a couple of steps in there. First, selecting a generation. This is quite important. And inside the ADN, the DNA of NixOS, we probably need to KEXEC to another kernel, since switching kernel is not easy,

and ideally I'd like every generation to list which kernel they use exactly and treat the boot IMG just like it was a bootloader. Then there's a strategy for a virtual keyboard during stage one that's needed, since you don't want to break out your full USB keyboard and plug it in through a USB adapter to your phone when you're rebooting it,

since it crashed for whatever reason, maybe not mobile NixOS's fault. Then enhancing the boot progress reporting, since right now it's just an image telling you it's stage one and then another image for stage two. It's probably better if you have some output,

like it's currently doing this thing, this thing, this thing, this thing. All work in progress. Then we need to make more things work, like sound, GPU acceleration, Wi-Fi, and everything cellular. Phone software. This is not about phone environments, it's about telephoning software.

I don't think there is much package in NixOS right now, so just taking time to do this. And then about a phone environment. What I mean by that is just like the E's, WMs, DMs, you all know what this means, then I want you to know that PE means phone environment.

Let's continue with questions I already know you have in your mind and you want to ask me. What do I need to port? What do I need to port? You need first an unlockable bootloader, and also to have an unlockable bootloader. It's not enough to just have one that's unlockable.

And then kernel sources. I did write for SPD port. It's possible without the sources, but it's going to be in uphill battle. How can you help? You can help by porting to new devices. That's like the first way,

it's probably the best way to help since there's so many devices and so many hours in a day. Then you can test with the devices you own. If you already own one of the devices listed previously, or one of the devices that's going to be listed in the future, you can just run it hopefully. Then packaging software.

This could be done without even any mobile phone. With the QEMU VM, some work on some of the parts of the stack, most likely the phone environment, some of the software testing that things work as expected. This can be done without even having a phone that's supported.

Other things you can do to help? Well, talk about it. Not only talk about mobile Linux OS, just forget about it for one minute. It needs to become ingrained in everyone's head, maybe not the normal people, but every geek that has a phone, that it shouldn't be normal to want to run another mobile operating system.

I'm not saying necessarily a new Linux distribution. It should be normal to even want Windows on your phone. You probably don't want it, but it should be normal to want to run whatever you want on your phone. And this is not something that we can fix. It's something that can be fixed most likely by the OEMs,

but even then, most likely by the manufacturers of the CPUs, the system on chips. So let's try and make this an issue that's known, and that, anyways, I most likely will not buy a phone where I can't control the boot process from A to Z,

and another issue, phones where it's easy to brick by accidentally flashing to the wrong partition. I didn't skip anything. This is all something that's to be continued. And now I'm ready for your questions, hopefully.

Ask me anything. We've got some time. Hey, how many phones have you bricked while trying to run this?

Can you repeat, please? How many phones have you broken? None. But it's the easy way. You don't have much risk as long as you don't flash the boot loader, the one bit before Linux. If you only flash the bits on your Android phone where Linux resides,

it's, as far as I know, like 99.99999% safe. I don't want you to come to me when you break a phone, but I think that as long as you don't flash stuff to partitions you shouldn't flash stuff to, it's going to be fine.

I have a question of my own. So you still keep the original kernel in place in the new K exec, or do you even replace the original kernel? Currently, right now, it's building the OEM provided kernels. Why? Well, the reason is simple. Everything already works with that kernel.

The Wi-Fi, the cameras, the sound, everything is supposed to work with this kernel. Then, this kernel could get updated. Some projects already update kernels from Android OEMs. So what I like is that there's always going to be the boot.img kernel

that's going to be a stable one, one that you trust, one that you've built and you know works, and then you're always able to just K exec into a new kernel that might be mainline, hopefully be mainline, and where you're working on porting it

and bettering the whole Linux ecosystem. If I have a Lineage OS device which has all your check marks checked, how much hard work and sweat separates me from booting MixOS Mobile? Days, weeks, months? Your first port may be a week, depending on if you're lucky,

if the phone is trivial to port 2, but when you're using a phone that's already well supported with Lineage OS, in my experience, it's much easier since everything is listed already in the open. Are there phones to port 2?

Our phones, where there's only the OEM source dump and no community yet, like the Redmi Note 7 right here. Fun story, that's my first Xiaomi kernel, first Xiaomi phone, first Xiaomi kernel from their open source kernel release.

It would not boot, not at all. I finally figured it out since during this time some other projects were porting it, and then when I found out which option I was lacking, I searched online what this option was doing, and it's documented in the wiki of the project.

So basically, read the docs. So when you use the kernel sources from the OEMs, can you reuse the Linux builds that we use in X packages, or do you have to write your own build files for that? When a device gets ported to mainline,

then generally it would mean that you can't use a normal kernel, but until then you're going to need to build a kernel specialized for your phone, or maybe a family of phones. Is it the right question that I answered?

So if you're using the OEM's kernel with their modules and drivers, which would support the hardware like LTE, what is the challenge to get those devices working? Can you repeat the end of the question? What's standing between you and supporting the devices like sound and modems?

For porting to mainline, the main issue is that most of the times the OEMs just drop horribly atrocious code to just make it work, so it just can't be ported forward. Sometimes there's also breakage in the kernel APIs, the internal APIs, and it's normal, it's to be expected.

They never said that a kernel API is stable. It's the kernel ABI for user length that is stable. So that's one main issue. And then about just porting to this kernel to work on mobile Linux OS, no issues. That's exactly what we're using. We're using the OEM dumps to get started.

Perhaps one more question. Have you looked at packaging what JOLA have as their UI continuation of the Nokia operating system?

Can you repeat, please? The JOLA operating system, the Sailfish, if you have looked at packaging those things, because I don't think they're going to be extra friendly to packaging outside of their distribution. Currently I'm not working on anything else than a standard GNU Linux distribution,

so it should be possible, just like everything is possible with enough time, to make the whole Sailfish OS build with Nix, but it's more Sailfish OS, even though it's more GNU Linux than Android,

is still like its own OS, like just Loon OS, which is the open source part of web OS, is its own integrated operating system. So just taking bits from them sometimes is harder. So it should be possible, but it's not a current goal due to lack of human power working on the project.

Maybe in the future we will. Any more questions? Would you benefit of us giving you our old phones to make them all work on Nix OS? I would benefit if you were to use your old phone to port it to.

Not only because I'm lazy, but also because you're going to have a phone with mobile Nix OS in your hands, so you're going to be able to test it and maybe file bugs,

or even better, PRs for whatever is missing for you. And the second question would be, for the grant that you got, is it limited to some extent only to you, or is it possible that in the future you might extend your project to have multiple people working on that as well?

If I understood what it is about the grant, I'm not perfectly sure. I could ask people from an LNET that I think are hidden in the room, and they will tell me if it's all right, but I think so. All right, so since there is no microphone, the best thing to do is to write a new proposal,

which means from myself or something like that. Yes, so if you have additional features that you would like to help, which are maybe not as large as the stuff that Samuel is doing right now,

but you can also ask for a fairly small grant to help. Well, that's the question answered. And if you want to do a whole desktop, which would be a larger thing, it's all fine with us.

Well, it was fun presenting to you. Have a nice day. Thank you so much.