> 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.
I'd prefer if it were more letters. It bothers me when API designers omit random letters just to save a few keystrokes. These are particularly egregious because I keep forgetting which letters they kept. Is it "chk"? or "ckd"? or "chd"? or something else?
I wrote a portability library that wraps these with compiler intrinsic and standard C fallbacks. I chose to spell out the full word in addition to making the type explicit. It's a lot more verbose of course but a lot clearer to read:
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?