sunday_serif
Joined 4 years ago
Joined 4 years ago
Once you start to dig into how computer hardware really works, you start to realize that nothing is really O(1).
If you’ve never looked into computer hardware, you’d believe that lots of the primitive machine operations like reading and writing a value are O(1). But on modern hardware, they can be far slower. And that’s before we even get into out of order instructions etc.
So by the authors definition, I guess assembly and machine code aren’t real systems languages ;)
I use LLMs for most info now, any slightly ambiguous query really. Often times I use the LLM to figure out what source I should find, then I just use google for retrieval
When I want to “surf the web” I use kagi search (usually with small web filter) when I want to see sources written by people. This isn’t that often, but when I need it kagi is the best!
An example, the other day I wanted to make fermented hot sauce, and I couldn’t remember how much salt was needed for the fermentation. I could google and get served hundreds of crappy ad ridden recipe sites that have the answer to my question buried under five pop up videos, or I could ask an llm with one or two follow ups and have a much more pleasant experience.
Then when I decided I wanted to follow a real recipe I used kagi with small web to find a recipe page that wasn’t an ad farm.
A few more steps than google, but all and all so much better.
The hard parts seems to be figuring out (1) how to cut red tape for only certain projects and (2) figuring out what red tape to keep.
Chesterton's fence and all that.
I often feel like those who haven’t done the exercise of understanding the ISA of a “fantasy cpu” have a really hard time understanding those more advanced features.
I guess all I am saying is that learning the “fantasy cpu” still has value even if everything else in the real world is more complex.
Walking before running and all that.
I often have an idea for a post that would be interesting, but then as a learn more about the topic in order to write, I start to realize how much I don’t know. At this point, the post either dies or I spend way too long learning every irrelevant detail until I feel like I know enough.
So I think the skill I am trying to learn is writing as a non-expert. Learning to write in a tone that makes it ok to not know everything. Writing in a tone that conveys my experience and understanding, but doesn’t try to be an authority on the subject.
Writing is a tough skill!
The course has you make useful extensions to a reimplementation of the XV6 kernel in RISC-V.
This course really helped me start to understand how an OS works and what the hardware software interface really is.
[1] https://pdos.csail.mit.edu/6.828/2020/ — linking to the 2020 class because all of the lectures were uploaded to YouTube to accommodate remote work during the thick of Covid.
Each chapter of the book includes a test suite to run against the code you’ve written.
In some ways, the tests in this book feel very similar to the labs in the book Computer Systems: A programmers perspective — which is high praise!
I think it really allows you to grasp some of the more intricate and nuanced parts about building a programming language.
You can encounter all of the big ideas in the first half of the book and gain enough familiarity with them so that when you revisit them again in the second interpreter, you can actually absorb the interesting parts.
Such a phenomenal book!
It is an excellent tool that covers a lot of the gaps in the QEMU documentation.
Curious which devices are memory mapped to which regions on your virtual board and the docs aren’t specific? Check the device info in the monitor!
Want to know what interrupt signals a device might generate and can’t find that info in the docs, use the monitor to check!
It’s honestly a life saver.
A cool tip I recently found to make using the Monitor easier when you are running your QEMU machine in nographic mode is that you can have QEMU read and write the monitor to a file on your system. Then you can use a tool like socat to have one terminal running your QEMU machine and another running your monitor! Super convenient.
This stack exchange answer explains the details:
https://unix.stackexchange.com/questions/426652/connect-to-r...
Once I understood that and reframed the contradiction as a statement about unsatisfiability… I could then see directly how the positive result you get is the equivalent logical consequence.
Unfortunately, I feel like this intuition only really helps if you are pretty immersed in formal logic… otherwise it just sounds like jibberish.