Jihad needs scientists

[krw]

In article <14kpu2t3mskaebbmbhuhkvg7fiei5pujir@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...

On 05 Mar 2007 13:05:11 +0200, Phil Carmody
thefatphil_demunged@yahoo.co.uk> Gave us:

krw <krw@att.bizzzz> writes:
In article <9ldku21o58531j21nnipbg2qorbqtc71li@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Sat, 3 Mar 2007 13:38:29 -0500, krw <krw@att.bizzzz> Gave us:

If you accept that there are disk controllers controlling
controllers.


IDE controllers are ALL ON THE DRIVE.

Clueless.

The part on the MOBO is called an I/O interface, NOT a drive
controller.

You couldn't be more clueless, Dumbulb.

Actually, he's right.

What's on the mobo is the bus controller. Once it's pumped onto
that bus it doesn't matter what device is at the far end.
Sure, it's most likely to be a physical IDE hard disk drive,
but to the motherboard it's just a black box.

Are you confusing IDE drivers with IDE controllers? IDE drivers
are the things that need to know what commands are to be written
onto the IDE bus. They aren't drive controllers though.


Proven even moreso by the fact that today's SATA drives REQUIRE that
the master be on the end of the cable when both drives are present on
that channel. That master's Integrated Drive Electronics is the drive
controller.

Dimbulb, SATA drives are one per cable. There is no Master/Slave,
nor Cable Select (what you're attempting simper on about).

I do have some confusion, however, regarding the fact that an
optical storage/read drive does not require being set master or slave,
and will work on a channel without a master.

Some do, some don't. Of course you're confused. When haven't you
been?

I believe it sits on the IDE I/O channel, and accepts (through a
driver) some standard subset of I/O commands, which are now supported
in hardware at/on the IDE I/O chip.

Can you say ATAPI, MassivelyWrong?

--
Keith

 

[krw]

In article <esijhk$9en$2@blue.rahul.net>, kensmith@green.rahul.net
says...

In article <MPG.2056422472aa66b398a06f@news.individual.net>,
krw <krw@att.bizzzz> wrote:
In article <eshesp$8qk_004@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com says...
In article <eshe15$l1t$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <MPG.2055feeb3db1e22498a066@news.individual.net>,
krw <krw@att.bizzzz> wrote:
[....]
Much of the "controller" is on the chipset these days, oh
MassivelyWrong one.

I know that appearing to agree with MissingProng is a strong indication of
error but there is a point that I would like to make here.

Way back in the mists of time, there was electronics for disk drives we
called the "controller". This electronics was much simpler than the
electronics used related to disk drives today.

And one controller could have many devices hanging off it.
Apparently, that doesn't happen at the moment. From your
descriptions, it appears there a 1::1 restriction.

SCSI controllers can have several devices hanging off them.

"SCSI controller" usually refers to the stuff that is making the SCSI
interface go. This shouldn't really be included in the "disk drive
controller" term.

Sorry, that's what they're called. ...perhaps just to keep
MassivelyWrong confused.

Things other than disk drives have been hung off SCSI
interfaces. Tape drives would be the simplest example of this. The SCSI
bus has to be general enough that such things can be done.

And other things, like "SCSI controllers". ;-)

--
Keith

 

[krw]

In article <esjjoe$8ss_002@s931.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com says...

In article <MPG.2056422472aa66b398a06f@news.individual.net>,
krw <krw@att.bizzzz> wrote:
In article <eshesp$8qk_004@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com says...
In article <eshe15$l1t$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <MPG.2055feeb3db1e22498a066@news.individual.net>,
krw <krw@att.bizzzz> wrote:
[....]
Much of the "controller" is on the chipset these days, oh
MassivelyWrong one.

I know that appearing to agree with MissingProng is a strong indication of
error but there is a point that I would like to make here.

Way back in the mists of time, there was electronics for disk drives we
called the "controller". This electronics was much simpler than the
electronics used related to disk drives today.

And one controller could have many devices hanging off it.
Apparently, that doesn't happen at the moment. From your
descriptions, it appears there a 1::1 restriction.

SCSI controllers can have several devices hanging off them. There
are two interfaces per parallel ATA port. Things get a little
complicated, depending on exactly what variety of ATA port one is
talking about though. At it's simplest ATA is just a buffer from the
8086 bus. Later devices have fully independent busmastering DMA disk
ports.

For some reason, I thought SCSI was daisy chained which isn't
a win for some kinds of gear setups.

SCSI is normally Multi-drop, not daisy chained. There can be eight or
sixteen drops on the cable. Some variants (e.g. Fibre Channel) use
other topologies (ring or switched) but basic SCSI is a multi-dropped
cable.

Today, there is a lot more electronics included in the term "controller"
mostly because we didn't create a new term to cover the new stuff. The
bulk of work of the controller of old is now done by the disk drive but
mother board chip set now has a bunch of this new work to do. The IDE was
the point where the mother board electronics was the simplest.

I believe that this disagrees with what MissingProng has had to say on
this subject but should it turn out to agree with him in full or in part,
I will retract it immediately.

The term for this paragraph is "disclaimer".

;-)


I still have ours in my head..."this is not to be construed
as a committment of Digital...."

When used in front of a DECUS session, it always got a laugh.

"All warranties and guarantees are void upon payment of invoice." ;-)

--
Keith

 

[Ken Smith]

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

In article <esikk3$9en$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <eshe41$8qk_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <eshcs5$l1t$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <eshaf7$8ss_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[.....]
tape. And that was a PITA because a checksummed directory of the
tape was never precisely accurate because the checksum of the
first file (the checksummed directory of itself) always changed .

It was one of those neat CATCH-22 problems that I liked to think
about. It reminded me of those three-way mirrors in the clothing
store's dressing rooms. It was turtles all the way down.

A checksum isn't the best way to do it if but assuming a checksum is used,
the problem of the checksum including its self was solved years ago.

No, it wasn't.

Yes, it was.

Not with the spec I had. Remember that the
directory of the tape had to be the first file on that tape.

No problem. Was the contents you intended to put in the directory known
before you started to write.

Sure. But you are missing the requirement that the DIR file
was a checksummed directory of the _tape_, not of the
contents of the tape before it was saved.

If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

If so this is falling off a log simple.

I am aware of that one. This was a directory of the tape,
not the files of the disk before they were copied to the
tape.

If you intend to put the files onto the tape and can do so you can also
figure out what the directory should look like before hand. This is so
simple that it doesn't need further discussion.

The issue of what to do if you can't be sure about how much will really
fit onto the tape is worthy of further discussion if you want to know how
to solve that one.


[....]

You are not solving the problem I was talking about.

I didn't solve it. It was solved by others long long ago. You can't see
the solution without further help so I will include that help below.

Hint: what do write you when you haven't done the checksum yet? What do
you write after you have done it.

The medium was magtapes. They are not random access writable media.

Think about the questions. I gave you a huge hint as to how to do it.

You are talking about checksumming the files on the disk. That
was not the purpose of the directory file. This directory file
had to be done on the tape.

Did you control what was written onto the tape or did some random
generator determine it. If you controlled what went onto the tape, you
knew before you wrote the first byte what all the bytes were going to be
so the figuring out of the checksum was not really a problem. The problem
is that you couldn't see how to make the checksum correct when the file
that contained the checksum had to be included in the checksum.

A checksum is a simple sum where carried out of th etop of the word are
discarded. For this reason you can take advantage of the observation
that:

A+B+C+D+E+F+G+0+0 == A+B+C+D+E+F+G+(-H)+H

The checksum is not changed if two changes that cancel each other are
made. With binary data it is very easy to implement this by simply
writing the values. If you need work in ASCII doing the (-H) part is only
slightly trickier.

Before:
*Please ignore this line: ZZZZ
The checksum is = 0000

After:
*Please ignore this line: ZXYZ
The checksum is = 0210

See how the compensating change means that we can figure out a checksum
and then put it in without changing the very thing we just calculated.
Your problem was solved years ago. Doing the same on CRC based checking
requires a more complex routine for doing the compensating change but the
method still works.

Some people even came up with cute ways to hide the compensating changes
so that it wouldn't look like anything funny was being done.

I
always used the one implemented in our DIRECT program. I'm talking
about storing a file whose contents changes with each previous
save. Remeber that a checksummed directory of the tape also has
to include the file that contains the checksummed directory of the
tape.

Like I said solved years ago.

No, it is a problem that cannot be solved.

See above.



--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <2f35c$45ed811d$4fe701c$6345@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
[.....]

Not what BAH is refering to isn't. The change she is disagreeing with
didn't start with any ability to do operations between drives without the
CPU getting involved. The disk drive controller electronics was shared
between two drives but only one drive could operate at a time.

It is posible that she has confused the disk drive controller with a
thing called a channel controller that was a topic in earlier discussion.

Seems to me she's delving into theory while you're stuck
in "hardware as it is now" arguments.

I think you need new glasses. She is speaking of theory that was old when
we were young. She has gone part way towards noticing that a round thing
will roll even if you attach to a shaft at its center point. In a another
few weeks whe will have a wheel.




--
--
kensmith@rahul.net forging knowledge

 

[Tony Lance]

Big Bertha Thing pin-wheel
Cosmic Ray Series
Possible Real World System Constructs
http://web.onetel.com/~tonylance/pinwheel.html
Access page JPG 17K Image
Astrophysics net ring access site
Newsgroup Reviews including talk.politics.guns

Detail from frontspiece painting showing,
so called pin-wheel rickshaw

Caption;-
A Chinese Street

From the book
The World and Its People
Asia With Special Reference to British Possessions
Published by Thomas Nelson and Sons 1903
Without Author or Editor Name
(C) Copyright Tony Lance 1998
Distribute complete and free of charge to comply.

Big Bertha Thing china

There is an old chinese curse,
which goes "Live in interesting times."
In which times, they used to get their heads chopped off.
They used to go around saying
"Thats not so good, thats not so funny or thats not so interesting."

There was a nation of them, now some 1 billion strong.
There are even bigger numbers in OUSA Classical Particle Conf.,
such as 227879226 photons in an electron.
Every one should have one.

Tony Lance
judemarie@bigberthathing.co.uk


From: Tony Lance <judemarie@bigberthathing.co.uk>
Newsgroups: swnet.sci.astro,sci.chem
Subject: Re: Big Bertha Thing mayor
Date: Fri, 23 Feb 2007 17:34:45 +0000


Tuesday, November 18, 1997 04:12:46 PM
Message
From: Pam Scruton
Subject: Re: archivist
To: Tony Lance
Hi Tony
++++++

I'm afraid you are going to have to take me through all this very slowly - I did say my
last Physics was A level some 30+ years ago didn't I?


In answer to your question, yes I'm happy to be archivist - my 486 'boasts' a reasonable
amount of hard disk space and I could allocate about 500MB to the job with as many backup
100MB floppies (on a zip drive) as is necessary. I'm a bit puzzled about the email and
password bit - do you mean that I should log on as AML34 with your password and download
your mail and files? I'm not terribly comfortable with that idea - I would much rather
you forward the relevant messages and attachments to me rather than I should find myself
reading all your mail.

Or perhaps it might be better to set up a closed subconference, one that can only be
accessed by your volunteers and I would get archive the files from there.

Or you can ask people to copy them to me or mail them to me directly.

Have a think and let me know - I would rather not mess around with your mailbox - I'm
pretty sure it's against the rules anyway!

Next
++++
I have downloaded and run the Pastures software and there are lots of things I don't
understand (probably because I don't exactly understand the physics - and I'm not even
going to try to do that right now - although I think I understand what your goal is).
First thing I didn't understand was why working through the Worked Example for Option 1 -
the seven-hour bit took my machine about 20 minutes. So either I'm missing something
fairly fundamental or there is a much bigger speed differential between a 386 and a
486DX-66 than I would have thought!

Then as Option 4 in the Worked example was next, I tried that, but it didn't work -
presumably because it shouldn't be next, it should be after Option 3?

When you refer to 'Edit particle.dat' are you referring to the Dos Edit command or are you
using the term Edit more loosely than that?

Anyway, having made a miserable attempt at running the examples I decided that I really
need my hand held on this one. I'm afraid that perhaps your documentation steps just
aren't quite small enough for me. Would it be too much trouble to go over it again at
half speed? If it would and I can't be of much help to you running the damn thing, I will
still happily act as archivist because I am now quite intrigued by it all!

Cheers for now

Pam
PS I don't understand your Big Bertha messages either - and I've heard of Serpico, there
was a not very good film made about the case a few years ago that has been doing the
rounds on Sky.
PPS: Did you ever get Philip Sims on board? You certainly managed to alienate a few mods
though didn't you? <<<Grin>>>

Cheers once more
Pam

 

[MassiveProng]

On Tue, 06 Mar 2007 08:07:00 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

It is a hard disk controller and more, a superset rather
than "something different" that you'd prefer to make it.

It is a bus controller that becomes a hard drive controller per se
once hard drives are included on its bus.

 

[MassiveProng]

On Tue, 06 Mar 2007 08:07:00 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

The IDE connection supports CD drives as well as CR-R and
CD-RW drives. IDE can also support tape drives designed
for that purpose. Think Travan.

Only if they are manufactured with an IDE interface. D'oh!

Stupid link snipped

flush> your argument.

Tell your doctor that the lobotomy wasn't fully successful, dipshit.
He should also up your Lithium doses.

 

[MassiveProng]

On Tue, 06 Mar 2007 08:16:02 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

MassiveProng wrote:

On Mon, 05 Mar 2007 07:15:46 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:

snip

Bit by bit compare is the gold standard.

Bullshit. The MICROSOFT Flight Sim X CHECKSUMS the DVD during the
install process. It reads the entire DVD, and there is no image to
check it against bit-for-bit. It relies on a checksum figure, and it
is deadly accurate, dipshit.

snip

Using a Microsoft game as your standard?

Using any optical medium based install application, dumbass.

Good for you, not so good for serious uses.

You're an idiot. For one thing MS Flight is NOT a game. It is one
of the most advanced flight simulators on the planet at the consumer
level.

For another, ALL Suse Linux, as well as many other distros use
checksums to verify their disc images as well as the finished burned
discs. As do many other makers of soft media provided on optical
storage mediums.

You could be a bit more clueless, just not in this life.

 

[MassiveProng]

On Tue, 06 Mar 2007 08:19:41 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

MassiveProng wrote:

On Mon, 5 Mar 2007 10:13:57 -0500, krw <krw@att.bizzzz> Gave us:


, most dim one. PCI is not required for either ATA nor Busmaster
DMA. THe first busmaster DMA ATA was on ISA, Dimbulb.


Oh but, the KRW dumbfuck has forgotten that ever since the adoption
of the PCI bus, ALL peripheral I/O passes THROUGH it, as in TERTIARY
to it.

Guess which side of that bus your precious IDE I/O chip is on?

Guess where even an ISA bus is at when used (as they were for years
after PCI hit the industry)?

The exception was AGP, and PCIx is even a PCI bus architecture, and
it is blazing fast.

Yet you seem to think that all this is bypassed. Good luck learning
about modern PC motherboards, you're going to need it.

Your sun may rise and set around "modern PC motherboards" but
not everyone's does.

Obviously you are unable to keep up with this discussion.

It is about interfaces, and since add on cards are not nearly as
proliferant these days, the conversation is certainly about
motherboard bus utilization and configuration methodology.

Grow the fuck up, asswipe. Stop running around behind my posts like
a little fucking pissed off Chihuahua. All bark and no bite. Fuck
off, dog boy.

 

[MassiveProng]

On Tue, 06 Mar 2007 08:25:51 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

MassiveProng wrote:

On Mon, 05 Mar 07 16:01:29 GMT, jmfbahciv@aol.com Gave us:


And one controller could have many devices hanging off it.



Nope. MFM as well as ESDI carried only two drives per channel.

Had tapes on them too.

SCSI
is the exception, and has always carried many "ports" per channel.
That is due to the fact that the interface, SCSI, is meant for more
than hard drives.

Wrong again. SCSI is NOT an exception. You'd probably be
surprised at the sorts of things we hang off a centronics
parallel I-O port. You folks call that the printer port
because IBM named it LPT1.

I worked with various IEEE standard interfaces before you even knew
what a printer was, much less how it was attached.

 

[MassiveProng]

On Tue, 06 Mar 2007 08:42:13 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

MassiveProng wrote:

When you are at the bottom of a mid-oceanic trench, like you are, it
usually is.

Don't wonder why you stand alone in these discussions
lacking any admiration for your efforts.

Damn! I keep hearing that fucking retarded Chihuahua barking again!

 

[MassiveProng]

On Tue, 06 Mar 2007 08:56:31 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

Seems to me she's delving into theory while you're stuck
in "hardware as it is now" arguments. She's learning from
you, possibly not in ways you can relate to.

Your analytical skills are about as useless as your capacity for the

computing realm. That said, you cannot possibly have any credibility
when addressing such issues, dumbass.

 

[MassiveProng]

On Tue, 6 Mar 2007 15:06:34 +0000 (UTC), kensmith@green.rahul.net (Ken
Smith) Gave us:

In article <2f35c$45ed811d$4fe701c$6345@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
[.....]
Not what BAH is refering to isn't. The change she is disagreeing with
didn't start with any ability to do operations between drives without the
CPU getting involved. The disk drive controller electronics was shared
between two drives but only one drive could operate at a time.

It is posible that she has confused the disk drive controller with a
thing called a channel controller that was a topic in earlier discussion.

Seems to me she's delving into theory while you're stuck
in "hardware as it is now" arguments.

I think you need new glasses. She is speaking of theory that was old when
we were young. She has gone part way towards noticing that a round thing
will roll even if you attach to a shaft at its center point. In a another
few weeks whe will have a wheel.

Dip that wick into the hot wax often enough and eventually you will
produce what we modern folks call a candle.

 

[MassiveProng]

On Tue, 6 Mar 2007 10:09:04 -0500, krw <krw@att.bizzzz> Gave us:

Dimbulb, SATA drives are one per cable. There is no Master/Slave,
nor Cable Select (what you're attempting simper on about).

I meant UDMA. You know, that method you swore was controlled at the
motherboard.

Just so you know, the SERIAL ATA interface is ALSO tertiary to the
PCI bus.

 

[MassiveProng]

On Tue, 6 Mar 2007 10:09:04 -0500, krw <krw@att.bizzzz> Gave us:

Some do, some don't. Of course you're confused. When haven't you
been?

Wrong. ALL current drives do.

OLD pieces of shit from SEVERAL years ago may or may not, just like
you may or may not have a clue sometimes, you old piece of shit.

 

[MassiveProng]

On Tue, 6 Mar 2007 10:09:04 -0500, krw <krw@att.bizzzz> Gave us:

I believe it sits on the IDE I/O channel, and accepts (through a
driver) some standard subset of I/O commands, which are now supported
in hardware at/on the IDE I/O chip.

Can you say ATAPI, MassivelyWrong?

It STILL is NOT a hard drive controller, dumbfuck.

For that bus, they reside ON THE DRIVE.

 

[MassiveProng]

On Tue, 6 Mar 2007 10:11:14 -0500, krw <krw@att.bizzzz> Gave us:

Sorry, that's what they're called. ...perhaps just to keep
MassivelyWrong confused.

No they are not. They are BUS controllers. When and if a hard drive
is placed on the bus, they also are the controller for it/them.

Dedicated SCSI hard drive controllers are specifically designed for
RAID applications, and usually do not accept other types of SCSI
devices, only hard drives. THAT is a hard drive controller.

Google Adaptec SCSI Bus Controller, and Google Adaptec SCSI Hard
Drive Controller, and you get two completely different lists of
products. 600k hits for one and 800k hits for the other.

Try again.

 

[MassiveProng]

On Tue, 06 Mar 2007 17:49:59 +0000, Tony Lance
<judemarie@bigberthathing.co.uk> Gave us:

Big

Find your own thread to SPAM in, dipshit.

 

[nonsense@unsettled.com]

MassiveProng wrote:

On Tue, 06 Mar 2007 08:07:00 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:


It is a hard disk controller and more, a superset rather
than "something different" that you'd prefer to make it.



It is a bus controller that becomes a hard drive controller per se
once hard drives are included on its bus.

That's the same as saying that a car isn't a car
until it is being driven.