elfenpiff
commented
3 days ago @tamird I appreciate and completely get it.
Just to give you some context, we have all been working together for the last seven years. Starting with a Bosch research project, the predecessor of iceoryx, then we fought for over a year to make it open source. In the last years, we have certified parts of iceoryx1 according to ISO 26262 and realized that some things make the zero-copy communication hard to certify - one key element was the central broker.
We started redesigning iceoryx again and came up with the iceoryx2 architecture. It just took us five years to realize that everyone has a central broker - it is the operating system. So we founded ekxide to realize the next generation of iceoryx.
At the moment we have the goal to reach feature parity with iceoryx and complete the user documentation with a good getting started guide. When this is done, we will present the iceoryx2 design in detail. Maybe it would be a great topic for a FOSDEM 2025 talk but I think we need a bit more than just one hour.
Just out of curiosity, what topic would you be most interested in:
- Architecture without a central daemon
- Decentralized process monitoring and resource cleanup
- Decentralized communication and service discovery
- Zero trust approach for shared memory communication
- Indestructible processes
- Incorruptible data structures
tamird
It would be great to have something like a design document: what problems does this library solve, how does it solve them, how does it avoid various pitfalls, etc.
I came across this reply from @elBoberido on HN and it's emblematic of what's lacking; the parent talks about shared memory challenges in the presence of process death and the response simply states
Another point of confusion for me: how does this work without a central broker? According to https://iceoryx.io/ there is no need for one.
Anyway, something that describes the design of the software would go a long way in increasing (at least my) confidence in it.