Exploring the Internals of Linux v0.01
seiya.me
seiya.me
- The project was highly successful or influential
- Freely available source code
- Ideally the bulk of the project was written by one person
So far my list includes Linux, the John Carmack id releases (wolf3d, DOOM, Quake), SQLite, and vim. Any others I'm missing?
Also, though this is not precisely what you’re asking for, The architecture of open-source applications and its sequels[8] have the original designers’ reflections on some well-known codebases.
[1] http://mirrors.ctan.org/info/knuth-pdf/tex/tex.pdf
[2] http://mirrors.ctan.org/info/knuth-pdf/mf/mf.pdf
[3] https://github.com/drh/lcc
[6] https://github.com/ForthHub/cmFORTH/blob/combined/cmforth.ft...
Wirth's "Compiler Construction" is very concise and written in a similar way: https://people.inf.ethz.ch/wirth/CompilerConstruction/ - he manages to describe a complete compiler for an Oberon subset (earlier versions of the book used PASCAL) in a bit more than 100 pages.
Since OBS Classic is now gone, I’d recommended anyone interested in programming video, audio and cross platform native apps to read through the current OBS Studio code base on GitHub.
https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca...
pw = getpwuid(getuid());
if (!pw)
usage("You don't exist. Go away!");
That's actually still the case. `git` is just a wrapper that when called as `git <command>` looks for `git-<command>` under `libexec/git-core/`.
You can add any command named `git-foo` into your PATH and then run it with `git foo`. For example, I have `git-gsr` which is a simple shell script that does a global search and replace in a git repo. I run it as `git gsr <old> <new>`
I needed to learn how a very specific OS thing worked and I read the code from Linux, openbsd, L4, hurd, minix, and a few other projects.
The openBSD kernel code was easiest to follow because it favored simplicity over all other things (improved security was just a byproduct).
For the record, the microkernels where hardest to follow despite having tons of books and a few experts nearby. But that's a whole different discussion
Projects with a maintainer who strictly enforces code style and quality would still fit the description. From what I've heard, OpenBSD falls under this category. I'll add it to my list.
Though honestly if you were gonna read a chess engine, might as well read modern Stockfish. You'll learn a lot about squeezing out every last cpu cycle and byte of memory, as well as parallelism in a non- "embarassingly parallel" problem domain. I recommend starting with the transposition table(ttable.cpp), since it's very self-contained.
GNU Emacs also comes to mind I suppose.
https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...
[0]: https://jvns.ca/blog/2023/08/03/behind--hello-world
[0]: https://web.archive.org/web/20130319041327/http://www-formal... - this is a link directly to the page that has eval on it, but the rest of the paper leading up to it is important to really understand what's going on.
But Russel basically hand-translated the calls into assembly code and got an interpreter out of it.
An interpreter written in Lisp cannot be executed if you don't already have an existing interpreter to run it.
The key insight that we can describe the interpreter in Lisp, and then somehow compile it into code belongs to Russel. Eventually it became possible to do that by machine: when you have a Lisp compiler, the Lisp-in-Lisp interpreter can be compiled by machine rather than by hand.
Bitcoin?
Redis?
Coreutils?
I would suggest MS-DOS: https://github.com/microsoft/MS-DOS
The distribution also includes Amake, a parallel version of Make.
For a simple but really rather elegant piece of code, I very much enjoyed reading the sources to abduco a while back.
I was thinking, maybe first version/commit of QEMU would be interesting to read.
I feel like we can be more (or less) flexible about the 'impact' and 'single author' criteria, but we _definitely_ need to be able to see the source :)
Actually the effect is that counter will exponentially decay up to 2 * priority (if the task is not runnable). You can sanity check this by looking at the limit: if counter is 2*priority then that expression will leave it at its current value.
Ha! It's been a long time since GCC was even able to compile older versions of _itself_.
It's just a product of the times.
The behaviour you want isn't "compile this version of Linux even though it has a bug", it's "compile this version of Linux as if you were a compiler at the time which accepted this broken code in this way", which is a very tall order, along the lines of bug-for-bug compatibility while also fixing the bug.
> This is an older release of GCC which we are going to install for the purpose of compiling the Linux kernel in Chapter 8. This version is recommended by the kernel developers when you need absolute stability. Later versions of GCC have not received as much testing for Linux kernel compilation. Using a later version is likely to work, however, we recommend adhering to the kernel developer's advice and using the version here to compile your kernel.
https://www.linuxfromscratch.org/museum/lfs-museum/5.0/LFS-B...
I wish I had a better reference. The bit about "compile this version of Linux as if you were a compiler at the time which accepted this broken code in this way" made me think of that.
A common mistake is expecting code that has undefined behavior to be compiled into something that makes logical sense.
You may disagree with it but that’s how compilers work and how the standard describes they should work.
'* For those with more memory than 8 Mb - tough luck. I've
* not got it, why should you :-) The source is here. Change
* it. (Seriously - it shouldn't be too difficult. ...'
Bill Gates, 1981: "640K ought to be enough for anyone..."
Linus Torvalds, 1991: "8MB ought to be enough for anyone..."
Jen-Hsun Huang, 2023: "144TB ought to be enough for anyone..."
:-) <g> :-)
(Disclaimer: The above quotes are written for comedy purposes only! The above individuals referenced probably didn't actually say those things! <g>)
> What? No.
> It always used tabs.
> And by "always used tabs" I mean "mistakes probably happened, and there may be spaces in some places", but afaik I've always used hard-tabs as the normal indentation.
> If you see something else, you probably have some archive that has been reformatted.
1 tab is 1 byte, 4 spaces is 4 bytes, so it doesn't actually work anyway.
And you can't rely on it being multiples of 4 anyway, so you'd have to iterate and check the bytes to check they are actually spaces.
So no, it's be slower, but not enough to matter.
Edit: or is the parent proposing the opposite? I sti hope they're being humourous as it still doesn't really matter
https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
Usually it will only contain the most important core features without a lot of abstractions/generalizations. So it is actually manageable to read through all of the code in a couple of days.
Reading the initial working versions of a successful project will inform you on how that project used to work. In a sense it’s akin to reading a working draft of a great piece of literature without reading the final product.
There was even a Howto for 4MB laptops.
If you wanted to run X confortabily, even with FVWM and RXVT, you needed 16MB.
Today I do the same with Gemini/Gopher/light HTTP pages and nsxiv to display the pictures and mpv+yt-dlp to watch videos/music/podcasts.
That on an Atom N270, which today is like having 4MB and a 386 back in the day in 1999.
- Use Luakit, set hardware-acceleration-policy to either always or never, just try.
- Setting an Android 4.x User Agent in Luakit will help, too. Often pages sent for phones/tablets are much lighter.
- git clone https://github.com.com/stevenblack/hosts ; cd hosts ; sed -n '/Start Steven/,$p' < hosts > hosts.new, append that hosts.new file to your current /etc/hosts file.
- MuPDF it's far lighter than Okular.
- Fluxbox + Rox + Zukitre GTK2/3 and Fluxbox theme can be far lighter than the whole DE. Ping me back for an easy setup.
* Books or articles to read? Hopefully with a hands-on and practical approach.
* Target environment: VM or real hardware, and what specifically?
VMs would be the most common target, but the Raspberry Pi is also quite popular.
Another common recommendation is to find a hackable existing OS/kernel. You already have a working OS, but you can inspect and rewrite portions without having to do everything yourself upfront. http://www.minix3.org/ seems to be a popular one. Various BSDs seem to be mentioned, as well.
Back in undergrad in the early 90s, our OS course was we spent the semester building a crappy x86 OS which could boot, run a couple of processes with basic I/O and simple signals and memory management. Even though it had nearly zero concepts relevant to modern OS's, it was so much fun. It didn't set me up in any way to be a serious OS designer, but it was the essence of programming a CPU and some devices, with nothing in between us. I'd love to experience that again. But I don't know where to find resources for the lowest levels: booting into a raw CPU and connecting directly to devices (including display and keyboard). To be sure, I can find plenty of OS texts on advanced memory and process management schemes and so on, but what about the lowest level?
Unfortunately, this isn't updated to work with current RISC V specs, so you will run into a number of problems which can be frustrating...
https://www.amazon.com/Developing-32-Bit-Operating-System-Cd...
``` printk("Kernel panic: %s\n\r",s); for(;;); ```,
could the for-loop be damaging to the CPU by over-utilizing a small portion over and over again, in terms of it heating up a tiny space on it?
I'd guess the physical CPU package of an i386 would cope just fine with the few (hundreds?) of gates toggling in that small loop.
I wonder if it might be possible to do on a modern FPGA, if you artifically create some unstable circuit and pack deliberately it in a corner of the die?
There's probably some AVX512 concoction that would be the closest equivalent on a modern X64. There's probably an easy experiment -- if that concoction makes CPU freq drop and also makes whole-package thermals drop, it /could/ be due to localized die heating.
https://www.semanticscholar.org/paper/MAGIC%3A-Malicious-Agi...
[1] http://www.cocoon-culture.com/lib/noise-report/external-docs...
i just had chat gpt generate said program and i think its very similar to what I wrote. I'm unsure if it ever did anything but i've always been interested in efficiency:
#include <stdio.h>
#include <windows.h>
void main() {
printf("Setting process priority to low...\n");
SetPriorityClass(GetCurrentProcess(), IDLE_PRIORITY_CLASS);
printf("Halting the processor when no other programs are running...\n");
while (1) {
__asm {
hlt
}
}
}I’m pleased to see the frequency and depth of the comments in the code too, makes it all very accessible.
Anyone managed to get it to compile?
I would love to see a graphical breakdown of how many lines of code, how many functions, etc are used for each major software module. Are there existing tools that do this?
I don't know what's the actual count of lines of code that I actually have on the kernel compiled on my specific x64 machine, but I think considering how many significant changes were made to the Linux kernel over the years, I don't think it's a victim of unnecessary bloat. The various virtualization features alone were industry changing features.
Some people might debate this :)
If not it might be interesting to fork it into a linux-zero-dot-zero-one project that merely tries to make minimal adjustments so it runs virtualized on modern hardware.