Gentoo Linux, or Why in the World You Should Compile Everything [Video]

All right. So, why don't we get started? Um, so you guys are presumably here to learn about Gen 2 and why you should use a source based Linux distribution instead of uh a binary one. Um, so we're going to basically introduce you to Jensy today. Um, why you should use it, how it works, some of where it's going from the technical side. I uh can pull up that graph again for anybody who walked in later on the social side of things as far as community management and you know keeping things healthy there and uh then we can do some demo stuff if you want.

So you can actually see how it works instead of look at bullet points of how it works. So uh somebody else made this picture a few years back and I lost about 50 pounds since then. So if you can't recognize me that's all right. Um in Jenu I wear a lot of hats. I've done a lot of things over the years. I've been working on Gen 2 Linux for about uh 10 years now and in that time I you know kind of get bored of one role and move on to another one. Um just like in real life you kind of get sick of doing one thing and you're like oh I'll learn Rails and I'll learn Node because they're interesting and you know writing the same Java code day after day gets a little boring.

Um so the same thing in Gen 2. I started out as a developer maintaining packages. Um, I still do some of that, but I also do a lot of other things. Um, I got very interested in the community side of things and and maintaining a healthy community, a healthy project after we got a few very abusive people who uh we failed to deal with for a long time and then we did deal with them. Um, and people were like, "Oh, why didn't we do that years ago? This is so much better now." um even though they were they were technically outstanding people, turns out that if you get rid of them um the other 200 people can make up for those three, you know, it's hard to imagine.

Um so over the time I've been a developer, I've uh you know, led the team that maintains a switch, which is the graphical subsystem of Linux. I've been uh right now I'm on the council which is a group of seven people that uh basically runs Gen 2 and I've spent about four years on the council now. Um it's a great way to spend lots of time in meetings just like any committee and and get very little done. Um but we're working on that. Um I started using Gen 2 and this may be interesting to you guys who are thinking about Gen 2.

Um, I started using it because I initially was using Red Hat back in the, let's see, late 90s, early 2000s. Um, I got pissed at RPMs. They were just so annoying and frustrating to deal with. And then I ended up, uh, pumping and using FreeBSD for a while. Um, FreeBSD has a system called ports where they basically write a make file that builds lots of different packages. And that was kind of nice, but um it the lack of cohesiveness got kind of annoying where everything had its own little variables you had set to build that package that didn't apply to the next one and the next one.

And then on top of that, um on the BSD side of things, they they do have some Linux compatibility, but it just it's not perfect. And so there were all these apps that you couldn't run or that you had to somehow patch to make them work properly. Um and so I decided, you know what I really want? I want free BSD, but Linux. Um, and that's when I discovered Gen 2, which has a quartz-like system called portage. Um, compiles everything from scratch. And so what that gives you is it, yes, it does give you like an extra 3 or 5% of performance.

Um, but it also gives you a lot of flexibility to have your system exactly the way you want to have it. Um, you only install the packages you want and not not not only that, you can only get the features you want in those packages. um using a a system called use flag that I'll talk about a little bit later. Um it's called Gensy because Gen Cube is of all penguins, it is the one that swims the fastest. Um it's based on Linux. We can also run it on top of FreeBSD.

We can run it on top of uh OSX using a system called Prefix, which I'm not a good person to talk about, but I think Jeremy could probably talk about more. Um, so if you have questions, don't direct them to me, direct them to him. And you can run on top of I think Windows even and like Sigin. Um, and the nice thing is it gives you the flexibility to, you know, have a real package management system installing open source software on basically any operating system you want to.

Um, OSX has things like and Mac ports. Um, but in my opinion, Gen 2 is a better system for package management than any of those. Um it's we started back in about 99 by with a guy named uh Daniel Robbins. He's a very interesting person and uh if you ever run into him talk to him about it cuz uh he's technically uh very creative and socially uh very controlling which makes for an interesting combination when you know people like to dictate everything that happens but then they don't do it themselves.

Um, and it works great uh in a company but not so well in a volunteer environment. Um, in terms of features, uh, let's see, I've got a list of bullet points here, but I'm not going to show them. But, uh, basically it's very easy to maintain a system. We've got, uh, this concept of package sets. So, the core software on your system is called system. Everything else is called world. Um, and you can say update the system, update the world. You can update individual packages of your choice.

Um, you can say find all the packages with security holes and update only those. Um, you can say I upgraded my kernel. I have modules built against it. Upgrade only those. Um, one of the really cool things about Gen 2 is that uh you can install live packages like live git, live CBS stuff by writing an evolved. Right now it's it's called a 99999 version just because that supersedes everything that's smaller than that and most packages haven't yet gotten into the fivedigit release numbers.

Um there's a lot you know in the past like the the people who developed KDE ran Gen 2 because it was so convenient for them to maintain the live software especially when you've got I mean you can do it run stuff from git when you've got one or two but once you start getting into the you know 20 or 30 or 50 packages where you want to run all of them um live git versions it gets pretty frustrating to keep updating and building those yourself. I mean, that's where Gen 2 comes in pretty handy is you write basically a shell script called an ebuild once um and then you say emerge fu and foo updates and it's there and it's all in working for you bullets and move on.

This is kind of the default Gen 2 presentation that I grabbed off the PR project. So, um, it's kind of markety. I apologize for that. Uh, let's see what we got. Okay, so I talked about some of the advantages of compiling from source. Um, one of the cool things it can do is it can slot different versions of the same package on your system at the same time. Um so you could for example run the live version of KDE alongside uh KDE4 alongside KDE3 um assuming that the packages are written to support that.

Um and so GTK1 for example and GTK 2 are written to support this concept of slotting. So you could be running you know different graphical apps um compiled against both of those at the same time. And this is great from a developer point of view because it's very easy to test against multiple different versions of libraries at the same time. Um, it's very easy to compile software with like 10 different versions of GCC to see if it builds on all of them because you can have them all installed at the same time and just say, you know, GCC 3.4, GCC 2.95 if you want to go back that far.

Um, GCC, you know, 4.1, 4.2, 4.3. I have them all in my system right now and I can test compilations with all of them simultaneously. Um, one of the other really cool features is even though it is a sourcebased distro, it has the capacity to use binary packages. Um, and this is where um, was it your question about production? Yeah. So where where the you know how do you run J2 in a production environment is you don't compile stuff on a production server as it's running.

Um, that would be silly. What you do is you have a build server and that compiles them and distributes the binaries. Um, and Portage, which is the package manager nowadays, has support for going out and checking for a binary package server and grabbing all the updates from there. So, it is source based, but you can still get a lot of the benefits of a binary distribution, like not using up 100% of your CPU to build stuff while you're trying to serve out, you know, 10,000 hits a second on your website.

Um, it can also actually install things like RPMs and and dev packages because we have uh some code written that'll do the conversion for you. So, you can convert them and then um you can do the installation. There's a little bit of effort required but it it'll work if you want to work. What does it convert to? Um to a tarball which we then install like it's a tarball. So, it just grabs the files out sticks them in tarball. Um, and then you can basically throw them onto your file system, but the package manager still remembers where the files are.

And that's a benefit is it doesn't just throw them out there. You can also uninstall them. You can upgrade them and so on. Um, so let's see how many bullet points. Looks like a good number to start talking about. Um, so like I said, you can optimize the way you want. Um, you can change your compilation flags or C flags. You can also change your linker flags. um if you care about that. In some cases, you do and most cases you don't. And let's see, you can protect the live system.

This is really the value of of packaging the apps you're working on, running them through package management is that you can make sure they don't overwrite stuff. You can upgrade them very easily. You can make sure there aren't files lying around from version, you know, 0.3 of something. Um because the package manager is there to pull them out for you. Um you can also speed up the compilation through various methods. Um some of the companies um running big server forms on genet 2 use this thing called discc which is a distributed c compiler and it basically throws the code out takes each file and throws it out to a different server um and parallelizes the compilation not just across multiple CPUs but multiple servers at the same time.

Um, so you can do things like build a kernel parallelized 64 ways which as you can imagine speed things up quite a bit. Uh, let's see what else we got. Some of this there was one somewhere that I may have wanted to make sure I mention. Okay, so it's coming up here. So the really cool one from a developer point of view is is blast bullet point debugging support. Um it's very easy to build packages with full support for debugging all of the uh you know little flags in there.

So you can run GDB across you can install the source code um in such a way that the package manager understands where everything is. Um and not just that but the the binary code on the system knows where the source is. So you can step through the source code instead of just stepping through binary functions. Um, and it's a lot of times if you're trying to debug stuff, um, it gets really annoying when you're building stuff by hand. Um, so having this kind of support in the package manager is a pretty huge feature.

Interesting. We'll talk about in the demo. Um, embedded system support. This is actually a feature that I really enjoy. Um, I've built out routers that run Gen 2. Um, I installed Gen 2 onto a floppy disc a few years back. So you can actually fit it into, you know, 1.8 megabytes if you want to. Um, one other case where this is pretty cool is is terminal servers. Genty supports them reasonably well is with this thing called the LTSD project. So you can have a system installed on a server and then um all these dumb terminals that just read the files across the network.

And the thing with Gentu is um a lot of times if you're building out an embedded system, you basically throw the files on there and leave them and it's hard to manage them and upgrade them over time. But with Genty, you can have the package database on there too. Um so you could have, you know, a kernel uh busy box, which is a very small set of core utilities, and a package database that understands that, hey, I've got BYOX 1.4 on there. um which makes it possible to upgrade the image without starting from scratch every time.

And this is something that really isn't out there um for other methods to have an embedded system like builder or whatever. And we already talked a little bit about package sets like system and world and kernel modules you want to rebuild. Um, one of the things coming up in the the version of Portage that's kind of sort of released but not really and has been that way for about five years now is uh generic package sets. You can define a set of packages and then very easily manage them all simultaneously.

So uh I don't know imagine you're you're working on some web app you could define the entire stack all the way down as a as a set and very easily upgrade them uninstall them reinstall them. um and do that kind of thing. So that can be pretty powerful. Question for did I see something about Raspberry Pi? You guys supporting Raspberry Pi? Uh I'm sure we do. I mean our team get free devices on anything. Yeah. I mean I would say with maybe the exception of Debian, Jens runs on more architectures and more CPUs than anything else out there.

Um, and because it's designed to make it very easy to modify, um, it often runs first on the new stuff that comes out. And, you know, if we're at a conference and let's say IBM's got some wacko mainframe there, we can walk up to it with the Gen 2 CE and it just boots like nobody else does that. Um, because we've got all this new stuff available and, uh, you know, our live CDs are actually pretty good. What we got here? So, the software repository is possibly the largest one out there.

I'm not sure. Right now, we've got something like 12,000 packages available. And that's not if if you think about something like Red Hat or Fedora or whatever. Um, they might have 12,000 packages, but they're not really 12,000 packages. It's one package split up six different ways. So, you've got, you know, the libraries in one package, the headers in another package, the binaries in a third package. Um, when we're talking Jens, we're source based and so every package is actually an entire package.

Um, so when we say 12,000, if you translate that into pora terms, that might actually be 50 or 60,000 because we don't split this stuff up. And basically, if you want some software, it's very likely to already be in a package. Um, but even if it's not, the packages are basically just shell scripts. So it's it's pretty easy to write one. So is there support for I mean binary binary packages within software repository two areas graphics drivers wireless.

Yeah absolutely I mean genu is is a very pragmatic philosophy as a distribution. We want to not get in your way but enable you to do the things you actually want to do. Um so yes we package the Nvidia drivers. We package the ATI drivers. Um if the license legally allows us to package it we will. I mean, this is actually a a great question because um we have features in our packages that allow us to say we can't mirror or redistribute this, but if you download it from the original source, we'll still install and manage it for you.

I mean, in fact, we can we can go so far as to print a message that says we're not even allowed to download this automatically, but if you log into the website, go download it, and stick it in this file in this folder, um we'll still manage it for you. Um, so you know, if you're stuck using SDKs or something that you have to download and log into to get at, um, you can still manage those using a package manager, which is pretty cool. Um, we've got leading edge packages more or less.

Um, nowadays a lot of them are in in a different repository called an overlay. Um, so we've got the main package repository and then we've got these things that kind of lay on top of them or lay over them. um thus the name overlay and there's gosh probably a hundred at this point. There's tons of them. Um and so a lot of the developers work in overlays um and keep a lot of bleeding edge software there and you can very easily get at it um while with the caveat that it's basically if if you destroy your system, it's your own fault.

Um but that said, you know, if you've got a live git package there that you want to have, it's there. Um and so you're not limited to the 12,000 that are in the repository. We've also got, you know, newer versions of them and other software out there. Um, anybody can can create and publish an overlay, which is just a package repository. Um, so you can have, you know, internal ones in your company, for example, that aren't published anywhere else, but are still very easy to to manage using a tool called layman, which is it's like layman- alay name, and there it is on your system, ready to go.

So I I don't want to go through all this stuff, but uh the packages are called ebuilds. They're basically simple shell scripts with a set of functions we defined to make things a little bit easier. um they've got variables and batch code and uh it's it's set up in a sort of object-oriented way even though it is shellcript so that you're able to um inherit things from a library called an e-class so you don't have to basically rewrite the same installation process over and over and over.

Um all the default stuff is just handled magically for you and then when you have to break away from the default you can you know do one little extra thing and then say call the default code for the rest of it. Um, so even if you have to do something a little bit weird, you still don't have to write like 100 lines of stuff to uh make it happen. Um, so use flags are how you build specific features or leave out specific features. Um, and it's I think I've got an example on here.

Yeah. So it's just a bash variable and you say, you know, build this with KD support and without support, you know, minus Gnome and then with KD. uh you can set those per package if you want to. So you could have some packages built supporting some feature, others without the same feature or you can define it globally which is the reason I stopped using FreeBSD in the first place. Um you can just say I want my whole system to just support Gnome. I want it to support uh network manager, pulse audio, whatever.

Now, one thing that's that's a little bit weird about Jenu and unique to it is uh we actually wrote our our own custom init system. Um nowadays it's called Open RC which was a rewrite so that it would faster. Um the reason we did this back in the day is um the CIS 5 and it system actually didn't support dependencies. You had to name things with certain letters and numbers to make them start in the right order. Uh so we wrote one that said that basically said you know this service requires AB and C um and then the dependencies would automatically get sorted out things would start in the right order.

Um so we were there first and now we're we're still there last. Everybody else is kind of moving on to things like systemd. Um we're we're kind of sort of working on it but uh you know it it works pretty well the way thing things are and so why why break it? See these stupid. Okay. So, our documentation is awesome. This is one of the big reasons why people start using Gen 2 is we have I mean seriously top-notch stuff. We've our handbook has won awards for being so good.

Um and you know like the number one or two source of documentation about Linux stuff anywhere. A lot of times if you Google a problem and if Linux related um the Gen 2 doc will pop up telling you how to fix it or there'll be you know somebody who posted on our forums that says hey I encountered this weird error message. Um, since I run Gen 2 and I'm seeing inside the black box of Linux, I've actually fixed it myself and here's how. Um, so even if you're running Fedora or Ubuntu or whatever, a lot of times you run into a problem and some Gen two person has solved it.

Um, of course you have to have the docs because on Gen 2, you are doing everything yourself. There's an installer. You download a tarball, you unpack it, you format the file system, all that stuff you do by hand. And that after after a point it doesn't really matter even I can probably install Jensy by hand faster than I could install the door by clicking next because you know there's only so many ways to install Linux system you know format the file system you got your set up you unpack it and then you're done.

Um on the community side of things like I was saying it's it's very easy to create packages and submit them. We've even got overlay repositories that are specifically designed to uh enable users to very easily contribute stuff and get it distributed to other users. Um, Gen 2 is very IRCcentric. Um, if you haven't heard of IRC, it's basically like chat rooms before chat rooms had a name. You know, kind of a standard protocol for it. You can use whatever client you want to.

Turns out that uh Zenu is a very technical place. So a lot of people are actually using IRC clients that run in terminals rather than graphical ones because we like terminals and we use them all the time. That's how uh you maintain a ventry system. You're running commands in a terminal. Let's see do this stuff so we can actually do some demo. So, um, basically if if you care about having control over your system, if you have a need to have control over your system, um, if it would be helpful to you to be able to control your system, you're a developer, you're building embedded stuff, you uh want to learn how Linux works, um, that's when you should be running Gen 2.

Um, so now I want to get into some some new things. Um, so the E API is an API for our euilds. um we define a package format. We're able to increment that format so we can actually add features over time. There are very few distributions out there that are still adding features to their packaging. They basically said it's good enough. We're going to stop here. Um like Red Hat packages are still written in basically C shell which is the torrent. Um, and so we're we're still working on our packages, still making them better and better and improving the experience, not just for end users, but also for people who are writing the package because we try and make those two the same group.

So it's very easy to maintain your own system, do whatever you want with it. So roughly every year, year and a half for the past uh 5 years, we come out with a new version of our package format. Um, and we're working on the fifth one right now. And these add features like new convenience functions that uh manage different steps of the installation process for you so that when you do have to customize things there's less code you have to write to do it.

Um one one example is we used to uh unpack and patch code in the same set of functions and we split those up so that if you need to add a patch you just modify the patch function and the unpacking still happens magically for you. You don't have to care about it. Another example is it turns out that the upstream coders um myself included do a lot of dumb stuff in software and so we have to have a lot of backend code to enable us to fix that and do things neatly and cleanly.

Um so we can do things like download a tarball and rename it automatically. Um, you know, we can do lots of wacky things with the versions because people write the weirdest versions you've ever thought of and we have to deal with all of that because we've got it packaged. And people write like 0.1 pre4_rc6, you know, and you have to be able to do something with that and understand whether it's newer or older than, you know, some other weird wacko version.

Um, so I'm just going to go through a couple of these just so you can see some examples of the directions we're going and like why would you want to change how you're um handling packages. Um doing things like more cleanly specifying dependencies so that it's easier to for example create an embedded system without installing all of the headers on it. So you could compile against um your lab system and then install to some other route and keep it as minimal as you possibly could. um doing a lot of things automatically that still have to be specified by hand when there's no reason they should be.

Uh let's see this one that's second from the bottom is actually one of the really cool ones that you can you can build into the package itself a way to uh create and bundle the source code and upload it to some mirror. And so this is useful not just for just for people but also even for for upstream coders so that you could use a Jensen package to uh create a release of your software basically and push it out to a mirror. Um and then a lot of things that are just kind of specified in a silly way right now.

Uh let's see through this stuff yet. Okay. So let's do a demo. Okay. So, make this a little bit bigger. So, this is what it looks like when you say uh emerge- new world, which is basically upgrade everything on my system. Can you guys read it in the back or do I need to make it bigger? All right. So when you're when you're running emerge um which is the command line front end to our package manager um this is what the output looks like. You do it in the terminal you do it with text.

There are some graphical managers out there um but they don't have the flexibility and they're missing features. So basically the administrator of the system should always be doing it in a terminal. Um but despite that we do everything we can to still make the output pretty and easy to use. Um that's why we see we use so many you know colors and bold and all that stuff. Um there's no reason being in a terminal has to be ugly or painful. Um so for example uh let's see at the very top there it's telling you how it's installing something.

So at the at the left end it says ebuild. So I'm going to be building this from source. It could also say binary which if you're using a binary package that's how it would be. Um and then it says U for upgrade. It's got the package the version in brackets after that it's got the old version it's upgrading from. And then in in some cases after that it it shows this use variable and this is all the features that are built in or excluded from a given package.

Um it's it's actually so for example with uh the second one up there the tip image library. Um it built in C++ support which is probably some kind of API. Uh it built in the under uh the ability to understand JPEG images as well uh using zip for compression. And then it leaves out a couple of other um let's see another compression algorithm and another image format because if you don't use it, why should you have that code on your system? Um and this isn't just space.

This isn't just about OCD. It's actually about security, too. Um why should that code be there in a compiled binary if you're not going to use it? Um every additional line of code is an additional opportunity to get exploited. Which goes back to the production question again. Having a minimal system is with people the concept of least lease privilege. You know, give people the rights they have to do what they need and no more. Um give people the code they have to run on their system and no more.

Um everything else uh is just another opportunity for pain. Um yes, you've got use flags. You can actually build in different languages, exclude different languages. Um turns out languages actually take up a whole lot of space on a system. And you can see in red is is enabled stuff. Blue is disabled stuff. And then if something changed from the last version, it it calls that out in yellow. And it's got a little percent sign for people on black and white systems or people who are color blind because we we try very hard to be accessible and useful.

And it's a lot easier for us because things are done on a command line. So you don't have to understand how to deal with graphical app and how to turn that into, you know, an audio format that people who are blind can use. um it's it's already there and people can use their standard screen readers. Um so that's what it looks like if if you're about to do an upgrade. Um everything just shows up. It handles all the dependencies just like any modern package manager should.

Um one of the cool things it can do is is we can integrate with other package management systems as well. So a lot of people use gems to install Ruby stuff or uh cpan or pearl stuff. um we can actually turn those into a Genji package automatically and then install them um so that everything is managed through the same package manager and you don't have weird conflicting things with the different versions floating around your system. Um it's also nice for security stuff because um frankly a lot of these languages writing their own package managers don't really care about a lot of things that uh distributions have spent the last 20 years thinking about and working on. that, you know, the best strategy is ignore the past so you can invent the future, right?

And so it's great to uh be able to take advantage of all that experience no matter what language you're using, no matter what package format you're using to manage the stuff in that language. Uh let's see. So that's what it looks like when you're upgrading stuff. Let me see if I can uh try and open a file without actually being able to read what I'm typing. Yeah, there we go. Okay, so if we open a package, this is what it looks like. Um you see a little header at the top, you see a EAPI variable.

Um, this inherit thing is is the object-oriented stuff I was talking about where we've got this concept of inheriting code from other places then reusing it or changing it somehow. Yeah. Um, in in a way there's I mean there's a limit to what you can do in shell scripts, but we do the best we can. Uh, you've got, you know, a description for the package. You've got which architectures does it work on. Uh, let's see. This I use the available features for that package and that's the then displays the user as here are the ones you can turn on or turn off.

So you only show the ones that actually exist. Uh we've got you know tons of dependencies. This is the X server. So there's about 300 of them. Um our dependent is a runtime dependency. Dependent is a build dependency. We separate those out so that you can build the system and then remove all the buildtime only stuff. Or another case would be if you're, you know, building out an embedded environment, you can install it to a different section of your file system, but only have to build stuff on on the actual server that's doing the building and not sitting there on the router.

Like why why would you want GCC on a router? And so you can specify dependencies. Uh you put them in blocks saying like if I'm building this feature then I need these libraries otherwise I don't. And let's see more dependencies. snatch these. Okay, so now we're getting to the interesting stuff. Um, so there's a series of functions and these functions basically follow the path through a build process. Um, you've got uh package pretend which shows up when you're basically saying, I'm thinking about upgrading this.

Uh, show me what I need to know right now. Am I is it a what versions are changing? Did my use flags change? Um, the output that I just showed you. And so you've got code that can run when that happens and show you something. After that, you've got this package setup function um that runs before anything else during the build process. So if there's something that has to be the case uh beforehand, you can do that here. Um for example, here I'm checking whether various combinations of use flags uh are possible.

I'm setting up mapping of use flags to configure flags because it turns out that the whole world doesn't define the same configure options for the same feature and so we have to do a lot of mapping there so that you can have global settings. Yeah. What time is it? Okay. Thanks. All right. So, we'll uh wrap things up in a minute here and if you have any other questions we can talk about this. Um, and it turns out in this case, uh, so I go straight from package setup to installing because the build process is defined somewhere else and I just inherited that.

It automatically understands how to how to build this software. Um, and I for the installation I I call out to some inherited code so I don't have to define it again. Um, this this thing comes from one of those E-Class libraries. Um I end up installing about three files manually because uh every package is a little bit different and you're able to do this by you know using the inherited code for most of it but and then just um deviating from that where you have to.

And then we've got other functions that run when you're uninstalling so that if if your package leaves weird crusty stuff on the system you can handle that and and leave the system exactly the way it started out. Um and that's about that. So that's what a package looks like and a fairly complex one at that. If you wanted to look at a simpler one, let's see if I can hopefully this is a simple one. It's a very simple piece of code. Um so a simpler package basically has variables up top.

Um does a couple of things and that's about it and you're done. Um, a properly written community package basically requires no code at all. It will download, unpack, run configure, run make, install it, and you're done. And all you do is find the variables and not need any code for it. The code is just for uh basically upstreams that do weird things. Um, so I hope that was kind of useful to you. If not, I apologize. You should have walked out earlier.

If you have any questions, I'm happy to answer. I'm not a Linux ninja. Okay. But this looks really interesting. I actually like to build something kind of lean it out. So I don't have it. If I'm in the role of not knowing everything, how do I know if I delete something that I'm not going to how do I know that there's dependency somewhere down? Um, we we have support for that in package manager where uh there's there's basically a a flag that says clean out the dependencies I don't need anymore.

Um, and so you don't have to specify them individually. It just goes and finds all of things that are not depended upon by any other software and uh the democracies. We do have some level of protection for I guess extreme cases of that like we our package manager is written in Python. So we try and make it pretty hard to uninstall Python. you try and make it pretty hard to, you know, uninstall the C library where, you know, it flashes up huge red bold letters and blinks at you for like 10 seconds and says like, "You're are you sure you want to do this?" Because you might be in trouble afterwards.

Um, it'll still let you do it because there are actually use cases for doing some of these things sometimes like an embedded system. Um, not not the C library in most cases. Um, but if you do build everything statically, you might want to install it. Um but certainly you can imagine a case where you wouldn't want Python on a system because you're doing a packet manager on a different system and then installing into this little router um that's maybe NFS mounted or something else.

Yeah. GCC. Um it's possible to use other compilers. there are some assumptions that they will accept or ignore um GCC compiler flags and so if they instead choke on them and die um you might have some issues but I've built a lot of stuff with um for example the Intel C compiler all you do is define a variable called CC which for the C compiler or CXX for the C++ compiler and then it'll use that in packages Right. Um yeah, I mean if the package supports it, then it'll build that way.

If and presumably if you're building for like an Arduino or something, um you're using packages that are designed to work the way Upstream want them to work. And that's kind of a philosophy of Jensen is, you know, software the way Upstream intended instead of piling all of our weird branding modifications on top of it. Yeah. Uh I've written a bunch of projects in Python and I maintain them on Pi essentially or push them out to Pi. Uh what exactly is there a dock somewhere uh in terms of putting or adding those into uh the standard packages?

So for Pi, that's one of the examples where we can automatically create a package in on the fly. Um there's a piece of software called let's see, they're all called G- whatever um for basically gentifying something. So uh let me see if it's sure it's on me somewhere. But uh anyway, there this package called G PII. There it is. Okay. Um and I can say g pi some package up on pi and it'll go look at it, fetch the latest version, um turn it into an ebuild and install it on your system if you want to.

And so there's there's no reason you have to actually write the evil in the first place unless your package is doing weird non-standard stuff. Um like you know it doesn't have a properly written uh setup. py or something because all it all the pack is going to do is like setup. You know build install standard. How many of the Um, good question. Jeremy, you know anything about that? Question. How maintained is the previous col? Um, the the part for that goes up and down the time depending on who's active in the project.

Um, I'm not really sure. Yeah. So, uh, you'd have to check yourself. Um, we have, if you basically Google it, it's pretty easy to find on our website. We have a page for like weird architectures and OS and that kind of stuff. And uh, if you're an IRC person, we also have IRC channels, lots of them. Uh, in fact, I didn't mention this, but I think Jenzu is, if not the biggest, certainly among the top five IRC channels on the Freo network, which is basically where most of the open source stuff happens.

I think there's like 900 users in there. you know something about that. Cool. Um yeah, if you guys uh have any more questions, catch me at any point. I'll be around all day. Thanks for your time. Appreciate it. Hey, hey, hey.

This transcript was generated automatically from the video's captions and may contain errors.