Magic lantern vs. tragic lantern. Any differences?

Question

What is the differences between the two? Is it model dependent?

Answer 1

Tragic Lantern is a fork of the Magic Lantern codebase, which means it was based on ML, but is no longer a part of ML or supported by the ML community. But probably the biggest difference is that from what I can tell, TL development is no longer active (the latest commits I can find, on bitbucket.org are from 2014). I suspect all TL development has moved back to ML.

And yes, just like with its parent project, Tragic Lantern builds are model/OEM firmware-version specific. (See also: Is there a way to get Magic Lantern on my newer model Canon?)

The main history is that the user "1%" began learning to code and chose to use the ML code base as his first project, because he had an (at the time) unsupported 7D and wanted to see if he could add it. 7D users rejoiced. He made a lot of progress (not just on the 7D, but also the 6D and EOS M) and did amazing things, but he was inexperienced and not versed in two major things that caused trouble down the line.

The first issue was that while he knew how to download the codebase and develop from it, he wasn't versed in open source practices, and did not habitually push his code changes back to the main ML development effort for review and inclusion into the main ML development repository, or pull down newer codebases to stay in sync with the current development everyone else was doing. As a result, as time went by, TL got more and more out of sync with ML, and trying to roll in his new features (on old code) eventually became more effort than simply rewriting from scratch in the current codebase.

The second issue was that he activated some features by simply ignoring known bugs. So TL had features that ML chose not to activate for safety reasons. In the main thread on the Tragic Lantern fork on the ML messageboards, "a1ex" (the main contributor to ML) pointed out that 1% had, for example, enabled WAV recording, which was known to write to unallocated memory. Without fixing the issue first. (As far as I can gather as a non-programmer, 1% misinterpreted the situation and thought he was disabling the write capability, not just an error message).

Naive users of the models that only TL supported or who wanted the features TL has that ML doesn't, of course, complained, and gave anecdotal "evidence" that since their TL-equipped cameras hadn't crashed, clearly the code was safe. 1% was also putting up with some harsh criticism and felt that his efforts were unappreciated, while the ML developers were upset about all the wasted effort that could have (from their POV) been avoided. But basically, it was a huge mess of hurt feelings and a Big Learning Experience for all. And forking TL off as a separate open-source project was the cleanest way of getting out of the mess. And then everyone rolled up their sleeves and started working on backporting 7D features from TL.

Today, ML supports the 6D, 7D, and EOS M. And is still very actively developed. Unless you rely on one of the TL features that isn't active in the ML code, then you should probably stick with ML.