WEBVTT 00:00.000 --> 00:11.800 Okay, so good afternoon, everybody, so we talk a bit about GNU Hurt indeed, the latest 00:11.800 --> 00:19.200 progress from various people, actually, a few people have joined the choice recently. 00:19.200 --> 00:25.560 I would like to make just a quick recap on the purpose of the Hurt and some things that 00:25.560 --> 00:30.240 have been available for a long time already. 00:30.240 --> 00:31.240 That's my opinion. 00:31.240 --> 00:35.960 The Hurt is all about freedom zero, that is freedom zero in free software is the freedom 00:35.960 --> 00:38.800 to run the program for all purpose. 00:38.800 --> 00:43.440 And for me that includes the freedom from the season mean of the machine. 00:43.440 --> 00:49.480 That is why all these programs hidden in slash has been, I should be able to partition 00:49.480 --> 00:56.120 an image, there's no reason to be able to do it and make it and mount it and mounting 00:56.120 --> 00:58.640 on Linux is a privileged operation. 00:58.640 --> 01:04.360 It shouldn't be a privileged operation, I should be able to mount an image, take something 01:04.360 --> 01:07.680 out of it and everything. 01:07.680 --> 01:12.160 The idea is that I have access to some part of the disk, I have access to the network, I want 01:12.160 --> 01:15.160 to be able to do anything with that. 01:15.160 --> 01:19.480 And that's also the freedom to innovate, that is, if you want to experiment with a five 01:19.480 --> 01:23.920 system, you should be able to do this without having to insert a module into a kernel or 01:23.920 --> 01:24.920 whatever. 01:24.920 --> 01:34.000 Maybe you have a personal workflow that match some use case and not the ones that were configured. 01:34.000 --> 01:38.640 And maybe you have a PCI card in a machine and you want to give it to a user and whatever 01:38.640 --> 01:42.000 he wants to do with it. 01:42.000 --> 01:47.280 And conversely, you want to have some freedom from these behaving programs, so for the 01:47.280 --> 01:53.400 administrators to get free of the bugs introduced by the users, but also the admin get rid 01:53.400 --> 01:57.280 of the bugs of the drivers and everything. 01:57.280 --> 02:00.800 So that's why we want to isolate things. 02:00.800 --> 02:03.600 So that's what it looks like on NewHurde. 02:03.600 --> 02:09.120 So we have the micro kernel here and basically the goal is to just manage the task memory 02:09.160 --> 02:13.000 IPC and then everything else is in NewHurde. 02:13.000 --> 02:18.960 So here we have like Proc who knows about processes, if you have finite the TCP-IP stack 02:18.960 --> 02:24.120 X2FS for the file system, or who knows about who is who. 02:24.120 --> 02:28.360 And then we have actual programs, a shell and a copain. 02:28.360 --> 02:34.560 And what happens is the shell is actually when it opens a file, it asks X2FS and X2FS 02:34.560 --> 02:43.720 as asks old, but who is that guy who is opening a file, what authorizations does it have. 02:43.720 --> 02:48.160 Which means that when a server crashes, it's not a problem, you get a narrow, you don't 02:48.160 --> 02:53.520 get a blue screen or something or whatever, you just get errors. 02:53.520 --> 02:59.400 And it's also easier to tune and to debug, you can attach to X2FS and then put breakpoints 02:59.480 --> 03:02.000 into your file systems. 03:02.000 --> 03:06.480 And then since it's easier to develop than you do, can do crazy things. 03:06.480 --> 03:14.120 In that the hard console text controls, controls are can actually print all kinds of fonts, 03:14.120 --> 03:20.840 including Chinese and everything, because it loads cliffs on the fly, because it's easy 03:20.840 --> 03:28.760 to do without the kernel way of developing things and just use a lot of things. 03:28.760 --> 03:34.880 Then we can virtualize at very fine grain, we had a toast about it, previously at first 03:34.880 --> 03:35.880 them. 03:35.880 --> 03:43.320 Just to give an example, so here I have the TSP IP stack and I'm stopping on it, an FTP and 03:43.320 --> 03:51.280 translator to access files and transparently through FTP, then I have an ISO system translator 03:51.280 --> 03:56.520 who knows about ISO image and then I can run a shell that opens a file in it. 03:56.520 --> 04:02.560 So to show how it looks like, so here I'm putting a translator on my home, which is called 04:02.560 --> 04:09.880 FTP colon, which is a multiplexer of the host name for the FTP translator. 04:09.880 --> 04:15.120 And so I do it just once for the whole installation of my system. 04:15.120 --> 04:21.200 And then when I want to mount a ISO image, I just tell, okay take this ISO image, so it's 04:21.200 --> 04:27.320 inside that mount point, so we access that FTP server and then we get an ISO image. 04:27.320 --> 04:32.240 And we mount this through the ISO translator on M&T. 04:32.240 --> 04:38.240 And then when we can look at it and we have the files, we can even extract things, we can 04:38.240 --> 04:47.320 mount an X2 image inside the ISO image and take things from there, everything is possible. 04:47.320 --> 04:53.760 And that's possibly stored in the file system that this is stored for good, even after 04:53.760 --> 05:00.680 rebooting and things which are fun, like a signature file, which changes every time you 05:00.680 --> 05:05.560 open it, it actually runs a new instance of fortune, so you get a new content every time 05:05.560 --> 05:07.600 you open it. 05:07.600 --> 05:09.760 So yeah, that's fun. 05:09.760 --> 05:17.120 So the status, it's quite stable, I've never really reinstalled the box, really from 05:17.120 --> 05:22.440 scratch sometimes it crashes and we fix with X2FS, but having to install, I've not done 05:22.440 --> 05:28.400 it for a decade at least, while we have the build demons in the bin which keep building 05:28.400 --> 05:33.920 package all the time and that goes fine, we have three quarters of the DBN archive which 05:33.920 --> 05:34.920 works fine. 05:34.920 --> 05:40.840 Well, at least it builds, we haven't tested every of them, but nowadays there's a lot 05:40.840 --> 05:47.080 of test suites in the past, in the packages, so at build time of the package, we actually 05:47.080 --> 05:50.960 test the package, so yeah, it works really well. 05:50.960 --> 05:58.120 And we have support management upstream in gccglibc etc, and recently we had a gig's released 05:58.120 --> 06:02.800 which had a hard part of it, so that's great. 06:02.800 --> 06:10.560 So okay, what's the point of today that's the newest things, so first the really hardware part, 06:10.560 --> 06:18.440 so I added PIE for 32 bit machines, which became really a necessity when trying to build 06:18.440 --> 06:25.640 webkit to gtq for instance, because it really requires a lot of memory, so if you have a 32 06:25.640 --> 06:31.360 bit operating system, you have to implement PIE just for this, otherwise yeah, you're quite 06:31.360 --> 06:33.280 screwed. 06:33.280 --> 06:42.080 So we added support for APIC and HPAT, HPAT also is really required nowadays software, really 06:42.080 --> 06:49.000 assumed to have a high precision timing, usually in operating systems, you just advance 06:49.000 --> 06:56.560 time on clock tick on intrep, but that's really not enough for nowadays software, so we've 06:56.560 --> 07:02.160 seen like in post-gray SQL, we had a test suite which was surprised that time doesn't 07:02.160 --> 07:10.840 advance, that much just only every clock, so yeah we implemented it, so we have a PIE 07:10.840 --> 07:19.400 and PIE driving essentially in user space, so for a PIE we just pick up a libacy PIE 07:19.400 --> 07:25.280 here and we run it in use land and whatever the result of the interpreter, we tell the 07:25.280 --> 07:31.240 kernel, okay this intrep we want to configure it in this way, and the PIE avatar is also 07:31.240 --> 07:36.920 a bit of the same, so we have libacy access which has an X86 driver, well we just run it 07:36.920 --> 07:44.840 in user land and then we can let applications use that, continue it on this, so we have 07:44.840 --> 07:52.120 USB support for this and CD, which is essentially using a Ramp USB disk, so it's the 07:52.120 --> 07:58.760 continuation of what we had for SATA disks and just taking the Ramp, so it's actually 07:58.760 --> 08:05.920 BSD drivers, combined for user land and so we just take that, so we have two processes 08:05.920 --> 08:13.880 one for USB disk and one for SATA disks, so for now it embeds the USB stacks so we have 08:13.880 --> 08:19.880 the disk driver and the USB stacks in the same process for simplicity, but we plan to split 08:19.880 --> 08:26.520 that into a USB driving process which we can use for different USB drivers and then 08:26.520 --> 08:35.040 had the disk USB driver on top of it, so for network device we are planning to use Ramp 08:35.040 --> 08:41.640 Net, we have something working already just from one driver for now, previously we were 08:41.640 --> 08:47.920 using a NetDD, so that was two six at the time, we didn't spend the time to upgrade that 08:47.920 --> 08:55.200 because the NetLayer in Linux is advancing so much, so we prefer to keep on with the 08:55.200 --> 09:03.480 BSD source which is much easier to work with, so the idea is that for hardware support we 09:03.480 --> 09:10.840 are basically assuming the maintenance of the Ramp layer on top of BSD, I believe that's 09:10.840 --> 09:20.280 a long term good decision in that the on BSD development is less crazy than Linux, so 09:20.280 --> 09:27.840 yeah, maintaining Ramp at least in the past several years, maybe a decade, maybe we haven't 09:27.840 --> 09:35.280 seen too much work to do to keep up with the pace, so this is how it looks like, no 09:35.280 --> 09:41.640 it is, we have the kernel which is really doing just task memory and IPC and then we run 09:41.640 --> 09:48.800 the ACPAC in its own process, let PCI access in its own process and then Ramp and Sata in 09:48.800 --> 09:55.520 their own process and X2 accesses the disk through Sata Ramp for instance, Sata just 09:55.520 --> 10:01.680 asked PCI access and ACPF on some configuration but otherwise it just accesses the disk 10:01.760 --> 10:12.400 directly and I forgot to write the kernel raises intrep to the Sata Ramp to tell it and 10:12.400 --> 10:23.200 the operation has dominated, so more on software parts, so we have 64 bit support which 10:23.200 --> 10:30.560 is finished, it's running really well on with this, so there was some work previously but 10:30.640 --> 10:37.840 the little pieces that were missing, so that was just the X86 boot, who was implemented, 10:37.840 --> 10:45.600 really implemented X86 booting in the room, almost no more year, just a few hands, how 10:45.600 --> 10:51.920 full do you see it, you start in 16 bit then you move to 32 and then to 64 you have to put the 10:52.000 --> 11:00.480 page table, it's crazy, so yeah that's why it took some time, then we have the RPCs, so 11:01.280 --> 11:09.040 the hardware is really with RPCs everywhere, so we had to teach the RPC Engine about 64 bit, 11:09.920 --> 11:16.880 so basically fixing the translation how you layout the message etc, but once we had done that then 11:16.960 --> 11:24.720 all system calls are actually ported, in that we just fixed make, maybe a couple of bugs here 11:24.720 --> 11:31.440 and there and then we had all the interfaces of files and directories network etc, ported 11:31.440 --> 11:38.880 to 64 bit, we don't have that kind of complex compatibility 32 bit 64 bit that like there is 11:38.880 --> 11:47.920 in Linux, so it went quite easily, we had some work but we went with that some special corners would 11:47.920 --> 11:57.120 be difficult, for gcc and gdb mostly it was plumbing because there is already x86, x4 support there, 11:57.120 --> 12:04.640 of course, and then for the whole part itself, so the translator of everything, there were fixes 12:04.720 --> 12:14.960 about 64 bitness, so not confusing, long ends and everything, but otherwise the software 12:14.960 --> 12:23.520 layers were just fine, and the thing is now that we have fixed the bitness, we know that for ARM 64 12:23.520 --> 12:28.800 which files 64 etc, we won't have to do anything more than this, so yeah it will work fine, 12:28.880 --> 12:36.080 so then the question is how do you get an actual operating system, I mean the package, 12:36.080 --> 12:42.960 you install it and everything, so bootstraping the software, so I did it for Debian, 12:44.000 --> 12:50.400 the essential part was the software there is more and more cross-bildable and that's really great 12:50.400 --> 12:54.560 because then you can actually bootstrap an operating system, a complete operating system 12:55.200 --> 13:01.280 through cross-compilation, so what happened is that first we were using a script from Flavio 13:01.280 --> 13:06.960 that just uses configure, make-making install with target and host options, 13:06.960 --> 13:14.640 to cross-compile, gcc, gldbc etc, just to get something that works, you get to shell and it does 13:14.640 --> 13:20.160 say something, okay, and then we know that okay it seems to be working fine, then we want an actual 13:20.160 --> 13:27.440 distribution, and in Debian we have the reboot-strap script which is basically cross-bilding 13:27.440 --> 13:34.320 all the base package of Debian, so with that we had all the necessary package to actually 13:34.320 --> 13:42.320 installed a bit daemon, so I installed that into an actual hardware system, and then I just let it 13:42.400 --> 13:50.880 build all the rest of Debian, some package do not produce the same when cross-compiling like this 13:50.880 --> 13:56.320 and then compiling natively, so we just we build all the package and just to be sure, 13:57.040 --> 14:03.200 we know just a few cases where there are runtime and tests that are done by configure, 14:03.200 --> 14:07.200 so you really want to recompile once you have an actual native system, 14:07.520 --> 14:17.280 it made the Debian 2025, which was released like last year, so we have a release of 164 bit, 14:17.920 --> 14:26.000 and we have some preliminal work for ARM64, which might come if we spend in our time on it, 14:27.520 --> 14:36.640 so we have a simple support quite recently, which we based on originally has a simple support, 14:36.640 --> 14:42.720 it was really research kernel actually at the time, so that there was already the framework there 14:42.720 --> 14:48.480 for locks scheduling and everything, so we knew everything like that is okay, but then there's 14:48.480 --> 14:56.480 x86 support, which was completely missing for SMP, so I'm with the network on it, 14:57.200 --> 15:03.280 so basically detecting that you have indeed several CPUs, animate them and then start up and the 15:04.240 --> 15:13.360 again crazy, even crazy, you really start again in 16 bit, then 32, but yeah, they fixed it, 15:14.880 --> 15:22.560 Debian fixed a lot of things and also put it to 64, but now it does work, it does put, 15:23.600 --> 15:29.120 for now we are quite cautious in that all the userland translators that we have, for now, 15:29.200 --> 15:36.400 which is execute them on CPUs, so that they are not exposed to actual multi-processor concurrency, 15:36.400 --> 15:45.040 but otherwise all the other processes can go in other CPUs, so we get a polysum for the compiler, 15:45.040 --> 15:52.320 for instance, which is great for C++ and everything, and then once we have fixed the translators 15:52.400 --> 15:59.360 one by one, once we work on one, and we put it on other CPUs, when we see it's stable, 15:59.360 --> 16:05.360 then okay, we can move to the other CPUs, and all the others we keep on one CPUs, so we can 16:06.000 --> 16:12.800 we don't have a switch, a big switch, like in monolithic kernels, where it's either every drivers 16:12.800 --> 16:18.880 is running on all CPUs or just on one, so we can do this progressively. 16:18.960 --> 16:29.760 Okay, so now really the software part, we had some security fixes, so there was a talk and just a couple 16:29.760 --> 16:37.120 of hours before about capacities, so in Gnuma it's called ports, and we have to take care of not 16:37.120 --> 16:43.760 leaking ports, there were some leaks, so I gave fixed that, there were some memory issues also, 16:44.400 --> 16:50.880 it worked on it, and stress energy really we commend using it for your own operating system, 16:50.880 --> 16:57.040 because it really stresses your own operating system, you have a bug that happens one every one 16:57.040 --> 17:02.480 million, it will put the nail on it, so yeah, really use that, it's useful. 17:03.760 --> 17:12.240 And the TCP IP stack used to be an order, Linux 2.2 stack, again it's really hard to follow the 17:12.400 --> 17:19.040 Linux space, so what we plan to do, we have something working already, we don't have 17:19.040 --> 17:25.440 made the switch by default yet, but basically using LWIP, which is maintained, well why not, 17:25.440 --> 17:30.160 it's a libraries, so we can just use it and stuff into a process. 17:33.840 --> 17:40.560 About translators, we used, so in slash dev and slash servers, we used to have records of 17:40.640 --> 17:47.760 slash dev, slash dkwise, slash dev, slash SDA, et cetera, to have records, which are extensions 17:47.760 --> 17:54.640 of the X2 format, which was properly defined, et cetera, but which Linux didn't know at all about, 17:55.360 --> 18:04.320 so we moved to using X et cetera, that Linux does know, which makes it possible to just install 18:04.400 --> 18:11.360 and the hard completely and from a Linux system, with also the all the extra things like translators, 18:13.040 --> 18:17.760 which is really great in that, you can actually create your sales route and things like this, 18:18.800 --> 18:26.000 cross installation, wise, and that works. We have journaling support, which is in progress, 18:27.440 --> 18:33.440 it doesn't seem that hard actually, it's just nobody to time to do something, so we will have it 18:33.520 --> 18:41.600 quite soon, apparently. We have moved to just use XKB for the text console, and to avoid having 18:41.600 --> 18:52.640 to maintain the keyboard layout, but software quality, so we have more and more continuous integration, 18:52.640 --> 19:00.400 so GNUMA has now a make check target, the idea is that it starts QMU and it loads a GNUMA 19:00.400 --> 19:09.760 kernel and a small program that just tests some system calls, so that we can test each piece of the kernel 19:09.760 --> 19:16.080 automatically. It was really, really, really nice and to be able to do the 64-bit port, because then 19:16.080 --> 19:21.280 you don't have to start a whole shell or something complex like this, you start with just each, 19:21.280 --> 19:25.680 and every system call of a microchannel, which is not that much, created tasks, 19:25.840 --> 19:32.400 allocate memory, etc. But once you have these small pieces checked, then the user run goes fine. 19:33.440 --> 19:45.120 So it's now in CI. In Dibian we have CI as well, thanks to porting go on the herd, so we could 19:45.120 --> 19:50.240 compile the GitLab runer, and then we have a runer that is available for Dibian package. 19:51.200 --> 19:58.400 We also have animals for XE Man PostgreSQL. Ideally, we would have integration of 19:58.400 --> 20:05.200 these CI into each and every upstream as much as possible. We have it in G-Lipsy, for instance, 20:05.200 --> 20:11.200 so that people stop breaking the compilation of G-Lipsy on GNU herd, and that's really helpful, 20:11.200 --> 20:16.080 even if they don't actually test, at least it does compile and usually it works fine. 20:16.960 --> 20:24.000 We have fixed some warnings, so I'm just praising Diego for taking the time to do it. 20:24.720 --> 20:31.680 Really, you want to avoid warnings at all costs, because they are really helpful. It is a 20:31.680 --> 20:38.480 habit of hitting battle against GCC, because they introduce them all the time. Ideally, you test 20:38.480 --> 20:44.080 both GCC and LLVM and whatever tool can give you warnings, really take them, fix them. 20:45.040 --> 20:52.560 This one thing I wanted to mention also is P3D in Lipsy, so traditionally to get P3D functions, 20:52.560 --> 20:58.880 you have tooling with minus LP3D. G-Lipsy started moving all these symbols into Lipsy itself, 20:58.880 --> 21:06.560 so you don't have tooling with minus LP3D anymore, and so people nowadays have stopped using 21:06.560 --> 21:12.080 minus LP3D, so we had to make the move if you want to port programs etc, 21:12.080 --> 21:18.960 well, it will be easier to just move the bitred symbols into Lipsy, into your own Lipsy. 21:21.040 --> 21:27.920 Okay, about language, so we did port the rest, so is it the rest that gets ported on 21:27.920 --> 21:32.640 I know how on the contrary it was not clear for the maintainers of rest, for me it's really 21:32.640 --> 21:38.080 rest that has to make some efforts, but okay, it was tedious, it was really tedious, 21:38.080 --> 21:44.400 we don't took it the time to do it, in rest you have to teach, rest all the ABI details, 21:44.400 --> 21:50.800 so each and every function of your Lipsy, all your structures etc, you have to teach it, 21:50.800 --> 21:57.200 you have to find why it's all described. There's a bind gen that is able to generate such 21:57.200 --> 22:03.040 thing from your header, which is the natural way of doing it, but it's not done automatically, 22:03.040 --> 22:07.920 and so you have to take the output of bind gen, look at it, see that some pieces of wrong 22:07.920 --> 22:14.640 that it's not in the shape that upstream would like, so we had to review all of what 22:14.640 --> 22:22.320 and bind gen generated, so the whole ABI of Lipsy basically. It took some time, the problem is that 22:22.320 --> 22:29.360 rest moves really fast, so every 40 days you have a new release, and if you want to build 22:30.080 --> 22:38.800 release N plus 1, you have to have a release N, which means you have ported, it was 174, I think, 22:39.360 --> 22:48.160 and so we had 174 working, okay, but upstream was already 178, so we had to board all patch 22:48.320 --> 22:58.640 74 to 75, 76, 77, 78, oh, they have moved to 79 in between, it's port of 79, no, we are up to date, 22:59.440 --> 23:08.000 so okay, we don't have to do that anymore, but yet a rest is really useful, extremely useful step, 23:08.000 --> 23:15.440 but it's quite hard, and we have seen all the if deaths that we have got to read enough in 23:15.520 --> 23:21.920 the C-language mostly, they have put it a lot in rest, so you will have to put in a lot of crates, 23:23.440 --> 23:30.560 hash config, my target always is this, and so yes, it does have to sink in, yes, like all 23:30.560 --> 23:39.200 unix systems, but yet you have to tell rest about it, there are even two crates that knows about 23:39.520 --> 23:46.480 so you have to port both of them, okay, it's a bit of pain, but yes, in the end we have it, 23:46.480 --> 23:51.680 and yeah, it's it's actually essential, no it is, just to get some basic libraries built, 23:53.200 --> 23:59.520 and we have go as well, so this one did this, we could reuse a lot of PSD code, so we 23:59.600 --> 24:06.720 went really much easier than rest, there were some tweaking, there's one thing we had to fix 24:06.720 --> 24:15.280 that was the stack split support, so when you have a signal, you switch to another stack, 24:15.280 --> 24:20.720 just for the signal and back, it's still not enough for quite a few package, because it's 24:20.720 --> 24:27.440 GCC go that we have ported, we would have to port go along to have all the bienpackages built, 24:27.520 --> 24:36.320 this chava, we had some work a long time ago by Emilio, so we had to add support in the 24:36.320 --> 24:44.240 hard for this, so sick info, the dynamically origin support and things like this, so he did that a long 24:44.240 --> 24:54.880 time ago, Jamie worked on importing Open GTK some time ago, we have GCC networks inside the GCC, 24:54.960 --> 25:00.880 but we would like to have an actual Open GTK, again you have that effect and plus one builds 25:00.880 --> 25:08.160 only with at least N and we have six, seven should be fine and I think it's 25, 25:09.840 --> 25:19.040 okay we'll see, about dissemination we have quarters of the whole, which Joshua took the time to 25:19.120 --> 25:25.360 write and it's really useful to tell people what's happening and when we forget to do it, 25:25.360 --> 25:31.360 people think that it's not moving, while it is actually moving, okay but it is moving, we have some 25:31.360 --> 25:39.120 of this, and so GCC has appeared, so there's a blog post about it, sorry, working on actual 25:39.120 --> 25:48.480 thingpad, we have an i-time distribution showing up, maybe we will see, so basically what do we have, 25:48.560 --> 25:55.520 so to give summary, so we have all of this, so 64 bits, Saka USB support and network drivers, 25:56.720 --> 26:04.320 and this is essentially all in use, and the really good thing is that most of this, we don't maintain, 26:05.440 --> 26:13.920 we don't maintain all these drivers because we refer that to BSDP poll to SIPIC and etc, and I think 26:14.000 --> 26:19.840 it's really useful to just rely on existing libraries rather than just re-implement everything, 26:20.480 --> 26:26.240 for partitioning, this partitioning, okay, it just loses, just use liparted and you're fine with that, 26:27.760 --> 26:34.160 so we have a lot of DPR, we have gigs, etc, and I didn't mention everything that you can look at previous 26:34.160 --> 26:41.920 videos for the herd, we have a lot of stuff that is interesting and we find green control 26:42.400 --> 26:51.440 petrolization and etc, just to show one thing I really like, so here I'm pinging some knood.org, 26:52.080 --> 27:02.400 and here, because maybe the network driver gets stuck or whatever, I just kill the network driver, 27:03.360 --> 27:09.680 and then after some time it throws up again, and it works fine because TCP is really different 27:09.760 --> 27:17.280 and to this, the only thing that happened is here, the only thing that the current, so that 27:17.920 --> 27:22.720 process stopped using an iocq, and then there's a new one that uses the iocq, that's the only thing 27:22.720 --> 27:33.200 that the current, so, and yes, this is what it looks like, everything like this is just a process, 27:33.200 --> 27:38.800 so you can, well if you kill a disk, that's more of a concern because you don't want X2FS to just 27:38.800 --> 27:45.440 continue with the new one, you want to run FSCK in between, but that's just a software step and to have. 27:47.120 --> 27:53.200 So to conclude, there's a lot of things that we kind of achieve, there's a contributing 27:53.200 --> 28:00.800 page where we have the ideas for moving forward, it just needs your help, so thanks for your attention. 28:09.760 --> 28:19.280 Yeah, you mentioned problems with post compilation, yeah, I guess the GenQ has to actually serve 28:19.280 --> 28:25.760 basically the same problem doesn't it? GenQ, Gen2, because they're building essentially the 28:25.760 --> 28:31.200 volumeage from scratch, and sometimes they do in the kind of post compilation nature, so it means 28:31.200 --> 28:38.560 fire there, so to recap, so Gen2 maybe has the same kind of cross compilation issues that we have, 28:38.640 --> 28:45.360 the one thing that we saw was, was it turn or bash, I think it was bash, which was 28:45.360 --> 28:52.640 measuring the size of pipes, and so yes, it's using the actual operating system, and so if it 28:52.640 --> 28:58.400 kind of do this, that it puts value, and unfortunately it was wrong, and then yeah, it was actually 28:58.400 --> 29:04.240 making pure loose characters, due to this because it was feeling but it's, et cetera, so yes, 29:04.320 --> 29:10.720 this is the kind of things that we have seen, quite often programs which are not able to test 29:10.720 --> 29:17.280 things at one time, and they would keep a conservative value, and then they will go fine, 29:17.280 --> 29:23.280 not optimized but at least fine, so most of them we don't see that much of a trouble, a few 29:23.280 --> 29:26.800 details, that's why you want to really recompile everything, but mostly it works. 29:27.440 --> 29:31.440 Other questions? Yes? 29:33.440 --> 29:39.040 Maybe I've missed it, but what's the story about journaling file systems for the original? 29:40.080 --> 29:41.120 Which file system? 29:41.120 --> 29:43.920 Journaling, journaling, as journaling. 29:43.920 --> 29:52.320 Journaling, so basically it's just an additional piece that is, we are still working on it, 29:53.280 --> 30:00.160 you have to put into your file system implementation, some calls to write to the journal and delay 30:00.160 --> 30:08.960 other things, so it's just an addition to the X2FS implementation, that's mostly it, 30:08.960 --> 30:10.560 or maybe I didn't understand the question. 30:14.800 --> 30:18.240 It is getting worked on, yes, we are discussing it on the list right now. 30:18.560 --> 30:26.560 So, can you question if you use drivers from a VSD, why not use file systems from VSD? 30:26.560 --> 30:32.320 Yeah, why not using the file system from VSD, that's one of the, to do these items indeed. 30:33.520 --> 30:39.280 Somebody wanted to implement a journaling file system, okay, it's just a few hundred lines more, 30:39.280 --> 30:44.480 so yeah why not, but indeed we want to use room professor at some point, there's quite some 30:45.360 --> 30:49.120 planning, that's much more involved than just a network card you send, you receive, 30:49.120 --> 30:52.320 you have a lot of operations, but yes, that's one of the ideas we have. 30:52.320 --> 31:02.800 And another thing is, why not make all this runtime to be compatible with Linux binaries? 31:03.520 --> 31:10.720 So you want, you want need to port software, so yeah, we have to wrap it up, 31:10.720 --> 31:12.480 maybe you can take it outside. 31:12.480 --> 31:17.680 Yeah, just to answer quickly, so why not make it, Linux compatible binaries and compatible? 31:18.480 --> 31:23.920 We can recompile free software, it's free software, so yeah, just why not recompile it. 31:25.120 --> 31:27.920 And we have a longer answer, and different.