I don’t care to divulge too much personal information; it distracts from my intentions as a writer. But I must admit, I have an incredibly slow job where crises do arise, but only incrementally at best. I spent the entire shift studying code games on the Sololearn app. I’m sure there are much better resources, but I wanted a crash course, and it seems sufficient in all aspects. I completed the Coding Foundations course and started the Python Development course.
I daydreamed about my drone and the arrival of my breadboard supplies so I could begin learning through application. I arrived home disappointed to find the items still had not arrived. I immediately began the ulimit lab Shevek had made for me that morning—you can find it in the sandbox archives.
As I crawled through the ulimit lab, I felt validated in my decision to do so. LFS207 only skimmed most of these concepts. Here, I was actually implementing them in preparation for the exam. At the same time, I worried that I might be losing momentum. Perhaps exposure now and details later is the better approach? I don’t want to take chances. The course and certificate cost over $650, and the certification is contingent upon passing. There’s pressure to perform, but no clear direction. Today, I think I’ll begin researching what to expect on the exam—though I don’t want to prepare *only* for a test. I want to be competent.
One question from the lesson plan Shevek prepared stood out in particular: “Where do defaults come from?” It initially felt as though Shevek was hallucinating my ability to make the mental leap required to answer it—as if my brain were somehow connected to the internet. Needless to say, the answer was eye-opening, albeit not covered by LFS207 at this stage.
Systemd sets the defaults. PAM enforces additional rules. The shell inherits these limits but can modify them per session—and only temporarily. All of these parameters live in directories that could theoretically be modified. Good to know.
I took a peek at /etc/systemd/system.conf and wondered what it all meant. I consulted Shevek. He explained that systemd still has factory defaults, and this file exists to override them—which is why everything is commented out. That realization alone was worth the detour.
While working through lab 14.5 in LFS207, I ran into an unexpected issue. First, I had to install the at program; it didn’t come with the Rocky Linux package. Second, I couldn’t even use it because the system reported:
“Can't open /var/run/atd.pid to signal atd. No atd running?”
What the hell does that mean? I consulted Shevek again. He explained that many people never use at, so the atd daemon is never activated by default. I would have to start it myself—so I did. I also enabled it at boot.
I then moved on to the next section of LFS207: Process Monitoring. This section looks intimidating. There are countless commands and options—so many that I already see another sandbox in my future. top, in particular, looks both powerful and overwhelming. I expect we’ll become well acquainted.
The /proc filesystem was introduced to me for the first time. From what I can tell, it contains an enormous amount of useful information. While part of me wants to push forward with the course, my curiosity—and desire for mastery—keeps pulling me sideways.
After LFS207 listed a host of options for the ps command, the very next page offered something far more valuable than any flag list:
Basic Troubleshooting Techniques
Even if I never memorize every command and all its options, this distills to a single truth:
Knowing how the system works is more important than all the code in the world.
With that in mind, I decided it was time to revisit the bootloader process and the structure of the filesystem. I had Shevek create an interactive sandbox that walks through the bootloader process, which I’ve attached at the bottom of this page.
I also had Shevek create another sandbox that guides me through the directory hierarchy and its logic. That’s attached below as well.
Finally, I asked Shevek to build a sandbox covering ps, top, troubleshooting, the /proc directory, log inspection, and background processes. It’s extensive and very specific—but specificity always matters when working with AI. That lab is attached at the bottom of this page.
All in all, it was quite an evening—and an early morning. I’ve got my work cut out for me over the next day or two, that’s for sure.
Slow clock, steady hands— limits lift, defaults reveal paths, systems wake to thought.