if you want to go really minimalistic, see stage0, it's like 500 Bytes
https://github.com/oriansj/stage0
details are in the article
I considered using Guile as the scripting/extension language in some of our tools, but I couldn't get over the large size and the number of additional dependencies it introduced.
There's a certain irony to the idea that Guile was designed to be a TCL killer, and wound up being larger and harder to deploy.
Code injected into the monitor can do the next best thing, a similar program that loads text files with hex into binaries and skips ends of lines after a comment marker starts.
As such, the initial stuff in the stage0 project is further programs that are still in my view blobs, but instead of binary blobs they're plain text hex blobs with comments documenting the assembler equivalent and what's going on.
From there there are iterations of having hex files (hex 1 and hex2) with increasing complexity of symbol tables so references can be made to addresses and relative jumps by symbols.
From there stage0 project makes the leap to "stage1" and there are things like basic editors, file concatenation tools, macro based assembler and so . It all ends with a C-subset (M2-planet) compiler written in assembler.
Work is in progress to rewrite the scheme interpreter mes in M2-planet instead of normal C. The c compiler mescc (written in scheme) can build tcc and onward to gcc.
There's bootstraps along these lines for a fantasy machine called knight and there's x86 versions and maybe some other archs in the works.
My stalled side project is interpreting the knight stuff in python: https://github.com/markjenkins/knightpies
I'm excited by the idea that I could use really old GNU/Linux distro CDs that I trust with python2.3+ as a bootstrap path and eventually with some other work even use old power macs with MacOS X that included python2.3+ as another cool place to bootstrap the free world.
The GNU build system was huge since about forever.
Of course, this can be stripped down a lot if you decide to taylor the kernel to your system (less drivers, etc).
To answer GP, a full texlive installation takes around 2GB on my system. That's mostly fonts, but also packages, tools and documentation. I take the bloat for convenience, because I can afford a few extra GBs nowadays. If you want to go for minimalism, you still can (and even reach smaller footprints than back then), but that's no longer the mainstream option. Not when a GB is a few cents.
> Our goal is to provide a practical 100% free software distribution of Linux-based and other variants of GNU, with a focus on the promotion and tight integration of GNU components, and an emphasis on programs and tools that help users exert that freedom.
Hurd itself has interesting concepts, like translators. And it might be useful in some specific cases where robustness is needed. But you might as well try MINIX 3.
Hurd is on my list of things to try, just like Plan 9.
[1] (edit): https://en.wikipedia.org/wiki/GNU_Hurd#GNU_distributions_run...
Anyone at Apple have a beef with the FSF back when they named that?
Is there not a tool that does this for you automatically? That'd be kind of neat! Like a webservice that takes your lspsci/lsusb output, then gives you a compiled kernel just for you back?
800x600 16 bit backgrounds and 16x16 16 bit icons...
> sounds
MIDI sounds...
We're not living in 1995, anymore.
JPG was released in 1992, GIF in 1987.
Also, as far as I know even stuff like compilers (if they want to support Unicode fully) have to pull in dependencies like ICU, which because of its symbol DB weighs about 30MB.
That's another problem Win 95-era software didn't have to care about...
Pretty sure sounds in Win95 were MIDI, which aren't even actual audio files.
And no, Win95 did include real audio files (if small).