Top 10 Linux Distributions that still support 32-Bit Architecture

[rockedge]

List of 32 bit Linux OS's
"Top 10 Linux Distributions that still support 32-Bit Architecture"

https://www.fosslinux.com/43256/linux-d ... QXk-_7wFEM

[taersh]

Just to mention.

As the comments pointed out this list is failure.
It lists Distros that dropped 32bit meanwhile.
Also incomplete as the comments pointed out.
It is missing some Distros that still seem to support 32bit.

Thanks for the link anyway.

[rockedge]

I thought it would spark some interest and we can get a better picture of what 32 bit OS's will continue to get support!

[wiak]

I'm never sure what is going on up at Void Linux in terms of team situation. It's original creator seems to have left its development team (again). However, Void is a distribution that builds its repositories via build scripts and is a rolling release so no reason it ever goes defunct due to developers changing so it seems to remain a reliable distro for long-term adoption, and it still seems to support 32 bit. Since, as I say it uses build scripts for its repos, rather than depending on whatever repos some other distros provide (such as Ubuntu, Debian, or Slackware) it seems likely that it will continue to support 32 bit for as long as people see point in that.

Void Linux is a particularly great choice for someone looking for a particularly fast/efficient implementation, and also for those who do not like systemd (Void uses perhaps the best alternative to systemd, which is runit).

Void also provides a fantastic independent package manager (xbps) for handling its repos. And when I say 'independent' I also mean that Void provides statically compiled versions of xbps that has no external dependencies and can thus be run from any distro (though mixing package managers is probably not a great idea since neither used will be then able to keep track of what is installed). It is no accident, therefore, that I adopted xbps as the package manager on my first WeeDogLinux creations, since the philosophy of WDL was to start from a core consisting simply of busybox (or similar) and a standalone package manager (there is no standalone package manager for Debian or Ubuntu, so I've had to resort to debootstrap for WDL variants of these, and similarly for WDL Arch though it may be possible to make a static pacman build). WDL Void is generally used to build a frugal install version of Void Linux thereafter, but it doesn't actually need to do that, and in simplest mode actually uses SysVInit via its simple busybox implementation plus a simply SysVinit initial init script provided by WDL - that way WDL Void could be used to build absolutely tiny distros according to whatever plugin design is made for them. Generally though, I do not use that initial default SysVinit capability but immediately let Void xbps install their terrific runit alternative instead (as a 32 bit or 64 bit system).

So that is my feeling/recommendation when it comes to keeping 32bit systems alive. Debian certainly remains another alternative, which has the biggest repos of course. I'd say that Void runs more efficiently (which is of significance importance on old low-powered 32bit machines of course) and huge repos of Debian maybe not such an advantage on such old machines which will be limited in their abilities to run some apps anyway (and you can always compile your own for Void; Puppy style..., though Void repos are actually quite big anyway so most all popular apps are available by default). Best choice longterm will depend on their continuing support of course.

BTW, Void Linux official installation is only a full install as far as I remember. It is not because I created WeeDogLinux Void version that I would recomment it if you want to try Void Linux. The main reason is that WDL is a frugal install distro providing save persistence facilities somewhat similar to Puppy (though the grub boot lines are different for WDL as is the overlay system and modes; WeeDog uses overlayfs rather than aufs). Also, Void Linux official full install installation is somewhat tricky (at least I had some troubles doing it - took me several attempts), whereas installing WDL is simply a matter of running its build scripts (waiting patiently till installation is complete) and then adding appropriate boot lines to grub menu. I haven't myself produced much of a full desktop version of WDL Void as yet (I've only made WDL Arch64 and WDL Slitaz) but rockedge has provided some build scripts for WDL Void that use JWM and ROX along with additional scripts for creating a full Zoneminder for his implementation (video surveillance system - which rockedge's WDL plugin build script auto-compiles for Void use):

https://weedoglinux.rockedge.org/viewto ... p=299#p299

I believe that will work on 32 bit or 64 bits WDL Void version.

wiak

[wiak]

There is a pretty good review of Void Linux (32bit or 64bit) itself here:

https://linuxinsider.com/story/void-lin ... 85703.html

That review is 2 years old, but Void Linux is a rolling release system so the review remains pretty much current - once you have Void working to your satisfaction you have no more worries about future versions - you can upgrade any or all of its packages and kernel any time you wish... (or lock in any package versions you don't want upgraded).

Actually, in my own opinion, there would be no better future for Puppy Linux than to adopt Void Linux package manager xbps as its core/default package management system. Please refer to following link for my reasoning behind that:

viewtopic.php?p=9555#p9555

wiak

[rockedge]

@wiak I just have been trying to run a build of WeeDog32-Void then a 64 bit version. I've encountered a certificate problem! I think we've run in to it before. So the script is ending with errors.

I am working on adding the auto menu build and a fixmenu tool to the plug files

• firstrib00-32-auto.plug

• firstrib00-64-auto.plug

Code: Select all

./build_firstrib_rootfs_104.sh void rolling i386 firstrib00-32-auto.plug

and:

Code: Select all

./build_firstrib_rootfs_104.sh void rolling amd64 firstrib00-64-auto.plug

Screenshot(10).png (99.29 KiB) Viewed 600 times

[wiak]

@wiak I just have been trying to run a build of WeeDog32-Void then a 64 bit version. I've encountered a certificate problem! I think we've run in to it before. So the script is ending with errors.

Hmmm, been a while since I built a WDL Void. Your Zoneminder work is a good time for me to take a look. Yes, I remember that problem cropped up - alas I've forgotten the details and can't find a note on it. I have a feeling I simply provided an update initial certs file to fix it (but knew that was only a temporary fix until such time as a better permanent solution could be found). For a first stab I'll probably try and create that temporary fix again (if that initial ssl certs file is indeed the issue) but good to be reminded that for Void builds a stable fix needs to be found.

Won't be today or tomorrow but will report back soon as I can (hopefully within a week) once Void builds working for me.

EDIT: Maybe the certs are not the issue??? I notice from your screenshot that the build says it cannot find the file:

https://alpha.de.repo.voidlinux.org/cur ... l-repodata

I manually used my browser to look in https://alpha.de.repo.voidlinux.org/current/nonfree

There is no x86_64-musl-repodata in there; only x86_64-repodata, which seems to have been updated recently (9 Nov 2020). Maybe the musl version is still in build process so not added back into the Void repo yet? EDIT2: Ah, sorry, it is probably in https://alpha.de.repo.voidlinux.org/current/ rather than nonfree; I can't check that in my browser - I'll try quickly with wget.

EDIT3: No, unless I made some daft mistake, it didn't work (wasn't there) to manually run from a terminal:

wget -c https://alpha.de.repo.voidlinux.org/cur ... l-repodata

x86_64-repodata was there though, so looks like a x86_64-musl-repodata upstream file omission rather than a WDL Void build issue(?)

I haven't tried musl builds before really so found that unexpected anyway.

wiak

[wiak]

I should answer on WeeDog forum but since posting above I'll just continue here for now.

I just tried:

./build_firstrib_rootfs-latest.sh void rolling amd64 f_00_Void_noarch_noXsimple00_wiak-rc1.plug

and that seems to be working fine (I believe it is using x86_64-repodata and not looking for musl variant.

The f_00... plugin above is from post here:

https://weedoglinux.rockedge.org/viewto ... p=271#p271

Are you using musl via your own plugin?

[wiak]

By the way, I cannot find these build firstrib plugin files you mention:

firstrib00-32-auto.plug

firstrib00-64-auto.plug

EDIT: The really weird thing is that I am not getting these sslcerts.tar.xz errors you get. My attempt is having no raw.githubusercontent.com

Perhaps I fixed something earlier and the fix is in build_firstrib_rootfs-latest.sh, which is Build_firstrib_rootfs_208 (version="2.0.8"; revision="-rc7). You are using a very old build script so I first suggest you use the latest, which is available from here:

https://gitlab.com/weedog/weedoglinux/- ... ild_latest

This is the line in the build script that downloads the sslcerts, and it works for me in a terminal and in actual build:

Code: Select all

wget -c https://gitlab.com/weedog/weedoglinux/-/raw/master/build_resources/sslcerts.tar.xz

I'm running the commands from my WeeDogLinux Arch64 system and not sure if something not working from system you are running on, though I doubt different host system would be an issue (unless trying to do 64 bit build from a 32 bit system - that wouldn't work).

The only thing I'm wondering about is if that command to fetch from gitlab is really correct. It is working for me, but I'm not sure if gitlab has put some cookie on my system that is allowing that method to work (gitlab talks about an 'access token'; I've never taken the time to figure that out). I'd need to try same from a clean system to make sure that command universally works, unless you can prove it works or otherwise more generally... I remember reading on gitlab the official notes on how to download single files from there, and it was admittedly not so simple... but for some reason the above did work for me... This doesn't effect Arch builds I think, since not using sslcerts like that I think. Maybe everything is working from my computer, but for no one else though... that would be sad!!! However, being a public repo, I 'think' I do not need to provide any access token so simple command above thus works... please let me know.

[rockedge]

firstrib00-32-auto.plug
firstrib00-64-auto.plug

Are here: https://github.com/techrockedge/weedog-ZM

I am going to use the latest version, about 3 weeks ago I ran these scripts and they worked still!

[wiak]

firstrib00-32-auto.plug
firstrib00-64-auto.plug

Are here: https://github.com/techrockedge/weedog-ZM

I am going to use the latest version, about 3 weeks ago I ran these scripts and they worked still!

That is amazing, but I can't remember what is inside the older scripts now - no idea why they worked so recently but not now. Let's hope the latest works for you. I think you gave me that github weedog-ZM link before, but I forgot... oops. I'll try the plugins from there this week since I really want a zoneminder server running for my wife's business office security - anyway, I've always meant to become familiar with zoneminder (from many years back when I was experimenting with the much less sophisticated 'Motion' surveillance program).