Okay, so good afternoon, everybody, so we talk a bit about GNU Hurt indeed, the latest
progress from various people, actually, a few people have joined the choice recently.
I would like to make just a quick recap on the purpose of the Hurt and some things that
have been available for a long time already.
That's my opinion.
The Hurt is all about freedom zero, that is freedom zero in free software is the freedom
to run the program for all purpose.
And for me that includes the freedom from the season mean of the machine.
That is why all these programs hidden in slash has been, I should be able to partition
an image, there's no reason to be able to do it and make it and mount it and mounting
on Linux is a privileged operation.
It shouldn't be a privileged operation, I should be able to mount an image, take something
out of it and everything.
The idea is that I have access to some part of the disk, I have access to the network, I want
to be able to do anything with that.
And that's also the freedom to innovate, that is, if you want to experiment with a five
system, you should be able to do this without having to insert a module into a kernel or
whatever.
Maybe you have a personal workflow that match some use case and not the ones that were configured.
And maybe you have a PCI card in a machine and you want to give it to a user and whatever
he wants to do with it.
And conversely, you want to have some freedom from these behaving programs, so for the
administrators to get free of the bugs introduced by the users, but also the admin get rid
of the bugs of the drivers and everything.
So that's why we want to isolate things.
So that's what it looks like on NewHurde.
So we have the micro kernel here and basically the goal is to just manage the task memory
IPC and then everything else is in NewHurde.
So here we have like Proc who knows about processes, if you have finite the TCP-IP stack
X2FS for the file system, or who knows about who is who.
And then we have actual programs, a shell and a copain.
And what happens is the shell is actually when it opens a file, it asks X2FS and X2FS
as asks old, but who is that guy who is opening a file, what authorizations does it have.
Which means that when a server crashes, it's not a problem, you get a narrow, you don't
get a blue screen or something or whatever, you just get errors.
And it's also easier to tune and to debug, you can attach to X2FS and then put breakpoints
into your file systems.
And then since it's easier to develop than you do, can do crazy things.
In that the hard console text controls, controls are can actually print all kinds of fonts,
including Chinese and everything, because it loads cliffs on the fly, because it's easy
to do without the kernel way of developing things and just use a lot of things.
Then we can virtualize at very fine grain, we had a toast about it, previously at first
them.
Just to give an example, so here I have the TSP IP stack and I'm stopping on it, an FTP and
translator to access files and transparently through FTP, then I have an ISO system translator
who knows about ISO image and then I can run a shell that opens a file in it.
So to show how it looks like, so here I'm putting a translator on my home, which is called
FTP colon, which is a multiplexer of the host name for the FTP translator.
And so I do it just once for the whole installation of my system.
And then when I want to mount a ISO image, I just tell, okay take this ISO image, so it's
inside that mount point, so we access that FTP server and then we get an ISO image.
And we mount this through the ISO translator on M&T.
And then when we can look at it and we have the files, we can even extract things, we can
mount an X2 image inside the ISO image and take things from there, everything is possible.
And that's possibly stored in the file system that this is stored for good, even after
rebooting and things which are fun, like a signature file, which changes every time you
open it, it actually runs a new instance of fortune, so you get a new content every time
you open it.
So yeah, that's fun.
So the status, it's quite stable, I've never really reinstalled the box, really from
scratch sometimes it crashes and we fix with X2FS, but having to install, I've not done
it for a decade at least, while we have the build demons in the bin which keep building
package all the time and that goes fine, we have three quarters of the DBN archive which
works fine.
Well, at least it builds, we haven't tested every of them, but nowadays there's a lot
of test suites in the past, in the packages, so at build time of the package, we actually
test the package, so yeah, it works really well.
And we have support management upstream in gccglibc etc, and recently we had a gig's released
which had a hard part of it, so that's great.
So okay, what's the point of today that's the newest things, so first the really hardware part,
so I added PIE for 32 bit machines, which became really a necessity when trying to build
webkit to gtq for instance, because it really requires a lot of memory, so if you have a 32
bit operating system, you have to implement PIE just for this, otherwise yeah, you're quite
screwed.
So we added support for APIC and HPAT, HPAT also is really required nowadays software, really
assumed to have a high precision timing, usually in operating systems, you just advance
time on clock tick on intrep, but that's really not enough for nowadays software, so we've
seen like in post-gray SQL, we had a test suite which was surprised that time doesn't
advance, that much just only every clock, so yeah we implemented it, so we have a PIE
and PIE driving essentially in user space, so for a PIE we just pick up a libacy PIE
here and we run it in use land and whatever the result of the interpreter, we tell the
kernel, okay this intrep we want to configure it in this way, and the PIE avatar is also
a bit of the same, so we have libacy access which has an X86 driver, well we just run it
in user land and then we can let applications use that, continue it on this, so we have
USB support for this and CD, which is essentially using a Ramp USB disk, so it's the
continuation of what we had for SATA disks and just taking the Ramp, so it's actually
BSD drivers, combined for user land and so we just take that, so we have two processes
one for USB disk and one for SATA disks, so for now it embeds the USB stacks so we have
the disk driver and the USB stacks in the same process for simplicity, but we plan to split
that into a USB driving process which we can use for different USB drivers and then
had the disk USB driver on top of it, so for network device we are planning to use Ramp
Net, we have something working already just from one driver for now, previously we were
using a NetDD, so that was two six at the time, we didn't spend the time to upgrade that
because the NetLayer in Linux is advancing so much, so we prefer to keep on with the
BSD source which is much easier to work with, so the idea is that for hardware support we
are basically assuming the maintenance of the Ramp layer on top of BSD, I believe that's
a long term good decision in that the on BSD development is less crazy than Linux, so
yeah, maintaining Ramp at least in the past several years, maybe a decade, maybe we haven't
seen too much work to do to keep up with the pace, so this is how it looks like, no
it is, we have the kernel which is really doing just task memory and IPC and then we run
the ACPAC in its own process, let PCI access in its own process and then Ramp and Sata in
their own process and X2 accesses the disk through Sata Ramp for instance, Sata just
asked PCI access and ACPF on some configuration but otherwise it just accesses the disk
directly and I forgot to write the kernel raises intrep to the Sata Ramp to tell it and
the operation has dominated, so more on software parts, so we have 64 bit support which
is finished, it's running really well on with this, so there was some work previously but
the little pieces that were missing, so that was just the X86 boot, who was implemented,
really implemented X86 booting in the room, almost no more year, just a few hands, how
full do you see it, you start in 16 bit then you move to 32 and then to 64 you have to put the
page table, it's crazy, so yeah that's why it took some time, then we have the RPCs, so
the hardware is really with RPCs everywhere, so we had to teach the RPC Engine about 64 bit,
so basically fixing the translation how you layout the message etc, but once we had done that then
all system calls are actually ported, in that we just fixed make, maybe a couple of bugs here
and there and then we had all the interfaces of files and directories network etc, ported
to 64 bit, we don't have that kind of complex compatibility 32 bit 64 bit that like there is
in Linux, so it went quite easily, we had some work but we went with that some special corners would
be difficult, for gcc and gdb mostly it was plumbing because there is already x86, x4 support there,
of course, and then for the whole part itself, so the translator of everything, there were fixes
about 64 bitness, so not confusing, long ends and everything, but otherwise the software
layers were just fine, and the thing is now that we have fixed the bitness, we know that for ARM 64
which files 64 etc, we won't have to do anything more than this, so yeah it will work fine,
so then the question is how do you get an actual operating system, I mean the package,
you install it and everything, so bootstraping the software, so I did it for Debian,
the essential part was the software there is more and more cross-bildable and that's really great
because then you can actually bootstrap an operating system, a complete operating system
through cross-compilation, so what happened is that first we were using a script from Flavio
that just uses configure, make-making install with target and host options,
to cross-compile, gcc, gldbc etc, just to get something that works, you get to shell and it does
say something, okay, and then we know that okay it seems to be working fine, then we want an actual
distribution, and in Debian we have the reboot-strap script which is basically cross-bilding
all the base package of Debian, so with that we had all the necessary package to actually
installed a bit daemon, so I installed that into an actual hardware system, and then I just let it
build all the rest of Debian, some package do not produce the same when cross-compiling like this
and then compiling natively, so we just we build all the package and just to be sure,
we know just a few cases where there are runtime and tests that are done by configure,
so you really want to recompile once you have an actual native system,
it made the Debian 2025, which was released like last year, so we have a release of 164 bit,
and we have some preliminal work for ARM64, which might come if we spend in our time on it,
so we have a simple support quite recently, which we based on originally has a simple support,
it was really research kernel actually at the time, so that there was already the framework there
for locks scheduling and everything, so we knew everything like that is okay, but then there's
x86 support, which was completely missing for SMP, so I'm with the network on it,
so basically detecting that you have indeed several CPUs, animate them and then start up and the
again crazy, even crazy, you really start again in 16 bit, then 32, but yeah, they fixed it,
Debian fixed a lot of things and also put it to 64, but now it does work, it does put,
for now we are quite cautious in that all the userland translators that we have, for now,
which is execute them on CPUs, so that they are not exposed to actual multi-processor concurrency,
but otherwise all the other processes can go in other CPUs, so we get a polysum for the compiler,
for instance, which is great for C++ and everything, and then once we have fixed the translators
one by one, once we work on one, and we put it on other CPUs, when we see it's stable,
then okay, we can move to the other CPUs, and all the others we keep on one CPUs, so we can
we don't have a switch, a big switch, like in monolithic kernels, where it's either every drivers
is running on all CPUs or just on one, so we can do this progressively.
Okay, so now really the software part, we had some security fixes, so there was a talk and just a couple
of hours before about capacities, so in Gnuma it's called ports, and we have to take care of not
leaking ports, there were some leaks, so I gave fixed that, there were some memory issues also,
it worked on it, and stress energy really we commend using it for your own operating system,
because it really stresses your own operating system, you have a bug that happens one every one
million, it will put the nail on it, so yeah, really use that, it's useful.
And the TCP IP stack used to be an order, Linux 2.2 stack, again it's really hard to follow the
Linux space, so what we plan to do, we have something working already, we don't have
made the switch by default yet, but basically using LWIP, which is maintained, well why not,
it's a libraries, so we can just use it and stuff into a process.
About translators, we used, so in slash dev and slash servers, we used to have records of
slash dev, slash dkwise, slash dev, slash SDA, et cetera, to have records, which are extensions
of the X2 format, which was properly defined, et cetera, but which Linux didn't know at all about,
so we moved to using X et cetera, that Linux does know, which makes it possible to just install
and the hard completely and from a Linux system, with also the all the extra things like translators,
which is really great in that, you can actually create your sales route and things like this,
cross installation, wise, and that works. We have journaling support, which is in progress,
it doesn't seem that hard actually, it's just nobody to time to do something, so we will have it
quite soon, apparently. We have moved to just use XKB for the text console, and to avoid having
to maintain the keyboard layout, but software quality, so we have more and more continuous integration,
so GNUMA has now a make check target, the idea is that it starts QMU and it loads a GNUMA
kernel and a small program that just tests some system calls, so that we can test each piece of the kernel
automatically. It was really, really, really nice and to be able to do the 64-bit port, because then
you don't have to start a whole shell or something complex like this, you start with just each,
and every system call of a microchannel, which is not that much, created tasks,
allocate memory, etc. But once you have these small pieces checked, then the user run goes fine.
So it's now in CI. In Dibian we have CI as well, thanks to porting go on the herd, so we could
compile the GitLab runer, and then we have a runer that is available for Dibian package.
We also have animals for XE Man PostgreSQL. Ideally, we would have integration of
these CI into each and every upstream as much as possible. We have it in G-Lipsy, for instance,
so that people stop breaking the compilation of G-Lipsy on GNU herd, and that's really helpful,
even if they don't actually test, at least it does compile and usually it works fine.
We have fixed some warnings, so I'm just praising Diego for taking the time to do it.
Really, you want to avoid warnings at all costs, because they are really helpful. It is a
habit of hitting battle against GCC, because they introduce them all the time. Ideally, you test
both GCC and LLVM and whatever tool can give you warnings, really take them, fix them.
This one thing I wanted to mention also is P3D in Lipsy, so traditionally to get P3D functions,
you have tooling with minus LP3D. G-Lipsy started moving all these symbols into Lipsy itself,
so you don't have tooling with minus LP3D anymore, and so people nowadays have stopped using
minus LP3D, so we had to make the move if you want to port programs etc,
well, it will be easier to just move the bitred symbols into Lipsy, into your own Lipsy.
Okay, about language, so we did port the rest, so is it the rest that gets ported on
I know how on the contrary it was not clear for the maintainers of rest, for me it's really
rest that has to make some efforts, but okay, it was tedious, it was really tedious,
we don't took it the time to do it, in rest you have to teach, rest all the ABI details,
so each and every function of your Lipsy, all your structures etc, you have to teach it,
you have to find why it's all described. There's a bind gen that is able to generate such
thing from your header, which is the natural way of doing it, but it's not done automatically,
and so you have to take the output of bind gen, look at it, see that some pieces of wrong
that it's not in the shape that upstream would like, so we had to review all of what
and bind gen generated, so the whole ABI of Lipsy basically. It took some time, the problem is that
rest moves really fast, so every 40 days you have a new release, and if you want to build
release N plus 1, you have to have a release N, which means you have ported, it was 174, I think,
and so we had 174 working, okay, but upstream was already 178, so we had to board all patch
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,
so okay, we don't have to do that anymore, but yet a rest is really useful, extremely useful step,
but it's quite hard, and we have seen all the if deaths that we have got to read enough in
the C-language mostly, they have put it a lot in rest, so you will have to put in a lot of crates,
hash config, my target always is this, and so yes, it does have to sink in, yes, like all
unix systems, but yet you have to tell rest about it, there are even two crates that knows about
so you have to port both of them, okay, it's a bit of pain, but yes, in the end we have it,
and yeah, it's it's actually essential, no it is, just to get some basic libraries built,
and we have go as well, so this one did this, we could reuse a lot of PSD code, so we
went really much easier than rest, there were some tweaking, there's one thing we had to fix
that was the stack split support, so when you have a signal, you switch to another stack,
just for the signal and back, it's still not enough for quite a few package, because it's
GCC go that we have ported, we would have to port go along to have all the bienpackages built,
this chava, we had some work a long time ago by Emilio, so we had to add support in the
hard for this, so sick info, the dynamically origin support and things like this, so he did that a long
time ago, Jamie worked on importing Open GTK some time ago, we have GCC networks inside the GCC,
but we would like to have an actual Open GTK, again you have that effect and plus one builds
only with at least N and we have six, seven should be fine and I think it's 25,
okay we'll see, about dissemination we have quarters of the whole, which Joshua took the time to
write and it's really useful to tell people what's happening and when we forget to do it,
people think that it's not moving, while it is actually moving, okay but it is moving, we have some
of this, and so GCC has appeared, so there's a blog post about it, sorry, working on actual
thingpad, we have an i-time distribution showing up, maybe we will see, so basically what do we have,
so to give summary, so we have all of this, so 64 bits, Saka USB support and network drivers,
and this is essentially all in use, and the really good thing is that most of this, we don't maintain,
we don't maintain all these drivers because we refer that to BSDP poll to SIPIC and etc, and I think
it's really useful to just rely on existing libraries rather than just re-implement everything,
for partitioning, this partitioning, okay, it just loses, just use liparted and you're fine with that,
so we have a lot of DPR, we have gigs, etc, and I didn't mention everything that you can look at previous
videos for the herd, we have a lot of stuff that is interesting and we find green control
petrolization and etc, just to show one thing I really like, so here I'm pinging some knood.org,
and here, because maybe the network driver gets stuck or whatever, I just kill the network driver,
and then after some time it throws up again, and it works fine because TCP is really different
and to this, the only thing that happened is here, the only thing that the current, so that
process stopped using an iocq, and then there's a new one that uses the iocq, that's the only thing
that the current, so, and yes, this is what it looks like, everything like this is just a process,
so you can, well if you kill a disk, that's more of a concern because you don't want X2FS to just
continue with the new one, you want to run FSCK in between, but that's just a software step and to have.
So to conclude, there's a lot of things that we kind of achieve, there's a contributing
page where we have the ideas for moving forward, it just needs your help, so thanks for your attention.
Yeah, you mentioned problems with post compilation, yeah, I guess the GenQ has to actually serve
basically the same problem doesn't it? GenQ, Gen2, because they're building essentially the
volumeage from scratch, and sometimes they do in the kind of post compilation nature, so it means
fire there, so to recap, so Gen2 maybe has the same kind of cross compilation issues that we have,
the one thing that we saw was, was it turn or bash, I think it was bash, which was
measuring the size of pipes, and so yes, it's using the actual operating system, and so if it
kind of do this, that it puts value, and unfortunately it was wrong, and then yeah, it was actually
making pure loose characters, due to this because it was feeling but it's, et cetera, so yes,
this is the kind of things that we have seen, quite often programs which are not able to test
things at one time, and they would keep a conservative value, and then they will go fine,
not optimized but at least fine, so most of them we don't see that much of a trouble, a few
details, that's why you want to really recompile everything, but mostly it works.
Other questions? Yes?
Maybe I've missed it, but what's the story about journaling file systems for the original?
Which file system?
Journaling, journaling, as journaling.
Journaling, so basically it's just an additional piece that is, we are still working on it,
you have to put into your file system implementation, some calls to write to the journal and delay
other things, so it's just an addition to the X2FS implementation, that's mostly it,
or maybe I didn't understand the question.
It is getting worked on, yes, we are discussing it on the list right now.
So, can you question if you use drivers from a VSD, why not use file systems from VSD?
Yeah, why not using the file system from VSD, that's one of the, to do these items indeed.
Somebody wanted to implement a journaling file system, okay, it's just a few hundred lines more,
so yeah why not, but indeed we want to use room professor at some point, there's quite some
planning, that's much more involved than just a network card you send, you receive,
you have a lot of operations, but yes, that's one of the ideas we have.
And another thing is, why not make all this runtime to be compatible with Linux binaries?
So you want, you want need to port software, so yeah, we have to wrap it up,
maybe you can take it outside.
Yeah, just to answer quickly, so why not make it, Linux compatible binaries and compatible?
We can recompile free software, it's free software, so yeah, just why not recompile it.
And we have a longer answer, and different.