Re: What makes a mac better?

Discussion in 'Digital Photography' started by ray, Aug 26, 2012.

  1. ray

    -hh Guest

    Alan Browne <> wrote:
    > On 2012.09.01 12:38 , nospam wrote:
    > >
    > > lightning is not a major cause of hard drive failures. in fact, it
    > > probably causes no hard drive failures at all. a lightning strike will
    > > normally affect the power supply of a hard drive, but not the hard
    > > drive itself, so all you need to do is put it in a new enclosure.

    >
    > Clarification.
    >
    > It would affect the PC power supply.


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


    > The HD has its own power supply being fed from the PC power supply.
    >
    > It's possible, but not likely, that the power supply will let a spike
    > through to other parts.


    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
     
    -hh, Sep 2, 2012
    #61
    1. Advertising

  2. ray

    nospam Guest

    In article
    <>, -hh
    <> wrote:

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


    while that will certainly fix it, running a disk utility is likely to
    fix the corruption and avoid the hassle of a reformat.
     
    nospam, Sep 2, 2012
    #62
    1. Advertising

  3. ray

    -hh Guest

    Alan Browne <> wrote:
    > -hh wrote:
    > > Alan Browne <> wrote:
    > >> On 2012.09.01 12:38 , nospam wrote:

    >
    > >>> lightning is not a major cause of hard drive failures. in fact, it
    > >>> probably causes no hard drive failures at all. a lightning strike will
    > >>> normally affect the power supply of a hard drive, but not the hard
    > >>> drive itself, so all you need to do is put it in a new enclosure.

    >
    > >> Clarification.

    >
    > >> It would affect the PC power supply.

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

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


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


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

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


    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
     
    -hh, Sep 2, 2012
    #63
  4. Mayayana <> wrote:

    >| >> Amen. But WINE is not an emulator. It is an application interface - big
    >| >> difference.


    >| > It's more code than Windows by itself.


    >| More code doesn't imply slower.


    > WINE is essentially an interpreter.


    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.

    > They've created
    > Linux libraries to interpret Windows API calls into Linux
    > functionality.


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


    > I haven't tried it since around .9+ or
    > 1.0, but at that time, at least, the lag was very
    > noticeable.


    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.


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

    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?

    > The WINE
    > people are trying to get particular programs (games, mostly)
    > that Linux people want to work on Linux.


    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?

    > They are not --
    > and have no interest in -- providing a usable, documented
    > API for Windows developers.


    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 means that WINE usability
    > will probably always be subject to the whims of the WINE
    > contributors.


    I see you don't grasp Wine.


    -Wolfgang

    PS: Try to use the common quote character '>'. '|' indicates
    quoted text from an external source.
     
    Wolfgang Weisselberg, Sep 17, 2012
    #64
  5. ray

    Mayayana Guest

    | 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.
     
    Mayayana, Sep 17, 2012
    #65
  6. -hh <> wrote:
    > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    > wrote:
    >> -hh <> 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.


    >> There is also the possibility of using faster software.
    >> (E.g. better (faster) algorithms or software that uses the GPU
    >> for calculations.)


    > All of that minutia is wrapped up in a holistic 'sufficiency'.


    Not regarding "machine".


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

    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!


    > Ask around the
    > office and you'll probably easily find 30-50% of colleagues who have
    > lost data in a 'home PC' hard drive crash.


    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
     
    Wolfgang Weisselberg, Sep 19, 2012
    #66
  7. Mayayana <> wrote:

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


    > Yes. But it is an acronym.


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

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


    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.


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


    Exactly.

    > But what I said is that it's *essentially*
    > an interpreter. WINE intercepts Windows API calls and
    > "translates" them. That's essentially interpretation.


    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.


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


    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.

    > To be anything
    > more efficient it would have to be compiled.


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


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


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


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

    > 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 don't run Photoshop under anything. Why should I?

    But feel free to run everything under Windows.

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


    HUH?

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


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


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


    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?


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


    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.


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


    You really try to misuse Wine.


    > From their point of view they were not providing APIs.
    > They were just trying to get Windows software to work.


    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.

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


    Improve Wine to work with your software instead.


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


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


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


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


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


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


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


    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
     
    Wolfgang Weisselberg, Sep 19, 2012
    #67
  8. ray

    -hh Guest

    On Sep 18, 8:58 pm, Wolfgang Weisselberg <>
    wrote:
    > -hh <> wrote:
    > > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    > > wrote:
    > >> -hh <> 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: 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.



    > >> There is also the possibility of using faster software.
    > >> (E.g. better (faster) algorithms or software that uses the GPU
    > >> for calculations.)

    > > All of that minutia is wrapped up in a holistic 'sufficiency'.

    >
    > Not regarding "machine".


    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?


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


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


    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.


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


    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.


    > > Ask around the
    > > office and you'll probably easily find 30-50% of colleagues who have
    > > lost data in a 'home PC' hard drive crash.

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


    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.


    > 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

    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
     
    -hh, Oct 4, 2012
    #68
  9. -hh <> wrote:
    > On Sep 18, 8:58 pm, Wolfgang Weisselberg <>
    >> -hh <> wrote:
    >> > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    >> >> -hh <> 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. 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]


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

    I ... disagree.

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


    > Dubs are a backup.


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

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


    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.

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


    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.


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


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


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


    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.


    >> > Ask around the
    >> > office and you'll probably easily find 30-50% of colleagues who have
    >> > lost data in a 'home PC' hard drive crash.


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


    > You're trying to be pedantic again.

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


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

    [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.
     
    Wolfgang Weisselberg, Oct 7, 2012
    #69
  10. ray

    -hh Guest

    On Oct 7, 9:16 am, Wolfgang Weisselberg <>
    wrote:
    > -hh <> wrote:
    > > On Sep 18, 8:58 pm, Wolfgang Weisselberg <>
    > >> -hh <> wrote:
    > >> > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    > >> >> -hh <> wrote:
    > >> >> > [...]
    > >> >> > Yes, although it is a bit more than merely sufficiency (although this
    > >> >> > can depend on how it is defined):  there's also a considerationfor
    > >> >> > 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.


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

    Oh, and your contrived strawman is clearly disingenuous.


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

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

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


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

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

    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.
     
    -hh, Oct 11, 2012
    #70
  11. -hh <> wrote:
    > On Oct 7, 9:16 am, Wolfgang Weisselberg <>
    > wrote:
    >> -hh <> wrote:
    >> > On Sep 18, 8:58 pm, Wolfgang Weisselberg <>
    >> >> -hh <> wrote:
    >> >> > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    >> >> >> -hh <> 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
     
    Wolfgang Weisselberg, Oct 20, 2012
    #71
  12. ray

    -hh Guest

    On Oct 20, 10:20 am, Wolfgang Weisselberg <>
    wrote:
    > -hh <> wrote:
    > > On Oct 7, 9:16 am, Wolfgang Weisselberg <>
    > > wrote:
    > >> -hh <> wrote:
    > >> > On Sep 18, 8:58 pm, Wolfgang Weisselberg <>
    > >> >> -hh <> wrote:
    > >> >> > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    > >> >> >> -hh <> 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
     
    -hh, Oct 20, 2012
    #72
  13. -hh <> wrote:
    > On Oct 20, 10:20 am, Wolfgang Weisselberg <>
    > wrote:
    >> -hh <> wrote:
    >> > On Oct 7, 9:16 am, Wolfgang Weisselberg <>
    >> > wrote:
    >> >> -hh <> wrote:
    >> >> > On Sep 18, 8:58 pm, Wolfgang Weisselberg <>
    >> >> >> -hh <> wrote:
    >> >> >> > On Aug 31, 6:30 pm, Wolfgang Weisselberg <>
    >> >> >> >> -hh <> 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
     
    Wolfgang Weisselberg, Oct 23, 2012
    #73
  14. ray

    -hh Guest

    On Oct 23, 12:22 pm, Wolfgang Weisselberg <>
    wrote:
    > -hh <> 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
     
    -hh, Oct 24, 2012
    #74
  15. -hh <> wrote:
    > On Oct 23, 12:22 pm, Wolfgang Weisselberg <>
    > wrote:
    >> -hh <> 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/current/mod/core.html#files
    https://httpd.apache.org/docs/current/mod/core.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
     
    Wolfgang Weisselberg, Oct 31, 2012
    #75
  16. ray

    -hh Guest

    On Oct 31, 1:03 pm, Wolfgang Weisselberg <>
    wrote:
    > -hh <> wrote:
    > > On Oct 23, 12:22 pm, Wolfgang Weisselberg <>
    > > wrote:
    > >> -hh <> 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/current/mod/core.html#files
    >    https://httpd.apache.org/docs/current/mod/core.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
     
    -hh, Nov 2, 2012
    #76
  17. -hh <> wrote:
    > On Oct 31, 1:03 pm, Wolfgang Weisselberg <>
    > wrote:
    >> -hh <> wrote:
    >> > On Oct 23, 12:22 pm, Wolfgang Weisselberg <>
    >> > wrote:
    >> >> -hh <> 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=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.


    > 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
     
    Wolfgang Weisselberg, Nov 2, 2012
    #77
  18. ray

    -hh Guest

    On Nov 2, 1:23 pm, Wolfgang Weisselberg <> wrote:
    > -hh <> wrote:
    > > On Oct 31, 1:03 pm, Wolfgang Weisselberg <>
    > > wrote:
    > >> -hh <> wrote:
    > >> > Wolfgang Weisselberg <> wrote:
    > >> >> -hh <> 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
     
    -hh, Nov 2, 2012
    #78
  19. ray

    David Taylor Guest

    "What makes a mac better?"

    - having the ability to run Windows, of course!
    --
    Cheers,
    David
    Web: http://www.satsignal.eu
     
    David Taylor, Nov 3, 2012
    #79
  20. ray

    nospam Guest

    In article <k78hvv$5tu$>, David Taylor
    <> 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.
     
    nospam, Nov 5, 2012
    #80
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nospam

    Re: What makes a mac better?

    nospam, Aug 26, 2012, in forum: Digital Photography
    Replies:
    0
    Views:
    319
    nospam
    Aug 26, 2012
  2. nospam

    Re: What makes a mac better?

    nospam, Aug 26, 2012, in forum: Digital Photography
    Replies:
    0
    Views:
    335
    nospam
    Aug 26, 2012
  3. nospam

    Re: What makes a mac better?

    nospam, Aug 26, 2012, in forum: Digital Photography
    Replies:
    2
    Views:
    348
    nospam
    Aug 26, 2012
  4. tony cooper

    Re: What makes a mac better?

    tony cooper, Aug 26, 2012, in forum: Digital Photography
    Replies:
    109
    Views:
    1,328
    Wolfgang Weisselberg
    Aug 31, 2012
  5. nospam

    Re: What makes a mac better?

    nospam, Aug 27, 2012, in forum: Digital Photography
    Replies:
    0
    Views:
    305
    nospam
    Aug 27, 2012
Loading...

Share This Page