I'm not a legal expert, but I've been following the case. It appears that the judge is giving SCO every chance to make their case. The judge could slap SCO down and dismiss the suit today, but SCO would appeal. If the judge gives SCO every chance now to get their act together, then when the case is settled, SCO will probably not successfully appeal it.
IBM, meanwhile, is all in favor of SCO getting every chance to make their case. IBM knows that SCO doesn't have a case, IBM's lawyers are on salary instead of hourly billing, and IBM wants a clear and decisive victory over SCO, not a case thrown out on a technicality.
This lawsuit is very annoying, but it looks like it will get the GPL finally tested in court. If you wanted to take the GPL to court, you couldn't ask for a better case than this one: IBM not only has money and lawyers on its side, it's also got the facts and the law on its side. IBM will win this, and the GPL will have been shown in court to be valid.
The reason the GPL has never been tested in court is because so far, everyone the FSF's lawyers have contacted about GPL violations has preferred to sort things out without a lawsuit. The FSF says this is because no one has been stupid enough yet to try to get the GPL held invalid; well, we finally have someone, SCO, giving it a go in court.
SCO's lawsuit against IBM will fail. SCO won't get any money from IBM, and may need to pay IBM for legal expenses. Meanwhile, IBM's counter-suit will probably succeed. Double whammy for SCO, and a clear precedent for anyone else considering suing about Linux: don't try it, it's not worth it.
Cute, quoting the dictionary. I'll counter by quoting the words I actually wrote. Here you go:
IBM has offered the full source code to 232 releases of OS versions (AIX and Dynix, put together). IBM doesn't get to vet anything; just hand over the source.
So, which files? All of them for each of 232 releases, which are all the official releases during the disputed time period.
IBM doesn't choose which source files; they give all source files for each release. IBM doesn't exactly choose which releases either; they give all of ones actually shipped as official releases, and none of the daily builds or whatever.
It looks like a big court-ordered phase of "looking for more proof".
That's because the case is in its "discovery" phase, where both sides introduce all the evidence they are going to introduce. The judge has ordered both sides to produce evidence.
SCO told the judge they couldn't provide a list of all the allegedly offending lines of code in Linux unless they first got a bunch of stuff from IBM. In fact they asked for every release ever of AIX and Dynix, literally billions of lines of code. Instead, they are getting the source to 232 released versions of those OSes from the disputed time period, only a million lines of code, and they aren't getting them until after they provide the list of all the allegedly offending lines of code in Linux.
It is not possible to spin this as a victory of any sort for SCO. IBM got everything they asked for, and SCO got only a small part of what they asked for.
The judge has just let IBM control what code SCO gets to see. IBM would not offer to hand over 232 files containing their code without having fully vetted it first.
No.
IBM has offered the full source code to 232 releases of OS versions (AIX and Dynix, put together). IBM doesn't get to vet anything; just hand over the source.
SCO demanded a copy of all the sources for every version that ever existed. If some guy made daily builds for a year, that's a few hundred releases from that guy alone; 8000 people worked on these OSes for years, so SCO was literally asking for billions of lines of code. IBM offered a million or so from the 232 releases. The judge saw things IBM's way.
IBM has been doing IP for decades. They know what you can do and what you can't, and they were careful when they released source code for Linux. Thus they don't need to vet anything anyway; they know SCO won't find anything, since there isn't anything there for SCO to find.
The price issue wasn't a killer, either, because the eBook was in the $800 range, and shrinking the package down to Palm (or even Psion) size would have halved the price
But an $800 price point was (and still is, I'd say) too high for a PDA. And that was the eBook, not even the Newton proper. The Palm, at introduction, was $300; at that price it sold like hotcakes.
If Apple had shrunk the Newton down and cut the price a lot it indeed might have made a better PDA, but that never happened.
The Palm was not a step forward, and the fact that even today that it relies on glyphic shorthand alphabets rather than true handwriting recognition, even though it has access to more horsepower than even the Newton 2100, is telling.
I must respectfully disagree. The Palm was a huge hit with customers, because it provided exactly what people wanted in a PDA. The Newton didn't. I would say the Palm was a step forward, because it was the first time anyone made a PDA that was exactly what people wanted. Even today, Palm's biggest competitor is their own installed base. People are basically happy with their Palm PDAs and see little reason to pay money for a newer one.
The shorthand alphabet made the Palm viable on an 8 MHz 68000-family CPU. It isn't hard to learn, and if you do it correctly the recognition accuracy is close to 100%. Modern Palms continue to use it under the "if it ain't broke, don't fix it" theory, as well as the "customers don't like it when you change an established product too much" theory. Note that you can buy different recognition systems for Palm, if you like.
From what I have heard, the Newton's handwriting recognition did improve a whole lot, but the damage had already been done to its reputation. In any event, I only listed that as one of the factors that made it fail as a PDA.
Note that I am not dissing the Newton; I am merely observing that it wasn't what most people wanted in a PDA. And I certainly am not dissing the Newton community.
Not just one deficiency. In addition to size, there was the wonky handwriting recognition, and the price.
You can roll it up into one meta-deficiency: the Newton didn't make a good PDA. From comments I'm reading here, it makes a heck of a compact mini-laptop. But that's not how it was sold.
The reason the Palm took off big-time is that the Palm made a great PDA. The size was perfect, the handwriting recognition was solid, and the price was reasonable ($300 at introduction). The Palm doesn't work as well as the Newton as a mini-laptop, though, so if that's what you want, don't get a Palm.
I've always been annoyed that Steve Jobs killed the Newton outright, when there was a loyal core user base that wanted Newton to not die. A group of Newton developers got together and made a serious bid to license the Newton from Apple, and Jobs refused. I don't know if he expected to introduce an Apple PDA, and wanted Newton dead so it couldn't compete; or if he just didn't like the Newton since it wasn't ever his baby.
The good news is that in the near future, you should be able to put together a Newton-like package: take one of the new small computers with a touch-screen (like the Oqo, which may actually ship someday) and run a GNOME system on a Linux kernel. Now run GNOME Storage. (I haven't used a Newton, so I don't really know how the "data soup" system works; if I'm wrong and GNOME Storage isn't Newton-like, perhaps there is some other free software project that will be Newton-like.)
Once there is free software that is Newton-like, you can have your Newton happiness and no one can take it away from you.
Patents are themselves neither offensive nor defensive. But they can be used defensively.
Suppose company A gets a patent on writing to hard disks. Company B gets a patent on accepting keyboard input. Company B sues company A: "you accept keyboard input! Pay up!" Company A can then defensively say "Oh yeah? Well you write to hard disks. Leave us alone and we'll call it even."
If company A never did anything else with that patent, I'd be willing to call it a "defensive patent".
Of course, all it would take is a change of management for the patent to be turned into a profit center, and used offensively. Or imagine this: suppose upstart company C comes along and starts taking business away from companies A and B. As an upstart company, it has no patents yet, so it has nothing to cross-license with companies A and B for their patents. If basic software concepts are locked up in patents, then the only way to successfully introduce a new software product would be to get a large company (that already has lots of patents) to shield you. This sucks.
Note that IBM has a huge patent portfolio, and they went through it and found four patents with which to hammer the SCO Group. I'm eager to see the SCO Group lose their IBM lawsuit... but I'm nervous about what IBM could do if they ever, as a company, go nuts and start trying to abuse their patents.
I wonder what he was thinking -- why he didn't get Nehemiah core motherboards. For that matter, I wonder why he used microdrives instead of just getting extra RAM and having the motherboards do net boots?
steveha
Re:Floating point performance
on
Mini-ITX Clustering
·
· Score: 2, Informative
he said the cluster has more processing power than a four-P4 SMP system
Whoops, I made a mistake. He actually said his 12-node VIA cluster has more power than "four 2.4 GHz pentium 4 mcahines used in parallel". Not SMP!
Sorry about the mistake.
steveha
Re:Floating point performance
on
Mini-ITX Clustering
·
· Score: 5, Interesting
the floating point performance [...] of VIA CPUs is just abyssmal.
Older C3 cores run the FPU at half the clock rate. If you get the fanless 600 MHz EPIA motherboard, the FPU will be running at 300 MHz.
The newer, Nehemiah core C3 chips run the FPU at full clock speed. Any C3 newer than Nehemiah should run the FPU at full speed.
He used the VIA EPIA V8000A motherboard with an Eden core CPU. From what I found on google (here), the Eden core does run the FPU at full clock speed.
In any event, he said the cluster has more processing power than a four-P4 SMP system, while taking less electricity to run. And it will be quieter and more reliable. I'd like to see actual benchmarks, but it seems like it makes enough sense.
I read about a cluster of PocketPCs, and that didn't make practical sense. It was just a fun project.
And for those of us who need things Linux provides, but don't need PhotoShop, Linux and GIMP are the right tools.
I wouldn't dream of telling a professional graphic designer to use Linux; the pros need PhotoShop. But if you just want to make a few digital photos look a bit better, or make some simple graphics for a web page, the GIMP is all you need. And it runs on Linux.
Well, I think the overhead of a translation layer may be more significant than you say. But I will freely admit to guessing.
I'm guessing, too. But I'm partly going from the fact that the fastest PowerPC chips don't dramatically outperform the fastest x86 chips. I keep hearing how horrible x86 is, yet x86 chips seem to be holding their own.
The thing is, Intel may have the fastest chips, but they aren't fastest by much.
I was specific: I said "fastest clock speed". Intel unquestionably has the fastest clock speed. It's just that they don't manage to turn all that clock speed into raw performance; much slower-clocked chips from AMD perform similarly.
If I understand you correctly, you are saying that a good RISC design would totally beat the x86 if equal resources were applied to the design of the chip. All I know is that, in the real world, x86 chips such as the Opteron perform extremely well, and even the latest PowerPC chips are not dramatically better. (The benchmarks I have seen show G5 and Opteron in the same ballpark on performance, each better in some areas.)
If x86 is so horrible, why doesn't PowerPC totally crush the x86?
P.S. The Alpha sure sounds wonderful. Why doesn't someone make an Alpha-like RISC chip and crush the x86? If all you say is true, this should be a no-brainer.
The extra translation stage leads to longer pipeline delays
Denser instructions fit better in cache, increasing cache hits. Longer translation pipelines are bad when branches aren't predicted correctly. CISC instructions thus are both a win and a loss. Is this a net loss? How bad a net loss? I don't know where to find the numbers on this.
This branch prediction logic adds considerably to the complexity of the chip (hence size and cost)
AMD and Intel would add branch prediction logic in any case. And Intel has chosen to go for insane long pipelines so they really need the branch prediction.
Intel is seeing the end of the road for the x86 architecture and wants to start down a new path with the IA64 architecture.
The fact that no one but Intel can make IA64 chips is a pure coincidence, huh?
Meanwhile AMD is showing that there is still life left in the x86 family, so there is no need to embrace a chip that Intel owns completely.
And meanwhile Linux is growing more popular. If you want to walk away from x86, you need a portable OS with portable apps. Windows won't do. If anything can break the x86 stranglehold, it will be Linux, not any new chip from Intel.
I don't see why it would. Not sure what you are worried about here. (I hope you aren't worried that I will be unpleasant; I try not to be.)
Modern CPUs from AMD and Intel do this kind of translation, but they're the only ones that do it as far as I know.
How many companies make x86 chips anyway? They are the big two. And Transmeta does their own weird thing. The only other chip I can think of is the Via C3 family, which as I understand it is sort of a 486 on steroids... in other words, it doesn't do the decoding to micro-ops thing.
Meanwhile, on the PowerPC side, they do the micro-ops thing too (but they call them "iops").
If this translation layer isn't holding them back, why does Intel need such an enormous R&D budget to produce chips that, while fast, are not so great when it comes to performance/power?
I said the pain of a wacky instruction set is isolated to the translation layer, and the wacky instruction set doesn't hold back the rest of the chip. I never said there is no pain in a wacky instruction set, or that designing the fastest CPU chips in the world is easy.
As for performance/power, Intel made a deliberate decision to make the fastest clock speeds they could, and that's what they did. AMD focused on performance per clock cycle and wound up with better performance/power (not surprising). I would guess that Intel figured they can keep their power dissipation from getting too insane with die shrinks.
As for why Intel spends so much to design their chips, don't ask me. They would probably be spending a lot even if they were making PowerPC-family chips instead of Pentium 4 chips.
P.S. Intel may not care about performance/power, but I do. I want a CPU that won't dissipate too much heat, because I want a quiet computer. I'm eagerly looking forward to 90 nanometer SOI Athlon64 chips.
It's not so much that AMD is "still following in Intel's footsteps", it's that AMD chose to remain x86-compatible. If that's following in Intel's footsteps, then Intel is following in Intel's footsteps too, I guess, because Intel sells lots of x86-compatible chips.
The continuation of adding on register extensions is great for backwards compatiblity but it makes the instruction set a mess.
But -- who cares? Modern CPU chips translate instructions into RISC-like micro-ops, and feed the micro-ops into multiple execution units. AMD chips can do a whole bunch of stuff in a single clock cycle, which is why they are much faster per clock cycle than an Intel chip. The pain of a wacky instruction set is isolated in the translation part of the chip, and doesn't significantly hold back the chip in other ways.
RISC fans predicted years ago that CISC would die, because RISC is so much better. But CISC chips contain RISC cores these days, and meanwhile architectures that were originally "RISC" have all kinds of special instructions for working with video data and such (doesn't seem so "reduced" to me). What really happened is that RISC and CISC kind of met in the middle.
And the old idea that RISC instructions would win because they are easier to decode didn't pan out. CISC instructions get decoded to RISC-like micro-ops, as I said, and it turns out not to be a huge deal. Meanwhile, those CISC instructions are denser than RISC instructions, so you fit more of them into your limited cache space, which helps speed.
In short, modern chips do all kinds of clever stuff, and the instruction set architecture is not really holding them back.
The sad thing is that a new cpu could have a compatibility layer that had a slight performance hit but with a lack of software supporting new 64 implementations people wouldn't buy it because the pretty little bar graphs that the sales drones produce.
If you want me to feel sad, you need to back this up with some facts. Show me why you feel the Athlon64 would be faster if it were not backward-compatible with x86.
As it is, the Athlon64 is already a sweet chip in 32-bit x86 mode (you know, "following in Intel's footsteps"). Then it gets better when you run 64-bit software (mainly due to the extra registers). Good in 32-bit, better in 64-bit... why am I supposed to be sad again?
Probably not. I think that comment was a gratuitous bash (the news is about wines, not about movies), but I think it's clear that the poster wanted to make a joke.
I was going for "funny" moderation, not "insightful", actually.
P.S. Like you, I wish that the original, unmodified movies were available on DVD. Just wait; someday they will release a new mega-deluxe box set with the new versions, the original versions, three making-of disks, and a mynock in a pear tree. If they have learned anything from watching the Lord of the Rings box sets, they will go through at least three or four box sets along the way. Plenty of Star Wars fans will buy each box set as it comes out!
Heck, there are fans out there who would buy a DVD of the Star Wars Christmas special if that ever came out! [...shudder...]
I was intrigued by the news of Parrot, the interpreter core. It's a virtual machine, register-based rather than primarily stack-based as some other virtual machine cores have been. This is to take advantage of compiler technology.
Long-term, Parrot hopes to be at the core of not just Perl 6, but also Python, FORTH, and what-have-you. Then applications could support Parrot, and users could script the applications in their favorite language. Python users could call into Perl CPAN code. That sort of fun thing.
The Parrot FAQ is worth reading. There are some really entertaining sections. One of my favorites:
Why should I program in Parrot Assembly language? [...] You get all the pleasure of programming in assembly language without any of the requisite system crashes.
Another:
What language is Parrot written in?
C.
For the love of God, man, why?!?!?!?
Because it's the best we've got.
That's sad.
So true. Regardless, C's available pretty much everywhere.
So, my next question was: if they want to become the core of languages like Python, what does Guido van Rossum (the architect of Python) have to say about that? A few google searches later, and I found an interview at linuxfr.org, which contained this:
DLFP: What do you think of the Parrot project (http://www.parrotcode.org/), which aim is to develop a common virtual machine for interpreted languages, such as Perl 6, Python, Ruby and Tcl ? [Jean-michel Fayard]
Guido: I wish them well, but I don't think they will succeed. They are vastly underestimating the effort that goes into a virtual machine for any specific programming language. Even languages as similar as Ruby and Python have fundamentally different runtime abstractions, and the difference between Python and Perl is much greater still. (For example, the concepts of strings and numbers are entirely different in these two languages: in Python, numbers and strings are different immutable types, while in Perl they are the same type and are mutable.) I expect Parrot will do a great job of running Perl 6, but a relatively poor job of running other languages. Of course, I'd be happy if I were wrong (except for the brief moment of receiving a pie in the face at OSCON 2004), but I don't expect that to happen.
People complain about FSF, RMS, debian-legal and so on all being nit-picky about fine points of licensing.
The correct attitude about this is: I'm so glad those guys are nit-picky so I don't have to be!
We can grab a Linux kernel, and a whole bunch of cool software. We can use them, give copies to our friends, modify them... and we don't need to worry about IP issues, because other people are doing the worrying for us.
There was a project, GNOME Basic, which was going to try to create a VB-compatible language. The project has been abandoned, though. Instead, the Mono system has a VB-compatible component:
IBM could spend a bunch of money helping to get OO.o to run Mono Basic in an Office-compatible way. That would be a longer-term strategy, though. Customers would be happier to have 100% Office compatability right away.
Slashdot Mirror
There is no search capability in GPDF.
True. They will add it in future.
Is this feature too obstrucive? Or is it just because the coders can't make a good pdf searcher?
I suspect it's harder than you think. Just look at gpdf; they did a great job on it. Why leap to the assumption they are poor coders?
Once they have this feature added, I'll cheerfully remove xpdf from my system. I really like gpdf.
steveha
Anyone who wants to see which scene he is talking about, click here:
http://www.khaaan.com
steveha
I'm not a legal expert, but I've been following the case. It appears that the judge is giving SCO every chance to make their case. The judge could slap SCO down and dismiss the suit today, but SCO would appeal. If the judge gives SCO every chance now to get their act together, then when the case is settled, SCO will probably not successfully appeal it.
IBM, meanwhile, is all in favor of SCO getting every chance to make their case. IBM knows that SCO doesn't have a case, IBM's lawyers are on salary instead of hourly billing, and IBM wants a clear and decisive victory over SCO, not a case thrown out on a technicality.
This lawsuit is very annoying, but it looks like it will get the GPL finally tested in court. If you wanted to take the GPL to court, you couldn't ask for a better case than this one: IBM not only has money and lawyers on its side, it's also got the facts and the law on its side. IBM will win this, and the GPL will have been shown in court to be valid.
The reason the GPL has never been tested in court is because so far, everyone the FSF's lawyers have contacted about GPL violations has preferred to sort things out without a lawsuit. The FSF says this is because no one has been stupid enough yet to try to get the GPL held invalid; well, we finally have someone, SCO, giving it a go in court.
SCO's lawsuit against IBM will fail. SCO won't get any money from IBM, and may need to pay IBM for legal expenses. Meanwhile, IBM's counter-suit will probably succeed. Double whammy for SCO, and a clear precedent for anyone else considering suing about Linux: don't try it, it's not worth it.
steveha
So, which files? All of them for each of 232 releases, which are all the official releases during the disputed time period.
IBM doesn't choose which source files; they give all source files for each release. IBM doesn't exactly choose which releases either; they give all of ones actually shipped as official releases, and none of the daily builds or whatever.
Are we clear now?
steveha
This doesn't look like a SCO loss at all.
No, it is. It really is.
It looks like a big court-ordered phase of "looking for more proof".
That's because the case is in its "discovery" phase, where both sides introduce all the evidence they are going to introduce. The judge has ordered both sides to produce evidence.
SCO told the judge they couldn't provide a list of all the allegedly offending lines of code in Linux unless they first got a bunch of stuff from IBM. In fact they asked for every release ever of AIX and Dynix, literally billions of lines of code. Instead, they are getting the source to 232 released versions of those OSes from the disputed time period, only a million lines of code, and they aren't getting them until after they provide the list of all the allegedly offending lines of code in Linux.
It is not possible to spin this as a victory of any sort for SCO. IBM got everything they asked for, and SCO got only a small part of what they asked for.
steveha
The judge has just let IBM control what code SCO gets to see. IBM would not offer to hand over 232 files containing their code without having fully vetted it first.
No.
IBM has offered the full source code to 232 releases of OS versions (AIX and Dynix, put together). IBM doesn't get to vet anything; just hand over the source.
SCO demanded a copy of all the sources for every version that ever existed. If some guy made daily builds for a year, that's a few hundred releases from that guy alone; 8000 people worked on these OSes for years, so SCO was literally asking for billions of lines of code. IBM offered a million or so from the 232 releases. The judge saw things IBM's way.
IBM has been doing IP for decades. They know what you can do and what you can't, and they were careful when they released source code for Linux. Thus they don't need to vet anything anyway; they know SCO won't find anything, since there isn't anything there for SCO to find.
steveha
The price issue wasn't a killer, either, because the eBook was in the $800 range, and shrinking the package down to Palm (or even Psion) size would have halved the price
But an $800 price point was (and still is, I'd say) too high for a PDA. And that was the eBook, not even the Newton proper. The Palm, at introduction, was $300; at that price it sold like hotcakes.
If Apple had shrunk the Newton down and cut the price a lot it indeed might have made a better PDA, but that never happened.
The Palm was not a step forward, and the fact that even today that it relies on glyphic shorthand alphabets rather than true handwriting recognition, even though it has access to more horsepower than even the Newton 2100, is telling.
I must respectfully disagree. The Palm was a huge hit with customers, because it provided exactly what people wanted in a PDA. The Newton didn't. I would say the Palm was a step forward, because it was the first time anyone made a PDA that was exactly what people wanted. Even today, Palm's biggest competitor is their own installed base. People are basically happy with their Palm PDAs and see little reason to pay money for a newer one.
The shorthand alphabet made the Palm viable on an 8 MHz 68000-family CPU. It isn't hard to learn, and if you do it correctly the recognition accuracy is close to 100%. Modern Palms continue to use it under the "if it ain't broke, don't fix it" theory, as well as the "customers don't like it when you change an established product too much" theory. Note that you can buy different recognition systems for Palm, if you like.
From what I have heard, the Newton's handwriting recognition did improve a whole lot, but the damage had already been done to its reputation. In any event, I only listed that as one of the factors that made it fail as a PDA.
Note that I am not dissing the Newton; I am merely observing that it wasn't what most people wanted in a PDA. And I certainly am not dissing the Newton community.
steveha
Not just one deficiency. In addition to size, there was the wonky handwriting recognition, and the price.
You can roll it up into one meta-deficiency: the Newton didn't make a good PDA. From comments I'm reading here, it makes a heck of a compact mini-laptop. But that's not how it was sold.
The reason the Palm took off big-time is that the Palm made a great PDA. The size was perfect, the handwriting recognition was solid, and the price was reasonable ($300 at introduction). The Palm doesn't work as well as the Newton as a mini-laptop, though, so if that's what you want, don't get a Palm.
I've always been annoyed that Steve Jobs killed the Newton outright, when there was a loyal core user base that wanted Newton to not die. A group of Newton developers got together and made a serious bid to license the Newton from Apple, and Jobs refused. I don't know if he expected to introduce an Apple PDA, and wanted Newton dead so it couldn't compete; or if he just didn't like the Newton since it wasn't ever his baby.
The good news is that in the near future, you should be able to put together a Newton-like package: take one of the new small computers with a touch-screen (like the Oqo, which may actually ship someday) and run a GNOME system on a Linux kernel. Now run GNOME Storage. (I haven't used a Newton, so I don't really know how the "data soup" system works; if I'm wrong and GNOME Storage isn't Newton-like, perhaps there is some other free software project that will be Newton-like.)
Once there is free software that is Newton-like, you can have your Newton happiness and no one can take it away from you.
steveha
There is no such thing as a "defensive patent"
Patents are themselves neither offensive nor defensive. But they can be used defensively.
Suppose company A gets a patent on writing to hard disks. Company B gets a patent on accepting keyboard input. Company B sues company A: "you accept keyboard input! Pay up!" Company A can then defensively say "Oh yeah? Well you write to hard disks. Leave us alone and we'll call it even."
If company A never did anything else with that patent, I'd be willing to call it a "defensive patent".
Of course, all it would take is a change of management for the patent to be turned into a profit center, and used offensively. Or imagine this: suppose upstart company C comes along and starts taking business away from companies A and B. As an upstart company, it has no patents yet, so it has nothing to cross-license with companies A and B for their patents. If basic software concepts are locked up in patents, then the only way to successfully introduce a new software product would be to get a large company (that already has lots of patents) to shield you. This sucks.
Note that IBM has a huge patent portfolio, and they went through it and found four patents with which to hammer the SCO Group. I'm eager to see the SCO Group lose their IBM lawsuit... but I'm nervous about what IBM could do if they ever, as a company, go nuts and start trying to abuse their patents.
steveha
Thank you for the corrections.
I wonder what he was thinking -- why he didn't get Nehemiah core motherboards. For that matter, I wonder why he used microdrives instead of just getting extra RAM and having the motherboards do net boots?
steveha
he said the cluster has more processing power than a four-P4 SMP system
Whoops, I made a mistake. He actually said his 12-node VIA cluster has more power than "four 2.4 GHz pentium 4 mcahines used in parallel". Not SMP!
Sorry about the mistake.
steveha
the floating point performance [...] of VIA CPUs is just abyssmal.
Older C3 cores run the FPU at half the clock rate. If you get the fanless 600 MHz EPIA motherboard, the FPU will be running at 300 MHz.
The newer, Nehemiah core C3 chips run the FPU at full clock speed. Any C3 newer than Nehemiah should run the FPU at full speed.
He used the VIA EPIA V8000A motherboard with an Eden core CPU. From what I found on google (here), the Eden core does run the FPU at full clock speed.
In any event, he said the cluster has more processing power than a four-P4 SMP system, while taking less electricity to run. And it will be quieter and more reliable. I'd like to see actual benchmarks, but it seems like it makes enough sense.
I read about a cluster of PocketPCs, and that didn't make practical sense. It was just a fun project.
steveha
Do give GIMP 2.0 a try; I rather like it. It's easier to find things you want.
steveha
And for those of us who need things Linux provides, but don't need PhotoShop, Linux and GIMP are the right tools.
I wouldn't dream of telling a professional graphic designer to use Linux; the pros need PhotoShop. But if you just want to make a few digital photos look a bit better, or make some simple graphics for a web page, the GIMP is all you need. And it runs on Linux.
steveha
Well, I think the overhead of a translation layer may be more significant than you say. But I will freely admit to guessing.
I'm guessing, too. But I'm partly going from the fact that the fastest PowerPC chips don't dramatically outperform the fastest x86 chips. I keep hearing how horrible x86 is, yet x86 chips seem to be holding their own.
The thing is, Intel may have the fastest chips, but they aren't fastest by much.
I was specific: I said "fastest clock speed". Intel unquestionably has the fastest clock speed. It's just that they don't manage to turn all that clock speed into raw performance; much slower-clocked chips from AMD perform similarly.
steveha
If I understand you correctly, you are saying that a good RISC design would totally beat the x86 if equal resources were applied to the design of the chip. All I know is that, in the real world, x86 chips such as the Opteron perform extremely well, and even the latest PowerPC chips are not dramatically better. (The benchmarks I have seen show G5 and Opteron in the same ballpark on performance, each better in some areas.)
If x86 is so horrible, why doesn't PowerPC totally crush the x86?
P.S. The Alpha sure sounds wonderful. Why doesn't someone make an Alpha-like RISC chip and crush the x86? If all you say is true, this should be a no-brainer.
steveha
The extra translation stage leads to longer pipeline delays
Denser instructions fit better in cache, increasing cache hits. Longer translation pipelines are bad when branches aren't predicted correctly. CISC instructions thus are both a win and a loss. Is this a net loss? How bad a net loss? I don't know where to find the numbers on this.
This branch prediction logic adds considerably to the complexity of the chip (hence size and cost)
AMD and Intel would add branch prediction logic in any case. And Intel has chosen to go for insane long pipelines so they really need the branch prediction.
Intel is seeing the end of the road for the x86 architecture and wants to start down a new path with the IA64 architecture.
The fact that no one but Intel can make IA64 chips is a pure coincidence, huh?
Meanwhile AMD is showing that there is still life left in the x86 family, so there is no need to embrace a chip that Intel owns completely.
And meanwhile Linux is growing more popular. If you want to walk away from x86, you need a portable OS with portable apps. Windows won't do. If anything can break the x86 stranglehold, it will be Linux, not any new chip from Intel.
steveha
I hope this doesn't start anything unpleasant
I don't see why it would. Not sure what you are worried about here. (I hope you aren't worried that I will be unpleasant; I try not to be.)
Modern CPUs from AMD and Intel do this kind of translation, but they're the only ones that do it as far as I know.
How many companies make x86 chips anyway? They are the big two. And Transmeta does their own weird thing. The only other chip I can think of is the Via C3 family, which as I understand it is sort of a 486 on steroids... in other words, it doesn't do the decoding to micro-ops thing.
Meanwhile, on the PowerPC side, they do the micro-ops thing too (but they call them "iops").
If this translation layer isn't holding them back, why does Intel need such an enormous R&D budget to produce chips that, while fast, are not so great when it comes to performance/power?
I said the pain of a wacky instruction set is isolated to the translation layer, and the wacky instruction set doesn't hold back the rest of the chip. I never said there is no pain in a wacky instruction set, or that designing the fastest CPU chips in the world is easy.
As for performance/power, Intel made a deliberate decision to make the fastest clock speeds they could, and that's what they did. AMD focused on performance per clock cycle and wound up with better performance/power (not surprising). I would guess that Intel figured they can keep their power dissipation from getting too insane with die shrinks.
As for why Intel spends so much to design their chips, don't ask me. They would probably be spending a lot even if they were making PowerPC-family chips instead of Pentium 4 chips.
P.S. Intel may not care about performance/power, but I do. I want a CPU that won't dissipate too much heat, because I want a quiet computer. I'm eagerly looking forward to 90 nanometer SOI Athlon64 chips.
steveha
It's not so much that AMD is "still following in Intel's footsteps", it's that AMD chose to remain x86-compatible. If that's following in Intel's footsteps, then Intel is following in Intel's footsteps too, I guess, because Intel sells lots of x86-compatible chips.
The continuation of adding on register extensions is great for backwards compatiblity but it makes the instruction set a mess.
But -- who cares? Modern CPU chips translate instructions into RISC-like micro-ops, and feed the micro-ops into multiple execution units. AMD chips can do a whole bunch of stuff in a single clock cycle, which is why they are much faster per clock cycle than an Intel chip. The pain of a wacky instruction set is isolated in the translation part of the chip, and doesn't significantly hold back the chip in other ways.
RISC fans predicted years ago that CISC would die, because RISC is so much better. But CISC chips contain RISC cores these days, and meanwhile architectures that were originally "RISC" have all kinds of special instructions for working with video data and such (doesn't seem so "reduced" to me). What really happened is that RISC and CISC kind of met in the middle.
And the old idea that RISC instructions would win because they are easier to decode didn't pan out. CISC instructions get decoded to RISC-like micro-ops, as I said, and it turns out not to be a huge deal. Meanwhile, those CISC instructions are denser than RISC instructions, so you fit more of them into your limited cache space, which helps speed.
In short, modern chips do all kinds of clever stuff, and the instruction set architecture is not really holding them back.
The sad thing is that a new cpu could have a compatibility layer that had a slight performance hit but with a lack of software supporting new 64 implementations people wouldn't buy it because the pretty little bar graphs that the sales drones produce.
If you want me to feel sad, you need to back this up with some facts. Show me why you feel the Athlon64 would be faster if it were not backward-compatible with x86.
As it is, the Athlon64 is already a sweet chip in 32-bit x86 mode (you know, "following in Intel's footsteps"). Then it gets better when you run 64-bit software (mainly due to the extra registers). Good in 32-bit, better in 64-bit... why am I supposed to be sad again?
steveha
I think you take the poster too literally.
Probably not. I think that comment was a gratuitous bash (the news is about wines, not about movies), but I think it's clear that the poster wanted to make a joke.
I was going for "funny" moderation, not "insightful", actually.
P.S. Like you, I wish that the original, unmodified movies were available on DVD. Just wait; someday they will release a new mega-deluxe box set with the new versions, the original versions, three making-of disks, and a mynock in a pear tree. If they have learned anything from watching the Lord of the Rings box sets, they will go through at least three or four box sets along the way. Plenty of Star Wars fans will buy each box set as it comes out!
Heck, there are fans out there who would buy a DVD of the Star Wars Christmas special if that ever came out! [...shudder...]
steveha
Wonder if there's any spots on that ranch left that can make a good Star Wars movie?
Meee-ow!
By the way, I didn't think the ranch made the movies. That comment is stranger the more I think about it.
steveha
Long-term, Parrot hopes to be at the core of not just Perl 6, but also Python, FORTH, and what-have-you. Then applications could support Parrot, and users could script the applications in their favorite language. Python users could call into Perl CPAN code. That sort of fun thing.
Parrot's home page is: http://www.parrotcode.org/
The Parrot FAQ is worth reading. There are some really entertaining sections. One of my favorites:
Another:
So, my next question was: if they want to become the core of languages like Python, what does Guido van Rossum (the architect of Python) have to say about that? A few google searches later, and I found an interview at linuxfr.org, which contained this:
steveha
But... my Mom doesn't have a basement. And it would be take a while to dig one. Would it be okay if I just hang out in her garage or something?
"...and play games." What a great idea! I think I'll play some games now. Thanks!
P.S. Go back and read what I wrote. I know licensing is important; that's why I am grateful that other people worry about it so I don't have to.
steveha
People complain about FSF, RMS, debian-legal and so on all being nit-picky about fine points of licensing.
The correct attitude about this is: I'm so glad those guys are nit-picky so I don't have to be!
We can grab a Linux kernel, and a whole bunch of cool software. We can use them, give copies to our friends, modify them... and we don't need to worry about IP issues, because other people are doing the worrying for us.
Be grateful.
steveha
There was a project, GNOME Basic, which was going to try to create a VB-compatible language. The project has been abandoned, though. Instead, the Mono system has a VB-compatible component:
http://www.go-mono.com/mbas.html
IBM could spend a bunch of money helping to get OO.o to run Mono Basic in an Office-compatible way. That would be a longer-term strategy, though. Customers would be happier to have 100% Office compatability right away.
steveha