I’m curious about proprietary Nvidia drivers. Ubuntu normally comes with fairly outdated, if not obsolete ones, but there’s a semi-official PPA with more recent versions. How does Debian handle this?
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.
Debian offers Nvidia drivers as well although they tend to be outdated. Thankfully you can use Nvidia's official .deb repos to get the latest drivers on both Debian and Ubuntu.
Awesome, this must be a recent thing, when I last checked about a year ago the latest drivers from restricted were a couple versions behind. Many people always complained about it on reddit, AskUbuntu etc, which is where I found out about the PPA.
We deployed 570 and 580 in the April-June 2025 time frame, so I'm not sure what you were looking at, but they've tried to keep up with the latest for a while.
I have used Pop OS for years and for me it was the most smooth desktop environment I've ever used.
They have been working on a custom Desktop Environment which sadly still isn't very stable yet. Promising development, but putting me off of using Pop for a while.
I just put the new popos on my laptop and am still running the old version on my primary desktop. Agreed that Cosmic is not quite ready for prime time yet, but it is pretty impressive the state it's in for how new it is. Haven't had any show stopping bugs on the laptop, just a few small quirks.
Anyway, the main issue with Debian, Ubuntu, and Nvidia is about licensing. GNU/Linux is free software, and Nvidia drivers are not. Loading a non-free driver is known as “Tainting the Kernel”.
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
As much of a dog as cmake is, "just use make!" does not solve many of the problems that cmake makes a go at. It's like saying go write assembler instead of C because C has so many footguns.
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.
That hasn't been true for a few years at least. https://www.jetbrains.com/help/clion/cmake-debug.html is has had CMake debugging since cmake 3.27. Ditto for vscode and probably other C IDEs I am not familiar with. So does Gradle for Java. GNU make is hardly exclusive.
This is very true. My thought process was that since majority of projects already run on CMake, I would simply build off of that and take advantage of what CMake is good at while making the more difficult operations easier. Thank you for your feedback!
CMake does three main things: Compilation with dependency tracking, finding external dependencies, and platform-independence. Make only does one of them.
Another comment suggested batch files - these do zero out of three.
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!
Thanks for replying - I really admire your work with mrcal, and have used it for a while in my work. And lensboy is heavily inspired by mrcal.
> Is your splined representation compatible with the mrcal splined stereographic model?
No. It was a conscious design decision to only use pinhole models, at least to begin with. As I understand it, the tradeoff is that the pinhole model does not support ultra-wide lenses like the stereoscopic model does. But I have never used a lens that has a field of view close to the limits of pinhole models, so I just went with pinhole models.
However, if I understood your documentation correctly, the distortion model should be identical, it's just the core model that is different.
> Is your splined lens representation better in some way?
I'm pretty sure it's not - I based it entirely off yours, without trying to improve it. However, I did implement regularization slightly differently.
> I didn't see any documentation about it.
Unfortunately I have not written documentation as impressive as you have in mrcal, though I aim to. I wanted to get the project working as soon as possible to use it at work.
> If you think the mrcal distribution methods could be improved, and are willing to help improve it, I would be very amenable.
I actually did attempt this in this fork: https://github.com/Robertleoj/drcal (I'm sorry for the brazen phrasing in the readme, but I believe it is sligtly in the style of the name "numpysane").
The purpose of this was just to have functionality of mrcal but available on pypi, and with a build system I understand better.
However, I abandoned this, instead opting for making a library from scratch, partly because I had a hard time removing numpysane as a dependency (I want to have very minimal dependencies in this project).
I'm not sure how to reconcile this, but I'm happy to chat about what I did there.
> Do you support mrcal .cameramodel files? If not, can you do that?
I don't support them currently. I'd love to chat about doing this, even if loading them would lose some information because of different data models.
Don't hesitate to send me an email, you can find it on my github profile.
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.
reply