Paintshop and Corel

See David Taylor's comments in a following post.

 

it doesn't contradict anything and hard drives under load won't last as
long as ones that are idle, a fact you refuse to acknowledge.

and the rating you mention is per cell, not for the entire ssd. with
wear leveling, the ssd will last much longer than the life of one
individual cell.

ssd reliability rates are better than hard drives. there is a lot of
evidence for this. early ssds had problems but that's long gone. early
hard drives weren't that reliable either.

the #1 failure mode for ipods was the hard drive in those that had hard
drives. the flash based ipods were *much* more reliable.

it's obvious you dislike ssd, and are trying to justify it. there will
always be edge cases to twist the numbers any way you want. the reality
is that ssd is not only more reliable, but *much* faster, a *huge*
advantage you are ignoring.

here's another report:
<http://www.hardware-revolution.com/best-ssd-best-hard-drive-september-2
013/>

SSD Failure Rates:
- Samsung 0,05%
- Plextor 0,16%
- Intel 0,37%
- Crucial 1,12%
- Corsair 1,61%
- OCZ 6,64% (!)

Hard Drive Failure Rates:
. Toshiba 1.15%
. Seagate 1.44%
. Western Digital 1.55%
. Samsung 2.24%. Note that the Samsung hard drive division is now
owned by Seagate and consists mostly of rebranded Seagate drives.
. Hitachi 2.40%

other than ocz, who recently filed for bankruptcy so they can be
ignored, ssd is more reliable, unless you intentionally pick the worst
of one and compare it with the best of the other, which is of course,
bogus.

 

see actual industry statistics, quoted in another post. you too are
looking for a reason to not want to use ssd.

 

[]

I have never discussed HD lifetime. What I have discussed is that SSDs
have a different failure mechanism than HDs and that therefore one must
know the use to which SSDs will be put before blindly saying that they
are more reliable.

 

they do have a different failure mode (which *is* lifetime), but the
user doesn't care what happens internally.

what matters is did it fail and how recent is their backup if it did,
as well as what its performance is when it isn't broken.

with ssd, they won't need to worry about that as much because it's more
reliable and a *lot* faster.

there might be some edge cases where one is worse than the other (and
it works both ways, not just one way), but that's always the case for
*any* technology. nothing is perfect.

for instance, hard drives don't work at high altitudes and ssds do.
that won't matter to most people but it will to some.

 

It seems that way to only because you completely reject the idea of a
backup protocol in this context. As I've several times tried to
explain, a protocol does not entail software.

Now why did you snip the next line?

Didn't you want anyone to go back and discover what this discussion
was all about?

Isn't that a statement of what the code must do?

Do you mean on Mon, 25 Nov 2013 10:23:24 -0500 when at Message-ID:
<> he started to discuss
what was protocol and what was not after you introduced the "The old
..Mac backup application"?
And that was clear from your discussion of the time.

I didn't say that you believed in protocol being software. But you
seemed to believe that Tony meant that protocol meant software and
went to some trouble to disprove it. For example, on 26 Nov 2013
22:09:20 GMT in Message-ID: <> you
wrote an article of some length, including a code example. Your final
paragraph was:

"Few, if any, developers would call this a protocol. It's just
conditional code. And I fear that nospam's suspicion was correct,
you're way out of your league here because you're ignorant about
the technical nature of these things. Maybe "protocol" is your
way to make sense, in your head, for a series of steps taken by
the software that you don't understand how it is done? No shame
in that, you're in good company if you know nothing about
the tech trivia of computers."

From the way you continue digging around inside programs looking for
Tony's 'protocol' it is clear that you have never understood what he
was talking about. I tried to use the 'black box' analogy to explain
to you that the protocol lay outside the program, but you rejected
that. I gave the real examples of FTP etc and you brushed them aside.

Is that your objective?

 

That is a stupid and argumentative statement. I want to know so I can
make an evaluation for my personal use. Obviously, you lack the
objectivity I seek.

 

i've provided several sources.

your mind is made up and you want something that matches your beliefs,
even when facts show otherwise.

 

For christ sakes, Eric. You have a *reading disorder* that I can't
circumvent or rectify. *TONY* started to talk about software then **I**
told *HIM* that a *PROTOCOL DOES NOT MEAN SOFTWARE*.

I'm using caps here to help direct your gaze towards the parts of my
sentence that I'm hoping that you will be able to read and, less likely,
comprehend!

Of course not. It's a standard to which to application most adhere. You can
"do" this many ways using code. The HTTP or FTP protocol says *nothing*
about code, especially considering the very fact that you can use these
protocols using pretty much any programming language.

You see, "code" doesn't "do" anything. Code is an instruction to a
compiler, that creates applications. Applications are the ones that DO
something. So the FTP protocol very much defines what an application must
DO to adhere to it.

As a programmer, you can achieve this in a multitude of ways in your code.

It's a moot point, either way, since communication protocols between
computer systems (FTP, HTTP) was never the topic, and is just a diversion
on your part.

No, I mean when I told him that software development is rarely using the
word "Protocol" when he ignorantly refered to software development.

I've already quoted the relevant parts in another post, but since you
refuse to read and/or comprehend them, I won't bother doing it again. It's
just a waste of time and effort. Once is enough.

Which is a lie, given the fact that you have failed to support that it was
"clear". FOr a million dollars, you couldn't quote me using the word
"Protocol" in an incorrect way.

No, "meaning" software, like I said. Why don't you notice it yourself when
you have to switch out words in order to claim you haven't said it.

Look, what things "seem" to you is of no consequence to me. I have never
claimed, believed or said that Tony meant that "protocol meant software"

And above you said that *I* used the word "Protocol" meaning software, and
now you're saying I "believed" Tony used it that way. You are very very
confused and you mix things up in every post and you can't keep anything
straight even in one paragraph of your own text.

Which is proof that I don't use the word "protocol" meaning software.

But your incorrect claim wasn't that I didn't understand what Tony was
talking about - it was that I didn't understand the word "protocol". A
claim you have yet to support, of course.

Your black box laymen analogies had no place in a thread where actual
programmers post. It's your equivalent of saying "it does stuff"

Since backup protocols was the topic, not inter-system communication
protocols.

It seems to be yours.

 

That's an undeniably correct statement. A protocol is established
when the developer determines what will be done. The required code to
perform the steps in the protocol the developer comes up with are
then written into the program.

 

Correct, I never claimed otherwise.

My reply to the above was me mocking you over the fact that you were
stating the obvious.

 

(Tony Cooper wrote)

This is a good example of the limited thinking ability of our Swedish
Popinjay when it comes to the understanding of words. A "requirement"
is most certainly what you "want to do". In the context of the
user-defined steps in a backup protocol, requirements are determined
by the wants of the user.

I have two external drives. It is not "necessary, compulsory, or
needed" for my backups to be directed to either or both of those
drives. But, I want them to be directed to these drives. Therefore,
in my backup protocol, I make this a requirement. Requirement follows
want.

In any context, not necessarily computer-context, a requirement is
simply the manifestation of a want. Someone wants it, so someone
makes it a requirement. Without it being wanted, it is not a
requirement. Not all "want to do"s become requirements, but I didn't
say that this is the case.

 

Then why did you cite it in a post claiming that I didn't know what I
was talking about?

So, a correct statement from me is "stating the obvious" and subject
to mocking? But, from you, a correct statement is "substantiation"?

 

Absolutely, but that doesn't mean that "requirement" means "what you want
to do". Words can be related to each other, and conditional upon each
other, yet not have the same meaning.

No, but they are a requirement if you want to do a backup to either or
both of them.

So you make their presence be a requirement - i.e. necessary, compulsory or
neeeded. Voila.

It may, to some extent. That doesn't equate the word "requirement" with the
phrase "what you want to do".

Not really, no. A requirement is something more than a mere desire for
something. If you really want pancakes, you may exaggerate and shout "I
require pancakes!" but you know full well that if none is available, you
will continue functioning as usual. If you're starving and risk dying from
starvation, then you *require* food (and I'm quite sure any food will
suffice, not only pancackes and it's more than a mere desire for food.
It's a requirement, a need, something compulsory for your survival.

Sure, that's ok. A diva may say that it's a requirement for white roses to
be in her dressing room when she comes to the opera, which is merely
something she wants, not something she actually needs. So she makes it a
requirement for her presence there.

This is totally incorrect though. An iOS developer is required to purchase
a Mac to run Xcode to develop applications. In many cases, this is against
their wishes, and an unwanted and for some an unfortunate requirement. This
is something driven by a *need*, not a *want*, quite clearly illsutrating
the fact that the word "requirement" does NOT mean "what you want to do".

Again, you should get yourself a real dictionary and learn a thing or two.

 

I didn't. I substantiated my claim that you were the one who started to
talk about software development in relation to the word "protocol".

In that instance it was. It was funny because you posted obvious things and
pretended that you were telling me about them.

A correct statement is not substantiation. Proof is substantiation. Merely
making a statement proves nothing.

I understand that all of this is very confusing to you, since you always
assumed that merely by claiming something, it became true. Alas, that's not
the case.

 

What's this? Stating the obvious? Should I mock you?

Actually, your statement here is exactly my point: "they are a
requirement if you want..."

Just so you'll know, "Viola" without the grave accent is a musical
instrument. The word "Voilà" is actually a contraction of vois là, or
"see there".

To all extent. No requirement follows something that is not wanted in
some way. Shallow-thinking.

As you say, "incorrect".

More limited thinking. You have misidentified the "want". The person
wants to be an iOS developer. That creates the requirement.

Understanding the definition of a word is not enough. You must learn
when that word, with one of the word's definitions, can be used in
context to effectively communicate a thought. Many words have more
than one definition, and sometimes even definitions that are
opposites. Contronyms, or Janus words, like "oversight" and "bolt"
can plague the unwary writer or reader.

Some words, like "moot" or "table" (as in "table the motion") are
defined differently by different cultural groups.

All-in-all, you do well English, but your rigid view of usage is an
example of not seeing the forest for the trees. Or, maybe it's just
pettiness on your part.

 

You're an adult (?) you are free to do whatever pleases you. I am just
letting you know what the words you use mean.

Indeed. Hence, "requirement" does not mean "what you want to do", it can
very much be dependant on a desire. I.e. you may want to do something,
which requires a condition to be met.

So it's the other way around. The "want" is "make a backup", "make a
backup" then have the requirement of connecting the backup disk. It doesn't
start with you "wanting" to connect the backup disk, that's a requirement
for your desires to be fulfilled.

I take your diversion to accented characters as you admitting that
"requirement" means soemthing that is needed, compulsory or necessary?

No, the statement above is correct.

You want to go to the pub, that requires that you put some pants on, but
that's not what you "want to do", it is something you have to do.

Indeed - he does NOT want to have to buy a computer, i.e. he has no desire
at all to meet the requirement, but he is forced to. Hence - "requirement"
does NOT mean "what you want to do"

In the example:

What he wants to do: Be an iOS developer:
Requirement: Get a Mac

See how the two lines differ, and how what he wants doesn't match the
requirement? Of course you don't.

You should learn that too, yes.