 Let's see what that means. I'm quite curious. I haven't been running apps on my desktop. So, welcome then. So, Chashlik, in the beginning, alright, I'm a bird sometimes. Right, my name is Dan Lane, and I've been with KDE for some time now, very nearly a decade. I'm a master's of software construction with some crazy title that didn't fit on my diploma. And over time, I started my involvement in KDE in the Amara community, but since then, I've been working with Caligra, and I've been working with the glue on team. And most recently, I became an employee of Blue Systems, in which capacity I am on this stage today. So, as a base concept of this, I want to explain why Blue Systems is interested in doing something like Chashlik. So, the plasma foam stuff that you've been, that everybody's been very excited about recently, has been all about getting our stuff to work on phones. And getting the sort of the convergence, these are very nice words these days. So, getting our stuff to work on other devices is kind of where we want to be. But obviously, the opposite is also true. So, we want to get stuff that currently runs on phones, all of these apps that are available there. We want to have that also available on desktops, which is the current primary goal of Chashlik. So, it will eventually run on phones, but right now, that's not the prime goal. We will get that, but it will take a little while. So, first of all, now, Android, everyone will tell you, in particular the Linux Foundation will tell you that Linux runs on billions of devices out there. The problem is, they run Android, which technically is Linux, but not really. It's Linux in the sense that there is a kernel. But everything from there and up is different, which is lovely. You have Binder, which is an IPC system, inter-process communication system, which was developed for BIOS, if you remember correctly, which is old but very, very efficient. It is not very popular in security circles because it's basically siphoned directly into the kernel. However, it is now available in the mainline Linux kernel, so we can work around that for now. Then you have Surface Flinger, which is something of an issue in that Surface Flinger is traditionally the way to access the hardware, where we have other ways of doing that on Linux. We have something called Open Drivers, which Android hasn't really worked out yet. And, of course, there's the whole way that Android applications get run, which is through the Dalvik runtime, or the new version, which would be the Android runtime, which is something called Cilic. Basically, the idea is you have the central virtual machine, which contains all of your system processes, and then any application will request a copy of that runtime, and then applications run inside that. Now, the problem. Obviously, there are a lot of applications out there, and we would like those on our systems as well. That's the main issue that I've been talking with some people recently, and they were asking, why are you doing this? Why would we want all of these apps on our perfectly functional Linux desktops when we have all of the content in the Ubuntu repositories, and we have all of the applications in OpenSUSE, and all of these wonderful things? The problem is they're not the things that a lot of people out there want. People want Candy Crush, and that's not really available in there. The problem with being that none of the ones on Android currently run on a normal Linux. You've got a couple of options for doing that right now. There's the Android emulator itself, which requires you to install the Android SDK, and it is terribly awkward to get anything to run inside it, and they're all virtual machines. There's the ACL as well, which is also a virtual machine, and they all come with that weight that a virtual machine comes with. They are emulating a processor, and there's a virtual computer running inside your computer, which, given the nature of a lot of these applications, would potentially not be that much of an issue, but we'd rather not. It's also awkward to do. Then there's the remote run option, which is stuff like advertising and manual, which is basically you put an APK on some server somewhere and they run it for you, so the popular other people's computer issues. Then you've got web browsers. I understand Firefox are working on something similar, so it will run on Firefox OS, but there's the one that was in the press recently called ARC, which basically means you wrap Android applications in something which makes them run on Chrome, but if you don't want to run Chrome, then you can't run that. So what we're doing is taking the Android stack and removing the bits of it that make it really awkward to run on Linux. So we're taking out the OpenGL code. There's a lot of weirdness in that, which means that you can't use the same libraries that exist on Android on Linux, and yeah, it's terribly awkward, but that's why these things take time to get to work. The base concept then is that because this is running Android on a real Linux system, not inside an emulator, not inside a web browser, not on other people's computers or whatever, we have the ability to really deeply integrate stuff, so that's what we want to do as well. And then, of course, surface flinger itself is there. We can't really very easily get rid of that just because there is the possibility of getting rid of surface flinger. If you only run pure Java-based applications in Android, then you can do it. That's what the people in Gentroid have done. Good friends of ours. Well, good work, people. And yes, we work with the Gentroid people. Lovely guys. But surface flinger itself is required for getting anything that's based on the native SDK in Android to run, because they interface directly with surface flinger. We need surface flinger, and what we've done there is that we have ripped out all of the hardware abstraction stuff, and then that hole that was left behind was shaped pretty much like Wayland, so we put Wayland into that. Now, an interesting thing about that is the code that existed there. The code that existed before, people have done things with Wayland and surface flinger and trying to get the two to work together before. The case in point would be the YOLO phone. Salesforce OS is basically doing that. The plasma phone itself is doing that. But what that does is it's putting Wayland on top of surface flinger, which then handles the hardware bits. We don't do that here. We just have to have some EGL surfaces to paint on, which we then get out of Wayland and surface flinger can work with them. It sounds very simple. It's not, unfortunately, but that's the current process. And then we have currently a small application that handles this. Basically, there's a lot of services and things that need to run. This is not a final UI. We'll need to speak with the Visual Design Group once we are a little bit closer to having something that works properly. So, obviously, work in progress there. But the idea is obviously that all of that functionality will be hidden. And the idea is that run an APK button up there is not a run APK button. It's a double click on an APK, install a launchers, application shows up in your menu. And so the idea is to have Android applications, of course, running as full proper citizens on a real normal Linux desktop. So, yeah, that will eventually go away, but right now it's a useful little tool. So, a little demo. Now let's see if I can get this to work. No, it's not working. That's too wrong. There's that controller. And there is Western, which is a Wayland compositor that runs on top of X windows. So, useful little tool for us to do some testing on. Now, I click start all services and a black screen shows up. Now, something I told people sometime on Friday when we finally had a black screen showing up, that is the most exciting black rectangle I've ever seen in my life. Right, so all of the output you can see in the background here is Android running. It's dropping events because there's no touchable windows. There's no application running, so there's no input window. But that is a running Android system. Oh, that is a running Android runtime running on pure Linux. There is no hacks, no changes to Linux itself. It is just Linux, standard user space. One change would be binder, but given binder is now in the mainline kernel, that's not really a hack. But yes, that is... I'm putting a B as interesting as that demo gets. I did my thing though. On account of this whole Wayland thing, I'm switching between Queens as well, so I've lost my shortcuts and I can't type them into the correct window from my scale. Oh, yeah, and now even show up. I've stopped all the services. I'm probably someone with a flappy bird, so I had a flappy bird. Now, what's up next? Now, other than, of course, getting something installed and actually having a flappy bird on screen and being able to play the game and all of the other things that you can do with it. Okay, so my personal goal for this is something a little bit more, I guess, enterprise-y. I have, I'm afraid, not an open form. I have a library passport. It runs BV10, and there is this lovely little application that makes it possible to mirror your messaging system on there, on your desktop, but that only works on Windows, on macOS, and on Android. But, so once we have applications up and running, all of the integration begins to become a point. So we have all of the, it's not just frameworks, there's all the other things as well. As much as possible needs to be done through the FDO specs, all the notifications, and all of that stuff will end up being done through the proper standards, probably using the KDE libraries to provide the functionality. But, yes, so it's all stuff like notifications and contacts, like integrating K-people into Catholic and the task, having the task manager show the Windows, each application rather than just have a single window which contains everything, which is also a problem. Atlas teams in your K-menu, and, yeah, all of these things that make the, that will eventually make the applications run as full citizens, like proper, full, you run an application, an Android application, and you can only tell that there is a difference because, well, it's going to still look like an Android application, but it will run, and it will show your content, it will show itself in the task bar, and you've launched it through the K-menu, and you've, you know, all of that. And then, yes, obviously separate Windows, perhaps. Now, the idea for the controller is to make it a little bit more in essence, I guess, like the, what's that called, the Settings app on Android. It has a lot of detailed statistics for each application. We can't really sensibly filter that into the existing package managers, but as much as possible we want in there, but some things we will need to be, we'll need to have the controller if nothing else for debug purposes, so, yeah, you can't see that because resolution, but, yeah. And then, right now, it's KitKat, and we want to obviously, we want to upgrade that to Android and when that's out, and then so on, N, O, P, whatever, whenever they start coming up. And then people have been asking, oh, but where do I get my APKs? How would I, you know, get all of my applications, all of these many, many thousands of, you know, it's not hundreds of thousands of applications out there. Surely you're not expecting people to go and rip them from Play Store or, you know, whatever. No, the idea is to integrate, again, deep integration into the existing frameworks that we have. There's a wonderful little thing called Moone Discover, which is a sort of centralized application portal for multiple sources. And it's, you know, applications and content, both. So, if we can, but for Froid, I don't expect it would be that much of an issue because it's all open, but the other two might be a little fun. I know that people have done it for Google Play. There is Snap for BB10 and there's a Google Play client type thing for YOLA as well. I think the latter one is even open source, so it should be possible to get at least three apps from Google Play. Amazon, no idea. I don't believe they have an API because this is Amazon. They don't play well with others. Even worse than Google. But, yes, the idea is to integrate as many of the existing stores out there into Moone Discover, potentially, you know, also AppStream, if we can get that to work. And then, obviously, bugs, bugs, bugs, any bugs. And, yeah, once we have all of it done, there's what they're saying about the sound bug content. So, now it's a little bit faster than I expected, but questions? In your phone, if you install something on Linux, would you be able to see it in your phone? Well, in that this is a Linux-based system, the whole thing where you install apps through the Play Store, or the way that, you know, you can go onto the web, like this online device, so on, is a little bit different here. It doesn't quite work like that. That requires the Google services, and that's very specific. But, technically, because we get the APK, I don't see that... Well, it wouldn't be impossible, at least. It's not a... I haven't thought of that one. But, yeah, I can see it working, at least. How do you do something like that? I usually just know that if you go on my phone, I don't talk, so... Oh, well, that would be more a KG Connect thing, I guess. But, yeah, actually, that's a point. Having Shashlik integrating with KG Connect would be really useful. Yeah. Note to yourself. What language is Shashlik from? Shashlik? Well, it does sound orcish, and that would be because I believe it's Russian. It's... Right, so the snack itself... Actually, the Shashlik name is Turkish, I'm told. But the picture I found... The Shashlik picture, that one. That picture says it was Russian. It's sort of that kind of area. I mean, it's a kebab. It's a huge kebab, basically. Sorry. Does anyone here have a cultural connection to Shashlik? There you go. The different architectures and question number two is, is it technically possible to... When the Android model is executed inside the Shashlik, then you can offer the underlying little system for that? Well, yes, you would technically... Well, start from the far end. If I understood the question correctly, you will be able to detect from inside your application if it's running inside Shashlik, because Shashlik has the... The same way you would detect any Android build on any device, you can detect if it's running on an XS5, or you can detect if it's a cyanogen or so on. That information is registered as Shashlik and Shashlik runtime inside the VM. So if you request the version information from Android, it will tell you that it's running on Shashlik. What was the first one? I thought the first question on that was, it's to be made by... Oh, yes, the native stuff. Yes, right. So what we've discovered is that applications which are distributed on the Play Store, at least, will tell you what architectures they're available for. And inside the same APK, you have libraries for all of the different architectures. So, you know, say, Flappy Bird. Again, Flappy Bird has inside the same APK, you have libraries for ARM, two or three different versions of ARM. You've got MIPS, you've got X86, and so on. So it's... That's the thing. Shashlik is not an emulator in the same way that wine is not an emulator. There is no hardware emulation going on here. It's an API that runs directly on top of your local native system. So it's all... If the application lacks its X86 support, it will not run in Shashlik. Technically, I guess it would be possible to do but it's not really in scope at the moment, at least. So, yeah. Let's get the proper sort of system running first and then we're going to get the emulation working. My question is simple. When can I run VLC on Android? Which one? VLC on Android. For VLC, for example, we need SDK, we need NDK, and we need also private NDK APIs. Private is a problem. Not an enormous problem. It's solvable, but right now it's a problem. We supported the VLC in the last month to a code, an ARC, an Android Entertainment Code, and we managed to get a few things on that. There are APIs where you actually need private APIs. Is it possible at some point? It will eventually be possible, but we'll need to... Yeah, we'll need to look at that. Right now it's not out of scope, so to say, but it is not currently possible. Well, yeah. Well, obviously some of the private stuff is bionic. We don't have bionic. We have... Oh, the frameworks stuff. Yes, the frameworks, private stuff, that's all there. Yeah, that actually, yes, that should be possible. We will need to look at it, and that is one of the things that we're working on at the moment. So, yeah, but, yeah. Actually, let me just do this. But, yes, let's talk later. Right now? Okay, so, Plasma Phone. Yeah, someone was going to ask that at some point. Right. So, running it on Plasma Phone at the moment is a problem, because there is already a surface layer on Plasma Phone, because it uses Lepimeras, which speaks to the hardware through a sort of... sort of kind of surface layer. No, you don't use surface layer. Are you sure? There's no surface flinger process running on the phone today. If we can kill the surface flinger on Plasma Phone, then, yes, it will be possible. Basically, the problem is that if you have Lepimeras running with the surface flinger, then the two surface flingers will be fighting over who gets to speak through binder, because it's supposed to be, essentially, a single-term type application. But, yeah, in that case, yes, if there is no surface flinger on the phone, then, yes, we can do it. It'll take some time, because also, right now, it is an x86 project. We will need to add the stuff to Shashvik to get that to work. But, yeah, it should be possible. Is it not just saying things? Yeah. Do you think this kind of thing could upset some application developers? Because it seems like a useful base for, for instance, for creating applications like information, or checking out games, or debugging them, and... Um... Well... Right, so Shashvik is not very useful for that sort of spying on applications type stuff. So I wouldn't think that Shashvik itself would annoy people. The Android emulator itself is much more useful for that, because it has all the debugging tools that are already there, because it's a part of the SDK, and it's supposed to be used for that. So, yeah, I wouldn't think that we would have that issue, at least, on purely on a political level, at least. Important to do devices. Is it a meaning, similarity, that you touch the device... Nope. That's the thing. Because we don't use the hardware extraction stuff, we are just using system libraries. We're using the system EGL, we're using the system OpenGL, everything runs on Mesa. So, and that's, that's really the problem that we have with plotting, we want to touch on all the other libraries-based things to new devices, is that, essentially, you need to modify the libraries to work with the odd quirks that exist in the various drivers. And we don't have that. What we do have, though, is because it is Android, there are some fairly specific requirements to versions of specific libraries. But most of that is something that we can deal with. And it is getting better. As Android gets older, interestingly, they also fix a lot of this sort of hard-coded line-redependency type stuff inside their own code base. So, I have a suspicion that when we do upgrade to Android M, some of that will go away as well. So, let's bring that first. Yeah. So, unmodified Linux or unmodified Linux means my kernel doesn't need binary support? Unmodified Linux means you need to enable that standard option in your kernel. Sorry. Right now, you need Binder, hoping to get rid of that at some point. So, there's a lot of other people, they actually want to get rid of it in Android itself. But they looked at kdbus and found out that kdbus is not an option. So, yeah. But because obviously our requirements are somewhat smaller than what they have. We're not contacting the hardware directly. There's a lot of stuff that we may very well be able to get rid of the Binder dependency. But yes, right now, you need Binder. All right. Thank you then. Thank you.