Creating purpose-built TinyCoreLinux Images

These kinds of tools are very relevant when creating Docker base images - not all of us can afford to download 1.6GB just for Ruby. See the official Ruby baseimage vs Alpine + ruby package for example

Supermin seems quite old. Perhaps an idea that has passed?

Supermin solves a narrow case: how to distribute an appliance [Linux-based OS disk image] as a very small download (typically 100K - 1MB). It works by observing that the end user already has the files they need as part of their host Linux OS (eg. /bin/bash, /lib/libc.so), and the distribution is just a skeleton of the disk image, which is "filled in" on the end user's machine by copying the host files in at the last second.

So it's not really applicable here, although I understand people use supermin to build chroots for Docker (as the author of supermin, I wouldn't necessarily recommend doing that unless you understand the limitations).

What is actually needed here is libguestfs, which is a pure userspace tool for building disk images that doesn't require root access and is built for scripting/automation and security. We have a tool built on top of libguestfs called virt-builder which specifically churns out minimal Linux distros very quickly.

Sadly virt-builder can't build TinyCore Linux yet, although it probably should be extended to do that. It would be a lot simpler to use virt-builder, than to go through the tedious and dangerous steps outlined in the article.

http://libguestfs.org/

http://libguestfs.org/virt-builder.1.html

I am with mwcampbell. There's something to say for the minimalism/lack of dependencies - even if it is not much more complex to use nbd. You don't need qemu to create a sparse file, mount it as a loopback device and manipulate it as a new device from there. If someone needs a qcow2 file afterward, fine. But that doesn't /need/ to be involved in the build step.

Aren't these images typically built on designated build machines anyway? Sure you've got to develop it locally. But the majority of developer-consumers will get it from some distributor fed from a build machine.

The diffing is still a great point. I did not know that about qcow2 images. Do you have any articles then on incremental builds with .qcow2 images?

When I've done this sort of thing in the past, the ability to work with a set of staged partial images was a very mixed blessing. It ended up being over-complicated and rarely taken advantage of. I've settled on local package repositories and a single image build step which compiles everything together.

The latter problem you describe, that of needing to be root, goes away if you don't use a loopback device but instead use a mountable filesystem image. `truncate -d1G os.img && mkfs.ext3 os.img && mount os.img mountpoint/` doesn't need root at any point.

a test / development environment inside the browser where a server is emulated for testing purposes too, accompanied with a code editor.

I d like to describe the vm configuration similar to chef or ansible in js and run some dev/test code.

Depending what you want to do, there is also the OR1K Emulator running Linux - http://jor1k.com and a generic x86 emulator - v86 - https://github.com/copy/v86

you can check a small benchmark here: https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-e...

via https://news.ycombinator.com/item?id=10498305

You're in the right ballpark. I ported a network monitoring app to Linux and helped bring Linux up on a custom board a long time ago, and that device had 4MB for the kernel, shell/utilities and the application itself. It fit nicely.

Not useless, it's a useful thing to have when you're trying to learn how to write Hello World as an OS - http://wiki.osdev.org/Bare_Bones

Are there any bootloader specs that are standard across architectures? UEFI comes to mind, and I'm sure you could boot an x86 board via u-boot.