undefined | Better HN

0 pointsdgb234y ago0 comments

I’m from the modern web dev generation so to speak, but just yesterday had an amazing conversation with my dad, who did what you describe.

He explained to me what a “patch” actually means, or meant back then. He was talking about debugging and implementing loaders for new hardware and such, then he mentioned a “patching area”, I asked wtf that means and apparently the release cycles then where so slow, that a binary left some dedicated space for you to directly hack in a patch. He then would change the machine code directly to jump to the patched area so he could fix a bug or extend the behavior.

Contrast this to the arguably wasteful CI/CD setups we have now.

0 comments

4 comments · 1 top-level

mwcampbell4y ago· 3 in thread

> Contrast this to the arguably wasteful CI/CD setups we have now.

To clarify, are you arguing that modern build and release processes should patch binaries in-place, or something else?

benreesman4y ago

As a kind of middle-ground: CI/CD burns our abundant cycles out of band. That’s a good place to spend extravagantly.

I’m all for burning more cycles on tests and static analysis and formal verification etc. before the software goes on the user’s machine.

But we all live every day with “good enough” on our machines every day. I think there’s a general consensus that too much software spends my CPU cycles like a drunken sailor.

int_19h4y ago

It's also the question of what the burned CPU cycles actually buy. Cycles burned on testing buy us less buggy programs. Cycles burned on your CPU that do stuff like out-of-bounds checks or garbage collection also do that.

But most of them are burned on layers upon layers of abstraction that do not actually do anything useful safety- or correctness-wise; they're there solely because we've turned code reuse into a religion. Which wouldn't be bad by itself, if that religion had a firm commandment to not reuse bad solutions - yet that is exactly what we keep doing, again and again, patching it all with the software engineering equivalents of duck tape and glue to keep it all from falling apart. Why is C still at the bottom of virtually every software stack we run? Why do we keep writing desktop apps in HTML/JS? Does a simple app really need 20 dependencies of uncertain quality?

JavaScript is a good example. It's not a bad language because it's high-level - to the contrary, that's the best part of it! It's a bad language because, despite being high-level, it still gives any user ample opportunities to mess things up by accident. We need something just as (if not more) high level but better for general-purpose software development.

1 more reply

dgb23OP4y ago

I’m not arguing. Just observing the difference. Different times, different needs and practices.

For example back then it was common to understand the whole machine code of a binary in total. We’re talking no abstraction, no runtimes. Portability and virtual memory were luxuries.

I definitely think CI/CD could be less wasteful, but I don’t necessarily think we should manually patch binaries in place.

j / k navigate · click thread line to collapse