Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Digital Photography > Re: What makes a mac better?

Reply
Thread Tools

Re: What makes a mac better?

 
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      10-20-2012
-hh <(E-Mail Removed)> wrote:
> On Oct 7, 9:16*am, Wolfgang Weisselberg <(E-Mail Removed)>
> wrote:
>> -hh <(E-Mail Removed)> wrote:
>> > On Sep 18, 8:58*pm, Wolfgang Weisselberg <(E-Mail Removed)>
>> >> -hh <(E-Mail Removed)> wrote:
>> >> > On Aug 31, 6:30*pm, Wolfgang Weisselberg <(E-Mail Removed)>
>> >> >> -hh <(E-Mail Removed)> wrote:
>> >> >> > [...]
>> >> >> > Yes, although it is a bit more than merely sufficiency (although this
>> >> >> > can depend on how it is defined): *there's also a consideration for
>> >> >> > productivity.
>> >> >> > For example, 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.
>> >> >> 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.)
>> >> > Agreed, although the "text typing" as an example hasn't been computer
>> >> > limited for a good 35 years.
>> >> And yet it's a very, very common task, be it email, facebook
>> >> or IPTC metadata in a photo.
>> > Sure, but the hardware isn't what is limiting the throughput
>> > productivity of the task of typing:


>> That was my point THE WHOLE TIME.


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


"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 ...


>> >> > Personally, I expect that historians in the future will look back at
>> >> > the period of 2000-2025 as the "valley of death for photo images"
>> >> > because the digital medium to date simply hasn't been as real-world
>> >> > archival as film, due to non-robust data backup plans.
>> >> It won't. *There's much more than just photos.
>> > Sure, digital data other than just photos will go 'poof' too. *But


>> [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.


> No.


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


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

> Oh, and your contrived strawman is clearly disingenuous.


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


>> >> And while I've had several drives dying in my computers, I've
>> >> never had to restore anything from backup because of that.
>> > 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


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


> No, not misconfigured: simply another clue.


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.


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


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


MS PowerPoint is NOT Text/Plain.


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


> And Photoshop isn't proprietary?


Only Photoshop produces JPEGs?

Free clue: you're an idiot.

> You're simply trying to make excuses
> for your failure to open the file.


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.


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


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


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]

> 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?


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.

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


Cue open software.

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


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

-Wolfgang
 
Reply With Quote
 
 
 
 
-hh
Guest
Posts: n/a
 
      10-20-2012
On Oct 20, 10:20*am, Wolfgang Weisselberg <(E-Mail Removed)>
wrote:
> -hh <(E-Mail Removed)> wrote:
> > On Oct 7, 9:16*am, Wolfgang Weisselberg <(E-Mail Removed)>
> > wrote:
> >> -hh <(E-Mail Removed)> wrote:
> >> > On Sep 18, 8:58*pm, Wolfgang Weisselberg <(E-Mail Removed)>
> >> >> -hh <(E-Mail Removed)> wrote:
> >> >> > On Aug 31, 6:30*pm, Wolfgang Weisselberg <(E-Mail Removed)>
> >> >> >> -hh <(E-Mail Removed)> wrote:
> >> >> >> > [...]
> >> >> >> > Yes, although it is a bit more than merely sufficiency (although this
> >> >> >> > can depend on how it is defined): *there's also a consideration for
> >> >> >> > productivity.
> >> >> >> > For example, a machine which is merely _sufficient_ for a conducting
> >> >> >> > particular workflow versus a machine that can perform the sametask(s)
> >> >> >> > more quickly will result in a workflow productivity gain.
> >> >> >> 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.)
> >> >> > Agreed, although the "text typing" as an example hasn't been computer
> >> >> > limited for a good 35 years.
> >> >> And yet it's a very, very common task, be it email, facebook
> >> >> or IPTC metadata in a photo.
> >> > Sure, but the hardware isn't what is limiting the throughput
> >> > productivity of the task of typing:
> >> That was my point THE WHOLE TIME.

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

>
> "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?


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.

> >> >> > Personally, I expect that historians in the future will look backat
> >> >> > the period of 2000-2025 as the "valley of death for photo images"
> >> >> > because the digital medium to date simply hasn't been as real-world
> >> >> > archival as film, due to non-robust data backup plans.
> >> >> It won't. *There's much more than just photos.
> >> > Sure, digital data other than just photos will go 'poof' too. *But
> >> [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.

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

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


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!


> > Oh, and your contrived strawman is clearly disingenuous.

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


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


> >> >> And while I've had several drives dying in my computers, I've
> >> >> never had to restore anything from backup because of that.
> >> > 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
> >> This "Content-Type: text/plain" isn't plain, and probably not text.
> >> Your webserver is misconfigured. *THAT's the real world problem.

> > No, not misconfigured: simply another clue.

>
> 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 textin
> | * * * * *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 includeany
> | * * * * *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.


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.


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

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

>
> MS PowerPoint is NOT Text/Plain.


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.


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

> > And Photoshop isn't proprietary?

>
> Only Photoshop produces JPEGs?


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.


> Free clue: you're an idiot


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
 
Reply With Quote
 
 
 
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      10-23-2012
-hh <(E-Mail Removed)> wrote:
> On Oct 20, 10:20*am, Wolfgang Weisselberg <(E-Mail Removed)>
> wrote:
>> -hh <(E-Mail Removed)> wrote:
>> > On Oct 7, 9:16*am, Wolfgang Weisselberg <(E-Mail Removed)>
>> > wrote:
>> >> -hh <(E-Mail Removed)> wrote:
>> >> > On Sep 18, 8:58*pm, Wolfgang Weisselberg <(E-Mail Removed)>
>> >> >> -hh <(E-Mail Removed)> wrote:
>> >> >> > On Aug 31, 6:30*pm, Wolfgang Weisselberg <(E-Mail Removed)>
>> >> >> >> -hh <(E-Mail Removed)> wrote:
>> >> >> >> > [...]
>> >> >> >> > Yes, although it is a bit more than merely sufficiency (although this
>> >> >> >> > can depend on how it is defined): *there's also a consideration for
>> >> >> >> > productivity.
>> >> >> >> > For example, 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.
>> >> >> >> 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.)
>> >> >> > Agreed, although the "text typing" as an example hasn't been computer
>> >> >> > limited for a good 35 years.
>> >> >> And yet it's a very, very common task, be it email, facebook
>> >> >> or IPTC metadata in a photo.
>> >> > Sure, but the hardware isn't what is limiting the throughput
>> >> > productivity of the task of typing:
>> >> That was my point THE WHOLE TIME.
>> > If it truthfully was, then you performed very poorly in expressing
>> > yourself.


>> "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?


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


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

>> >> >> > Personally, I expect that historians in the future will look back at
>> >> >> > the period of 2000-2025 as the "valley of death for photo images"
>> >> >> > because the digital medium to date simply hasn't been as real-world
>> >> >> > archival as film, due to non-robust data backup plans.
>> >> >> It won't. *There's much more than just photos.
>> >> > Sure, digital data other than just photos will go 'poof' too. *But
>> >> [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.
>> > No.
>> > If you hadn't noticed, <rec.photo.digital> is a photo-centric
>> > discussion group.


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


> 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!


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


>> > Oh, and your contrived strawman is clearly disingenuous.


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


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


?


>> >> >> And while I've had several drives dying in my computers, I've
>> >> >> never had to restore anything from backup because of that.
>> >> > 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
>> >> This "Content-Type: text/plain" isn't plain, and probably not text.
>> >> Your webserver is misconfigured. *THAT's the real world problem.
>> > No, not misconfigured: simply another clue.


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


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


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

> 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'.


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


> BTW and furthermore, since I directed you to right-click & save the
> file locally, this auto-config feature does not apply.


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.

> 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


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


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


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

[...]
> 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.


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.


>> >> We were takling about photos in well documented formats. Like
>> >> JPEGs. Not proprietary crap.
>> > And Photoshop isn't proprietary?


>> Only Photoshop produces JPEGs?


> No, and non sequitur.


That's why I asked: your "Photoshop isn't proprietary" seemed
quite a 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.


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


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


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.

>> Free clue: you're an idiot


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


Unfortunately, you can't stand the truth.

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


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

-Wolfgang
 
Reply With Quote
 
-hh
Guest
Posts: n/a
 
      10-24-2012
On Oct 23, 12:22*pm, Wolfgang Weisselberg <(E-Mail Removed)>
wrote:
> -hh <(E-Mail Removed)> wrote:
> > [...big snip...]

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


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



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

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


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


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

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


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.


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


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

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


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


 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      10-31-2012
-hh <(E-Mail Removed)> wrote:
> On Oct 23, 12:22*pm, Wolfgang Weisselberg <(E-Mail Removed)>
> wrote:
>> -hh <(E-Mail Removed)> wrote:
>> > [...big snip...]


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


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


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

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


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.

> 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,


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/curren...ore.html#files
https://httpd.apache.org/docs/curren...html#forcetype

> but that's hardly a burden when the target
> application information is also provided (as was done here).


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.

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


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


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


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.


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


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


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


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.


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


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.


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


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


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


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


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


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


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


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

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


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"?

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


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.

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


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
 
Reply With Quote
 
-hh
Guest
Posts: n/a
 
      11-02-2012
On Oct 31, 1:03*pm, Wolfgang Weisselberg <(E-Mail Removed)>
wrote:
> -hh <(E-Mail Removed)> wrote:
> > On Oct 23, 12:22*pm, Wolfgang Weisselberg <(E-Mail Removed)>
> > wrote:
> >> -hh <(E-Mail Removed)> wrote:
> >> > [...big snip...]
> >> 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.

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

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


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.


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

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


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


> 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


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.


> > 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,

>
> If you actually had a clue, you'd know that that's not true.


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

> 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/curren...ore.html#files
> * *https://httpd.apache.org/docs/curren...html#forcetype
>
> > but that's hardly a burden when the target
> > application information is also provided (as was done here).

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


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.


> >> > 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.
> >> That's why you don't use an obscure, closed, undocumented
> >> format and choose something like JPEG.

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

>
> 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]?


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.



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


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.



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


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.


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

>
> 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"?


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.



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

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



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


> *Then* I'll recreate a reader for said format(s)....


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
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      11-02-2012
-hh <(E-Mail Removed)> wrote:
> On Oct 31, 1:03*pm, Wolfgang Weisselberg <(E-Mail Removed)>
> wrote:
>> -hh <(E-Mail Removed)> wrote:
>> > On Oct 23, 12:22*pm, Wolfgang Weisselberg <(E-Mail Removed)>
>> > wrote:
>> >> -hh <(E-Mail Removed)> wrote:
>> >> > [...big snip...]
>> >> 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.
>> > 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.


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


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


*I* realized that.

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


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

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


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


> Romeo is dead. So are some file formats.


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

> This is an example thereof,
> and why this "successfully archived" file still is not recoverable.


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.

>> 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


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


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".

>> > 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,


>> If you actually had a clue, you'd know that that's not true.


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


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.


>> > but that's hardly a burden when the target
>> > application information is also provided (as was done here).


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


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


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.


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


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?

> And sure, this only needs to be done once per file, it does
> have to be done for each and every such file.


Wrong.

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


Irrelevant: It's not.

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


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.

>> >> > 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.
>> >> That's why you don't use an obscure, closed, undocumented
>> >> format and choose something like JPEG.
>> > The format for the 5.25" floppy 'twas also well documented.
>> > So how's it doing today as a standard?


>> 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]?


> You tried to base your argument on how well known/documented the
> format is.


A *file* format, yes.

> The physical format of the data onto its storage media is
> merely another part of the holistic system.


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.

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


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


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


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


You're really too stupid. Ever heard of 'da interweb'?
http://www.ebay.com/sch/i.html?_nkw=...ppy+disk+drive
https://www.google.com/search?q=5.25...drive&tbm=shop
http://www.disktransfer.co.uk/floppy...r-recovery.php
(first page on google for >5.25" floppy disk drive<)
http://datarecoveryspecialist.com/fl...a_recovery.htm
http://www.datarecoverymasters.com/f...a_recovery.php
(both on first page of google >floppy disk data recovery company<)
And then there is
https://www.google.com/search?q=data...ce+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.


> And even if one finds the drive,


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

> that's only the start of the battle.


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.


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


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


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.


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


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.

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


>> 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"?


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


They used the wrong storage media, 'tis all.


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


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.


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


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


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


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


>> *Then* I'll recreate a reader for said format(s)....


> Until you recover the file I previously provided,


Until you present the complete specification of the file you
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.


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


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?


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


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

-Wolfgang
 
Reply With Quote
 
-hh
Guest
Posts: n/a
 
      11-02-2012
On Nov 2, 1:23*pm, Wolfgang Weisselberg <(E-Mail Removed)> wrote:
> -hh <(E-Mail Removed)> wrote:
> > On Oct 31, 1:03*pm, Wolfgang Weisselberg <(E-Mail Removed)>
> > wrote:
> >> -hh <(E-Mail Removed)> wrote:
> >> > Wolfgang Weisselberg <(E-Mail Removed)> wrote:
> >> >> -hh <(E-Mail Removed)> wrote:
> >> >> > [...big snip...]
> >> >> 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.
> >> >
> >> > 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.
> >>
> >> 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.)

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

>
> *I* realized that.


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


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

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


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.


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

> > Romeo is dead. *So are some file formats.

>
> So are some brain cells!


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.



> Neither Romeo nor file formats have anything to do with renaming
> files to add '.PPT'


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



> > This is an example thereof,
> > and why this "successfully archived" file still is not recoverable.

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


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


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


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.


> [...snip...]


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

> [...snip...]


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


> There's *no* suffix in
> * *http://www.huntzinger.com/photo/ADPA-snipertrainer


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.


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


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.


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

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


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.


> [...snip...]


"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
 
Reply With Quote
 
David Taylor
Guest
Posts: n/a
 
      11-03-2012
"What makes a mac better?"

- having the ability to run Windows, of course!
--
Cheers,
David
Web: http://www.satsignal.eu
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      11-05-2012
In article <k78hvv$5tu$(E-Mail Removed)>, David Taylor
<(E-Mail Removed)> wrote:

> To be honest, I think I've had more furstrations with the quirks of the
> iPad than I have had with Windows, but I would consider myself more
> familiar with Windows. I find it amusing that, to delete directories of
> photos on my iPad (what they call "albums"), I have to connect it to a
> PC (Windows or Mac). Otherwise I have to tap each photo individually to
> select it before deletion. There's no multi-file selection.
>
> Yes, Apple's forced way of working does drive you insane!


it's optimized for the common use case.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: What makes a mac better? tony cooper Digital Photography 109 08-31-2012 08:29 PM
Re: What makes a mac better? nospam Digital Photography 0 08-27-2012 08:39 AM
Re: What makes a mac better? nospam Digital Photography 2 08-26-2012 09:05 PM
Re: What makes a mac better? nospam Digital Photography 0 08-26-2012 05:57 PM
Re: What makes a mac better? nospam Digital Photography 0 08-26-2012 05:57 PM



Advertisments