4 ms·

> It was true that management became less engineering-driven in the 1980s-1990s period, which was both unfortunate and avoidable, but it's also true that over t

> It was true that management became less engineering-driven in the 1980s-1990s period, which was both unfortunate and avoidable, but it's also true that over the same timeframe he's referring to, companies like Tektronix and HP had to migrate to custom ASICs and software-heavy architectures that were inherently less user-serviceable. Why do you think that? What about ASICs and software-heavy makes devices less user-serviceable? I mean, software has schematics you, we usually call those "source code", but it's the same thing, so the assumption would be that devices would come with the source code for the software. With ASICs, I can see a problem when the ASIC itself is broken and you can't buy it anymore, but then I'd think that's probably not the most common failure mode?

CamperBob2 7y ago
Code doesn't break, overheat, or wear out, so it's not something you'd expect to see in a service manual. ASICS can (and do) break, unfortunately, and schematics continue to be helpful in diagnosing and repairing those sorts of problems. Often an elaborate recalibration process is needed after doing so, requiring all kinds of specialized equipment. As a result, both the supply and the demand for those schematics started ramping down in the 1990s. Early on in that cycle, some major customers like Boeing continued to insist that schematics be provided, which is the only reason we have some of those documents at all.
- zAy0LfpBZLC8mAC 7y ago
  > Code doesn't break, overheat, or wear out, so it's not something you'd expect to see in a service manual. But the purpose of a schematic is not to identify a broken component, it's to enable you to understand the system and thus diagnose malfunction, which is exactly what you would need the code for as well. When it's obvious what component is broken (like, a blown cap or a burned resistor or whatever), you don't need a schematic to figure out the fix. You need a schematic to understand all the stuff around the actual defect in order to be able to locate it--and code would be equally useful for that. The fact that there is no wear to repair in the code itself is secondary--there is no (problematic) wear in most of the circuit that you study to find the fault either. Also, even if there is no wear to repair, there could still be opportunities to modify things either for repair or for diagnostic purposes. Like, make the software produce test signals that you can trace through the circuit. Or "rewire" I/O pins in the software to work around broken hardware. Exactly what you would use schematics for as well: It's not always about replacing a broken part, sometimes you also just modify some other parts of the circuit to restore function or to diagnose a problem, and the same could potentially be done in the software as well. > ASICS can (and do) break, unfortunately, and schematics continue to be helpful in diagnosing and repairing those sorts of problems. Well, yeah, sure. But my point is that many defects are in other parts of the circuit, and knowing the internals of the ASIC could still be helpful in diagnosing and fixing those problems.

CamperBob2 7y ago

Code doesn't break, overheat, or wear out, so it's not something you'd expect to see in a service manual. ASICS can (and do) break, unfortunately, and schematics continue to be helpful in diagnosing and repairing those sorts of problems. Often an elaborate recalibration process is needed after doing so, requiring all kinds of specialized equipment. As a result, both the supply and the demand for those schematics started ramping down in the 1990s. Early on in that cycle, some major customers like Boeing continued to insist that schematics be provided, which is the only reason we have some of those documents at all.

zAy0LfpBZLC8mAC 7y ago
> Code doesn't break, overheat, or wear out, so it's not something you'd expect to see in a service manual. But the purpose of a schematic is not to identify a broken component, it's to enable you to understand the system and thus diagnose malfunction, which is exactly what you would need the code for as well. When it's obvious what component is broken (like, a blown cap or a burned resistor or whatever), you don't need a schematic to figure out the fix. You need a schematic to understand all the stuff around the actual defect in order to be able to locate it--and code would be equally useful for that. The fact that there is no wear to repair in the code itself is secondary--there is no (problematic) wear in most of the circuit that you study to find the fault either. Also, even if there is no wear to repair, there could still be opportunities to modify things either for repair or for diagnostic purposes. Like, make the software produce test signals that you can trace through the circuit. Or "rewire" I/O pins in the software to work around broken hardware. Exactly what you would use schematics for as well: It's not always about replacing a broken part, sometimes you also just modify some other parts of the circuit to restore function or to diagnose a problem, and the same could potentially be done in the software as well. > ASICS can (and do) break, unfortunately, and schematics continue to be helpful in diagnosing and repairing those sorts of problems. Well, yeah, sure. But my point is that many defects are in other parts of the circuit, and knowing the internals of the ASIC could still be helpful in diagnosing and fixing those problems.