Hacker News

"The Kampfanzugskode isn't working well." - "Why can't we use KI to improve it? I've heard from Hans that this Klaus Kode is good at Programmierung." - "We can only use Mistral because of Regulierungen." - "Let's open source it then, so others can use Klaus Kode." - "Ja! This is indeed a legit Schlupfloch and a fantastische Idee!"

Excellent cold open for a sci fi

There's a range of DDS implementations, definitely a number that are compatible with embedded and spaceflight applications that don't require dynamic memory allocations. You're going to take a hit on some DDS features, but then again you aren't going to need to handle a large queue of large dynamically-sized messages on some small embedded platform.

I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.

Pretty sure there are DDS implementations that provide most of that, maybe with memory pools instead of no-allocations.

Other than that, PX4 uses an in-memory only pub/sub for internal data bus, somewhat inspired by DDS

Zenoh (https://zenoh.io/) is a good alternative to DDS in many cases - it scales down to microcontrollers with most features still intact, but scales up to a routed hybrid mesh if needed.

It does move the schema enforcement out of the middleware layer, so it’s a bit different. But it’s now a first-class alternative middleware implementation for ROS2 as an alternative to DDS.

I have not heard about HLA for a looong time !

why the hate on DDS?

seems like a perfect fit.

They've got the IDL files as well for the APIs, but you can't use them without their libs:

> The data model is defined using a custom format .rmodel based on the ddkit > framework (rmodel-api).

> Please note that the .rmodel data model is for documentation purposes only and > does not reflect the actual interface used on the communication layer. Network > communication is only possible through the provided libraries.

I think that’s what the “protcol” (sic) in the title was supposed to indicate. I agree it’s misleading.

This seems like an incredibly unimportant quibble... I would imagine they just used std::endl b/c that's what most random tutorials used in the 2000s and that's how the engineer learned. If you are printing a debug string, you probably don't care that much about perf in the first place.

The modern C++ idiom is std::println() anyways...

https://en.cppreference.com/cpp/io/println

For a long time, std::endl demonstrated that you were a proper C++ programmer, not some neckbeard C apologist. It wasn’t until C++ had „won“ that it became acceptable to use \n again.

> And because cout is guaranteed to flush anyways when the program ends, you're adding a delay for no reason.

I mean... If your command line utility doesn't print anything til it's done, that is going to be, _at best_, an annoying user experience.

Cool I did not know that.

Your comment is a bit salty, but I learned something from it, so I don’t think you deserve the downvotes

DDS sort of took over from CORBA in the military domain, and the statically-typed IDL was still quite similar to CORBA last time I looked at it, so that takes you back to around 1998 when CORBA was being used a lot in the military in my experience.

What other protocols and systems were you thinking of that can provide (depending on broker) hard-realtime delivery that can be used in safety-critical systems?

Every mil company designs unique bespoke things often with some exceptions, and even the "open systems" mostly aren't open by any stretch of the definition.

Obscurity is part of the allure, not a repulsive factor.

You don't want a hostile nation suddenly and easily understanding your systems.

This is so ROS2 that ROS2 can't even tell that its not ROS2