You can't leave the determination of "obviousness" to courts as a matter of common practice. Going to court costs a lot of money and creates a lot of risk.
If the patent office routinely grants obvious patents, to make money, you only need to patent something obvious and then keep your licensing fees below the expense and risk you create for potential infringers. This is particularly lucrative if you are a lawyer or have a staff of lawyers as part of your normal business operations: then, the cost of pursuing obvious patents is much lower for you than for the people you go after.
If you manage to get an important but obvious patent past the patent office (and that isn't so difficult), and if you have reasonably efficient legal representation, you pretty much have written yourself a check for a few million dollars. And that's money that ultimately comes out of what you pay for goods and services.
Furthermore, the US patent office is activist and expands notions of patentability far beyond what used to be established practice. Some of the software and business practices that have been patented recently were obvious to many people in the 80's, but they weren't patentable then. You are rewarding boldness in pushing patent law, not innovation.
The idea behind patent law isn't stupid. But the actual implementation and politics in the US that surround it, the special interests, the lobbying, and the unchecked expansion of its scope are.
What "ready for the desktop" seems to mean in practice is "Windows and MacOS users will feel comfortable on it". In particular, it will mean adopting a lot of the behaviors of those systems because that's what users are used to. In fact, I think KDE and Gnome aren't all that far from it: my mother had no significant problems with a KDE desktop.
But even if a new Linux UI could innovate freely, unrestrained by user expectations, designing for the "average desktop" still means designing for a different user community from the current Linux users.
So, I still don't get the motivation: why do people volunteer for projects that largely seem to try to replicate an existing user experience for the non-programming masses? Even if someone really wants to develop software for average users, why try to replicate a paradigm (the Windows/Mac desktop) that seems intrinsically complex, when very easy to use interfaces (appliance like, embedded, etc.) seem actually much more promising.
So, maybe being "ready for the desktop" in the sense of what runs on most desktops today is just the wrong thing to aim for: most people seem to need something simpler (think WebTV, Playstation, and word processor), and expert Linux users probably want something more flexible than a Windows/MacOS desktop workalike.
The concerns for the recording industry are valid but pointless. PDAs running Windows CE or Linux with equivalent capacities and processing power are coming out. They do allow bidirectional transfer. Is the RIAA going to dictate what kind of software we can put on our PDAs?
Maybe what PJB should do is add general PDA and installable software support. Then, you can ship it as is, and people add the PDA application for bidirectional transfer between units and between a unit and their desktop themselves.
Otherwise, I'm just going to wait for the next device. If I'm going to lug around a 5G drive, I at least want to be able to store some files on it as well.
The system discovers duplicate files and links them to a single instance automatically. It also uses copy on write. The "invention" is not symlinks, but it isn't new either.
Many backup systems eliminate duplicate files, for example, and some of them actually have file system interfaces. You can get scripts that will scour your file system and cross-link duplicate files under UNIX on Freshmeat (or write your own in Perl in a few minutes). The idea of copy-on-write for file systems is not new either.
I think many people have thought about putting this into the file system, and probably many of them concluded that it wasn't such a good idea on UNIX systems. It complicates the file system implementation unnecessarily for an uncertain gain.
Brace yourself for the patent, however. Microsoft is sure to have patented this, and there is a good chance that the patent will stand, no matter how much other related prior art there is. The argument will be simple: nobody else has actually implemented this in a widely used commercial file system, and we are wildly commercially succesful with it. That's generally enough.
Even if you are pretty frugal, you can expect to spend several thousand dollars on the initial application for one patent ("Patent It Yourself" from Nolo Press is pretty good if you want to read about the process). The patent also needs to be renewed regularly. This is in addition to significant amounts of time you are going to spend on it. If you actually want to enforce the patent, you face the question of detecting infringement and going through the legal process (and expenses) to enforce the patent.
I looked at these issues and decided it didn't make sense for me to patent merely "very good" ideas as an individual--the expense and time are too high, and if I wanted to get something out of a patent as an individual inventor, I would have to dedicate my life to the pursuit of that (no fun).
Where I find it probably makes sense to get the patents is if there is a specific technology business you want to start; in that case, you may want to get several patents around that business. And if you want to get VC funding, having patents on your basic technology is important.
Large companies, of course, routinely patent everything under the sun. With a dedicated staff of patent attorneys, a pipeline to the patent office, and a burning need for a large patent portfolio for trading with other companies, it makes a lot of sense for them to patent anything that's patentable, even if it just barely makes the cut (or so the thinking goes, at least).
I think none of this is particularly fair or beneficial for innovation, but it seems to be the rules people have to play by today.
In any case, if you think you have a good idea but don't want to go through the expense of patenting it, consider "disclosing" it in the formal patent law sense (in addition to publishing it). That requires little more than a brief note to the patent office. Formal disclosure will protect you pretty well from other people claiming a patent on the same invention.
In this case, the tool in question may have been used for a crime. But regardless of whether there were other reasons involved in this case, in general, in the real world, tools and devices that are involved in crime are often regulated.
As long as the Internet was computer scientists, engineers, and a few students working on machines with little commercial significance, there was very little regulation. But now, you get businesses, families, lawyers, policemen, everybody moving on-line.
They are going to be asking for the same protections and laws that they ask for in the real world, whether it makes sense on-line or not. That's why you see strong efforts to combat pornography. That's why you are probably going to see efforts to outlaw the on-line equivalent of "burglary tools".
The popularization of the Internet reduces it to the lowest common denominator of society, both in terms of skills and expectations. Whether there is anything we can do about it remains to be seen; perhaps the Internet will eventually break up into distinct parts with very different rules, only sharing a common hardware and protocol infrastructure.
I would have been perfectly happy with the Internet remaining what it was and most non-technical people working on some simple commercial system like Minitel or a proprietary WebTV. But, I suppose, the way things have turned out, they are at least a lot more interesting.
I have used various versions of Macsyma in the past, and I found it to be very good and reliable. I strongly recommend people give it a try and don't get put off by the options and syntactic quirks it may seem to have at first sight.
On using packages like Macsyma, many commercial ones seem to promise that they can solve your problems automatically. But for most non-trivial problems, what those packages shine at is bookkeeping during complex manipulations; the guidance and inspiration still needs to come from the user (and this is true of all of the packages I have used).
It's great that Macsyma is now officially free as Maxima (I had been using older versions that you could download but whose copyright status was complex). I hope Maxima will become a standard part of Linux distributions and that more people will start developing packages for it again.
Fees like $2500 for specs are not going to make anybody rich. There may be lots of reasons for the fees. It's possible that the forum miscalculated its budget and needs extra money to pay for publication, mailing, or other office exenses (it happens with these kinds of efforts). It's also possible that they simply want to limit the number of people who participate in USB-related standards discussions (many of the documents don't seem finished yet).
It seems unlikely to me, that they are really trying to keep the specs themselves under wraps in the long run.
So, I wouldn't jump to conclusions. Still, whatever the reasons for it, I hope this policy gets reversed because it does seem, ultimately, short sighted and harmful to the standard itself.
When I try it, the KAppWizard of KDevelop generates more than 500 lines of source code for an empty GUI program, complete with VC++-style "fill in the blanks" comments. It also has a "dialog editor" just like VC++ that lets programmers design GUIs "visually".
Perhaps emblematic of what I'm getting at is that KDevelop makes it possible to write a KDE GUI program without any clear understanding of how the toolkit works--as I demonstrated myself. To me, it still looks like KDevelop supports and encourages a style to programming similar to what prevails on Windows. Both opinions and preferences differ on this point, but to me, that is not a plus.
You are shooting down a straw man: nowhere did I say that development from within Emacs was more "manly" or that you could only develop graphical applications in KDevelop. In fact, if KDevelop were only for graphical applications, it wouldn't much interest me who uses it.
What I'm saying is that different people have different preferences and styles. KDevelop may well be enormously productive for you and the majority of programmers (just like VC++ is). But for me (and at least some other people), it's just not a good tool (believe me, I have tried). That doesn't mean either way is better than the other, it means that there are different groups of people with different skills and preferences. Just like command line users ought to admit that GUI-based development tools are useful to some, the reverse ought to be conceded too.
What is an open question to me is whether the two kinds of styles can co-exist in the same community. Will I be able to make sense of, and contribute to, your libraries developed in KDevelop using my programming tools? Will you be able to handle modifications that I make to them outside KDevelop? I have dealt with MFC by hand, moved software packages back and forth between VC++ and the command line, etc., and I'm not that optimistic in the long run.
Tools like VC++ and KDevelop tend to encourage much of the intelligence to move into the development environment, making the actual code difficult to read and maintain any other way. And, conversely, tools like VC++ and KDevelop tend not to be able to make a lot of sense of interesting abstractions implemented "by hand".
Maybe my concerns are unfounded: KDevelop, KDE, and Qt are a lot cleaner than VC++ and MFC, and KDevelop tries to fit in well with the current Linux development styles (in fact, I'd much rather use KDevelop than VC++). But I'm not convinced that in the long run, this can work out.
So, Linux may well split into a Windows-like community and a UNIX-like community, with less and less code sharing between them as time goes by. That's probably still better than a MS Windows/Linux split, but maybe by thinking about it ahead of time, we can at least make such a transition easier and have realistic expectations.
Well, yes, Linux is free software and people can do with it what they want, within the license.
However, that doesn't mean that one should abandon all thought on what the consequences of particular developments are. What happens if Microsoft ports Office to Linux and releases it? What happens if Linux development becomes more and more Windows-like?
Your answer seems to be that it doesn't matter: there will simply be more and more distributions catering to different tastes. That may turn out to be the case. I hope so, because I think that's the best of all worlds.
But it isn't the only way things can unfold. he fact that many of the Windows UI windows don't resize, that they lock each other, that MFC has serious flaws in its inheritance hierarchy, that the Windows requires various kinds of even tables, etc., are all consequences of a particular approach to programming.
Some of those issues are related to historical developments, some to programming style prevalent in the Windows community, and some are related to the use of an environment like VC++: it allows people to fix problems by building wizards and graphical tools that then generate complex source code that is difficult to maintain by hand.
It's useful to think about this ahead of time because a lot of the design you see in the Linux kernel, GNU libraries, and Linux libraries comes out of a tradition and development environment that made certain things hard and therefore forced people to come up with different (I think better) designs. I believe that traditional UNIX environment forced you to design more cleanly, build general tools, and build good abstractions, because it simply didn't support good visualizations and expedient fixes.
I believe it is worth thinking about these issues now while KDevelop and tools like it aren't that widely used yet. Maybe we can improve the way the two approaches to programming can live side-by-side. Maybe it doesn't matter because KDevelop might not catch on. Or maybe your optimism is warranted and different communities of people will just use different distributions, all somewhat interoperable.
I downloaded the beta of Kdevelop 1.1. Kdevelop will make people coming from a Windows and VC++ environment really happy, since it offers a similar style of programming and GUI design. Kdevelop will also attract a lot of developers to the Qt toolkit, since it makes it pretty easy to use Qt.
Of course, I'm not entirely sure why this is a good thing. GNU&Linux wasn't built or used by people who approached programming that way. Is KDevelop going to bring a lot of developers from Windows to Linux? What kind of changes will they want in Linux? And what will that mean to the traditional GNU&Linux communities?
I think there is a lot of interesting stuff to be done in the traditional text-based GNU/Linux/UNIX approach to programming. Here are just some simple ideas:
a working command line version of cextract for C++
a better version of make that determines and manages dependencies among C/C++ files faster, more automatically, and more reliably than existing approaches
a constraint and rule-based language for specifying GUIs in your favorite toolkit
an SML-style module system for C (and maybe C++), integrated with a make-like facility
integrating the C/C++ bounds checking hacks into the main branch of GNU C and figuring out a good way of making that backwards compatible with old libraries
KDevelop is glitzy. It's a big and impressive development effort. It's probably useful for people who want to build Windows-like applications with a Windows-like IDE. I can even see why people have fun developing it.
But, ultimately, KDevelop looks foreign to me in a UNIX environment and less useful for traditional UNIX uses and users. I'd like to see more effort go into building tools in the traditional UNIX style (and I'm trying to help when I can).
The difference is: Linux is a volunteer effort, Microsoft makes billions from their software.
If you are a paying customer and don't get what you have been promised, you can complain. If you get free software and don't get what you have been promised, you can volunteer.
Making something "incredibly more convenient" can be a security flaw (and in the case of ActiveX definitely is).
In the process of downloading a browser plugin, you get a lot more information about the plugin and a lot more opportunity to find out more about it. That's a security feature. And that's why plug-ins are much less evil than ActiveX.
Of course, proper sandboxing, as in Java and Tcl, is the best answer.
In addition, I think it's not just control over their own content that comes with SDMI or other proprietary formats. By controlling the format, the industry consortium also controls access to the market by other companies and not-for-profit efforts.
And they control upgrade paths: every ten or so years, you will get a new, "enhanced" format that requires you to repurchase your entire collection of media.
Contrast that with MP3. Because MP3 is open and media independent, it's archival: if you have paid for some piece of music once, you and your heirs can access it in perpetuity.
Furthermore, with an open format like MP3, you'd get more and more free content, from people who perform music and theater for fun. Much of that isn't going to be very good, but some can be excellent. With the kind of format the RIAA is pushing for, they'd get their cut even from such productions, through license fees and inflated production costs.
Technology promises to bring us, finally, the ability to share artistic content freely, and the established media companies are trying to thwart this. I think, ultimately, the RIAA and MPAA efforts are doomed to failure. But if we don't watch out, we may be in for a very unpleasant few decades where content remains unnecessarily expensive and limited.
Actually, a number of machines have had special hardware to deal with memory allocation issues (among them, Lisp Machines, an old Intel "object oriented processor", and various segmented architectures). Note, also, that the UNIX malloc on many machines does actually make use of the memory mapping hardware to avoid page copies when memory gets "realloc'ed".
None of those machines have caught on. The reason is that generally, you seem to do better if you invest the same kinds of resources into just making your processor faster.
Simply implementing existing malloc/free algorithms in hardware is unlikely to help. Those are complex algorithms with complex data structures, and they are probably memory limited. Where hardware could help is by changing the representation of pointers themselves: adding tag bits that are invisible to other instructions (allowing pointers and non-pointers to be distinguished, as well as space for mark bits), and possibly representing pointers as base+offset or some other kind of descriptor that makes it easier for the allocator to move memory around without the C/C++ program knowing about. As a side benefit, this kind of approach could also make C/C++ programs much safer and help run languages like Java faster.
But altogether, after having seen several attempts at this, I'm not hopeful. Unless Intel or Motorola do this in a mainstream, mass market processor, it will be very expensive and not perform as well. If you want those features, you end up getting better performance at a lower price by simply buying a mainstream processor without the features and simulating what you need.
The same problems occur with Netscape plug-ins, dynamically loadable Linux kernel modules, native code Tcl extensions, native code Perl extensions, native code Python extensions, and a lot of other software.
And if you think you can catch those problems reliably with a careful test of the binary code, you are kidding yourself. Very common kinds of bugs in those components (off-by-one errors, buffer overflows, changes to the floating point modes, etc.) can cause very subtle problems in other parts of the system. Without language/runtime suport, you won't find them, support that C/C++ doesn't have. And even if you could catch those errors, what would you do? Throw out the system-supplied standard libraries? the GUI toolkit you are using?
BTW, I have written a lot of C/C++ code, and continue doing so. But that's for research and experimentation. For multi-programmer code that goes out the door, Java, Modula, Eiffel, Python, and other, safer languages are clearly vastly superior.
There are indeed some safe runtimes for C and C++. However, they are not suitable for delivering applications. The kind of overhead they impose is considerably greater than runtime safety costs you in Java or other safe languages--you are better of using Java than using one of those runtimes.
At the heart of the problem is that C/C++ don't have a standard way for programmers to specify information that is important for efficient runtime checks.
In particular, in C/C++, the "pointer/reference" construct is used for arrays, references to local variables, call-by-reference, raw memory manipulation, format conversions, and some other purposes. But because you can't tell the compiler which of those you are intending to do, they compiler can't check for you efficiently--it has to check all the possibilities.
This lack is a peculiarity of the C/C++ family of languages. It has nothing to do with power or lack thereof. You could add the necessary constructs to C/C++ without removing any of the power. C/C++ are simply deficient in a number of important language constructs. Java may lack template constructs, but C/C++ lack crucial typing constructs.
Well, I claim, the lack of runtime safety in C and its descendants is a peculiarity and historical accident of those languages. I claim that there is no power you gain from it over alternative designs. The problem with C/C++ is not that they give you power, but that they don't give you the tools you need to ensure safety in those parts of a program where you need them.
As for "with better coders, it doesn't have to be a problem", that may work for very well run organizations developing all their own code. And even for them, the required testing cost them plenty in time-to-market and testing resources.
For the rest of us, who try to reuse commercial components and libraries, we simply don't have control over the testing that goes into the components we have to use. For starters, if you develop on Windows or Linux, you are already relying on millions of lines of source code that were developed with enthusiasm, but hardly the kind of quality control that ensures "no pointer errors in half a million lines of code". Quite to the contrary, both of those systems are known to contain plenty of pointer errors. And those errors can cause silent, serious errors, for example in a financial application.
I think people generally misunderstand the meaning of these kinds of patents. The patents are not intended to make lots of money from licensing fees. Rather, they are needed for trading with other companies with big patent portfolios. If priceline.com gets silly patents, amazon.com needs to as well, so that they can trade their patent portfolios. No money changes hands.
The net effect of this is, of course, not innovation. Rather, it increases barriers of entry to new companies who don't have patent portfolios to trade (this is seen as an advantage by established companies). Furthermore, it increases the cost of doing business, because all that patent activity costs lots of money and time. I estimate that in a corporate environment, each patent that is filed probably costs around $50k (there are a lot of highly paid lawyers and engineers involved in each patent).
Ultimately, the US patent office needs to stop this kind of abuse by reviewing patent applications more dilligently and not expanding notions of patentability as they go along. Individual companies are ultimately powerless: if they try to be high-minded about it, they'll simply go out of business.
And it's pretty clear that the US patent office is at fault. Apologists for them say that there is really no basis on which to criticize them. But there is actually a pretty straightforward metric: you can simply look at the kind of technical and legal comments you get from the US patent office vs. the European patent offices on the same patent application. The European patent office generally make competent evaluations, understand prior art quite well, and impose clear limitations on claims. The European patent offices are also much more reluctant to expand notions of patentability, usually only being pushed along by the US. From those, direct comparisons, it's pretty clear that there is a lot of room for improvement at the US patent office.
Nevertheless, I find that even by the currently low standards of patentability used by US businesses, priceline.com and amazon.com are pushing the limits. They can be justly criticized for that. It's one thing to go along with the crowd because you have to, it's quite another thing to try to deliberately push the boundaries. For that reason, I boycott Amazon, Priceline, and similar sites (I spend several thousand dollars in books and airfare each year, so this isn't an empty threat).
It's sad that Stroustrup didn't get a chance to talk about safety and fault isolation. I believe that lack of those features is a fundamental problem in the C family of languages and causing a lot of the most serious problems with computers today. What are some of them?
Many (most?) security holes in clients and servers are due to buffer overrun problems: the Morris worm, bugs in Netscape and IE, bugs in IE, bugs in most Internet protocol daemons (sendmail, bind, etc.). These are entirely avoidable with almost no runtime cost.
Component based software (browser plug-ins, COM/ActiveX components, Perl/Tcl/Python plug-ins, etc.) crash their hosting applications, often without even a clear indication of which component caused the system to fail.
Many programs contain pointer errors and corrupt memory without crashing, resulting in incorrect results or incorrect behavior that often goes undetected for years. Even when the behavior is detected, it often can't be traced to the component that is causing it. This is a particular problem when software is reused, because the reused components are developed with unknown quality control measures and safety design methodologies.
Most people seem to have come to accept the fact that their word processor, browser, and operating system crash with obscure register dumps with some regularity. But to a large degree, many of those problems are the heritage of some old design decisions in the C programming language, inherited by C++ and Objective-C. In fact, I think many of the serious problems we have with computers can be traced to lack of support for fault isolation and runtime safety in the languages we use, either directly (programs crash/have security holes) or indirectly (time that could go towards improving software needs to be spent on unnecessary testing/debugging).
It isn't very difficult to come up with a programming language that is like C (or C++ or ObjC) but also provides support for runtime safety and fault isolation. You don't need to sacrifice any efficiency or systems programming features. But C++ has, so far, dropped the ball on this. Some of its abstraction facilities (e.g., the "string" class) alleviate some of the problems if used properly, but there are no guarantees you can make about any piece of C++ code, and even if you are careful, you can't avoid unsafe constructs in code that ought to be safe.
That's why Java is catching on. Java may be lacking templates, systems programming support, multiple inheritance, and lots of other features. Java is also slow and heavy by comparison to C/C++. But Java does provide fault isolation and runtime safety, and in the end, that is what matters most to application programmers that need to get out reasonably reliable software on a tight schedule.
I suggested that RedHat support (the development of) an open source streaming media project, just like RedHat supports some other important open-source development efforts.
In fact, a number of components of such a system already exist and have been released in open source form (some of them by companies I have worked for), including H.xxx CODECs, MPEG CODECs, streaming media servers, etc. We also have good cross-platform toolkits for writing generic clients.
I disagree that having a proprietary solution on a free OS is preferable to having a proprietary solution requiring a proprietary OS in this case. If we go down that route, we may well end up with all proprietary software, formats, and protocols and only an open source kernel; what's the point of that? Supporting proprietary clients using proprietary protocols on a mainstream Linux distribution will simply help make those protocols more entrenched.
I think decisions like these are also important for RedHat's image. My organization is considering standardizing on some Linux distribution. We like Linux because it is based on open standards. RedHat has been very supportive of open source software and open standards so far, and has been sponsoring a number of open source development efforts. We want to do business with a company that continues to show that kind of commitment to open source.
Even if RedHat ships Real Networks software in the short run, I very much hope that RedHat will take the initiative and support a truly open source streaming media system. Streaming media are too important to leave them to a single company.
Many people seem to view MS Office as "a wordprocessor, a spreadsheet, and a presentation package". But in many offices and corporate environments, it has become a workflow and database system and programming environment.
In particular, many documents in a corporate environment contain templates, input fields, and scripts/macros. MS Office also supports revisions, indexing/search, and database functions. None of the MS Office clones handle the full range of day-to-day documents that appear in a corporate environment, both because they lack compatible macro/scripting capabilities in particular, and because they lack some of the other, seemingly more esotheric features in general.
A lot of people have spent a lot of time learning, and come to depend on, the idiosyncracies of MS Office. Anyone who wants to displace it faces an uphill battle. At the very least, a credible alternative must provide good import/export, scripting, macro, and template support (considerably better than any of the existing systems do). But there also would need to be support for workflow features (a web/server-based system might be an attractive alternative to the MS Office mess). And I think it would be essential to offer any open source Linux office suite on Windows as well to make the migration as easy as possible.
Of course, a more basic question to ask is still: while this could be done, why should the open source community bother? MS Office is ancient technology. Perhaps rather than focussing so much on cloning and displacing MS Office, maybe it would be better to explore new frontiers: better markup-based environments for text processing, data analysis tools that are less limited than spreadsheets, server/web-based workflow and groupware, easy end-user programming, etc. If people come up with something genuinely better, the users will come.
Yes, there is a lot of streaming content in Real Networks format out there. However, the company has hardly behaved particularly well: they never released specifications for their format as they had originally promised, and their closed source player has transmitted private information back to their servers.
Using RealPlayer will only help their proprietary format get entrenched further. That means that we may have to live for a long time with their disregard for privacy and their haphazard clients. (I removed RealPlayer from my Linux machines a while ago.)
I think it would be better to look towards open alternatives and to contact web sites to use such alternatives. Streaming MP3 is a good choice for some applications. And there has been some work on other streaming media for Linux (e.g., here).
Furthermore, I think customers of RedHat should let them know that they prefer that RedHat support an open source streaming audio/media project, rather than bundling Real Networks software.
Empirically, large C++-based software systems and component software (including COM/VBX/...) still frequently crash with pointer errors. Even more worrisome are problems where software faults in one module cause incorrect results in another module without actually causing a runtime error.
Unlike Ada or Java, C++ currently has no facilities that allow a programmer or software engineer to ensure that a fault (e.g. a pointer error) in one component does not cause errors in another component (the facilities that C++ has are advisory).
The traditional answer has been to use better overall software engineering and design. But that does not work in a world in which components come from various different sources with different standards and coding conventions.
Java has many problems, but it does have a commitment to runtime safety and fault isolation. And Java's promise really works out in practice: we can combine dozens of independently developed components and trace any software faults to specific components reliably. We'd like to have the safety and decomposability of Java with the efficiency and control of C++, but given the choice, safety and decomposability usually win out for day-to-day applications for us.
So, what does the future hold for C++ runtime safety and fault isolation? Will future C++ standards mandate more facilities than exist right now? If not, how do you think C++ can survive in a world where software is composed of hundreds of independently developed components?
Slashdot Mirror
If the patent office routinely grants obvious patents, to make money, you only need to patent something obvious and then keep your licensing fees below the expense and risk you create for potential infringers. This is particularly lucrative if you are a lawyer or have a staff of lawyers as part of your normal business operations: then, the cost of pursuing obvious patents is much lower for you than for the people you go after.
If you manage to get an important but obvious patent past the patent office (and that isn't so difficult), and if you have reasonably efficient legal representation, you pretty much have written yourself a check for a few million dollars. And that's money that ultimately comes out of what you pay for goods and services.
Furthermore, the US patent office is activist and expands notions of patentability far beyond what used to be established practice. Some of the software and business practices that have been patented recently were obvious to many people in the 80's, but they weren't patentable then. You are rewarding boldness in pushing patent law, not innovation.
The idea behind patent law isn't stupid. But the actual implementation and politics in the US that surround it, the special interests, the lobbying, and the unchecked expansion of its scope are.
But even if a new Linux UI could innovate freely, unrestrained by user expectations, designing for the "average desktop" still means designing for a different user community from the current Linux users.
So, I still don't get the motivation: why do people volunteer for projects that largely seem to try to replicate an existing user experience for the non-programming masses? Even if someone really wants to develop software for average users, why try to replicate a paradigm (the Windows/Mac desktop) that seems intrinsically complex, when very easy to use interfaces (appliance like, embedded, etc.) seem actually much more promising.
So, maybe being "ready for the desktop" in the sense of what runs on most desktops today is just the wrong thing to aim for: most people seem to need something simpler (think WebTV, Playstation, and word processor), and expert Linux users probably want something more flexible than a Windows/MacOS desktop workalike.
Maybe what PJB should do is add general PDA and installable software support. Then, you can ship it as is, and people add the PDA application for bidirectional transfer between units and between a unit and their desktop themselves.
Otherwise, I'm just going to wait for the next device. If I'm going to lug around a 5G drive, I at least want to be able to store some files on it as well.
Many backup systems eliminate duplicate files, for example, and some of them actually have file system interfaces. You can get scripts that will scour your file system and cross-link duplicate files under UNIX on Freshmeat (or write your own in Perl in a few minutes). The idea of copy-on-write for file systems is not new either.
I think many people have thought about putting this into the file system, and probably many of them concluded that it wasn't such a good idea on UNIX systems. It complicates the file system implementation unnecessarily for an uncertain gain.
Brace yourself for the patent, however. Microsoft is sure to have patented this, and there is a good chance that the patent will stand, no matter how much other related prior art there is. The argument will be simple: nobody else has actually implemented this in a widely used commercial file system, and we are wildly commercially succesful with it. That's generally enough.
I looked at these issues and decided it didn't make sense for me to patent merely "very good" ideas as an individual--the expense and time are too high, and if I wanted to get something out of a patent as an individual inventor, I would have to dedicate my life to the pursuit of that (no fun).
Where I find it probably makes sense to get the patents is if there is a specific technology business you want to start; in that case, you may want to get several patents around that business. And if you want to get VC funding, having patents on your basic technology is important.
Large companies, of course, routinely patent everything under the sun. With a dedicated staff of patent attorneys, a pipeline to the patent office, and a burning need for a large patent portfolio for trading with other companies, it makes a lot of sense for them to patent anything that's patentable, even if it just barely makes the cut (or so the thinking goes, at least).
I think none of this is particularly fair or beneficial for innovation, but it seems to be the rules people have to play by today.
In any case, if you think you have a good idea but don't want to go through the expense of patenting it, consider "disclosing" it in the formal patent law sense (in addition to publishing it). That requires little more than a brief note to the patent office. Formal disclosure will protect you pretty well from other people claiming a patent on the same invention.
As long as the Internet was computer scientists, engineers, and a few students working on machines with little commercial significance, there was very little regulation. But now, you get businesses, families, lawyers, policemen, everybody moving on-line.
They are going to be asking for the same protections and laws that they ask for in the real world, whether it makes sense on-line or not. That's why you see strong efforts to combat pornography. That's why you are probably going to see efforts to outlaw the on-line equivalent of "burglary tools".
The popularization of the Internet reduces it to the lowest common denominator of society, both in terms of skills and expectations. Whether there is anything we can do about it remains to be seen; perhaps the Internet will eventually break up into distinct parts with very different rules, only sharing a common hardware and protocol infrastructure.
I would have been perfectly happy with the Internet remaining what it was and most non-technical people working on some simple commercial system like Minitel or a proprietary WebTV. But, I suppose, the way things have turned out, they are at least a lot more interesting.
On using packages like Macsyma, many commercial ones seem to promise that they can solve your problems automatically. But for most non-trivial problems, what those packages shine at is bookkeeping during complex manipulations; the guidance and inspiration still needs to come from the user (and this is true of all of the packages I have used).
It's great that Macsyma is now officially free as Maxima (I had been using older versions that you could download but whose copyright status was complex). I hope Maxima will become a standard part of Linux distributions and that more people will start developing packages for it again.
It seems unlikely to me, that they are really trying to keep the specs themselves under wraps in the long run.
So, I wouldn't jump to conclusions. Still, whatever the reasons for it, I hope this policy gets reversed because it does seem, ultimately, short sighted and harmful to the standard itself.
Perhaps emblematic of what I'm getting at is that KDevelop makes it possible to write a KDE GUI program without any clear understanding of how the toolkit works--as I demonstrated myself. To me, it still looks like KDevelop supports and encourages a style to programming similar to what prevails on Windows. Both opinions and preferences differ on this point, but to me, that is not a plus.
What I'm saying is that different people have different preferences and styles. KDevelop may well be enormously productive for you and the majority of programmers (just like VC++ is). But for me (and at least some other people), it's just not a good tool (believe me, I have tried). That doesn't mean either way is better than the other, it means that there are different groups of people with different skills and preferences. Just like command line users ought to admit that GUI-based development tools are useful to some, the reverse ought to be conceded too.
What is an open question to me is whether the two kinds of styles can co-exist in the same community. Will I be able to make sense of, and contribute to, your libraries developed in KDevelop using my programming tools? Will you be able to handle modifications that I make to them outside KDevelop? I have dealt with MFC by hand, moved software packages back and forth between VC++ and the command line, etc., and I'm not that optimistic in the long run.
Tools like VC++ and KDevelop tend to encourage much of the intelligence to move into the development environment, making the actual code difficult to read and maintain any other way. And, conversely, tools like VC++ and KDevelop tend not to be able to make a lot of sense of interesting abstractions implemented "by hand".
Maybe my concerns are unfounded: KDevelop, KDE, and Qt are a lot cleaner than VC++ and MFC, and KDevelop tries to fit in well with the current Linux development styles (in fact, I'd much rather use KDevelop than VC++). But I'm not convinced that in the long run, this can work out.
So, Linux may well split into a Windows-like community and a UNIX-like community, with less and less code sharing between them as time goes by. That's probably still better than a MS Windows/Linux split, but maybe by thinking about it ahead of time, we can at least make such a transition easier and have realistic expectations.
However, that doesn't mean that one should abandon all thought on what the consequences of particular developments are. What happens if Microsoft ports Office to Linux and releases it? What happens if Linux development becomes more and more Windows-like?
Your answer seems to be that it doesn't matter: there will simply be more and more distributions catering to different tastes. That may turn out to be the case. I hope so, because I think that's the best of all worlds.
But it isn't the only way things can unfold. he fact that many of the Windows UI windows don't resize, that they lock each other, that MFC has serious flaws in its inheritance hierarchy, that the Windows requires various kinds of even tables, etc., are all consequences of a particular approach to programming.
Some of those issues are related to historical developments, some to programming style prevalent in the Windows community, and some are related to the use of an environment like VC++: it allows people to fix problems by building wizards and graphical tools that then generate complex source code that is difficult to maintain by hand.
It's useful to think about this ahead of time because a lot of the design you see in the Linux kernel, GNU libraries, and Linux libraries comes out of a tradition and development environment that made certain things hard and therefore forced people to come up with different (I think better) designs. I believe that traditional UNIX environment forced you to design more cleanly, build general tools, and build good abstractions, because it simply didn't support good visualizations and expedient fixes.
I believe it is worth thinking about these issues now while KDevelop and tools like it aren't that widely used yet. Maybe we can improve the way the two approaches to programming can live side-by-side. Maybe it doesn't matter because KDevelop might not catch on. Or maybe your optimism is warranted and different communities of people will just use different distributions, all somewhat interoperable.
Of course, I'm not entirely sure why this is a good thing. GNU&Linux wasn't built or used by people who approached programming that way. Is KDevelop going to bring a lot of developers from Windows to Linux? What kind of changes will they want in Linux? And what will that mean to the traditional GNU&Linux communities?
I think there is a lot of interesting stuff to be done in the traditional text-based GNU/Linux/UNIX approach to programming. Here are just some simple ideas:
KDevelop is glitzy. It's a big and impressive development effort. It's probably useful for people who want to build Windows-like applications with a Windows-like IDE. I can even see why people have fun developing it.
But, ultimately, KDevelop looks foreign to me in a UNIX environment and less useful for traditional UNIX uses and users. I'd like to see more effort go into building tools in the traditional UNIX style (and I'm trying to help when I can).
If you are a paying customer and don't get what you have been promised, you can complain. If you get free software and don't get what you have been promised, you can volunteer.
In the process of downloading a browser plugin, you get a lot more information about the plugin and a lot more opportunity to find out more about it. That's a security feature. And that's why plug-ins are much less evil than ActiveX.
Of course, proper sandboxing, as in Java and Tcl, is the best answer.
And they control upgrade paths: every ten or so years, you will get a new, "enhanced" format that requires you to repurchase your entire collection of media.
Contrast that with MP3. Because MP3 is open and media independent, it's archival: if you have paid for some piece of music once, you and your heirs can access it in perpetuity.
Furthermore, with an open format like MP3, you'd get more and more free content, from people who perform music and theater for fun. Much of that isn't going to be very good, but some can be excellent. With the kind of format the RIAA is pushing for, they'd get their cut even from such productions, through license fees and inflated production costs.
Technology promises to bring us, finally, the ability to share artistic content freely, and the established media companies are trying to thwart this. I think, ultimately, the RIAA and MPAA efforts are doomed to failure. But if we don't watch out, we may be in for a very unpleasant few decades where content remains unnecessarily expensive and limited.
None of those machines have caught on. The reason is that generally, you seem to do better if you invest the same kinds of resources into just making your processor faster.
Simply implementing existing malloc/free algorithms in hardware is unlikely to help. Those are complex algorithms with complex data structures, and they are probably memory limited. Where hardware could help is by changing the representation of pointers themselves: adding tag bits that are invisible to other instructions (allowing pointers and non-pointers to be distinguished, as well as space for mark bits), and possibly representing pointers as base+offset or some other kind of descriptor that makes it easier for the allocator to move memory around without the C/C++ program knowing about. As a side benefit, this kind of approach could also make C/C++ programs much safer and help run languages like Java faster.
But altogether, after having seen several attempts at this, I'm not hopeful. Unless Intel or Motorola do this in a mainstream, mass market processor, it will be very expensive and not perform as well. If you want those features, you end up getting better performance at a lower price by simply buying a mainstream processor without the features and simulating what you need.
And if you think you can catch those problems reliably with a careful test of the binary code, you are kidding yourself. Very common kinds of bugs in those components (off-by-one errors, buffer overflows, changes to the floating point modes, etc.) can cause very subtle problems in other parts of the system. Without language/runtime suport, you won't find them, support that C/C++ doesn't have. And even if you could catch those errors, what would you do? Throw out the system-supplied standard libraries? the GUI toolkit you are using?
BTW, I have written a lot of C/C++ code, and continue doing so. But that's for research and experimentation. For multi-programmer code that goes out the door, Java, Modula, Eiffel, Python, and other, safer languages are clearly vastly superior.
At the heart of the problem is that C/C++ don't have a standard way for programmers to specify information that is important for efficient runtime checks.
In particular, in C/C++, the "pointer/reference" construct is used for arrays, references to local variables, call-by-reference, raw memory manipulation, format conversions, and some other purposes. But because you can't tell the compiler which of those you are intending to do, they compiler can't check for you efficiently--it has to check all the possibilities.
This lack is a peculiarity of the C/C++ family of languages. It has nothing to do with power or lack thereof. You could add the necessary constructs to C/C++ without removing any of the power. C/C++ are simply deficient in a number of important language constructs. Java may lack template constructs, but C/C++ lack crucial typing constructs.
As for "with better coders, it doesn't have to be a problem", that may work for very well run organizations developing all their own code. And even for them, the required testing cost them plenty in time-to-market and testing resources.
For the rest of us, who try to reuse commercial components and libraries, we simply don't have control over the testing that goes into the components we have to use. For starters, if you develop on Windows or Linux, you are already relying on millions of lines of source code that were developed with enthusiasm, but hardly the kind of quality control that ensures "no pointer errors in half a million lines of code". Quite to the contrary, both of those systems are known to contain plenty of pointer errors. And those errors can cause silent, serious errors, for example in a financial application.
The net effect of this is, of course, not innovation. Rather, it increases barriers of entry to new companies who don't have patent portfolios to trade (this is seen as an advantage by established companies). Furthermore, it increases the cost of doing business, because all that patent activity costs lots of money and time. I estimate that in a corporate environment, each patent that is filed probably costs around $50k (there are a lot of highly paid lawyers and engineers involved in each patent).
Ultimately, the US patent office needs to stop this kind of abuse by reviewing patent applications more dilligently and not expanding notions of patentability as they go along. Individual companies are ultimately powerless: if they try to be high-minded about it, they'll simply go out of business.
And it's pretty clear that the US patent office is at fault. Apologists for them say that there is really no basis on which to criticize them. But there is actually a pretty straightforward metric: you can simply look at the kind of technical and legal comments you get from the US patent office vs. the European patent offices on the same patent application. The European patent office generally make competent evaluations, understand prior art quite well, and impose clear limitations on claims. The European patent offices are also much more reluctant to expand notions of patentability, usually only being pushed along by the US. From those, direct comparisons, it's pretty clear that there is a lot of room for improvement at the US patent office.
Nevertheless, I find that even by the currently low standards of patentability used by US businesses, priceline.com and amazon.com are pushing the limits. They can be justly criticized for that. It's one thing to go along with the crowd because you have to, it's quite another thing to try to deliberately push the boundaries. For that reason, I boycott Amazon, Priceline, and similar sites (I spend several thousand dollars in books and airfare each year, so this isn't an empty threat).
Most people seem to have come to accept the fact that their word processor, browser, and operating system crash with obscure register dumps with some regularity. But to a large degree, many of those problems are the heritage of some old design decisions in the C programming language, inherited by C++ and Objective-C. In fact, I think many of the serious problems we have with computers can be traced to lack of support for fault isolation and runtime safety in the languages we use, either directly (programs crash/have security holes) or indirectly (time that could go towards improving software needs to be spent on unnecessary testing/debugging).
It isn't very difficult to come up with a programming language that is like C (or C++ or ObjC) but also provides support for runtime safety and fault isolation. You don't need to sacrifice any efficiency or systems programming features. But C++ has, so far, dropped the ball on this. Some of its abstraction facilities (e.g., the "string" class) alleviate some of the problems if used properly, but there are no guarantees you can make about any piece of C++ code, and even if you are careful, you can't avoid unsafe constructs in code that ought to be safe.
That's why Java is catching on. Java may be lacking templates, systems programming support, multiple inheritance, and lots of other features. Java is also slow and heavy by comparison to C/C++. But Java does provide fault isolation and runtime safety, and in the end, that is what matters most to application programmers that need to get out reasonably reliable software on a tight schedule.
In fact, a number of components of such a system already exist and have been released in open source form (some of them by companies I have worked for), including H.xxx CODECs, MPEG CODECs, streaming media servers, etc. We also have good cross-platform toolkits for writing generic clients.
I disagree that having a proprietary solution on a free OS is preferable to having a proprietary solution requiring a proprietary OS in this case. If we go down that route, we may well end up with all proprietary software, formats, and protocols and only an open source kernel; what's the point of that? Supporting proprietary clients using proprietary protocols on a mainstream Linux distribution will simply help make those protocols more entrenched.
I think decisions like these are also important for RedHat's image. My organization is considering standardizing on some Linux distribution. We like Linux because it is based on open standards. RedHat has been very supportive of open source software and open standards so far, and has been sponsoring a number of open source development efforts. We want to do business with a company that continues to show that kind of commitment to open source.
Even if RedHat ships Real Networks software in the short run, I very much hope that RedHat will take the initiative and support a truly open source streaming media system. Streaming media are too important to leave them to a single company.
In particular, many documents in a corporate environment contain templates, input fields, and scripts/macros. MS Office also supports revisions, indexing/search, and database functions. None of the MS Office clones handle the full range of day-to-day documents that appear in a corporate environment, both because they lack compatible macro/scripting capabilities in particular, and because they lack some of the other, seemingly more esotheric features in general.
A lot of people have spent a lot of time learning, and come to depend on, the idiosyncracies of MS Office. Anyone who wants to displace it faces an uphill battle. At the very least, a credible alternative must provide good import/export, scripting, macro, and template support (considerably better than any of the existing systems do). But there also would need to be support for workflow features (a web/server-based system might be an attractive alternative to the MS Office mess). And I think it would be essential to offer any open source Linux office suite on Windows as well to make the migration as easy as possible.
Of course, a more basic question to ask is still: while this could be done, why should the open source community bother? MS Office is ancient technology. Perhaps rather than focussing so much on cloning and displacing MS Office, maybe it would be better to explore new frontiers: better markup-based environments for text processing, data analysis tools that are less limited than spreadsheets, server/web-based workflow and groupware, easy end-user programming, etc. If people come up with something genuinely better, the users will come.
Using RealPlayer will only help their proprietary format get entrenched further. That means that we may have to live for a long time with their disregard for privacy and their haphazard clients. (I removed RealPlayer from my Linux machines a while ago.)
I think it would be better to look towards open alternatives and to contact web sites to use such alternatives. Streaming MP3 is a good choice for some applications. And there has been some work on other streaming media for Linux (e.g., here).
Furthermore, I think customers of RedHat should let them know that they prefer that RedHat support an open source streaming audio/media project, rather than bundling Real Networks software.
Unlike Ada or Java, C++ currently has no facilities that allow a programmer or software engineer to ensure that a fault (e.g. a pointer error) in one component does not cause errors in another component (the facilities that C++ has are advisory).
The traditional answer has been to use better overall software engineering and design. But that does not work in a world in which components come from various different sources with different standards and coding conventions.
Java has many problems, but it does have a commitment to runtime safety and fault isolation. And Java's promise really works out in practice: we can combine dozens of independently developed components and trace any software faults to specific components reliably. We'd like to have the safety and decomposability of Java with the efficiency and control of C++, but given the choice, safety and decomposability usually win out for day-to-day applications for us.
So, what does the future hold for C++ runtime safety and fault isolation? Will future C++ standards mandate more facilities than exist right now? If not, how do you think C++ can survive in a world where software is composed of hundreds of independently developed components?