He doesn't have a lack of alternatives BECAUSE of Microsoft. There's simply not
enough money in it to do the work. Microsoft knows that their software works best
when everyone can exchange data across a common platform (especially theirs),
so it was in their best intrest to locallize the code.
This has nothing to do with monopoly. It's simply market economics.
Monopolies are "simply market economics". The fact that there exist market conditions that create a very high barrier to entry and that effectively exclude other players means that Microsoft has a monopoly.
From an economic point of view, it makes no difference whether Microsoft actively pursued that market position or just accidentally fell into it. That difference is only interesting from a US legal point of view, and even in the US, even if a monopoly position wasn't pursued deliberately, the company or industry in question can still be subjected to government regulation. Their intent and actions merely have to do whether they are legally guilty of wrongdoing.
Of course, in the Microsoft case, I'd argue that they are somewhere in between: their disregard for standards processes, industry standards, and documentation turned out to not only cut their costs but also keep others out of their market. So, I think they are actually responsible for their position. Initially, their actions may not have been deliberate, but I think their later company internal communications show that they actively pursued this strategy as a business strategy (they merely thought that there wasn't anything wrong with it).
There are no format incompatibilities between Word 2000 and previous versions - If I save a file in Word2000 and give it to a Word97 user, they can read it just fine. The compatibility matrix is on their site.
If you look at the compatibility matrix, you'll find that it's mainly 2000 and 97 that they claim interoperate. But even if they actually interoperate, given Microsoft's history, most buyers I have talked to don't seem to assume that they have to upgrade to 2000 anyway in order to be able to read other people's files.
But row level locking in a $99 dbms is hard to beat.
Sure, it's easy to beat: with a free database. There are several of them, and they work and scale a lot better than Access.
Again, this is a microcontroller, and NOT a general purpose "microprocessor."
It's an ARM chip that Intel is positioning for "compute intensive" applications, "low power consumption", "rich media", and "handhelds".
More importantly, the context of this posting is that someone booted Linux on it and that people built PDAs based on this processor, so it's not just being used as an I/O controller for RAIDs.
Besides, I was under the impression most handwriting
recognition was image processing anyway, which is usually integer based.
Handwriting and speech recognition involve lots of statistical modeling, which is floating point based. You can convert those algorithms to fixed point, but that's a lot of work, since you need to make sure that you scale everything correctly.
32-bit interpolated interger math is much faster than
single-precision floating-point -- important for things like real-time speech recognition.
I suggest you do some actual benchmarks on real processors. On a few processors, what you say is true. On most modern processors, you actually often get faster performance if you implement using FP because integer arithmetic (for loops and indexes) and FP arithmetic can happen in parallel.
I/O processors isn't all Intel is positioning this for. They are also talking about using it as a low-power chip for handhelds.
And if you read Intel's sales pitch, they are talking about applications far beyond traditional I/O processing. Traditional I/O processing requires a little bit of bit pattern matching, maybe some error correction, some compression, a few traditional data structures, and copying lots of data around fast.
For this chip, Intel is talking about "extremely complex applications", "processor intensive calculations", "rich content", and all that. And even in the domain of fairly traditional I/O, statistical and other numerical techniques become increasingly important: you need to predict traffic patterns, calculate optimal routes, predict resource utilization, model statistical distributions, etc. Coding and compression algorithms for media are also usually much more easily formulated with floating point.
The gum-drop style won't age well and Apple will have to go for another look pretty soon. Let's just keep this in mind for the time when Apple will change the look of their OS again, to something less silly; surely, they will end up close to some look on themes.org, and if they claim protection on their look, surely the authors of those other looks can claim protection as well.
I think that rigidly enforcing speed limits is good. The current situation in the US is disturbing. The speed limits are set ridiculously low, in part as a legacy of the oil crisis, and in part under the assumption that people will be going faster anyway. If you keep to them, you will be an obstacle to traffic in many places and may even get a ticket. If you break them, you are at constant risk of being pulled over.
If speed limits were enforced rigidly, people would finally get up the political will to set them where they actually want them to be set. Maybe then we can travel at reasonable speeds without breaking the law.
Putting a GPS receiver and limiter into each car seems like a pretty expensive and heavy-handed approach. I think it would be better to have automated traffic cameras for enforcement. In addition, to help drivers comply, we should come up with a system of local transmitters (cheap, small, solar-powered boxes) that send information about local speed limits (and other local traffic information) to cars to be used as the cars and drivers see fit.
So basically I guess what I'm trying to say is C and C++ are just fine, if not
much better, for programming secure software than other programming languages.
That's what you are saying, but I still think you are completely wrong. I hope you would agree that it would be crazy to design a car in such a way that the malfunction of the radio can easily make the whole car explode. But that's the way C/C++ work: bugs anywhere in a C/C++ program can have completely unpredictable, non-local, and unbounded consequences. There is no way in C/C++ to contain faults. Buffer overflow exploits are only one of many problems resulting from this language design problem.
Second, are you seriously suggesting that we trust our computer security,
privacy and even lives to something as hideous as Java? Or another one of the
"new and improvised" programming languages that seems to allow script kiddies
whole new ways of breaking your system?
Most languages, historically, have had excellent support for safety; C and C++ are the aberrations.
As for Java-the-language, I don't see anything particularly wrong with it. It's a very simple OO language. It's 30 year old technology. It's a conservative design. The JVM is pushing the limits, but you don't have to implement Java on a JVM. If Java is not to your taste, Modula-3 is more powerful and just as safe.
I fully agree: it's a question of resources and tradeoffs. With enough resources spent on design, testing, and code-review, you can make asm and C programs very safe and secure. But the empirical fact is that most real-world software is not constructed that way.
While no programming language guarantees safety, a language with less disregard for safety than C/C++ appears to be able to substantially lower the cost and effort involved in producing software that is as safe and secure as equivalent C software that took a lot more time and money to produce.
You are completely right: using a safer programming language than C or C++ doesn't guarantee safety. But it's false to infer therefore that using a safer programming language doesn't help. Electrical fuses, safety belts, and air traffic control don't guarantee safety, but they guard against common problems. Furthermore, if you don't have to worry about string buffer overflows all the time, you have more time to worry about the other problems.
Have you actually looked under the STL covers? STL makes virtually no guarantees about runtime safety. If you make mistakes with STL, the runtime behavior is often even more subtle and odd than with raw pointers. Besides, C++ still has lots of other ways of unintentionally producing unsafe code, and introduced quite a few new ones.
The string class in C++ happens to be a little safer than using raw malloc'ed buffers in C, but for that minimal level of safety and convenience, there are also good string libraries for C.
The practical record on runtime safety and freedom from buffer overflows in C++ is also not so good if you look at the various Microsoft products.
In fact, computers "without an operating system" existed long before Raskin or Apple even appeared on the scene.
One of the pioneers in this area was probably Smalltalk, which provided a tightly integrated set of applications and let applications easily share data. Data in Smalltalk is, in a sense, "self-describing", so it can be exchanged easily between different parts of the system. And because Smalltalk is a safe language, errors in one application would usually not kill another application. That made it possible to build fairly large systems of closely interacting parts.
UNIX, of course, came more out of a mainframe tradition. For its applications, it made sense to isolate processes well from one another. And that's why programming languages for UNIX and mainframe systems do not have to be particularly safe (the operating system will prevent the worst disasters from happening), and because they can't easily exchange data, data doesn't have to be self-describing.
Apple copied the look of the Smalltalk interfaces but tried to build them out of what amounts to mainframe languages without even the benefit of mainframe process protection. The result was a system that was quite unreliable, leading eventually to the adoption of memory protection. But I guess some people at Apple, like Raskin, eventually figured out their mistake.
The yearning for a Smalltalk-like system is also expressed by de Icaza and Microsoft, who come up with all sorts of complex COM-like systems.
The fact is that the industry is still in a state of confusion. Many programemrs are too conservative to give up their mainframe style tools, but they still want to build Smalltalk-like dekstop systems. The result of using the wrong tool for the job is desktop software that ends up being both bloated and complex, and still is lacking in integration and extensiblity. This is, sadly, true for MacOS X as much as for Windows, Gnome, and KDE.
I don't even need any sophisticated power management, I'd be happy to be able to suspend or hibernate my desktop when I'm not using it. Windows seems to know how, it has a "sleep" button on the case, but the Linux 2.2 kernel doesn't know how even if I configure it with different power management options.
There is a generic "hibernate" patch for the Linux kernel, but it doesn't seem to have ever made it into the main kernel tree. Too bad.
How many more buffer overflows and compromises of key Internet infrastructure is it going to take to finally convince people that it is irresponsible to write security-critical software in C or C++? Buffer overflows are pretty much the domain of C, C++, and assembly language. Almost all other languages protect against them, at negligible compile-time and runtime cost. Many C/C++ hackers claim and think that they don't need this sort of thing, but the fact that 15 years after the Internet worm, these things still keep cropping up shows otherwise.
The solution to these unnecessary bugs is not to form a closed mailing list to exchange information about the latest silly programming slips, it's to avoid the avoidable in the first place.
And you'd be wrong to think that I just hate C/C++: have used C since '82 and C++ since its first release (around '87?), and continue to use them. C and C++ are great for a variety of applications, and I write C++ code daily. But these languagse are not so great when trying to write software that withstands deliberate attacks and may have every boundary condition identified and exploited by an adversary. Would you drive your car without a safety belt? Raid a compound with armed terrorists without a bullet-proof vest? You may get away with it, but it just isn't prudent. So, why this complete disregard for basic and cheap safety precautions when it comes to security-critical programming?
Bountyquest only pays for prior art upon which the patent claims read completely.
Earlier art which is read on by only some of the elements is ineligible.
Of course they only pay for that kind of information; I didn't say anything to the contrary. BountyQuest tries to find prior art for legal purposes. Slashdot is not a court of law; we discuss policy.
The actual parameters of the patent system are essential to these questions. If you
don't understand them, you are out of the ball game, and will quickly find yourself
marginalized and discounted.
I understand the legal issues just fine. The question underlying discussions on Slashdot, however, is what the policy ought to be and whether current legal practice expresses those policies.
I believe that in this case there is ample prior art that ought to be relevant. Based on what I know, it also appears that such an argument would be difficult to make in court, precisely for the reasons you keep restating.
So, current legal practice is very relevant to the current discussion. The very fact that the definitions of prior art for patent purposes are, as you keep pointing out, so narrow and that they are likely in disagreement with the intuitions of actual practitioners is an indication that the law and legal practice need to change.
Patent law is not divine, it is created by humans for utilitarian purposes. We need to figure out whether it serves those purposes and fix it if it doesn't.
BountyQuest agrees, Werdna agrees, and I agree completely: for legal challenge, that's the strongest evidence you can find. My point is that creating a strong legal argument isn't the purpose of a Slashdot discussion.
I don't understand why people repeatedly bring up this obvious point. Nothing guarantees that a legal challenge is ultimately going to be successful. There are many valid legal challenges that are abandoned and fail even if all the i's are dotted and all the t's are crossed. That doesn't mean you shouldn't talk about it.
The fact remains that one of the best bets for having a patent invalidated is published prior art that is not already cited in the patent. That is exactly the prior art BountyQuest is looking for.
The article you refer to doesn't even make this point. Werdna argues that for prior art to be useful in a legal challenge it needs to be compared point-by-point against the claims. That, too, is missing the point in finding prior art in the first place. You need to identify potential prior art before you can do the point-by-point comparison. In addition to prior art, there are challenges based on "obviousness". They are a lot harder, but they, too, require identifying related work.
But discussions of prior art and practice doesn't just serve specific legal challenges, it also helps us with applying political pressure on the patent system. A system that grants patents on techniques that were published decades ago in textbooks, and that entangles users of such techniques in long legal battles, is broken, and the more examples we can find for that, the better.
Discussions on Slashdot about patent validity are mainly policy discussions by engineers. I view the constant harping on technicalities of specific legal challenges by some people merely as an attempt to sabotage such rational discussions of policy. The lawyers that challenge these patents in court presumably know what they are doing and don't need our advice.
A true enterprise-grade message store will use an embedded database with transactions support. [...]
Messages are stored in a database,
like they should be. The Berkeley DB package from Sleepycat Software (yes, it's open source) is used for robust back-end storage, including transaction and logging support.
Databases are not without problems. Most importantly, they can easily leave you stranded with data in a format you can't read, they guarantee data integrity only under a very limited set of failures and will corrupt your data otherwise, they have their own set of bizarre resource limits, and they require considerably more complex software and maintenance.
It's also a common fallacy to assume that scaling up requires a database. But mailboxes of different users don't interact with one another. If a file-system-based mailbox system works fine for one users, it will work fine for each of 1000 users. In fact, in many cases, a database makes the problem worse, because if messages for different users are stored in the same database, using a database introduces interactions between users that weren't there before.
Both maildir and the standard mailbox format work fine and do scale up. They do have their limitations, problems, and failure modes. But, you know what, so do databases. In practice, in my experience, mailbox-based mailers seem to work more reliably than Exchange, so being an "Exchange-killer" isn't much of an advertisement.
As for mailbox and maildir based mailers, you can avoid almost all problems by turning on message size limits and per-user quotas; even very liberal limits will keep accidents from happening while not interfering with normal mail traffic.
Maybe there is just too much consultant mumbo-jumbo in the XP publications, but the technique sounds old. Develop incrementally, have a small group of smart people working together, test and release frequently, etc.,... those things have been used as the guidelines for projects for at least 20 years, if not longer. I think one might argue that GNU Emacs and other GNU software was developed that way. I don't see anything "extreme" about it, and in fact tools support for this kind of programming used to be much better. However, it doesn't always work: you really do need people on the project that are really smart, love what they are doing, and can work together. Self-selected groups in open source development fit that profile much better than a bunch of people thrown together into a project in a company, under stress from release dates and career paths.
Talking about this stuff in the abstract is meaningless -- its just whining. Let's get to
particulars. Name the patent and the prior art in question, then we can start talking. Until
then, we are all spitting in the wind.
Who is talking in the abstract? I have a good idea about what Archie and Veronica are, as well as what the CMGI patents cover. Mr. Emtage does as well. And so do many other people. If you don't, maybe you should look up this information before accusing others of "spitting in the wind".
For all we know, the patents in question may have already cited, directly or indirectly, to this very prior art. The issue is not whether the patents relate to pre-existing technology -- this is true of virtually EVERY PATENT EVER EVER.
We are discussing technical issues and issues of obviousness here: given that Veronica and Archie existed years before AltaVista, is there actually any innovation in AltaVista's claims? Should AltaVista's patents be valid in an equitable patent system that aims to encourage and reward innovation? And does that suggest possible challenges to AltaVista's patents based on obviousness?
Legal validity is a completely different questions. The legalistic points you make are true and clear to many people involved in the discussion. But they are irrelevant at this point. If you attempt to reduce every discussion of patents and prior art from the start to a point-by-point discussion of legal strategy, you are missing the point. That kind of approach makes a poor lawyer as well as a poor engineer. But, then, you seem to be mainly contributing to this discussion to push a particular agenda, not as either an engineer or a lawyer.
Going through the C# language documentation, it really looks like Java with some of the top items of Sun developer's Java wishlist (signup required) added: call-by-value for classes, syntax for looping over sequences, and a few others. Typical MS style: clone the competitors product and add the most visible gimmicks.
Microsoft makes a big deal out of the universality of their runtime, but it isn't significantly more universal than the JVM. They claim they compile C++ into their runtime, but it isn't C++, it's a "safe subset" (full C++ is compiled into native code and linked in--useful, but not a feature of their runtime). In fact, more than 100 languages have been implemented on top of the JVM, including C; there are also semi-automatic translators for C++.
.NET is about not just C# and the runtime, but also about XML. Of course, that's a big thing with Java as well, with several excellent XML projects in Java, perhaps most notably the Apache efforts.
I wouldn't actually care much about whether Java or C# ultimately "wins" in the market, if it weren't for the fact that C# is years behind and has the wrong motivations behind it. Java is, by now, fairly mature and it has an excellent set of APIs and libraries behind it, both from Sun and from other sources. There are numerous compilers to the JVM for languages like Python and Smalltalk. And there are several third party implementations. Java's implementation isn't particularly tied to any one platform, and it actually runs better on Windows than on Sun's own Solaris. And it will take a C#/.NET implementation at least as long to mature as the JVMs--building these kinds of runtimes is hard and requires a lot of benchmarking and user feedback to get the bugs and performance bottlenecks out.
If Slashdot readers care about open source and open standards, rather than complaining about Microsoft, there is a much more effective thing you can do: support open source Java efforts like Kaffe, Intel's Intel's Open Runtime, GNU GCJ (now part of GCC), and GNU Classpath. By "support" I mean: use them, consider them for your next open source project, submit bug reports, and maybe contribute code. GNU GCJ, in particular, should be a good basis for you to write Linux applications: it compiles to executables that start up quickly, it lets you use native code almost as if it were written in Java, and you can even write native Gtk/Gnome applications in it.
But perhaps most importantly, educate yourself about Java rather than complaining about it; Java is really a pretty decent engineering effort. Give it the benefit of the doubt, and wher it needs improvement, help it along. C/C++ will not make it in the long run. It's Java or C# or something else similar to those languages.
Java isn't slow at all. In fact, in terms of raw execution speed, it's probably one of the fastest object-oriented languages next to C++.
What is slow about Java is its startup. And that's because you are loading a fresh JVM everytime you start up a Java application. If you did the equivalent with C/C++, you'd have to load many megabytes of libraries before you could start any C/C++ program, something that would make things like starting up any GUI app crawl to a halt. If you use Java the way those kinds of environments are supposed to be used, start up a JVM and do all your work inside that, it is very fast. Compilations fly, windows pop up instantaneously, etc.
But since people aren't going to change their work practices overnight, Sun is working on addressing the startup speed by introducing something equivalent to precompiled, shared libraries for C++. That way, you should be able to start up JVMs very quickly.
Incidentally, if your only experience with Java is through Netscape applets in Netscape 4, the JVM that comes with Netscape 4 is outdated and very slow. Furthermore, it takes forever to start up even compared to the unenhanced modern JVMs. Under Galeon or other browsers, applets start up quite quickly already.
(which is sort of to be expected, it attempting to be all things to all people, not an easy task)
Java's language design is very conservative, and it's a lot easier to compile into efficient code than, say, Perl or Python (when Perl or Python beat Java in benchmarks, it's because of highly optimized library code in those languages, not because the languages themselves are compiled well). In fact, because Java's language design is so conservative, it is actually not all that much easier to write Java programs than, say, C++; Python, Perl, and Smalltalk are certainly a lot more convenient. Java's advantage over C++ isn't convenience, it's safety, simplicity, and runtime support.
What is really big and complex in Java is its GUI and "enterprise" libraries, and other languages should be so lucky. Swing is still by far the best designed object-oriented GUI toolkit I have ever used (and I have used quite a few). Java's database libraries are great, and so are its support for persistence and distributed computing.
Microsoft could easily deliver a Java compatible runtime; in fact, they have some kind of relationship with Transvirtual to do just that. They only thing they can't do is call it "Java" or use Sun's source code for doing that. And that's exactly how it should be: trademarks like "Java" are there to assure customers that they know what they are buying. Microsoft's broken "Java" implementations and subsequent damage to the reputation of the Java platform are an excellent example of why trademarks are needed.
Think of the thousands of companies driven out of business by Microsoft over the years. In the office suite area alone, we have VisiCalc, Lotus, WordPerfect, Corel, Borland, and lots of others. You're probably safer developing something commercial targeting the free software world than developing something commercial that competes with Microsoft.
The reality of this market is that, unless you are Microsoft, almost no software product is a long-term money maker. Sooner or later, someone is going to take your market. Either people get stuff "for free" from Microsoft, or they get stuff "for free" from free or open source software efforts (the latter makes a lot more economic sense).
In this mature market, you can't expect to beat Microsoft with a clone of MSOffice and charge for it. If anything is going to beat MSOffice in the market, it will have to be at the very least free, and it probably has to offer some other compelling features as well. Some companies (like Sun and RedHat) still have enough incentive to sponsor those kinds of developments. But Star and Applix were anachronisms, and it is completely unsurprising that they have disappeared.
The problem with MacOS on PC-like hardware is not that it is difficult to do, it's that Apple doesn't want it to happen. So, I don't see how adding another processor vendor to the mix is going to make any difference.
As for advertising 1.5GHz Macs, if Apple/Motorola had wanted to do that, they would have needed to do little more than add a 2x clock divider to the processor (I'm sure they could have found some technical justification).
Slashdot Mirror
Monopolies are "simply market economics". The fact that there exist market conditions that create a very high barrier to entry and that effectively exclude other players means that Microsoft has a monopoly.
From an economic point of view, it makes no difference whether Microsoft actively pursued that market position or just accidentally fell into it. That difference is only interesting from a US legal point of view, and even in the US, even if a monopoly position wasn't pursued deliberately, the company or industry in question can still be subjected to government regulation. Their intent and actions merely have to do whether they are legally guilty of wrongdoing.
Of course, in the Microsoft case, I'd argue that they are somewhere in between: their disregard for standards processes, industry standards, and documentation turned out to not only cut their costs but also keep others out of their market. So, I think they are actually responsible for their position. Initially, their actions may not have been deliberate, but I think their later company internal communications show that they actively pursued this strategy as a business strategy (they merely thought that there wasn't anything wrong with it).
If you look at the compatibility matrix, you'll find that it's mainly 2000 and 97 that they claim interoperate. But even if they actually interoperate, given Microsoft's history, most buyers I have talked to don't seem to assume that they have to upgrade to 2000 anyway in order to be able to read other people's files.
Sure, it's easy to beat: with a free database. There are several of them, and they work and scale a lot better than Access.
It's an ARM chip that Intel is positioning for "compute intensive" applications, "low power consumption", "rich media", and "handhelds".
More importantly, the context of this posting is that someone booted Linux on it and that people built PDAs based on this processor, so it's not just being used as an I/O controller for RAIDs.
Besides, I was under the impression most handwriting recognition was image processing anyway, which is usually integer based.
Handwriting and speech recognition involve lots of statistical modeling, which is floating point based. You can convert those algorithms to fixed point, but that's a lot of work, since you need to make sure that you scale everything correctly.
32-bit interpolated interger math is much faster than single-precision floating-point -- important for things like real-time speech recognition.
I suggest you do some actual benchmarks on real processors. On a few processors, what you say is true. On most modern processors, you actually often get faster performance if you implement using FP because integer arithmetic (for loops and indexes) and FP arithmetic can happen in parallel.
And if you read Intel's sales pitch, they are talking about applications far beyond traditional I/O processing. Traditional I/O processing requires a little bit of bit pattern matching, maybe some error correction, some compression, a few traditional data structures, and copying lots of data around fast.
For this chip, Intel is talking about "extremely complex applications", "processor intensive calculations", "rich content", and all that. And even in the domain of fairly traditional I/O, statistical and other numerical techniques become increasingly important: you need to predict traffic patterns, calculate optimal routes, predict resource utilization, model statistical distributions, etc. Coding and compression algorithms for media are also usually much more easily formulated with floating point.
Until recently, handhelds like the Palm and its WinCE clones didn't need much smarts. That's rapidly changing.
The gum-drop style won't age well and Apple will have to go for another look pretty soon. Let's just keep this in mind for the time when Apple will change the look of their OS again, to something less silly; surely, they will end up close to some look on themes.org, and if they claim protection on their look, surely the authors of those other looks can claim protection as well.
If speed limits were enforced rigidly, people would finally get up the political will to set them where they actually want them to be set. Maybe then we can travel at reasonable speeds without breaking the law.
Putting a GPS receiver and limiter into each car seems like a pretty expensive and heavy-handed approach. I think it would be better to have automated traffic cameras for enforcement. In addition, to help drivers comply, we should come up with a system of local transmitters (cheap, small, solar-powered boxes) that send information about local speed limits (and other local traffic information) to cars to be used as the cars and drivers see fit.
That's what you are saying, but I still think you are completely wrong. I hope you would agree that it would be crazy to design a car in such a way that the malfunction of the radio can easily make the whole car explode. But that's the way C/C++ work: bugs anywhere in a C/C++ program can have completely unpredictable, non-local, and unbounded consequences. There is no way in C/C++ to contain faults. Buffer overflow exploits are only one of many problems resulting from this language design problem.
Second, are you seriously suggesting that we trust our computer security, privacy and even lives to something as hideous as Java? Or another one of the "new and improvised" programming languages that seems to allow script kiddies whole new ways of breaking your system?
Most languages, historically, have had excellent support for safety; C and C++ are the aberrations.
As for Java-the-language, I don't see anything particularly wrong with it. It's a very simple OO language. It's 30 year old technology. It's a conservative design. The JVM is pushing the limits, but you don't have to implement Java on a JVM. If Java is not to your taste, Modula-3 is more powerful and just as safe.
While no programming language guarantees safety, a language with less disregard for safety than C/C++ appears to be able to substantially lower the cost and effort involved in producing software that is as safe and secure as equivalent C software that took a lot more time and money to produce.
You are completely right: using a safer programming language than C or C++ doesn't guarantee safety. But it's false to infer therefore that using a safer programming language doesn't help. Electrical fuses, safety belts, and air traffic control don't guarantee safety, but they guard against common problems. Furthermore, if you don't have to worry about string buffer overflows all the time, you have more time to worry about the other problems.
The string class in C++ happens to be a little safer than using raw malloc'ed buffers in C, but for that minimal level of safety and convenience, there are also good string libraries for C.
The practical record on runtime safety and freedom from buffer overflows in C++ is also not so good if you look at the various Microsoft products.
One of the pioneers in this area was probably Smalltalk, which provided a tightly integrated set of applications and let applications easily share data. Data in Smalltalk is, in a sense, "self-describing", so it can be exchanged easily between different parts of the system. And because Smalltalk is a safe language, errors in one application would usually not kill another application. That made it possible to build fairly large systems of closely interacting parts.
UNIX, of course, came more out of a mainframe tradition. For its applications, it made sense to isolate processes well from one another. And that's why programming languages for UNIX and mainframe systems do not have to be particularly safe (the operating system will prevent the worst disasters from happening), and because they can't easily exchange data, data doesn't have to be self-describing.
Apple copied the look of the Smalltalk interfaces but tried to build them out of what amounts to mainframe languages without even the benefit of mainframe process protection. The result was a system that was quite unreliable, leading eventually to the adoption of memory protection. But I guess some people at Apple, like Raskin, eventually figured out their mistake.
The yearning for a Smalltalk-like system is also expressed by de Icaza and Microsoft, who come up with all sorts of complex COM-like systems.
The fact is that the industry is still in a state of confusion. Many programemrs are too conservative to give up their mainframe style tools, but they still want to build Smalltalk-like dekstop systems. The result of using the wrong tool for the job is desktop software that ends up being both bloated and complex, and still is lacking in integration and extensiblity. This is, sadly, true for MacOS X as much as for Windows, Gnome, and KDE.
There is a generic "hibernate" patch for the Linux kernel, but it doesn't seem to have ever made it into the main kernel tree. Too bad.
The solution to these unnecessary bugs is not to form a closed mailing list to exchange information about the latest silly programming slips, it's to avoid the avoidable in the first place.
And you'd be wrong to think that I just hate C/C++: have used C since '82 and C++ since its first release (around '87?), and continue to use them. C and C++ are great for a variety of applications, and I write C++ code daily. But these languagse are not so great when trying to write software that withstands deliberate attacks and may have every boundary condition identified and exploited by an adversary. Would you drive your car without a safety belt? Raid a compound with armed terrorists without a bullet-proof vest? You may get away with it, but it just isn't prudent. So, why this complete disregard for basic and cheap safety precautions when it comes to security-critical programming?
Of course they only pay for that kind of information; I didn't say anything to the contrary. BountyQuest tries to find prior art for legal purposes. Slashdot is not a court of law; we discuss policy.
The actual parameters of the patent system are essential to these questions. If you don't understand them, you are out of the ball game, and will quickly find yourself marginalized and discounted.
I understand the legal issues just fine. The question underlying discussions on Slashdot, however, is what the policy ought to be and whether current legal practice expresses those policies.
I believe that in this case there is ample prior art that ought to be relevant. Based on what I know, it also appears that such an argument would be difficult to make in court, precisely for the reasons you keep restating.
So, current legal practice is very relevant to the current discussion. The very fact that the definitions of prior art for patent purposes are, as you keep pointing out, so narrow and that they are likely in disagreement with the intuitions of actual practitioners is an indication that the law and legal practice need to change.
Patent law is not divine, it is created by humans for utilitarian purposes. We need to figure out whether it serves those purposes and fix it if it doesn't.
BountyQuest agrees, Werdna agrees, and I agree completely: for legal challenge, that's the strongest evidence you can find. My point is that creating a strong legal argument isn't the purpose of a Slashdot discussion.
The fact remains that one of the best bets for having a patent invalidated is published prior art that is not already cited in the patent. That is exactly the prior art BountyQuest is looking for.
The article you refer to doesn't even make this point. Werdna argues that for prior art to be useful in a legal challenge it needs to be compared point-by-point against the claims. That, too, is missing the point in finding prior art in the first place. You need to identify potential prior art before you can do the point-by-point comparison. In addition to prior art, there are challenges based on "obviousness". They are a lot harder, but they, too, require identifying related work.
But discussions of prior art and practice doesn't just serve specific legal challenges, it also helps us with applying political pressure on the patent system. A system that grants patents on techniques that were published decades ago in textbooks, and that entangles users of such techniques in long legal battles, is broken, and the more examples we can find for that, the better.
Discussions on Slashdot about patent validity are mainly policy discussions by engineers. I view the constant harping on technicalities of specific legal challenges by some people merely as an attempt to sabotage such rational discussions of policy. The lawyers that challenge these patents in court presumably know what they are doing and don't need our advice.
Databases are not without problems. Most importantly, they can easily leave you stranded with data in a format you can't read, they guarantee data integrity only under a very limited set of failures and will corrupt your data otherwise, they have their own set of bizarre resource limits, and they require considerably more complex software and maintenance.
It's also a common fallacy to assume that scaling up requires a database. But mailboxes of different users don't interact with one another. If a file-system-based mailbox system works fine for one users, it will work fine for each of 1000 users. In fact, in many cases, a database makes the problem worse, because if messages for different users are stored in the same database, using a database introduces interactions between users that weren't there before.
Both maildir and the standard mailbox format work fine and do scale up. They do have their limitations, problems, and failure modes. But, you know what, so do databases. In practice, in my experience, mailbox-based mailers seem to work more reliably than Exchange, so being an "Exchange-killer" isn't much of an advertisement.
As for mailbox and maildir based mailers, you can avoid almost all problems by turning on message size limits and per-user quotas; even very liberal limits will keep accidents from happening while not interfering with normal mail traffic.
Maybe there is just too much consultant mumbo-jumbo in the XP publications, but the technique sounds old. Develop incrementally, have a small group of smart people working together, test and release frequently, etc., ... those things have been used as the guidelines for projects for at least 20 years, if not longer. I think one might argue that GNU Emacs and other GNU software was developed that way. I don't see anything "extreme" about it, and in fact tools support for this kind of programming used to be much better. However, it doesn't always work: you really do need people on the project that are really smart, love what they are doing, and can work together. Self-selected groups in open source development fit that profile much better than a bunch of people thrown together into a project in a company, under stress from release dates and career paths.
Who is talking in the abstract? I have a good idea about what Archie and Veronica are, as well as what the CMGI patents cover. Mr. Emtage does as well. And so do many other people. If you don't, maybe you should look up this information before accusing others of "spitting in the wind".
We are discussing technical issues and issues of obviousness here: given that Veronica and Archie existed years before AltaVista, is there actually any innovation in AltaVista's claims? Should AltaVista's patents be valid in an equitable patent system that aims to encourage and reward innovation? And does that suggest possible challenges to AltaVista's patents based on obviousness?
Legal validity is a completely different questions. The legalistic points you make are true and clear to many people involved in the discussion. But they are irrelevant at this point. If you attempt to reduce every discussion of patents and prior art from the start to a point-by-point discussion of legal strategy, you are missing the point. That kind of approach makes a poor lawyer as well as a poor engineer. But, then, you seem to be mainly contributing to this discussion to push a particular agenda, not as either an engineer or a lawyer.
Microsoft makes a big deal out of the universality of their runtime, but it isn't significantly more universal than the JVM. They claim they compile C++ into their runtime, but it isn't C++, it's a "safe subset" (full C++ is compiled into native code and linked in--useful, but not a feature of their runtime). In fact, more than 100 languages have been implemented on top of the JVM, including C; there are also semi-automatic translators for C++.
I wouldn't actually care much about whether Java or C# ultimately "wins" in the market, if it weren't for the fact that C# is years behind and has the wrong motivations behind it. Java is, by now, fairly mature and it has an excellent set of APIs and libraries behind it, both from Sun and from other sources. There are numerous compilers to the JVM for languages like Python and Smalltalk. And there are several third party implementations. Java's implementation isn't particularly tied to any one platform, and it actually runs better on Windows than on Sun's own Solaris. And it will take a C#/.NET implementation at least as long to mature as the JVMs--building these kinds of runtimes is hard and requires a lot of benchmarking and user feedback to get the bugs and performance bottlenecks out.
If Slashdot readers care about open source and open standards, rather than complaining about Microsoft, there is a much more effective thing you can do: support open source Java efforts like Kaffe, Intel's Intel's Open Runtime, GNU GCJ (now part of GCC), and GNU Classpath. By "support" I mean: use them, consider them for your next open source project, submit bug reports, and maybe contribute code. GNU GCJ, in particular, should be a good basis for you to write Linux applications: it compiles to executables that start up quickly, it lets you use native code almost as if it were written in Java, and you can even write native Gtk/Gnome applications in it.
But perhaps most importantly, educate yourself about Java rather than complaining about it; Java is really a pretty decent engineering effort. Give it the benefit of the doubt, and wher it needs improvement, help it along. C/C++ will not make it in the long run. It's Java or C# or something else similar to those languages.
Java isn't slow at all. In fact, in terms of raw execution speed, it's probably one of the fastest object-oriented languages next to C++.
What is slow about Java is its startup. And that's because you are loading a fresh JVM everytime you start up a Java application. If you did the equivalent with C/C++, you'd have to load many megabytes of libraries before you could start any C/C++ program, something that would make things like starting up any GUI app crawl to a halt. If you use Java the way those kinds of environments are supposed to be used, start up a JVM and do all your work inside that, it is very fast. Compilations fly, windows pop up instantaneously, etc.
But since people aren't going to change their work practices overnight, Sun is working on addressing the startup speed by introducing something equivalent to precompiled, shared libraries for C++. That way, you should be able to start up JVMs very quickly.
Incidentally, if your only experience with Java is through Netscape applets in Netscape 4, the JVM that comes with Netscape 4 is outdated and very slow. Furthermore, it takes forever to start up even compared to the unenhanced modern JVMs. Under Galeon or other browsers, applets start up quite quickly already.
Java's language design is very conservative, and it's a lot easier to compile into efficient code than, say, Perl or Python (when Perl or Python beat Java in benchmarks, it's because of highly optimized library code in those languages, not because the languages themselves are compiled well). In fact, because Java's language design is so conservative, it is actually not all that much easier to write Java programs than, say, C++; Python, Perl, and Smalltalk are certainly a lot more convenient. Java's advantage over C++ isn't convenience, it's safety, simplicity, and runtime support.
What is really big and complex in Java is its GUI and "enterprise" libraries, and other languages should be so lucky. Swing is still by far the best designed object-oriented GUI toolkit I have ever used (and I have used quite a few). Java's database libraries are great, and so are its support for persistence and distributed computing.
Microsoft could easily deliver a Java compatible runtime; in fact, they have some kind of relationship with Transvirtual to do just that. They only thing they can't do is call it "Java" or use Sun's source code for doing that. And that's exactly how it should be: trademarks like "Java" are there to assure customers that they know what they are buying. Microsoft's broken "Java" implementations and subsequent damage to the reputation of the Java platform are an excellent example of why trademarks are needed.
The reality of this market is that, unless you are Microsoft, almost no software product is a long-term money maker. Sooner or later, someone is going to take your market. Either people get stuff "for free" from Microsoft, or they get stuff "for free" from free or open source software efforts (the latter makes a lot more economic sense).
In this mature market, you can't expect to beat Microsoft with a clone of MSOffice and charge for it. If anything is going to beat MSOffice in the market, it will have to be at the very least free, and it probably has to offer some other compelling features as well. Some companies (like Sun and RedHat) still have enough incentive to sponsor those kinds of developments. But Star and Applix were anachronisms, and it is completely unsurprising that they have disappeared.
As for advertising 1.5GHz Macs, if Apple/Motorola had wanted to do that, they would have needed to do little more than add a 2x clock divider to the processor (I'm sure they could have found some technical justification).