Yeah, I considered changing the title to "File interface to cron" or something similar, but that also seemed to leave some of the reality out. It's just another element of the "everything is a file" philosophy of Plan 9, which I find very interesting and pragmatic, and wish were more common in the directions Linux is evolving in, with stuff like systemd, firewalld, systemd timers, etc.
I find this an interesting experiment, as I am often struck by how much history seems to get forgotten. Plan 9 is pretty ripe for picking out lots of cool little things for integration into modern systems, but a lot of it doesn't seem to have resonated out into the world at large. It's unfortunate that Plan 9 wasn't Open Source from the beginning, as it might have been common enough to have inspired more stealing of ideas for other systems.
As it is, we've got a lot of reinvention of ideas happening, often without much forward movement.
That reflects a mindset from an OS where the only data structure is a file system. When the only hammer you have is a file system, everything looks like a tree. Chrontab is a database and should be treated as such.
The "everything is a file and files have no locking" mentality of UNIX doesn't scale well to continuously running systems.
"Chrontab is a database and should be treated as such."
Why a database?
"The "everything is a file and files have no locking" mentality of UNIX doesn't scale well to continuously running systems."
I don't understand what argument you're making here. UNIX doesn't actually have "everything is a file" semantics (cron does not, for example, in the sense proposed by the article). Plan 9 mostly does, and it's actually kind of awesome. What part of Plan 9's semantics of everything is a network-transparent file "doesn't scale"? And, what do you mean by "doesn't scale"?
I'm not trying to be argumentative, I genuinely don't understand what you're suggesting instead. What is an alternative cron implementation that is implemented as a database that "scales" better than something like this, by your definition? And, what is "scale" in this context?
The problem with filesystems is that they don't usually support transactions. For example, it is not possible to atomically change two files, without resorting to ugly and dangerous hacks.
Plan 9 came close. You could create /foo/a and /foo/b at your leisure, then bind /foo over /etc. This atomically replaced /etc/a and /etc/b with /foo/a and /foo/b, for the purposes of open. The change could be atomically reverted with unmount.
If that wasn't good enough, then /etc/a and /etc/b could be virtual files served by the same daemon. This could look for change sets written to /dev/patch, and block reads and writes while it applied them.
Right. If you're changing the configuration of a live system, you often want to do it atomically. Databases are designed for that. They also support search operations and have indexes, which get updated as the data changes.
What!? Did you even read the article? It covers the fact that files are network transparent...i.e. every file is available everywhere on the network. You really should give the article a read and maybe read up on Plan 9 a bit. You're missing out on some really interesting stuff.
