alt.hn

12/6/2025 at 2:18:42 PM

Tiny Core Linux: a 23 MB Linux distro with graphical desktop

 http://www.tinycorelinux.net/

by LorenDB

12/6/2025 at 10:28:25 PM

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.

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.

This is actually how I have powered the backend data collection and processing for [2], as I wrote about in [3]. The end result is a static site built in Hugo but I was careful to pick parts I could safely leave to wheedle on their own for a long time.

[1]: https://til.andrew-quinn.me/posts/consider-the-cronslave/

[2]: https://hiandrewquinn.github.io/selkouutiset-archive/

[3]: https://til.andrew-quinn.me/posts/lessons-learned-from-2-yea...

by hiAndrewQuinn

12/7/2025 at 12:12:14 AM

"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

by 1vuio0pswjnm7

12/7/2025 at 5:46:46 AM

“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…”

A lot of the SD-card wear issues come from people running “normal PC workflows” on a storage medium that was never designed for that pattern.

Something I’ve seen help many newcomers is simply enabling an overlay filesystem or tmpfs-based writes. It’s basically the middle ground between a full RAM-boot distro (piCore, Alpine diskless, NetBSD) and a standard SD-based Raspberry Pi OS.

You still get the normal ecosystem and docs, but almost no writes hit the card unless you explicitly commit them.

For anyone stuck between “I want something simple” and “I don’t want my SD to die,” overlays are the easiest win.

by victorbuilds

12/7/2025 at 6:39:18 AM

Tesla rather famously had issues by writing logs to SD storage.

by SoftTalker

12/7/2025 at 1:15:34 AM

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.

by embedding-shape

12/7/2025 at 10:13:11 AM

I suspect the majority of "SD corruption" on RPis is due to bad power supplies or EMI causing the system to misbehave (and write erroneous data to the card) rather than actually exhausting the card's write capacity.

by Nextgrid

12/7/2025 at 11:16:23 AM

That's been my experience. The Pi 3 was notorious for killing SD cards, for instance. I know one guy who eventually just moved all Pi 3 installations he made over to USB sticks because every Pi 3 he used would just kill SD cards at random but far faster than they should have. Not many write cycles at all, just surged the cards or something.

by Firehawke

12/7/2025 at 8:05:30 PM

The point I'm making is not that NetBSD is a solution

The point I'm making is that putting the rootfs on a memory filesystem, e.g., tmpfs, mfs, etc. avoids the problem with SD cards^1

This can be done with a variety of operating systems. IMO, the advantange of the RPi hardware is that it is supported by so many different operating systems

When I want to run additional, larger programs that are not in the rootfs I have embedded into the kernel, I either (a) run them from external storage or (b) copy them to the mfs/tmpfs

It depends on how much RAM I have available

1. There are probably other ways to avoid the problem, too

by 1vuio0pswjnm7

12/7/2025 at 7:39:25 AM

I actually considered NetBSD for an old 32 bit box yesterday, so I'm somewhat wise to this world. My first experience with ramdisk operating systems was Puppy Linux back in the early 2010s. Ultimately I'm probably going with OpenBSD for that box.

But, NetBSD ISOs are much heavier than TCL ISOs, and so while I'm sure there's a way to get just what I want working in diskless mode, I'm not confident I will have any RAM to run what I actually want to run on top of it.

by hiAndrewQuinn

12/7/2025 at 7:11:32 PM

Puppy Linux was pretty sweet back then, I used it for a Gecko machine for a few years until I got a vastly more powerful 'flat' netbook that arrived after those. It was a pretty nice gadget, though one had to have small and/or flexible fingers or the keyboard would have been a pain.

https://www.digitalreviews.net/reviews/pc/norhtec-xcore-geck...

I've noticed Puppy is still around but I have no idea whether it can still be comparable to Tiny Core.

by cess11

12/7/2025 at 5:06:17 PM

Hi check this https://smolbsd.org/#about Also standard NetBSD ISO might not be useful do check platform specific images.

by jaypatelani

12/11/2025 at 6:26:56 AM

This is really cool!!!

by hiAndrewQuinn

12/7/2025 at 6:02:54 AM

What's the size of your "diskless" NetBSD installation, and how fast does it boot?

As compared to TC, the "out of the box" NetBSD images contain many things I wouldn't need, so customizing it has been a recurring thought, but oh well. The documentation and careful modularity is, obviously, a huge bonus of NetBSD in that regard (even an end-user like me could do some interesting modifications of the kernel solely by reading the manual). TC seems much more ad-hoc, but I assume this, too, is intentional, by design.

by marttt

12/8/2025 at 5:01:14 AM

In 2011, TCL was 10MB

Around that time the NetBSD kernels with embedded rootfs filesystem I was making were around 17MB

Today, TCL is 23MB

The NetBSD kernels with embedded rootfs I'm using today are around 33MB

That size can be reduced of course

I don't monitor the boot process on RPi with serial console, I only connect after tinysshd is running, so I don't pay close attention to boot speed. It's fast enough

TCL appears to be aimed at users that prefer a binary distribution; also it provides GUI by default

I prefer to compile from source and I only use textmode hence NetBSD is more suitable for me than TCL

For someone who does not want to compile anything from source, it is possible to "customise" (replace) the rootfs of a NetBSD install image with another rootfs. It is not documented anywhere that I'm aware of but I have done it many times

I use a very minimal userland. I guarantee few if any HN readers would be satisfied with it. If I need additional programs I either (a) mount an external drive and run the programs from external storage, e.g., via chroot, or (b) copy them from an external drive into mfs or tmpfs

It depends on how much RAM I have

by 1vuio0pswjnm7

12/7/2025 at 5:07:07 PM

Check this https://smolbsd.org/#about

by jaypatelani

12/7/2025 at 8:46:06 PM

This appears to be new to me. Very interesting, many thanks for sharing!

by marttt

12/7/2025 at 6:54:29 AM

I set up a similar system using NixOS, no writes to the disk by default.

Though I don't explicitly load the entire userspace into RAM, since this is a laptop and I don't foresee a need to remove the SSD after boot.

by ycombinatrix

12/7/2025 at 7:50:10 AM

Back in the day I believe I just installed the OS on a USB stick and used the SD card only to boot of that.

by jimvdv

12/6/2025 at 11:34:33 PM

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/

by squarefoot

12/7/2025 at 12:21:52 AM

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.

by Lyngbakr

12/7/2025 at 11:29:41 AM

Same here, I put it on two very old RPi 1 and was amazed at how low the footprint is. I wish there were images available for other SBCs as well, mostly Allwinner based ones (OrangePi, NanoPi, etc); probably I did something wrong but building them from scratch turned out more complicated than expected.

by squarefoot

12/8/2025 at 11:19:06 AM

Yep, Alpine works well. A GUI can be tricky, though. And none of the RasPi tools (e.g. `raspi-config`) will run because of the different libc.

So, running it on a Pi 5 CM in an IO board, there's no way to tell the Pi what device to boot from.

by lproven

12/7/2025 at 3:42:21 AM

I can vouch for it, I had an RPi that was translating a serial port to TCP/IP in a difficult to access location, and it stayed doing its duty for years, Alpine is very solid.

by jwrallie

12/7/2025 at 12:29:23 PM

Important to mention: Alpine can run from RAM like TinyCore

by blueflow

12/6/2025 at 11:02:32 PM

"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?

by lukan

12/7/2025 at 2:52:06 AM

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.

by fsagx

12/7/2025 at 7:30:53 AM

To my understanding TCL expects the RAM-only / diskless case unless you put in a lot of extra work not to do that. In your situation the only thing you would have to really be worried about is whether 4 GB of RAM or whatever you have is enough to fit TCL and the files for your node server and the actual programs you are trying to run with all that. It doesn't get pretty once you exceed your available RAM, be forewarned - but that's true of all programs in a sense.

by hiAndrewQuinn

12/6/2025 at 4:04:37 PM

I've used many of these small Linux distros. I used to have Tiny Core in a VM for different things.

I also like SliTaz: http://slitaz.org/en, and Slax too: https://www.slax.org/

Oh and puppy Linux, which I could never get into but was good for live CDs: https://puppylinux-woof-ce.github.io/

And there's also Alpine too.

by ifh-hn

12/6/2025 at 4:57:42 PM

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.

by LorenDB

12/6/2025 at 8:54:29 PM

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.

by forinti

12/8/2025 at 11:14:20 AM

Yep. PiOS Desktop (for x86) was a superb very-lightweight distro.

I carefully put a fairly minimal Xfce setup on it instead of LXDE and RAM usage doubled. It's impressively hand crafted and pruned.

Sadly, though, it hasn't been updated since Debian 11.

by lproven

12/6/2025 at 6:10:54 PM

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

by t_mahmood

12/6/2025 at 7:45:20 PM

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.

by Aurornis

12/6/2025 at 8:41:36 PM

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.

by dotancohen

12/7/2025 at 4:01:12 AM 

    > Alpine uses musl instead of glibc for the C standard library. This has caused me all types of trouble in unexpected places.
I have no experience with alternative C libs. Can you share some example issues?

by throwaway2037

12/8/2025 at 11:17:42 AM

> I have no experience with alternative C libs. Can you share some example issues?

No precompiled Linux stuff runs. No Chrome, no 3rd party Electron apps work unless specifically ported. For me, no Slack, no Panwriter, no Ferdium.

Flatpak works, sort of, with restrictions. Snap doesn't.

by lproven

12/6/2025 at 11:16:48 PM

How about debian-slim?

by autotune

12/7/2025 at 8:51:30 AM

I actually have used that, thank you. Excellent choice.

by dotancohen

12/6/2025 at 10:57:22 PM

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?

by t_mahmood

12/7/2025 at 9:51:50 PM

Is docker valid for your use case?

by dotancohen

12/8/2025 at 11:53:55 PM

Docker to start IntelliJ and access remotely from my Laptop, will have to tunnel. Hm, I should give this a try. I was not sure if Docker+GUI goes well.

by t_mahmood

12/6/2025 at 6:35:31 PM

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

Never really got what it’s for.

by ornornor

12/6/2025 at 6:48:58 PM

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

by rovr138

12/6/2025 at 7:10:47 PM

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

by t_mahmood

12/6/2025 at 7:26:05 PM

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

It'd be best with hardwired network though.

by silasb

12/6/2025 at 4:42:47 PM

> I also like SliTaz

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

by hdb2

12/6/2025 at 4:39:39 PM

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

by samtheprogram

12/6/2025 at 4:55:35 PM

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

by projektfu

12/6/2025 at 6:25:39 PM

> 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?

by sundarurfriend

12/6/2025 at 9:33:49 PM

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.

by ifh-hn

12/6/2025 at 4:57:30 PM

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

by dayeye2006

12/6/2025 at 8:57:46 PM

I like using old hardware, and Tiny Core was my daily driver for 5+ years on a Thinkpad T42 (died recently) and Dell Mini 9 (still working). I tried other distros on those machines, but eventually always came back to TC. RAM-booting makes the system fast and quiet on that 15+ years old iron, and I loved how easy it was to hand-tailor the OS - e.g. the packages loaded during boot are simply listed in a single flat file (onboot.lst).

I used both the FLTK desktop (including my all-time favorite web browser, Dillo, which was fine for most sites up to about 2018 or so) and the text-only mode. TC repos are not bad at all, but building your own TC/squashfs packages will probably become second nature over time.

I can also confirm that a handful of lenghty, long-form radio programs (a somewhat "landmark" show) for my Tiny Country's public broadcasting are produced -- and, in some cases, even recorded -- on either a Dell Mini 9 or a Thinkpad T42 and Tiny Core Linux, using the (now obsolete?) Non DAW or Reaper via Wine. It was always fun to think about this: here I am, producing/recording audio for Public Broadcasting on a 13+ year old T42 or a 10 year old Dell Mini netbook bought for 20€ and 5€ (!) respectively, whereas other folks accomplish the exact same thing with a 2000€ MacBook Pro.

It's a nice distro for weirdos and fringe "because I can" people, I guess. Well thought out. Not very far from "a Linux that fits inside a single person's head". Full respect to the devs for their quiet consistency - no "revolutionary" updates or paradigm shifts, just keeping the system working, year after year. (FLTK in 2025? Why not? It does have its charm!) This looks to be quite similar to the maintenance philosophy of the BSDs. And, next to TC, even NetBSD feels "bloated" :) -- even though it would obviously be nice to have BSD Handbook level documentation for TC; then again, the scope/goal of the two projects is maybe too different, so no big deal. The Corebook [1] is still a good overview of the system -- no idea how up-to-date it is, though.

All in all, an interesting distro that may "grow on you".

1: http://www.tinycorelinux.net/book.html

by marttt

12/6/2025 at 7:17:23 PM

In college I used a Slax (version 6 IIRC) SD card for schoolwork. I did my work across various junk laptops, a gaming PC, and lab computers, so it gave me consistency across all of those.

Booting a dedicated, tiny OS with no distractions helped me focus. Plus since the home directory was a FAT32 partition, I could access all my files on any machine without having to boot. A feature I used a lot when printing assignments at the library.

by hamdingers

12/7/2025 at 3:47:18 AM

Slax is cool, it used to fit a mini cd, so it was easy to carry around and boot and backup files from machines that refused to boot by themselves.

by jwrallie

12/6/2025 at 9:27:33 PM

All sorts. Having a full bootable OS on a CD or USB was always cool. When I left the military and was a security I used to use them to boot computers in the buildings I worked in so I could browse the internet.

Before encryption by default, get files from windows for family when they messed up their computers. Or change the passwords.

Before browser profiles and containers I used them in VMs for different things like banning, shopping, etc.

Down to your imagination really.

Not too mention just to play around with them too.

by ifh-hn

12/6/2025 at 5:02:20 PM

They can be nice for running low footprint VMs (e.g. in LXD / Incus) where you don't want to use a container. Alpine in particular is popular for this. The downside is there are sometimes compatibility issues where packages expect certain dependencies that Alpine doesn't provide.

by jbstack

12/6/2025 at 7:07:53 PM

I used DSL for the control of a homebrew 8' x 4' CNC plasmacutter.

by jacquesm

12/6/2025 at 7:35:20 PM

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.

by ja27

12/6/2025 at 7:46:24 PM

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

by jacquesm

12/6/2025 at 3:15:32 PM

Not to disrespect this, but it used to be entirely normal to have a GUI environment on a machine with 2MB of RAM and a 40MB disk.

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

by trollbridge

12/6/2025 at 3:26:34 PM

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.

by maccard

12/6/2025 at 4:38:57 PM

I had a 386 PC with 4MB of RAM when I was a kid, and it ran Windows 3.1 with a GUI, but that also had a VGA display at 640x480, and only 16-bit color (4 bits per pixel). So 153,600 bytes for the frame buffer.

by snek_case

12/7/2025 at 2:38:58 AM

> 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.

by perching_aix

12/7/2025 at 11:36:27 AM

"Windows 3.1 primarily used palette-based color modes, common modes included 16 colors (VGA/EGA) and 256 colors (SuperVGA)"

by snek_case

12/7/2025 at 11:58:25 AM

Right, so 16 color, not 16 bit color.

To be frank, I wasn't aware such a mode was a thing, but it makes sense.

by perching_aix

12/7/2025 at 7:54:34 PM

I recently installed NT4 (including Plus!) in an emulator with a VESA video driver, and was greatly surprised when about half of the icons that I thought of as “Windows 2000” (including the memorable “My Computer” one with the bulbous sky-blue screen) turned out to be available even there, provided a non-indexed mode. The rest were the more familliar 16-color-compatible 95/NT4 ones, making for an incongruous result overall. I guess what I want to say is that 16-color compatibility is a large part of the 95/NT4 look from which 2000 very carefully departed.

by mananaysiempre

12/6/2025 at 4:40:15 PM

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

by Dwedit

12/6/2025 at 8:31:46 PM

The Amiga 500 had high res graphics (or high color graphics … but not on the same scanline), multitasking, 15 bit sound (with a lot of work - the hardware had 4 channels of 8 bit DACs but a 6-bit volume, so …)

In 1985, and with 512K of RAM. It was very usable for work.

by beagle3

12/6/2025 at 8:41:06 PM

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?)

by mrits

12/6/2025 at 9:04:32 PM

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.

by krige

12/6/2025 at 10:14:32 PM

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

by teamonkey

12/6/2025 at 11:31:21 PM

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

by globalnode

12/6/2025 at 11:14:09 PM

And 6-bits per colour component.

by bananaboy

12/7/2025 at 4:15:13 PM

VGA color palette was 18-bits/256K, but input into the palette was 8-bit per channel. (63,63,63) is visibly different from (255,255,255).

http://qzx.com/pc-gpe/tut2.txt

http://qzx.com/pc-gpe/

by oso2k

12/8/2025 at 10:44:12 AM

Sorry I'm not exactly sure what you're saying. I know very well how it works as I write a lot of demos and games (still today) for mode 13h (see https://www.pouet.net/groups.php?which=1217&order=release) and I can program the VGA DAC palette in my sleep. Were you referring to the fact that you write 8-bits to the palette registers? That's true, you do, but only 6-bits is actually used so it effectively wraps around at 64. There are 6-bits per colour component which as you pointed out is 18-bits colour depth.

Btw I was a teenager when those Denthor trainers came out and I read them all, I loved them! They taught me a lot!

by bananaboy

12/6/2025 at 4:58:19 PM

It's so much fun working with systems with more pixels than ram though. Manually interleaving interrupts. What joy.

by bobmcnamara

12/7/2025 at 1:39:08 PM

If you use a tile-based hardware renderer, such as on the original nintendo chip, then pixels are rendered on the fly to the screen by the hardware automatically pulling pixels based on the tile map.

by em3rgent0rdr

12/7/2025 at 2:29:29 AM

More like 6.2+ MB, or at least I'd sure hope that a FHD resolution is paired with at least a 24 bit (8 bpc) SDR color. And then there's the triple buffered vsync at play, so it's really more like 18.6+ MB.

by perching_aix

12/7/2025 at 6:15:07 AM

My video card then didn’t have video ram for 256 color SVGA…

by BobbyTables2

12/7/2025 at 6:41:14 AM

Those old computers were 640x480 or so. Maybe smaller.

by SoftTalker

12/6/2025 at 3:40:33 PM

Do you really need the framebuffer in RAM? Wouldn't that be entirely in the GPU RAM?

by echoangle

12/6/2025 at 3:51:07 PM

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.

by jerrythegerbil

12/6/2025 at 4:17:35 PM

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.

by jsheard

12/6/2025 at 5:01:11 PM

Yes if you have UEFI.

by throwaway173738

12/6/2025 at 4:48:11 PM

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

by the8472

12/6/2025 at 5:04:52 PM

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

by jsheard

12/6/2025 at 4:01:01 PM

> 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.

by Rohansi

12/6/2025 at 4:10:59 PM

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.

by monocasa

12/6/2025 at 5:15:26 PM

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

by jsheard

12/6/2025 at 7:36:27 PM

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?

by hinkley

12/6/2025 at 5:28:43 PM

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

by maccard

12/6/2025 at 3:47:55 PM

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

by znpy

12/6/2025 at 5:29:57 PM

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

by ErroneousBosh

12/6/2025 at 10:55:44 PM

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.

by trollbridge

12/7/2025 at 10:07:46 AM

Neither EGA or VGA were "GPUs", they were dumb framebuffers. Later VGA chipsets had rudimentary acceleration, basically just blitters - but that was a help.

The PGC was kind of a GPU if you squint a bit. It didn't work the way a modern GPU does where you've got masses of individual compute cores working on the same problem, but it did have a processor roughly as fast as the host processor that you could offload simple drawing tasks to. It couldn't do 3D stuff like what we'd call a GPU today does, but it could do things like solid fills and lines.

In today's money the PGC cost about the same as an RTX PRO 6000, so no-one really had them.

by ErroneousBosh

12/7/2025 at 2:25:16 PM

A video card is not a GPU.

by Yeask

12/8/2025 at 12:16:27 PM

> The 8514/A (1987) was Turing complete

WTF? Tell me more!

I have one, but I have no matching screen so I never tried it... Maybe it's worth finding a converter.

by lproven

12/6/2025 at 3:50:04 PM

VGA standard supports up to 256k

by sigwinch

12/7/2025 at 3:17:54 PM

You do not really need a framebuffer to drive a GUI, though. That's very much a PC thing.

by AshamedCaptain

12/6/2025 at 3:44:17 PM

[dead]

by ohhellnawman

12/6/2025 at 3:55:51 PM

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

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

by forinti

12/6/2025 at 5:35:22 PM

That's only RISC OS 2 though. RISC OS 3 was 2MB, and even 3.7 didn't have everything in ROM as Acorn had introduced the !Boot directory for softloading a large amount of 'stuff' at boot time.

by xyzzy3000

12/6/2025 at 4:13:57 PM

If that is a lot less of things not needed for the specific use case, that is still a big plus.

by psychoslave

12/6/2025 at 4:25:22 PM

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.

by pastage

12/6/2025 at 8:13:39 PM

RISC OS has the concept of "OS units" which don't map directly onto pixels 1:1, and it was possible to fiddle with the ratio on the RiscPC from 1994 onwards, giving reasonably-scaled windows and icons in high-resolution modes such as 1080p.

It's hinted at in this tutorial, but you'd have to go through the Programmer's Reference Manual for the full details: https://www.stevefryatt.org.uk/risc-os/wimp-prog/window-theo...

RISC OS 3.5 (1994) was still 2MB in size, supplied on ROM.

by xyzzy3000

12/6/2025 at 5:39:47 PM

The OS did ship with bezier vector font support. AFAIK it was the first GUI to do so.

P.S. I should probably mention that there wasn't room in the ROM for the vector fonts; these needed to be loaded from some other medium.

by masfuerte

12/7/2025 at 4:16:28 AM

Anyone else remember the QNX demo disk from the late '90s? A full unix-like GUI environment that booted from a 1.44MB floppy disk. Ran super responsively in 386 machines with 8MB of RAM.

by bigiain

12/7/2025 at 7:22:27 AM

They had a free distro for a while, it's was pretty exciting being real time and with a microkernel and such. As a CS student it was neat to see where the world of computing might have went if different decisions had been made in the past.

by Suppafly

12/6/2025 at 4:25:59 PM

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!

by taylodl

12/6/2025 at 3:20:31 PM

Yea, but those platforms were not 64bit

by Perz1val

12/6/2025 at 4:12:07 PM

64 bit generally adds about 20% to the size of the executables and programs as t to last on x86, so it's not that big of a change.

by monocasa

12/6/2025 at 10:42:09 PM

Switch to an ILP32 ABI and you get a lot of that space back

by IAmLiterallyAB

12/7/2025 at 6:13:59 AM

I agree. That system even had MS word in something like 2-5MB of storage.

Windows 3.1 was only something like 16MB of storage.

Imagine the Cray supercomputer in those days being used to run a toaster or doorbell…

by BobbyTables2

12/6/2025 at 3:58:14 PM

I would like to have this again

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

by 1vuio0pswjnm7

12/6/2025 at 6:55:45 PM

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

by oso2k

12/6/2025 at 4:38:21 PM

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

by beng-nl

12/6/2025 at 5:03:39 PM

I've been wondering if I could pull the DIMM from a running machine if everything was cached.

Probably not due to DMA buffers. Maybe a headless machine.

But would be funny to see.

by bobmcnamara

12/6/2025 at 7:25:52 PM

Like the k language!

by veqq

12/6/2025 at 5:04:33 PM

With 320x240 pixels and 256 colors

by croes

12/6/2025 at 10:57:01 PM

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

If you were someone special, you got 1024x768.

by trollbridge

12/7/2025 at 2:26:59 PM

And a 20kg monitor.

by Yeask

12/6/2025 at 5:07:25 PM

"640k ought to be enough for everyone!"

by nilamo

12/6/2025 at 3:37:14 PM

> 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?

by embedding-shape

12/6/2025 at 3:06:00 PM

This is cool. My first into to a practical application of Linux in the early 2000s was using Damn Small Linux to recover files off of cooked Windows Machines. I looked up the project the other day while reminiscing and thought it would be interesting if someone took a real shot at reviving the spirit of the project.

by shiftpgdn

12/6/2025 at 11:32:21 PM

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.

by jollyjerry

12/7/2025 at 6:30:19 AM

Damn Small Linux was the second Linux I tried (after the free CD promotion that Ubuntu did). I liked it and it was fun to play with, but I was such a newbie that I wasn't able to really use it for anything.

It's 20 years later and I've been running Linux for most of that time, so I probably would have even more fun revisiting DSL and Tiny Core Linux.

by tombert

12/6/2025 at 4:24:06 PM

I love lightweight distros. QNX had a "free as in beer" distro that fit on a floppy, with Xwindows and modem drivers. After years of wrangling with Slackware CDs, it was pretty wild to boot into a fully functional system from a floppy.

by gardnr

12/6/2025 at 4:55:54 PM

> 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....)

by Someone

12/6/2025 at 4:46:48 PM

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

by ddalex

12/6/2025 at 5:40:45 PM

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

by Joel_Mckay

12/6/2025 at 6:51:00 PM

This also underscores my explanation for the “worse is better” phenomenon: worse is free.

Stuff that is better designed and implemented usually costs money and comes with more restrictive licenses. It’s written by serious professionals later in their careers working full time on the project, and these are people who need to earn a living. Their employers also have to win them in a competitive market for talent. So the result is not and cannot be free (as in beer).

But free stuff spreads faster. It’s low friction. People adopt it because of license concerns, cost, avoiding lock in, etc., and so it wins long term.

Yes I’m kinda dissing the whole free Unix thing here. Unix is actually a minimal lowest common denominator OS with a lot of serious warts that we barely even see anymore because it’s so ubiquitous. We’ve stopped even imagining anything else. There were whole directions in systems research that were abandoned, though aspects live on usually in languages and runtimes like Java, Go, WASM, and the CLR.

Also note that the inverse is not true. I’m not saying that paid is always better. What I’m saying is they worse is free, better was usually paid, but some crap was also paid. But very little better stuff was free.

by api

12/6/2025 at 7:34:09 PM

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.

by rzerowan

12/6/2025 at 9:06:30 PM

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

by Joel_Mckay

12/6/2025 at 8:51:25 PM

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

by Joel_Mckay

12/7/2025 at 6:57:34 PM

As someone who used QNX back then, they didn't target end-users but embedded and real-time users.

They were expensive too. You had to pay for each device driver you used.

by RachelF

12/6/2025 at 8:05:49 PM

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

by knowitnone3

12/6/2025 at 4:30:50 PM

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

by anyfoo

12/6/2025 at 4:33:35 PM

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

by taylodl

12/6/2025 at 7:11:33 PM

And incredibly responsive compared to the operatings systems of even today. Imagine that: 30 years of progress to end up behind where we were. Human input should always run at the highest priority in the system, not the lowest.

by jacquesm

12/7/2025 at 9:20:07 PM

That ended with Win9x. It was the last OS where the mouse and keyboard inputs were processed as hardware interrupts.

by M95D

12/6/2025 at 8:00:35 PM

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

by knowitnone3

12/6/2025 at 3:24:15 PM

I have an older laptop with a 32-bit processor and found that TinyCoreLinux runs well on it. It has its own package manager that was easy to learn. This distro can be handy in these niche situations.

by veganjay

12/6/2025 at 4:12:57 PM

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

by bdbdbdb

12/6/2025 at 5:13:08 PM

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.

by Narishma

12/6/2025 at 7:13:02 PM

Personally, I think that dropping 32 bit support for Linux is a mistake. There is a vast number of people in developing countries on 32 bit platforms as well as many low cost embedded platforms and this move feels more than a little insensitive.

by jacquesm

12/7/2025 at 1:34:03 PM

won't there still be the older kernels?

by stOneskull

12/6/2025 at 4:48:40 PM

In around 2002, I got my hands on an old 386 which I was planning to use for teaching myself things. I was able to breathe life into it using MicroLinux. Two superformatted 1.44" floppy disks and the thing booted. Basic kernel, 16 colour X display, C compiler and Editor.

I don't know if there are any other options for older machines other than stripped down Linux distros.

by noufalibrahim

12/7/2025 at 10:35:39 AM

Delicate Linux; but you need patience to compile some LibreSSL fork on top of BrSSL and then recompile Lynx, a newer Dillo, Git and so on.

by anthk

12/6/2025 at 5:06:06 PM

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

by Romario77

12/6/2025 at 7:35:58 PM

Tiny Core also runs from ramdisk, uses a packaging systems based on tarballs mounted in a fusefs and can be installed on a dos formatted usb key. It also has a subdistro named dCore[1] which uses debian packages (which it unpacks and mounts in the fusefs) so you get access to the ~70K packages of debian.

It's documentation is a free book : http://www.tinycorelinux.net/book.html

[1] https://wiki.tinycorelinux.net/doku.php?id=dcore:welcome

by slim

12/6/2025 at 3:07:49 PM

The site doesn't have HTTPS and there doesn't seem to be any mention of signatures on the downloads page. Any way to check it hasn't been MITM'd?

by hypeatei

12/6/2025 at 3:13:35 PM

Not foolproof. Could compute MD5 or SHA256 after downloading.

by firesteelrain

12/6/2025 at 3:23:26 PM

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/

by hypeatei

12/6/2025 at 3:27:53 PM

Which is served from the same insecure domain. If the download is compromised you should assume the hash from here is too.

by maccard

12/6/2025 at 3:30:44 PM

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

by hypeatei

12/6/2025 at 3:40:53 PM

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/

Under a HTTPS connection. I am not at a terminal to check the cert with OpenSSL.

I don’t see any way to check the hash OOB

Also this same thing came up a few years ago

https://www.linuxquestions.org/questions/linux-newbie-8/reli...

by firesteelrain

12/6/2025 at 4:13:22 PM

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…

by maccard

12/6/2025 at 4:29:57 PM

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

by firesteelrain

12/6/2025 at 6:19:15 PM

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!

by maccard

12/6/2025 at 3:39:08 PM

An integrity check where both what you're checking and the hash you're checking against is literally not better than nothing if you're trying to prevent downloading compromised software. It'd flag corrupted downloads at least, so that's cool, but for security purposes the hash for a artifact has to be served OOB.

by embedding-shape

12/6/2025 at 4:20:48 PM

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.

by uecker

12/6/2025 at 5:26:42 PM

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.

by maccard

12/6/2025 at 7:21:48 PM

"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.

by uecker

12/6/2025 at 4:07:35 PM

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

by maccard

12/6/2025 at 3:46:35 PM

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

by firesteelrain

12/6/2025 at 6:22:40 PM

Where is that mirror linked from? If for the HTTP site that’s no better than downloading it from the website in the first place.

> for extra high security,

No, sending the hash on a mailing list and delivering downloads over https is the _bare minimum_ of security in this day and age.

by maccard

12/6/2025 at 10:29:51 PM

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.

by firesteelrain

12/7/2025 at 4:55:47 PM

> 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.

This thread started by talking about the site serving the download (and hash) over http. Github serves their content over https, so you're not going to be MITM'ed. There are other attack vectors, but if the delivery of the content you're downloading is compromised/MITM'ed, you've lost.

by maccard

12/7/2025 at 7:50:01 PM

If you want real integrity + provenance, you need a GPG-signed ISO and a public key obtained independently (or at least via HTTPS). Hashes alone aren’t a security measure; HTTPS + signatures are the modern minimum.

by firesteelrain

12/6/2025 at 3:59:05 PM

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

by throwaway984393

12/6/2025 at 10:13:17 PM

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

by debo_

12/7/2025 at 1:18:54 AM

And their shavers.

by lysace

12/7/2025 at 9:25:17 AM

Tiny Core Linux fits nicely on a FAT32 EFI boot partition as a rescue OS.

by Grom_PE

12/8/2025 at 12:51:55 PM

Hey, this sounds interesting! Is there any tutorial out there on how to make it work?

by ajot

12/7/2025 at 6:27:34 PM

When I was a teenager, tiny core saved me for a few months. My laptop had died and all I could use until I got a replacement was an old desktop computer we had around with 256MB of RAM. It was around the end of the windows 7 era, so even Xubuntu was struggling on such an old computer.

Tiny Core ran surprisingly well and I could actually use it to browse the web and use IRC.

by zer0tonin

12/6/2025 at 6:03:38 PM

I've used it around early 2010s as a live cd to fix partitions etc. Definitely recommend as a lightweight distro.

Was a little tricky to install on disk and even on disk it behaved mostly like a live cd and file changes had to be committed to disk IIRC.

Hope they improved the experience now.

by devsda

12/6/2025 at 6:07:35 PM

/* On the website, body { font-size: 70%; } — why? To drive home the idea that it's tiny? The default font size is normally set to the value comfortable for the user, would be great to respect it. */

by nine_k

12/6/2025 at 7:10:14 PM

For unknown reasons, tinycorelinux's website is geoblocked in Japan.

by snvzz

12/7/2025 at 2:32:21 PM

I seem to be able to access it just fine via ProtonVPN's Japan region tho.

by hexagonwin

12/7/2025 at 4:50:32 PM

I was also able to load it from Japan for the first time.

In weeks before, when the topic came up elsewhere, I had to use one of my tailscale exit nodes elsewhere.

It wouldn't work from Japan. Not from home, not from office, not from phone network either.

by snvzz

12/7/2025 at 1:32:07 AM

Could such a distro support my i486-DX4-100 system with 64MB of RAM? I've been looking for something other than Win95, NT4, and OpenBSD 6.8 to run on this box. :)

by accrual

12/7/2025 at 7:44:46 AM

Tiny Core has always amazed me. The amount of functionality they fit into such a small footprint shows how far you can go when you optimize for simplicity.

by Simplita

12/6/2025 at 9:05:10 PM

I used to run Puppy Linux and then TCL (and its predecessor DSL) on a super old Pentium 3 laptop with like 700mb of RAM or something. Made it actually usable!

by girvo

12/6/2025 at 9:06:28 PM

That's a ton of ram for a pIII

by nurettin

12/7/2025 at 3:02:59 AM

Yeah I’m pretty certain it had been upgraded and with mismatched sticks to boot! Very weird hand me down laptop

by girvo

12/6/2025 at 4:47:55 PM

Another small one is the xwoaf (X Windows On A Floppy) rebuild project 4.0 https://web.archive.org/web/20240901115514/https://pupngo.dk...

Showcase video https://www.youtube.com/watch?v=8or3ehc5YDo

iso https://web.archive.org/web/20240901115514/https://pupngo.dk...

2.1mb, 2.2.26 kernel

>The forth version of xwoaf-rebuild is containing a lot of applications contained in only two binaries: busybox and mcb_xawplus. You get xcalc, xcalendar, xfilemanager, xminesweep, chimera, xed, xsetroot, xcmd, xinit, menu, jwm, desklaunch, rxvt, xtet42, torsmo, djpeg, xban2, text2pdf, Xvesa, xsnap, xmessage, xvl, xtmix, pupslock, xautolock and minimp3 via mcb_xawplus. And you get ash, basename, bunzip2, busybox, bzcat, cat, chgrp, chmod, chown, chroot, clear, cp, cut, date, dd, df, dirname, dmesg, du, echo, env, extlinux, false, fdisk, fgrep, find, free, getty, grep, gunzip, gzip, halt, head, hostname, id, ifconfig, init, insmod, kill, killall, klogd, ln, loadkmap, logger, login, losetup, ls, lsmod, lzmacat, mesg, mkdir, mke2fs, mkfs.ext2, mkfs.ext3, mknod, mkswap, mount, mv, nslookup, openvt, passwd, ping, poweroff, pr, ps, pwd, readlink, reboot, reset, rm, rmdir, rmmod, route, sed, sh, sleep, sort, swapoff, swapon, sync, syslogd, tail, tar, test, top, touch, tr, true, tty, udhcpc, umount, uname, uncompress, unlzma, unzip, uptime, wc, which, whoami, yes, zcat via busybox. On top you get extensive help system, install scripts, mount scripts, configure scripts etc.

by haunter

12/6/2025 at 5:40:16 PM

I love Tiny Core Linux for use cases where I need fast boot times or have few resources. Testing old PCs, Pi Zero and Pi Zero 2W are great use cases.

by oso2k

12/6/2025 at 7:14:57 PM

Thank you for that comment, I did not realize Pi Zero and Pi Zero 2W worked with TCL. I am brewing an application for that environment right now so this may just save the day and make my life a lot easier. Have you tried video support for the Pi specific cams under TCL?

by jacquesm

12/6/2025 at 11:17:22 PM

I don't know about CSI cameras. My use case for TCL doesn't require a CSI camera. But it looks like others have made a CSI camera work:

https://forum.tinycorelinux.net/index.php/topic,26713.0.html

I recommend asking on that forum. Folks are helpful.

by oso2k

12/7/2025 at 12:42:03 AM

Thank you once more!

by jacquesm

12/6/2025 at 5:53:52 PM

https://luxferre.top http://t3x.org

All of the minilaguages exposed there will run on TC even with 32MB of RAM.

On TC, set IceWM the default WM with no opaque moving/resizing as default and get rid of that horrible dock.

by anthk

12/6/2025 at 3:03:43 PM

Looks really nice, I like the idea.

But can they please empower a user interface designer to simply improve the margins and paddings of their interface? With a bunch of small improvements it would look significantly better. Just fix the spacing between buttons and borders and other UI elements.

by bflesch

12/6/2025 at 3:12:52 PM

Modern UX trends are a scourge of excessive whitespace and low information density that get in the way of actually accomplishing tasks.

Any project that rejects those trends gets bonus points in my book.

by wild_egg

12/6/2025 at 4:21:48 PM

I sympathize, but I feel compelled to point out that the parent didn’t say that the interface had to look like a contemporary desktop.

In my opinion, I believe the Tiny Core Linux GUI could use some more refinement. It seems inspired by 90s interfaces, but when compared to the interfaces of the classic Mac OS, Windows 95, OS/2 Warp, and BeOS, there’s more work to be done regarding the fit-and-finish of the UI, judging by the screenshots.

To be fair, I assume this is a hobbyist open source project where the contributors spend time as they see fit. I don’t want to be too harsh. Fit-and-finish is challenging; not even Steve Jobs-era Apple with all of its resources got Aqua right the first time when it unveiled the Mac OS X Public Beta in 2000. Massive changes were made between the beta and Mac OS X 10.0, and Aqua kept getting refined with each successive version, with the most refined version, in my opinion, being Mac OS X 10.4 Tiger, nearly five years after the public beta.

by linguae

12/6/2025 at 6:35:39 PM

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

by oso2k

12/6/2025 at 3:34:34 PM

If you look at the screenshots it immediately jumps out that it is unpolished: the spacings are all over the place, the window maximize/minimize/close buttons have different widths and weird margins.

I thought that would be immediately clear to the HN crowd but I might have overestimated your aesthetic senses.

by bflesch

12/6/2025 at 4:10:23 PM

There is a balance.

Too much information density is also disorienting, if not stressing. The biggest problem is finding that balance between multiple kinds of users and even individuals.

by delfinom

12/6/2025 at 3:30:23 PM

Look at screenshots -> wallpaper window. The spacing between elements is all over the place and it simply looks like shit. Seeing this I'm having doubts if the team who did this is competent at all

by Perz1val

12/6/2025 at 3:36:48 PM

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.

by bflesch

12/6/2025 at 3:33:43 PM

[dead]

by ohhellnawman

12/6/2025 at 9:45:22 PM

[dead]

by crackernews1

12/6/2025 at 3:08:28 PM

One could argue that visible borders are a feature, not a bug.

If you are trying to maximize for accessibility, that is.

by grim_io

12/6/2025 at 3:33:15 PM

It's not about the damn borders it is about the spacing between the buttons and other UI elements as you can see in the screenshot. I don't want them to introduce some shitty modern design, just fix the spacing so it doesn't immediately jump out as odd and unpolished.

by bflesch

12/6/2025 at 3:23:09 PM

Pretty sure it was not about presence of visible borders, but about missing spacing between borders and buttons. That on some screenshots, but not others. It's not like this ui has some high-density philosophy, it's just very inconsistent

by egormakarov

12/6/2025 at 4:31:05 PM

This just looks like a standard _old_ *nix project. I've used Tiny, a couple of decades ago IIRC, from a magazine cover CD.

I imagine the sign-off date of 2008, the lack of very simple to apply mobile css, and no https to secure the downloads (if it had it then it would probably be SSL).

This speaks to me of a project that's 'good enough', or abandoned, for/by those who made it. Left out to pasture as 'community dev submissions accepted'.

I've not bothered to look, but wouldn't surprise me if the UI is hardcoded in assembly and a complete ballache to try and change.

by pbhjpbhj

12/6/2025 at 4:03:05 PM

[dead]

by throwaway984393

12/7/2025 at 6:12:16 PM

Is there a reason the site doesn't support HTTPS? For a distro offering ISO downloads, this seems like a meaningful security gap -> it makes MITM attacks trivial for anyone on the network path.

by hit8run

12/6/2025 at 4:06:12 PM

This would be perfect if it had an old Mac OS 7 Platinum-like look and window shading.

by rcarmo

12/6/2025 at 10:25:45 PM

As I updated my thinkpad to 32 GB of RAM this morning (£150) I remembered my £2k (corporate) thinkpad in 1999, running Windows 98, had 32 MB of RAM. And it ran full Office and Lotus notes just fine :)

by retube

12/6/2025 at 7:09:52 PM

It is so tiny that it is http only because https was too big...

by roscas

12/6/2025 at 6:52:44 PM

for a moment I thought about a Corel Linux revamp :)

by mannycalavera42

12/8/2025 at 12:25:22 PM

I wish.

I would much prefer its final desktop, from Xandros 4, to the Trinity (TDE) desktop fork of KDE 3.

by lproven

12/6/2025 at 9:18:36 PM

“Tiny” :)

I remember booting Linux off a 1.44Mb floppy

by alfiedotwtf

12/6/2025 at 9:21:22 PM

What gui were you running?

by jethro_tell

12/7/2025 at 7:43:19 PM

Last time I ran a linux distro from a floppy disk (mid 2000s, novelty reasons), it was xfce.

by extraduder_ire

12/7/2025 at 12:37:45 AM

Ah. Yeah, no gui on that device, but I was running XFree86 on another tiny device. Maybe 8Mb though

by alfiedotwtf

12/7/2025 at 12:46:35 PM

OK but I need a Linux with GUI that is less than 1.44MB so it works with my floppy disk.

by vid

12/9/2025 at 12:40:11 PM

Not sure why I was downvoted. I legitimately need this for a demo.

by vid

12/6/2025 at 4:42:22 PM

Does it run docker?

by theanonymousone

12/6/2025 at 6:46:58 PM

With some modifications, yes. Boot2docker and boot2podman were based on tinycorelinux.

by oso2k

12/7/2025 at 4:30:35 AM

Both are deprecated though. And both say something unexpected on their repositories: one suggests you to use Docker Desktop (what?!), the other to try Fedora (what?!!). Am I taking crazy pills?

by thway15269037

12/6/2025 at 11:00:17 PM

and who is using this?

by sfarcolacul987

12/6/2025 at 6:40:12 PM

[flagged]

by arschficknigger

12/6/2025 at 3:21:59 PM

[flagged]

by deadbabe

12/6/2025 at 3:24:15 PM

Why use a terminal when you can use punch cards?

by lp0_on_fire

12/6/2025 at 3:30:36 PM

Because this is now a paperless office, please consider the enviroment

by Y_Y

12/6/2025 at 3:40:10 PM

Switching away from clay tablets was a step in the wrong direction.

by adrianN

12/6/2025 at 4:05:19 PM

Those clay tablets needed to be fired and had a negative carbon footprint.

Handmade parchment, or leather carvings if you don’t mind.

by SV_BubbleTime

12/6/2025 at 5:57:04 PM

Why fire them when you can just reuse them?

by adrianN

12/6/2025 at 3:49:51 PM

[dead]

by ohhellnawman

12/6/2025 at 3:30:58 PM

Why use a computer when you can use a slide rule?

by jqpabc123