 So, I will just be very short and introduce Wookie, who will now give you an embedded Debian presentation. Wookie. Okay, hello everyone. So, I work for Alhaf1. We do embedded development for anybody who will pay. And we try and base it on Debian when there are letters. I've been interested in this for a while. I'm normally project leader for the last three years or something, which means very little has happened in that time. But I'll tell you where we are and where we're going. How many, before we start, how many of you already know all about embedded development? Well, you know, are interested, have done some, know what we're talking about. And how many of you, this is a kind of new area and you've got some widget, you just think it would be cool to put Linux on. Okay, a few of each. So, to some extent I've got you here under false pretensives today. The talk was billed as it was suggested to me in fact by Lars Visnius that what we should do to encourage Debian to support embeddedness would be demonstrate all the cool things you can do with embedded widgets and how easy it is and why we should all do it. So, I thought that's a good idea, but I've just spent. So, the idea was I'd sit here and show you how to download the tools and install the tool chain and configure it for cross-building, build a kernel for your little widget, download all the sources and then explain about how cross-building works, build a root fest, stick it on the machine and it would sing songs or whatever. And you'd all be suitably impressed and could go home and do it yourselves. So, I spent the last week doing that. We got as far as installing the tool chain, that worked quite well. Fixed a couple of things, configured for cross-building and try and build things and nothing worked at all really. It was all a disaster. So, the current state of the tools is that lots of things don't work. If you want to do, as I just described, then go and use Scratchbox or Open Embedded because they actually do work. If you want to try and do it the pure Debian way, it makes life difficult. For some reasons, I'll go on to explain. So, what I'm actually going to talk about today is, say at Plan B, the reason why I haven't got all this working and marvellous and beautiful is that I spent most of the last month fighting software patterns and not preparing this talk or working on embedded Debian or anything else I was supposed to be doing. So, that's my excuse for any disorganisation that may occur in the next hour or so. This worked quite well though. So, we had a major success on that front. So, the backup. This is what you'll get. I'll just explain what embedded Debian is for those of you who don't know and tell you where we've got to and explain some of the pros and cons of this approach. What we're trying to do, how it's supposed to work and what we need to do next to actually make it work. One of the things I want to... We kind of got into it in the previous session. I don't know if there's anyone who's here who wasn't there about why Debian supporting embedded stuff more than it does now. It's probably a good thing for everybody. So, embedded Debian is an official subproject. It's all very exciting. The idea is that lots of people who are already familiar with developing the Debian way they use it would like to just be able to produce a mini version for a specific purpose. There's an awful lot of companies like mine that people who don't know about embedded systems realise that they probably want to use Linux on their hardware. They need easy ways to build a system with this stuff on. Alternatively, we build them a base system that they can put their special thing on. As someone mentioned this morning, people often have a great deal of expertise in their particular application area that they really don't know about building basic Linux systems. In principle, Debian ought to be a good base for this kind of thing. Partly because of the multi-architect support and all the tools we've got. The other thing, of course, is that it all has to be proper free tools, none of this Montevista and their secret configuration system which is proprietary. Started in the year 2000 by a guy called Frank Smith from Amarix who thought, basically what I think, that this would be a good idea. They produced a tool chain that worked for ARM and PowerPC, I think. Also, a handy tool called, I'm sure it should be Mdebsis, which is quite primitive, but it's also quite neat. Basically, you use the kernel configuration language and extend it into user space so you can configure which tools you want, whether you want ping or mount or whatever. Then it just goes and fishes the relevant binaries out of the Debian archive and puts together a root of s. The problem with that was keeping it in sync with the changing packages was a real pain, so inevitably it got left behind by both the kernel and Debian. Also, it was written in CML2 which never made it into kernel favor, which put it at something with disadvantage. It did get updated to the new kernel config language and people have used it for real commercial projects. It works. It's arguably one of the best ways of producing a really small system is positively fishing out the binaries you want as opposed to building packages and throwing away the bits you don't want because it guarantees you don't end up with anything. You didn't really, really need. Since then, we basically started again with a new scheme using d-package cross and a thing called the stag framework, which is basically the work of Philip de Swert, who unfortunately isn't here today. We've been fiddling with that for a year and a half now. There's also been new tools, which is mostly the work of Nikita Yushenko. People used to use all sorts of cross-compilers from all over the place. It would make a lot more sense if you used the standard Debian source. Somebody did a thing called toolchain source, which was a package which was basically just the toolchain source from which you could build a cross-compiler, which is all right, but it tends to get out of sync with the compilers people were using in the rest of Debian. Obviously, it was much smarter to actually build the cross-compilers from the same source package that we built the normal compilers, which after all is something that the upstream source can do, so our packaging ought to be able to do it too. Nikita fixed all that, so now we can build cross-compilers for all Debian architectures from the same source. They may even work. They're all available on mdebian.org. Obviously, increasingly, for a long time basically you wanted an x86 compiler to whatever target you want to use, but these days there's more than one fast development machine you might conceivably be using. Hopefully this week we'll get the PowerPC and AMD64 development host versions working, so you'll have from all those three fast architectures to all the weedy small ones. Now, we don't want to put all of those tools in Debian because there's an awful lot of combinations you can work it out, an 11 factorial or something, which hardly anybody needs, especially all the ones, like you really don't need a cross-compiler that runs on-arm and produces x86 binaries, that will be dumb. So trying to put all of them in the Debian bucket is just a waste of space really, so we'll just host them on mdebian.org or somewhere useful. So reasons why Debian isn't really where you want to start, it's all built natively, and there's good reasons for that, and it's simple, that's the way everything was designed to be done, but embedded developers really don't like natively building. I mean, you can do, and indeed it can be quite practical if you have a fast enough target machine, so if you've got a fast-arm box you can build your arm binaries on that, and it does save a lot of aggravation, and that's how quite a few people I work with actually operate. You can buy 600 MHz arm desktop box, which will compile everything pretty slowly by modern standards, but still fast enough. But in practice, most embedded developers need to be able to cross-build things. Normally Debian doesn't care at all about the size of binaries, however we care a little bit, but basically eight people go. You can't buy hard this small than 40 gig. Why are you complaining about a couple of 100K here and there? And the answer is, of course, because that thing's got 64 MHz of flash in it. So your entire file system has to fit in 64 MHz. In fact, it's got to fit in 60 MHz, because you quite like some data of your own. So there is a dramatic difference. I mean, embedded used to mean 32K. These days it means less than 32 MHz, so it's got a lot bigger, which is why Linux has become practical in embedded systems. In your average standard Debian package, there's a whole load of stuff that you don't need on your average embedded system. All the documentation, most of it, example files, Vim colouring schemes, 27 languages that you aren't going to use, all that sort of thing. So you want to be able to get rid of that. And by default, we tend to enable everything. So if it's possible to use something with X, then it will be compiled to do so. Or with some fancy font mangling system, or whatever, all of that stuff. And again, people want more control than that, and often might not on a lot of systems. There is no display. You don't want any of the X versions, but you still want the underlying functionality. Reasons why Debian is good. The code base is nice. Everything's consistent. Files are where they're supposed to be. I mean, that's why a lot of us started using Debian in the first place. I know I used to hate Red Hat. But it was a great revelation to find that config files were always actually in slash ETC, where they were supposed to be, and not somewhere bizarre. All that stuff. I mean, to some extent, I think that has gone upstream, and the world's a tidier place than it used to be in 1997. But even so, it is nice. And you know it builds on all the architectures without aggravation because we checked. The multiple architecture support's good. A lot of the targets people are actually using embedded systems supported in Debian. Not all of them. People do use weird stuff like SH4. Actually, we got an SH4 build. People had one for a while, but I'm not sure it's defunct. But in practice, most people are using ARM, or PowerPC, or 68K. Or X86, of course. And our management tools are quite nifty. If you start to look at how it all works, we can in fact do most of what's needed in terms of cross-building and installing packages, not to the default file system, but to a target file system, all of your own, a charoute, or whatever. It's all there. And it's a matter of bringing together these tools so that it works in a coordinated way. As we were discussing earlier, we quite like having derived distributions. It provides useful ideas and feedback, and gets things fixed that wouldn't otherwise be fixed. And the familiarity of developers is one of the reasons why they quite like to be able to use something like Debian on their small devices. Not exactly the same, but having a lot of the things they used to. So people who don't come from that background are quite happy to use any strange embedded system you give them, whereas people who are just used to Linux looking like Debian, or like their other boxes to behave in a similar way. So that's the main target, I think, is people who are already Debian users, but do embedded things and want easy ways to prototype systems. Embedded Debian probably isn't the best way of producing general production embedded systems. There's something like Open Embedded. I think we'll always have much finer grain control over what you can do. Because absolutely everything is possible within that framework. But it is horribly complicated, even by our standards. And it will be nice if we could produce something that will let people prototype stuff quicker and easier than that. So to make this work, we need a scheme to cross-compile things. It doesn't break horribly. Dealing with optimisations, generally things are optimised for speed, whereas for an embedded system, you probably want to optimise for space. And in fact, it might go faster anyway. There's arranging things so that you can manage the packages on the target device, which of course aren't going to be the same set of packages as on your host device, a build device. There'll be a small subset of them. And as we'll talk about later, these are actually a slightly different arrangement, potentially. So you need some mechanism to say which bits you want. Splitting packages up into smaller pieces helps a lot. So you have all the languages split out into a separate little language package, and the docs split off, and the X versions split off, and so on. The finer grain your package management is, the easier it is to get the bits you actually wanted rather than a whole load of stuff you didn't. One of the things that we kind of think about regularly at these events, but haven't reached final conclusions on it, I don't think, is the packaging namespace. So if you take Debian installer as an example, that is basically an embedded system based on Debian, but it's designed to live in the same namespace. All the Debian installer packages exist in parallel with the normal packages because of what it's designed to do. But in a lot of cases, you probably don't need to do that. What you actually want to do is build a whole separate namespace set of packages for your particular target, which don't have to work with Debian ones. On the other hand, there's a set of people who want to be able to prototype something quickly using a standard base system, a standard small base system, and then sticking random Debian packages for obscure or complicated stuff because it's not in our little mini build. And if you want to do that, you've got to have a compatible system. So you've got to be using the same LibC. You can't be using LibC and then sticking random Debian packages and expect it to work. I mean, you can do that to some extent, but that's making it a lot of difficult. So there's various ways you might want to do this. And you probably can't support all of them at once. It would be nice if we could, but we certainly have to start with, we've got to pick something and do that and prove it works before trying to satisfy all conceivable schemes at once. It just makes your life so difficult that you never get anywhere. One thing people do want is a customization mechanism for their particular device. For the reasons of all the derive distributions that we're talking about, there's always some stuff you want to change. It might just be the kernel. It might be some kind of unified graphical goodness for the front end on your little widget. So a kind of organized way of applying your set of patches so that you can keep porting that forward as things move on easily will be a very nice feature. That's something Open Embedded does really well. You've got to stick into the deep-packaged cross kind of Debian way of cross-compiling things because we have one dirty, great big patch instead of parts of little ones, which is what you really want. Staying in sync with Debian is the other thing. There's a very small number of people actually working on this at the moment. That's one of the reasons it's progressing fairly slowly. And Debian keeps moving on and our tools get left behind. Once we have a whole load of changed packages, if those changes aren't kept basically in Debian itself, then in practice it'll just get left behind immediately and become useless, and better Debian will only work unless, if either, several hundred people start working on it, or we have a mechanism for keeping the changes from standard Debian within normal packages and maintainers actually looking after those changes. So if that's work, we have to get a fair amount of buy-in from Debian that this is something worth doing. So there's two major issues which are largely independent. There's cross-compiling things. Now that's useful for embedded people, but it's useful for other reasons too. As I mentioned, if your buildies are sufficiently slow, you might actually want to cross-build that architecture just because you can do it in hundreds of time. I think it would also be... It gives the same benefits to Debian that building for a lot of architectures has given us in the past. You know, nobody else used to do that, and it meant that Debian was the only thing where you could guarantee everything worked on big-endian and little-endian and different sizes of pointers and all the things that vary across architectures, the fundamental stuff. An awful lot of those bugs were pushed upstream over the years as we've discovered that things were broken because people only write for the architecture they know. You can't necessarily be expected to know that ARM has really strange float format, which you're finally getting rid of. Those things have got fixed over the last decade. We can now not care about anymore. I think if we decided that Debian should be cross-buildable and fix things accordingly, because the mechanisms all exist. They've been there for a long time. There's an awful lot of crap or cruft in autoconf and package confing and all that stuff, which in theory means cross-building should work the way it's intended, but it doesn't for a lot of detailed reasons like people never try it and nobody understands autoconf and just copy the script from somewhere else and you have the same badness that everybody else had. An awful lot of the fixes are in fact already an open embedded because they've been going through this process for a year and a half. There is a great load of goodness in there which tells you what needs changing to make things build properly. To some extent they're pushing that upstream as well. Do you want to say this for the end? If you can remember. I think there will be quite a lot to talk about like this. There is a whole load of stuff which has to be run at build time. Lots of things build stuff and then run it for tests. There's a limit to how much of that you can do without creating a whole target environment that looks like the target environment and running things in it, which is what Scratchbox does. I think we want to use a lot of the good things that Scratchbox has done. To a large extent, I'll talk about that more on a later slide actually. The other part of this is package modifications, which is throwing away the docs at the most primitive level. You can have a lot of basic heuristic rules which say throw away all the examples and throw everything in user share. We don't care about that except for about six files that are actually important, which will do the right thing for a lot of packages. In a lot of cases, you'll need specific rules for a particular package that say the way it should be done for a small builders like this. In fact, we want three different versions of it for different purposes. These two things, the cross-compiling part and the building-shrunk packages part, are mostly independent. What we're trying to do is reuse the existing package management system, d-package and apt, and add-cross compilation support, which in fact already exists in the form of d-package cross, which is a tool designed to just build. With d-package build package, you just add a couple of options and say build it for ARM. Remove the stuff we didn't want and have a scheme for installing the packages either onto the development host for testing or on the target itself. You can either build your root file system on your development box, so you make all your packages and then you install them to the virtual target and then you copy the results across onto your actual target, or you can make packages which the target can install itself. There's two different models. It depends whether you want to just make a widget and give people a system image or whether it's kind of like a PDA and they actually want to be able to have a set of packages which you can choose things from and shop and change. The things we fiddled with, these slides are now going to get in slightly randomised order, so I do apologise if it becomes a bit disjoint. That's the fault of software patterns. Deep package cross is this thing that has existed in Debian for a while. I think it was originally produced for people who just needed to build an ARM version of a particular package in order to do a port as binary upload. Nevertheless, it's basically a wrapper for deep package build package which sets a whole load of stuff and can fill in config variables in order to do arbitrarily complicated things in order to set all the things that should be set, such that if your package build system is properly constructed, it will just spit out the right thing at the end. As Scratchbox buyers can tell you, life is nothing like that simple in practice, but the principle seems reasonably sound. It automatically means that the build system is told to use the right compiler and the right bin utils and the right strip and all that sort of thing. The way we implemented this is basically just wrappers for deep package and apt, which give it the right options. This is what your standard setup on your normal Debian box. This is a repository with binary and source packages in it. You can get a list of those packages which apt puts in a local database so you know what's available. Then you get those into your local cache. You can build them or you can just install them and there's a database of what's installed. We all more or less know how that works. To do that for the embedded setup, we have basically the same thing but slightly more complicated. Now there's a second repository list for the target architecture and a second locally available database for the target architecture and a second local database of installed packages for the target architecture. It's not difficult. That way you can manage the set of packages on your device separately from the set of packages on your machine. Now apt and deep package already provide all the technology we need to do this. We don't have to write any new software. It's great. Why wasn't that the next slide? Because I'm rubbish. How do I go backwards? I'll show you that in a minute. The way you do this, you download your sources and build everything on your development machine. The parameters which control the cross-compiling live in ETCD package cross-compile which tells it which architecture it should be assuming you have a default one and where the tool chain lives and stuff like that. If that also provides a mechanism for special versions of things which I'll come to in a minute. That's quite a new feature. You build things with deep package, build package the way you did before. Then there's a wraparound deep package for actually installing the packages you've built into your local target system. On the actual device when you get later, so you haven't built a tool up tool now, but when you finally dig it out and make it work, you can use I package to install those packages rather than deep package if you want to save the phenomenal amount of space you'll save by doing that because deep packages databases are very large especially when you've got a lot of packages. I package is a lot more efficient in that regard but it's basically compatible so you can choose which one you want to use on the end device. You can't use I package for all this build stuff because it's not smart enough. This is the neat new feature that's been added to deep package cross recently which is basically you can have a set of modes. You can have arbitrarily complicated flags for all sorts of purposes. It's very generic but there's a special Mdebyn flag which basically says all the tools that you normally use for building so this affects a DEB helper if we got ran to it it would affect CDBS and any other obscure build schemes which we don't know about can be told things like by default throw away the docs by default remember to link with the target architecture libraries and not the host ones when doing deep package shlib depths and generating the runes because a lot of the packages are built with the same tools by changing those tool scripts a little bit to just make them cross compiler where you get quite a lot of this almost for free by basically setting this flag so that bit works it was working in February but since then something's changed and it's now broken again as I discovered this week which is why I'm not going to demonstrate it by typing it because all you get is obscure runes about not being able to set cross prefix to cross prefix but you can also specify in the scope here all the extra flags so if you want to build everything with dash m cpu strong arm or you want to add soft float or other compiler flags basically you stick them in here and they give them to every single package that gets built you can specify different C library and so on so that's the kind of fundamental control level mechanism so this is how the wrapper stuff to make app to do all that stuff about retaining a separate set of lists for the architecture it's not very complicated you tell it what the app to architecture is and that it should be using a different sources dot list because you probably want to get your file from somewhere else 15 minutes Jesus right okay and that the cache is somewhere else and so on and the that anything that gets installed gets installed to a different place from the default root file system basically the same but the package stag the package is a wrapper for it which just gives it the right runes every time so that does quite a lot of what you want at the basic level so there's a fundamental problem of how do you control the bits that are different for embedded builds now we kind of hummed and hard about this we're now on the second generation of the scheme which I still view very much as an experimental implementation so the moment you have your Debian directory which contains the control files and stuff everything you need to build Debian rules so now we have an Mdebian directory as well so if an Mdebian directory is present then the tools these new tools will use that preferentially so that's how you have different packages different dependencies and different build options the problem with that is because it's a separate directory it's not at all obvious to your maintainer that there's all this basically we've got two copies of a lot of information we could copy the standard rules and then change them a bit and those will go out of sync horribly over time if anyone can think of a much better scheme the main advantage of this was that we could we could tack it on to existing packages without getting anybody's way so we could experiment with this system prove it was actually valid and then worry about we could get that into people's packages without it changing anything at all one jot of their work which would be relatively painless we were hoping so that's the advantage of this scheme it's entirely a non-intrusive but it may not be the best way to keep maintenance in the long term so package doesn't change much we had this in Debian's sub-directory with new build info which is usually very similar but just slightly different blah blah blah told of that splitting the docs there is a good thing because as Timo will tell you later in the week the docs produce an awful lot of circular dependencies in Debian which makes it incredibly hard to build the whole thing from scratch you have to have Debian already in order to build Debian it's a bit of a pain for embedded systems so you've got to build the whole thing from a tool chain up from G-Lib C upwards because that way it definitely comes out right so the way you actually use this you install you know modified tools modified debhelper and d-package and d-package cross set that mdibi in flag and then just build things with a dash A arm instead of what you normally did and in principle it spits out all your Debian packages for another architecture as I observed earlier that generally doesn't work except for extremely simple packages and that's where we're going to have a session afterwards and sit around and hack some things and discuss about stealing a number of the good bits out of scratchbox especially the ability to run non-native binaries in order to do compile time tests the multi-arch stuff I think is also very interesting in this regard it's primarily aimed at x86 and d64 but in fact you can also get it to run arm test binaries during the build which you know could be useful so yeah so as I said the tools will fix will improve packages from our point of view without you making any changes to them at all and then there's a more specific set of changes you can make if necessary so these are the scripts that need modifying in d-package dev because all of them need to know about basically just knowing about the mdibi in directory and using it preferentially if it exists it's not rocket science actually if you look you'll find there's lots of trivial modifications to all the scripts so things that don't work so well d-package cross as I said was really designed so it's a handy tool if you need to build something for arm you need to have all the libraries it needs at the very least to and d-package cross basically lets you get those libraries from the existing architecture pile so you already, with Debian already has all the arm libraries pre-build and it's just you can basically do d-package cross package name it'll fish out the library files and the package name and architecture it'll fish out the library files and the header files for package config files for all the libraries you need stick them in the right place so that the cross build system will just find and use them what it doesn't have is a neat way of actually sucking the binaries in the first place as far as I can tell you you have to go to packages.dibbyn.org and download them with Wooget each time which is incredibly rubbish because we have lots of other tools that sort of do that like apt build but I couldn't get it so that it would just get the few packages you need for this particular build dependency apt would get carried away and go no but if I need those I need all these and then it says we'll download 336 megabytes of packages basically an entire system and you go no I don't need an entire system I just need the stuff for this package now that could just be because I'm very stupid and someone will explain to me later what the right rune for that is but it was annoying me this week you do need to be root for a lot of this stuff to work but then that's kind of true for package building anyway with the fake root stuff I can see that it could be a problem in some environments it kind of depends whether there's lots of developers trying to use a system or if it's just you and your box in which case it probably doesn't matter if we put in runes for an awful lot of packages the fact that all the bodys for cross building something properly go in it should be d-package cross compile it's going to get to be a very big file after a while if we've got little secret runes for a thousand packages in there so I probably need splitting up but that can come later the other thing I think that needs a bit of thought is on embedded systems almost invariably you don't use a whole load of the base file stuff you use busybox instead and you don't tend to use standard xlibs and all the associated cruft you use tiny x instead so there's a kind of base system which you will usually want to use which has a fundamentally different set of dependencies and I haven't quite got my head round exactly how we're going to do that I'm sure we can but it needs somebody smarter than me to explain to me what the correct runes are so once you've generated a whole load of these packages then you use stagget as I mentioned earlier so you just do staggetarm update staggetarm install package and it will just take your packages from the pile so once we have produced an example embedded Debian we can do a standard one which will probably satisfy a lot of people which is basically probably 500 packages from Debian that people actually use and a much smaller base system box and tiny x then most people can just point their point stagget at that and use it and that way they can produce embedded systems in about a quarter of an hour and then they put their one application on top that they actually want to use that's new or different that's the idea so we have the tools to do this but they don't work very well which is why we have more people in this room to come and have a good hack later so we can at least get things up to date and see how much of a system we can build that works we have a build machine which is five minutes right okay does that include questions as well right okay I better shut then don't I I'm nearly at the end which is good and we need to build actually build an example distro that people can try out that means making a list of the things packages that people actually need I'm not sure what the minimal set of packages is but making a list to say these are the first 200 that we ought to compile and then that will satisfy a lot of people or 500 or however many it is adding QEMU actually I've mentioned earlier didly-do covered that pretty much somebody from Debian install ought to come and help because I haven't taken enough notice of exactly how they've done what they've done and I'm sure that we ought to make sure that we're not inventing things which they've already worked around and the other thing is that ultimately Scratchbox guys are well ahead of me on this they've been playing this game for a couple of years already discovered that it's hard work and doing things this way is difficult so basically Scratchbox works around a lot of these problems not fixing all the broken build systems and just providing a big sandbox so that the broken build systems still do the right thing which is very cool but what I'm kind of interested in is whether it's possible to actually fix all the build systems and do it kind of cleanly and properly with rather less stuff needed to make it work I don't know maybe it isn't in which case those solutions are in fact already the best way of doing it and I should just give it with this because the other thing is can we persuade everyone in Debian that cross-compilability is a good thing because if we can't do that this probably isn't going to get very far and can the changes we make to in Debian be kept in step with Debian as it rushes along in its headlong epicness again if not we have a problem we'll just keep getting left behind and we'll never get anywhere there are all sorts of odd build systems out there most of this stuff should work for Autoconf and for Debhelver but when people do exotic kind of build it and then build it again from the results of the amazing Makefile which built all your Debian Makefiles and stuff life will get difficult these people have all helped out OMS has provided the build box we've got somewhere in the States or New Zealand or somewhere I don't know where it is but basically we've got a box we can play with that's that, right probably good oh yeah okay as we went all the trouble to make it appear on the camera so this is just an example system which we didn't build with embedded Debian of course because it's rubbish and doesn't work this was built with open embedded this is the kind of cool stuff you can do this is 64 mega flash packed with Firefox and a proper email client which is are you supposed to sit up there? yeah sorry magic technical people make my thing appear yes someone ask a question there's a whole in the ETCD package cross-compad you have all the configure variables for a particular architecture and for Linux oh sorry yes repeat the question where are we going to put all the configure variables so deep package cross basically takes care of that there's a set of files so there's one for if you're using Linux configure variables look like this if you're using ARM configure variables look like this so we can add an arbitrary set of those files if you're using embedded Debian some configuration variables look like this that's right so that's a feature of deep package cross alright so we've got our netbook so this is a quick 30 second demo just to show that you can do quite neat things we should have the Nokia people here because this is even cooler I'm sure because it's newer so these are a whole load of apps this is the GNU palm top environment plus Mozilla, AbbeyWord, GNUmeric GPDF blah blah blah and this little thing in the corner Therian editor is a scheme which basically means you can stick in so that's what fits in 64 mega flash but if you've got things that don't fit you obscure one of my packages in Debian for drawing cave surveys which requires TCLTK and all of Tetech and a whole load of garbage and basically you can just fish all of that stuff out of Debian standard Debian packages stick them on a compact flash and put them in and add a little app icon and that appears and runs so you can add a random vertical app to the basic system slowly so this is a strong ARM 400 megahertz PXA thing as you can see GPDF runs really really quickly but it does work and what this gives you it is so that's Therian TCL thing finally started up Mozilla goes fast enough to be quite usable it's a little bit sluggish but it works and what this lets you do is have all the stuff you need on a basic system so text editor, email, web browser PDF reader calendar app blah blah blah and that was built with open embedded and it took I don't know about eight of us eight months or something that was a big job we spent a lot of science money on that does it? oh it does yes indeed and to be fair it included a lot of work if you look at the standard version of Balsa it's got a lot more menus and options and things it's been this has had a human interface man go over it and basically throw away most of it people don't know any of these things get rid of them hide them in extra menus that say more at the bottom here we are like that so all the extra cruft that used to live there is hidden from your normal user and quite a lot of the work went into that and that's the sort of thing where open embedded is good because there were some fairly heavy patches but it's got a mechanism for keeping your dirty great patch for your special version of the applications so anyway yes that's cool toy it does yes so open office goes in on the compact flashcard that's what the mechanism was devised for and I haven't got that on this card I'm afraid because I was much more interested in cave surveying open office it does run it very slowly I'm sorry but we'll have to we'll have to stop there so the thing I do need to say is there will be a hackfest for the rest well Tuesday and Wednesday and the rest of today on embedded Debian so anyone who's interested in this sort of thing please come to wherever the hacking is there's a room for it I gather smoky yes smoky or something and we will be there in the corner playing with this stuff thank you