What makes a mac better?

Discussion in 'Digital Cameras' started by Dudley Hanks, Aug 26, 2012.

  1. Dudley Hanks

    Alan Browne Guest

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

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

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

  2. Dudley Hanks

    -hh Guest

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

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


    -hh
     
    -hh, Sep 2, 2012
    1. Advertisements

  3. Dudley Hanks

    Guest Guest

    while that will certainly fix it, running a disk utility is likely to
    fix the corruption and avoid the hassle of a reformat.
     
    Guest, Sep 2, 2012
  4. Dudley Hanks

    Alan Browne Guest

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

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

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

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

    Home routers/WiFi widgets are usually fed by a wall wart. Its
    transformer will take the brunt of a surge and its AC|DC converter will
    absorb most of the rest (esp. more recent switching designs v.
    rectifier/capacitor/inductance designs). And then even if that DC out
    'surged' a little, the front-end of the power supply in the router/wifi
    would deal with the rest.
    Sure, but I would bet most computer HD's have a lot of corrupted files
    that don't affect the OS enough to cause much real harm over the short
    term. It can take a lot of corruption before there is a serious issue
    that isn't re-written with other (good) state data in the meantime.
     
    Alan Browne, Sep 2, 2012
  5. Dudley Hanks

    -hh Guest

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

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

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


    -hh
     
    -hh, Sep 2, 2012
  6. An interpreter is the opposite of a compiler.

    Wine [note the correct spelling: it's not all upper case!] is not
    reading the source code of a windows program, it's thus neither
    an interpreter nor a compiler.
    "Wine translates Windows API calls into POSIX calls
    on-the-fly" (http://www.winehq.org/about/)

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

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

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

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

    Would you also want to teach a monkey to use your camera and
    photograph the same stuff you'd be able to photograph yourself
    without any trouble?
    Apart from being wrong (Wine isn't Linux only) ... are you
    suggesting they should be trying to get programs to run that
    people who are the target audience for Wine aren't interested in?
    The API is identical to the API of Windows, so go ask Microsoft
    for complete documentation. The only difference are
    a) bugs, which you should report and maybe even fix
    b) unimplemented parts, which you should report as bugs
    I see you don't grasp Wine.


    -Wolfgang

    PS: Try to use the common quote character '>'. '|' indicates
    quoted text from an external source.
     
    Wolfgang Weisselberg, Sep 17, 2012
  7. Dudley Hanks

    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
  8. And yet it's a very, very common task, be it email, facebook
    or IPTC metadata in a photo.

    Not regarding "machine".

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

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

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


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

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

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

    -Wolfgang
     
    Wolfgang Weisselberg, Sep 19, 2012
  9. Wine is no longer an acronym.
    And RADAR still is one.
    People are perfectly capable of looking for the context.
    You're also not saying "the size of the hole in the bunch of
    polished glass bodies held together by metal and plastics, which
    goes in front of the black box which records images" when you're
    talking about the aperture of a lens.

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

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

    Wine doesn't have to "interpret the content of the function
    parameters". There's no need to divine what they mean ---
    their meaning is explicitely given by the API definition.
    There's no need to "interpret" the content, Wine doesn't
    change the content, it just passes it through to the POSIX
    calls. Only the latter have to "interpret" the contents.
    Wine is compiled.
    You're blinded by your own prejudices.
    Do you really think all the Windows API isn't layer upon
    layer of translating calls?

    It's so. There are grossly inefficient parts in Windows.
    I don't run Photoshop under anything. Why should I?

    But feel free to run everything under Windows.
    Well, what does Wine provide if not Windows APIs? OS X APIs?
    Plan 9 APIs?
    Inquiring minds want to know!

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

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

    You really try to misuse Wine.

    Exactly. Noone is interested in developers coding against the
    Windows APIs when they could better, faster, without "interpreter"
    and translation code against the Linux (or Mac OS) APIs.
    Improve Wine to work with your software instead.

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

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

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

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

    -Wolfgang
     
    Wolfgang Weisselberg, Sep 19, 2012
  10. Dudley Hanks

    -hh Guest

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


    Fine: let's call it "System".

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

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

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

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

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

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

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

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

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

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

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

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



    -hh
     
    -hh, Oct 4, 2012
  11. [/QUOTE]
    That was my point THE WHOLE TIME. And why I choose that
    counterexample to your
    | a machine which is merely _sufficient_ for a conducting
    | particular workflow versus a machine that can perform the same task(s)
    | more quickly will result in a workflow productivity gain.

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

    [blah blah not always totally lost blah blah]

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

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

    Try to use a dub to make a large print that already strains the
    quality of the original. Unless you don't do large prints a dub
    won't serve as a substitute.
    Ah, really?
    If 5% of a slide or negative gets trashed, the value of the image
    is gone. Noone will buy a print of it.
    If 5% of a JPEG (or RAW) gets trashed, you just pull a fresh
    copy from one of the copies in one of the archives or from one
    of the backups.
    I assume that he was more aware of the problem than of film rot and
    vastly more capable of doing something against it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    -Wolfgang

    [1] Kodachrome being a lucky accident.
     
    Wolfgang Weisselberg, Oct 7, 2012
  12. Dudley Hanks

    -hh Guest

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

    No.

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

    Oh, and your contrived strawman is clearly disingenuous.

    No, not misconfigured: simply another clue.
    You were also given the free clue that I've used this example before
    and that all have failed. A quick Google search would have revealed
    that it is Microsoft's Powerpoint and exactly which version thereof.
    And Photoshop isn't proprietary? You're simply trying to make excuses
    for your failure to open the file.

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

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

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

    Golly, what a slippery slope!

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

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

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

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


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



    -hh


    PS: I found it particularly ironic how you got all pedantic about
    "DUPES vs Backups" and then recommend the lossy file format of JPEG.
     
    -hh, Oct 11, 2012
  13. "Only so far as the computer is slowing down the user. (Example:
    typing a text. The computer does nothing but wait for the
    user.  Waiting faster doesn't speed up the user or the task.)

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

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

    I had, but how comes historians must *also* be photo-centric when
    naming periods?
    Oh, you might wish to learn about JPEG and restart markers,
    so your claims aren't clearly uninformed.

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

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

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

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

    MS PowerPoint is NOT Text/Plain.

    Only Photoshop produces JPEGs?

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

    As is this here:

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

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

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

    [blah blah]
    Simple question: Why didn't you write "are you referring to JPEG,
    JPEG, or the JPEG standard?" If you can answer that, you know
    the answer.
    Cue open software.
    JPEG doesn't need to be lossy. Which you knew, didn't you?

    -Wolfgang
     
    Wolfgang Weisselberg, Oct 20, 2012
  14. Dudley Hanks

    -hh Guest

    You've already had your chance from this 'kind soul'; you'll have to
    go find another who thinks that you're somehow still redeemable.
    Stone Age ... Bronze Age ... Iron Age ... Steel Age ... Industrial
    Revolution ... Information Age ... and today's "Straw Man Age"! ...
    verily, you are correct in that these are all quite "photo-centric" in
    their historical naming conventions when you tried to put words in my
    mouth!

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

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

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

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

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

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

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

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

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

    No, and non sequitur.

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

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

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

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


    -hh
     
    -hh, Oct 20, 2012
  15. I see. You are unable to explain how you could have misunderstood
    me and thus attack me.
    You have a strange way of saying that I was right.

    A binary file produced by PowerPoint is *never* intended to
    be displayed "as-is".
    And it's still not PLAIN.
    Nope. application/octet-stream is nearly always the right
    type for unknown file formats.

    You wouldn't need to 'direct people to right-click & save' if
    you used the correct type: it would either open in the right
    application or be offered to be saved.
    I see, you are able to learn, though it's really hard work.

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

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

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

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

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

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

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

    That was perfectly obvious to almost anyone.
    Unfortunately, you can't stand the truth.
    I see you haven't managed to decode the secret file I gave you.

    -Wolfgang
     
    Wolfgang Weisselberg, Oct 23, 2012
  16. Dudley Hanks

    -hh Guest

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

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

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


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

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

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

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

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

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

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



    -hh
     
    -hh, Oct 24, 2012
  17. Obviously you've been misinformed. Suffixes are informatory only
    (except on DOS and Windows, where they stupidly replace file
    attributes like "executable"). That's why e.g. web servers do
    transmit the file type instead of just relying on the suffix of
    the ending. (And that's why getting a .php-file doesn't mean
    your local PHP is supposed to start up and execute the file.)
    What's in a name? that which we call a rose
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    By any other name would smell as sweet;
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    So Romeo would, were he not Romeo call'd,
    Retain that dear perfection which he owes
    Without that title.


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

    Call your JPEG (not JPEG XR, not JPEG 2000, ...) encoded picture
    "me and my dog.jpeg" or "HXWE2341.JPG" or "mumble" --- if it's
    the same bits, no harm done. (And that it's you and your dog
    should be in the IPTC metadata embedded in the file, yet distinct
    to the photo itself.) All you need to do is tell the receiving
    site that the bag-o-bits is a image/jpeg.
    If you actually had a clue, you'd know that that's not true.
    It's easy enough to tell a (competent) webserver to serve a
    file as a specific file type even when there's no matching
    suffix.

    https://httpd.apache.org/docs/current/mod/core.html#files
    https://httpd.apache.org/docs/current/mod/core.html#forcetype
    And delivering with the correct MIME type is also hardly a
    burden, but one that needs to be borne only ONCE, not *every*
    *single* *time* someone downloads the file.
    Are you really stupid enough to not understand the difference
    between a *file format* of a file[1] and a hardware method of
    storing arbitrary data[2]?

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

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

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

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

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

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

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


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

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

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

    The same Strohl book where he told us that e-commerce is "baloney"
    and nonviable, due to lacking interpersonal contacts and no secure
    online funds transfer. *Poof* implodes the internet ...
    Like "they used a good format and forgot the tapes in the cellar
    until the tapes were in so bad shape that they couldn't be read"?
    It does not really matter if the format is "dead", "brand new",
    "common" or "rare", except that in all but "common" you may have
    less data to test your code against it.
    So you want me to decode the data. Fine. *You* provide me
    with the correct and exact description of the formats, *You*
    provide me with the read-error free data that's to be
    decoded. That's my challenge to you.

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

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

    -Wolfgang
     
    Wolfgang Weisselberg, Oct 31, 2012
  18. Dudley Hanks

    -hh Guest

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

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

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

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

    Given the amount of text & time that you've invested on equally
    irrelevant points, we can all see that your assertion is patently
    false.
    True, but once again, you're dwelling on a point of misdirection so as
    to try to avoid the real issues.

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

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

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


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

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


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

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

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

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



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

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

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

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


    -hh
     
    -hh, Nov 2, 2012
  19. *I* realized that.
    When I saw "text/plain" I got the right clue. I didn't look at
    the filename for info.
    So are some brain cells!
    Neither Romeo nor file formats have anything to do with renaming
    files to add '.PPT'
    This is mostly an example of how someone who doesn't have a real
    name also doesn't have basic skill of telling a webserver what
    type of files it is supposed to serve.

    And an example of how someone who doesn't have a real name also
    doesn't have the skill of reading what is written or keeping
    the context.
    I see ---
    I misdirect, you "return to the topic at hand".
    I say irrelvant things, you "state profound truths".
    I don't follow directions, you "do things the way you want".
    I talk about JPEGs, you "use dead file formats".
    I move goalposts, you "adjust the thread to reality".
    I talk about file formats, you "think floppy disks are formats, too".
    Given the fact that you haven't properly corrected your URLs
    (but rather removed the files) even after I gave you all the
    hints a five year old would need, I can only conclude that you
    don't have the technical aptitude to use computers, and thus a
    blind-from-birth person talking about colours would be as relevant
    and insightful as you talking about file formats.

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

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

    Wrong.
    Are you able to come up with a counter example all by
    yourself, or do I need to tell you so you'll call it
    irrelvant again?
    Irrelevant: It's not.
    There's *no* suffix in
    http://www.huntzinger.com/photo/ADPA-snipertrainer
    and there's only 3 character (1 digit long) suffix in
    http://www.huntzinger.com/photo/ADPA-snipertrainer.PPT
    .. Anyone with a functioning brain, one tiny handful of fingers
    or toes and an eye or Braille display can see that.

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

    Me thinks you're completely off your rocker by now.
    A *file* format, yes.
    Which is completely irrelevant, as it can be copied to a new
    storage media by a trained monkey, even if you're not up to
    the task.
    So use an MDISC already. 1000 years should be long enough
    for a millennium.

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

    Trivial, see above. Not that I wouldn't have a couple lying
    about ...
    Try again, simplebrain.
    You can simply use some money, and that's it.
    Try again, simplebrain. And try not to spout too many
    wrong and irrelevant claims this time.

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

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

    I could go on.

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

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

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

    And try tell us why undeveloped Kodachrome is relevant in any
    way to the long term storage on floppy disks.
    They used the wrong storage media, 'tis all.

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

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

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

    Until you present the complete specification of the file you
    previously "provided" ...
    Deliver the complete, open specification for you "ADPA-snipertrainer".
    I guess you can't, so now you again move goalposts.

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

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


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

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

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

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

    -Wolfgang
     
    Wolfgang Weisselberg, Nov 2, 2012
  20. Dudley Hanks

    -hh Guest

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

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

    Gee, see a pattern here yet? I do.

    Yet another ad hominem personal insult.

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


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


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

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

    I read on and simply see more ad hominem personal insult attempts.
    I read on and see flat out lies: sorry, but I've not removed even a singleURL or file from my website.

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

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

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

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


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

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

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

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

    Clearly, we are done here.

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


    -hh
     
    -hh, Nov 2, 2012
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.