MiniMagAsm – a minimalistic but powerful CMS in assembly language
asm32.hopto.org
asm32.hopto.org
The comparison with git is very shallow, seemingly based on misunderstandings of how git works.
On branches they describe the Linus/Linux workflow, ignoring the fact that a more traditional workflow can also be supported by git. In fact "git flow" is a recommended workflow, and it's pretty much exactly what Fossil does (only with more flexible merging options).
Sharding vs. Replication turns out to be a matter of defaults; otherwise there's no material difference.
The web interface is cool, but I use GUI tools locally that are nicer and faster than any web interface could possibly be. Speaking of, there are a plethora of GUI tools available, free and for pay, for GIT.
Rebase is one of my favorite Git features; they claim it's a feature that it doesn't exist in Fossil.
Complexity is a good point, and git has famously bad command-line UI. I'm sure Fossil does a better job there; Mercurial and Bazaar certainly do. But git has the features I need, which isn't true of Mercurial or Bazaar, and git has a user base of a sufficient size (compared to Fossil) that I don't worry that I'll hit some corner case bug and lose data.
Zed Shaw used to be a major fan of Fossil, for instance, but then he lost a repo irretrievably and swore off using it. His old site with essays seems to be down, or I'd link his posting about it. Having everything in an SQLite database means that SQLite usually will be safe, but if something does go wrong, well, you're screwed.
It does sound like they misunderstand (or misrepresent) the way git works. git is very flexible and its capabilities and limitations follow from its distributed nature. If Fossil tries to be git with a smoother interface and more streamlined workflow, it's not surprising that its repos can go bad and lose your data.
On the plus side, it's a tiny fast CMS that can likely be used on minimal-ish hardware.
On the down side, A) it's x86 assembler while most really minimal hardware these days is ARM-based, and B) it generates all of its HTML on the fly so there's a chance that decently-done caching with generation of static content will beat it, particularly in situations where MiniMagAsm is working through an entire directory structure to generate navigation.
I think it's an interesting concept that might actually find some use in the real world if it was ARM assembler, but right now it's an ultralightweight solution that will run primarily on hardware that is unlikely to really need that light weight.
It might be interesting to compare its performance to Blosxsom or its other-language derivatives, particularly with those in static generation mode instead of CGI mode.
If there's a similar quantity of x86-based low-power systems I'm not aware of it even in passing. That doesn't mean it doesn't exist, but it probably does mean that x86-based systems of the sort aren't widely internet-connected devices which means that an assembler-based CGI CMS is probably not really relevant for them.
Edit: and I should add that by "really minimal" I'm not talking the true low-end of embedded microcontrollers at the Arduino level or below, I'm just talking about network-connectable devices with power consumption measured in single-digit watts.
I know that the performance can be improved by using some optimization tricks, but I simply don't need (for now) it to be faster. :)
Also, it is true, that x86 hardware can run much heavier web engines, but think about that the same hardware can run more lightweight engines as MiniMagAsm.
Anyway, the future of this project is probably towards using FastCGI or SCGI interfaces and maybe the use of some lightweight database engine - like SQLite.
Ah, BTW, http://asm32.hopto.org is actually my home desktop computer. :) Recently, the whole project has been moved to a commercial hosting: http://asm32.info
but you can visit the above address and download .zip files with the latest version