I was trying to understand what this project is. It's some sort of open firmware for Canon camera that you put on the flash card (SD). The home page has info: https://www.magiclantern.fm/
Yes its truly noteworthy project. They exploited Canon cameras by first managing to blink red charging LED. Then they used the LED blinks to transmit the firmware out. Then they built custom firmware which boots right from SD (thus no posibility to break the camera). The Magic Lantern firmware for example allows many basic cameras to do RAW 4K video recording (with unlimited length) - feature which is not even in the high-end models. But it has much more features to tinker with.
There's a fun step you're missing - it's not firmware. We toggle on (presumably) engineering functionality already present in Canon code, which allows for loading a file from card as an ARM binary.
We're a normal program, running on their OS, DryOS, a variant of uITRON.
This has the benefit that we never flash the OS, removing a source of risk.
I really want to know how many search requests are being made by ChatGPT and other AI systems in 2025. I know OpenAI has a partnership with Bing for this, but then I see OpenAI in the list on the post.
Do we know if they're sending the referer header? Maybe there is no way to know. It would just be interesting to see that trend over time.
This is still a hard problem today. Some hard tech was built for this. I'm excited for a world where this is more accessible and less hardcore than something like CRDTs (in terms of accessibility).
How have others noticed the world shifting in the past 6 years?
There are now a few sync engines that tackle this problem. Rocicorp Zero, Electric SQL, and one or two others. By no means a crowded space, but there are options now.
Have you had a chance to use either of these yet? Electric looks like an obvious mature choice — curious if you think Zero's approach is compelling enough to be worth trying in alpha
Haven't used either of them. I met the guy behind Zero and he's super smart. He had been working on Replicache for a long time before he started this thing.
That being said, I haven't tried them, so can't really give an educated opinion. But I feel pretty confident in the domain expertise on the Zero team.
All the fundamentals have existed for at least 26 years. So, no, not really.
It's also really weird to use video game terminology and ignore the fact that all of the approaches used in this article have in fact, been done by major game engines, are readily documented in game development circles, etc.
It reads like an undergrad discovering game development for the first time. None of this is novel. It wasn't even novel for a web or desktop application to use.
I also found it weird. They're basically doing what multiplayer games do but for a web app. Not the typical way you'd build your web backend but nothing actually new... not even using CRDTs, just inspired by them.
Can you say more about which prior art you think overlaps here? We have a similar use case to Figma and are implementing a similar solution. I'm not particularly concerned whether the path we're following is novel but I am particularly concerned with whether there are gotchas along it that we should be watching out for, so if there are more mature solutions, we'd be interested.
Read QuakeWorld 1999, client-server prediction, Counter-Strike: Source lag compensation.
See also, “reconciliation.”
Also, debatably the article hints towards an incorrect implementation because they specifically mention sending events instead of user input.
By design, if you do this, you can create events that are supposed to eventually stop, but the user may drop packets and disconnect all the while you were processing an event that was never supposed to occur.
If you poll user input and experience loss, there’s no event to misfire.
This behavior manifests itself in games as a player that continues to walk forward despite having lost their connection to a server and is a indicator that a multiplayer server was implemented incorrectly.
Multiplayer video games are the big one. There's no reason why you couldn't apply the same kind of synchronization to a web app. You'll just need to decide on an approach because not all games do it the same way. Most likely you'd want rollback netcode.
I know Liveblocks.io has been making this very easy and accessible over the last few years. They recently introduced AI, and are promoting that of course, but as I understand it multiplayer collaboration (https://liveblocks.io/multiplayer-editing) is their meat and potatoes.
Not affiliated with Liveblocks, just aware of its existence.
I work at Liveblocks—yes! Our founders were inspired by Figma and wanted to make it possible for others to build apps like this more easily. We provide our own sync engine, Storage, which is aimed at this use case.
PubSub and LiveView do go a long way. However, broadcast isn't sync and LiveView isn't appropriate for all applications.
Phoenix recently added Phoenix.Sync [0], a sync engine library explicitly designed [1] to address this. In combination with a front-end library like TanStack DB [2] it goes much further towards giving you a Figma/Linear-style sync engine out of the box [3].
A sync engine plus the always online nature of LiveView feels at odds with offline-first (which is often associated with sync engines). I wish LiveView had a better offline story.
This distro seems like a fork of JELOS based on it literally saying "Just Enough Linux Operating System (ROCKNIX)" on the front page. That spells out JELOS, not ROCKNIX lol.
I believe JELOS did die, so this is cool to see. I'll try flashing it to a new SD card and seeing what's up! Does anybody see info on what's difference? Also, is there any indication that this is a fork anywhere?
It's a form of JELOS picked up by contributers in the wake of the project getting dropped after Nintendo went after Citra. JELOS shipped with it by default.
Source: I've contributed to Rocknix and was around for the dissolution of JELOS and the fork.
Some time ago it was written on their GitHub repository. Unfortunately JELOS stopped the development and Rocknix picked up the code and further maintained it. Hopefully it will last, but one should also say that the ecosystem is now also rich in alternatives to RetroPie itself. In fact, Batocera is also a strongly community-supported distribution for retrogaming
devs threw in m8c and its dependencies so you can hook up a teensy 4.1 flashed with Dirtywave’s headless M8 firmware, and make music on the handheld. 8 mono tracks, synths and samplers. it turns any handheld running this into a decent DAW
Something in the article that I had to look up that might bother others. He uses the term 'DCT' in this sentence, but it's never defined in the article. AFAIK it stands for 'DRAM Memory Controller', but that could be an LLM hallucination. Running a web search defines it as Discrete Cosine Transform. :P
> "AMD’s BIOS and Kernel Developer’s Guide (BKDG) indicates there’s a 4-bit read pointer for a sideband signal FIFO between the GMC and DCT, so the “Garlic” link may have a queue with up to 16 entries."
Should maybe swap DCT in for MCT (memory controller)?
I'm a versatile engineer with 15+ years of professional experience now. Ex-(Uber, Snap, YCombinator, Figma).
Actively interviewing but always curious about interesting opportunities. Looking to work more directly with AI and LLMs, as that has been my focus in recent years!
reply