 Let's start. Can you all hear me? Fine. Okay, I'm going to give a very brief introduction to how the X-Herbal Linux distribution got started, how I actually started it, and then I'm going to talk about 10 or actually 11 things that I think we are doing that's cool and exciting that we are trying to do differently from other projects. And those cool things should apply to other projects than just Linux distributions. That's my aim at least. Okay, in the beginning I had just left Gentle Linux as a developer after four years, and I was starting to wonder what I was going to do with all this free time of mine that I suddenly had. And I knew I was going to spend it doing open source development somehow, but wasn't quite sure what I was going to do. So then I was sitting just me alone and doing some random stuff really. But slowly I started just trying to build a few packages for myself. Just really basic packages like GDFC and the GNU compiler suite and so on. Just a few packages and just experimenting, seeing how simple I could get stuff, trying to solve some of the problems that I've seen in other distributions and stuff like that. But I wasn't really thinking about doing a distribution at this point. But slowly I experimented with more and more packages and then it looked something like that. Tons of packages and still just me doing all the work. And it was beginning to be a bit messy actually. So at this point I started talking, first I started realizing that maybe I was actually doing a distribution here. That might actually be what I was beginning to work on. So I started discussing this with a few friends of mine that seemed to be interested in my ideas and said, oh please keep working on that and it might be something we'd be interested in later on. So fortunately these friends of mine stuck around and started helping with this distribution. And then I had a few ideas about what I wanted to do with the distribution. Some of these ideas is quite contrary to what other open source projects are doing. One example is that I want as few developers as possible. I don't want 100 developers. I want 10 or 20 developers for this project. And I don't really want it to grow any larger than that if I can avoid it. And the reason for that is that as soon as projects grow to be 100 developers or 200 developers you're going to get a lot of organizational problems. People are wanting very different things. You're going to start having at least some internal fights in the project. It's going to be much harder to control the project and make sure that it's actually going in the direction that you had wanted from the beginning. So to avoid all these problems I was just going to keep the developer account as low as possible. And one problem with that is that with 10 developers and a sort of full Linux distribution with 10,000 packages or 15,000 packages, every developer is going to be incredibly busy just making sure that new versions of all these packages are available. And it would be kind of impossible to make sure that we could actually fix box timely and so on. So my next realization was that having these few developers we also needed to have very few packages. And of course people want 15,000 packages. That's what users want. They want all the packages available right away that they use. And people use a lot of different packages. So the way to do this is that we as official server developers just focus on the core packages. So we are focusing on making sure that GCC and GNC unit systems so on is available to users. We are making a few things available that most users want like KDE and GNOME and different popular desktop environments. But not all the desktop environments because that's not really needed. We just need the most popular so you can take and install extra on a system and it's useful out of the box. It may not have all the packages and all the stuff that you want but it's still usable. And that's important. So the way we do try to support 15,000 packages or 10,000 packages or whatever the goal is going to be is that instead of adding lots of developers to Xherbo, we make it extremely easy for users to build their own packages, to import binary packages to their systems, to contribute patches to Xherbo. So we have focused very much on what I call distributed development or decentralized development. So right now we have about 20 developers and we have at least 20 users that's actively contributing new packages and so on to Xherbo. So that's actually working quite well and the way to make it work is to focus on the problems of distributed development and making sure that you have tools making it fairly easy to do this. So my first point is package manager support for multi-semit dependent repositories. We have a code package repository named ARBO that's containing GDPC and GCC and a few other necessities like auto tools and so on. Just what's needed to boot up your system more or less and build packages, not much more than that. So stuff that's needed on all Xherbo systems. Then we have several other repositories. We have a KDE repository, we have a GNOME repository, we have a repository with scientific packages and so on. And we are making sure that the package manager makes it easy to use all these different package repositories. And one way we are doing that is that we are making repositories depend on each other because in the package repositories we also have some libraries making it easier to write our packages because all the KDE packages for example are using pretty much the same functions to install packages. So we just put these functions in a library that all the KDE packages can use. But these libraries need to be shared between different repositories. So when we are making a new repository we are saying here's this new repository and the master repository for this is ARBO or KDE or whatever. And we can set several different masters for this repository where it can grab these libraries from. So we don't have to copy libraries to all the different repositories. So that's one way we are making it possible to use multiple repositories. Another way is that I think on my laptop I probably have about 20 package repositories installed, something like that. And we have maybe 35 package repositories in all or something like that. And it's growing all the time. So for users they need to be able to quickly decide if they want to install a package which repository is this package available in. And to facilitate this we made a special repository type called unavailable repository. And that's nothing more than a big list of all the packages and all the different repositories that we know about. So every time I'm updating repositories on my laptop and updating all the package information I'm also updating this unavailable repository. And when I'm trying to install a package that's not available in any of my installed repositories, unavailable repository is going to tell me that. Hey, it's not available in any of the repositories you already installed. But it's available in the repository named Xorg or KDE or whatever. So I'm getting the name of the repository that I need to install this package. Because we already have built an index and updated this index of packages regularly. Taking that idea a bit further, we've made an unwritten repository. That's fairly similar to unavailable repositories in that it's just a list of packages that doesn't exist on your system. But it's a bit more than that in that it's a list of packages that nobody has written yet. So it just contains metadata about these packages. So for example, if we don't have a package for KDE games, we might add it to that repository saying we need to write a package for KDE games. And the URL to the KDE games website is this and so on. Add different metadata about this package that we need to write in the future. And it's making it easier in the way that we collect all this information in the package manager. So instead of going to our bug tracker and searching for some package and seeing if somebody should have mentioned that, then maybe made some attempt at a package and so on, we just get the information directly from the package manager when we search for the package or try to install the package. And that makes it much easier both for the developers and for users to find out what's the status of this. And users are also welcome to tell us that they want a package and if we don't have time to write that package right now and the user isn't capable of writing the package himself, we can just add it to unwritten repository. And we know in the future that this package actually needs to get written. We know who requested it and so on instead of having to go to a completely different interface. We have it right in our package manager. I kind of mentioned this, but package manager handling most things is important. We're using the package manager every day, of course, as part of the development. We install packages, we upgrade packages and uninstall packages and so on. So what we really want is the package manager to handle most things. It's not everything, but most things is actually suited fairly well for the package manager. Also, some things that might not seem obvious at first. So one of the things is what we call alternatives. And Debian has something similar and Gen2 has something similar. But what we want to provide is different versions of Emacs, different implementations of VI and so on and let the user decide which version to use. But we need package support for this because package is supposed to register a new implementation of VI or a new implementation of Emacs and so on. So we can later select between these alternatives that we have installed. So in the packages, we have a small library supporting these alternatives and that just makes a few functions available to packages to register these versions and so on and also the uninstallation part of it, of course. Another thing that's quite new actually is support for accounts directly in the package manager. What most distributions do when they are installing MySQL or Apache for example is that they need a user that this demon can run as. So they just add an add user command somewhere in the install script that sets up this user. This works fairly well, I'd say, but we are able to do much better than that. So what we did was make an accounts repository that takes care of installing users and groups. And one of the things that allows us to is that when we list the packages that needs to be installed when I want to install for example Apache, our package manager can also list that it's going to create this user and this group because it's just treated as normal dependencies in our system. Right now we don't yet have the ability to upgrade users but we'll gain that at some time and it's not just Unix accounts either because we'll be able to create MySQL users and so on in some time. So when you install mid-TV or whatever that requires its own MySQL user, the package manager can take care of creating this user in a standard way instead of having five different packages calling add user in five different ways for example. Options is, we have a lot of, just like gentle, we have a lot of options for each package. For example, if we have a PHP package, we might want to build it with JPEG supporter, so you can specify that for the package. But there's also a lot of options that applies generically to packages. For example, do you want to build packages with debug information? Do you want to strip debug information and so on? So we made a generic interface to specify such options for all the packages. And we are able to, from the package, to look at these options, see which options are enabled, which options are disabled, and do whatever is needed if anything special is needed to handle this. It might be that a package needs to do something special when you're able to debug information for example. So we are able to handle that. In the future, we are probably going to have options for various source control management systems. So you, through options, can specify the exact revision of a JIT package or subversion package that you want to install, for example, stuff like that. And it's fairly powerful being able to apply these options generically across packages without packages, in most cases having to do anything special to allow this. One of the other things we are trying to do is to keep good metadata about all the packages and all the other stuff we have. It's fairly easy just adding metadata to packages, but it's also, in many ways, fairly important. And it's just metadata like where is the package coming from, who is the author of the package, when we are doing, when we are adding patches to packages, have the patch been sent upstream, have upstream rejected the patch, why have upstream rejected the patch, who made the patch and so on. And it allows us to keep really good track of all the patches and it makes it much easier also when we are doing a new version of a package to decide which patches are still needed and so on, because we have a direct link to the mailing list post where this exact patches discussed and so on. And we actually make sure to require quite a bit of this metadata, so people are not allowed to add patches to our repositories without describing whether the patches send upstream and watch the status of the patch and so on. Another thing is the user interface. With all the flexibility of source-based distributions like Xerbo, it's fairly important that we have a user interface that's easy to figure out. And it's fairly important that we don't have 500 different ways to configure things. We're not going to change the Apache configuration, of course, but all the things that relate to our distribution as such, how to install packages, where packages are installed and so on, needs a standard configuration and not five different ways to configure this, to make it easy for users to use. So we are going for a fairly simple configuration in many cases, although that kind of configuration might be slightly too easy. So we are going for a somewhat harder configuration. And another related thing is upstream error reporting, up-front error reporting. So what we are trying to do with these two points is that we are trying to say that we want to install 20 packages, maybe. And we want to, in advance, before pressing the big button and installing these packages, want to provide all the configuration information needed to install these packages. So we need to tell the package manager up-front exactly what's going to be included and which packages are we going to include JPEG support, are we going to include PHP support or whatever. But we also want up-front error reporting, because if we are trying to install 20 packages and some of these packages are incompatible with each other, blocking each other in some way, one of them require JPEG support and enable JPEG support. We want to know before it's installed half of the packages and break down with some silly error message halfway through. Up-front error reporting is also known by many of you, I'm sure, as fail early. And that's fairly important actually, because if I'm installing 20 packages, if it's big packages, it might take two hours to install these. And I don't want to sit in front of my laptop just watching it compile for two hours just to see if something is failing, if something is going to fail. So one of the main Linux competitors have actually learned from this up-front error reporting. The blue screen of that, as I'm sure you all know, that's not exactly what we are doing, but it's important still to be clear about error messages and situations. So finally, you really need to keep the project fun. That's one of my main goals actually. We are trying to do a lot to make distributed development available, to make lots of technical progress in all kinds of different areas. And we are all very serious about this. We might be doing it primarily because we wanted ourselves, so we are just scratching it, as you can say. But it's also important to keep the project fun, because if I'm going to spend 15 hours every week or 20 hours every week on something that I'm not getting paid for, I really want it to be fun, because otherwise I wouldn't be doing it, of course. So in that regard, we have this silly mascot, the ZebraPik, and it's silly on purpose, actually. And some would even call it ugly, and that's fine, because we need to remind ourselves from time to time that it can't be too serious. You can't be too serious about stuff you're not getting paid for. So just remind yourself of that from time to time. And that's why I have this t-shirt also with the ZebraPik on the back of it, saying I love X Herbal. And I mean, of course I love X Herbal. It's my project in many ways, so I'm going to love it, but it's also just a bit of fun reminding me that maybe you can't get a bit too serious from time to time. So, all right. But let me show you some of the stuff I've been talking about. Right. So I've been talking a lot about having lots of repositories available. I don't have every repository installed here on my laptop, but I have quite a few repositories installed. That's maybe 20 or 25 repositories here. That's a list of all the repositories that I have installed right now. Some of them I've mentioned specifically, like unavailable. Unavailable is the repository type that talks about packages available in some repository that I haven't installed. So that's the index of all the different repositories. We are allowing random users more or less to create their own repositories. We are even encouraging it. So we have some problem with doing quality assurance on some of these repositories, of course. The way we deal with that is that we have all the official repositories. That's the repositories that's listed or indexed by unavailable. And then we have another index called unavailable, unofficial, that's an index of all the repositories that we don't think is bad in itself, but doesn't quite have the quality that we want for an official repository. But it's still got our stamp of approval, if you want, saying, this repository is generally okay and it shouldn't do anything bad to your computer or anything like that. And we've looked at the packages and they seem to be okay. And we know the author of this repository. And you can, of course, add all kinds of repositories that isn't in any of these unavailable repositories, if you want to. Then we have the unwritten repository that's all the packages that we still need to write. And the accounts repository containing users and groups that's installed through the package manager. All right. So what I've just did was I currently unwritten repository. So this is all the information we have about packages that we know we need to write at some point. That's the packages that we really want to write, but just haven't had time to write yet. So that's the mid-stage that we keep about these packages. And we can see, for example, that we need to write a package for the Apache web server here. We are adding information about the version we want of the Apache server. We are adding a short description. What is the Apache server? We are adding the home page for it. And there's also some short comment from the package manager saying that the packages' mask, it can't be installed because nobody has written it yet. But that's fairly powerful, actually, that you can get all this information even on packages not written yet. So sometimes we can just take a look at this list of packages that needs to be written instead of trying to find all the packages that's been requested on our bug tracker. We just get all the information in a coherent format from the package manager. And we know exactly what mid-stage is required for each package. So we know we get a home page for the software and so on. These are the user accounts that's handled by the package manager. And we actually have dependencies in the packages on users exactly like we have dependencies on libraries and so on. But here we can list all the users managed by the package manager. We can see what options there are for each of these users or groups. And another thing allowed by adding user accounts and user groups directly in the package manager like this is that we can actually have users depend on groups also. So the package manager is able to upfront state, I need to make this use about the group already exists so I'm not making the group and so on because we're not touching users and groups if they already exist. It's only if they don't exist that we are creating them. This is the package for our package manager. So what we can see is that we have a lot of build dependencies. We need how to make and how to configure and so on for various options. But we can also see in this line here that we are depending on a user called PalutisBuild that's the user that our package manager uses when building packages. We need root privileges to install packages to the main system of course but we are trying to build packages as a non-privileged user. So if anything should go wrong during build it's not going to delete large parts of your systems and so on or if there should be any malicious code in the build system for example. It's restricted to a sandbox area running as this user. As part of our package tree in every repository we have a bit of metadata specifying master repositories and so on and as part of that we also specify the users and groups that packages in this repository needs. So here we have the PalutisBuild user for example the configuration for that. So we are just specifying Gecko's field, we are specifying the shell the home for that user, the home directory and a primary group. We can also specify other stuff like which user ID do we want for this user if we have any requirements then we can specify preferred user ID and so on. This is the configuration for the NTP group. All we really want for that group that the NTP program is running as is a preferred group ID so that's all that we specify and the package manager just calls user add or rather group add with that option and let everything else just to be default values for that. That's not what I wanted. Okay this is the X11 repository that's slightly more interesting than the Arbor repository because the Arbor repository is the core repository so it doesn't have any dependencies or not a repository or anything like that. But here we can see in the X11 repository some of the metadata describes the layout of this repository. We are actually able to support repositories using different package formats and we've already seen that kind of in that we have our Arbor repository that's containing XHarris packages that's our main package format but we've also looked at shortly looked at unavailable repositories that's a totally different kind of repository and also the unwritten repository. So here we can specify what type of repository this is and we can see that we are using XHarris for this for all the stuff in this repository. One of the interesting things is also that we can see that as master's repository we have specified the Arbor repository. So every time some package in this repository needs an XHarris library that's available in Arbor we don't have to copy it to this repository because the package manager is just going to grab it from the master and we can specify multiple master's if needed. That's usually not needed but we can do it when if needed. If we specify multiple master repositories it's going to take the repository mentioned first as the highest priority so we have some kind of priority to control where libraries are coming from. This is the unwritten repository just to show you that. It's fairly different from the normal package repositories in that we just have a bunch of configuration files describing all the packages that we still want to write and it's in a fairly easy format. So this is the basic format of these configuration files. So first we have the category in the tree where the package is supposed to be then we have the package and the version of the package that we want somebody to write for us. And then we have the mixed data with home page and description and who added this to unwritten and so on. So that's basically it. I don't think there's any more interesting repositories to show but as part of, oh that's not working for some reason but we have a small program called eclectic that takes care of most of the stuff that we can't directly add to the package manager. So for example we have packages registering that there's some kind of V.I. and that the users should be able to switch between these V.I. versions. We are not using the package manager directly to switch between these versions but rather using the eclectic command to list providers of V.I. providers of print services or whatever it might be and we are able to switch providers for different stuff both on a system basis and also on a user basis for most things. So yeah I can't show you eclectic for some reason I think. I can maybe. So this is eclectic, the small program and some packages have installed modules to control things related to that package. For example you can have several different OpenGL providers installed. I only have one OpenGL provider installed on this laptop right now but if I had an NVIDIA card for example I would probably have both a MISA implementation and an NVIDIA accelerated implementation of OpenGL that I could use eclectic to switch between these two versions. Another thing that's fairly important that we use eclectic for is managing configuration files because every time I upgrade a web server or something it's going to install new versions of its configuration files in the slash etc directory. We are not going to just overwrite the version you already have there because that would be dangerous. Instead we are going to keep a new version of this and through eclectic we let you list the differences between these versions, merge the versions or just overwrite or delete the new version as you want to. Okay I think that's it. Any questions? Sorry? The name, ex-herbal. Well at that time we needed a name that wasn't already taken. And there was quite a few Palutis projects that were already using Latin inspired names Palutis being our package manager of choice. So we kind of went with the Latin theme. I'm not exactly an expert on Latin, but Google could lead me to some Latin dictionaries so I just started looking at different words and thinking what could be fun here and finally I came up on ex-herbal. And it somehow fits in with some of the other project names we were selecting at the time that were also starting with ex. And it's just a fun word that it's a small pun on the fact that we are starting from scratch basically because it means to weed out or something like that or from grass or trees. And we are basically starting from ground zero if you want and trying to take ideas from all kinds of distributions. We are also taking some ideas from Ruby and putting them into our package format actually. So we are taking ideas from all over the open source world really and ex-herbal just fit that idea somewhat. So that's how that came about. Other questions? There is this information like in my world for example that this game is doing this or that as soon as we have that available this information is redundant with what is available for example in Boxzilla? Yes. How do you manage that redundancy? Yeah. We've just stopped using Boxzilla more or less. Because when we started we had several books about packages needing to be written in Boxzilla before we got the unavailable repository. But unavailable repository is a much better way of managing this. So none of the developers are filing Box for packages that we need to write. They are all just adding it to unwritten and so on. And if any user files box we usually the developers usually just transfer the information. So we have it all in one place. It would be interesting to also add a proposed ex-ress for example from a user. Sorry. It would be interesting to add a proposed ex-ress from a user. Something that is not possible to merge yet but that would be visible. Yeah. Users are making their own repositories available all the time even if they are not quite yet the quality that we need to make them more official. So that's happening all the time. We have several layers of unavailable repositories. We have the official layer that's just called unavailable. We have the layer called unavailable unofficial that's repository that we think is basically all right. It's not maintained by us and it might not quite meet the quality that we'd like if we had to maintain it ourselves. But it's good enough that we are willing to make it available for other users. And then there's a third layer with repositories just made up by random users where they just post it on their blog or whatever. So we basically have three levels of repositories in that way. Any other questions? Induces. I've been using XHerbal at my work for the last year or so actually without any problems. I'm in a special situation in that regard of course because I'm a developer and I started XHerbal. So I know about all the problems that might prop up in advance. But right now for the past three or four months at least it's been quite stable. We're not quite ready to tell users that yes we're going to support you with all your problems and so on. So you're still on your own for some part at least. But we have certain users that's never used the source-based distribution before in our IRC channel for example. And they are getting help. So as long as you are willing to listen to us when we're trying to help you and we tell you to read the documentation or whatever it should be quite stable and it should also provide most of the packages that an end user would need these days. We have some packages lagging obviously. Apache was one of them that's obviously lagging. And we'll get to that in time of course. I can't say how fast but it's quite stable and I'm hearing from lots of people actually that's trying XHerbal that it's very stable and that they haven't had any problems. So I'm not telling you all to go home and start using it but it should be alright. So we also just got a new home page yesterday I think where we are not quite as aggressively discouraging users. So we're definitely going in the right direction. Yes, the original website definitely told users to go away. But what you have to keep in mind was that page is a year old or something like that and back then XHerbal was really rough. Not quite as rough as 18 months ago but still really rough. And we didn't really have any KDE packages or GNOME packages or anything. I think we had awesome Window Manager or something like that or you could just use TWM, wonderful Window Manager. And that's basically it. So back then it really wasn't ready for users. It's definitely starting to be ready for users now I think. We have a few big things that we still like to implement. I need to implement the unit system that I've been talking about quite some time and haven't had time for. Yeah, right now we're just, well most people are just using base layout from Gen2 and that works fairly well so it's not a big problem. But there's one or two bigger things that we still want to implement before saying yes it's ready for users. But it shouldn't make any big differences. It shouldn't cause any big trouble at all. More questions?