 Right, so let's talk about no-herd. So for us it's a bit old about freedom zero, that is the ability to use software, basically. For any purpose, and for us the important thing is that you shouldn't have to ask the system administrator for things. You should be allowed to do whatever you want. So for instance, why is FDisk, MQ2FS, et cetera, hidden in slash has been. I want to be able to build disk images, play with them, mount them, et cetera. So just be able to work with the kind of disk and network access I have and do whatever I want with this. So it's about freedom to innovate as well if I want to use an experimental file system just play with it without being afraid of crashing the machine. You should be able to just run the file system and let the system administrator be happy with this because it's safe to do this. And also it's a way to provide freedom from misbehaving programs like a driver which doesn't work so well or something like this. So just to give an idea, in GNU Heard, so you have the kernel which does basically almost nothing just managing tasks, the memory and inter-process communications and then you have a lot of daemons doing the actual stuff. So the PFI net is the TCP IP stack, X2FS does the file system thing and then you have the user just running programs. And these tools just actually just talk to the daemons through the micro-cernel. The micro-cernel doesn't do much, it just passes requests along. So for instance, if a server crashes then that's fine. For instance, a driver crashes, or hangs, you just can kill it and then PFI net will reopen a new instance of the driver and it will just work thanks to TCP just continuing to ping the other computer. So it's just a narrow, it's not something of the death. At some point on my desktop I could switch off the light and then that would crash my laptop because switching off the light would reboot my hard disk, a USB hard disk and then the kernel of the laptop wouldn't like this. This is not something which is supposed to happen. So with a server approach this is completely fixed. It's also easier to debug, it's really nice to be able to GDB a TCP IP stack when there is something happening in there, just run GDB, you can jpeg it etc. You can also there more crazy things. For instance, the Linux console doesn't support much because we don't want to put too much complex code in there. On GNU Heard, the console actually supports things like Chinese double width support etc. which is not supported by the next console and that's right because you don't want to put too crazy stuff. Here, since it's just a user land program then you're fine and so we do have Chinese support in actually text mode in the Debian installer. Okay, so just to show an example, so here I have FTPFS which uses the TCP IP stack to actually mount a remote directory and then I can use ISOFS to mount an ISO image which is inside that FTP server and then I can just let Cp copy a file from the ISO image which is on the server. So this translates that way. So I've turned this command a long time ago just to say that FTP colon in my home directory is whatever FTP and then I can take tilt FTP slash etc. a URL and give that to ISOFS and then mount that on my MNT and then I can just browse inside the ISO image without having to download the whole ISO image without having to ask root for this kind of things etc. And I can also permanently store this in X2FS so just to give an example I have a translator on my signature file which just calls fortune so when I cut that signature I get one signature or another because each time I open the file it's a new instance of fortune which is started so you can see that indeed this is stored in my signature file. So this is fun. Another example, as a user I can start my own TCP IP stack and tell it to use virtual network interface and then put the TCP IP service on some node in my home and then I can run OpenVPN to actually put and push and pull packages from that virtual interface and build a VPN with somewhere else and then I can remap the system what is supposed to be the system TCP IP stack into my own socket and then I get a new shell for which the system TCP IP stack is actually my own TCP IP stack and so I can decide which program actually use this TCP IP stack and just do my own VPN without having to ask anything to the administrator but also for instance it happens quite often that you have a binary maybe not SH but like Python or Perl or whatever you have a program which wants slash bin slash SH to be actually bash or whatever so I want to change this and so I can remap this so for instance if I look at SH so as usual it's green but you can see here it's dash and if I remap bin SH into bin bash for instance I get a new shell and actually a set is not the same so it's remapped into slash bin slash bash and so it's actually bash which shows up here so I do really choose how I work what my environment looks like and for instance I can even remap the whole slash bin directory into my own directory where I expose slash bin and also other things so that programs which have slash bin slash something hardcoded into them I can use them without having to ask the administrator to install stuff inside slash bin so it's kind of interesting it's a bit like Stowe next geeks but done in a nice way so how does it work well it's actually relatively simple in the principle simply that libc doesn't talk with the kernel or whatever it always uses rpcs so to ask nicely about opening files etc and so it's really natural in GNU HURD that you can redirect things so for instance the remap and translator here is like maybe 200 300 lines because it's just a matter of you open a file okay is it something I want to translate yes I translate that and then I open the real file and give the new handle to the program and that's all so it's extremely simple so everything in GNU HURD is an RPC and so it is interposable and then translators get exposed inside the file system so we have seen the tcpip stack it's just a path inside the file system and then the user can decide whatever it wants to do to interpose whatever so for instance fakeroot in Linux is quite a big because it has to interpose libc symbols and every time libc invents something new then it breaks in fakeroot because fakeroot has to know about this new symbol etc sorry interpose them so either through ptrace or ld or whatever in GNU HURD fakeroot is like a thousand lines long because it just implements a few basic things and then everything just works we just interpose basic authentication hooks and libc uses them all the time so it's fully virtualizable and with a really fine grain interface because you can precisely decide which RPC I interpose or which file in the file system I interpose and then you can just use your home directory the tcpip stack and pile stuff over it the way you want so just to give a crazy example so we have a lot of stuff so I actually have a nicer image inside a partition disk image on ftp over vpn and this is not so crazy maybe the ISO image inside a partition disk the ISO image is a bit too much but one file inside a partition disk image on ftp over vpn it's not so crazy because maybe you're on a hostile network so you have to use a vpn and then you want to access a file you know is inside a disk image I don't know an ARM based disk image I did on a public ftp server and you don't want to download the whole image just to get I don't know the readme file or something like this so it's not so crazy and it just works nicely so a bit more debian stuff porting packages to hurt is quite easy in principle because it's just a POSIX system there is a lot more than just a POSIX but it provides a POSIX interface so portable programs should be really fine just for fun some dumb issues so for instance some programs think that if it's not Linux or BSD then they can include windows.h why not if the system has mar.h that must be macOS because macOS is the only system in the world that use mar I don't know why but I will try to grab cpu info which doesn't exist on gnuherd yet so they basically just run mac-j which just explodes the system even on a lignix system it's just the same unless it's a small program but with a lot of c++ files it's horrible some people include linux.h from linux instead of just standard one a problematic thing is people who hard-code erno values the values of erno are not standardized so you shouldn't hard-code them like in test-tweet results or things like this and quite often in configure it's hard-coded that only linux knows about LP threads or LDL etc so quite often programs are not generic enough and that's just easy to fix but we have more so we have a portal page developing a bit more about this I wanted to talk a bit more about pathmax so it is not defined on gnuherd for a very good reason and it is allowed by posix not to define this just to say that there's no limitation on the pathmax value we don't have a limit on the size of the path and indeed it has a fragile semantic it has never meant a reasonable size for an array of characters to store a path on linux it's 4000 that's a whole page that's a whole TLB entry for just one file name it's extremely costly most people don't have a so long path and so it's really a pity to use so much memory because it's always a whole page always a line on 4k etc so that's a waste for one and paths can actually be longer there's no strict limitation you can mkdir something cd into that mkdir again cd etc you can do that as much as you want there's no limitation on this it's just that when you call get current working directory you won't get it completely and maybe some programs behave misbehave in that case because they won't see these files they will be quite actually hidden or protected or I don't know you cannot remove them just giving the path you have to cd cd cd and then you can access the file and for no reason actually because linux inside doesn't doesn't have such limitation actually and also POSIX didn't really say precisely whether the final slash 0 actually is included in pathmax or not so people would allocate pathmax plus 1 or maybe not so we have a lot of code which doesn't maybe actually work but nobody tests it actually because they don't never have so long path so I'm a bit afraid of all this got using pathmax so you should be afraid as well just to give another view of the state so we have a 386 support we have a 64 bit support which has started so we have the kernel booting and now it's mostly translating between 32 and 64 in RPCs we have drivers for network boards in as user translator using the DD layer so we have disk we have extend port we have preliminary sound support which was announced today using Rump, the Rump kernel we don't have USB yet it is quite stable I haven't reinstalled my boxes for like a decade I don't remember when I installed them actually and the building machines just keep building packages for weeks without a problem 81% of the archive we have the native and Debian is started working which is really working great recent work is like interesting thing is a distributed mtime translator to provide slash proc slash mounts in a hurtish way we have quite a few optimizations which went in to improve the performance we had release quite some time ago I really recommend to have a look at this one it's fun so we released some Weezy and Jesse snapshots they are not official but for us it's really an official thing and the important thing I wanted to discuss this week is the removal from ftpments master so this is due since quite a few years now honestly it's really not useful to mirror the hurt packages over the whole world because they are not even as many users as the number of mirrors so okay that's fine for just the removal from the main archive in terms of mirroring but then we have a lot of consequences so for instance builddbm.org is really an important thing because that is where the release team schedules transitions and losing this for us would be really tedious work because I've been there doing actually the transition work the same work as the release team and it's really painful to do this again so we would really like to have solution for this so maybe get that fed from Debian ports and then that's fine we can be on Debian ports as long as at least there is some synchronization between something and also getting exposed on the buildd package status page so that people are aware that there is some port which is failing and maybe they are keen on spending some time on it maybe not that's fine but at least get them know about it and also a corner thing when we have a version upgrade like GCC or Perl the release team ask okay we'll have to upgrade the buildd's and at the moment they don't even have an account on them so they cannot check whether the version is good or not so maybe we should just provide an account we just need to know who we need to give an account to so basically my idea would be okay that's fine not being on FTP master the thing is we still want to have most of the support of Debian to make our life less burden as much as possible without any extra load on the release team etc we do understand well that we don't want to put work on people's hand but we would like to still get some benefit and probably there are solutions for this and conversely all this I mean putting more work on us herd porters would actually be the same solutions that existing ports on Debian ports would be really happy to have to improve their life to have less work to do than they currently have it's really a problem so maybe we want to think about a real status for second class citizens so like herd but also the spark etc so maybe we want to have some both at some time so we can gather and discuss about this okay so future work interesting thing is probably the most interesting thing is probably using the ramp drivers because at the moment we use DDE but it's not really going forward we thought it would be a way to get newer drivers, Linux drivers without extra effort but it doesn't actually happen at the moment while ramp does go forward we see work being done with Xen etc so this is probably a long term solution maybe we'll have another distribution through Geeks this is progressing we are quite far from doing this so for now Debian is really the only herd distribution that we have so we'll see and of course just come and have fun with your pet project just try thanks any quick questions before we run to lunch hello I just wondered if you're using herd I wonder if you're using herd on that laptop with you there to give the presentation yeah yeah this is running herd yes so it's quite like usable every day well not every day because without USB you cannot mount a USB stick for instance so that's quite inconvenient but yeah I could probably use it every day I don't I mean for work I cannot for this but yeah also we don't have wireless drivers at the moment we hope that with the run drivers we would get this so yes some people do use it every day not me but those would be the major things missing for more people to be able to use it thanks any more questions if there are any more questions then thanks again right and I think we are out to lunch