hpr-knowledge-base/hpr_transcripts/hpr1191.txt

Episode: 1191
Title: HPR1191: Arch Linux
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1191/hpr1191.mp3
Transcribed: 2025-10-17 21:21:03

---

Hello and welcome to HackerPublicRadio.
What you're going to hear is a recording from the HackerPublicRadio Someday sessions.
Saturday sessions, my bad.
Let's keep that in.
And the purpose of these sessions is in order to record content for HPR.
So if you want to record about something or there's something you know a lot about
and you want to share this information but you don't really know how to say it
or you need somebody to ask questions about it then.
Basically if you can't get your cat or your dog to listen to you and you need a real human,
come along and find some of us here who prompt you and ask some questions and what else?
That's 9 a.m. right on mumble on the Linux base.
9 a.m. CST on the Linux basics mumble server 9 a.m. ESD or 3 p.m. or 1500 hours.
It's Europe Amsterdam.
Should we just introduce ourselves from the top?
I'll start off first because I'm after Bert and Bert's muted himself.
So I'm Bruce and today I'm just going to sit on the sidelines and chime in when I have something useful to say.
Hey folks, this is Chad or can everybody hear me?
Yes, we can hear you. I can hear you louder.
Thank you. I finally got Bluetooth working with a headset.
So I'm pleased to see that both the output and input is working.
The problem is I can't use my headphones. My wired headphones all I can use is Bluetooth.
So I'm special that way today.
I'm Cooper too and I just came to moral support to anybody who needed to record something.
I'm a dude man and I'll come into these mumble channels and chat with anybody for prolonged periods of time.
And I think today I wouldn't mind talking a bit about art because that's what I've been spending the last week trying to educate myself about.
Arch Linux, I presume?
Yeah, Arch Linux history.
Okay.
All right, I'm KT4V, John.
I just go by John, but just for a handle I use my amateur radio call sign.
And basically I'm just I'm going to listen and throw my two cents worth in.
I don't have a subject.
I'm a master of nothing and interested in everything.
Avil Hacker.
My name is Kay Wisher. Kevin is my first name.
So you know, unfortunately, by my first name, you don't matter.
I don't have a particular subject for the day.
We were I thought we were just gathered here to kind of gather some information and kick off some ideas.
But I'll be happy to give my two cents worth when needed.
Okay, well, I'm Nido Media.
I'm a great supporter of HPR and I'd be happy to record something about how to create a configure script.
I'd be happy to talk about.
Let's see how to create RPM packages and how to publish RPM repository.
And well, that's two subjects already.
There's something else you want to talk about.
If you want to know about email, I can talk about that as well.
Dude, talk about somebody who's on the ball.
Excellent.
Well, since we have one.
There's one subject.
Actually, one particular subject on the list.
I'm suggest we start with Arch Linux.
Cobra that was your subject.
Negative, sir.
Actually, my subject and I'm very sorry for the execution.
I tried to do better next time.
No, it's a great way of getting people involved, making them speak, you know, pretending that you were confused.
Are you happy?
Arch Linux, I'll take the the pattern from here.
As maybe you've known, if you listen to my podcast, that dudemanovie.cz,
over the last month or so, I've been swaying between which distro to use,
hopping around on one foot aimlessly in some aspects.
And I've kind of hopped on to Arch Linux.
And I had heard through lots of podcasts, I listened to, you know, that it's very technical and, you know, difficult to maintain and update.
But I thought I'd give it a go anyway.
And I've been playing with it for the last week on a virtual machine.
But just the last few days, I had got comfortable with a virtual machine and I went ahead and put it on some raw metal.
And I'm actually really surprised.
I'm surprised that I haven't found it earlier and I'm surprised how much easier it is than I actually thought.
Has anyone else ever played Arch Linux?
I've used Arch Linux for about five years.
I was actually considering doing some more subjects on Arch Linux, maybe even a podcast.
I'd saw in the forums over Arch Linux that someone had asked maybe back in 2009 if people were interested.
And my main reason is it's a great way to learn is chatting with people and meeting for some common subjects.
So maybe you can really help me here.
Well, I got a question for you on your installer.
You didn't really have to mess with any of the RC scripts of the old BSD and it's all you just jump straight into the system D stuff.
Yeah, exactly, which made it so smooth.
And to be honest, even in a virtual machine, I was amazed at how fast it booted.
And then in the virtual machine, how quickly it boots and also how simple the documentation was.
I tried gente to a good few months ago and I just got stuck at installing any kind of X windows.
But from the Arch, I followed the instructions, made my choices.
Good E17 up without a hiccup and followed how to configure auto login.
And then I just went through the list of all the applications that I use on a day-to-day basis.
I found out how to install stuff from the AUR repository and how to build those things installed.
I think it's a YAHURA.
Maybe you can correct me on that.
They used to call it yogurt.
That would be much easier to remember.
How is it supposed to be pronounced?
I have no idea.
I remember reading on the Arch Wiki a couple of years back that it was pronounced as yogurt.
But I don't know if that's still there.
The main thing I wanted to bring to this episode was just to bring out my feelings of what Arch Linux is and the benefits of it.
Not necessarily trying to sell it to people, but it seems to me that I never understood properly the motivations for it.
When I read the Arch way, it was really fascinating and not what it sounds like a strange person.
But it really harmonized with my feelings of free and open source and simplicity and the fact that I love the idea that they try not to apply too many of their own patches to the upstream software.
And in that way, you use stuff as it's near as possible by the original developers.
Then if there are any problems, I understand it's maybe more straightforward to know that you can report the stuff straight upstream and get things fixed more quickly.
Am I understanding that properly?
Vanilla distro. Vanilla being in that they just pull straight from upstream and build the packages without applying hardly any patches.
I think there's a couple of kernel patches that they do.
But other than that, everything's pretty much vanilla, kind of like Slackware.
Well, I found it's a lot easier to deal with than Slackware.
Even though I like Slackware, I personally am using an Ubuntu based Mint 14, but that's just because some of my amateur radio applications that I like to use are in the repositories.
And I'm not adept enough to build them from source.
But my second boot on this machine is the CrunchArch.
And I love that it is just wonderful, fast, quick, you know, just very, very great to work with.
Yeah, I was just going to download and have a look at the SinArch as well, you know, because the one problem I had with installing from the Arch was I needed a screen up to be able to follow the instructions when I was doing it on bare metal.
And so I had my wife's computer, which is across the room and around the bed.
So I had to keep jumping up going over to her computer right inside her down coming back to my computer, which you know tripled the install time just because I didn't memorize all the commands.
It wasn't complicated at all. It was just I had to walk across the room repeatedly.
So I want to want to think of next time you go to install it, use links to LAN, KS to browse over to the wiki and just use a text-based web browser to look at it.
Yeah, I actually thought about that afterwards and I've installed it on the command line, but I haven't used it yet.
I remember using that back in university days and it was really nice, but thanks for that. Bit too late though.
Well, I've got a comment. I think I'd like to bring up right now that something that dawned on me the other day.
You know, we we talk about, you know, the different desktops.
Yeah, I haven't had any trouble loading an alternate desktop to any distribution that I've had, you know, in my on my play type portion of my hard drive.
When I had plain art working, I went from XFC to cinnamon without a problem and not a reinstall.
I just loaded the desktop, the different desktop and I wondered why folks haven't found that out or am I above a head of the curve or just lucky.
I really want to answer this or to try and understand it better myself because this is a frustration I've had with lots of different distros.
You know, you get you get to the same distro, but in a different graphical environment, flavor, you know, a gnome or a KDE version or whatever.
And for one, it just seems like it unnecessarily creates a lot more work for the distro, distro developers.
And not wanting to criticize distro developers, but like if I'm making my own desktop, then I want to brand it and make it look like my own.
So I feel comfortable when it, but I'm not I'm not sure it doesn't really matter to me.
If I if I take on somebody else's branded desktop, you know, what I want is it to work functionally well and to be to be solid.
You know, and I just get in the feeling that maybe all those patches that the individual distros are or distros are putting on top of their packages to make it, you know, better or to somehow integrate this or integrate that aren't causing kind of incompatibilities between the different desktop environments or different installations of stuff.
And and then it kind of becomes maybe more complicated to a more problematic if you install different desktops.
If I may chime in.
Okay, well, I think you're right in a sense that there is indeed some incompatibilities made by changes made by certain distributions.
However, I think that ultimately these distributions making their own little versions slightly different.
And in makes that in the end, we can decide, well, this way or how Ubuntu did it or how Fedora did it or how Debian did it.
That seems to be the right way. Let's grow that path.
I think that's more or less a natural part of the development. I think that problem with installing the different desktop environments in distribution such as Fedora and Ubuntu has to do with the fact that one expects if one installs the KDE package on an Ubuntu system.
That one essentially gets the Ubuntu distribution while if that is what you want to get, you need to look a bit further.
You need to do a group install of the Ubuntu desktop.
And well, everybody's calling it KDE, so they usually don't find out and install all the separate packages themselves.
What were you going to say, Bruce?
I think a lot of it has to do more with what the focus of a particular distribution is.
For example, Ubuntu, a couple of years back, I think they were really earnest in their bid to bring more users on board and get them used to the fact that Linux is not scary, it's not just command line.
I did like their approach to things. I don't have a good analogy for it, but basically it's just one of those things where everybody has their own spin on things, actually, literally as well.
What you have is that I think it exposes you to different looks and feels of different desktops.
I think that after you get in at the entry level, then you realize a little later on it's like, okay, this was really fun.
I've had a lot of fun distro hopping. Now it's time to settle in and consider something a little more long term.
That's where I've been for a couple of years now, which is one of the reasons why either machine is, if I'm not running Slackware on one, I'm running a Debian on another.
I think ultimately after you get into the entry level, then you do decide a little bit further on what you want.
The reason Debian was such an easy selection for me is because it allows me to use the XFCE desktop.
The last thing is that you have exposure to 30,000 packages in synapses.
My comment, let me clarify, was not that the different styles of distributions, such as what the group of Ubuntu styles from using XFCE and KDE, etc.
My comment was the fact that for some reason, a lot of us think that we've got to reinstall a whole distribution to look at Ubuntu in general.
Let's say, or Debian in general, with a different desktop, and you really don't have to.
You can put that desktop on your working system and switch between, as long as you've got the hard drive space, and it's just a notion that I've heard over and over.
I tried Ubuntu, I didn't like that, so I got rid of it and put Kubuntu on, where all you really had to do was put the KDE desktop on your already working system.
If you're using Ubuntu and you decide you don't like the no interface and then you install the Kubuntu desktop package, can you go back and remove the Ubuntu desktop package when you start off with the base Ubuntu?
I would just guess here, you know, that all of these things are possible, but I'm really guessing that all the dependencies between the packages and whatever might nowadays, because of the complications, make some of these things likely to break or have complications or implications that we're not understanding.
I just wanted to quickly say to Bruce the 30,000 packages, I'd heard from a distro developer that in the Debian case, most of those are actually duplicates or outdated packages, and that that number shouldn't be anywhere near as high as that.
I don't mean to create some war here about who's got the biggest, what have you, but that was at least what I'd heard.
So no data about it. In fact, no, you go ahead, then we'll close the distraction.
I think in terms of, yeah, there are a lot of duplicates. There's no data about it. In fact, I think that's one of the problems that we ended up with in the beginning of the year.
I think that 2012 will go by as the year of the desktop for all the wrong reasons, because that's where we started off with a couple of really interesting new releases in terms of Razer QT followed by E17, and I mean, there were a lot of new development being done on the desktop, but, you know, now I think what's what we're running into problems with is that I don't know who runs cinnamon here, but I found it to be pretty wonky.
On my wife's machine and unfortunately, I've actually had the machine seize on me three or four times, and that's a little unusual for a Linux distribution.
I heard, I mean, this is, as is my subject, I'm going to jump in here and dominate a little bit, but this was my whole reason for trying at least something which is simpler and less sort of modified by the distro,
distro, distro, distro makers, you know, arch Linux, to see what things were like from upstream, you know, to see how the developers have intended it.
And I would like to get back to the days where you could have multiple desktops installed on the same machine and they seem to work well together and reliably, you know.
So that this is my, my whole thing we've tried to not just, I see using arch as educating myself to be a little bit of a distro developer myself,
but making the distro for my own personal use, you know, and maintaining it, maintaining it and understanding it, instead of just relying upon a distro.
I have one question for you all, and that is how like a lot of us do distro hopping.
So how long do we usually leave a distro on our machine before we switch to something else?
And how successful is the upgrade path on say Ubuntu or Debian build or Slackware between, you know, they're not rolling releases, but how successful and non problematic are they between each,
each minor or major release? And that amount of effort or upheaval, can you compare it to just a continuous maintenance required for say a rolling release like Arch Linux?
Are they comparable or is one of those systems, you know, more time consuming?
With my experience, I find that the Debian based distributions are much harder to upgrade than distributions such as Arch or Slackware.
Like the interject for just a second. Can everybody hear me okay?
Yes.
Okay, so, well, okay, so a background of very long history with both Debian based distros and Redhead based and now Gen2 and Arch.
I find that the rolling release distros both Gen2 and Arch, the maintenance involved with keeping them up and upgrading and so forth is so much less time consuming and problematic.
And then say a Debian or an RPM based distro.
The potential for something to either break or not be compatible when you upgrade say a version of Ubuntu or Commuter or whatever is far higher to give you an example, my Gen2 system, which I've had running now for four years or close to four years.
I originally installed it on an AMD 64 bit single core system.
And then about a year later, rather than reinstalling on new hardware, I simply changed some of the settings in the kernel so that the drivers were correct.
And then cloned the installation onto the new hard drive and changed a couple settings on the bootloader and it was up and running.
And then about a year and a half after that, I went from that dual core system to now a quad core system.
Same thing, all I had to do is change a few options in the kernel and then a few options with the bootloader and I was up and running within 15, 20 minutes.
That really confirms my faults as I was just mentioning there in the chat.
And I was amazed looking and I don't mean to over sell archer, maybe Gen2 is very good as well or some other distros, but I was amazed that the detail, but the kind of simplicity of the documentation over arch, if you can confirm what you're looking for, there was describe descriptions of how to how to move an install onto a separate partition.
And before you do an upgrade to make a backup, how to move it to a separate machine and really detailed, but really effective and I found it so interesting to read along and to improve my understanding.
If I'm really interested in your go ahead boss, if I may ask a question, I'm only regarding the wrong releases.
I'm only knowledgeable about Gen2, I use CentOS and Fedora myself at the moment.
And to me, the problem with a rolling release or problem is that once upstream decides to upgrade the upgrade and when that changes configuration options, then it changes configuration options and once you restart your service, it may or may not work again.
That is the idea with the with Debian and the CentOS like releases the which keep a stable stable system, or at least the stable base, which maybe a bit older because it was already a few years ago when it was released, but integrate the stream.
And have it safer to do an upgrade or an update of your system.
And when you're ready for it, you can upgrade from say version five to version six, then you get all the configuration changes and all the binary incompatibilities in one go.
But that gives you a moment when you have a lot of things to do instead of having them moments in time, the advantage of the not rolling release being then that you can choose the moment when you do the upgrade.
I would like to say that the one the one thing about gen to an arch.
Well, first of all, Gen2 is almost as stable as Debian as far as updates go.
They tend not to unmasked packages in the standard repos until they're absolutely sure that they're stable.
Number one, number two, you don't really have the problem of being forced to upgrade when something comes out.
Especially in the gen two repos and the gen two repos for a particular package, there might be four or five different versions of the same package in the repos so you can basically pick and choose which one you want to install.
And then on top of that, once you install the particular version that you want, you can within gen two's package manager portage basically lock it in so that that package and any any dependencies that it requires are blocked from being upgraded for as long as you need it to be.
So I mean, there are really issues with, you know, incompatibility or things breaking like that because I mean, you're free to customize what you install when you install it and what version you're able to install.
It's not quite the same with arch arch, once they once they upgrade to the latest version, they remove the older versions of a package fairly quickly.
So in that regard, you're kind of once you upgrade, there's really no rollback path, whereas with with gen two, even if you upgrade to the latest version, if something happens, you can always roll back to a previous version within the repos.
So it's way to interrupt you there prematurely, but I'm not sure for my understanding as a newbie that that's really true.
That as long as you don't delete the package cache on your local machine, then you have all of the old versions you can run scripts or programs which will delete say, you know, and only keep the last three versions of any particular software.
And they also have, I'm not sure how up to date it is or what the status, but I saw mention of kind of a way back machine for all arch packages.
And you can enter commands and have it install any any kind of package.
I'm not saying it's all automated, you know, with any of these things, you basically have to know what you're doing and to be careful about incompatibilities between versions.
And, you know, the simpler the packages with the fewer dependencies or none at all, they're more likely you are to be successful, but I think those same mechanisms do exist in arch as well.
Well, the problem is they do exist, but you have to go through tons of extra steps to do them.
They're also not officially supported.
Exactly.
They're not officially supported.
The officially supported method is once a new package comes out, you upgrade to it, and that's it.
There's no, there's no reverse.
If you want to roll back, you basically have to find one of these methods to do it yourself.
Whereas in Gen2 and Portage, rolling back is officially supported.
And it's basically a two commands emerge, dash, unmerge, and the name of the package.
And then you set which version you want, and then emerge, and the name of the package, and it'll install the correct version that you want.
Simple as that.
Looking through the, hey, go where you're sitting.
Looking through the document, looking through the documentation of arch, and I'm a newbie to watch.
It didn't look complicated to roll back to a particular version or to install from that repository I mentioned.
I'm not sure really what the difference is between supported and non-supported.
At the end of the day, it's a free OS and does Gen2 really support all of your problems.
You know, the support you get surely is based upon the strength of the community and your ability to interact and your own skills.
And this for me seems a big difference between at least I'm understanding now.
Rolling release, let Gen2 arch, maybe some others, and the kind of more automated where you get backported security and bug fixes to major packages like for Debian or Ubuntu.
But that major update upgrade you're basically putting off to some later point, which is I think we've clarified it usually is quite painful.
I just want to touch on the sort of topic that you were just talking about.
The difference between supported and unsupported is when you, when you install a unsupported package and arch specifically,
you are the maintainer of that package and any bugs that are generated from it, that's your problem and somebody might be willing to help you out.
But anybody who's running the standard distribution isn't going to be able to help you.
You're going to have to find somebody that did exactly the same thing that you did.
Whereas with Gen2, if it's supported in portage, the Gen2 devs view out.
And they're very friendly, very open, they will answer any questions you need in IRC or even email or in the forums.
Sure, I understand. I haven't really got my feet without shit.
Maybe Gen2 is the thing I should be trying. I'm not sure.
Well, I'd stick with arch first balls.
Yeah.
And you do yours and I'll close the subject.
I was just going to say, I would probably get a bit more familiar with arch first before wetting your feet with Gen2.
I've been using Linux for about 12 years now.
And it took me until four years ago to finally get to where I had enough knowledge and experience that I felt I was confident enough to try Gen2.
To return to the subject of arch.
Could you, is it, is it, is it source based or are there also binary packages?
Both.
Okay, then the main supported packages are binary and the AUR, the user contributed packages are source.
Okay, then what would you say would, in practice, the biggest difference for a regular say, say Fedora user or Ubuntu user?
I don't know, just from my perspective, just as being a, I was on Ubuntu or Ubuntu respins and just when it comes to upgrading or making sure you've got a backup before you do an update.
Just what I've educated myself so far in the last week, it just seems you've got to be a little bit more aware, have good backups.
You've got to know what, what files you've modified, perhaps use a few scripts to to understand and it's not just open in synaptic or some other package manager and clicking update and blindly hoping on the most part of the update is okay.
But it's kind of getting involved a little bit and if you're interested in getting a bit more involved and understanding what's really going on and not just sort of hopping from one distro to another hoping that
the next one will solve all your problems and be better than the previous but kind of getting your feet wet and getting a little bit involved and at least my first impressions and experience so far have been surprisingly good and I'm happy.
If that helps to kind of close this subject at all.
The thing with the thing with both arch and gen 2 and even slackware when you start to involve source packages.
You basically have a level of control over not only what gets installed but what features of it get installed that you don't get in binary distros with any one of those three slackware arch or gen 2 you can even go in and edit the individual make file for the package.
So let's say you're installing oh I don't know pigeon and you don't need ms and messenger support.
You can actually set it in the make file or in gen 2's case it's a simple use flag to basically disable that and it won't get compiled into the final binary when you install it.
Which does two things or actually three things makes the individual program run a little bit faster because it's less that has to load to without the extra code running you have fewer security vulnerabilities that you have to deal with.
And three because you're compiling in less things that you don't need it takes up less space on the hard drive and also offers better overall performance for your system.
You also don't need to have as many dependencies when you're doing stuff that as well.
Yeah, I forgot to mention I have a guess all the things you mentioned are really important but the hard disk thing is probably moved because due to in order to do this and to have all the backups of versions and we'll have you both on gen 2 and are to you.
The distro will use a lot more disk space and but that's cheap nowadays so I'm guessing that's not the most critical or the reason to do this at all.
Actually, I'm running arch off of a gig SSD so space is extremely important.
I've run gen 2 off of an 8 gig SSD.
But what I mean more is just you know, I've used with an Ubuntu build you know the whole install will only take say one and a half gig or something like that maybe less but for the equivalent right now in arch mine is up to about four or five gig you know still within your the size of your SSD but it does use more space it seems to me but that's not a problem for me.
Yeah, my arch install it right around 800 megs and that's with X and flux box.
Wow, where do you store all the packages which which download you didn't install do keep those versions or because they seem to take up you know quite a bit of space.
The way I do it is when I upgrade I push when I get back home if I'm out of the house I push all my back packages to my NFS server.
Yeah, I saw some scripts for doing that for moving moving them to a different place.
Yeah, that was that's one thing that gen 2 has the ability to do if you set it up with external storage you know network storage or some whatever the case maybe you can store all of your repository packages and everything that's stored locally on a network partition so that you can have an extreme.
Lee small hard drive in fact I think the minimum requirement for a route partition in arch.
I mean that arch in gen 2 is something like I want to say 2.4 gigs is what they recommend minimum.
Yeah, I'm at 2.6 now, but did you think many of the arch people actually do this you know I understand it's all possible but does that not you know excited run one machine and I have no no need to to put it off somewhere else.
Well, the nice thing about when I download packages for my little network that runs x86 I can use those exact same packages without having to download them again on my other machine which is also x86.
Yep, same with that's why that's part of the reason why I do it because I run multiple gen 2 machines once I download packages to a single local repository cache I don't have to download them again.
That was reading something on the arch that you can set up one machine is kind of a master package downloader and then all the others can just pick up off of it.
Gobra what's going on in there. I'm sorry I'm back in meet and evidently my push to talk keeps on getting hung.
Anyway, I'm not wanting to occupy all the time how let the arch Linux subject drop and pass it back on to our host.
I'm sorry.
Unless anyone else has any more yeah to you less anyone else has any more questions about arch Linux or what have you and I'll carry on my my exploration and education and I'll pass it back to our host.
Hey, do we want to I think we want to record the do we want to take this recording of the arch episode as separate recording of whatever is happening next.
I think that would be a good idea.
You have been listening to Hacker Public Radio at Hacker Public Radio.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show like all our shows was contributed by an HBR listener like yourself.
If you ever consider recording a podcast then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the digital dark pound and the economical and computer cloud.
HBR is funded by the binary revolution at binref.com.
All binref projects are crowd-responsive by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative comments, attribution, share a like, read our license.