I've been running Oracle on Slackware since 8.0.5. No problems. Software that comes packaged in RPMs and depends on Red Hat RPMs can be very annoying, for example HP Insight Manager. Spent several frustrating hours trying to install it on Debian the other day.
The numbering system used by many, not all, projects is major.minor.teeny:
Bugfixes increment the teeny number.
New, backwards compatible features increment the minor number and set teeny to 0.
Changes that break backwards compatibility increment the major number and set the minor and teeny numbers to 0.
And of course, the major number starts out as 0, so the only way the major number could be anything else is by introducing incompatible changes.
Libraries use similar rules, or at least rules with the same effect, except that many libraries have separate so-numbers (which dictate compatibility) and "marketing" numbers.
Completely? I thought several scenes had been lost for good.
Re:Testing - The Anti Quality Process
on
QA != Testing
·
· Score: 1
The algorithm in the Powerpoint document is absurd because nobody tests software like that (for reasons you outline above, among others). Or jellybeans for that matter.
2. Present performance figures for an inner kernel, and then represent these figures as the performance of the entire application.
It is quite difficult to obtain high performance on a complete large-scale scientific application, timed from beginning of execution through completion. There is often a great deal of data movement and initialization that depresses overall performance rates. A good solution to this dilemma is to present results for an inner kernel of an application, which can be souped up with artificial tricks. Then imply in your presentation that these rates are equivalent to the overall performance of the entire application.
4. Scale up the problem size with the number of processors, but omit any mention of this fact.
Graphs of performance rates versus the number of processors have a nasty habit of trailing off. This problem can easily be remedied by plotting the performance rates for problems whose sizes scale up with the number of processors. The important point is to omit any mention of this scaling in your plots and tables. Clearly disclosing this fact might raise questions about the efficiency of your implementation.
8. If MFLOPS rates must be quoted, base the operation count on the parallel implementation, not on the best sequential implementation.
We know that MFLOPS rates of a parallel codes are often not very impressive. Fortunately, there are some tricks that can make these figures more respectable. The most effective scheme is to compute the operation count based on an inflated parallel implementation. Parallel implementations often perform far more floating point operations than the best sequential implementation. Often millions of operations are masked out or merely repeated in each processor. Millions more can be included simply by inserting a few dummy loops that do nothing. Including these operations in the count will greatly increase the resulting MFLOPS rate and make your code look like a real winner.
10. Mutilate the algorithm used in the parallel implementation to match the architecture.
Everyone is aware that algorithmic changes are often necessary when we port applications to parallel computers. Thus in your parallel implementation, it is essential that you select algorithms which exhibit high MFLOPS performance rates, without regard to fundamental efficiency. Unfortunately, such algorithmic changes often result in a code that requires far more time to complete the solution. For example, explicit linear system solvers for partial differential equation applications typically run at rather high MFLOPS rates on parallel computers, although they in many cases converge much slower than implicit or multigrid methods. For this reason you must be careful to downplay your changes to the algorithm, because otherwise the audience might wonder why you employed such an inappropriate solution technique.
I do not for one moment believe that Amdahl's law won't affect these systems. Dual-core won't be a problem, quad-core probably won't, but I can't see that stuffing in more cores will solve the scalability problem in the long run.
That's what I thought too. Acknowledged by whom? I'm pretty sure that if the Linux developers knew of patent violations in the kernel, those violations would be removed plenty fast.
Since the numbers are not there in TFA to actually do the math, I did a little research on my own and found
the original IDC article. It seems the numbers are not there either, but these snippets should allow us to calculate market share in 4Q03 and 4Q04:
"Unix server revenues were $5.2 billion in the quarter, increasing 2.7% year over
year against a difficult compare for 4Q03."
"Additionally, on a sequential basis, Unix servers grew dramatically in 4Q04, add
ing more than $1 billion in quarterly revenue."
"Linux servers generated $1.3 billion in quarterly revenue, representing 9.0% of
worldwide server revenue."
"Overall, Linux server revenue grew 35.6% year over year"
"factory revenue in the worldwide server market grew 5.1% to $14.4 billion in the
fourth quarter of 2004"
"For the full year 2004, worldwide server revenue grew 6.2% to $49.0 billion"
So...
Unix in 4Q03 was 5059.6 million.
Linux in 4Q03 was 837.2 million.
Total market in 4Q03 was 13717 million.
Unix/Linux marketshare was 42%
Unix in 4Q04 was 5200 million.
Linux in 4Q04 was 1300 million.
Total market in 4Q04 was 14420 million.
Unix/Linux marketshare was 45%
I still don't understand how that would benefit Google. The competition would immediately implement similar technology for everybody, and Google would be stuck with the minority users.
Because then they would lose visitors who use IE, which is still the dominant browser. They can't afford to do that. And even if they could, the shouldn't.
What part of
"Linux servers represented 9 percent of worldwide server revenue in 2004, which is 35.6 percent growth compared to the year before."
don't you understand?
He did that because at the time, Microsoft didn't have a product. They didn't even have a useful TCP/IP stack. I'm pretty sure that Bill Gates had an idea of what was coming, but they needed some time to catch up.
Can't blame him for that. What was he supposed to say? "You know, this is the future, but you can't buy it from us."
Isn't this the exact opposite of what they've been doing before? It seems like they now want to open up what they have previously been trying to keep proprietary for only one reason: the product is becoming irrelevant.
Slashdot Mirror
Yes! Not to mention the bandwidth. Imagine a whole office downloading this crap onto every PC.
It was reported on Bugtraq on Feb 13. Here: http://www.securityfocus.com/archive/1/390378/2005 -02-07/2005-02-13/0
http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPIComm and=RedirectToDomain&DomainUrl=http://siag.nu/
That's a link to ebay.com which redirects to siag.nu. And it doesn't look like a glitch, it looks like it's on purpose.
I've been running Oracle on Slackware since 8.0.5. No problems. Software that comes packaged in RPMs and depends on Red Hat RPMs can be very annoying, for example HP Insight Manager. Spent several frustrating hours trying to install it on Debian the other day.
- Bugfixes increment the teeny number.
- New, backwards compatible features increment the minor number and set teeny to 0.
- Changes that break backwards compatibility increment the major number and set the minor and teeny numbers to 0.
And of course, the major number starts out as 0, so the only way the major number could be anything else is by introducing incompatible changes.Libraries use similar rules, or at least rules with the same effect, except that many libraries have separate so-numbers (which dictate compatibility) and "marketing" numbers.
Completely? I thought several scenes had been lost for good.
The algorithm in the Powerpoint document is absurd because nobody tests software like that (for reasons you outline above, among others). Or jellybeans for that matter.
Quoting Twelve Ways to Fool the Masses When Giving Performance Results on Parallel Computers:
I do not for one moment believe that Amdahl's law won't affect these systems. Dual-core won't be a problem, quad-core probably won't, but I can't see that stuffing in more cores will solve the scalability problem in the long run.
Certainly. Any problem that can be parallelized benefits. Chess or pretty much any game engine that searches a game state tree can be parallelized.
The jellybean example is absurd. I know an algorithm which will, by looking at only 100% of the beans, find 100% of the defective ones.
That's what I thought too. Acknowledged by whom? I'm pretty sure that if the Linux developers knew of patent violations in the kernel, those violations would be removed plenty fast.
An interesting fact, as I noted in another thread, is that combined Unix+Linux marketshare seems to be increasing.
"Unix server revenues were $5.2 billion in the quarter, increasing 2.7% year over year against a difficult compare for 4Q03."
"Additionally, on a sequential basis, Unix servers grew dramatically in 4Q04, add ing more than $1 billion in quarterly revenue."
"Linux servers generated $1.3 billion in quarterly revenue, representing 9.0% of worldwide server revenue."
"Overall, Linux server revenue grew 35.6% year over year"
"factory revenue in the worldwide server market grew 5.1% to $14.4 billion in the fourth quarter of 2004"
"For the full year 2004, worldwide server revenue grew 6.2% to $49.0 billion"
So...
Unix in 4Q03 was 5059.6 million.
Linux in 4Q03 was 837.2 million.
Total market in 4Q03 was 13717 million.
Unix/Linux marketshare was 42%
Unix in 4Q04 was 5200 million.
Linux in 4Q04 was 1300 million.
Total market in 4Q04 was 14420 million.
Unix/Linux marketshare was 45%
I still don't understand how that would benefit Google. The competition would immediately implement similar technology for everybody, and Google would be stuck with the minority users.
Because then they would lose visitors who use IE, which is still the dominant browser. They can't afford to do that. And even if they could, the shouldn't.
What part of "Linux servers represented 9 percent of worldwide server revenue in 2004, which is 35.6 percent growth compared to the year before." don't you understand?
I'm assuming that the vast majority of Linux servers are x86.
Can't blame him for that. What was he supposed to say? "You know, this is the future, but you can't buy it from us."
Isn't this the exact opposite of what they've been doing before? It seems like they now want to open up what they have previously been trying to keep proprietary for only one reason: the product is becoming irrelevant.
The live CD is based on Slax, which is based on Slackware, which is built for i486. Until recently it was i386.
Re:Write-ahead logging
Apparently a problem with Linux 2.6.x on AMD Opteron. The surviving server was a Xeon. Interesting.
- They were using myisam tables
- They were running an old version of linux with broken fsync
- They were using non-battery backed disk cache
The first is the most common cause of corruption in mysql databases. The last two would have killed any database.It supports transactions right now, not "someday".
Hmm, this AC sounds just like the actual Theo.