Scheduling subsystems (crontab, at) and the desktop

[Rodney Dawes]

Hrmm. Scheduling for the user is something that would be nice to have
integrated into the user's calendar I think. And having a cron daemon
that read scheduling information from an icalendar file, where "tasks"
are used to specify what applications to run/etc...

Are you suggesting that a spec be created for the data storage format?
The command line options to the various cron tools? What exactly? It
seems to me that saying "use icalendar" would be good. Though, we run
into the backward compatibility problems. And we all know that admins
are different from users, and are more often the people that are
actually doing scheduling. Users don't tend to do backups. Trust me
here. I have repaired many a windows machine, where the users lost that
very important piece of data, simply because they don't back up. Backups
take a lot of time. They require more manual intervention on desktop
machines. And really, what kind of media are you going to back up 200 GB
onto? Tape? How many desktop PCs come with tape backup media? A CD-R
holds 700 MB. Virus scanning is probably more important, but the virus
scanner will probably install its own cron job to scan the system, no?
Telling xmms to start playing every day at 7 am though. That's probably
something more useful. At least, that's how my alarm clock is set up.

I'm not sure we want to try and enforce something upon system services
from freedesktop.org yet. We can't just go break compatibility and
everything there. There are very large unix installations that are still
many years old, where they may update the UI, but not the backend.

Anyway, these are just my thoughts for now.

-- dobey


On Thu, 2004-07-22 at 12:51 +0200, Philip Van Hoof wrote:
> 
> Hi there fellow hackers, geeks and others who want the UNIX desktop to
> succeed.
> 
> I bring forward the question whether or not a (freedesktop.org)
> specification is necessary for application scheduling software.
> 
> The current UNIX Desktop user does not have an easy way to configure the
> tasks which he wants to schedule. Sure we have such a utility. And sure
> we can shout to our Desktop users "export EDITOR=vi; crontab -e" you
> moron, and RTFM!!
> 
> And then that user wont ever use our desktop anymore. He will probably
> never figure out out to quit vi let alone insert a line in that spartan
> editor and forget it that he will actually lookup how the format of a
> crontab record looks like. And the user is right. He should not have to
> look it up. He should not have to know about that. He is right that he
> can be stupid, really stupid, while working with that device which
> others call it a "computer".
> 
> And yes, scheduling tasks is something lots of desktop users want to do.
> Scheduling a backup of is "important" data (whether or not this data
> really is important our not, is not important). Scheduling a virusscan
> (whether or not this is necessary TODAY, is not important). Scheduling
> an annoying noise at 8'O Clock in the morning which tells the user to
> wake up. Scheduling a reminder message. Scheduling a shutdown.
> Scheduling a fadeout effect on the users music volume just before he
> goes to bed.
> 
> So we (a team of three people: Gaute Hope, Philip Van Hoofand Kristof
> Vansant) created a HIG-compliant GNOME 2.0 userinterface for both at and
> crontab. It's in the GNOME Cvs, module name is gnome-schedule. It
> currently depends on python, pygtk -from cvs- and python-gconf.
> 
> However, and here comes the reason for this E-mail.
> 
> While implementing this userinterface, we came across several
> incompatibilities between different versions and implementations of
> crontab and incompatibilities between different versions of at.
> 
> This makes it very very hard to implement a GUI for such systems.
> 
> At will prepend a bunch of environment variables to your scripts. Which
> ones differs between distributions, users and the stack of environment
> variables which you have set.
> 
> Crontab has different implementations (dcron, Vixies crontab) which
> might or might not have the same commandline options and behaviours.
> 
> I feel that freedesktop.org is the place to be to get a specification
> for these subsystems published.
> 
> What do you people think?
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040722/2b386541/attachment.pgp