We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Exploring Sculpt a component-based operating system

00:00

Formal Metadata

Title
Exploring Sculpt a component-based operating system
Title of Series
Number of Parts
94
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The talk explores the current state of a Genode-based operating system. It will demonstrate how Genode's unique system design lends itself to compose a general purpose OS that puts the user in full control without sacrificing security by applying the principle of least privilege from the very beginning. Over the past decade, the Genode OS Framework has evolved from a research prototype to a practical operating-system foundation. By now it is used by the Genode developers as well as a group of enthusiasts in form of Sculpt day to day. Being a component-based system designed after the principle of least privilege from the very beginning, it breaks with many concepts that we take for granted in traditional operating systems, e.g., the central role of files. Instead, Genode introduces a novel way of composing system scenarios out of building blocks where the building blocks are able to cooperate without ultimately trusting each other. Thus components are isolated sandboxes, whose access to the surrounding environment is managed from the outside and enforce by a microkernel. In 2018 the Sculpt system scenario was created to make this system more easily accessible by providing a user interface making it more convient to execute common administrative tasks, e.g. configuring the network, as well as installing and deploying applications. This talk will give a brief overview of the architecture of Genode and will show the current state of Sculpt by giving a live demonstration.
14
Thumbnail
08:55
28
30
36
Thumbnail
57:37
39
Thumbnail
58:46
48
Thumbnail
1:00:10
57
Thumbnail
15:55
91
Operations researchPhysical systemComponent-based software engineeringOpen sourceFreewarePhysical systemMereologyXMLUMLComputer animation
Computer fontPhysical systemSlide ruleMereologyPhysical systemSoftwareSoftware frameworkInformationPoint (geometry)BitComputer animation
Information securityComponent-based software engineeringMikrokernelPrototypeOperations researchPhysical systemSlide ruleMusical ensembleComputer animationLecture/Conference
Information securityComponent-based software engineeringMikrokernelPrototypeOperating systemPrototypePhysical systemComplex (psychology)Thermodynamisches SystemComplex systemComponent-based software engineeringData structureMultiplication signNumberProjective planeOcean currentComputer animation
Physical systemArchitectureTablet computerOpen setInformation securityComponent-based software engineeringScalabilityData structureRecursionLatent heatComputer architectureAbstractionPhysical systemInformation securityComplex systemGame controllerCASE <Informatik>Connectivity (graph theory)Component-based software engineeringThermodynamisches SystemSemiconductor memoryProcess (computing)Data structureView (database)Cartesian coordinate systemWorkloadNetwork topologyLengthScalabilityComputer architectureScaling (geometry)Basis <Mathematik>NeuroinformatikDependent and independent variablesComplex (psychology)CodePhysicalismRight angleProtein foldingHeuristicMechanism designOperating systemBranch (computer science)BuildingFunctional (mathematics)Computer programmingCategory of beingBlock (periodic table)Point (geometry)Key (cryptography)Inheritance (object-oriented programming)FinitismusKernel (computing)Variety (linguistics)Order (biology)Sensitivity analysisOperator (mathematics)Service (economics)
CuboidPhysical systemMechanism designConnectivity (graph theory)MikrokernelFlow separationStack (abstract data type)RandomizationInheritance (object-oriented programming)AreaNeuroinformatikSoftware frameworkSensitivity analysisComputer programmingLogic gateSinc functionComponent-based software engineeringMereologyFunctional (mathematics)LaptopLatent heatProcess (computing)Network topologyImplementationSemiconductor memoryInformation securityCommunications protocolComputer architectureInternet service providerThermodynamisches SystemDemonKernel (computing)Virtual machineFigurate numberMilitary baseWeb browserArithmetic meanDevice driverComplex (psychology)Constructor (object-oriented programming)Software development kitIntegrated development environmentDomain nameGreatest elementBuildingComplex systemComputerService (economics)Computer-generated imageryClient (computing)Core dumpWave packetRootkitCryptographyProper mapCASE <Informatik>Cartesian coordinate systemThread (computing)Scaling (geometry)Run-time systemComputer fileLecture/Conference
System programmingScale (map)Binary fileVisualization (computer graphics)DisintegrationComponent-based software engineeringSource codeDuality (mathematics)Software frameworkOpen sourceGraphics processing unitPhysical systemFile systemInternet service providerComputer configurationFunctional (mathematics)PlastikkarteConnectivity (graph theory)Software frameworkRevision controlKernel (computing)Computer networkDampingProjective planeFrame problemWireless LANThermodynamisches SystemDevice driverOpen setDuality (mathematics)Computer animation
Component-based software engineeringSoftware frameworkConnectivity (graph theory)CuboidDevice driverKernel (computing)Multiplication signPhysical systemElectronic data interchangeComputer animationUML
Thermodynamisches SystemDisintegrationFluid staticsComponent-based software engineeringAerodynamicsPhysical systemConnectivity (graph theory)Multiplication signBuildingComputer-generated imageryIntegrated development environmentScaling (geometry)BootingFluid staticsRevision controlBasis <Mathematik>Run time (program lifecycle phase)Software frameworkRadical (chemistry)Web 2.0INTEGRALDynamical systemShape (magazine)Virtual machineWeb browserForcing (mathematics)Motion captureThermodynamisches SystemComputer animation
Gastropod shellGraphical user interfaceComputer-generated imageryMultiplication signVirtual machineRevision controlVotingTask (computing)Maxima and minimaPhysical systemSystem administratorBootingLecture/Conference
Physical systemMikrokernelDifferent (Kate Ryan album)Figurate numberLatent heatCASE <Informatik>Network topologyPhysical systemGreatest elementFluid staticsComputer animationProgram flowchart
Physical systemConfiguration spaceData storage deviceFile systemView (database)Binary codeConfiguration spaceConnectivity (graph theory)Computer-generated imageryMereologyBootingServer (computing)Computer fileRun time (program lifecycle phase)Traffic reportingState of matterModul <Software>Physical systemUniform resource locatorService (economics)Fluid staticsStructural loadComponent-based software engineeringFrame problemComputer animation
Open setConfiguration spaceMikrokernelConnectivity (graph theory)MultilaterationPhysical systemFrame problemInterrupt <Informatik>Black boxContrast (vision)Complex (psychology)Computing platformData storage deviceSemiconductor memoryNetwork topologyoutputFigurate numberKernel (computing)Level (video gaming)
Principle of maximum entropyCore dumpoutputComputing platformMikrokernelDevice driverSemiconductor memoryService (economics)Frame problemTouchscreenTerm (mathematics)Right anglePhysical systemComponent-based software engineeringInterface (computing)Game controllerCASE <Informatik>Computer animation
Physical systemData bufferoutputMaxima and minimaPhysical systemSlide ruleData managementoutputComponent-based software engineeringInterface (computing)Connectivity (graph theory)State of matterView (database)Computer animation
Physical systemThermodynamisches SystemComponent-based software engineeringData storage deviceGraphical user interfaceComputer networkConfiguration spaceComputer configurationGraphical user interfacePhysical systemConfiguration spaceDirectory serviceFile systemBootingHeuristicDefault (computer science)Data managementComputer configurationComponent-based software engineeringInverter (logic gate)Computer animation
RootkitQuiltPhysical systemComputer fontRun time (program lifecycle phase)Total S.A.Presentation of a groupKey (cryptography)outputModul <Software>QuadrilateralJava appletBinary fileLetterpress printingContent (media)Default (computer science)Client (computing)Focus (optics)SummierbarkeitTime domainPointer (computer programming)outputPhysical systemFile systemComputer fileSpherical capConfiguration spaceSoftware frameworkTraffic reportingDirectory serviceEscape characterDomain nameData managementMereologyKey (cryptography)Pointer (computer programming)Probability density functionSet (mathematics)RAIDFile viewerFrame problemDimensional analysisOcean currentBit rateSlide ruleSource codeComputer animation
Configuration spacePhysical systemThermodynamisches SystemComponent-based software engineeringGraphical user interfaceComputer iconComputer configurationMaxima and minimaFocus (optics)Key (cryptography)Run time (program lifecycle phase)Read-only memoryoutputDefault (computer science)SummierbarkeitTime domainContent (media)Duality (mathematics)Pointer (computer programming)Client (computing)Presentation of a groupBinary fileTorusMotion blurQuiltPointer (computer programming)Position operatorEvent horizonPhysical systemKey (cryptography)Data managementoutputGraph coloringRun time (program lifecycle phase)Computer animationSource code
Run time (program lifecycle phase)Data managementConfiguration spaceComponent-based software engineeringComputer networkMechanism designRouter (computing)Inheritance (object-oriented programming)Dynamic random-access memoryInclusion mapDenial-of-service attackBefehlsprozessorRaster graphicsRun time (program lifecycle phase)Web 2.0Cartesian coordinate systemVirtual machineWeb browserText editorConfiguration spaceComputer fileProcess (computing)Component-based software engineeringProbability density functionView (database)Computer animation
Systems engineeringInheritance (object-oriented programming)View (database)Large eddy simulationRouter (computing)BefehlsprozessorComputer fontConfiguration spaceComputer programmingComputer fileConnectivity (graph theory)Computer animation
Physical systemInterior (topology)Configuration spaceComponent-based software engineeringComputer fileComputer programmingCASE <Informatik>Object (grammar)Probability density functionComputer animation
Systems engineeringInheritance (object-oriented programming)Router (computing)Common Language InfrastructureCodecPhysical systemArchitectureOperations researchTablet computerInformation securityComponent-based software engineeringComputer architectureSoftware frameworkSoftwareData storage deviceUniform resource locatorFile viewerProbability density functionComputer programmingConnectivity (graph theory)File archiverUniform resource locatorSoftwareSource codePublic-key cryptographyComputer animation
Formal verificationUniform resource locatorSoftwareConnectivity (graph theory)MultiplicationData managementSource codeInformationComputer programmingThermodynamisches SystemSoftwareComputer animationProgram flowchart
SoftwareContent (media)Configuration spacePhysical systemComputer networkEmailUniform resource locatorCache (computing)Rollback (data management)Revision controlDefault (computer science)AbstractionFocus (optics)Time domainKey (cryptography)outputRun time (program lifecycle phase)Client (computing)RootkitTotal S.A.CloningRankingDenial-of-service attackSoftware development kitDuality (mathematics)Dynamic random-access memoryReading (process)File systemPublic-key cryptographyFilm editingRevision controlSoftwareComponent-based software engineeringInstallation artAddress spaceFirewall (computing)Data managementComputer networkComputer programmingFile archiverMultiplicationDirectory serviceFormal verificationSoftware bugInformationConnected spaceCASE <Informatik>WritingUniform resource locatorQuery languageConfiguration spaceMereologyComputer fileCache (computing)Data storage deviceComputer animation
Visual systemRootkitTotal S.A.Run time (program lifecycle phase)FingerprintExecution unitSource codeSoftware frameworkBitSimilarity (geometry)Revision controlVisualization (computer graphics)Bit rateProcess (computing)Connectivity (graph theory)Gastropod shellPhysical systemRun-time systemComponent-based software engineeringMaxima and minimaRight angleGraph (mathematics)MereologyPoint (geometry)Computer animation
Connectivity (graph theory)Thomas BayesConnected spaceRootkitNetwork topologyInheritance (object-oriented programming)Multiplication signMusical ensembleSlide ruleMilitary baseTouchscreenCartesian coordinate systemLecture/Conference
Latent heatComputer architectureFingerprintMultiplication signConnectivity (graph theory)Service (economics)Network topologyLecture/Conference
FreewareOpen sourceComputer animation
Transcript: English(auto-generated)
All right, so hello everybody, my name is Joseph and today I will talk about the Skype2S. Well, actually since you can see from the title of my talk which is called Exploring Skype2S.
I will not only talk about the system but I will also show you the system actually. So, I've structured my talks in basically four parts.
Basically I will just start with giving you some background information about the underlying technology that is used, namely the Geno2S framework to build the Skype2S. Then I will give you a brief overview of the Skype system itself. Followed by how you can extend the system by basically installing software on the running system.
We skipped the fourth point and will go straight through the roadmap. So, there are some things we still have planned for this year. All right, so let me start by giving you some background information.
Well, actually I just have to use the other slides because that will be a little bit complicated.
I just have to look for the proper slides otherwise I will get confused, which will be bad.
It doesn't matter. So, let's just move on.
Well, the problem is that by now we are surrounded by an increasing number of computing devices and those computing devices mostly by now are running commodity operating systems which are highly complex.
And since the vendors mostly want to innovate quickly, they accept the reliance on such highly complex systems. But on the other hand, the key ingredients or the technologies or principles that can be used to build still complex systems
but whose complexity can be better managed are available but are not employed. And from within the L4 microcurrent research community came the idea to explore the practicality of component-based operating system
that uses capabilities to manage the complexity, the overall complexity of a contemporary commodity system in a better way. So, the first idea came back in 2003 and it took some time but eventually in 2006 the first prototype was built with some success.
In fact, so much success that the people behind the prototype decided to found a company to develop the prototype even further back in 2008.
And that is basically how the whole project got started. So, if we talk about the complexity of contemporary commodity systems, how can you structure or provide a new system structure if you disregard all the assumptions that are normally made when you build a traditional operating system?
What are the key features that such a system architecture should provide? Well, as I said, the commodity systems normally consist of a complex global system policy where it's difficult to have fine-grained control over the different components within the system.
So, what we would like to have in a new clean-set system architecture would be an architecture that follows the principle of least privilege where each component only has the access rights or access to the resources that are needed for the component to fulfill its function.
And we want to have mechanism where we can express exactly this property which basically leads us to capability-based security. Another point is that we have mixed criticality.
That means that we have complex components that we don't fully trust and we have security-sensitive functions we also want to run on the system. And we want to run them on the same system at the same time without that the untrusted components can influence the security-critical functions.
So, we can achieve that by strictly isolating each component and structuring the system in a way that we can assess the application-specific trusted computing base. An application-specific trusted computing base is basically the amount of code a component or a
user of a program has to trust in order for the program to fulfill its purpose, which in commodity systems can be quite large. Another thing is that we want to have a robust system.
By now almost all operating systems provide the illusion that all resources are infinite and they go to great lengths to uphold this illusion. Like for example if memory becomes scarce they try to swap out inactive processes to make room for active processes and apply some heuristics
and eventually if something fails or the whole construct falls down in the worst case, the OS kernel normally chooses arbitrarily some process that it will kill to free up resources for other processes. And we don't actually want that in our new system and we actually don't want to have the abstraction of resources at all.
So what we want to have is the ability to remove the abstractions, only trade physical resources but in a way that we can account them, that we can trade them and that we can track them.
Trading them is vital to this concept because since the physical resources are infinite we have to give another component access to the resource so that we can utilize the resources more thoroughly.
And last but not least we want to have a system that scales well. Scalability means that we have a variety of use cases, of workloads, basically that we all want to accommodate with one system.
And we can achieve this by structuring the system in a recursive way so that we can compose complex systems by using simple building blocks. Naturally the gNode OS architecture is such a system that contains all those four key features.
A gNode system is normally structured as a tree where each parent owns the component or owns a child. And by owns the ownership is defined as having the responsibility as well as ultimate control over the other component.
For example the child has to provide the resources that are needed to create its child. But in return it retains the control of the child. That means it can restrict the system view of the child, it can restrict the access to the resources of the surrounding system of the child and obviously it can also control the lifetime of the child.
So since a child can also have children you will end up with a system where we have a recursive system and each component in this system gets assigned.
Since I told you before we don't want to abstract physical resources in the gNode OS architecture we have a budget of physical resources. This budget can be used to either access the resource or you can pass along the budget along the branches of the tree.
So components can trade its budget. This dynamically trading of budgets enables you to basically provide services without paying for them. Like for example I have a frame buffer resource multiplexer that enables clients to display pictures on one frame buffer.
Instead of the resource multiplexer having to spend its own resources each component that wants to display an image of the frame buffer will donate some of its budget to the resource multiplexer.
And as I said those trading mechanisms enable the system to really utilize the resources in a proper way. Since we talk about application specific trusted computing base if we look at the
figure at the bottom we see the reddish box which is basically our microkernel. The microkernel is part of every TCP of every component in the system but its only job is to provide for one threads of execution so you can run components.
It has to provide protection domains so that all components that are run within the system are isolated from each other and it needs to provide a mechanism for the components to communicate with each other in a controlled way. All other system functionality like device drivers, file system, protocol stacks, runtime environments or virtual
machines for example, security sensitive functions and so on are provided as component within the tree. They are not part of the underlying microkernel and so you can structure your system in a
way that it becomes easy for you to assess the trusted computing base of one specific component. For example if we look at the yellow box. The yellow box has several parents and grandparents and the red area denotes basically
the trusted computing base that means all components that the yellow box has to trust. But if we look at the whole picture we can completely discard the right side of the tree because the right side of the system is completely unrelated to the yellow box.
So that means for example we could run some huge complex web browser on the right side and we could run our GNU PG or whatever security crypto component on the left side and it isn't possible for the components to influence each other.
Building on that it makes sense that you locate critical components as near to the root of the tree as possible because in this case the trusted computing base is small.
And well that enables you to build secure systems, complex systems but you can manage the complexity in that you build a system consisting of multiple smaller systems. And the concrete implementation of the g node OS architecture is the g node OS framework.
It's basically a construction kit for special purposes. OS is written in C++. It scales from embedded systems to general purpose computing that means it runs on systems with at least 4 megabytes of memory available and obviously also on my laptop which has much more resources.
Since even the kernel is just one component of the system the g node OS framework runs on multiple kernels and we are actually all components are binary compatible between the kernels.
Which is a nice feature because you can debug your component on Linux and later on deploy it on the target which runs a microkernel. And one of the things is the framework as a whole just provides the means
that components can communicate in a controlled manner and can access resources in a controlled manner. And in the current implementation, in the concrete implementation of the g node OS framework every program
is executed in its isolated sandbox and can only communicate via a specific mechanism with the surrounding components. OS framework consists of by now hundreds of ready to use components.
Since I already mentioned that all the system functionality that normally is located in the kernel is provided by components within the system. It would require much effort to write all those components from scratch. Therefore we borrow basically the drivers from other operating systems. For example our framework driver is ported from Linux kernel for Intel graphics cards.
We also use the Linux wireless stack as well as the Intel wireless device drivers from Linux for our wireless driver. The OpenBSD audio subsystem provides the foundation for our audio driver.
And we use the ROM kernel of NetBSD as file system provider. So we gather all, we collect all the functionality that we need to actually run the system from other open source projects which is quite nice actually. So we don't have to reinvent the wheel and implement the drivers on our own.
Of course the g node OS framework is also open source, it's dual licensed, the open source license is the AGPL version 3 and there are also commercial license options available. Yeah, that's just a nice picture which shows you some components.
On one side, in the middle you see the various kernels, the gene drives runs on, the bluish boxes denote the device drivers. And actually it isn't, well it doesn't matter which components you actually see here, it's just a rough overview.
Of course there is documentation, there is the book called Genome Foundations which explains more thoroughly how the system came to be and explains the technical details in depth.
And well, I encourage you to just take a look at the book because it's nice written and it's really worth your time to just read it. Okay, finally I will talk about Sculpt.
Yeah, by now, since I said the genome OS framework was by now only used to build general purpose systems, back in 2014 we said well it's about time that we use the system on a daily basis for doing our work. So we created the static terminal scenario which basically is a system where you can
run dynamically, where you can change, at runtime you can change the components you run. For example you can start multiple virtual machines, you can start your web browser, your POSIX environment and so on.
But it's static in the sense that it's still limited to integration time. That means if you want to exchange components or update components you would still have to build your own system image and boot your system image. Fast forward four years, static doesn't scale well so we thought we need a
dynamic system, a system that is easily accessible and changeable, well shapeable actually at runtime. So we built the Sculpt OS. Sculpt is short for sculpture, basically which denotes the intent the system has.
And the first version we released in February, that was the version Sculpt for the early adopters. In this version you still had to build your own system image and there was just a minimal POSIX shell for interacting with the system to do your administrative work basically.
Back in May we released Sculpt for the curious which for the first time in years provided a ready to boot system image of GNode which works on real machines as well as virtual machines. And it also featured a graphical user interface that aids the user by doing some administrative tasks.
So we are not confined to just using the POSIX shell. So let's look at how this system is structured. You will see that it reassembles the figure I have shown you before in that it's a tree
basically and the tree hosts different subsystems and each subsystem has a specific use case or a purpose basically. At the bottom there is still your microkernel and now we will briefly look into each subsystem.
Let's start with the static system. The static system hosts the part of the system that does not change at runtime. For one it provides a frame buffer resource multiplexer or lid picker GUI server as well as
components that enable other components or subsystems basically to report their state to access boot modules for example. Like the ROM component, the ROM service enables you to load F binaries from the boot image. As well as there are two file systems, one the report F file system that provides a nice file based view on each
of the reports as well as the config file system which provides the storage location for the configuration of each of the components. And you have some global policy which I will go into more detail later.
Alright, so let's start with the first subsystem, the driver subsystem actually. The driver subsystem contains all the components that are needed to bootstrap the system like your platform driver, your input driver, your frame buffer driver, your storage driver and so on.
Don't be intimidated by the figure, that's the complexity you normally have also in your traditional S kernel or system. But in contrast to the traditional system on Genode, the complexity is hidden in plain sight but luckily you can also choose to ignore it.
Basically treat the driver subsystem as a black box which transforms low level resources like for example the IO memory, the IO ports or interrupts into higher level resources like for example the platform resource, input resource, frame of resource and so on.
And the other subsystems can access these resources but they don't care about the details like they don't care that the device driver accesses IO memory. They just care about that the graphics driver provides the frame buffer service so they can paint something onto the screen.
And the next subsystem is the so-called Leitzenträule which is basically the German term for control center and is the subsystem that hosts the administrative interface.
In this case there are on the right hand side you see a component which displays the system lock and on the left hand side you see, well since it's an old slide normally it would be the Skype manager that you see here.
But in a sense you have one component that controls the system and the other component shows some system state. And I can actually show you that for example if I fade in the Leitzenträule on the right side you see the system lock and on the left side you see the Skype manager.
The Skype manager itself is basically also a subsystem that hosts various components. For one there is one component, the system agent basically that monitors the system state of the various driver components and another component which provides the graphical view and also handles the user input.
And that's basically your administrative interface if you interact with the Skype system.
As I said the system is managed by the Skype manager component, the managed configurations are stored within the config file system in the managed directory. There are some inbuilt heuristics for example which default file system is used when the system boots up and so on.
But you can also choose to overwrite all the automatically managed configurations. And you can access the system via the inspect option of the graphical user interface and we will exactly do that. So let me just show you what's in the config file system.
Just to show you the system as you have seen in the previous slides, this is basically your config file system and that's your report file system. We will go into the config file system and there we have a bunch of files that control certain aspects of the system.
For example, let me just show you the managed directory. It contains the files of the subsystems that are automatically managed from the Skype manager.
But since I now use the system I normally use and not the empty system like I would like to do because the PDF viewer didn't work the way I wanted to. I will show you my own config files.
For example, within the input filter config file you can configure the input subsystem. And in those files you can for example add key remappings. I'm a WVID2VIM user and I don't use my caps lock very much so naturally the first thing I do is remap the caps lock to the escape key.
Because it's much more comfortable to press it with my pinky finger. But what I can show you is if I go to the RAID settings and I press A, you see the key is repeated very fast.
If I change the setting and press A again, it takes somewhat longer. Another thing, as we have seen, the framework for resource multiplexer is also part of the ZX system.
But we can change the configuration of the framework quite easily, the multiplexer. Here we have different domains and as you can see there is one domain that basically just hosts the pointer. And another domain which hosts the light central and so on.
And what I can actually do is I can change the origin of one domain. For example, if I just change the origin of the light central domain to the pointer, suddenly the light central follows my pointer movement because it's anchored to the pointer position.
And as I've said, there is some global policy in the static system. And here you see the global key management. For example, when I open the input filter again, as you can see certain F keys are remapped to other keys.
And those keys are used in the global policy to trigger events. For example, if I press F12, the light central will fade in and fade out. And that's basically how you can configure your system.
Alright, let's go back. Finally, let's look at the runtime subsystem. The runtime subsystem is actually the subsystem where the user runs its applications. For example, the virtual machines, the web browser, the editor, the POSIX subsystem and so on. It is also managed by the Skype Manager, but it can also be controlled by the user.
Namely, the user can change the deploy configuration file. And now I just closed the PDF here, but it's fine. I'm actually already in my deploy configuration file and you can see that there are also already a backdrop.
So let me just close the component. Okay, so the backdrop is gone.
And what the user basically can do, the user can select the components, the programs. The user wants to run by just editing the configuration file. And what we can do, we can just spawn some nice...
There's the backdrop again. Just let me remove the backdrop once again. Because I just wanted to show you the program which draws some objects.
And we can edit the configuration file that is used by the component to... In this case, we change the config file to use another painter for the configuration.
For the component and now the component uses another painter to paint itself. Let's start the backdrop again. PDF viewer.
So for now, what we have seen so far is how I can start already installed components or programs for that matter. I now want to show you how you actually can install components on the Skype OS.
To install software, first we need a location where we can temporarily store the archives we are downloading. We need a location where we can store the installed software. We need the source where we can download the archives from. And we need a public key to verify that the archives we have downloaded are actually properly signed and not tampered with.
So it's your basic package manager workflow. In five steps, you install the software. What's noteworthy here is that on Skype for that matter, it's also a subsystem which is orchestrated by the download manager.
And the way it works is that we first look for all the missing dependencies. We look up the information we need to find the source of the missing dependencies. We fetch the missing dependencies, we verify them and we extract them.
But what is normally done in one program on traditional systems is done in Gmail in multiple components or programs basically. As I said, the download manager controls the subsystem. And at first it will start the depot query component that will look up the missing dependencies.
It will therefore look into the file system when normally the software is installed in. That's basically the depot directory. It will then look up the missing information which is also stored in the depot directory.
Afterwards it will replace the query component with the fetch URL component, give the component access to the network and write access to the location where the archives are temporarily stored. But it can't access the directory where the software is installed, so it can't tamper with already installed software.
Even if there is some bug or somebody exploits the component. After we have downloaded the firewall, we will replace the fetch URL program with the verify program and we will cut our network connection. And we will give the verify component only access to the archives that were just downloaded.
And after the verify component has verified that the archives are actually sound, the download manager will start the extract program which will extract the archives and write them to the proper location.
So, in a sense the installation and deployment is a new one. The depot is just a cache that holds the files. I can actually show you how that looks.
For example, if I move into my storage device and there is the depot directory and there you see multiple directories. For example, in my directory you will find the download file which contains the address where the archives are downloaded from and my public key.
And there you also see all the, let's just do the recursive thing. You also see that all packets are versioned so you can install multiple versions.
In case a newer version has some missing feature or has some bugs or something like that, you can roll back to an older version by just choosing to run the older version in your configuration file.
And while it's a user defined policy that means that there is no automatism that updates something or tries to run a program without the consent of the user. We will just skip that part and we will come to the roadmap for this year.
By now we have some iterative process where with each Skype version we introduce new features and the next version which will be released in a few days will contain some visual composition feature.
I can tease it a little bit because here you can see some components that are already running in the... Let me make that a little bit more clear.
Right. Here you see some components that are running in the runtime environment and if I click on such a component it will show me how much resources it's currently using
and we hope that at some point the need to open the shell to interact with the system is reduced to a bare minimum but the graph is the key feature in the scope PC release at the end of August.
You already can download the system, you can build packages, you can publish packages but so far the tooling is somewhat lacking for a community to foster around the Skype system. And that we hope to address by the end of the year with our release in November.
More details you can find on the roadmap. So far that is it for my part. I hope I don't have rushed too much. It's actually fine.
So thank you for your time and if you have questions please ask them. I'm not sure if I got it quite right but the slide would be tree based. Yes.
For example if applications are sharing a screen blocker they always have to communicate with their parents upwards until they are up to the tree. No, no, no. The question was if multiple or two components want to communicate with it
if they have to traverse the tree basically every time back to the root of the tree. No, they don't. They have to initially because the parent provides access to the grandparent and the other components
but after you have established the connection, basically you exchange the capabilities, both components can communicate directly with each other. So you might have some, if that was your intention, you have some latency when you first request the service because obviously you have to traverse the tree but later on you can basically communicate without any latency.
Alright. Another question? Alright. Thank you for your time.