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...
"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
“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.
Tesla rather famously had issues by writing logs to SD storage.
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 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.
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.
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.
Hi check this https://smolbsd.org/#about Also standard NetBSD ISO might not be useful do check platform specific images.
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.
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
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.
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
Check this https://smolbsd.org/#about
This appears to be new to me. Very interesting, many thanks for sharing!
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.
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.
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/
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.
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.
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.
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.
Important to mention: Alpine can run from RAM like TinyCore
"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?
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.
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.
Not true. You can enable “Mount Mode of Operation: TCE/Install” where packages will be mounted off disk. See:
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.
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.
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.
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
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.
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.
> 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?
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.
DNS queries randomly failing:
https://purplecarrot.co.uk/post/2021-09-04-does_alpine-resol...
Not an issue anymore
Really? I seen to remember this being considered "not a bug" by some narrow view of the issue.
Fixed over 2 years ago, as I reported at the time.
How about debian-slim?
I actually have used that, thank you. Excellent choice.
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?
Is docker valid for your use case?
Isn’t this what GitHub remote envs are (or whatever they call it)?
Never really got what it’s for.
JetBrains has Gateway which allows connecting to a remote instance and work on it.
Yes, but it requires JetBrain running on the client too.
moonlight / sunshine might work if you can't run it locally.
It'd be best with hardwired network though.
> I also like SliTaz
thank you for this reminder! I had completely forgotten about SliTaz, looks like I need to check it out again!
Wow, Slax is still around and supports Debian now too? Thanks for sharing.
I used to use it during the netbook era, was great for that.
> 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?
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.
wondering what's your typical usage for those small distros?
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".
I use one of them to make an old EEE laptop a dedicated Pico-8 machine for my kids. [https://www.lexaloffle.com/pico-8.php]
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.
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.
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.
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.
I used DSL for the control of a homebrew 8' x 4' CNC plasmacutter.
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.
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.
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.
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.
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.
> 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.
"Windows 3.1 primarily used palette-based color modes, common modes included 16 colors (VGA/EGA) and 256 colors (SuperVGA)"
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.
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.
640 * 480 / 2 = 150KB for a classic 16-color VGA screen.
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.
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?)
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.
You might be thinking of DOS mode 13h, which was VGA 320x200, 8 bits per pixel.
And 6-bits per colour component.
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).
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!
i remember playing with mode 13h, writing little graphics programs with my turboc compiler. computers were so magical back then.
It's so much fun working with systems with more pixels than ram though. Manually interleaving interrupts. What joy.
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.
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.
My video card then didn’t have video ram for 256 color SVGA…
Those old computers were 640x480 or so. Maybe smaller.
Do you really need the framebuffer in RAM? Wouldn't that be entirely in the GPU RAM?
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.
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.
Yes if you have UEFI.
well, if you poke framebuffer pixels directly you might as well do scanline racing.
Alas, I don't think UEFI exposes vblank/hblank interrupts so you'd just have to YOLO the timing.
> 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.
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.
That's 100MB of RISC-V code, believe it or not, despite Nvidias ARM fixation.
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?
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
Aren’t you cheating by having additional ram dedicated for gpu use exclusively? :)
Computers didn't used to have GPUs back then when 150kB was a significant amount of graphics memory.
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.
A video card is not a GPU.
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.
> 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.
VGA standard supports up to 256k
You do not really need a framebuffer to drive a GUI, though. That's very much a PC thing.
[dead]
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.
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.
Here’s a blast of classic internet: http://toastytech.com/guis/qnxdemo.html
No ssl, probably so you can access that site on the browser
The Acorn Archimedes had the whole OS on a 512KB ROM.
That said, OSs came with a lot less stuff then.
> The Acorn Archimedes had the whole OS on a 512KB ROM.
True. And it's still around. It's FOSS now, runs natively on a Raspberry Pi 1-400 and Zero, and has Wifi, IPv6, and a Webkit browser.
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.
If that is a lot less of things not needed for the specific use case, that is still a big plus.
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.
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.
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.
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!
Yea, but those platforms were not 64bit
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.
Switch to an ILP32 ABI and you get a lot of that space back
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…
I would like to have this again
I prefer to use additional RAM and disk for data not code
There’s an installation option to run apps off disk. It’s called “The Mount Mode of Operation: TCE/Install”.
To think that the entire distro would fit in a reasonable LLC (last level cache)..
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.
Like the k language!
With 320x240 pixels and 256 colors
640x480 with 16 colours was standard in offices in the late 80s.
If you were someone special, you got 1024x768.
And a 20kg monitor.
"640k ought to be enough for everyone!"
> 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?
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.
> someone took a real shot at reviving the spirit of the project.
They did.
https://www.theregister.com/2024/02/14/damn_small_linux_retu...
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.
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.
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.
> 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....)
Somebody has build it: https://membarrier.wordpress.com/2017/04/12/qnx-7-desktop/
I never understood how that QNX desktop didn't pick up instanntly, it was amazing !
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"
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.
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.
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
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
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.
because it's not free and their aim was at developers and the embedded space. How many people have even heard of QNX?
That famous QNX boot disk was the first thing I thought of when reading the title as well.
Me too! And the GUI was only a 40KB distribution and was waaaaaay better than Windows 3.0!
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.
That ended with Win9x. It was the last OS where the mouse and keyboard inputs were processed as hardware interrupts.
yeah but what can you do with free QNX? With tinycore, you can install many packages. What packages exist for QNX?
> yeah but what can you do with free QNX?
« QNX DEMO disk
Extending possibilities and adding undocumented features »
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.
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
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.
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.
won't there still be the older kernels?
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
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.
Haiku OS:
I mean - DOS or it's equivalents still exist and for older computers you will probably be able to find drivers.
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.
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?
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...
Not foolproof. Could compute MD5 or SHA256 after downloading.
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/
Which is served from the same insecure domain. If the download is compromised you should assume the hash from here is too.
An integrity check is better than nothing, but yes it says nothing about its authenticity.
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...
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…
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
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!
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.
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.
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.
"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.
It’s not better than nothing - it’s arguably worse.
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
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.
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.
> 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.
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.
Because there's big demand to mitm users of an extremely small and limited distribution from 2008?
I swear to god. Won't somebody think of the yaks.
And their shavers.
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.
Tiny Core Linux fits nicely on a FAT32 EFI boot partition as a rescue OS.
Hey, this sounds interesting! Is there any tutorial out there on how to make it work?
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.
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.
/* 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. */
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. :)
Yes. 486 with 26MB for MicroCore (cli) or 46MB for TinyCore (gui).
https://en.wikipedia.org/wiki/Tiny_Core_Linux#System_require...
For unknown reasons, tinycorelinux's website is geoblocked in Japan.
I seem to be able to access it just fine via ProtonVPN's Japan region tho.
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.
That’s even smaller than these!
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!
That's a ton of ram for a pIII
Yeah I’m pretty certain it had been upgraded and with mismatched sticks to boot! Very weird hand me down laptop
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.
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.
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?
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.
Thank you once more!
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.
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.
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.
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.
With CorePlus, you have the the choice of some 10 GUI environments. I prefer openbox or jwm.
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.
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.
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
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.
[dead]
[dead]
One could argue that visible borders are a feature, not a bug.
If you are trying to maximize for accessibility, that is.
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.
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
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.
[dead]
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 :)
This would be perfect if it had an old Mac OS 7 Platinum-like look and window shading.
It is so tiny that it is http only because https was too big...
for a moment I thought about a Corel Linux revamp :)
I wish.
I would much prefer its final desktop, from Xandros 4, to the Trinity (TDE) desktop fork of KDE 3.
OK but I need a Linux with GUI that is less than 1.44MB so it works with my floppy disk.
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.
Does it run docker?
With some modifications, yes. Boot2docker and boot2podman were based on tinycorelinux.
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?
“Tiny” :)
I remember booting Linux off a 1.44Mb floppy
What gui were you running?
Last time I ran a linux distro from a floppy disk (mid 2000s, novelty reasons), it was xfce.
Ah. Yeah, no gui on that device, but I was running XFree86 on another tiny device. Maybe 8Mb though
and who is using this?
[flagged]
[flagged]
Why use a terminal when you can use punch cards?
Because this is now a paperless office, please consider the enviroment
Switching away from clay tablets was a step in the wrong direction.
Those clay tablets needed to be fired and had a negative carbon footprint.
Handmade parchment, or leather carvings if you don’t mind.
Why fire them when you can just reuse them?
Those both require cattle farming, which is a major contributor to greenhouse gas emissions (at least 10%, perhaps as high as 19.6%, per https://thebreakthrough.org/issues/food-agriculture-environm...). Stick with papyrus or wax, please.
[dead]
Why use a computer when you can use a slide rule?
