4 ms·

A gold standard behaviour for when you want to replace a disfunctional tool/system and will require buy-in from a wide community, is to behave like Charlie Mars

by senko 11mo ago

A gold standard behaviour for when you want to replace a disfunctional tool/system and will require buy-in from a wide community, is to behave like Charlie Marsh did with ruff and uv. He didn't barge in guns blazing proclaiming "pip is a disgrace" and "it's a fuckin joke". He wrote a tool that was much better and encourage others to try it. Within a year or so, it snowballed into an unstoppable change. This project currently has a bunch of C++ files, no docs, no tests, no roadmap on how it might replace d-bus, nothing. And as another commenter pointed out, starting a new system service in 2025, yelling about security, and doing this in an unsafe language doesn't inspire confidence. Lennart Poettering, Theo de Raadt and Linus Torvalds may get away with talking like this, but if you seriosly want to bring a wide community on board (without which the entire thing is a non-starter), look to Charlie instead. Oh, and also, if you think D-Bus is bad, consider yourself lucky you didn't need to use the thing it replaced - CORBA.

GalaxyNova 11mo ago
> This project currently has a bunch of C++ files, no docs, no tests I think the more important thing is the protocol itself, rather than the specific implementation. As the author notes the current D-bus standards are substandard at best.
- senko 11mo ago
  I can get on board with that if there's a protocol spec - at least a draft or something more tangible than "it's a tavern". I just see a bunch of undocumented C++ code here.
- forty 11mo ago
  I think one of the point from your parent comment is that something that works for people is a powerful way of making things happen, much more powerful than rants or theory or protocols. I also noticed that with cryptography algorithms/protocol for example: design the most amazing algorithm - no one is going to use it ever if there is no great reference implementation people can use.
Asooka 11mo ago
Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer." Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
javier2 11mo ago
Aint that the truth. D-Bus isnt that terribly shit either, we just need to solve this SecretManager issue...
p_l 11mo ago
At this point I would like CORBA back.
- parsimoniousplb 11mo ago
  That would be Cap'n Proto RPC
  - p_l 11mo ago
    No thanks, all the reasons I ended up looking at CORBA recently are because of things that simple RPC libs like Cap'n Proto don't do.
    - kentonv 11mo ago
      Out of curiosity, like what?
      - p_l 11mo ago
        - There's actual standard logic for remotely-existing objects vs. just RPC - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases) - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects) - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems) That's just quick throw from memory.
        kentonv 11mo ago
        > - There's actual standard logic for remotely-existing objects vs. just RPC Cap'n Proto is an object-capability system that very much has a uniform representation of remote objects. Object references are first-class types. You can send someone a remote object reference, embedded in some other message (e.g. params or return value of another RPC). When they release that reference, you get notified that the object can now be cleaned up. Is there something else you were looking for here that Cap'n Proto doesn't do? Not meaning to argue, just curious to understand. (I'm the author of Cap'n Proto.) > - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases) FWIW Cap'n Proto objects can implement multiple interfaces. That said, identity of remote objects is a surprisingly complicated subject, and at present it's not necessarily possible to tell whether two references point to the same object. > - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects) This is definitely a limitation of Cap'n Proto right now. > - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems) There is definitely a lot CORBA does here that Cap'n Proto doesn't. Cap'n Proto itself only defines object lifetimes within the context of an RPC session. Persistence and long-term object identity are left to a higher layer.

by senko 11mo ago

GalaxyNova 11mo ago

> This project currently has a bunch of C++ files, no docs, no tests I think the more important thing is the protocol itself, rather than the specific implementation. As the author notes the current D-bus standards are substandard at best.

senko 11mo ago
I can get on board with that if there's a protocol spec - at least a draft or something more tangible than "it's a tavern". I just see a bunch of undocumented C++ code here.
forty 11mo ago
I think one of the point from your parent comment is that something that works for people is a powerful way of making things happen, much more powerful than rants or theory or protocols. I also noticed that with cryptography algorithms/protocol for example: design the most amazing algorithm - no one is going to use it ever if there is no great reference implementation people can use.

Asooka 11mo ago

Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer." Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.

javier2 11mo ago

Aint that the truth. D-Bus isnt that terribly shit either, we just need to solve this SecretManager issue...

p_l 11mo ago

At this point I would like CORBA back.

parsimoniousplb 11mo ago
That would be Cap'n Proto RPC
- p_l 11mo ago
  No thanks, all the reasons I ended up looking at CORBA recently are because of things that simple RPC libs like Cap'n Proto don't do.
  - kentonv 11mo ago
    Out of curiosity, like what?
    - p_l 11mo ago
      - There's actual standard logic for remotely-existing objects vs. just RPC - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases) - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects) - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems) That's just quick throw from memory.
      - kentonv 11mo ago
        > - There's actual standard logic for remotely-existing objects vs. just RPC Cap'n Proto is an object-capability system that very much has a uniform representation of remote objects. Object references are first-class types. You can send someone a remote object reference, embedded in some other message (e.g. params or return value of another RPC). When they release that reference, you get notified that the object can now be cleaned up. Is there something else you were looking for here that Cap'n Proto doesn't do? Not meaning to argue, just curious to understand. (I'm the author of Cap'n Proto.) > - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases) FWIW Cap'n Proto objects can implement multiple interfaces. That said, identity of remote objects is a surprisingly complicated subject, and at present it's not necessarily possible to tell whether two references point to the same object. > - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects) This is definitely a limitation of Cap'n Proto right now. > - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems) There is definitely a lot CORBA does here that Cap'n Proto doesn't. Cap'n Proto itself only defines object lifetimes within the context of an RPC session. Persistence and long-term object identity are left to a higher layer.