great looking podcast!

1 members found this post helpful.

as always, a good talk!

Thanks!
Episode 8 is up now.

2 members found this post helpful.

Episode 9 is up now. This time we're speaking to Angel Montanez about his experiences with Slackware and Linux at the USA's National Weather Service.

This is part 1 of 2 - episode 10 will be uploaded soon!

2 members found this post helpful.

Part 2 is up now.

2 members found this post helpful.

Episode 11 is up. Phil's been looking at Slackware ARM in docker.

The package naming convention is here.

2 members found this post helpful.

Episode 12 is up.

We're discussing the use cases for Slackware ARM on docker, and how to distribute it.

1 members found this post helpful.

Did this podcast die?

Covid-19 changed schedules and priorities. We've been talking about doing the next episode for weeks but haven't yet.
I'm also unsure what people are interested in hearing about. Phil and I can talk about anything, since we usually just make it up as we go along and I edit out most of the insanity. Ideas for topics are always welcome :-)

If you're missing my dulcent tones you can always listen to my other podcast, Master Engagement Strategies. Nothing to with Slackware though! ;-)

1 members found this post helpful.

We're going another episode of slackchat this week.

I've just published a conversation with an Infrastructure Architect on my other podcast, which people might find interesting (not Slackware or Linux related though).

Latest episode is up. This is a recording of a mini hackathon with Brent Earl, where we're fixing the qemu support. I don't know how well it'll turn out since we're looking at a screen, but just close your eyes and imagine a terminal with text on it and you'll be right with us :-)

1 members found this post helpful.

If i can get Slackware interest going in Ghana then i might try and record something

Thanks for having me. I had a lot of fun.

This was a fun episode, thanks for putting it out. I just wanted to chime in as a regular listener and say that I am also in the group of Slackware users that made the switch mostly because of the systemd thing, as your guest mentioned. Not only that, but it was systemd on ARM that started it all.

Back in 2013 I was into mining bitcoin, and I made the mistake of buying a Butterfly Labs mining ASIC, which needed an external controller. I chose a PogoPlug v2 (Marvell Kirkwood board), and the default OS at the time was Arch Linux ARM, and I was using Arch on my main tower at the time too.

I wanted to automatically start the miner when booted, to minimize downtime. I was not new to Linux, but new enough to not know much at all about startup scripts. I spent untold hours trying to get the miner to autostart on boot reliably. Sometimes it would work, sometimes it would not. Eventually I figured out that I was basically having systemd problems. No matter what I would set for variables in the service files, I would have to put in weird hacks like long sleep delays just to get a daemon to start on boot without crashing. I had this problem with several services/daemons, but the miner was mission-critical and drove me to near insanity, if I recall correctly.

That lead me to start exploring distros that had not included systemd yet. I tried everything I could get my hands on, Slackware included. There was something special about Slackware that stood out. Looking back, I think it was the perfect balance of being challenging enough to be fun but not so challenging that it was frustrating. That feeling has continued to this day. I continue to learn new stuff (like the Ctl-r in BASH that Stewart mentioned a few shows back, that has changed my life entirely...), and Slackware keeps it just challenging enough to keep it fun without making me want to throw in the towel and wipe my hard drive.

These days, I am more or less indifferent about systemd (although I do not miss it and still find that it gets in the way on other systems when I run into it). I have said to myself before, in regards to Slackware, that I came to get away from systemd, but I stayed because of the SlackBuild system. I really like how packages can be maintained as SlackBuilds. I know that other distros have their own equivalent build-from-source systems, but something about the simplicity of SlackBuilds helped me to finally wrap my head around source-based packages, something I had always been intimidated by before that. And that is the first thing I miss when I am on another distro. I just do not want to spend time learning another build system at this point. Maybe I am just lazy in that sense.

I do not think I ever got any other ARM distro to work on that PogoPlug. I believe my first SlackwareARM device was an unsupported FriendlyARM NanoPi NeoCore 2. I did the method where you use another image and rip out everything except the kernel and modules (I think I even removed the modules actually), and build up from the rootfs. Now I am hooked, several devices later. My main device is a Pinebook running Slarm64 and I am very satisfied, after all these years. I also have a Rock64 running as a torrent-box that runs Slarm64. And no, I do not mess around with cryptocurrency anymore, that was just a phase. I was more interested in the hardware than anything, I think.

Thanks for giving me a space to type. And keep the shows coming, I always find something useful in each one. Much respect.

I was thinking to myself how it could be that someone would jump ship just because of the init system, and I struggled getting it until I realised that I only use and manage Slackware now, so I don't deal with these kind of dramatic events.
Welcome to the calm :-)

Not that I want to defend system d, but I have found many times that when developers ship binaries for an array of OSs, it's often not packaged in the best way (I have seen this for Slackware ARM too (Phil is still coming to terms with the horror)), and so even with the more BSD-style init of Slackware, and the SystemV init of Red Hat - many of these types of packages often needed wrappers around their complex web of init scripts.
So if its init system is anything more than a couple of scripts, it may fall into that category.

Good to hear! I stopped using Red Hat Linux even before I started working there, because it got in my way of learning, and would edit my hand-crafted config files. In fact, managing and fixing Red Hat's servers (when it goes off the rails and has no tool to solve it), was done with my Slackware knowledge.

I look at a lot of the other distributions' build systems, and Slackware is the most simple and immediately obvious to anyone who is well-versed in Unix or Linux. However, the build system as is has limitations, *but* for (I'd say) the general populous, it fits the bill perfectly.

2 members found this post helpful.