4 ms·

>Think of chips as microservices. This is a good analogy, but not in your favor. This is all part of the disease of modern computing where you program against

>Think of chips as microservices. This is a good analogy, but not in your favor. This is all part of the disease of modern computing where you program against a giant machine with a giant interface and you set a few config variables and have no idea or control over how it will work and your program winds up full of unintended behavior. See: game engines, gstreamer, web frameworks, browser API, HDMI modules, terminal emulators, shells (bash, etc).

Kye 5y ago
The flip side is that the more popular an off-the-shelf tool is, the harder it is to sneak something in. Someone somewhere is bound to notice fishy behavior at a certain scale. It lowers the skill level required to understand the choices you make and make better choices. I wouldn't even know where to begin trying to notice, much less explore, what AT&T is doing at 1111340002. The more components with a million eyes watching it, the more attention you can direct toward the rest.
- unixbane 5y ago
  So you're saying having giant IP modules inside your electronics is somehow making things more secure? They certainly don't make the product any less buggy.
  - Kye 5y ago
    Sometimes it goes down a dark path, like with Google moving all the important stuff in AOSP into a proprietary app attached to proprietary services most devices end up using to deal with phone vendors not updating. I'm not sure it's possible to come to a real determination here when the viewpoint counter to mine would require someone go find and study all the obscure little modules 2 people in the world know how to work with. The data is stacked in my favor, but it's hopelessly incomplete. I might be wrong.
- JohnFen 5y ago
  > Someone somewhere is bound to notice fishy behavior at a certain scale. I'm not convinced that this is true to a meaningful degree. It's certainly theoretically true. However, we've now had a number of events where bad things were found in fundamental and popular OSS software, and those things existed for years or even decades before being found. And who knows how many more exist that haven't been found, or at least publicized, yet (and may never be). I think the reality is that most devs aren't deeply examining the tools and libraries they use. How could we? We'd spend all of our time vetting software and little time writing it.

Kye 5y ago

The flip side is that the more popular an off-the-shelf tool is, the harder it is to sneak something in. Someone somewhere is bound to notice fishy behavior at a certain scale. It lowers the skill level required to understand the choices you make and make better choices. I wouldn't even know where to begin trying to notice, much less explore, what AT&T is doing at 1111340002. The more components with a million eyes watching it, the more attention you can direct toward the rest.

unixbane 5y ago
So you're saying having giant IP modules inside your electronics is somehow making things more secure? They certainly don't make the product any less buggy.
- Kye 5y ago
  Sometimes it goes down a dark path, like with Google moving all the important stuff in AOSP into a proprietary app attached to proprietary services most devices end up using to deal with phone vendors not updating. I'm not sure it's possible to come to a real determination here when the viewpoint counter to mine would require someone go find and study all the obscure little modules 2 people in the world know how to work with. The data is stacked in my favor, but it's hopelessly incomplete. I might be wrong.
JohnFen 5y ago
> Someone somewhere is bound to notice fishy behavior at a certain scale. I'm not convinced that this is true to a meaningful degree. It's certainly theoretically true. However, we've now had a number of events where bad things were found in fundamental and popular OSS software, and those things existed for years or even decades before being found. And who knows how many more exist that haven't been found, or at least publicized, yet (and may never be). I think the reality is that most devs aren't deeply examining the tools and libraries they use. How could we? We'd spend all of our time vetting software and little time writing it.