5 ms·

We need another variation of the rule: "Any sufficiently advanced desktop operating system contains an informal, buggy implementation of half of Smalltalk" DBu

by sph 2y ago

We need another variation of the rule: "Any sufficiently advanced desktop operating system contains an informal, buggy implementation of half of Smalltalk" DBus, COM, various UNIX IPC mechanisms & co. are a lot of bureaucracy to do a very simple job: connecting two things and letting them communicate, without caring about the semantics of messaging, or protocols. DBus is crucial to making a fully-featured desktop, but that's a lot of work to send some typed data to another process. Despite the complexity and ceremony, more and more thing depend on DBus because communication among disparate actors is such a useful concept. We have spent the last 60 years in this field focused on honing methods of computation, while communication is something that's tacked on at the end. Now, deep in the Internet age, with fast-enough multicore networked machines, we need a lot of boilerplate to do something all our software depends on. [1] It should be the other way around: communication should be as easy, for the programmer, as adding two integers. (I am working on this space, as I have been obsessed with this question for a long while.) --- 1: even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that?

cjk2 2y ago
I quote Fowler's ancient First Law of Distributed Object Design: "don't distribute your objects". Any distribution results in masked complexity and many hard to reason about scenarios even if the language or platform supports it transparently. Ergo, just because you can doesn't mean you should, unless you want to discover them all, usually at an inconvenient point in the future when everything is broken and there's cash bleeding out of your org somewhere.
- sph 2y ago
  > don't distribute your objects I guess people writing microservices or services connected via the Internet didn't get the memo.
  - mort96 2y ago
    Microservices aren't about distributed objects, they're about small services which communicate via explicit IPC (such as HTTP or gRPC).
  - dayjaby 2y ago
    The author of that rule explains that (well-crafted) microservices don't disobey that rule: https://martinfowler.com/articles/distributed-objects-microservices.html https://martinfowler.com/articles/distributed-objects-micros...
  - cjk2 2y ago
    I spend all day every day working with those. I have yet to find a single microservices architecture that could not be solved cheaper and simpler in some other way with less side effects. Plus there are some disparity between APIs and object distribution. (Note I only work on non-google scale stuff where it is probably appropriate) Edit: good example recently, I saw one where they implemented a complex distributed reservation pattern across microservices that gets about 100 transactions a day. They could have done it in one process with proper transaction isolation in a DB fine for about 1/100th of the total cost.
    - XorNot 2y ago
      Honestly the rule I put on it nowadays is, if it doesn't have a logical boundary within the organization then it doesn't need to be a separate service. If you have 6 microservices and they're all being maintained by the same team of developers, you don't need 6 microservices. At most, I would grant maybe 2 - and that's simply because usually once something like payments and credit card handling get involved, for compliance reasons you want to really not touch it unless you have to - but that's still an organization boundary, just a self-imposed/PCI compliance based one.
      - khimaros 2y ago
        sounds as bit like Conway's Law
      - oaiey 2y ago
        Conway's law
mort96 2y ago
Frankly, I completely disagree. There was a lot of research into distributed objects back in the 80s/90s; languages which allow objects to seamlessly move between nodes. And there's a very good reason IMO why that never took off. Communication between processes is always fallible and subject to blocking indefinitely, and when such communication happens implicitly and all over the place, the result is a disaster. IPC must be explicit, not implicit. IPC must also be language-agnostic, which means serialization and deserialization, which means there will always be some manual "impedance matching" between your program's domain model and the IPC protocol's messages. Could things be better? Sure, yeah, I guess. Languages with a single implicit event loop and with native support for JSON-like trees of values (such as JavaScript) will have an easier time than languages with neither (such as C++). But I don't think there's really some magical 10x better solution out there if only we had all "seen the light" and used SmallTalk.
- sph 2y ago
  > Communication between processes is always fallible and subject to blocking indefinitely You speak as if you have never heard of Carl Hewitt's research, Erlang or Elixir before.
  - mort96 2y ago
    You mentioned SmallTalk, not Erlang. I wasn't aware that Erlang did IPC implicitly.
    - sph 2y ago
      Erlang puts communication across actors/processes at its core mechanism. Sending a message is as simple as adding two numbers. It is closer to Smalltalk than a lot of other programming paradigms. The real issue is that Erlang is its own world. But you could also say IPC is its own world (does not work natively on the Internet, does not work on non-UNIX machines, etc.)
      - grandinj 2y ago
pjmlp 2y ago
You mean OS/2 with Visual Age for Smalltalk and SOM? It was great, SOM even supported meta-classes, but sadly we all know how it went down.
rwmj 2y ago
> communication should be as easy, for the programmer, as adding two integers I agree wholeheartedly. But the real issue is that Linux doesn't have rich communication primitives (compared to, say, the NT kernel), so we've had to implement those in userspace, and so here we are with systemd and dbus being intertwined with each other and the rest of the desktop. It could have been better if the kernel provided a message bus or at least some primitives.
- pjmlp 2y ago
  Even with richer kernel primitives, Apple, Google and Microsoft have learned that user space with process separation for IPC and OS extensions, is a much saner way than expecting developers to write code that doesn't randomly crash their hosts, including the kernel.
amelius 2y ago
> We need another variation of the rule: "Any sufficiently advanced desktop operating system contains an informal, buggy implementation of half of Smalltalk" How about: any sufficiently advanced desktop OS eventually turns into a buggy microservices system.
nurettin 2y ago
> even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that? I usually output json if the output is hierarchical, or some simple size+block format if it is just fixed size column data.
mike_hearn 2y ago
You might want to look at how Apple's platform does it. If you use the high level API it's pretty straightforward. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1 https://developer.apple.com/library/archive/documentation/Ma...
- nxobject 2y ago
  (Not to be confused with the OG Mach messages!) https://dennisbabkin.com/blog/?t=interprocess-communication-using-mach-messages-for-macos https://dennisbabkin.com/blog/?t=interprocess-communication-...
zzo38computer 2y ago
I think there are many problems with D-Bus, and there are better ways to send data to other processes. It is a useful feature, but I have different ideas about how it would be done, which I will describe below. There is no bus names, interface names, and object path. Capabilities are used, and the program refers to the capabilities it has access to, to do any kind of I/O (and, the capabilities can be used for security, too). The kernel does not know about data types; each message is a sequence of bytes and/or capabilities. However, there is common conventions (which are the same for all computer types, so that programs on different computers and programs being emulated, can still communicate with each other) for data types. It does not use Unicode, so there are no Unicode types (the main character code is Extended TRON Code, although 8-bit characters are also possible, including strings of arbitrary bytes/capabilities which can be used for any purpose). It does not need the marshaling, authentication, etc like D-Bus uses. Other features of D-Bus also are not needed, and can be made simpler and faster. The Command, Automation, and Query Language would make communication almost as easy as adding numbers together. (It can never be quite as easy (unless adding numbers is difficult), because communication is just a thing that is not as easy, anyways; but, it can be made almost easy.) Actually, it is like a actor model in some ways. (The above ideas are a part of an operating system design, which does not yet have a name, at this time.) > (I am working on this space, as I have been obsessed with this question for a long while.) What is your work on this space? > even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that? I would think it depends what you need to communicate. Sometimes, I would expect, printf would do.

by sph 2y ago

cjk2 2y ago

I quote Fowler's ancient First Law of Distributed Object Design: "don't distribute your objects". Any distribution results in masked complexity and many hard to reason about scenarios even if the language or platform supports it transparently. Ergo, just because you can doesn't mean you should, unless you want to discover them all, usually at an inconvenient point in the future when everything is broken and there's cash bleeding out of your org somewhere.

sph 2y ago
> don't distribute your objects I guess people writing microservices or services connected via the Internet didn't get the memo.
- mort96 2y ago
  Microservices aren't about distributed objects, they're about small services which communicate via explicit IPC (such as HTTP or gRPC).
- dayjaby 2y ago
  The author of that rule explains that (well-crafted) microservices don't disobey that rule: https://martinfowler.com/articles/distributed-objects-microservices.html https://martinfowler.com/articles/distributed-objects-micros...
- cjk2 2y ago
  I spend all day every day working with those. I have yet to find a single microservices architecture that could not be solved cheaper and simpler in some other way with less side effects. Plus there are some disparity between APIs and object distribution. (Note I only work on non-google scale stuff where it is probably appropriate) Edit: good example recently, I saw one where they implemented a complex distributed reservation pattern across microservices that gets about 100 transactions a day. They could have done it in one process with proper transaction isolation in a DB fine for about 1/100th of the total cost.
  - XorNot 2y ago
    Honestly the rule I put on it nowadays is, if it doesn't have a logical boundary within the organization then it doesn't need to be a separate service. If you have 6 microservices and they're all being maintained by the same team of developers, you don't need 6 microservices. At most, I would grant maybe 2 - and that's simply because usually once something like payments and credit card handling get involved, for compliance reasons you want to really not touch it unless you have to - but that's still an organization boundary, just a self-imposed/PCI compliance based one.
    - khimaros 2y ago
      sounds as bit like Conway's Law
    - oaiey 2y ago
      Conway's law

mort96 2y ago

Frankly, I completely disagree. There was a lot of research into distributed objects back in the 80s/90s; languages which allow objects to seamlessly move between nodes. And there's a very good reason IMO why that never took off. Communication between processes is always fallible and subject to blocking indefinitely, and when such communication happens implicitly and all over the place, the result is a disaster. IPC must be explicit, not implicit. IPC must also be language-agnostic, which means serialization and deserialization, which means there will always be some manual "impedance matching" between your program's domain model and the IPC protocol's messages. Could things be better? Sure, yeah, I guess. Languages with a single implicit event loop and with native support for JSON-like trees of values (such as JavaScript) will have an easier time than languages with neither (such as C++). But I don't think there's really some magical 10x better solution out there if only we had all "seen the light" and used SmallTalk.

sph 2y ago
> Communication between processes is always fallible and subject to blocking indefinitely You speak as if you have never heard of Carl Hewitt's research, Erlang or Elixir before.
- mort96 2y ago
  You mentioned SmallTalk, not Erlang. I wasn't aware that Erlang did IPC implicitly.
  - sph 2y ago
    Erlang puts communication across actors/processes at its core mechanism. Sending a message is as simple as adding two numbers. It is closer to Smalltalk than a lot of other programming paradigms. The real issue is that Erlang is its own world. But you could also say IPC is its own world (does not work natively on the Internet, does not work on non-UNIX machines, etc.)
    - grandinj 2y ago

pjmlp 2y ago

You mean OS/2 with Visual Age for Smalltalk and SOM? It was great, SOM even supported meta-classes, but sadly we all know how it went down.

rwmj 2y ago

> communication should be as easy, for the programmer, as adding two integers I agree wholeheartedly. But the real issue is that Linux doesn't have rich communication primitives (compared to, say, the NT kernel), so we've had to implement those in userspace, and so here we are with systemd and dbus being intertwined with each other and the rest of the desktop. It could have been better if the kernel provided a message bus or at least some primitives.

pjmlp 2y ago
Even with richer kernel primitives, Apple, Google and Microsoft have learned that user space with process separation for IPC and OS extensions, is a much saner way than expecting developers to write code that doesn't randomly crash their hosts, including the kernel.

amelius 2y ago

> We need another variation of the rule: "Any sufficiently advanced desktop operating system contains an informal, buggy implementation of half of Smalltalk" How about: any sufficiently advanced desktop OS eventually turns into a buggy microservices system.

nurettin 2y ago

> even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that? I usually output json if the output is hierarchical, or some simple size+block format if it is just fixed size column data.

mike_hearn 2y ago

You might want to look at how Apple's platform does it. If you use the high level API it's pretty straightforward. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1 https://developer.apple.com/library/archive/documentation/Ma...

nxobject 2y ago
(Not to be confused with the OG Mach messages!) https://dennisbabkin.com/blog/?t=interprocess-communication-using-mach-messages-for-macos https://dennisbabkin.com/blog/?t=interprocess-communication-...

zzo38computer 2y ago

I think there are many problems with D-Bus, and there are better ways to send data to other processes. It is a useful feature, but I have different ideas about how it would be done, which I will describe below. There is no bus names, interface names, and object path. Capabilities are used, and the program refers to the capabilities it has access to, to do any kind of I/O (and, the capabilities can be used for security, too). The kernel does not know about data types; each message is a sequence of bytes and/or capabilities. However, there is common conventions (which are the same for all computer types, so that programs on different computers and programs being emulated, can still communicate with each other) for data types. It does not use Unicode, so there are no Unicode types (the main character code is Extended TRON Code, although 8-bit characters are also possible, including strings of arbitrary bytes/capabilities which can be used for any purpose). It does not need the marshaling, authentication, etc like D-Bus uses. Other features of D-Bus also are not needed, and can be made simpler and faster. The Command, Automation, and Query Language would make communication almost as easy as adding numbers together. (It can never be quite as easy (unless adding numbers is difficult), because communication is just a thing that is not as easy, anyways; but, it can be made almost easy.) Actually, it is like a actor model in some ways. (The above ideas are a part of an operating system design, which does not yet have a name, at this time.) > (I am working on this space, as I have been obsessed with this question for a long while.) What is your work on this space? > even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that? I would think it depends what you need to communicate. Sometimes, I would expect, printf would do.