Personally, I still like 'find / > index' in a cron script, then just grep 'index'...."
Try "man locate" and "man updatedb"; that's been around forever. It probably already gets updated nightly on your computer (that's why your disk starts making all that noise early in the morning).
If you want to search for content, you can combine it with grep and xargs:
provided that it would be easy for the USA to disrupt it.
It's not that simple. If the US turns off its GPS system, the Europeans can moan but they don't really have cause to complain. If the US disrupts Galileo without consent from the Europeans, that would be a grave violation of international law and something that can't be papered over easily. The US may have a button to disrupt Galileo now, but their use of it is quite constrained.
The sad thing is that one even has to contemplate these issues. And the fault for that lies entirely with recent US unilateralism. A nation that wants to be the leader of the free world has responsibilities to listen to the concerns of the free world, but as Bush and other politicians have made crystal clear recently, America always comes first and they will only do what is in America's best interest. That amounts to an abdication of US leadership.
But even if the US were not adopting such hostile policies, US influence would be diminishing over the next several decades anyway: without both massive foreign borrowing and a strong dollar, the US simply cannot sustain its standard of living, let alone its huge military. But the current deficits are not sustainable: the US has to cut back while other nations pull ahead economically, and hence militarily.
With Gallileo on the other hand, good luck getting the ruling body (by the people, for the people) to agree quick enough for it to make a difference.
And how much did the US listen to international input when deciding to invade Iraq? Cooperation goes both ways, and the US government has demonstrated that it will do whatever it pleases, no matter what the international community says. And it's not just Iraq: the US has recently ignored, violated, and abrogated lots of international treaties.
From the perspective of other nations, the US is looking increasingly untrustworthy and unreliable, and that's why they have to start building their own infrastructure.
If you don't like the way decisions are made in Europe, that's tough: Europeans don't like the way decisions are made in the US either, and there are more of them around (ditto for Indians and Chinese).
As a citizen of the US, I absolutely DO NOT want a third party to be able to accurately aim a missile at the White House, the Capitol, or a nuclear power plant.
Nobody wants foreign powers to be able to aim missiles at their cities. But the US can aim and guide missiles where it pleases and is refusing to give up that capability. Therefore, there is no reason why the Europeans shouldn't be able to do the same. In fact, the US government has stated itself that it wants the Europeans to develop their own high-tech military capabilities. That includes their own GPS system, their own missiles, and other technology. And the Europeans aren't just going to pay for high tech weapons and then put them under US control.
This kind of development is inevitable anyway: Europe is becoming stronger and more independent. But the really big change will occur when India and China are starting to develop their own high-tech dual-use technologies, in particular, space technologies, and they are not going to be bound by cultural affiliations with the US.
You better get used to it now because this sort of thing is unavoidable.
If you want to reinvent the wheel to be object-oriented, go for it. But first write a new language in which to do it. C++ has way too many shortcomings to write the foundations of a whole system in.
Actually, we don't need to invent new languages; before the invasion of UNIX, people actually were writing operating systems in better languages than C/C++. However, even C++ is a better than C because it lets programmers standardize and automate things; in my experience, with the right coding guidelines and libraries, programmers produce much better code and have a lot fewer bugs than in equivalent C code.
The reason I prefer procedural languages to object-oriented ones is because computing itself is procedural. Object orientation feels like a hack. It's a weird way I look at it, yes, but it takes me personally a lot more effort to implement something in an object-oriented way than the same functionality in a procedural way, and the procedural way ends up cleaner and more efficient in the end. That's just me.
Those are the same objections dyed-in-the-wool procedural application programmers were raising, and they have had to switch; OS and RT programmers are just getting away with not switching because their fields are somewhat black arts that nobody else wants to bother with. So, one indulges their quirks.
Of course, just about everybody understands that OOP has lots of flaws. It's simply a pragmatic solution to standardizing a bunch of procedural constructs that procedural programmers are using anyway. BSD and Linux both have lots of OOP constructs in them, they are simply not made explicit or standardized.
In any case, OOP is only one aspect. A more important one is to use languages with better type systems, resource management, and error checking than C. Even Bell Labs has started using something other than C in Plan9.
Hey, I wouldn't mind seeing a whole revolution in software design for FOSS systems, but the fact of the matter is that it would break a lot of familiarity and compatibility, and if it isn't good in the end (which is very possible) it will have all been for nothing. Not changing anything for decades is a good thing in this respect - there's no way to go 'wrong'.
But user-level software on UNIX has never been exclusively C: a large part of it has always been in HLL, starting with languages like awk. Over the last decade, more and more has been written in languages like C++, Perl, Python, Ruby, and Java. It's just that the kernel hasn't been following that trend.
And flawed as C++ is, it is flawed exactly because it tries to give people like you what you claim you want: full backwards compatibility and demonstrably equivalent performance to C. The reason C++ is so messed up is because C is so messed up; the reason C programmers don't like C++ is because C++ breaks the only thing C has ever had going for it: C is a small language, while C++ is not.
How could a current C-based UNIX-like OS improve? Well a good start would be:
Convert many of its user mode programs (in particular, servers and system configuration tools) to something higher level than C, much of it perhaps even scripting languages.
Make it possible to use at least one higher-level language in the kernel; Embedded-C++, C++ or Objective-C are obvious choices. A Java subset would be another.
What's your point about not making progress for 20 years? What kind of progress are you after?
Well, a good start would be if the kernel and user-mode utilities were implemented in an object-oriented language with built-in error checking and garbage collection and a large standard library. Why? Because it would let people use modern software engineering and design tools, it would make it much easier to experiment and add features, and it would reduce the amount of effort required for implementing resource management, security, and error handling.
If Linux itself was a project that involved attention to code quality...
You still mistake this for a BSD-vs-Linux discussion. I'm not saying Linux is better than BSD, I'm saying the differences don't matter to me (or apparently millions of other users), so I might as well use the more mainstream system.
It does sound to me, too, that the judge screwed up. But I doubt he screwed up because he was biased specifically against Microsoft. He might have had a general bias in favor of small inventors and academic researchers and against big companies in patent cases. That's not such an unreasonable bias to have, given that big companies often walk all over small inventors with their legal teams and expert witnesses.
The fact that the big company was Microsoft probably was incidental. And, as it turns out, the small inventor may have been less than honest in this case.
I wish people would get over this notion that something like this is a "subscription vs. free", implying that Google is doing charitable work. Whether their service is advertising supported or a loss leader, they are maximizing return on investment for their stock holders. Google Scholar may be "free", just like your Yellow Pages may be free, but it's still a product. And Google will go aggressively after people who may be violating their trademarks.
However, in this particular case, I think the dispute is silly just because of the names: "SciFinder Scholar" and "Google Scholar" are not confusingly similar.
but don't try to make it appear as if Linux kernel code is as clean and elegantly designed as NetBSD
See the Subject:? I just asked you, the BSD advocates: "why should I care"? Apparently, you have no answer. Instead, you bring up all sorts of bullshit, claiming that BSD does things "the Right way", badmouthing Linux, going on about "microkernels", etc. Anything other than concrete and specific things that someone might care about in 2004.
Because in the end, there's a reason people don't use these so-called microkernel-derived designs.
Yes, I fully agree. So, which part of "Microkernels were a bad idea. They're dead. The debate is over. Get over it. Stop using them as a strawman to answer the hard question of why *BSD is still stuck firmly in the 1970's." did you have trouble understanding?
The reasons are practical and have to do with software engineering, something a lot of academics don't grasp very well.
Well, if there is so much software engineering going on, maybe you can point me at the requirements documents, specifications, UML diagrams, code reviews, schedules, bug metrics, usability studies, and all the other artifacts that software engineering produces.
The funny thing is, I don't even think the NetBSD is bad, it just seems somewhat redundant to me. Oh, and apparently its authors can't explain what it's good for and they like to say bad things about more successful FOSS projects.
Back in the seemingly dark ages of the early 90's the "hot" thing in OS design was microkernels [...]
Microkernels were a bad idea. They're dead. The debate is over. Get over it. Stop using them as a strawman to answer the hard question of why *BSD is still stuck firmly in the 1970's.
The next generation of kernels took the microkernel idea of complete separation of functions but linked it all together in a single executable, replacing message passing with parameter passing.This produces much of the benefit of the microkernel design without the tremendous speed degredation of the microkernel design.
An important part of that message seems to have gotten lost on you. Microkernels provided fault isolation and dynamic configurability, they were just inefficient at it. The answer to that was not to say "oh, let's just link everything back together again", the answer to that was "let's put everything into a single address space but provide fault isolation and dynamic configurability at the runtime/language level inside the kernel, because that gives us the benefits of microkernels without the context switch overhead" (well, there were a bunch of other good answers and approaches, but this is the one that matters here).
*BSD didn't do that; *BSD just represents a regression to the pre-microkernel monolithic kernels of the 1970's with no support for fault isolation or language-supported dynamic configurability. And if I have to use such an antidiluvian kernel architecture anyway, I might as well use Linux.
Actually, I prefer low cost and low business risk. Open source happens to be one way of getting that. Picking a proprietary platform from a company that's teetering on the edge of bankruptcy isn't.
Your preference doesn't make Java poorly designed nor does it make Flash poorly designed.
No. What makes Java poorly designed and what makes Flash poorly designed is, drumroll, their poor design. But even if they weren't so flawed and cumbersome, even if they were comparable to the free and open standards, that wouldn't be enough. Costly and risky proprietary solutions like Flash and Java need to demonstrate that they are substantially better than the open and free alternatives, and it's the responsibility of their proponents to provide hard and convincing evidence.
Please start quoting proper sources because otherwise the two statements above are non-falsifiable nonsense.
You got it backwards. Advocates of Flash/Flex as a user interface toolkit need to demonstrate that Flash/Flex-based user interfaces have greater usability, greater user acceptance, and lower development costs than DHTML-based user interfaces, otherwise there is no point for giving it even a second look. Advocates of Java for server-side programming need to demonstrate that Java projects can be developed at lower cost, have higher quality, and have faster time to market than PHP projects, otherwise Java is the wrong choice.
People who run BSD usually do so because they want systems that are Right
BSD is a monolithic C-based kernel with a 1970's design, just like Linux. Saying it is "Right" is like saying that lime green bell bottom pants are "Right" while the orange variety is "Wrong". Give me a break.
And as a personal anecdote NetBSD hugely outperforms Linux 2.6 on all of the machines I have tried in my experience,
Unless you can produce some more facts to support such an incredible assertion, I'll just file that away under "superstition".
"essentially exposing himself as a nonrational anti-MS activist."
This sort of thing happens in many patent cases. The judge probably made serious mistakes, but that doesn't make him an anti-MS activist. In fact, I seriously doubt the judge cares at all about MS, one way or the other.
There does exist anti-MS activism, but it is a rational, justified reaction to Microsoft business practices, like forced bundling agreements, Microsoft marketing FUD, and lousy security in Microsoft products. That kind of "anti-MS activism" is at the same level as activism against a polluting chemical plant or activism against corruption in government: it's real people without a marketing budget reacting to a real problem and misrepresentations by a powerful corporation with deep pockets.
Occasionally, anti-Microsoft activism may be unfair to Microsoft, and that is wrong: activism should stick to the truth and remain rational. But, on balance, Microsoft's conduct is so egregious compared to the miniscule amount of actually unfair criticism it receives that there is no justification for anybody to bellyache about "anti-MS activism".
It does seem to me (although IANAPL) that this very clearly describes an implementation of what was later called a "plugin".
A "plugin" is something you obtain by some means (maybe download, maybe CD) and install permanently on your machine; a plugin extends what your browser can render (new image types, video, etc.). Some plugins enable your browser to run applets (e.g., the Flash or Java plugins).
An "applet" is code that is downloaded into the browser and executed there as you browse.
The Viola browser implemented applets, and that's what this lawsuit is about.
What does all that cleanliness translate into? How does it make my computing life easier?
Let's compare this to Linux. Linux runs where I want it to run. It's open source, has lots of drivers, lots of user-mode programs, and several package systems to choose from. It seems to run reasonably close to hardware speed under normal conditions. Its init scripts may not be as clean as NetBSD's, but they seem to get the job done. Where is the big improvement in NetBSD over Linux that would make me switch?
Something like Plan9 might be tempting from my point of view because it really does offer some pretty advanced additional functionality. But the differences between Linux and *BSD just don't seem particularly big.
Great! Now, a poorly designed server-side technology (Java) meets a poorly designed client GUI technology (Flash).
Thanks, but no thanks. For "rich internet applications", PHP and DHTML-based toolkits are a better choice right now: easier to train developers, faster development times, better user interfaces. With SVG, XUL, PHP-XUL, and similar technologies, that's only getting better.
The problem isn't with USPTO employees, it's with the criteria and conditions under which they need to work. If you go to work for the USPTO, it won't improve anything, since you'll be working under the same conditions.
To prevail in an infringement case, an accused infringer has to present clear and convincing evidence that the patent is invalid.
Simply reversing this standard might be good: someone who wants to obtain a 20-year monopoly should have to present clear and convincing evidence that the idea he is seeking protection for is novel, useful, and can be reproducibly implemented based on the patent application. If he can't make a clear and convincing argument, then the patent should be found invalid by default.
Furthermore, patents should be found valid and invalid not claim-by-claim, but all-or-nothing. That way, applicants for patents have themselves a strong incentive only to claim what is actually novel and useful. Right now, almost every patent has claims in it that are ridiculously broad, that create unwarranted uncertainty and risk for competitors, and that courts need to spend enormous amounts of resources whittling down.
I think those two changes alone would do wonders for the patent system. But the IEEE suggestions are also welcome.
The only possible benefit of using Linux as Cobalt's kernel would be that PalmSource might be able to leaverage the open source model for driver development (driver development is traditionally the responsiblity of Palm OS licensees, AFAIK).
That's probably the major reason for them doing this.
But if they do the PalmOS/Linux integration right, you'll be able to mix Linux and Palm code and instantly get a boatload of libraries: XML, HTML, databases, networking protocols, command line apps, encryption, you name it. That makes PalmOS+Linux a hugely attractive platform.
Slashdot Mirror
Try "man locate" and "man updatedb"; that's been around forever. It probably already gets updated nightly on your computer (that's why your disk starts making all that noise early in the morning).
If you want to search for content, you can combine it with grep and xargs:More complicated pipes involve "file", "perl", "awk", etc.
provided that it would be easy for the USA to disrupt it.
It's not that simple. If the US turns off its GPS system, the Europeans can moan but they don't really have cause to complain. If the US disrupts Galileo without consent from the Europeans, that would be a grave violation of international law and something that can't be papered over easily. The US may have a button to disrupt Galileo now, but their use of it is quite constrained.
The sad thing is that one even has to contemplate these issues. And the fault for that lies entirely with recent US unilateralism. A nation that wants to be the leader of the free world has responsibilities to listen to the concerns of the free world, but as Bush and other politicians have made crystal clear recently, America always comes first and they will only do what is in America's best interest. That amounts to an abdication of US leadership.
But even if the US were not adopting such hostile policies, US influence would be diminishing over the next several decades anyway: without both massive foreign borrowing and a strong dollar, the US simply cannot sustain its standard of living, let alone its huge military. But the current deficits are not sustainable: the US has to cut back while other nations pull ahead economically, and hence militarily.
With Gallileo on the other hand, good luck getting the ruling body (by the people, for the people) to agree quick enough for it to make a difference.
And how much did the US listen to international input when deciding to invade Iraq? Cooperation goes both ways, and the US government has demonstrated that it will do whatever it pleases, no matter what the international community says. And it's not just Iraq: the US has recently ignored, violated, and abrogated lots of international treaties.
From the perspective of other nations, the US is looking increasingly untrustworthy and unreliable, and that's why they have to start building their own infrastructure.
If you don't like the way decisions are made in Europe, that's tough: Europeans don't like the way decisions are made in the US either, and there are more of them around (ditto for Indians and Chinese).
As a citizen of the US, I absolutely DO NOT want a third party to be able to accurately aim a missile at the White House, the Capitol, or a nuclear power plant.
Nobody wants foreign powers to be able to aim missiles at their cities. But the US can aim and guide missiles where it pleases and is refusing to give up that capability. Therefore, there is no reason why the Europeans shouldn't be able to do the same. In fact, the US government has stated itself that it wants the Europeans to develop their own high-tech military capabilities. That includes their own GPS system, their own missiles, and other technology. And the Europeans aren't just going to pay for high tech weapons and then put them under US control.
This kind of development is inevitable anyway: Europe is becoming stronger and more independent. But the really big change will occur when India and China are starting to develop their own high-tech dual-use technologies, in particular, space technologies, and they are not going to be bound by cultural affiliations with the US.
You better get used to it now because this sort of thing is unavoidable.
Actually, we don't need to invent new languages; before the invasion of UNIX, people actually were writing operating systems in better languages than C/C++. However, even C++ is a better than C because it lets programmers standardize and automate things; in my experience, with the right coding guidelines and libraries, programmers produce much better code and have a lot fewer bugs than in equivalent C code.
The reason I prefer procedural languages to object-oriented ones is because computing itself is procedural. Object orientation feels like a hack. It's a weird way I look at it, yes, but it takes me personally a lot more effort to implement something in an object-oriented way than the same functionality in a procedural way, and the procedural way ends up cleaner and more efficient in the end. That's just me.
Those are the same objections dyed-in-the-wool procedural application programmers were raising, and they have had to switch; OS and RT programmers are just getting away with not switching because their fields are somewhat black arts that nobody else wants to bother with. So, one indulges their quirks.
Of course, just about everybody understands that OOP has lots of flaws. It's simply a pragmatic solution to standardizing a bunch of procedural constructs that procedural programmers are using anyway. BSD and Linux both have lots of OOP constructs in them, they are simply not made explicit or standardized.
In any case, OOP is only one aspect. A more important one is to use languages with better type systems, resource management, and error checking than C. Even Bell Labs has started using something other than C in Plan9.
Hey, I wouldn't mind seeing a whole revolution in software design for FOSS systems, but the fact of the matter is that it would break a lot of familiarity and compatibility, and if it isn't good in the end (which is very possible) it will have all been for nothing. Not changing anything for decades is a good thing in this respect - there's no way to go 'wrong'.
But user-level software on UNIX has never been exclusively C: a large part of it has always been in HLL, starting with languages like awk. Over the last decade, more and more has been written in languages like C++, Perl, Python, Ruby, and Java. It's just that the kernel hasn't been following that trend.
And flawed as C++ is, it is flawed exactly because it tries to give people like you what you claim you want: full backwards compatibility and demonstrably equivalent performance to C. The reason C++ is so messed up is because C is so messed up; the reason C programmers don't like C++ is because C++ breaks the only thing C has ever had going for it: C is a small language, while C++ is not.
How could a current C-based UNIX-like OS improve? Well a good start would be:
What's your point about not making progress for 20 years? What kind of progress are you after?
...
Well, a good start would be if the kernel and user-mode utilities were implemented in an object-oriented language with built-in error checking and garbage collection and a large standard library. Why? Because it would let people use modern software engineering and design tools, it would make it much easier to experiment and add features, and it would reduce the amount of effort required for implementing resource management, security, and error handling.
If Linux itself was a project that involved attention to code quality
You still mistake this for a BSD-vs-Linux discussion. I'm not saying Linux is better than BSD, I'm saying the differences don't matter to me (or apparently millions of other users), so I might as well use the more mainstream system.
It does sound to me, too, that the judge screwed up. But I doubt he screwed up because he was biased specifically against Microsoft. He might have had a general bias in favor of small inventors and academic researchers and against big companies in patent cases. That's not such an unreasonable bias to have, given that big companies often walk all over small inventors with their legal teams and expert witnesses.
The fact that the big company was Microsoft probably was incidental. And, as it turns out, the small inventor may have been less than honest in this case.
I wish people would get over this notion that something like this is a "subscription vs. free", implying that Google is doing charitable work. Whether their service is advertising supported or a loss leader, they are maximizing return on investment for their stock holders. Google Scholar may be "free", just like your Yellow Pages may be free, but it's still a product. And Google will go aggressively after people who may be violating their trademarks.
However, in this particular case, I think the dispute is silly just because of the names: "SciFinder Scholar" and "Google Scholar" are not confusingly similar.
but don't try to make it appear as if Linux kernel code is as clean and elegantly designed as NetBSD
See the Subject:? I just asked you, the BSD advocates: "why should I care"? Apparently, you have no answer. Instead, you bring up all sorts of bullshit, claiming that BSD does things "the Right way", badmouthing Linux, going on about "microkernels", etc. Anything other than concrete and specific things that someone might care about in 2004.
Because in the end, there's a reason people don't use these so-called microkernel-derived designs.
Yes, I fully agree. So, which part of "Microkernels were a bad idea. They're dead. The debate is over. Get over it. Stop using them as a strawman to answer the hard question of why *BSD is still stuck firmly in the 1970's." did you have trouble understanding?
The reasons are practical and have to do with software engineering, something a lot of academics don't grasp very well.
Well, if there is so much software engineering going on, maybe you can point me at the requirements documents, specifications, UML diagrams, code reviews, schedules, bug metrics, usability studies, and all the other artifacts that software engineering produces.
The funny thing is, I don't even think the NetBSD is bad, it just seems somewhat redundant to me. Oh, and apparently its authors can't explain what it's good for and they like to say bad things about more successful FOSS projects.
What an embarrassing typo. Although I am generally also quite "anti-diluvian", here the correct word is "antediluvian".
Back in the seemingly dark ages of the early 90's the "hot" thing in OS design was microkernels [...]
Microkernels were a bad idea. They're dead. The debate is over. Get over it. Stop using them as a strawman to answer the hard question of why *BSD is still stuck firmly in the 1970's.
The next generation of kernels took the microkernel idea of complete separation of functions but linked it all together in a single executable, replacing message passing with parameter passing.This produces much of the benefit of the microkernel design without the tremendous speed degredation of the microkernel design.
An important part of that message seems to have gotten lost on you. Microkernels provided fault isolation and dynamic configurability, they were just inefficient at it. The answer to that was not to say "oh, let's just link everything back together again", the answer to that was "let's put everything into a single address space but provide fault isolation and dynamic configurability at the runtime/language level inside the kernel, because that gives us the benefits of microkernels without the context switch overhead" (well, there were a bunch of other good answers and approaches, but this is the one that matters here).
*BSD didn't do that; *BSD just represents a regression to the pre-microkernel monolithic kernels of the 1970's with no support for fault isolation or language-supported dynamic configurability. And if I have to use such an antidiluvian kernel architecture anyway, I might as well use Linux.
Apparently you prefer open source.
Actually, I prefer low cost and low business risk. Open source happens to be one way of getting that. Picking a proprietary platform from a company that's teetering on the edge of bankruptcy isn't.
Your preference doesn't make Java poorly designed nor does it make Flash poorly designed.
No. What makes Java poorly designed and what makes Flash poorly designed is, drumroll, their poor design. But even if they weren't so flawed and cumbersome, even if they were comparable to the free and open standards, that wouldn't be enough. Costly and risky proprietary solutions like Flash and Java need to demonstrate that they are substantially better than the open and free alternatives, and it's the responsibility of their proponents to provide hard and convincing evidence.
Please start quoting proper sources because otherwise the two statements above are non-falsifiable nonsense.
You got it backwards. Advocates of Flash/Flex as a user interface toolkit need to demonstrate that Flash/Flex-based user interfaces have greater usability, greater user acceptance, and lower development costs than DHTML-based user interfaces, otherwise there is no point for giving it even a second look. Advocates of Java for server-side programming need to demonstrate that Java projects can be developed at lower cost, have higher quality, and have faster time to market than PHP projects, otherwise Java is the wrong choice.
So, you show us the data, then we can talk.
People who run BSD usually do so because they want systems that are Right
BSD is a monolithic C-based kernel with a 1970's design, just like Linux. Saying it is "Right" is like saying that lime green bell bottom pants are "Right" while the orange variety is "Wrong". Give me a break.
And as a personal anecdote NetBSD hugely outperforms Linux 2.6 on all of the machines I have tried in my experience,
Unless you can produce some more facts to support such an incredible assertion, I'll just file that away under "superstition".
"essentially exposing himself as a nonrational anti-MS activist."
This sort of thing happens in many patent cases. The judge probably made serious mistakes, but that doesn't make him an anti-MS activist. In fact, I seriously doubt the judge cares at all about MS, one way or the other.
There does exist anti-MS activism, but it is a rational, justified reaction to Microsoft business practices, like forced bundling agreements, Microsoft marketing FUD, and lousy security in Microsoft products. That kind of "anti-MS activism" is at the same level as activism against a polluting chemical plant or activism against corruption in government: it's real people without a marketing budget reacting to a real problem and misrepresentations by a powerful corporation with deep pockets.
Occasionally, anti-Microsoft activism may be unfair to Microsoft, and that is wrong: activism should stick to the truth and remain rational. But, on balance, Microsoft's conduct is so egregious compared to the miniscule amount of actually unfair criticism it receives that there is no justification for anybody to bellyache about "anti-MS activism".
It does seem to me (although IANAPL) that this very clearly describes an implementation of what was later called a "plugin".
A "plugin" is something you obtain by some means (maybe download, maybe CD) and install permanently on your machine; a plugin extends what your browser can render (new image types, video, etc.). Some plugins enable your browser to run applets (e.g., the Flash or Java plugins).
An "applet" is code that is downloaded into the browser and executed there as you browse.
The Viola browser implemented applets, and that's what this lawsuit is about.
What does all that cleanliness translate into? How does it make my computing life easier?
Let's compare this to Linux. Linux runs where I want it to run. It's open source, has lots of drivers, lots of user-mode programs, and several package systems to choose from. It seems to run reasonably close to hardware speed under normal conditions. Its init scripts may not be as clean as NetBSD's, but they seem to get the job done. Where is the big improvement in NetBSD over Linux that would make me switch?
Something like Plan9 might be tempting from my point of view because it really does offer some pretty advanced additional functionality. But the differences between Linux and *BSD just don't seem particularly big.
Great! Now, a poorly designed server-side technology (Java) meets a poorly designed client GUI technology (Flash).
Thanks, but no thanks. For "rich internet applications", PHP and DHTML-based toolkits are a better choice right now: easier to train developers, faster development times, better user interfaces. With SVG, XUL, PHP-XUL, and similar technologies, that's only getting better.
Don't you mean "poor UI design is evil"? Both the issues you describe seem to boil down to bad design and authoring.
Unfortunately, Flash makes it really easy to design bad UIs and really hard to design good ones.
The technology should not be blamed just because some people use it poorly.
But the technology should be blamed if it is hard to use properly. And that's what Flash is.
Since when are they found valid at all?
Sorry, I was using that as a shorthand for "are not invalidated".
And an ability to use prior art the PTO was aware of.
Right: that's a very important point, since the PTO doesn't really seem check that much anymore.
Lowering infringement damages would also be good.
Agreed.
And perhaps eliminating damage awards as subject to MFL clauses.
I'm not sure I follow that. Can you explain?
THEN WHY DON"T YOU SPELL IT PHONETICALLY?!?!??!
Perbli fer the seim rizn u dohnd spell fenetekli idha.
The problem isn't with USPTO employees, it's with the criteria and conditions under which they need to work. If you go to work for the USPTO, it won't improve anything, since you'll be working under the same conditions.
To prevail in an infringement case, an accused infringer has to present clear and convincing evidence that the patent is invalid.
Simply reversing this standard might be good: someone who wants to obtain a 20-year monopoly should have to present clear and convincing evidence that the idea he is seeking protection for is novel, useful, and can be reproducibly implemented based on the patent application. If he can't make a clear and convincing argument, then the patent should be found invalid by default.
Furthermore, patents should be found valid and invalid not claim-by-claim, but all-or-nothing. That way, applicants for patents have themselves a strong incentive only to claim what is actually novel and useful. Right now, almost every patent has claims in it that are ridiculously broad, that create unwarranted uncertainty and risk for competitors, and that courts need to spend enormous amounts of resources whittling down.
I think those two changes alone would do wonders for the patent system. But the IEEE suggestions are also welcome.
The only possible benefit of using Linux as Cobalt's kernel would be that PalmSource might be able to leaverage the open source model for driver development (driver development is traditionally the responsiblity of Palm OS licensees, AFAIK).
That's probably the major reason for them doing this.
But if they do the PalmOS/Linux integration right, you'll be able to mix Linux and Palm code and instantly get a boatload of libraries: XML, HTML, databases, networking protocols, command line apps, encryption, you name it. That makes PalmOS+Linux a hugely attractive platform.