Tiny Core Linux
tinycorelinux.net
tinycorelinux.net
[1] http://forum.tinycorelinux.net/index.php?topic=8924.0
[2] http://forum.tinycorelinux.net/index.php/topic,8522.0.html
[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:
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.
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.
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?
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.
"minimal live Linux system based on Micro Core (Tiny Core Linux) that uses scripts to download select packages directly from vast Debian or Ubuntu repositories and convert them into useable SCEs (self-contained extensions). "
Buildroot also includes a cross compiler, so that you can rebuild the entire toolchain, kernel, and libraries in one go.
But I think Buildroot targets different hardware than Tiny Core. Buildroot targets embedded systems. It therefore lacks a package manager. Tiny core seems to target bigger systems, like notebooks, servers and desktops.
Then, I take that list of modules and set them to "Y", and disable everything else. That way, needed libraries are statically linked and unneeded libraries aren't built at all.
I've run the latest ones and for a quick and dirty live desktop from a super small image, it still seems to be a good option.
I tried looking around for what happened to SliTaz, is there an article/detail anywhere on that (the transition/rewrite/zombification)?
When I workded in public IT, on a few occasions I booted Slitaz on troubled machines that idiot colleagues had battled with for hours or days, trying to install som Windows. In less than a minute, I had a working, webbrowsing desktop running entirely from RAM. Tellingly, nobody ever as much as asked a simple how? - somehow reminding me of the Australian aborigines simply ignoring the arrival of a UFO in the shape of captain Cook's ship.
What a great little OS.
QNX is crazy fast in that respect simply because it has almost no context to switch. The soft-realtime aspect of the kernel also helps tremendously in keeping things moving, everything that is interactive runs at a high priority so you'll never see frozen mousepointers or stuff like that.
Still astounding they managed to fit so much into 1.44mb!
I wish RIM/Blackberry hadn't bought it, closed the source¹, and killed off Photon. QNX was a really solid and fast OS.
1. For those who don't follow QNX development closely, the source was available for a few years but was not open in the usual sense. It was still under a proprietary license. RIM bought QNX and closed it off completely.
Even so, there probably are still untold millions (or even 10's of millions) of embedded QNX installations out there besides the Blackberries that are still in use.
That little os is about as elegant as they come this side of plan9/inferno.
> tomsrtbt (pronounced: Tom's Root Boot) is a very small Linux distribution. It is short for "Tom's floppy which has a root filesystem and is also bootable."[1] Its author, Tom Oehser, touts it as "The most GNU/Linux on one floppy disk", containing many common Linux command-line tools useful for system recovery (Linux and other operating systems.) It also features drivers for many types of hardware, and network connectivity.
https://en.wikipedia.org/wiki/Tomsrtbt
Also, Oberon fits on a 1.44M floppy. http://www.projectoberon.com/
Can't seem to find anything today that would fit on one, but then again I haven't done much more than a cursory dig.
I built a Linux floppy-based bootable disk imaging environment to roll out masses of Windows 95/98 machines back in 1997-1999. You'd compile a minimal kernel down to 600 - 800 KB then pack-up your userland in an itty-bitty gzipped filesystem archive and concatenate it with the kernel at an even sector boundary, dd the whole thing to a disk, and set some bits to tell the kernel where to load the initrd. I've never gone back to see how much of that functionality still exits in modern kernels. (Very little, I'd assume...)
http://kparc.com - OS, GUI, database, boots on 64-but bare metal, still fit on a 3.5in floppy last time I looked.
EDIT: Don't get me wrong, it is really cool people can build such tiny systems. But the smallest storage device in my household it a 2GB SD card. Outside of embedded devices and low-end routers, I do not see the point other than for hack value.
If so you maybe have been able to get a drive emulator that can take modern storage devices in the front.
I've worked with connecting equipment that we super finicky on what was on the serial port, and after 2-3 tries, we gave up and just sourced an old machine with hardware serial. We only have a few old machines left!
IoT ain't seen nothin' yet.
[0] http://dmitry.gr/index.php?proj=07.+Linux+on+8bit&r=05.Proje...
https://www.youtube.com/watch?v=kTrOg19gzP4 seriously, seriously did my head in. I was certainly fascinated by this, but I fear that I'd contribute one character, accidentally put it in the wrong place, break the build for two days because nobody can figure out what broke, and then feel really bad for weeks afterwards.
(Okay, okay, diffing... but still. I'd break my own build, at least.)
I _am_ genuinely interested, and I'd LOVE to play with this, but I'm really, really conservative, and would far prefer to be a fly on the wall for a bit for a while first.
Tcl still has many unique features that other languages lack. One new highly experimental feature is TclQuadCode, which can compile Tcl to machine code using LLVM. It's been in progress for over 5 years and it is amazing work. Compiling a dynamic language is a difficult task.
The other floppy OS I tinkered around with was QNX, but it was just a demo of what QNX could do.
I remember Blender boasting for years about how it fit on a floppy.
Trinux was pretty slick back in the day.
Granted, this is pushing it, but I've been using this setup every day for almost two years. (I just like to use old hardware until it dies -- or, is this what old IPS-screened Thinkpads generally turn people into?)
Sure, you probably should be a "computational minimalist" by nature (e.g. there is an older version of Chromium, but I suppose your main browser will be Dillo -- which, actually, is just wonderful once you get used to it). But if you are a minimalist, I'd say it's a really solid system.
Also, it's fun for me to think that I bought this Thinkpad T42 three years ago for €20. And now I use it as my main workhorse in a field where typical setups consist of new-ish MacBooks with high-end SSDs and an up to date version of Pro Tools. (And where people occasionally still think that "duh, you can probably only edit a text file in Linux".)
So it's an awesome, clean, fairly easy to maintain distro (e.g. in case of a typical install you have a pristine system after every reboot). And the community is very friendly and responsive.
Nowadays I've found myself mostly using it for VNC to a slightly better machine (my old desktop, on permanent loan to a family member after their laptop broke. This works...). And... even on my not-great 802.11g, and the CPU even locked to 800MHz, typing this text over TigerVNC is literally realtime with no perceptible lag or delay. I'm honestly amazed. But anyway...
FWIW, launchpad.net have multiple sources providing the latest 32-bit builds of Chromium. These are built for Ubuntu, but I find they've worked 100% fine on Slackware. :P (After some work I even got the debugging symbols into the right place!)
(Nothing stopping you from building the world's largest LD_PRELOAD to pull in "enough Ubuntu" that Chromium boots, but I find that 100% unnecessary at this point.)
Some build daily(ish), some build fortnightly-to-monthly-ish. Before I set up VNC, I was in the process of figuring out an autoupdate script (CLI PHP, easily rewritten) that would find and fetch the packages off Launchpad. Let me know if you'd like a copy, I never finished it but I did do the Herculean bit of figuring out the magic API URLs, the rest is just boring scripting and downloading.
Protip. If you open 100-170 tabs (possible! on 2GB! with The Great Suspender), the main process will hit 4G VIRT. xD
Besides that, NetSurf is a bit better than Dillo, you're probably already aware of it.
What's tiny core's advantage over Alpine? Given the outsized interest in Alpine from the docker community, it may have better packages and security updates
A more apt comparison would be vs alpine standard which is 109 MB and contains a kernel.
I have a few old PCs sitting around, a Pentium 4D, a core duo or two. These are full-size PCs, old Dells and IBMs. It doesn't make much of a difference if they are running an 11MB distribution or a full Debian with GUI.
What I'd really like is a small form factor PC with full x86 support so that I can run DOS, or other PC oses, like the BSDs or BEOS. Ideally it would be the size of a Raspberry PI and cost the same. I know such systems are available, but the cost is an issue. Emulation just isn't the same either.
If you're making a hundred million of them, the marginal gains add up. There's no point in adding stuff you don't need.
In my mind the primary value is learning. The smaller the system the more likely I can understand how all the parts interact. Once a basic understanding is achieved you can start layering in more and still keep up.
Once you get a bit past that it's easy to create recovery media and other interesting boot tools.
I'm sure others can think of more but that's the first thing that I think of when I think of LFS, Tiny and to a lesser extent distros like Slackware that still tend to keep things relatively simple.
I think this is pretty much why. If you were to take your average hacker/maker, most of them would probably have a similar sentiment. However, most of them would also have a story about how they needed some tiny distro like TCL recently for some niche use case.
I myself needed a tiny distro recently. I had 22 rackmount servers with no HDD all on the same network, and I needed them to all run the same static binary. I realized like most Intel servers, with default settings, they will try to boot over the network with PXE. Wanting to not spend a day messing around with provisioning these servers, I decided I would just put a linux image on a USB stick, stick it in my OpenWRT router, and host it over TFTP. Serving a large image from a USB stick every time each of 22 servers started up was an unnecessary use of bandwidth and would often fail (I didn't have the best router). I also didn't need anything except a network stack and the ability to run a 64 bit static binary, so I did some research and ended up using the x86_64 version of TCL. Worked great! I'm sure tons of others have weird niche use cases for such a distro.
Of course, as my needs evolved, I ended up just using a minimal Arch linux image...