17–
I created by own domain rudhar.com over 20 years ago, on
2000-12-14T18:05:35Z, says whois. Since
then my website has always been running on FreeBSD. I’m not sure
why I initially chose that operating system. It may have been
because it was the only OS my then hosters had on offer?
The idea of getting my own domain and finding hosting arose from a vague plan to do something similar to what Google was doing. But with paid guaranteed inclusion in the search index. In this respect, Google was very slow and unreliable in those days. I had made a calculation that everything could fit on one server. Later on I realised I had made an error. But I liked having the domain and hosting, so I kept it anyway. And I never built the search engine.
The first hoster I tried was Csoft, sometimes also called Cubesoft. When I now reread old e-mails, it seems they actually ran OpenBSD. I had no recollection of that.
Hosting of my website at Csoft was short-lived, because their services were unreliable and error-prone, and customer support was slow, one time even outright rude, and some problems were simply not solved at all. I see the company still exists and still does web hosting, even with the exact same people under the same nicknames. Well, as said, my experience was more than 20 years ago. They must have somehow learnt and improved, seeing that they are still in business.
On 11 March 2001 I terminated my first three-month hosting contract with Csoft. Meanwhile I was already talking to a German hoster, Verio. They were more expensive, for what I wanted to be able to do, viz. compile and run my own C programs as CGI ‘scripts’. At first I had to pay 110 euros a month. (Yes, the euro already existed back then, although not yet as coins and notes.) Later it became cheaper. The essential point was: Verio delivered. And they used FreeBSD.
They also had branches in France, England and the US, and they were owned by the Japanese Postal Service NTT, Nippon Telegraph and Telephone. But it felt like a purely German company to me, which I liked, because it reminded me of the time when I worked for the Dutch branch of a German company myself.
I find that the American
verio.com still exists,
and the German
verio.de too, although
that address now redirects to
inwx.de. They all
still do web hosting, but more like shared hosting than something
like a VPS (Virtual Private Server). In hindsight, in my early days
at Verio, I was in a multi-domain shared hosting in Apache, without
having full access to the whole machine. Later on, I had a variant
which felt more like a real VPS, although if I remember correctly,
I didn’t have a root login or sudo.
I was always quite satisfied with Verio, even though in hindsight, the FreeBSD versions they offered became outdated and they didn’t quickly change them. Understandably, because that isn’t always easy, as I now know from experience. But it was up to them to do it, I couldn’t. I remember having versions 4.7 and 6.4 at Verio. I stayed with them until 31 December 2012, when FreeBSD 6.4 was already two years after end-of-life. Or did I have a version 7 then?
When cancelling, there was a difference of opinion: in later years I had always paid a single amount for a whole calendar year, so I thought I could cancel by the end of December. But because for technical reasons the most recent VPS version had started in July, they wanted to make me pay until July 2013. After long negotiations, we reached a compromise. It is a point to bear in mind when doing business with them, or their successors.
I didn’t leave out of dissatisfaction, but because Tilaa.nl (also known as Tilaa.com) offered a real VPS, with full root control, for less money. A Tilaa VPS feels like you have a complete, real server computer all to yourself. Physically though, it does run on shared hardware, but thanks to KVM, that is completely unnoticeable. See Tilaa’s 22 February 2010 and 10 May 2010 blog entries. Full control also means you are responsible for keeping the OS and other software up-to-date. That is unless you pay Tilaa for doing that.
My website is hosted with Tilaa since 14 April 2012, and I will probably stay. (Update 18 May 2023: since 15 November 2022 I’m on Virtua Cloud.)
Now it’s about time to come to the point, which is that I found
a comment in a program I wrote, stating that
on 28 April 2011 I switched from using the field st_ctime
(change time) of the struct stat delivered by system
call stat, to using st_birthtime
(birth time). The birth time? What is that?
Traditionally, Unix file systems keep note of three kinds of date/time info per file. Well, more accurately, per inode, because more than one filename can refer to the same inode, and thereby to the same physical file. The three are:
The access time: when did a process last access, that is read, the file. Not very interesting, also because many Unix systems don’t record this, or not very often, or not reliably, because doing so would turn every read action into a read/write action, which is inefficient.
The change time: this refers to change, not so much of the file itself, but of the information in the inode, like owner or group, permissions, and also the number of bytes in the file. This means that any modification of the file’s contents that changes the byte count, also causes an update of the change time.
The modification time. This is about what is in the file. In practice, this is the only really interesting item, and the only one often used.
One list of links to pages on my website is indeed sorted by the
modification date – or time, which is the same thing because
all those are stored as seconds since 1970, in more modern systems
even with a granularity of nanoseconds. The list can be accessed
by the shortcut
rudhar.com/x, which I instructed
the web server software to expand to
https://rudhar.com/sitemap.xml.
Recently modified files are on top, which is useful for search engines
to stay up-to-date. That is why it is in a format invented by Google.
However I doubt if Google really uses the file, although it does know about its existence and location. That’s because when I look at the log files, I often see the GoogleBot access files that were created many years ago, and which also weren’t modified recently. Strange behaviour.
The downside of using the modification date to sort the list, is that even the tiniest change, like fixing a typo, or adding a postscript linking to a related file, puts the file on top, which obscures the actual website history. Therefore in addition to my handmade What’s New page (rudhar.com/new), I offer various RSS feeds in a menu. And that’s where the birth time, or creation date, comes into play: the moment when a file was first published on the website.
28 April 2011 was still in my Verio days, before Tilaa, the first
invoice of which mentions 14 April 2012. So 2011 was when I made myself
dependent on FreeBSD, because its filesystem UFS maintains the
birth time or creation date of files. It also offers software support
for it, e.g. find in addition to -atime,
-ctime, and -mtime, has -Btime.
And as mentioned above, st_birthtime is an extra field in
struct stat, which can be filled by issuing system call
stat.
I later found that ext4, the current file system for Linux,
unlike ext3 and ext2,
also has a
creation date for files, and there is a
Linux-specific
system call statx, which with
some difficulty (I had to
provide the function prototype myself explicitly, or
#include <x86_64-linux-gnu/bits/statx-generic.h>),
I could verify to work, using Linux Mint 20.1 and
glibc 2.31.
Command line utility find has a selection option
-newerXY in which X and/or Y can be B for birth.
Under FreeBSD 11.4, that works, under Linux Mint 20.1 it doesn’t.
The error message is:
“This system does not provide a way to find the
birth time of a file.”
which in light of the above is clearly untrue.
Being dependent on non-portable features is never good. It’s
not just about retrieving the date, but also about preserving
it when copying the files from one system to the next.
Unfortunately that is sometimes necessary or convenient, e.g.
when an older OS version is no longer supported. I performed
such copying several times over the years.
If I remember correctly, zip (a Unix implementation
compatible with good old PKZIP for MSDOS)
preserves the birth date, and cpio and tar
do not. Or maybe the other way round.
Fact is this did go wrong in the past sometimes, as evidenced by birth dates in September 2015 in the foneport directory, whereas I distinctly remember that the plan for those pages about Portuguese pronunciation arose during a trip to Paris with my family. That was 27–29 February 2000 (yes, 2000 was a leap year), I started working on it soon after that, and my announcement of a first complete version has been archived, dated 27 September 2000. So the files must have been created before that date, and not in 2015.
By the way, in my announcement I mentioned
utopia.knoware.nl, which was a physical single
hosting computer with my
then
access provider. Still without an internet domain of my own.
On 19 February 2021 I suddenly had that idea: why not ignore this non-standard birth time, and mark all HTML with a machine-readable publication date? That will make my website compatible with any kind of Unix system, FreeBSD or any Linux distribution, it will no longer matter. Much better.
Most of my pages already have a human-readable date, just below the
top <h1>title header</h1>. Therefore I am
now in the process of converting things like:
17–22 March 2021
to:
17–<time datetime="2021-03-22">22 March 2021</time>
with the least possible amount of handwork. And the generation of
the RSS files will find those date markings, and use them for sorting
(newest first), and selection (last week,
last
month, all).
Copyright © 2021 by R. Harmsen, all rights reserved.