 I will start now. Thanks for coming. I know I've been talking about the open-to-the-base system, so probably nobody has heard this term before because we just invented it. So I will start with some motivation and then talk about two different parts of this base system, namely with one part that we called base column build. This is actually a project I have in the open-to-the-base service, just like you see in the description. The other one is base column install, and then I will briefly talk about the hacking project we did two weeks before. We developed base bootstrap, which is basically a type bootstrap code for open-to-the-base system, and then some nice packaging advice that fell out from that project because we have some broken packages which are usually making your images bigger and stuff like that. So the usual problems. So what is the motivation? The motivation is to care a little bit about the core part of open-to-the-base. So all the parts that are not colorful or moving or making sounds, which is usually where people spend more of the time, because it's, of course, very not appreciated if things start moving or making sounds. So if you care for the core part, it's often hard to see the benefit, but it's still there. Of course, somebody needs to do it, and from time to time you'll get an inch, which creates a few and then you will open it. So it's like an ongoing project for now, I think, two years. And so every week, maybe we will work on it a little bit, which is actually the first one we started with is to look at a base code and build which originated in the idea to reduce the number of packages we install into our auto-build changes with environments. So like, before we did that, we, for example, by default installed our strange stuff that usually nobody uses, but of course packages had started to depend on them being available. Like, the VI existence was actually necessary because at the moment we removed it, we got like for one package, I think it was I don't know, but it detected, oh, well, as we are available, it looks so useful as my default editor. So, actually you get interesting dependencies of our RPMs on the installed set of packages that are not in the built-in files. So we thought we need to clean that up and identify sort of a small set of packages this way where you don't need any other packages to build these packages. And this is of course one way to identify what is more powerful and suitable. And the motivation at that time was to first reduce the build time because as in auto-build and also in the build service we are doing bootstraps of bootstrapping of packages. And once you have cycles in your build dependencies the packages can rebuild over and over until there is no change anymore. So if you have lots of dependencies with lots of cycles the build time usually is very large. And of course for small packages the most time you spend is actually setting up this build change rule. So if you reduce the amount of packages you install there you will get faster boot faster package build times. This set of core packages is also the set where you would need to cross bootstrap somehow if you want to bootstrap on a new architecture like if you have ARM or not that many new architectures these days but it's probably mostly interesting for embedded architectures. And on the side note there's maybe you know that Linux from scratch so this is basically building up your Linux distribution from source scratch and this basically from the set of packages you need to build manually this is exactly that set of base build because if you have done that then you can use our regular build script and just automatically build source packages but you need all of them to start with using build that's then open to the from scratch. So how does this build look like? At the moment I say at the moment because it costs changes if people have dependencies or packages get split packages get removed it's 80 source packages and 264 generated final packages there's still stuff in like gtm and less maybe so the thing on dependency is because we run some test suites which require djgnu which requires tickle and gpm is I think I don't know but it's oh yeah right because it has gpm support so it needs the library and less is there because we require man to be present because that is the only thing that sets the man path so otherwise the script that compresses all the man pages afterwards wouldn't find the man pages so that's a more interesting dependency and this actually takes about half a day to bootstrap in the build service but this is of course because in the build service you have only one cpu per package and there are packages in like gcc gdpcd and automate which require on a single cpu quite a lot of time to build so this is actually the dependency graph of this base system as I can speak a little bit so that I can read it and actually read it I can read more so I see there's stuff like utility notes so little I only read it but I can just now those packages we always install in the build rule and they of course have dependencies and build dependencies and so you get for example this always install man and for that reason it gets to this because well man wants a pager the blue ones are actually those that have sources and the regular bank ones are the generated binaries so for example from the gcc for sweet package there are generated a lot of sub packages like aida and the other ones are somewhere down so this is actually not all dependencies but it's all dependencies but the graph is transitively reduced to a reduced amount of errors because otherwise you wouldn't see anything because everything requires gdpc for building and everything requires a compiler for building so yeah, it wouldn't make any sense so I'm all gcc packages below you can also see that we require of course cat text and technical for building because we have like technical man pages and translations there is of course bash because in every change rule you need it and there's basic set up stuff like the file system which is setting up 4 parts of the build rule enough for that so what's now the basic install part the basic install part is the opposite of the building part so we are not no longer interested in build dependencies but only in dependencies that get put in an install time that is what we want always to fulfill all our dependencies so that you in the end could install the basic install with a single rpm transaction without a complaint not just unpacking the rpm into some directory but using rpm for that and of course for install we are interested in the size of the install system because if you want to install an embedded device and you only have like 64 megabytes then you only have 64 megabytes of flash one thing we use the install part for is of course again for setting up the build rule because there we install all the packages and also install the dependencies so by doing this one for example don't need up here itself in principle because you don't need a package manager in the install system if you don't want to install additional packages so in principle everything that this magic package AAA base depends on should be that minimal system so this AAA base is I think it's for historical reasons named that way so I don't know if it's true but yeah it's basically a sort of a hook package to provide initial stuff like there's an init tab inside there is some strips that massage a distribution updating stuff like that as well as a magic package so if you look at the dependencies of AAA base then you can see for example that you get a console port put in through a login program and you get interesting you get UDF for device files you get CPIO I don't know why you get CPIO probably I don't know and we get info because we have info pages in the system and we're in the post install rules we require of course info to update the directory and then we have some probably mostly script related users of fight utility we get call utility you can do ls and stuff and of course you get a bash also because there are scripts inside so if you install all these dependencies of AAA base you will need to end up with a change route where you can change route into your shell you can basically find some operations so this is exactly what it was but it's still 35 megabytes in size so it's pretty big so the biggest part of that is 10 megabytes of translations for call utility I have the rumors that this is already fixed and it's split to a separate package and then it's just ending up there are no other big offenders left so for example in former times we only had one cracklet directory and because of configuration it requires another cracklet it was another 10 megabytes of direct dictionary file but now this one is empty if you not only want to change route into such a system but also want to boot it and maybe log in then you will need to think about putting a kernel in an RDA and that should be it if you again have this AAA base so in the install system itself you don't necessarily need a kernel as an RDA if you want to boot over network you can just fetch all these things over network you also don't need to build this unit RDA inside package one thing we have done in the Acme project to sort of better split the unit RDA building from the install system and the same is of course also true for the boot loader so you don't need to install directly to the system you just have to boot over to have a bootable image so if you add the kernel to this one and then you will get something like this as the kernel requires to incarnate already so when you are in it all the kernel modules so our default kernel is basically everything split into modules where possible you need some more scripting stuff that is otherwise not required in the AAA base packaging but this adds another 73 megabytes because it adds about 60 megabytes of kernel modules and this 60 megabytes you wouldn't necessarily get rid of if you take out the kernel image itself from the system because if you want to like so called USB port plugging you would need to the kernel modules on demand so you have to have them install the system somewhere now let's look at how bad things get if you choose to add for example the OpenSSH or DHCP client for a machine that put it to get a network address and they can then remotely log into it actually only puts in all the SSL stuff on the OpenSSH and there should be somewhere there oh yeah right OpenSSH also requires pvd utils for some reason pvd utils is where stuff like changing your password changing your full name all this end up related stuff which also means that you get in the add up libraries and that's actually not very bad that's about 20 megabytes to the database system or you can maybe add an X server so you have an X terminal small window manager after that so if you add X server where the XTM and X terminal stuff nicely just put in my dependencies from if you install the X or X 11 server package and you get a whole lot of X related packages that you don't put in a lot of other stuff this adds up 206 megabytes in total but this is with all the kernels so if you have a kernel inside the system then you get this another 70 megabytes but it's still not bad but for a 64 megabytes device it's already too much like fonts which probably add a lot to the image size here and once you pull in for example our smallest window manager I think it's the ICM we like then you get also desktop backgrounds which is like 10 megabytes of jpegs so it adds another 60 megabytes but it would still fit on today's average size USB stick which would be about 2 megabytes I think so that's already nice so what you can see is that it wouldn't be possible for example at that point to somehow weaken the dependency on all this desktop data maybe get rid of it completely and shift installing of that to some other magic package which for example could provide some product specific configuration or install stuff also what we saw great here we open add up support which is built in into PDU tools hopefully maybe modularized out so that if open add up is not available the binary is still would work but just with open add up support so in the HGIT project we try to build portable systems from so simple page selections to just a test if you select this A base in the kernel if you actually can log in so if all requirements are really written out in the RPMs and if you remove some if the system still works and so we in the Wiki created this like Wiki page where we summarize also the fast work and especially the base bootstrap work and then the base install package contains an image builder this base bootstrap script which is similar to that bootstrap where that only sets up a timestamp hierarchy with some packages but also a script just call a basic install that builds and would build images at the moment we build just queueing normal images for other images you need to manually configure the modules you want to load into the HRD so you can find your artist control and stuff like that yeah this is the base bootstrap script you can actually use that also for your post-inst scripts and your pre-recribers because we set up everything in one RPMs transaction for example you can see that some packages call your name but it's not yet installed you can see all the errors from the install script you need to go over these and fix the packages that we found doing that and yeah the base install builds the image so demo prepared demo I do have already took that image so this is an image which only contains kernel the incline ID and a base what I'd like to show is after for example we can see that gcc is not required but gdpc complains that p3d cancels will not work that is the case but nobody requires it so fully it's just a false warning to even start installed and to use everything it could be and what you can see the system is about this 100 megabytes and the biggest offenders are user and lib and you can see the kernel modules with 64 megabytes not so interesting to look into maybe use a share and this is actually the dope case and I already said it's only about 14 megabytes but these are the biggest offenders and the rest is really spread out probably single useless documentation files stuff like that or binary sweep you really don't need in such a basic system it's not too much in flash bin I'll use a binary sweep already I can show you if you are interested on my own laptop afterwards outside or tomorrow some more images with more interesting stuff so what's the result of this project it's more or less that for core packages you want to use slightly required for example you don't want to require audio bits but for example in cp stuff like that to be able to just throw a busy box into a repository and get that automatically substituted for audio bits with the audio bits and you want to prefer c programs in any of the pictures I showed you earlier for the c++ standard library which would add I think 4 or 5 megabytes with all its dependencies so if you can avoid c++ then it's nice and you also want to restrict your splits to bash maybe also perl but please only comp parts of perl so we have actually split the perl package into two to a base package which is I think 2.5 megabytes big but if you then use more fancy stuff you get the full 50 megabytes perl package so if you can encode it in bash even if you like more do it with a normal shell still and also post scripts in core packages should be avoided if possible if necessary post scripts you really need to audit your scripts that you insert all the required pre-requires and possibly not create cycles in that case because if bash pre-requires bash then it's a problem because it might work out and of course split your packages like I think Dirk has split the translations of all your scripts into a separate package which would get rid of 10 megabytes in that case or common modules could maybe be split on the common int package or maybe could even split common modules on topics so everything that's not what plug related we could omit from installs that have to come and then you don't need it outside of the system so with shell library policy there are still lots of packages that have a library that is the only thing that is required for a package but you also have some fancy binaries in that package that require in turn a complete other stuff so package or shell libraries make sense of course and this is actually something we thought about like we ship a standard configuration which requires for example REST manager and Stratlip and some extra PEM modules and lots of stuff it would be nice to split out such default configuration from the package in that case PEM because I'm on a magic package that would be customised for like a product for example we have the NIDA Bs in A base it could also be customised in 5 minute package I don't know why it's not there because why it's in A base it's in the end of this so the thumb configuration so actually both dictionary packages provide I think correctly ticked smaller and actually ticked full or big and our package so and our finished over for that it has actually the policy to prefer the smaller if it has a choice my my yeah so it would be of course a policy that could be enforced also for the subculture maybe about package install sizes I don't know if that's in the sort of files but you could if you have a choice prefer a smaller one or you prefer to be more fancy and you look at the requirements put in from that decision and solve for the smallest complete system size which I don't do I only look at individual package sizes but it helps in most cases you could do that and it's of course it makes sense if you want to build smaller I think it isn't at least if you are an Intel hardware the difference shouldn't be too big so also all these numbers included complete debug information because in the build service the debug information is not scripted I was wondering because I created a better model of the system so I could I remember most of the data files okay that could be but that's a reasonable difference that would be like 20% something like that it's maybe a little bit less because data files once your system gets bigger they start to do you have an estimation what is the smallest possible size so if you leave away the debug info you can leave away all the useless documentation fonts background images well I can remember in former times a bootable Linux system fit on a floppy disk nowadays oh no idea it's 64 megabytes it's just a target well 64 megabytes should certainly be enough if you have your kernel external you have to run an external I think it's completely reasonable to expect that to be enough it will work out distribution which builds base system which exudes all these info so you draw all those quantities on things like info for example and then build distribution based on that distribution well actually embedding does stuff like that so they don't build any documentation they also think it excludes all languages but one by default stuff like that so it certainly would make sense for a specific product if it's really space constrained and you hit that constraint and you try optimizing it but you can also use again if the documentation is properly marked you don't need to install it I don't know if you can get rid of the post-inscript requirement easily but what do you require info I said pre-requires I don't know if you can disable that and install it of course yes so we cheated at one point the base release packages was always seen there because otherwise you get full per but you don't need per root load because we don't build in it already so this about users requires do you see it as a separate requirement or did you ever try to think of building with that would touch more than it requires so you could try mirroring the base builds thing and substitute for example new celibacy and see if everything builds I am probably not but yeah maybe or you can for example substitute added up with nothing to get rid of add up support stuff like that so it should be fairly easy to do in a build source to experiment with that by editing the configuration and building against for example use celibacy and stick in for example with inbox and see if we have strange scripts that require more than classic compliant commands I meant we have but I think that's also I don't know it's still live it's Microsoft's project so it's probably something that could be revived for people that are interested and actually have those embedded devices to try it out and you can also look at that embedded basically they know also very special things aside from that so they rebuild everything every 200 packages they use some magic stuff it's only sent to us building a really really tiny script based system and build service then it has all these packages built without any experience and then it rebuilds them to build the actual ones that we just could really add up as soon as you see both a bootstrap whatever minus info creates itself with the info completely there and you might get a 50 megabytes image which you can use as a base build so what I think was Jan Blum was working with me on that and he's probably looking at all the maintenance stuff related to our products like Sincline stuff like that which also have related problems and are solving them like in a manual way by selecting individual files that go on the QB image so it's probably we should just try in the base distribution to get rid of the easy things and once you start running into the progress way to rebuild with different options then I think we can think for example of providing a base set of packages with reduced dependencies in a build service as target you can build for that's a good idea actually we can prepare our spec files to some width and we're going to build with something and without some other projects that we make it awesome just without any environment like standard names for end up and just ignore it for that project something like that and that's why I used the interactive because I thought there was some flag that was being passed so I didn't think the interactive actually includes both RPMs it's more of a big normal question and one more question QB Well it's not possible it's probably possible in the build service I think that the current script for building the images just run strip of all the system before finally building the image but of course in the end the build service needs support for debugging for packages which would then strip for debugging you compare the size it's only about 20% so it would reduce the A based system from 35 megabytes to 30 megabytes QB Just the image size which results if you strip or don't strip so it's only C cost usually debugging for something