3 ms·

"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

"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?

beberlei 12y ago
Everything is a file doesn't scale to more than one system without resorting to hacks (Using NFS or the likes). One condition for a scalable system is a network interface imho. Cron doesn't have that as well, which usually leads to application level complexity to avoid running the same cron on multiple machines.
- SwellJoe 12y ago
  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.
- vezzy-fnord 12y ago
  You've never heard of 9P, have you?
amelius 12y ago
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.
- Animats 12y ago
  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.
- thisrod 12y ago
  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.

beberlei 12y ago

Everything is a file doesn't scale to more than one system without resorting to hacks (Using NFS or the likes). One condition for a scalable system is a network interface imho. Cron doesn't have that as well, which usually leads to application level complexity to avoid running the same cron on multiple machines.

SwellJoe 12y ago
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.
vezzy-fnord 12y ago
You've never heard of 9P, have you?

amelius 12y ago

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.

Animats 12y ago
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.
thisrod 12y ago
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.