$1k per year if you run an action 24/7. How many minutes per month do you actually use? How does that compare to the cost of the machines being used as runners?
The real mistake was GH not charging anything for self-hosted runners in the first place, setting an expectation.
There were a bunch of ports, like arm64, but with several bugs. So the maintainer removed all but x86_64, and then another group added risc64.
From there arm64 can be tried again
Does XML allow you to define for-loops inside <bracketed> items then reference the loop variables inside {{template vars}}? https://youtu.be/b9WDcFsKixo?t=223
I guess it doesn't prevent you from doing such things, but... well... there's some eyebrow-raising shoehorning in this one.
Yes it does. Apache ant did that... many many years ago.
Creating a new language that looks like XML but is not XML is... kind of unforgivable. I'd go as far and call it amateur-like. We already have good configuration languages (such as dhall-lang) and when more power is needed, then just use a real language and provide a DSL inside of it.
Similarly, PROFINET, the confusingly named EtherNet/IP (IP here stands for Industrial Protocol not Internet Protocol), POWERLINK, and others - all based on Ethernet but with a custom protocol layer replacing IP. "We need something that is high speed but also supports rapid deterministic communication" is pretty much a solved problem in the industrial space.
I wonder what Tesla's game is here: is it really just reinventing the wheel, or are they perhaps using higher speed Ethernet as industrial Ethernet tends to still be limited to 100Mbit? Or perhaps it's tightly linked with the proposal to communicate over 48V lines?
Industrial Ethernet uses 100Mb speeds because (and when) those are sufficient for their use cases. There is no technical limitation there. 1000base-T1 (and even 2.5, 5 & 10G SPE¹) show where this is going.
Huh, I didn't know single pair ethernet went up that fast - neat! We're still living in the 100Mbit world at my company - and, yeah, it's fast enough for pretty much everything we need.
Trying to secure hardware that the attacker has direct access to is just so brutal. Your hardware vendor can promise compliance with X spec, implement Y protections and still fall foul to something like this.
It’s interesting to me that every robotics framework essentially boils down to a specialised pub-sub system with some flavour of serialisation and some kind of startup/launcher to wrangle running separate processes.
Props to this team for picking Protobuf given its wider adoption unlike ROS and its custom format.
Is there a reason an existing pub-sub system like NATS isn’t suitable for a framework like this?
Also unfortunate that this project is written in C++ and offers Rust bindings rather than the other way around.
I always wonder about this too. Half the ROS projects I've seen are just single-board applications with topics.
ROS bags are a useful facility for data capture and testing, and there are some ROS packages that are useful (against the backdrop of an awful packaging/build system). But even all that is just because the community decided this particular pub-sub system was the robotics one and started building packages on it.
I suspect it just happened to be at the right place at the right time, worked well for a set of users in the robotics community and built up strong network effects there.
This is a pretty common story. Python became very successful in a similar way. I have seen things like flight critical software written in Python not because Python is a good language for it (if I heard this 15 years ago I would laugh), but because Python became a de-facto standard for prototyping in the domain due to its libraries, tools and bindings and solving a realtime challenge for an existing prototype is often an easier lift than rebuilding it from scratch. My 2c.
ROS was developed as the framework for the PR1 robot, as a "Linux for robotics" idea. But it really took off when Willow Garage GAVE out a bunch of PR2 robots to academic institutes around the world.
It then stuck because those labs, even independently, developed really useful tools in a very backwards compatible language (C++) or with support to old languages (Lisp). You can find many repos such as this one which basically have EVERYTHING, handed down from PhD to PhD student over decades
Basically a lot of the headache inducing grudge work exist there as a library, you only need to glue it together.
You want to calibrate your camera, get the relative position to the root of a robot arm? You can knack it together with openCV and then end up debugging for hours because coordinate transform convention was wrong. Or just install this library, publish your sensor data in specified topic, and it does it for you.
Imo it's easy to miss the usefulness of ROS if you don't consider the tf package, rosbag and rviz together with ROS as a bundle.
Everytime I see a pub/sub "new ROS" framework, sooner or later I realize I need to reinvent tf/rosbag/rviz, because those standard packages are almost never available (or available only for the developers specific need)
We support mcap (the data container format that ROS2 uses) and Foxglove for viz. Shoutout to Foxglove, it's a much nicer experience than rviz. Something like tf is on the todo list - I recognize it's important.
That's cool to hear! I'll follow the project and fingers crossed it works out. Since I still kind of rely on legacy packages I probably won't/can't move to it in the nearest future but it would definitely be great when "prototyping" and production could be merged to one (without headache)
IMO, the real value of ROS is the data logging (bag/mcap files), visualization (FoxGlove) are the main value of ROS. Even then, I'm not sure it's worth the overhead and brittleness of building and running it. There is just so much complexity deploying and developing for it.
Yep. ROS is great if you are an academic or a garage startup who needs to get anything at all up and running ASAP because it is extremely flexible and has a huge volume of community modules.
But, when it comes time to deploy serious business (very often Safety Critical) robots in the field, you don’t want flexibility. You want certainty. You don’t even want everyone’s contributions. You want specialized, carefully vetted code.
Thus the effort to make it easy to transition off of ROS to something simpler and more reliable.
Nice looking landing page. Small bug, when I scroll down the page and then click "pricing" it doesn't take me to the right spot on the page until I click again. On Firefox 125.0.3
The real mistake was GH not charging anything for self-hosted runners in the first place, setting an expectation.
reply