This one thing I want to do when my Librem 5 arrives: replace cron with mcron. According to what I read the change will improve the CPU idle time and probably reduce the battery consumption.
While my Librem 5 arrives, this post is created to let other L5 owners share experiences on the topic.
Mcron program represents a complete re-think of the cron concept originally laid down in the BSD and AT&T Unices, and later rationalized by Paul Vixie. The original idea was to have a daemon that wakes up every minute, scans a set of files under a special directory, and determines from those files if any shell commands should be executed in this minute.
The idea with mcron is to read the required command instructions, work out which command needs to be executed next, and then sleep until the inferred time has arrived. On waking the commands are run, and the time of the next command is computed. Furthermore, the specifications are written in scheme, allowing at the same time simple instructions to be composed and very much more flexible ones than the original Vixie format will allow. This has several useful advantages over the original idea.
Does not consume CPU resources when not needed. Many cron daemons only run jobs once an hour, or even just once a day.
Can easily allow for finer time-points to be specified, i.e. seconds. In principle this could be extended to microseconds, but this is not implemented.
Times can be more or less regular. For example, a job that runs every 17 hours can be specified, or a job that runs on the first Sunday of every month.
Times can be dynamic. Arbitrary Guile (scheme) code can be provided to compute the next time that a command needs to be run. This could, for example, take the system load into consideration.
Turns out to be easy to provide 99.9% backwards compatibility with Vixie cron.
Each user looks after his own files in his own directory. He can use more than one to break up complicated cron specifications.
Each user can run his own daemon. This removes the need for suid programs to manipulate the crontabs, and eliminates many security concerns that surround all existing cron programs.
The user can obtain an advance schedule of all the jobs that are due to run.
Vixie cron is implemented in 4500 lines of C code; mcron is 1500 lines of scheme, despite the fact that it offers many more features and much more flexibility, and complete compatibility with Vixie cron.
This improved simplicity and usability comes about through the use of Guile as the programming medium and extension language (in the sense that the crontab files now become extensions of the cron core).
Surely there must be some disadvantage to this? One could argue that the program will not run as fast or efficiently as the original. (Matthew Dillon might argue that it is feature-laden and thus definitely inefficient). However, as long as the cron core runs in a small fraction of a second (and only when there is known work to do), it is perfectly capable of performing its function (kicking jobs off with a frequency no higher than one per second - and thatās a whole improvement over the original); furthermore, inefficiency (if there is any) will not be noticed in terms of overall system performance in this case.
Reduced auditability / verifiability. In the extreme, itās no longer open source even when the source is available.
I think everyone would agree that that is a poor design choice (and it should have been done in the way that you describe). A better way of fixing that though might have been to fix cron rather than add an alternative to cron.
While resources should definitely be used efficiently on a battery-powered device, has any test been done on whether cron makes a difference? Right now, as the Librem 5 does not put the main system into any kind of sleep state, it effectively runs continuously anyway. Even once the Librem 5 does implement a sleep state, what difference in time-between-charges will waking up once a minute make? (Thatās a question to be answered by measurement when the opportunity exists.)
Anyway
This is the beauty of having a device that you own !
How auditability / verifiability can be reduced if you have to check only 1500 lines of mcron code instead 4500 cron code lines? I mean, if you have to read 4500 lines and me only 1500 lines, who of us is gonna end first?
Yes, that is my basic point. Itās not about the actual number of programmers working on it. Itās about the global pool of programmers who could work on it.
In the extreme, I could define my own programming language, letās call it MoreEvil (because there is already a language called āevilā and it is true to name), and I could create a cron implementation and release the source code even but noone would be able to verify it and noone would be able to maintain it.
1500 lines or 4500 lines, you wonāt be able to verify āevilā, let alone MoreEvil.
Nowadays I use Gnu Guix Operating System on a daily basis. I have installed succesfully on two laptops now. In fact I am waiting my Librem5 to try gnu guix on it
Off-topic, but does there exist a version of Guix for routers? Declarative network config is a blast, but I donāt know if guix checks the validity of configs before applying, or if it has automatic rollback.
)