4 ms·

I've written about the same comparison, but came to a somewhat different conclusion. In my experience Embedded Software development was poor preparation for my

I've written about the same comparison, but came to a somewhat different conclusion. In my experience Embedded Software development was poor preparation for my later distributed-systems work (I wrote Embedded Software for 10 years, then distributed databases and logging analysis systems for the next 10). Embedded software is so deterministic compared to large-scale systems. https://www.philipotoole.com/a-prayer-for-distributed-systems-developers/ https://www.philipotoole.com/a-prayer-for-distributed-system... "The idea of monitoring the responsiveness of a read-modify-write cycle is obviously nonsense from a programmer’s point of view (though not so for the microprocessor designer!)."

rcxdude 4y ago
You can turn even a small embedded system into a distributed system if you try. It's a common fault of designers to sprinkle a lot of different processors throughout a system without realising they're creating a problem for themselves or the software developers who have to use the hardware. I've seen a single PCB with 8 processors on it (for no good reason other than the electronics engineer thought it was convenient and liked PICs), it made it so much harder to maintain the state of the system than it needed to be. (and even though the response times may be far more consistent than what a distributed web application may need to deal with, at least the underlying tools like TCP generally work pretty well, unlike the half-measures embedded developers tend to wind up implementing)
- otoolep 4y ago
  A system made of multiple distinct components, while it can be complicated, is not a distributed system. A SoC is not a distributed system. For the system you describe to have the practical challenges of a distributed system it would also need experience some of the following: - some of the "different processors" would need to fail at seemingly random times, only to come back again in a few minutes. - the speed at which those "different processors" respond would need to vary widely, and different times of the day.
  - larve 4y ago
    Isn't that the case though? I often have the case of some cheap-ass i2c peripheral getting locked up because of noise on the lines or what not. While this hopefully gets caught and we get the timing right to make things work in production, I pretend it's an async device that can fail and lock up at any point. It makes debugging easier.

rcxdude 4y ago

You can turn even a small embedded system into a distributed system if you try. It's a common fault of designers to sprinkle a lot of different processors throughout a system without realising they're creating a problem for themselves or the software developers who have to use the hardware. I've seen a single PCB with 8 processors on it (for no good reason other than the electronics engineer thought it was convenient and liked PICs), it made it so much harder to maintain the state of the system than it needed to be. (and even though the response times may be far more consistent than what a distributed web application may need to deal with, at least the underlying tools like TCP generally work pretty well, unlike the half-measures embedded developers tend to wind up implementing)

otoolep 4y ago
A system made of multiple distinct components, while it can be complicated, is not a distributed system. A SoC is not a distributed system. For the system you describe to have the practical challenges of a distributed system it would also need experience some of the following: - some of the "different processors" would need to fail at seemingly random times, only to come back again in a few minutes. - the speed at which those "different processors" respond would need to vary widely, and different times of the day.
- larve 4y ago
  Isn't that the case though? I often have the case of some cheap-ass i2c peripheral getting locked up because of noise on the lines or what not. While this hopefully gets caught and we get the timing right to make things work in production, I pretend it's an async device that can fail and lock up at any point. It makes debugging easier.