An idea for 32-bit system for old machines, input requested

greenjeans · 2025-04-09 17:02:18

So don't laugh at the ignorance of this ol coot, but I have an idea, and likely not a new one as i'm sure somebody is probably already doing something similar.

Thinking of making a 32 bit iso for older machines, as it seems 32 is going away soon. But I don't want to use modern/current 32 bit kernels and software for the most part. The problem is the new stuff is very heavy, and requires a lot more ram than it used to.

It's not an issue to use older software if it works, the only problem area is in the browser, as older versions of browsers suffer in the area of functionality (and security). But appimages are a solution for that, I have one working right now on a 2005 machine, that's using software from the archive repo for Jessie, and an appimage of FF.

But there is a potential security issue in using software that old, so my thought on dealing with that is, to make a system that uses a conventional filesystem for everything below /home, and a single read-only squashfs file for everything above it. That way even if a user screwed up while online and downloaded something bad, it wouldn't be able to change any system files.

I guess simply encrypting the whole file system would accomplish basically the same thing, but encryption comes with it's own set of challenges.

The kernel and all the rest from jessie in my old 32 bit iso, idles at about 98 mb of ram, so much lighter than current stuff, this is the crux of the matter, making it work on machines with only 512 mb of installed ram.

I just really don't know what's the best way, or if I can even do what I described above on just one partition without making separate ones for /home and for /.

Any input very welcome!

Camtaf · 2025-04-09 18:16:31

I think you want to check out some Puppy Linux distros they use compressed software....

greenjeans · 2025-04-09 19:13:16

Oh i'm aware, I used to be a user, actually have some isos still around here somewhere. But I think what i'm proposing is different, Puppy is all read-only with the potential for a persistence file, no real difference from a live-usb.

ralph.ronnquist · 2025-04-10 03:25:42

I'm not sure where the security angle is, but it all sounds like it could be a fun project. Of course there are few other filesystem points that need to be writeable for a working system. Most if not all could probably be set up tempfs.

steve_v · 2025-04-10 10:52:19

on just one partition without making separate ones for /home and for /.

Why? Separate partitions with / as r/o or squashfs and /home, /var as r/w or tmpfs is the obvious answer here, is it not?

Personally, I wouldn't use a debian-based distro for this. Security bugs in old software go way beyond just the browser, and by the time you find and fix/update all vulnerable packages (and rebuild the revdeps) you may as well have started from something more aligned with the "use modern software, and aggressively optimise for memory use" approach... Like TinyCore, or a custom build (gentoo, LFS, etc.) with uclibc-ng or musl, -Os, and minimal ~~feature-bloat~~ compile-time options.

Then again, I wouldn't bother with a 32bit machine as a general-purpose desktop to begin with. Used 64bit hardware is dirt-cheap now (Sandybridge/Ivybridge boxes can often be had for literally nothing), and modern browser engines kinda blow that 512MB memory target away all by themselves.

FWIW, TinyCore/Coreplus runs just fine on a Pentium 233 with 64Mb RAM. With 128MB, it's even pretty snappy... And it doesn't run decade-old software to achieve it.

Last edited by steve_v (2025-04-10 11:04:59)

greenjeans · 2025-04-10 14:10:35

I'm aware of tiny-core, have messed with it a lot over the years. I don't want to use it. I want to make this thing using Devuan.

@RRQ- Security is probably not even much of an issue for people who might use this, I started to just update the 32-bit system I already have with a 32-bit appimage of a browser, but then I started wondering about making the whole thing more secure and of course live-CD/DVD/USB popped into my head and that would probably be the simplest and most secure. But many old machines won't boot from USB, and having to rely on an old optical drive to boot and run every day may not pan out well in the end.

I've had multiple people ask me to build a new 32-bit Vuu-do, and I have some 32 bit machines down at the library and a printer-scanner i'd like to resurrect.

I'm not targeting anything below 512 mb of ram, that's for stuff like Tiny-core.

fsmithred · 2025-04-10 18:03:00

My 32-bit netbook thinks it's a good idea. It already has convinced me to work on a similar project. I merged it with my project to update my nodbus build, which turned out to be more difficult than expected. A bunch of stuff that used to install without dbus will no longer comply with such a restriction. That includes spacefm. I think xfe is the only graphical file manager that doesn't want dbus.

Anyway, if you want to look at any of what I've done, we can talk. If you do make one, I'm sure it'll be leaner than mine.

The real issue is the web browser. None of the big ones are fun to use with only 2G of memory. Falkon uses more than firefox which uses more than chromium. Hundreds of megabytes with one page open. Leave that out and you just eliminated a huge security risk.

Also regarding security - encrypted filesystems only work when the computer is turned off.

greenjeans · 2025-04-10 21:04:29

I have an appimage of FF esr on the 2005 machine (64-bit) with just one gig of ram, it will run one tab just fine, even up to 2-3 tabs, but if I open anymore or try to open another app while the browser is open, it bogs down and gets all swappy.

Wondering if the 32 bit version of FF would be any lighter on ram? Most 32 bit apps are.

Yeah the browser is the only fly in the ointment, otherwise i'd just make an updated 32 bit from that repo, with all the apps somebody might could use offline, I mean it all works fine, it's just the browser from that time that's not going to work right and may have bad security issues.

Re: security; I don't know that much about appimages, just the basics, but isn't an appimage already partially sandboxed? Especially if it's in userspace with no root privileges?

steve_v · 2025-04-11 04:56:28

isn't an appimage already partially sandboxed?

Appimages aren't sandboxed, they're essentially just a compressed directory with an executable header to handle the library path shenanigans. Nothing stopping you running one in firejail, bubblewrap, etc. like any other application though.
Flatpak and Snap do include sandboxing (of somewhat dubious effectiveness IMO), but that's a whole other kettle of fish.
Any "self-contained" or "unversal" package will likely use more memory (and definitely more disk) than a native package, due to shared-library duplication.

Last edited by steve_v (2025-04-11 05:12:11)

hacksenwerk · 2025-04-11 11:10:36

Just don't use flatpak:
https://flatkill.org/
https://flatkill.org/2020/

pcalvert · 2025-04-11 17:01:17

Take a look at this:

Package: bilibop-lockfs
https://packages.debian.org/stable/bilibop-lockfs

It's intended to be used for external media, but can probably be used for internal drives as well.

greenjeans · 2025-04-20 16:30:04

Did a test install yesterday, pulled out the last Vuu-do 32-bit mini I did in 2017 and installed on the computer while we were working on the library, only issue was it needed a newer version of e2fsck for some reason, but the two packages I needed to upgrade were in the archive repo and after installing those in the live session the install worked perfectly.

It idles at a whopping 85 mb of ram, lol, and that's with conky running which takes another 10-15 mb typically. Runs really fast on that old machine. I think re-building it and making a max version too will be very worthwhile. Going to test next with a 32-bit appimage of either FF or Chromium so as to have a modern browser that works.

I've got a lot of irons in the fire right now, so my time may be limited, what I really need to know is how much longer the Jessie repo at archive.devuan.org will be available?

If anybody knows that would be great, if it's to be shut down any time soon I might be able to shuffle my schedule around and get it done fast, otherwise if it's going to be up for a while i'd like to take my time and polish it up a fair bit.

delgado · 2025-04-20 19:04:30

I don't know the policy of archive.devuan.org, but snapshot.debian.org covers anything since lenny.

The officially official Devuan Forum!

#1 2025-04-09 17:02:18

An idea for 32-bit system for old machines, input requested

#2 2025-04-09 18:16:31

Re: An idea for 32-bit system for old machines, input requested

#3 2025-04-09 19:13:16

Re: An idea for 32-bit system for old machines, input requested

#4 2025-04-10 03:25:42

Re: An idea for 32-bit system for old machines, input requested

#5 2025-04-10 10:52:19

Re: An idea for 32-bit system for old machines, input requested

#6 2025-04-10 14:10:35

Re: An idea for 32-bit system for old machines, input requested

#7 2025-04-10 18:03:00

Re: An idea for 32-bit system for old machines, input requested

#8 2025-04-10 21:04:29

Re: An idea for 32-bit system for old machines, input requested

#9 2025-04-11 04:56:28

Re: An idea for 32-bit system for old machines, input requested

#10 2025-04-11 11:10:36

Re: An idea for 32-bit system for old machines, input requested

#11 2025-04-11 17:01:17

Re: An idea for 32-bit system for old machines, input requested

#12 2025-04-20 16:30:04

Re: An idea for 32-bit system for old machines, input requested

#13 2025-04-20 19:04:30

Re: An idea for 32-bit system for old machines, input requested

Board footer