rubicks

You don't have to stop at the gas phase.

https://en.m.wikipedia.org/wiki/Inductively_coupled_plasma#A...

No. No, it isn't. Lynx is a browser I use in the terminal. This is something else.

Can confirm. $DAYJOB makes robots subject to hard worst-case latency constraints. The product runs on QNX.

Can confirm https://github.com/jonls/redshift works great; been using it for years.

Whoops, sorry. I must have repressed that trauma.

You treat it like the metaphorical toxic waste it is: avoid it at all costs. You don't need ROS to get a dependency manager, a build system, a middleware, and/or a process manager.

Can confirm. I am a grown man and my professional work with ROS has made me cry.

My colleagues and I used to joke that any build system issue you encounter will be addressed in next year's build system.

* https://wiki.ros.org/rosbuild

* https://wiki.ros.org/catkin

* https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libr...

* https://docs.ros.org/en/jazzy/How-To-Guides/Ament-CMake-Docu...

It doesn't feel like a joke anymore.

I have worked in two failed and failing startups that invested heavily in ROS. I could fill several volumes with "ROS Gotchas". Everything in the ROS stack is either a useless curio or an on-fire clown car.

Using ROS is a great way to turn your project and business into a cautionary tale.

Relevant: https://newsboat.org/

If you like your email in mutt, then you'll probably like your feeds in newsboat.

This is not a comment about open/closed-source software and/or licensing models.

Projects like this never fail to impress me vis-a-vis source obfuscation. The 'generate.pyz' is an interesting twist on the usual practice.

I have been looking for something like this. Got a link to your project?

Times like this really bolster my distrust and hatred for those horrible dkms installers. Thank you, nvidia, for living up to my worst expectations.

I'm interested in doing something similar, except using a board with open-source firmware. What kind of options do I have (if any)?

I'm putting qnx cross-toolchains into Debian packages because $DAYJOB builds qnx images in ubuntu containers. I've learned a lot about cross-toolchains and my appreciation for blackberry's technical prowess has never been lower.

Shucks: canonical abbreviation collision.

https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

I can't wait to see the shell equivalents for ptrace, setjmp, and dlopen.

What I remember about ROOT Cint is that it was an absolute nightmare to work with, mostly because it couldn't do STL containers very well. It was a weird time to do language interop for physicists.

SICP was one of my course texts and introduction to the scheme language. It is a masterpiece of a computer science book with a staggering breadth of applications.

I came here for this and I will not be shamed.

I usually start with the `dh_make` generated skeleton and incrementally add overrides as I iterate with `gbp buildpackage`. It's not pretty, but it's what I know.

If you are who I think you are, then the answer is "a lot".

If we can push Ubuntu out of the pole position, then I think we can solidify Alpine as the next great Linux distribution. I am all for simpler packaging.

I do fear, though, that Debian packaging has absorbed some necessary complexity that Alpine packaging has not --- if only because Debian has been around so much longer.

I have both hated and appreciated debian packaging, largely depending on the thing I was trying to package at the time. Things implemented in C/C++ and built with vanilla cmake are feasible. Other things get complicated very quickly.

If you're willing to absorb that complication, then debhelper really will handle any and every situation. It is a hell of an investment, though.

Hi! Given that I've invested 8 years learning and using debhelper, how does this affect me and my tooling?

My employer uses Teams and it is an extremely reliable productivity killer.

I came here expecting atom syndication for social media and was disappointed.

Here's a heuristic that works for me, for $foobar, any language and/or sufficiently complicated tech:

Within the documentation, find the sections that deal with the following topics:

  * extending $foobar
  * embedding C in $foobar
  * embedding $foobar in C
  * packaging/distributing $foobar
  * porting/cross-building $foobar

In my experience, these topics are inherently hardest to implement, last to be documented, and trickiest to understand. As such, they make for worthwhile reading for advanced practitioners.

I've been using firefox exclusively for years.

No, slack.com, I will not switch to chrome. Fix your "huddles" to support Firefox.

I prefer x2x, which supports multiple Linux hosts very well.

https://manpages.debian.org/bookworm/x2x/x2x.1.en.html