I love that GNU loves Guile. There are few Scheme implementations as well polished as guile is, and what a breath of fresh air it can be to sit down to some '() stew after a few rough weeks of spreadsheet hell at work.
Might be just me, but it's kind of like having another universe to take a vacation in.
It does make me miss types, doing data structure programming in scheme can be irritating I guess, but still. I can compose, I can syntax-rules if I wanted, etc.
It's a pity GNU doesn't use Common Lisp instead of Scheme — it has rich types, data structures & more. It's a language built for programming large systems, rather than teaching small examples.
R7RS large is underway now! CL also has unhygienic macros, non-lispy loop grossness, lots of cruft, lots of poorly named functions that are named two different ways in two different places, and generally reeks of the 70s.
Scheme actually tried to compete with CL once, with a language called T. It had something sorta similar to CLOS and if I recall it was aiming for optimized performance per Sussman and Steele, but it eventually languished.
SBCL is the only thing keeping CL alive and they don't have the wherewithall to begin a modernized spec.
I don't hate CL, but I LOVE scheme. It is much more pleasant to actually work in, and feels cleaner. All the potholes of CL leave me checking under my fingernails for grime.
Scheme was implemented as a clean toy/educational Lisp on top of Maclisp in the mid 70s.
Scheme was defined too small upto R5RS and in R6RS is got unlispy.
> Scheme actually tried to compete with CL once
It never really did, since all implementations were different. There are lots of great Scheme implementations (MIT Scheme, Chez Scheme, ...) - but all were different. Then a bunch of extension were bolted onto Scheme - but the base was too small.
> It is much more pleasant to actually work in, and feels cleaner.
Which Scheme? Chicken Scheme? Racket - which is no longer a Scheme? Kawa? They are cleaner than CL?
The last clean Scheme was R5RS - and that was underspecified as a programming language.
Whenever I used Scheme I missed keyword arguments, CLOS, LOOP, optimization declarations, type declarations... Oh, wait. All those and much more has been added to Scheme in some ways. Unfortunately the result does not look 'cleaner'.
> CL also has unhygienic macros, non-lispy loop grossness, lots of cruft, lots of poorly named functions that are named two different ways in two different places, and generally reeks of the 70s.
That's all true enough; I believe that non-hygienic macros are a vital capability of a programming language (and Common Lisp being a Lisp-n makes them much less of a problem), and that LOOP is okay. I don't mind the cruft much: it's a mostly-backwards-compatible language, and backwards-compatibility is important; it's why Lisp code from the 80s can still run now, almost 40 years later.
I don't hate Scheme, really: it's a very neat little language. But it's completely unsuited for production work on large systems, which are what I'm interested in. Case in point: call/cc. It's nifty, really cool and absolutely has no place in any production system — it's ultimately just a very-lightly-structured GOTO.
I find it rather rare for GNU to actually use (any) lisp or support it. Sometimes I have a feeling that only a few hard working people somehow carry the torch of Guile as standard extension language of GNU project. :(
Guix uses it extensively. I'm away from a computer now but I'm sure there are some gifted minds working on it. Andy Wingo, others.
And anyways, isn't that the case with most software? HN loves APL, but there's only a few implementations around any more, Arc used to be the big topic of HN, it's all but dead, software comes and goes.
Scheme will die someday, or change enough that its something different, but the lessons of programming with linked lists and eval will stick around in those that bother to learn them. Ie, people like you and I.
Maybe you should check the Savannah repo. Maybe they need some work done that you could do!
I don't understand what you're asking. Python is completely unlike scheme.
The type situation irks me because I do ocaml for a living, so I rely on the type system a lot. Scheme reminds me of a more seductive flavor of FP, though sometimes it's cumbersome to ensure that a data structure isn't being subtly changed somewhere.
This is a nice misrepresentation. Your Vixie cron example offloads the day of week check to `date`. I'm sure there are examples where mcron syntax is superior to anacron as well.
I didn't know about mcron until this post either, but I find it super frustrating when people dismiss tools, ideas, or people simply because they don't conform to familiar patterns.
> The new idea 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.
> 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.
> 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.
One would have to check the timeline to determine whether the second was, in fact, an Mcron innovation. Uwe Ohse's uschedule, which has been around since 2001, also works by individual users having files in their own directories with their own daemons.
Now that timers are baked into systemd[1], the days of cron and its cousins seem to be numbered. The systemd timer specification is pretty rich, and since it can control any arbitrary systemd unit, I can't imagine using a legacy solution anymore.
Sure but there are tons of simple cron alternatives with better syntax that don't need systemd (such as fcron). In fact, Mcron from the OP can be configured using Scheme.
> Sure but there are tons of simple cron alternatives with better syntax
But you loose the main point, that is consistency of syntax. Nowadays thanks to systemd I can use the exact same syntax to configure my daemons, my network, my DNS resolver, my timers, my locale, etc etc. The mental burden is way lighter than with the traditional UNIX toolset.
You could have made the same consistency and mental burden argument about the crontab syntax. There are a lot of things in Unix which are table-driven and the tables take the form of one line per record with fields delimited by whitespace, blank lines ignored, and line comments introduced by hash.
Indeed these are your job scheduler (crontab), your mount points (fstab), your local host name resolution (hosts), your NS switch (nsswitch.conf), your terminal login services (ttys), your device permissions (fbtab), your automounts (auto_master), your plug-and-play device permissions (devfs.conf), your network services (inetd.conf), your MAC policy (mac.conf), your local network name resolution (networks), your call-out telephone numbers (phones), your network protocol name map (protocols), your RPC service map (rpc), and your network port name map (services).
And those are just the ones in /etc .
This set of table files with a common syntax is just as consistent and as light a burden as the set of .INI files that you are talking about. And any argument that you can make about things like having to remember what the fields mean can also be made just as much about the .INI files.
You only "need" to read the man page - the same as with systemd (asuming it still uses man, and not its own custom help viewer). If you'd read said man page, you'd know you can just type @weekly, for such a simple time period.
The standard cron that nearly everyone used to use would have been Williamson cron. Paul Vixie's PD cron (which was the original name for it) was a clone from 1987, and it of course was not used where people used the standard one, so was clearly not the one "nearly everyone" used.
It never became it, either. It was fairly quickly forked. Several times. Debian cron was forked from PD cron in 1994 by Ian Jackson, for example. The "standard one that everyone used to use" but only in the limited field of Debian Linux (and no longer, nowadays with Debian Linux version 9) was that fork, which M. Jackson actually named "Debian/GNU Linux's". RedHat made a comparatively much more recent fork. OpenBSD and FreeBSD have their own (different from each other) forks of long standing, too.
Mike Meyer apparently made a GNU cron for the Free Software Foundation in 1987. If it indeed ever existed in the first place, it has since disappeared without a trace.
I provide pre-made service bundles for the nosh toolset for various crons, and I have so far had to make separate ones for Dillon crond, Debian cron, Vixie (a.k.a. ISC or PD) cron, Guenter bcron-{spool,start,update}, Godouet fcron, and OpenBSD cron; because they are significantly different from one another.
In part, this is because although the crontab utility is actually standardized, in the SUS, cron (like many such non-ordinary-user-facing internals) is not standardized. This is actually a good thing, inasmuch as the radically different multiple untrusting dæmons architecture of Guenter bcron would not have been possible if it had had to conform to a standard of one monolithic cron dæmon.
The history of cron is indeed fascinating. But I think you interpreted the word "standard" too literally. I meant "the most commonly-encountered and well-known cron implementation to date."
What's that mean though? It's entirely meaningless unless you, what's that, check the manual. Or what if you want it to run on another day? What's that? Check the manual? Sound familiar?
In particular: which day of the week, and at what time?
cron expressions have about as much learning curve as ISO-8601, and are otherwise unambiguous once you know how to read them. systemd's time specifications look like they're full of special cases:
Monday is first day of the week according to ISO 8601. This is also the case in most European countries. In the middle east Saturday would be the first day and in some countries (notable North American and Islamic) it's Sunday.
But ISO 8601 is the standard so it makes sense to use that.
Sure, but there is nothing telling me it's adhearing to 8601 in that snippet. Why isn't it using the tm struct where Sunday = 0? I, what's that?, Have to check the documentation? ::gasp:: just like if you forget the order of the cron tab columns...
It's pretty intuitive once you've done it twice unlike cron's impenetrable syntax, tbh.
They also have other desirable behavior like being able to configure it concurrent runs are allowed or if the script should run if the initial date was missed or even restart the job if it fails up to a limit.
It's much more versatile than simply cron, due to that, it's also a lot more useful.
I'm aware of the extension but Systemd Timers have RandomizedDelaySec which allows me to schedule nightly backups without having to coordinate about 20 different machines into timeslots.
I should note that `man crontab | wc` returns 1680 words while `man systemd.timer | wc` returns 1300 words. Take that for what you while, especially since .timer spends most words on explaining the options instead of the syntax.
There's little functional difference between syntax and options in this case, as the options in systemd serve the same purpose as the syntax iin crontab.
I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application.
>I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application.
I think it's perfectly fine that timer does this, it's useful. The applications I run don't support this behaviour out of the box, so why should I have to code up something for each app?
>There's little functional difference between syntax and options in this case,
There is an important difference. The manpage on timers spends most words explaining what exactly each option does and how it can be useful while most of the crontab manpage explains how the syntax works, the options crontab provides are minimal.
I never attacked them. I simply found how they described cron extremely funny given that it's entirely contradictory to mine and pretty much everyone I've discussed sys admining with.
The man page, with system specific extension, is barely 1500 words long. That's neither impentrable nor complex.
I've just tired of dealing with people who have no way to describe things but with hyperbole, making an actual discussion difficult, if possible at all, because the facts of the matter can never be clearly stated. "I don't like cron because I can never keep the columns straight (and we can't keep comments in our crontab for w/e reason), the division symbol is used in a weird way, and I want _my_ services/code simple and my _system_ to handle complexity" is a much more honest way to complain about cron. Saying it's impenetrable is a load of BS and entirely unhelpful to the discussion.
So yes, I laughed at their response. No, it was not a personal attack. Finding someone's argument terrible and divorced from reality, or otherwise just hyperbole over known issues is not a personal attack. I'm making no judgement on them as a person. I'm not basing my response on anything except what they've said and constraint my response to be entirely within the scope of the argument, not extending it to them as a person.
Now, we can discuss if my response is helpful and furthers the discussion. Probably not. (Although,I did try to follow up with one that was.)
Was it uncivil or a personal attack? Absolutely not.
First, arguing with a moderator is unlikely to get you the outcome you're looking for.
Second, you're continuing even still with unwelcome, potentially hurtful, and overly-judgmental characterizations of another member's opinion and experience as a "load of BS," following your earlier characterization of someone's comment as "laughable." You may disagree with another's opinion, but there are less divisive ways to express it than how you've done it so far.
The majority of HN participants debate issues -- even ones that are contentious or may have "obvious" answers -- with an inclusive tone that conveys respect. We'd do well to look to them for inspiration.
I actually don't know who the moderators are here, nor am I looking for any specific outcome. Even if I knew all the mods, I would treat them as any other member. Not doing so would imply I treat other members poorly or that the mods have a god complex, neither of which I believe to be true. Moreover, if they deem me unfit to be a member of this community, I doubt grovelling and theatre would do any good.
> Second, you're continuing even still with unwelcome, potentially hurtful, and overly-judgmental characterizations of another member's opinion
None of which is a personal attack. It's quite literally impossible to not be hurtful to everyone all the time. It's not worth my effort to go out of my way to not be direct (which isn't rude).
It's more than possible to find an argument BS or laughable without that being a commentary on the presenter of said argument. Plenty of not-stupid people make stupid and shitty arguments -- myself included.
I expect my BS, poor arguments, and bad reasoning to be called out and corrected without needing to beat around the bush or otherwise sugar coat it. I'm an adult, I can accept when I'm wrong when presented with a convining argument. I expect others to find some of my opinions dumb, or otherwise incompatible with their world view. That isn't the other person being uncivil, disrespectful, or otherwise antagonistic or launching ad hominems. They shouldn't feel ashamed for voicing that either, many times over if I'm presenting my opinion as some universal truth.
> The majority of HN participants debate issues -- even ones that are contentious or may have "obvious" answers -- with an inclusive tone that conveys respect. We'd do well to look to them for inspiration.
What have I done that's disrespectful or otherwise not inclusive. It's very saddening that simply finding someone's opinion, especially one that's no where near deep-seated or otherwise a defining characteristic, so over the top with exaggeration that it's funny is now considered not inclusive or disrespectful.
People can be respected without needing to baby them and protect their egos.
However, arguments are not the people that make them. Arguments deserve no respect simply for existing. The fast bad, false, or ineffective ones die, the better. If we can't sit and discuss arguments and options without everyone taking it personally, we will never be able to get far as a society.
You make some fine points, but the dominant consideration here is a simple practical one: we know from many years of experience what an internet forum turns into when people respond to others with "Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol." and similar. It leads to flamewars, insults, and tire fires. The smart people get tired of it and leave. The rest keep flaming each other till nothing but scorched earth is left.
So, while I personally agree with some of what you said, I can't let you post like that, for the same reason that if I were a park ranger I wouldn't let you start dangerous fires. If you want to keep commenting here, please read https://news.ycombinator.com/newsguidelines.html and make a point of using the site as intended.
> we know from many years of experience what an internet forum turns into when people respond to others with "Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol." and similar.
Fair point. It doesn't move the conversation forward in any useful way.
I'll keep my comments tuned to further a debate, and not just react aimlessly.
>Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol.
? It's a personal opinion, you can laugh all you want but that won't make it any more wrong than yours.
>Those just feel out of scope to me. Why would I want this tool to handle that?
I run my backups with a systemd timer. Since it's a desktop system it might not be online during a desired timeslot so the backup can be repeated once the machine becomes available after that. Additionally it prevents concurrent backup runs on my servers if a snapshot is taking longer for a reason (which does happen when too many servers get scheduled at the same time, which btw, is handled by having the timer with a random offset to the schedule which last I checked is not present in cron).
It's something I want this tool to handle, yes.
>So much laughing this morning! You should really try an open mic night!
Why? Because I find a tool that solves my problems useful? Sounds like you should reconsider your standpoint because to me it sounds like you claim that cron is the one true tool to solve timed scheduling of scripts. Which it clearly isn't since cron doesn't solve the problems I have.
Well, I used systemd as an init system on a device I was working on (based on imx.6) because it turned out systemd was faster than sysVinit. And from my experience it is very popular now oj embedded systems.
Out of curiosity, what phone/OS is that? I don't believe stock Android runs either of those, right? (iirc, they have a custom init daemon and compositor, am I wrong?)
While your phone may run systemd, modern phones are pretty powerful compared to platforms traditionally considered "embedded".
It's also an extremely niché phone... Witch I seriously wanted to try out, but couldn't because it was actually impossible for me to buy.
It's definitively not representative for phones in general, and certainly not for embedded Linux as a wider term.
Edit: Things might be changing though.
For instance my Netgear NAS used to run a custom Debian-derivative based on Debian 7 (which used sysvinit). But I discoverd today that after some recent updates it's now based on Debian 8 (which ships with systemd instead).
Based on that, I could produce the following plot[1], on a "embedded" device. Which I now know spends a tremendous 42 seconds booting the kernel. I guess it contemplates life, the universe and everything before moving along :)
I've seen it in a few places, both a buildroot system and one based on Fedora (of all things). Not "small" embedded systems, but devices meant to do one thing and not act as general purpose computers.
Systemd has become quite popular among Linux distros, but it's not universal; plus Linux isn't the only Unix system around; and there's more to operating systems than just Unix.
It's also not just a matter of time before everyone switches over, since there's been backlash against systemd and competing projects have either started up, or gained more momentum (except for upstart, obviously!).
One of those alternatives is the "dmd" init system, which seems to have been around for a while but has recently been rebranded as "GNU Shepherd". Shepherd follows the "do one thing well" philosophy, so it only manages daemons. If shepherd users (e.g. GuixSD) want to run scheduled commands, they'll need another program to do that (i.e. a cron daemon), and GNU Mcron looks like a sensible choice since all of these things are configured using Guile Scheme.
As a side rant: I dislike your use of the term "legacy" for something which is actively maintained and gaining users. Usually "legacy" refers to something which is either abandoned, or where the maintainers recommend against adopting it (e.g. "that's our legacy API, use this other one instead"). I think the word "traditional" would work, when talking about cron in general; although Mcron in particular doen't look like a particularly traditional cron (since its selling point is using Scheme for config!)
I think systemd is gross and its configuration files awful. I have often wondered why the Linux community, in general, finds it acceptable and I can only conclude that it is because they are no longer attempting to create a good Unix.
The fact that the Linux distributions that practically everyone uses have adopted it is pretty compelling. :)
But seriously though, it solves a lot of problems around dependency and device management, error handling, logging, timer management, and so forth. To be sure, it has a steep learning curve, but I've found the effort invested to be well worth it.
Systemd doesn't "solve" these problems so much as it puts them into a Windows-y monolith that you then have to understand in its entirety, and have to update all the time, forcing you to startup/shutdown services managed by it. Given its accumulated complexity, systemd isn't viable for HA systems.
You mean, besides all the highly-available systems on which it currently runs? Since it's already part of the two most-used distributions in the world, it's fair to say that it's gotten sufficient exercise such that all of the serious kinks have been worked out by now.
Also, I'm not sure what you mean by having to "update all the time." Sure, systemd gets occasional security/bugfix patches, but so did sysvinit. And like sysvinit, systemd is hot-reloadable, so it's never been a problem in practice.
Right, but cron works everywhere. Also, I can’t say i’ve ever had the thought “you know what cron needs? A steep learning curve and dependency management system.” That’s nuts. Cron isn’t going anywhere anytime soon.
Sure. But your pitch is incredibly unrealistic for actually convincing anyone systems is obsoleting cron (except for linux distro specific packages, i’m sure).
For some people, myself included, on a long enough time scale you end up working on every piece of software on their system. In this case the simplicity is valued.
Different tools suit different people. Cron isn't dying any time soon just because the casual Linux user is better served by systemd.
No. But I have commits in lots of things and I've definitely dealt with the code of several cron implementations and the Linux kernel, among other kernels.
no, the poster is citing well documented historical evidence that systemd reinventions of traditional posix compliant unix/BSD/Linux services arrive as a horrendously complex mess of overcomplicated code.
take oddjobd for example, which supplants pam_mkhomedir.so in creating a users home directory on first login. oddjob is its own standalone daemon running constantly, while pam_mkhomedir is invoked only as necessary. oddjob needs dbus and systemd to complete what in many systems is just a simple mkhomedir && chown user:grp $homedir. its now fully dependent on the most fundamental building blocks of your OS to do one simple thing.
this also assumes the user doesnt have a home directory...which...many do.
in most commercial infrastructure if you suggest installing oddjobd to handle the potential for a user to log in without their home youll be laughed out of the chat. oddjobd forces organizations back into the 1980s and NIS based implementations of federated authentication where you had to go to a new user machine, or an account creation machine first if you dont want to run yet another idle daemon on your machine
What does systemd-resolved have to do with systemd's timer implementation? It's possible to agree that the resolver implementation is problematic, while other parts of the ecosystem are reasonably good.
This breaks the site guidelines badly, particularly the ones about civility and avoiding shallow dismissals. We ban accounts that post like this (regardless of how wrong someone else might be), so please read https://news.ycombinator.com/newsguidelines.html and follow the rules from now on.
What does this have to do with systemd, exactly? This sounds like a rant that is only tangentially related, and demonstrates that you don't know why oddjobd exists (specifically to provide an encapsulated means by which unprivileged processes can safely perform privileged operations).
Just because you deem something overly complicated doesn't mean that it doesn't serve a practical purpose.
systemd is attempting to take over unix just like gnome has always been trying to turn linux into GNOME-OS. It's all just a matter of having people with no taste given too much influence.
Maybe you've never tried to optimize an OS for battery life on mobile devices, then. There needs to be one place that timers happen—ideally the kernel, but a "userland kernel adjunct" like systemd is fine too—in order to be able to coalesce all the timers on the system (except for real-time ones) along some granularity scale.
You don't want to go to all the effort to spin up a CPU core to schedule a (cron) process thread, just to find out it has no work to do. Ideally, if you're going to check the time at all, you just want it done in one thread running on one core, so that the rest of the cores can stay asleep and you never have to spend energy context-switching when idle.
That being said, systemd isn't quite the right architecture for getting down to a "tickless everything" system. That'd be something more like WinNT's kernel timer object API, where the kernel sends an event to your window's or service's message inbox to wake you up when the timer is done; or macOS's "Grand Central Dispatch", where any native code (including non-Foundation POSIX code!) can pass scheduling control of any async block through a Mach trap over to one central scheduling process, which coalesces both timers and the runtimes of async events in general so that all background CPU activity happens in bursts with idles in between.
In my cronjob, I like to log the target process output, and ensure that only one timer jobs runs at a time, and apply resource limits, and have an easy way to know if the job is still running.
Right now, I am doing this all with a mess of shell scripts (flock + logger + echo calls + pgrep). This is fragile and ugly.
Since systemd provides all of the above easily, a better approach will be one-off systemd jobs. In this case, my crontab entries would be a trivial -- "1 3 * * * root systemctl start cronjob1". This only requires scheduling functionality -- background execution, env vars, email notification and other things no longer matter.
From there, it is just one small step to move scheduling into the init process itself -- after all, compared to what other things init does, scheduling is both simple and safe.
Lots of people have written modern, clean, init systems that are not from the '70s, and have all managed to do so without creating all-consuming blobs like systemd.
"baked" and "arbitrary": that about sums up SystemD (because software that hobbled deserves to be camel cased) development.
> I can't imagine using a legacy solution anymore.
Good thing sane people are improving on the legacy space then, with mcron--the subject of the link before someone had to mention SystemD--being a case in point.
and allows configuration files to be written in scheme (as well as Vixie's original format) for infinite flexibility in specifying when jobs should be run.
It looks like Greenspun's Tenth Rule has been taken to the next level. Software that's so configurable its configuration files itself are written in a Turing-complete language is the bane of enterprise development. IMHO if you need such complex requirements, that should be done by something other than the configuration file of what should be a simple task scheduler.
I guess calling Guile an "ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" could be a clever salvo in a religious war between Scheme and Common Lisp programmers, but of course Mcron's approach is heeding Greenspun's implied advice.
That rule is plain wrong. Not everything compose well enough to make pipelines or configure with some booleans and numbers and strings. Sometimes you need custom behaviour. In fact, most of the time you want custom behaviour, or just minor modifications or hooks. IDK what uses there can be for custom behaviour in a cron task, but that is the key: that you can not know every use case before hand. And instead of fighting with users over what features and configurables to enable, allowing them to do what they want is just easier and better.
Moreover, "a simple task scheduler" is a simple task scheduler. It's written in 1500 lines of scheme code, another commenter quotes.
But it seems like in Mcron, you can schedule a job along the lines of "Run on May 27th, November 23rd and December 29th, but only in non-leap years and if the days in question fall on a Wednesday or Saturday". With cron, you would have to run the program ever day and the job itself is responsible for checking if it needs to do its action.
Is that a silly example? Yes. Is it realistic? Perhaps. As the company I work for transitions to an "Enterprise Class" company, I'm seeing a lot of silliness in processes.
It might just be me, but I like being able to use a scheme file instead of a bash file if I need more complex logic for the command to execute.
It gives you standard vixie Cron AND the possibility to handle everything as a scheme program. You just put a scheme file in your Cron dir and have the logic in there. Really not much different from executing a shell file from regular Cron.
I think this is the crux of the argument between proponents of simpler init systems and proponents of systemd. We have complex requirements implemented in complex logic. Do we want that complexity baked into the init system, or do we want that in our configuration language?
Not sure what the OP intended as the context around this submission, but here's some more info:
Latest version 1.1.1 released 2018-04-08 [1][2]. Previous version was 1.1 on 2018-03-19, and the one before that dates to 2010-06-13 [2].
This is a job scheduler compatible with vixie-cron [3], but written in Guile Scheme. Entries in a crontab file can be the traditional format, or snippets of Guile. There's a whitepaper from 2003 [4] and up-to-date documentation [5] that explain the rationale and usage.
“[A]lmost anything ending in ‘x’ may form plurals in ‘-xen’ (see VAXen and boxen in the main text). Even words ending in phonetic /k/ alone are sometimes treated this way; e.g., ‘soxen’ for a bunch of socks. Other funny plurals are the Hebrew-style ‘frobbotzim’ for the plural of ‘frobbozz’ (see frobnitz) and ‘Unices’ and ‘Twenices’ (rather than ‘Unixes’ and ‘Twenexes’; see Unix, TWENEX in main text). [...] The pattern here [...] is generalization of an inflectional rule that in English is either an import or a fossil (such as the Hebrew plural ending ‘-im’, or the Anglo-Saxon plural suffix ‘-en’) to cases where it isn't normally considered to apply. This [...] is grammatical creativity, a form of playfulness.”
I make backups using cron, and recently I've been wondering what happens if the backup (hypothetically) takes longer than the interval between cron jobs. Will it start the new job while the old one is still running? Will unrelated cron jobs be blocked? And how is that in Mcron?
Yes - I believe it will start the new job while the old one is running - your backup script should write a PID file to ensure it isn't already running.
It wouldn't hurt for the website linked to tell us what the package does at least somewhere on the page, I will agree with that much. The first paragraph tells me what it replaces, what language it is coded in and who wrote it...but not what it does.
It says exactly that. It's written in Guile (which is inconsequential until it reaches the second part) and can take Scheme code as configuration file (which is very interesting).
Oh yes I would, but since when was this website only available to the HN community? It is full of mysterious pages like this...hardly making free software accessible.
It certainly isn't likely to make me question the choice I made to use the cron that my distro came with.
Might be just me, but it's kind of like having another universe to take a vacation in.
It does make me miss types, doing data structure programming in scheme can be irritating I guess, but still. I can compose, I can syntax-rules if I wanted, etc.
The sexpr universe isn't dead yet.