This list is of no particular orderning, neither of importance nor chronological. It is written in the order in which I remembered them as I was writing this.
Designated Initializers in C
This link explains designated initializers in C.
I found it while reading through the BBFS explanation which included a struct in which the members were defined starting with a dot (.) which I had never seen before.
I find it interesting that despite underestimating C as a “simple language”–not to say that it is easy, but simple–I keep finding new things about it every so often.
fprintf
This link very comprehensively describes the specifications for fprintf, sprintf, snprintf, and dprintf.
I find it interesting because although I was somewhat aware of the existence of fprintf and sprintf during my time learning C a year ago, I was not aware that it had deeper technical differences beyond that one is “for files” etc.
I suppose to some extent that could be due to the fact that the only other programming language I knew was Python and I had taken for granted the fact that language constructs such as variable-length arguments was not a luxury available to the people developing Unix and C.
Writing a FUSE Filesystem in Python
This link describes the process of creating a FUSE filesystem, akin to that of Joseph Pfeiffer’s tutorial of the same kind in C, using the fusepy module.
The reason this is interesting needs some context: some time during my first semester, I had developed a strange love-hate relationship with Python–it was the only language I knew as a newcomer to Computer Science, but nonetheless I had adopted some notions about what a “good” language should be.
Namely, I thought it should be something akin to C.
There was this strange idea in my head that despite not knowing anything close to the low-levelness of C, I was convinced that learning a language as high-level as Python was “damaging” my knowledge of programming, and that I would eventually become stuck in it.
This one flips my ideas upside down, really revealing to me that even the mere concept of filesystems is something that can be handled from a high-level perspective.
It is necessary to note though that filesystems by themselves aren’t inherently low-level; in fact they’re high-level from the perspective of someone from, say, the 1960s.
printf() isn’t actually defined in C
The link above is a quotation from the K&R specification book on C, which explains that printf() isn’t an actual part of C itself, but is in fact part of the stdio.h library.
While I had discovered this fact long ago–via an unfortunate accident of removing the library from the top of the file before compiling and getting surprised that it doesn’t run–it does slip by my mind from time to time.
It’s interesting to me as the idea of something that generally everyone takes as a fundamental programmer right in computing is actually not, simply due to how the language and its intended environment is designed.
An Introduction to File Compression on Linux Servers
This link provides a very high-level, brief, and non-exhaustive review of the several compression schemes available in Linux and specifically, tar.
It’s a fun read at least for myself though for someone who’s already been thoroughly familiarized with the compression tools mentioned here, it wouldn’t be interesting.
Quick Benchmark: Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO
This link provides a very thorough benchmark of the various compression algorithms implemented intar, and it does so with pure, raw numbers.
I think it’s interesting because it serves as a good companion piece to the previous link: it provides the comparisons one would need in very quick numbers for consideration when choosing which compression scheme to use.
Linux Directories Explained in 100 Seconds
This link is a (very approximately) 100 second video on the Linux directory specified by its Filesystem Hierarchy Standard.
I think it’s interesting purely for the single factoid that the /etc directory is named after “Editable Text Configuration”.
For the longest time I had thought it literally meant “et cetera” as this directory also exists in Windows and its sole purpose is for the hosts file.
Though, as far as I’ve researched after finding out about this acronym, it may be merely serendipitous rather than intended.
Still, though, a pretty funny coincidence.
File Descriptors
This link is a comprehensive explanation of what exactly “file descriptors” are.
I came across it when I was reading the Pfeiffer tutorial and was greeted quite readily with the term “file descriptor” and “file pointer”.
While I was aware of what a file pointer was, as the name very plainly suggests, I had no clue what a “file descriptor” was or why it would be an integer instead of a string–I had assumed it was some sort of metadata.
Another possibility, I thought, was that it was another built-in C feature; I suppose I was fooled by the fact that both are related to files.
It turns out, no, it’s just an array index for the kernel to list open files.
Which is pretty interesting when you think about it: the concept of a filestream is so far abstracted so as to only be understood by most people as a stream of bytes that magically gets transported into the device whenever a file closing function is called.
At least, that was how I envisioned how file opening and closing would work.
I was very unaware that it had this many layers to it.
Mounting and Unmounting File Systems
This link is a very short introduction to the idea of filesystem-mounting and what it actually does, at least at a high-level description.
For context, this week I had the unfortunate experience of having to manually partition the virtual disk on my Debian guest using the mere sticks and stones available: fdisk, mkfs and umount.
I was at the last part where I had to mount the actual partitions into the directory tree when I suddenly realized: “Wait, what does mounting even do?”
Being a long time Windows-user, I only knew vaguely that mounting makes the system “know” where the storage parts are, but I wasn’t exactly sure of what’s going on.
For all I knew mounting just happened in the background or something.
So I looked it up, and sure enough it’s actually pretty simple; all mounting performs is disclosing to the system where a filesystem or storage component is and attaches it to the directory tree.
I think it’s pretty interesting, especially if you were to have the same background as me, being almost wholly unaware of the nitty-gritties of operating systems up until taking this subject.
Which Linux File System Should You Use?
This link is a brief introduction to the various file systems available for Linux systems.
I think it’s interesting because it may not be apparently obvious, even after finding out about something like FUSE, what the differences between file systems are.
At least, it wasn’t obvious to me, that different file systems could need something beyond different implementations of read() etc., but also entirely different file structures, provisions on limiting partitons, on dealing with fragmentations, on dealing with power-offs, and the like.
Specifically to that last point–dealing with power-offs–it wasn’t immediately obvious to me what “journaling” meant when I first saw it reading the osp4diss tutorial on installing Debian.
It didn’t occur to me to look it up until I eventually stumbled on to this link which also explains what journaling is in file systems.
That’s it for now. またね！