dima55

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.

Macro-economic policy is political. I'm sorry.

This is a new release of the mrcal camera calibration and lens modeling library.

Fun! If you want to compute these yourself and/or if you like hiking into the mathematically middlest-of-nowhere location, here's a good blog post: https://notes.secretsauce.net/notes/2015/05/06_poles-of-inac...

Look at pyfltk also. I haven't used the windows builds, but it's real nice on GNU/Linux.

Huh? I contribute to Debian; I don't aggressively patch anything. You can too.

Moving from a patch stack maintained by quilt to git is what this article is about.

Lots. Because many upstream projects don't have their build system set up to work within a distribution (to get dependencies form the system and to install to standard places). All distros must patch things to get them to work.

Yeah, have they ever actually used a garmin product? The hardware and the sound effects are excellent. Everything else is barely functional.

I use the `vnlog` and `feedgnuplot` shell tools HEAVILY to do data analysis and visualization. In emacs, these work well in shell-mode or in any buffer with `shell-command-on-region` (M-|). Not strictly emacs, but works great.

Maybe it's a fallacy and maybe it isn't. But I often hear people say "I don't use tool X because it doesn't actually increase my productivity". X is emacs or debuggers or profilers or Linux or version control or code comments or whatever. And after observing such people work over time I decided that most of them are just trying to justify their laziness. YMMV.

The packaging is only one of ROS's numerous issues. Just do it yourself.

This is the ROS way: add more layers of crap on it until it sorta kinda works sometimes. If you want "reproducible package management", use Debian. ROS1 is already in stock Debian. Some of ROS2 is as well. If you actually want ros to suck less, please package the reset of ROS2, and push it to Debian.

Exciting. I just looked for docs about these new features, and can't find anything. Can you point us to these? Thanks!

I like looking at these, but does why does it have to redline my cpu?

This is HN. This thread is about data and backups. Yes.

There are multiple cross-platform gui toolkits. What's wrong with QT?

Does org-babel work? Do equations work?

I blog with emacs using the long-abandoned o-blog generator. Anybody have something better? Using the org-mode exporter, with working org-babel and equations and all that. This article doesn't go into the details.

I'm saying that all usage of docker that I have ever seen is as a laughably over-engineered schroot. Literally. It can probably do more stuff, but I haven't seen it.

Are you referring to this Nix effort or to Docker? Because that largely applies to most usages of Docker.

Eventually, yes I guess. But long before that the breaker and breakee both are notified, and the breakage hopefully is fixed. As it should be.

I would hope the other aspirational software distribution systems (pip, npm, et al) ALSO do that, but according to this article, I guess they don't? Not shocked , to be honest

I'm also space and launch-vehicle adjacent. Using vnlog for data storage (like what you described, but with better tooling support) and feedgnuplot/gnuplotlib for visualization. Works great. The learning curve is really easy, you can get going and start analyzing stuff FAST. Making complex plots is fiddly, but it usually is with any tool.

Important nitpick: this wasn't reported to the "Debian maintainers". In DEBIAN this was fixed long ago. The problem persists and was reported to people that work with Docker images, which is primarily people that don't want to use Debian the normal way, and don't benefit from many of the Debian niceties.

Because there are different use cases. About 100% of the people I talk to that use docker, are using it to make a separate set of dependencies available in a possibly-different distribution. For THOSE people, the ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate. I see docker users waste countless hours working around its statelessness. All the time. YMMV

Kinda. Yeah. Ignorance really isn't a virtue, and at some point bending over backwards to support people that don't want to learn things is counterproductive.

Look at "remake": a drop-in fork of GNU make, with an interactive debugger.

Mine too. This is a feature :)