Well sure. Yeah. Do you find this explanation clear and satisfying though? Can you use it to answer a question like "at sunset, during a half-moon, can you see an upward-facing moon"? Maybe you're much smarter than me, but I had to write the simulator to figure out the answer. Claude and gemini never wrote the simulator, so they consistently answer that question incorrectly :)
I think you're overstating your case. I never said this was novel. I didn't vibe code any of this. Two balls and a lamp were not sufficient to make this clear to me, but writing the simulator was.
The LLMs have read all of the internet, and are thus quite good at answering questions like this, and I have zero problems asking them about it. In THIS case, the answers available on the internet kinda suck, which made the LLM suck as well.
Not being open source is the thing that the program in the article fixes. You want the goal of the software-writer to be producing a good tool, not using the software as a means to turn a profit. That's how you get the turd being replaced by the tool in the article
I want org-mode markup support for the wikis and readmes. Github supports this, and gitlab sorta does. You should hook up pandoc to it, and support everything it can handle.
Great writeup. Along similar lines, the East fork of the San Gabriel river is a bit outside Los Angeles. It has a dead-end road with two tunnels to nowhere, abandoned in the 1960s. Below that is a massive bridge to nowhere that connected to an under-construction road that was abandoned in the 1930s, with all traces of the road largely gone; except the bridge, which is huge and is very much still there. Much more obscure is the PL&P trail, a bit above the bridge. Built and abandoned in the 1910s. All in the same canyon!
ARM boards need a custom kernel and bootloader. These aren't things managed by the distro. The userspace IS managed by the distro and IS standard. Using yocto to manage userspace maybe made sense 15 years ago, but it has long since become far more trouble than its worth. Debian supports most architectures out of the box, has good cross-building infrastructure, many thousands of ready-to-use packages, and is non-weird.
Modern SBCs are just normal computers and not "embedded" in the traditional sense. You can generally just use Debian, and spend time on the actual project, instead of wrestling with the system
A dedicated key for all window-manager things is what people that have thought about it do (I use the "windows" key). But keyboard manufacturers haven't thought about it, so sometimes reasonable things aren't possible. I don't know.
Debian has their own nvidia driver packages (it's nvidia's drivers repackaged in a nice way that integrates with the system well). I can't say if they're "outdated" or how different they are from what ubuntu ships, but they've always worked very well for me.
GNU Make has a debugger. This alone makes it far superior to every other build tool I've ever seen. The cmake debugging experience is "run a google search, and try random stuff recommended by other people that also have no idea how the thing works". This shouldn't be acceptable.
If you think cmake isn't very good, the solution isn't to add more layers of crap around cmake, but to replace it. Cmake itself exists because a lot of humans haven't bothered to read the gnu make manual, and added more cruft to manage this. Please don't add to this problem. It's a disease
Hello! I'd love it if this and mrcal could work together. Do you support mrcal .cameramodel files? If not, can you do that? Is your splined representation compatible with the mrcal splined stereographic model? If not, can it? Is your splined lens representation better in some way? If so, should mrcal use some of that logic? I didn't see any documentation about it. If you think the mrcal distribution methods could be improved, and are willing to help improve it, I would be very amenable. Let's collaborate to make both projects better!
I would love for us to move past the idea that non-pinhole projections have "distortion", and we should strive to remove this "distortion" by reprojecting stuff to pinhole models. In practice, ALL projections distort straight lines and/or shapes and/or sizes, so if you use the pinhole projection everywhere, your images look like crap (see iphone wide-lens camera output for instance). Most of the normal non-pinhole projection functions work fine for wide lenses, while behaving like a pinhole lens with long lenses: https://en.wikipedia.org/wiki/Fisheye_lens#Mapping_function
This is real clunky from a browser. https://caltopo.com can do this from a map (right-click on the viewpoint, point-info, simulated view). The horizonator (https://github.com/dkogan/horizonator/) is a hackable implementation; has a FAST local gui, and can easily be extended to do other stuff.