Doesn't seem like diatomaceous earth would help much with bedbugs.
DDT actually wasn't all that bad. The problem was that it was way way way overused (back in the fifties they were literally pouring thousands of gallons into lakes and rivers because they thought it would be a good idea to get rid of the mosquitos).
Yes, and it's pretty much harmless in itself, but since when does installing one package (esp. from a third party with no verification beforehand) install a new apt key into your keyring (thus allowing all packages signed by that key, no matter what they are) and reconfigure the package manager itself? It's ludicrous.
It's not a mistake: the development deb for Chrome did exactly this - installed the repository key and a cron job to "protect" the apt-sources entry. Of course it's not really doing this secretly, in that you can read about it in the post-install script before you run dpkg, but I agree it doesn't feel right.
Also, can't this be said of any package you install through the package manager? If you install it as root, then in principle you're giving root access to whatever is in the package. If you don't like it, there's always a way to run it with ordinary permissions (but the extra fiddling to get that working may be hairy) or under mandatory access control (definitely hairy).
I back up several times a day, automatically. I've run RAID arrays for years with no problems, but all drives eventually fail. An SSD is internally a RAID0 that can be up to 16 wide (that's how they get their performance). Used and managed properly (including proper backup and recovery), RAID0 works very well with good quality drives. If you have noise problems, then you likely have vibration issues that will shorten the life of your drives. I use anti-vibration mounts for all hard drives, and I hear my (quiet, anti-vibration mounted) fans more than I hear my drives. I also spin down the backup drives when they are not in use, so they add no additional noise.
An SSD is internally a RAID0 that can be up to 16 wide (that's how they get their performance).
Erm. Actually they get their performance because they write to NAND instead of spinning platters. SSD controllers are also quite a bit smarter than plain RAID0.
RAID0 works very well with good quality drives.
A RAID0 over three disks has about 1/3 the MTBF of a single disk.
That can still be a worthwhile trade-off if you need the extra capacity, but if you're mostly after performance and reliability then a pair of SSDs, or even a single SSD, is the better choice.
Also, while RAID0 reduces the MTBF, it's not linear. Drive life is not magically shortened as a result of the drive being in a RAID array (if you take care to isolate synchronous vibration). The life of the array is equal to the shortest drive life. In other words, if a drive would have failed after 25,000 hours in standalone operation, it will still fail in 25,000 hours in an array. The other drives may run to 100,000 hours, but it's a "weakest link" failure mode.
Also, while RAID0 reduces the MTBF, it's not linear.
Well, it is inverse proportional.
The life of the array is equal to the shortest drive life.
Erm. To be clear: Your risk of having a RAID0-set (over 3 disks) fail during a given timespan is 3 times higher than having a single-disk-"set" fail in the same timespan.
In other words, if a drive would have failed after 25,000 hours in standalone operation, it will still fail in 25,000 hours in an array.
That calculation makes no sense.
If you have a single drive then that will fail, on average, after 25k hours. If you stripe over three of these drives then your array will, on average, fail after 8333 hours.
While the probability of failure is nearly a function of the number of drives, the MTBF/MTTF calculations do not work that way.
For example, if there were a probability of 5% that the disk would fail within three years, in a three disk RAID0 array, that probability of failure would be:
P=(1-(1-.05)^3)=.14263
In other words, 14.3% probability of failure within three years. That doesn't mean it will fail in that time frame. It means if you have a large population of that configuration, that is the rate you would be dealing with for drive replacement planning.
The MTBF and MTTF calculations apply to populations of drives (e.g. a given model) not to a given drive. The values provide no predictability for the failure of any specific drive. Using the values for that purpose is a common misapplication. A drive with a MTTF of 1,000,000 power-on hours can fail in 15 minutes or never during its useful life.
As a result, a three drive array will have a higher probability of failure over a given interval, but the MTTF/MTBF of the drives is essentially unchanged.
Think of it this way... The probability of winning the lottery is one in 20,000,000. The probability that someone (anyone) will win the lottery in a given week may be one out of ten - 10%. In other words, some person wins the lottery, on average, one time in ten weeks. That doesn't mean that your probability of winning the lottery is 10%. It also doesn't mean that the average probability of winning the lottery is 10%. It also doesn't change the probability of winning the lottery; it's still one in 20,000,000, even if three people win in a 10 week interval.
Could it be you're just arguing for arguments sake?
My original point was: A RAID0 over 3 disks is about 3 times more likely to fail than a single disk running standalone. Fail means "total data loss". You confirm that point with your own math, yet still seem to be trying to argue that there was no difference. Sorry, that makes no sense to me.
"A RAID0 over three disks has about 1/3 the MTBF of a single disk."
This is incorrect, the MTTF and MTBF are not significantly changed. Assuming you meant failure probability, my issue with the probability variance is the linear relationship you imply.
If the variation were linear, a RAID array composed of drives with a 5% failure probability would reach certainty of failure (1.00 probability) within the interval at 20 drives. In actuality, it takes 225 drives to reach that probability.
The difference is a real world consideration for capacity management. What it means is that RAID0 arrays are not as failure prone as people think they are.
The person that wrote the Wikipedia article you referenced read the same mythology you did; repeating it doesn't make it true. The plural of anecdote is not fact.
Think about it yourself for a moment. If two cars are traveling 50mph, does that make their average speed 25mph (50/2)? Applying a divisor to a failure rate based on the number of devices is nonsensical.
You're right, there's no reason to try to correct the 20% of the population that believes the Sun revolves around the Earth. It's a lost cause; you win.
You're right, there's no reason to try to correct the 20% of the population
Erm wait, didn't I just suggest the exact opposite?
If you really think everyone has been wrong about this all the time then please, by
all means, correct wikipedia or write a blog post about the matter.
This "false" formula has been out there for quite some time and you find it
in pretty much every write-up on the topic, including those from RAID-vendors
who (I'd hope) have spent some thought on these things.
On the flip-side I haven't found a single source to support your thesis.
Thus I'd say the burden of proof is on you.
Make friends with spiders and house centipedes. They are the natural enemies of most every house pest, including bedbugs, and mostly harmless to people. The enemy of my enemy is my friend.
"The customer didn't really want to use a unique identifier though, because though it was anonymous, the customer wanted to count computers, but unique identifiers are for tracking (following a user over time)."
That seems to be a misunderstanding of the nature of a UUID. Simply replacing the model with the UUID provides no tracking in this use case, as it's a single purpose reference.
I can't figure out what exactly you are proposing here..
If you propose that they generate a new UUID on every ping the OS makes, then you'd be able to tell how many unique installations are active on any given day, but you wouldn't know how long they had been active, nor would you know what model of computer they were, nor would you be able to know how many were active for a longer time range such as a week or a month.
Fedora, for example, already does this with UUIDs and the smolt project. A UUID is generated on installation and used for the 'ping'. The user opts-in at first boot, and the software runs periodically:
So women are only permitted to search for men? No lesbians allowed? After the eHarmony lawsuit and $500,000 payout, you'd think dating sites wouldn't want to repeat that disaster.
"On November 13, 2006, Sun released much of Java as open source software under the terms of the GNU General Public License (GPL). On May 8, 2007, Sun finished the process, making all of Java's core code available under free software/open-source distribution terms, aside from a small portion of code to which Sun did not hold the copyright."
If Sun willingly made the code GPL licensed, and Google isn't using anything outside the GPL code, even if some of the technologies were covered by patents I don't see Oracle having a case. Right now, this sounds very much like the SCO - Linux suit that dragged on forever and went nowhere.
That's not true. See section 7 of the GPL. In part:
For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
However, it seems Sun can relicence the software under whatever they want, and the current versions of it wouldn't be under GPL anymore. I am not a lawyer, so I don't know exactly what this implies.
So you're saying that it grants users of the GPL code an exception from the patent owned by the original developers?
In that case, wouldn't the exception only be extended to Google if their implementation of Java was not independent from Sun's implementation? Because Devrak was derived from Apache Harmony, it might not share any code with Oracle Java.
Considering that Sun released Java before the GPL v3 was finished, I assume that it's under the GPL v2. v2 doesn't have the same patent guarantees that v3 does, and these guarantees were an important reason for creating v3. Specifically, the GPL v3 specifically prohibits this sort of "make it free software and then sue over the patents". The GPL FAQ claims that in some countries, releasing software under the GPL v2 constitutes a patent license, but I don't think that applies in the US.
There's no need to assume when authoritative information is but a few keystrokes away. And yes, it is under the GPL v2 + Classpath exception, except for Java ME which is under straight GPL v2.
And I would really wonder if they decide against Google. It looks almost like a trap of Sun/Oracle then, kind of "hey, here, use our code, it is open source now grin".
Or to put it different: Why did they use the GPL licence?
I actually have no problem with Apple's prices. People don't buy a Rolls-Royce because it's a car, they buy it because it's a Rolls-Royce. Comparing the purchase price or mpg to a Toyota Camry is missing the point.
I build my own machines, and don't buy Apple products. However, I see nothing wrong with charging what the market will bear for an upscale product.
"not merely because designs are being “shared” (read “pirated”), but because people are downloading free charts rather than paying for a designer’s work."
Pretty sure the real problem with that theory is those aren't the licenses most people choose.
Movies, software and games that are non-distributable have significant signs or precautions in place advertising that. The only thing that doesn't is music.
It's a good introductory text for learning Python. However programming is a very small part of Computer Science.
http://abstrusegoose.com/strips/computer_science_major.PNG