If you don't mind me asking, which denomination of (presumably Christian) faith do you practice?
As a Catholic, the Sacrement of Reconciliation is central to my beliefs. To fully receive the Sacrement, the confessor must seek the help of a priest and make the confession to that other person. I believe this is a uniquely Catholic view, but someone correct me if I'm wrong. The idea is that you're confessing to the priest, who acts as a mediator for Christ. The confessor is not confessing to flesh and blood. He or she is confessing to the human-divine Christ.
The idea of an on-line confessional brings up some interesting questions. How can the confessor be sure the other end is being viewed by an ordained priest? If the confession really does stay on the user's computer and no one sees it, then it is not a valid confession according to Catholic doctrine. How can the privacy of the confessional be maintained over a public medium (think of all those courtroom dramas you've watched over the years)?
Before anyone sends e-mail to the Copyright Office, please visit the link at the top of the story. There are restrictions on the format of submissions. Namely, they must by MIME attachments of PDF, Word 7 (or earlier) or WordPerfect 7 (or earlier) files. A text e-mail may not be enough.
This still doesn't solve the problem of third-party vendors. Shipping multiple binaries for different classes of CPU core is not economical. There are just too many variables. The support costs are nightmarish. Code morphing can alleviate this.
And to beat a dead horse, the code morpher also optimizes. This is extremely important to the performance of Crusoe. It can actually run programs faster than if they were compiled natively, due to the run-time information available to the optimizer.
No, a static compiler will never produce optimal code. It can't for several resons:
Separate compilation. Without being able to look at the whole program at once (including BTW, system libraries and kernel code), the compiler can't fully know the aliasing conditions present in the program. It can make some guesses, but a function call to an external module will pretty much kill the optimizer (though you can do things with locals and such).
Lack of context. A static compiler has no idea what will happen at run-time. Can the compiler elimiate a load after a store? Not if the store potentially writes to the same address from which the load reads. But there may be times when the load is not dependent on the store. Theoretically, the code morpher can take advantage of this. With profiling, a static compiler can gain some run-time context. But you're relying on the assumption that the profile runs are representative of the way the program will be used for all time. And then you get into that hazy, ugly area known as dynamic memory allocation...
ISA limitations. The compiler is restricted to the idioms provided by the machine's ISA. On the x86, performance is absolutely killed by the lack of general-purpose registers and the non-orthogonality of the instruction set. With the code morpher, Transmeta could theoretically release a "clean" ISA that is a nice compiler target. And improve it as the experience builds up.
Moderators, knock this one up! Great explanation of JIT vs. Dynamic Compilation/Specialization!
Note that there is no reason Crusoe couldn't support a staging compiler. Transmeta could always release a virtual ISA that had support for doing this efficiently. And of course you could always write a dynamic compiler in x86 (ugh). The point is that Transmeta could directly provide support for something akin to DyC in a later processor. And still maintain both backward and forward compatibility.
No, it's not a closed source problem. It might be a binaries problem. I don't know about you, but I wouldn't want to statically compile an ActiveX object every time I view a web page.
The translation software provides backward compatibility, yes, but it also provides flexibility for Transmeta.
What if Transmeta desigs the TM-ISA? It's a virtual machine designed to translate efficiently to the bare hardware. Now compilers can take advantage of the additional registers provided by TM-ISA. If a new core provides more physical registers, TM-ISA v.2 can be released, allowing the use of more registers by the compiler.
That's all well and good, but we get the additional benefit that old programs run on the new hardware just fine, and there's no additional hardware cruft to maintain compatibility.
Ok, that's pretty cool. Backward compatibility is important. But what's really neat is that Crusoe provides forward compatibility. Code written to TM-ISA v.2 will run just fine on processors released with TM-ISA v.1 as long as new firmware is loaded that can understand TM-ISA v.2. So now software houses can release code optimized for the latest and greatest without worrying about users behind the curve not being able to run their stuff.
How often do people moan about RedHat not providing Pentium-optimized packages? With Crusoe, RedHat can silence the critics without impacting us 486 users.
You're ignoring the fact that the translator also optimizes. If you look at this post, you'll see that the code morpher does some neat tricks to get around the aliasing problem. This is something a static compiler can't easily do. Sure, with profiling and re-compilation it might make some intelligent guesses, but isn't it simpler to let the translation software do it for you?
What Transmaeta has essentially done is take the Merced core and execute the compiler at run-time. The alias handling structure acts like the ALAT on Merced.
Code executed through the translation layer should perform better than code executing on the bare metal because the translation software is learning and optimizing.
Think of it this way: would you rather manage your stock portfolio as is done today, by guessing what might happen, or would you rather know what the market is going to do and trade your stocks accordingly. I guarantee that I can beat your statically predictive management every time if I have that additional context.
Except that the code morphing software has one very important property: it optimizes the code dynamically. You can't do that by statically compiling to the VLIW layer.
Now I suppose Transmeta could design a full O-O-O core, but I don't see the point. If the software does a good job, the additional flexibility they gain to change the underlying machine is worth it.
As far as branches go, yes, you usually can guess a backward branch is going to be taken. But branches are still a huge problem. It's tough to keep a processor core fed. And don't even get me started on multiple branch prediction. The hit rate goes way down. A study was done here that showed processors today (or in the near future) spend about half the time recovering from branch mispredictions. That's a lot of wasted work. While the code morphing software can't do a perfect job, it is somewhat easier to tune the chip. And then think about per-application tuning. Load a different set of rules depending on the program you're running.
Hey, thanks for the information about the aliasing situation. I didn't realize Crusoe did this.
This is really, really great! Insanely great! Is the code optimizer smart enough to do cross-call optimization? That is, can it get rid of the call overhead?
Obviously I need to go read some documents, but how much code scheduling does it do? What does it do about control and/or data speculation, if anything? With the optimizer, you have the tradeoff between optimizing really aggressively and being able to cache as much generated code as possible. How is this tradeoff made?
Some of us were thinking about the x86 issue today. Obviously, Transmeta chose the x86 because of its market share.
Then it hit us. Crusoe can do well at x86 translation because of the utter lack of registers on the x86. If Crusoe even does just an average job of mapping of memory operations to registers (stack locations come to mind), that in itself could cover a lot of the translation overhead. Especially if the code cache is working well.
PowerPC, Sparc, etc. may not translate as well because their ISA's have more registers. There is not a lot of spill code in those object files. One win that could be had here is getting rid of some of the function call overhead. Saving and restoring registers is nasty stuff.
Didn't Intel license with IBM way back when they started out? Intel basically sold its soul to IBM and others (National Semi, I believe) because they were a no-name in the market. Monopoly concerns had nothing to do with it.
In any event, many licenses include a clause saying something to the effect of, "This agreement may be terminated at any time by either party." Now whether that's been tested in court, I don't know.
I'd guess most OEM's will wait on the sidelines to see what happens. Why put your company's neck on the line if you don't have to?
If you read any of the recent papers about FX!32 and Dynamo, you'll see some interesting results. The code caches can be made to work quite effectively.
The problem with static compiler scheduling is that it doesn't have any run-time context. The translation layer provides this context, in effect allowing a compiler to optimize your code as it runs, which gives the optimizer more exact information. It's like an O-O-O machine, only more powerful since software can generally "see" further ahead than hardware. Because the generated code is re-used, the software translator can take a bit more time to do a good job.
You could get exactly what you want if Transmeta released firmware for running its native instruction set on the CPU. The "code morphing" would simply be a direct issue to the processor core.
However, as pnagel explained so well in another response to your message (Moderators, up the score on that one!), the code morphing does more than translate. It optimizes. A lot. It's very important for performance reasons that this happens. If Transmeta ever releases an O-O-O CPU, then this effect is somewhat less important and a direct issue would perform almost as well.
You could get exactly what you want if Transmeta released firmware for running its native instruction set on the CPU. The "code morphing" would simply be a direct issue to the processor core. However, as pnagel explained so well in another response to your message (Moderators, up the score on that one!), the code morphing does more than translate. It optimizes. A lot. It's very important for performance reasons that this happens. If Transmeta ever releases an O-O-O CPU, then this effect is somewhat less important and a direct issue would perform almost as well.
What you're essentially saying is that the ISA doesn't matter.
Well, it does. I don't know what Crusoe does with memory references, but I can almost guarantee you it can't map all of them to registers. The x86 is severely limited in the register area, and this really, really hurts compiled code. Spill code is a major problem on that architecture, not to mention all of the implicit dependencies between instructions and the general non-orthogonal nature of the instruction set. All of these things contribute to poor code generation on the compiler's part.
Even if it could map everything to registers (it might actually be able to handle most references to the stack), there's still the problem of instruction fetch. Getting instructions into the core is a big, big bottleneck. Having your program expressed in fewer instructions means you save I-Cache and instruction window/reservation station space. It means the hardware can "see" more of the program at once. Now the processors introduced today are not O-O-O, but the I-Cache still matters.
More registers usually means fewer instructions, as the "overhead" memory operations are not necessary. None of Crusoe's code morphing can help (static) instruction count.
What piques my interest in something like Crusoe is that now the compiler can generate its own ISA! This has been done by some researchers before, especially in the area of code compression where a custom ISA is designed to compress well for a particular program.
Think about this for a minute: the developer profiles a program to find some representative behavior. The compiler takes this information and figures out the best code it can generate without ISA restrictions. Need a vector add? Make one up! The compiler must still be aware of hardware issues (number of function units, etc.), but this removes one layer of restriction.
So the compiler generates object code as well as the firmware needed to run it. Linux (or your favorite OS) is modified so that the loader loads the object code into main memory, loads the firmware into flash memory (or wherever it goes) and yells, "Go!"
Can someone tell me if there's a a non-trivial web browser plug-in that's not available for Macs? I can't think of any.
Well, without ActiveX support, you're SOL on a lot of pages (mostly Microsoft pages, maybe, but software updates are important). The fact is that most PC users run Windows, so Windows must be supported. There's nothing preventing PowerPC from being supported as well.
The only CPUs that IBM makes now are PowerPC chips.
Not true. What about the Power line (G5 [S/390], etc.)? I'm sure there are others (embedded chips, etc.), but I can't name them off the top of my head. Picking nits, maybe, but it irked me.:)
So I just finished watching the first half of the presentation with some of the fellows I work with here. We're in the computer architecture group, doing compiler work with a fair amount of hardware support.
It struck me as odd that Ditzel claims Crusoe is the first processor to make use of a software solution. It may be the first designed to do this from the ground up, but the code morphing idea is not really all that new.
The IBM S/390 has the ability to completely recode the instruction set through microcode. The Alpha has PAL code for VAX compataility. FX!32 provide x86 compatability and "learns" about the program through profiling and reoptimization. Dynamo is HP's answer to FX!32, providing similar functionality to PA-RISC and probably IA32. While none of these are quite exactly like Crusoe, it's the same general idea.
Dynamic recompilation research has been going on for a while. Translating JVM's are only the most recent example. In fact Transmeta hired some big names in this area, which of course makes a lot of sense.
We've been kicking around the idea of self-optimizing computers for a while now. The idea being basically what Crusoe does - examine the software running and adjust accordingly. Now if a couple of inexperienced graduate students can come up with this idea after reading a few papers, it can't be all that revolutionary.:)
What I did like was the fact that someone finally publicly (i.e. through marketing) expressed the value of being able to change the underlying native instruction set. The question of whether the native ISA would be exposed was asked. The answer was no. This is a good thing, as it frees the hardware designers from having to carry around a bunch of compatability cruft. It's almost a necessary thing when your core is native VLIW.
I found it humorous that the bigwigs at Transmeta feel that Linus is the guy you want on a project like this. I figured you'd want someone with expertise in computer architecture and compilers. Yeah, I know it was a throwaway line, but we had a bit of a chuckle. I'm sure Linus us doing a great job.:)
As for the power consumption, it's not all that spectacular when you consider that the StrongARM has been sub-Watt for some time now. I'm not sure how many hardware power tricks were pulled with Crusoe, but the power demo was very entertaining. In any event, no one has been able to run x86 at a Watt, so that is certainly worth some praise. I know that Intel is very, very concerned about power (from a friend I have there). This could make them a bit nervous. I'm interested to see if they have anything that can compete.
But my big question concerns the web pad. First of all, that screen is tiny! No wonder it's low power! Aren't the disk and screen the largest consumers of battery power? It doesn't seem like Transmeta does anything about that. Hopefully the unnammed (and apparently unsigned) OEM's can solve that problem.
Even ignoring the screen/disk problem, why is Linux "the obvious choice" for a ROM-based OS in a web pad? If their main goal is a "fully internet compatable" low-power mobile device, it seems as though they've shot themselves in the foot by relying on an OS that has sub-average plugin support at best. They kept touting how the x86 compatability provides full support for plugins, but the OS question was completely ignored. What's the answer? It doesn't seem fully internet compatible to me.
I fired off a message to MP3.com a few days back asking about BeamIt/InstantListen support for Linux. The fellow who wrote back told me that Linux support is in the works and that the engineers at MP3.com (who all use *nix) really want it.
He couldn't give me a timetable, but it is coming.
Well it is, in a sense. Microsoft gave away IE in order to break Netscape's market. Now, IMHO, IE is a better product, so don't go accusing me of zealotry.
RedHat is not providing products at below cost to undercut competitors. Free (in both senses of the word) software has been their business model from day one. They sell support and nice packaging.
The fact is, Microsoft can use the huge profits on Office to shore up losses from IE. This in itself is not a bad thing. Corporations often buy up debt-ridden companies for tax reasons. But when this is done to strangle a competitor, it is illegal. They're using a monopoly in one market (Office) to gain entry into another market (internet browsers).
Well, one thing it would prevent is the hiding of losses in one sector of the market by using the gains in another sector. So distributing lots of software for free (i.e. dumping) becomes more difficult, for example.
The difference with banks is that those numbers are produced by computers. Handwriting is not.
As far as whether it's a "common sense" solution, I'm not so sure. Everything is easy once you've seen it. How many of us look at the internet today (or 10 years ago, or whenever we got involved) and wonder why we didn't see it coming?
If I'm reading this correctly, the patent claims a handwriting recognition scheme that uses (graphically well-separated) characters that can be created with unbroken strokes. Said characters are allowed to have no spatial relation to each other.
It also includes a mechanism for translating the strokes into sequential coordinate lists and converting those lists to codes the machine can understand. There are other bits as well.
It seems to me that this is a valid patent (assuming no prior art) and Xerox has every right to defend it. This is not some silly patent on windowing or one-click shopping. Handwriting recognition is a non-trivial task and frankly, the inventors deserve to profit from their inventions.
That said, I wonder what Mentor Graphics thinks of all this, given their stroke interface to CAD tools. Doesn't it work the same way?
I've been reading the comments here and people have mentioned many sound/music projects for Linux. However, none of these has satisfactory support for input from MIDI devices. Rosegarden has a horrendous interface, Brahms just plain doesn't work and I don't know of any other notation programs for Linux.
What I, as a musician/arranger, want to see is something like Finale. Anyone who's used the "speedy entry" feature knows what I'm talking about. I don't realy need software that can transcribe my playing real-time (though that would be nice), but I do need something that can grab a sample from the MIDI port and stick it on a staff.
Just as important is hardware support. I've got a SoundBlaster 16 with a crappy MIDI port. The thing doesn't work at all. So I went and got a parallel port MIDI interface that works like a charm under Windows. The problem is, there are no Linux drivers. I offered to develop some for the company, but they would not release specs. I can't imagine that this is a difficult driver to write or that the hardware configuration of the interface is so radically innovative that the company (MIDIMan) can't release its top-secret information.
I'd like to see some of these sound applications support MIDI input and some of the hardware companies actually giving a damn about their customers.
Actually, if you look at the recent elections, you'll see all of the candidates moving to the more extreme sides of their respective parites and then you see them move back toward the center. Happens every time.
I thought Bush and McCain did rather well in last night's debate (at least the highlights I saw), especially with regard to the question about the part Jesus plays in Bush's life. I *loved* McCain's answer about rendering to Caesar what is Caesar's and rendering to God what is God's. Quite smart - quote the Bible for the extreme right while at the same time placating the (majority) moderates!:)
Of course Alan Keyes did not come off so well...
It's too bad you're voting based solely on religious preference.
Cool-looking cases are swell and all, but I want something functional.
Look at the newest Mac cases (not even the G3's - a recent PowerMac will do just as well). Everything swings out very easily, there aren't 10 different ribbon cables choking each other off and pulling the soundcard-to-cd cable out of its socket. The power supply is on a hinge so the SIMMs can be accessed easily.
Dell has started to add some of this (the hinged power supply), but it's still nowhere near as elegant as a Mac.
Where can I buy cases like this? I'd be willing to pay extra to get one.
Slashdot Mirror
As a Catholic, the Sacrement of Reconciliation is central to my beliefs. To fully receive the Sacrement, the confessor must seek the help of a priest and make the confession to that other person. I believe this is a uniquely Catholic view, but someone correct me if I'm wrong. The idea is that you're confessing to the priest, who acts as a mediator for Christ. The confessor is not confessing to flesh and blood. He or she is confessing to the human-divine Christ.
The idea of an on-line confessional brings up some interesting questions. How can the confessor be sure the other end is being viewed by an ordained priest? If the confession really does stay on the user's computer and no one sees it, then it is not a valid confession according to Catholic doctrine. How can the privacy of the confessional be maintained over a public medium (think of all those courtroom dramas you've watched over the years)?
--
--
And to beat a dead horse, the code morpher also optimizes. This is extremely important to the performance of Crusoe. It can actually run programs faster than if they were compiled natively, due to the run-time information available to the optimizer.
--
--
Note that there is no reason Crusoe couldn't support a staging compiler. Transmeta could always release a virtual ISA that had support for doing this efficiently. And of course you could always write a dynamic compiler in x86 (ugh). The point is that Transmeta could directly provide support for something akin to DyC in a later processor. And still maintain both backward and forward compatibility.
Pretty neat trick, I'd say.
--
The translation software provides backward compatibility, yes, but it also provides flexibility for Transmeta.
What if Transmeta desigs the TM-ISA? It's a virtual machine designed to translate efficiently to the bare hardware. Now compilers can take advantage of the additional registers provided by TM-ISA. If a new core provides more physical registers, TM-ISA v.2 can be released, allowing the use of more registers by the compiler.
That's all well and good, but we get the additional benefit that old programs run on the new hardware just fine, and there's no additional hardware cruft to maintain compatibility.
Ok, that's pretty cool. Backward compatibility is important. But what's really neat is that Crusoe provides forward compatibility. Code written to TM-ISA v.2 will run just fine on processors released with TM-ISA v.1 as long as new firmware is loaded that can understand TM-ISA v.2. So now software houses can release code optimized for the latest and greatest without worrying about users behind the curve not being able to run their stuff.
How often do people moan about RedHat not providing Pentium-optimized packages? With Crusoe, RedHat can silence the critics without impacting us 486 users.
--
What Transmaeta has essentially done is take the Merced core and execute the compiler at run-time. The alias handling structure acts like the ALAT on Merced.
Code executed through the translation layer should perform better than code executing on the bare metal because the translation software is learning and optimizing.
Think of it this way: would you rather manage your stock portfolio as is done today, by guessing what might happen, or would you rather know what the market is going to do and trade your stocks accordingly. I guarantee that I can beat your statically predictive management every time if I have that additional context.
--
Now I suppose Transmeta could design a full O-O-O core, but I don't see the point. If the software does a good job, the additional flexibility they gain to change the underlying machine is worth it.
As far as branches go, yes, you usually can guess a backward branch is going to be taken. But branches are still a huge problem. It's tough to keep a processor core fed. And don't even get me started on multiple branch prediction. The hit rate goes way down. A study was done here that showed processors today (or in the near future) spend about half the time recovering from branch mispredictions. That's a lot of wasted work. While the code morphing software can't do a perfect job, it is somewhat easier to tune the chip. And then think about per-application tuning. Load a different set of rules depending on the program you're running.
Interesting, no? :)
--
This is really, really great! Insanely great! Is the code optimizer smart enough to do cross-call optimization? That is, can it get rid of the call overhead?
Obviously I need to go read some documents, but how much code scheduling does it do? What does it do about control and/or data speculation, if anything? With the optimizer, you have the tradeoff between optimizing really aggressively and being able to cache as much generated code as possible. How is this tradeoff made?
--
Then it hit us. Crusoe can do well at x86 translation because of the utter lack of registers on the x86. If Crusoe even does just an average job of mapping of memory operations to registers (stack locations come to mind), that in itself could cover a lot of the translation overhead. Especially if the code cache is working well.
PowerPC, Sparc, etc. may not translate as well because their ISA's have more registers. There is not a lot of spill code in those object files. One win that could be had here is getting rid of some of the function call overhead. Saving and restoring registers is nasty stuff.
--
In any event, many licenses include a clause saying something to the effect of, "This agreement may be terminated at any time by either party." Now whether that's been tested in court, I don't know.
I'd guess most OEM's will wait on the sidelines to see what happens. Why put your company's neck on the line if you don't have to?
--
The problem with static compiler scheduling is that it doesn't have any run-time context. The translation layer provides this context, in effect allowing a compiler to optimize your code as it runs, which gives the optimizer more exact information. It's like an O-O-O machine, only more powerful since software can generally "see" further ahead than hardware. Because the generated code is re-used, the software translator can take a bit more time to do a good job.
--
However, as pnagel explained so well in another response to your message (Moderators, up the score on that one!), the code morphing does more than translate. It optimizes. A lot. It's very important for performance reasons that this happens. If Transmeta ever releases an O-O-O CPU, then this effect is somewhat less important and a direct issue would perform almost as well.
--
--
Well, it does. I don't know what Crusoe does with memory references, but I can almost guarantee you it can't map all of them to registers. The x86 is severely limited in the register area, and this really, really hurts compiled code. Spill code is a major problem on that architecture, not to mention all of the implicit dependencies between instructions and the general non-orthogonal nature of the instruction set. All of these things contribute to poor code generation on the compiler's part.
Even if it could map everything to registers (it might actually be able to handle most references to the stack), there's still the problem of instruction fetch. Getting instructions into the core is a big, big bottleneck. Having your program expressed in fewer instructions means you save I-Cache and instruction window/reservation station space. It means the hardware can "see" more of the program at once. Now the processors introduced today are not O-O-O, but the I-Cache still matters.
More registers usually means fewer instructions, as the "overhead" memory operations are not necessary. None of Crusoe's code morphing can help (static) instruction count.
What piques my interest in something like Crusoe is that now the compiler can generate its own ISA! This has been done by some researchers before, especially in the area of code compression where a custom ISA is designed to compress well for a particular program.
Think about this for a minute: the developer profiles a program to find some representative behavior. The compiler takes this information and figures out the best code it can generate without ISA restrictions. Need a vector add? Make one up! The compiler must still be aware of hardware issues (number of function units, etc.), but this removes one layer of restriction.
So the compiler generates object code as well as the firmware needed to run it. Linux (or your favorite OS) is modified so that the loader loads the object code into main memory, loads the firmware into flash memory (or wherever it goes) and yells, "Go!"
Now if we could only add registers... :)
--
Well, without ActiveX support, you're SOL on a lot of pages (mostly Microsoft pages, maybe, but software updates are important). The fact is that most PC users run Windows, so Windows must be supported. There's nothing preventing PowerPC from being supported as well.
Not true. What about the Power line (G5 [S/390], etc.)? I'm sure there are others (embedded chips, etc.), but I can't name them off the top of my head. Picking nits, maybe, but it irked me. :)
--
It struck me as odd that Ditzel claims Crusoe is the first processor to make use of a software solution. It may be the first designed to do this from the ground up, but the code morphing idea is not really all that new.
The IBM S/390 has the ability to completely recode the instruction set through microcode. The Alpha has PAL code for VAX compataility. FX!32 provide x86 compatability and "learns" about the program through profiling and reoptimization. Dynamo is HP's answer to FX!32, providing similar functionality to PA-RISC and probably IA32. While none of these are quite exactly like Crusoe, it's the same general idea.
Dynamic recompilation research has been going on for a while. Translating JVM's are only the most recent example. In fact Transmeta hired some big names in this area, which of course makes a lot of sense.
We've been kicking around the idea of self-optimizing computers for a while now. The idea being basically what Crusoe does - examine the software running and adjust accordingly. Now if a couple of inexperienced graduate students can come up with this idea after reading a few papers, it can't be all that revolutionary. :)
What I did like was the fact that someone finally publicly (i.e. through marketing) expressed the value of being able to change the underlying native instruction set. The question of whether the native ISA would be exposed was asked. The answer was no. This is a good thing, as it frees the hardware designers from having to carry around a bunch of compatability cruft. It's almost a necessary thing when your core is native VLIW.
I found it humorous that the bigwigs at Transmeta feel that Linus is the guy you want on a project like this. I figured you'd want someone with expertise in computer architecture and compilers. Yeah, I know it was a throwaway line, but we had a bit of a chuckle. I'm sure Linus us doing a great job. :)
As for the power consumption, it's not all that spectacular when you consider that the StrongARM has been sub-Watt for some time now. I'm not sure how many hardware power tricks were pulled with Crusoe, but the power demo was very entertaining. In any event, no one has been able to run x86 at a Watt, so that is certainly worth some praise. I know that Intel is very, very concerned about power (from a friend I have there). This could make them a bit nervous. I'm interested to see if they have anything that can compete.
But my big question concerns the web pad. First of all, that screen is tiny! No wonder it's low power! Aren't the disk and screen the largest consumers of battery power? It doesn't seem like Transmeta does anything about that. Hopefully the unnammed (and apparently unsigned) OEM's can solve that problem.
Even ignoring the screen/disk problem, why is Linux "the obvious choice" for a ROM-based OS in a web pad? If their main goal is a "fully internet compatable" low-power mobile device, it seems as though they've shot themselves in the foot by relying on an OS that has sub-average plugin support at best. They kept touting how the x86 compatability provides full support for plugins, but the OS question was completely ignored. What's the answer? It doesn't seem fully internet compatible to me.
--
He couldn't give me a timetable, but it is coming.
--
RedHat is not providing products at below cost to undercut competitors. Free (in both senses of the word) software has been their business model from day one. They sell support and nice packaging.
The fact is, Microsoft can use the huge profits on Office to shore up losses from IE. This in itself is not a bad thing. Corporations often buy up debt-ridden companies for tax reasons. But when this is done to strangle a competitor, it is illegal. They're using a monopoly in one market (Office) to gain entry into another market (internet browsers).
--
--
As far as whether it's a "common sense" solution, I'm not so sure. Everything is easy once you've seen it. How many of us look at the internet today (or 10 years ago, or whenever we got involved) and wonder why we didn't see it coming?
--
If I'm reading this correctly, the patent claims a handwriting recognition scheme that uses (graphically well-separated) characters that can be created with unbroken strokes. Said characters are allowed to have no spatial relation to each other.
It also includes a mechanism for translating the strokes into sequential coordinate lists and converting those lists to codes the machine can understand. There are other bits as well.
It seems to me that this is a valid patent (assuming no prior art) and Xerox has every right to defend it. This is not some silly patent on windowing or one-click shopping. Handwriting recognition is a non-trivial task and frankly, the inventors deserve to profit from their inventions.
That said, I wonder what Mentor Graphics thinks of all this, given their stroke interface to CAD tools. Doesn't it work the same way?
--
What I, as a musician/arranger, want to see is something like Finale. Anyone who's used the "speedy entry" feature knows what I'm talking about. I don't realy need software that can transcribe my playing real-time (though that would be nice), but I do need something that can grab a sample from the MIDI port and stick it on a staff.
Just as important is hardware support. I've got a SoundBlaster 16 with a crappy MIDI port. The thing doesn't work at all. So I went and got a parallel port MIDI interface that works like a charm under Windows. The problem is, there are no Linux drivers. I offered to develop some for the company, but they would not release specs. I can't imagine that this is a difficult driver to write or that the hardware configuration of the interface is so radically innovative that the company (MIDIMan) can't release its top-secret information.
I'd like to see some of these sound applications support MIDI input and some of the hardware companies actually giving a damn about their customers.
Can anyone help me? :)
--
I thought Bush and McCain did rather well in last night's debate (at least the highlights I saw), especially with regard to the question about the part Jesus plays in Bush's life. I *loved* McCain's answer about rendering to Caesar what is Caesar's and rendering to God what is God's. Quite smart - quote the Bible for the extreme right while at the same time placating the (majority) moderates! :)
Of course Alan Keyes did not come off so well...
It's too bad you're voting based solely on religious preference.
--
Look at the newest Mac cases (not even the G3's - a recent PowerMac will do just as well). Everything swings out very easily, there aren't 10 different ribbon cables choking each other off and pulling the soundcard-to-cd cable out of its socket. The power supply is on a hinge so the SIMMs can be accessed easily.
Dell has started to add some of this (the hinged power supply), but it's still nowhere near as elegant as a Mac.
Where can I buy cases like this? I'd be willing to pay extra to get one.
--