

Cron as a filesystem - SwellJoe
http://blog.gopheracademy.com/cron-filesystem/

======
mwcremer
Ahem, meaning "manipulate crontab entries in a vfs" and not "store files in
cron".

~~~
SwellJoe
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.

~~~
rcthompson
How about "exposing cron as a filesystem"?

~~~
SwellJoe
Sounds like a Fox News title, where they expose cron to secretly be a
filesystem. They'll call it "crongate".

~~~
rcthompson
"What you need to know about Cron. News at 0 22 * * 1-5."

------
SwellJoe
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.

------
Animats
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.

~~~
SwellJoe
_" 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?

~~~
amelius
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.

~~~
thisrod
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.

------
lamby
Reminds me somewhat of Debian's /etc/cron.{daily,monthly,weekly,monthly}

