Jihad needs scientists

In article <esurfc$ds3$6@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esu74a$8qk_001@s861.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esrtcj$qj4$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum still
works. If you wrote the TAPE.DIR before the other files and never changed
it, my method still works.


[....]
Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all written?

Yes. TAPE.DIR was created after the files were written to the tape.
That is how you get a directory listing of the tape onto the tape.

The first cut of the tape had a zero block TAPE.DIR for a place holder
on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done.
Then another save was done; this time TAPE.DIR that was on the
tape contained a checksummed directory of the tape.

In other words, you "editted" the tape.

No.

You wrote one file and then wrote
something different in its place.

No. I wrote the whole save set. In magtape terms, the saveset
was the file on the tape.

Given this, the method of making the checksum of TAPE.DIR is done very
easily. I have already explain how several times.

I know you've explained ad nauseum. You keep ignoring the point
of the file. IOW, you implemented something that wasn't in the spec.
In fact, your implementation is 100% contrary to the spec.

I don't think so. You objected to opening it for writing. This means
that you only could have put it onto the tape before the others. You must
therefor have known what you intended to write. You also would have
checked when you were done that you really had written what you intended.
If what you actually wrote did not match what you intened to write, you
would have taken some action. Most likely you would make a new tape.

A second save exercise had to be done. Howver, the checksum of
the file TAPE.DIR in the file TAPE.DIR would never be correct.
We could live with that. It would not generate any SPRs nor
create problems in the field.

As I explained, the claim that it can't be correct it wrong. The method I
explained makes it correct. There is no problem.

But you don't fulfill the requirement that the file is a
directory of the tape, untouched by editing hands.

No, what I suggested solves the problem you had cleanly and without adding
any problems. You just seem not to be able to grasp what it does.

I know what it does. And the solution would cause more problems than
it fixed. If your solution was the only one, I'd punt the idea.

You don't seem to be able to understand the idea so yes, I guess you would
punt the idea. leaving the tape incorrect and your customers at an extra
risk.

Nobody assembled the file called TAPE.DIR. It listed the files
that were on the tape when we made the master. If the tape
they received didn't match the ones listed in the file, then
they knew they got a bum tape and could alert us that our
manufacturing process has a problem. It was quite possible
that SDC (software distribution center) had an order of tapes
that were a lot less than 2400'. If the master was longer than
the physical lenght of those tapes, then customers would get
a distribution that didn't have the end of the save set.
Not putting a directory of the tape onto the tape would create
risks.

[....]
Nothing I suggested would result in that. The net result of what I have
suggested is one line of text in the TAPE.DIR file if it is an ASCII text
file and an extra byte if it is binary.

Since the medium is a magtape, inserting one tiny bit would make a
mess of the save set and cause it to not be restorable.

No, it would not, You just need to think about what I really said. When
you first made the tape, you left a gap for the file.

No, there is no gap.

You then write this
file after. Before you write this TAPE.DIR, you think for about 3 seconds
and then write a TAPE.DIR that is completely correct instead of one with
an error in it.

You do not understand how tapes and savesets worked.

This
was the master cut of the tapes that would soon be made to ship
to all customers. It had to be perfect and copyable.

..... and yet you shipped it with a mistake on it.

Yes. It was an error that was acceptable. The error had no
side effects. Not shipping the file would have caused expensive
side effects.

This means it was not
perfect at the instant you created it. The checksum was wrong because you
didn't think for about 3 seconds.

I thought about this problem for months before I decided that it
was OK to have one 36-bit word incorrect on that tape. I've thought
about the CATCH-22 problem often since then because those
are neat puzzles.

Another trick that had to done was to save files to tapes that
had been physically logically "shortened". That was done by
moving the silver strip to make a "short tape".

This has nothing to do with the question at hand. The strips on the ends
of tapes were moved on ones that were being used as scratch. You would
never do this on a production tape.

We had to do this on a master tape. You simply have no concept
of the problems in a manufacturing environment when the products
produced were OSes and the computers they were installed on.

[..........]
Once again what you are saying contradicts what you suggested earlier.
You had to check that you really did put onto the tape what you intended
to put onto the tape. My method makes no change to that requirement.

Your method does not put a director _OF_ the tape onto the tape.

Yes it does! You can do exactly all the same steps as what you did plus a
very small amount of thinking and get it right.

No, it doesn't. Your method says what we think it should be like.
That is very different from what it really is like.

[....]
WRONG! You have always been able to edit magnetic tape. You can't cause
the lengths of things to change but you can overwrite a file with one of
the same size.

But it isn't the same size. You cannot predict the size of any
record on a magtape.

You wrote something onto the tape called TAPE.DIR. I have not suggested
anything that makes its size change in anyway that you did not have.
Either you knew before hand its size or you didn't.

I didn't know because the magtape had not been made yet.

I assume you did
because you had to write something to take up that much space. Nothing in
what I suggested makes that any sort of a problem.

The first TAPE.DIR on the tape was a zero block file.

[....]
Hardly new. Reel to reel tape isn't used much anymore. Even very stone
aged reel-to-reel drives like the Kennedy 9700 could do it. You being
unaware of this contradicts statements you made earlier.

I was never aware that the purpose of IRGs was so a human could
edit directly to the tape.

We are not talking about humans doing things we are talking about what
computers could do.

Humans made everything. Humans told the computers what to do.

Yes! THat is the only way to get a directory of the tape.

Then as I have explained, the method works the checksum did not need to be
wrong.

YOur method does not provide a directory of what is on the tape.
The whole point was to document what was on the tape when we made
it.

/BAH

 

In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esu5ct$8ss_001@s861.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esrqvn$n5i$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines.

Why? Most user machines are used essentially as end nodes, especially
the systems used as a TTY hosted into an ISP. These should never
be doing routing. Contention and pathway changes are too high
and would be a waste of overall routing CPU time to deal with.

You have only stated the current situation and not what it could be in the
future.

In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.

It's easier to fire wall also.

The way things are evolving, the server/router/firewall will be just a
Linux box running software.

Yup. I know a bit god who is exploring methods with a goal of 100%
cracker-proof using the least amount of power: both man and
electric.

/BAH

 

[Ken Smith]

In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.



--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <45F38D27.F4D71457@hotmail.com>,
Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:

"nonsense@unsettled.com" wrote:

There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts.
The supply
voltage has to be less than that.

The EB breakdown is lower than that. This is why unused inputs that
needed to be held high sometimes weren't tied to Vcc.


--
--
kensmith@rahul.net forging knowledge

 

[nonsense@unsettled.com]

Eeyore wrote:

"nonsense@unsettled.com" wrote:


There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.


Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Graham

Just when I thought dumb donkey had run out of
stupid things to say.

 

[nonsense@unsettled.com]

Ken Smith wrote:

In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[....]

has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.


Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.

There are lots of well believed urban legends.

The constraint was 5V so choices
made from one development project to the next had to include
the old choices. Most projects had to think about backwards
compatibility and the parts and power that was available at the
time of planning. Then implementation was also determined by
the parts and resources available at the time of the implementation.
You can't make something that depends on a foobar existing at
the time of production. There is also the requirement that there
will be enough of the foobars so manufacturing the item
won't be held up.

 

[Ken Smith]

In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.

Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.

The constraint was 5V so choices
made from one development project to the next had to include
the old choices. Most projects had to think about backwards
compatibility and the parts and power that was available at the
time of planning. Then implementation was also determined by
the parts and resources available at the time of the implementation.
You can't make something that depends on a foobar existing at
the time of production. There is also the requirement that there
will be enough of the foobars so manufacturing the item
won't be held up.
--

--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
No, you are making the same mistake over and over. As I stated before, if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the method.

Then that TAPE.DIR was not made by taking a directory of the
tape. That was not the purpose of the file. If I had to do
it the way you suggested, I wouldn't put the file on the tape
since it would be a waste of tape space.

So now you are suddenly changing your story and saying that editing of the
tape was done. You really need to go back and reread what I've suggested.
I have pointed out that you could have gotten the correct checksum if you
had just thought for a minute.

[....]

I have tried to explain how but you just don't seem to be able to
understand the issue.

It is you who do not understand the purpose of the file. It is
made by taking a physical directory of the magtape and never
touched by human hands. The last was THE requirement.

I never suggested that the directory had to be touched by human hands.
You have made claims of being a developer. If you retract that claim then
perhaps we can say that you did the best you could do. If you don't
retract, you then have to admit that you could have shipped correct tapes
but didn't.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et0qsp$8qk_002@s776.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esurfc$ds3$6@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esu74a$8qk_001@s861.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esrtcj$qj4$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum still
works. If you wrote the TAPE.DIR before the other files and never changed
it, my method still works.


[....]
Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all written?

Yes. TAPE.DIR was created after the files were written to the tape.
That is how you get a directory listing of the tape onto the tape.

The first cut of the tape had a zero block TAPE.DIR for a place holder
on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done.
Then another save was done; this time TAPE.DIR that was on the
tape contained a checksummed directory of the tape.

In other words, you "editted" the tape.

No.

How yes you did. You did exactly the action called editing when speaking
of a tape.

You wrote one file and then wrote
something different in its place.

No. I wrote the whole save set. In magtape terms, the saveset
was the file on the tape.

Now what the heck are you claiming?

I know you've explained ad nauseum. You keep ignoring the point
of the file. IOW, you implemented something that wasn't in the spec.
In fact, your implementation is 100% contrary to the spec.

You seem to keep not being able to understand it, or the spec said "do it
wrong".


[....]

As I explained, the claim that it can't be correct it wrong. The method I
explained makes it correct. There is no problem.

But you don't fulfill the requirement that the file is a
directory of the tape, untouched by editing hands.

Yes, I do. At least if you are as you claimed earlier in the development
team.


[....]

You don't seem to be able to understand the idea so yes, I guess you would
punt the idea. leaving the tape incorrect and your customers at an extra
risk.

Nobody assembled the file called TAPE.DIR. It listed the files
that were on the tape when we made the master.

You earlier stated a command you typed to make the file. Are you a
noone??????


[....]

No, it would not, You just need to think about what I really said. When
you first made the tape, you left a gap for the file.

No, there is no gap.

You then write this
file after. Before you write this TAPE.DIR, you think for about 3 seconds
and then write a TAPE.DIR that is completely correct instead of one with
an error in it.

You do not understand how tapes

ROFLMAO

You were the one that didn't know.

This means it was not
perfect at the instant you created it. The checksum was wrong because you
didn't think for about 3 seconds.

I thought about this problem for months before I decided that it
was OK to have one 36-bit word incorrect on that tape. I've thought
about the CATCH-22 problem often since then because those
are neat puzzles.

You missed the obvious way to solve the problem. You thought it could not
be solved, even though at that time, it was very likely solved in nearly
every other shop on the planet.

[....]

This has nothing to do with the question at hand. The strips on the ends
of tapes were moved on ones that were being used as scratch. You would
never do this on a production tape.

We had to do this on a master tape. You simply have no concept
of the problems in a manufacturing environment when the products
produced were OSes and the computers they were installed on.

Your shop had flaky practices. That is all there is to it.

[...]

Yes it does! You can do exactly all the same steps as what you did plus a
very small amount of thinking and get it right.

No, it doesn't. Your method says what we think it should be like.
That is very different from what it really is like.

No, you missed the whole point. My method makes it correct. That is
correct in all the same ways as your method did plus the added one of not
making a wrong checksum. You have missed the central point and gotten
mixed up about what I was suggesting vs what I used in an example to try
make it clear to you.

Go back and reread. The example I did earlier or the one I did just a day
ago. Look at how it worked. Understand that one little thing and then
maybe the light will come on.

[....]

You wrote something onto the tape called TAPE.DIR. I have not suggested
anything that makes its size change in anyway that you did not have.
Either you knew before hand its size or you didn't.

I didn't know because the magtape had not been made yet.

So, you didn't know the size. The suggested method still works. There is
no reason to ship tapes with an incorrect checksum.

I assume you did
because you had to write something to take up that much space. Nothing in
what I suggested makes that any sort of a problem.

The first TAPE.DIR on the tape was a zero block file.

This is an interesting change to what you said earlier. If the TAPE.DIR
was at the front of the tape and was not already the length needed, then
you could not write the TAPE.DIR in its place.

You had to:

(1) Write a new tape.
(2) Overwrite this tape.
or
(3) Not put the TAPE.DIR at the start.

We are not talking about humans doing things we are talking about what
computers could do.

Humans made everything. Humans told the computers what to do.

Squirm squirm.


[....]

YOur method does not provide a directory of what is on the tape.
The whole point was to document what was on the tape when we made
it.

Yes, it does. You haven't understood what it is. Until you stop assuming
that I somehow didn't put the right things on the tape, you will not catch
on.

--
--
kensmith@rahul.net forging knowledge

 

[MassiveProng]

On Sun, 11 Mar 2007 15:57:08 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) Gave us:

In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.

Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.


The constraint was 5V so choices
made from one development project to the next had to include
the old choices. Most projects had to think about backwards
compatibility and the parts and power that was available at the
time of planning. Then implementation was also determined by
the parts and resources available at the time of the implementation.
You can't make something that depends on a foobar existing at
the time of production. There is also the requirement that there
will be enough of the foobars so manufacturing the item
won't be held up.

Remember the tiny, baby finger sized tubes of the 40s and 50s
military radios by Raytheon and the like? What were their filament
voltages? ISTR it being slightly lower than 6.3V, not certain though.

Then, the TV era had tubes in the 3 to 6 inch length range.

Filament voltage selection would seem to me to have at least a
little to do with how far up a tube one could spiral a length of
filament media and still get nice, even heating of it without
adversely affecting longevity.

 

[MassiveProng]

On Sun, 11 Mar 2007 10:14:09 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

Eeyore wrote:

"nonsense@unsettled.com" wrote:


There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.


Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Graham


Just when I thought dumb donkey had run out of
stupid things to say.

As if a twit like you knows anything about it.

 

[MassiveProng]

On Sun, 11 Mar 2007 10:16:07 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

Ken Smith wrote:

In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[....]

has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.


Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.

There are lots of well believed urban legends.


The constraint was 5V so choices
made from one development project to the next had to include
the old choices. Most projects had to think about backwards
compatibility and the parts and power that was available at the
time of planning. Then implementation was also determined by
the parts and resources available at the time of the implementation.
You can't make something that depends on a foobar existing at
the time of production. There is also the requirement that there
will be enough of the foobars so manufacturing the item
won't be held up.

I see you mouthing off a lot, but I have yet to see you give a
dissertation as to why 6.3 volts was what the ENTIRE industry selected
and settled on!

Put up or STFU, you retarded wussy boy!

 

[Eeyore]

"nonsense@unsettled.com" wrote:

Eeyore wrote:
"nonsense@unsettled.com" wrote:

There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Just when I thought dumb donkey had run out of
stupid things to say.

So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !

Graham

 

[nonsense@unsettled.com]

Eeyore wrote:

"nonsense@unsettled.com" wrote:


Eeyore wrote:

"nonsense@unsettled.com" wrote:


There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Just when I thought dumb donkey had run out of
stupid things to say.


So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !

Graham

And even more dumb donkey dumbness.

That depends on how you design it.

Transistors are available for many voltages
higher than you seem to believe.

 

[John Fields]

On Sun, 11 Mar 2007 17:50:06 +0000, Eeyore
<rabbitsfriendsandrelations@hotmail.com> wrote:

"nonsense@unsettled.com" wrote:

Eeyore wrote:
"nonsense@unsettled.com" wrote:

There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Just when I thought dumb donkey had run out of
stupid things to say.

So you reckon TTL's good for 8 volts do you ?

---
Looks like he hasn't...


--
JF

 

[Eeyore]

"nonsense@unsettled.com" wrote:

Eeyore wrote:
"nonsense@unsettled.com" wrote:
Eeyore wrote:
"nonsense@unsettled.com" wrote:

There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The
supply voltage has to be less than that.

Just when I thought dumb donkey had run out of stupid things to say.

So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !

And even more dumb donkey dumbness.

Oh dear. That means you're going to be shown to be dumber than a donkey !

That depends on how you design it.

Transistors are available for many voltages higher than you seem to believe.

*Transistors* are indeed available for nice high voltages and I'm very pleased about it
since I've used lots of them.

What you clearly haven't the tiniest clue about though is IC processes. There's another
'barrier' btw at around 40 volts.

Graham

 

[MassiveProng]

On Sun, 11 Mar 2007 17:50:06 +0000, Eeyore
<rabbitsfriendsandrelations@hotmail.com> Gave us:

"nonsense@unsettled.com" wrote:

Eeyore wrote:
"nonsense@unsettled.com" wrote:

There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Just when I thought dumb donkey had run out of
stupid things to say.

So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !

He's clueless.

 

[MassiveProng]

On Sun, 11 Mar 2007 12:11:53 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

Eeyore wrote:

"nonsense@unsettled.com" wrote:


Eeyore wrote:

"nonsense@unsettled.com" wrote:


There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Just when I thought dumb donkey had run out of
stupid things to say.


So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !

Graham



And even more dumb donkey dumbness.

That depends on how you design it.

Transistors are available for many voltages
higher than you seem to believe.

TTL logic is a STANDARD, dumbass, and it is INSIDE integrated
circuit chips in most cases, you fucking retard!

 

[nonsense@unsettled.com]

MassiveProng wrote:

On Sun, 11 Mar 2007 12:11:53 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:


Eeyore wrote:

"nonsense@unsettled.com" wrote:



Eeyore wrote:


"nonsense@unsettled.com" wrote:



There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The supply
voltage has to be less than that.

Just when I thought dumb donkey had run out of
stupid things to say.


So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !

Graham



And even more dumb donkey dumbness.

That depends on how you design it.

Transistors are available for many voltages
higher than you seem to believe.



TTL logic is a STANDARD, dumbass, and it is INSIDE integrated
circuit chips in most cases, you fucking retard!

You never managed to figure out that because something
is *A* standard doesn't mean that's all there is.

I'm sure glad not to be "one of you".

 

[Eeyore]

"nonsense@unsettled.com" wrote:

MassiveProng wrote:
"nonsense@unsettled.com" Gave us:
Eeyore wrote:
"nonsense@unsettled.com" wrote:
Eeyore wrote:
"nonsense@unsettled.com" wrote:

There's no good reason to have selected 5 volts as opposed
to 6 volts, or for that matter, 8 volts.

Utter nonsense.

The IC process used for TTL has a breakdown voltage of around 7 volts. The
supply voltage has to be less than that.

Just when I thought dumb donkey had run out of stupid things to say.

So you reckon TTL's good for 8 volts do you ?

Bwahahahahahahahahaha !


And even more dumb donkey dumbness.

That depends on how you design it.

It depends on the IC process.

Transistors are available for many voltages
higher than you seem to believe.

TTL logic is a STANDARD, dumbass, and it is INSIDE integrated
circuit chips in most cases, you fucking retard!

You never managed to figure out that because something
is *A* standard doesn't mean that's all there is.

And you apparently are unaware of how physics works.

So Mr Expert. Why isn't TTL made on a 40 Volt process ?

I'm sure glad not to be "one of you".

LMFAO !

Graham