My Vintage Dream PC

[Archimedes' Lever]

Core memory is nonvolatile. Wrong, as always.

John

You are incorrect. If you attempt to test the logic state with
external gear or re-energize the device, you are no longer in "Pull Power
Cord" state. While it IS in "Pull Power Cord" state, the device is
non-functional, therefore all is zero for all intents and purposes.

You have to leave "Pull Power Cord" state to examine the logic state of
the memory, and it will be whatever it was last set to, but that is not
that state I put it in. When the power is gone, all readings are zero.

Even though they retain their condition, you can't read it without
removing the state.

I still win.

 

[FatBytestard]

Much like racing stripes on a 1980s Pontiac?

Actually, I don't think even C++'s proponents say it's faster to
compile or run. They hope it's faster or easier to write.

-- Patrick

Wasn't this a Borland evolution originally? C+ ?

 

[FatBytestard]

Writing fast makes bugs. Slow down and get it right *before* you try
to run it.

John

Writing fast does NOT "make" bugs.

 

[Archimedes' Lever]

We do nightly backups to local hard drives and zero-based weekly
backups of *everything* to DVDs. The backups get stashed in three
different locations in two different cities. Seems to work so far.

John

Funny. That sounds like the most comprehensive, proper use of technology
I have observed you making use of yet. Aside from your immature,
jackassed, peanut gallery remarks, which you seem to incessantly have an
urge to spew occasionally, I'd almost say that there may be hope for you
yet. Alas, the depth of that immaturity tells me that you will be
forever stuck in your hard wired John Larkin mouthy pre-teen mentality.

You are far better when you stick to the technology, and keep your
mouth off of people.

 

[FatBytestard]

On Mon, 01 Jun 2009 19:45:50 -0700, Archimedes' Lever

One instruction? - Pull Power Cord.

ALL ZEROS.

I win.

Nope.
True CORE memory holds its state across power failures.
And RAM memory may well come up in a random state.
--
ArarghMail905 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

And most hardware initializes the ram to a known state (and on some it
does it to start out with good ECC).

Some to all one's... some to all zeros, some to the address of the ram written
to the ram as data.

bill

I have ECC RAM. It is not for correcting power outages, it is for
correcting occasional bit errors, and only then below a certain number of
them in any given instance, and with a threshold on how many in sequence
can be off as well.

When the power is off, ECC RAM shuts off too. Even "good ECC RAM".

 

[Joe Pfeiffer]

With the machine in "Pull Power Cord state, all are at zero. If you
attach a device to read the logic levels, or re-energize the unit, you
are no longer in "PullPower Cord" state.

Any reasonable description of changing the state of memory has it still
changed after the instruction is complete. If the data is back when you
plug the cord back in, it wasn't zeroed. Of course.

 

[FatBytestard]

By definition, the operating system must run on the same core
as the transfer mechanism, and once it is running, transfering control to
another processor just adds latency and overhead.

NOT. Video co-processing. Math co-processing... et al. They were all
done to ease the load on the main processor, and relegate it to more
adept engines.

You would not be able to play a modern 3-D environment based games
without multi-processing at those levels as well as right on the CPU
itself. Sub systems allow the main CPU core and OS kernel get things
done faster, not slower.

Leave the serial bit by bit stuff to the comm links between the computer
and storage devices and other bit blast bottlenecks. Even that realm
(storage) has co-processed controllers available for it.

On the main system, multi cored, multi-processed, multi-threaded, time
slice arbitrated systems allows one to keep processing traffic jams from
occurring.

 

[FatBytestard]

Message passing systems aren't known for speed.

Since plenty (speed) is available, it is no longer an issue.

 

[FatBytestard]

Back when I was more current on DRAM, half the bits would use 0V to
represent 0 and half would use it to represent 1 to better balance power
requirements.

If all were filled with (and being filled with) bytes, it would be
random aggregation regardless.

 

[FatBytestard]

No, you lose. Remember, this is *core*, not that newfangled
semiconductor stuff. When you plug it back in, the memory is still
there. ISTR some people running a standalone dump after a power-up to
see what was happening when it shut down.

So... I still win.

The machine must remain in "Pull Power Cord" state. if you attempt to
read the logic level externally or re-energize it, it is no longer in
"Pull Power Cord" state. While it IS in "Pull Power Cord" state, one
cannot read the logic level, therefore all is zero, for all intents and
purposes.

I am still the winner.

 

[FatBytestard]

A mere terabyte of data takes up like 200 DVDs, do you have an automatic
writer?

He does incremental schema of some kind. OR he only has 20 or 30 GB of
data. That would be pretty expensive anyway, and using re-writables is
ludicrous. Optical is ludicrous actually.

With hard drives as cheap as they are these days, having shadow drives
are really the best way. eSATA and even USB drives both write data way
faster than a DVD writer does, and have ZERO likelihood of writing an
errant bit for the most part.

One merely leaves work with the off site back up, and brings it back
each day. If you feel it to be a problem, you can buy seven (or five)
and have one for each day, like the old DAT schemas used to be.

SAS or Serial Attached SCSI is the best way if you have the bucks. The
interface is also SATA 2 compliant, IIRC.

Anyway, that one blazes.

The most reliable optical solution is DVD RAM, and it ain't cheap. VERY
reliable, however. Most current PC writer drives will write to DVD RAM.
Unless you buy crap.

 

[FatBytestard]

Hard drives costing what they do, we could almost dump it all to a
hot-plug drive and physically archive them.

John

Your "backup guy" is in the Barnum family, and you are... well...
every minute...

 

[ItsASecretDummy]

Damn, but you are amazing. When you make any statement of fact, I know
I can prove you wrong with about 10 seconds of googling.

http://www.gcn.com/Articles/2009/01/30/Cray-Linux-gets-Common-Criteria-certs.aspx

Always, always wrong!

John

Which one? The big floor model or the desktop unit? Try again.

 

[FatBytestard]

Idiot doesn't know the difference between a pure text printout, and a
graphically compiled print job. Remember WYSIWYG, Johnny? THAT is why
it takes a while for a modern app to print you complete dweeb!

 

[FatBytestard]

Blank DVDs are cheap. We buy them in packs of 200, around $50.

No. CHEAP blank DVDs are cheap. They are also not very good at
archiving data reliably. High quality blank DVDs are not cheap. Buying
in bulk helps, but your price sounds like it is a cheap brand as well.

I guess you are shredding the older sets?

What a waste.

Hard drives are far cheaper, and you don't have some dope that talked
you into letting him do your backups for you for a fee some time ago. Is
he bonded? Does your government contract holder know that you do this?

 

[FatBytestard]

The problem with reusing any backup media is that if you lose or
corrupt a file on the server, the corrupted file sooner or later winds
up on all the backups... in just one week in your example. That's why
we do backups to burn-once DVDs.

You really do not know much about it then.

ALL files on the volume get re-written on each session.

The five day schema actually ensures that you will likely be able to
find the non-corrupted file, if you catch that it was corrupted soon
enough.

And your disc based burn once method doesn't change the fact that if you
write a corrupt file down to it, it will still be there the next day, and
unless you catch it on the server, it will also migrate down to any
subsequent write sessions and fill up your archive with the same file.
Your method escapes nothing. It just forces you to keep your archives
longer, even more risk. Can't do this kind of stuff in large, heavy
government contract oriented companies.

Of course real companies have hundreds of servers and facilities in
several cities, and they have the right backup mediums being used at all
times, and no third parties are ever involved.

 

[FatBytestard]

Some datasheets print in seconds, some in minutes. Minutes per sheet
is too slow, and whoever published it was the idiot.

John

No. The dope that compares a DOS based application's print job
compilation time with a graphical based, scaled font rendered graphical
print job compilation is the idiot. And NO, I am not talking about the
GUI you are in, I am talking about the utter crispness and registration
of what prints out.

You bend the brain of any kid trying to learn what is going on by
reading your crap as well.

 

[Patrick Scheible]

I have a photo here somewhere where I unpotted a hand loomed array
stuffed into a small case that actually stored an event on a ruggedized
power supply.

My remark holds. With the power cord pulled, you will not be able to
read any logic, therefore all is zero. If you apply a device to read the
logic level, or re-energize the unit, you are no longer in the "Pull
Power Cord" state.

There is no power, therefore it's zero? That is a strange
conclusion. I would say, there is no power, therefore the bits are
undefined.

-- Patrick

 

[Patrick Scheible]

You are the zero bit on this bus, La Chinga.

Bye bye.

-- Patrick

 

[Patrick Scheible]

Reproduce crashes? In Windows?

A long time ago, on a computer far, far away...

-- Patrick