4 ms·

Sounds like the early* days of software engineering, where everything was a big bowl of spaghetti you would never untangle again, compared to modular applicatio

Sounds like the early* days of software engineering, where everything was a big bowl of spaghetti you would never untangle again, compared to modular applications that you have nowadays. *rumor has it, that most of the software out there is still written like that.

krisoft 2y ago
> Sounds like the early days of software engineering Sounds much more like they are trying to work with a production system without the source code, the debugers, the compilers, the datasheets, and the documentation. Plus many of the things they want go directly against the wishes and good judgement of the engineers who made the system. They want to start the car without the steering component. I bet that someone at the manufacturer spent extra energy that you can’t do that. Why? Because under production circumstances if the steering components are not answering that means that something is terribly wrong with the car and it would be dangerous to turn on and accelerate. Same with the keyless entry component. I bet that there were at least an effort done to make circumventing that hard.
- f1shy 2y ago
  >> Plus many of the things they want go directly against the wishes and good judgement of the engineers who made the system. Never attribute to intelligence what can easily be explained by good old stupidity. I know the automotive industry from inside. It is a miracle that cars work at all.
- deleted 2y ago
  [deleted]
Kye 2y ago
I thought early code was carefully validated on paper with flowcharts and review by someone else before you were allowed anywhere near an expensive CPU cycle.
- MrGilbert 2y ago
  Absolutely, yes. We had walls decorated with flow charts back in the day. (/s, just in case)
  - deleted 2y ago
    [deleted]
boricj 2y ago
In software engineering, we only ever maintain processes, not artifacts. Software modularity when it exists is usually extremely coarse and rigid when compared to the malleability of electro-mechanical systems. Got a bug to fix or a feature to implement on a program? Modify the source code, run the build system, use the newly built artifact and discard the old one. Lose this process and you're screwed because the tooling for modifying an extant program is still in the Dark Ages. It's not just about proprietary software that has reached its end of support, given enough time almost any source code tree will bitrot past the point where rebuilding it will require a major overhaul. When you need to fix or customize a physical artifact like a coffee machine, you usually don't go inside the factory to change the blueprints and manufacture a new one. You just modify the one you have with standardized tools. It also doesn't matter how old the artifact is, even if it's decades out of production it can still usually be disassembled and put back together as if it was fresh out of the assembly line. The more software bleeds into electro-mechanical systems, the less repairable, versatile and hackable they become.
- jiggawatts 2y ago
  That's very insightful, and I just wish I had the ability to explain this to non-technical managers. "But it was working!" "Sure, 10 years ago, now I can't even find a version of Visual Studio that will install that can even open the project, let alone compile it."
  - actionfromafar 2y ago
    And VS on an old laptop or Virtualbox might actually work, still. Good luck recreating some random services tangle from the year 2024 in 2034.
    - jiggawatts 2y ago
      Since Visual Studio is Windows only, the straightforward solution that I used was to install an old version in a Hyper-V virtual machine. Then it's a multi-step process where the project is upgraded inside the VM with an ancient VS copy as "far as it'll go", then copied out to the external environment with VS 2022 that also has the 2016 and 2019 "Build Tools" installed. Then the projects can be upgraded to "current day". In some cases I just gave up and created new empty projects with identical names and GUIDs, then copy-pasted the code files across. It can be simpler and faster.
m3047 2y ago
History doesn't repeat, it rhymes; and it kind of goes in phases or epochs. As Derrida was wont to point out, we show up in the middle of things, just flippantly speaking a language and carrying on as though the language was something we were born with and it's been the same forever because we only know our own "forever". I popped my cherry on VAX silicon, where stack frames were baked into the silicon. This meant that regardless of language, the stack architecture was a target for the compiler not something it constructed. I fell into the middle of things: VAX silicon was new, and people wrote in e.g. COBOL, FORTRAN, BASIC, Pascal, C because they'd successfully done so before and had libraries and practices which had stood the test of time and had made the jump to successfully infect a new species of silicon. The successful colonizer libraries and practices had certain rules. "You can't manage heap in BASIC" for example, or that modular compilation units all had to be written in the same language. This is not and never was strictly true, and the people writing code knew it; but it was true enough for code which jumped silicon. I on the other hand knew about the silicon stack, and could implicitly understand some of the more esoteric compiler pragmas for dealing with that stack (intended for cross-language linking support) and so by disabling certain linker checks and abusing compiler pragmas I could do e.g. memory management in BASIC by isolating the compilation unit where "memory is an array" from the one where "a memory address is an integer" and explicitly telling different lies with compiler pragmas in each. Fast forward a few years and everybody had learned HTML and then I'm confronted with somebody wanting me to fix a steaming basket of soup machine gun sprayed into different files all with "(c) Macromedia" in them. "Where's your no-code tool which generated this?" I innocently ask. "Wuuut?" is the response. Yea well when you find it, let me know. Let's just say the people who have to fix things like that probably get paid good money and the solves they come up with are comparatively fragile, that code will not (and did not) survive; any more than my silicon-aware hacks (which I was paid quite well for) for VAX will work on modern silicon. Where's all of that shitty VB Wizard code spew? Thankfully gone. Some of these integrations will not be fixable, but some of the subsystems will survive, and it might be simply because there is no security and it's possible to replay CANbus reliably as a result.

krisoft 2y ago

> Sounds like the early days of software engineering Sounds much more like they are trying to work with a production system without the source code, the debugers, the compilers, the datasheets, and the documentation. Plus many of the things they want go directly against the wishes and good judgement of the engineers who made the system. They want to start the car without the steering component. I bet that someone at the manufacturer spent extra energy that you can’t do that. Why? Because under production circumstances if the steering components are not answering that means that something is terribly wrong with the car and it would be dangerous to turn on and accelerate. Same with the keyless entry component. I bet that there were at least an effort done to make circumventing that hard.

f1shy 2y ago
>> Plus many of the things they want go directly against the wishes and good judgement of the engineers who made the system. Never attribute to intelligence what can easily be explained by good old stupidity. I know the automotive industry from inside. It is a miracle that cars work at all.
deleted 2y ago
[deleted]

Kye 2y ago

I thought early code was carefully validated on paper with flowcharts and review by someone else before you were allowed anywhere near an expensive CPU cycle.

MrGilbert 2y ago
Absolutely, yes. We had walls decorated with flow charts back in the day. (/s, just in case)
- deleted 2y ago
  [deleted]

boricj 2y ago

In software engineering, we only ever maintain processes, not artifacts. Software modularity when it exists is usually extremely coarse and rigid when compared to the malleability of electro-mechanical systems. Got a bug to fix or a feature to implement on a program? Modify the source code, run the build system, use the newly built artifact and discard the old one. Lose this process and you're screwed because the tooling for modifying an extant program is still in the Dark Ages. It's not just about proprietary software that has reached its end of support, given enough time almost any source code tree will bitrot past the point where rebuilding it will require a major overhaul. When you need to fix or customize a physical artifact like a coffee machine, you usually don't go inside the factory to change the blueprints and manufacture a new one. You just modify the one you have with standardized tools. It also doesn't matter how old the artifact is, even if it's decades out of production it can still usually be disassembled and put back together as if it was fresh out of the assembly line. The more software bleeds into electro-mechanical systems, the less repairable, versatile and hackable they become.

jiggawatts 2y ago
That's very insightful, and I just wish I had the ability to explain this to non-technical managers. "But it was working!" "Sure, 10 years ago, now I can't even find a version of Visual Studio that will install that can even open the project, let alone compile it."
- actionfromafar 2y ago
  And VS on an old laptop or Virtualbox might actually work, still. Good luck recreating some random services tangle from the year 2024 in 2034.
  - jiggawatts 2y ago
    Since Visual Studio is Windows only, the straightforward solution that I used was to install an old version in a Hyper-V virtual machine. Then it's a multi-step process where the project is upgraded inside the VM with an ancient VS copy as "far as it'll go", then copied out to the external environment with VS 2022 that also has the 2016 and 2019 "Build Tools" installed. Then the projects can be upgraded to "current day". In some cases I just gave up and created new empty projects with identical names and GUIDs, then copy-pasted the code files across. It can be simpler and faster.

m3047 2y ago

History doesn't repeat, it rhymes; and it kind of goes in phases or epochs. As Derrida was wont to point out, we show up in the middle of things, just flippantly speaking a language and carrying on as though the language was something we were born with and it's been the same forever because we only know our own "forever". I popped my cherry on VAX silicon, where stack frames were baked into the silicon. This meant that regardless of language, the stack architecture was a target for the compiler not something it constructed. I fell into the middle of things: VAX silicon was new, and people wrote in e.g. COBOL, FORTRAN, BASIC, Pascal, C because they'd successfully done so before and had libraries and practices which had stood the test of time and had made the jump to successfully infect a new species of silicon. The successful colonizer libraries and practices had certain rules. "You can't manage heap in BASIC" for example, or that modular compilation units all had to be written in the same language. This is not and never was strictly true, and the people writing code knew it; but it was true enough for code which jumped silicon. I on the other hand knew about the silicon stack, and could implicitly understand some of the more esoteric compiler pragmas for dealing with that stack (intended for cross-language linking support) and so by disabling certain linker checks and abusing compiler pragmas I could do e.g. memory management in BASIC by isolating the compilation unit where "memory is an array" from the one where "a memory address is an integer" and explicitly telling different lies with compiler pragmas in each. Fast forward a few years and everybody had learned HTML and then I'm confronted with somebody wanting me to fix a steaming basket of soup machine gun sprayed into different files all with "(c) Macromedia" in them. "Where's your no-code tool which generated this?" I innocently ask. "Wuuut?" is the response. Yea well when you find it, let me know. Let's just say the people who have to fix things like that probably get paid good money and the solves they come up with are comparatively fragile, that code will not (and did not) survive; any more than my silicon-aware hacks (which I was paid quite well for) for VAX will work on modern silicon. Where's all of that shitty VB Wizard code spew? Thankfully gone. Some of these integrations will not be fixable, but some of the subsystems will survive, and it might be simply because there is no security and it's possible to replay CANbus reliably as a result.