Google could avoid this if they switched to HTTPS instead of HTTP. But that might require a lot of extra computing power to do all the encryption and decryption. I wonder how much it would cost, in fact?
It would be great if Google phased out HTTP in favour of HTTPS, to help their Chinese users, and all the other big sites followed suit - but I don't think it's going to happen any time soon.
I dunno, the propaganda for GTK-- seems to say that it is a better fit for C++ than Qt, since Qt is old and crusty and 1993-era C++ rather than nice and clean and STL, standard-library-based. So I don't think the KDE / GNOME choice is as simple as C++ / C.
The Qt licensing costs aren't a big amount but I think the point is there's only a single supplier. This is generally considered a Bad Thing, even if in the short term the fees they are currently charging (to get people 'hooked') are affordable.
Surely it's best to change the bug-reporter to send bugs to RedHat and not KDE, since RH are distributing a modified version. There would be many more complaints if the KDE team started getting deluged by bugs which were actually caused by RH's changes... better to have Red Hat, as the 'vendor', take the effort to work out which are problems with their distribution and which bugs in KDE.
There are good political reasons to choose GNOME. (I don't know why when people say 'politics' it is assumed to be a synonym for 'bad'.) Namely, proprietary software vendors can produce GNOME versions of their apps without any trouble; but you have to pay Troll Tech if you want to produce proprietary software for KDE.
Free software zealots won't care one way or the other - indeed they might even prefer the GPL'd Qt rather than Lesser-GPL'd GNOME libraries - but businesses are perhaps more likely to choose GNOME if they decide which desktop to develop for.
About half of the TNG episodes are drivel as you describe (I just watched the 'Riker clipshow' and became increasingly disgusted as it became apparent nothing was actually going to happen - also a bit sorry for Riker because his adventures are much duller than Picard's) but there are enough good ones to keep watching. With DS9 or Voyager however the proportion of good episodes is less than half, which is why I stopped watching them a couple of years back. (And Enterprise seems to suck too.)
Don't all the Bond movies essentially have about three or four plots? What about Police Academy? Indeed, is there any series of movies that *doesn't* have the same few plots repeated again and again?
Why do we have to use dots per inch at all? Why not just measure resolution in micrometres (as is done for integrated circuit manufacturing, for example)? So a '75dpi' screen is about 340 micrometres resolution. Professional printing might use a resolution of 21 micrometres. And so on.
(Yeah I know dots per inch is the established standard and it's not going to go away any time soon. But I still think metric is the way to go. Alternatively you could measure dots per millimetre - but something measured in 'per unit of length' is a more complex measurement than just a unit of length. Still, often there's the feeling that higher is better (eg CPU speeds are measured in Hz, not cycle time) so maybe dots per millimetre is it.)
I believe there is an OpenGL library which uses wireframe graphics, so you can run Quake (even Quake 3) on modest hardware. Anyone know where it lives?
It would be good if Linux distributions did things like having a single system-wide speller - unfortunately that means changes to applications, and distros tend to get flamed by weenies if they ship 'non-standard' versions of packages. More importantly, there just isn't the time for the packagers to modify all the apps to behave nicely. Distributions like Lycoris where there is just *one* mail client, web browser, drawing program etc etc are closer to achieving this.
FWIW, it would be okay if MS Office included a spellchecker that _replaced_ the system standard one (optionally, but if it really was better then you'd say 'yes'). Then you'd have both consistency and the improved features. Office sounds like it is doing things the Windows way where each app has to drag a kitchen sink with it, rather than implement a service centrally.
If MS Office's source code were available then Apple would be able to modify it to use the system spellchecker. That's a new argument for source disclosure as far as I'm aware: it helps enforce consistency among applications.
(My personal favourite example: why do web browsers have disk caches? Why not install a single proxy server package, not necessarily a big one like Squid but something small and serving the local machine, and then have the browsers connect to that?)
Apple's guidelines are the direct opponent of all those developers for Mozilla, Java, StarOffice, and so on who go to a lot of trouble to make sure their app looks the same on all platforms. Even reimplementing a whole widget set from scratch, in the three examples above. Now, which philosophy do users prefer - make it consistent with the rest of the platform, or make it consistent with the same app on other systems?
Can someone explain the objection to using Python for the configuration system? Surely the kernel developers don't believe that C is the be-all-and-end-all of languages. If it's quicker and more maintainable to write in a high-level language then why not just do the job - and use the time you saved compared to writing in C for other things? It's not as if Python is something wacky or proprietary or a resource hog.
Re:Most annoying game ever
on
Awari Solved
·
· Score: 2
Yeah, an owari-playing program I wrote did that. It would announce the best score available to it, computed from the lookahead tree, and when the game was winnable within the lookahead range this score would be '+24' (the highest possible). Unfortunately during the tournament such a pronouncement wasn't accepted as proof of winning, we had to wait for the game to play through to the end:-(.
I could have programmed it to 'resign' when the game was unwinnable, but if your opponent is not using the perfect strategy then you could keep playing and hope he makes a mistake. In fact the best strategy here is probably to draw the game out for as long as possible.
If you count 'your opponent might make a mistake' as an element of chance, then _every_ game has an element of chance and so the phrase doesn't really mean anything.
When people talk of games with chance involved they mean those where the rules have some kind of randomness, like dice. This makes sense if you realize that by 'the game of chess' it is meant 'the rules of the game of chess'. If the rules do not contain randomness, then 'the game' does not involve chance.
Of course any particular game of chess you play has an element of luck, since your opponent might get struck by lightning causing a draw, for example.
The game of awari (owari) was an end-of-first-term programming project at my university. Because there are at most six moves possible at any point, and usually fewer than that, the game works well with a minimax tree-searching strategy. On a Celeron 400, allowing about 30 seconds for each move, I got a lookahead depth of 9 moves, increased to 18 moves after adding alpha-beta pruning. I don't know how this compares to the best human players but it was certainly enough to beat me into the ground:-).
I did wonder about cranking up the lookahead depth to try and solve the game - after all, most games the program played it won within 25 moves or so - but each extra level of lookahead roughly triples the run time. After seeing the hardware used by these two chaps it seems that the problem was a bit bigger than I thought. I had considered using a Postgres database to store the lookup of the best move at each stage - lucky I didn't, it would have been completely slaughtered:-).
The owari-playing program is at http://membled.com/work/owari/owari.c if anyone is interested - that directory also contains a Perl front-end which caches the computed best moves. I used that to automatically build up a database of 'openings' computed to a slightly higher lookahead level. I was planning to package up the program and release it, perhaps moving the minimax code into a library. But now the game of owari has been solved, I guess there isn't much point any more:-P.
BTW you can easily un-solve it just by playing with fourteen bowls and twenty-eight stones - it would take them several times longer to find the solution to that.
I wonder if all possible (symmetric) owari games are draws when played with the best strategy?
What's the CPU speed like? How long does it take to compile a kernel on an Xbox?
Re:Linux Driver programmer will be missed my many
on
RIP: Leonard Zubkoff
·
· Score: 2
I found a problem with the BusLogic driver he maintained. He was very helpful and suggested a fix. I said thanks, I'll try it and get back to you sometime. Now I never will.
I think you should make the case based on economic welfare, since arguments based on freedom or fairness are not considered legitimate by some (and will help opponents to characterize you as extremists, idealists, etc - in fact it is the everything-should-be-patentable campaigners who are taking the ideological position).
I wrote to the European Commission when they asked for comments on their (rather biased) study of software patentability; I have pasted in these comments below.
Comments on the study 'The Economic Impact of Patentability of
Computer Programs'
Ed Avis, ed@membled.com
These are comments I would like to submit to the Commission about its study on software patentability. The order of the comments follows the order in which the study is presented, which means that comments on the study's conclusions come first.
At the end are some more general comments on whether it is useful to grant patents on computer programs.
SECTION I
* Open source development
I feel that the authors of the report have misunderstood the position of open source developers summed up in the quotation from one open source developer. This developer points out that while the platform itself is open, individuals are free to create proprietary products based on that platform. This is usually true. and it is what copyright achieves. But I know that most open source developers would not support the idea that a particular use of their platform could be patented by one company which then prevents others from making their own implementation---in effect making the platform itself proprietary, since it no longer provides an open base for competing developers to build on.
The anonymous developer comments: `The goal of open source is to make sure that IP rights or other proprietary rights do not interfere with that platform'. This is the case for copyright on software, but software patents often do interfere with a previously open platform and limit choice. This is particularly true given the broadness and triviality of many software patents currently being granted.
Actually, I feel that the emphasis given to open source developers is misleading. Certainly the individual developer is vulnerable to software patents, but then so are all development groups not big enough to fight back. It just happens that unpaid open source developers are at one end of the scale. (They are also more vulnerable because they cannot keep their development secret, a point I'll mention again later.)
* Software patents necessary for American SMEs
Commenting on the situation in the United States, the authors write: `On the one hand there is abounding evidence that the profitability and growth of independent and SME software developers in the States has often been to a significant extent dependent on possession of patent rights'.
It should be clear that this does not imply that the existence of software patents helps small and medium-sized developers to grow. It could just as well be true that the legal climate is such that a small company without sufficient patents to use defensively is vulnerable to attacks from large patent-holding corporations, and thus it is necessary for small companies to acquire patents if they are to attract investment and grow. In fact I believe that this is the case. The fact that, in the present US legal climate, it is necessary for small firms to hire patent lawyers and start acquiring patents does not mean that small firms in Europe would be helped by the introduction of a similar system. It might just be a burden they would rather do without.
Also remember that a fast-growing, highly profitable company which holds many patents does not necessarily indicate a healthy marketplace. It could be that this company is doing well through blocking competitors from entering the market and through demanding licence money from other firms. Such behaviour does not usually help consumers, who would prefer an open and competitive market. It might be better to have several companies, not quite as fast-growing or as profitable, who are competing freely and growing the total size of this market segment faster than a single monopolistic firm.
It is jumping to conclusions to say, as the report does, that patentability of computer programs has helped the growth of SMEs in the US. All one can conclude is that in a market where your competitors are filing for patents, you need to do the same yourself if you expect to grow.
* Do software patents help small companies?
The authors claim that lack of software patents in the early days of the computer industry made it easier for large companies to copy the ideas of smaller developers. But is there any evidence that widespread software patentability has stopped this trend? A small developer holding one or two patents on a key idea will not stand a chance in a legal battle with a large developer holding thousands of patents, many of them vague or extremely broad but nonetheless granted. Software patents certainly do not level the playing field in favour of the small developer---except perhaps for the company which does no development work itself (thus not infringing on anyone else's patents) but distorts the market by accumulating patents on whole classes of computer programs.
(There is also the implicit assumption that it's a bad thing for other companies to market their own products based on a particular idea. But in order for competition in software to exist at all, this must be allowed. The advantage of being first to market is particularly great in the software industry, there's no reason to create extra barriers to entry for those who are trying to bring competing products to market.)
* Invalid patents
The report acknowledges that many software patents granted in the US are invalid, but doesn't consider this important: `Their existence... is hardly a significant barrier to software developers.'. This is to seriously underestimate the problem.
Even an infringement suit for an invalid patent requires hiring a patent lawyer and a trip to court. Even if you win, the process can be cripplingly expensive for a small software developer, impossible for an individual or start-up. (This is true even under a loser-pays system, since it can never be absolutely certain who will win.) Multiply that by the sheer number of vague, possibly invalid patents held by many large companies, each one of them the subject of infringement proceedings, and you will see that invalid patents are just as much a problem as valid ones.
The overheads of software development are much lower than those in most industries where patents are used; so the costs of fighting patent lawsuits are proportionally much higher. Any patents, invalid or otherwise, represent a real risk for the small software developer. Large companies can usually countersue with their own collection of patents and reach a cross-licensing agreement, so invalid patents aren't so much a problem for them.
* Current quality of software patents
The report concludes that we need to make sure European patent offices (national and EPO) do not fall into the same trap as the USA, to make sure they do not grant `obvious' patents. (It's not clear whether this means obvious to a software developer, or obvious to a patent examiner, which in practice is rather different.) There's no evidence that this is happening. If patentability is to be extended, it would be prudent to clean up the patent examination procedure before such an extension, rather than afterwards.
* Antitrust law
Anti-trust regimes are not an effective way to stop companies abusing their software patent portfolio. The speed at which the courts work, and the speed at which the software industry works, mean that any possible action would come far too late and take far too long. It is not good to introduce one layer of litigation through software patentability, and then try to fix it with another legal process. Better to allow companies to write software without the threat of legal action hanging over them, and let them respond quickly to market demand without waiting for courts to make decisions.
* Options presented for changing the law
On aims II and III, the report presents three options. I feel that these options are misleading and do not show the whole story.
OPTION 1: The report tries to present the status quo as being that computer programs are patentable, and suggests that the `computer programs as such' exception be removed from the EPC. But this is not maintaining the status quo at all. The EPO has very cleverly managed to reinterpret the law to make an arbitrary and unclear distinction between `computer programs as such' and `computer programs not as such'. This happened very recently in the lifetime of the EPC; if it were really the intention of the EPC's authors, surely it would not take several decades for this new, enlightened interpretation to appear?
Since the EPO's decision was not based on any economic criteria or any research of its effect on the software market, there is no reason to suppose that it represents any improvement on the previous, clear position that computer programs were not patentable.
The criterion of `technical effect', which is supposed to distinguish between software as such and software not as such, does not have any clear meaning. Patents have been granted for purely abstract, mathematical algorithms such as data compression on the basis that this has a technical effect---the effect being that you might use such an algorithm to encode data travelling across a network, for example. But the same could be said of any algorithm to translate data from one format into another, so at a stroke all network protocols and file formats become patentable. Patents have been granted on user interfaces, so we can assume that any software whose purpose is user interaction is not software as such. So already all means of input and output are considered as having a technical effect; and for any other software patent application it is not difficult for a computer programmer to think up a possible technical effect which gets round the `software as such' exclusion. For example, the EPC rejected a patent application for a homophone checker on the grounds that it did not have a technical effect---but conceivably one could use such a program to get more efficient data compression, thus putting it into the ever-expanding category of software not as such.
I'm sure you have seen the software patent `horror gallery' listing very broad patents granted by the EPO on setting prices in a Website (WO9615505), dynamically generating web pages from a database (EP0747840), printing ingredients required for a recipe (WO9529453) and many others. Apart from the serious implications for competition, these should be sufficient proof that the notion `technical effect' is in practice just used as an excuse to grant patents on as wide a range of programs as possible.
It's hard to imagine the EPC ever ruling that something previously considered a technical effect is no longer to be counted as one---the border between patentable software and excluded software would move in one direction only. For these reasons, there is no real difference between Option 1 and Option 2.
But there is an option left out:
OPTION 0: Uphold the status quo as clearly defined by the EPC, making it clear that computer programs are not patentable, just as methods for playing games and methods for doing business are not patentable. This would not stifle competition and innovation in the software market; it would not expose small developers to legal threats; it would mean that companies can get on with writing software and not fighting court battles.
I urge you to consider this option too, and to recognize that the EPO's fig-leaf of `technical effect' has no real meaning when applied to software.
SECTION II
Since I am not a lawyer, I will not write much on Section II, but I would like to say a few things about lawmaking:
Firstly there is the obvious point that there is a fundamental difference between a physical invention or process, and something which is purely information such as a picture or computer program. Making a clear, legally enforceable distinction between the two has already been managed by copyright law, so there is no reason why patent law cannot do the same.
But more importantly, the patent system exists only to serve economic interests. Any decision on what is patentable should be made on economic grounds and not by trying to carry across decisions made for a different area.
So removing exemption of computer programs on the grounds of `technical effect' alone is not sensible, because having a technical effect and being economically justified are two unrelated criteria. What is worthwhile for other industries may not be worthwhile for software, and vice versa.
Finally, on the question of whether software is `technology', I would like to point out that while marketing departments often refer to software as `technology', you will not usually hear a programmer use this term.
SECTION III
Section III has a mixture of pro- and anti-swpat viewpoints. But those which favour software patents, or at least suggest that the anticompetitive effects they cause would not be too great, tend to be founded on the assumption that `the system works properly'. So large numbers of bad patents are not being issued, companies cross-license on reasonable terms, antitrust laws work swiftly and effectively, and so on. But this idealized software patent world is not real. The software patents being granted by the EPO are frequently of very poor quality, just as bad as those in the US if not worse. And it only takes a single firm to start aggressively enforcing its software patents to cause serious trouble to every other firm which is not big enough to have its own defensive portfolio.
The claim that `the existence of a patent system... discourages business secrecy' may be true in other areas, but not for software. Many companies cannot disclose their source code, even if customers want it, for fear that this would allow others to trawl through it for possible infringements. On the other hand, the typical software patent will not disclose anything of value; either it is too broad and vague to give any details, or contains ideas which would occur to many programmers thinking about the same problem. (There are some software patents which contain descriptions of new algorithms, but in these cases the algorithm would have been disclosed anyway without a patent, if it is to become any sort of useful standard.) So software patents actually encourage business secrecy and discourage disclosure.
GENERAL COMMENTS ON SOFTWARE PATENTABILITY
The hard work of software development is usually not in thinking up an idea but in implementing that idea. This is particularly true given the obviousness of many of the ideas that the USPTO and EPO consider patentable, in some cases simply because they involve a computer. It is not like (for example) the drug industry where many years and lots of money must be expended to generate new patents. Rather, thinking up new ways to solve a problem is what a computer programmer does every day, and the same idea will almost certainly have occurred to many programmers in the past. The expense comes in implementing and testing code based on that idea.
The work of implementation is already protected by copyright, which provides a good balance between incentives for development and a competitive marketplace. Software patents tip that balance too far towards monopoly, and in any case it's unlikely that the first company to file a patent actually `invented' the idea.
But even if, in theory, it were possible for the patent office to examine all the millions of lines of program code currently in use and grant patents only on genuinely new algorithms, the price would still be too great. The software market is unlike most others in its strong requirement for compatibility; competing products need to read each others' file formats, for example. A patent on a file format, or on an algorithm used to encode that format, allows one company to block all competing products that might perform the same function as its own.
Developers are expected to check every line of their code against thousands of existing patents. Consider that the USPTO has allowed the same algorithm (LZW compression) to be patented twice, by Unisys and by IBM. If even the patent office cannot check an application against previous patents, what hope is there for the developer checking a 500,000 line program? Copyright, on the other hand, does not have this problem; you have legal certainty that if you have not copied anyone else's work, you are not infringing. Copyright works well for computer software; patents do not.
In short, the possibility of infringing on thousands of software patents is a serious burden for small companies, and patents on file formats (or on business methods, which could effectively be granted if the business method involves a computer) affect even large companies. The result is reduced choice in the market and less software available to the consumer. And patents on file formats mean total monopoly with no possibility of competing, compatible programs being written.
The fact that American firms are stuck in this mess is not a reason to inflict it on European companies. I urge you to recommend that the existing wording of the EPC be upheld, so that computer programs (along with methods for playing games, doing business, and so on) are made explicitly not patentable.
Also, any change to the EPC which allows the EPO to decide for itself on changes to the rules would be very unwise. The patent office is not equipped to make a proper economic analysis of changes to the system. Past experience has shown that the EPO would move the frontier of patentability in one direction only.
VRAM can be read and written at the same time - at least on the video card. And it should be possible to use the video hardware to blit around chunks of memory very quickly. I wonder if there are any algorithms (apart from those to manipulate a bitmapped display) which could be specially coded to take advantage of this hardware?
No, he (or she) is working a 13-hour day, which means five hours nitpicking spelling on Slashdot and elsewhere in order to keep programming down to eight hours.
So how long until we get real PCs (as in AT386 clone) in a palmtop form factor? Wouldn't that deal with the question of software availability at a stroke? Or maybe such devices already exist and they failed miserably.
BTW, the Ipaq uses the same (StrongARM) processor family as the Newton, doesn't it? Unless the Newton has some weird hardware support, it should be possible to port the Newton OS to the Ipaq.
Slashdot Mirror
Google could avoid this if they switched to HTTPS instead of HTTP. But that might require a lot of extra computing power to do all the encryption and decryption. I wonder how much it would cost, in fact?
It would be great if Google phased out HTTP in favour of HTTPS, to help their Chinese users, and all the other big sites followed suit - but I don't think it's going to happen any time soon.
I dunno, the propaganda for GTK-- seems to say that it is a better fit for C++ than Qt, since Qt is old and crusty and 1993-era C++ rather than nice and clean and STL, standard-library-based. So I don't think the KDE / GNOME choice is as simple as C++ / C.
The Qt licensing costs aren't a big amount but I think the point is there's only a single supplier. This is generally considered a Bad Thing, even if in the short term the fees they are currently charging (to get people 'hooked') are affordable.
Surely it's best to change the bug-reporter to send bugs to RedHat and not KDE, since RH are distributing a modified version. There would be many more complaints if the KDE team started getting deluged by bugs which were actually caused by RH's changes... better to have Red Hat, as the 'vendor', take the effort to work out which are problems with their distribution and which bugs in KDE.
There are good political reasons to choose GNOME. (I don't know why when people say 'politics' it is assumed to be a synonym for 'bad'.) Namely, proprietary software vendors can produce GNOME versions of their apps without any trouble; but you have to pay Troll Tech if you want to produce proprietary software for KDE.
Free software zealots won't care one way or the other - indeed they might even prefer the GPL'd Qt rather than Lesser-GPL'd GNOME libraries - but businesses are perhaps more likely to choose GNOME if they decide which desktop to develop for.
I'm glad to hear that KDE and GNOME are unifiable. But will it be the least upper bound or the greatest lower bound of the two?
About half of the TNG episodes are drivel as you describe (I just watched the 'Riker clipshow' and became increasingly disgusted as it became apparent nothing was actually going to happen - also a bit sorry for Riker because his adventures are much duller than Picard's) but there are enough good ones to keep watching. With DS9 or Voyager however the proportion of good episodes is less than half, which is why I stopped watching them a couple of years back. (And Enterprise seems to suck too.)
Don't all the Bond movies essentially have about three or four plots? What about Police Academy? Indeed, is there any series of movies that *doesn't* have the same few plots repeated again and again?
Certain newspapers always ask, 'how many of these would equal the height of a double-decker bus?'.
Why do we have to use dots per inch at all? Why not just measure resolution in micrometres (as is done for integrated circuit manufacturing, for example)? So a '75dpi' screen is about 340 micrometres resolution. Professional printing might use a resolution of 21 micrometres. And so on.
(Yeah I know dots per inch is the established standard and it's not going to go away any time soon. But I still think metric is the way to go. Alternatively you could measure dots per millimetre - but something measured in 'per unit of length' is a more complex measurement than just a unit of length. Still, often there's the feeling that higher is better (eg CPU speeds are measured in Hz, not cycle time) so maybe dots per millimetre is it.)
I believe there is an OpenGL library which uses wireframe graphics, so you can run Quake (even Quake 3) on modest hardware. Anyone know where it lives?
My 2d: write either 'spelling checker' or 'spellchecker'.
It would be good if Linux distributions did things like having a single system-wide speller - unfortunately that means changes to applications, and distros tend to get flamed by weenies if they ship 'non-standard' versions of packages. More importantly, there just isn't the time for the packagers to modify all the apps to behave nicely. Distributions like Lycoris where there is just *one* mail client, web browser, drawing program etc etc are closer to achieving this.
FWIW, it would be okay if MS Office included a spellchecker that _replaced_ the system standard one (optionally, but if it really was better then you'd say 'yes'). Then you'd have both consistency and the improved features. Office sounds like it is doing things the Windows way where each app has to drag a kitchen sink with it, rather than implement a service centrally.
If MS Office's source code were available then Apple would be able to modify it to use the system spellchecker. That's a new argument for source disclosure as far as I'm aware: it helps enforce consistency among applications.
(My personal favourite example: why do web browsers have disk caches? Why not install a single proxy server package, not necessarily a big one like Squid but something small and serving the local machine, and then have the browsers connect to that?)
At some point it might be cheaper to give up on computers and just pilot the Shuttle by hand.
Apple's guidelines are the direct opponent of all those developers for Mozilla, Java, StarOffice, and so on who go to a lot of trouble to make sure their app looks the same on all platforms. Even reimplementing a whole widget set from scratch, in the three examples above. Now, which philosophy do users prefer - make it consistent with the rest of the platform, or make it consistent with the same app on other systems?
Can someone explain the objection to using Python for the configuration system? Surely the kernel developers don't believe that C is the be-all-and-end-all of languages. If it's quicker and more maintainable to write in a high-level language then why not just do the job - and use the time you saved compared to writing in C for other things? It's not as if Python is something wacky or proprietary or a resource hog.
Yeah, an owari-playing program I wrote did that. It would announce the best score available to it, computed from the lookahead tree, and when the game was winnable within the lookahead range this score would be '+24' (the highest possible). Unfortunately during the tournament such a pronouncement wasn't accepted as proof of winning, we had to wait for the game to play through to the end :-(.
I could have programmed it to 'resign' when the game was unwinnable, but if your opponent is not using the perfect strategy then you could keep playing and hope he makes a mistake. In fact the best strategy here is probably to draw the game out for as long as possible.
If you count 'your opponent might make a mistake' as an element of chance, then _every_ game has an element of chance and so the phrase doesn't really mean anything.
When people talk of games with chance involved they mean those where the rules have some kind of randomness, like dice. This makes sense if you realize that by 'the game of chess' it is meant 'the rules of the game of chess'. If the rules do not contain randomness, then 'the game' does not involve chance.
Of course any particular game of chess you play has an element of luck, since your opponent might get struck by lightning causing a draw, for example.
The game of awari (owari) was an end-of-first-term programming project at my university. Because there are at most six moves possible at any point, and usually fewer than that, the game works well with a minimax tree-searching strategy. On a Celeron 400, allowing about 30 seconds for each move, I got a lookahead depth of 9 moves, increased to 18 moves after adding alpha-beta pruning. I don't know how this compares to the best human players but it was certainly enough to beat me into the ground :-).
:-).
:-P.
I did wonder about cranking up the lookahead depth to try and solve the game - after all, most games the program played it won within 25 moves or so - but each extra level of lookahead roughly triples the run time. After seeing the hardware used by these two chaps it seems that the problem was a bit bigger than I thought. I had considered using a Postgres database to store the lookup of the best move at each stage - lucky I didn't, it would have been completely slaughtered
The owari-playing program is at http://membled.com/work/owari/owari.c if anyone is interested - that directory also contains a Perl front-end which caches the computed best moves. I used that to automatically build up a database of 'openings' computed to a slightly higher lookahead level. I was planning to package up the program and release it, perhaps moving the minimax code into a library. But now the game of owari has been solved, I guess there isn't much point any more
BTW you can easily un-solve it just by playing with fourteen bowls and twenty-eight stones - it would take them several times longer to find the solution to that.
I wonder if all possible (symmetric) owari games are draws when played with the best strategy?
What's the CPU speed like? How long does it take to compile a kernel on an Xbox?
I found a problem with the BusLogic driver he maintained. He was very helpful and suggested a fix. I said thanks, I'll try it and get back to you sometime. Now I never will.
I think you should make the case based on economic welfare, since arguments based on freedom or fairness are not considered legitimate by some (and will help opponents to characterize you as extremists, idealists, etc - in fact it is the everything-should-be-patentable campaigners who are taking the ideological position).
... is hardly a significant barrier to software developers.'. This is
... discourages
I wrote to the European Commission when they asked for comments on their (rather biased) study of software patentability; I have pasted in these comments below.
Comments on the study 'The Economic Impact of Patentability of
Computer Programs'
Ed Avis, ed@membled.com
These are comments I would like to submit to the Commission about its
study on software patentability. The order of the comments follows
the order in which the study is presented, which means that comments
on the study's conclusions come first.
At the end are some more general comments on whether it is useful to
grant patents on computer programs.
SECTION I
* Open source development
I feel that the authors of the report have misunderstood the position
of open source developers summed up in the quotation from one open
source developer. This developer points out that while the platform
itself is open, individuals are free to create proprietary products
based on that platform. This is usually true. and it is what
copyright achieves. But I know that most open source developers would
not support the idea that a particular use of their platform could be
patented by one company which then prevents others from making their
own implementation---in effect making the platform itself proprietary,
since it no longer provides an open base for competing developers to
build on.
The anonymous developer comments: `The goal of open source is to make
sure that IP rights or other proprietary rights do not interfere with
that platform'. This is the case for copyright on software, but
software patents often do interfere with a previously open platform
and limit choice. This is particularly true given the broadness and
triviality of many software patents currently being granted.
Actually, I feel that the emphasis given to open source developers is
misleading. Certainly the individual developer is vulnerable to
software patents, but then so are all development groups not big
enough to fight back. It just happens that unpaid open source
developers are at one end of the scale. (They are also more
vulnerable because they cannot keep their development secret, a point
I'll mention again later.)
* Software patents necessary for American SMEs
Commenting on the situation in the United States, the authors write:
`On the one hand there is abounding evidence that the profitability
and growth of independent and SME software developers in the States
has often been to a significant extent dependent on possession of
patent rights'.
It should be clear that this does not imply that the existence of
software patents helps small and medium-sized developers to grow. It
could just as well be true that the legal climate is such that a small
company without sufficient patents to use defensively is vulnerable to
attacks from large patent-holding corporations, and thus it is
necessary for small companies to acquire patents if they are to
attract investment and grow. In fact I believe that this is the case.
The fact that, in the present US legal climate, it is necessary for
small firms to hire patent lawyers and start acquiring patents does
not mean that small firms in Europe would be helped by the
introduction of a similar system. It might just be a burden they
would rather do without.
Also remember that a fast-growing, highly profitable company which
holds many patents does not necessarily indicate a healthy
marketplace. It could be that this company is doing well through
blocking competitors from entering the market and through demanding
licence money from other firms. Such behaviour does not usually help
consumers, who would prefer an open and competitive market. It might
be better to have several companies, not quite as fast-growing or as
profitable, who are competing freely and growing the total size of
this market segment faster than a single monopolistic firm.
It is jumping to conclusions to say, as the report does, that
patentability of computer programs has helped the growth of SMEs in
the US. All one can conclude is that in a market where your
competitors are filing for patents, you need to do the same yourself
if you expect to grow.
* Do software patents help small companies?
The authors claim that lack of software patents in the early days of
the computer industry made it easier for large companies to copy the
ideas of smaller developers. But is there any evidence that
widespread software patentability has stopped this trend? A small
developer holding one or two patents on a key idea will not stand a
chance in a legal battle with a large developer holding thousands of
patents, many of them vague or extremely broad but nonetheless
granted. Software patents certainly do not level the playing field in
favour of the small developer---except perhaps for the company which
does no development work itself (thus not infringing on anyone else's
patents) but distorts the market by accumulating patents on whole
classes of computer programs.
(There is also the implicit assumption that it's a bad thing for other
companies to market their own products based on a particular idea.
But in order for competition in software to exist at all, this must be
allowed. The advantage of being first to market is particularly great
in the software industry, there's no reason to create extra barriers
to entry for those who are trying to bring competing products to
market.)
* Invalid patents
The report acknowledges that many software patents granted in the US
are invalid, but doesn't consider this important: `Their existence
to seriously underestimate the problem.
Even an infringement suit for an invalid patent requires hiring a
patent lawyer and a trip to court. Even if you win, the process can
be cripplingly expensive for a small software developer, impossible
for an individual or start-up. (This is true even under a loser-pays
system, since it can never be absolutely certain who will win.)
Multiply that by the sheer number of vague, possibly invalid patents
held by many large companies, each one of them the subject of
infringement proceedings, and you will see that invalid patents are
just as much a problem as valid ones.
The overheads of software development are much lower than those in
most industries where patents are used; so the costs of fighting
patent lawsuits are proportionally much higher. Any patents, invalid
or otherwise, represent a real risk for the small software developer.
Large companies can usually countersue with their own collection of
patents and reach a cross-licensing agreement, so invalid patents
aren't so much a problem for them.
* Current quality of software patents
The report concludes that we need to make sure European patent offices
(national and EPO) do not fall into the same trap as the USA, to make
sure they do not grant `obvious' patents. (It's not clear whether
this means obvious to a software developer, or obvious to a patent
examiner, which in practice is rather different.) There's no evidence
that this is happening. If patentability is to be extended, it would
be prudent to clean up the patent examination procedure before such an
extension, rather than afterwards.
* Antitrust law
Anti-trust regimes are not an effective way to stop companies abusing
their software patent portfolio. The speed at which the courts work,
and the speed at which the software industry works, mean that any
possible action would come far too late and take far too long. It is
not good to introduce one layer of litigation through software
patentability, and then try to fix it with another legal process.
Better to allow companies to write software without the threat of
legal action hanging over them, and let them respond quickly to market
demand without waiting for courts to make decisions.
* Options presented for changing the law
On aims II and III, the report presents three options. I feel that
these options are misleading and do not show the whole story.
OPTION 1: The report tries to present the status quo as being that
computer programs are patentable, and suggests that the `computer
programs as such' exception be removed from the EPC. But this is not
maintaining the status quo at all. The EPO has very cleverly managed
to reinterpret the law to make an arbitrary and unclear distinction
between `computer programs as such' and `computer programs not as
such'. This happened very recently in the lifetime of the EPC; if it
were really the intention of the EPC's authors, surely it would not
take several decades for this new, enlightened interpretation to
appear?
Since the EPO's decision was not based on any economic criteria or any
research of its effect on the software market, there is no reason to
suppose that it represents any improvement on the previous, clear
position that computer programs were not patentable.
The criterion of `technical effect', which is supposed to distinguish
between software as such and software not as such, does not have any
clear meaning. Patents have been granted for purely abstract,
mathematical algorithms such as data compression on the basis that
this has a technical effect---the effect being that you might use such
an algorithm to encode data travelling across a network, for example.
But the same could be said of any algorithm to translate data from one
format into another, so at a stroke all network protocols and file
formats become patentable. Patents have been granted on user
interfaces, so we can assume that any software whose purpose is user
interaction is not software as such. So already all means of input
and output are considered as having a technical effect; and for any
other software patent application it is not difficult for a computer
programmer to think up a possible technical effect which gets round
the `software as such' exclusion. For example, the EPC rejected a
patent application for a homophone checker on the grounds that it did
not have a technical effect---but conceivably one could use such a
program to get more efficient data compression, thus putting it into
the ever-expanding category of software not as such.
I'm sure you have seen the software patent `horror gallery' listing
very broad patents granted by the EPO on setting prices in a Website
(WO9615505), dynamically generating web pages from a database
(EP0747840), printing ingredients required for a recipe (WO9529453)
and many others. Apart from the serious implications for competition,
these should be sufficient proof that the notion `technical effect' is
in practice just used as an excuse to grant patents on as wide a range
of programs as possible.
It's hard to imagine the EPC ever ruling that something previously
considered a technical effect is no longer to be counted as one---the
border between patentable software and excluded software would move in
one direction only. For these reasons, there is no real difference
between Option 1 and Option 2.
But there is an option left out:
OPTION 0: Uphold the status quo as clearly defined by the EPC, making
it clear that computer programs are not patentable, just as methods
for playing games and methods for doing business are not patentable.
This would not stifle competition and innovation in the software
market; it would not expose small developers to legal threats; it
would mean that companies can get on with writing software and not
fighting court battles.
I urge you to consider this option too, and to recognize that the
EPO's fig-leaf of `technical effect' has no real meaning when applied
to software.
SECTION II
Since I am not a lawyer, I will not write much on Section II, but I
would like to say a few things about lawmaking:
Firstly there is the obvious point that there is a fundamental
difference between a physical invention or process, and something
which is purely information such as a picture or computer program.
Making a clear, legally enforceable distinction between the two has
already been managed by copyright law, so there is no reason why
patent law cannot do the same.
But more importantly, the patent system exists only to serve economic
interests. Any decision on what is patentable should be made on
economic grounds and not by trying to carry across decisions made for
a different area.
So removing exemption of computer programs on the grounds of
`technical effect' alone is not sensible, because having a technical
effect and being economically justified are two unrelated criteria.
What is worthwhile for other industries may not be worthwhile for
software, and vice versa.
Finally, on the question of whether software is `technology', I would
like to point out that while marketing departments often refer to
software as `technology', you will not usually hear a programmer use
this term.
SECTION III
Section III has a mixture of pro- and anti-swpat viewpoints. But
those which favour software patents, or at least suggest that the
anticompetitive effects they cause would not be too great, tend to be
founded on the assumption that `the system works properly'. So large
numbers of bad patents are not being issued, companies cross-license
on reasonable terms, antitrust laws work swiftly and effectively, and
so on. But this idealized software patent world is not real. The
software patents being granted by the EPO are frequently of very poor
quality, just as bad as those in the US if not worse. And it only
takes a single firm to start aggressively enforcing its software
patents to cause serious trouble to every other firm which is not big
enough to have its own defensive portfolio.
The claim that `the existence of a patent system
business secrecy' may be true in other areas, but not for software.
Many companies cannot disclose their source code, even if customers
want it, for fear that this would allow others to trawl through it for
possible infringements. On the other hand, the typical software
patent will not disclose anything of value; either it is too broad and
vague to give any details, or contains ideas which would occur to many
programmers thinking about the same problem. (There are some software
patents which contain descriptions of new algorithms, but in these
cases the algorithm would have been disclosed anyway without a patent,
if it is to become any sort of useful standard.) So software patents
actually encourage business secrecy and discourage disclosure.
GENERAL COMMENTS ON SOFTWARE PATENTABILITY
The hard work of software development is usually not in thinking up an
idea but in implementing that idea. This is particularly true given
the obviousness of many of the ideas that the USPTO and EPO consider
patentable, in some cases simply because they involve a computer. It
is not like (for example) the drug industry where many years and lots
of money must be expended to generate new patents. Rather, thinking
up new ways to solve a problem is what a computer programmer does
every day, and the same idea will almost certainly have occurred to
many programmers in the past. The expense comes in implementing and
testing code based on that idea.
The work of implementation is already protected by copyright, which
provides a good balance between incentives for development and a
competitive marketplace. Software patents tip that balance too far
towards monopoly, and in any case it's unlikely that the first company
to file a patent actually `invented' the idea.
But even if, in theory, it were possible for the patent office to
examine all the millions of lines of program code currently in use and
grant patents only on genuinely new algorithms, the price would still
be too great. The software market is unlike most others in its strong
requirement for compatibility; competing products need to read each
others' file formats, for example. A patent on a file format, or on
an algorithm used to encode that format, allows one company to block
all competing products that might perform the same function as its
own.
Developers are expected to check every line of their code against
thousands of existing patents. Consider that the USPTO has allowed
the same algorithm (LZW compression) to be patented twice, by Unisys
and by IBM. If even the patent office cannot check an application
against previous patents, what hope is there for the developer
checking a 500,000 line program? Copyright, on the other hand, does
not have this problem; you have legal certainty that if you have not
copied anyone else's work, you are not infringing. Copyright works
well for computer software; patents do not.
In short, the possibility of infringing on thousands of software
patents is a serious burden for small companies, and patents on file
formats (or on business methods, which could effectively be granted if
the business method involves a computer) affect even large companies.
The result is reduced choice in the market and less software available
to the consumer. And patents on file formats mean total monopoly with
no possibility of competing, compatible programs being written.
The fact that American firms are stuck in this mess is not a reason to
inflict it on European companies. I urge you to recommend that the
existing wording of the EPC be upheld, so that computer programs
(along with methods for playing games, doing business, and so on) are
made explicitly not patentable.
Also, any change to the EPC which allows the EPO to decide for itself
on changes to the rules would be very unwise. The patent office is
not equipped to make a proper economic analysis of changes to the
system. Past experience has shown that the EPO would move the
frontier of patentability in one direction only.
So you're telling me that a card with '64Mbyte VRAM' doesn't actually have VRAM? I'm so disillusioned :-(.
VRAM can be read and written at the same time - at least on the video card. And it should be possible to use the video hardware to blit around chunks of memory very quickly. I wonder if there are any algorithms (apart from those to manipulate a bitmapped display) which could be specially coded to take advantage of this hardware?
No, he (or she) is working a 13-hour day, which means five hours nitpicking spelling on Slashdot and elsewhere in order to keep programming down to eight hours.
So how long until we get real PCs (as in AT386 clone) in a palmtop form factor? Wouldn't that deal with the question of software availability at a stroke? Or maybe such devices already exist and they failed miserably.
BTW, the Ipaq uses the same (StrongARM) processor family as the Newton, doesn't it? Unless the Newton has some weird hardware support, it should be possible to port the Newton OS to the Ipaq.