> Current F13 expansion cards will pull out sometimes
Just echoing what others have said here: I'm typing this on an original F13 I think from batch 6 which has had many upgrades but not the bottom cover. I have never had an expansion card pop out accidentally. I can't imagine that happening considering how difficult they are to remove. I usually have to lay the laptop flat upside down and use my multitool while holding the button to push a card out.
My wife has an F12 and she has also never had one pop out accidentally. Unlike mine, hers has locking switches to keep them in place, but even with the switches open they're pretty hard to remove.
Is it possible there was an intermediate redesign at some point that made them too easy to remove before they landed on the latest design?
The 5x5 is very nice, and the 3x5 isn't bad either. Unfortunately neither of them have all of ASCII. The size is also a bit misleading because you need to add spacing so really they need a 6x6 or 4x6 grid.
It has a 5x8 font which has all of ASCII, but most glyphs are actually 4x8 and include horizontal spacing. I modified it to reduce the rest for a project I'm doing so all glyphs are 4x8. The result can be rendered on a 5x9 grid with a guaranteed line of horizontal and vertical spacing between all glyphs. It's very nice.
One of the VMs I wrote for Onramp is in POSIX shell [1]. This was intended to make C bootstrappable on any POSIX system of any architecture with nothing besides the shell. Unfortunately it's about 100,000x too slow to be useful. It's also at least as complicated as a machine code VM. I've since mostly abandoned the POSIX shell idea.
Onramp does have a very simple C89 VM though, and its purpose is for bootstrapping modern C on systems that have only a basic C compiler [2]. So this c89cc.sh could in theory work. I tried it and unfortunately it doesn't quite compile yet (and doesn't give a comprehensible error message either.) Even if it worked, c89cc.sh only compiles to x86_64 ELF, and it's way more complicated than the x86_64 ELF machine code Onramp VM [3].
This has been a bit of a recurring theme with Onramp: anything I've tried to get away from the initial machine code stages ends up being more complicated than handwritten machine code. Still, it's nice to have a lot of different ways to bootstrap. I love seeing projects like this and I'm glad to see more people taking bootstrapping seriously.
These filesystems are not really alternatives because mdraid supports features those filesystems do not. For example, parity raid is still broken in btrfs (so it effectively does not support it), and last I checked zfs can't grow a parity raid array while mdraid can.
I run btrfs on top of mdraid in RAID6 so I can incrementally grow it while still having copy-on-write, checksums, snapshots, etc.
I hope that one day btrfs fixes its parity raid or bcachefs will become stable enough to fully replace mdraid. In the meantime I'll continue using mdraid with a copy-on-write filesystem on top.
I put my original mainboard in one of these when I upgraded. It's fantastic. I had it VESA-mounted to the back of a monitor for a while which made a great desktop PC. Now I use it as an HTPC.
Indeed, a decent closed hash table is maybe 30 lines. An open hash table with linear probing is even less, especially if you don't need to remove entries. It's almost identical to a linear search through an array; you just change where you start iterating.
In my first stage Onramp linker [1], converting linear search to an open hash table adds a grand total of 24 bytecode instructions, including the FNV-1a hash function. There's no reason to ever linear search a symbol table.
Oh, amazing! I've heard of DuskOS before but I didn't realize its C compiler was written in Forth.
Looks like it makes quite a few changes to C so it can't really run unmodified C code. I wonder how much work it would take to convert a full C compiler into something DuskCC can compile.
One of my goals with Onramp is to compile as much unmodified POSIX-style C code as possible without having to implement a full POSIX system. For example Onramp will never support a real fork() because the VM doesn't have virtual memory, but I do want to implement vfork() and exec().
Indeed! An eventual goal of Onramp is to bootstrap in freestanding so we can boot directly into the VM without an OS. This eliminates all binaries except for the firmware of the machine. The stage0/live-bootstrap team has already accomplished this so we know it's possible. Eliminating firmware is platform-dependent and mostly outside the scope of Onramp but it's certainly something I'd like to do as a related bootstrap project.
A modern UEFI is probably a million lines of code so there's a huge firmware trust surface there. One way to eliminate this would be to bootstrap on much simpler hardware. A rosco_m68k [1] is an example, one that has requires no third party firmware at all aside from the non-programmable microcode of the processor. (A Motorola 68010 is thousands of times slower than a modern processor so the bootstrap would take days, but that's fine, I can wait!)
Of course there's still the issue of trusting that the data isn't modified getting into the machine. For example you have to trust the tools you're using to flash EEPROM chips, or if you're using an SD card reader you have to trust its firmware. You also have to trust that your chips are legit, that the Motorola 68010 isn't a modern fake that emulates it while compromising it somehow. If you had the resources you'd probably want to x-ray the whole board at a minimum to make sure the chips are real. As for trusting ROM, I have some crazy ideas on how to get data into the machine in a trustable way, but I'm not quite ready to embarrass myself by saying them out loud yet :)
Author here. I think my opinion would be about the same as the authors of the stage0 project [1]. They invested quite a bit of time trying to get Forth to work but ultimately abandoned it. Forth has been suggested often for bootstrapping a C compiler, and I hope someone does it someday, but so far no one has succeeded.
Programming for a stack machine is really hard, whereas programming for a register machine is comparatively easy. I designed the Onramp VM specifically to be easy to program in bytecode, while also being easy to implement in machine code. Onramp bootstraps through the same linker and assembly languages that are used in a traditional C compilation process so there are no detours into any other languages like Forth (or Scheme, which live-bootstrap does with mescc.)
tl;dr I'm not really convinced that Forth would simplify things, but I'd love to be proven wrong!
That might be rather more difficult than you might expect. Advent of Code uses quite a lot of 64-bit numbers. A bit of googling tells me C64 BASIC only supports 16-bit integers and 32-bit floats. I imagine the other BASICs have similar limitations.
I did 2023 Advent of Code with my own compiler and this was the biggest challenge I ran into. I only had 32-bit integers at the time so I had to manually implement 64-bit math and number formatting within the language to be able to do the puzzles. You would probably have to do the same in BASIC.
The current version of rustc may compile itself quickly, but remember, this is after nearly ten years of compiler optimizations. Older versions were much slower.
I seem to recall complaints that old rustc would take many hours to compile itself. Even if it takes on average, say, two hours to compile itself, that's well over a week to bootstrap all the way from 0.7 to present. You're right that months is probably an exaggeration, but I suspect it might take a fair bit longer than a week. The truth is probably somewhere in the middle, though I suppose there's no way to know without trying it.
The minimum tool that bootstrapping projects tend to start with is a hex monitor. That is, a simple-as-possible tool that converts hexadecimal bytes of input into raw bytes in memory, and then jumps to it.
You need some way of getting this hex tool in memory of course. On traditional computers this could be done on front panel switches, but of course modern computers don't have those anymore. You could also imagine it hand-woven into core rope memory for example, which could then be connected directly to the CPU at its boot address. There are many options here; getting the hex tool running is very platform-specific.
Once you have a hex tool, you can then use that to input the next stage, which is written in commented hexadecimal source code. The next tool then adds a few features, and so does the tool after that, and so on, eventually working your way up to assembly and C.
It can be difficult to explain why bootstrapping is important. I put a "Why?" section in the README of my own bootstrapping compiler [0] for this reason.
Security is a big reason and it's one the bootstrappable team tend to focus on. In order to avoid the trusting trust problem and other attacks (like the recent xz backdoor), we need to be able to bootstrap everything from pure source code. They go as far as deleting all pre-generated files to ensure that they only rely on things that are hand-written and auditable. So bootstrapping Python for example is pretty complicated because the source contains code generated by Python scripts.
I'm much more interested in the cultural preservation aspect of it. We want to preserve contemporary media for future archaeologists, for example in the Arctic World Archive [1]. Unfortunately it's pointless if they have no way to decode it. So what do we do? We can preserve the specs, but we can't really expect them to implement x265 and everything else they would need from scratch. We can preserve binaries, but then they'd need to either get thousand-year-old hardware running or virtualize a thousand-year-old CPU. We can give them, say, a definition of a simple Lisp, and then give them code that runs on that, but then who's going to implement x265 in a basic Lisp? None of this is really practical.
That's why in my project I made a simple virtual machine, then bootstrapped C on top of it. It's trivially portable, not just to present-day architectures but to future and alien architectures as well. Any future archaeologist or alien civilization could implement the VM in a day, then run the C bootstrap on it, then compile ffmpeg or whatever and decode our media. There are no black boxes here: it's all debuggable, auditable, open, handwritten source code.
While it is technically possible to bootstrap Rust from Guile and the 0.7 Rust compiler, you would need to recompile the Rust compiler about a hundred times. Each step takes hours, and you can't skip any steps because, like he said, 1.80 requires 1.79, 1.79 requires 1.78, and so on all the way back to 0.7. Even if fully automated, this bootstrap would take months.
Moreover, I believe the earlier versions of rustc only output LLVM, so you need to bootstrap a C++ compiler to compile LLVM anyway. If you have a C++ compiler, you might as well compile mrustc. Currently, mrustc only supports rustc 1.54, so you'd still have to compile through some 35 versions of it.
None of this is practical. The goal of Dozer (this project) is to be able to bootstrap a small C compiler, compile Dozer, and use it to directly compile the latest rustc. This gives you Rust right away without having to bootstrap C++ or anything else in between.
It is true that there are many layers of code below the OS level. UEFI for example is probably hundreds of thousands of lines of compiled code. Modern processors have Intel IME and equivalent with their own secret firmware. Almost all modern peripherals will have microcontrollers with their own compiled code.
These are all genuine attack vectors but they are not really solvable from the software side. At least for Onramp I consider these problems to be out of scope. It may be possible to solve these with open hardware but a solution will look very different from the kind of software bootstrapping we're doing.
The team at bootstrappable.org have been working very hard at creating compilers that can bootstrap from scratch to prevent this kind of attack (the "trusting trust" attack is another name for it.) They've gotten to the point where they can bootstrap in freestanding so they don't need to trust any OS binaries anymore (see builder-hex0.)
I've spent a lot of my spare time the past year or so working on my own attempt at a portable bootstrappable compiler. It's partly to prevent this attack, and also partly so that future archaeologists can easily bootstrap C even if their computer architectures can't run any binaries from the present day.
It's nowhere near done but I'm starting a new job soon so I felt like I needed to publish what I have. It does at least bootstrap from handwritten x86_64 machine code up to a compiler for most of C89, and I'm working on the final stage that will hopefully be able to compile TinyCC and other similar C compilers soon.
> That’t not "doing sketchy shit with people's data"
Of course it is. If you add AdSense to your website you are letting Google track your users in exchange for a cut of the profits. Of course you should have to warn your users that they are being tracked at the very least.
I was definitely hoping for a look at modern compilers. This article was written last month, yet its history ends with the release of LLVM. There's quite a lot of development in small C compilers lately!
- TinyCC, SCC (Simple C Compiler) and Kefir are all fairly serious projects in active development.
- QBE is a new optimizing backend much simpler than LLVM; cproc and cparser are two of the C compilers that target it, in addition to its own minic.
- There's the bootstrapping work of stage0, M2-Planet, and mescc.
- chibicc is an educational C compiler based on the author's earlier 8cc compiler. The author is writing a book about it.
- lacc is another simple compiler that works well, although development appears to have stalled.
I think a lot of these projects are inspired by the problem that GCC and Clang/LLVM are now gigantic C++ projects. A pure C system like OpenBSD or Linux/musl/BusyBox ought to be able to compile itself without relying on C++. We really need a production quality open source C compiler that is actually written in C. I'm hopeful one of these compilers can achieve that someday.
Just echoing what others have said here: I'm typing this on an original F13 I think from batch 6 which has had many upgrades but not the bottom cover. I have never had an expansion card pop out accidentally. I can't imagine that happening considering how difficult they are to remove. I usually have to lay the laptop flat upside down and use my multitool while holding the button to push a card out.
My wife has an F12 and she has also never had one pop out accidentally. Unlike mine, hers has locking switches to keep them in place, but even with the switches open they're pretty hard to remove.
Is it possible there was an intermediate redesign at some point that made them too easy to remove before they landed on the latest design?