Thanks, TheTKS.

For me, the real interesting story was wifi. I first had a huge issue because what wifi chip the RPi 4 was using was one of the best-kept secrets by Broadcom - like they were afraid to say it was theirs. In X86 land I held a poor opinion of Broadcom generally after my experiences qith the BCM43xx. I eventually inferred it from text files in the firmware, but only positively identified it by removal of firmware. For the record the Rpi 4 uses a brcm43455 or brcmfmac 43455. It's not a separate chip, it's just 0.1mm³ or so in the cpu or SoC that the bcm2711 appears to be. The good news is that they don't have the Cypress stuff that apparently was the cause of trouble in the RPi 3.

The sad thing is that I don't know if I'll be back on Arm. I like the way slackware does things, and imho it's the most well designed OS. Where else can you run multilib, make your own packages, screw up and sort yourself out? But there's great development effort compiling & providing Arm packages. There's at least 6 developers putting X86 packages online independently, as well as whoever's here - at least 2 in slarm64 and however many are in the Armv7 port. Their efforts could be managed a lot better if they weren't ignored by official slackware.

I also feel Arm is a different use case. X86 does servers(large & small), office use, research, clusters, home users. Arm is essentially competition for SBCs. Arms are up long poles in remote places, logging, weather stations, monitoring, headless (or not) jobs of great variety. My use case is unusual, where it's purely streaming media, normally seen as an X86 job. I would hope to see this effort acknowledged, but know it's unlikely, and that slackware will suffer. Unofficial slackware will become bigger than slackware, at which point a fork becomes inevitable.

Whilst I can see your point and to you it may be that way, but there's a part you're missing here.
One of the things you need to do to maintain an OSS project long term is be aware of two things
1. What your resources are - both for yourself and those who contribute
2. What you tie yourself to - both in terms of technology (software, hardware) *and* to what _individuals_ contribute.

The reason is that people come and go, and so if you include so much stuff and those contributors eventually quit contributing, you've got to maintain this by yourself or have someone else step up to maintain it.
As is often the case, in my experience, people talk more than they do and quickly quit their contribution when they realise how much work it is.

So in fact, I think that the reason Slackware's still around and people continue to use it is because of how the community ecosystem/feedback operates. Is it frustrating that your changes don't get taken because you like them and they're useful for you? Sure. It happens to me too.
If you like how Slackware does things, you'll need to take on your own burden of maintaining things yourself.
If that's too much, you pick another tool.

In fact, I'd say that the way this works really is no different to a commercial offering. Part of my paying job role is to take customer feedback and turn it into product improvement requests, and most of them (despite customers paying millions of $s) don't get done. The customers understand that their requests are one of many and they're always at liberty to pick a different supplier: most don't though.

I can see your point. Yes, a project manager has a POV, and needs to use resources wisely. I am suggesting work but not doing it. In the 2nd quote below, I wasn't talking about my effort, btw in case that quote gets out of context!

Since my stroke in 2015, I'm not game for half as much. My schedule is also controlled by others to a certain extent and physical limitations slow everything down. So I'm not undertaking stuff I used do. So I'm stuck with the tools out there. I will compile & package stuff, but when it takes you all day to do what you used to do all day, you learn your limits, and time elapsed, accidents or pain will force you to stick to them. My career was as a hardware Electronics guy. Now I can't even solder. So I have to pick off the shelf. That's why I said goodbye.

That was the correct URL you were meant to resolve. The content was intented. It has no affiliation with LA Times or Slackware [ARM].

Likewise. Thank you for taking the time.

Err... that'll be my fault. The "problem" was two-fold (and I'm guessing here) in that the wireless firmware needed updating and some code in the /etc/wpa_supplicant needed revising for the RPis in order for the "problem" to go away. I think it was mainly due to the firmware. I don't use wireless and wouldn't have known until it became an issue or someone alerted me. Which they did.

I had a good read of the following page and worked it out from there: https://www.raspberrypi.org/document...ireless-cli.md

1 members found this post helpful.

I am very aware of the status of raspberry pi wifi. I've been using a raspberry pi as wireless access points here at home since Pi B+ was released and onward. Breakage happens when the raspberry pi foundation decides to push an update to firmware. For several months after a new board is released firmware malfunctions often, but only for the new board. The other instance where problems are found, is when Debian releases (upstream) a new major version (Debian Stable) or point release. Normally it is fixed quickly and this is the time to extract firmware from the Debian release, rather than the raspberry pi git repository. As a result, I've largely avoided issues.

The process is detailed here: https://www.linuxquestions.org/quest...nd-4175627137/

1 members found this post helpful.

Thank you both, Exaga and mralk3.

I've subscribed to the LQ thread and bookmarked the RPi link, should they come in handy again.

Wifi is still working after running updates yesterday on SlackwareARM and Sarpi packages for the 5.4.47 kernel.

Until next time ;-)

TKS