2 ms·
It seems MenuetOS/KolibriOS haven't been mentioned yet - those aim for an ostensibly "complete" OS experience, albeit one that is very Spartan due to everything
by exikyut 5y ago
It seems MenuetOS/KolibriOS haven't been mentioned yet - those aim for an ostensibly "complete" OS experience, albeit one that is very Spartan due to everything being restricted to assembly language (which sadly also makes the platform completely nonportable away from x86).
http://menuetos.net/ http://menuetos.net/
https://kolibrios.org/en/ https://kolibrios.org/en/
Someone else mentioned Serenity, which is awesome IMO, and probably the surest bet in terms of something lightweight yet modern and relevant.
A long time ago I remember playing around with the Syllable OS, which got to a fairly decent level of development, but sadly fell apart. That one's sadly only interesting from a history perspective, but still fascinating to look at.
I definitely have to +1 the idea of playing around with things like LFS and Buildroot, although I'd suggest a gentler ramp-up by way of something like Slackware, which exposes a lot of low-level knobs and components that you can progressively pick up on as you go along. I incidentally got my start on Slackware on an ancient laptop with no Wi-Fi or Ethernet, installing from a partially corrupted CD. The net result was actually surprisingly awesome, I had no distractions or ADHD catnip to have to deal with, and enough packages installed that the base system more or less worked. It was just the programming stuff (gcc etc) that failed, haha. But... sed worked, and grep, and bash. And so it was that I wound up learning regular expressions pretty much inside out. It was remarkably easy because I had absolutely no distractions. It ended up working too well; the bulk of the package viewer/installer GUI I'd started writing was an entire screenful of regex at one point, and I had to give up because looking at it gave me a headache :/. But I've never had a problem leveraging grep or sed ever since.
I've also played around with booting Linux kernels with minimal initramfs images on relatively ancient hardware (Celeron/Pentium/Core2 class) and found you can generally boot an optimally-configured kernel in less than 1 second if you set the loglevel to 0 during early boot - printing dmesg to screen as the kernel boots is a necessarily synchronous operation, given that the text about what is happening next must by definition make it to the screen before the thing happens in order for the info to actually useful ("ok, so it crashed here"), and while scrolling VGA is trivially fast nowadays the time does still add up. Setting loglevel=0 doesn't disable the internal ring buffer, it just disables printing it to the screen, allowing everything to initialize and reach userspace in maybe 450ms on 10-15 year old hardware, and probably reasonably less on just about everything newer (haven't benchmarked my current machines). This leaves you plenty of room to play around in userspace (start X or Wayland, connect to Wi-Fi, etc) and go from there, and presents a fun full-stack optimal integration opportunity (if you like this sort of thing, look into kiosk systems). I've missed that sort of tweaking, been meaning to get back into it. It's genuinely fun. "Why, again, do I even need udev?" (I only start udev on my Slackware box if I absolutely need it.)