Vim

This video is the second part (0x1) of a series on writing an operating system. The creator, Raj, details the comprehensive studying and logging strategy he has designed to tackle this long-term project. The goal is to create a structured approach that fosters deep understanding, maintains motivation, and effectively manages the vast scope of the endeavor.

This video serves as an announcement and introduction to a new, long-term project: Operating System Development (OSDev). The creator, Raj, explains his motivations for taking on this formidable challenge, his plan for documenting the journey, and the tools he intends to use.

Why OSDev? The Motivation for a New Challenge

• [00:00:15] Raj explains he’s been feeling bored with typical software engineering projects, which often feel too easy, especially with the rise of powerful LLMs.
• [00:01:21] He was seeking a “formidable project” that would genuinely challenge him and couldn’t be easily solved by an AI tool.
• [00:03:00] A primary driver is a personal quest to feel competent. He believes that successfully building an operating system will cement his confidence as an engineer.
• [00:04:36] He wants to move beyond being a “hand-wavish” software engineer and gain a deep, fundamental understanding of the systems he uses daily, such as systemd.
• [00:05:43] The project also serves as an opportunity to get back into reading textbooks and explore “old-school” computing concepts, which he enjoys.

Project Plan and Documentation

• [00:02:40] The video series will be unstructured, presented as work logs and journals rather than polished tutorials. He compares the process to exploring an “open-world RPG.”
• [00:02:47] His entire journey, including notes and logs, will be version-controlled and publicly available in a GitHub repository.
• [00:10:48] He plans for a continuous, podcast-style format with at least one video per week (Saturdays), supplemented by shorter, micro-video updates for milestones to maintain a tight feedback loop with his audience.

Tooling and Workflow

• [00:06:21] Emacs will be the central hub for the project, used for coding, note-taking, journaling, and as an LLM client.
• [00:07:44] He will use Tmux for terminal management and work within an openSUSE Tumbleweed environment.
• [00:10:14] The project will involve programming in C and Assembly, which he sees as a return to the fundamentals of programming.

Channel Direction and Future Goals

• [00:09:44] Raj wants to shift his channel’s focus from showcasing tools in a “glass case” to demonstrating them in a real-world, complex application.
• [00:13:00] OSDev provides a natural, unforced use case to explore and evaluate different tools and programming philosophies.
• [00:11:15] He hopes the documented journey can serve as a guide for others who might want to start OSDev from scratch in the future.

Conclusion

Raj concludes by expressing his excitement for this new, challenging venture. He emphasizes that this project is as much for his personal growth and learning as it is for creating content. He plans to be much more regular with his uploads and invites viewers to follow along on this ambitious journey.

Getting a little pedantic with my doom configs¹ these days..

(defmacro generate-bindable-lambda (&rest body)
  `#'(lambda ()
       (interactive)
       ,@body))

;; .. the home row ..
(map! :map evil-normal-state-map
      "C-M-i p" (generate-bindable-lambda (insert "+"))
      "C-M-i n" (generate-bindable-lambda (insert "-"))
      "C-M-i u" (generate-bindable-lambda (insert "_"))
      "C-M-i e" (generate-bindable-lambda (insert "=")))

Maybe I should consider buying foot pedals.., and eye trackers (3 screens at the moment ) .., and setting up an array of interface sensors to truly begin exploiting emacs.., to the point of conducting an orchestra of text buffers.., somewhat musically (/ whimsically?)..

I’ve lately been thinking deeply about how I interact with my computing environments; when working, I’ve a
- an unrooted snapdragon ARM Android with Termux and Tmux for ephemeral vimmin & sshing around when on the move
- an Intel x86 FreeBSD home lab for some asynchronous compute that I don’t need right away and some redundancy for my important files
- a personal ubuntu VPS with a couple of intel x86 vCPUs for my self hosting endeavours and overall context orchestration
- several compute clusters (avx enabled x86s, ARM, “the propietary GPU driver guy on the street” GPUs, “the other open source GPU driver guy on the steet” GPUs, k8s orchestrated production & development playgrounds) for work
- an AMD x86 Tumbleweed with emacs as the daily driver where I actually “work” : this is desk where I dissect, analyse, reconstruct and dispatch for usage across the above

People have been responding to emacs and my beard.

For a while I thought I did not have a lot to say. Turns out a lot of other humans are quite interested in the much of the same things that I’m into: my hatred for the mouse, and the consequent love for efficient workflows being some of them.

I’ll give the people what they want: I get to enjoy esoteric tech and spread the word, growing a cult, while other humans have enlightened experiences (believe me I do talk like this in person) and continue propogating the techno-propaganda about enjoying computer science.

I recently shifted my operations to a thinkpad x13g4amd (Ryzen 7840U + 780M Radeon) and am using this transfer as an opportunity to realize and improve my work related habits.

GNU/Linux

All of my pipelines are based around Linux and the core GNU utils. I had to use windows for a while due to org-wide constraints but I’ve recently been given the signal to shift to linux.

I rarely used any windows native tools for my workflows and there was always a layer of linux emulation/virtualization (wsl, scoop, and the likes) upon which I conducted my usual operations. Given I use Debian at home, a non native linux experience was frustrating at best and depressing at worst. No more, do I have to confine myself.

I’ve been building up my vimrc again because emacs’ tramp mode just wasn’t cutting it when it came to speed for my remote work environments.

I’ve been a vim user for around 4 years now and having read some books partially and sampling a lot of blogs and conference recordings over this span, I decided I should commit and formally invest into a definitive resource to get me upto speed and beyond.

In memory of the author of vim, arguably the most influential programming utility ever…

Here is a paper : “ Seven habits of effective text editing ” by him that I hope continues to inspire programmers, as it did me when I was a novice.