Guix Reduces Bootstrap Seed by Half
guix.gnu.org
guix.gnu.org
800x600 16 bit backgrounds and 16x16 16 bit icons...
> sounds
MIDI sounds...
We're not living in 1995, anymore.
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...
JPG was released in 1992, GIF in 1987.
Pretty sure sounds in Win95 were MIDI, which aren't even actual audio files.
And no, Win95 did include real audio files (if small).
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.
Anyone at Apple have a beef with the FSF back when they named that?
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...
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?
if you want to go really minimalistic, see stage0, it's like 500 Bytes
https://github.com/oriansj/stage0
details are in the article
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.
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.
The GNU build system was huge since about forever.
Maybe starting from something like an Arduino is a better route for that.
(Ken Thompson coined the term and knows how to do it.)
If you implement your bootstrap C compiler entirely in machine code for instance, it doesn't matter if the "original C compiler" is compromised, since it's not being compiled.
Relying on security through obscurity is bad, but you need some obscurity.
Passwords and keyfiles are ultimately a form of security through obscurity.
I'd be curious to learn more about this.
I'm ruminating on the potential for "regular" electric signals to carry quantum information, that's the next aspect of security to consider with quantum around the corner.
So don't worry, there are and will be bigger things to worry about.
Isn't that pretty unlikely even if all the compilers are uncompromised?
Debian is currently sitting at around 93% of packages being reproducibly built. NixOS is close to 99% of the minimal install image set (https://r13y.com/).
- is deterministic,
- does not invoke undefined behavior, and
- was correctly compiled by the original compilers.
I worked on a contract for about a year and a half on a subproject of the research program described in this New York Times article:
https://www.nytimes.com/2012/10/30/science/rethinking-the-computer-at-80.html
The organizing principle was that every piece of code and data was owned by a well-defined system entity with well-defined permissions that were proven correct both statically and dynamically. For example, sending data to an endpoint that did not have the required authorization to receive it was a type error.
The thinking was that the state of the art is so broken (from the point of view of data integrity and security) that it's necessary to start from scratch. The overarching project name, appropriately enough, was "Clean Slate".
I don't know what they're up to now.
I like the work, but I still don't think the kind of attack mitigated here is practical. OTOH it's nice to have the option (if I was to build/publish my own distribution I would use this as my trust anchor, plus some ancient hardware and Linux 2.4 CDs to build my own bootstrap environment; though as a random guy on the internet I am probably less trustable than e.g. the Debian people).
1. I believe icecat is going to update pretty soon to version 68 to track with the latest esr, so perhaps in a week or so please check the main channel for an icecat version that should work with most, if not all, up to date extensions.
2. If I do get Firefox built and packaged then I’ll be more than happy to add it to the nonguix channel. Though I’m strongly considering just creating an unofficial icecat that keeps up with the latest version of Firefox like icecat on windows does. We’ll see what happens after these tears dry.
Icecat is really just a set of scripts to strip out branding from Firefox and packages it with gnu shit, though the gnuzilla project provides the esr version for convenience.
I wrote up a general guide here along the way: https://gitlab.com/rendaw/blog/blob/master/how_to_guix_for_t...
it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.
> The Guix development branch we just merged introduces a reduced binary seed bootstrap for x86_64 and i686