The "regular" office server she "should have" been using was NOT designed for classified info either. The same risk would exist had she simply used the generic office email server. The wrong info would have ended up on the wrong server regardless.
I've argued elsewhere it's NOT common sense. There is no clear-cut benefit of one over the other; the differences are subtle and involved.
Classified info didn't belong on the "regular" office server EITHER. The same problem would have existed even IF she had only used the office server. It's comparing Chevy's to Chevy's, and not a (home) Chevy to an office Cadillac. (There is a separate system for classified stuff, but it's not email as we know it.)
Hillary is not tech-savvy enough to hack. Her emails revealed she had trouble working her desktop email client, preferring her Blackberry to process emails.
Democrats sure like their Blackberries. I'm surprised they didn't try to bail out that company like they did GM:-)
From the public's perspective, key questions remain:
1. Who sent her the (alleged) classified info?
2. Was the info classified at the time it was sent?
3. Was it realistic for her to know she received classified material? (Or material she should have known should have been classified or treated as such.)
4. Did she knowingly forward or fail to report classified info?
5. Did she put such info at risk by having a home server? (The "regular" office email server was NOT designed for classified info either. Seems it was pretty generic.)
6. Was a home server against the law? (The legal consensus seems to be "no", but she may not have disposed of the info properly when her term ended, although that's an involved claim.)
DBA's gotta manage it, and many prefer using a GUI.
Granted, it's often considered better to manage it via scripts (command line text) so that it can be re-created, but in practice, some want "quick and easy". This is MS shops we are talking about.
even though Linux doesn't need it and nobody asked for it
One thing MS learned from Windows is that for customers, compatibility often matters more than quality. Customers end up getting themselves married to a tool stack.
Even with the past accidents, "N-power" is statistically safer than the fossil-fuel (FF) alternatives. This is largely because FF causes a general lung cancer increase, and other ailments such as asthma.
N-power seems scarier in part because the deaths and illness tend to be sporadic, typically once-a-decade kinds of accidents, while FF death and illness is more or less constant: low-level but ever-present.
It seems political "safer" to spread the risk evenly rather than have occasional accidents that attract big news. It's reminiscent of the Office Space trick: if you rip a few pennies off from tens of thousands of people you are less likely to be noticed than if you rip thousands off from a few.
The discussions on the F35 often center around its capabilities as a fighter...neither the Navy nor the Marine core want a plane that is primarily a fighter.
But if you suck in that area, the enemy will force you to be a fighter.
Isn't Apple, Kia, and Samsung also getting into this biz, along with some no-names? It's premature to assume it will expand fast. It's a very new, untested, and immature market. We had the Dot Com bubble, maybe this is the Dot Car bubble.
These co's should perhaps split the load via co-ownership to divide the risk, yet be enough in the game to take advantage of a SDC boom if one actually happens.
Let's look at a more here-and-now example. EXISTING compilers can take code like Version 1 below and "convert" it to Version 2 under the hood (for execution).
Thus, a compiler can take what "traditionally" is considered an "n^2" algorithm and convert/run it with an "n" performance profile.
// Version 1 for x = 1 to foo
z = blah(x)
for y = 1 to bar
if z < 7 then
someRoutine(y)
end if
end for end for
// Version 2 for x = 1 to foo
z = blah(x)
if z < 7 then
for y = 1 to bar
someRoutine(y)
end for
end if end for
I've numbered the general steps to one of my arguments. If you disagree with the conclusion, which specific clause(s) do you disagree with?
1. A human can recognize a bubble-sort algorithm and convert it to merge-sort algorithm or implementation.
2. A human mind is a type of "computer".
3. A human can fulfill the role of a compiler. (A human can "be" a compiler.)
4. A compiler can convert a bubble-sort algorithm into a merge-sort "under the hood", per above.
5. A bubble-sort can thus run with a performance profile of "n log n" because a compiler can convert it into a merge sort, per above. (Bubble sort "normally" has a "n^2" O-nation profile.)
6. There's NO evidence that an "artificial" compiler can NEVER be made to do what a human does (1 through 4 above).
7. One cannot rule out the possibility that an artificial compiler can run (or create an executable to that runs) a coded bubble-sort with a "n log n" performance profile.
8. One cannot rule out the possibility that with a sufficiently powerful artificial compiler, a bubble sort can run "as fast as" a merge sort.
Now, you may point out it's never been done in practice, which is true. I'm only saying you cannot rule it out and thus cannot claim that a bubble sort is "inherently" slower than a merge-sort. You can only say such about "known compiler and chip implementations", which I don't dispute.
Why would somebody who is not tech savvy ask for such? Unless somebody points out a clear example/risk of such, the trade-offs will be over her head.
So far I have not heard one. The "regular" office email server was not designed for classified info either.
Some dummy went and put the wrong info on the wrong box. It still would have been the wrong box if she used the office email for ordinary work.
Who that dummy is, we don't know yet.
Windows XP? Try Netscape.
No problem, I just outsource my training.
The "regular" office server she "should have" been using was NOT designed for classified info either. The same risk would exist had she simply used the generic office email server. The wrong info would have ended up on the wrong server regardless.
I've argued elsewhere it's NOT common sense. There is no clear-cut benefit of one over the other; the differences are subtle and involved.
Classified info didn't belong on the "regular" office server EITHER. The same problem would have existed even IF she had only used the office server. It's comparing Chevy's to Chevy's, and not a (home) Chevy to an office Cadillac. (There is a separate system for classified stuff, but it's not email as we know it.)
No, todger country.
Where do you think Linux distros got it?
hell, I'd rather take the amnesia
Hillary is not tech-savvy enough to hack. Her emails revealed she had trouble working her desktop email client, preferring her Blackberry to process emails.
Democrats sure like their Blackberries. I'm surprised they didn't try to bail out that company like they did GM :-)
From the public's perspective, key questions remain:
1. Who sent her the (alleged) classified info?
2. Was the info classified at the time it was sent?
3. Was it realistic for her to know she received classified material? (Or material she should have known should have been classified or treated as such.)
4. Did she knowingly forward or fail to report classified info?
5. Did she put such info at risk by having a home server? (The "regular" office email server was NOT designed for classified info either. Seems it was pretty generic.)
6. Was a home server against the law? (The legal consensus seems to be "no", but she may not have disposed of the info properly when her term ended, although that's an involved claim.)
That has NOT been proven in a court of law yet. Many experts say the laws at the time were poorly written such as to make prosecution very difficult.
Bad judgement, yes. Illegal? Subjective.
"Alert: Pay us 5 grand in bitcoin, or we'll give you amnesia, like we did to Reagan and Rick Perry!"
DBA's gotta manage it, and many prefer using a GUI.
Granted, it's often considered better to manage it via scripts (command line text) so that it can be re-created, but in practice, some want "quick and easy". This is MS shops we are talking about.
One thing MS learned from Windows is that for customers, compatibility often matters more than quality. Customers end up getting themselves married to a tool stack.
Le huh?
Even with the past accidents, "N-power" is statistically safer than the fossil-fuel (FF) alternatives. This is largely because FF causes a general lung cancer increase, and other ailments such as asthma.
N-power seems scarier in part because the deaths and illness tend to be sporadic, typically once-a-decade kinds of accidents, while FF death and illness is more or less constant: low-level but ever-present.
It seems political "safer" to spread the risk evenly rather than have occasional accidents that attract big news. It's reminiscent of the Office Space trick: if you rip a few pennies off from tens of thousands of people you are less likely to be noticed than if you rip thousands off from a few.
Bet: If Ted and Marco are honest, I'll install Windows 10.
But if you suck in that area, the enemy will force you to be a fighter.
Nuking it from orbit is the only way to be sure.
If they really wanted to "hammer him", they wouldn't give him air-time, which is the opposite of what they do. Trump is a ratings magnet.
Isn't Apple, Kia, and Samsung also getting into this biz, along with some no-names? It's premature to assume it will expand fast. It's a very new, untested, and immature market. We had the Dot Com bubble, maybe this is the Dot Car bubble.
These co's should perhaps split the load via co-ownership to divide the risk, yet be enough in the game to take advantage of a SDC boom if one actually happens.
Shhhh, maybe IoT will distract them from F'ing with the Firefox UI, like throwing a dog a bone so that he doesn't maul the cat.
shhhh, at least it's cool pork
Addendum 2:
Let's look at a more here-and-now example. EXISTING compilers can take code like Version 1 below and "convert" it to Version 2 under the hood (for execution).
Thus, a compiler can take what "traditionally" is considered an "n^2" algorithm and convert/run it with an "n" performance profile.
Addendum:
I've numbered the general steps to one of my arguments. If you disagree with the conclusion, which specific clause(s) do you disagree with?
1. A human can recognize a bubble-sort algorithm and convert it to merge-sort algorithm or implementation.
2. A human mind is a type of "computer".
3. A human can fulfill the role of a compiler. (A human can "be" a compiler.)
4. A compiler can convert a bubble-sort algorithm into a merge-sort "under the hood", per above.
5. A bubble-sort can thus run with a performance profile of "n log n" because a compiler can convert it into a merge sort, per above. (Bubble sort "normally" has a "n^2" O-nation profile.)
6. There's NO evidence that an "artificial" compiler can NEVER be made to do what a human does (1 through 4 above).
7. One cannot rule out the possibility that an artificial compiler can run (or create an executable to that runs) a coded bubble-sort with a "n log n" performance profile.
8. One cannot rule out the possibility that with a sufficiently powerful artificial compiler, a bubble sort can run "as fast as" a merge sort.
Now, you may point out it's never been done in practice, which is true. I'm only saying you cannot rule it out and thus cannot claim that a bubble sort is "inherently" slower than a merge-sort. You can only say such about "known compiler and chip implementations", which I don't dispute.