Nicolas Williams wrote: > I don't agree. A better crontab UI doesn't really need property groups, > for example, so to have those visible by dint of re-using SMF as-is > seems lame.
No? How do you configure parameters for your cron job? Shouldn't the log retention policy be controlled through SMF properties? Tweaking command line arguments is so very 20th Century. > [ services tied to desktop sessions ] > I don't think you should reject that so easily. While I do think that something SMF-like would be good for managing desktop sessions, I think it's pretty much orthogonal to managing stuff that's *not* tied to desktop sessions, which is where we need to go to bring in cron. > I recommend the latter because you'd not want the main svc.startd > to block on remote homedir servers, say. Of course, but since I don't think background services can have a repository in $HOME, I don't think that's directly an issue. Indirectly, indeed user-specific services are likely to want to start with a current directory of $HOME, but that should only block starting the service. The reason that I don't think that the repository can be in $HOME is that (a) there's got to be *something* in the root that tells SMF to run something for this user, because we can't very well have tens of thousands of systems each scanning tens of thousands of users' home directories looking for something to do, and (b) I want to run some services on one machine and other services on another machine, so the systems better have separate repositories. Look at it another way: current crontab is per-user / per-system. Maintaining that status quo is my goal. (And note that crontabs are in /var, not in $HOME.) Something oriented around managing desktop sessions might be very interesting, but seems completely separate, scope creep of the finest kind.
