Okay, my name is Johannes, I'm from Genote Labs, and I want to show you a tool for developing
applications for Genote.
So I think Genote has been present in the micro-conadero room every year, I think, since
a couple of years.
So I don't think it needs much of an introduction, but I have a short introduction here.
And I'm just irritated because my slides aren't complete on my laptop, and it's okay.
Okay, on the presenter.
Okay, so the Genote OS framework has a component-based operating system, it supports different micro-conaderoes.
So I would actually like to switch contacts after a lot of Unicernel talks today.
We're talking about micro-conaderoes here, but I'm not going into technical details since
it's the last talk, and since we actually want to look at how we can develop applications
for Genote.
Yeah, it quarterly releases since 2008.
And in addition to the framework, we have a showcase that's this GALT OS that's based
on Genote that we at Genote Labs actually use as a daily driver.
So I'm actually running it on the system right now, so you see a control interface here.
I will demo it later on.
So back to my slides here.
The GALT OS release roughly twice a year.
So what was the motivation behind GOA?
The tour I'm presenting here.
So the Genote build system, it's very useful and efficient and robust for developing on
the framework.
But it can be a little bit cumbersome for our development, so we have to do a lot of
things and there's kind of a learning curve.
So if you occasionally get into Genote and want to try some applications, then it can
be a little bit off-putting.
So GOA, the name is from GOAL, but reached a little bit sooner.
It was started by Norman who's sitting in front of me in 2019 as a site project.
And last year we moved it under the umbrella of Genote Labs.
And since then it has seen quite a few additions and features.
And as already mentioned, its intention is to streamline the development of individual
applications for Genote.
Before I go into that, I have to tell you something about how applications are deployed
on Genote.
So the package management is made up the way that each user manages its own depot.
And depot contains different types of archives.
So for instance there are API archives which contain header files to use a library.
And then there are source archives which contain the source code, obviously.
And then there are the binary archives which contain the compiled binary architecture,
specific binary corresponding to a particular source archive.
And then we have such things as raw data archives which contain just raw data architecture
independent, so no binaries.
And then we have package archives which contain the runtime information.
So the information you need to actually start up an application scenario.
And it also contains a list of the required source, raw, and package archives.
And then we also have an index which is a list of users, packages, or package archives
that can then be used to, or can be deployed to, in scope you will see later on in the
demo how the index is used to actually install applications on the system.
And the archives are simply placed in corresponding sub-directives according to the names listed
here.
And now I want you to keep in mind that a Goal project basically resembles the structure
of these people.
I'll get back to that in a couple of slides and show you.
So what's the actual workflow?
So here's the very simplified application workflow with Goal.
So first you import, or you may want to import third-party software.
First import the source code and maybe also patch it.
Then you want to build it using the build system that comes with this third-party software.
So just reusing a commodity build system.
Then you want to test or run it on your development machine or another machine.
And if this works well, then you actually want to export and publish it so that other
users can run it.
So Goal now is a command line tool which basically has commands for all of these stages shown
here.
And here I will walk through these wide away.
So when it comes to importing third-party source code, in order to make this Goal import
run, we require some files.
So first of all there's an import file which actually describes what you want to download
or what you want to import.
And this then actually populates the source or raw sub-directory.
Here's a brief example.
So this import file is basically a makefile syntax which defines a couple of variables,
license and version, and then what you actually want to download.
And there can be a list of the syntax.
It has a name and a type.
Here the name is Calc and the type is an archive.
So a table.
And there are other types supported.
You can download from Git repository, SVN, or a single file.
And then you specify the URL for the archive to the char or for Git it would be the revision.
And you also define in which directory it goes.
So it can be the source directory or the raw directory.
And you are also able to patch this here.
I haven't shown this, but it's all documented in the intro documentation.
So just type Goal help import.
And you get a man page style help which should clarify how to use it.
Next step after having the import we would build the code.
So Goal build just builds the code which is present in the source directory,
whether it's imported or whether you wrote it on your own.
What you also need is you need two files, a used API file and an artifact file.
So the used API just says which APIs or which API archives you depend on
and the artifact file names the build artifacts that you want to include in your binary archive.
We have a couple of supported build systems here.
So just plain can you make or CMake or autoconfcumake.
We also have some Rust support with cargo and it's extensible so that you can add your own build system
and this list will probably grow in the future.
And there's also a couple of other files which you see on the right.
So like configure arcs or make arcs by which you can control or add some flags that you need for building.
So the next step would be to test run the scenario.
For this we have two more files that we need.
So there's an archives file and the runtime file.
You can actually have in a Goal project a multiple runtime scenario.
So there's a sub directory structure that you see on the right.
And then archive file lists the archives, the depot archives you depend on.
And the runtime I won't go into detail but it specifies how the...
It specifies the runtime scenario.
What I want to go into more details is supported targets.
So by default you can run the software and the host system which leverages the fact that the denote executables are binary compatible with all the supported kernels that we have.
And part of this is also the Linux kernel so you actually can run the denote system on top of your host system, your Linux system on which you are developing.
And then the component is just pop up as Linux processes.
And a very new target is the Sculptarget.
So we have implemented a method to synchronize all the required files via HTTP server to running Sculptarget system.
And thereby remotely run your application and test run your application on the system.
So let's have a look at that.
Here's my Linux VM.
I think the font is big enough, right?
So here I have a project that's a calculator app imported from the Lumre UI toolkit which was formerly known as the Hubo2 Touch UI toolkit.
And let's have a look what's in the directory there.
First of all there's the import file which I'm interested in.
So I don't have any source code here so I need to first import it.
But since Goal takes care of doing the import step before the build happens, I can just try Goal build.
It downloads everything needed and then builds the application.
So what I have then is IFDSource directory which is popped up.
So the source code is imported into the source directory.
Next I can type Goal.
My G is actually a bit...
Okay, Goal run.
Now I see the window opening and now I have the calculator up here.
So as I said before all the components are now running as Linux processes.
And as you see it's pretty slow because there's no GPU acceleration in this scenario.
So it's barely usable for actual debugging in this case.
But what I can do is I can also run this on my scope system that I'm using here to present.
So let's switch to that.
For this we have a Goal testbed here which we have available in the sculpt images as presets.
I cannot do this right now because my VM would then turn off.
But I have a launcher here so I just launch this testbed.
And then I add the argument sculpts.
What I haven't mentioned here, this tool has bash completion.
So I can actually spear some typing.
Okay, let's switch over and at some point...
I'll show you.
It still needs to sync the files via the HTTP put to the HTTP server that's running in this Goal testbed subsystem.
And now here we have the calculator.
And all the log output I still see on my host computer.
So it's quite useful for development and testing.
Alright, so let's say now we have everything working.
Next step would be to publish it.
So exporting, I'll leave it...
So export just assembles the poor archive.
And publishing then means that we make a signed tar archive out of that.
What we need for that is for each of those runtime scenarios that we have,
or for the runtime scenario that we want to publish, we need to readme.
And we also need to license file and diversion file.
And yeah, that's basically it.
I'll just show you this in the demo.
So let's have a look at my version.
So I want to publish a new version of this.
And what I'm doing is we have a helper command here.
I can just bump the version and see it's updated.
Oh no.
Oh no, it's updated. It's just the same thing.
So it was the third of January and now it's the third of February.
I can actually do this multiple times.
So it just depends on some letter to the end of the version.
Okay, then I go into another folder where I'm managing my index.
And what I want to do is I want to add this into my index.
So the index is just some x and l file here.
So I'm adding this here.
I'll calculate that.
And now I say publish.
And since I already have an index file, I have to specify that I want to overwrite that.
And wait for a moment.
So it says it exported the calculator app with the current version.
And now the index, I need to put in my password.
Alright, that's it.
And now it's published only on, and it's present as an archive on my laptop or NVM.
And I still need to sync this with the web server, which I'm doing right now.
Which can take a bit depending on the network.
Alright, all is done.
And now in my control system, or control UI here, I first need to enable my user depot,
fetching the current index.
And now I'm able to, there it was, there.
I install it.
Okay, downloadable.
Then I have to, when installing the app, I need to root the services.
So it needs a GUI service, which I wrote to the window manager.
Then I need something for the GPU acceleration, another thing for GPU, system clock,
and also something here, and edit.
Alright, there it is.
Okay, we calculate again.
Alright.
So the process of all of this, or the development work, is documented on our community blog,
which is called genodians.
Genodians.org, so there you find user stories about the development and how to use things.
Also, as you see in the screenshot, how to use this GUI testbed, I just showed,
and what was involved in porting the calculator that I just showed.
And yeah, more interesting things.
Also the very bare basic tutorials, which go into more details of using GUI.
And with this, I want to thank you.
And to get started, just clone it and have fun.
Thank you.
We can allow one single question, I think.
So thank you for this token demo.
It reminds me of the BSD port system, of course.
I have a question.
Did you pick the calculator because it doesn't do anything fancy like saving files,
and if it had, what kind of patches do you usually need to sort of a real world application to genode?
The calculator, I used it because there are other simple scenarios with not many additional libraries needed.
And on the other hand, it uses the Ubuntu UI toolkit.
So there's all these cute stuff already in use by that.
But it's mainly used because it's a GUI application and it has a narrow scope in porting efforts.
So I don't have to show too much details.
So that's the reason for that.
Yeah, we have more complex ports, actually.
So we have a LIN phone port quite recently.
So yeah, there are more complex ports already available.
So as you see here, there are also these projects repositories to check out.
It's on the one hand the GUI playground from Norman,
and then from me and a few colleagues, the GUI projects repositories on GitHub,
where you find ports of wirecrack, doom, chocolate doom, and things like that.
So there's a lot of things you can play around with.
Thank you, Johannes, for the talk. One more time.
What I forgot, we also have some takeaways here.
So we have these books, the main genome manual with all the concepts, the genome foundations,
and then a documentation of how to call genome to other platforms,
including peripherals and all the heart and fan system.
Thanks, so don't hesitate to take it.
And I would like to thank everybody, the speakers, the participants, the audience,
for participating in this year's microkernel and component-based West Dev Room.
And hopefully see you next year again. Bye-bye.