Which one is "best" really depends on your specific needs. I generally use JFC a lot (I think it's a very well designed and very complete toolkit), and do some small hacks in Tcl/Tk.
As for the C/C++-based toolkits, none of them are particularly fun to use, and I think that's really the fault of the underlying languages. Neither C nor C++ are particularly conducive to writing GUI applications (but with enough effort, anything can be done). Among the C/C++ toolkits, I like GTK+ best. Qt isn't bad, but because it's C++ based, its uses are more limited.
OpenStep looks like a great system, and I have used small bits and pieces of it, but the lack of standardization of Objective-C and its limited availability make it an impractical choice for me.
MFC/Win32, however, wins the prize for being the uniformly worst designed and worst implemented GUI toolkit I have ever used, but its popularity makes it unavoidable sometimes.
So, I use multiple GUI toolkits, depending on what I need to do. And different people prefer different toolkits depending on their needs and constraints.
Java and VRML are two existing open standards that have the power to render a lot of neat graphics and multimedia content. Java 1.2 and the media-related packages will be incorporated into the next browser releases and offer a lot more neat features when it comes to audio, video, and animation.
As for the "I need solutions NOW", I doubt it. Eventually, web designers may figure out how to incorporate multimedia content for the benefit of their site visitors (e.g., for maps and diagrams), but right now, Flash and Director are mostly used as gimmicks and probably end up driving more users away.
As I interpret Macromedia's past moves, they always try to remain as proprietary as possible. It seems to me that the only reason they released specifications for Flash is because they feared competition from the W3C's open vector formats.
Macromedia is, of course, free to do whatever they want with their software. But as consumers, we are also free to decide what we use and what we don't use.
If you care about free software or open standards, I'd recommend staying away from Macromedia products and formats as much as possible. There are several open alternatives available for creating multimedia content for the web. And if they don't do what you need yet, get involved in their open standardization processes.
Alpha seems like a much better processor design to me than Merced and its successors.
But Intel understands one thing that DEC doesn't seem to: providing a free, open source C/C++ compiler is essential for success with free software. In effect, that approach recoups the cost of compiler backend development from the people who buy the chip; charging for the compiler puts the burden on the software developers. But since developers of free software already donate their time, charging them for the compiler doesn't make a lot of sense.
In different words, at least in the open source world, the GNU C/C++ compiler is essentially part of the processor itself, and if GNU C/C++ doesn't perform well, then it doesn't matter much how fast the processor is with some proprietary compiler.
Unless DEC sponsors work for improving the gcc backend for Alpha to be competitive with their own proprietary compiler, my guess is that the 64-bit Intel chips are going to win.
Running one OS on a variety of platforms and processors is very useful: it ferrets out platform dependencies and bugs, it encourages hardware competition, and it discourages vendors from shipping binary-only versions.
All the processor dependencies that have crept into Windows and its software architecture (ActiveX, drivers, etc.) are one of the biggest problems Windows is facing, and it is good if Linux can avoid falling into the same trap.
This sort of thing may not matter to technical folks, but it does matter to investors, lawyers, and politicians. As long as those people consider Microsoft an innovative company and Gates a technical wizard, Microsoft will outcompete other companies for investments, and lawyers and politicians will take a hands-off approach to Microsoft.
Whatever cases you make, please just make sure you shield them correctly. Unshielded computers are a major headache to your fellow geeks who operate radio and wireless equipment.
I believe there are conductive transparent plastics or films that may work for shielding transparent cases, so please do some research.
There are, in fact, already lots of application rentals. They come in two forms: you rent an application and install it locally (used with high-end business apps), or you pay a monthly fee for using applications on a remotely hosted system (used both with business apps and increasingly Internet-based services).
While that may sound horrible to us technical folks, actually for many applications it could be quite nice: you don't have to install or maintain the software, and it becomes accessible from anywhere. For mail, text editing, spreadsheets, printing and snailmail, FAX, etc., that sounds like a real winner. With a suitable platform (UNIX, Java), you might even be able to rent compute cycles for general purpose computing, again, without the headaches of maintaining your own system.
It will be interesting to see how Microsoft believes this will work with their software and what kind of business advantage they have in that area. Right now, the only credible client plaform for delivering such services would seem to be Java, since ActiveX is too machine dependent and not secure or safe enough.
The issues of who pays for the "free servers" is what makes it tricky.
Companies like AOL, on the other hand, naturally try to finance the servers through advertising and are understandably wary of third party clients.
Ideally, IM service would be provided by ISPs, just like they provide SMTP service. But ISPs have little incentive to provide any kind of IM service until there is a large demand for it, and that won't happen until a protocol has been established.
A distributed advertising protocol linked to chat, similar to the way banner ads have worked with companies like LinkExchange in the past, might be a short-term solution. Once the service is off the ground, it may then simply become a must-have for ISPs.
AOL's protocol is for building clients that talk to a central, proprietary server. That's undesirable for an Internet-wide IM infrastructure, and whether it's open source or not doesn't matter much.
Instant messaging should work roughly like mail: distributed and ubiquitous, without ties to advertising or a single vendor. ISPs should provide the necessary infrastructure just like they provide SMTP services (in fact, some mailers have support for instant messaging, but that hasn't caught on in an ISP-based world).
I wouldn't blame AOL for not building such an infrastructure--it just has nothing to do with their business. The open question is whether the newly commercialized Internet actually allows for new protocols like a vendor independent IM protocol to catch on and become ubiquitous in the same way SMTP, HTTP, and many of the other classic protocols caught on.
There are several printer drivers like that available for a variety of purposes (none of them free/open source AFAIK, though).
Also, you can simply print from Windows to a Linux Samba server and tell Windows that it is a PostScript printer. That way, there is nothing at all to install. On the Linux side, you can convert to PDF.
I have been using XFS and JFS-based systems for several years and I'm unimpressed.
I have more experience with JFS because I have used it in some large applications; I have been running XFS on my desktop Irix machine for a couple of years.
Here are some observations about JFS; most of those also apply to XFS:
It can be quite slow in practice; for example, untarring a large amount of scientific data, JFS took three times as much time as ext2, even though it was running on a faster SCSI disk. I haven't done XFS measurements, but XFS also feels sluggish in practice to me.
It only protects file system structure, not file content.
It only protects against a small set of failures. For example, hardware failures and file-system related bugs still cause data loss.
JFS comes with a LVM (volume manager) and XFS integrates XLV. In my experience, those kinds of systems complicate disk management, increase the risk of file system management mistakes, and make it more difficult to predict performance.
Journalling does not guarantee fast recovery. There may still be extensive recovery going on at boot time. IBM's JFS, ironically, often runs on systems that have (unrelated) performance bottlenecks in their boot code that makes them some of the slowest booting UNIX machines in existence.
The only time I have actually lost a partition over the last decade was on a journalling file system due to, what appears to have been a software bug in the fs code. Journalling file systems are tricky pieces of software to write.
Of course, with XFS on Linux, we can finally compare these issues side-by-side on identical hardware and kernels. It will be interesting how XFS holds up.
XFS has some nice features, and I think it will be a great addition to Linux as an optional file system. Its availability will make Linux much more attractive to some corporate buyers.
But before adopting it widely, I believe the issues that I raise above need to be looked into and evaluated carefully. I suspect many people don't need the features of XFS, overestimate the safety of journalling file systems, and will get bitten by the complexities and overhead. I hope XFS will not preempt the further development of "traditional" Linux file systems.
You forgot one important difference: Windows 2000 is a commercial product, produced by a company that charges a heavy premium, and apparently bent on taking over 100% of the OS market.
Every bug you report and every enhancement you suggest to Microsoft, whether in this test or in their office suites, saves them lots of money in quality control and lost sales. It brings them one step closer to crowding out all their competitors. And, to add insult to injury, they will probably increase the prices later because their product is better, based on your suggestions.
I'd concentrate on testing and bug reporting for Linux. That way, you yourself are the beneficiary of your bug hunting; you don't pay for it twice.
Microsoft's claim is that commercial, for profit development is better. Well, then let them pay for their quality control themselves. Trying to weasel quality control out of their customers is just tasteless in my opinion.
What the hell is this? quite frankly, windows is almost perfectly compatible.
Backwards compatibility isn't the same as lack of fragmentation.
Major chunks of the APIs are different or missing between the different Windows versions (even leaving CE out of the equation). What is shared is often incompatible in subtle or not so subtle ways. And a lot of the backwards compatibility is only a short-term workaround and impractical (do you really think you can use an 8.3 version of Word on NT for long before it becomes a logistical nightmare?).
Similarly, in theory, you can keep your old source code and still compile it. But in a commercial development environment, that's not really an option. When Microsoft comes out with MFC, ATL, or a new database access library, you have to use the new stuff to be able to take advantage of the new features and remain competitive, and that often requires a fundamental rewrite of your application.
Which matters to you more as a developer and user depends. But I think it is accurate to say that the Windows platform is quite fragmented, even though it may offer a lot of backwards compatibility.
While there aren't seven incompatible versions of Windows, there is a lot of fragmentation on Windows platforms.
Among the two major product lines, consumer Windows (95/98/98SE) and small business Windows (NT3.51, NT4, NT2000), there are lots of differences and incompatibilities; even major chunks of the APIs are different. Then, there is CE, which is really just a completely different operating system.
With all that complexity, Microsoft's operating systems still don't scale over a large range of hardware: all you get is systems that run from hefty PDA to small server. Linux spans that range with just a single OS and API. UNIX/POSIX systems more generally run from on anything from small, embedded, real-time system to the largest scientific supercomputers, parallel machines, and mainframes.
Compared to UNIX/POSIX, I find that both the interoperability and the scalability of Windows platforms are disappointing.
Machine learning, pattern recognition, agents, and artificial intelligence are likely to become very important in security. But while the analogy to biology sounds nice, and people may even derive some useful inspiration from it, but it is pretty weak on the whole.
If you do take the analogy serious, it actually doesn't look so good for computer security. Biological immune systems protect populations, not individuals. A species can afford to have a few percent of the population die from immune system related diseases (oops--misrecognized the Linux kernel as a virus) or to have a quarter of the population be susceptible to a particular virus.
To deal with those issues, the "computer immune" system does something no biological system does: it uses a global repository for virus data.
Finally, most organisms on this planet live perfectly happily without immune systems; it's far from clear that that's a good design point. They just have good, strong biochemical defenses built-in; perhaps that's the best analogy for computers after all.
Federal three-letter agencies strongly oppose export of encryption. The move is clearly not designed to make encryption inaccessible to criminals (since it's easy to get around the export controls), but to prevent strong encryption from becoming part of the day-to-day communications infrastructure.
Upcoming cell phone standards must include GPS or similar in the handsets so that the location of each phone can be determined easily.
Echelon and other projects suggest that widespread monitoring of voice and data communications has been carried out in the past and will continue to be carried out.
Store and mail order purchase data is recorded for marketing purposes, but also available to law enforcement on demand (c.f. Lewinsky's book buying habits). Purchases of some legal materials (e.g., hydroponics, fertilizer, etc.) could result in closer scrutiny by law enforcement.
With some current anti-theft devices and car computers that record trip data for maintenance purposes, the whereabouts of your car and your driving habits may be recorded and available to law enforcement.
Public, traffic, and private surveillance cameras are becoming very commonplace, and their data is increasingly networked and stored in digital form.
Law enforcement, banks, and medical providers are collecting DNA databases, fingerprint databases, iris databases, dental databases, medical databases, and other biometric databases for a variety of purposes. With that information on-line, it becomes very quick and easy to establish the presence of any person at pretty much any location.
Large, anonymous cash transactions are essentially impossible in the US these days, as is the import/export of significant amounts of money without government scrutiny.
Much of the data that is being collected is inaccessible by the individuals it's being collected on. Much of it is stored in proprietary databases with no requirements to give anybody (other than law enforcement) access. Even data collected by security agencies and law enforcement may not be available during routine legal proceedings, since the government may make an argument that revealing the full extent of the data collected on you would hamper future data collection efforts. That is, data may be used against you, but you may not be able to obtain access to it for your own defense.
Now, I don't think this is one big conspiracy. Each of the individual decisions may make sense, but the overall result is that the government, and possibly other people with enough money, can find out just about anything about you that they want to.
This might not be quite so bad if everybody understood clearly the possibilities. But most US residents still seem to assume that their privacy is protected, that their conversations are private, and that a purchase at most results in annoying junk mail.
Similarly, the legal system and juries have no basis yet for judging the new realities. For example, setting penalties for anything from traffic violations to murder has not only been based on the severity of the infraction, but also on the likelihood being caught; penalties for speeding and car pool violations are high because people get away with them most of the time. If photo enforcement changes that, it completely changes the equation.
There is also considerable potential for abuse of such data. Information gathered by these means may not reveal illegal behavior, but law enforcement may still be used to embarrass and harrass potential witnesses or suspects.
The US strikes me like one of the countries furthest along in eroding privacy rights. For example, in many other countries, strong encryption is legal, large cash tranasactions are not subject to reporting requirements, and buying plant growing equipment doesn't automatically make you suspect of growing pot (or if it does, it may simply be legal).
Many of those mechanisms have been put into place under the umbrella of the "war against drugs", "anti-terrorism measures", and "protecting US defense secrets". But the societal costs resulting from the compromises that needed to be made to achieve those goals are not well understood. I must admit, the US government's obsession with drugs, terrorism, and defense secrets strikes me as bordering on collective paranoia.
We may well be able to live comfortably in a world in which all of our actions are very transparent and accessible to a wide variety of government agencies and businesses. But the combination of 19th/20th century laws, behaviors, and assumptions of privacy together with 21st century surveillance, tracking, and database technology strikes me as very dangerous. Either we have to regulate surveillance uses of these new technologies and enact strong privacy regulations, or our society has to undergo some profound transformation to deal with the new realities.
I agree that the enormous income disparity in the US is worrisome. And Gates happens to be the figurehead for that issue as well.
But you can't blame Gates for that--that's a political and social issue for all of US society to deal with: people who run successful businesses become enormously wealthy in the US. And it's not the wealth that bothers me (whatever makes people happy), but the enormous poverty and suffering of the bottom 20% that seems to go along with that kind of income distribution.
As for Gates, if he sticks to his promises about charitable donations, he will have done pretty much all you could ask from him to do his part.
The focus on Gates as a person seems to be mostly a fixation of the media and financial community. And not a very sensible one--it seems to me that inside Microsoft, it's Ballmer who runs the show, and the 20-somethings that make the technical decisions.
I don't like Microsoft for their technologies, just like I don't like Macdonald's food or Hertz customer service. But unlike Macdonald's or Hertz, avoiding Microsoft is becoming very difficult, no matter how poor I may think their products are. It's that monopoly position, that to me mostly seems to be the result of network effects and monopolistic practices, that bothers me.
I wonder what it is in Rivlin's background that causes him to see this as an epic struggle of hero versus villain, rather than as the technical and economic issue that it is. To the degree that Gates matters at all, he is simply the current figurehead of Microsoft. If he resigned and got replaced by someone else, nobody would care much about Gates anymore.
The failure for technical people to "bring down Gates" is probably a result of the fact that it isn't about bringing down Gates--it's about open protocols, open access, and choice. And it seems to me the technical community has been quite successful there, and there is enormous momentum in that area. If Gates and Microsoft prosper in an open, non-proprietary world (and I see no reason why they shouldn't), all the better for them.
People seem to view Windows-style development tools as one of the better aspects of Windows. But I suspect they are actually at the heart of what has made Windows such a mess.
Windows-style development tools allow both the API designers and the application programmers to delay facing up to, and fixing, serious design problems with their systems.
For example, the MFC class libraries have serious problems in their inheritance hierarchy, but rather than fixing them, Microsoft just adds a bunch of wizards to their development tool to do manual delegation.
Similarly, the VC++ GUI design tools result in GUIs that, for the most part, use fixed layouts that don't work well at different resolutions, and they generate code that is difficult to maintain.
To me, Windows-style development tools give the appearance of making development easier, but in the long run they have a negative impact on the quality of both the OS and the application code.
Bringing a lot of the Windows development tools to Windows risks bringing Linux down to the same level as Windows. I hope that the traditional Linux community will be strong enough to keep those kinds of influences from doing real damage.
Linux development tools aren't perfect, of course, but I think Windows-style development tools are the wrong place to look for improvements. We don't need more windows or buttons, we need better tools support for specifying, composing, analyzing, and verifying large software systems.
(In case you are wondering, yes, I have developed in VC++, Borland, and UNIX, and I'm currently a full MSDN subscriber.)
As far as I can tell, Sun's more recent OpenStep-related acquisitions were deliberately and clearly made in order to support Java development. There was nothing stealthy about it.
I think that kind of move makes sense. Unfortunately, even though their system software is quite good, Sun doesn't seem to be very good at end-user applications. Even their development environments were only so-so. But, of course, a purchase like this could change that.
I talked to Adobe representatives at JavaOne. They were showing a PDF reader written in Java.
I think open sourcing this would be a good start if they were serious about open source; there are lots of useful, new applications of Adobe's PDF protocol that that would enable.
The response was disappointing. Even though they said they weren't making any money on PDF readers, the stated that it was very unlikely that they would open source it. They also seemed fairly bearish on the outlook of the company as a whole.
We should be fairly happy that Adobe at least publishes reasonably usable PostScript and PDF specifications eventually. Unless they have a big change of heart (or get taken over), I don't see a lot more coming out of that company.
I don't see anything evil about it: IP masquerading does what it does and it's useful at that. It is halfway between having separate machines and having a true cluster of computers.
SOCKS works in user mode; I don't see any advantage to that. If you want bidirectional firewall traversal, you could implement similar functionality in the kernel. You need to either notify the firewall machine that a socket on the client is accepting connections and that needs to be forwarded to the firewall machine, or when there is a request coming in, the firewall machine has to try until it finds a machine willing to service it.
Most people don't need, and in fact, don't want that functionality. But people who do already get it: it's part of clustering.
When Microsoft originally came out with Windows and their development tools, I had high hopes for them. They had had the option to start from scratch and come out with a GUI-based system that was easy to develop to, powerful, and had high quality libraries. Surely, a company with those resources and a company that supported commercial developers, can do much better than X11, Motif, and POSIX.
Instead we got Visual C++, Win32, MFC, COM, and all the rest of it.
And things have been getting worse, rather than better.
Microsoft's APIs, "drag-and-drop" approach to programming, non-round-trip wizards, lack of runtime safety, lack of API error checking, and dozens of released attempts at getting some APIs right, to name just a few, make Windows programming the most painful kind of programming I know.
But worst of all, their "designs" just lack coherence. It may take me a few hours to figure out the design and functionality of GTK or X11 or Berlin or Qt or Zope or many other libraries designed for UNIX. There are a few parts of Windows that are similarly coherent. But, for the most part, after more than five years of Win32, I still don't "get it", and I have yet to meet anybody who does. Microsoft seems to have a nack for taking basically good ideas (message passing, MVC, core-COM, etc.) and turning them into systems that make the Winchester Mystery House look tame by comparison.
BTW, I'm among the "1 million programmers" signed up for their developer program (MSDN, full subscription), as are many of my friends and colleagues. Also, a lot of "Windows programmers", in particular on the server side, are simply UNIX programmers that do the minimum amount of work necessary to make UNIX server software work on NT, without ever using a lot of Microsoft's APIs. And, as I like to quip when people marvel at the amount of software for Windows, "Windows has 50000 application programs for it, 45000 of which are there to fix bugs, provide missing OS functionality, and work around UI problems in Microsoft Windows".
Yes, I think Microsoft should be worried about this: this is a hard problem they are up against. Their usual approach of adding more code and APIs to the system won't fix it--it's at the heart of their problem.
Slashdot Mirror
As for the C/C++-based toolkits, none of them are particularly fun to use, and I think that's really the fault of the underlying languages. Neither C nor C++ are particularly conducive to writing GUI applications (but with enough effort, anything can be done). Among the C/C++ toolkits, I like GTK+ best. Qt isn't bad, but because it's C++ based, its uses are more limited.
OpenStep looks like a great system, and I have used small bits and pieces of it, but the lack of standardization of Objective-C and its limited availability make it an impractical choice for me.
MFC/Win32, however, wins the prize for being the uniformly worst designed and worst implemented GUI toolkit I have ever used, but its popularity makes it unavoidable sometimes.
So, I use multiple GUI toolkits, depending on what I need to do. And different people prefer different toolkits depending on their needs and constraints.
As for the "I need solutions NOW", I doubt it. Eventually, web designers may figure out how to incorporate multimedia content for the benefit of their site visitors (e.g., for maps and diagrams), but right now, Flash and Director are mostly used as gimmicks and probably end up driving more users away.
Macromedia is, of course, free to do whatever they want with their software. But as consumers, we are also free to decide what we use and what we don't use.
If you care about free software or open standards, I'd recommend staying away from Macromedia products and formats as much as possible. There are several open alternatives available for creating multimedia content for the web. And if they don't do what you need yet, get involved in their open standardization processes.
But Intel understands one thing that DEC doesn't seem to: providing a free, open source C/C++ compiler is essential for success with free software. In effect, that approach recoups the cost of compiler backend development from the people who buy the chip; charging for the compiler puts the burden on the software developers. But since developers of free software already donate their time, charging them for the compiler doesn't make a lot of sense.
In different words, at least in the open source world, the GNU C/C++ compiler is essentially part of the processor itself, and if GNU C/C++ doesn't perform well, then it doesn't matter much how fast the processor is with some proprietary compiler.
Unless DEC sponsors work for improving the gcc backend for Alpha to be competitive with their own proprietary compiler, my guess is that the 64-bit Intel chips are going to win.
All the processor dependencies that have crept into Windows and its software architecture (ActiveX, drivers, etc.) are one of the biggest problems Windows is facing, and it is good if Linux can avoid falling into the same trap.
This sort of thing may not matter to technical folks, but it does matter to investors, lawyers, and politicians. As long as those people consider Microsoft an innovative company and Gates a technical wizard, Microsoft will outcompete other companies for investments, and lawyers and politicians will take a hands-off approach to Microsoft.
I believe there are conductive transparent plastics or films that may work for shielding transparent cases, so please do some research.
While that may sound horrible to us technical folks, actually for many applications it could be quite nice: you don't have to install or maintain the software, and it becomes accessible from anywhere. For mail, text editing, spreadsheets, printing and snailmail, FAX, etc., that sounds like a real winner. With a suitable platform (UNIX, Java), you might even be able to rent compute cycles for general purpose computing, again, without the headaches of maintaining your own system.
It will be interesting to see how Microsoft believes this will work with their software and what kind of business advantage they have in that area. Right now, the only credible client plaform for delivering such services would seem to be Java, since ActiveX is too machine dependent and not secure or safe enough.
Companies like AOL, on the other hand, naturally try to finance the servers through advertising and are understandably wary of third party clients.
Ideally, IM service would be provided by ISPs, just like they provide SMTP service. But ISPs have little incentive to provide any kind of IM service until there is a large demand for it, and that won't happen until a protocol has been established.
A distributed advertising protocol linked to chat, similar to the way banner ads have worked with companies like LinkExchange in the past, might be a short-term solution. Once the service is off the ground, it may then simply become a must-have for ISPs.
Instant messaging should work roughly like mail: distributed and ubiquitous, without ties to advertising or a single vendor. ISPs should provide the necessary infrastructure just like they provide SMTP services (in fact, some mailers have support for instant messaging, but that hasn't caught on in an ISP-based world).
I wouldn't blame AOL for not building such an infrastructure--it just has nothing to do with their business. The open question is whether the newly commercialized Internet actually allows for new protocols like a vendor independent IM protocol to catch on and become ubiquitous in the same way SMTP, HTTP, and many of the other classic protocols caught on.
Also, you can simply print from Windows to a Linux Samba server and tell Windows that it is a PostScript printer. That way, there is nothing at all to install. On the Linux side, you can convert to PDF.
I have more experience with JFS because I have used it in some large applications; I have been running XFS on my desktop Irix machine for a couple of years.
Here are some observations about JFS; most of those also apply to XFS:
Of course, with XFS on Linux, we can finally compare these issues side-by-side on identical hardware and kernels. It will be interesting how XFS holds up.
XFS has some nice features, and I think it will be a great addition to Linux as an optional file system. Its availability will make Linux much more attractive to some corporate buyers.
But before adopting it widely, I believe the issues that I raise above need to be looked into and evaluated carefully. I suspect many people don't need the features of XFS, overestimate the safety of journalling file systems, and will get bitten by the complexities and overhead. I hope XFS will not preempt the further development of "traditional" Linux file systems.
Every bug you report and every enhancement you suggest to Microsoft, whether in this test or in their office suites, saves them lots of money in quality control and lost sales. It brings them one step closer to crowding out all their competitors. And, to add insult to injury, they will probably increase the prices later because their product is better, based on your suggestions.
I'd concentrate on testing and bug reporting for Linux. That way, you yourself are the beneficiary of your bug hunting; you don't pay for it twice.
Microsoft's claim is that commercial, for profit development is better. Well, then let them pay for their quality control themselves. Trying to weasel quality control out of their customers is just tasteless in my opinion.
Backwards compatibility isn't the same as lack of fragmentation.
Major chunks of the APIs are different or missing between the different Windows versions (even leaving CE out of the equation). What is shared is often incompatible in subtle or not so subtle ways. And a lot of the backwards compatibility is only a short-term workaround and impractical (do you really think you can use an 8.3 version of Word on NT for long before it becomes a logistical nightmare?).
Similarly, in theory, you can keep your old source code and still compile it. But in a commercial development environment, that's not really an option. When Microsoft comes out with MFC, ATL, or a new database access library, you have to use the new stuff to be able to take advantage of the new features and remain competitive, and that often requires a fundamental rewrite of your application.
Which matters to you more as a developer and user depends. But I think it is accurate to say that the Windows platform is quite fragmented, even though it may offer a lot of backwards compatibility.
Among the two major product lines, consumer Windows (95/98/98SE) and small business Windows (NT3.51, NT4, NT2000), there are lots of differences and incompatibilities; even major chunks of the APIs are different. Then, there is CE, which is really just a completely different operating system.
With all that complexity, Microsoft's operating systems still don't scale over a large range of hardware: all you get is systems that run from hefty PDA to small server. Linux spans that range with just a single OS and API. UNIX/POSIX systems more generally run from on anything from small, embedded, real-time system to the largest scientific supercomputers, parallel machines, and mainframes.
Compared to UNIX/POSIX, I find that both the interoperability and the scalability of Windows platforms are disappointing.
If you do take the analogy serious, it actually doesn't look so good for computer security. Biological immune systems protect populations, not individuals. A species can afford to have a few percent of the population die from immune system related diseases (oops--misrecognized the Linux kernel as a virus) or to have a quarter of the population be susceptible to a particular virus.
To deal with those issues, the "computer immune" system does something no biological system does: it uses a global repository for virus data.
Finally, most organisms on this planet live perfectly happily without immune systems; it's far from clear that that's a good design point. They just have good, strong biochemical defenses built-in; perhaps that's the best analogy for computers after all.
Now, I don't think this is one big conspiracy. Each of the individual decisions may make sense, but the overall result is that the government, and possibly other people with enough money, can find out just about anything about you that they want to.
This might not be quite so bad if everybody understood clearly the possibilities. But most US residents still seem to assume that their privacy is protected, that their conversations are private, and that a purchase at most results in annoying junk mail.
Similarly, the legal system and juries have no basis yet for judging the new realities. For example, setting penalties for anything from traffic violations to murder has not only been based on the severity of the infraction, but also on the likelihood being caught; penalties for speeding and car pool violations are high because people get away with them most of the time. If photo enforcement changes that, it completely changes the equation.
There is also considerable potential for abuse of such data. Information gathered by these means may not reveal illegal behavior, but law enforcement may still be used to embarrass and harrass potential witnesses or suspects.
The US strikes me like one of the countries furthest along in eroding privacy rights. For example, in many other countries, strong encryption is legal, large cash tranasactions are not subject to reporting requirements, and buying plant growing equipment doesn't automatically make you suspect of growing pot (or if it does, it may simply be legal).
Many of those mechanisms have been put into place under the umbrella of the "war against drugs", "anti-terrorism measures", and "protecting US defense secrets". But the societal costs resulting from the compromises that needed to be made to achieve those goals are not well understood. I must admit, the US government's obsession with drugs, terrorism, and defense secrets strikes me as bordering on collective paranoia.
We may well be able to live comfortably in a world in which all of our actions are very transparent and accessible to a wide variety of government agencies and businesses. But the combination of 19th/20th century laws, behaviors, and assumptions of privacy together with 21st century surveillance, tracking, and database technology strikes me as very dangerous. Either we have to regulate surveillance uses of these new technologies and enact strong privacy regulations, or our society has to undergo some profound transformation to deal with the new realities.
But you can't blame Gates for that--that's a political and social issue for all of US society to deal with: people who run successful businesses become enormously wealthy in the US. And it's not the wealth that bothers me (whatever makes people happy), but the enormous poverty and suffering of the bottom 20% that seems to go along with that kind of income distribution.
As for Gates, if he sticks to his promises about charitable donations, he will have done pretty much all you could ask from him to do his part.
I don't like Microsoft for their technologies, just like I don't like Macdonald's food or Hertz customer service. But unlike Macdonald's or Hertz, avoiding Microsoft is becoming very difficult, no matter how poor I may think their products are. It's that monopoly position, that to me mostly seems to be the result of network effects and monopolistic practices, that bothers me.
I wonder what it is in Rivlin's background that causes him to see this as an epic struggle of hero versus villain, rather than as the technical and economic issue that it is. To the degree that Gates matters at all, he is simply the current figurehead of Microsoft. If he resigned and got replaced by someone else, nobody would care much about Gates anymore.
The failure for technical people to "bring down Gates" is probably a result of the fact that it isn't about bringing down Gates--it's about open protocols, open access, and choice. And it seems to me the technical community has been quite successful there, and there is enormous momentum in that area. If Gates and Microsoft prosper in an open, non-proprietary world (and I see no reason why they shouldn't), all the better for them.
Windows-style development tools allow both the API designers and the application programmers to delay facing up to, and fixing, serious design problems with their systems.
For example, the MFC class libraries have serious problems in their inheritance hierarchy, but rather than fixing them, Microsoft just adds a bunch of wizards to their development tool to do manual delegation.
Similarly, the VC++ GUI design tools result in GUIs that, for the most part, use fixed layouts that don't work well at different resolutions, and they generate code that is difficult to maintain.
To me, Windows-style development tools give the appearance of making development easier, but in the long run they have a negative impact on the quality of both the OS and the application code.
Bringing a lot of the Windows development tools to Windows risks bringing Linux down to the same level as Windows. I hope that the traditional Linux community will be strong enough to keep those kinds of influences from doing real damage.
Linux development tools aren't perfect, of course, but I think Windows-style development tools are the wrong place to look for improvements. We don't need more windows or buttons, we need better tools support for specifying, composing, analyzing, and verifying large software systems.
(In case you are wondering, yes, I have developed in VC++, Borland, and UNIX, and I'm currently a full MSDN subscriber.)
As far as I can tell, Sun's more recent OpenStep-related acquisitions were deliberately and clearly made in order to support Java development. There was nothing stealthy about it.
I think that kind of move makes sense. Unfortunately, even though their system software is quite good, Sun doesn't seem to be very good at end-user applications. Even their development environments were only so-so. But, of course, a purchase like this could change that.
I think open sourcing this would be a good start if they were serious about open source; there are lots of useful, new applications of Adobe's PDF protocol that that would enable.
The response was disappointing. Even though they said they weren't making any money on PDF readers, the stated that it was very unlikely that they would open source it. They also seemed fairly bearish on the outlook of the company as a whole.
We should be fairly happy that Adobe at least publishes reasonably usable PostScript and PDF specifications eventually. Unless they have a big change of heart (or get taken over), I don't see a lot more coming out of that company.
SOCKS works in user mode; I don't see any advantage to that. If you want bidirectional firewall traversal, you could implement similar functionality in the kernel. You need to either notify the firewall machine that a socket on the client is accepting connections and that needs to be forwarded to the firewall machine, or when there is a request coming in, the firewall machine has to try until it finds a machine willing to service it.
Most people don't need, and in fact, don't want that functionality. But people who do already get it: it's part of clustering.
Instead we got Visual C++, Win32, MFC, COM, and all the rest of it.
And things have been getting worse, rather than better.
Microsoft's APIs, "drag-and-drop" approach to programming, non-round-trip wizards, lack of runtime safety, lack of API error checking, and dozens of released attempts at getting some APIs right, to name just a few, make Windows programming the most painful kind of programming I know.
But worst of all, their "designs" just lack coherence. It may take me a few hours to figure out the design and functionality of GTK or X11 or Berlin or Qt or Zope or many other libraries designed for UNIX. There are a few parts of Windows that are similarly coherent. But, for the most part, after more than five years of Win32, I still don't "get it", and I have yet to meet anybody who does. Microsoft seems to have a nack for taking basically good ideas (message passing, MVC, core-COM, etc.) and turning them into systems that make the Winchester Mystery House look tame by comparison.
BTW, I'm among the "1 million programmers" signed up for their developer program (MSDN, full subscription), as are many of my friends and colleagues. Also, a lot of "Windows programmers", in particular on the server side, are simply UNIX programmers that do the minimum amount of work necessary to make UNIX server software work on NT, without ever using a lot of Microsoft's APIs. And, as I like to quip when people marvel at the amount of software for Windows, "Windows has 50000 application programs for it, 45000 of which are there to fix bugs, provide missing OS functionality, and work around UI problems in Microsoft Windows".
Yes, I think Microsoft should be worried about this: this is a hard problem they are up against. Their usual approach of adding more code and APIs to the system won't fix it--it's at the heart of their problem.