Jihad needs scientists

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.
Click to expand...
What I said was correct. I have explained how to make TAPE.DIR have the
right checksum for all posible cases of how you did things. 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 but is as I had suggested the directory of what you
intended to write onto tape.


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.
Click to expand...
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.

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.
Click to expand...
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.



/BAH
Click to expand...

--
--
kensmith@rahul.net forging knowledge
 
In article <5a788$45f7cdfe$4fe707e$27037@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
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.


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.

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.

I almost hate to say this, but I think that understanding
the problem is beyond him.
Click to expand...
No, understanding is beyond you. Even though I have explained many time
now exactly why what you say is untrue, you come back with stupid comments
like this.



--
--
kensmith@rahul.net forging knowledge
 
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 :).
Click to expand...
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.



--
--
kensmith@rahul.net forging knowledge
 
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.
Click to expand...
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.

--
--
kensmith@rahul.net forging knowledge
 
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.
Click to expand...
Did you bring these "bit gods" coffee?


--
--
kensmith@rahul.net forging knowledge
 
Martin Brown 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.
Click to expand...
ALLEGED file checksums are.

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.
Click to expand...
As she stated early on, editing and manipulation aren't permitted.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak
Click to expand...
Editing is not permitted.

a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.
Click to expand...
Now tell me about any theoretical scenario where you can.

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 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.
Click to expand...
Still, it isn't the checkum as read from the tape itself
which *is* the specification.

People who learned the technician approaches to solving
problems appear to be willing to cheat and to argue
strongly in favor of cheating. That wasn't the point
of the subthread.
 
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?
Click to expand...
Technicians and engineers are trained to problem solving
regardless of method. They consider it "inventive" to do
things the way they go about it; the way answers they have
provided in this subthread.
 
jmfbahciv@aol.com wrote:

In article <5a788$45f7cdfe$4fe707e$27037@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

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.



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.


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.

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 :).

I'm beginning to wonder if this lack is a common trait.
Consider the original thread subject matter. Weren't a lot
of the problems due to not being able to think recursively?
Click to expand...
Looks like you found a new word. :)

The answers we've seen over the months seem to me in
retrospect to have been rather linear with a lot of
semi-concealed "they're just like us" worldview. With
that premise being wrong, all that follows is as well.

Dammit, we don't even appreciate the difference between
the Russian mind (semi-oriental) and ours. The US and the
CIA have, for many decades, been accused of all sorts of
underhanded stuff. Still, no one has tied together
anything like the recent anti-leader dieoffs we can
clearly see happening. Factually we consider the Russians
"just like us" and clearly they're not. The middle eastern
mindset is still another sort of critter yet.

I've personally known some Russians, and they were very
nice. But where power, money, and their natural habitat
are concerned, things are rather different.

It didn't seem to take a whole lot to herd the Jim Jones
bunch into a situation where ~1000 murder/suicides were
the end of the journey and achieved in the matter of a
few hours at most. One is amused at the thought that it
was socialist/communist/liberal thinking that led to that
debacle, as sad as the outcome was.

I don't see societal power and control as linear functions.
I do see them as recursive, yes, with significant potential
for runaway positive feedback (for the electronics design
bunch to chew on.)
 
MassiveProng wrote:

On Wed, 14 Mar 2007 05:27:07 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:


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.



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.


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.

I almost hate to say this, but I think that understanding
the problem is beyond him.



All you EVER make are whimpy little peanut gallery comments, and even
those are pretty sad. Do you ever make a post where you tell anyone
the right answer if they are so wrong? NO.
Click to expand...
I did. You appear to be incapable of understanding it.

> You are pathetic.
 
MassiveProng wrote:

On Wed, 14 Mar 07 11:54:56 GMT, jmfbahciv@aol.com Gave us:


In article <5a788$45f7cdfe$4fe707e$27037@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

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.



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.


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.

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 :).

I'm beginning to wonder if this lack is a common trait.
Consider the original thread subject matter. Weren't a lot
of the problems due to not being able to think recursively?



You are BOTH recursively pathetic, lost, wrong, and bullheaded.

Also too old not to be hard wired wrong which means you will never
learn.
Click to expand...
Interpretation: ProngHead says he who blusters loudly is the winner!

Go stand by the kOOks where you belong.
 
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...
Different specification.
 
Ken Smith wrote:

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.



As an aside, do you actually believe you have the high ground?
Click to expand...
 
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...
It cannot be solved within the specification.
 
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.
Click to expand...
It's not even a "recursion" problem. If you're recursing, you've
failed to understand that linear checksums can be reversed (so
you create the file to match the checksum), and are probably
called "BAH", and probably rant insanely at length from a position
of extreme ignorance on usenet.

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 <et7ktl$bq1$4@blue.rahul.net>, kensmith@green.rahul.net
says...
In article <MPG.2060b389becb9ca598a106@news.individual.net>,
krw <krw@att.bizzzz> wrote:
In article <et68m3$t53$4@blue.rahul.net>, kensmith@green.rahul.net
says...
In article <et5vdg$8qk_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
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.

Only in badly written software using languages without run time checking
does it happen. We now have more than enough CPU speed that buffer
overruns should be a thing of the past.

What percentage of software over the last decade has been written in
C/C++? How much in, say, Ada?

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
Click to expand...
planet, and Billy Gates drawn and quartered. ...and then discuss
software quality.
I would never network my PC to my pacemaker.

I wouldn't connect mine to my toaster. Toast is simply too important

Yes, and with real peanut butter, it is even better.

to trust to a PeeCee and M$ (can't drink coffee anymore, so toast
will have to do here).

I wouldn't trust M$ for anything.
Click to expand...
It's OK for trolling for dumb donkeys and dimbulb.

That said, you are assuming that the user runs as root/superuser. I very
rarely ever do on my home system. I do it a little more often on the work
system but that is because I need to directly fiddle a few hardware things
from time to time.

M$ almost insists that users run as admin. Unix and variants are the
opposite. What's the relative population of each group?

With any luck, Vista will be the death of M$ and every home user will
switch to Apples. Apple should get the customers just for those great
ads.

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

--
Keith
 
Phil Carmody 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. If you're recursing, you've
failed to understand that linear checksums can be reversed (so
you create the file to match the checksum), and are probably
called "BAH", and probably rant insanely at length from a position
of extreme ignorance on usenet.
Click to expand...
As is usual for you, you're following the beat of
a drummer no one else can hear.
 
On Wed, 14 Mar 2007 15:12:12 -0400, krw <krw@att.bizzzz> Gave us:

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...
You're a Major idiot. Maybe even a General idiot. You could even
be the Idiot In Chief.
 
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 ;-)
Click to expand...

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

And whoopie fuckin' do, btw.

I worked with them, and what I did now protects fighter pilots.
 
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.
Click to expand...
It can be considered a "recursion" problem. It is more exactly a self
reference problem. It can be likened to the sentence: The first word in
this sentence is "The". 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.


--
--
kensmith@rahul.net forging knowledge
 
In article <d1696$45f819d6$4fe71d4$28690@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
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.


It cannot be solved within the specification.
Click to expand...
It depends on whether the specification forbids solving it or not. There
are at least three ways to do it. One would require that BAH actually
have been a developer. One requires works if the specification only
requires that "TAPE.DIR" be the directory of what is on the tape and the
third will work if TAPE.DIR must be the output of the directory command.

--
--
kensmith@rahul.net forging knowledge
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top