Jihad needs scientists

In article <MPG.2062131aed7a2dce98a111@news.individual.net>,
krw <krw@att.bizzzz> wrote:
In article <et7ktl$bq1$4@blue.rahul.net>, kensmith@green.rahul.net
says...
[....]
How mush is "badly written"? Most software is truly horrid. I still have
a hope that this may change. It may take the deaths of a hundred cute
puppies live on TV, due to a bug, to get the point.

So you agree that software sucks, C/C++ should be banned from the
planet, and Billy Gates drawn and quartered. ...and then discuss
software quality.
Click to expand...
Does screeming it from the roof tops qualify as merely agreeing?

I think that "C" could be allowed to remain on the planet. It can serve
as a good teaching tool about the dangers.

[....]
I wouldn't trust M$ for anything.

It's OK for trolling for dumb donkeys and dimbulb.
Click to expand...
I wouldn't even trust it for that.

[.....]
Don't want no steenkin' Apples, now that they're x86. (Disclosure: I
worked on the later G4 and G5 processors ;-)
Click to expand...
Yes the switch to X86 was a step backwards. I think a huge FPGA with a
soft processor may have been a better way to go. This way, you could run
any code. With a little trickiness, you could have some 8051 code, some
Z80 code, a bit of PIC code and a transputer all cohabiting the virtual
CPU space. we could have some real fun.



--
--
kensmith@rahul.net forging knowledge
 
Ken Smith wrote:

In article <MPG.2062131aed7a2dce98a111@news.individual.net>,
krw <krw@att.bizzzz> wrote:

In article <et7ktl$bq1$4@blue.rahul.net>, kensmith@green.rahul.net
says...

[....]

How mush is "badly written"? Most software is truly horrid. I still have
a hope that this may change. It may take the deaths of a hundred cute
puppies live on TV, due to a bug, to get the point.


So you agree that software sucks, C/C++ should be banned from the
planet, and Billy Gates drawn and quartered. ...and then discuss
software quality.


Does screeming it from the roof tops qualify as merely agreeing?

I think that "C" could be allowed to remain on the planet. It can serve
as a good teaching tool about the dangers.
Click to expand...
One has to remember the origin of the thing.

http://en.wikipedia.org/wiki/Unix

I wouldn't trust M$ for anything.

It's OK for trolling for dumb donkeys and dimbulb.


I wouldn't even trust it for that.

[.....]

Don't want no steenkin' Apples, now that they're x86. (Disclosure: I
worked on the later G4 and G5 processors ;-)


Yes the switch to X86 was a step backwards. I think a huge FPGA with a
soft processor may have been a better way to go. This way, you could run
any code. With a little trickiness, you could have some 8051 code, some
Z80 code, a bit of PIC code and a transputer all cohabiting the virtual
CPU space. we could have some real fun.
Click to expand...
 
kensmith@green.rahul.net (Ken Smith) writes:
In article <873b47kb97.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
kensmith@green.rahul.net (Ken Smith) writes:
In article <et8nqg$8qk_002@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[...]
I almost hate to say this, but I think that understanding
the problem is beyond him.

Definitely. I'm studying the phenomena. I have encountered this
before but it was rare in my area. I don't think one can do
comm and OS development without being able to breathe recursion
and live to tell about it :).

You are really stupid you know. I have pointed out how to solve the
recursion problem. You just refuse to believe that it can be solved so
you obviously aren't letting yourself understand what I am talking about.

The folks who came up with the method were obviously years ahead of you on
such subjects.

It's not even a "recursion" problem.

It can be considered a "recursion" problem. It is more exactly a self
reference problem.
Click to expand...
Self reference and recursion are very different things.

It can be likened to the sentence: The first word in
this sentence is "The".
Click to expand...
Nothing to do with recursion there.

The checksum refers to the very thing that is
stating the checksum. People who are not used to thinking about
self referencing, often have trouble understanding some of the issues it
raises.
Click to expand...
People who are not used to thinking, such as BAH, seem to
even have problems understanding *what* you're doing, let alone
how it works and any issues surrounding it. Sad really.

I decided not to chip in and tell her about the IOCCC entry from
a few years back which implemented exactly the scheme you're
talking about - I thought that would prompt even more confusion
from the senile one.

Phil
--
"Home taping is killing big business profits. We left this side blank
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.
 
In article <et8v9c$6oi$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hie$8ss_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et6c0m$t53$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
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.

There was no tape editing done.

In that case. The tape had to be written with the TAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

Bin thar, dun that, got t-shirt, wore out t-shirt.

I've done it. The idea wasn't new when I did. You just haven't
understood a very simple concept.

I understood you just fine. You didn't put a directory of the
tape onto the tape.

That *proves* you didn't understand. I have explained how to make the the
directory have correct checksum no matter how you actually want to do it.
You seem to constantly fail to understand that you can creat a file that
has its own correct checksum. It has been done many times on many tapes
and on many disks.
Click to expand...
The file you put on the tape did not contain a directory of the
tape. It was an edited file that you think may match the tape.

/BAH
 
In article <et90pt$6oi$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8oqh$8qk_006@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]
Mr. unsettled did write a summary of the behaviour and why it
can't be solved. He did it in 25 words or less. The magic
incantation is recursion.

The fact that you say "the magic incantation is recursion", is further
proof that you can't deal with it and therefor think that the problem
can't be solved.
Click to expand...
So far it can't be solved. If I do think of a solution, I'll be
the darling of the comm people and revered by the physics people.
It's a fun to think about.

/BAH
 
In article <et90d1$6oi$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hr5$8ss_002@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
Ken Smith wrote:

In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to
the
tape not what you actually wrote. This contradicts what you said
earlier.

It doesn't matter because the suggested method still works. The
checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.

It will trash the rest of the tape. We shipped the files within
savesets.

What I said was correct.
Click to expand...
No. It does not put a directory of the tape onto the tape.

I have explained how to make TAPE.DIR have the
right checksum for all posible cases of how you did things.
Click to expand...
Your methods require a human intervention which is called
editing. The minute you close the file, that file is no
longer a directory of the tape; it is a file that you think
is a directory of the tape.

This is just
responding to unsettled further incorrect statement about how tape drive
operate.

When you disagreed with my suggestion that TAPE.DIR is list of what you
intended to write onto tape, I could see that there was a way that you
could actually have done what you at that point were claiming. You have
now changed the claim. You no longer say that it is the directory of what
is on the tape
Click to expand...
What!?? You need reading comprehension eye glasses.

but is as I had suggested the directory of what you
intended to write onto tape.
Click to expand...
The script that creates the tape is already a list of what
I intended to put on the tape. What is needed is a directory
of the tape on the tape. To be useful, it has to be the first
file of the saveset of the tape. Your methods don't do this.
The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.

But your edit write would not include the directory of the tape
after you wrote it.

Oooops!!!! There you go again. Which is it. Is it (A)the directory of
what you wrote or (B) the directory of what you intend to write.

This is getting silly because your story changes back and forth on this.
Click to expand...
You are interpreting my posts as going back and forth because that
is the nature of the problem. unsettled called this recursion.
There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.

/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

You *still* haven't understood.

BTW: It isn't my method in that I did not invent what was done. It was
already old when I learned it. It was used on many tapes before I got
near one.
Click to expand...
It wasn't used on our distribution tapes. Nobody would put a hand
edited file on the tape and expect it to be a directory of the tape.
/BAH
 
In article <et8vtn$6oi$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8nid$8qk_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file

Now the file is no longer a directory of the tape. By modifying
the file on the tape, you have changed the tape. There is no
longer a directory of the tape on the tape.

That is just silly word games, but at least you now obviously must see
that you have been wrong.
Click to expand...
Wrong. [awed emoticon here]

/BAH
 
In article <f539$45f813cb$4fe71d4$28601@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
jmfbahciv@aol.com wrote:

In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:

On Mar 13, 10:34 am, jmfbah...@aol.com wrote:

In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file


Now the file is no longer a directory of the tape. By modifying
the file on the tape, you have changed the tape. There is no
longer a directory of the tape on the tape.


with a chunk of your favourite nonsense rhyme
or saying of the day until the statement "this files checksum = 1234"
is true. Checksum is invariant under permutations of the characters in
the file so you don't have to work very hard to do it by brute force.
Even if as seems likely the TAPE.DIR contains both length and checksum
then self consistent solutions can be found by SMOP.


It isn't a goal to have the checksum of TAPE.DIR correct. It was
a mandatory goal to have a directory of the tape on the tape. The
tradeoff to accomplish this goal was to have the checksum of
the file TAPE.DIR not match the checksum of TAPE.DIR reported
in TAPE.DIR.

Query: Is the ability to think about this concept (Mr. unsettled
called it recursion) a rare ability?

Technicians and engineers are trained to problem solving
regardless of method.
Click to expand...
I realize this.

They consider it "inventive" to do
things the way they go about it; the way answers they have
provided in this subthread.
Click to expand...
So how does the human race go from this "inventive" solution
methods into production? Is there a name for the work
which eliminates this requirement to tweak each item that comes
off the production line?

/BAH
 
In article <et90ti$6oi$8@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8i9q$8ss_004@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <87slc9jje1.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
jmfbahciv@aol.com writes:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
There need not be any increase in the risk. Its all a matter of
starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Don't judge all programmers based on your own inadequacy as one.

I'm stating this fact based on experience working with bit gods
and hardware that had the proper tweaks to help prevent
these problems.

Did you bring these "bit gods" coffee?
Click to expand...
Some times I did; usually at dawn. Other times I patted them
on the head. Once in a great while, I kicked their butts.
I was the one they showed their stuff to; they called it
the den mother test because it invariably would crash
the system. There is some aspect of life that, when you
think you're ready to show off your brand new invention,
doing so will cause it to immediately turn belly up
and die a horrible death.

I also participated in a lot of the preliminary bullshit
sessions which usually ended up in major products. I also
could predict where and when the axles would need greasing
and applied the grease before anybody heard a squeak.

All of the above was done in my spare time.
 
jmfbahciv@aol.com wrote:

In article <f539$45f813cb$4fe71d4$28601@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

jmfbahciv@aol.com wrote:


In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:


On Mar 13, 10:34 am, jmfbah...@aol.com wrote:


In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file


Now the file is no longer a directory of the tape. By modifying
the file on the tape, you have changed the tape. There is no
longer a directory of the tape on the tape.



with a chunk of your favourite nonsense rhyme
or saying of the day until the statement "this files checksum = 1234"
is true. Checksum is invariant under permutations of the characters in
the file so you don't have to work very hard to do it by brute force.
Even if as seems likely the TAPE.DIR contains both length and checksum
then self consistent solutions can be found by SMOP.


It isn't a goal to have the checksum of TAPE.DIR correct. It was
a mandatory goal to have a directory of the tape on the tape. The
tradeoff to accomplish this goal was to have the checksum of
the file TAPE.DIR not match the checksum of TAPE.DIR reported
in TAPE.DIR.

Query: Is the ability to think about this concept (Mr. unsettled
called it recursion) a rare ability?

Technicians and engineers are trained to problem solving
regardless of method.


I realize this.


They consider it "inventive" to do
things the way they go about it; the way answers they have
provided in this subthread.


So how does the human race go from this "inventive" solution
methods into production? Is there a name for the work
which eliminates this requirement to tweak each item that comes
off the production line?
Click to expand...
Sure. It is called the factory worker who is paid to rush
through production while ignoring flaws. That's why we now
have lemon laws.
 
In article <etb9rf$8ss_002@s881.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
In article <et8v9c$6oi$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hie$8ss_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et6c0m$t53$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
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.

There was no tape editing done.

In that case. The tape had to be written with the TAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

Bin thar, dun that, got t-shirt, wore out t-shirt.

I've done it. The idea wasn't new when I did. You just haven't
understood a very simple concept.

I understood you just fine. You didn't put a directory of the
tape onto the tape.

That *proves* you didn't understand. I have explained how to make the the
directory have correct checksum no matter how you actually want to do it.
You seem to constantly fail to understand that you can creat a file that
has its own correct checksum. It has been done many times on many tapes
and on many disks.

The file you put on the tape did not contain a directory of the
tape. It was an edited file that you think may match the tape.
Click to expand...
Now at least you seem to perhaps have started to get a slight glimmer of
understanding.

I was not suggesting a file that was manually edited. You have claimed to
be a developer so this part should have been obvious, but now lets
discuss this file you put on tape. It is also not a directory of the
tape. It was not made from the tape. It was made from what you intended
to write onto the tape. You wrote this file onto the tape before you
wrote the files it claimed were there. Unless you then checked the tape
to make sure that all the files you claimed to have written were actually
there, this file you wrote could not be said to be a correct directory of
the tape. The method I suggested way back at the start involved exactly
this sort of check to make sure that the file I was suggesting was also a
true and correct directory.

You seem at least to have finally settled on a claim about when you
created the TAPE.DIR.


--
--
kensmith@rahul.net forging knowledge
 
In article <etbb22$8qk_002@s881.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
In article <et8vtn$6oi$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8nid$8qk_001@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file

Now the file is no longer a directory of the tape. By modifying
the file on the tape, you have changed the tape. There is no
longer a directory of the tape on the tape.

That is just silly word games, but at least you now obviously must see
that you have been wrong.

Wrong. [awed emoticon here]
Click to expand...
Ok so you haven't yet figured out that you were wrong.

/BAH
Click to expand...

--
--
kensmith@rahul.net forging knowledge
 
In article <etbb6t$8qk_003@s881.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
[....]
So how does the human race go from this "inventive" solution
methods into production? Is there a name for the work
which eliminates this requirement to tweak each item that comes
off the production line?
Click to expand...
That process is called "engineering" or in some cases "manufacturing
engineering". Once the solution is found, procedures, script files and
software is written. In large scale manufacturing, whole new machines are
designed to do produce the product.


--
--
kensmith@rahul.net forging knowledge
 
In article <87hcsmizjg.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
kensmith@green.rahul.net (Ken Smith) writes:
In article <873b47kb97.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
kensmith@green.rahul.net (Ken Smith) writes:
In article <et8nqg$8qk_002@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[...]
I almost hate to say this, but I think that understanding
the problem is beyond him.

Definitely. I'm studying the phenomena. I have encountered this
before but it was rare in my area. I don't think one can do
comm and OS development without being able to breathe recursion
and live to tell about it :).

You are really stupid you know. I have pointed out how to solve the
recursion problem. You just refuse to believe that it can be solved so
you obviously aren't letting yourself understand what I am talking about.

The folks who came up with the method were obviously years ahead of you on
such subjects.

It's not even a "recursion" problem.

It can be considered a "recursion" problem. It is more exactly a self
reference problem.

Self reference and recursion are very different things.
Click to expand...
I disagree. Self references often lead to recursions and in the case we
have been considering, the thinking of the people who say the problem
can't be solved followed a recursive path. They followed the loop instead
of stepping outside of it and asking why the loop existed.


It can be likened to the sentence: The first word in
this sentence is "The".

Nothing to do with recursion there.
Click to expand...
I was explaining it from my point of view so yes you are right. There is
no recursion.



The checksum refers to the very thing that is
stating the checksum. People who are not used to thinking about
self referencing, often have trouble understanding some of the issues it
raises.

People who are not used to thinking, such as BAH, seem to
even have problems understanding *what* you're doing, let alone
how it works and any issues surrounding it. Sad really.
Click to expand...
She also seemed confused about what she had actually did. Perhaps she
just needed to thaw out the memory that had been in cold storage all these
years or perhaps she never really though about it at the time. She may
have just gone through the steps without really thinking about what they
did.


I decided not to chip in and tell her about the IOCCC entry from
a few years back which implemented exactly the scheme you're
talking about - I thought that would prompt even more confusion
from the senile one.
Click to expand...
Did they go with the two copies of the checksum or the "please ignore
this".

Two copies:

Before
The checksum is 0000
The checksum is ::::

Please ignore:

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


--
--
kensmith@rahul.net forging knowledge
 
In article <etba66$8ss_003@s881.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
In article <et90pt$6oi$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8oqh$8qk_006@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]
Mr. unsettled did write a summary of the behaviour and why it
can't be solved. He did it in 25 words or less. The magic
incantation is recursion.

The fact that you say "the magic incantation is recursion", is further
proof that you can't deal with it and therefor think that the problem
can't be solved.

So far it can't be solved. If I do think of a solution, I'll be
the darling of the comm people and revered by the physics people.
It's a fun to think about.
Click to expand...

It has been solved. It was solved long long ago. You just seem unwilling
to understand the solution.

--
--
kensmith@rahul.net forging knowledge
 
In article <etban7$8qk_001@s881.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
In article <et90d1$6oi$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et8hr5$8ss_002@s787.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
Ken Smith wrote:

In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to
the
tape not what you actually wrote. This contradicts what you said
earlier.

It doesn't matter because the suggested method still works. The
checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.

It will trash the rest of the tape. We shipped the files within
savesets.

What I said was correct.

No. It does not put a directory of the tape onto the tape.
Click to expand...
Yes it does.

I have explained how to make TAPE.DIR have the
right checksum for all posible cases of how you did things.

Your methods require a human intervention which is called
editing. The minute you close the file, that file is no
longer a directory of the tape; it is a file that you think
is a directory of the tape.
Click to expand...
No it does not require any such thing. You still haven't understood.
Think about any step you think a human must do and ask yourself the
question "does this step need to be done by a human?". You can also ask
yourself the questions "Who wrote the directory command?", "What do we
mean by directory" and "What really is a file?"

This is just
responding to unsettled further incorrect statement about how tape drive
operate.

When you disagreed with my suggestion that TAPE.DIR is list of what you
intended to write onto tape, I could see that there was a way that you
could actually have done what you at that point were claiming. You have
now changed the claim. You no longer say that it is the directory of what
is on the tape

What!?? You need reading comprehension eye glasses.
Click to expand...
Its is exactly what I said. If you did not create the TAPE.DIR from the
tape its self, you did not really create a directory of the tape. You
created a directory of what you intended to put onto the tape. After you
made this file you then attempted to write it and what it claimed was also
there onto the tape.


but is as I had suggested the directory of what you
intended to write onto tape.

The script that creates the tape is already a list of what
I intended to put on the tape. What is needed is a directory
of the tape on the tape. To be useful, it has to be the first
file of the saveset of the tape. Your methods don't do this.
Click to expand...
Yes, my methods do. You simply haven't understood perhaps both what you
were really doing and what I have suggested. I have suggested a method by
which the TAPE.DIR can be correct and can be the first file on the tape.


[....]
But your edit write would not include the directory of the tape
after you wrote it.

Oooops!!!! There you go again. Which is it. Is it (A)the directory of
what you wrote or (B) the directory of what you intend to write.

This is getting silly because your story changes back and forth on this.

You are interpreting my posts as going back and forth because that
is the nature of the problem. unsettled called this recursion.
Click to expand...
No, you keep changing your story. In this post you have said that
TAPE.DIR is created before the tape is written. Elsewhere you have
protested that TAPE.DIR must be a directory of what was actually written
onto the tape.

Unsettled has called something else, not this, recursion. This is because
he also did not understand what you were really faced with. He did not
know about the abilities of tape drives and he assumed what you had said
in one of your post was correct.


[.....]
BTW: It isn't my method in that I did not invent what was done. It was
already old when I learned it. It was used on many tapes before I got
near one.

It wasn't used on our distribution tapes. Nobody would put a hand
edited file on the tape and expect it to be a directory of the tape.
Click to expand...
Perhaps you have started to catch on. Perhaps not. Think about why and
how all the other steps did not need human actions to perform. These
steps were done by a script file. Nothing I have suggested needs a human
to do.

--
--
kensmith@rahul.net forging knowledge
 
In article <3j0hv21dmsbm446in4auk2106k1m71rvqk@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw@att.bizzzz> Gave us:


Don't want no steenkin' Apples, now that they're x86. (Disclosure: I
worked on the later G4 and G5 processors ;-)



That would be "worked with" Not "on", dipshit.
Click to expand...
MassivelyWrong once again, Dimbulb. I was a member of the Apple CPU
development team (Nintendo PPC750 processor variants as well) until
Apple switched to x86.

And whoopie fuckin' do, btw.
Click to expand...
What's the matter dimmie? Jelous of a real engineering work? That's
alright, someone will need a TV repairman, someday Dimme.

I worked with them, and what I did now protects fighter pilots.
Click to expand...
What you "did now" is step on your dick, again.

--
Keith
 
In article <eta7q5$hpg$3@blue.rahul.net>, kensmith@green.rahul.net
says...
In article <MPG.2062131aed7a2dce98a111@news.individual.net>,
krw <krw@att.bizzzz> wrote:
In article <et7ktl$bq1$4@blue.rahul.net>, kensmith@green.rahul.net
says...
[....]
How mush is "badly written"? Most software is truly horrid. I still have
a hope that this may change. It may take the deaths of a hundred cute
puppies live on TV, due to a bug, to get the point.

So you agree that software sucks, C/C++ should be banned from the
planet, and Billy Gates drawn and quartered. ...and then discuss
software quality.

Does screeming it from the roof tops qualify as merely agreeing?
Click to expand...
;-)

I think that "C" could be allowed to remain on the planet. It can serve
as a good teaching tool about the dangers.
Click to expand...
Since 90% of all software is written in C/C++, I don't expect
software quality to improve in my lifetime. In fact IMO it'll get
worse as more C types are minted every year.

I wouldn't trust M$ for anything.

It's OK for trolling for dumb donkeys and dimbulb.

I wouldn't even trust it for that.

[.....]
Don't want no steenkin' Apples, now that they're x86. (Disclosure: I
worked on the later G4 and G5 processors ;-)

Yes the switch to X86 was a step backwards. I think a huge FPGA with a
soft processor may have been a better way to go. This way, you could run
any code. With a little trickiness, you could have some 8051 code, some
Z80 code, a bit of PIC code and a transputer all cohabiting the virtual
CPU space. we could have some real fun.

An FPGA would never be fast enough as a general purpose CPU. You can
Click to expand...
simulate other processors faster than an FPGA can emulate them.

--
Keith
 
kensmith@green.rahul.net (Ken Smith) writes:
I decided not to chip in and tell her about the IOCCC entry from
a few years back which implemented exactly the scheme you're
talking about - I thought that would prompt even more confusion
from the senile one.

Did they go with the two copies of the checksum or the "please ignore
this".
Click to expand...
The please ignore this method. See for yourself ;-) It's omoikane from
http://www.ioccc.org/2004/

Of course, it uses a completely crap algorithm for performing
the work, as it doesn't exploit the linearity of CRCs. However,
not everyone's familiar with working in GF(2^n), and sensibity
is _never_ a factor in the IOCCC!

Phil
--
"Home taping is killing big business profits. We left this side blank
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.
 
krw <krw@att.bizzzz> writes:
In article <3j0hv21dmsbm446in4auk2106k1m71rvqk@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...
On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw@att.bizzzz> Gave us:


Don't want no steenkin' Apples, now that they're x86. (Disclosure: I
worked on the later G4 and G5 processors ;-)



That would be "worked with" Not "on", dipshit.

MassivelyWrong once again, Dimbulb. I was a member of the Apple CPU
development team (Nintendo PPC750 processor variants as well) until
Apple switched to x86.
Click to expand...
Hmmm, why were Apple buying G4s from us at Freescale if they
made their own?

Phil
--
"Home taping is killing big business profits. We left this side blank
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top