0:00:02.521,0:00:04.081
Let's talk about GNU/Hurd

0:00:05.841,0:00:11.101
For us it's a bit all about freedom 0,[br]that is, the ability to use software,

0:00:11.481,0:00:14.161
basically, for any purpose.

0:00:14.881,0:00:18.261
And for us, the important thing is that[br]you shouldn't have to ask

0:00:18.441,0:00:20.981
the system administrator for things.

0:00:21.481,0:00:23.581
You should be allowed to do[br]whatever you want.

0:00:24.161,0:00:30.901
So for instance, why is fdisk, mke2fs,[br]etc. hidden in /sbin?

0:00:31.142,0:00:36.841
I want to be able to build disk images,[br]play with them, mount them, etc.

0:00:37.700,0:00:44.581
So just be able to work with the kind of[br]disk and network access I have,

0:00:44.581,0:00:46.041
and do whatever I want with this.

0:00:47.161,0:00:52.301
It's about freedom to innovate as well, if[br]I want to use an experimental filesystem,

0:00:52.301,0:00:56.921
just play with, without being afraid of[br]crashing the machine.

0:00:57.841,0:01:01.421
You should be able to just[br]run the file system

0:01:01.440,0:01:06.241
and let the system administrator be happy[br]with this because it's safe to do this.

0:01:08.661,0:01:14.181
And also, it's a way to provide freedom[br]from misbehaving programs

0:01:14.181,0:01:18.481
like a driver which doesn't work so well,[br]some things like this.

0:01:20.581,0:01:25.041
Just to give an idea, in GNU/Hurd,

0:01:25.041,0:01:28.882
you have the kernel which does basically[br]almost nothing,

0:01:28.882,0:01:33.741
just managing tasks, the memory and[br]inter-process communications,

0:01:33.741,0:01:37.821
and then you have a lot of daemons[br]doing the actual stuff,

0:01:37.821,0:01:43.861
so the pfinet is the TCP/IP stack,[br]and ext2fs does the filesystem thing.

0:01:44.381,0:01:47.502
And then, you have the user,[br]just running programs.

0:01:48.581,0:01:55.321
And these tools just, actually just talk[br]to the daemons through the microkernel,

0:01:55.321,0:02:00.462
the microkernel doesn't do much, it just[br]passes requests along.

0:02:02.621,0:02:05.720
For instance, if a server crashes,[br]then that's fine.

0:02:07.080,0:02:10.342
For instance a driver crashes,[br]or just hangs,

0:02:10.342,0:02:17.221
you just can kill and then pfinet[br]will re-open a new instance of the driver

0:02:17.221,0:02:24.041
and it will just work, thanks to TCP just[br]continuing to ping the other computer.

0:02:25.261,0:02:27.921
So it's just an error, it's not something[br]of the death.

0:02:28.922,0:02:33.041
At some point on my desktop, I could[br]switch off the light,

0:02:33.041,0:02:35.522
and then that would crash my laptop.

0:02:35.842,0:02:42.940
Because switching off the light would[br]reboot my hard disk, USB hard disk,

0:02:42.940,0:02:46.461
and then the kernel of the laptop[br]wouldn't like this.

0:02:47.421,0:02:49.421
This is not something which is[br]supposed to happen.

0:02:49.680,0:02:54.401
So, with a server approach, this is[br]completely fixed.

0:02:55.120,0:03:00.321
It's also easier to debug, it's really[br]nice to be able to gdb a TCP/IP stack,

0:03:00.321,0:03:07.201
when there is something happening in there,[br]just run gdb, you can gprof it, etc.

0:03:08.721,0:03:10.780
You can also dare more crazy things.

0:03:11.102,0:03:16.820
For instance, the Linux console doesn't[br]support much, because we don't want to put

0:03:16.820,0:03:19.120
too much complex code in there.

0:03:19.902,0:03:23.881
On GNU/Hurd the console actually supports[br]things like Chinese,

0:03:23.881,0:03:25.661
double-width support, etc.

0:03:25.961,0:03:27.861
which is not supported[br]by the Linux console,

0:03:27.861,0:03:31.380
and that's right because you don't want[br]to put too crazy stuff.

0:03:32.160,0:03:35.661
Here since it's just a userland program,[br]then you're fine,

0:03:35.661,0:03:41.361
and so we do have Chinese support in,[br]actually, textmode in the Debian Installer.

0:03:44.542,0:03:52.401
Just to show an example, so here I have[br]ftpfs which uses the TCP/IP stack

0:03:52.401,0:03:56.101
to actually mount a remote directory,

0:03:56.101,0:04:03.321
and then I can use isofs to mount an ISO[br]image which is inside that FTP server.

0:04:03.861,0:04:09.682
And then I can just let cp copy a file[br]from the ISO image which is on the server.

0:04:10.441,0:04:17.141
So this translates that way, so I've done[br]this command a long time ago,

0:04:17.141,0:04:22.600
just to say that "ftp:" in my home[br]directory is whatever FTP,

0:04:22.600,0:04:29.962
and then I can take a "~/ftp:/etc." URL[br]and give that to isofs

0:04:29.962,0:04:33.401
and then mount that on my "mnt",

0:04:33.401,0:04:38.381
and then I can just browse inside the ISO[br]image, without having to download

0:04:38.381,0:04:44.481
the whole ISO image, without having to ask[br]root for this kind of things, etc.

0:04:45.480,0:04:48.601
And I can also permanently store this[br]in ext2fs.

0:04:49.201,0:04:53.561
So just to give an example, I have a[br]translator on my signature files,

0:04:53.561,0:04:58.660
which just calls fortune, so when I[br]"cat .signature" [demo],

0:04:58.660,0:05:02.600
I get one signature or another, because[br]each time I open the file,

0:05:02.600,0:05:06.941
it's a new instance of fortune which is[br]started.

0:05:07.602,0:05:12.142
You can see that, indeed, this is stored[br]in my signature file.

0:05:14.061,0:05:15.280
So this is fun!

0:05:16.721,0:05:22.741
Another example: as a user, I can start[br]my own TCP/IP stack,

0:05:22.741,0:05:27.000
tell it to use a virtual network[br]interface,

0:05:27.000,0:05:32.303
and then put the TCP/IP service on some[br]node in my home,

0:05:32.303,0:05:37.764
and then I can run openvpn to actually[br]push and pull packets

0:05:37.764,0:05:41.500
from that virtual interface, and build a[br]VPN with somewhere else.

0:05:42.121,0:05:49.301
And then I can remap the system, what is[br]supposed to be the system TCP/IP stack

0:05:49.301,0:05:51.141
into my own socket,

0:05:51.141,0:05:58.441
and then I get a new shell for which the[br]system TCP/IP stack is actually

0:05:58.441,0:06:00.420
my own TCP/IP stack.

0:06:01.021,0:06:06.382
So I can decide which program actually[br]uses this TCP/IP stack,

0:06:06.382,0:06:14.801
and just do my own VPN without having to[br]ask anything to the administrator.

0:06:17.261,0:06:22.361
But also, for instance it happens quite[br]often that you have a binary,

0:06:22.361,0:06:26.201
maybe not sh, but like, python or perl[br]or whatever,

0:06:26.201,0:06:34.301
you have a program which wants /bin/sh[br]to be actually bash or whatever,

0:06:34.301,0:06:38.841
so I want to change this, so I can remap[br]this, so for instance [demo]

0:06:38.841,0:06:43.541
if I look at sh, so as usual,[br]oh it's green,

0:06:43.541,0:06:45.541
but you can see here that it's dash,

0:06:45.541,0:06:53.201
and if I remap /bin/sh into /bin/bash, for[br]instance, I get a new shell where actually,

0:06:53.201,0:07:01.661
sh is not the same, so it's remapped into[br]/bin/bash,

0:07:01.661,0:07:04.441
and so it's actually bash which actually[br]shows up here.

0:07:04.860,0:07:10.881
So I do really choose how I work, what my[br]environment looks like.

0:07:11.921,0:07:18.181
And for instance, I can remap the whole[br]/bin directory into my own directory,

0:07:18.181,0:07:21.581
where I expose /bin, but also[br]other things,

0:07:21.581,0:07:27.281
so that programs which have /bin/something[br]hardcoded into them,

0:07:27.281,0:07:32.381
I can use them without having to ask the[br]administrator to install stuff inside /bin.

0:07:34.000,0:07:41.040
So it's kind of interesting, a bit like[br]stow, Nix, Guix, but done in a nice way.

0:07:43.321,0:07:47.861
How does it work? Well it's actually[br]relatively simple in the principle,

0:07:47.861,0:07:52.021
it's simply that libc doesn't talk with[br]the kernel or whatever,

0:07:52.021,0:07:57.321
it always uses RPCs, so to ask nicely[br]about opening files etc.,

0:07:57.321,0:08:04.021
and so it's really natural in GNU/Hurd[br]that you can redirect things.

0:08:05.241,0:08:10.840
So for instance, the remap translator here[br]is like, maybe,

0:08:10.840,0:08:13.481
200-300 lines[br][Note of transcriptor: 150 actually],

0:08:13.721,0:08:15.320
because it's just a matter of

0:08:15.320,0:08:20.161
"you open a file, OK, I look at the file[br]path, is it something I want to translate?

0:08:20.161,0:08:23.481
Yes, I translate that, and then I open[br]the real file,

0:08:23.481,0:08:26.641
and give the new handle to the program",

0:08:27.080,0:08:29.401
and that's all, so it's extremely simple.

0:08:32.221,0:08:36.940
So <i>everything</i> in GNU/Hurd is an RPC and[br]so it is interposable,

0:08:36.940,0:08:44.401
and then translators get exposed in the[br]filesystem, we have seen the TCP/IP stack,

0:08:44.401,0:08:46.961
it's just a path inside the filesystem.

0:08:47.721,0:08:53.381
And then the user can decide whatever it[br]wants to do to interpose whatever.

0:08:53.781,0:08:58.981
So, for instance fakeroot, in Linux,[br]is quite big,

0:08:58.981,0:09:02.581
because it has to interpose libc symbols,

0:09:02.581,0:09:07.401
and every time libc invents something new,[br]then it breaks in fakeroot

0:09:07.401,0:09:14.801
because fakeroot has to know about this[br]new symbol, etc. and interpose them,

0:09:14.801,0:09:18.221
either through ptrace or ld or whatever.

0:09:19.602,0:09:22.641
In GNU/Hurd, fakeroot is, like,[br]a thousand lines long,

0:09:22.641,0:09:26.161
because it just implements a few basic[br]things,

0:09:26.161,0:09:34.861
and then everything just works, which just[br]interpose basic authentication hooks,

0:09:34.861,0:09:37.141
and libc uses them all the time.

0:09:38.860,0:09:43.981
So it's fully virtualizable, and with[br]a really fine grain interface,

0:09:43.981,0:09:48.021
because you can precisely decide[br]which RPCs are interposed,

0:09:48.181,0:09:50.560
or which files in the filesystem[br]are interposed.

0:09:51.821,0:09:56.400
And then you can just use your home[br]directory, the TCP/IP stack,

0:09:56.400,0:09:59.981
and pile stuff over it, the way you want.

0:10:02.222,0:10:06.321
Just to give a crazy example, we have[br]a lot of stuff,

0:10:06.321,0:10:12.201
I actually have an ISO image inside a[br]partitioned disk image on FTP over a VPN.

0:10:13.041,0:10:14.821
And this is not <i>so</i> crazy.

0:10:15.821,0:10:20.282
Maybe the ISO image inside the partitioned[br]disk, the ISO image is a bit too much,

0:10:20.282,0:10:26.361
but one file inside the partitioned disk[br]image on FTP over VPN is not so crazy,

0:10:26.361,0:10:31.061
because maybe you are on a hostile[br]network, so you have to use a VPN,

0:10:31.061,0:10:34.761
and then you want to access a file[br]you know is inside a disk image,

0:10:34.761,0:10:40.441
I don't know, a known disk image which is[br]provided on a public FTP server,

0:10:40.441,0:10:44.001
and you don't want to download the whole[br]image just to get, I don't know,

0:10:44.001,0:10:45.502
the README file or something like this.

0:10:45.860,0:10:49.481
So it's not so crazy, and it just[br]works nicely.

0:10:52.141,0:10:54.621
So a bit more Debian stuff.

0:10:55.601,0:11:00.001
Porting packages to Hurd is quite easy[br]in principle,

0:11:00.001,0:11:05.520
because it's just a POSIX system, there is[br]a lot more than just POSIX,

0:11:05.520,0:11:07.521
but it provides a POSIX interface.

0:11:08.021,0:11:11.761
So portable programs should be[br]really fine.

0:11:13.121,0:11:17.761
Just for fun, some dumb issues, so for[br]instance some programs think that

0:11:17.761,0:11:20.981
if it's not Linux or BSD, then they can[br]include windows.h...

0:11:22.061,0:11:22.881
Why not...

0:11:23.661,0:11:26.241
If the system has mach.h, that must be[br]MacOS,

0:11:26.561,0:11:31.601
because MacOS is the only system in the[br]world that uses Mach, I don't know why...

0:11:32.841,0:11:37.861
Some people try to grep cpuinfo, which[br]doesn't exist on GNU/Hurd yet,

0:11:37.861,0:11:43.361
and so they basically just run "make -j"[br]which just explodes the system,

0:11:43.361,0:11:48.561
I mean even on a Linux system it's just[br]the same, unless it's a small program,

0:11:48.561,0:11:51.141
but with a lot of C++ files it's horrible.

0:11:52.302,0:11:58.781
Some people include limits.h from linux/[br]instead of just the standard one, well...

0:12:00.741,0:12:04.441
A problematic thing is people who[br]hardcoded errno values;

0:12:04.441,0:12:09.680
the values of errno are not standardized,[br]so you shouldn't hardcode them, like,

0:12:09.680,0:12:12.501
in testsuite results or things like this.

0:12:13.761,0:12:17.561
And quite often in configure it's[br]hardcoded that

0:12:17.561,0:12:21.856
only Linux knows -lpthread or -ldl, etc.

0:12:22.061,0:12:25.101
so quite often programs are not[br]generic enough,

0:12:25.101,0:12:30.061
and that's just easy to fix, but we have[br]more and more of these.

0:12:30.641,0:12:33.341
So we have a porter page developing[br]a bit more about these.

0:12:34.581,0:12:42.021
I wanted to talk a bit more about[br]PATH_MAX, it is not defined on GNU/Hurd,

0:12:42.021,0:12:46.560
for very good reasons, and it is allowed[br]by POSIX not to define it,

0:12:46.560,0:12:51.461
just to say that there is no limitation on[br]the PATH_MAX value,

0:12:51.941,0:12:54.261
we don't have a limit on the size of[br]the paths.

0:12:54.922,0:12:59.422
And indeed it has a fragile semantic, it[br]has never meant

0:12:59.422,0:13:03.881
"a reasonable size for an array of[br]characters to store a path".

0:13:05.181,0:13:09.281
On Linux it's 4000, that's a whole page,

0:13:09.281,0:13:12.280
that's a whole TLB entry for[br]just one file name.

0:13:13.441,0:13:16.801
It's extremely costly, most people don't[br]have so long paths,

0:13:16.801,0:13:24.241
and so it's really a pity to use so much[br]memory, because it's always a whole page

0:13:24.241,0:13:27.421
because it will always be aligned[br]on 4k etc.

0:13:27.941,0:13:30.081
So, well, that's a waste for one.

0:13:30.701,0:13:35.120
And paths can actually be longer,[br]there is no strict limitation,

0:13:35.120,0:13:40.062
you can mkdir something, cd into that[br]mkdir again, cd, etc.,

0:13:40.062,0:13:43.501
you can do that as much as you want,[br]there is no limitation on this,

0:13:43.501,0:13:45.381
it's just that when you call

0:13:45.381,0:13:50.841
"get current working directory",[br]you won't get it completely.

0:13:51.761,0:13:56.661
And actually, some programs misbehave[br]in that case,

0:13:56.661,0:14:01.421
because they won't see these files,[br]they will be quite actually hidden,

0:14:01.421,0:14:02.921
or protected, or I don't know,

0:14:02.921,0:14:07.341
you can not remove them just giving[br]the path, you have to cd, cd, cd, cd,

0:14:07.341,0:14:08.820
and then you can access the file.

0:14:11.181,0:14:15.242
And for no reason, actually, because Linux[br]inside doesn't have

0:14:15.242,0:14:17.842
such limitation, actually.

0:14:19.241,0:14:24.821
And also, it's stupid, but POSIX didn't[br]really said precisely whether

0:14:24.821,0:14:30.060
the final \0 actually is included in[br]PATH_MAX or not,

0:14:30.060,0:14:33.521
so people would allocate PATH_MAX+1,[br]or maybe not.

0:14:36.382,0:14:40.660
So we have a lot of code which doesn't,[br]maybe, actually work,

0:14:40.660,0:14:45.121
but nobody tests it, actually, because[br]they would never have so long paths.

0:14:45.741,0:14:48.561
So I'm a bit afraid of all these codes[br]using PATH_MAX.

0:14:49.541,0:14:50.881
You should be afraid as well.

0:14:52.620,0:14:54.501
Just to give an overview of the state.

0:14:54.740,0:15:00.661
We have a i386 support, we have a 64bit[br]support which has started,

0:15:00.661,0:15:02.401
we have the kernel booting,

0:15:02.401,0:15:06.641
and now it's mostly translating between[br]32 and 64 in our RPCs.

0:15:07.822,0:15:16.441
We have drivers for network boards as a[br]userland translator, using the DDE layer.

0:15:18.042,0:15:20.281
We have disk, we have a Xen port.

0:15:20.921,0:15:26.161
We have a preliminary sound support[br]which was announced today, using Rump,

0:15:26.161,0:15:27.521
the Rump kernel.

0:15:28.141,0:15:29.601
We don't have USB yet.

0:15:31.121,0:15:35.541
It is quite stable, I haven't reinstalled[br]my boxes for, like, a decade,

0:15:35.541,0:15:37.762
I don't remember when I installed them,[br]actually.

0:15:38.500,0:15:43.261
And then the buildd machines just keep[br]building packages for weeks

0:15:43.261,0:15:44.561
without a problem.

0:15:44.681,0:15:47.341
We have 81% of the archive.

0:15:48.241,0:15:52.441
We have the native Debian Installer which[br]is really working great.

0:15:54.461,0:16:00.561
Recent work is, like, interesting thing is,[br]a distributed mtab translator

0:16:00.561,0:16:04.021
to provide /proc/mounts in a hurdish way.

0:16:05.040,0:16:09.700
We have quite a few optimizations which[br]went in to improve the performance.

0:16:11.941,0:16:14.541
We had releases quite some time ago,

0:16:14.541,0:16:17.260
I really recommend to have a look at this[br]one, it's fun.

0:16:18.361,0:16:21.441
We've some Wheezy and Jessie snapshots,

0:16:21.441,0:16:25.260
they are not official, but for us it's[br]really an official thing.

0:16:29.361,0:16:34.521
An important thing I wanted to discuss[br]this week is the removal from ftp-master.

0:16:35.341,0:16:40.021
This is due since quite a few years now,[br]honestly,

0:16:40.021,0:16:44.322
it's really not useful to mirror the hurd[br]packages over the whole world,

0:16:44.322,0:16:49.121
because there are not even as many users[br]as the number of mirrors.

0:16:50.161,0:16:55.681
So OK, that's fine for just the removal[br]from the main archive in terms of mirroring.

0:16:56.141,0:16:58.862
But then we have a lot of consequences.

0:16:59.181,0:17:03.381
For instance, buildd.debian.org is really[br]an important thing,

0:17:03.381,0:17:08.281
because that is where the release team[br]schedules transitions,

0:17:08.281,0:17:12.901
and loosing this, for us, would be really[br]tedious work,

0:17:12.901,0:17:16.721
because I've been there, doing, actually,[br]the transition work,

0:17:16.721,0:17:22.080
the same work as the release team, and[br]it's really painful to do this <i>again</i>.

0:17:23.801,0:17:26.321
So we would really like to have a solution[br]for this.

0:17:26.881,0:17:31.001
Maybe get that fed from debian-ports and,

0:17:31.001,0:17:35.621
then that's fine, we can be on[br]debian-ports, as long as at least

0:17:35.621,0:17:37.901
there is some synchronization between[br]something.

0:17:38.921,0:17:43.881
And also, getting exposed on the buildd[br]package status page,

0:17:43.881,0:17:48.821
so that people are aware that there is[br]some port which is failing,

0:17:48.821,0:17:52.360
and maybe they are keen on spending some[br]time on it, maybe not,

0:17:52.360,0:17:56.541
but at least get them know about it.

0:17:58.281,0:18:03.101
And also, a corner thing, when we have[br]a version upgrade, like gcc or perl,

0:18:03.101,0:18:09.280
the release team asks[br]"OK, we'll have to upgrade the buildds",

0:18:09.280,0:18:12.121
and at the moment they don't even have[br]an account on them,

0:18:12.121,0:18:15.481
so they can not check whether the version[br]is good or not.

0:18:17.781,0:18:20.161
Maybe we should just provide an account,

0:18:20.161,0:18:24.121
we'd thus need to know who we need to give[br]an account to.

0:18:26.001,0:18:31.121
Basically, my idea would be[br]"OK, that's fine not being on ftp-master".

0:18:31.721,0:18:35.921
The thing is we still want to have most of[br]the support of Debian,

0:18:35.921,0:18:41.702
to make our life less a burden,[br]as much as possible,

0:18:41.702,0:18:44.981
without any extra load on[br]the release team, etc.

0:18:45.281,0:18:49.341
We do understand well that we don't want[br]to put work on people's hand.

0:18:50.821,0:18:56.081
But we would like to still get some benefit[br]and probably there are solutions for this.

0:18:56.921,0:19:04.540
And conversely, all of this, I mean, not[br]putting more work on us Hurd porters,

0:19:04.540,0:19:10.301
would actually be the same solutions that[br]existing ports on debian-ports

0:19:10.301,0:19:16.741
would be really happy to have, to improve[br]their life, to have less work to do,

0:19:17.041,0:19:20.541
than what they currently have,[br]it's really a problem.

0:19:21.141,0:19:25.981
So maybe we want to think about a real[br]status for Second Class Citizens,

0:19:25.981,0:19:30.001
like Hurd, but also the sparc, hppa, etc.

0:19:30.380,0:19:36.081
Maybe we want to have some BoF at some time,[br]so we can gather and discuss about this.

0:19:38.481,0:19:45.741
Future work, the most interesting thing is[br]probably using the Rump drivers,

0:19:45.741,0:19:50.640
because at the moment we use DDE but[br]it's not really going forward.

0:19:51.041,0:19:55.701
We thought it would be a way to get newer[br]drivers, Linux drivers,

0:19:55.701,0:20:00.061
without extra efforts, but it doesn't[br]actually happen at the moment,

0:20:00.061,0:20:06.041
while Rump does go forward, we see work[br]being done with Xen etc.

0:20:06.621,0:20:08.961
So this is probably a long-term solution.

0:20:10.921,0:20:13.941
Maybe we'll have another distribution[br]through Guix.

0:20:15.141,0:20:18.401
This is progressing, we are quite far from[br]doing this,

0:20:18.401,0:20:23.860
so for now Debian is really the only Hurd[br]distribution that we have, so we'll see.

0:20:24.841,0:20:32.001
And of course, just come and have fun with[br]your own pet project, just join, thanks!

0:20:33.441,0:20:38.761
[Applause]

0:20:39.641,0:20:42.401
[Michael Banck] Any quick questions before[br]we run to lunch?

0:20:53.321,0:20:54.841
[Steve Chamberlain] Hello, I just wondered

0:20:55.281,0:21:00.961
if you're using Hurd on that laptop[br]for the presentation?

0:21:01.261,0:21:02.581
[Samuel Thibault] Yeah, yeah,[br]this is running Hurd, yes.

0:21:02.701,0:21:04.662
[SC] So it's quite, like, usable everyday?

0:21:05.201,0:21:07.921
[ST] Well, not everyday because[br]without USB,

0:21:07.921,0:21:12.101
you can not mount a USB stick for instance,[br]so that's quite inconvenient,

0:21:12.101,0:21:15.421
but yeah, I could probably use it everyday.

0:21:15.960,0:21:20.040
I don't, I mean, for work,[br]I can not afford this, but yeah.

0:21:20.241,0:21:23.481
Also, we don't have wireless drivers[br]at the moment.

0:21:23.761,0:21:26.481
We hope that with the Rump drivers[br]we would get this.

0:21:26.801,0:21:28.741
So, yes.

0:21:29.041,0:21:30.841
Some people do use it everyday.

0:21:31.121,0:21:32.281
Not me.

0:21:33.120,0:21:36.101
[SC] But those would be the major thing[br]missing for more people

0:21:36.101,0:21:37.361
to be able to use it.

0:21:37.841,0:21:38.901
OK, thanks.

0:21:40.280,0:21:48.581
[MB] Any more questions? We're run out of[br]questions, then thanks again. Thanks.

0:21:49.141,0:21:54.560
[Applause]