None of what you said had anything to do with my discussing the fact that he wants anti-aliased fonts on items printed on paper.
It has nothing to do with screens or monitor resolution. I was talking about offset presses.
Well actually it does. Because as I said, when the resolution goes above the dot pitch of the monitor, anti-aliasing is a wasted effort. This is because the smudging of the sampling is at a sufficiently macro-level that better sampling of what essentially are "sub-pixels" doesn't actually change its appearance.
The fact is that offset, and printing presses have far and away higher resolution than any display monitor. My 19" monitor essentially displays about 71 pixels per inch, while printers can do something closer to 1200 dots per inch.
The fact is, the resolution of printed material, at its highest quality setting challenges the resolution of the human eye. One is practically unable to see the "pixels" at which the printing press works at, and therefore we again run into the situation where anti-aliasing is a wasted effort, since the human eye will sample it at a macro level.
Now if you are printing.JPGs or.GIFs which just naturally have a much lower resolution than what your printer is capable of, then you will typically end up in the opposite case again, where the printer's resolution is far above that of the source image, and anti-aliasing will appear as smudging.
I want fonts to be antialiased on paper, not on the screen.
You don't quite get the concept of anti-aliasing, do you? Aliasing is the stair-step pattern you get on non-orthogonal lines on a bitmap based display (e.g. a CRT or LCD). Anti-aliasing is the apparent removal of those artifacts by blending the line's color with the color behind it. You don't quite seem to understand computer monitors, and human perception. Whether or not a particular solution to anti-aliasing works well or not, is dependent on the resolution you are at and the dot pitch of your monitor.
As the resolution drops below the natural resolution of the monitor (dictated by its dot pitch) the typical anti-aliasing strategy of proportional sampling becomes percieved as smudging. For very small fonts this will actually worsen their appearance.
As the resolution increases above the natural resolution of the monitor, the effect of anti-aliasing becomes unnoticable. I.e., its not worth the processing power to do it.
Anti-aliasing by proportional sampling really works best if the desktop resolution is optimally set according to the dotpitch of the monitor. For 0.28, for example, 1280x1024 is the resolution you should pick. The reason is because that monitor is already doing a form of proportional sampling close to the resolution of the actual pixels. By performing the proportional sampling in the source pixels, it improves the accuracy of the sampling (from an information theory point of view) that the monitor performs.
Anyhow the point of all this is that depending on the resolution the end user has set, and the actual dot pitch of their monitor, they can actually see "anti-aliased" fonts as looking worse (typically smudged.)
Yes, this is a classical no-no learned through hard experience. That experiences? Coke versus Pepsi. Pepsi wouldn't have stood a chance if coke wasn't so stupid as to run their "taste test" ads which mentioned Pepsi in every one of them. This is why Intel has never ever mentioned AMD by name in any of its advertisement.
There are plenty of open source systems for version control and configuration management.
You are moving backwards in this conversation. There plenty of *crappy* open source systems for version control. This was covered to death a long time ago when Linus first moved to BitKeeper.
Furthermore, they way open source works, if you need an unusual tool for your project, you create it yourself and share it.
You should look through some of the presentations given by BitKeeper. Their claims are that developing such a tools *requires* a very large capitol investment. Doing it right requires a lot of dedicated people to produce.
While this kind of thing has been done in the past with things like gcc, that's a very well defined problem, with a lot of people motivated to work on that single project. There are *many* OSS revision control systems being worked on, and with the exception of the perrennial butt of all jokes (CVS) all of them are in a serious state of incompleteness.
We don't need to rehash the encyclopedic list of defects of CVS here again. The fact it is, its an unacceptable joke of a tool, and other tools like Perforce and BitKeeper are not.
The original poster is correct when he says a well designed project has very few "recompile from scratch" events. If you think that's BS its because you don't have a well designed project.
1) The first line of my makefile is always:
#if 0
And the last list is always:
#endif
This way I can include the makefile directly into the sources innocuously. Couple this with auto-dependency generation, and its just a matter of noting those files that are dependent on the makefile and those that aren't.
2) If you are touching your header files and this is causing frequent "everything needs to be recompiled" problems, then you have poorly designed header files. Mosts header file activity should deal with interfaces between as few modules as possible. Global header files should mostly contain agreed upon conventions, and absolute high level design APIs that should have been decided from the very beginning, and not change.
OTP is vulnerable plain text attacks if you use it improperly -- i.e., more than once. One of his claims is that he can use the pad more than once. IMHO, he hasn't proven himself to be a crackpot yet.
His real problem, IMHO, is that OTP style encryption is mostly useful theoretically, not practically. I.e., even if he has something as good as he claims, why aren't more conventional algorithms at least as good in practice?
Ok, so it doesn't, but it does. Eh? CVS handles binary files just fine. It may not do diffs, but it does version track them - it just stores full copies of each version. In most code projects the amount of change of binary files that are eligable to be checked into CVS is very small. Besides, disk space is way cheap, right?
Ah yes, but it doesn't allow conversion from binary to ascii and back without a *LOT* of working around of the revision system. And certainly such transitions are not tracked. And yes this *is* relevant for certain formats like PDF which be either ASCII or binary depending on the mode in which you are using it.
Wrong. CVS will not commit any files if there are conflicts in the files you are commiting. If you notice, it walks each directory before connecting to the repository.
But this does not make it atomic. If two users are checking in overlapping changes at the same time, then there is nothing CVS can do. CVS does not have a concept of a "block lock" on multiple transactions, and therefore has no way of dealing with concurrent overlapping checkins.
His scenario as stated is not correct, but he may have felt this to have happened if someone else was checking in at the same time, and they did not ever deduce that this is what happened. CVS also gives no warning about the concurrent overlapping checkin scenario.
CVS does this as well, and has for a long time. This is the only reason there is a 'problem' with binary files in the first place - CVS tries to translate the newline characters in the binary file unless you use -kb when adding the file the first time.
Well as long as we are nitpicking -- the other reason, that is just as relevant is because of the keyword expansion. While this is desirable in some text files, in some it is not, and it binary files it is never desirable. CVS forces you to correctly pick the mode right from the very start of file creation.
I would like to point out that because of the existence of Samba and certain *intellegent* editors that exist on Windows, this auto-translation that CVS performs can actually be a problem. If you check out with Windows, edit, then check in on UNIX you are screwed. And yes there are real scenarios where this can happen (this is when *I* learned about CVS's auto-CR/LF translation "feature".)
This license stipulation doesn't sound enforceable. My recommendation: For anyone in the situtation where this applies, just violate the license. I don't think there is anything they can do to you.
Wow... We use CVS at work and certainly haven't felt it isn't "industrial enough" to handle what we're after. Quite the opposite in fact.
What do you have like 3 developers at your work? Once we hit about 15 people at my work place, CVS was showing obvious warts and problems (but my employer is cheap, and I could not convince them to move to Perforce.)
Broken builds?? What do they think the last tagged version of the stable branch is supposed to be for?
Wasting people's time and giving people a false sense of security? If you have enough developers working on the same project, you rarely want to move the tree back more than a few hours. Do you put tags on your tree every few hours?
Also as your project gets bigger, tracking down the precise cause of a bug can very complicated. Simple binary search on checkins becomes a useful way to track down problems. Since CVS has atomicity problems, even doing checkout by date is insufficient to narrow down a precise checkin that caused whatever problem you are looking for.
"plain text" a bad thing? I find I can usually trust products that keep plain things plain, much more than ones that try to over-complexify everything. If a developer can't handle managing several checkouts of a repository in his/her own work area, he/she probably doesn't deserve the title.
You are going to put your JPG/GIF/WAV files into your repository in plaintext somehow? Even if you uu-encode them, the diffs will be as large as the files themselves.
CVS admin requires administration priveleges -- i.e., you are not suppoed to be directly fooling with your respository as part of standard development. Managing your own repositories requires changing your CVS environment directory, in between any context change between repositories. I.e., trying to manage a project where some files are part of the master repository and some are your personal repository is basically not reasonably doable.
RCS limitations? Be nice to see some of the most prominent listed if they are such a big deal.
They have a direct comparison of BitKeeper and RCS right there on their website.
The multiple repository thing does seem interesting, but I'd think if it came to where you really needed it, something could be worked out using CVS without too much work... Actually, in practice it would seem better to get everything into the main repository as quickly as possible so everyone else can start testing on the code sooner, even if there was a bit more overhead associated with doing that.
But that is only one mode of development criteria that you are satisfying. What if you need to perform a "long excursion" of source development, with a subteam of developers? The more developers on your team, the shorter this "excursion" has to be to warrant a seperate repository.
Course, maybe this BitKeeper appeals to managers more than actual developers...
From what I can tell, its features are developer oriented. For example, it does not have any features to associate bug tracking to checkins (so you know who to blame, for example.) But it has features relating to performance and finer granularity of checkin tracking versus CVS, which I would call developer features.
Deep Blue was simple a souped up version of Deep Thought II. Kasparov could look through all those games if he liked (he even played a previous match with it, which he won.)
None of the Deep Blue team is strong enough to program a specific strategy in particular to play against Kasparov, except US GM Joel Benjamin. And Joel knows nothing about computer chess programs. He came up with the opening book for Deep Blue and played a few training games to tune its positional coefficients, but there is little else he could do for that team. They could not feed it a specific anti-Kasparov strategy; they had to rely solely on technological advantages.
Kasparov also played in a style that he's never played in the past. It was bizarre, closed, and very passive. Completely opposite to how Kasparov plays normally (he is typically a very dynamic, tactical, and aggressive player.) Even given this choice of strategy, there are many other players in the world who can do that better that he. In any event, Kasparov's choice of playing strategy nullified any specific anti-Kasparov strategy they might have created.
Deep Blue was a very expensive technical experiment by IBM that played 6 games in its life, then was quickly dismantled and never heard from again, except in IBM's advertisements. Them trying to sell their computers based on its ability to beat Kasparov is no different from Intel trying to tell your that the Pentium 4 will improve internet speeds.
Kramnik is more than just a "staunch defender". He is the strongest all around chess player with the possible exception of Garry Kasparov. His greatest strength is his incredible depth of understanding chess from a positional point of view. That's how he beat Kasparov.
You are not up on the latest in computer chess results. The top programs have varying degrees of positional understanding which allows them to make some kinds of sacrifices. Deep Junior is especially renowned for its ability to make pure sacrifices on positional critieria.
Indeed in speed chess, computers reign supreme. But why not cite the actual results? A few years ago, Kasparov, Anand, and others were invited to play a few exhibition blitz games against a previous version of Fritz. They played a few dozen games, with Fritz winning by an extreme margin (something like 10-2 or so.)
(Deep) Fritz is a closed source program. It is impossible to say what its capable of in certain endgames. These programs have over a decade of programming in them, and they all have interesting strengths and weaknesses. While your analysis about its understanding of this endgame may be correct, I don't think your reasoning is necessarily well founded. Some ICCA (International Computer Chess Association) articles have shown methods for encoding algorithms for many endgames, such as pawn endgames in almost completely formulaic ways.
Of course Kramnik has been playing training matches against this precise version of Fritz for quite some time now. I would suggest that we *know* Fritz won't beat Kramnik in the Berlin Defence simply by virtue of him using it. The rules for this match stipulate that the Fritz team may not deviate its programming or openings while the match is going on. Thus if Fritz wants to change strategy, then its up to the program, not the programmers. It better have some kind of random opening generator, or opening learning system, otherwise a most embarassing thing will happen -- Kramnik will draw all his games with black with precisely the same moves.
Before I make a prediction, I want to see how Kramnik handles white. Of course, Kramnik is well known for his solid play, but if he can't make headway as white, he may feel he has to try harder, and screw up in the process. We shall see. But obviously drawing with black, and fairly easily shows that Kramnik is doing well so far, though perhaps not as well as we/he might have hoped.
Go look into the NSA's "Security Enhanced Linux". After investigating and understanding what they did with that, you should understand one thing -- Linux and UNIX in general as it currently stands, have a very insufficient security model.
The need to be able to install software and access device features may be legitimate things for any user to be doing in certain situations. Trying to impose the age-old Linux/UNIX method of security is not going to do anything but piss end users off, because they can't do things which are trivial under Windows.
In the last two Linux kernel summit conferences it is clear that they are taking this very seriously and are working towards some kind of "correct solution". But that means, of course, that they are not there yet. So I don't see the rationale of pushing the old model that's going to be obsolete, in maybe about 6 months to a year.
Dozens of companies have attempted to make x86 compatible processors. Only one other survived with any degree of seriousness.
And FPGA compatible x86 would not be a very compelling product. You could emulate it in software on another CPU (not involved in the Palladium deal) much faster.
The STREAM benchmark is one of the simplest programs imaginable. It has no OS requirements whatsoever. The only thing this says about Linux is that there appears to be either a Fortran or C compiler for it.
Tell me, how do you quickly minimize all the documents opened by a single application, but nothing else? With MDI, that's exactly what the minimize button does -- without it, you hit minimize on each open Window one by one.
Ranking in order of loss, draw and win, making moves that allows you to force the best possible outcome for your side. The definition is sound so long as the game ends deterministically -- since you can always recurse backwards starting from the last move of the game.
Slashdot Mirror
- None of what you said had anything to do with my discussing the fact that he wants anti-aliased fonts on items printed on paper.
Well actually it does. Because as I said, when the resolution goes above the dot pitch of the monitor, anti-aliasing is a wasted effort. This is because the smudging of the sampling is at a sufficiently macro-level that better sampling of what essentially are "sub-pixels" doesn't actually change its appearance.It has nothing to do with screens or monitor resolution. I was talking about offset presses.
The fact is that offset, and printing presses have far and away higher resolution than any display monitor. My 19" monitor essentially displays about 71 pixels per inch, while printers can do something closer to 1200 dots per inch.
The fact is, the resolution of printed material, at its highest quality setting challenges the resolution of the human eye. One is practically unable to see the "pixels" at which the printing press works at, and therefore we again run into the situation where anti-aliasing is a wasted effort, since the human eye will sample it at a macro level.
Now if you are printing
You don't quite get the concept of anti-aliasing, do you? Aliasing is the stair-step pattern you get on non-orthogonal lines on a bitmap based display (e.g. a CRT or LCD). Anti-aliasing is the apparent removal of those artifacts by blending the line's color with the color behind it.
You don't quite seem to understand computer monitors, and human perception. Whether or not a particular solution to anti-aliasing works well or not, is dependent on the resolution you are at and the dot pitch of your monitor.
As the resolution drops below the natural resolution of the monitor (dictated by its dot pitch) the typical anti-aliasing strategy of proportional sampling becomes percieved as smudging. For very small fonts this will actually worsen their appearance.
As the resolution increases above the natural resolution of the monitor, the effect of anti-aliasing becomes unnoticable. I.e., its not worth the processing power to do it.
Anti-aliasing by proportional sampling really works best if the desktop resolution is optimally set according to the dotpitch of the monitor. For 0.28, for example, 1280x1024 is the resolution you should pick. The reason is because that monitor is already doing a form of proportional sampling close to the resolution of the actual pixels. By performing the proportional sampling in the source pixels, it improves the accuracy of the sampling (from an information theory point of view) that the monitor performs.
Anyhow the point of all this is that depending on the resolution the end user has set, and the actual dot pitch of their monitor, they can actually see "anti-aliased" fonts as looking worse (typically smudged.)
Yes, this is a classical no-no learned through hard experience. That experiences? Coke versus Pepsi. Pepsi wouldn't have stood a chance if coke wasn't so stupid as to run their "taste test" ads which mentioned Pepsi in every one of them. This is why Intel has never ever mentioned AMD by name in any of its advertisement.
G5 is shown on the Motorola PPC Roadmaps. With the advent of this IBM CPU, I expect the G5 to be exactly one thing: Cancelled.
There are plenty of open source systems for version control and configuration management.
You are moving backwards in this conversation. There plenty of *crappy* open source systems for version control. This was covered to death a long time ago when Linus first moved to BitKeeper.
Furthermore, they way open source works, if you need an unusual tool for your project, you create it yourself and share it.
You should look through some of the presentations given by BitKeeper. Their claims are that developing such a tools *requires* a very large capitol investment. Doing it right requires a lot of dedicated people to produce.
While this kind of thing has been done in the past with things like gcc, that's a very well defined problem, with a lot of people motivated to work on that single project. There are *many* OSS revision control systems being worked on, and with the exception of the perrennial butt of all jokes (CVS) all of them are in a serious state of incompleteness.
We don't need to rehash the encyclopedic list of defects of CVS here again. The fact it is, its an unacceptable joke of a tool, and other tools like Perforce and BitKeeper are not.
The BSD folks are rolling their eyes.
Wasn't this added to the Emacs OS?
I have never run across an OS where this has been a problem.
The original poster is correct when he says a well designed project has very few "recompile from scratch" events. If you think that's BS its because you don't have a well designed project.
1) The first line of my makefile is always:
#if 0
And the last list is always:
#endif
This way I can include the makefile directly into the sources innocuously. Couple this with auto-dependency generation, and its just a matter of noting those files that are dependent on the makefile and those that aren't.
2) If you are touching your header files and this is causing frequent "everything needs to be recompiled" problems, then you have poorly designed header files. Mosts header file activity should deal with interfaces between as few modules as possible. Global header files should mostly contain agreed upon conventions, and absolute high level design APIs that should have been decided from the very beginning, and not change.
(eventhough it has a misleading title!)
Pot. Kettle. Black.
OTP is vulnerable plain text attacks if you use it improperly -- i.e., more than once. One of his claims is that he can use the pad more than once. IMHO, he hasn't proven himself to be a crackpot yet.
His real problem, IMHO, is that OTP style encryption is mostly useful theoretically, not practically. I.e., even if he has something as good as he claims, why aren't more conventional algorithms at least as good in practice?
Ok, so it doesn't, but it does. Eh? CVS handles binary files just fine. It may not do diffs, but it does version track them - it just stores full copies of each version. In most code projects the amount of change of binary files that are eligable to be checked into CVS is very small. Besides, disk space is way cheap, right?
Ah yes, but it doesn't allow conversion from binary to ascii and back without a *LOT* of working around of the revision system. And certainly such transitions are not tracked. And yes this *is* relevant for certain formats like PDF which be either ASCII or binary depending on the mode in which you are using it.
Wrong. CVS will not commit any files if there are conflicts in the files you are commiting. If you notice, it walks each directory before connecting to the repository.
But this does not make it atomic. If two users are checking in overlapping changes at the same time, then there is nothing CVS can do. CVS does not have a concept of a "block lock" on multiple transactions, and therefore has no way of dealing with concurrent overlapping checkins.
His scenario as stated is not correct, but he may have felt this to have happened if someone else was checking in at the same time, and they did not ever deduce that this is what happened. CVS also gives no warning about the concurrent overlapping checkin scenario.
CVS does this as well, and has for a long time. This is the only reason there is a 'problem' with binary files in the first place - CVS tries to translate the newline characters in the binary file unless you use -kb when adding the file the first time.
Well as long as we are nitpicking -- the other reason, that is just as relevant is because of the keyword expansion. While this is desirable in some text files, in some it is not, and it binary files it is never desirable. CVS forces you to correctly pick the mode right from the very start of file creation.
I would like to point out that because of the existence of Samba and certain *intellegent* editors that exist on Windows, this auto-translation that CVS performs can actually be a problem. If you check out with Windows, edit, then check in on UNIX you are screwed. And yes there are real scenarios where this can happen (this is when *I* learned about CVS's auto-CR/LF translation "feature".)
This license stipulation doesn't sound enforceable. My recommendation: For anyone in the situtation where this applies, just violate the license. I don't think there is anything they can do to you.
Wow... We use CVS at work and certainly haven't felt it isn't "industrial enough" to handle what we're after. Quite the opposite in fact.
What do you have like 3 developers at your work? Once we hit about 15 people at my work place, CVS was showing obvious warts and problems (but my employer is cheap, and I could not convince them to move to Perforce.)
Broken builds?? What do they think the last tagged version of the stable branch is supposed to be for?
Wasting people's time and giving people a false sense of security? If you have enough developers working on the same project, you rarely want to move the tree back more than a few hours. Do you put tags on your tree every few hours?
Also as your project gets bigger, tracking down the precise cause of a bug can very complicated. Simple binary search on checkins becomes a useful way to track down problems. Since CVS has atomicity problems, even doing checkout by date is insufficient to narrow down a precise checkin that caused whatever problem you are looking for.
"plain text" a bad thing? I find I can usually trust products that keep plain things plain, much more than ones that try to over-complexify everything. If a developer can't handle managing several checkouts of a repository in his/her own work area, he/she probably doesn't deserve the title.
You are going to put your JPG/GIF/WAV files into your repository in plaintext somehow? Even if you uu-encode them, the diffs will be as large as the files themselves.
CVS admin requires administration priveleges -- i.e., you are not suppoed to be directly fooling with your respository as part of standard development. Managing your own repositories requires changing your CVS environment directory, in between any context change between repositories. I.e., trying to manage a project where some files are part of the master repository and some are your personal repository is basically not reasonably doable.
RCS limitations? Be nice to see some of the most prominent listed if they are such a big deal.
They have a direct comparison of BitKeeper and RCS right there on their website.
The multiple repository thing does seem interesting, but I'd think if it came to where you really needed it, something could be worked out using CVS without too much work... Actually, in practice it would seem better to get everything into the main repository as quickly as possible so everyone else can start testing on the code sooner, even if there was a bit more overhead associated with doing that.
But that is only one mode of development criteria that you are satisfying. What if you need to perform a "long excursion" of source development, with a subteam of developers? The more developers on your team, the shorter this "excursion" has to be to warrant a seperate repository.
Course, maybe this BitKeeper appeals to managers more than actual developers...
From what I can tell, its features are developer oriented. For example, it does not have any features to associate bug tracking to checkins (so you know who to blame, for example.) But it has features relating to performance and finer granularity of checkin tracking versus CVS, which I would call developer features.
Yeah, and underneath it are the options:
[Retry] [Cancel]
Deep Blue was simple a souped up version of Deep Thought II. Kasparov could look through all those games if he liked (he even played a previous match with it, which he won.)
None of the Deep Blue team is strong enough to program a specific strategy in particular to play against Kasparov, except US GM Joel Benjamin. And Joel knows nothing about computer chess programs. He came up with the opening book for Deep Blue and played a few training games to tune its positional coefficients, but there is little else he could do for that team. They could not feed it a specific anti-Kasparov strategy; they had to rely solely on technological advantages.
Kasparov also played in a style that he's never played in the past. It was bizarre, closed, and very passive. Completely opposite to how Kasparov plays normally (he is typically a very dynamic, tactical, and aggressive player.) Even given this choice of strategy, there are many other players in the world who can do that better that he. In any event, Kasparov's choice of playing strategy nullified any specific anti-Kasparov strategy they might have created.
Deep Blue was a very expensive technical experiment by IBM that played 6 games in its life, then was quickly dismantled and never heard from again, except in IBM's advertisements. Them trying to sell their computers based on its ability to beat Kasparov is no different from Intel trying to tell your that the Pentium 4 will improve internet speeds.
(Deep) Fritz is a closed source program. It is impossible to say what its capable of in certain endgames. These programs have over a decade of programming in them, and they all have interesting strengths and weaknesses. While your analysis about its understanding of this endgame may be correct, I don't think your reasoning is necessarily well founded. Some ICCA (International Computer Chess Association) articles have shown methods for encoding algorithms for many endgames, such as pawn endgames in almost completely formulaic ways.
Of course Kramnik has been playing training matches against this precise version of Fritz for quite some time now. I would suggest that we *know* Fritz won't beat Kramnik in the Berlin Defence simply by virtue of him using it. The rules for this match stipulate that the Fritz team may not deviate its programming or openings while the match is going on. Thus if Fritz wants to change strategy, then its up to the program, not the programmers. It better have some kind of random opening generator, or opening learning system, otherwise a most embarassing thing will happen -- Kramnik will draw all his games with black with precisely the same moves.
Before I make a prediction, I want to see how Kramnik handles white. Of course, Kramnik is well known for his solid play, but if he can't make headway as white, he may feel he has to try harder, and screw up in the process. We shall see. But obviously drawing with black, and fairly easily shows that Kramnik is doing well so far, though perhaps not as well as we/he might have hoped.
Go look into the NSA's "Security Enhanced Linux". After investigating and understanding what they did with that, you should understand one thing -- Linux and UNIX in general as it currently stands, have a very insufficient security model.
The need to be able to install software and access device features may be legitimate things for any user to be doing in certain situations. Trying to impose the age-old Linux/UNIX method of security is not going to do anything but piss end users off, because they can't do things which are trivial under Windows.
In the last two Linux kernel summit conferences it is clear that they are taking this very seriously and are working towards some kind of "correct solution". But that means, of course, that they are not there yet. So I don't see the rationale of pushing the old model that's going to be obsolete, in maybe about 6 months to a year.
Please just go here:
http://www.xenutv.com/interviews/woodcrafts.htm
It will explain everything.
Dozens of companies have attempted to make x86 compatible processors. Only one other survived with any degree of seriousness.
And FPGA compatible x86 would not be a very compelling product. You could emulate it in software on another CPU (not involved in the Palladium deal) much faster.
Uuuuhhh ... you counted 3 more than I did.
The STREAM benchmark is one of the simplest programs imaginable. It has no OS requirements whatsoever. The only thing this says about Linux is that there appears to be either a Fortran or C compiler for it.
Tell me, how do you quickly minimize all the documents opened by a single application, but nothing else? With MDI, that's exactly what the minimize button does -- without it, you hit minimize on each open Window one by one.
Only consumers can strike down Palladeum. Fortunately, there is a good change they could do just that.
Ranking in order of loss, draw and win, making moves that allows you to force the best possible outcome for your side. The definition is sound so long as the game ends deterministically -- since you can always recurse backwards starting from the last move of the game.
I believe Go-Moku has already been cracked (win for first player I think.) Go? We won't see that one cracked in our lifetimes.
How does it compare with Insure++? This has been available for Linux for some time.