[00:00.000 --> 00:10.720]  Hello everyone, this is Eke Starra and we're going to talk about the RISVive support on
[00:10.720 --> 00:16.240]  the Geeks Woodstrap or at least the bits I've been working on during this last year.
[00:16.240 --> 00:20.980]  So I'm a telecommunication engineer, I'm a freelance engineer or programmer working
[00:20.980 --> 00:28.920]  at LNQ.tech, which is just my website, I'm a Geeks user and a contributor so many things
[00:28.920 --> 00:34.120]  we're going to talk about today involve Geeks one way or the other and maybe you
[00:34.120 --> 00:40.560]  will remember me from the last year I gave this talk in the this talk you can see here as an
[00:40.560 --> 00:49.640]  as a recapitulation of my last year working on RISVive and as the result of that talk it comes
[00:49.640 --> 00:55.920]  when I'm what I'm going to introduce to you today. So last year I asked for the NNET grant
[00:55.920 --> 01:02.200]  which I mentioned in that talk and we didn't know if it was given or not at that time but now I
[01:02.200 --> 01:10.560]  can say the grant was was given and I've been working for that grant as a part-time during
[01:10.560 --> 01:16.000]  one year and this is the work I'm going to show you today. So the work was based on the
[01:16.000 --> 01:23.720]  bootstrapping process of Geeks or in general for other distros for the RISVive architecture.
[01:24.720 --> 01:30.960]  And yeah we're going to talk about what they did, what did I did I leave for the future,
[01:30.960 --> 01:36.800]  how can how it can be improved and these kind of things. So if you want to read a longer
[01:36.800 --> 01:42.400]  version you have here in the bottom my blog and in my blog there's a series of posts describing
[01:42.400 --> 01:47.440]  every single comment I did so maybe read that one if you want to go into the details. In this
[01:47.440 --> 01:55.880]  talk we're going to just to take a look to a couple of these comments in a very high level way.
[01:55.880 --> 02:01.800]  So let's introduce the bootstrapping issue and why this is important right. So we have free
[02:01.800 --> 02:07.000]  software and we love it right because it lets us audit our programs, we can read the source code
[02:07.000 --> 02:14.280]  of our programs and we can check if we like what they do or if we don't like it. But when we
[02:14.280 --> 02:20.760]  start to have software distributions some other problems appear. For example if a distribution
[02:20.760 --> 02:27.000]  maintainer or someone working in the distribution decides to replace the binaries that are given to
[02:27.000 --> 02:33.640]  us through the package manager with other binaries that have some kind of vulnerabilities or stuff
[02:33.640 --> 02:41.880]  like that they could do that. And we have no way to match the source code we are we suppose
[02:42.040 --> 02:47.640]  that that binary is using we can't really match it to the binary so we don't know this relation
[02:47.640 --> 02:55.480]  right. In geeks we have reproducibility so if the geeks maintainers for a reason imagine they
[02:55.480 --> 03:01.160]  decide to give us the wrong binaries we can always challenge the binaries or from the
[03:01.160 --> 03:06.680]  substitutes and we can check if the result of those binaries that the binaries they are giving to
[03:06.680 --> 03:12.040]  us and the ones we can build ourselves are the same. That's interesting and it's very interesting
[03:12.040 --> 03:21.000]  in many other areas that we're not going to cover but this is only protecting us from people being
[03:21.000 --> 03:29.160]  evil but sometimes a program can be evil too. Imagine this compiler this evil compiler that has
[03:29.240 --> 03:40.360]  sunglasses it decides to introduce vulnerabilities or malware in our final binaries we can think
[03:40.360 --> 03:45.320]  that as we compile the software ourselves the binary is going to have
[03:47.720 --> 03:54.040]  only the functionalities that we can see in the source code but in fact the compiler can be
[03:54.040 --> 04:02.600]  introducing new functionalities that may harm us as a user so the reproducibility here will only
[04:03.960 --> 04:09.320]  ensure that we are going to reproduce this environment here and make the same binary but
[04:09.320 --> 04:16.280]  that binary if the compiler is corrupt in the reproducibility case we are just going to reproduce
[04:16.280 --> 04:21.960]  the same corrupt binaries so we need something else to make sure that the compilers we use
[04:22.920 --> 04:29.560]  are not corrupt because we don't really know and this kind of attack is described by Ken Thompson
[04:29.560 --> 04:37.400]  the one of the authors of UNIX in a paper that is called Reflections on Trust in Trust so you
[04:37.400 --> 04:45.320]  can take a look into it there's a link here to how this one's done in real life so we have to
[04:45.320 --> 04:51.160]  remember that the compilers are also programmed so this issue is recursive if we want we could
[04:51.160 --> 04:59.560]  make a compiler that introduces new this corruption in the next program that is built using it and
[05:00.680 --> 05:07.320]  if the next program is a compiler it could introduce this to reproduce itself so the
[05:07.320 --> 05:13.640]  problem might be here in this compiler but it might be here and this corrupt compiler can
[05:13.640 --> 05:21.560]  introduce the vulnerabilities to the next one so the problem we have here is much deeper
[05:21.560 --> 05:26.440]  it's a recursive problem because the compiler has to be compiled so what's the exit point of this
[05:26.440 --> 05:36.200]  recursion right so imagine we could make a compiler imagine we are just in the realm of the ideas
[05:36.200 --> 05:44.520]  and imagination if we could make a compiler that is just sure that doesn't have to be processed so
[05:44.520 --> 05:49.960]  if we write something in a in a language that doesn't have to be processed that is sure directly
[05:49.960 --> 05:59.320]  for example that would mean we don't need to add this this this arrow here so the conversion
[05:59.320 --> 06:04.920]  between the source and the compiler would be just one line with no no extra things so we could break
[06:04.920 --> 06:11.000]  this thing so we're going to mention some projects that do that in and we're going to introduce that
[06:11.000 --> 06:16.920]  how does it work in real life so that way we could break this problem right this recursion
[06:16.920 --> 06:24.040]  would be stopped so in practice the new linux distributions they are just given as many
[06:24.040 --> 06:31.480]  preview binaries including bus etc and many others so they have to trust all those all those binaries
[06:32.040 --> 06:39.160]  as they don't have any kind of malware inside right they are trusting the ones who build
[06:39.160 --> 06:44.520]  those problems and not only that they are trusting also the compilers that build those
[06:44.520 --> 06:50.440]  programs so there are many layers of trust there because the compilers that compile those software
[06:50.440 --> 06:56.680]  they are also being trusted so it's really hard to know which is who is compiling
[06:57.400 --> 07:03.560]  each thing and where does the compiler they are using coming it's coming from right so there are
[07:03.560 --> 07:09.080]  many issues with that so what we know in practice is that we can compile most of the world using a
[07:09.080 --> 07:17.880]  powerful compiler as ccc so we can base our research or our story on gcc and once we fix
[07:17.880 --> 07:23.960]  the buddhist applicability issue in gcc as everything or mostly everything comes from from a c
[07:24.600 --> 07:30.520]  program or from a c compiler we can bootstrap everything from there so the problem is we can't
[07:30.520 --> 07:37.960]  use a pre-built compiler for building gcc because of the thing i've been talking about during this
[07:37.960 --> 07:47.560]  this minute so the key here is who is compiling the compiler right so if we go to gcc and if we
[07:47.560 --> 07:52.840]  want to compile the world we have a dependency with this which is obviously gcc but gcc also
[07:52.840 --> 07:58.280]  requires a compiler to be built and normally that compiler is going to be what gcc a previous
[07:58.280 --> 08:04.040]  version of that and that gcc it's also going to require another compiler who's who's probably
[08:04.040 --> 08:10.120]  going to be gcc and that also going it's also going to need another compiler which is also going to
[08:10.120 --> 08:18.360]  be a gcc and so on so if we follow these points we are we are just realizing that we don't really
[08:18.360 --> 08:24.200]  know who built the first gcc in this list and probably the first one was just a program written
[08:24.200 --> 08:31.960]  assembly or whatever during the 80s we don't really know so we have to break this this recursion
[08:31.960 --> 08:36.920]  somewhere right so there's there are also a lot of libraries here in the middle it's kind of complex
[08:36.920 --> 08:44.440]  right so we have to make a a project that is a very simple compiler that's able to start this
[08:44.520 --> 08:53.160]  this chain of compilations and just break everything adding one point that that doesn't
[08:53.160 --> 08:59.800]  really need to be trusted right that we can add it and this is this exists already and this is
[08:59.800 --> 09:07.720]  what we have in gigs nowadays so we have the world which is with the world we mean all the all the
[09:07.720 --> 09:13.320]  packages in the world more or less we have a modern gcc that is able to build most of that
[09:13.960 --> 09:23.880]  we have a gcc 7.5 building the modern gcc we have a gcc 4 building that gcc 7 we have a gcc
[09:23.880 --> 09:30.440]  dot 95 building that we have a tiny c compiler in this case you see we are not using gcc anymore
[09:30.440 --> 09:35.720]  so we use a tiny c compiler which is a very small c compiler we use that to build the gcc
[09:36.840 --> 09:40.920]  in our case we are also using in the middle in the middle here somewhere
[09:41.000 --> 09:46.200]  with the strap all tiny c compiler which is a simplified version of tiny cc which is
[09:46.840 --> 09:53.640]  buildable using GNU mesh so we can build it using sorry we can build it using GNU mesh and we also
[09:53.640 --> 10:02.440]  have a state zero bo6 which is a a set of tools that are written in directly in source code so
[10:03.080 --> 10:08.200]  we don't really need to trust any binary and from there we can build a very simple compiler
[10:08.200 --> 10:15.400]  right so with that simple compiler we can just build GNU mesh and with that build the world right
[10:15.400 --> 10:21.000]  so let's let me introduce these these these two projects because maybe you don't know them very
[10:21.000 --> 10:27.480]  well those are very easy to understand the areas gcc c compiler and and a tiny tiny cc which is also
[10:27.480 --> 10:32.680]  a c compiler but these these two are a little bit complex so the case the case of the GNU mesh
[10:32.680 --> 10:37.480]  GNU mesh is a project that has like two legs right one of the legs is an scheme interpreter
[10:37.560 --> 10:43.480]  and the other leg is a c compiler so the c compiler is designed so it's able to build the scheme
[10:43.480 --> 10:49.880]  interpreter and the scheme interpreter is designed so it can interpret the c compiler right so in
[10:49.880 --> 10:54.680]  the end what we have is an scheme interpreter written in c and a c compiler written in a scheme
[10:54.680 --> 11:02.280]  and they are self-hosted right no self-hosted no they are mutually hosted so the scheme interpreter
[11:02.440 --> 11:09.240]  can interpret the c compiler and the other way around so they don't rely on themselves but in
[11:09.240 --> 11:18.040]  the other and the goal of this is to help to create a full bootstrap for unix like operating
[11:18.040 --> 11:23.480]  systems and this is what they are doing in in the case of kicks also the scheme interpreter is written
[11:23.480 --> 11:29.880]  in as you see is simple c and the c compiler is written in a scheme so the the most important
[11:29.880 --> 11:35.400]  part in this description that they just copied from the website and you can you can read more there
[11:35.400 --> 11:41.400]  is that they can be bootstrap using mesh to planet and messy tools these tools are also part from
[11:42.040 --> 11:50.840]  of state zero posix and state zero posix is that mini compiler thingy i told you that it's
[11:52.360 --> 11:58.360]  a literally source code so it starts in a very small seed you can see here like it's
[11:58.920 --> 12:09.640]  it's a 256 byte seed written directly in binary in a in a very in a little bit weird way to make
[12:09.640 --> 12:17.960]  it easier to to read but it's literally binary so we write that in binary and that is is small enough
[12:17.960 --> 12:25.400]  to be to be checked by the user to make sure that that binary is correct and then from that
[12:25.400 --> 12:31.480]  we can start building small tools until we build something that is near to a very simple c
[12:31.480 --> 12:39.000]  compiler so once we reach that we can build the new mess using that and from mess we are able to build
[12:39.000 --> 12:45.960]  a much bigger c compiler as a tiny cc and from from that one we can start building
[12:46.600 --> 12:52.680]  old gcc right so here you see this one is is relying on the kernel but there are other
[12:52.680 --> 12:58.520]  products that don't even trust the kernel so that's very interesting too so wrapping up
[12:58.520 --> 13:05.240]  there's no no corrupt compiler if there's only source code think about that so that's how we how
[13:05.240 --> 13:11.400]  we break the problem uh or how we break the that recursive so in the case of the ris 5 support
[13:11.400 --> 13:17.640]  this is the status of the ris 5 support uh one year ago when i started working on this we had
[13:17.640 --> 13:22.200]  like the world is not applicable because i mean the world there are many packages out there but
[13:22.280 --> 13:29.240]  we have uh in another project if ryan flasner is working on bringing the whole world to ris 5
[13:29.240 --> 13:36.360]  on geeks so that's very interesting too we have modern gccs uh do have ris 5 support starting
[13:36.360 --> 13:43.320]  on 7.5 the older ones don't have any ris 5 support tiny cc does have uh ris 5 support but the
[13:43.320 --> 13:49.800]  bootstrap hour one no because it's fourth from a couple of years ago maybe four years ago or six
[13:49.800 --> 13:55.480]  years ago i don't remember so it doesn't have ris 5 support and genomes does does have some support
[13:55.480 --> 14:02.040]  but it's not but i've tested yet so this is the status of the project so the spoiler of what they
[14:02.040 --> 14:08.200]  did is that i've reported the go the ris 5 support to this gcc and i've reported the ris 5 support
[14:08.200 --> 14:15.000]  to this tiny c compiler and we're going to remove probably this one so we don't really need it so
[14:15.000 --> 14:23.880]  in that case it's like everything has ris 5 support now well not everything but kind of so what i did
[14:23.880 --> 14:33.880]  i started uh working on gcc so i went for gcc 4.6 and i started like putting all the the ris 5 support
[14:33.880 --> 14:40.200]  i had in a more modern gcc but in order to understand that we have to understand a little bit about
[14:40.280 --> 14:47.400]  how does gcc work gcc uses a model that is called debits on phraser and it's not the same model that
[14:47.400 --> 14:53.400]  we can see in most of the compilers we have read in books and stuff like that this one the intermediate
[14:53.400 --> 14:58.920]  representation of gcc is machine dependent and it's based on something that is called phraser's
[14:58.920 --> 15:05.240]  transfer language so in a very high level way what we have is a high level language imagine c c
[15:05.240 --> 15:11.000]  plus plus we read that we convert that to an ast that it is called jimple in this case in gcc i
[15:11.000 --> 15:17.320]  don't i don't remember the reason but there is a reason behind this name um that is converted to
[15:17.320 --> 15:22.120]  to rtl to the intermediate representation that is machine dependent this one is machine independent
[15:22.760 --> 15:28.600]  and we optimize on top of that we generate new rtl with other with other structure and that
[15:28.600 --> 15:35.960]  structure is matched against some rtl templates and from those we obtain the assembly right from
[15:35.960 --> 15:43.480]  the assembly onwards is just calling as the as the genu assembler and ld the genu linker so these
[15:43.480 --> 15:49.720]  conversions are kind of easy to do but but not really so the first one the gimbal to rtl conversion
[15:49.720 --> 15:56.200]  is is that using identifiers so if imagine that we have the gimbal instruction at so we are going
[15:56.200 --> 16:03.800]  to search for the rtl instruction called add and we're going to to just convert from one to the other
[16:03.800 --> 16:11.080]  in the case of the optimizations they are then checking some templates of the rtl so if we have
[16:11.080 --> 16:15.240]  several instructions together and we have an instruction that can do everything together
[16:15.240 --> 16:21.160]  we can we can expand or or compress instructions right there are some rules we'll have to write
[16:21.160 --> 16:26.760]  and then there is the rtl to assembly conversion that is described in all the rtl instruction
[16:26.760 --> 16:33.320]  we're going to see an example here so this is this is an example of an of a machine description
[16:33.320 --> 16:39.800]  file or a very small piece of a very big machine description file that you can find them in the
[16:39.800 --> 16:49.400]  gcc source code at gcc slash config slash the machine you want to use slash whatever dot md
[16:49.400 --> 16:55.480]  from machine description and this is how the instructions look so the instruction here is
[16:55.480 --> 17:02.760]  called add di3 the add is from the add instruction the di is from double integrals so it's for big
[17:02.760 --> 17:08.840]  integrals and the three is that is going to use three arguments so this is the one that is going
[17:08.840 --> 17:14.440]  to be matched against the identifiers in gimpel so the conversion is going to be like that then
[17:14.440 --> 17:22.200]  this is what this this instruction looks like this is predicate so this is only going to be
[17:22.200 --> 17:28.600]  used this instruction in the case that the target is a 64-bit target that's why that's because it's
[17:28.600 --> 17:33.960]  using a double integer this is the assembly code is going to generate this instruction
[17:33.960 --> 17:38.520]  and these are some attributes i don't really get about those so the behavior of the instruction
[17:38.520 --> 17:46.680]  is described here and it says you have to set the register operand zero you have to set it to the
[17:46.680 --> 17:53.640]  value of the plus of the register operand one and the arithmetic operand two that's the way it works
[17:53.640 --> 18:00.120]  so this add instruction has this meaning and these match operand parts are pieces that are going to
[18:00.120 --> 18:05.560]  be matched against the against the RTL code we have so first it's going to generate like a like a
[18:05.560 --> 18:11.640]  general RTL code and then it's going to match against these blocks and if the the match it's
[18:11.640 --> 18:18.040]  going to generate these assembly files per line so if we had another rule that is more specific than
[18:18.040 --> 18:23.080]  this one and that matches before this is not going to be matched and it's going to generate another
[18:23.080 --> 18:28.600]  assembly this is a little bit how it works so these files are processed c files are generated
[18:28.600 --> 18:35.000]  and these c files are included in the code of the gcc so that's the gcc build system which is
[18:35.000 --> 18:40.760]  really really complex so you can think that if all this is made in this kind of machine description
[18:40.760 --> 18:46.680]  files that are kind of a configuration file you can think okay so if you take these machine
[18:46.680 --> 18:52.760]  descriptor files from from a gcc that supports RISC5 and you move them to the older RISC5 that
[18:53.320 --> 18:59.640]  to the older gcc that doesn't support RISC5 it should work right it you should be able to just
[18:59.640 --> 19:07.000]  compile the gcc and make it work but reality is not that simple we also have other types of things
[19:07.000 --> 19:13.720]  to to to bring another target to gcc so one of them is the target description matrix and functions
[19:13.720 --> 19:20.760]  which is just a very big header file with a lot of things defined there and there are also libraries
[19:20.760 --> 19:27.720]  like libgcc and many others it's more complex more complex than it looks so my process here was
[19:27.720 --> 19:37.400]  just trying to solve the missing pieces of code i found here and there so what i did was exactly that
[19:37.400 --> 19:44.520]  i went to the gcc code base to repeat the commit where the RISC5 support was added to repeat that
[19:44.520 --> 19:50.840]  to the past and in the past i started fixing all the problems i was finding there were many there
[19:50.840 --> 19:58.200]  were missing i in a sense so i have to fix them or add new ones or use older constructs that were
[19:58.200 --> 20:05.400]  equivalent to those there were also some RTL constructs that didn't exist i had to make some
[20:05.400 --> 20:12.680]  extra predicates i had to convert all the new api to the cc api that we had in the past
[20:13.960 --> 20:19.160]  many many things then the harder one was the libgcc because that was related with the build
[20:19.160 --> 20:24.920]  system and the gcc build system is really complex so i didn't really understand how it worked but
[20:24.920 --> 20:32.920]  i finally i made it work somehow so you can read these two blog posts where i described the all the
[20:32.920 --> 20:41.160]  changes i had to make and i go pretty much in a in a very detailed way in the description so you
[20:41.160 --> 20:47.160]  you can go and read those if you're interested in the code itself so about tiny cc i had a
[20:47.160 --> 20:55.880]  similar issue but the the the git history wasn't that well described so i had to go and just take
[20:55.880 --> 21:04.520]  take some files try to overwrite and make it a little bit by hand um same thing uh i packaged
[21:04.520 --> 21:09.800]  everything for gigs to be able to reproduce the the the work i was doing in another computer and
[21:09.800 --> 21:15.800]  let my friends help me um yeah and just started reading the code from the modern tiny cc and
[21:15.800 --> 21:23.400]  started adding it to the old tiny cc that that was the base of our fork of the buddhistrapable
[21:23.400 --> 21:31.160]  tiny cc um it was really hard to do tiny cc is super hard to read for me has many many many
[21:31.160 --> 21:38.840]  variables that their name is only one character functions that their name is o or o f and stuff
[21:38.840 --> 21:45.160]  like that it's really really hard to to read but i managed to make it work i don't remember very well
[21:45.160 --> 21:50.680]  how so if you want to read about that you have this blog post that describes it in a little bit
[21:50.680 --> 21:57.320]  more of with a little bit more of detail um i don't recommend it either in this case i didn't
[21:57.320 --> 22:04.120]  really make a really really interesting work here here it was kind of complex so and the
[22:04.120 --> 22:09.800]  only thing missing in this one i think this one is pretty pretty well done the only thing missing
[22:09.880 --> 22:15.960]  some optimization code and we decided or i decided to leave it outside the project because
[22:16.920 --> 22:21.880]  it would affect other architectures too so the the only difference we have with the upstream
[22:21.880 --> 22:28.120]  code is this one right so the the left is a program compiled with the optimized version and the other
[22:28.120 --> 22:33.880]  is the the one the one i did the only difference you can see is the jump here in the 4c that doesn't
[22:33.880 --> 22:40.680]  really like doesn't have just one instruction it has distraction is doubled because the there's
[22:41.640 --> 22:48.120]  is not applying the optimization of cleaning this out after after this jump is is set it doesn't
[22:48.120 --> 22:56.120]  really matter that much to me at least so yeah it doesn't really matter because this instruction
[22:56.200 --> 23:03.880]  is not going to be called ever so it doesn't really change that much and this this this
[23:03.880 --> 23:07.880]  this compiler is not going to be a production compiler so it doesn't really really really matter
[23:07.880 --> 23:14.760]  so considering those both backends are kind of working and generating these five binaries
[23:15.560 --> 23:21.320]  there are some things that need to be done we have to remember that that i only worked on the
[23:21.400 --> 23:28.600]  backends and something i didn't tell you is that i in order to test them i was working in a in a
[23:28.600 --> 23:33.480]  cross-compile environment so i was working on my machine making binaries for ris 5 and i test
[23:33.480 --> 23:39.960]  the backends that way but we have to test all these things in in proper hardware to make sure
[23:39.960 --> 23:46.760]  that we can build one thing with the next and and make the whole chain work so for gcc we have to
[23:46.760 --> 23:52.760]  properly package it tested with c++ support with i didn't have time to test and fix all the libraries
[23:52.760 --> 24:00.920]  that can be missing on the c++ side then we can we have to describe how to build that using tiny cc
[24:00.920 --> 24:07.880]  directly because we had before we had gcc 2.95 in the middle and we don't have it available in in
[24:07.880 --> 24:17.720]  ris 5 we have to be able to build gcc 7.5 using the back ported one too in also in ris 5 for tiny cc
[24:17.720 --> 24:24.520]  we have to build the bootstrap old tiny cc using the new mesh um and we have to decide if we are
[24:24.520 --> 24:30.760]  going for the to use the upstream one or we are just going to use the bootstrap old tiny cc in a
[24:30.760 --> 24:36.280]  minute so there are some decisions to be made here in the case of mesh we have to review the
[24:36.280 --> 24:42.600]  ris 5 support which is something we didn't do yet but i think it's pretty pretty advanced so it should
[24:42.600 --> 24:49.800]  be easy to merge and in geeks from the geek side we have to package everything so everything is very
[24:49.800 --> 24:55.880]  well described and the steps for building one compiler with the other is well described in geeks
[24:55.880 --> 25:03.320]  so everyone can benefit and can use everyone can use it and in the end as an extra we have to do
[25:03.320 --> 25:08.680]  all this in real hardware so we don't have the problems over the cross compilation and stuff
[25:08.680 --> 25:14.360]  like that which are cool for testing but they are not cool if we want to make something that is useful
[25:14.360 --> 25:22.040]  in real life so as last words yes i'm just finishing um as you can imagine from the talk
[25:22.040 --> 25:28.360]  there's a lot of work to be done but most of it is just the result of the integration that needs
[25:28.360 --> 25:34.840]  to be done after all the time i've been working just bringing some of the the dots in this line
[25:35.480 --> 25:41.320]  to ris 5 so now the work that is missing is packaging and integrating everything and maybe
[25:41.320 --> 25:46.760]  i'm not the best guy for doing that so we are looking for a little bit more funding from an
[25:46.760 --> 25:52.280]  internet and i think internet is is open to give us some help on that and we are going to involve
[25:52.280 --> 25:57.000]  more more people doing this kind of work so if you like this kind of work you can also join us
[25:57.000 --> 26:02.600]  and help us do this and also i want to thank all the people that that was involved in this one
[26:02.600 --> 26:09.960]  because i had help from many people and some people um told me that they want to help me
[26:09.960 --> 26:16.040]  further so thank you very much to everyone and just need just to finish if you want to to join us
[26:16.040 --> 26:21.560]  or if you have any question uh or anything like that you have my email there and these are the
[26:21.560 --> 26:29.480]  relevant uh ioc channels you can you can join and also just to finish i know this is hard i know
[26:29.480 --> 26:37.240]  this is complex but if you want to join it and if you are open to learn new things fight against
[26:37.240 --> 26:43.320]  all compilers and some code that is not very easy to read sometimes i'll be there right i'll be there
[26:43.320 --> 26:49.560]  trying to help you and give you the psychological support that everyone needs sometimes so just
[26:49.560 --> 26:55.560]  just join it's going to be a lot of fun i promise so thank you very much bye bye thanks for being there
[27:06.360 --> 27:12.760]  we are live then okay that's great yeah okay let's answer some questions then yeah okay so
[27:13.560 --> 27:19.400]  uh there's a question about the hardware i'm using to compile so yeah the easiest answer is just
[27:19.400 --> 27:26.120]  i use my laptop i have a laptop which is not a very powerful one but it's not even it's a good one
[27:26.120 --> 27:35.080]  and i just use that i'm a very patient guy i i have to compile many gcc many times yeah yes patient
[27:35.720 --> 27:41.720]  yes wait to wait to finish and that's that's what i'm doing for the future we are looking
[27:41.720 --> 27:47.400]  on buying some risk risk five hardware in order to test all these things in native
[27:47.960 --> 27:54.040]  in a native machine but at the moment i'm just using my laptop so yeah that's that's the answer
[27:56.120 --> 28:01.880]  so um what does geeks and this project think about rust versus sea that's on the first
[28:01.880 --> 28:08.840]  oh that's a good question um i can't i can't talk on on the name of geeks but i can't talk about
[28:08.840 --> 28:16.040]  around myself uh rust is a cool language it's a fantastic language but it's it's it's huge so
[28:16.040 --> 28:21.880]  sometimes i think it's going to be really hard to bootstrap we had issues with that if i don't
[28:21.880 --> 28:29.560]  remember uh wrong right like we have to build it through gcc and start like the bootstrap
[28:29.560 --> 28:35.880]  in process is really complex right so yeah rust is cool but but for bootstrap in issue is is not
[28:35.880 --> 28:44.280]  the best and in the case of sea we have i think yeah we are the relationship has been cut off so
[28:44.920 --> 28:52.440]  yeah okay yeah you can continue your point in the chat here or someone shows in this in the
[28:52.440 --> 28:59.480]  talk room okay yeah what what do i have the link to the to the next room or how how is it is
[29:00.120 --> 29:05.480]  so if you're in the bringing this quite a big bootstrap room that is your talk specific room
[29:06.200 --> 29:13.400]  okay so people can come and interact with you here even when the other talks are going on okay yeah
[29:22.200 --> 29:26.760]  so thanks for speaking at the first time you guys thank you thank you for being there and helping me
[29:29.080 --> 29:33.160]  i'll catch you later then i'll move on to the next yeah bye bye
[29:35.880 --> 29:36.380]  you