Hacker News Reader

Comment by bilekas | Hacker News Reader

> if NASA wanted to send control signals like transmit on and off, they’d need to run a whole parallel set of wires, which would be expensive. So, they came up with a solution: use the same lines for control signals as well!

It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.

Maybe I have rose tinted glasses, but the level of creativity and cleverness seen in old solutions to problems/challenges just blows my mind all the time.

View on HN

I agree that it seems like engineers of the past were more clever than us today, but I suspect that we feel that way only because a lot of the garbage systems and code have been lost to time. The good stuff gets immortalized and passed down, while the bad stuff isn't, much in the same way that nobody will see my hacky Python scripts in 30 years (with any luck). It's a selection bias.

See also people who are convinced they were born in the wrong time period. Much more annoying that you or me, I'd say, but the same principle nonetheless.

> much in the same way that nobody will see my hacky Python scripts in 30 years (with any luck)

LOTS of us have seen legacy systems long outlast their intended lifespan. I've seen this in enterprise settings, web development, small business, etc... I've got multiple custom web solutions (niche industry product catalogs) I developed in my early 20's that are still going strong 10-15 years later. The code behind them is dated and god awful, but if/when you talk to the client it's the "don't fix what's not broken" mentality.

Due to this experience I've learned to document the hell out of my projects because of really positive feedback from developers who have had to support/modify my work down-the-road. Docs can be a lifesaver in a less-than-ideal situation.

Just sharing my anecdotal experience of "holy cow that's STILL LIVE?!" and, "here's a DB2 mess from the late 80's ... figure it out kid." =)

"It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today."

We still use the same system today: most ham radio repeaters are triggered (and can be remotely configured by the owners) through audio tones; also most license free radios implement subtone codes (ctcss) to trigger the audio output when a radio with the same code is transmitting. The idea is that people wanting to talk each other use the same code so that they won't listen to transmissions by others. The system works as intended but is flawed by giving a false sense of privacy when users think others won't be able to listen to their conversations just because they use that code, which is false as there is no proteciton at all: the code is merely used on the receiver to voluntarily squelch off the audio when the same code isn't provided by the transmitter, but anyone with a receiver not using codes can listen to them.

Inband vs out-of-band signalling is one of those great debates in telecoms. You can see it in RS232 as well, with "XON/XOFF" characters versus "RTS/CTS" extra signalling lines.

Most internet protocols are "in-band", but there are two big exceptions in FTP and SIP, which is very much an internet protocol designed by phone people.

> SIP, which is very much an internet protocol designed by phone people.

Allegedly SIP is much better than the ITU's H.32x standards, and if that is true, then H.32X has to be an unspeakable horror.

SIP is only a speakable horror when you have RTP payload types in common, note. (-:

H.323 is the internet protocol designed by phone people, SIP is prime example of second systems effect caused by internet people trying to make it “more internet-ish”.

The reason why H.323 is “unspeakable horror” to internet people is mostly about it being built on top of existing practice of telco signaling, so: global titles instead of URIs and ASN.1 PER instead of HTTP-style (in case of SIP arguably overly verbose and complex) text messages.

Edit: and IIRC there is significant user experience difference caused by that: H.323 supports the traditional telco style Initial address/Subsequent address/Address complete dialing, while SIP works in terms of complete SIP URIs and the user terminal has to somehow divine that the dialed number is complete.

> while SIP works in terms of complete SIP URIs and the user terminal has to somehow divine that the dialed number is complete

I've never used a softphone that doesn't have an explicit Call button. You're telling me that there are terminals where people can just pound SIP URIs in one character at a time, and the call will just decide to initiate at some point?

That is how the normal POTS phone works and there is some expectation that physical SIP VoIP phone would work in same manner. For the VoIP phone the usual implementation is that the hardware SIP phones have configurable regular expression that describes all possible complete numbers and configurable dial timeout. Getting this to work reliably is somewhat intractable problem, while with H.323 or Cisco SCCP phones it just works. For SCCP because the phones are more or less dumb terminals and with H.323 because the signaling protocol is designed with this in mind.

On the other hand desktop phones are today mostly used in office environments, where essentially everybody today enters number first and then does some action that signifies that it is the complete address (pickups handset or enables speakerphone)

Edit: motivational example: suppose that random person pick ups random SIP phone and punches in 1-1-2 (or 9-1-1), then reasonable expectation is that the phone somehow divines, that what the user really means is 112@sip.exapmle.com(or 911@...) and immediately sends the INVITE, getting it to work that way for arbitrary numbers is somewhat nontrivial.

The creativity and cleverness is still there. It's just being applied differently.

That kind of insight is very "clean" when it's being applied at the level of bare wires, or to code crammed into tens of bytes. It's harder to see when it's part of a large app or extensive system, but it's still there.

Developers today are neither more nor less clever. The solutions they come up with every day are just less broadly applicable, because the broadly applicable ones are either low-hanging fruit long since picked, or unnecessary drains of developer time that are better spent solving more domain-specific problems. Forty years ago I'd admire a programmer who could cleverly eke out a few bytes per record, but today (in most circumstances) I'd fire them for making their code less flexible and harder to maintain.

I hear you, thanks too, I like to think we have better tools for the job, and that we do apply it by learning from the past.

So my original OP should be rephrased: Thank god we learnt and are still learning creative ways to make things work.

Inband signalling was the way long distance trunk lines worked back in the MF signalling days decades before ISDN D channels and SS7 and all that.

A fun topic to google for is what and how the 2600 Hz signal worked.

Didnt some guy figure out how to get free phone calls using a cheap whistle from a cereal box :-)

Captain Crunch!

John Draper

https://en.m.wikipedia.org/wiki/John_Draper

And Wozniak had his blue boxes

The book "Exploding The Phone" goes into all of these stories and much more. If you ever wanted to know about how and why the analog phone system was so hackable/phreakable, this book is for you.

[0] http://explodingthephone.com/

Wow, don't know how I missed that book. Looks great!

Yes, that's the most famous application. As to why it worked...that's the more interesting story IMHO.

You say that, but phone phreaking was possible because of in-band signaling. People back in the day had much the same tradeoffs we did; by necessity, they just came down on the side of less security / less portability / less reusability.

I wanted to echo this.

NASA would not have used this technique of they had today's signal proccessing/bandwidth/resources. They used these clever tricks because that was the only option.

These clever tricks have major downsides. They are more fragile and easier to get wrong. Just like code today, the most clever code is often the least maintainable.

> It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.

Naw. We just use our ingenuity to solve higher level problems. Or more precisely use it to solve the “actual problem” trying to be solved and not incidental problems caused by not being able to work at the right level of abstraction.

Mumble mumble Mythical Man Month and “no silver bullet”. There will always be the “real problem” to solve. It is just over time our level of tooling will let us focus more and more on solving the problem itself instead of tooling problems...

> It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.

Nowadays we would just NPM install a few gigabytes of shit (and some backdoors & malware for good measure) and call it a day!

Modern EE is full of clever tricks like this, just a lot less about cost because it's marginal but for very subtle things like DFM, reliability, etc... Just look at a mass manufactured board like from Apple or Samsung. Shit is fucking whack, yo.

When I first started getting into Arduino type systems, I was concerned about the limited number of inputs. After studying other designs, I saw a simple method of making each pin capable of accepting multiple inputs. Each input had a different resistor attached so that the voltage from each input/button was unique on that pin. Very simple/basic solution, but still creatively done nonetheless.

  It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.

I think that's the wrong way to look at it. There are a few factors at play here. One is selection bias (there was a lot of crap written then too).

More importantly though, "ingenuity" is somewhat a limited resource. If your systems are highly constraining, you burn a lot of it on working around the constraints. It can be clever as hell, but also means a lot of other stuff couldn't be done.

Also, there are vastly more people working in the area now, with the corresponding regression to the mean.

In addition to what else has been said, we have more ready-made solutions we've converged on, which pushes the scope for creativity higher in the stack. For example, we don't have to hack up a low-level communications system because we can just put JTAG parts on and use something everyone understands. We don't have to figure out how to allow multiple users to share the same network without stepping on anyone else's toes because we have TCP/IP and decades' worth of cleverness poured into things like creating a transparent, securely-encrypted tunnel over that protocol suite.

So our cleverness is inside the applications, getting stuff at the top of the stack to do things it wasn't intended to do by combining relatively high-level pieces. I've done that, I'm sure a lot of us here have done that.

It's like the old code: creativity and cleverness everywhere. But with each new generation some things get standardized.

If there is a more effortless way to do it, it will be done this way. It's getting interesting when there is no such way because the problem is at the edge of our current capabilities. If I wanted to search for ingenuity and creative solutions, I would start at the cutting edge or maybe even moonshot projects.

Some massproduced parts also contain a fair bit of ingenuity in their circuitry, though usually of the "they summoned Satan just so they don't need this $0.02 part" type of ingenuity.

Ironically future generations will likely look back now and wonder of our cleverness.

Now that you mention it, my little nephew could not wrap his head around how we used to not have mobile phones, and even when we did, we used to only use SMS and MMS for more expensive bills, and we even had emojis !

This is the way the telephone system worked while eliminating human switchboard operators. In-band signaling is what allowed the phreaks of the 60s and 70s to do what they did.

I mean, this is not particularly clever or creative. It's just a really straightforward solution to a simple problem.

Modern wireless microphone transmitters are configured and updated via audible tones generated by a smartphone app.

In-band signaling was the norm until the early 80's.

Reply on news.ycombinator.com