Hi

I hope you've all been enjoying the new Slackware release. I've got one ARM box left to upgrade next week, and my archive storage x86 server and I'm all upgraded.
As I was preparing to upgrade the ARM box, and thinking about how and when I will pick up -current again, I've concluded that I cannot see the purpose of developing the 32bit any further.

I don't have any 32bit hardware that's capable of being able to saturate my Internet uplink, and even if there was any consumer-grade hardware available - there's no good reason to purchase any when I have completed the 64bit port already. I've been using the RockPro64 and Pinebook Pro as daily drivers (mostly web browsing and shells) and since the web has moved to open technologies (e.g. not Flash), all web sites that I visit work on the ARM platform. Slackware is also incredibly easy to develop since the RockPro64 is literally twice as fast as the 32bit Orange Pi Plus 2E.

32bit support - even on the x86 - has been deteriorating in the last couple of years, and it's clear that some of the core upstream projects no longer test on 32bit. That said, issues are resolved but it can be a bumpy ride.

I plan to maintain 15.0 ARM 32bit for the foreseeable future (and maybe 14.2 depending on the conversation with its sponsor), as the armv7 hardware is solid and the support for the Hardware Models is mature.

There should be another Slackware release far sooner than you may have come to expect, which means that I can make a stable release Slackware AArch64 far more quickly than I had previously envisioned; enabling me to use it to power my production systems (I only run stable releases for prod machines) and 'drink my own champagne' so to speak.

I've also been thinking about how to keep pace with -current. A number of you have told me that you have preferred the 'roll up updates' (as I call them) rather than being in lockstep with x86. I plan to do monthly drops, and drop in the security updates as quickly as possible subsequent to a drop - as I'm doing with the 15.0 maintenance presently.
This approach also enables the community who want to contribute Hardware Model support to be advised ahead of time about major changes such as kernels and the likes, and pull from the private repo if they want to test their Hardware Model support prior to a drop.

If you do have 32bit ARM hardware, given the low price point of the AArch64 hardware and the gains in performance, I suggest looking into it.

Cheers
s.

Yes to this, thank you!

1 members found this post helpful.

As far as I'm concerned the "arm32" can go, I have no use for it. I'm eagerly waiting for aarch64 to be made public and I've ran out of nails to bite.

What he said! ^^^^^^^



--
Pete

Thank you for all your hard work, Stuart! I would have to agree with you that 32 bit is done for general purpose platforms that Slackware targets. Embedded still has a use, but there are dedicated embedded distros (or whole other OS's like he micro-kernel ones) for those. It was a good run, time to move on.

Thanks. I've pulled the 32bit hardware out and added it to the retirement/spare parts bin. Perhaps I'll put it on ebay "Built the ARM port of world's oldest Open Source Linux distribution, Slackware." ;-)

I'm quite pleased that running the same workloads on a Banana Pi running Slackware 14.2 vs 15.0 on an Orange Pi Plus 2E yields noticeable performance improvements, particularly in interactive applications such as PINE.
As I was upgrading the last ARM box, I had to abandon an ancient pop3 server I'd been maintaining for 20 years (as the code's too old and doesn't meet current language specs, I couldn't get the linker hacks to work and didn't feel like patching the code), and followed a Dovecot setup doc on docs.slackware.com, migrating the entire setup pretty quickly, plus removing the dependency of inetd.

Well, the 32bit -current tree has been wiped and I've set slackwareaarch64-current updating itself.
For those of you who are using the private SA64 repo: I'll upgrade Linux once 5.17 is released, update all the bootware; then have the RPi testers have a go at it before releasing it publicly.

Good deal!

*Throws Raspberry Pi 1 B+ and Orange Pi R1 into to be disposal bin*

Well-- eight of my regular use systems are 32-bit ARM. And I eat, sleep, and breathe Slackware (for around eighteen years now). And, I don't just throw things away. So, what can I do to help keep the 32-bit port alive? When I say "What can I do?", I mean-- can you share details about your build process? Or-- a link where that is outlined (extensively)? Perhaps, I will mirror my *own* 32-bit port.

Is it not premature, and doesn't it seem a little short sighted, to be writing off 32-bit Slackware ARM before AArch64 is released publicly? If you're looking to reach as many people as possible and increase the existing user-base/community then the implications of "moving on" may be a step in the opposite direction. While the world recovers from the impact of Covid and everything is becoming much more expensive, and considering the current semiconductor nightmare that's predicted to last until at least 2024, it's the perfect time to review existing strategies and formulate the best way forward. Some people might not be able to simply forget their 32-bit devices and procure 64-bit replacements, even if they wanted to, for financial reasons or otherwise. These are uncertain and unpredictable times indeed.

Similarly to your predicament, I have 18-20 ARM devices with only 5 of them being 64-bit capable. When I'm not testing other OS they run Slackware. This situation may be like your favourite TV series/show that's about to air its final episode - you'll potentially have to bite the bullet and find something else to enjoy and fill your time with.

1 members found this post helpful.

What would be short sighted would be to continue to spend huge amounts of time (1 hr already spent this morning solely on updates) nursing 32bit builds and testing, which comes at the expense of everything else I happen to be doing in my life.
What would be worse is to spend lots of time continuing with 32bit, only to kill it later with no support for people who'd followed along. Right now, -current (before I removed it from the ftp site) was in sync with 15.0 so it's a great point for departure.

I don't need to pay the personal price for that.

I'm running 15.0 on the 32bit ARM hardware I'm keeping up. It has an LTS Kernel with a (presently) modern set of packages.
Slackware ARM 14.2 still works flawlessly on the armv5 as will 15.0 on the armv7.
One has to draw a line somewhere.
You're welcome to take 32bit forwards - just don't use the Slackware, Slackware ARM or ARMedslack name.

2 members found this post helpful.

Let's do a vote to understand the need.
For current, I could allocate a resource and time with support.
Also don't forget about the existing aarch32 port bonslack.

sndwvs, thanks for this. I did not know about it (and will look into it).

Well-- it's certainly not my place to tell *you* which type of Slackware ARM system to maintain. I mean, my contributions are laughable (at best). But (based on what you're saying here) if the issue is time constraints, then the way I look at it is that-- 32-bit runs on 64-bit. If you only want to maintain one version, then stick with the port that runs on more systems. That makes more sense, practically. I encourage Slackware ARM users awaiting a 64-bit release to share the features they are dying to have. Because-- I can't imagine what those could possibly be.

I'll play devil's advocate. My NAS (a Raspberry Pi 4 (64-bit ARM)) has a 30TB RAID. Unfortunately, I must divide that into two 15TB partitions (due to a 32-bit ext2/3/4 mount limitation). 64-bit GNU/Linux systems have a mount size limitation of some number of exabytes (solving that problem). What else does a 64-bit Slackware ARM have to offer? Is it worth scrapping the 32-bit port Mozes maintains? 'cause, that's what's at stake. No more installing Slackware ARM on old Chromebooks, Raspberry Pi 2 (version 1 is already unsupported due to lack of hard float), Microsoft's useless Surface RT (yeah-- people do that now), or QEMU 32-bit ARM.

The available 32bit hardware is so much slower than the available 64 bit hardware, that *developing* on it is a chore where as 64bit isn't because it's faster to fail, faster to fix. Additionally there's no point in adding any new Hardware Models for it.
The testing is laborious as not all of it can be automated, and I cannot maintain the quality required.

_Using_ 32bit on the other hand is fine - I'm running 15.0 on my Orange Pi Plus 2E, and apart from not being able to saturate the network, it's perfect for the job it's doing.

I had a quick look at Bonslack and as I suspected, it (at least from browsing the repo) is built using modified x86 SlackBuild scripts, and doesn't support as deeply as Slackware ARM does with auto configuration of some packages, and doesn't have the level of documentation I've created to accommodate the differences in architectures.

I'm going to leave all of the 32bit support in the ARM src tree so if anybody wants to figure out how to improve their own 32bit port, they can do so.

I had planned to have one more release of 32bit but it's a relief to have decided to retire it already: You have no idea how much effort was required to maintain the quality required, even with the level of automation I have.

1 members found this post helpful.

Will 15.0 32-bit continue to receive security updates for some period of time or is it beyond "mostly dead" in the MPSFHG-sense?