Judging by the comments, it seems like people haven't realized yet that the distribution is precisely this small so the entire thing can run in RAM. TinyCore wants to be super fast, so they try and got everything in RAM.
[0]: https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%2...
[nitpicking, of course :)]
I do the same with stock Debian. Not an achievement to simply run from RAM only.
Personally, I have been running my computers this way for many years now. I do not use Linux kernel, but like "tinycore" everything fits in RAM. Size range is usually about 13-17MB for x86.
The USB stick or other boot media with the kernel+bootloader can be removed after boot. Depending on how much free RAM I have to spare, I can overlay larger userlands on top of this, and chroot into them. With todays RAM sizes, I can hold an entire "default base" (BSD) in memory if desired.
This filesystem on the media is not merely an "install" image. It has everything I need to do work, including custom applications. If I want distributions sets I download them; they are not stored on the media.
In normal use, I do not use any disk. Therefore I do not use a swap file.
Recently on HN a discussion of sorting came up, and I mentioned the issue of sorting large datasets using only RAM, no disk. Obviously BSD and other UNIX-like kernels date back to a time of severely constrained memory and are designed around space-saving concepts like "virtual memory" and "swap", "shared libraries", etc.
When one runs from RAM with no disk, working with large files means "thrashing" is a real possibility. Aside: Did the architects of virtual memory contemplate a world where users are doing work without using HDDs or other writeable permanent storage. (Start a new thread if want to answer/debate this.)
Sorting large files is something I do regularly so I am always open to new ideas. Currently I use k/kdb+ for large files instead of UNIX sort.
Here's the reply I got:
No question Linux wins on (b) given all the corporate backing, but whenever I revisit systems like Buildroot or Yocto I feel the system I am using wins on (a). More likely than not I am just resistant to change and not wanting to invest the effort to master those systems.
Purely subjective, but I suspect the system I devised for myself is simpler and more "stable" in the sense it is less reliant on third parties and thus less brittle. Those qualities are important to me.
Not sure if anyone has mentioned VoidLinux yet in this thread. Probably well worth a look at least as an example if "small and simple" are design goals.
Gentoo and its Portage are IMO really good for distro building, though I would not say it is "small" or "simple". NixOS might also be a good distro builder, from the little I've read about it.
On the same note, I take it your systems are very "I'm using the [whichever]BSD kernel and userland, but this is my own creation" as opposed to stock [whichever]BSD.
A related tangential question:
I've been on the fence about BSD distributions for a really long time, specifically the viability of maintaining them. The few that exist seem to end up forking the entire system, as opposed to just running off with the stock kernel and maybe doing package management differently. That puts huge pressure+responsibility on the person doing the fork.
My question is, are things the way they are because people wanted to fork the kernel for a specific reason and their fork naturally pulled userspace along, or is there a specific reticence toward forking userspaces in the *BSD world?
Generally all kernels will assume _some_ backing store. The reason for this is dealing with RAM being full.
This is because updating MMU is generally expensive, so it’s easier to mark an address as belonging to your process, and commit the pages after the fact.
Now this can be changed in settings. Ensure pages are backed before allocated, and running swap off can be done.
But then EVERY and let me repeat EVERY SINGLE piece of code you run has to able to handle malloc failing gracefully. And next to none do. This is a strange condition because how you handle it depends on your kernel configuration, and how much stack you have left. Which is difficult to know unless you wrote every piece of code FOR your custom kernel config.
Ultimately just having swap enabled and assuming a back store is easier. The few places where you get away with 100% ram and a read only store is embedded (generally, not always) and in these conditions you can closely tie software to kernel configuration.