That's an option with this ZFS feature - but they are suggesting it's only optional, and that for statistical reasons you can probably rely on the hash alone.
Basically saying that the odds of a hash collision causing irreperable data loss are orders of magnitude less likely, even in extreme cases, than the odds of losing that same data in your current raid setup.
They make the point that the likelihood of a hash collision (and ensuing corruption) is many orders of magnitude less likely than already recognized odds of data corruption in the physical media itself, including raid and redundancies - even in extreme cases of zetabyte filesystems with 128k block sizes.
(meaing if you weren't worried about your current setup, and you're worried about hash collisions, you have your priorities backwards)
Who cares about the EULA - what about the requirements written right on the box? A reasonable person, at the time of purchase, knows what is required to run said software.
It says right there "Mac with Intel processor."
To expect them to provide any type of support or work for anything OTHER than what is written right there is just silly.
"Any cost savings you can achieve by outsourcing to a more specialized company never seems to materialize." Agreed. Unfortunately, what we need are demonstrable cases where this is true.
Running full scale in-house development, especially if you have fat regulatory manuals to follow (PCI, SOX, etc) - requires quite a bit of staffing and process. Project managers, product lifecycles, all that buzz. It's a whole other thing that has to be managed.
Outsourcing looks good on the books. It's a line item, rather than a department.
The point is that a) Yes, system admins can read your mail. Even though they don't, they CAN. b) You know they can, and that those mails will sit on the company's servers in plaintext -
therefore, YOU are exposing your emails to the company in question on a regular basis.
"But the justification should not rest on wrong-headed assumptions like the notion that ISP customers "expose to the ISP's employees in the ordinary course of business the contents of their e-mails.""
It might be a bit far reaching... but come on, system administrators have had access routinely to people's mailbox contents since forever (on most mail systems). Not that we go around snooping on your mail, but we can and do have access to it, if it's plaintext, at any time. If you are sending emails through any provider without encryption and assuming that some staff at that provider are not technically capable of reading and copying your emails, you are delusional.
This is not like snail-mail, where although you know the postman could open your mail, you also know he'd go to prison for it.
It also depends on what their design goals were - perhaps they met them?
It's easy to look back in hindsight and say "That's obvious" - but if as a previous poster said, they were designed to shoot down slower targets, and as another said, the system was required to re-boot and re-synch every 36 hours, and this was ignored..... that's design.
And if that seems too extreme.... change the laws to make sense?
I'm not one of those "throw copyright out the window' guys - but something should change. Copyright law was created by us in response to our newfound ability to do things like use the printing press and record audio for mass productions. WE recognized that we wanted to protect, ultimately, the creators of these works. THe laws were sufficient for the time.
Now, with the internet, we've made another quantum leap in our ability to copy.. rather than being feasible on a commercial scale, it's possible for something to be available to everyone, at a cost approaching zero, globally, at a personal level. The law needs to catch up somehow.
That economic thing goes both ways, Canada being the US' largest trading partner, and the Canadian government doesn't need to ask for "permission" from the US to pass legislation.
Great... get your thoughts down on paper and you'll have a killer app.
Unfortunately, all of those things like "key signing" and "keys" and "trust" are currently required for PKI to be useful.
Someone has to mess around with all that "stuff" to make it work... and if it's not you, you have to trust someone else (software vendor, ISP) to do it for you.
The problem with encryption for email is you need some kind of trust heirarchy to authenticate everyone. Without that, you never know if you're being middled, and therefore you might as well not have encryption.
Given that even sensible, educated, technical people will often ignore certificate trust warnings.....who thinks email encryption will actually take hold globally?
Correct I believe, but they don't actually vote for the member of the electoral college - they vote for which president or party they want in power - and the electoral college members are supposed to pass this on. It has happened that they don't, and while I believe that can result in problems for the misbehaving college member back home, it wouldn't invalidate the election.
There is no magic solution - you are talking about managing multiple environments with different requirements and technologies in some meaningful, automated way.
You're looking at home-brew here.
What you want to aim for is
0) Stop using multiple technologies if you can. If that's not an option, it just makes more work.
1) Clearly define policies regarding development, testing, and release. These have nothing to do with tools. You build and select your tools based on these policies.
2) Automated pushbutton deployment. You want your code releases of each new version of a site to be automated. You also want rolling back to the previous version to be automated. This applies for CI, QA, and whatever other stages you want, all the way to Production. 3) Automated deployment should involve at a minimum tagging a given revision and pushing it to the correct environment.
4) You can use commit hooks or some other method against TRUNK to run a CI server that continually does regression testing and other funky stuff... as well as just shows you a live version of what's in trunk "right now".
5) When working towards a target release,developers need to include any necessary scripts to update (and rollback, if necessary) their respective databases.
6) Config data... can be handled by having a separate/config folder for each environment, version controlled separately - and where access and change control are again strictly defined and limited, and well documented. this would automatically be inserted by your pushbutton deployment process.
If you want to take into account those "great" odds, you have to look at your expected total outlay and strategy.
At round 10 - you *cannot* say "I can safely lay this $512, because my odds of losing are.0013". Statistics have no memory... as Mr. Durden said.
What you can say is "I'm going to play up to 10 rounds, doubling my bet each round if i lose, and stop after I lose $1023". By this strategy, when you do win, you will be up $1 on the house. You can also safely say that the odds of losing all 10 rounds in a row are.00051
Your odds of losing ten rounds in a row, then, are.00051, or 1,960:1
You are risking 1023 to win $1, so your expected win ratio is 1,023:1.
That's still a house edge of 0.52 - it hasn't changed:)
Correct but for the wrong reason - the system works because the high number of high-value cards in the shoe increases the odds of the dealer busting out - so when the count is high, you avoid busting at all costs, and bet high.
It's nto because your odds of getting a blackjack have increased - because the odds of the dealer hitting the blackjack have also increased, and if he hits a blackjack, the most you can hope for is a push.
The probablity of losing 2 rounds in a row is.26. but that doens't mean if you lose the first round, your odds of losing the second round are.26. Your odds of losing the second round are still.51.
Slashdot Mirror
That's an option with this ZFS feature - but they are suggesting it's only optional, and that for statistical reasons you can probably rely on the hash alone.
Basically saying that the odds of a hash collision causing irreperable data loss are orders of magnitude less likely, even in extreme cases, than the odds of losing that same data in your current raid setup.
They make the point that the likelihood of a hash collision (and ensuing corruption) is many orders of magnitude less likely than already recognized odds of data corruption in the physical media itself, including raid and redundancies - even in extreme cases of zetabyte filesystems with 128k block sizes.
(meaing if you weren't worried about your current setup, and you're worried about hash collisions, you have your priorities backwards)
Bingo.
Exactly.
"I don't see how Apple can justify an $1,100 (USD) price difference. This isn't a little more expensive, this is double the price."
People keep buying them. You don't sell things based on what they cost to make - you sell them based on how much people are willing to pay.
Who cares about the EULA - what about the requirements written right on the box? A reasonable person, at the time of purchase, knows what is required to run said software.
It says right there "Mac with Intel processor."
To expect them to provide any type of support or work for anything OTHER than what is written right there is just silly.
"Any cost savings you can achieve by outsourcing to a more specialized company never seems to materialize."
Agreed.
Unfortunately, what we need are demonstrable cases where this is true.
Running full scale in-house development, especially if you have fat regulatory manuals to follow (PCI, SOX, etc) - requires quite a bit of staffing and process. Project managers, product lifecycles, all that buzz. It's a whole other thing that has to be managed.
Outsourcing looks good on the books. It's a line item, rather than a department.
I think you are misinterpreting the statement.
The point is that
a) Yes, system admins can read your mail. Even though they don't, they CAN.
b) You know they can, and that those mails will sit on the company's servers in plaintext -
therefore, YOU are exposing your emails to the company in question on a regular basis.
They are warranted - the warrant is against the company holding the email, not against you.
"But the justification should not rest on wrong-headed assumptions like the notion that ISP customers "expose to the ISP's employees in the ordinary course of business the contents of their e-mails.""
It might be a bit far reaching... but come on, system administrators have had access routinely to people's mailbox contents since forever (on most mail systems). Not that we go around snooping on your mail, but we can and do have access to it, if it's plaintext, at any time. If you are sending emails through any provider without encryption and assuming that some staff at that provider are not technically capable of reading and copying your emails, you are delusional.
This is not like snail-mail, where although you know the postman could open your mail, you also know he'd go to prison for it.
There are several formulas to generate PI, to any accuracy required.
In every situation - there is a limit to the accuracy required. Significant digits and all that.
You only need PI to the same accuracy as the other measurements you are computing against.
Did they have another system to put in place?
It also depends on what their design goals were - perhaps they met them?
It's easy to look back in hindsight and say "That's obvious" - but if as a previous poster said, they were designed to shoot down slower targets, and as another said, the system was required to re-boot and re-synch every 36 hours, and this was ignored..... that's design.
Someone signed off on the design and use case.
Fines? Prison?
And if that seems too extreme.... change the laws to make sense?
I'm not one of those "throw copyright out the window' guys - but something should change. Copyright law was created by us in response to our newfound ability to do things like use the printing press and record audio for mass productions. WE recognized that we wanted to protect, ultimately, the creators of these works. THe laws were sufficient for the time.
Now, with the internet, we've made another quantum leap in our ability to copy.. rather than being feasible on a commercial scale, it's possible for something to be available to everyone, at a cost approaching zero, globally, at a personal level. The law needs to catch up somehow.
That economic thing goes both ways, Canada being the US' largest trading partner, and the Canadian government doesn't need to ask for "permission" from the US to pass legislation.
Great... get your thoughts down on paper and you'll have a killer app.
Unfortunately, all of those things like "key signing" and "keys" and "trust" are currently required for PKI to be useful.
Someone has to mess around with all that "stuff" to make it work... and if it's not you, you have to trust someone else (software vendor, ISP) to do it for you.
The problem with encryption for email is you need some kind of trust heirarchy to authenticate everyone. Without that, you never know if you're being middled, and therefore you might as well not have encryption.
Given that even sensible, educated, technical people will often ignore certificate trust warnings.... .who thinks email encryption will actually take hold globally?
Correct I believe, but they don't actually vote for the member of the electoral college - they vote for which president or party they want in power - and the electoral college members are supposed to pass this on. It has happened that they don't, and while I believe that can result in problems for the misbehaving college member back home, it wouldn't invalidate the election.
"You don't need development machines. Let them develop on their workstations. They're developers, they'll figure it out."
Quite often, they aren't - they are web design guys who should not be confused with programmers of any sort.
There is no magic solution - you are talking about managing multiple environments with different requirements and technologies in some meaningful, automated way.
You're looking at home-brew here.
What you want to aim for is
0) Stop using multiple technologies if you can. If that's not an option, it just makes more work.
1) Clearly define policies regarding development, testing, and release. These have nothing to do with tools. You build and select your tools based on these policies.
2) Automated pushbutton deployment. You want your code releases of each new version of a site to be automated. You also want rolling back to the previous version to be automated. This applies for CI, QA, and whatever other stages you want, all the way to Production.
3) Automated deployment should involve at a minimum tagging a given revision and pushing it to the correct environment.
4) You can use commit hooks or some other method against TRUNK to run a CI server that continually does regression testing and other funky stuff... as well as just shows you a live version of what's in trunk "right now".
5) When working towards a target release,developers need to include any necessary scripts to update (and rollback, if necessary) their respective databases.
6) Config data... can be handled by having a separate /config folder for each environment, version controlled separately - and where access and change control are again strictly defined and limited, and well documented. this would automatically be inserted by your pushbutton deployment process.
It did? I seem to recall it simply poppuped a window a couple of days ago and said "This has been disabled. Okay?" and your option was 'Okay"
Actually I think it was late and I've made a mistake in there somewhere.
I promise a concise, accurate summary later today, with math to back it up.
If you want to take into account those "great" odds, you have to look at your expected total outlay and strategy.
At round 10 - you *cannot* say "I can safely lay this $512, because my odds of losing are .0013". Statistics have no memory... as Mr. Durden said.
What you can say is "I'm going to play up to 10 rounds, doubling my bet each round if i lose, and stop after I lose $1023". By this strategy, when you do win, you will be up $1 on the house. .00051
You can also safely say that the odds of losing all 10 rounds in a row are
Your odds of losing ten rounds in a row, then, are .00051, or 1,960:1
You are risking 1023 to win $1, so your expected win ratio is 1,023:1.
That's still a house edge of 0.52 - it hasn't changed :)
Correct but for the wrong reason - the system works because the high number of high-value cards in the shoe increases the odds of the dealer busting out - so when the count is high, you avoid busting at all costs, and bet high.
It's nto because your odds of getting a blackjack have increased - because the odds of the dealer hitting the blackjack have also increased, and if he hits a blackjack, the most you can hope for is a push.
Have you played this strategy enough to know that you aren't just looking at a statistical anomaly?
The probablity of losing 2 rounds in a row is .26. but that doens't mean if you lose the first round, your odds of losing the second round are .26. Your odds of losing the second round are still .51.