Google is gonna get this done!!!!

I thought the article was pretty clear that this is not a Google enterprise. Both companies are private ventures by Page.

He seems to want to be "The Elon Musk of Airspace" :)
 
MIT engineers have been working on Terrafugia for over a decade and still haven't sold an airframe.
 
MIT engineers have been working on Terrafugia for over a decade and still haven't sold an airframe.

They don't have the bottomless pit of money available to them the Google-type wealth can provide.

The calculus for this type of work is quite different when there are essentially no investors to answer to and little to no intention of making money in the end (e.g, the entire development cost is intended to be written-off from the get-go).
 
Going to take a very creative approach, more creative than Terrafugia's, to avoid ending up with an outcome that isn't a very good car and isn't a very good airplane. That's pretty well been the experience with these flying cars through the decades.
 
MIT engineers have been working on Terrafugia for over a decade and still haven't sold an airframe.

How long have Teacher's been teaching? I still see stupid people. Hahaha.

Kidding of course, but it's a bit of a non-sequitur.

In reality, I've personally rescued two production computer/telecom systems from utter failure that were designed by MIT engineers. There's a distinct difference between design engineers and field engineers who make something actually work, sometimes. They were designed "by the book" and the real world doesn't read the book. Ha.

Which probably applies to that whole "stupid people" thing in some ways, too. Haha. There's Teacher's in classrooms, and then there's mentors in practical application... Heh.
 
How long have Teacher's been teaching? I still see stupid people. Hahaha.

Kidding of course, but it's a bit of a non-sequitur.

In reality, I've personally rescued two production computer/telecom systems from utter failure that were designed by MIT engineers. There's a distinct difference between design engineers and field engineers who make something actually work, sometimes. They were designed "by the book" and the real world doesn't read the book. Ha.

Which probably applies to that whole "stupid people" thing in some ways, too. Haha. There's Teacher's in classrooms, and then there's mentors in practical application... Heh.

And is also an indictment of the people who wrote the book.

I've profited greatly from information from books. But it's no substitute for real world experience.

John
 
And is also an indictment of the people who wrote the book.

I've profited greatly from information from books. But it's no substitute for real world experience.

In this case, not really, but I know what you mean.

The "book" in these cases was the ITU specifications, which really don't aim to document all of the real world odd-ball stuff that carriers and equipment manufacturers actually do in signaling, they just define the base signaling.

On one of the products, the interaction between in-band signaling and sending all of the same bits in all timeslots ( conference calling ) was the problem.

The short version is: If you would pick up a microphone and whistle into a conference bridge using in-band alarm signaling on its T1 circuits, you'd hit and hold a tone that would hit and hold the second most significant bit across all 24 channels of the T1 for long enough for the far-end to register that as a Yellow Alarm. Response to Yellow Alarm (at that time) was undefined in the ITU spec, but most carriers would instantly disconnect all DS0s and reset the span.

So basically... You couldn't use a non-ESF span for conference calls unless you could guarantee you wouldn't put 24 channels of the same conference call on the same span simultaneously, or you'd randomly lose 24 people from the conference when someone's voice triggered the right bits.

Actually you could lose multiple spans simultaneously.

Goldman Sachs and other large investment houses didn't like it too much when people were falling off "important" conference calls in multiples of 24. Haha.

Temporary solution: Take one of the channels off-hook on every span and disable using it (waste of a channel, but cheaper than ticking off financial customers) so you'd never get all 24 second most significant bits set to 1 from sounds in the conference call.

Long term solutions: Only use out of band signaling on T1s used for conference call bridges. You couldn't guarantee you still wouldn't end up with 24 inbound callers for the same call on a span, so algorithms to avoid sharing the span would only work on out-dialing bridges only.

I was the 20 year old kid who had to prove this was happening... We really ****ed off Sprint that day, triggering hundreds of alarms on their Cheyenne, WY switch... Haha. They called our NOC and asked WTF we were doing! LOL. I'd found that whistling would trigger it way faster than singing or talking... Significant bits being what they are in a u-Law digitization scheme...

High pitch and loud... Whistling worked great. It also explained why our largest complaint stack came from a conference call who had a squeaky high pitched girl for the chairperson...
 
In this case, not really, but I know what you mean.

The "book" in these cases was the ITU specifications, which really don't aim to document all of the real world odd-ball stuff that carriers and equipment manufacturers actually do in signaling, they just define the base signaling.

On one of the products, the interaction between in-band signaling and sending all of the same bits in all timeslots ( conference calling ) was the problem.

The short version is: If you would pick up a microphone and whistle into a conference bridge using in-band alarm signaling on its T1 circuits, you'd hit and hold a tone that would hit and hold the second most significant bit across all 24 channels of the T1 for long enough for the far-end to register that as a Yellow Alarm. Response to Yellow Alarm (at that time) was undefined in the ITU spec, but most carriers would instantly disconnect all DS0s and reset the span.

So basically... You couldn't use a non-ESF span for conference calls unless you could guarantee you wouldn't put 24 channels of the same conference call on the same span simultaneously, or you'd randomly lose 24 people from the conference when someone's voice triggered the right bits.

Actually you could lose multiple spans simultaneously.

Goldman Sachs and other large investment houses didn't like it too much when people were falling off "important" conference calls in multiples of 24. Haha.

Temporary solution: Take one of the channels off-hook on every span and disable using it (waste of a channel, but cheaper than ticking off financial customers) so you'd never get all 24 second most significant bits set to 1 from sounds in the conference call.

Long term solutions: Only use out of band signaling on T1s used for conference call bridges. You couldn't guarantee you still wouldn't end up with 24 inbound callers for the same call on a span, so algorithms to avoid sharing the span would only work on out-dialing bridges only.

I was the 20 year old kid who had to prove this was happening... We really ****ed off Sprint that day, triggering hundreds of alarms on their Cheyenne, WY switch... Haha. They called our NOC and asked WTF we were doing! LOL. I'd found that whistling would trigger it way faster than singing or talking... Significant bits being what they are in a u-Law digitization scheme...

High pitch and loud... Whistling worked great. It also explained why our largest complaint stack came from a conference call who had a squeaky high pitched girl for the chairperson...

Oh yeah. I love doing things like that to prove what's really happening.

It's not so dramatic, but I was writing SCSI tape drivers in a previous life. We were acquired by then Archive (not a bad company) and I was put to work on their QIC drives. The Adaptec SCSI controller would poll the drive with a Test Unit Ready request over and over while the drive was rewinding (which is technically legal but stupid). The QIC-150 (150MB) drive only had one processor and the firmware prioritized the SCSI port over the beginning of tape optical sensor. Every time it tried to rewind, it wound the tape off the spool. I figured out what was wrong with a SCSI analyzer and told the firmware team. Fast forward a year and the new high density QIC-525 drive showed up. One of the first tests I ran was the rewind test. It worked fine with a 525MB tape. Cool. But the drive also had a 150 compatible mode. Being the suspicious/perverse sort I was, I tried the test with a 150MB tape. Rewound right off the reel. They had lifted the code intact from the earlier drive for the "compatibility mode".

Several of the firmware guys stopped taking my calls after that one...

John
 
Oh yeah. I love doing things like that to prove what's really happening.

It's not so dramatic, but I was writing SCSI tape drivers in a previous life. We were acquired by then Archive (not a bad company) and I was put to work on their QIC drives. The Adaptec SCSI controller would poll the drive with a Test Unit Ready request over and over while the drive was rewinding (which is technically legal but stupid). The QIC-150 (150MB) drive only had one processor and the firmware prioritized the SCSI port over the beginning of tape optical sensor. Every time it tried to rewind, it wound the tape off the spool. I figured out what was wrong with a SCSI analyzer and told the firmware team. Fast forward a year and the new high density QIC-525 drive showed up. One of the first tests I ran was the rewind test. It worked fine with a 525MB tape. Cool. But the drive also had a 150 compatible mode. Being the suspicious/perverse sort I was, I tried the test with a 150MB tape. Rewound right off the reel. They had lifted the code intact from the earlier drive for the "compatibility mode".

Several of the firmware guys stopped taking my calls after that one...

John
Oh boy, that brings back (more recent than I'd like) memories.
A co-worker came by one day to tell me that the company server is offering SW updates to customers who don't have certain SW. I told him they need to fix the DB on the server and it will stop offering the SW update. Logical and simple, right?
Well, not to our management.
"We cannot touch the server", they claimed. From talking to them, it quickly became apparent that they had no idea how the server works (PFM, I tell ya) so they were afraid to touch it. Pure fear in their eyes.
They mandated that we fix it in our SW. I told them repeatedly that our SW did not have a problem. That the server was sending our SW to customers who didn't need it. My team (the a**-kissers they are) was gung-ho over implementing a "fix" in our SW. No amount of logical reasoning helped. The decision from higher up was that since my team is capable of fixing it "on the SW side", they started working on a "work-around" which entailed changing versions everywhere to make sure that the SW that eventually ended up on the customer's computer did not match what the SW offered by mistake.
Long story short (too late, right?), after a week of coding and making horrific changes to a product that was not broken, word came (quietly) from above that the server has been fixed and there is no more problem. How did my team react? "Um, we wish they had told us earlier that we did not need to fix this". How do you spell "1D10T"?
My team is full of smart people (when it comes to expertise) but many of them just don't have the logical thinking required for smart decisions. I expect boneheaded decision from the management but engineers should be smart, right? Right?

Now how in the heck did we get to boneheads? :D
 

I thought you were talking about this.

I did briefly wonder if that was the topic of the thread also.

Interesting analysis online about that article. Apparently Google censors / de-values "negative" words in searches. A search for similar under Bill Cosby's name also doesn't show articles about his indictment.

Bing has no such filter and works better overall when searching for anything "negative" apparently, after a lot of testing by a lot of people in response to the above article.

So it's consistent, and unlikely to be a bias toward a particular candidate, but Google wears rose colored glasses that with their size and scope may quite likely have, ironically, a negative effect on the real world. Cool how censorship ALWAYS bites the implementer in the ass eventually, if you ask me. It's so rare that it doesn't harm the credibility of the censors, when it's applied.

As a techie, I'm not sure attempts to limit searches by a perceived or made up values system about the words used, is a good idea at all. But it does seem very "California-ish", that's for sure. Which matches Google's home and likely the mentality (and perhaps blinders) of their developers.
 
I did briefly wonder if that was the topic of the thread also.

Interesting analysis online about that article. Apparently Google censors / de-values "negative" words in searches. A search for similar under Bill Cosby's name also doesn't show articles about his indictment.

Bing has no such filter and works better overall when searching for anything "negative" apparently, after a lot of testing by a lot of people in response to the above article.

So it's consistent, and unlikely to be a bias toward a particular candidate, but Google wears rose colored glasses that with their size and scope may quite likely have, ironically, a negative effect on the real world. Cool how censorship ALWAYS bites the implementer in the ass eventually, if you ask me. It's so rare that it doesn't harm the credibility of the censors, when it's applied.

As a techie, I'm not sure attempts to limit searches by a perceived or made up values system about the words used, is a good idea at all. But it does seem very "California-ish", that's for sure. Which matches Google's home and likely the mentality (and perhaps blinders) of their developers.
That's interesting and important. Censorship is not a survival skill in the long run, IMO, because negative stuff that remains undiscovered can't be fixed. If you run across that analysis again, I'd appreciate a link.
 
That's interesting and important. Censorship is not a survival skill in the long run, IMO, because negative stuff that remains undiscovered can't be fixed. If you run across that analysis again, I'd appreciate a link.


I went and tried to follow the path that led to it (Started with a FB post about the article and then comments on the post had links) but I haven't found the breadcrumb trail yet.

I kinda don't care. The analysis of whether or not our two biggest parties are totally corrupt is water under the bridge at this point, and that's more of an effect on the outcomes than the search engine, since we shouldn't have the scumbag candidates we have, anyway.

Whether a search engine could mess with things, once we have the approved scumbag list, even inadvertently, is also pretty obvious. But who cares?

The country wants Larry, Moe, and Curly.

I just thought the thread was going to break the political rules here because I read that article about two hours before and the title made me think of it. Sorry to digress into a censored topic.

Back to something PC and unimportant now... Almost got real there for a second, and we can't have that! LOL!
 
It seems to me that that behavior of the Google search engine has societal implications that go well beyond who gets elected president.
 
That's interesting and important. Censorship is not a survival skill in the long run, IMO, because negative stuff that remains undiscovered can't be fixed. If you run across that analysis again, I'd appreciate a link.
So I can't interest you in a pair of Somebody Else's Problem Glasses?
 
Back
Top