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.
The "everything is a file and files have no locking" mentality of UNIX doesn't scale well to continuously running systems.