What makes a mac better?

Regrettable with almost all Macs is no option of replacing the CPU or
motherboard/CPU. The Mac Pro offers some CPU upgradeability (not sure
if it's Apple supported, but it does work) - though you can't increase
the memory speed.

A Windows box I bought in 1998 went through 2 more motherboards over the
following 8 years greatly increasing CPU and memory. Hard disks I added
to it or replaced I can't even remember the number. The last
motherboard had a failure in 2010 or so that I didn't even investigate.
Sold the box and cards via Craigslist for $200.

I do lust for another iMac - faster 4 core CPU (vice 2) and more/faster
memory. But really this 4.5 yr old iMac is still doing it's job as well
as day one (better actually as I've increased the RAM to 6 GB and
replaced the 500 GB HD with a 2 TB).

 

Power surges also like take out the network connection hardware too.

It is probably more likely to have a power interrupt during a write
which causes sufficient corruption which the general consumer would
then characterize as something where his PC 'crashed' and didn't work
properly afterwords. In many cases, a reformat can resolve the
problem.


-hh

 

while that will certainly fix it, running a disk utility is likely to
fix the corruption and avoid the hassle of a reformat.

 

I was constraining the correction to the PC enclosure around the
computer and hard drive.

Where the network (home) is concerned the modem (DSL or cable) is
vulnerable if it has AC directly, phone or cable directly. (Mine has AC
(no wall wart) and the cable lines - direct - however all cables
(electric, phone, cable) are buried here so not as much risk as where
the wires are in the air).

All my power for the computers in my home office flow through a power
strip alleged to handle spikes.

That said, I've been considering an APC recently - not to prevent a
blackout stop, just to tame surges. We had a wicked lightning storm
last month and within a couple minutes the power sagged many times. The
iMac didn't stop however. But there will be a point one day... I'd
rather have the time to shut things down in an orderly manner (or have
the computer do so automatically when the APC tells it to). Likewise my
Drobo which is my primary backup.

Home routers/WiFi widgets are usually fed by a wall wart. Its
transformer will take the brunt of a surge and its AC|DC converter will
absorb most of the rest (esp. more recent switching designs v.
rectifier/capacitor/inductance designs). And then even if that DC out
'surged' a little, the front-end of the power supply in the router/wifi
would deal with the rest.

Sure, but I would bet most computer HD's have a lot of corrupted files
that don't affect the OS enough to cause much real harm over the short
term. It can take a lot of corruption before there is a serious issue
that isn't re-written with other (good) state data in the meantime.

 

Fair enough approach. I'm basically alluding to a lightning strike
entering the house via the telephone (or CATV) line instead of (or in
addition to) the conventional AC power. The reason I'm aware of it is
that a friend does IT on a small tropical island that has dirty power
due to thunderstorms and even when they've adequately isolated power,
they've still gotten fried PCs because the communications connection
wasn't similarly isolated.

FWIW, most of this was back in the days of 56K modems, but a hardwire
connection is another conduction path which requires isolation. The
good news is that the rise of WiFi has helped quite a bit, as it takes
out the router (cheaper) instead of the laptop (not cheap, nor as
serviceable).

Ultimately, it all comes down to where the corruption was done, and
how many such events have occurred without the operator performing
proactive maintenance. Just as there's plenty of consumers who don't
keep up with robust backups, there's also plenty that don't invoke any
specific maintenance on their hard drive such as this. The net
cumulative effect is that eventually there can be too much, and then
the machine is hors de combat and labelled as having 'crashed'.


-hh

 

An interpreter is the opposite of a compiler.

Wine [note the correct spelling: it's not all upper case!] is not
reading the source code of a windows program, it's thus neither
an interpreter nor a compiler.

"Wine translates Windows API calls into POSIX calls
on-the-fly" (http://www.winehq.org/about/)

No interpretation anywhere. You may try to say the right
thing, but you are using technical terms wrongly.

On different hardware, while running CPU and IO intensive
background processes, with bad drivers and misconfigured
or broken 3D on your Linux box.

Depending on the circumstances (especially drivers) Wine can be
faster than running the same application natively on Windows.

Why would you want cross-platform development, when native
development is much easier, and in this case, very feasible?

Would you also want to teach a monkey to use your camera and
photograph the same stuff you'd be able to photograph yourself
without any trouble?

Apart from being wrong (Wine isn't Linux only) ... are you
suggesting they should be trying to get programs to run that
people who are the target audience for Wine aren't interested in?

The API is identical to the API of Windows, so go ask Microsoft
for complete documentation. The only difference are
a) bugs, which you should report and maybe even fix
b) unimplemented parts, which you should report as bugs

I see you don't grasp Wine.


-Wolfgang

PS: Try to use the common quote character '>'. '|' indicates
quoted text from an external source.

 

| Wine [note the correct spelling: it's not all upper case!]

Yes. But it is an acronym. And I figure it can be very
confusing for people unfamiliar with it when people just
start talking about "Wine". So I have to beg your tolerance
on that one.

| it's thus neither
| an interpreter nor a compiler.
| "Wine translates Windows API calls into POSIX calls
| on-the-fly" (http://www.winehq.org/about/)
|

Yes. An interpreter is generally thought of as something
that runs script. But what I said is that it's *essentially*
an interpreter. WINE intercepts Windows API calls and
"translates" them. That's essentially interpretation. It has
to interpret the content of function parameters in order
to work, because the function calls are to be adapted to
Linux versions. They are not direct calls. To be anything
more efficient it would have to be compiled. "Translate" is
not a technical term. I said "interpret" because that seems
the most accurate description of what's actually happening,
and it stresses the inefficiency inherent in WINE.

| Depending on the circumstances (especially drivers) Wine can be
| faster than running the same application natively on Windows.
|

If you say so. Anything's possible. In my own experience
I found WINE to be wanting in all aspects, but if you're
running Photoshop under WINE and it works well for you, then
that's all that matters.

|
| > I'd love to see Linux/WINE function as a Windows
| > development platform, but I'm not optimistic.
|
| Why would you want cross-platform development, when native
| development is much easier, and in this case, very feasible?
|

What I meant was that it would be nice if Windows
developers could write for WINE. (See below.)

| The API is identical to the API of Windows, so go ask Microsoft
| for complete documentation. The only difference are
| a) bugs, which you should report and maybe even fix
| b) unimplemented parts, which you should report as bugs
|

That's not the way it works. I worked with the WINE people
once, briefly. They were looking for Windows developers to
test their own software and report bugs. At first that seemed
like an interesting idea. And it seemed like it might be a way
to help Linux become more usable, at least for my own purposes.
But WINE does not provide a mirrored Windows API. This is why
I said above that I'm not optimistic about WINE for Windows
developers. (I have Microsoft API docs. That doesn't help.)

The way it worked was that the WINE people wanted me to
test my software, file official bug reports, and then take charge
of testing any reported bug fixes. Then it would be my job to
officially declare the bug fixed. The WINE people were not interested
in working together. They provided very little information about
about which Windows APIs worked well and what the bugs were with
other APIs. And the WINE APIs often do not match the Windows
APIs in terms of which library they're in. As a result of all that,
it was very difficult to find out very much about what functions
WINE was *really* providing, and what limitations there were in
each. (There were lots of limitations because they were trying to
translate one system to another and it didn't always work.)

From their point of view they were not providing APIs.
They were just trying to get Windows software to work. Since
they didn't want to cooperate with Windows developers on
creating functional Windows API analogs, there was no way for
me to know how I might improve my software to work with WINE.
There was no way for me to choose better APIs or to weed out
unsupported APIs from my software, or to adapt partially supported
API calls. There was nothing I could do except join the WINE
"boy scouts" and report bugs to my "superior". Maybe someday
my software would work without a hitch. Maybe not. The person
I was dealing with actually specifically said he did not want me
to adapt my software. Their plan was to just support specific
programs. I stopped taking part shortly after that because I was
really just in the role of bug-testing lackey.

I can only speak from my own experience, and that experience
is probably about 4 years old. (Though 4 years is just the blink
of an eye for WINE developers. In my testing I found that
everything I tried worked surprisingly well under WINE, but
nothing worked well enough to call it dependably useable.
Operations that required high speed showed how inefficient
WINE was. The effect was worse with indirect operations,
like using ActiveX controls. The effect was also worse when
using WINE library versions rather than Windows libraries. It had
nothing to do with "drivers". I'm not talking about complex
graphic rendering in games. I'm talking about basic operations
like sending messages to windows.

If you find Photoshop under WINE to work as well and as
dependably as Photoshop on Windows or Mac, then you
should make that clear and explain how you did it, for others'
sake. If not then you're misleading people by implying that
software under WINE is "as good and sometimes better" than
software on Windows.

 

And yet it's a very, very common task, be it email, facebook
or IPTC metadata in a photo.

Not regarding "machine".

It won't. There's much more than just photos.

Additionally, film never had a backup. Best you could do was a
degraded copy of the negative.

On the other hand, you can easily have your digital image lasered
on film, develop it and archive that.


Not that there are that many interesting photos around, and not
that huge numbers of photos haven't been destroyed, often enough
on purpose, even though they were film or glass plate!

I have never worked in an office where colleagues routinely whack
their drives with rubber mallets.

And while I've had several drives dying in my computers, I've
never had to restore anything from backup because of that.

-Wolfgang

 

Wine is no longer an acronym.
And RADAR still is one.

People are perfectly capable of looking for the context.
You're also not saying "the size of the hole in the bunch of
polished glass bodies held together by metal and plastics, which
goes in front of the black box which records images" when you're
talking about the aperture of a lens.

In the sense of an American Sign Language Interpreter, maybe.
Who does translate. Who doesn't "interpret" what's said and then
rephrases and changes the stuff he signs.

"Intepret" is completely wrong usage. You could as well say bokeh
is "mental haze" or "senility", based on the etymology of the word.
When we talk of Bokeh, we mean something very different.

Wine doesn't have to "interpret the content of the function
parameters". There's no need to divine what they mean ---
their meaning is explicitely given by the API definition.
There's no need to "interpret" the content, Wine doesn't
change the content, it just passes it through to the POSIX
calls. Only the latter have to "interpret" the contents.

Wine is compiled.

You're blinded by your own prejudices.
Do you really think all the Windows API isn't layer upon
layer of translating calls?

It's so. There are grossly inefficient parts in Windows.

I don't run Photoshop under anything. Why should I?

But feel free to run everything under Windows.

Well, what does Wine provide if not Windows APIs? OS X APIs?
Plan 9 APIs?
Inquiring minds want to know!

So you propose someone else should pay for software they don't
want and spend time testing it for things they don't use it for?

This is also irrelevant for you.
If you want to code for Linux, code natively, and write your
code in a way that you can port it to Windows. Or vice versa.
No need to misuse Wine.

You really try to misuse Wine.

Exactly. Noone is interested in developers coding against the
Windows APIs when they could better, faster, without "interpreter"
and translation code against the Linux (or Mac OS) APIs.

Improve Wine to work with your software instead.

And that's exactly the right way to handle that.

Obviously "dependably useable" means software that not only
does what you want, but also reads your mind first.

Why again did you want to code against WINE?
And how comes that sending messages to windows are operations
that require high speed?

Please provide a message ID where I literally said "as good and
sometimes better" in regard to Wine and Windows. If you're
using quotes, I'm sure you have quoted my words exactly, and
that's what I want to check now ...

-Wolfgang

 

Sure, but the hardware isn't what is limiting the throughput
productivity of the task of typing: it is the human performance of
the typist that is the bottleneck. As such, the differentiation
between 'Hardware A' versus 'Hardware B' is going to have to look
elsewhere.

Fine: let's call it "System".

Now that the pedantic semantics are out of the way, what else will you
try to bring up as a deflection, since you're clearly trying to avoid
the basic point being made?

Sure, digital data other than just photos will go 'poof' too. But
author/researcher Clifford Stohl (sic) made the point in his "Silicone
Snake Oil" book a decade ago: read his chapter on retrieving archived
NASA data: pedantically, you're correct in that the data hasn't been
utterly lost, but pragmatically, the forms in which it still exists
make it non-retreivable pragmatically. If you wish to disagree,
simply volunteer to donate your time to him to spend the touch labor
to run IIRC two full sized CONEX boxes ("tractor trailer containers")
worth of 80-column punch cards through a card reader ... oh, and
you'll need to provide the card reader hardware too.

The crux of the problem is that an ongoing investment is required to
offset the obsolescence of various forms of hardware ... for a similar
illustration, consider that you are holding a floppy disk with some
data you need - - where's your floppy disk drive with which to read
it? Oh BTW, it is an 8" floppy, not a 5.25" one.

Dubs are a backup. Sure, it isn't a "digitally perfect" copy in that
there's a loss of some image data, but one could nevertheless make
'backups'. And further, if one is talking about prints, there's still
the original negative too (typically not co-located too).

In any case, film has a more graceful failure mode: if 5% of a slide/
negative gets trashed, there's still the other 95% of the frame, which
differs from binary corruption in Jpegs or a lot of other formats.
Sure, this is an inevitable process, but so too was CD and DVD "Rot",
which was particularly problemmatic a decade ago...do you really think
that Uncle Bob has been proactive enough to have tested & re-burned
his optical media every 3 years over the past decade, or do you think
that he's simply assumed that it has been "safely" stored all this
time?

Sorry, but the odds are that Uncle Bob is an average guy who can't
even tell if the CHECKSUMs have been returning (& fixing) errors for
the past five years...all he is likely to know is that they'll "be
fine" but then suddenly stop working.

The reason why to keep something is ultimately up to the artist ... as
well as those that inherit the media later on: if the context/
providence isn't also retained, the product loses value. For example,
I have a literal box full of 19th century tin photos ... and their
context is that they're portraits of family members - - but the
identification of who's in each photo (and where/etc) wasn't retained,
so their value is reduced.

You're trying to be pedantic again. It isn't that drive crashes are
the primary failure mode, but that the generic layperson refers to any
such 'failure to boot' (etc) as a "crash", even if it was technically
a corruption or a messed up DLL: all they know is that they can no
longer access their data.

That's only one modality of failure from a more complex system, and
I'll give you a real world example for you to ponder:

http://www.huntzinger.com/photo/ADPA.snipertrainer

Right-click on the above to save a local copy and then get to work to
display this file to its original fidelity. It is a data file from a
very well known & longstanding Microsoft product and yes, its
electrons are perfectly 100% intact. The challenge is to view it in
its original condition.

Good luck. I've been using this example online for at easily six
years and no one has succeeded yet. Provide a .PDF of your effort and
if it agrees with mine, I'll pay you $50.



-hh

 

[/QUOTE]

That was my point THE WHOLE TIME. And why I choose that
counterexample to your
| a machine which is merely _sufficient_ for a conducting
| particular workflow versus a machine that can perform the same task(s)
| more quickly will result in a workflow productivity gain.

[snip, since you already ceeded the point to me]

[blah blah not always totally lost blah blah]

So basically you think photos are by far the most valuable source
for historians and other people looking back into the past.

I ... disagree.

| Definition of BACKUP
| 1 a : one that serves as a substitute or support <a backup plan>
[...]
| 3 : a copy of computer data (as a file or the contents of a
| hard drive); also : the act or an instance of making a backup
[...]
| First Known Use of BACKUP
| 1951
http://www.merriam-webster.com/dictionary/backup

Try to use a dub to make a large print that already strains the
quality of the original. Unless you don't do large prints a dub
won't serve as a substitute.

Ah, really?
If 5% of a slide or negative gets trashed, the value of the image
is gone. Noone will buy a print of it.
If 5% of a JPEG (or RAW) gets trashed, you just pull a fresh
copy from one of the copies in one of the archives or from one
of the backups.

I assume that he was more aware of the problem than of film rot and
vastly more capable of doing something against it.

Uncle Bob could trivially make more than one copy of a CD or DVD,
and later combine the working parts. Uncle Bob could trivially
make a copy some years later, and still get most or all of the
stuff undamaged.

Uncle Bob can't do that with film, couldn't back then, he had
no "film writer", but he has a DVD writer. And even if he
could have the film copied --- at degraded quality --- it
would just go on rotting, losing colour. Making a new copy
won't rewind the clock at all. It does with digital data.

The odds are that Uncle Bob stores his photos in the damp garage
in a shoebox, complete with mildew. They'll be bad within a
couple years.

Irrelevant, since the "valley of death for photo images" is only
relevant to historians if photos of historical values will be
lost in much higher numbers than in earlier times.

[... ha-ha claims "crash" == any "'failure to boot'" ... he's
the photographer Charles L. Dodgson's Humpty Dumpty, who
changes the meaning of words every time ...]

So *you* lose data when a technician fixes the MBR you mixed up?
Or repairs a DLL you broke? I don't.

Nor do I know anyone who's computer won't boot due to fire,
water damage, etc. to call that a "hard drive crash" ...

Maybe you and yours don't have much understanding of computers.

This "Content-Type: text/plain" isn't plain, and probably not text.
Your webserver is misconfigured. THAT's the real world problem.

[ha-ha claims it's some 'correct' proprietary format of some
unspecified microsoft product]

We were takling about photos in well documented formats. Like
JPEGs. Not proprietary crap.

If the file is undamaged, then you can trivially "open" it
with the correct software --- which you'll know and have if
you happen to have "open"ed it before. Problem solved.

Otherwise I can give you
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.12 (GNU/Linux)

jA0EAwMCEzCS4vwCLV1gyTf5IrTTYYeWmGdbzQhZCFvZkUr5KMsR2sFmRPK2SbG9
jqPt7BEFjxBkD7KnALoseUiLAfw7gkwu
=8T7u
-----END PGP MESSAGE-----
and tell you to open THAT. I'll even tell you which software
that is. Problem also solved.

-Wolfgang

[1] Kodachrome being a lucky accident.

 

If it truthfully was, then you performed very poorly in expressing
yourself.

No.

If you hadn't noticed, <rec.photo.digital> is a photo-centric
discussion group.

Oh, and your contrived strawman is clearly disingenuous.

No, not misconfigured: simply another clue.

You were also given the free clue that I've used this example before
and that all have failed. A quick Google search would have revealed
that it is Microsoft's Powerpoint and exactly which version thereof.

And Photoshop isn't proprietary? You're simply trying to make excuses
for your failure to open the file.

As I already have stated: the file is complete, whole, and
undamaged.

And for YA free clue, while Microsoft Project still exists, it has
undergone updates over the years, but it will not open this file
correctly today, even if one appends a .PPT onto it: the reason why
is because MS dropped support for this version of their file format
several revisions ago. As such, the only practical way to retrieve
this file is if the Application, OS for that Application (and possibly
hardware also) had also all been retained.

So...the answer is to open it in PowerPoint v4. Think you can find a
copy of that App today? As well as the correct OS to run it? And the
hardware to run that correct OS flavor?

Golly, what a slippery slope!

Sure, this happens to be a specific example, but the reality is that
there's been a regular parade of revisions to OSs, Applications and
even file data formats which all have to be identified and included in
one's data archiving plans.

So while you may try to hang your hat on JPEG as being your
format...let's start with a simple question: are you referring to
JPEG, JPEG 2000, or the JPEG XR standard?

In other words, do you even know which flavors of JPEG you're using
that you need to provide support for?

JPEG hasn't remained perfectly static either, and there's been no
guarantee made that it won't be changed tomorrow. Similarly, you have
no assurances from today's application developers that they will never
drop the older JPEG file formats.


If you don't incorporate all of these factors, then your "data
management plan" relies on luck.



-hh


PS: I found it particularly ironic how you got all pedantic about
"DUPES vs Backups" and then recommend the lossy file format of JPEG.

 

"Only so far as the computer is slowing down the user. (Example:
typing a text. The computer does nothing but wait for the
user.  Waiting faster doesn't speed up the user or the task.)

Hmm. I wonder ... what's so hard to understand here? Could some
kind soul help me out how this could be construed differently?

Or does your "truthfully" mean "so you wer e*only* talking about
typing text?". In that case, no, it was an example ...

I had, but how comes historians must *also* be photo-centric when
naming periods?

Oh, you might wish to learn about JPEG and restart markers,
so your claims aren't clearly uninformed.

RFC2046:
| The five discrete top-level media types are:
|
| (1) text -- textual information. The subtype "plain" in
| particular indicates plain text containing no
| formatting commands or directives of any sort. Plain
| text is intended to be displayed "as-is". No special
| software is required to get the full meaning of the
| text, aside from support for the indicated character
| set. Other subtypes are to be used for enriched text in
| forms where application software may enhance the
| appearance of the text, but such software must not be
| required in order to get the general idea of the
| content. Possible subtypes of "text" thus include any
| word processor format that can be read without
| resorting to software that understands the format. In
| particular, formats that employ embeddded binary
| formatting information are not considered directly
| readable. A very simple and portable subtype,
| "richtext", was defined in RFC 1341, with a further
| revision in RFC 1896 under the name "enriched".

It's definitely not PLAIN. "Plain text is intended to be displayed
"as-is". No special software is required to get the full meaning
of the text, aside from support for the indicated character set."

And since you don't indicate any character set, the character
set must be US-ASCII-

Hence: your webserver is misconfigured, THAT's the real world problem.

MS PowerPoint is NOT Text/Plain.

Only Photoshop produces JPEGs?

Free clue: you're an idiot.

Yep, that's it. RFCs are completely unimportant (even though
they define how the internet works). Your "errors" are just
other people's "excuses". That's it to a tee. You're incapable
of errors.

As is this here:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.12 (GNU/Linux)

jA0EAwMCFjsDbilYgR1gySe/HQRJuMBCa70VMH86bpEYeOwxMA+qDjg6eJIkuaAf
j0nwylimvCc=
=zvSs
-----END PGP MESSAGE-----

Feel free to try to open it. The program is clearly named,
the file type is explizitely mentioned and the clue is that you
aren't very bright.

[blah blah]

Simple question: Why didn't you write "are you referring to JPEG,
JPEG, or the JPEG standard?" If you can answer that, you know
the answer.

Cue open software.

JPEG doesn't need to be lossy. Which you knew, didn't you?

-Wolfgang

 

You've already had your chance from this 'kind soul'; you'll have to
go find another who thinks that you're somehow still redeemable.

Stone Age ... Bronze Age ... Iron Age ... Steel Age ... Industrial
Revolution ... Information Age ... and today's "Straw Man Age"! ...
verily, you are correct in that these are all quite "photo-centric" in
their historical naming conventions when you tried to put words in my
mouth!

Keep on trying to snipe and cherry-pick...so as to persist in ignoring
the big picture.

Read what's above again: "...intended to be displayed...".

The webserver configuration you're referring to is simply to aid the
Web browser & OS for auto-loading the appropriate plug-in/application
for known file format types. This is merely an aid which does not
change the contents of the underlying file...just how the system will
**automatically** try to treat it. If a file happens to be of an
unknown file format type, it defaults to 'text'.

BTW and furthermore, since I directed you to right-click & save the
file locally, this auto-config feature does not apply. But since you
think that it will make a difference, I've taken a copy of the
original file, revised its name to add a '.PPT' on the end and
uploaded it to this address:

http://www.huntzinger.com/photo/ADPA-snipertrainer.ppt

And as I said before, this won't make any damn difference in you
actually viewing the file: the only difference that this change will
make is that within an OS, double-clicking the downloaded file will
automatically launch Powerpoint to *try* to then open the file.

Of course, the keyword here is "try": it will still fail to open/view
the file properly, because as I said, Microsoft Project no longer
supports all of Microsoft Project's historically prior file formats.

Nor was/is the file in question. As I said before, you're simply
reaching for any excuse that you can, to try to save face because this
indeed was a "successfully archived" file that now can't be read by
the current version of the application that created it, because the
archiving strategy was incomplete.

This is a data archiving failure and it is indicative of the
insidiously holistic nature of data archiving lifecycle management:
there's more to it than merely successfully keeping the data file,
even if said file was faithfully stored in what was an 'industry-
standard' format at the time of its creation.

No, and non sequitur.

The point was that no software vendor today - - not even Adobe - - has
provided a bonded written guarantee that the file formats that they
currently support will continue to be supported for the next 10, 25 or
50+ years.

And do note that this is not saying anything about if a file format
happens to be proprietary or if it is an open standard: there's still
no such assurance. Sure, you can pedantically argue that with an open
standard, you're technically free to write your own Application to
access the data, but DIY'ing is not particularly practical,
particularly for all of the "Uncle Freds" of the world where 99.99% of
the data will be residing.

Unfortunately your crass remark now invokes Bell's Law: the first
person to resort to name-calling forfeits the argument.

Just go read Clifford Stohl's book on the subject.


-hh

 

I see. You are unable to explain how you could have misunderstood
me and thus attack me.

You have a strange way of saying that I was right.

A binary file produced by PowerPoint is *never* intended to
be displayed "as-is".
And it's still not PLAIN.

Nope. application/octet-stream is nearly always the right
type for unknown file formats.

You wouldn't need to 'direct people to right-click & save' if
you used the correct type: it would either open in the right
application or be offered to be saved.

I see, you are able to learn, though it's really hard work.

That's why you don't use an obscure, closed, undocumented
format and choose something like JPEG.

[...]

I see you have learned the real value of 'industry-standard'.

Now you only need to learn the real value of open, well documented
and widely used formats, together with open source implementations
reading the same.

That's why I asked: your "Photoshop isn't proprietary" seemed
quite a non sequitur.

Read above, the part with "open, well documented and widely
used formats". Think about that that means that many, many
people implenented it, and can re-implement it, as long as a
single documentation in some form survives. And yes, you can
save the documentation in text/plain (the real McCoy, not your
PowerPoint-way), so it's very durable.

Read above, the part with "open source implementations reading
the same". Think about what it means when you actually have a
number of working implementations that you --- worst case ---
only need some computer programmer to adapt to the then-current
computer stuff. And ask yourself: how likely is it that in 100
years there will be no way to read JPEGs and translate them into
the then-current, well documented, widely used, open format ---
assuming you managed to miss a full 100 years somehow ...

Yep, that's where some will DIY and sell the service,
some will DIY and sell the program,
some will DIY and open-source the program,
and at least a few people will not only archive the JPEGs,
but also the source code and tools to build such programs
without any DIYing needed.

That was perfectly obvious to almost anyone.

Unfortunately, you can't stand the truth.

I see you haven't managed to decode the secret file I gave you.

-Wolfgang

 

Incorrect, because what you're overlooking is that the ".PPT" suffix
didn't exist as part of the naming convention under this particular
application at the time of its file creation, so there is no one
single "correct" way to configure a contemporary webserver for this
class of files.

The alternative was to rename the file to add .PPT - - - but to do so
represents a post-creation alteration of the original contents of the
original file: if that had been done, you would now be bitching about
the file's providance having being "corrupted" by that post-creation
renaming.

As such, the "least bad" choice is to leave the original file
perfectly intact. This does require additional handling of the right-
click as directed, but that's hardly a burden when the target
application information is also provided (as was done here).

The format for the 5.25" floppy 'twas also well documented.
So how's it doing today as a standard?

Sorry, but incorrect: the lesson is that all standards are always
transient and temporary.

They only exist for a window in time, and to maintain data over longer
periods, a maintenance strategy is required to be implimented ...
which consumes resource investments _over_ time. That makes the
process more perishable.

That's still not a bonded guarentee from anyone that reduces future
risks.

That's also not a bonded guarentee from anyone that reduces future
risks.

Of course, the answer to that question has already been provided
before. As I already have said, go read Clifford Stohl's 1995 book on
the subject: Stohl published specific examples, including instances
where the data had been **successfully** archived in **multiple**
published/open formats by NASA, and yet data mortality still
occurred.

Here's my tangible suggestion to you: instead of continuing to rail
against my message, simply go read Stohl's book, find the section on
the archived NASA data, contact NASA and recover the data, and provide
it to Stohl. Not only will Stohl probably be quite happy, but you'll
prove beyond any doubt that the core of your assertion: an individual
can muster the resources to revive data published in a "dead" yet open
format. Granted, this one is only 50 years old, not 100 years that
you're suggesting, but it is a real world example that you can go
tackle to prove your point and show that I'm wrong.

And to keep this sporting, do provide us with monthly updates on your
progress.



-hh

 

Obviously you've been misinformed. Suffixes are informatory only
(except on DOS and Windows, where they stupidly replace file
attributes like "executable"). That's why e.g. web servers do
transmit the file type instead of just relying on the suffix of
the ending. (And that's why getting a .php-file doesn't mean
your local PHP is supposed to start up and execute the file.)

What's in a name? that which we call a rose
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By any other name would smell as sweet;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So Romeo would, were he not Romeo call'd,
Retain that dear perfection which he owes
Without that title.


There's *no* tie between a convenient handle for a bag-o-bits
(which may or may not have the 'correct' suffix) and the contents
of the same bag. However, telling others the bag-o-bits contains
(and is to be interpreted as) plain text when it's in fact not is
deliberately misleading both browsers and people

Call your JPEG (not JPEG XR, not JPEG 2000, ...) encoded picture
"me and my dog.jpeg" or "HXWE2341.JPG" or "mumble" --- if it's
the same bits, no harm done. (And that it's you and your dog
should be in the IPTC metadata embedded in the file, yet distinct
to the photo itself.) All you need to do is tell the receiving
site that the bag-o-bits is a image/jpeg.

If you actually had a clue, you'd know that that's not true.
It's easy enough to tell a (competent) webserver to serve a
file as a specific file type even when there's no matching
suffix.

https://httpd.apache.org/docs/current/mod/core.html#files
https://httpd.apache.org/docs/current/mod/core.html#forcetype

And delivering with the correct MIME type is also hardly a
burden, but one that needs to be borne only ONCE, not *every*
*single* *time* someone downloads the file.

Are you really stupid enough to not understand the difference
between a *file format* of a file[1] and a hardware method of
storing arbitrary data[2]?

[1] which can be stored on CDs, DVDs, magnetic tape, hard drives,
barcodes on paper, 2d-barcodes on microfilche, "in the cloud"
and many other technologies ...

[2] so completely arbitrary that the data contained can be
copied to any other storage technology and continue to
work (except for some programs that have a usage
protection relying on some (mis)feature of the original
data carrier system)?

Oh, BTW: JPEGs that were stored on 5¼" disks have been very
successfully migrated to 3½" "floppy" disks and to hard
drives and flash ram and DVDs and BlueRays ... they continue
to work like they did on the first day.

Yep, if a galactic catastrophe wipes out the whole galaxy and
neither humans nor their (receiveable) signals, drones and probes
haven't managed to reach another one, then all standards will
have been lost.

Other standards are pretty hard. "Thou shalt not murder",
for example.

Of course you are --- sort of --- right. The standards of
old Egyptian hieroglyphs and Cuneiform have been lost in time.
And yet we managed to decipher them after more than 1.5 millennia.

Please note the rosetta stone. That's the "open and well
documented format" part.


It's extremely unlikely that all JPEG decoders along with the
information how JPEG works will be lost in this century barring
a global catastrophy. It's unlikely that that knowledge will
be lost in a span of time when chemical film and prints will
already have lost their usefulness. A recoding to whatever is the
then-common format can be done fully automatic by the computer ---
quite unlike translating hieroglyphs.

There's no bonded guarantee the Earth will not turn into a
black hole tomorrow, either. Your point?

There's no bonded guarantee the Earth will not turn into a
black hole tomorrow, either. Your point?

The same Strohl book where he told us that e-commerce is "baloney"
and nonviable, due to lacking interpersonal contacts and no secure
online funds transfer. *Poof* implodes the internet ...

Like "they used a good format and forgot the tapes in the cellar
until the tapes were in so bad shape that they couldn't be read"?

It does not really matter if the format is "dead", "brand new",
"common" or "rare", except that in all but "common" you may have
less data to test your code against it.

So you want me to decode the data. Fine. *You* provide me
with the correct and exact description of the formats, *You*
provide me with the read-error free data that's to be
decoded. That's my challenge to you.

*Then* I'll recreate a reader for said format(s). Which may not be
trivial, but what about anyone skilled in the field is able to
do. (And make no mistake, NASA has lots of clever people
perfectly capable of such a "feat".)

I bet you won't be able to hold up *your* end. Because that's
where the trouble really is: either the format description is
faulty or lacking or the data is anything but error free.

-Wolfgang

 

Keep on trying to convince yourself of that. What you've not realize
is that the period in this filename is not a delimiter for a file type
identification suffix.

When you saw that the original name wasn't an '8.3' but was a '4.13',
you should have gotten a clue.

Romeo is dead. So are some file formats. This is an example thereof,
and why this "successfully archived" file still is not recoverable.

Irrelevant since it doesn't apply because you were directed to right-
click to retrieve a filecopy to work with it locally. Unfortunately,
this fact won't stop you from attempting to misdirect.

Given the amount of text & time that you've invested on equally
irrelevant points, we can all see that your assertion is patently
false.

True, but once again, you're dwelling on a point of misdirection so as
to try to avoid the real issues.

Because there is no suffix, to automate a webserver's assignment to a
particular MIME type is limited to relying on the individual file
name. And sure, this only needs to be done once per file, it does
have to be done for each and every such file. In other words, if this
example really was an archive of 100 unique archived files, the
webserver's list would also be 100 lines long (one for each filename).

Feel free to prove me wrong by documenting what Applications have ever
used a 13 digit long suffix.

You tried to base your argument on how well known/documented the
format is. The physical format of the data onto its storage media is
merely another part of the holistic system.

Once again you choose to miss a major point: it isn't that it
couldn't be done, but that it required active resources across time to
be invested.

If someone provided an old floppy today - - just how would one go
about recovering the data thereon onto another format (eg, DVD)? One
can't exactly just driver over to the local brick & mortar computer
store and buy these old disk drives anymore. And even if one finds
the drive, that's only the start of the battle.

And fifteen years ago, we would have made similar claims about how
unlikely it would be for floppy disk technology to vaporize.

And on chemical film technology, just where can I get a roll of
Kodachrome developed today which won't cost an arm and a leg? Be
specific.

Yes, that's one of the examples:the archive was lost because there
were not **recurring** investments made over time.

This is substantiating evidence that our current digital tech has
substantially higher maintenance requirements than things like those
Egyptian hieroglyphics you mentioned.

Sorry, but that's trying to move the goalposts.

Until you recover the file I previously provided, you've shown that
you're not worth the effort of even testing to see if your current
"promise" isn't simply more bullshit.

Your claim was that the concerns I expressed are a trivial non-
problem, yet you've not even been able to successfully decode my one
example of a successfully archived file that is read-error free and
whose originating application is known.

If it really was as trivial as you claimed, you would have been
successful two months ago and RPD would have been spared the past two
months (yes, since August!) of your impotent whining.


-hh

 

*I* realized that.

When I saw "text/plain" I got the right clue. I didn't look at
the filename for info.

So are some brain cells!
Neither Romeo nor file formats have anything to do with renaming
files to add '.PPT'

This is mostly an example of how someone who doesn't have a real
name also doesn't have basic skill of telling a webserver what
type of files it is supposed to serve.

And an example of how someone who doesn't have a real name also
doesn't have the skill of reading what is written or keeping
the context.

I see ---
I misdirect, you "return to the topic at hand".
I say irrelvant things, you "state profound truths".
I don't follow directions, you "do things the way you want".
I talk about JPEGs, you "use dead file formats".
I move goalposts, you "adjust the thread to reality".
I talk about file formats, you "think floppy disks are formats, too".

Given the fact that you haven't properly corrected your URLs
(but rather removed the files) even after I gave you all the
hints a five year old would need, I can only conclude that you
don't have the technical aptitude to use computers, and thus a
blind-from-birth person talking about colours would be as relevant
and insightful as you talking about file formats.

The real issue is that you are too stupid to handle basic computing
tasks. It's better for everyone to bear a burden slightly smaller
than the one you might bear once *every time*, right?

Then by your own logic (or technical inaptitude) let them who
receive the files deal with them in 100 years rather than us
doing any sensible thing now to improve their chances. So
what are you jammering at, exactly? You're just as bad.

Wrong.
Are you able to come up with a counter example all by
yourself, or do I need to tell you so you'll call it
irrelvant again?

Irrelevant: It's not.

There's *no* suffix in
http://www.huntzinger.com/photo/ADPA-snipertrainer
and there's only 3 character (1 digit long) suffix in
http://www.huntzinger.com/photo/ADPA-snipertrainer.PPT
.. Anyone with a functioning brain, one tiny handful of fingers
or toes and an eye or Braille display can see that.

So, where's that mythical file with 10^13 characters of suffix,
and how do you fit it in 256 or 1024 characters (usual maximum
lengths for filenames/paths)? There's not even one with 13
characters suffix ...

Me thinks you're completely off your rocker by now.

A *file* format, yes.

Which is completely irrelevant, as it can be copied to a new
storage media by a trained monkey, even if you're not up to
the task.

So use an MDISC already. 1000 years should be long enough
for a millennium.

You're really too stupid. Ever heard of 'da interweb'?
http://www.ebay.com/sch/i.html?_nkw=5.25+inch+floppy+disk+drive
https://www.google.com/search?q=5.25" floppy disk drive&tbm=shop
http://www.disktransfer.co.uk/floppy-disk-data-file-transfer-recovery.php
(first page on google for >5.25" floppy disk drive<)
http://datarecoveryspecialist.com/floppy_data_recovery.htm
http://www.datarecoverymasters.com/floppy_disk_data_recovery.php
(both on first page of google >floppy disk data recovery company<)
And then there is
https://www.google.com/search?q=data+recovery+service+floppy+disk
.... hits, hits and more hits. I'd tell you to "Login to
www.clue.org and issue the GET command" but I don't think you'll
manage to even understand what you're supposed to do, you'd
probably land on a cluedo site and think you're Sherlock Holmes.

Trivial, see above. Not that I wouldn't have a couple lying
about ...
Try again, simplebrain.

You can simply use some money, and that's it.
Try again, simplebrain. And try not to spout too many
wrong and irrelevant claims this time.

Really? Would "we"? You, yes, surely.
Informed people knew: End of 1997 CD-ROMs had been used for
years for computers. The CD-RW had been available for a year ---
the CD-R even longer. Writers were coming down in prices FAST.
The obviously *much* larger storage capability compared to the
floppy disk was well noticed.

ZIP disks were another contender for floppy disk replacements.
Introduced 3 years ago, it was also well known.

I could go on.

Point is: while YOU might though it unlikely for floppy disks
to "vaporize", everyone with a functioning brain was well
aware it was on it's way out.

Again, this is completely irrelevant, since we're talking about
*file* formats.

So you happen to have 100 year old, exposed, undeveloped
Kodachrome lying around? How comes? Be specific.

And try tell us why undeveloped Kodachrome is relevant in any
way to the long term storage on floppy disks.

They used the wrong storage media, 'tis all.

You really think the papyrus they all used all the time
for everything was low maintenance, right? You'd have to
rewrite it regularly (and that's not as simple as putting a
tape/DVD/USB-Stick/whatever in connection with the computer and
click on "copy now"), or transfer it to clay tablets (which you
needed to burn and keep away from harm) or build a temple or
pyramid to inscribe the insides of. The middle ages had
leather to write on and paper --- and even though they copied
all the time in monasteries, most is lost.

Worse, practically everyone in Egypt was un-hieroglyphed.
They had to rely on memory; so storing accurate data was more
than iffy and high maintenance, same for duplication of said data.

That's trying to move the goalposts *back*.

Until you present the complete specification of the file you
previously "provided" ...

Deliver the complete, open specification for you "ADPA-snipertrainer".
I guess you can't, so now you again move goalposts.

I notice you snipped my 'NASA can recreate of a reader of an open
format (and likely better than me), so that's not the problem at
all', which is proof that you blustered and lied.

I also notice you haven't yet decoded that PHP, which does not need
an old closed source program for a closed, secret document format.


Which --- as you goal-post mover know --- is exactly what I
claimed was the wrong way in first place.

Your concerns are a trivial non-problem for widely used (i.e.
not PowerPoint Version 20-years-ago-not-available-anymore),
well and open documented (i.e. not PowerPoint Version
20-years-ago-not-available-anymore) file formats, for which
open source readers exist (i.e. not PowerPoint Version
20-years-ago-not-available-anymore).

You're trying to move goalposts again, and you don't even
notice? Are you *that* braindead?

I'm simply not interested in your stupid "decode this secret
proprietary unused format" games. Thus, I have not even tried.

-Wolfgang

 

Unfortunately, if your claim really is true, then it begs the question as to why you kept on harping on an irrelevant issue.

Unfortunately, if your claim really is true, then it begs the question as to why you kept on harping on an irrelevant issue.

Gee, see a pattern here yet? I do.

Yet another ad hominem personal insult.

Clearly, poster "Wolfgang" has decided that he can't win the disagreement based on its actual *merits*, so he tries to attack the messenger instead.

Unfortunately, if your claim really is true, then it begs the question as to why you brought up Romeo in the first place.

A particularly ironic remark from a poster at "The Original Disposable Email Address Company", sneakemail.com

And the hypocrisy is that I'm posting from my own domain, whose registration info isn't hidden at all...as if reading it off of the domain's homepage is not a "...handle basic computing tasks..." easy enough task.

I read on and simply see more ad hominem personal insult attempts.

I read on and see flat out lies: sorry, but I've not removed even a singleURL or file from my website.

Sorry, but you mistyped: the filename in question (which is still online) is:

http://www.huntzinger.com/photo/ADPA.snipertrainer

The irony of "...handle basic computing tasks..." bites a second time.

Oops, and yet another innocent "accident" on his part -- golly, what an amazing coincidence! I'm sorry, but the archives clearly show that what I said was that all media standards are temporary (transient), and I cited floppies as a recent real world example of said transient nature.


Sure, digital data can be archived successfully, but for ease of subsequentuse, it is not a "zero maintenance" activity, particularly in comparison to prior technologies which can more readily tolerate years/decades of benign neglect and still be adequately recovered. Similarly, it is pedanticallypossible to invoke heroic (and expensive) measures to recover something, but pragmatically, this won't be done for the vast majority of "somethings",because invariably, the potential (or perceived) value of said 'something'isn't known to justify the expense, usually because of the Catch-22 that said 'something' hasn't been adequately identified so as to make a value assessment. Finally, the process of data recovery isn't merely the format of the bits, but also the medium of how those bits are being stored - - it is both software and hardware, and the failure of either one makes the data permanently irretrievable.

Unfortunately, the tragedy is that this actual issue of how to subsequentlydecide how to manage digitally based data archives has been ignored, because it is more important to "Wolfgang's" ego to try to attack this Messenger, rather than to potentially acknowledge the validity of any part of the message.

Not only is this lame, but "Wolfgang's" public criticism of how my domain served up the files as "text/plain" says that he did try. Yet another untruth is thus revealed.

"Wolfgang" has surrendered all semblance of being capable of carrying on a reasonable conversation and not perpetuating even more outright lies between his Ad Hominem personal attack attempts and other quotation/citation "accidents".

Clearly, we are done here.

Any interested parties who wish to continue this conversation offline are free to contact me ... this email address forwards to a general account thatwill require a "yes I'm human" reply to self-whitelist prior to retransmission to counter spam. Otherwise, I'll never see it.


-hh