Sabitlenmiş Tweet
KernelNomad
119 posts
KernelNomad
@KernelNomad_
Systems nerd. Hacking @zymtrace. Building an OS kernel in Rust and userspace in Zig currently.
/nix/store Katılım Nisan 2026
33 Takip Edilen12 Takipçiler
@athre0z oh boy, it just feels like a huge pain but could be a fun experiment with an LLM :d
English
@KernelNomad_ Would be kind of fun to teach zymtrace to peek into qemu Linux guests, wonder how much work it would be
English
In my kernel, sleeping tasks are checked on every timer interrupt to wake up expired timers.
Originally, I stored them in a Vec and scanned it every tick. That worked, but removing an arbitrary element is O(n), and keeping the Vec sorted makes insertion O(n) instead.
I switched to a BinaryHeap>, making both insertion and removal O(log n).
I also cache sleep_until inside each heap node instead of reading it from the Task. That means I no longer need to Arc::upgrade() the Weak while traversing the heap, and the hot path has better cache locality.
I'm expecting this to be noticeably faster, but I'd rather measure than assume. One of my next tasks is adding in-kernel benchmarks so I can quantify changes like these instead of relying on intuition.
(Being a profiling nerd helps.)
English
@lauriewired I simply think it's because people just do it for a living and just happy to get to the same outcome (could be less quaility or buggy but still a working outcome) with less effort.
English
I’m convinced that a large % of programmers don’t actually like computers.
As a side effect, are also perfectly happy to throw away their reasoning to a model as soon as they can.
I don’t get it, at ALL. Don’t you *LIKE* understanding the magic of the machine?
You do realize hand-programming (I hate that I even have to specify hand now) is fun…right?
English
I agree with this because pre-AI, writing the code was not the main skill. It was going through a lot of different design choices, tracking nasty issues, going through other people's solutions and diving into huge codebases. Top engineers were so used to doing these so they had good understanding. Mids just didn't bother. Now, mids using the AI in a way that it replaces their thinking because they cannot keep up with it in terms of comprehension and this increased their lazyness while giving them an insane confidence. But top devs **drive** AI to do crazy amount of work in a small time while being able to understand the outcome. And be able to identify when AI did a shitty job and iterate.
Michael Arnaldi@MichaelArnaldi
This will piss you off but it's true
English
I work on a profiler at work. Our profiler-related PRs are small but usually contains deep logic and research behind it. Writing code is not the bottleneck for us. And understanding how the profiler really works is very valuable. For CRUD stuff, I agree that reviewing code will be less necessary but I don't think that will be the case for research-heavy parts of the industry (at least in a few months). But I use AI daily to make it easier for me to understand changes and test my claims.
English
Manually reviewing code is going to disappear in a few months.
Mark my words.
dax@thdxr
issue comes in tag opencode opens a PR with a video verifying fix
English
After writing Zig for some time as a Rust nerd, I think I like the verbosity of unsafe in Rust. The combination of 1 unsafe block per unsafe operation + the safety comments make it definitely harder for funny errors to slip into the codebase. It's also easier to debug ig.
And for the "skill issue" guys, a small disclaimer: Yes I'm not as skillful or magnificent as you. I have skill issues.
English
@awesomekling Im building an os kernel and a profiler. Good luck to my wife using them lol
English
If you're a married programmer and your wife isn't using at least one of your custom apps daily, you're missing out on one of the most rewarding experiences in programming. Build wifeware!! 🤓
English
@rustrover Building a Rust kernel from scratch. Specifically working on page faults and fork/exec syscalls this weekend.
github.com/aeryz/efiks-os
English
Any fun Rust projects on your radar this weekend? Share what you’re building or learning below 👇
English
I really need to make use of ASID's and targeted TLB flushes tho. Right now, every page fault handling and every ctx switch flushes the whole TLB.
KernelNomad@KernelNomad_
My kernel now supports lazy allocation and page fault handling 🎉 Here is how it works: 1. A userspace program requests, say, 10 × 4 KiB pages (40 KiB). 2. Instead of allocating physical memory immediately, the kernel records that this virtual address range is valid and remembers its permissions.. 3. When the program first accesses one of those pages, the CPU raises a page-fault exception. 4. The kernel verifies that the access is valid, allocates a physical page, updates the page table, and resumes execution. In the attached image, my Zig BrkAllocator reserves 29 pages, but the test program only touches one of them. As a result, the kernel handles exactly one page fault and allocates only a single physical page.
English
See the link to the PR for implementation.
github.com/aeryz/efiks-os…
English
My kernel now supports lazy allocation and page fault handling 🎉
Here is how it works:
1. A userspace program requests, say, 10 × 4 KiB pages (40 KiB).
2. Instead of allocating physical memory immediately, the kernel records that this virtual address range is valid and remembers its permissions..
3. When the program first accesses one of those pages, the CPU raises a page-fault exception.
4. The kernel verifies that the access is valid, allocates a physical page, updates the page table, and resumes execution.
In the attached image, my Zig BrkAllocator reserves 29 pages, but the test program only touches one of them. As a result, the kernel handles exactly one page fault and allocates only a single physical page.
English
Not having guard pages around the kernel sp bites me every time. Finally adding one. What happens here is, at the first call, I allocate the root page table and the second one is allocating the kernel stack. But since my frame allocator is a bump allocator, they are put back to back and any time the kernel stack underflows, my root page table gets rekt and I'm not even hitting my trap handler to catch the error, just complete failure.
English
English
We do the same. And apart from it keeping the code quality very high, it also makes it very easy for others to pick up each others tasks or work outside of their comfort-zone. Because after some point, everyone has a good overview of every component even if they don't directly work on it. This also ensures everyone completing the tasks with the whole system in mind. That's actually how proper engineering is done imo but my AI-pilled bro told me that we are wasting our times 🤡
English
At TigerBeetle, as systems engineers, we:
1. write code, sharpening skill and second order understanding
2. read code, walking through the building to constantly improve things
3. review code, ensuring no code is merged without two engineers’ understanding and review.
English
@mitchellh Keep up the good work! I'm very much interested in a writeup on how you achieve this performance tho. Is there already a post on this I missed?
English
Mind boggling to me that I can make a thing faster and there's always people that ask "but why?" What kind of mentality is that? The pursuit of excellence does not need justification. Also, I find in so many cases, we can't know the impact of an improvement until we do it.
For example, one I've talked about before: Ghostty's high IO throughput has enabled terminal program (emulator and TUI) fuzzing at a speed thats incomparably fast to prior solutions. This has resulted in upstream patches to resolve issues in popular projects like btop, tmux, and more.
Speed enabled that anecdotally example that lifted the tides of adjacent communities that don't rely on Ghostty technology at all. I didn't predict this.
Make things better because they can be better and let the results naturally play out.
English
@lauriewired @TheCherno I havent written a single cpp for several years but still watch his videos from time to time. Truly a fan.
English
@TheCherno has such an excellent programming channel.
Been a fan for a while now, figure it deserves a shoutout if you haven't seen it before!
English
Based on the PR, if its refactoring, I skim through it and pay less attention. But if it's critical, I take my time to really understand it. Understanding "why" is never enough for my work since its highly performance-critical. But even if it is not, if you are a decent engineer who is working on a system with some complexity, you must understand it and be careful when you add code.
English
The "should you read code" debate is dumb because the real decision isn't binary, it's a scale:
1. Reading every line of every diff
2. Scanning every diff, reviewing important lines
3. Ignoring diffs but understanding the 'why' of every PR
4. Spot checking PR's instead of reading every one
5. Ignoring PR's, but doing regular spot checks on the codebase
6. Ignoring the code, but spot checking agent traces to help improve the system
7. Ignoring both the code and the system, let models handle everything
Where are you on the scale?
English
It's not nice that you cannot override a default setting in helix and I have to patch `languages.toml` in Nix. Thank god im using nix and its very trivial to do so but not nice anyways.
English
@0xAX Do a really bad job at first and you will still be able to rewrite it in Rust
English
Started a new project in rust. Already feeling I lost one important milestone in future - time to rewrite it in rust
English
The token spending between "LLM do this" version "LLM, here is what we have, here is how I want you to do this, do it" is insane. With the latter, I both keep my knowledge and the code quality good and do my work with a 20$ Codex subscription. Plus, I enjoy my work even more because I don't have to deal with monkey work and it is now viable to quickly try different solutions. Still dunno why people act as if they have no capability of thinking instead of using this powerful tool to get the most out of themselves. Anyways, less strong engineers to beat at least.
English