HN user
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
Hear hear. That was has been thoroughly lost.
At least with android devices, you can plug in any usb keyboard, and have it work. Those are free, in the garbage all over the place
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.
It sorta looks like they're trying to reinvent Debian, and kinda failing?
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 is great, and is where the distro development actually happens. What doesn't it do that you want?
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.
I'm suggesting that people creating build systems read the make manual. Surely this isn't controversial?
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
I use vnlog and feedgnuplot to massage and plot data on the console all the time. It's even less than a tui, but might be what you want.
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.
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!