FTL light and EM waves are invisible

I had in mind the following setup.

Computer A -> FTL transmitter A -> FTL receiver B -> Computer B

Computer B -> FTL transmitter B -> FTL receiver A -> Computer A.

The computers are under the control of the independent evaluator.

Computer A generates messages, encrypts them, and hands them to the FTL communication system. On receipt, computer B decrypts them, transforms them in a regular way, reencrypts them, and hands them back to the FTL communication system. On receipt, computer A decrypts them, checks that message corresponds to what was sent, and determines the roundtrip time. If that time is less that the shortest possible lightspeed roundtrip time between the computers, then the evaluator is convinced.

With such a scheme, the evaulator cannot argue that the messages have not really made the trip, nor that they really took longer than they appeared to.

Of course, in the (expected) case of failure, and in line with known behaviour of proponents of FTL schemes, free energy schemes, psychic phenomena, and so on, the failure will not be recognised by the proponent as evidence that the idea is fundamentally flawed, and they will go away and shortly come back with a variant that they inist be independently evaluated again. When, after repeated failures, the independent evaluators decide they don't want to waste any more of their time, the proponent will cite that as evidence of a conspiracy to prevent their technology seeing the light of day, in order to protect big business and governments from the consequences.

Sylvia.

Both. With the partial exception of interface definitions, specs are just a kind of wish-list. It's frequently the case that only when one writes the code does one realise that the spec is deficient, ambiguous, or both.

Sylvia.

So, you are mostly a programmer who insists on defined interface requirements (specs, sort of)?

Would you like to discuss this privately? I can give you an email address.

John

Jamie, I had some respect for you until that post. There was no call for that.

If you don't like me, that's fine. But I think Sylvia deserves more respect than I.

John

Yeah, sort of. My problem has been gathering the information that the "client" thinks is germane to his needs. Most of the time, he thinks he wants something when, in reality, he really wants something else. You would think that pinning all that down would resolve the problem. It doesn't always work that way.

Enough. I could go on forever.

John

More like that I'd be defining interfaces, but implementing at least one side of them, which would feed back into the definition where problems were exposed.

I think I'll pass on that, sorry. I prefer to keep discussions on Usenet.

Sylvia.

Would that be background or backside? I get confused at times!

Jamie

Okay, I understand.

Cheers, John

You seem to know a lot of electronics and physics for a software engineer. I usually have to write a pretty detailed spec, with math rules, algorithms, pseudocode, stuff like that, to get realtime signal-processing sort of code written. I could almost (almost!) do it myself faster.

I think a lot of people get degrees in software engineering without learning much math.

John

I like to cover the bases :)

My computer science degree involved a combination of hardware and software elements, though the electronics side is now thirty years out of date.

I confess that my math is not as strong as I'd like. If I do something with a math component, I have to read up on the relevant area, and it no doubt takes me multiples of the time it should.

Sylvia.

With a bit of practice you probably could actually do it faster.

It's a standard problem in software engineering - the managers always want the project divided up into subtasks so that it can be done in less elapsed time. Frequently doing that just has the opposite effect.

I remember years ago being told that a new member had been added to the team, and asked how we could best use him. My response was that the best thing to do was to sit him in a corner reading a book. This idea was not well received.

I was right though. His work was useless. I ended up having to redo it all over a weekend.

Sylvia.

Writing test code is sometimes a good use for another person.

They try things that "smart" users wouldn't do. They can also find bugs or missing sections in the documentation.

I find it funny that it is so easy for you to trap the idiots, even if that was not the intent.

Yet another stalking, retarded bastard.

She has more on the ball than a retarded little punk like you does.

Jamie is a low grade troll with a ham ticket. Take a look at his website for proof. Maynard A. Philbrook's call is: KA1LPA

Goddamned retard trying to steal folks' ways and means.

Fuck off, Johnny.

An understatement to the max.

You deserve public stoning.

She deserves to be left alone by the likes of a retarded f*ck like you.

It's called a requirements analysis, you stupid fucktard.

You do not meet any of the requirements.

I would never contract with a pathetic fucktard like you.

A stalking, retarded f*ck like you understands nothing.