Posted
by
Unknown Lamer
on Monday March 18, 2013 @09:56PM
from the end-of-time dept.

First time accepted submitter victorhooi writes "AirBNB has open-sourced Chronos- a scheduler built around Apache Mesos (a cluster manager). The scheduler is distributed and fault-tolerant, and allows specifying jobs in ISO8601 repeating notation, as well as creating dependent jobs. There's also a snazzy web interface to track and manage jobs, as well as a RESTful API."
It's under the Apache License as seems to be the fashion with businesses releasing software nowadays. It looks like it might be useful if you have to manage a lot of machines with interconnected recurring processes; I know I wish this had existed a few years ago.

No, but this seems to be aimed more at Control-M and other scheduling 'frameworks'. Not that these features are enough to challenge CTM, but it's still targeting that one more than it's targeting cron.

http://code.dogmap.org/runwhen/"runwhen is a set of utilities for running commands at particular times. With these tools, you can perform calculations on time values in various ways, and use those calculated times to determine how long a process should sleep before performing some task."

http://ohse.de/uwe/uschedule.html

http://untroubled.org/bcron/"This is bcron, a new cron system designed with secure operations inmind. To do this, the system is divided in

KISS is no guarantee of security. In what way are they simpler and thus more secure. While complexity introduces more opportunity for insecurity, inverse is not necessarily true. If you are just asserting that simple software is somehow better then you need to back that up.

The statement made was that the examples listed above were more secure, which implies familiarity with them. If you are just talking in generalities that isn't actually very useful.

Please remember the first rule of skepticism, the person to make the claim is the one who should justify it. Simply telling me to go look at bcron's implementation page doesn't do that. Especially since four different schedules were mentioned.

You (I presume you) are telling me that Chronos is insecure, you need to actually prove that. What are the vulnerabilities, or are you just speaking in vague generalities based on some philosophical belief?

a) Chronos is actually correct (to the extent that the most accepted transliteration for the greek letter chi is 'ch' rather than 'kh') and means 'time'.
b) If anything, it's actually the Khronos group which should be cowering in shame, since they are misspelling the name Kronos.
c) Latin doesn't even have a 'ch' diphthong, except when transliterating Greek words (http://en.wikipedia.org/wiki/Ch_%28digraph%29#Latin)
d) The latinization of Kronos would have been Cronus, not Chronos.
e) Strictly speaking, Kronos is a Titan, not a Greek God (except in the looser definition of Titans as deities in general)

Chronos looks very yummy. Over the years I've deployed a number of schedulers (launchd on OS X and Quartz come to mind) but cron always comes back because it's so available and flexible. While it has many shortcomings, it's reliable and easy to grasp. Chronos, with the ISO 8061 job scheduling syntax will have an edge over the nasty mess of launchd, and the cron-like extensions and idiosyncrasies in Quartz. The first glance at the GitHub pull shows clean code. I'm looking forward to taking it through it

It's not a matter of fashion, it's a practical reality. No sane business wants to be the who defends the GPL in court. It'll be expensive and messy, and if the result goes against GNU/GPL "accepted wisdom", it will be a PR nightmare.

Nonsense. The GPL is rock solid.You know how you can tell? It survived the heyday of Microsoft's monopoly without a court challenge.If Microsoft was afraid to tangle with the GPL at the height of its power, you better believe smaller fish will have an even harder time of it.

No sane business wants to find out what the term "punitive damages" means when trying to violate the GPL for commercial gain.

No, but a lawyer should consult with a software engineer before setting out to design software, rather like a software engineer should consult with a lawyer before setting out to apply legal constraints to his creation.

I believe I understand the GPL, all I had to do is to read it. People try to mystify you as "you have to be a lawyer" to read a license if its more than 2 lines. Well nope. The GPL is very clear and uses simple words. It has nothing to do with the gibberish from EULAs, and I guess, that's on purpose.

What are you talking about? The GPL is both remarkable and robust because it is written in plain english not in twisted legalese. It is easily understandable by developers who take the time to sit down and read it. I encourage you to do that now, maybe you'll change your tune.

I'm not arguing for or against the *GPL licenses myself. All I'm saying is that I've experienced enough funding or acquisition due diligence processes to have heard from the acquiring/funding party's counsel that *GPL code must either be replaced with a viable alternative, or that the deal might be called off. Other people have had other experiences, and of course there are companies (e.g. Percona, Red Hat) who are doing well with it.

By the way -- I don't think legal/business concerns are about the solidity of the license. The concerns are about the aspects that could be hostile to business and investment.

Remember that not everyone wants to make their bacon by offering consulting or other professional services.

Some people want to build and offer finished, successful products that some enterprising licensor may feel are worth pursuing in court over some obscure clause, very much like patent trolls and other IP holders of dubious value g

Like you said, it's case-to-case. And until *GPL is contested in court we won't know for sure.

At Very Large Retailer I engaged Bruce Perens and his team (circa 2006) and we went through education. It paid off. Irrational fear of the GPL was squelched.

At other deals, especially startups, i try to advise them to find the best tech first, then worry about the license, and whenever possible to just avoid *GPL in their products to preempt potential issues. They will have a full plate if they end up in a fund

Come on, this is ridiculous. The GPL has been found perfectly enforcable [wikipedia.org] in many cases in many jurisdictions, with some eventually going to courts. The reason that most cases are settled out of court comes from the fact that defending a GPL violation is such a hopeless endeavor in most situations.

I'm not arguing for or against the *GPL licenses myself. All I'm saying is that I've experienced enough funding or acquisition due diligence processes to have heard from the acquiring/funding party's counsel that *GPL code must either be replaced with a viable alternative, or that the deal might be called off.

While I understand that this can happen, it effectively means you are advocating against using the GPL not based on the actual content of the license, but because of the (quite likely irrational) behavior of a third party.

While I understand that this can happen, it effectively means you are advocating against using the GPL not based on the actual content of the license, but because of the (quite likely irrational) behavior of a third party.

If it makes business sense to use *GPL I'll be the first one to advocate it. If there's no reason for it, and an Apache licensed component is available, I'll advocate that. It all depends on the business model and whom I'm advising. If I advise against using code under any particular license is precisely because the license content could have an adverse effect on the business.

I've licensed my own code under GPLv2 when it made sense, under Apache at times, and under BSD most of the time. If we're talking

The GPL has been already effectively tested in court, repeatedly. Unfortunately, intellectual property lawyers are scared of the GPL. I discussed it with one 8 days ago: they consider it dangerously viral. I'm trying to arrange a lunch so we can sit down and go over the details of it, so they can understand why I much prefer to use it and I can give examples of companies who pretend to be open source but drive engineer like me nuts when their commercial versions of their "open source" tools break and we can

The GPL has been already effectively tested in court, repeatedly. Unfortunately, intellectual property lawyers are scared of the GPL. I discussed it with one 8 days ago: they consider it dangerously viral. I'm trying to arrange a lunch so we can sit down and go over the details of it, so they can understand why I much prefer to use it and I can give examples of companies who pretend to be open source but drive engineer like me nuts when their commercial versions of their "open source" tools break and we can

Seems like Chronos is yet another 'Let's re-invent the wheel' project to create a scheduler'. Projects such as Grid Engine do the same thing, and have been doing it very well for a very long time. There are also API interfaces to Grid Engine such as DRMAA (www.drmaa.org) so you can incorporate it into your applications as well.

Grid Engine is not longer open source or free. They're charging $500/processor (!) for the latest version and have hidden the previously free versions. You might be able to find the earlier versions in other places on the net, but not through Oracle.

But since Grid Engine is not written in Java.....the Java guys have to go and write yet another scheduler....that does less, is less scalable, etc...

As you mention above Grid Engine supports DRMAA, so it works very well with Java from the controller side. The tasks need to be in scripts though, which is a pain.