macemoneta

This isn't 'How to Think Like A Computer Scientist', but rather 'Introducing Programming with Python'.

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

Diatomaceous earth (DE) does the job.

https://secure.wikimedia.org/wikipedia/en/wiki/Diatomaceous_...

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.

Which is at odds with the (correct) definition of MTTF as a rate-based calculation:

http://en.wikipedia.org/wiki/Failure_rate

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.

Your statement was:

"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.

Yeah, a closed source application installed as root, with the express purpose of accessing your webcam and microphone. What could go wrong?

tl;dr: For RAID0 arrays there is a non-linear increase in the probability of failure, but the MTTF/MTBF doesn't change much.

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.

You'll probably find this interesting reading on the internal architecture of SSDs:

     http://www.denali.com/wordpress/index.php/dmr/2010/02/02/ssd-interfaces-and-performance-effects

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.

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.

It really depends on the platform and requirements.

On a desktop, a three-drive RAID0 provides about the same performance, and gives you nearly 40x the storage for a given price-point.

On a mobile platform the physical space, vibration/motion, and power constraints coupled with the increased performance may make SSDs worthwhile.

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.

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:

http://en.wikipedia.org/wiki/Smolt_(Linux)

The data is aggregated for reporting:

http://www.smolts.org/

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.

Model numbers? Isn't that why UUIDs were created? Unique identifier, and anonymous:

https://secure.wikimedia.org/wikipedia/en/wiki/UUID

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.

As background, from WikiPedia:

"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.

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.

My comment was in reply to the author's statement that "sharing a copyrighted design is theft". This is clearly false.

Why does everyone forget that copyrighted content can be shared if the license allows it? Copyright does not automatically prohibit sharing.

   http://creativecommons.org/about/
   http://www.opensource.org/licenses/alphabetical

The real problem is that content creators frequently don't make finding the license easy - if they even use one.

It's a joke. If you're not using v4l, then you're rolling your own. So you either have to fix it yourself, or hold it upside down. :)

Regressive is the term used here for describing property taxes. While not entirely appropriate, for the sake of communication commonly agreed upon terminology is used by politicians and the media.

Yes, the taxation of property needs to be tied to market value, but it needs to be capped in some manner to prevent abuse. For example, pro-rating the tax against a sliding scale based on income.

The problem is that people get old. Bizarre concept, I know. Once people retire, their incomes tend to be fixed. As property tax rises uncontrolled (and unpredictably) year to year, the people that are the foundation of the community are forced out. Friends and neighbors leave - not because they want to - but because they have no choice. When the taxes on your home become 30%, 40% or more of your gross on the home you've lived in all your life, what do you do?

It still might not be so bad if new people moved in. However, if the taxes are too high home sales in a recession become difficult or impossible. Homes sit empty as people walk away from the properties. They become run-down, and the neighborhood degrades. To compensate for the loss of revenue, local government raises the tax rate continuing the cycle.

They neglected the impact of property taxes, which are regressive (independent of income). Here in NJ for example, my property taxes are now at 25% of my income, and that's before other taxes and fees (income tax, sales tax, gas tax, tolls, etc.). As homeowners go bankrupt or walk away from their homes, the tax rate is raised to keep the local fiefdom's income level stable.

In the United States, the problem started with the war on drugs. The increasing privatization of the prison system made crime a business opportunity, which in turn lead to more things being criminalized.

http://upload.wikimedia.org/wikipedia/commons/thumb/5/54/US_...

But that's not all; prison labor is now used as cheap labor to compete with foreign countries, instituting a new age of under-the-radar slavery.

http://www.youtube.com/watch?v=gwT6CisM0mU

The more you look at this cyclic process, the more disturbing it becomes.

You are assuming shared memory as the communication medium. When using processes, you can use sockets for IPC for example. The advantage is that the application can then scale beyond a single system with no change - something that's impossible to do with threads. It's easier to implement and more scalable. Far from a red herring, the persistent focus on threads for concurrency imposes limitations that are unnecessary in modern systems, and slows development.

Exactly. For example, process forks are much lighter in overhead than they used to be (depending on the platform), and for long running processes their initiation and termination is insignificant compared to the overall task time. Processes are conceptually easier for people to get started with when starting development of concurrent software.

My current quad core is running about 550 processes at near-idle. Their workload is distributed across cores with no effort. Most Apache implementations use multiple processes for the workers, as an example.

The idea that multi-core code has to have threading actually slows development, because it's a more difficult concept to implement correctly. Multiple processes get the job done as well in many instances, and since each process is single threaded it's easier to implement and maintain.

That bill carries no legal weight; it's an opinion, not a law.

I switched all our machines to Linux (currently Fedora 13) 10 years ago, and never looked back. All our software since is free.

I haven't read a (paper) newspaper or magazine in about 10 years, and I'm 54. I think it's weird that people still read paper.

Our local free newspaper still delivers to us each week (we can't get them to stop), but I actually read the content online at their website a couple of days before I get the hard copy version. It just goes directly to the recycling bin, unopened.

Magazines are even worse. Because they typically have a 2-4 month lead time, I've read pretty much everything weeks before they come out, for free, elsewhere.

As Craig Ferguson puts it, newspapers and magazines are like an old papery blog. Set up your feed reader and never look back.

Rooting isn't impossible on the Droid X, it's just annoyingly difficult. If someone wanted to distribute malware ROM images, they just need to wait for the root to be accomplished by someone else. There's no real protection.

If it's Verizon that's behind this to "protect the network" it's starting to sound like we're heading for another "Carterfone Decision":

https://secure.wikimedia.org/wikipedia/en/wiki/Modem#The_Car...

The Nokia N900 doesn't make life difficult for users. To root it you just download and run 'rootsh'. Done. The network hasn't exploded simply because it's easy to root and update ROMs.