https://www.youtube.com/@offlinemark
This is my personal roadmap for my OS development project. It should not be confused with a roadmap for how to learn OS development!
Unlike money, learning doesn’t compound passively. If you learn something, then sit around, you don’t automatically get more learning.
Learning compounds in the sense that the more you learn, the easier it becomes to learn new things. Therefore your rate of learning increases over time, allowing you to learn more.
As you do more things, it allows you to do new things more easily, because you’ll already have done some fundamental building blocks. For example, it was easier for me to start an online clothing brand for fun, since I already have experience with graphic design and websites from past projects.
If I didn’t already have experience with graphic design, or setting up a website, it would have taken me much longer to set up the online clothing brand.
Additionally, the more you learn, the easier it is to create novelty. This is because it is much easier to generate novelty by remixing two things together, than by generating it from scratch. The more you have experience with, the more combinations you can remix.
libc++ is surprisingly hard to use for my kernel
I currently use libstdc++, but that’s the only GNU part of my toolchain left. I use LLVM for everything else (clang, compiler-rt, lldb, clangd…)
Here are a few screenshots of the additional porting work to make libc++ work
Libraries for freestanding C++ development:
Not freestanding, but interesting:
Yoga classes often end with “Shavasana”, which is a period of full relaxation, lying on your back.
When I first tried yoga, I disliked this. I didn’t understand it and thought it was a waste of time.
Now, it’s my favorite part. I actively look forward to the Shavasana period, after the sometimes-intense yoga practice.
I apply this is in my normal life too, now. After ending a hard work day or even just a hard work session, I take a moment to Shavasana (if not physically, then mentally). It doesn’t have to take a lot of time.
There’s a certain wisdom in the recognition that after a strenuous period, it’s good to explicitly block some time to decompress, unwind, and relax.
“Sharpening the saw” is a term from “The 7 Habits of Highly Effective People”.
I’m lucky enough to get time in my day job to do this. Here’s how I use that time, specifically:
This is the first priority during sharpening time. It means attending to natural breakages, accumulations of disorder & chaos.
Over time, systems naturally accumulate chaos. The work of maintenance is simply to bring a system back up to the status quo.
It does not mean going beyond to try to fundamentally improve a system (that comes later). However, sometimes it’s easier to replace a system instead of doing maintenance on it.
Examples:
Learning could mean learning to use my tools better, learning more about the codebase I work in, or more general learning that is still relevant to my daily work.
The idea here is to focus on key leverage points that amplify your ability to do the main workstream better.
If I use tools daily, learning to use them 1% or 5% better can yield impactful differences in what I can accomplish.
If I work in a codebase daily, improving my understanding of certain corners where I have shaky understanding can also be a force multiplier for how effectively I can work, and what kinds of projects I can contribute to.
Examples:
For example, if you were cleaning up your note taking system, maintenance would look like cleaning things up within the existing system, but wouldn’t go as far as deeper thinking about whether you should fundamentally change the system, switch products, etc.
That’s the thinking that comes in the Systems Improvement phase, where you go one level deeper and examine the system holistically and consider larger scale changes, repairs, or improvements.
Maybe the system doesn’t even exist, which is an outstanding liability.
Examples:
Innovation is taking time to explore new, experimental, or unconventional ideas that would never get prioritized into the main workstream. Nevertheless, these experiments can be significant points of leverage. (GMail came from Google’s “20% time”).
I checked out some hot new tools and here’s what I’m using:
A “new” terminal emulator. It’s supposed to be very fast and lightweight.
Why I’m using it:
My config:
theme = Dracula
font-family = Menlo
font-size = 14
font-thicken = true
keybind = global:alt+backquote=toggle_visibility
copy-on-select = true
macos-titlebar-style = tabs # No iterm2 compact mode equivalentIt’s a dark terminal color scheme. I like it.
If you ever wrote a Makefile just to conveniently run some commands, just is that but designed explicitly for this use case.
Benefits:
Downside: You can’t explicitly control parallelism with -j. You can only use a [parallel] annotation in the justfile.
A better version of EasyMotion, vim-sneak, hop, leap etc. Jump to any character on screen immediately. Also has LSP support.
There is an unofficial VSCode extension too.
Easily jump around directories.
Been using this for a while, but an extremely powerful git client. Ideal tool for rebasing and cleaning up branch history.
Not-new parts of my setup I continue to use:
Here’s how I successfully asked for feedback from a colleague at work recently.
In the past, I sent such an email without the self-evaluation attached, or worse, with a long list of specific feedback questions I wanted answered.
The self-evaluation + call strategy works well because it reduces the amount of creative energy the feedback giver needs to spend.
Rather than reflecting from scratch on your performance (which they may not even have close to mind), they have a set of initial prompts which might spur ideas.
Doing your own self-evaluation also shows that you’re self-aware of your own weaknesses.
Making some “critical” comments about yourself can make it easier for a colleague to give feedback that they might be shy about. They might not want to sound negative, and might be reluctant to bring something up, but if you were able to anticipate it and “pre-critique” yourself, that makes it easier for them to agree and possibly elaborate on the topic.
An important thing to note about the GPLv3 is that it is not just an incremental improvement or modernization of the GPLv2, contrary to its name.
It’s effectively a different license that’s even one level stricter than the GPLv2 in a substantial way.
In addition to the base requirements of the GPLv2 for releasing source code for distributed binaries, it goes one step further and requires that modified binaries can be installed onto the hardware that distributed the original binaries.
Unlike simple release of source code, this has engineering implications for hardware manufacturers. It prevents “locked down” devices and forces devices to be open and reprogrammable. “Tivo-ization” is a term referring to the practice of “locking down” a device, which is often used in discussions around GPLv3.
This is why Linus Torvalds refused to adopt GPLv3 for Linux, because in his view, this was going too far.
So if you’re in the market for a copyleft OSS license, keep in mind that GPLv3 is not automatically the best fit, and should not necessarily be automatically used over GPLv2 just because it’s the newest version in the “GPL series”.
It represents an additional step of strictness on the restrictiveness scale. If you’d like distributors to release source code, but don’t necessarily need them to make their devices openly programmable, GPLv2 is still the license to use.
Resources: