On July 24th, I received an email from srcmgr@ informing me that I had been granted a src commit bit. After that, the FreeBSD accounts team created a freefall.FreeBSD.org account and a FreeBSD email address (mchoo@) for me. Then, I created patches for src and doc to complete the steps for new committers. They landed in the FreeBSD repositories yesterday (src, doc).

As I had an issue with my current PGP key, I created a new one and updated my about page to reflect it. This is my third PGP key. My first one was RSA 4096, and I created a new one a year ago because of the Ed25519 hype. It was stored on a YubiKey, but I forgot to back up the original master key. The key was moved to the YubiKey permanently, where keys are writable but not readable for security. After realizing this recently, I created a new Ed25519 PGP key.

This time, I not only backed up the original master key, but also created separate subkeys for authentication, encryption, and signing. I issued revocation certificates for the RSA 4096 key and the first Ed25519 key so that I can announce that they are no longer in use and prevent others from tampering with them. I hope this is the last time in my life that I have to create a new PGP key and revoke the old one.

Lastly, I would like to thank everyone in the FreeBSD community who has helped me on my journey to becoming a committer, especially Ed Maste (emaste@), Warner Losh (imp@), and my mentor, John Baldwin (jhb@).

The renderer project now has the Metal backend, and I used metal-cpp to wire it up with GLFW (I'll explain later why metal-cpp is painful). At first, I was leaning towards starting with Metal 3 and then transitioning to Metal 4, because Metal 4 is more verbose and gives more optimization opportunities like Vulkan, but since I didn't have enough time, I decided to start with Metal 4 right away. Then I created a project which is a native macOS application with MetalKit. This is the base template I will use over the metal-cpp one, for the reasons I will mention later.

For the renderer project, I asked Claude to write the whole backend first so I could see how Metal works. Then I read several resources on Metal 3+ and overhauled the code to reflect those. For the native application, Claude wrote everything other than Renderer.swift. After I made an initial version of Renderer.swift, I asked Claude to make it use native Swift syntax because my Swift code was in a C++ style. Unlike the Vulkan backend, I handwrote most parts of the code this time because I enjoyed writing Metal code, but due to time constraints like FreeBSD scheduler improvements and final exam preparation, I had to leave the rest to Claude and move on.

Favourite things about Metal

The first thing that impressed me was the API. Compared to OpenGL and Vulkan, everything was straightforward and easy to remember. Metal 4 became more verbose compared to the previous versions, but it’s still nowhere close to Vulkan when it comes to verbosity and boilerplates. It offers most of the optimization opportunities that Vulkan does and still has better ergonomics and design. I also love the Metal Shading Language (MSL). To me, it looks even better than Vulkan’s Slang.

The tooling around Metal is also nice. Xcode’s Metal debugger and Instruments’ Metal System Trace are fantastic tools to work with Metal. The fact that I can integrate SwiftUI without extra rendering logic is another advantage over other graphics APIs that need GLFW. The ImGui rendering logic has always required too much extra code, while SwiftUI provides sharper fonts and a more native-feeling design.

These easy-to-use GUI tools help me save time otherwise spent studying old and complicated debugging and tracing tools for other graphics APIs and operating systems. This is a huge plus for me because I’m not planning to pursue graphics programming as a job but just as a hobby, and I’m already busy with my university studies and FreeBSD work.

Don’t use metal-cpp

Apple provides C++ Metal headers for video game developers, where C++ is the dominant language. However, there are a few shortcomings that I encountered while developing.

First, the integration with window libraries like GLFW is bad. If I remember correctly, Apple used to provide essential functions for getting CAMetalLayer through metal-cpp-extensions obtained from the Learn Metal with C++ sample code. Now those functions are omitted from the header, so people have two choices left: either fetching the old headers from a random GitHub repository or writing their own objc_msgSend hack to interact with Objective-C code from C++. Neither is ideal.

Second, the API isn't written in a C++ style; it feels like they transcribed Objective-C to C++. For example, descriptors are initialized by MTL*Descriptor::alloc()→init(). You need an NS::AutoReleasePool around the render loop, and it becomes more obvious that you are writing Objective-C in a C++ file. If your company already has an established C++ coding style, metal-cpp will keep being the special one that stands out from the rest of the code, adding to the burden of both reading and writing.

When I started the native Metal application project, I could immediately tell that the developer experience was way better on Swift with Xcode. Not only did I not need to care about allocations, but Xcode's tab suggestions were also way superior to CLion's. I could call the Metal debugger right away without locating an external executable, and everything felt so smooth. So please, unless you have an outstanding reason to avoid Swift or Objective-C and need pure C++, I recommend going with them and forgetting about metal-cpp completely.

Conclusion

What I expect from my graphics projects is very simple: just real-time rendering where I don’t need to spend too much energy on the technical side. As I said before, I just want to visualise atmospheric and space environments for my own interest, so being cross-platform or microtuning through low-level APIs like Vulkan is not that important. All I want is that when my work is over and I’m lying on the sofa, I can just prototype stuff on my MacBook and be happy with the visual itself.

In this scenario, OpenGL’s design was archaic. None of my machines had a Windows installation. I tried Vulkan, but it was too painful. WebGPU is still immature and no one knows when the spec will be finalized. Then I tried Metal, and I was very satisfied. Although metal-cpp was hard to use, the native Swift API was good enough. The tooling around the Metal API, such as the Xcode Metal debugger and Instruments, was very satisfactory. Because of this, there is no reason for me to choose a graphics API other than Metal.

I’m not saying everyone should use Metal. For beginners, there are way more resources around OpenGL, and I think it will be the same for a while, as it’s the only cross-platform API that is accessible to beginners. Some might prefer Vulkan because it provides opportunities to squeeze maximum performance out of a GPU. Some might use Direct3D because it has good integration with the Windows ecosystem, like the Win32 API and the PIX debugger. But to me, it seems like ease of use is the most important thing, above all those attractive features.

Resources

The following are the resources I used for the projects:

• Learn Metal with C++ (This one is very outdated, but it’s the only metal-cpp resource from Apple)

• Getting started with Metal-cpp

• Apple Metal Documentation

• Discover Metal 4

• Drawing a triangle with Metal 4

• Getting Started with Metal 4 and sample code

A few weeks ago, I found an article on rendering the atmosphere and the universe. Because I have been interested in graphics programming, specifically real-time rendering for games, since high school, I decided to do some graphics projects in the future. As I'm transferring to mathematical physics, I thought it would be nice to visualize physical phenomena such as the bending of light around a black hole, or realistic rendering of the Earth and the universe, using a graphics API.

Since I have already learned the basic concepts of real-time rendering and OpenGL usage through LearnOpenGL, I wanted to go on with a "modern" graphics API for two reasons. First, most OpenGL resources are written with GLSL and binding APIs, and I hate those two. Secondly, even though there are SPIR-V and Direct State Access in OpenGL 4.6, my MacBook doesn't support the latest OpenGL specification, as macOS ceased updating its OpenGL implementation at OpenGL 4.1 and moved to Metal a decade ago.

The first candidate was DirectX 11/12. They have great tooling backed by Microsoft, tons of resources online, and have been battle-proven for more than a decade. But they're Windows-only, and I removed all my Windows installations a few months ago because I hate Windows 11, so I didn't pick DirectX 11/12.

The second candidate was Vulkan. It's cross-platform, a choice of open-source enthusiasts, and supports a niche shader language called Slang. I had such high expectations because it was the successor to OpenGL, but eventually it disappointed me a lot while I was learning it. I wrote a glTF model renderer with multiple backends (OpenGL, Vulkan, Metal coming soon) to compare how these APIs work and choose one for my future projects. In this blog post I will show why I was disappointed by Vulkan.

Before I start criticizing Vulkan, I want to note that the project was heavily written by an LLM, although I had to modify a lot of code (I will discuss this in the bonus section). So if you are an LLM-paranoid person who believes that what I wrote here can't be trusted just because I didn't write the whole code myself (i.e. you can't learn if an LLM wrote some of your code), close this window. Seriously, reading this article will be a waste of time for you. The sole goal of the project was comparing the ergonomics of different graphics APIs, and I used an LLM because not only did I not have much time (I have a bunch of scheduled work right now), but it turned out that Vulkan is painful to write and I would have faced burnout without the LLM's help. When I need to practice a graphics API in the future, either for a job or research, I will rewrite this from scratch.

Tooling issues

I went through so many tooling issues with Vulkan. The Khronos Group is a typical example of a high school or university group project. Everyone wants their project to succeed, but no one wants to put in maximum effort. DirectX and Metal don't have this problem because Microsoft and Apple have full responsibility for managing their APIs.

The first issue is the Vulkan SDK. I encountered a bug in the Slang CMake config shipped by the SDK, where project configuration fails because the Slang CMake config points to the wrong directory. I found a bug report on the issue tracker and the maintainer acknowledged that this is a regression in the latest release. This is good, but the problem is this: the maintainer said the issue will be fixed in the next SDK release. What? There is a misconfigured CMake file that basically makes all projects depending on Slang fail, and the fix will come in the next release, which will arrive in a few months? I was quite surprised that they didn't make a patch release for this regression, so I had to write a hack in my CMakeLists.txt file to work around this issue.

The second issue is the graphics debugger. The de facto debugger for OpenGL and Vulkan is RenderDoc, a piece of software maintained by an individual. I encountered an issue where RenderDoc couldn't capture a frame on Linux, and it turned out that I hadn't built with XWayland (GLFW has a GLFW_PLATFORM_X11 flag for this). Now imagine this: what happens if there is a bug that only occurs on Wayland? How are developers supposed to debug this if they are planning to ship their application as a Wayland application? Finding the root cause would be a nightmare because they cannot use a graphics debugger for Wayland. RenderDoc is used by many graphics programmers, some from big game studios making video games with Vulkan, but surprisingly no one has stepped up to add Wayland support. Remember I said the Khronos Group is a typical group project? This is exactly what I mean: more than a decade has passed since Vulkan was made, but the tooling is still bad because everyone only wants to make the application that can be monetized.

Problems with the API itself

The Vulkan API is too verbose. Sometimes far too much. Things like sType in *CreateInfo structures, memory allocation, device and logical device handling, swapchain, image, and image view management, and so on.

Some of the boilerplate around *CreateInfo structures and object destruction can be reduced by using vulkan.hpp instead of vulkan.h. The RAII version of vulkan.hpp reduces the boilerplate further. Memory allocation can be simplified with VulkanMemoryAllocator, and the startup boilerplate can be reduced with vk-bootstrap; these were what I used for my project.

But the issue is that many of the essential Vulkan libraries aren’t managed directly by the Khronos Group. Both VMA and vk-bootstrap are third-party libraries, but I believe these should be first-party libraries led by the Khronos Group.

I also think this level of verbosity is useless for ordinary users. Yes, there might be some users who need to squeeze maximum performance out of the API, but I think that’s a minority. For ordinary users, things like image transitions (stage mask, access mask, and layout) and memory types (host, GPU, optimal, etc.) are pretty useless. A common excuse I see on the internet from Vulkan proponents is that people can choose OpenGL if they feel Vulkan is too verbose, but don’t say that. We all know OpenGL’s design is archaic, and Vulkan could’ve been a higher-level API similar to Metal.

The Khronos Group was right to judge that many OpenGL drivers were poorly written. Some decisions were good, like moving from GLSL to SPIR-V, because many drivers had different parsing rules. But the idea of letting the graphics programmer do the low-level optimization is bogus. The micro-optimization cases they worried about only apply to a few pieces of software, but by making that mandatory, now all the burden is on the graphics programmer and everyone needs to write the same boilerplate. In most cases this ends up being unnecessary premature optimization that doesn’t bring any visible improvement, and developers waste time and resources. This is critical for indie game studios, where they have limited time and money.

What did the Khronos Group miss?

Vulkan is a common graphics driver interface, not an application programming interface. The designers of Vulkan only focused on reducing the burden of device driver programmers and did not consider application programmers at all. This might be a successful interface for GPU manufacturers, but it’s a total failure for application programmers. There is a reason why Apple was involved in the creation of Vulkan but chose to make their own API in the end. They definitely knew Vulkan was too complicated for the average application programmer, and this was the right move. I thank Apple for creating an alternative, and this is one of the rare occasions where I thank Apple.

People suggest learning graphics programming with OpenGL and then moving to Vulkan, but this is a bad idea. Not only do you need to start with an archaic API that you won’t use in most cases, but the transition from OpenGL to Vulkan is hard because there are too many discrepancies. The pipeline and synchronization concepts should be enough. Device-level optimization should be left to advanced programmers who really need to squeeze out maximum performance (e.g. simulations and AAA video games).

The minimum they should do here is make a simpler version of Vulkan with less boilerplate. They could implement a graphics API library on top of Vulkan, like Zink, and the majority of graphics programmers would spend less time writing boilerplate and more time implementing the actual logic, improving productivity. This is crucial for small indie game studios.

Unfortunately, I don’t think this will happen. The Khronos Group will keep focusing on adding more extensions to Vulkan without considering the true pain point for many programmers. That has been the case over the last decade.

Conclusion

First, to the Vulkan proponents who wonder why more game studios don’t make video games based on Vulkan:

It’s simply because Vulkan sucks. If Vulkan were at least at DirectX’s or Metal’s level, I think the majority of video games would run on Vulkan. Before criticizing the game studios that use DirectX only, ask yourself whether Vulkan is actually superior to, or at least on par with, other modern graphics APIs.

Next, to the Khronos Group:

Stop adding more extensions to the API specification and focus on the actual product. Improve the tools and spend more time testing them (the aforementioned Slang config incident should not happen again). Make an API that does one thing great before moving on. We want a graphics API, not a weird mix of graphics and GPGPU APIs that isn’t good at either.

I’m currently working on the Metal backend of the project and it seems better than Vulkan, so I guess my choice of graphics API for the future will be Metal. I’ll lose the cross-platform advantage for sure, but it’s better than getting headaches from Vulkan’s downsides. Metal has issues too, specifically with the C++ implementation. I will discuss this in a following post.

Bonus: Claude sucks

I noticed this while using Claude Code for this project: Claude (or Claude Code) has become worse in the last couple of weeks. Claude Code seems to find and fetch many resources from the internet but fails to make use of them. One example of this is writing CMakeLists.txt for me. Even when I gave it a link to a reference configuration, and the only thing Claude Code needed to do was copy that and make some small modifications, it spent three minutes thinking and came up with something I didn’t ask for.

It writes many comments in the code, but the actual code is garbage. Even a novice graphics programmer like me can notice it. It seems to optimize the code prematurely, but does not accomplish what I asked for. It even does things like multiplying view and projection matrices on the CPU instead of on the GPU, which is clearly wrong, and I had to manually revamp that part by hand in the end.

At this point Claude Code is degrading my productivity, so I decided not to renew my Claude subscription and to move to ChatGPT and Codex. It probably plagued me more than Vulkan did during this project.

Off-topic: I watched The Odyssey with my friends yesterday and it was pretty good. All six of us gave the movie 10/10 (some 20/10). Definitely a recommended watch. I watched it in normal IMAX, and I think the experience could've been much better if I'd watched the 15/70 version, so if you haven't watched the movie I suggest going for IMAX 70mm.

Why I chose Computer Engineering in the first place?

It has been clear that I was going to be a programmer since I entered high school. I've contributed to FreeBSD since then, and although I paused contributions from time to time due to coursework, I'm at the point now where I can call myself a FreeBSD developer.

So back in the fall of Grade 12, it was obvious that I was going to apply to computer-related programs for university. I got an acceptance letter in March 2025 from uWaterloo Computer Engineering and I gladly accepted the offer.

What's wrong with the Computer Engineering program?

The first term (1A) was fine and I didn't have any complaints back then. I found myself enjoying maths and physics courses more than engineering ones, but it wasn't a big deal. I genuinely believed that the second term (1B) would be fine as well and the Computer Engineering program was my way.

But I was wrong.

Engineering courses are boring

I mean… you can’t enjoy the program if you don’t like the courses, right?

A few weeks after the start of 1B, I was confident that I was enjoying maths and physics courses more than engineering ones. Don’t get me wrong: the professors are fine, it’s just the courses. Calculus 2, Discrete Mathematics, and Electricity and Magnetism were fine, but Electric Circuits and Digital Circuits and Systems were not. However, I like writing digital circuits in Verilog at the same time, so what’s wrong with me for disliking the digital circuits course?

The answer is that learning engineering through courses isn’t my preference. I’ve taught myself programming since Grade 6 and I am luckily at the level where I can have technical discussions with experts in this area. Because I taught myself programming through books and projects, not school or online courses, engineering has become something I learn through hands-on experience, not through academic evaluations like exams or quizzes.

Also, the Computer Engineering program covers a broad field and it involves things like electric circuit courses that I’m not interested in. I love electrodynamics but not circuits. Finding the electric field at a certain point apart from a uniform charge distribution was fun, but calculating voltage, resistance, and current was the most boring math work I’ve ever done in my life.

And when upper years told me that we don’t have “fun” courses (e.g. OS, compiler, uarch) until the third year in CS and CE, I decided not to waste two years on courses that I don’t enjoy.

The Faculty of Engineering (or the ECE department) doesn’t align with my expectation

This year I was going to be an undergraduate research assistant (URA) under a CS professor but got rejected by the ECE administration. It turns out that the Faculty of Engineering doesn’t allow first-year students to become URAs. NO EXCEPTIONS. This is funny because the CS department grants exceptions for URAs when there is an explicit agreement from the supervisors (i.e. professors). Isn’t university a place for research? Why do they gate-keep the first years from doing research? This is totally absurd.

Meanwhile, the Faculty of Engineering is very into the idea of co-op and most engineering programs here are co-op only (i.e. no regular program offered). It’s okay because students can have experience before they graduate. However, if they are aware that the current job market is bad, they should give more time to students for job hunting instead of plaguing us with a huge amount of coursework. Like other programs, full-time engineering programs have five courses per term, but they seem to forget that 1) we have to learn way more stuff (no first-year calculus course covers more than MATH 119, which is basically a crammed version of Calculus 2 and 3) and 2) our schedule is full of tutorials and labs. Many students are skipping tutorials because they need to prepare for job interviews, and no wonder they get low academic grades in quizzes and exams. Do the people who architected this program know how it feels to have an 8:30 to 16:30 class schedule every day and need to do problem sets and lab work after that? Do they even validate the feasibility of the course schedule before making it effective?

As a result, Computer Engineering has become a contradictory program that’s operated by a university but does not aim for research, and promotes co-op but does not give enough time for job search. A similar metaphor here is “le saint empire romain n’était en aucune manière ni saint, ni romain, ni empire.”

Engineering programs are expensive

Look at the uWaterloo tuition page. Engineering programs have the highest tuition, which is $19,000 per year. Computer science is at $16,000 and mathematics and science programs are at $9,000.

I would be fine if it is truly worth the cost. However, the ECE 455 lab sessions were cancelled this term because there wasn't enough budget. For your information, it is an embedded software course. An embedded software course without a lab? This doesn't make sense. Each student pays $19,000 a year for an engineering program. The faculty sold the name of E7 and changed it to PSE because they got $20M from some organization. And what? They don't have enough money for one-term lab sessions? That doesn't sound right. Even after OSAP, students spend a lot on tuition every year, and labs are still getting cancelled. Also don't forget that engineering programs are the most popular ones at uWaterloo.

So why Mathematical Physics?

I have loved watching stars since I was young, as my mum took me to observatories quite often. I liked the numbers related to stars (e.g. size comparison of famous stars) and astrophysics videos that explained things like why light bends in gravity. When I did my first high school physics course in Grade 11, I really liked it. My teacher was great at teaching it, so no way I disliked his course.

At the time I made university applications, I was in the Waterloo dream: making a huge amount of money through co-ops and continuing that after graduation. But GenAI and layoffs happened, so the dream is now hard to achieve. I made lots of connections here at Waterloo, but that wasn’t enough to justify staying in Computer Engineering. This is when I realized that I came to university for the wrong reasons. In my humble opinion, university is for learning knowledge, not for money or networking. Before, I was treating university just as a graduation certificate giver, which is completely false. It makes no sense to burn five years of tuition and living costs of around one million dollars just for a piece of paper.

On the other hand, learning physics in university makes sense to me. I’m interested in it but don’t know it quite well, so I have the passion to pursue it. Every single course that I read from the curriculum seemed to be interesting, so I can justify staying in the program for four years. Lastly, physics teaches you how to think. What’s behind the formula, why it happens, and how to play with those formulas. It’s not just plug-n-play.

What next?

First of all, it’s highly unlikely that I will work in a physics-related field after graduation. I will not pursue graduate degrees in physics either, as I believe undergraduate topics are enough to appease my curiosity for now. Yet, I might write an undergraduate thesis in graphics shaders like this.

Mathematical Physics gives nine electives, and I can always overload or take more courses in spring breaks. For ECE courses, I’m planning to take Embedded Microprocessor Systems, Computer Architecture, and Digital Hardware Systems. The rest will be pure mathematics and thesis courses for my graphics shaders idea. After I graduate, I might work in the industry or do a PhD in operating systems or microarchitecture.

So you might wonder: what are safety razors? Most people use electric razors (shavers) or cartridge razors. When I just started shaving, I used disposable razors but realized that it created too much waste while the shaving experience wasn’t good. I could go for shavers or cartridge razors, but they seemed to be too expensive.

Then I found safety razors on the internet. In brief, safety razors are similar to cartridge razors, but it only has one blade which is not enclosed in a plastic case. It’s also less protective and it takes more time to shave than shavers and cartridge razors, which is why it was replaced by those two in modern days. Thus, when people use safety razors, they have specific reasons to do so.

Why do people use safety razors?

Modern shavers or cartridge razors come with technologies that cut your hair as much as possible. The issue is that they sometimes cut too much. When razors pull hair and cut it, they actually cut part of the hair that was below the skin. Sometimes the hair fails to grow out of the hair follicle and gets stuck in it. This is what we call ingrown hair, which causes inflammation and severe itching. Safety razors are free from this problem because they don’t pull the hair when they cut it. However, this also means that it will leave some hair visible after you shave, which is a trade-off. I’ve had skin troubles since I was very young, and ingrown hair was too annoying to deal with especially when it came with pimples on my face. After switching to safety razors, I’ve had fewer issues with skin troubles on face.

On the UX side, shaving with safety razors is more fun compared to other types of razors. It’s like Vim: it’s not beginner-friendly but once you get used to it, it gives a better experience compared to other types of razors. Because it’s easy to cut your skin with safety razors, everyone accidentally cut their skin in the beginning and even experienced people make that mistake sometimes. But once you get experienced, shaving with safety razors is quite fun because you have complete control over shaving. It’s also more convenient when you need fine control over the hair. For example, removing hairs around the lips is much easier with safety razors over cartridge and disposable razors because you only need to care about one blade, not layers of blades.

The cost-effectiveness of safety razors is controversial. Of course, the minimum initial setup requires a safety razor, blades, aftershave (or an alum block), a shaving brush, shaving soap, and a shaving mug. My initial setup costed over $400. However, razor blades for safety razors are extremely cheap compared to the ones for cartridge razors or disposable razors. You can buy ten of them at $6 in Canada and each blade can be used several times. In the last one year, I only spent $25 on razor blades.

Safety razors and shaving brushes are expensive, but you can use them forever if they are kept in good maintenance. I started with Merkur Progress 500 because it has configurable aggressiveness and I didn’t know the proper aggressiveness for my skin. I settled with aggressiveness between 2 and 3 (5 is the maximum) and have enjoyed it for the past one year. Unfortunately, I didn’t know how to maintain it properly, so the threading got rusty and loose and it ended up being unusable. As my second safety razor, I was considering between Merkur 37C and Muhle R41 but chose Merkur 37C because people said R41 is too aggressive while my blades from Feather is already one the most aggressive blades in the world. So I ordered 37C a few days ago and it arrived today. It gave me a better shaving experience over the Progress 500. Unlike Progress 500, 37C is a slanted razor, so it requires less force to shave. In other words, it requires fine control so usually it’s not recommended for beginners. Moreover, 37C is an open-comb razor, so cleaning up the remaining shaving soap and hair on the razor is much easier compared to closed-comb razors like Progress 500.

Safety razors are also good for the environment compared to others because they don’t have any plastic components. Also the only thing that you need to dispose of regularly are razor blades which are just a piece of metal.

Roadmap for shaving

I’ll keep using Merkur 37C for a few more years as I’m very satisfied with it. When it breaks, I’ll switch to Muhle R41 or a straight razor if I feel I need more aggressiveness for shaving.

In other words, you won’t see this type of article for a while.

There are myriads of documentation formats. At least I have encountered plain text (.txt), reStructuredText, Markdown, AsciiDoctor, mandoc, DOCX, Apple Pages, Google Docs, and LaTeX over the last year for different purposes. The first five are usually used for technical documentation related to programming like the FreeBSD handbook or source code documentation. The next three are for school stuff such as collaborating on a project report or writing English essays. I find that different formats and software have their own strengths, so it’s obvious why I use so many formats for writing: there is no such thing as the best format in writing.

But LaTeX is different. So far, there hasn’t been any competitor that is appealing enough to replace LaTeX. Although LaTeX is very inconvenient, no alternatives could overcome its ecosystem. But finally I discovered something that can be its replacement: Typst.

Pain Points of LaTeX

So what’s wrong with LaTeX, a de-facto standard format for writing technical reports, papers, and dissertations? Here are the issues:

• Slow compilation, no incremental build

• Intermediate files like .aux during compilation that make my workspace dirty

• Difficult to learn

• Compilation log issues (hard to interpret, notorious “Underfull \hbox”)

• Needs too many delimiters, thus worsening readability

The first two are obvious; I don’t think I need to explain them. For the third point: LaTeX is definitely harder than simple languages like Markdown or reStructuredText and WYSIWYG editors like Microsoft Word. But still, it’s unnecessarily complicated, and Typst solves the problem. We’ll visit that point again later.

Now let’s take a look at the last two points.

Abstruse compilation log

While working on my BSDCan paper, I got the following error message:

Underfull \hbox (badness 10000) in paragraph at lines 308--314
\OT1/pcr/m/n/10 hmp_state.total_capacity \OT1/ptm/m/n/10 dur-ing ini-tial-iza-tion
/Users/minsoochoo/Documents/BSDCan 2026 - HMP/hmp.tex:318: Missing $ inserted.
<inserted text> 
                $

What was the issue? Here’s what I had in line 318:

Each score is a single scalar value: each CPU exposes exactly two
scores, indexed by \texttt{enum score_type}:

Yes, I forgot a delimiter \ between “score” and the following underscore. If you were experienced in LaTeX, you would’ve noticed it easily. If not, you might have wondered why it triggered that error message. The point is that the error message was kinda useless here to see what triggered it.

But that’s just part of the problem. The whole log I got from the compiler was 497 lines long, and most of them were “Underfull \hbox” warnings. That warning is very annoying because it’s not an issue most of the time but takes up a huge part of the log, making identifying issues way harder.

Needs too many delimiters

This is part of my BSDCan paper in LaTeX:

Providers register themselves at \texttt{SI\_SUB\_SMP} via two parallel
macros: \texttt{HMP\_CAPACITY\_PROVIDER\_DECLARE} and
\texttt{HMP\_SCORE\_PROVIDER\_DECLARE}.  Each hooks a \texttt{SYSINIT}
handler that calls the corresponding registration routine
(\texttt{hmp\_capacity\_provider\_register()} or
\texttt{hmp\_score\_provider\_register()}) and ...

In programming, underscores are used frequently, mainly due to namespacing. Whenever I introduce new functions or variables in my papers, I need to use delimiters so the compiler doesn’t spit out incomprehensible error messages. Now you would ask, “Why not just live with it?” The fact is that my eyes hurt even with a paper of seven pages in length. One day, I’ll need to write a thesis or longer papers. These delimiters make my eyes tired during proofreading, and as you may know, writers do proofreading multiple times (I repeated proofreading and revising more than seven times for that BSDCan paper).

I don’t have that issue with Typst. In Typst, I simply write:

Providers register themselves at `SI_SUB_SMP` via two parallel
macros: `HMP_CAPACITY_PROVIDER_DECLARE` and
`HMP_SCORE_PROVIDER_DECLARE`. Each hooks a `SYSINIT`
handler that calls the corresponding registration routine
(`hmp_capacity_provider_register()` or
`hmp_score_provider_register()`) and

How simple is that, right?

Another advantage of not having delimiters for underscores is that copy-pasting from source code requires less work. And again, if I miss one delimiter, the compiler will complain in a way I can’t understand.

So why Typst?

Remember I said LaTeX is hard to learn? It’s because many developers these days learn Markdown as their first documentation language since it’s widespread in the OSS world. And when they encounter LaTeX, it feels like learning a new language without any connection to the ones you already know. Analogy here: an Anglophone is likely to learn French more easily than CJK languages.

Typst doesn’t share the same grammar as Markdown, but at least it’s similar. Let’s see some examples:

// Typst
# Heading 1
## Heading 2
### Heading 3
*Bold*
_Italic_
`Monospace`

// ... while in LaTeX,
\section{Heading 1}
\subsection{Heading 2}
\paragraph{Heading 3}
\textbf{Bold}
\textit{Italic}
\texttt{Monospace}

I admit that LaTeX is more consistent: every command starts with a backslash. But if you are coming from Markdown, you would admit that Typst is easier to start with. As a university student who does OS development as a hobby, I don't have time to learn a documentation language that completely differs from the ones that I already know. As a student in a STEM field and as a developer attending many conferences, I would definitely need to learn one of them. And considering my time constraints, it's obvious why I chose it over mastering LaTeX.

Another minor thing: I found that Typst’s VSCode extension is better than the VSCode LaTeX Workshop extension. Unlike the LaTeX extension, the Typst extension doesn't compile the source into a PDF until I trigger it manually, but it shows a PDF preview instead. Thanks to Typst's superior compilation speed, the latency between save and update on the preview tab is better, too. And finally, the Typst extension automatically scrolls the PDF preview when I put my cursor on different parts of the document, and when I click a part in the preview, the cursor in the editor window automatically moves to the equivalent point (although this doesn't work well when macros are involved).

Where would I still use LaTeX?

But Typst cannot replace LaTeX completely. LaTeX already has a rich ecosystem, and many journals provide templates in LaTeX and only accept papers in LaTeX. Even arXiv only accepts LaTeX, although there is an ongoing effort to accept Typst as well (PDF is also accepted, but it has too many downsides compared to LaTeX).

Take my BSDCan paper as an example. Because it’s a conference paper, I’m going to submit a PDF generated from the LaTeX version. Typst’s charged-ieee template still has some minor style issues. They don’t stand out, but when I put it side by side with other articles from the original IEEE template, it stands out too much. Also, the lack of a \thanks{} command made me hesitate to make a switch.

So I’ll use LaTeX when I have to, like I’m forced to use Google Docs when collaborating with my friends for university projects.

What I’ll use Typst for

I'll use Typst for anything else. I already converted my résumé to Typst. Originally it was in the famous Jake’s Resume LaTeX template, but I converted it to a similar Typst template called basic-resume. It's not a 1:1 equivalent, and I still like the original styling, but the convenience of Typst surpasses that minor styling issue. So I'll stick with that template until a 1:1 equivalent comes out.

Lastly, I thank the Typst developers for creating such a wonderful language.

For my first co-op term (one of six), I joined the FreeBSD Foundation as a Junior Software Developer Intern. I had been contributing to FreeBSD since May 2021, so I came in with an existing project backlog and a list of ideas I wanted to pursue. My supervisor, Ed Maste (emaste@), gave me the freedom to drive my own roadmap, which made the term especially productive.

Main Projects

I focused on two primary areas this term: HMP (heterogeneous multi-processing) scheduling, and improvements to LLDB kernel debugging.

HMP Scheduling

I wrote the initial patch for the hmp(4) framework, which serves as an interface between the provider (which reports CPU state) and the scheduler. This work will be presented at BSDCan 2026, and I've also been drafting an accompanying paper in LaTeX.

LLDB Kernel Debugging

The goal here was to bring LLDB to feature parity with KGDB for FreeBSD kernel debugging. This had originally been proposed as a Google Summer of Code project, but since no suitable candidate was found, I picked it up as part of my co-op work.

The work included fixing significant bugs such as kernel debugging on FreeBSD 14+ on arm64 being completely broken. I also extended support to less common architectures like riscv and ppc64le. By the end of the term, every supported platform on FreeBSD 14+ works, with the exception of i386 and armv7, which have limited support. These changes will ship in LLVM 23, and I plan to backport them to FreeBSD's in-tree LLVM as well.

Exploratory Work

I also spent time on two exploratory projects that didn't reach a meaningful outcome before my last day:

Forgejo CI scripts. FreeBSD developers are currently evaluating Forgejo as a potential successor to Phorge for our source forge. Due to limited hardware resources on my end, I wasn't able to run as many script experiments as I'd hoped.

EEVDF scheduler. This was a side project I used as a testbed to evaluate how far LLM-assisted development ("vibe coding") could take me. I'll go into more detail in a separate post, but the short version is that even Claude Code with Opus 4.6 got me only about 70% of the way to what I wanted.

Acknowledgements

First and foremost, thank you to Ed Maste (emaste@), Senior Director of Technology at the Foundation and my co-op supervisor. Despite a heavy workload, Ed consistently looked out for me and the other co-op students, pointed me to useful resources, and tagged the right reviewers on my Phabricator revisions. I wouldn't have been able to land nearly as many changes on the FreeBSD and LLVM sides without his support.

Thank you to Li-wen Hsu (lwhsu@) for rebuilding the network setup at the Kitchener office, maintaining and upgrading the FreeBSD clusters, and organizing AsiaBSDCon 2026.

Thanks to Siva Mahadevan (siva@) for troubleshooting network issues at the Foundation, recovering my desktop after a panic from a -CURRENT update, and supervising the three of us co-op students.

On the FreeBSD project side, thanks to Olivier Certner (olce@), Konstantin Belousov (kib@), Warner Losh (imp@), and John Baldwin (jhb@) for reviewing my patches and offering constructive feedback.

On the LLDB side, thanks to Jessica Clarke (jrtc27@), Sheng-yi Hung (aokblast@), and David Spickett (@DavidSpickett) from Arm for reviewing my FreeBSD kernel debugging patches.

Finally, thank you to the HR team at the Foundation for supporting the co-op students and helping arrange my travel grant for AsiaBSDCon 2026.

Devsummit

The Developer Summit ran for two days, 10 AM to 5 PM each day. Most sessions were short presentations covering topics like FreeBSD on WSL 2 and Ansible on FreeBSD. Between talks, developers worked on patches, followed up on mailing-list threads, and reviewed one another's work — I got some useful feedback on my LLVM pull requests during these gaps.

The AsiaBSDCon organizer handed out Kuai Kuai, a popular Taiwanese snack that comes in a bright green package. The tradition is to place it on top of your computer as a good-luck charm — the idea being that your code won't break as long as the snack hasn't expired. Think of it as the Taiwanese equivalent of holding a blessing ceremony in a server room before it goes live.

So I guess it's something similar to having religious ceremony in a server room before it opens to public.

AsiaBSDCon 2026

The main conference began right after the summit and drew roughly three to four times as many attendees. Each participant received a copy of the AsiaBSDCon 2026 Proceedings as part of the welcome package. The book itself was well produced, though the formatting across papers was inconsistent — most followed the IEEE Conference template, but font weight, size, margins, and layout varied noticeably, and a few papers used entirely different templates. It would be great if future committees provided a strict template and enforced compliance. A PDF or EPUB edition would also be a welcome addition.

Talks That Stood Out

Rethinking the forms of OS functionality development

Kenichi Yasukata presented his work on a portable userland TCP/IP stack. He outlined the performance advantages of running the network stack in userspace but highlighted a persistent challenge: portability across operating systems due to divergent APIs.

His solution is a userland TCP/IP stack that deliberately omits OS-specific code. That sounds paradoxical — how can a TCP/IP stack function without OS bindings? The answer is that developers supply the OS-specific low-level glue themselves. This separation lets the core stack remain portable while still achieving strong performance.

Kenichi also discussed techniques for intercepting system calls without relying on LD_PRELOAD. His approach uses binary overwriting, which requires architecture-specific hooks: svc-hook on arm64, and zpoline (a trampoline through an alternative syscall entry point) on x86-64.

Faster, smolBSD! Boot! Boot!

Pierre Pronchery showcased smolBSD, a container-oriented NetBSD variant. By stripping the kernel down to only the necessary drivers and bypassing the traditional UEFI boot path, smolBSD achieves bare-metal boot times under one second.

Pierre demonstrated PicoClaw and SSH server images that can be instantiated much like Docker images — an impressive feat for anyone who has waited several seconds for a standard container to come up. He also showed ZFS-on-root running on NetBSD, though this still appears to lag behind FreeBSD's mature ZFS support.

Run Time Reoptimization for Modern Heterogenous Systems

George Neville-Neil argued that modern hardware — CPUs, GPUs, NPUs — has evolved far beyond the PDP-11 model, yet Unix-like operating systems still carry assumptions rooted in that era.

He dove deep into CPU microarchitecture: cycle-level penalties, cache misses, branch mispredictions, and the like. The core idea is to capture these runtime penalties and feed them back into LLVM, which he highlighted as a strong abstraction layer across diverse hardware targets. This feedback from live profilers is passed through optimization pipelines that produce architecture-specific binaries, which are reloaded without exiting the program.

I'll admit this talk was hard to follow in real time — partly because I was multitasking — and I plan to revisit the recording to better understand the benchmarking results.

Bringing memory safety to BSD with CHERI

Brooks Davis presented the CheriBSD upstreaming effort, with a strong emphasis on CHERI's security benefits. Two examples stood out. First, the team asked an LLM to inject 13 memory bugs into NGINX; CHERI caught all 13 plus two additional bugs the LLM introduced unintentionally. Second, while porting Chromium to CheriBSD, the two-person team uncovered numerous memory vulnerabilities that were later assigned CVEs — matching or exceeding the output of over 100 security researchers on the Chrome team, thanks to CHERI's memory-safety guarantees.

The upstreaming roadmap targets completion by FreeBSD 16, expected in December 2027. CheriBSD will be the first time-sharing operating system with full CHERI support, covering both Arm Morello and RISC-V CHERI (RV64Y). On the Linux side, a CHERI port is in progress, but organizational challenges — what I'd describe as significant process and priority shifts — appear to be slowing adoption.

What's Next?

BSDCan 2026 — I'll be presenting a talk on hybrid scheduling. Unfortunately, a midterm exam will keep me from the hackathon.

EuroBSDCon 2026 — I'm eager to attend, pending travel approval from my second co-op employer.

AsiaBSDCon 2027 — During the closing session, Li-wen Hsu announced that next year's conference will be held in Singapore. As George put it, making it happen requires "volunteers, volunteers, volunteers — and sponsors, sponsors, sponsors." If you're based in Singapore and can spare four days, please consider volunteering. If your company is in a position to help financially, sponsorship goes a long way.

Acknowledgments

As George Neville-Neil noted in the closing session, enormous thanks are owed to Li-wen Hsu (lwhsu@) for making AsiaBSDCon possible. Everyone who worked alongside him knows the effort he poured into the event, day and night. Thank you, Li-wen.

I also want to thank the FreeBSD Foundation for approving and sponsoring my trip to Taiwan.

The Good

Jujutsu's workflow is meaningfully more efficient than Git's. Operations that tend to be friction-heavy in Git—moving commits between branches, rewriting commit messages, and resolving merge conflicts—are noticeably smoother in Jujutsu. Compatibility with existing Git repositories is solid; in most cases I disable Git colocation entirely and work with a fully native Jujutsu repository.

For production use, I rely on Jujutsu for both LLVM development and my weekly reports at the FreeBSD Foundation. Across both of these workflows, it has been completely reliable.

The Bad

Jujutsu is in good shape overall, but a few pain points remain.

No hook support. While it is true that most Git hooks are unnecessary in Jujutsu's model, prepare-commit-msg is the exception I miss daily. The FreeBSD Project uses this hook to inject metadata into commit messages, and its absence is the sole reason freebsd-src is the one repository where I still fall back to Git. I am hopeful that hook support will land soon.

No --fixup equivalent. Git's git commit --fixup has no direct counterpart in Jujutsu. My current workaround is to manually prepend fixup! to the change description, but this means re-typing the target commit message each time. When working on a series of LLVM patches, this gets tedious quickly.

Manual bookmark management. Jujutsu does not advance bookmarks automatically, which makes pushing changes more verbose than it needs to be. Where Git requires a single git push, Jujutsu requires two commands: jj bookmark set -r <revset> foo followed by jj git push --bookmark foo. It is a small friction, but it adds up.

Immature ecosystem. Third-party tooling is still catching up. As a concrete example, Spaceship only gained Jujutsu prompt support last week, and only through a community-maintained plugin. There are other integration gaps as well, though the Jujutsu team is actively working toward full Git compatibility, and progress has been rapid.

Final Thoughts

Despite its rough edges, Jujutsu has become my default version control tool. The workflow improvements over Git are substantial enough that the remaining gaps feel like temporary inconveniences rather than fundamental limitations. If you spend any meaningful amount of time in Git, it is worth giving Jujutsu a serious look.

KGDB remains the preferred tool for many developers, largely because widely used debugger scripts and utilities like crashinfo depend on it. However, KGDB is GPL-licensed and therefore not shipped with FreeBSD. To address this, Moritz Systems ported KGDB's core functionality into LLDB several years ago under contract with the FreeBSD Foundation. One important distinction: KGDB is only available on FreeBSD because it depends on FreeBSD's kvm library — a dependency that also enables partial live kernel debugging through /dev/mem. LLDB's FreeBSDKernel plugin, by contrast, supports two backends: kvm and libfbsdvmcore.

The Problem with the Dual-Provider Model

Why does the FreeBSDKernel plugin offer two separate interfaces? The choice between them isn't made at runtime — it's determined at compile time. The root issue is that kvm is only available on FreeBSD. To enable cross-platform support, LLDB needed an alternative, which led to the creation of libfbsdvmcore (commonly referred to as fvc).

This dual-provider approach introduces several problems.

First, fvc is effectively a clone of kvm with FreeBSD-specific code stripped out and cross-platform scaffolding added in. As a result, it inherits kvm's bugs and limitations. Patches applied to kvm on the FreeBSD side need to be backported to fvc — and when they aren't, things break. For example, if a new minidump format version lands in FreeBSD but isn't reflected in fvc, cross-platform users will be unable to process core dumps generated under the new format.

Second, fvc is a third-party library that isn't bundled with LLDB. The original goal of making FreeBSDKernel cross-platform was to allow developers on macOS or Linux to debug FreeBSD core dumps. In practice, however, distribution-supplied LLDB packages don't include libraries like fvc, meaning those developers would need to build LLDB from source — a barrier high enough that virtually no one does it. This has left fvc largely unmaintained and undertested. I recently discovered, for instance, that it was missing minidump version 3 support on arm64. My ongoing work to bring the FreeBSDKernel plugin to feature parity with KGDB is made considerably harder by having to validate against two separate providers.

Solving the Dual-Provider Problem

The solution, originally proposed by the developer of the FreeBSDKernel plugin, is to integrate kvm's functionality directly into LLDB. I agree with this approach: it enables cross-platform debugging without relying on external libraries, and it allows us to retire both the kvm and fvc interfaces in favor of a single, unified backend — significantly reducing the maintenance burden.

The one trade-off is that changes to the internalized implementation will need to be backported to FreeBSD's in-tree LLDB and upstreamed accordingly. In practice, though, this is far more manageable than maintaining two parallel interfaces.

That said, this is a substantial undertaking involving significant research, implementation, and testing. Since I already have ongoing LLDB improvement work in progress, it isn't the immediate priority. My current target is to complete the in-flight work by LLVM 23, with the unified interface aimed for LLVM 24. In the interim, the most practical step is to remove fvc from the FreeBSDKernel plugin and make it kvm-only. A pull request for that change is currently under review.

Other Improvements to FreeBSDKernel

My broader work on the FreeBSDKernel plugin focuses on improving LLDB's overall FreeBSD kernel debugging support. This was originally conceived as a GSoC project idea, but I took it on as a work item during my co-op with the FreeBSD Foundation. The scope includes adding support for additional architectures, implementing commands and features where FreeBSDKernel currently falls short of KGDB, and other enhancements. Progress is being tracked publicly on LLVM's GitHub issue.

ULE, the default scheduler in FreeBSD, was introduced in FreeBSD 5.1 and became the default in FreeBSD 7.1. You might wonder why FreeBSD still ships its predecessor, 4BSD, even now at FreeBSD 15. The reason is that despite ULE being designed as a replacement for 4BSD, there are implementation issues in ULE that cause it to perform worse than 4BSD in certain scenarios. These should, of course, be fixed — and a developer has announced plans to work on this in the near future. In this post, I'll describe what those issues are and outline possible fixes.

Nice is not well-respected

In the ULE scheduler, nice values are not well-respected. The original ULE paper describes the design as follows:

A fixed part of the priority range in FreeBSD is used for time sharing threads. ULE uses the interactivity score to derive the priority. After this the nice value is added to the priority, which may actually lower the priority in the case of negative nice values.

For context, here is how FreeBSD defines its priority bands and how ULE calculates scheduling priority:

/* from sys/sys/priority.h */
/*
 * Priorities range from 0 to 255.  Ranges are as follows:
 *
 * Interrupt threads:		0 - 7
 * Realtime user threads:	8 - 39
 * Top half kernel threads:	40 - 55
 * Time sharing user threads:	56 - 223
 * Idle user threads:		224 - 255
 *
 * ...
 */

/* from sys/kern/sched_ule.c:sched_priority(), simplified */
/*
 * If the score is interactive we place the thread in the realtime
 * queue with a priority that is less than kernel and interrupt
 * priorities.  These threads are not subject to nice restrictions.
 *
 * Scores greater than this are placed on the normal timeshare queue
 * where the priority is partially decided by the most recent cpu
 * utilization and the rest is decided by nice value.
 *
 * The nice value of the process has a linear effect on the calculated
 * score.  Negative nice values make it easier for a thread to be
 * considered interactive.
 */
score = imax(0, sched_interact_score(td) + nice);
if (score < sched_interact) {
    pri = PRI_MIN_INTERACT;
    pri += (PRI_MAX_INTERACT - PRI_MIN_INTERACT + 1) * score /
        sched_interact;
} else {
    const struct td_sched *const ts = td_get_sched(td);
    const u_int run = SCHED_TICK_RUN_SHIFTED(ts);
    const u_int run_unshifted __unused = (run +
        (1 << SCHED_TICK_SHIFT) / 2) >> SCHED_TICK_SHIFT;
    const u_int len = SCHED_TICK_LENGTH(ts);
    const u_int nice_pri_off = SCHED_PRI_NICE(nice);
    const u_int cpu_pri_off = (((SCHED_PRI_CPU_RANGE - 1) *
        run + len / 2) / len + (1 << SCHED_TICK_SHIFT) / 2) >>
        SCHED_TICK_SHIFT;
    pri = PRI_MIN_BATCH + cpu_pri_off + nice_pri_off;
}

In FreeBSD, nice values range from −20 to 20 (41 levels), while the timeshare priority band spans from 56 to 223 (168 levels). The nice value is added to the priority linearly without scaling. This means the impact of nice on scheduling priority is relatively small, and the interactivity score can easily dominate the priority calculation, effectively drowning out the nice value.

One straightforward fix would be to multiply the nice value by 3 or 4 before adding it to the priority. However, linear addition has a deeper problem: the perceptual difference between nice 0 and nice 1 is much greater than the difference between nice 18 and nice 19. A proportional approach using an exponential weight table solves this by expressing nice levels as ratios rather than fixed offsets — for example, each nice level corresponds to roughly a 10% change in CPU share.

Linux already takes this approach. The CFS/EEVDF scheduler maps each nice level to a weight via a precomputed table:

/* from kernel/sched/core.c */
/*
 * Nice levels are multiplicative, with a gentle 10% change for every
 * nice level changed. I.e. when a CPU-bound task goes from nice 0 to
 * nice 1, it will get ~10% less CPU time than another CPU-bound task
 * that remained on nice 0.
 *
 * The "10% effect" is relative and cumulative: from _any_ nice level,
 * if you go up 1 level, it's -10% CPU usage, if you go down 1 level
 * it's +10% CPU usage. (to achieve that we use a multiplier of 1.25.
 * If a task goes up by ~10% and another task goes down by ~10% then
 * the relative distance between them is ~25%.)
 */
const int sched_prio_to_weight[40] = {
 /* -20 */     88761,     71755,     56483,     46273,     36291,
 /* -15 */     29154,     23254,     18705,     14949,     11916,
 /* -10 */      9548,      7620,      6100,      4904,      3906,
 /*  -5 */      3121,      2501,      1991,      1586,      1277,
 /*   0 */      1024,       820,       655,       526,       423,
 /*   5 */       335,       272,       215,       172,       137,
 /*  10 */       110,        87,        70,        56,        45,
 /*  15 */        36,        29,        23,        18,        15,
};

With this kind of weight table, nice values are meaningfully respected at every level, and the effect of each increment feels consistent across the entire range.

Fairness Issue

The ULE scheduler is not completely fair. To illustrate what this means: in Linux's CFS and EEVDF schedulers, total CPU usage is tracked per task via a virtual runtime (vruntime). When a task yields the CPU before its time quantum expires, the unused portion is preserved, and the task receives compensation the next time it is scheduled.

ULE does not do this. When a batch-class task in ULE yields the CPU early, the remainder of its time quantum is simply lost. If the task repeatedly yields early — but not frequently enough to be promoted to the interactive class — it ends up receiving less CPU time than it is entitled to, leading to a form of soft starvation. One approach to fixing this would be to track the lost quantum as a credit and apply it the next time the task is scheduled.

Conclusion

Recently, FreeBSD landed a patch that allows ULE and 4BSD to coexist in the same kernel, enabling users to select a scheduler at boot time without recompiling. Once fixes for the issues described above land, users who have been relying on 4BSD due to ULE's shortcomings will be able to properly evaluate ULE's performance. If ULE can be shown to be superior to 4BSD in all cases, 4BSD can finally be deprecated. To follow progress on this work, subscribe to the freebsd-hackers mailing list.

A note before we begin: this advice won’t apply to everyone. Web developers, for instance, may find some of this less relevant. But I believe most programmers will recognize these principles as foundational.

The Best Way to Learn Is From Good Teachers

This holds true across every discipline—music, mathematics, art, science. The fastest, most reliable path to expertise is learning from someone who’s already mastered the craft. Think of teenage pianists who travel across countries to study with legendary tutors. Programming is no different.

Here’s the problem: computer science is barely a century old, yet it’s become one of the most popular fields in the world. The demand for great teachers far outstrips the supply.

But that doesn’t mean you’re out of luck.

We have something better than a scarce handful of mentors: hundreds of excellent books written by legendary programmers. Yes, many students avoid them—they’re long, dense, and admittedly boring at times. But progress in any field has boring parts. Computer science is no exception. And I promise you, working through these books is infinitely more valuable than churning out throwaway projects at hackathons.

For fundamentals, I recommend Computer Systems: A Programmer’s Perspective and Computer Architecture: A Quantitative Approach. For the C programming language, start with C Programming: A Modern Approach, then move to The C Programming Language and Modern C.

Now, some of you might argue that starting with C is outdated—that Python is a better entry point. That’s a reasonable position, but here’s the truth: you’ll need to learn C eventually. No exceptions. Even if you’re a web developer, understanding what C teaches you will make you more effective—whether that’s tracking down why your app is slow, profiling performance, or occasionally digging into browser internals. Languages like C++, Rust, and Zig exist, but C remains the simplest and most direct way to understand how machines actually work.

After that, learn algorithms. Introduction to Algorithms is the gold standard. Once you’ve read it, you’ll find that understanding new algorithms becomes straightforward—often just a matter of reading a Wikipedia page and some example code. LeetCode has its place, but don’t grind through hard problems for the sake of it. Focus on easy and medium difficulty. Instead of memorizing solutions, learn to recognize patterns. When you face an algorithmic challenge at work or in an interview, you’ll spend less time both planning and implementing.

Open Source Is Your Classroom

Now you need real-world experience. But before you start writing code, study how others have done it.

Remember what I said about learning from good teachers? The open-source world is filled with them. Want to see exemplary object-oriented, modern C++? Study the LLVM project. Curious about how operating systems work? Explore FreeBSD, XNU (macOS's kernel), Linux, and FreeRTOS.

Here’s the catch: not all open-source code is worth studying. Even the Linux kernel has its infamous staging drivers—poorly maintained code that exists in a kind of purgatory for a reason. But as you read more, you’ll develop the ability to distinguish good code from bad. You’ll start to sense when something is off.

This “smell”—the instinct that tells you code was written by a beginner, by an experienced developer new to a codebase, or by AI—is hard to articulate, but unmistakable once you’ve internalized it. After reading a few hundred thousand lines, you’ll know. If you ever want to advance to senior-level work, this skill is non-negotiable.

Whatever your area of interest—databases, web servers, quantitative finance, cryptography, blockchain, AI, GPU programming, video games—find the most respected project in that space. Ninety percent of the time, you’ll be learning from the best. (There are exceptions; GPU kernels written in CUDA, for instance, leaves much to be desired.) If you’re unsure, ask around—forums, communities, and colleagues can point you toward the gold-standard implementation of whatever you’re studying.

Unless you’re working on classified military software, you can find source code for almost anything online—including, as a fun fact, leaked Windows XP kernel code.

Conclusion

So yes, becoming a good programmer involves a lot of reading—books and real-world code. Sounds boring? Welcome to professional-level work in any field.

If you’d rather stick to hobby projects and hackathons, that’s fine—but then why pursue a computer science degree? You can do those things without one. Once you’ve committed to this field, it’s time to do what students in every other serious discipline do: learn from the best examples, written by the best teachers.

The shortcuts aren’t shortcuts. The fundamentals are the path.

Courses

If there’s one takeaway from my 1A term in Computer Engineering, it’s this: the curriculum feels designed without much consideration for whether it’s actually realistic for first-year students.

ECE 105 (Classical Mechanics): Easily the hardest and, for computer engineers, least relevant course of the term. I genuinely love physics, which made this experience all the more disappointing. The teaching approach covers principles in lectures while expecting students to figure out applications independently. Tutorial problems are so difficult they never appear on actual assessments—and it seems like even the instructors aren’t sure what the quizzes and exams should look like. The kicker? ECE 105 covers more material and is harder than PHYS 111 and PHYS 121, which are designed for physics majors.

ECE 150 (Fundamentals of Programming): Learning C++ fundamentals in three months is ambitious, to put it mildly. Unless you’ve already programmed in C++ before arriving, expecting above a 70 is optimistic. I feel for the electrical engineering students—most of them will never use this material again.

ECE 190 (Engineering Profession and Practice): This course isn’t really about ethics; it’s about memorizing slides. The exams are full of gotcha questions that test trivia rather than understanding. You’ll need to remember obscure facts (how many undergraduate engineering programs exist in Canada?) and distinguish between nearly identical terms (in “E-coop,” does the “E” stand for “Enterprise” or “Entrepreneurial”?). It’s more IQ test than ethics course.

ECE 198 (Project Studio): The professor allowed AI usage, which was fortunate because I had no time to do anything else. I essentially vibe-coded my way through with Claude Code—GenAI usage isn’t against Policy 71 for this course, after all. The group project was painful; I had a teammate who was equal parts arrogant and uninformed, which is the worst combination. Also, they scheduled our symposium on a Sunday. That presentation was worth around 30% of our grade. Do student labour protections not apply here?

MATH 115 & MATH 117 (Linear Algebra and Calculus): These were manageable. If you finished high school math with 85+ and stayed awake during lectures, you should be fine. The conventional wisdom that university grades drop 15% from high school doesn’t seem to apply here. Credit where it’s due: the Faculty of Mathematics has excellent professors and TAs.

COMMST 192 (Communication in Engineering): Fun and genuinely useful, but the workload was enormous. I spent most of my after-class time on COMMST 192 assignments, which is why I never finished the problem sets for ECE 105, MATH 115, and MATH 117. For me, this course had more work than everything else combined—though for most people, ECE 150 probably takes that crown. My Grammarly Pro subscription expired after reading week, which made catching errors significantly harder without AI assistance.

The Bottom Line: The schedule and workload are brutal for first-year students. It feels like the institution prioritizes tuition revenue over student well-being. If I were an MPP, I’d propose legislation requiring curriculum coordinators to complete their own programs before implementing them.

Co-op

This was the easiest part of my term, though I know it’s the hardest for most people. I was one of the lucky few who secured a good placement quickly. Many friends—including my roommate—are still searching. I’ve noticed tension building as some students without placements grow envious of those who have them.

The fantasy that everyone will land great co-ops for five years and walk into FAANG after graduation is starting to crumble. I knew this going in—friends with older siblings in CS and CE had warned me—but I applied anyway.

I taught myself most of this material before university and had two successful work experiences under my belt. Academically, 1A taught me almost nothing new. What I did discover was an unexpected passion for theoretical physics and pure mathematics. It’s too late to switch programs, though I don’t regret choosing computer engineering. I’m pragmatic enough to acknowledge that physics and math degrees don’t pay the same way.

Health

Now I understand why engineering and math students have certain reputations at this university.

Yes, the gym is open until midnight. But when you’re drowning in assignments, who has time to go? Before reading week, I’d see engineering students working out regularly. Now? I don’t know anyone in my cohort who still makes it to the gym. We’re all burnt out. Even the walk there feels like too much.

Mental health is worse. Friends from high school keep suggesting I date someone. But making a girlfriend—or even talking to women—isn’t realistic here. Achieving 80+ and finishing everything on time requires isolation. The gender ratio doesn’t help either. I don’t have exact numbers (and collecting them would be awkward), but it feels like somewhere between 10:1 and 15:1. We joke that finding a girl in our cohort is harder than finding a unicorn.

When you’re one week from finals, fighting a cold because the university didn’t call a snow day during an actual snowstorm, and you got sick trudging between classes—the combination of physical and mental strain is indescribable.

Food

The best thing about my first 18 years of life was that my mom is the best chef in the world. Food here tastes like sewage and costs a fortune. It’s borderline fraudulent.

I’m fortunate to be in a residence with the best dining hall on campus, but it doesn’t come close to what I ate at home in Ottawa. I’ve also learned that nutritional balance matters more than I thought. I got sick at least once a month because I refused to eat vegetables. The vegetables here don’t help—they’re not the fresh greens I had back home; they taste like they survived some kind of biohazard incident.

I don’t know why I was so stubborn about vegetables in Ottawa. I swear I’ll eat them happily when I go back after finals.

Conclusion

I wish I could have skipped first year entirely. There’s nothing here that matches what I expected back in June. A physics or mathematics degree might have been more intellectually fulfilling, but it would have left me broke after graduation. The current economy leaves little room for idealism.

On the bright side, I’ve discovered a genuine interest in physics and am now pursuing a joint honours. Hopefully this will make my tuition feel less wasted while I continue learning almost nothing new in my core engineering courses.

Resources

If you’re navigating Waterloo, I highly recommend Xierumeng’s “Guide to UW” blog series. It offers detailed guidance for each academic term, co-op terms, and other essential skills for succeeding here.

The Rush to Nowhere

University physics lectures move at breakneck speed. When students struggle with new concepts, they’re left with limited options: figure it out independently or seek help from teaching assistants who aren’t always available. The situation becomes particularly challenging for students arriving from educational systems where these foundational concepts weren’t covered—they find themselves simultaneously learning new material while racing against exam deadlines.

The Memorization Trap

Here’s what makes physics fundamentally different from most university courses: while chemistry, biology, and even engineering mathematics lean heavily on memorization, physics demands something else entirely. Every physics instructor I’ve encountered shares the same philosophy: “The only equation you need to remember is F=ma.”

Of course, this isn’t literally true—students must know formulas for energy, momentum, and wave mechanics to complete exams within time limits. But the underlying message is clear: physics should be about understanding systems, not memorizing solutions.

Consider elastic collisions between two objects. Most students instinctively memorize the velocity exchange formulas, while professors consistently discourage this approach, advocating instead for case-by-case analysis. This disconnect reveals a fundamental tension in how physics is taught versus how it’s tested.

Why Students Choose Shortcuts

The reality is stark: exams reward speed over understanding. When you have 50 minutes to solve five complex problems, methodical analysis becomes a luxury you can’t afford. Students who memorize formulas gain a clear advantage—not because they understand physics better, but because they can navigate the exam more efficiently.

This creates a perverse incentive structure. Physics problem-solving through genuine analysis becomes an IQ test under time pressure. Some students excel at rapid analytical thinking, but many others—who could solve these problems given adequate time—find themselves forced to choose between understanding and grades.

A Better Way Forward

The solution isn’t complicated, but it requires reimagining how we assess physics knowledge. Instead of rewarding formula application, we should structure evaluations to emphasize systematic thinking. Imagine a marking scheme that allocates points like this:

• 30% for system identification: Recognizing the relevant objects and forces

• 20% for visual representation: Creating accurate free-body diagrams and illustrations

• 30% for conceptual explanation: Articulating in words why and how the system behaves

• 20% for mathematical execution: Applying formulas to reach the numerical answer

This approach would make shortcuts through memorization insufficient. Students couldn’t achieve full marks simply by plugging numbers into equations—they’d need to demonstrate genuine understanding of the physical principles at play.

Crucially, such changes must be paired with realistic time allocations. There’s no value in testing analytical thinking if students must still race against the clock.

The Uncomfortable Truth

Despite these clear improvements, I’m skeptical we’ll see meaningful change. While I personally enjoy studying physics in my spare time, I recognize that most students have different interests and priorities. Without widespread demand for reform, professors have little incentive to restructure their courses.

The result? Physics remains trapped in its current form—simultaneously the most challenging and least engaging course of the term for many students. We’ve transformed a subject that should inspire curiosity about the natural world into a high-stakes memorization contest.

Until we’re willing to sacrifice some breadth of coverage for depth of understanding, and until we design assessments that reward thinking over speed, university physics will continue to feel less like an exploration of the universe’s fundamental principles and more like an academic obstacle course.

The Hackathon Gold Rush

Ontario’s hackathon circuit—Hack the North, Hack the Valley, DeltaHacks—follows a familiar formula: teams sprint through 24-36 hours of coding, judges crown winners, and everyone goes home exhausted. These events were designed to reward brilliant ideas and creative problem-solving. That original vision, however, has been casualties of a much larger shift in the tech landscape.

The post-pandemic job market fundamentally altered how students approach their careers. With supply dramatically outpacing demand in software engineering, stories of graduates struggling for years to find work have shattered the once-reliable narrative that a computer science degree guaranteed a pathway to Big Tech. Students who once believed GPA alone would open doors now scramble for any edge they can find.

Enter the modern hackathon: a perceived shortcut to distinction. Unlike GPA, where theoretically everyone can excel, hackathons produce a limited number of winners. Victory promises not just a line on a resume, but face time with senior developers and hiring managers from sponsoring companies. In this new reality, the original purpose—fostering innovation—has become secondary to career advancement.

When Competition Corrupts Innovation

The pressure to win has transformed hackathons into something unrecognizable. While rule-bending has always existed—teams uploading pre-written code to GitHub was once the height of cheating—the rise of LLM coding agents has fundamentally broken the playing field.

Today’s hackathon landscape rewards resources over creativity. Teams with premium AI subscriptions, multiple specialized tools, and access to various LLM models hold decisive advantages. When participants can generate entire project architectures and implementations without understanding the underlying code, we’re no longer measuring innovation or skill—we’re measuring who can afford the best digital assistants.

This pay-to-win dynamic violates the fundamental philosophy of hackathons. Instead of identifying the brightest ideas and most talented developers, we’re selecting for those with the deepest pockets and the most sophisticated AI toolchains.

The Hidden Cost: Technical Debt as Education

Perhaps most concerning is what hackathon culture teaches about software development. The sprint mentality—ship something, anything, in 36 hours—produces code that would horrify any professional developer. No version control, incomprehensible commit messages, zero documentation, and architectural decisions that would make maintenance impossible. These aren’t just bad habits; they’re anti-patterns that actively harm students’ development as engineers.

I regularly review code from serial hackathon participants, and the patterns are depressingly consistent: branches merged instead of rebased, creating labyrinthine Git histories; commit messages that explain nothing; code generated by AI that neither the author nor reviewer truly understands. One memorable submission included hundreds of lines of refactoring with a single-line commit message.

This is the opposite of what industry needs. While hackathon veterans chase the next win, they’re failing to develop the fundamental skills that matter: writing maintainable code, thinking about long-term architecture, collaborating effectively through proper version control, and—critically—understanding what they’re building.

The Wrong Lesson at the Wrong Time

Computer science students should be learning to write good code, not just fast code. They need a learner’s mindset, not an entrepreneur’s hustle. Yet hackathon culture teaches them to prioritize velocity over quality, prizes over understanding, and shortcuts over craftsmanship.

The irony is stark. While students optimize for ephemeral 36-hour sprints, the industry still runs on COBOL systems in financial institutions that have operated reliably for decades. We’re creating a generation of developers who can spin up a flashy demo but can’t maintain a production system, who can prompt an AI but can’t debug its output, who can win competitions but can’t collaborate on real codebases.

A Call for Better

Hackathons could be valuable learning experiences. They could teach collaboration, innovation, and yes, even how to work under pressure. But the current model—driven by job market anxiety and enabled by AI shortcuts—is producing the opposite of what our industry needs.

We’re teaching students to play a lottery rather than develop skills, to generate code rather than understand it, to win at any cost rather than build something lasting. If we continue down this path, we risk creating a generation of developers who view software as something to be generated quickly and discarded, rather than crafted carefully and maintained.

The “move fast and break things” mentality has its place in certain contexts. But when it becomes the primary educational model for our future developers, we’re not just breaking things—we’re breaking the very foundation of software craftsmanship that our industry depends on.

It’s time to reconsider what we’re really teaching when we celebrate the hackathon winner who cobbled together an AI-generated project they don’t understand over the student who spent the same weekend learning to properly use Git, understanding design patterns, or contributing to an open-source project. Because in the long run, I know which one I’d rather have on my team.

The Golden Era

“Microsoft’s favorite recruiting grounds were Harvard, Yale, Massachusetts Institute of Technology, Carnegie Mellon, and a little college near Toronto named the University of Waterloo.” — Hard Drive: Bill Gates and the Making of the Microsoft Empire

For decades, the University of Waterloo has occupied a unique position in North American tech education. While Canada boasts several excellent institutions—Toronto, UBC, McGill among them—Waterloo carved out something different: a co-op program so robust that it became the envy of engineering schools continent-wide.

The formula was simple and brilliant. Students would alternate between academic terms and work placements, graduating with two years of real-world experience. In the golden age of tech expansion through the mid-2010s, this wasn’t just an advantage—it was a golden ticket. The mythology around Waterloo computer science, software engineering, and computer engineering graduates landing FAANG positions wasn’t entirely exaggerated. Software jobs were abundant, companies were in perpetual hiring mode, and Waterloo students arrived battle-tested from their co-op experiences.

When Supply Meets Reality

But mythology has a way of creating its own demise.

As Waterloo’s reputation soared, two forces began reshaping the landscape. First, admissions became brutally competitive as students nationwide—and internationally—competed for spots in these “guaranteed success” programs. Second, and more critically, the tech job market underwent a seismic shift, particularly post-pandemic. The industry that once seemed to have infinite appetite for developers suddenly discovered limits.

Here’s the Economics 101 problem no one wanted to acknowledge: When supply surges while demand contracts, value plummets.

Today’s WaterlooWorks platform tells a sobering story. Software engineering positions that once attracted applications solely from computing students now see desperate bids from chemical and biomedical engineers, driven by scarcity in their own fields. The platform simply doesn’t have enough quality positions for its core computer science and engineering cohorts, let alone the overflow from other programs.

The Quality Crisis

But numbers tell only half the story. The more insidious problem is the deterioration in job quality itself.

Modern WaterlooWorks has become a hunting ground for startups operating on questionable foundations. Companies post positions before securing funding. “Teams” consist of two full-time employees supervising ten co-op students—a ratio that screams exploitation rather than education. The crunch culture that Silicon Valley is slowly abandoning has found new life in companies that view co-ops as disposable labor rather than future talent.

Consider this: One New York startup systematically fired half its co-op cohort for “financial reasons,” only to hire the exact same number the following term. The message was clear—conform to our crushing work culture or be replaced.

Most troubling is the persistent complaint, documented across decades of online forums, that the university itself prioritizes corporate relationships over student welfare. The institution meant to protect and educate has become, in many students’ eyes, complicit in their exploitation.

A Path Forward

The solutions aren’t complex—they require institutional courage.

First, implement supply-side discipline. If only 1,000 of 2,000 students secure meaningful co-ops (excluding programs like WE Accelerate), next year’s admission should reflect that reality. Yes, this intensifies admission competition, but it creates a more sustainable ecosystem where admitted students can focus on learning rather than surviving a hunger games-style job hunt.

Second, establish real oversight. The co-op office must evolve from placement facilitator to quality guardian. This means verifying companies’ financial stability, examining their employee composition, and ensuring they offer genuine learning environments. Startups using co-ops as venture-subsidized labor should find no place on WaterlooWorks.

The Waterloo Moment

The University of Waterloo’s co-op program revolutionized Canadian technical education and served as a model for universities nationwide. But models built for one era don’t automatically translate to another.

The question isn’t whether Waterloo can maintain its historical dominance—that ship has likely sailed. The question is whether it can evolve to protect what made it special in the first place: giving talented students real experience in supportive environments that foster both learning and career development.

The current system burns out students before they graduate, exploits their labor while they’re learning, and leaves many questioning whether the “Waterloo advantage” still exists. Without substantive reform, the institution risks becoming a cautionary tale about what happens when reputation outlives reality.

The co-op program doesn’t need to be perfect. But it does need to remember its purpose: education, not exploitation. The students flooding into Waterloo’s programs deserve the opportunity their predecessors enjoyed—to learn, grow, and launch careers, not merely survive.

That’s the promise worth fighting for.

How It All Started

My programming journey began when I was twelve, captivated by the portrayal of hackers in popular media. My first programming book (화이트 해커를 위한 암호와 해킹 (1st Edition) by 장삼용)—a Korean text on cryptography and network security in Python—was far beyond my comprehension at the time. While I can parse it effortlessly now, back then I grasped maybe 60% of the concepts, if I’m being generous.

Some of my earliest engineering experiences still baffle me today. At age ten, I successfully upgraded the network card in my mother’s aging laptop—a feat I still can’t quite explain. The machine shipped with Windows 7, but I was desperate to experience Windows 10’s sleek, modern interface. After multiple failed upgrade attempts, I dove into online forums, searching for others with similar symptoms.

I stumbled upon a blog post describing my exact issue with a nearly identical laptop model. The solution? A network card upgrade—Windows 10 apparently lacked drivers for the older hardware. Armed with nothing but this single blog post and unwavering determination, I ordered the recommended card, completely disassembled the laptop, swapped the hardware, and reassembled everything. The upgrade to Windows 10 went through without a hitch.

Looking back, I’m amazed that my mother trusted her ten-year-old with such a task. That trust would soon be tested.

The Incident That Changed Everything

My next experiment—attempting to dual-boot Ubuntu—ended in disaster. I accidentally formatted the entire drive, obliterating years of irreplaceable family photos and documents. Despite spending hundreds of dollars on professional data recovery, we salvaged only fragments.

This catastrophe convinced my parents that perhaps I needed my own machine for these experiments. When I was twelve, my mother made a unilateral decision to purchase me a $6,000 iMac—a purchase she hadn’t cleared with my father, who was our family’s sole income earner. The tension was palpable, but the deed was done, and my mother’s unofficial veto power prevailed.

I’d justified the iMac request by claiming macOS’s gaming limitations would keep me focused on programming. Naturally, I immediately installed Windows via Bootcamp and played games. But I also kept my promise—I discovered FreeBSD and became obsessed with contributing to its base system.

The Challenge of Finding Direction

Unlike web development, with its abundance of detailed roadmaps and tutorials, kernel development resources are scarce and scattered. This knowledge is typically reserved for third-year university courses, leaving self-taught programmers to piece together their own curriculum.

After years of trial and error, I’ve assembled the roadmap I wish I’d had when starting. While there may be more efficient paths, this one worked for me.

Roadmap to Kernel Developer

This is subjective path that I found and followed. There could be better roadmaps that are more efficient and in higher quality. I only listed books below because I believe that books are the most efficient, high quality, and accurate resources for programming. If you want to be a kernel developer, you’ll need to read a lot of standard documents, papers, and man pages. Learning through books can help you prepare for those situations.

1. Master the C Language

C is non-negotiable for kernel development. You need to read C code as naturally as you read English. The language itself is deceptively small, but its evolution means you’ll need multiple perspectives:

Start here:

• C Programming: A Modern Approach (2nd Edition) by K. N. King — An excellent introduction, though it doesn’t cover the latest standards

Then understand the philosophy:

• The C Programming Language (2nd Edition) by Kernighan & Ritchie — Not for beginners, but essential for understanding C’s design philosophy and machine-oriented thinking

Finally, modernize your approach:

• Modern C (3rd Edition) by Jens Gustedt — Learn how C is written today, which differs significantly from traditional approaches

2. Algorithms and Data Structures

Programming languages are merely tools—algorithms and data structures are what make programs actually do something meaningful.

Essential reading:

• Guide to Competitive Programming (3rd Edition) by Antti Laaksonen — A solid introduction to fundamental concepts

• Competitive Programming 4 by Halim, Halim & Effendy — Advanced material for serious practitioners

For Korean readers: 알고리즘 문제 해결 전략 by 구종만 remains my favorite comprehensive introduction to the field.

3. Computer Architecture

Understanding the machine beneath the code is crucial for kernel developers. You need to know how software and hardware dance together.

The heavyweight champion:

• Computer Systems: A Programmer’s Perspective (3rd Edition) by Bryant & O’Hallaron — Dense, comprehensive, and absolutely essential. This textbook assumes self-directed learning, so prepare for extensive research and problem-solving.

Alternative perspective:

• Computer Architecture: A Quantitative Approach (7th Edition) by Patterson & Hennessy — Highly recommended by the community

4. Operating Systems

After 1-2 years of foundation building, you’re ready for the main event.

Modern and accessible:

• Operating Systems: Three Easy Pieces by the Arpaci-Dusseaus — More current and approachable than traditional texts, available free online (though I recommend print for your eyes)

For Linux enthusiasts:

• 디버깅을 통해 배우는 리눅스 커널의 구조와 원리 by 김동현 — Hands-on kernel hacking (Korean only, unfortunately)

For FreeBSD developers:

• The Design and Implementation of the FreeBSD Operating System (2nd Edition) by Neville-Neil & McKusick — Comprehensive but theoretical; essential for FreeBSD contributors

The Reality Check

This roadmap represents a minimum three-year commitment. Unlike web development’s relatively quick onramp, kernel development demands deep understanding of both software and hardware layers. And this is just the beginning—kernel developers never stop learning, constantly adapting to new architectures, technologies, and paradigms.

I’ve completed most of this curriculum and still consider myself a novice. If you’re serious about kernel development, you need two things above all: genuine passion for systems programming and the humility to embrace lifelong learning.

The path is long, the learning curve is steep, but for those who persist, you’ll gain the ability to work at the very foundation of modern computing. Is it worth it? For me, absolutely.

The University of Waterloo’s co-op program is both its greatest strength and its students’ most daunting challenge. As a Stream 4 Computer Engineering student, I barely had time to settle into my 1A term before the job hunt began. September rolled around, and suddenly everyone was polishing résumés and practicing for interviews. The university requires five co-op credits to graduate—a requirement that feels overwhelming when companies barely glance at first-year applications.

My WaterlooWorks experience was typical: three interview offers, all for web development roles. A California startup reached out directly through my résumé, only to ghost me after I replied. The other two—a company in Oakville and a startup in North York—interviewed me, but my heart wasn’t in it. I’d done enough web development to know it wasn’t my calling.

it wasn’t my calling.

That’s when I remembered where I truly belonged: the world of operating systems.

A Five-Year Journey to My First Co-op

My journey with kernels and CPU architectures began long before university. At thirteen, I submitted my first patch to the FreeBSD Project. That first commit on May 5th, 2021, marked the beginning of a consistent contribution habit that carried me through high school. I spent my free time diving into man pages, updating C17 implementations in the base system, and helping import jemalloc 5.3.0—unconventional hobbies for a teenager, but they were what fascinated me.

I never expected rewards—seeing my name in git logs was reward enough. But those five years of contributions (always balanced with schoolwork as my priority) became my unconventional path to my dream co-op.

Operating systems are typically third-year material at university. Most students don’t touch kernel code until they’ve built a solid foundation in computer science fundamentals. Yet here I was, a first-year student with half a decade of practical experience in the field. After realizing this unique position, I reached out to a developer at the FreeBSD Foundation—someone I’d met during my two BSDCan attendances, sponsored by the foundation.

Against all odds, they offered me my first co-op position.

An Ambitious Roadmap

My plans for these four months at the FreeBSD Foundation are ambitious, perhaps overly so. The review process is strict, and time is limited, but I’m determined to contribute as much as possible:

• Infrastructure modernization: Migrating our code forge to Forgejo

• Documentation enhancement: Creating comprehensive kernel documentation (Doxygen + Sphinx + Breathe + Exhale) inspired by the Linux Kernel documentation

• Performance optimization: Adopting AVX/AVX2/AVX10 SIMD instructions in libc based on simd(7)

• Standards compliance: Implementing C23 and Single Unix Specification requirements

• Compatibility improvements: Matching Linuxulator and Linux KPI functionalities to the latest kernel

• Scheduler optimization: Enhancing sched_ule(4) for hybrid processors (Intel P/E-core, ARM big.LITTLE)

• Continuous bug fixes: Contributing to overall system stability

This first co-op is about mastering operating system fundamentals. Looking ahead, I’m already mapping out my trajectory: exploring CHERI and RISC-V ports for my second and third terms, with companies like Capabilities Limited and Codasip on my radar. Eventually, I want to delve into processor design with HDL and compiler development.

Swimming Against the Current

While my peers chase positions in web development or applied AI—fields increasingly dominated by LLM coding assistants—I’m deliberately choosing a different path. Too many startups treat co-op students as cheap labor, burning them out with repetitive tasks that teach little of value. Big tech companies, despite their prestige, often mean following a manager’s roadmap rather than exploring the technology that fascinates you.

I’m not chasing the highest salary or the most recognizable company name. I’m chasing knowledge in the field that has captivated me since I was thirteen. The FreeBSD Foundation saw something in me—perhaps the same passion for operating systems and CPU architectures that has driven me all these years.

The Value of Hard-Won Experience

Waterloo’s six co-op terms might seem grueling to some, but I see them differently: 24 months of deep, hands-on experience in a field that typically requires years of study to enter. While balancing operating systems work with undergraduate studies is challenging, these co-op terms offer something invaluable—the opportunity to learn by doing, to contribute to systems that power the internet’s infrastructure, and to work alongside developers who’ve shaped the technology we rely on daily.

The FreeBSD Foundation took a chance on a first-year student with an unconventional background. Now it’s my turn to prove that passion, combined with years of consistent contribution, can be just as valuable as a traditional academic path.

Memory safety bugs cause 70% of cyber vulnerabilities, leading to disasters like OpenSSL Heartbleed and the 2024 CrowdStrike outage ($5.4 billion in losses). The CHERI technology, developed over 15 years by Cambridge University and SRI International, prevents these attacks through hardware-enforced memory protection rather than endless software patches.

The momentum is extraordinary. The UK government invested £80 million alongside £200 million from industry, with backing from DSIT, NCSC/GCHQ, DSTL, and DARPA. Industry giants Google, Microsoft, and Arm have joined alongside BT Group and Siemens, recognizing that hardware-level security is no longer optional.

I’m particularly excited about our working groups porting critical operating systems to CHERI. FreeBSD, FreeRTOS, Zephyr, and seL4 have all been ported to run on CHERI hardware, with teams actively developing and maintaining these implementations. This ecosystem work ensures CHERI can protect everything from embedded IoT devices to enterprise servers, making memory safety accessible across the entire computing stack.

Microsoft found CHERI would have prevented two-thirds of their 2019 vulnerabilities. The technology is practical too – existing software often needs less than 0.03% code changes to become memory-safe. As we deploy AI and connect critical infrastructure, we can’t afford to keep patching symptoms. CHERI addresses the root cause.

While I originally launched this Substack to chronicle computer architecture and university life, my passion for operating systems has taken the wheel. Going forward, you’ll find articles, updates, and announcements covering operating systems and CPU architectures—particularly FreeBSD, Linux, CHERI, and RISC-V.

If your company takes cybersecurity seriously, consider joining the CHERI Alliance. We’re building secure-by-design systems and welcome everyone who shares this vision. It’s time to stop playing defense against memory vulnerabilities and solve the problem at its root.

I've been in web development since the end of 2023, for almost two years now. My first project was a summaive project for my Grade 11 English class written in Next.js. After that, I built websites for my school band and city jazz band, again, written in Next.js. At first, it was fun, with all those Tailwind CSS and state management. Unlike other programming areas, I could see the results of my work immediately just by running next dev in my terminal. Compared to SwiftUI, web development felt more easier but more fun, especially with npm libraries that faciltate the development process.

Then, I found Vite and SvelteKit. I was amazed by the compiler approach (which Vue and React now have experimental support for) and the performance of Svelte. SvelteKit was similar to Next.js, so it was pretty easy to learn the fundamentals. I migrated all my three websites to SvelteKit, and it was a breeze. However, I encountered my first challenge in web development — dependencies. In my Next.js projects, I heavily used Motion (it was called Framer Motion back then). It was a great library, as I could apply fancy animations in a few lines of code. But it was binded to React, so when I migrated to SvelteKit, I had to implement the same animations in a different way. I spent almost a week trying to implement the same animations in Svelte, and that was the first time I was disappointed by the web development ecosystem.

First Big Project in My Life

Around the end of 2024, I joined Poliwave, a platform that provides Canadian election projection. I was the only developer with previous experience in the team, and I was responsible for the frontend and backend. I was excited to work on a project that was actually useful, and I was excited to work with a team that was actually professional.

However, it was too difficult to maintain such a large project by myself. I was the only developer, and I was responsible for both the frontend and backend. I was overwhelmed by the amount of work, and since my colleague who maintained the actual electoral projection also wrote the code for the web app, it was really hard to maintain the codebase in a good state. Sometimes the code was deployed even though it failed checks on GitHub Actions, and when I tried to fix the issues, it was too late to fix them without reverting the changes to the initial state.

At last, it reached the state where the website was lagging and it had glitches everywhere, but I was unable to debug and fix the core issues due to the low quality of the codebase. We added patches on the codebase to mitigate the issues, but since the code was already in a bad state, another glitch appeared after the patch was applied.

We also had to migrate between different UI libraries, and everytime we did, it broke the existing codeflow. Since it was really hard to create our own design system in a team of two, we had to use a third party library, and it was painful to find the right components to use. Even though we made a decision on which library to use, our mind changed in a few days, and we had to migrate to a different library again.

I felt too tired of spending so much time and energy on visual side of the project. Unlike other fields of programming, frontend development is mostly about designing and implementing the UI, not the core logic of the project. Instead of building a complete project, I was just destroying and rebuilding the project over and over again without any progress.

For these reasons, I lost interest in most part of web development. Except for reading release notes of SvelteKit, Vite, and Bun, I switched to other fields of programming such as operating systems, embedded systems, AI, and blockchain.

Got a Job

In July 2025, I got a summer student job at CHEO RI, a research institute in Ottawa. I love the work I do there and my colleagues are great, but while I was working on the project, I made my decision to leave web development after this job is over in August.

My team spent first three days on determining the tech stack, which was changed again on the next week. I felt very unproductive and saw myself as a website designer, not a programmer. As a side project, I built a RAG-based chatbot platform with my friend. Because we focused more on the programming aspect rather than the design aspect, it was way more fun than any of my web projects.

I also studied blockchain and AI, and I was amazed by the potential of these technologies. I also had an opportunity to revisit the computer architecture and low-level programming, and although they were more difficult than web development, they didn't cause me as much frustration as web development did. I felt that I was being a computer engineer, not a designer, and that was the time that I decided to leave the world of web development.

Issues with Web Development Ecosystem

The Ecosystem is Too Fragmented

Let me list some technologies you can use to build a web project:

• Runtime: Node.js, Bun, Deno, etc.

• Framework: Next.js, SvelteKit, Nuxt.js, Astro,etc.

• Library: React, Vue, Svelte, etc.

• UI Library: Tailwind CSS, Shadcn UI, etc.

• Package Manager: npm, yarn, pnpm, bun, etc.

• Build Tool: Vite, Webpack, rsbuild, Turbopack, etc.

• Testing Framework: Jest, Vitest, Playwright, etc.

• Linting & Formatting: ESLint, Prettier, etc.

• Typing: TypeScript, JSDoc, etc.

• Database: Supabase, PostgreSQL, etc.

• Hosting: Vercel, Netlify, etc.

• CI/CD: GitHub Actions, GitLab CI, etc.

• Monitoring: Sentry, etc.

• Analytics: Google Analytics, etc.

• and so on...

There are so many options to choose from, and there is new technology coming out every day. In 2025, people complain about the best LLM model being updated every month, but compared to web technologies in 2022-2024, it's not even a big deal. It's really hard to keep up with the latest trends and technologies, and it's hard to find innovation in the web development ecosystem. The last time I remember innovation in the web development ecosystem was when Svelte introduced the compiler approach and when node-rs made using Rust in web development possible. Apart from that, most hyping techonologies that appearaed in that era is not even mentioned anymore (Who remembers Remix, MongoDB, Gatbsy, etc?).

Unsafe Nature of Javascript

No, I'm not talking about memory safety like C/C++. I'm talking about the type safety of Javascript. Although Typescript and JSDoc are great, they are not the core specification of Javascript. I used Typescript in my projects, but my colleague didn't follow the type safety rules, and even deployed the code while the CI check was failing. If this was a C/C++ project, the binary would have been built at the first place, even though they might contain memory safety issues.

Ecosystem that Has Both Legacy and Modern Technologies

In Javascript ecosystem, we see a lot of legacy syntax and technologes and their modenr counterparts. Callback vs async, Webpack vs Vite, CommonJS vs ESM, etc. Some times we need to use Javascript transpilers to run code on old browsers due to lack of something like ABI compatibility. Although this is not a big issue for building a new project, it's quite problematic when you're maintaining a legacy project. Imagine that you are working on two projects, one is relatively new using Vite and ES6 code while the other is legacy project using Webpack and deprecated Vue v2. Yes, it would be very painful to maintain those two at the same time.

You might say that this is the same problem in other fields of programming. But in web development, this happens too frequently. C++98 was used for 16 years until the release of C++11. Although there have been new features in C++20, it was not a major overhaul with breaking changes like CommonJS to ESM or Vue v2 to Vue v3. Note that while using C++11 is not legacy in 2025, Webpack, which people replaced with Vite, was released in 2012.

What's Next?

As I'm going to the University of Waterloo for computer engineering, I will focus on embedded programming and circuit design. I will also study AI and blockchain, although I'm not sure if I will be able to use them in my future career.

Although I will still follow the release notes of SvelteKit, Vite, and Bun, I will completely keep distance from the web development ecosystem. The only reason I'm still following the release notes is because I believe that those three are the only innovative projects left in the web development ecosystem. Others seem to repeating same ideas over and over again, which I'm not interested in.

Edit for September 20th, 2025: For the last two months, I’ve tried many things: infrastructure, database, AI, etc. At the end, I chose operating systems and compilers for my future careers. Even though I’ve been learning those for more than three years now, they are the most interesting and fascinating topics to me.