lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

732
hpr_transcripts/hpr4321.txt Normal file
View File

@@ -0,0 +1,732 @@
Episode: 4321
Title: HPR4321: Crux Linux
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4321/hpr4321.mp3
Transcribed: 2025-10-25 22:59:42
---
This is Hacker Public Radio episode 4321 from Monday the 24th of February 2025.
Today's show is entitled Crocs Linux.
It is hosted by Clot 2 and is about 53 minutes long.
It carries a clean flag.
The summary is Tri-Crocs Linux.
Hey everybody, this is Clot 2 and recently I tried a distribution that I've been meaning
to give a go for ages literally over 10 years.
Just tried it recently.
It's called Crocs Linux and it's located at Crocs.inu.
I'll spell it out.
Charlie Romeo Uniform X-ray dot November uniform.
Crocs.inu.
This is a distribution that got started back in the year 2000.
Their first public release of an ISO was back in 2001.
So they've been going strong for good 24, 25 years at the time of this recording.
And I discovered them.
I believe around 2011 or 12.
And at that time I just kind of thought that it could be interesting to give this sort
of minimal Linux distribution a try because it looked fascinating.
It looked like the installer was pretty manual.
You had to use Cherute to get the thing installed on your computer.
That's exciting.
That's not something that you see every day.
So I thought this could be of interest to me.
And I did give it a go back then, but it was a real cursory glance.
It was kind of like I did download it.
I did try to get it installed on a computer.
I messed up one of the install steps.
I think I know why.
And then I just kind of that is what kind of fell apart for me.
I just I didn't get it done in the time I lauded and then I never went back to it.
But it's been in the back of my mind for a good decade now.
I just should try that and and finally I have tried it.
I have tried it about a month ago.
So I've been using it on a spare laptop for about 30 days now.
And I'm going to talk about the experience so far.
I will also admit, not beneath admitting that one of the appeals of Crux Linux
is the cute little baby blue penguin that they use for their logo.
And it being a blue penguin is significant to me now because I live in New Zealand
where there are baby blue penguins.
So I mean, it's it kind of fits.
Is it going to replace Slackware for me?
No, I'm not looking to replace Slackware.
Happy with Slackware.
Perfectly happy using Slackware.
It's comfortable.
I love it.
Still using Slackware on my main machine.
Is Crux going to stay on this spare laptop?
Who knows?
I don't know.
I don't use as many computers as I used to.
I have my main computer set up on my desk.
I have a work computer and an array of Raspberry Pi's.
And they're just they just kind of all sit in there in a place.
And I just don't really have the occasion to swap out computers all that often
because I'm usually just here at my desk.
And it's actually a little awkward to put a laptop in front of my keyboard.
You know, it just kind of doesn't, doesn't quite fit.
So like physically it doesn't fit.
So so yeah, who knows the future of me and Crux in terms of sort of like
is this a new blooming blossoming relationship?
I don't know that.
But it has been a lot of fun.
And that's kind of what I think that that sometimes is justification enough.
Just have fun with Linux.
So let's talk about Crux.
Crux has a very manual install process.
It there is a very good handbook, very free BSD style.
Like you click on the handbook and it has basically all of the information
you need to install it and then all of the all of the distribution specific tools.
Those tools include a relatively custom as far as I can tell in net system.
It is BSD style though.
So you're looking at a slash at C slash RC dot D folder full of just custom
shell scripts that start and stop a service.
So that's nice.
If you're looking for something without system D sort of pre baked in,
then Crux is a valid option.
It is it the right option for you.
I don't know, but it is a distribution that does not ship with system D.
So if you don't, you know, if you like the BSD style in it system,
you could just run it as is.
If you want to try something else like run it or open RC or whatever,
then you could try that on Crux.
I mean, for the record, you could try that on Slackware as well.
So and frankly, it's probably easier to do over on Slackware.
So I'm classifying I guess mentally Crux being a quote unquote harder than Slackware.
And I guess I'll try to get into why I say that.
As I go, I'll sum it up at the end as well.
It is a very, I want to emphasize this is a very manual style Linux distribution.
You're going to be doing a lot of your own things to set Crux up and to maintain Crux.
It has a packaging system, however.
It's called a it's it calls it package utles PKG UTA ILS.
And that's a series of commands that you use to interact with the packaging system.
A package add PKG add is what you use to install a package,
but getting a package in the first place is a series of commands in itself.
It does have a series of ports that it provides.
And you can query that that or you can interact with that the port system with package make PKG MK.
A PKG make or package make that's how you go into a port source and you use package make.
I think dash D for download and it downloads the source code and builds the package.
And then you end up with a package and then you do PKG add and that adds the package to your system.
It's pretty pretty simple.
There's PKG remove as well to remove a package and PKG info to query for information about a package.
So if you're at all used to using either Slackware or a BSD,
then this is all going to sound pretty familiar to you.
There's a certain feel to this distribution where it definitely has taken a lot of notes from BSD probably.
That's what I'm guessing.
I mean, certainly it's a knit system and it's packaging sensibilities feel very BSD or very Slackware to me,
which I quite enjoy.
It feels kind of refreshing or not refreshing, but it just it feels comfortable, I guess.
This is differentiating it from something that feels a little bit more, let's say like Debian,
where you're using a packaging system that has a specific a robust packaging format,
where you're installing that and making entries into a literal database.
That kind of stuff, this won't feel like that to you.
It's a knit system won't feel like that at all.
Whether that's good or bad, who knows, it depends on your preferences.
Okay, so let's just kind of talk through a little bit about the install process,
because that's one of the things that you'll notice pretty early on.
Installing Crux is obviously a matter of first downloading the official ISO image.
You do that from crux.inu.
There's a download link somewhere on that page.
There's a lot of data on the site, but you just read, you'll find the link.
You get the ISO on your drive and then you need to copy it over to a USB drive.
I use Balena etcher.balena.io.
That's B-A-L-E-N-A.io.
It's an easy little open source and cross-platform imaging tool.
It makes it super simple to flash an ISO onto a USB drive.
Once the image is on the drive, you can use D-D or whatever you prefer.
I just find the etcher.balena.io, etcher just makes it really a no-brainer and it's pretty
quick as well.
Anyway, once you got the image on the drive, attach the drive to your target computer, reboot,
and use whatever keyboard shortcut your computer requires for you to use to boot to something
other than the internal drive, and that's usually a message on the initial screen when
you turn on your computer.
Sometimes it's F2, sometimes it's the DEL key, sometimes F8.
You can never tell you just have to read or look it up online.
On some computers, you might also need to enter into UEFI or BIOS to deactivate any number
of locks designed to prevent you from booting from an external drive.
If you don't know all of that, what I've just said, if that's news to you, then crux
may not be the best starting point for you.
That's a warning.
If you're just trying to figure out how to boot into some non-standard location and you're
learning something new from what I've just said, don't start with crux, probably, okay,
because crux doesn't have an installer as such.
You have to manually partition your drive using Partid or FDisk or CFDisk, I think they
have CFDisk as well.
Then you mount the internal drive, you extract the packages to it from the USB drive to your
hard drive, and then you trute into the target drive, presumably your internal drive, to install
a bootloader and add configuration files.
Now, the good news is that crux doesn't exactly make you do it all manually.
There are some helpful scripts, including a setup script, which installs packages and
a setup-chirute command to perform the steps required to establish a charute environment.
The handbook also tells you the steps of the charute, like what setup-chirute.
It tells you what it's doing, so for some reason you need to do it manually, you can.
The thing to know is that these little setup scripts aren't very robust.
If you skip a step accidentally and try to run a script before the drive is ready, then
the script might fail and then leave you in a state of complete uncertainty.
This is where I was several times during the process.
It's not irrecoverable.
You can detect that something has failed, usually when you reboot your computer and nothing
happens, and then you can go back, you can boot back to the install environment, you can
mount the internal drive, you can try to figure out where something went wrong, or you
can just start over, and sometimes that's the easier thing to do.
It's just to start back at the beginning and try again.
I think the first time I ever tried installing crux back in whatever it was, 2012, let's
say, I believe that was my solution.
I just kept something failed, I went back to the beginning, and still didn't get it
right.
This time around, I didn't have really a deadline, so I just sat down, really thought about
what I was doing.
When something failed, I would reboot back to the install environment, figure out what
I'd missed, fill that in, and then continue from there, or whatever.
You can work on this, but it is easy to miss a step, and part of the reason there is
that the handbook itself is not formatted all that well.
A lot of times, what you're supposed to do is described to you instead of proscribed
to you.
The instructions are formatted sometimes as like a bullet list, which for me that suggests
an unordered list, I mean, that's literally what a bullet list is, it's an unordered
list.
When really, it should have been a numbered list.
There are numbered lists in there, but sometimes you'll come across a series of steps that
are bullet lists.
You think you're being given a choice or something.
It's a numbered list, except they didn't give it numbers, they just gave it bullets.
You're not clear that a certain array of steps, you don't realize that you're supposed
to do them all or something like that.
In other cases, there's a series of choices under a subheading that's actually just a series
of choices dependent upon your system configuration, like one choice for UEFI or one choice for
BIOS.
It becomes very confusing when you're just kind of reading and you think you're on one
path and then you realize, oh no, no, this isn't for me because there was like a conditional
that I missed or that they didn't write down.
I missed a step more than once because I had a difficult time differentiating instructions
that were optional or conditional from instructions that were absolutely mandatory.
If you don't do this, everything else will fail.
You have to just read very, very carefully.
Read ahead frequently.
Don't follow the instructions as you're reading.
Read them and then follow the instructions.
Even then, even once you've read it once and you're going back to the top to now you're
going to read and do, don't do that.
Read like two paragraphs in front of where you are because it can be very, very confusing.
I would love to contribute fixes for this particular issue.
I'm still navigating how crux sort of structures, its contribution, invitation.
I haven't proposed any changes yet, but that's on my list of things to do.
The other thing you get to do for crux is compile your own kernel.
As you may or may not know, my daily distribution, my daily driver is Slackware has been for a
long time.
What?
2008?
I think something like that has been a long time.
Slackware ships with a few kernel configurations and binary kernel packages.
You don't really have to compile your own kernel on Slackware.
It so happens that when I first tried Slackware, there was a driver that wasn't included in
the binary package for the kernel.
I ended up having to compile a kernel from my very first Slackware experience.
It was a Wi-Fi driver.
That was an interesting experience.
That was a very great learning experience.
Even since then, I used to compile real-time drivers into Slackware.
Really, I can't say I can't honestly say I've stopped compiling kernels because I still
do compile kernels, just not as frequently as I used to, but ever since 2.3.8, no, 2.38.6,
the kernel release that gave basically low latency kernel performance.
I don't compile kernels quite as often as I used to.
I am running a custom kernel on my current Slackware box, but I think that might have
just been because I felt like updating a kernel one day.
It wasn't needed.
It wasn't necessary.
But Crux requires you to compile a kernel.
Unless you're very, very thorough, you're probably going to do this more than once.
I have now compiled the kernel.
It must have been eight times in one day.
That wasn't for the initial install, though.
I think for me, in my mind, there are two ways to manage how you're going to handle the
installation, the compilation and installation of a kernel.
Actually first of all, let's really quickly talk about why you would even need a kernel.
The kernel is the thing that tells your computer what to do.
It tells your computer what the computer consists of, like literally what components the
computer is because the computer doesn't know inherently about any other component other
than basically the CPU.
Something has to bring up all of those things like your keyboard and your monitor and your
mouse and a hard drive and internet connect or network interface card and so on.
So that's the primary job of the kernel is to just handle the hardware components of
your computer.
So you need that because your computer needs is hardware.
So to my mind, there are two ways to attack this.
One is to be very, very methodical, do lots and lots of research, figure out exactly what
you need in your kernel based on what computer is sitting in front of you that you are installing
Crux onto and you compile like the perfect kernel for your setup.
That's front loading it.
There's nothing wrong with it.
I took a little course a long time ago now on Linux to learn more at a little weekend
get away at a community college.
It was great.
It was really cool.
It was in California, I think.
And that was fantastic.
It takes a lot of time, takes a lot of effort and you sort of don't get the satisfaction
of having a compiled kernel until the very end.
I think the danger here is twofold.
One is that you don't get instant satisfaction.
It takes a lot of work up front and some people do that well, some people don't do that
well.
And then secondly, there's the danger of even after you've done all that research and
that work and you compiled your kernel, but if you didn't do it right, but if you got
something wrong, then you've spent all that time and you still don't have the system
of your dreams.
So the second option and the way that I did this was to just do it good enough to get
a bootable system and then just keep recompiling your kernel as you discover things that your
kernel doesn't know about yet.
So that's the second one, the second option is the tactic.
I took, I think for me, that's the one that I recommend to be perfectly honest.
But if that's not how you do things, then obviously you can do it your own way.
But you do have to compile the kernel for crux and it's really, really easy.
Crux does not install its kernel through the package add system.
So you just compile the kernel and copy the kernel image over to your slash boot partition.
You copy your system map and then now your kernel is installed.
The process of compiling a kernel is the classic way.
It's the traditional canonical way of compiling a kernel.
Like it's the instructions that you get when you download the kernel source code.
It isn't the new stuff like on Fedora or Debian where you invoke some kind of special packaging
things so that you can package up the kernel and integrate it into your system and add
it to your grub and stuff like that.
It isn't like that.
It's just you just go in and you do a make menu config and that brings up the little
funky little interface for choosing all of the different modules and things that you're
going to compile into your kernel.
If you've done your research and you know what your computer has in it, then you can look
through there and find all the modules that you'll need, all the drivers that you need
to include and make sure those get included.
If you can't be bothered to do that, then you can kind of just go for the basics.
I have compiled enough kernels on Slackware to know, you know, the important stuff like
well, file system drivers are really, really important.
I think EXT4 is probably auto included, but I just like to include all the file system
drivers, network card, nix, network interface cards.
Those are important.
Wi-Fi drivers, I think I did at least look at what the Wi-Fi driver was on the computer
before compiling the computer, the kernel, and that worked out well.
I didn't have to recompile for that.
Then there are some obvious things, obvious, I say obvious, I forgot to include it, but
I was installing it on a spare, like this is a Dell, something or another laptop.
I don't even know where I got it from, and it's like a rescue computer.
It's a Dell laptop, and so you would think that I would have thought to include the
drivers or the driver package called Dell underscore laptop.
I didn't.
I did not think of that.
And frankly, the menu config interface of compiling, of prepping a configuration is
a little bit not great for discovery, and so what I like to do is I do the make menu
config command to bring up that kernel configuration.
This is in slash usr slash slash linux version number.
You do make menu config, or actually I think I had to do, no, yeah, make menu config.
You might have to do pseudo make menu config if you're doing this after install.
I do that, and that creates a dot config file in that directory, in your source code
directory of the kernel, and that is really great for discovery.
I open that up in nano, I do a control W to search, or I guess it's a where is command.
And then I search for a thing that that I'm looking for.
This again, this is kind of what you can do this before you compile to.
I do it like later later, like when I'm when I'm realizing, oh, the fans keep turning
on, you know, at a really not very high temperature, how can I control that?
Oh, well, I need to go install the drivers for the various sensors in the laptop.
Okay, well, that means I have to find all the I2C drivers.
So, so then you just do a control W, I2C, or I see two, and I think it's I2C.
And then you get to find all the options that have probably not been set at all,
but they're commented out.
And it just says, you know, I2C underscore, blah, has not been set.
And then you can just set it yourself.
You race the part that says has not been set and put in equals why, or equals M for module.
And now you're modifying your configuration, but in a way that you don't have to like hunt
through a menu.
So whether you use menu config, whether you just do a config file by hand, I don't know
why you do that, or maybe you borrow one, like a known good configuration from like Slack
where maybe just throw that in there, see what happens.
Lots of different ways to compile your kernel.
And once you're kind of done the configuration, you do your make all, and then you do your
make modules underscore install.
I think that's it.
Then you copy the, from the arch x86 underscore 64 slash whatever slash, what, what, what
beat BZ image to slash boot slash VM, the news.
And then you copy system map from your current directory over to slash boot.
And you've got a kernel installed.
And as I say, if you're going to do it the lazy way, like I do, you'll be doing that
sequence of steps frequently later on as well.
You have to do it once to get your computer bootable in the first place, but you don't
have to necessarily do everything right.
You do, you need the basics, you, you'll need a file system support.
Like without that, then yes, you'll have a kernel, but your kernel can't recognize,
you know, like the rest of your computer cannot recognize the file system upon which
you've installed your operating system.
So that's not a great idea.
You do want the basics, but when I say basics, I think file support might be practically
the only basic you really, really need.
I mean, other than just all the other defaults that the kernel provides anyway.
So yeah, if you've never compiled a kernel, that's a great learning experience.
If you've compiled a kernel, it's still a good learning experience because there's always
something.
There's always something you've, I forget, you know, it's just, it's silly, but you
just, you realize how complex it can be.
Okay.
Anyway, once you get like the kernel installed, then you need to do the install of the boot
loader and the boot loader is in theory pretty simple for you to do, but it is kind of
difficult sometimes to understand what, what you, which of the options you need to choose.
The first of all, crux uses grub as a boot loader, it's not, I don't love grub.
I'm learning to love it a little bit more, but, but I don't love it, but it is better
than syslinics.
So realistically, it's probably easiest to install and use grub, but then you have to choose
between two different paths in the documentation.
You can do grub on UEFI or grub on BIOS.
The difference between these two options is that UEFI requires grub to be located in
slash boot slash EFI, while BIOS expects grub to be in the master boot record or the
MBR of the drive.
It explains all of this in the handbook.
You just want to read it really thoroughly, as I've said before actually doing it.
Once you've done all of those steps and I'm assuming you're not following along with
my vague description here and that you're following along with the crux handbook, once
you've done all of the steps that you, that it is told you have been required, you have
to configure your language and your network settings and eventually you can reboot your
computer and boot from the internal drive and assuming you got everything right, then
you get a grub screen allowing you to boot into your new crux system.
As I've said, I didn't get that far the first time.
Instead of grub, I got an error message on my screen and so I had to go back and reread
the documentation and I realized that yes, I had installed grub, but I had not configured
grub.
At this point, this was the third or the fourth major mistake I'd made during the process,
but it was like many of these errors.
Once you figure out what you've missed, it's pretty easy to fix and it's kind of hard
to know whether it's just overwhelming or whether it's overwhelming and poorly written.
I lay a lot of the blame on the handbook, the style of writing in the handbook.
It is just sometimes not clear about what you need to do next and when to do it, it's
just I don't know.
Maybe it's just me, I'm not a huge fan of the passive voice and kind of vague description
of things that could be done on a computer when you're when installing crux, but don't
tell me what could be done, tell me what to do or tell me why I don't need to do the
next step so that I can skip to the next section and the instructions.
Anyway, it's not an episode about documentation, so I rebooted to the installer to fix this
particular grub issue.
I mounted the internal drive using mount and then I used the setup dash trute script, which
is just so handy to make it my active environment and then ran grub make config, which is the
step that I had missed.
So grub make config, redirect into slash boot slash grub slash grub.cfg, because after
you run setup dash trute, your environment, you just pretend you're on the drive, that's
your new environment, you don't have to change the paths of anything, it's all active,
it's all mounted as the active environment.
So a lot of the things that you'll run into may be fixable by just using the setup dash
trute, you don't have to necessarily go through the install process again, you just have
to boot to a thing that allows you to use setup dash trute and from there you can do whatever
you need to do, whether you, whether that is recompiling your kernel, because you got
something completely wrong or running grub make config, because you didn't do that or
whatever little error, I mean sometimes it will be easier to just go back and start over,
but don't feel like you absolutely have to, if it's, if you think you know the problem.
Okay, so I rebooted again at this point and had an operational and operating crux system.
When you first boot into crux, you have, you have to log in as root and then you continue
configuring your system.
So for me, this meant installing the Wi-Fi drivers, because I've forgotten those and then
creating a normal user and then eventually I had to install the sensors for the, so
that the fans would stop going on all the time and so on.
So there's a lot of things that you can kind of, like I say, if you take my style of doing
it, my tactics, we're just to get it bootable and then adjust as needed as you go.
And again, the recompiling of the kernel is just a matter of going back to user source,
Linux, whatever the version number was, and then editing the .config file and then recompiling
and just copying the BZ image over to VM Linus in slash boot and the system map and then
rebooting and you're good, you don't ever, you don't, there's no, there's no trick to
that.
It's just, it's the same process over and over again.
I mean, you could keep an old kernel around and, you know, kind of switch between kernels
and stuff if you wanted to.
I didn't need to do that in this case.
I'm just, I'm just replacing the kernel because the first one that I did wasn't right,
the second one that I did wasn't right, the third one and so on.
Okay, so installing software, let's talk about that.
Now you're using crocs, you've got your normal user setup, you've got most of the environment
set up the way you want it.
Now you want to add to your bootable system and get more applications.
This is, this is cool that they're, they're packaging system.
I really, I quite like, I say that with a note of hesitation because the biggest problem
with their packaging system is that there's not enough packages in it, like there's, there's
just not.
They're, they're, their ports system is really nice that they're, they've got some cool
little tools.
It feels very slackwareian.
I think probably if I had been crocs, I'd have just stolen slackware as packaging system.
Like just honestly, that's what I would have done because they're, they're, the package
is available from crocs and even from their contributors, just, it's not sufficient.
It just isn't sorry.
So the good news is, well, there's lots of good news.
One good news is that it's super easy to make your own package.
You can, the packaging script formats such as it is, it's really easy.
You basically give it a URL to download the source code from and then you give it the, the
instructions of what, of how to compile the, the source code, which it's, it's no different
than what you do anyway.
It's like a, you know, if you did .slash configure, make, make install, that's what you put in
your script.
That's it.
There's, there's no magic here.
Now, there's the opportunity for magic if you need more out of your script, you can make
it do more, but pretty much like the, the, if it's, if it's just, if it's a super simple
install that you'd have done anyway, just with a .slash configure, make, make install,
you can make a package out of that simply by, by, by making a, a package file for it and
then running package, make dash D on your own package file.
It produces a package, then you use package add, the name of your package and it's installed.
It's, you're, you're done.
Really, really easy, possibly, possibly even easier than Slack builds.
I hesitate to say that because Slack builds is more, well, it's a little bit more structured,
I guess.
There are conventions that have risen up around Slack builds formatting, which handles a bunch
of different, different edge cases, whereas I have a feeling that with crux, that's those
same conventions don't exist.
So you might be re-implementing some things, some hacks here and there because you, you
know, like, oh, this package needs this weird adjustment made.
Well, I guess I'll do that this way and someone else has the same adjustment that they need
me, need to make two different package and they're doing it a different way because as
far as I know or at least as far as I've found, there's no template for like, this is
how you should do these things.
So I don't know, it's probably half a dozen one of one, six of the other, but my point
is it's really easy to make your own packages and I have a feeling it would be super easy
to adapt packages from other sources like Slackware or Arch Linux.
I don't see why there would be any problem with doing that.
And I haven't done it yet, but I have a feeling you could also just run Slackware packages
or rather Slackware build packages here on crux, like I don't see anything that would
stand in the way, the one thing would be that the Slackware packages assume or I should
say, Slackware build scripts assume that you have Slackware and so it just makes blind
assumptions about whether you have, I don't know, Perl installed because of course you
would have Perl installed because that's part of Slackware.
But if you're running crux, maybe Perl isn't installed, that's not true, Perl is installed.
Let's just say Foo.
So if it wants Foo, then it assumes that it has Foo because it knows Foo is on Slackware
whereas on crux, maybe Foo isn't installed.
And so running a build thing that was designed for Slackware, you might run into an error,
a surprise error because, and it might not even tell you what the error directly is, you'll
have to look through the log, the output of the compiler to realize, oh right, okay Foo
is on Slackware, Foo is not here, so I need to install that first.
So that could like run into a quote unquote problem, meaning it wouldn't just be sort of
a press return and then go have a cup of coffee, you'd have to sit there and kind of babysit
it and figure out what the problems are and then go back and solve them.
But to a point, I don't even think that would be that big of a deal.
I feel like, especially if you know some, a lot of the package that you're installing,
you kind of, after a while, I think you kind of build up a sort of a mental list of dependencies
anyway.
And so you kind of think, I think this is probably going to fail, but I think it's going
to fail because I think this needs Foo and Bar and Baz, and I don't think, I don't know
for sure that crux has that, I mean you could also just check before running.
So yeah, you can use other packages or other rather build scripts.
I think you could probably easily hack other packaging systems into crux, like again,
Slackware.
I don't see why I wouldn't be able to run Slack PKG on crux.
I've run it on Debian, so why wouldn't I be able to run it on crux?
I think if I really, really wanted to and started using crux, really seriously, I think
I would probably do that.
I would probably just port Slack PKG over to it.
I mean, I say port.
I mean, it would be, like I say, it's a super simple process.
It's not that hard.
It's just a bunch of shell scripts and some temporary, or not a temporary file, but some
log files.
So those are all options.
And then there's the other universal global option of PKG source or package source.
However, you're supposed to say that.
The thing from netBSD, which I, which I tend to enjoy trying.
And I say it that way because sometimes I try it and it doesn't work as well as I wanted
it to work.
But I'll talk about that after I talk about the PKG utles on crux.
Okay.
So I've talked about how easy it is to make a package on crux.
But let's just back up and figure we've just booted into crux.
We've created our standard user.
We've gotten some things configured.
Now we want more software.
So it's as either as a root user or using sudo, you do a ports dash U. This is a ports
command for crux and the dash U stands for upgrade.
What that does in this case is it triggers ports to create a directory in slash usr.
So now it's slash usr slash ports.
And then it downloads the ports tree, which is, you know, all of the text files included
in the in the ports system from crux servers down to your computer.
All that really is is a directory for each software package.
And in that directory is a PKG file, PKG file has a URL of where to get the source code.
And then maybe some special instructions for the ports system on on what it needs to
do to compile that package successfully on crux.
As I've said, usually that is a matter of just dot slash configure, make, make install.
But sometimes you'll run into a package that also needs, I don't know, auto-con for
auto-recon for, you know, auto-gen.sh or AC local or something like that run first.
And then a dot slash configure and then a make and then a make install so on.
So there's usually some kind of, well, I guess probably always, some kind of instructions
in the PKG file of what crux needs to do.
But it is pretty much a straightforward sort of shell script that you'd be doing anyway,
whether it was a package or not.
Now, you can find a port on your system using standard system tools like L.S. or GREP or
FIND or the special crux command PRT-GET.
The PRT-GET command searches your port's tree and gives you information about what it
finds.
So you can do port GET, search, I don't know, TCSH.
And then you can do port GET info TCSH and it tells you where that package is located.
So you know that TCSH exists in your port tree.
You don't know where yet.
So port GET info TCSH tells you the name.
The path is in this case user port opt, the version available and so on.
Now to install a port, you change directory to the location of that port, which we just
got with port GET info.
So CD slash usr slash ports slash opt slash TCSH and then you use the package make command
along with dash d for download to create this thing into a package.
Now, the first time I tried this, I got an SSL error from curl, a package make uses curl
to download the source code.
And I got an error message because you've probably seen this yourself.
Curl and SSL are kind of having issues right now and have had issues for a while.
It's sort of the integration of it.
So to tell curl where to find the certs, the SSL certs on your system, what I did was
I issued a ca underscore cert underscore bundle equals slash ETC slash SSL slash certs.
.pm space package add dash d and that that that fixed it strangely that fixed it forever.
I thought, well, I'm going to have to add that to some kind of environment variable
or something.
And I don't remember actually doing that.
So I don't know if curl is now sort of logging where the SSL certs are or or what happened
there, but it hasn't been a problem since.
So yeah, ca cert bundle your your certs are in Etsy SSL it's the certs.pm that that curl
is looking for.
And so if you do that before package add, then curl inherits that environment variable
and it's good to go.
So once you've gotten the package built, then in your current directory, you have a package
TCSH in this case hash the version number, the build number, and then dot pkg dot tar dot
gz, which is a really weird format for a package name.
I can't get used to a hash being in the package name, but there it is.
That's how package add knows that you're giving it a the package and not just any old
random tar ball.
The package add is completely silent upon success.
So as long as you see no output from your package add command, then your package has been
added to your system successfully.
Now by default, crux provides you with core opt and zorg package sets.
That's over 750 ports ready to install, it's kind of nice.
However, there are yet more in the contrib collection.
So if you want to enable the contrib collection, which I recommend doing, just rename a configuration
file.
It's sudo move slash ETC slash contrib dot rsync dot inactive to slash ETC slash contrib dot
rsync.
Makes sense.
You see what's going on there.
And then you update your ports tree ports dash you or sudo ports dash you.
And now when you do a port get, you'll find a bunch of more packages.
The contrib collection currently has about a thousand additional ports.
So total, you've got a good one thousand seven hundred and fifty or, you know, in that
ballpark number of software packages that you can build and install on crux.
That was not quite enough for me.
And so I did install package source as well from net VSD.
So if you go to package source PKGS RC dot org, probably I would imagine package source.
Yeah, dot org.
You can find out more information on how to install package source on Linux.
It's not terribly difficult.
There is a bootstrapping process that you must do.
And then from there, you must use be make rather than just make when building things.
And you do run into problems there are there are weird little issues with package source
sometimes or rather there are there are problems with package source sort of and yours and
your system like recently I ran into a problem installing.
I think ghost script, which was a dependency for image magic because I'm pretty sure
crux doesn't have image magic in its ports collection.
That doesn't seem believable, but why else would I have been doing it?
Anyway, I was installing image magic and it needed ghost script and ghost script needed.
I don't know, something else.
And it turns out that that something else was already installed on my system.
I think it was a Python script or something.
And and package source was looking in user include and finding the thing that it thought
it needed, but it was the wrong version.
And so it wasn't it never worked.
So I had to go in and kind of modify the setup.py install script for this thing such that
it wouldn't look in user include and it wouldn't look in user local include or wherever
else it was looking and that it would only look in like some other prescribed place.
I think slash opt slash PKG source.
So there are sometimes some surprises about what what package source sort of it you know
like is programmed to do and what it really ought to be doing through no fault of its own.
It's just sometimes it is not you know the system and package source don't know each other.
And so sometimes there's a little bit of confusion.
Another thing about package source is that sometimes frequently you basically feel like
you're just installing a new system like a whole new operating system.
You're just you're installing a lot of stuff that you that you already have on your system.
And that again is because just like with with slack builds or really anything like the
packaging system no matter how simple or complex that there are just assumptions that
that's that we have to set down we have to make assumptions.
So package source can assume either that you have that any time you need something new
on your system that you either already have it and that it should find it or that you
don't already have it and that it should install it.
You can choose what package source assumes you you get to make that choice in your I
don't know mk.com for something like that probably not that but some configuration file within
package source you get to choose whether it prefers package source or or not.
And if if you tell it to prefer package source then it's going to any time it needs food
and and it knows it needs food and it's going to install food into its little package
source sub system into like a you know into slash opt package source or wherever you
have package source installed.
And if you if you tell it not to prefer package source then it'll check your system
to see if any version of food has been installed and that is a little bit dangerous as you
can imagine because now you're you're just randomly saying yes or whatever I've got installed
just just take that and use it that doesn't always work.
So you have to make a choice and the choice that I typically make is to prefer package
source. So if there's something that package source needs on my system I tell it not
to assume you know to to assume that anything that's already on my system is not isn't
say it has to have its own copy of whatever it needs and that does very frequently mean
that you are compiling basically a whole new OS into package source.
So that's that's kind of a downside I mean I'm being hyperbolic it's not a whole OS
but it's a lot of stuff and a lot of that stuff you're going to think I already have that
over here but do you have that version and maybe you do today but are you still going
to be that version tomorrow like how are you going to synchronize these things.
So I do just kind of keep a whole package source sort of subdirectory on on crux so far
and that that's one way of doing it a different there are different ways a different way
could be to to not prefer package source and just risk risk at all just go for it honestly
I who knows I might try that I might try that myself soon just just for fun but another
way is to just use slackware packaging or arch building you know art the arch whatever
they call it a you are whatever the arch thing or you steal from arch and slackware package
definitions like their build scripts adapt them for crux and build it that way you know
so lots of different options I think that they're all basically equally realistic probably
the right one is whatever brings more packages into crux's ports system I mean I mean quote
unquote right meaning that it's the right way because that's the now you're you're adding
to crux's repository of of packages you do have to figure out how to become like an official
package or whatever which I haven't looked into yet but you're also just you're only dealing
with one port system then because if you do the package source option now every time you install
a package you have to you have to search two places your ports tree and your package source tree
and then if if the thing exists in both places you have to decide which place are you going to
install it from keeping in mind that if you do it in the crux port system and you're preferring
package source then you might be installing it again later if it becomes a dependency of
something that you install with package you know it becomes very confusing potentially if you
overthink it or if you're trying to be too precise about it so that can be kind of a danger so
probably the the right way is to just try to optimize or rather bolster crux ports as much as
you can with your own custom scripts maybe contribute back if you can if you do that and then you've
got a nice sort of personal setup for for all the for all the things that you need on crux and
that's kind of where I am with crux right now is just kind of building up my own environment adding
packages to it and just kind of enjoying the the minor differences here and there and between crux
and sort of like slackware basically and there are minor differences that you know it does it's
rc.d and it scripts a little bit differently not terribly differently but the the you know there are
certain I mean they don't all start with rc. for instance that's one difference um I mean they
are basically all just case statements or you know with a couple of fancy if then statements thrown
in for for fun but I mean it's it's it it is different um there's not as much stuff pre sort of
installed and sort of pre configured on crux as there is on slackware um which I mean technically
I guess could be a good bet thing could be a bad thing depends on what you're looking for so um I
think probably I would hazard to say like if you're if you're maybe looking for a BSD like
experience but you're you're just really really comfortable with the way Linux does things as I
am then then crux could be something to take a look at there's there's a lot of manual labor here
but if that's what you're looking for then then crux could be a very cool um sort of project
to endeavor upon I mean or you could just use a BSD like net BSD I mean there's there's a lot
of stuff to learn there as well so it's kind of whatever you're feeling like I guess um but I've
had a lot of fun with crux it's been a it's been a real pleasure to experience it to try it out
finally to get it installed to to really get back into to to just fiddling with a kernel like that
that has been you know it's it's weird it's it's like it isn't that I couldn't do more with my
kernel on slackware it's just that I guess I don't feel like I know what I would like to bother with
and also you know certainly I don't really want to break anything on slackware like it's my
daily computer now I could just install slackware on a different laptop mess around with the kernel
and do but but with crux or with something new a lot of times like the reason you explore more
is because you kind of have to because something isn't working and so like there's a different
sense of urgency and purpose when when just when you encounter something that's just like oh I
have to do this I have no interest in fixing this I don't actually care about what sensors are on
my motherboard I don't care about how to detect the different sensors and what hardware monitor
inputs trigger you know to monitor for those sensors but I guess I have to learn about that now
because this stupid fan won't shut off if I don't do that um so it it's almost like the the the
thing that that is broken has a a different sense of it has a different drive behind it
than just sitting down with a computer and looking for something that you could say optimize or
or something that you could break and then refix it's just I don't know it's different
so it's kind of fun to try crux and see what what little details of computer functionality you
may have missed because of because of a really someone else is really hard work you know someone
else is configured your kernel already to do that for you but what if what if they hadn't so yeah
it's kind of fun kind of it's kind of an interesting experiment and at the end of the day I mean
crux is a really nice little Linux distribution like this would be a really fun and usable Linux
distribution if there wasn't any other minimal Linux distribution out there this would definitely be
that this is a great fallback option if nothing else and I don't mean that in a bad way I mean
it's great to find a Linux distribution that's been around for a quarter of a century now uh and
that has you know that that's that's got support it's it's it feels steady it feels like it's it knows
exactly what it is and it it is it just continues to be that so if you're curious give crux Linux
a try it's a lot of fun thanks for listening you have been listening to hacker public radio
at hacker public radio does work today's show was contributed by a hbr listener like yourself
if you ever thought of recording podcast you click on our contribute link to find out how easy it
is hosting for hbr has been kindly provided by an honest host.com the internet archive and
our things.net on the satellite status today's show is released under creative comments
attribution 4.0 international license