[00:00.000 --> 00:07.680]  Okay, so, hello everybody.
[00:07.680 --> 00:09.520]  I am a frying flasherner.
[00:09.520 --> 00:16.040]  I work on porting risk five to GNU Geeks or GNU Geeks to risk five, depending on which
[00:16.040 --> 00:18.400]  way you look at things.
[00:18.400 --> 00:24.440]  I've been involved with Geeks as a packager and involved with Geeks in general since about
[00:24.440 --> 00:25.440]  2015.
[00:26.440 --> 00:33.080]  Yes, over the years I've just ended up touching everything in the code base just by accident
[00:33.080 --> 00:35.000]  to just end up happening.
[00:35.000 --> 00:45.400]  I also worked, I guess the first big project was porting Geeks to AR64, which was similar
[00:45.400 --> 00:50.600]  but different with a lot of pieces.
[00:50.600 --> 00:56.240]  So this slide I meant to fill in a bit, but not very good with drawing on the computer.
[00:56.240 --> 00:59.720]  So some quick stuff about Geeks.
[00:59.720 --> 01:04.200]  It is a, at the heart of it, it's a transactional package manager.
[01:04.200 --> 01:09.400]  So that means that anything that you do, you can undo and roll back.
[01:09.400 --> 01:15.400]  And so that gives you the chance to, I guess in terms of porting things, you get to build
[01:15.400 --> 01:19.400]  things and see how they break and then build it again and see how else it breaks.
[01:19.400 --> 01:23.080]  And in the end, when it works, you don't have to worry about all the broken stuff polluting
[01:23.080 --> 01:24.840]  your environment.
[01:24.840 --> 01:28.360]  So using just the pieces that work every single time and just the pieces you're actually
[01:28.360 --> 01:33.120]  putting in every single time.
[01:33.120 --> 01:39.160]  Everything is built in a container, again, back to the, everything is self-enclosed when
[01:39.160 --> 01:41.680]  you're building it.
[01:41.680 --> 01:44.600]  And everything is built natively.
[01:44.600 --> 01:50.800]  We do, I mean, there is support for cross-building just about everything, but when we're actually
[01:50.800 --> 01:55.640]  installing programs, everything is actually built on native hardware.
[01:55.640 --> 01:59.440]  This picture is a little small and actually a little old.
[01:59.440 --> 02:02.640]  Let me slide this down a little bit.
[02:02.640 --> 02:09.560]  This one is from the actual bootstrap of, I don't know, it's little dated, it's changed
[02:09.560 --> 02:10.560]  a little bit.
[02:11.000 --> 02:21.480]  You start from an actual couple's statically compiled binaries and in this case, it's actually
[02:21.480 --> 02:27.600]  down, we download, yeah, we actually download in this picture the GCC 4.7 source code and
[02:27.600 --> 02:30.960]  compile it to the GCC bootstrap.
[02:30.960 --> 02:41.360]  So it's, so everything is a, so DAG is a directed acyclic graph.
[02:41.360 --> 02:47.160]  Everything, you can follow the inputs from one package to the next and see exactly how
[02:47.160 --> 02:49.280]  everything is built.
[02:49.280 --> 02:57.680]  So going back to the first talk, which I suggest everyone watches if I really enjoyed it.
[02:57.680 --> 03:05.560]  Our self-hosting comes from a couple of cross-compiled static binaries from another architecture
[03:05.560 --> 03:13.960]  running Geeks, which then we use to bootstrap everything up from the start on direction.
[03:13.960 --> 03:20.960]  So the same G-Lib C bootstrap here and GCC bootstrap here, then for whatever reason,
[03:20.960 --> 03:25.120]  we've actually flipped the graph around going the other way and now we're going from bottom
[03:25.120 --> 03:26.120]  to top.
[03:26.120 --> 03:30.880]  So G-Lib C bootstrap at the bottom and aiming up.
[03:30.880 --> 03:40.480]  So go and actually bootstrap everything, the, I actually haven't used Gen 2, but from what
[03:40.480 --> 03:47.480]  I understand the stage one and stage two starts, you start from just about nothing and it just
[03:47.480 --> 03:54.600]  builds itself also the way Linux from scratch does until you actually reach a fully functional
[03:54.600 --> 04:02.200]  and optimal as much as you want the optimizing fully functional and optimized or built with
[04:02.200 --> 04:11.720]  dash O2 binaries that you actually use to build everything else in the system.
[04:11.720 --> 04:19.160]  So just coming at it from the distribution side, risk five, okay, so what's it similar
[04:19.160 --> 04:21.480]  to?
[04:21.480 --> 04:27.680]  What sorts of problems did I run into with the actual porting?
[04:27.680 --> 04:40.840]  Yes, let's see, so the AR64 port, the boards at least initially were a little easier to
[04:40.840 --> 04:41.840]  get.
[04:41.840 --> 04:47.320]  ARM already had partners building boards and could get somewhat expensive ARM V8 boards
[04:47.320 --> 04:49.160]  in different places.
[04:49.160 --> 04:54.960]  Risk five boards that I've picked up actually mostly been through Kickstarter and one way
[04:54.960 --> 05:03.200]  that's one way that I guess I found it's radically different than ARM is that anyone
[05:03.200 --> 05:10.000]  can put together a chip and create it and sell it and there are just so many more options
[05:10.000 --> 05:16.360]  available for the actual chips and for the actual boards.
[05:17.360 --> 05:23.320]  On one hand, looking at online discussion, sometimes it seems like risk five will save
[05:23.320 --> 05:34.120]  the world and it's a unicorn farting out rainbows and it's just the end all be all.
[05:34.120 --> 05:38.240]  From the pure packaging side, it's another architecture that not a lot of people are
[05:38.240 --> 05:50.240]  using yet, but it really is somewhere in the middle as all things seem to be.
[05:50.240 --> 05:56.000]  My impression so far is that it's gotten much faster adoption than AR64.
[05:56.000 --> 06:00.720]  I bought my first AR64 board in 2017, I think.
[06:00.720 --> 06:06.480]  It was ARM V8 or the 8.0 specifically.
[06:06.480 --> 06:08.400]  Go ahead and buy an ARM 8 board today.
[06:08.400 --> 06:17.600]  It's still the 8.0 architecture other than Mac, the M1s which are almost 8.5.
[06:17.600 --> 06:24.920]  ARM just finalized the ARM V9 architecture and everyone's still selling ARM 8 boards.
[06:24.960 --> 06:36.560]  So it's really is exploding everywhere and as a project Geeks aims to make it available
[06:36.560 --> 06:47.680]  for as another architecture that Geeks runs on.
[06:47.680 --> 06:54.920]  So I guess other comparisons that I've run into, a lot of software doesn't have any
[06:54.920 --> 07:05.480]  sort of just-in-time compilation and a lot of it seems to be hand-coded assembly or added
[07:05.480 --> 07:12.480]  after the fact and a lot of times when building software end up with something just saying
[07:12.480 --> 07:18.600]  risk five isn't supported for just-in-time, your architecture is not supported past the
[07:18.600 --> 07:22.160]  no JIT flag.
[07:22.160 --> 07:33.000]  So PowerPC64, one hand in the past, I guess you still have the Apple G5s which were big
[07:33.000 --> 07:39.080]  Indian PowerPC64 and now we've switched to little Indian and you end up in a similar
[07:39.080 --> 07:49.400]  situation of there just aren't, no one's written that for yet, they come across a whole bunch
[07:49.400 --> 07:58.840]  of packages where you don't use autoconf and configure make install to install the packages
[07:58.840 --> 08:07.680]  and things just end up being too old, I apologize this one's a little small again, you go and
[08:07.680 --> 08:14.400]  run configure and have a timestamp, it was last updated in 2014, it was the last time
[08:14.400 --> 08:25.600]  they grabbed the let's say stock file, it's a regularly used file for plenty of packages
[08:25.600 --> 08:35.080]  and this just says yes I recognize that your names comes back as riskv64, I don't know
[08:35.080 --> 08:36.800]  what to do with that.
[08:36.800 --> 08:46.360]  So as part of the packaging of everything we do go through and have to update these packages.
[08:46.360 --> 08:55.680]  So in terms of I guess this is where I'm starting from with some of this, there's been a lot
[08:55.680 --> 09:03.080]  of work by the other distributions by many people to actually get risk five support into
[09:03.080 --> 09:09.040]  all of the tool chains and into major programming languages and really make it to the point
[09:09.040 --> 09:17.560]  where it's just go and create some bootstrap binaries and things just start building and
[09:17.560 --> 09:23.760]  so we've been very lucky that it's been such a big effort and everyone's so excited for
[09:23.760 --> 09:33.800]  it that built the bootstrap binaries and everything more or less just started working.
[09:33.800 --> 09:37.720]  So we really didn't have any, I mean other than you know we weren't using these versions
[09:37.720 --> 09:42.880]  these ones were a little too old but you know as things built up things pretty much just
[09:42.880 --> 09:47.040]  kept on going and working correctly.
[09:47.040 --> 09:55.360]  So one thing, so I mentioned that in Geeks everything is built containerized when it's
[09:55.360 --> 10:05.880]  installed it's not installed into FHS into the file hierarchy system, file system hierarchy.
[10:05.880 --> 10:10.440]  It's not installed in, we don't use the regular prefixes so here we don't have a user lib,
[10:10.440 --> 10:21.440]  we don't have a slash lib as part of a, I assume as part of a multi-lib change which
[10:21.440 --> 10:33.880]  happened years ago in most Linux distros, a lot of packages end up getting installed
[10:33.880 --> 10:39.840]  and we'll say user lib and then we'll say what architecture and what ABI it is and then
[10:39.840 --> 10:47.160]  we'll fall back to oh and otherwise it's just here in slash lib or slash user lib.
[10:47.160 --> 10:57.160]  All of our packages get installed into its own hashed prefix so for example this one
[10:57.160 --> 11:02.800]  is from GCC.
[11:02.800 --> 11:11.320]  So instead of looking in user lib, GCC I forget the actual path but anyway so we're not going
[11:11.320 --> 11:20.800]  to find libgcc.so used for linking everything pretty much actually had to comment out the
[11:20.800 --> 11:28.920]  start file prefix spec so that GCC would correctly link to itself after it had been built.
[11:28.920 --> 11:35.920]  So it was a odd situation that most things built and then occasionally things would just
[11:35.920 --> 11:42.600]  fail and say I can't find libgcc and say just built everything else where is it and then
[11:42.600 --> 11:49.000]  I add the library specifically and suddenly it could find it and eventually it turned
[11:49.000 --> 11:54.560]  out that as part of taking everything from its own special prefix, putting it together
[11:54.560 --> 12:02.360]  in the build environment and building, when I added libgcc specifically it got added into
[12:02.360 --> 12:07.640]  the library path and everything found it and without it it's supposed to be brought in
[12:07.640 --> 12:14.480]  by GCC itself, by the binary and then say oh yeah and here's libgcc if you need it so
[12:14.480 --> 12:20.040]  this was kind of a little gotcha that got me for a couple of months and I actually started
[12:20.040 --> 12:26.480]  adding ugly hacks around the Geeks code base to say and when you're building on risk five
[12:26.480 --> 12:35.920]  add in libgcc here and add it in over there and I had ended up with a paragraph size note
[12:35.920 --> 12:42.440]  going back to the after bootstrapping everything and getting to the final GCC used to build
[12:42.440 --> 12:47.920]  everything we actually had a special one just for risk five that said in addition to everything
[12:47.920 --> 12:55.560]  that's normally there we also need libgcc so I mean this was a looking back at it you know
[12:55.560 --> 13:01.200]  it feels silly adding everything but some of it also is I guess live and learn and you know get
[13:01.200 --> 13:09.320]  things to work. I found upstream and this one is you know it's a little dark maybe a little
[13:09.320 --> 13:17.680]  hard to read upstream is mostly been it's been happy to you know accept patches for risk five
[13:17.680 --> 13:23.640]  support some of the patches that that I've added to make things work you've just grabbed from upstream
[13:23.640 --> 13:29.880]  from newer versions or from pull requests or modified from other ones and said you know it
[13:29.880 --> 13:38.160]  worked here it'll work here too or this is about the same so as part of bootstrapping everything
[13:38.160 --> 13:45.440]  from source and we we support Rust as we aim to support pretty much every programming language
[13:45.440 --> 13:52.080]  and so current installation instructions for Rust are download Rust and use Rust up to manage
[13:52.080 --> 13:57.720]  Rust and in the distributions it's you know at some point it's in and then you use one version
[13:57.720 --> 14:04.880]  to build the next and then as far as actually putting Rust in the first time you know coming
[14:05.280 --> 14:11.400]  from source only our options really were to you know follow the OCaml path back from the very
[14:11.400 --> 14:18.480]  big very early days and build a thousand copies of it until we got to something more modern. Luckily
[14:18.480 --> 14:28.720]  for us there was an effort called M Rust C which aims to implement enough of the Rust C binary
[14:28.760 --> 14:40.840]  itself to rebuild Rust C and the rest in this case the rest of Rust 1.54 so and this was the
[14:40.840 --> 14:48.640]  you know the pull request that I had for hey and it also works on risk five we said oh everything
[14:48.640 --> 14:55.840]  just worked so we said yeah you know after you know split up the build instructions and built
[14:55.960 --> 15:05.640]  everything and everything just went and after 56 hours I had Rust 1.54 so it was on on my x86
[15:05.640 --> 15:12.880]  machine it took you know four or five hours maybe here it took 56 hours and it's you know the
[15:12.880 --> 15:19.080]  machines are they're getting faster and it was you know luckily I didn't you know there was no
[15:19.080 --> 15:24.480]  hand compiling there was no interacting with it in the middle it's and Geeks made it sit easy to
[15:24.520 --> 15:31.440]  just say here's the build instructions take the pieces and go so said here's the build instructions
[15:31.440 --> 15:37.760]  and I was always curious so I added time before everything and said 56 hours later here you go
[15:38.040 --> 15:49.320]  it just works so yeah so this is let me skip that one so I mean inside of Geeks
[15:49.320 --> 15:58.000]  you know was you know add the patch and then you know just tag supported systems saying you know
[15:58.000 --> 16:04.920]  yes it also works on risk five and you know here you're going back to the previous slides about
[16:05.400 --> 16:14.360]  you know end up with similarities with AR64 and with PowerPC that certain things just aren't
[16:14.360 --> 16:19.560]  you know aren't fully tested or aren't fully supported you know I ended up making the same
[16:19.560 --> 16:24.960]  mistake here and we've changed I changed it from you know it only works on these architectures to
[16:24.960 --> 16:32.520]  you know it's it works and it's it does it's you know it's not expected to be super efficient or fast
[16:32.840 --> 16:40.440]  but it gets the job done and I left the it may support I686 soon and I completely left out
[16:40.440 --> 16:47.800]  PowerPC no mention that you know it's coming or it's in progress or it probably works or even it just
[16:47.800 --> 16:55.240]  works on all 64 bit machines that we have it's completely forgotten so it's you know I fall
[16:55.240 --> 17:03.960]  into the same traps too sometimes with those as far as other language support for Go for most
[17:03.960 --> 17:10.560]  languages well for Go for most architectures we start with the Go 1.4 release from Google and
[17:10.560 --> 17:24.760]  then use that to build newer versions it's an issue with GCC Go with I forget the interaction it got
[17:24.760 --> 17:34.600]  fixed later so we're using GCC Go 10 to build Go 1.16 to build newer Go versions I've done it on
[17:34.600 --> 17:42.520]  X8664 which for this type of thing is where I normally end up doing most of the testing not to
[17:42.520 --> 17:50.520]  say cross-compiler but just to say use Go use GCC Go for X8664 to build Go 1.16 to build newer
[17:50.600 --> 17:56.040]  Go's and just say you know does this process work then say okay well let's you know do it on the
[17:56.600 --> 18:02.920]  on actual risk five and there was there's some issue with the test suite that I need to fix up
[18:04.760 --> 18:11.480]  the actual building process of building of the building before the testing takes I mean that part
[18:11.480 --> 18:19.720]  takes 12 to 20 hours it's I'm not sure why that part takes so long it's just one of those things
[18:21.240 --> 18:29.720]  I mean for node this one we fell into some we fell back into our bootstrapping trap of
[18:31.080 --> 18:35.960]  some sort of circular dependency between LLHTP and node itself in later versions
[18:36.600 --> 18:44.440]  so this one I'm actively working on I think node officially got support for risk five and 16 or 18
[18:44.440 --> 18:51.160]  partway through the cycle so I have to back port it to 14 which we currently have packaged and then
[18:51.720 --> 18:58.760]  again to 10 so that we can move forward with it Java
[19:01.320 --> 19:11.400]  Java's a problem I'm not sure we're actually ever going to get Java support it's one of those things
[19:11.400 --> 19:17.720]  it's going to take a really long time someone can correct me I believe Java support officially
[19:17.720 --> 19:28.280]  upstream it was added in Java 18 we build Java using the previous version going back version by
[19:28.280 --> 19:38.520]  version initially we had used until through GCC five there was a Java compiler as part of GCC
[19:38.520 --> 19:44.760]  after which it got removed and we used that for a while but it turned out that Java compiler
[19:44.760 --> 19:53.240]  also needed a Java compiler to compile itself so after some software archaeology luckily not
[19:53.240 --> 20:02.120]  by me someone else worked on this one managed to package early versions of of new class path from
[20:02.120 --> 20:11.240]  I'm going to say the year 2000 or so and use that to build uh iced tea the you know then free version
[20:11.240 --> 20:20.600]  of Java with Java 7 of Java 1.6 1.7 1.8 and use that to build all the open JDKs and so to backport
[20:20.600 --> 20:25.480]  risk five support all the way back through everything and we actually have a hard enough
[20:25.480 --> 20:31.320]  time keeping AR64 working on some of the earlier versions I'm I'm hesitant to touch that one
[20:33.000 --> 20:38.200]  Haskell is actually one of the ones where we've we've looked at it and it comes up
[20:38.760 --> 20:44.600]  every six to eight months like can can we do better on this one so I mean I've spent a fair
[20:44.600 --> 20:51.400]  amount of time looking at the Haskell download page binaries going back years and years they have
[20:51.400 --> 20:58.440]  0.29 listed as an option for downloading every version of Haskell needs an earlier every version
[20:58.440 --> 21:04.280]  of GHC needs an earlier version of GHC all the way back to the beginning there are alternate
[21:04.280 --> 21:12.120]  implementations back in the early days which can't actually get to build GHC itself so for
[21:13.080 --> 21:18.200]  for other architectures we actually do just say okay we'll take the you know we've chosen a point
[21:19.000 --> 21:25.560]  grab the official binary released by GHC and use that to build all future versions
[21:26.120 --> 21:35.000]  there's you know there's nothing for risk five currently from from upstream Haskell we
[21:35.960 --> 21:41.960]  we could add support currently our Haskell build system doesn't actually support crossbuilding it's
[21:43.080 --> 21:45.320]  more of it hasn't come up no one's done it yet
[21:48.120 --> 21:55.000]  so I mean we could cross build from x86 64 to risk five for that but then you're left with if
[21:55.000 --> 22:01.640]  you want to build anything using Haskell you need a second computer to build it and so looked
[22:01.640 --> 22:08.600]  into briefly can we cross build the other way from foreign to native and I mean other than an
[22:08.600 --> 22:12.920]  interesting thought experiment of now you have to build an entire second architecture to build
[22:12.920 --> 22:17.000]  the one you're actually using we actually we haven't made any progress on that one
[22:17.800 --> 22:21.800]  and seemed like it was more of an interesting thought experiment than something that we actually
[22:21.800 --> 22:28.440]  thought we would end up going forward on so I guess going back to you know actually talking
[22:28.440 --> 22:34.920]  about risk five itself one of the another thing that geeks has is like all links distributions
[22:34.920 --> 22:41.160]  we target a base architecture which is great for distributing binaries it's not great for actually
[22:42.040 --> 22:48.920]  running optimized binaries so you have a flag called dash dash tune obviously for
[22:49.000 --> 22:53.880]  for hello which just prints hello world it's not useful but for plenty of other programs it is
[22:54.840 --> 22:59.640]  so so when starting the risk five port I followed the
[23:01.480 --> 23:09.960]  it's the process that Debian and Fedor and I assume others took and I targeted the gc extension
[23:09.960 --> 23:17.240]  combination so as as time goes on and we get more extensions we'll be able to use the tune flag to
[23:17.240 --> 23:24.040]  say you know yes I'm you know I'm happy using the baseline or that's what I have or actually I
[23:24.040 --> 23:31.480]  have these other extensions you know rebuild some of the software so that I can actually make use
[23:31.480 --> 23:36.280]  of the better hardware of the more advanced hardware that I have with the extra extensions
[23:37.080 --> 23:46.600]  and in that way you know we've we've had good use of the tune flag in high performance computing
[23:46.600 --> 23:53.960]  in people with newer machines and be targeted by x86 64 v4 as a sub architecture
[23:55.160 --> 23:59.240]  you know we're we're still going through and and trying to find programs that are good for
[23:59.240 --> 24:04.440]  tagging saying you know yes this will actually run faster enough to be worth it but certain
[24:04.440 --> 24:12.360]  certainly plenty of math applications do very well with that and so I'm I'm you know everything's
[24:12.360 --> 24:21.720]  in place to add more sub architecture support for risk five as it comes you know we just have to
[24:21.720 --> 24:25.480]  you know actually have access to it and you know hopefully test it before just saying yeah yeah
[24:25.480 --> 24:34.440]  it'll it'll work fine so it'll probably just work fine but you know so it's it's it's there and you
[24:34.440 --> 24:41.720]  know it's you know it works fairly well for you know for everyone that's that's actually using it
[24:42.920 --> 24:54.040]  um see I was wondering you know if any any questions any comments seem to have an extended
[24:54.040 --> 25:00.920]  q and a period here at the end of my talk I'm happy to talk more about how geeks interacts with
[25:01.640 --> 25:07.800]  you know with you know other architectures with anything how you know other fun stories with
[25:08.360 --> 25:11.240]  courting software to work on risk five
[25:18.200 --> 25:18.440]  yes
[25:26.760 --> 25:31.800]  okay so the question was risk risk gcc is gaining the
[25:32.760 --> 25:38.760]  rust front end and have I looked into it for the bootstrapping part I haven't looked into it
[25:38.760 --> 25:47.160]  yet for the bootstrapping part my understanding is that it is that it you're similar to I'm
[25:47.160 --> 25:55.800]  rustsy it implements the it just aims to implement the I guess the rustsy binary more or less itself
[25:55.880 --> 26:02.920]  also so that so currently and so currently when we're building rust programs we'll say okay well
[26:02.920 --> 26:09.000]  upstream says cargo build this we run cargo build this and then cargo itself says you know rustsy
[26:09.880 --> 26:15.000]  library and this part is here and that part is there and that part is there and we can do the same
[26:15.000 --> 26:23.400]  thing um with you know either you know just with rustsy itself or with the rust front end from gcc
[26:23.480 --> 26:30.520]  it should also be possible which uh you know I'm not sure for uh bootstrapping rust if we would
[26:31.160 --> 26:36.360]  if it's something that we would slot in it's you know I guess at first thought I could see
[26:36.360 --> 26:43.560]  slotting it in uh instead of m rustsy itself and just saying we'll take the m rustsy infrastructure
[26:43.560 --> 26:49.880]  to go and say you know here's the pieces we need to build to rebuild rustsy from upstream but we're
[26:49.880 --> 26:55.800]  going to use gcc's rust to actually build everything faster and more efficiently which would also solve
[26:55.800 --> 27:03.320]  some of the other architecture problems and you know as rust gets into the linux kernel
[27:03.320 --> 27:07.240]  we're definitely planning on using the gcc rust front end for that
[27:07.400 --> 27:11.240]  uh yes
[27:19.640 --> 27:24.600]  okay so the question was has there been progress on building desktop environments and not just languages
[27:25.400 --> 27:26.120]  um
[27:29.800 --> 27:37.640]  let's see so I have built let's see current no I'm thinking through all the all the source code bits
[27:37.640 --> 27:42.840]  I personally run enlightenment on my laptop uh that one doesn't work yet but that's because
[27:42.840 --> 27:49.480]  we use an older version of uh lua jet as an input and I just need to actually tell it no for risk
[27:49.480 --> 27:55.000]  five use lua itself instead of lua jet or no really I'm not giving it to you and don't look
[27:55.000 --> 28:01.480]  for it and don't error if it's not there um other than that enlightenment should work which I know
[28:01.480 --> 28:12.680]  has many people using it as far as uh major desktops um it's the xfce just builds fine uh mate or mate
[28:12.680 --> 28:17.480]  just builds fine uh gnome I'm sorry I said that again
[28:21.080 --> 28:28.520]  yeah running it is another thing um I have not actually tested running it on the hardware itself
[28:28.520 --> 28:37.400]  yet um I've been uh I guess so far focused on the actual uh I guess just getting everything to build
[28:37.400 --> 28:47.720]  first uh as far as actually running geeks on the heart on I guess uh so geeks runs uh in two ways
[28:47.720 --> 28:53.880]  it runs as the entire operating system or on top of a foreign operating system so so far I've been
[28:53.880 --> 29:00.680]  running geeks on top of whatever uh operating whatever Linux happens to come from the vendor
[29:01.240 --> 29:11.000]  and I've been you know using that as the base um as part of actually testing the uh it should be
[29:11.000 --> 29:20.040]  not too hard to test it with qmu either from risk five or from an x86 64 machine running uh using
[29:20.040 --> 29:27.080]  the risk using the qmu emulation uh as far as actually building a actual image for one of the
[29:27.080 --> 29:38.360]  boards um I ran into some issues with uh different boards needing specific offsets for um it was
[29:42.120 --> 29:50.520]  just the g-parted version of fdesk helps create some partitions in a scriptable way and
[29:51.480 --> 29:58.840]  uh assigning magic partition codes and things like that so it's very doable in geeks uh this one
[29:58.840 --> 30:06.360]  was actually uh a problem problem I ran into I I actually burned through all of my spare sd cards
[30:07.080 --> 30:12.280]  so I was building everything on the risk five boards and then I needed a new one to go and say
[30:12.280 --> 30:17.960]  now actually you know create an installable image and install to that sd card and I I had
[30:17.960 --> 30:27.000]  actually run out of them uh but I've actually I've picked up more finally and um at the point
[30:27.000 --> 30:33.720]  now where I can go and say uh so the first plan was to go and say here's the here's an upstream
[30:33.720 --> 30:38.600]  image either from a vendor or from another uh Linux distribution I'm going to flash that
[30:38.600 --> 30:46.680]  onto the sd card that gets me all the partitions that I need then I say uh geeks system in it
[30:46.680 --> 30:53.160]  into the sd card that's already partitioned correctly and it'll install u-boot over uh over
[30:53.160 --> 31:00.520]  the u-boot and the os over the entire root partition and then you know it should either work or not
[31:00.520 --> 31:05.960]  and if it doesn't then we're into the you know why not but assuming everything just works uh
[31:06.840 --> 31:12.120]  everything should just come up in work and I'll be able to better test the graphical applications
[31:12.520 --> 31:18.520]  okay
[31:26.680 --> 31:34.520]  let's see so currently I am using what was it I'm using the sci-fi unmatched board
[31:35.240 --> 31:43.080]  uh when you know after a year long wait or so it was a long lead time with mouser it
[31:43.080 --> 31:49.480]  it did finally arrive and uh shocked the local computer guy when I showed up and said I need
[31:49.480 --> 31:54.600]  a case and a cpu and I have this he's like oh do you what else do you need it's like graphics card
[31:54.600 --> 31:59.960]  peripherals like nope have risk five board and he's like you're you're you're you're killing me again
[32:00.680 --> 32:06.040]  so he's the one I've gone to in the past when it's been okay I need a graphics card and it
[32:06.040 --> 32:11.800]  has to be 10 years old and work with you know Linux library kernel and it's you know sometimes it
[32:11.800 --> 32:18.200]  just becomes a you know work with the pieces that I have so that's that's the main machine that I've
[32:18.200 --> 32:27.720]  been doing a lot of the work on um the so I've also have the uh first vision five board uh that's
[32:27.720 --> 32:34.120]  been helping a lot with a lot of the building and I recently got the vision five two which so far
[32:34.120 --> 32:42.360]  seems to be at least as powerful as the high five unmatched uh not the one with the eight gigs of
[32:42.360 --> 32:50.520]  ram uh compared to the 16 from the high five unmatched and the cpu uh up to 1.5 gigahertz instead
[32:50.520 --> 33:00.200]  of 1.2 ish and you know truly in the we had some geeks meetup days before FOSDM actually hooked up
[33:00.200 --> 33:05.960]  to the projector and just started building you know building from nothing up to uh hello and you
[33:05.960 --> 33:11.080]  know things were building and it was people say oh what are we building now you know where are we up
[33:11.080 --> 33:19.560]  to now so it was you know GCC itself takes six to eight hours to build uh from from the uh bare
[33:19.560 --> 33:29.160]  bootstrap binaries uh from this one here from the bare bootstrap binaries up to hello which you know
[33:29.160 --> 33:36.040]  is the first quick to build package uh after building everything you you know GCC and Ben
[33:36.040 --> 33:43.560]  utils and everything you actually build everything with on risk five uh it was uh somewhere between
[33:43.560 --> 33:52.760]  16 and 20 hours of building uh on on x86 64 the entire process I think was four to six hours
[33:53.480 --> 34:00.280]  maybe a little faster um it's taken a little longer now that now that the bootstrap bit has
[34:00.280 --> 34:03.320]  has been extended um it's
[34:07.080 --> 34:13.480]  yeah the one of the other architectures that I worked on for fun was 32 bit power pc
[34:14.280 --> 34:21.480]  and so that one that one was really more of a because I had it and not because anyone uses it
[34:22.200 --> 34:27.320]  and so with that one uh GCC 10 actually takes more than 24 hours to build
[34:28.120 --> 34:33.880]  so it's so you know it's it's actually useful hardware unlike the 32 bit power pc
[34:35.240 --> 34:40.200]  may I ask what is the answer is there is some cross compilation for
[34:40.200 --> 34:46.920]  duix uh I'm familiar with the next so I would expect that the initial would be to use cross
[34:46.920 --> 34:53.320]  compilation and not the native but duix doesn't have a cross compilation only it's just the
[34:53.400 --> 34:58.520]  direction to write the native because of course that would be way faster yeah it would be way
[34:58.520 --> 35:05.000]  faster um so the question was uh so you are familiar with nix which does have cross compilation
[35:05.000 --> 35:09.560]  and you're wondering if geeks also had cross compilation which would be much faster to compile
[35:09.560 --> 35:17.320]  than native uh so geeks does have cross compilation uh you can cross compile binaries and then um
[35:18.280 --> 35:24.040]  use the basically geeks send command to send it to the board and then run it there and everything
[35:24.040 --> 35:30.120]  just works uh as far as actually building from it though uh everything gets built from the
[35:30.120 --> 35:39.240]  native binaries so the initial bootstrap binaries uh cross compiled and uh they were then used to
[35:39.240 --> 35:41.880]  as the native binaries to go and build everything else
[35:42.120 --> 35:54.120]  uh but you know I've used cross compiling uh one the where was it uh for for node that one
[35:54.120 --> 36:01.720]  back porting basically you know two rounds uh the plan for back porting node was to back port it
[36:01.720 --> 36:09.560]  to node 14 and then cross compile from x86 to risk five and say does node 14 work with this patch
[36:09.560 --> 36:15.960]  that I've written and then once it does then to go and back port it the rest of the way to node 10
[36:15.960 --> 36:22.360]  and then to go and you know haven't decided there whether whether the actual building would be faster
[36:22.360 --> 36:35.000]  to uh cross build node 10 as a test or whether to start from native as the test so um so geeks does
[36:35.000 --> 36:41.720]  do uh yeah we do have cross compilation and we do use it for you know for creating images
[36:41.720 --> 36:48.520]  or creating binaries for for other architectures but as far as actually uh building from it or
[36:48.520 --> 36:54.680]  using it as a as a stepping stone it's really only in the very initial stage when the architecture is
[36:54.680 --> 37:15.720]  first added okay so I I think that's it so thank you everyone