You seem to be confused about who's doing the review. Nellardo has no financial relationship with OSTG. And his text ends above the bar.
Slashdot adds the
You can purchase 'Blah' from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Someone mod the parent down. OSTG isn't stealling from anyone.
From the article:
84% of internet users have used search engines. On any given day, 56% of those online use search engines.
92% of those who use search engines say they are confident about their searching abilities, with over half of them, 52%, saying they're "very confident".
Which should have been obvious even from the abstract. 'Web Searchers' != 'All survey respondents'.
I can't agree enough. I wasn't sure about Eric Flint's 1632. I ripped through that (on my Clie tj-35) in a few days. I started looking around for 1633 in paperback, since I really do prefer reading an actual book, but I endded up finishing the e-book before I could track it down.
But I did end up buying the hardcover of "The Galileo Affair", so I guess it all worked out for Baen and Eric Flint.
Baen also included all of Weber's Honor Harrington books on CD in the last hardcover Honor Harrington book.
You couldn't really do anything in Excel that you couldn't with 1-2-3, but one day we woke up and everyone was calling spreadsheets Excel instead of Lotus.
We're in violent agreement here. Even though the book is about 30 years old, it still applies today.
But, when someone picks it up, they see FORTRAN and PL/1, no C, no Java, and assume that it's obsolete.
The languages, although in common use when the book was written, now obscure, rather than reveal.
Re:Big Brother Google
on
Gator Examined
·
· Score: 5, Informative
google watch.org was founded by Daniel Brandt. He doesn't like google because they don't rank his site, NameBase, very highly. NameBase collects citations for people in power. It's somewhat slanted towards conspiracy and secrecy, with a heavy leftist bias.
He would prefer that searches for, say, "Oliver North", turn up this, rather than this.
Quoting Brandt quoting himself:
Regarding his opposition to Google's hegemony, Brandt says, "It feels like the right thing to do. It's the cyber equivalent of my draft resistance days." (see U.S. v. Brandt, 435 F2d 324, United States Court of Appeals, Ninth Circuit, Dec. 4, 1970)
Two reasons for the training. One is that they don't want to pay to train someone who is more likely to leave than a permanent employee. The second is that it's one of the tests used by the IRS to distinguish between employees and contractors.
Most of the libraries that are in the gray area are written by people who work closely with the MPlayer team anyway, and/or are designed for other projects and need heavy modifications to be used in MPlayer (one of the conflicts is just based on the absence of a ChangeLog file!!! You gotta be kidding).
Reading the thread, someone spent about 5 minutes looking at the source for mplayer. He discovered that it included code for other libraries. Those libraries had been modified, with no notice that the source had been changed, nor by who. This conflicts with the letter of the GPL.
Now, the mplayer developers claim that the authors of the the library said it was OK.
So, it it OK for someone else to make changes to the library and distribute it? Is it OK to redistribute the modified version outside of mplayer? What license applies to the modified version? Who holds copyright?
And should you take the word of the mplayer developers that everything is OK?
Would you take the word of the seller's real estate agent that a house is up to code, or do you hire an engineer?
Debian has to asses the risk for themselves. And the mplayer developers aren't being very reassuring about all the i's being dotted and t's being crossed. So it will continue to be the case that mplayer isn't distributed as part of Debian.
Actually, it does offer some very practical advice. Just not the advice you wanted. Nor is it directed to the line programmer.
This is information that's of use to a team lead trying to decide what modules should receive some attention. Ideally before QA, or worse the customer, finds bugs related to that module.
It's a bit of a truism that sloppy code is buggy code. This paper is showing some solid evidence of that. It's not surprising. If there are simple mistakes in the code that could have been fixed with just a small amount of attention, that indicates that the probability of deeper errors is also greater. It's a Bayesian filter for code, instead of spam.
One of my favorite metrics for finding buggy modules is rather simple. Number of commits on the module. In most of the projects I've worked on, I've found high correlation with number of commits and number of outstanding bugs related to a module. It indicates that the whole module needs to be reworked, rather than the small, incremental, patches that have been applied to it so far. Or that the requirements have drifted from what the code was originally spec'd against, and the code is no longer a good fit.
I've had some programmers argue that it's OK to leave dead code in a system, or unused variables, since the compiler will take care of them. The problem is that the compiler is not the most important audience for the code. The code needs to speak to other programmers. And if it's harder to understand than it needs to be, then the code doesn't do its job.
They're i386 for instruction set, but i686 for selection of instructions. Actual use of i586/i686 instructions buys you very little on that architecture, and can be a negative on Athlons.
Now, you might be able to get another 2% of performance by compiling for your specific arch, and you can do that by recompiling.
Or you might not. A lot of high performance code is in asm, and that's independent of the architecture.
The configuration choices are a much better reason for building from source. The downside is that your installation is unlike all other installations.
According to MySQL CEO Marten Mickos...
the missing functionality in products such as MySQL is not needed by some companies
This was the party line on transactions for ages. As if it would be OK to have inconsistent or lost financial records.
The classic example, a transfer of funds between two accounts. The withdrawal from one goes OK, but the post to the other fails. According to the MySQL crowd, it's OK for the bank to loose that money. Or to try to fix it up later, while checks are bouncing.
Now that they have transactions, at least sometimes, on some tables, if you set it up that way, I'm waiting to find out what else they think I don't need.
MySQL treats performance as a primary feature. That's almost always a bad idea. Correctness HAS to come first. If it doesn't have to work, I can make it go as fast as you want,
Slashdot Mirror
You are easily impressed. A 1 out of 20 chance isn't all that unlikely.
Slashdot adds the
Someone mod the parent down. OSTG isn't stealling from anyone.
From the article: 84% of internet users have used search engines. On any given day, 56% of those online use search engines. 92% of those who use search engines say they are confident about their searching abilities, with over half of them, 52%, saying they're "very confident". Which should have been obvious even from the abstract. 'Web Searchers' != 'All survey respondents'.
The OED lists insecure in the sense of 'Unsafe, exposed to danger' with references going back to 1654.
But I did end up buying the hardcover of "The Galileo Affair", so I guess it all worked out for Baen and Eric Flint.
Baen also included all of Weber's Honor Harrington books on CD in the last hardcover Honor Harrington book.
-SMD
multiply a by b giving c
COBOL is alive and well. If it's simple enough, managers will be able to express what they want, without all of those expensive programmers.
I don't think anyone should be surprised when people google with a new engine.
You couldn't really do anything in Excel that you couldn't with 1-2-3, but one day we woke up and everyone was calling spreadsheets Excel instead of Lotus.
But, when someone picks it up, they see FORTRAN and PL/1, no C, no Java, and assume that it's obsolete. The languages, although in common use when the book was written, now obscure, rather than reveal.
The fact that the language under critque was FORTRAN, unfortunately today, obscures the underlying truths they were discussing.
Fortunately, Google makes him easy to track down.
He would prefer that searches for, say, "Oliver North", turn up this, rather than this.
Quoting Brandt quoting himself: Regarding his opposition to Google's hegemony, Brandt says, "It feels like the right thing to do. It's the cyber equivalent of my draft resistance days." (see U.S. v. Brandt, 435 F2d 324, United States Court of Appeals, Ninth Circuit, Dec. 4, 1970)
I'm sure that would fly with the FTC and DOJ.
Even in this loose regulatory environment, there are some limits.
Two reasons for the training. One is that they don't want to pay to train someone who is more likely to leave than a permanent employee. The second is that it's one of the tests used by the IRS to distinguish between employees and contractors.
Now, the mplayer developers claim that the authors of the the library said it was OK.
So, it it OK for someone else to make changes to the library and distribute it? Is it OK to redistribute the modified version outside of mplayer? What license applies to the modified version? Who holds copyright?
And should you take the word of the mplayer developers that everything is OK?
Would you take the word of the seller's real estate agent that a house is up to code, or do you hire an engineer?
Debian has to asses the risk for themselves. And the mplayer developers aren't being very reassuring about all the i's being dotted and t's being crossed. So it will continue to be the case that mplayer isn't distributed as part of Debian.
Life goes on.
This is information that's of use to a team lead trying to decide what modules should receive some attention. Ideally before QA, or worse the customer, finds bugs related to that module.
It's a bit of a truism that sloppy code is buggy code. This paper is showing some solid evidence of that. It's not surprising. If there are simple mistakes in the code that could have been fixed with just a small amount of attention, that indicates that the probability of deeper errors is also greater. It's a Bayesian filter for code, instead of spam.
One of my favorite metrics for finding buggy modules is rather simple. Number of commits on the module. In most of the projects I've worked on, I've found high correlation with number of commits and number of outstanding bugs related to a module. It indicates that the whole module needs to be reworked, rather than the small, incremental, patches that have been applied to it so far. Or that the requirements have drifted from what the code was originally spec'd against, and the code is no longer a good fit.
I've had some programmers argue that it's OK to leave dead code in a system, or unused variables, since the compiler will take care of them. The problem is that the compiler is not the most important audience for the code. The code needs to speak to other programmers. And if it's harder to understand than it needs to be, then the code doesn't do its job.
So if your web server is hacked and defaced, you don't have to reveal anything. If your credit card database is hacked, you do.
I don't see the problem with this. As it is, confidential information is exposed, and no one knows about it.
And in New York City, to a Democrat, Rudy Guiliani looks like a goose-stepping facsist. But in Montana, he looks like a typical New York Liberal.
And if you know that, you probably are NOT a member of Generation X. It was before your time.
Now, you might be able to get another 2% of performance by compiling for your specific arch, and you can do that by recompiling.
Or you might not. A lot of high performance code is in asm, and that's independent of the architecture.
The configuration choices are a much better reason for building from source. The downside is that your installation is unlike all other installations.
That's becuase it's Free as in Free Peoples Democratic Socialist Republic.
The classic example, a transfer of funds between two accounts. The withdrawal from one goes OK, but the post to the other fails. According to the MySQL crowd, it's OK for the bank to loose that money. Or to try to fix it up later, while checks are bouncing.
Now that they have transactions, at least sometimes, on some tables, if you set it up that way, I'm waiting to find out what else they think I don't need.
MySQL treats performance as a primary feature. That's almost always a bad idea. Correctness HAS to come first. If it doesn't have to work, I can make it go as fast as you want,
Tell them that their wireless access point attempted to gain unauthorized access to your computer network.
man vs. nature
man vs. man
man vs. the environment
man vs. machines/technology
man vs. the supernatural
man vs. self
man vs. god/religion These are also known as the basic conflicts. Plots are variously numbered at 20 or 36. Take a look here for longer lists.