Classic Applications in a Confined Ecosystem
Price, Larry
Libertine is an application suite for installing and running classicapplications in a confined environment. Using libertine allows us to useeveryday applications which have not been ported over to a new packagingformat or don't work natively with a new display server. Libertine has allowedus to take advantage of classic apps such as Firefox and LibreOffice in UbuntuTouch, a version of Ubuntu for devices based on click packaging andMir/Unity8. Ubuntu developers have recently unveiled snappy, a new kind ofpackaging system which keeps an application confined to a readonly filesystemwith all of its dependencies managed internally. Since migrating applicationsto snaps is a manual process, we've been working on a libertine snap to giveus the ability to use non-snap applications in an all-snaps Ubuntu. This lecture will start with an overview of why libertine is a necessarycomponent for managing and launching deb-based applications on both a classicMir/Unity8 system and a completely confined all-snaps Ubuntu. Then there willbe a review of how libertine works in general through container management andapplication launching. Finally, these topics will come together with anexplanation of the infrastructure required for libertine to operate in an all-snaps environment. There will be light code and tooling examples throughout,as well as a live demonstration of deb-based X applications running in a snapenvironment.
 So, hi everyone, glad you're here too. Thank you, Jordan. Like this slide says my name is Larry Price. I work at Canonical on the new Chinese Kurtz of popular industry software system, the Bluetooth. This afternoon I'm here to talk to you about how we run classical applications that are used by the system. And a good tip. So what do I mean by classical applications? And furthermore, what do I mean by classical applications? Well, so let's start with a little bit of background. My job focuses on the idea of convergence. We're going to say we're going to, on any platform, we're going to have some screen size and computing power. Convergence has great rustic build. A lot of really cool software over the years. Discovering new concepts of security and usability for the future's sake. While we want to take advantage of these new architecture and tool chains where we build, we also want to take advantage of the tremendous build of stable mature software available in the archives. And the reason that software should be seen less to our users. So a classic application in this context is any application that I can currently install with a traditional package manager, which is an after-p-package or a self-resented, and then run using either the terminal or a graphical discovering interface such as Unitybench. These applications are terminal-based for Graph3CGNX11. Their application would be using for years to make our Linux desktop experience complete. And actually, Firefox would be out of this again. And D, like CRID, PNGIS, and many others. With that as an answer, it would never be your Linux desktop instead of every year being your Linux desktop. And those applications have already migrated to new display servers and new packaging systems. This top will be focused on those which have gotten installed in the system. Classic applications were designed to be installed and used in an unconfined ecosystem. The way that applications have been traditionally installed and accessed resources has grown up organically alongside the tooling and other parts of system management. And throughout this process, applications can or must access parts of the system that they are given with access. And malicious software could be used to do on private business and online applications. This is not only a show on desktop where you're likely checking on the machine once a day or so, but also a potential threat to the internet and able devices which are intricately updated or checked for health issues and could be scattered throughout your home. And dependencies are another place where classic applications run into problems. Typically, apps depend on several other packages, and sometimes those packages can inflict with other versions of packages installed by their applications. Worse, sometimes applications need newer version packages that aren't available on the system. Or similar package versions have different patches on different distros. But even applications pull back changes until a newer application version becomes available, which may not be until a distro makes a new release. This could be preventing users from having the best version of a piece of software at any given time. On top of that, we also see an increase in the pollution of our root file system, and this is hard to read. This graphic is a great visualization of the way that the Linux file system looks. But you may notice that it's pretty complicated, and some of these things are a little bit redundant. For instance, this is the contents of WMI Ad Variable. We mean that user-runable binaries that's been used in user-resubmitted games, user-local-ban-assuming games, and any number of God directories in my home directory, as well as the work we're sneaking in in some random user-local-broke event. And similarly, library and data files appear wherever they want. These are the results of bringing out the input on my machine, but I'm not considering this as a complete list. And data directories are just kind of more after they need to be. So to generalize the goal confinement, we want to move away from letting apps lose by each other without print permission, and we want to take back control of our file system, putting these applications in a non-location, and giving each application the appropriate dependencies. Our traditional package manager and definitely the sovereign system to be packaged is over 20 years old and periods the weight of those years on its shoulders. And because of this, we thought it would be best to introduce a new packaging tool chain. So historically, a couple years ago, Canonical announced click packages, which were kind of a solution to this problem. An application package in the click is bundled with any specific dependencies that it needs, and it takes advantage of frameworks to access and share resources that it might need. It also uses AppArmor to create a combined application and specify any security features it needs. Clicks were used to package applications for the initial wrapper. We do touch devices, giving them a little bit of headline. We use devices in brand new, instead of X11, as well as Unity8's display server, which sort of gave us our combined ecosystem. But these tool chains were missing some important features and lack maturity. So fast forwarding to today, we're seeing the emergence of SNAP packaging. Also referred to as SNAPI. SNAPI is essentially another iteration on clicks, doing better version management, so you can application five definitions and new ways to integrate your system resources. You can use SNAP today, I'm monitoring Ubuntu or several other distros. SNAPs will all live in a special boot directory and can be completely confined to an itself-stable channel for unconfined, self-mustable channels, if you must. SNAP apps come bundled with all their connections for locally, meaning that all apps will have the dependencies to need it after it runs for a month. No longer needing to wait on tag-containers to even get to the main distro. SNAPs are automatically updated once a day, taking the pressure off of the user to keep their system up to date. And SNAPs come with the option for delta updates, which means that the toolchain can validate if instead of entire package, potentially making downloads smaller and faster. And as confining is concerned, SNAP apps are relegated to their mutilating use-to-classes and by default, requiring interfaces to be connected to perform system tasks between the display, using audio, and using the network. Instead of using a hybrid or classic environment, in addition to a traditional package manager, we can continue to pull in and use our classic applications while enjoying confinement security in our migrated apps. However, one exciting premise is SNAPs is that they're related to running an all-SNAP environment, which we, I think, call a bit diverse. But this puts in a bind. We can't run classic apps in this all-SNAP environment. Our little classic applications are looking for an unconfined system, and we're looking for the X11 display server. And this all-SNAP environment, no idea of neither. We need a way around this issue to give to its audience its run applications, just like they would in a classic system. So to resolve this, we've been working on a suite of tools, which we call Libertine. A Libertine is a person who acts about more restraint. Libertine is an extreme form of hedonism. Living one's life for pleasure while only thinking of oneself. In a sense, our classic applications are practicing Libertines. And it's our job to pull them back and to more on my standard. These applications need a safe place to go while the rest of the world falls in line, and we provide the safe space as a Linux container. Containers are generally unrecognizable from a traditional Linux desktop experience. A Libertine container has some files that we can work with and binds assistive resource directories to access things like home and some system resources. Internally, we continue to use apps and deep packages to manage our packages, even when the host system is not allowed to use deep package, even if deep package is not installed on the host system. Libertine also connects to a program called XMirror, which allows us to run an X11 window isolated on top of Mirror. Every installation, removal, and system modification is done internally, protecting the outside world from whatever these classic applications may be doing to the host system. In the Libertine suite, as many parts are abstracted away, the underlying implementation of classic windows is best possible. C++ library includes Python launchers and command line interfaces, and tools to control other aspects, like watching XMirror, and to comply with the board. So, we cover a few of these. Again, a little bit of difficulty. This is just JSON, dictionary, arrays, and all the good JSON stuff. So, Libertine uses JSON as a database file. Team and trackable install packages, creating containers, modified bindouts. And we just use this database individually for each user on the system. And using JSON, we found, let's us not handle any database frameworks, which is good for our use, because we can also just ask users for the raw database file and data line, because there are 30 or 40 lines of JSON. And so, the crux of our container management is our Python library. Of course, it contains an abstraction around the database that we just saw, and we have a lot of other applications, but the primary use is to extract away the process to handle different limitations of Libertine containers. Of which we support three types, Jiru, LXC, and LXD. Jiru is a special case. We maintain only a few use-on-devices with kernels to hold to support LXC or LXD. With the Jiru diagram, we use the Thinker-Coning Line tool to use home directory as a shrewd jail from which we'll run all of our commands and applications. And when we run commands within a shrew, we use the tool help keyword. And we'll generally try to run a few on privilege to run that command in our generic shrewd jail, but every now and then we have to run privilege-free commands. And so, we prefer not to use shrewd-premise containers. Except that the deprecator, though, is still useful. But LXC containers have been our preferred containers for most of Libertine's lifetime. LXC combines the kernel C-groups to support isolated namesraces to provide an isolated environment for applications. LXC tools, based on the forest recovery we've run home directory. Oh, no. I forgot to add names. I'm sorry. Sorry, I wasn't as loud as I thought. Thank you. Thank you. Thank you. We're capturing a sound from the camera, but it's just not perfect. Okay, thank you. It's going great. I'm trying to do that. I'm setting up the solution here. I'm setting up the access to home and system directories. I'm setting up. I'm going to see the end grade and show the best of features for the tree. I'm going to go to grade lines to make sure that we can access things like audio and the system. I also hope that the LXC Python would be quite mature and work well for our needs, for instance. This is a code sample showing how we used the LXC container on the patch map to be on our command. And to your Python. The newest shine is back into Libertine as LXC containers. LXC is a new space on top of the LXC implementation. Simplifying container management and tip-on for writing speed and usability improvements as well. Libertine LXC containers are outliers and that we've aimed on the LXC back end to maintain the root file system, but we still maintain locally the user's home directories and the local applications directories. The most important thing about LXC is just like every set of LXC containers, we buy and match up with devices, map the current procedures in the system, and it's also going to be all-cannot. One, I guess, one weird thing about LXC is how we have to set up SedgeRumSedgeUser. SedgeRumSedgeUser is an assistant director for stored files running processes when LXC finish starts. This directory unfortunately is overwritten completely when it starts, so we need to remap it by using sound search, storage scripts. To work around this, we create a custom script and copy it into the container. The script creates missing directories, makes it permission to remap it to LXC. But sure, this is the solution we've ordered. We add the files to the container using the files API which is back there. This is part of the Python by LXC mechanism. But the Python API for LXC is not quite metamorphic, we can use it for all of our use cases. So we use a hybrid solution that you can apply to API and calls it to be open to start processes manually. As an example here, we use the Python API to update those devices. It's just a dictionary, and we use the Python by LXC to create this profile of a dictionary using LXC exception to tell us when there's an error. On the other hand, when we run applications, we have to use KSC-SOL-LATKE open to launch applications because that's the best way for us to run LXC applications in the background while still getting all the outside in the foreground. So we also have these services that are responsible for making sure the container does start and stop appropriately in LXC LXC. This is to help us save battery life so that the container isn't started all the time, and it ensures that when a user stops one container, or stops one application within a container, the container doesn't stop, but we wait for all applications to be closed. Moving on, we use the RUMO binaries. We have a Python binary called the container manager, which allows you to create managed containers and self-active and modify them by amounts. This is a basic overview of using the RUMO binaries in container manager to create a container. It's fairly straightforward. We just call them create something in, with any number of flags, all of which have intelligent defaults, is a priority. So the user doesn't have to know what kind of container they're back and where they're using. Here I've shown that as just a black box, and then it just updates the database and the agile of the file system using the container's back end. And this is similarly just what installing a package would look like. Note that a package name may not line up with the binaries installed, but we're only keeping track of what the user is supposed to be asked to install. Because the purpose of this container manager is to prevent the user from having to deal with the low-level concepts within a particular container type or package management system, and focus on the key concepts of creating an install. We also have a DOS server, and Python has replaced the work being done by the last application we saw. All of those have been fully implemented yet. But many of the commands that we use in the container manager take a very long time to write, and bad things will happen when those things are interrupted. For instance, having D-Pag, which of course will cause the R-TAN-cog broken package to a container system. The other team being to solve that by being a completely asynchronous method, where we use Python threads and send updates to DOS signals. And although we would like to replace the container manager back end with this in the future, we currently just use it to list container ads and application ideas. Now, which brings us to LiveLiberTeen, which is the root of disturbing container information for several external libraries. It's currently a wrapper around a client for LibertyD. And many of the low-level ads libraries that access Liberty are written in C++. And LibertyD is a convenient way to access Liberty information without having to talk directly to D-Lis. The code sample in here is just by taking out a simple D-Must call from C++. We also have a GUI written in C++ with QML. This is an easy way for us to manage containers and even on a less technical use field, easily manage containers and install packages. It's mostly a series of lists showing you how you can do it in a list of containers in which you could do the list of packages. For the most part, functionality GUI is the same as it is in the main library. There's the mainline tool. And now the real neat is Liberty Launch, which is the Python tool that we use to actually launch applications. But at Liberty Launch, we do use kind of the environment for running ads, and in four of that environments, the container implementation actually running application. Liberty Launch is maternal, but we generally prefer to use a new A8 we use with the Dread Launch. K-Steak is a demon. It's a conveying binary to help applications use the board. We just use key signals and slots to wait for copy and paste events from the underlying combo hub, and then we forward those events to our excellent ads. And doing this, we can use copy and paste pretty much like we would in these applications on our desktop. So what actually happens when we launch applications to Liberty? Well, if we look at our desktop icon, we'll call Liberty Launch with a container ID and application exact line, which is probably found using Liberty Team, which found that information actually in Liberty Beach. Liberty Launch will then start utilities, like pastes and X-Mere. It'll set up a session by coming at the environment and setting up a whole bunch of sockets and then it will launch a container instance based on the Python library, which will then do any number of things based on the container type. They'll buy an outs, launch a window manager to connect to a dimensions of X, and finally launch the app. And that's most of the full picture. To review the container, you want to look at the features, and you set it up to install applications through app. Even when app is not a system, Liberty keeps your container and it's possible to get it on the root file system in a small whole loop of it to let them access things like the home directory and the resource directory. At which point something or someone can launch with an application pilot to launch. They go prepare the container environment near the host, set a window manager, and set a container connected to the host display variable and launch applications. You might all know that. Where can we actually use Liberty? The answer is well, in most of our modern and future systems. Liberty 7 is the current people that stop the session and they do too. And using Liberty in Liberty 7 is a little bit silly because Liberty 7 is not in a planned environment. Already run there's 11. And already installed packages to be packaged. But I think we're noting that we can use Liberty just as well here and where there are a lot of users to run their applications and apply the container without looking up their host system. If Liberty 7 is already running at 11, Liberty 7 is a classic app that can use the running X server to connect to their window manager. So we don't need any special tools for that. And because Unity 7 is not a target platform, applications in the containers are automatically discovered by the Unity Dash. So you can jump through some loops to give them a show up, either by writing some vital desktop files or by manually launching Liberty Launch. Alright, so Unity 8 is a new version of Unity 7. Running Mirrors is a display server instead of X and pre-installed in the new system. Desktop Unity 8 is also not very fairly defined, but running Mirrors instead of X will be able to do some of our previous security things. In Mirrors Unity 8, you can run some applications natively such as modern QDats, but are I able to run an all-around class F natively just yet? And Liberty works well in Unity 8. And it's built into the application discovery logic. That's in here, just for being a sense, come up. The guy I kind of thought was in the past, he had the ring Liberty Launch just as we normally would. Except in this case, there's no X11. So the system also started in the sense of XMirror to put their four applications to a Tetris window manager too. XMirror allows us to run the X11 apps on an excellent window on top of Mirror. Each running a Liberty Launch application will get its own XMirror. So we're running our own communication between the apps. And with this done, we successfully launched XApps in an Onyx environment. So similarly, we would be touch, we would be touch also in Unity 8 in here, and it will can't run across apps on its own. Furthermore, users would prevent using apps to deep-exchange install apps due to the testing and running<|el|><|translate|> of the system by default. So we even asked that would work in a best-of-year sessions, attend the reading of a System. You can see we can create one large package file. We need to update the padding environment and variables to be more flexible for SNAPs. And we need to make some architectural changes to the lower team and lower team being. SNAPs also encourage us to hurry the production of our let's see thing go back in, because we'd let's see SNAP available that we can use. In order to access resources and SNAPs, you have to connect to the interfaces, and we connect to quite a few. This is a short list currently that we use. Lexi, obviously, the Metro Lexi. Now we can network by, connect to SOCAs, to the network, home, connect to the use home directories, and all the rest of your sound and graphics. OK. Live demo. This never looks great. Well, in Plot Twist, I've been running this presentation in Firefox, running a leveraging container in SNAP the whole time. So it works. But I'm not interested in the other applications real quick. Something like X911. More to come up. That's not too loud. And we can say, Firefox, and you can see the command of being run within the container. And this is running completely isolated in its own root file system, completely separate from the host. And what else? Let's see. Do we run something like LeapPad, Edit Documents? Like, I opened something that already exists. Test file. And it all stays fine. And it doesn't crash, which is good. So we'll open that up. And one more. How about some minus fever? And there. Well, pretty good. We've got some under it. This is on Unity 8? This is all on Unity 8, yeah. So yeah. To be clear, this is, everything's running on Unity 8. Everything is in SNAP, running LXD containers. And with that, we can go ahead and pick up. Oh, wrong. Can you lower that? To very quickly review, we wanted to be able to run classic desktop applications in a fully confined, I mean, fully confined, an ex-less ecosystem, in a package format. And we used Liberty to do just that, mostly through LXD containers. And there's a bit of a weird degree in the back end in SNAPs. And we have this working on a lot of our modern machines. There's obviously a lot that we're still working on. All of these things, Unity 8 near Android, seeing it in SNAP, tomorrow, moving in to Milo, and then in development wise, they're also still working. Like, they're in a couple with a lot of apps that you can do with us. Our SNAP is just big. I recently, I mean, think I might have made a regression where audio doesn't work in the SNAP. But that's called working too hard on that demo. And that's it for me. Yeah, good. I think that's all my content information. It might be out of time. Right on time. So I asked, I was to set up a running card that says how to question us, but they will be recorded. Because the recording is kind of in the mail. There. So that's a really good question. So are there any questions? Yes. What will be after running the state premiere? So there's one pre-review today? Right. So the system is made up so that you could create a container that you want. And then our underlying back menu will know which container he is being. Which container is the right one to run on a patient hand. All of these are right in the same place. And so if you want to. I thought, guess what you said, people, that it was like in one application, or if you're right, it's the three-point that you have to use. You can't do that on separate teams. Right. So they all run. So we work around a problem that's moving on each other. So we're up. Does anyone have, it's the event of each year that we come over? Yeah. So we come in the apps around talking to each other through X11 by using an individual instance of Xmer. Or, and I think you can do it. And so each application will have its own Xmer that it's running on. But they can still talk to the same cloud system. Yes. We're hopefully going to. No comment. Although I'm saying it's nice to have a diverse ecosystem of new display servers and a pack of new formats on that horizon. Anyone else? Okay. Thank you. Thank you.
 So, hi everyone, glad you're here too.  Thank you, Jordan.  Like this slide says my name is Larry Price.  I work at Canonical on the new Chinese Kurtz of popular  industry software system, the Bluetooth.  This afternoon I'm here to talk to you about how we run  classical applications that are used by the system.  And a good tip.  So what do I mean by classical applications?  And furthermore, what do I mean by classical applications?  Well, so let's start with a little bit of background.  My job focuses on the idea of convergence.  We're going to say we're going to, on any platform,  we're going to have some screen size and computing power.  Convergence has great rustic build.  A lot of really cool software over the years.  Discovering new concepts of security and usability  for the future's sake.  While we want to take advantage of these new architecture  and tool chains where we build, we also want to take advantage  of the tremendous build of stable mature software  available in the archives.  And the reason that software should be seen less to our  users.  So a classic application in this context is any application  that I can currently install with a traditional package  manager, which is an after-p-package or a self-resented,  and then run using either the terminal or a graphical  discovering interface such as Unitybench.  These applications are terminal-based for Graph3CGNX11.  Their application would be using for years to make our Linux  desktop experience complete.  And actually, Firefox would be out of this again.  And D, like CRID, PNGIS, and many others.  With that as an answer, it would never be your Linux desktop  instead of every year being your Linux desktop.  And those applications have already migrated to new  display servers and new packaging systems.  This top will be focused on those which have gotten  installed in the system.  Classic applications were designed to be installed and used  in an unconfined ecosystem.  The way that applications have been traditionally installed  and accessed resources has grown up organically alongside  the tooling and other parts of system management.  And throughout this process, applications can or must  access parts of the system that they are given with access.  And malicious software could be used to do on private business  and online applications.  This is not only a show on desktop where you're likely  checking on the machine once a day or so,  but also a potential threat to the internet and able devices  which are intricately updated or checked for health issues  and could be scattered throughout your home.  And dependencies are another place where classic applications  run into problems.  Typically, apps depend on several other packages,  and sometimes those packages can inflict with other versions  of packages installed by their applications.  Worse, sometimes applications need newer version packages  that aren't available on the system.  Or similar package versions have different patches  on different distros.  But even applications pull back changes until a newer application  version becomes available, which may not be until a distro  makes a new release.  This could be preventing users from having the best version  of a piece of software at any given time.  On top of that, we also see an increase in the pollution  of our root file system, and this is hard to read.  This graphic is a great visualization of the way  that the Linux file system looks.  But you may notice that it's pretty complicated,  and some of these things are a little bit redundant.  For instance, this is the contents of WMI Ad Variable.  We mean that user-runable binaries that's been used  in user-resubmitted games, user-local-ban-assuming games,  and any number of God directories in my home directory,  as well as the work we're sneaking in  in some random user-local-broke event.  And similarly, library and data files appear wherever they want.  These are the results of bringing out the input on my machine,  but I'm not considering this as a complete list.  And data directories are just kind of more after they need to be.  So to generalize the goal confinement,  we want to move away from letting apps lose by each other  without print permission, and we want to take back control  of our file system, putting these applications in a non-location,  and giving each application the appropriate dependencies.  Our traditional package manager and definitely  the sovereign system to be packaged is over 20 years old  and periods the weight of those years on its shoulders.  And because of this, we thought it would be best  to introduce a new packaging tool chain.  So historically, a couple years ago,  Canonical announced click packages,  which were kind of a solution to this problem.  An application package in the click is bundled with any specific dependencies  that it needs, and it takes advantage of frameworks  to access and share resources that it might need.  It also uses AppArmor to create a combined application  and specify any security features it needs.  Clicks were used to package applications  for the initial wrapper.  We do touch devices, giving them a little bit of headline.  We use devices in brand new, instead of X11,  as well as Unity8's display server,  which sort of gave us our combined ecosystem.  But these tool chains were missing some important features  and lack maturity.  So fast forwarding to today,  we're seeing the emergence of SNAP packaging.  Also referred to as SNAPI.  SNAPI is essentially another iteration on clicks,  doing better version management,  so you can application five definitions  and new ways to integrate your system resources.  You can use SNAP today, I'm monitoring Ubuntu  or several other distros.  SNAPs will all live in a special boot directory  and can be completely confined to an itself-stable channel  for unconfined, self-mustable channels, if you must.  SNAP apps come bundled with all their connections  for locally, meaning that all apps will have  the dependencies to need it after it runs for a month.  No longer needing to wait on tag-containers  to even get to the main distro.  SNAPs are automatically updated once a day,  taking the pressure off of the user to keep their system up to date.  And SNAPs come with the option for delta updates,  which means that the toolchain can validate  if instead of entire package, potentially  making downloads smaller and faster.  And as confining is concerned,  SNAP apps are relegated to their mutilating  use-to-classes and by default,  requiring interfaces to be connected  to perform system tasks between the display,  using audio, and using the network.  Instead of using a hybrid or classic environment,  in addition to a traditional package manager,  we can continue to pull in and use our classic applications  while enjoying confinement security in our migrated apps.  However, one exciting premise is SNAPs  is that they're related to running an all-SNAP environment,  which we, I think, call a bit diverse.  But this puts in a bind.  We can't run classic apps in this all-SNAP environment.  Our little classic applications are looking for  an unconfined system, and we're looking  for the X11 display server.  And this all-SNAP environment,  no idea of neither.  We need a way around this issue  to give to its audience its run applications,  just like they would in a classic system.  So to resolve this,  we've been working on a suite of tools,  which we call Libertine.  A Libertine is a person who acts about more restraint.  Libertine is an extreme form of hedonism.  Living one's life for pleasure while only thinking of oneself.  In a sense, our classic applications are practicing Libertines.  And it's our job to pull them back  and to more on my standard.  These applications need a safe place to go while  the rest of the world falls in line,  and we provide the safe space as a Linux container.  Containers are generally unrecognizable  from a traditional Linux desktop experience.  A Libertine container has some files that we can work with  and binds assistive resource directories  to access things like home and some system resources.  Internally, we continue to use apps and deep packages  to manage our packages,  even when the host system is not allowed to use deep package,  even if deep package is not installed on the host system.  Libertine also connects to a program called XMirror,  which allows us to run an X11 window  isolated on top of Mirror.  Every installation, removal, and system modification  is done internally,  protecting the outside world from whatever these  classic applications may be doing to the host system.  In the Libertine suite,  as many parts are abstracted away,  the underlying implementation of classic windows  is best possible.  C++ library includes Python launchers  and command line interfaces,  and tools to control other aspects,  like watching XMirror,  and to comply with the board.  So, we cover a few of these.  Again, a little bit of difficulty.  This is just JSON, dictionary, arrays,  and all the good JSON stuff.  So, Libertine uses JSON as a database file.  Team and trackable install packages,  creating containers,  modified bindouts.  And we just use this database  individually for each user on the system.  And using JSON, we found,  let's us not handle any database frameworks,  which is good for our use,  because we can also just ask users  for the raw database file and data line,  because there are 30 or 40 lines of JSON.  And so, the crux of our container management  is our Python library.  Of course, it contains an abstraction  around the database that we just saw,  and we have a lot of other applications,  but the primary use is to extract away the process  to handle different limitations of Libertine containers.  Of which we support three types,  Jiru, LXC, and LXD.  Jiru is a special case.  We maintain only a few use-on-devices  with kernels to hold to support LXC or LXD.  With the Jiru diagram,  we use the Thinker-Coning Line tool  to use home directory as a shrewd jail  from which we'll run all of our commands and applications.  And when we run commands within a shrew,  we use the tool help keyword.  And we'll generally try to run a few on privilege  to run that command in our generic shrewd jail,  but every now and then we have to run privilege-free commands.  And so, we prefer not to use shrewd-premise containers.  Except that the deprecator, though, is still useful.  But LXC containers have been our preferred containers  for most of Libertine's lifetime.  LXC combines the kernel C-groups  to support isolated namesraces  to provide an isolated environment for applications.  LXC tools, based on the forest recovery  we've run home directory.  Oh, no. I forgot to add names.  I'm sorry.  Sorry, I wasn't as loud as I thought.  Thank you.  Thank you.  Thank you.  We're capturing a sound from the camera,  but it's just not perfect.  Okay, thank you.  It's going great. I'm trying to do that.  I'm setting up the solution here.  I'm setting up the access to home and system directories.  I'm setting up.  I'm going to see the end grade  and show the best of features for the tree.  I'm going to go to grade lines to make sure  that we can access things like audio and the system.  I also hope that the LXC Python  would be quite mature  and work well for our needs, for instance.  This is a code sample showing how we used  the LXC container on the patch map  to be on our command.  And to your Python.  The newest shine is back into Libertine  as LXC containers.  LXC is a new space on top of the LXC implementation.  Simplifying container management and tip-on  for writing speed and usability improvements as well.  Libertine LXC containers are outliers  and that we've aimed on the LXC back end  to maintain the root file system,  but we still maintain locally  the user's home directories  and the local applications directories.  The most important thing about LXC  is just like every set of LXC containers,  we buy and match up with devices,  map the current procedures in the system,  and it's also going to be all-cannot.  One, I guess, one weird thing about LXC  is how we have to set up  SedgeRumSedgeUser.  SedgeRumSedgeUser is an assistant director  for stored files running processes  when LXC finish starts.  This directory unfortunately is overwritten  completely when it starts,  so we need to remap it  by using sound search,  storage scripts.  To work around this,  we create a custom script  and copy it into the container.  The script creates missing directories,  makes it permission to remap it  to LXC.  But sure, this is the solution we've ordered.  We add the files to the container  using the files API  which is back there.  This is part of the Python by LXC mechanism.  But the Python API for LXC  is not quite metamorphic,  we can use it for all of our use cases.  So we use a hybrid solution  that you can apply to API  and calls it to be open  to start processes manually.  As an example here,  we use the Python API  to update those devices.  It's just a dictionary,  and we use the Python by LXC  to create this profile  of a dictionary  using LXC exception to tell us  when there's an error.  On the other hand,  when we run applications,  we have to use  KSC-SOL-LATKE  open to launch applications  because that's the best way  for us to run LXC applications  in the background  while still getting all the outside  in the foreground.  So we also have these services  that are responsible for making sure  the container does start and stop  appropriately in LXC LXC.  This is to help us save battery life  so that the container  isn't started all the time,  and it ensures that when a user stops  one container,  or stops one application  within a container,  the container doesn't stop,  but we wait for all applications  to be closed.  Moving on, we use the RUMO binaries.  We have a Python binary  called the container manager,  which allows you to  create managed containers  and self-active  and modify them by amounts.  This is a basic overview  of using the RUMO binaries  in container manager  to create a container.  It's fairly straightforward.  We just call them  create something in,  with any number of flags,  all of which have intelligent defaults,  is a priority.  So the user doesn't have to know  what kind of container  they're back and where they're using.  Here I've shown that as just a black box,  and then it just updates the  database and the agile  of the file system using the  container's back end.  And this is similarly just  what installing a package would look like.  Note that a package name may not line up  with the binaries installed,  but we're only keeping track of what the user  is supposed to be asked to install.  Because the purpose of this  container manager is to prevent the user  from having to deal with the low-level concepts  within a particular container type  or package management system,  and focus on the key concepts  of creating an install.  We also have a DOS server,  and Python has replaced the work being done  by the last application we saw.  All of those have been fully implemented yet.  But many of the commands that we use  in the container manager take a very long time to write,  and bad things will happen when those things are interrupted.  For instance, having D-Pag, which of course  will cause the R-TAN-cog broken package  to a container system.  The other team being to solve that  by being a completely asynchronous method,  where we use Python threads and send updates  to DOS signals.  And although we would like to replace  the container manager back end with this in the future,  we currently just use it to list container ads  and application ideas.  Now, which brings us to LiveLiberTeen,  which is the root of  disturbing container information  for several external libraries.  It's currently a wrapper around a client for LibertyD.  And many of the low-level ads libraries  that access Liberty are written in C++.  And LibertyD is a convenient way  to access Liberty information  without having to talk directly to D-Lis.  The code sample in here is just  by taking out a simple D-Must call from C++.  We also have a GUI written in C++  with QML.  This is an easy way for us to manage containers  and even on a less technical use field,  easily manage containers and install packages.  It's mostly a series of lists  showing you how you can do it in a list of containers  in which you could do the list of packages.  For the most part, functionality GUI  is the same as it is in the main library.  There's the mainline tool.  And now the real neat is Liberty Launch,  which is the Python tool  that we use to actually launch applications.  But at Liberty Launch, we do use  kind of the environment for running ads,  and in four of that environments,  the container implementation  actually running application.  Liberty Launch is maternal,  but we generally prefer to use  a new A8 we use with the Dread Launch.  K-Steak is a demon.  It's a conveying binary to help applications  use the board.  We just use key signals and slots  to wait for copy and paste events  from the underlying combo hub,  and then we forward those events  to our excellent ads.  And doing this, we can use copy and paste  pretty much like we would  in these applications  on our desktop.  So what actually happens when we launch  applications to Liberty?  Well, if we look at our desktop icon,  we'll call Liberty Launch with a container ID  and application exact line,  which is probably found using Liberty Team,  which found that information actually in Liberty Beach.  Liberty Launch will then start utilities,  like pastes and X-Mere.  It'll set up a session by coming at the environment  and setting up a whole bunch of sockets  and then it will launch a container instance  based on the Python library,  which will then do any number of things  based on the container type.  They'll buy an outs, launch a window manager  to connect to a dimensions of X,  and finally launch the app.  And that's most of the full picture.  To review the container,  you want to look at the features,  and you set it up to install applications through app.  Even when app is not a system,  Liberty keeps your container  and it's possible to get it on the root file system  in a small whole loop of it  to let them access things like the home directory  and the resource directory.  At which point something or someone  can launch with an application pilot to launch.  They go prepare the container environment  near the host, set a window manager,  and set a container connected to the host display variable  and launch applications.  You might all know that.  Where can we actually use Liberty?  The answer is well,  in most of our modern and future systems.  Liberty 7 is the current people  that stop the session and they do too.  And using Liberty in Liberty 7  is a little bit silly  because Liberty 7 is not in a planned environment.  Already run there's 11.  And already installed packages to be packaged.  But I think we're noting that we can use Liberty  just as well here  and where there are a lot of users to run their applications  and apply the container  without looking up their host system.  If Liberty 7 is already running at 11,  Liberty 7 is a classic app  that can use the running X server to connect to their window manager.  So we don't need any special tools for that.  And because Unity 7 is not a target platform,  applications in the containers  are automatically discovered by the Unity Dash.  So you can jump through some loops  to give them a show up,  either by writing some vital desktop files  or by manually launching Liberty Launch.  Alright, so Unity 8 is a new version of Unity 7.  Running Mirrors is a display server instead of X  and pre-installed in the new system.  Desktop Unity 8 is also not very fairly defined,  but running Mirrors instead of X  will be able to do some of our previous security things.  In Mirrors Unity 8, you can run some applications  natively such as modern QDats,  but are I able to run an all-around class F natively just yet?  And Liberty works well in Unity 8.  And it's built into the application discovery logic.  That's in here, just for being a sense, come up.  The guy I kind of thought was in the past,  he had the ring Liberty Launch just as we normally would.  Except in this case, there's no X11.  So the system also started in the sense of XMirror  to put their four applications to a Tetris window manager too.  XMirror allows us to run the X11 apps  on an excellent window on top of Mirror.  Each running a Liberty Launch application  will get its own XMirror.  So we're running our own communication between the apps.  And with this done, we successfully launched  XApps in an Onyx environment.  So similarly, we would be touch,  we would be touch also in Unity 8 in here,  and it will can't run across apps on its own.  Furthermore, users would prevent using apps  to deep-exchange install apps  due to the testing and running  of the system by default.  So we even asked that would work in a best-of-year  sessions,  attend the reading of a System.  You can see we can create one large package file.  We need to update the padding environment and variables  to be more flexible for SNAPs.  And we need to make some architectural changes  to the lower team and lower team being.  SNAPs also encourage us to hurry the production of our  let's see thing go back in, because we'd  let's see SNAP available that we can use.  In order to access resources and SNAPs,  you have to connect to the interfaces,  and we connect to quite a few.  This is a short list currently that we use.  Lexi, obviously, the Metro Lexi.  Now we can network by, connect to SOCAs,  to the network, home, connect to the use home directories,  and all the rest of your sound and graphics.  OK.  Live demo.  This never looks great.  Well, in Plot Twist, I've been running this presentation  in Firefox, running a leveraging container in SNAP  the whole time.  So it works.  But I'm not interested in the other applications  real quick.  Something like X911.  More to come up.  That's not too loud.  And we can say, Firefox, and you can see the command  of being run within the container.  And this is running completely isolated in its own root file  system, completely separate from the host.  And what else?  Let's see.  Do we run something like LeapPad, Edit Documents?  Like, I opened something that already exists.  Test file.  And it all stays fine.  And it doesn't crash, which is good.  So we'll open that up.  And one more.  How about some minus fever?  And there.  Well, pretty good.  We've got some under it.  This is on Unity 8?  This is all on Unity 8, yeah.  So yeah.  To be clear, this is, everything's running on Unity 8.  Everything is in SNAP, running LXD containers.  And with that, we can go ahead and pick up.  Oh, wrong.  Can you lower that?  To very quickly review, we wanted  to be able to run classic desktop applications  in a fully confined, I mean, fully confined,  an ex-less ecosystem, in a package format.  And we used Liberty to do just that, mostly through LXD  containers.  And there's a bit of a weird degree in the back end in SNAPs.  And we have this working on a lot of our modern machines.  There's obviously a lot that we're still working on.  All of these things, Unity 8 near Android,  seeing it in SNAP, tomorrow, moving in to Milo,  and then in development wise, they're also still working.  Like, they're in a couple with a lot of apps that you can do  with us.  Our SNAP is just big.  I recently, I mean, think I might have made a regression  where audio doesn't work in the SNAP.  But that's called working too hard on that demo.  And that's it for me.  Yeah, good.  I think that's all my content information.  It might be out of time.  Right on time.  So I asked, I was to set up a running  card that says how to question us, but they  will be recorded.  Because the recording is kind of in the mail.  There.  So that's a really good question.  So are there any questions?  Yes.  What will be after running the state premiere?  So there's one pre-review today?  Right.  So the system is made up so that you could create a container  that you want.  And then our underlying back menu will know which container  he is being.  Which container is the right one to run on a patient hand.  All of these are right in the same place.  And so if you want to.  I thought, guess what you said, people,  that it was like in one application,  or if you're right, it's the three-point  that you have to use.  You can't do that on separate teams.  Right.  So they all run.  So we work around a problem that's  moving on each other.  So we're up.  Does anyone have, it's the event of each year  that we come over?  Yeah.  So we come in the apps around talking to each other through  X11 by using an individual instance of Xmer.  Or, and I think you can do it.  And so each application will have its own Xmer that it's running  on.  But they can still talk to the same cloud system.  Yes.  We're hopefully going to.  No comment.  Although I'm saying it's nice to have a diverse ecosystem  of new display servers and a pack of new formats on that  horizon.  Anyone else?  Okay.  Thank you.  Thank you.
Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__0_47.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__48_107.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__108_779.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__780_1031.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__1032_2183.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__2184_3263.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__3264_3455.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__3456_5687.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__5688_6287.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__6288_6407.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__6408_7523.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__7524_8831.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__8832_11759.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__11760_16007.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__16008_18947.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__18948_22943.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__22944_24947.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__24948_26759.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__26760_28739.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__28740_34223.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__34224_35687.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__35688_37367.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__37368_37595.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__37596_37643.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__37644_37775.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__37776_37823.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__37824_37931.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__37932_38339.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__38340_38423.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__38424_38483.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__38484_38711.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__38712_38807.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__38808_38891.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__38892_39083.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__39084_39395.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__39396_39503.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__39504_39611.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__39612_43655.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__43656_44279.png Classic_Applications_in_a_Confined_Ecosystem_Using_libertine_to_run_debpackaged_X11__44280_44417.png
So, hi everyone, glad you're here too. Thank you, Jordan. Like this slide says my name is Larry Price. I work at Canonical on the new Chinese Kurtz of popular industry software system, the Bluetooth. This afternoon I'm here to talk to you about how we run classical applications that are used by the system. And a good tip. So what do I mean by classical applications? And furthermore, what do I mean by classical applications? Well, so let's start with a little bit of background. My job focuses on the idea of convergence. We're going to say we're going to, on any platform, we're going to have some screen size and computing power. Convergence has great rustic build. A lot of really cool software over the years. Discovering new concepts of security and usability for the future's sake. While we want to take advantage of these new architecture and tool chains where we build, we also want to take advantage of the tremendous build of stable mature software available in the archives. And the reason that software should be seen less to our users. So a classic application in this context is any application that I can currently install with a traditional package manager, which is an after-p-package or a self-resented, and then run using either the terminal or a graphical discovering interface such as Unitybench. These applications are terminal-based for Graph3CGNX11. Their application would be using for years to make our Linux desktop experience complete. And actually, Firefox would be out of this again. And D, like CRID, PNGIS, and many others. With that as an answer, it would never be your Linux desktop instead of every year being your Linux desktop. And those applications have already migrated to new display servers and new packaging systems. This top will be focused on those which have gotten installed in the system. Classic applications were designed to be installed and used in an unconfined ecosystem. The way that applications have been traditionally installed and accessed resources has grown up organically alongside the tooling and other parts of system management. And throughout this process, applications can or must access parts of the system that they are given with access. And malicious software could be used to do on private business and online applications. This is not only a show on desktop where you're likely checking on the machine once a day or so, but also a potential threat to the internet and able devices which are intricately updated or checked for health issues and could be scattered throughout your home. And dependencies are another place where classic applications run into problems. Typically, apps depend on several other packages, and sometimes those packages can inflict with other versions of packages installed by their applications. Worse, sometimes applications need newer version packages that aren't available on the system. Or similar package versions have different patches on different distros. But even applications pull back changes until a newer application version becomes available, which may not be until a distro makes a new release. This could be preventing users from having the best version of a piece of software at any given time. On top of that, we also see an increase in the pollution of our root file system, and this is hard to read. This graphic is a great visualization of the way that the Linux file system looks. But you may notice that it's pretty complicated, and some of these things are a little bit redundant. For instance, this is the contents of WMI Ad Variable. We mean that user-runable binaries that's been used in user-resubmitted games, user-local-ban-assuming games, and any number of God directories in my home directory, as well as the work we're sneaking in in some random user-local-broke event. And similarly, library and data files appear wherever they want. These are the results of bringing out the input on my machine, but I'm not considering this as a complete list. And data directories are just kind of more after they need to be. So to generalize the goal confinement, we want to move away from letting apps lose by each other without print permission, and we want to take back control of our file system, putting these applications in a non-location, and giving each application the appropriate dependencies. Our traditional package manager and definitely the sovereign system to be packaged is over 20 years old and periods the weight of those years on its shoulders. And because of this, we thought it would be best to introduce a new packaging tool chain. So historically, a couple years ago, Canonical announced click packages, which were kind of a solution to this problem. An application package in the click is bundled with any specific dependencies that it needs, and it takes advantage of frameworks to access and share resources that it might need. It also uses AppArmor to create a combined application and specify any security features it needs. Clicks were used to package applications for the initial wrapper. We do touch devices, giving them a little bit of headline. We use devices in brand new, instead of X11, as well as Unity8's display server, which sort of gave us our combined ecosystem. But these tool chains were missing some important features and lack maturity. So fast forwarding to today, we're seeing the emergence of SNAP packaging. Also referred to as SNAPI. SNAPI is essentially another iteration on clicks, doing better version management, so you can application five definitions and new ways to integrate your system resources. You can use SNAP today, I'm monitoring Ubuntu or several other distros. SNAPs will all live in a special boot directory and can be completely confined to an itself-stable channel for unconfined, self-mustable channels, if you must. SNAP apps come bundled with all their connections for locally, meaning that all apps will have the dependencies to need it after it runs for a month. No longer needing to wait on tag-containers to even get to the main distro. SNAPs are automatically updated once a day, taking the pressure off of the user to keep their system up to date. And SNAPs come with the option for delta updates, which means that the toolchain can validate if instead of entire package, potentially making downloads smaller and faster. And as confining is concerned, SNAP apps are relegated to their mutilating use-to-classes and by default, requiring interfaces to be connected to perform system tasks between the display, using audio, and using the network. Instead of using a hybrid or classic environment, in addition to a traditional package manager, we can continue to pull in and use our classic applications while enjoying confinement security in our migrated apps. However, one exciting premise is SNAPs is that they're related to running an all-SNAP environment, which we, I think, call a bit diverse. But this puts in a bind. We can't run classic apps in this all-SNAP environment. Our little classic applications are looking for an unconfined system, and we're looking for the X11 display server. And this all-SNAP environment, no idea of neither. We need a way around this issue to give to its audience its run applications, just like they would in a classic system. So to resolve this, we've been working on a suite of tools, which we call Libertine. A Libertine is a person who acts about more restraint. Libertine is an extreme form of hedonism. Living one's life for pleasure while only thinking of oneself. In a sense, our classic applications are practicing Libertines. And it's our job to pull them back and to more on my standard. These applications need a safe place to go while the rest of the world falls in line, and we provide the safe space as a Linux container. Containers are generally unrecognizable from a traditional Linux desktop experience. A Libertine container has some files that we can work with and binds assistive resource directories to access things like home and some system resources. Internally, we continue to use apps and deep packages to manage our packages, even when the host system is not allowed to use deep package, even if deep package is not installed on the host system. Libertine also connects to a program called XMirror, which allows us to run an X11 window isolated on top of Mirror. Every installation, removal, and system modification is done internally, protecting the outside world from whatever these classic applications may be doing to the host system. In the Libertine suite, as many parts are abstracted away, the underlying implementation of classic windows is best possible. C++ library includes Python launchers and command line interfaces, and tools to control other aspects, like watching XMirror, and to comply with the board. So, we cover a few of these. Again, a little bit of difficulty. This is just JSON, dictionary, arrays, and all the good JSON stuff. So, Libertine uses JSON as a database file. Team and trackable install packages, creating containers, modified bindouts. And we just use this database individually for each user on the system. And using JSON, we found, let's us not handle any database frameworks, which is good for our use, because we can also just ask users for the raw database file and data line, because there are 30 or 40 lines of JSON. And so, the crux of our container management is our Python library. Of course, it contains an abstraction around the database that we just saw, and we have a lot of other applications, but the primary use is to extract away the process to handle different limitations of Libertine containers. Of which we support three types, Jiru, LXC, and LXD. Jiru is a special case. We maintain only a few use-on-devices with kernels to hold to support LXC or LXD. With the Jiru diagram, we use the Thinker-Coning Line tool to use home directory as a shrewd jail from which we'll run all of our commands and applications. And when we run commands within a shrew, we use the tool help keyword. And we'll generally try to run a few on privilege to run that command in our generic shrewd jail, but every now and then we have to run privilege-free commands. And so, we prefer not to use shrewd-premise containers. Except that the deprecator, though, is still useful. But LXC containers have been our preferred containers for most of Libertine's lifetime. LXC combines the kernel C-groups to support isolated namesraces to provide an isolated environment for applications. LXC tools, based on the forest recovery we've run home directory. Oh, no. I forgot to add names. I'm sorry. Sorry, I wasn't as loud as I thought. Thank you. Thank you. Thank you. We're capturing a sound from the camera, but it's just not perfect. Okay, thank you. It's going great. I'm trying to do that. I'm setting up the solution here. I'm setting up the access to home and system directories. I'm setting up. I'm going to see the end grade and show the best of features for the tree. I'm going to go to grade lines to make sure that we can access things like audio and the system. I also hope that the LXC Python would be quite mature and work well for our needs, for instance. This is a code sample showing how we used the LXC container on the patch map to be on our command. And to your Python. The newest shine is back into Libertine as LXC containers. LXC is a new space on top of the LXC implementation. Simplifying container management and tip-on for writing speed and usability improvements as well. Libertine LXC containers are outliers and that we've aimed on the LXC back end to maintain the root file system, but we still maintain locally the user's home directories and the local applications directories. The most important thing about LXC is just like every set of LXC containers, we buy and match up with devices, map the current procedures in the system, and it's also going to be all-cannot. One, I guess, one weird thing about LXC is how we have to set up SedgeRumSedgeUser. SedgeRumSedgeUser is an assistant director for stored files running processes when LXC finish starts. This directory unfortunately is overwritten completely when it starts, so we need to remap it by using sound search, storage scripts. To work around this, we create a custom script and copy it into the container. The script creates missing directories, makes it permission to remap it to LXC. But sure, this is the solution we've ordered. We add the files to the container using the files API which is back there. This is part of the Python by LXC mechanism. But the Python API for LXC is not quite metamorphic, we can use it for all of our use cases. So we use a hybrid solution that you can apply to API and calls it to be open to start processes manually. As an example here, we use the Python API to update those devices. It's just a dictionary, and we use the Python by LXC to create this profile of a dictionary using LXC exception to tell us when there's an error. On the other hand, when we run applications, we have to use KSC-SOL-LATKE open to launch applications because that's the best way for us to run LXC applications in the background while still getting all the outside in the foreground. So we also have these services that are responsible for making sure the container does start and stop appropriately in LXC LXC. This is to help us save battery life so that the container isn't started all the time, and it ensures that when a user stops one container, or stops one application within a container, the container doesn't stop, but we wait for all applications to be closed. Moving on, we use the RUMO binaries. We have a Python binary called the container manager, which allows you to create managed containers and self-active and modify them by amounts. This is a basic overview of using the RUMO binaries in container manager to create a container. It's fairly straightforward. We just call them create something in, with any number of flags, all of which have intelligent defaults, is a priority. So the user doesn't have to know what kind of container they're back and where they're using. Here I've shown that as just a black box, and then it just updates the database and the agile of the file system using the container's back end. And this is similarly just what installing a package would look like. Note that a package name may not line up with the binaries installed, but we're only keeping track of what the user is supposed to be asked to install. Because the purpose of this container manager is to prevent the user from having to deal with the low-level concepts within a particular container type or package management system, and focus on the key concepts of creating an install. We also have a DOS server, and Python has replaced the work being done by the last application we saw. All of those have been fully implemented yet. But many of the commands that we use in the container manager take a very long time to write, and bad things will happen when those things are interrupted. For instance, having D-Pag, which of course will cause the R-TAN-cog broken package to a container system. The other team being to solve that by being a completely asynchronous method, where we use Python threads and send updates to DOS signals. And although we would like to replace the container manager back end with this in the future, we currently just use it to list container ads and application ideas. Now, which brings us to LiveLiberTeen, which is the root of disturbing container information for several external libraries. It's currently a wrapper around a client for LibertyD. And many of the low-level ads libraries that access Liberty are written in C++. And LibertyD is a convenient way to access Liberty information without having to talk directly to D-Lis. The code sample in here is just by taking out a simple D-Must call from C++. We also have a GUI written in C++ with QML. This is an easy way for us to manage containers and even on a less technical use field, easily manage containers and install packages. It's mostly a series of lists showing you how you can do it in a list of containers in which you could do the list of packages. For the most part, functionality GUI is the same as it is in the main library. There's the mainline tool. And now the real neat is Liberty Launch, which is the Python tool that we use to actually launch applications. But at Liberty Launch, we do use kind of the environment for running ads, and in four of that environments, the container implementation actually running application. Liberty Launch is maternal, but we generally prefer to use a new A8 we use with the Dread Launch. K-Steak is a demon. It's a conveying binary to help applications use the board. We just use key signals and slots to wait for copy and paste events from the underlying combo hub, and then we forward those events to our excellent ads. And doing this, we can use copy and paste pretty much like we would in these applications on our desktop. So what actually happens when we launch applications to Liberty? Well, if we look at our desktop icon, we'll call Liberty Launch with a container ID and application exact line, which is probably found using Liberty Team, which found that information actually in Liberty Beach. Liberty Launch will then start utilities, like pastes and X-Mere. It'll set up a session by coming at the environment and setting up a whole bunch of sockets and then it will launch a container instance based on the Python library, which will then do any number of things based on the container type. They'll buy an outs, launch a window manager to connect to a dimensions of X, and finally launch the app. And that's most of the full picture. To review the container, you want to look at the features, and you set it up to install applications through app. Even when app is not a system, Liberty keeps your container and it's possible to get it on the root file system in a small whole loop of it to let them access things like the home directory and the resource directory. At which point something or someone can launch with an application pilot to launch. They go prepare the container environment near the host, set a window manager, and set a container connected to the host display variable and launch applications. You might all know that. Where can we actually use Liberty? The answer is well, in most of our modern and future systems. Liberty 7 is the current people that stop the session and they do too. And using Liberty in Liberty 7 is a little bit silly because Liberty 7 is not in a planned environment. Already run there's 11. And already installed packages to be packaged. But I think we're noting that we can use Liberty just as well here and where there are a lot of users to run their applications and apply the container without looking up their host system. If Liberty 7 is already running at 11, Liberty 7 is a classic app that can use the running X server to connect to their window manager. So we don't need any special tools for that. And because Unity 7 is not a target platform, applications in the containers are automatically discovered by the Unity Dash. So you can jump through some loops to give them a show up, either by writing some vital desktop files or by manually launching Liberty Launch. Alright, so Unity 8 is a new version of Unity 7. Running Mirrors is a display server instead of X and pre-installed in the new system. Desktop Unity 8 is also not very fairly defined, but running Mirrors instead of X will be able to do some of our previous security things. In Mirrors Unity 8, you can run some applications natively such as modern QDats, but are I able to run an all-around class F natively just yet? And Liberty works well in Unity 8. And it's built into the application discovery logic. That's in here, just for being a sense, come up. The guy I kind of thought was in the past, he had the ring Liberty Launch just as we normally would. Except in this case, there's no X11. So the system also started in the sense of XMirror to put their four applications to a Tetris window manager too. XMirror allows us to run the X11 apps on an excellent window on top of Mirror. Each running a Liberty Launch application will get its own XMirror. So we're running our own communication between the apps. And with this done, we successfully launched XApps in an Onyx environment. So similarly, we would be touch, we would be touch also in Unity 8 in here, and it will can't run across apps on its own. Furthermore, users would prevent using apps to deep-exchange install apps due to the testing and running<|el|><|translate|> of the system by default. So we even asked that would work in a best-of-year sessions, attend the reading of a System. You can see we can create one large package file. We need to update the padding environment and variables to be more flexible for SNAPs. And we need to make some architectural changes to the lower team and lower team being. SNAPs also encourage us to hurry the production of our let's see thing go back in, because we'd let's see SNAP available that we can use. In order to access resources and SNAPs, you have to connect to the interfaces, and we connect to quite a few. This is a short list currently that we use. Lexi, obviously, the Metro Lexi. Now we can network by, connect to SOCAs, to the network, home, connect to the use home directories, and all the rest of your sound and graphics. OK. Live demo. This never looks great. Well, in Plot Twist, I've been running this presentation in Firefox, running a leveraging container in SNAP the whole time. So it works. But I'm not interested in the other applications real quick. Something like X911. More to come up. That's not too loud. And we can say, Firefox, and you can see the command of being run within the container. And this is running completely isolated in its own root file system, completely separate from the host. And what else? Let's see. Do we run something like LeapPad, Edit Documents? Like, I opened something that already exists. Test file. And it all stays fine. And it doesn't crash, which is good. So we'll open that up. And one more. How about some minus fever? And there. Well, pretty good. We've got some under it. This is on Unity 8? This is all on Unity 8, yeah. So yeah. To be clear, this is, everything's running on Unity 8. Everything is in SNAP, running LXD containers. And with that, we can go ahead and pick up. Oh, wrong. Can you lower that? To very quickly review, we wanted to be able to run classic desktop applications in a fully confined, I mean, fully confined, an ex-less ecosystem, in a package format. And we used Liberty to do just that, mostly through LXD containers. And there's a bit of a weird degree in the back end in SNAPs. And we have this working on a lot of our modern machines. There's obviously a lot that we're still working on. All of these things, Unity 8 near Android, seeing it in SNAP, tomorrow, moving in to Milo, and then in development wise, they're also still working. Like, they're in a couple with a lot of apps that you can do with us. Our SNAP is just big. I recently, I mean, think I might have made a regression where audio doesn't work in the SNAP. But that's called working too hard on that demo. And that's it for me. Yeah, good. I think that's all my content information. It might be out of time. Right on time. So I asked, I was to set up a running card that says how to question us, but they will be recorded. Because the recording is kind of in the mail. There. So that's a really good question. So are there any questions? Yes. What will be after running the state premiere? So there's one pre-review today? Right. So the system is made up so that you could create a container that you want. And then our underlying back menu will know which container he is being. Which container is the right one to run on a patient hand. All of these are right in the same place. And so if you want to. I thought, guess what you said, people, that it was like in one application, or if you're right, it's the three-point that you have to use. You can't do that on separate teams. Right. So they all run. So we work around a problem that's moving on each other. So we're up. Does anyone have, it's the event of each year that we come over? Yeah. So we come in the apps around talking to each other through X11 by using an individual instance of Xmer. Or, and I think you can do it. And so each application will have its own Xmer that it's running on. But they can still talk to the same cloud system. Yes. We're hopefully going to. No comment. Although I'm saying it's nice to have a diverse ecosystem of new display servers and a pack of new formats on that horizon. Anyone else? Okay. Thank you. Thank you.
so let's start with a little bit of background. take advantage of these new architecture and tool discovering interface such as Unitybench. These migrated to new display servers and new packaging management. And throughout this process, business and online applications. This is not devices which are intricately updated or checked throughout your home. And dependencies are new, instead of X11, as well as Unity8's display distros. SNAPs will all live in a special boot directory and can be completely confined to an classic system. So to resolve this, we've been working on a suite of tools, which we call more restraint. Libertine is an extreme form of container has some files that we can work with LXC tools, based on the forest recovery we've run way for us to run LXC applications in the overview of using the RUMO binaries in container kind of the environment for running ads, and in someone can launch with an application pilot to Alright, so Unity 8 is a new version of Unity 7. Running Mirrors is a display server instead of X Unity 8, you can run some applications natively XMirror allows us to run the X11 apps on an too loud. And we can say, Firefox, and you can how to question us, but they will be recorded. right, it's the three-point that you have to use. over? Yeah. So we come in the apps around talking