That's a ton of ram for a pIII

Puppy was the first Linux distro I ever tried since it was such a small download (250ish MB) and I had limited bandwidth. Good memories.

I tried a handful of small distros in order to give new life to an old laptop with an AMD C-50 and 2GB of RAM.

The most responsive one, unexpectedly, was Raspberry Pi OS.

> I also like SliTaz

thank you for this reminder! I had completely forgotten about SliTaz, looks like I need to check it out again!

"Tiny Core Linux has a version for Raspberry Pis called piCore [0] that I wish more people would look at, because it loads itself entirely into RAM and does not touch the SD card at all after that until and unless you explicitly tell it to."

Before RPI existed, I always made filesystem images for USB sticks in NetBSD so that writes never touched "disk" ("diskless"). This allows me to remove the USB stick after boot, freeing up the slot for something else

BSD "install images" work this way

I have been using the RPi with a diskless NetBSD image since around 2012; there are no SD card writes, the userland is extracted into RAM

I can pull out the SD card after boot and use the slot for something else

If I want data storage, I connect an external drive

It's been wild to read endless online complaints from so-called "technical" RPi users for the last 13 years about SD card wear and tear

To me, it's another example of how it's possible to have a solution that is as old as the hills and have it be completely ignored in favor of a "modern" approach that is fatally-flawed

Alpine also has a lesser known RPi build on their download page; by using musl instead of glibc the difference in size and resources used compared to regular distros is huge as well. https://alpinelinux.org/downloads/

"Phenomenal for those low powered servers you just want to leave on and running some tiny batch of cronjobs [1] or something for months or years at a time without worrying too much about wear on the SD card itself rendering the whole installation moot."

Yes, this is exactly what I want, except I need some simple node servers running, which is not so ultra light. Would you happen to know, if this still all works within the ram out of box, or does this require extra work?

Wondering if it would be a good idea to setup a VM with this. Setup remote connection, and intellij. Just have a script to clone it for a new project and connect from anywhere using a remote app.

It will increase the size of the VM but the template would be smaller than a full blown OS

Aside from dev containers, what are other options? I'm not able to run intellij on my laptop, is not an option

I use Nvim to ssh into my computer to work, which is fine. But really miss the full capacity of intellij

Wow, Slax is still around and supports Debian now too? Thanks for sharing.

> puppy Linux, which I could never get into

In what way? Do you mean you didn't get the chance to use it much, or something about it you couldn't abide?

There is (at least) two different groups of people using Raspberry PI. One of them are completely new Linux users who need a ton of help and resources to understand enough so they can achieve what they're trying to do. Raspbian/Raspberry Pi OS, even with their faults, is probably the better option for those people, as the environment and context very much takes first time users into account.

NetBSD and Tiny Core Linux, even with all their benefits, is a harder experience to get into if you haven't already dipped your toes into Linux, and doesn't have the same wide community and boundless online resources.

I recently put Alpine with i3 on a Raspberry Pi 4 Model B and I'm super impressed with how snappy it is. I find it much better even than Raspberry Pi OS Lite.

on a pi?

You can run nodejs fine on a pi with "Raspberry Pi OS Lite". In the configs, look for "Overlay File System" and enable it on the boot partition and main partition. The pi will boot from the sd card and run entirely in ram.

Be sure to run something to clear your logs occasionally or reboot once in a while or you'll run out of RAM. Still, get a quality sd card and power supply. You can get years out of a setup like this.

moonlight / sunshine might work if you can't run it locally.

It'd be best with hardwired network though.

I used to use it during the netbook era, was great for that.

No I tried to use it but it didn't click with me. I had it on cd but I'd normally reach for something else.

"640k ought to be enough for everyone!"

When I first started using QNX back in 1987/88 it was distributed on a couple of 1.4MB floppy diskettes! And you could install a graphical desktop that was a 40KB distribution!

> Or 128K of ram and 400 kb disk for that matter.

Or 32K of RAM and 64KB disk for that matter.

What's your point? That the industry and what's commonly available gets bigger?

yeah but what can you do with free QNX? With tinycore, you can install many packages. What packages exist for QNX?

I used to have a floppy and a mini-cd boot version of these. The mini-cd looks like a credit card and fit into a standard size cd drive. Reading the history of the project is a bit of a bummer, but still love the project ethos.

I mean - DOS or it's equivalents still exist and for older computers you will probably be able to find drivers.

Ideas to decrease risk of MITM:

Download from at least one more location (like some AWS/GCP instance) and checksum.

Download from the Internet Archive and checksum:

https://web.archive.org/web/20250000000000*/http://www.tinyc...

Ive experimented with several small distros for this when doing cross platform development.

In my experience, by the time you’re compiling and running code and installing dev dependencies on the remote machine, the size of the base OS isn’t a concern. I gained nothing from using smaller distros but lost a lot of time dealing with little issues and incompatibilities.

This won’t win me any hacker points, but now if I need a remote graphical Linux VM I go straight for the latest Ubuntu and call it day. Then I can get to work on my code and not chasing my tail with all of the little quirks that appear from using less popular distros.

The small distros have their place for specific use cases, especially automation, testing, or other things that need to scale. For one-offs where you’re already going to be installing a lot of other things and doing resource intensive work, it’s a safer bet to go with a popular full-size distro so you can focus on what matters.

Isn’t this what GitHub remote envs are (or whatever they call it)?

Never really got what it’s for.

wondering what's your typical usage for those small distros?

A single 1920x1080 framebuffer (which is a low resolution monitor in 2025 IMO) is 2MB. Add any compositing into the mix for multi window displays and it literally doesn’t fit in memory.

The Acorn Archimedes had the whole OS on a 512KB ROM.

That said, OSs came with a lot less stuff then.

Yea, but those platforms were not 64bit

I would like to have this again

I prefer to use additional RAM and disk for data not code

With 320x240 pixels and 256 colors

> QNX had a "free as in beer" distro that fit on a floppy, with Xwindows and modem drivers.

I don’t think that had the X Windows system. https://web.archive.org/web/19991128112050/http://www.qnx.co... and https://marc.info/?l=freebsd-chat&m=103030933111004 confirm that. It ran the Photon microGUI Windowing System (https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx....)

I never understood how that QNX desktop didn't pick up instanntly, it was amazing !

That famous QNX boot disk was the first thing I thought of when reading the title as well.

Similar situation here. Have some old 32bit machines that I'm turning into writer decks. Most Linux distros have left 32bit behind so you can't just use Debian or Ubuntu and a lot of distros that aim to run on lower hardware are Ubuntu derivatives

Not foolproof. Could compute MD5 or SHA256 after downloading.

Because there's big demand to mitm users of an extremely small and limited distribution from 2008?

Valid points, completely forgot about that part, and even with installation script, I manage to waste a good amount of time downloading and setting things up.

Question, I use VirtualBox, but I feel it's kind a laggy sometimes, What do you use? Any suggestion on performance improvements?

To really hammer this home: Alpine uses musl instead of glibc for the C standard library. This has caused me all types of trouble in unexpected places.

I'm all for suggestions for a better base OS in small docker containers, mostly to run nginx, php, postgress, mysql, redis, and python.

JetBrains has Gateway which allows connecting to a remote instance and work on it.

> and only 16-bit color (4 bits per pixel).

The "high color" (16 bit) mode was 5:6:5 bits per channel, so 16 bits per pixel.

> So 153,600 bytes for the frame buffer.

And so you're looking at 614.4 KB (600 KiB) instead.

640 * 480 / 2 = 150KB for a classic 16-color VGA screen.

You’re assuming a discrete GPU with separate VRAM, and only supporting hardware accelerated rendering. If you have that you almost certainly have more than 2MB of ram

VGA standard supports up to 256k

Aren’t you cheating by having additional ram dedicated for gpu use exclusively? :)

There’s an installation option to run apps off disk. It’s called “The Mount Mode of Operation: TCE/Install”.

640x480 with 16 colours was standard in offices in the late 80s.

If you were someone special, you got 1024x768.

Somebody has build it: https://membarrier.wordpress.com/2017/04/12/qnx-7-desktop/

because it's not free and their aim was at developers and the embedded space. How many people have even heard of QNX?

Thank you once more!

With CorePlus, you have the the choice of some 10 GUI environments. I prefer openbox or jwm.

Exactly.

I know that not everybody spent 10 years fiddling with CSS so I can understand why a project might have a skill gap with regards to aesthetics. I'm not trying to judge their overall competence, just wanted to say that there are so many quick wins in the design it hurts me a bit to see it. And due to nature of open source projects I was talking about "empowering" a designer to improve it because oftentimes you submit a PR for aesthetic improvements and then notice that the project leaders don't care about these things, which is sad.

I was just thinking today how I miss my DSL (Damn Small Linux) setup. A Pentium 2 Dell laptop, booted from mini-CD, usb drive for persistence. It ran a decent "dumb" terminal, X3270, and stripped down browser (dillo I believe). Was fine for a good chunk of my work day.

a 320x200 6bit color depth wasn't exactly a pleasure to use. I think the games could double the res in certain mode (was it called 13h?)

To put it in GPU RAM, you need GPU drivers.

For example, NVIDIA GPU drivers are typically around 800M-1.5G.

That math actually goes wildly in the opposite direction for an optimization argument.

Computers didn't used to have GPUs back then when 150kB was a significant amount of graphics memory.

To think that the entire distro would fit in a reasonable LLC (last level cache)..

Licensing, and QNX missed a consumer launch window by around 17 years.

Some businesses stick with markets they know, as non-retail customer revenue is less volatile. If you enter the consumer markets, there are always 30k irrational competitors (likely with 1000X the capital) that will go bankrupt trying to undercut the market.

It is a decision all CEO must make eventually. Best of luck =3

"The Rules for Rulers: How All Leaders Stay in Power"

https://www.youtube.com/watch?v=rStL7niR7gs

Me too! And the GUI was only a 40KB distribution and was waaaaaay better than Windows 3.0!

Same situation but I'm using NetBSD instead. I'm betting it'll still be supporting 32-bit x86 long after the linux kernel drops it.

And compare it against what?

EDIT: nevermind, I see that it has the md5 in a text file here: http://www.tinycorelinux.net/16.x/x86/release/

I swear to god. Won't somebody think of the yaks.

It was GUI defined manually by pixel coordinates, having more flexible guis that could autoscale and other snazy things made things really "slow" back then..

Sure we could go back... Maybe we should. But there are lots of stuff we take for granted to day that were not available back then.

How about debian-slim?

Yes, but it requires JetBrain running on the client too.

I ran it on a Via single board computer, a tiny board that sipped power and was still more than beefy enough to do real time control of 3 axis stepper motors and maintain a connection to the outside world. I cheated a bit by disabling interrupts during time critical sections and re-enabling the devices afterwards took some figuring out but overall the system was extremely reliable. I used it to cut up to 1/4" steel sheet for the windmill (it would cut up to 1" but then the kerf would be quite ugly), as well as much thinner sheet for the laminations. The latter was quite problematic because it tended to warp up towards the cutter nozzle while cutting and that would short out the arc. In the end we measured the voltage across the arc and then automatically had the nozzle back off in case of warping, which worked quite well, the resulting inaccuracies were very minor.

https://jacquesmattheij.com/dscn3995.jpg

For OCS/ECS hardware 2bit HiRes - 640x256 or 640x200 depending on region - was default resolution for OS, and you could add interlacing or up color depth to 3 and 4 bit at cost of response lag; starting with OS2.0 the resolution setting was basically limited by chip memory and what your output device could actually display. I got my 1200 to display crisp 1440x550 on my LCD by just sliding screen parameters to max on default display driver.

Games used either 320h or 640h resolutions, 4 bit or fake 5 bit known as HalfBrite, because it was basically 4 bit with the other 16 colors being same but half brightness. The fabled 12-bit HAM mode was also used, even in some games, even for interactive content, but it wasn't too often.

Someone last winter was asking for help with large docker images and it came about that it was for AI pipelines. The vast majority of the image was Nvidia binaries. That was wild. Horrifying, really. WTF is going on over there?

The IBM PGC (1984) was a discrete GPU with 320kB of RAM and slightly over 64kB of ROM.

The EGA (1984) and VGA (1987) could conceivably be considered a GPU although not turning complete. EGA had 64, 128, 192, or 256K and VGA 256K.

The 8514/A (1987) was Turing complete although it had 512kB. The Image Adapter/A (1989) was far more powerful, pretty much the first modern GPU as we know them and came with 1MB expandable to 3MB.

You might be thinking of DOS mode 13h, which was VGA 320x200, 8 bits per pixel.

Doesn't the UEFI firmware map a GPU framebuffer into the main address space "for free" so you can easily poke raw pixels over the bus? Then again the UEFI FB is only single-buffered, so if you rely on that in lieu of full-fat GPU drivers then you'd probably want to layer some CPU framebuffers on top anyway.

> NVIDIA GPU drivers are typically around 800M-1.5G.

They also pack in a lot of game-specific optimizations for whatever reason. Could likely be a lot smaller without those.

And 6-bits per colour component.

i remember playing with mode 13h, writing little graphics programs with my turboc compiler. computers were so magical back then.

Yes if you have UEFI.

The only reason FOSS sometime works was because the replication cost is almost $0.

In *nix, most users had a rational self-interest to improve the platform. "All software is terrible, but some of it is useful." =3

There is also the option by well written professional wherer the startergy is to grab as much market share as they can by allowing the proliferation of their product to lockup market/mindshare and rleaget the $ enforcement for later - successfully used by MSWindows for the longest time and Photoshop .

Conversly i remenber Maya or Autodesk used to have a bounty program for whoever would turn in people using unlicensed/cracked versions of their product.Meanwhile Blender (from a commercial past) kept their free nature and have connsistently grown in popularity and quality without any such overtures.

Of course nowadays with Saas everything get segmented into wierd verticals and revenue upsells are across the board with the first hit usually also being free.

There is a secure domain to download from as a mirror. For extra high security, the hash should be delivered OOB like on a mailing list but it isn’t

An integrity check is better than nothing, but yes it says nothing about its authenticity.

As a business, dealing with Microsoft and Oracle is not a clean transactional sale.

They turned into legal-service-firms along the way, and stopped real software development/risk at some point in 2004.

These firms have been selling the same product for decades. Yet once they get their hooks into a business, few survive the incurred variable costs of the 3000lb mosquito. =3

well, if you poke framebuffer pixels directly you might as well do scanline racing.

Even the open source drivers without those hacks are massive. Each type of card has its own almost 100MB of firmware that runs on the card on Nvidia.

It’s not better than nothing - it’s arguably worse.

Alas, I don't think UEFI exposes vblank/hblank interrupts so you'd just have to YOLO the timing.

That's 100MB of RISC-V code, believe it or not, despite Nvidias ARM fixation.

You can use this site https://distro.ibiblio.org/tinycorelinux/downloads.html

And all the files are here https://distro.ibiblio.org/tinycorelinux/16.x/x86/release/

I posted that above in this thread.

I will add that most places, forums, sites don’t deliver the hash OOB. Unless you mean like GPG but that would have came from same site. For example if you download a Packer plugin from GitHub, files and hash all comes from same site.

Is that actually tiny core? It’s _likely_ it is, but that’s not good enough.

> this same thing came up a few years ago

Honestly, that makes this inexcusable. There are numerous SSL providers available for free, and if that’s antithetical to them, they can use a self signed certificate and provide an alternative method of verification (e.g. via mailing list). The fact they don’t take this seriously means there is 0 chance I would install it!

Honestly, this is a great use for a blockchain…

It is better than nothing if you note it down. You can compare it later if somebody / or you was compromised to see whether you had the same download as everyone else.

I usually only install on like a Raspberry Pi or VM for these toy distros

Are any distros using block chain for this ?

I am used to using code signing with HSMs

Sorry but this is nonsense. It’s better than nothing if you proactively log the hashes before you need them, but it’s actively harmful for anyone wi downloads it after it’s compromised.

I’d install it as a VM maybe,

> are any sisters using blockchain

I don’t think so, but it’s always struck me as a good idea - it’s actual decentralised verification of a value that can be confirmed by multiple people independently without trusting anyone other than the signing key is secure.

> I am used to code signing with HSMs

Me too, but that requires distributing the public key securely which… is exactly where we started this!

"It is better than nothing" is literally what I said. But thinking about it more, I actually think is quite useful. Any kind of signature or out-of-band hash is also only good if the source is not compromised, but knowing after the fact whether you are affected or not is extremely valuable.