Quorten Blog 1 started out as mere text files written in a quasi-Markdown syntax, originally not available online. Actually, most of the text came from only two huge text files. With the help of some automated conversion tools, these notes were brought into the 21st century in blog form. Incidentally, many of my notes were summaries of information that came from existing blogs, but sure, you know the way the web works… more redundant information in slightly different forms always improves the quality of search engine results.
The imported posts encompass most of my previously written tech notes in terms of volume. Although there will be more older notes to come, most of them will be fairly small compared to the initial import.
Two large text files?
Now, you’re probably wondering, “Why did you create two large text
files? Why not create one text file per article? After all, that’s
what Jekyll runs off of.” Well, good questions there. Basically, the
reason had to do with on-disk layouts for local filesystems. After
all, I did say that the historic notes were all stored locally, did I?
Oh, okay, I didn’t say that yet, but that was the original intent. As
for the original reason as to why they weren’t accessible from the
Internet, that was because I did not put them in the public_html of
my Unix home directory, and even if I did, it still wouldn’t have been
accessible from the Internet because I wanted to keep my machine
entirely behind a firewall for easier security maintenance, or not
have to run it 24/7.
So anyways, the point is that if you write a bunch of short text files, since every file needs to be padded out to a minimum of 4 KB of disk space on a traditional local filesystem, you end up wasting disk space compared to a few larger text files. So I kept everything in a few large text files. Then I combined some of my large text files into one huge text file to make searching “all my writings” more convenient, at least from a local computer. Finally, once the text file got larger than 4 MB, I had to give way and make a compromise with a few large text files rather than only a single huge text file, otherwise it took too much disk I/O to save it.
- Footnote: In the past, the RAM consumption during editing would have been considered an issue, but not so much anymore now that 1 GB of RAM is considered small.
The alternative solution?
Git and GitHub. With Git, you can pack and compress a bunch of small text files into a single larger local file. Therefore, you do not need to worry about wasting local disk space, but you still get the convenience of being able to create one file per article. (You have to pull off some pretty nifty Git tricks to do this, though. I might discuss those in more detail in a later blog post.)
- Footnote: You can also do likewise with TAR and ZIP files. Yeah, but the point is, what’s the motivation if some technology or use case doesn’t require it? If you are the single local user, just using text dividers in a single large text file is easier.
With GitHub, you can publish that repository to the Internet via GitHub pages with ease. Consequentially, you can then use Internet search engines to search your text files. Incidentally, I must mention that with GitHub, you do not need to think about paying for hosting your simple text files, which is important because otherwise you would quickly take the site down if you think people aren’t using it and it doesn’t benefit yourself compared to local storage and access.
Unfortunately, GitHub is not for everyone. If you read the fine print of the terms and conditions, you’ll notice that they have some very curious terms if they are to be interpreted together: for example, the first time I checked (circa 2016), there is one term requiring the user to be greater than a certain age, and there is another term allowing updates to the terms of conditions. You know where they can go with this. On the other hand, you could argue that such highly detailed terms cannot be practically enforced, except in the highly unlikely case that you’d end up in court. Therefore, those terms can be ignored. Still, the legal language is enough to scare some people away, unfortunately, especially when one doesn’t “feel it is a life necessity.” So, as with all “needs,” there is a cultural dimension to this too, one that is independent of the absolute requirements of human needs.
-
Footnote: In fact, to be honest, the main reason why I got started creating a GitHub account was that I felt it was necessary to submit some pull requests to some open-source projects that I was using at work. So, there you go. That was the cultural dimension that pushed me toward creating a GitHub account.
-
Yes, absolutely. All that nasty “adhesion contract” legalese is something most of us would never accept to if we had a choice with a more sane alternative, even if it still was an “adhesion contract.”
20180515/https://en.wikipedia.org/wiki/Standard_form_contract
20180515/https://en.wikipedia.org/wiki/Unconscionability
-
-
UPDATE: Recently I’ve checked back with the GitHub Terms and Conditions (2018-05-16) and I’ve found that they’ve reformatted the terms of service to be quite user friendly. That was not the case when I first read them.
Past and Present
Back in 2010 when I started writing much of my expanded tech notes, GitHub was a newfangled thing. Nowadays, in the year 2018, people have been chatting positively about this GitHub for quite some years now, because, more importantly, it’s what most people use nowadays. GitHub alone was the force that caused the shutdown of Google Code, Microsoft CodePlex, and many more. So, now I know that this GitHub is really something. Back in the day around the year 2005, SourceForge.net was one of the really big things in collaborative software development and free, libre, open-source software. Not so much anymore, and the same thing can happen to GitHub.
So, why am I not concerned about this? Well, first of all, either way all of my writings are still plain text files, written in Markdown syntax, perfectly readable without special software.
- Footnote: Indeed, I vividly remember arguing with myself and ultimately passing up the opportunity to write my notes in Rich Text Files or Word Documents for the sake of compatibility, interoperability, and simply readability as plain text. Due to the advent of GitHub, Markdown has simultaneously become a de facto standard in lightweight markup languages for web publishing, and the web itself is a reputable standard for browsing/viewing.
They are still easy to grep on a local computer system, but they now
have the added convenience of being easily accessible from the
Internet too. Ultimately, for whatever future hot new thing comes
along, I’ll be able to just as easily forward migrate my old text data
into the new system, just as I have done with this current GitHub
system.
That being said, it’s really a bummer that the user-friendly WYSIWYG GUI systems are still troubled in this regard. In the past (1979 - 1995), it was proprietary file formats that was the inhibitor. In the present (2005 - 2018), it is proprietary databases and segmented websites, each of which can be independently discontinued, that are the inhibitor. Suffice it to say, it’s the same problem, just that it keeps getting reinvented using more modern technologies. Almost every single time a technological upgrade happens, the users who choose to use WYSIWYG GUI systems end up loosing all their old data, but incidentally most of them don’t care either. (There have been some notable exceptions in the past, but the common case still holds.) Nevertheless, these systems remain perpetually popular and commercially lucrative in all eras of technology despite their shortcomings.
Style Remarks
Oh, and some comments on my writing style. Unfortunately (GitHub-flavored) Markdown does not have a standard for inserting footnotes into documents. In my previous quasi-Markdown writing, I’ve developed a habit of “faking” footnotes via interrupting the flow of text with bullet point lists. I continue that same habit into, only this time I add “Footnote:” as the first thing of the first such bullet point that interrupts the flow of text. In fact, you’ve already seen an example of this style in this blog post. Footnote interruptions can be recursive, hence bullet points may be nested.
Also, Markdown does not have syntax for underlining text, only bold and italic. Incidentally, however, most of my writings do not need such detailed distinction, so that is okay for me.
You’ll also note some curious habits that I’ve developed in my language use that would not correspond to the formal written English standard of the late 2000s.
-
The English language lacks certain grammatical constructs found in other natural languages. Sometimes I borrow these constructs for my own convenience, even though it means my writings can’t be strictly interpreted as formal written English.
-
I developed the use of redundant language in my writings to make searching them via primitive local search engine techniques easier.
-
You’ll notice that I use timestamped URLs. The purpose of this is so that it is easy to find the original contents in the Internet Archive Wayback Machine, in case the URL no longer resolves on the modern Internet. Also, I try to save summaries of the page contents in case even an archived copy of the page in question is no longer accessible.
-
You’ll also notice that I log my search queries, via a timestamp and the name of the search engine I used with the search query.
-
Historically, I’ve developed a natural language tagging mechanism to try to measure how important some of my articles/writings are so that I can focus on them when doing revisions into a more organized work. Of course, nowadays I have categories and tags I can use on the blog for a similar purpose. Those historic phrases were kept inside the transferred writings for posterity and are as follows:
-
The same subject is repeated more than once: “Again, I reiterate, because this is important!”
-
Keeping track of when information is found from a search: “I searched for this and found it, that means it’s important!”
-