I find handheld devices with optics in them to be rather difficult to look into for a long period of time. At the very least, it keeps one or both hands busy, making data entry hard.
Similar technology will soon be available for headmounted displays that disappear into fairly normal looking glasses. Since most nerds wear glasses anyway...:-)
I understand the time pressures that the company is under and I appreciate that they are providing players for Linux.
However, the RealAudio formats are still proprietary. For a streaming format, that may be a little less of a concern than for a true archival format. Still, RealAudio files are being archived. Who will be able to read those files 20 years from now when Win95, NT4, and Linux 2.0 will be all dim memories? And why should users of other operating systems (FreeBSD? BeOS? AmigaOS? Plan9? future free OS software efforts?) be excluded from listening to on-line broadcasts?
Internet streaming audio could become an important way of distributing public service information, independent information, etc., and I think it should be open. I hope it will happen, one way or another.
I think his work is as good or better as many Ph.D. theses. And many a thesis is simply a bunch of papers or reports put together into a single document anyway, further blurring the lines between a "thesis" and "practical work".
There are many honorary degrees that are only awarded so that the institution can ingratiate themselves with some dignitary. I think an honorary degree for Linus, however, really is a recognition of excellent work, work that could probably have counted as a Ph.D. if done within a university.
I applaud SGI's move. I think it's courageous on their part and shows that they are serious about their commitment to open source. And once they start delivering Linux systems, it lets them keep entry level server customers and provide a growth path to high end systems.
I hope this will not replace the non-journalling file systems for Linux, however. After having used them for a few years, I think the benefits of journalling file systems are actually very minor in practice and I don't expect to want to use it either on servers or clients. In addition, the XFS implementation is likely to be fairly complex (making other enhancements more difficult) and may not even perform as well as much simpler non-journalling file systems.
On balance, I think this will make Linux more attractive to corporate buyers and people for whom journalling is a requirement. But I also hope the mainstream of Linux file system development will explore other areas.
Looks like it took features from logo, scheme, and tcl. From what I can see, the result is fairly dissimilar to anything most users might be used to. Some specific simple messaging related might be simple to do, but more complex tasks seem no simpler than in other scripting languages.
I have trouble seeing REBOL go anywhere, though. It's not open source, making adoption that way rather difficult. And it's up against a lot of competition.
On Windows, people use VBScript and Internet COM components with it.
In the open source world, there are Perl, Python, Tcl/Tk, LUA, GUILE, and a lot of others. Perl in particular has good support for most Internet protocols. For less common languages with some history and interesting features, there are Icon and Logo.
It is nice that their interpreter is small (something they share with Logo and Lua), but that alone doesn't seem sufficient to buy their stuff. And Tcl started off small, too.
To me, the frontiers of scripting languages are in areas like COM/CORBA integration, automatic generation of C/C++/Java interfaces, and entirely new computational paradigms, not variations on an old theme.
Yahoo! started out as two students with a web site. Requirements for "some kind of official organization" only limit access to big corporations, and that hardly seems desirable to me. However, the current domain name system is getting kind of silly. We should have dozens of top level domains, each with their own meaning and requirements. For example, there should be something like ".inc" for registered corporations, ".tmk" for registered trademarks, ".per" for personal domains (which can conflict with trademarks--the presumption would be that they are not for trade), ".alt" (anything goes like the ".alt" hierarchy). Maybe most of the 36^3 possible 3 letter TLDs should be available to make sure that no single company or individual can register all the second level names; there ought to be room for "bush.sux".
No matter how "fair" the testing procedure itself is, the benchmark still tests the wrong thing and evaluates the wrong thing. (And, as others have pointed out, it uses the wrong hardware for Linux, too.)
Beyond certain minimum requirements, # static pages served per second really doesn't matter in real life, and SMP performance is also much less important in Linux environments than in NT due to the different way those platforms are deployed.
And the study doesn't compare costs, it compares performance. For the cost of a NT server license (not to mention all the extra software NT needs, plus the on-site handholding), you can buy a lot of extra Linux hardware.
Besides, performance is only one of many factors in picking a web server platform. Linux has an easy upgrade path to other, high-end UNIX systems. And NT has some big strikes against it with its iffy security, proprietary APIs, and difficult remote administration.
Mindcraft's study is intrinsically biased towards NT. I'm quite sure NT will shine in it no matter what we do. I think people should not participate.
Well, maybe you are particularly partial to Outlook. I don't particularly like it, precisely because it has so much stuff in it, and because I had a number of other technical problems with it.
Contrary to Microsoft's claims, one size doesn't fit all, more isn't always better, and there is no single "#1 application" for everybody.
ZD's test suffers from the same problems as many others.
For example, the ability to serve lots of hits per second on static web pages from a single box has no relevance to real-life web sites. At 1000 hits per second, a single Linux machine can serve about as many hits per second in these benchmarks as the whole Microsoft web site receives. That seems more than enough, and it's clearly not where real web sites are hitting their limitations (Microsoft uses dozens of their machines for their web site). I think the reason why Microsoft like this kind of benchmark is because it's easy to tune the OS for, even if it has little impact on actual web operations.
Also, the importance of SMP is overrated: the need for SMP on NT and some other systems arises often simply from licensing and system management issues; in many server applications, separate machines are preferable.
The benchmarks also don't take into account cost/performance. ZD claims "NT excels in NetBench". But actually, it only does 50% better for a price of at least $800 more. For that amount of money, you can buy another Linux machine and double Linux performance.
Most importantly, however, I think it is wrong to consider Linux, Solaris, and other UNIX systems to be "competitors". People can (and do) run mixed UNIX environments. For example, I might use Linux for all the web servers and an AIX machine for running a DB2 enterprise database that backs it all. Using Linux means there are lots of directions to grow in and lots of compatible commercial vendors to choose from.
If I develop for NT, I'm stuck when NT runs out of steam on its measly 4 or 8 processor Intel boxes, or when it runs out of its 3G address space. With NT, there is nothing to upgrade to.
Linux clearly isn't for everybody or everything. Only Microsoft seems to have the hubris of thinking that a single OS (theirs) can work well for everybody. Linux is part of a family of operating systems from different vendors that are interoperable and mostly compatible, and that only as a group cover most needs from embedded systems to mainframes. But within its own niche, R/D desktop applications, server farms, and small to medium servers, Linux is actually quite good.
3dfx seems to be making some sort of intellectual property claim to the 3dfx API itself rather than just their implementation of it, and they seem to be willing to back that up with threats of lawsuits (whether they would win or not is another question). I would say that a company like that is hostile to the idea of free software and their desire to be present on Linux is largely opportunistic.
Even in the Windows world, 3dfx has not been particularly well behaved. Their packages have been claiming OpenGL support for a long time, but they aren't delivering (and I suspect that's a strategic decision rather than inability to deliver). And recently, they pulled out the rug from under all the board makers that used to use their chip sets by deciding that future 3Dfx boards would be done in-house.
There are also technical issues. The 3dfx APIs look to me like they are designed to give the company a short-term competitive advantage on 1998 model PCs. But in the long term, I'd much rather see more powerful APIs like OpenGL widely supported.
There are a lot of nice 3D boards out there that don't have Linux drivers yet, and there are several nice 3D APIs. There is a lot of useful 3D work to be done on Linux. A 3dfx API driver for 3dfx boards would be near the bottom of my list of priorities.
Linux is, in fact much more scalable than NT. Why? Because it's largely compatible with AIX, Solaris, and other UNIX implementations on much bigger machines.
If you develop your product or site for NT, you are stuck on systems that NT runs on, and those are pretty pitiful compared to the "big iron" available in the UNIX world.
And there is no indication that that is changing--the upcoming 64bit and enterprise versions of NT are still years behind current high-end UNIX systems.
Mindcraft's benchmarks are largely meaningless no matter how well they tune Linux. For example, the number of hits per second that a web server can serve static pages at has no relevance to real web sites: most web servers can saturate their Internet hookup with static pages. Furthermore, Microsoft has tuned their systems to look good on those kinds of benchmarks.
Similarly, the concern about SMP support also has much less relevance for Linux than for NT. Unlike NT, Linux can be scaled easily and cheaply by using multiple single processor machines.
Another crucial difference is that Linux has a growth path: you can get started with a small, single processor machine, and if your business takes off, you can get a 256 processor IBM system. That's because Linux uses POSIX standard APIs. NT, on the other hand, is, for practical purposes, stuck with the Win32 APIs, so you better like the four processor performance, because that's all you are likely to get for now.
And Mindcraft's survey doesn't take into account cost. How much does a four processor SMP NT machine cost vs. four single processor Linux machines? What about all the software licenses? What about all those other little bits of software NT machines need, you know, the ones that cost $50-$100 a piece? Even if NT were faster, what matters is cost.
Only fools make decisions on server platforms based on benchmarks like Mindcraft's. The best that a test like Mindcraft's might be good for is to weed out obviously bad apples. But given that both Linux and NT are already used widely as servers, they clearly pass that test.
I'm saying that if you get a completely free choice in doctors by eliminating licensing, that imposes a cost on everybody else, an information cost. That cost is no different than if you decide to, say, pollute the groundwater and other people have to install water filters because of your actions.
These aren't black or white decisions. In most areas, government doesn't and shouldn't restrict choice. But in some areas, it makes sense for government to do so.
In the case of licensing of doctors, it does to me, as it does in setting a single standard for household current, and a set of cellular phone standards (something the Europeans have and the US regrettably doesn't, which is why the cellular phone industry is in such a mess over here). As I was saying above, I don't believe programmers need to be licensed, however.
Plan 9 is a nice, clean system. But it's a research operating system that's been developed and is being used in a very protected environment. Even at Bell Labs itself, most people have been and are using commercial operating systems rather than Plan 9 or Research UNIX.
I'm not even convinced that Plan 9 scales as well as Linux (and that isn't saying all that much). And Plan 9 lacks a lot of practically important features, some by accident, some by design (e.g., Plan 9 has no sparse address spaces because the Plan 9 designers believe they are "bad for you").
Like most of Bell Lab's research operating systems, Plan 9 is contributing a lot of important ideas, even if it itself isn't widely used. I think the accolades that group has received are well deserved. Some of Plan 9's features have already made it into Linux, and I hope some more will. But even if Plan 9 was licensed in the same way Linux is, I wouldn't switch.
Professional, commercial software development is based on requirements these days. If a large commercial software package isn't Y2K compliant, then it is most likely because "must continue to work in the 21st century" wasn't part of the requirements and hence programmers were free to do what they wanted.
While a good team might catch that issue, bring it to the attention of management, and do something about it, licensing isn't going to create good teams or good channels of communication.
But not even management is "responsible", in my opinion. The sources of Y2K are structural. Software development is usually given less money and time than it would actually require for delivering high quality end products. And management, faced with the decision of paying for redoing a payroll system that still seems to be working OK vs., say, investing in a glitzy new advertising campaign, are nearly forced to do the latter.
Like a lot of infrastructure these days, software is being used far beyond its anticipated lifetime. That's only going to change if the market starts permitting companies to look towards their long term success again, and if employees at those companies have long term job stability (from the CEO on downwards).
Claims that in a free market, licensing doesn't have any place are ignoring basic economic facts about the cost of information. In a market without mandatory licensing, there are additional costs to buyers of services to find a seller that meets their requirements. There is no a priori reason that in a free market we should decide to impose those costs on buyers rather than sellers, just like there is no reason to let companies pollute with impunity in a free market.
In the case of doctors or lawyers, the buyer doesn't even have the skills to make that evaluation themselves. It makes a lot of sense to license doctors or lawyers to ensure minimal competency. The cost of information in that case could be life or liberty. In other cases, society may determine that the costs of licensing are small compared to the costs of forcing everybody to evaluate professionals for themselves.
I happen to agree that for programming, we do not need licensing. But the reason is not that licensing in general is a bad idea, but that the details of the market for programming services are different. Unlike a sick person trying to find a good doctor, a manager of a software development team has both the skills and the power to evaluate candidates for programming positions.
I find it understandable but regrettable that Linux also has gone down the path of implementing the NFS server in the kernel. As the user level NFS server shows, there is no need for kernel privileges to implement the NFS protocol. The only reason for moving it in the kernel is performance. But that is an indication to me that the system APIs simply aren't complete or efficient enough to allow implementation of something like NFS. If this problem got addressed in a more general way, other network services (SMB, httpd, etc.) might benefit as well.
If implemented according to Sun's pre-NFSv3 spec, I believe writes are always going to be very slow because they are required to be synchronous (I have no idea what v3 requires, it's academic for me at this point). In the past, with Sun NFS, writes were often 4-5 times slower than reads. That used to be fixable only by adding battery backed up RAM (e.g., PrestoServe) to buffer the writes that NFS guaranteed to be synchronous.
You don't need very complex test setups to measure those differences--simply read and write a bunch of big files with "dd". If you want to do it simultaneously from several clients, there are some simple, free tools that let you execute the same command on multiple systems in parallel.
For years, Sun NFS would insert blocks of nulls at random when reading large files over NFS. Sun NFS write performance was also horrendously poor, even (or in particular) on Suns. And I remember lots of crashes relaed to Sun NFS. And even today, it isn't all that speedy.
Sun NFS is probably the best NFS there is. My point is that people have been calling it "stable" and "rock solid" even when it had very serious bugs and performance problems, and I'm not at all convinced that those aren't still lurking around (I simply gave up using NFS for anything serious).
significant, meaningful differences
on
The Desktop Wars
·
· Score: 1
To me, the differences between KDE+Qt/Gnome+GTK have been significant and meaningful, and I think they are a valid subject of debate:
KDE is somewhat more mature than Gnome
GTK is based on C, Qt based on a variant of C++
GTK has a free Windows version, Qt does not
The Qt license is different from the GTK license
To me, those differences come down to that I will use some KDE components on my desktop for now, but for any C/C++-based GUI development, I will use GTK. But despite their utility, both environments seem fairly backwards looking: they are designed like the toolkits of the 80's.
GUIs for the next millenium will make much more use of transparency, scaling, 3D, animation, multimodal input/output, browsing, and hypertext. I don't think either KDE or Gnome are in a particularly good position to play a big role in that. Java with Swing, Java2D, Java3D, and its other APIs, however, is in a much better position to become the substrate on which those future GUIs will be built.
To me, it's a shame that so much effort has been going into KDE and Qt, rather than into creating a non-proprietary Java-based desktop. But it is all volunteer work, after all, and people have to work on what they believe in.
I have observed how the GPL works in corporate environments for a number of years. Its function is to strongly encourage companies to share their improvements to open source software, and it works. Most corporations and corporate lawyers do their utmost to comply with the GPL because lawsuits are such bad publicity and so costly. Looking for loopholes in licenses to software that makes or breaks your releases simply doesn't make a lot of business sense.
The way the GPL functions in the corporate environment is fairly subtle, actually. When develoeprs set out on a new project and they consider basing it on GPL (or LGPL) software, they generally discuss the pros and cons of open sourcing their enhancements carefully. If open sourcing doesn't make business sense, they usually simply won't bother with GPL software. If they do go with GPL software, they license itself serves as something that keeps the source release process on track; without the GPL, the tendency would be to procrastinate with source releases. But in that context, the GPL is not a legal sledgehammer, but a merely a nudge, albeit an important one, to encourage companies to follow through at release time on the commitment to open source they made when starting the project.
Now, let's say that Microsoft deliberately tried to ignore the GPL. So what? Are they going to ship "MS Linux" with a bunch of proprietary APIs and no source code? People use Linux because it's open source, because it's small and simple, and because it has standard APIs; if Microsoft shipped a proprietary version, they'd be missing the whole point.
Misappropriating Linux source code would only make sense for companies that are so strapped for resources and programmers that they can't build anything similar themselves. Microsoft suffers from generating too much code, not from generating too little.
Microsoft has the manpower to put together a proprietary Linux-like kernel in a year or two with no impact on any of their other projects. What they lack is the corporate culture and development processes to put together something like Linux, and that's something they can't buy, copy, or license. (Microsoft's corporate culture and development processes are, however, evidently quite successful for their market segment--for now.)
Finally, there are lots of open source software packages released under licenses that allow commercial entities to ship them without providing source. That doesn't seem to have killed those packages either.
As to Apple open-sourcing the QuickTime code, take a look at the QuickTime API, and ask yourself how much engineering effort went into making it. The amount and quality of code in QuickTime makes Mozilla look like a weekend project. I'd say it approaches the complexity of the Linux kernel,
I don't think that's something in QuickTime's favor. Apart from gee-whiz awe, what good is all that complexity? And a framework that allows zillions of proprietary, platform dependent codecs to be plugged into it does not seem like something that is particularly desirable from an open source perspective.
There are good reasons why people "confuse" QuickTime with the codecs: when all is said and done, what the end user sees is that in order to look at QuickTime content, they need a Mac or possibly a Windows PC. Whether the reasons for that are technical, economical, social, or just random doesn't really matter.
To me, one of the best things about the open source movement is that, by necessity, it keeps things simple. The fact that QuickTime is big, complex, very general, and overly powerful isn't an advantage to me.
Apple indeed has a right to set whatever terms they want to for their software. But, in addition to choosing not to use their software, I see nothing wrong with criticising them publically over their licensing terms or their strategy.
Apple is investing millions of dollars in public relations, and they should certainly be open to public criticism. And public debate and criticism of their licensing terms is important so that everybody can make an informed decision of what they are signing up for if they decide to go with Apple's "open source" software. Apple's intent, future, and their licensing terms are all important considerations there.
On the issue itself, I'm somewhat pessimistic. After Cesar Chavez, Einstein, and the Dalai Lama, the ever-out-for-something-hip Apple marketing department has latched onto Open Source. It seems to me they simply pick any icon of creativity and stamp the Apple logo onto it. Their actual investment in those issues that people care passionately about appears minimal.
In fact, for Apple to assume the "open source" banner while pushing media formats that limit access to a small handful of proprietary formats simply offends me. I almost prefer Microsoft; at least they don't pretend.
There are several problems with the web server results.
Pretty much all high-traffic sites have dynamic content. They are not limited by the kind of web server performance these systems measure, but by the technology you use for generating the dynamic content (Perl, CGI, Servlets, databases, etc.).
Throughput of more than a few megabits per second is also pretty academic, at least for Internet sites and most intranet sites, simply because the network can't handle more than that.
Furthermore, Microsoft has been foremost in doing funny things with their TCP/IP implementation, both on their servers and on their clients, to look better on these kinds of benchmarks. If you look at the TCP/IP specs, it's actually impossible to achieve the kinds of hit rates they claim with a compliant implementation. Microsoft also seems to have done other things with timing and sequence in the past that made their systems look good and other systems trying to interoperate with them look bad (accident? you tell me...). So, even if NT performs better with 95/98 clients, that doesn't necessarily imply that NT is a more efficient system.
Another problem with their study is that it makes little sense to buy a four processor Xeon machine to run web sites with Linux. Four separate Linux machines are going to be more robust, easier to install, easier to maintain, perform better, and cost less. Of course, with Windows NT, because of the hassles of administering machines and because of the cost of the various software licenses involved, people may end up having to buy expensive, high-end SMP machines. I view that as a strike against NT.
They also don't seem to have tested systems where multiple, different server processes need to run on the same machine (web server, database, etc.). NT seems to perform poorly in those situations.
I can't comment as much about the Samba results. What I do know is that the Microsoft SMB servers we use seem to perform very poorly compared to the Samba servers on Solaris in practice. These are both professionally installed and maintained systems on high end hardware with hundreds of clients.
Altogether, their study strikes me as biased and meaningless. To me, NT isn't even in the running for building large, high-performance web services. For the performance characteristics and functionality that matter on real web servers, a Linux or BSD server farm is a cost effective way to go.
To me, the technically obvious solution is MP3 on a UDF DVD disk. Any additional data (track information, etc.) can also be put into the file system. But I guess that's just too simple...
Slashdot Mirror
Similar technology will soon be available for headmounted displays that disappear into fairly normal looking glasses. Since most nerds wear glasses anyway... :-)
However, the RealAudio formats are still proprietary. For a streaming format, that may be a little less of a concern than for a true archival format. Still, RealAudio files are being archived. Who will be able to read those files 20 years from now when Win95, NT4, and Linux 2.0 will be all dim memories? And why should users of other operating systems (FreeBSD? BeOS? AmigaOS? Plan9? future free OS software efforts?) be excluded from listening to on-line broadcasts?
Internet streaming audio could become an important way of distributing public service information, independent information, etc., and I think it should be open. I hope it will happen, one way or another.
There are many honorary degrees that are only awarded so that the institution can ingratiate themselves with some dignitary. I think an honorary degree for Linus, however, really is a recognition of excellent work, work that could probably have counted as a Ph.D. if done within a university.
I hope this will not replace the non-journalling file systems for Linux, however. After having used them for a few years, I think the benefits of journalling file systems are actually very minor in practice and I don't expect to want to use it either on servers or clients. In addition, the XFS implementation is likely to be fairly complex (making other enhancements more difficult) and may not even perform as well as much simpler non-journalling file systems.
On balance, I think this will make Linux more attractive to corporate buyers and people for whom journalling is a requirement. But I also hope the mainstream of Linux file system development will explore other areas.
I have trouble seeing REBOL go anywhere, though. It's not open source, making adoption that way rather difficult. And it's up against a lot of competition.
On Windows, people use VBScript and Internet COM components with it.
In the open source world, there are Perl, Python, Tcl/Tk, LUA, GUILE, and a lot of others. Perl in particular has good support for most Internet protocols. For less common languages with some history and interesting features, there are Icon and Logo.
It is nice that their interpreter is small (something they share with Logo and Lua), but that alone doesn't seem sufficient to buy their stuff. And Tcl started off small, too.
To me, the frontiers of scripting languages are in areas like COM/CORBA integration, automatic generation of C/C++/Java interfaces, and entirely new computational paradigms, not variations on an old theme.
Yahoo! started out as two students with a web site. Requirements for "some kind of official organization" only limit access to big corporations, and that hardly seems desirable to me. However, the current domain name system is getting kind of silly. We should have dozens of top level domains, each with their own meaning and requirements. For example, there should be something like ".inc" for registered corporations, ".tmk" for registered trademarks, ".per" for personal domains (which can conflict with trademarks--the presumption would be that they are not for trade), ".alt" (anything goes like the ".alt" hierarchy). Maybe most of the 36^3 possible 3 letter TLDs should be available to make sure that no single company or individual can register all the second level names; there ought to be room for "bush.sux".
Beyond certain minimum requirements, # static pages served per second really doesn't matter in real life, and SMP performance is also much less important in Linux environments than in NT due to the different way those platforms are deployed.
And the study doesn't compare costs, it compares performance. For the cost of a NT server license (not to mention all the extra software NT needs, plus the on-site handholding), you can buy a lot of extra Linux hardware.
Besides, performance is only one of many factors in picking a web server platform. Linux has an easy upgrade path to other, high-end UNIX systems. And NT has some big strikes against it with its iffy security, proprietary APIs, and difficult remote administration.
Mindcraft's study is intrinsically biased towards NT. I'm quite sure NT will shine in it no matter what we do. I think people should not participate.
Contrary to Microsoft's claims, one size doesn't fit all, more isn't always better, and there is no single "#1 application" for everybody.
For example, the ability to serve lots of hits per second on static web pages from a single box has no relevance to real-life web sites. At 1000 hits per second, a single Linux machine can serve about as many hits per second in these benchmarks as the whole Microsoft web site receives. That seems more than enough, and it's clearly not where real web sites are hitting their limitations (Microsoft uses dozens of their machines for their web site). I think the reason why Microsoft like this kind of benchmark is because it's easy to tune the OS for, even if it has little impact on actual web operations.
Also, the importance of SMP is overrated: the need for SMP on NT and some other systems arises often simply from licensing and system management issues; in many server applications, separate machines are preferable.
The benchmarks also don't take into account cost/performance. ZD claims "NT excels in NetBench". But actually, it only does 50% better for a price of at least $800 more. For that amount of money, you can buy another Linux machine and double Linux performance.
Most importantly, however, I think it is wrong to consider Linux, Solaris, and other UNIX systems to be "competitors". People can (and do) run mixed UNIX environments. For example, I might use Linux for all the web servers and an AIX machine for running a DB2 enterprise database that backs it all. Using Linux means there are lots of directions to grow in and lots of compatible commercial vendors to choose from.
If I develop for NT, I'm stuck when NT runs out of steam on its measly 4 or 8 processor Intel boxes, or when it runs out of its 3G address space. With NT, there is nothing to upgrade to.
Linux clearly isn't for everybody or everything. Only Microsoft seems to have the hubris of thinking that a single OS (theirs) can work well for everybody. Linux is part of a family of operating systems from different vendors that are interoperable and mostly compatible, and that only as a group cover most needs from embedded systems to mainframes. But within its own niche, R/D desktop applications, server farms, and small to medium servers, Linux is actually quite good.
Even in the Windows world, 3dfx has not been particularly well behaved. Their packages have been claiming OpenGL support for a long time, but they aren't delivering (and I suspect that's a strategic decision rather than inability to deliver). And recently, they pulled out the rug from under all the board makers that used to use their chip sets by deciding that future 3Dfx boards would be done in-house.
There are also technical issues. The 3dfx APIs look to me like they are designed to give the company a short-term competitive advantage on 1998 model PCs. But in the long term, I'd much rather see more powerful APIs like OpenGL widely supported.
There are a lot of nice 3D boards out there that don't have Linux drivers yet, and there are several nice 3D APIs. There is a lot of useful 3D work to be done on Linux. A 3dfx API driver for 3dfx boards would be near the bottom of my list of priorities.
If you develop your product or site for NT, you are stuck on systems that NT runs on, and those are pretty pitiful compared to the "big iron" available in the UNIX world.
And there is no indication that that is changing--the upcoming 64bit and enterprise versions of NT are still years behind current high-end UNIX systems.
Similarly, the concern about SMP support also has much less relevance for Linux than for NT. Unlike NT, Linux can be scaled easily and cheaply by using multiple single processor machines.
Another crucial difference is that Linux has a growth path: you can get started with a small, single processor machine, and if your business takes off, you can get a 256 processor IBM system. That's because Linux uses POSIX standard APIs. NT, on the other hand, is, for practical purposes, stuck with the Win32 APIs, so you better like the four processor performance, because that's all you are likely to get for now.
And Mindcraft's survey doesn't take into account cost. How much does a four processor SMP NT machine cost vs. four single processor Linux machines? What about all the software licenses? What about all those other little bits of software NT machines need, you know, the ones that cost $50-$100 a piece? Even if NT were faster, what matters is cost.
Only fools make decisions on server platforms based on benchmarks like Mindcraft's. The best that a test like Mindcraft's might be good for is to weed out obviously bad apples. But given that both Linux and NT are already used widely as servers, they clearly pass that test.
These aren't black or white decisions. In most areas, government doesn't and shouldn't restrict choice. But in some areas, it makes sense for government to do so.
In the case of licensing of doctors, it does to me, as it does in setting a single standard for household current, and a set of cellular phone standards (something the Europeans have and the US regrettably doesn't, which is why the cellular phone industry is in such a mess over here). As I was saying above, I don't believe programmers need to be licensed, however.
I'm not even convinced that Plan 9 scales as well as Linux (and that isn't saying all that much). And Plan 9 lacks a lot of practically important features, some by accident, some by design (e.g., Plan 9 has no sparse address spaces because the Plan 9 designers believe they are "bad for you").
Like most of Bell Lab's research operating systems, Plan 9 is contributing a lot of important ideas, even if it itself isn't widely used. I think the accolades that group has received are well deserved. Some of Plan 9's features have already made it into Linux, and I hope some more will. But even if Plan 9 was licensed in the same way Linux is, I wouldn't switch.
While a good team might catch that issue, bring it to the attention of management, and do something about it, licensing isn't going to create good teams or good channels of communication.
But not even management is "responsible", in my opinion. The sources of Y2K are structural. Software development is usually given less money and time than it would actually require for delivering high quality end products. And management, faced with the decision of paying for redoing a payroll system that still seems to be working OK vs., say, investing in a glitzy new advertising campaign, are nearly forced to do the latter.
Like a lot of infrastructure these days, software is being used far beyond its anticipated lifetime. That's only going to change if the market starts permitting companies to look towards their long term success again, and if employees at those companies have long term job stability (from the CEO on downwards).
In the case of doctors or lawyers, the buyer doesn't even have the skills to make that evaluation themselves. It makes a lot of sense to license doctors or lawyers to ensure minimal competency. The cost of information in that case could be life or liberty. In other cases, society may determine that the costs of licensing are small compared to the costs of forcing everybody to evaluate professionals for themselves.
I happen to agree that for programming, we do not need licensing. But the reason is not that licensing in general is a bad idea, but that the details of the market for programming services are different. Unlike a sick person trying to find a good doctor, a manager of a software development team has both the skills and the power to evaluate candidates for programming positions.
I find it understandable but regrettable that Linux also has gone down the path of implementing the NFS server in the kernel. As the user level NFS server shows, there is no need for kernel privileges to implement the NFS protocol. The only reason for moving it in the kernel is performance. But that is an indication to me that the system APIs simply aren't complete or efficient enough to allow implementation of something like NFS. If this problem got addressed in a more general way, other network services (SMB, httpd, etc.) might benefit as well.
You don't need very complex test setups to measure those differences--simply read and write a bunch of big files with "dd". If you want to do it simultaneously from several clients, there are some simple, free tools that let you execute the same command on multiple systems in parallel.
Sun NFS is probably the best NFS there is. My point is that people have been calling it "stable" and "rock solid" even when it had very serious bugs and performance problems, and I'm not at all convinced that those aren't still lurking around (I simply gave up using NFS for anything serious).
- KDE is somewhat more mature than Gnome
- GTK is based on C, Qt based on a variant of C++
- GTK has a free Windows version, Qt does not
- The Qt license is different from the GTK license
To me, those differences come down to that I will use some KDE components on my desktop for now, but for any C/C++-based GUI development, I will use GTK. But despite their utility, both environments seem fairly backwards looking: they are designed like the toolkits of the 80's.GUIs for the next millenium will make much more use of transparency, scaling, 3D, animation, multimodal input/output, browsing, and hypertext. I don't think either KDE or Gnome are in a particularly good position to play a big role in that. Java with Swing, Java2D, Java3D, and its other APIs, however, is in a much better position to become the substrate on which those future GUIs will be built.
To me, it's a shame that so much effort has been going into KDE and Qt, rather than into creating a non-proprietary Java-based desktop. But it is all volunteer work, after all, and people have to work on what they believe in.
The way the GPL functions in the corporate environment is fairly subtle, actually. When develoeprs set out on a new project and they consider basing it on GPL (or LGPL) software, they generally discuss the pros and cons of open sourcing their enhancements carefully. If open sourcing doesn't make business sense, they usually simply won't bother with GPL software. If they do go with GPL software, they license itself serves as something that keeps the source release process on track; without the GPL, the tendency would be to procrastinate with source releases. But in that context, the GPL is not a legal sledgehammer, but a merely a nudge, albeit an important one, to encourage companies to follow through at release time on the commitment to open source they made when starting the project.
Now, let's say that Microsoft deliberately tried to ignore the GPL. So what? Are they going to ship "MS Linux" with a bunch of proprietary APIs and no source code? People use Linux because it's open source, because it's small and simple, and because it has standard APIs; if Microsoft shipped a proprietary version, they'd be missing the whole point.
Misappropriating Linux source code would only make sense for companies that are so strapped for resources and programmers that they can't build anything similar themselves. Microsoft suffers from generating too much code, not from generating too little.
Microsoft has the manpower to put together a proprietary Linux-like kernel in a year or two with no impact on any of their other projects. What they lack is the corporate culture and development processes to put together something like Linux, and that's something they can't buy, copy, or license. (Microsoft's corporate culture and development processes are, however, evidently quite successful for their market segment--for now.)
Finally, there are lots of open source software packages released under licenses that allow commercial entities to ship them without providing source. That doesn't seem to have killed those packages either.
I don't think that's something in QuickTime's favor. Apart from gee-whiz awe, what good is all that complexity? And a framework that allows zillions of proprietary, platform dependent codecs to be plugged into it does not seem like something that is particularly desirable from an open source perspective.
There are good reasons why people "confuse" QuickTime with the codecs: when all is said and done, what the end user sees is that in order to look at QuickTime content, they need a Mac or possibly a Windows PC. Whether the reasons for that are technical, economical, social, or just random doesn't really matter.
To me, one of the best things about the open source movement is that, by necessity, it keeps things simple. The fact that QuickTime is big, complex, very general, and overly powerful isn't an advantage to me.
Apple is investing millions of dollars in public relations, and they should certainly be open to public criticism. And public debate and criticism of their licensing terms is important so that everybody can make an informed decision of what they are signing up for if they decide to go with Apple's "open source" software. Apple's intent, future, and their licensing terms are all important considerations there.
On the issue itself, I'm somewhat pessimistic. After Cesar Chavez, Einstein, and the Dalai Lama, the ever-out-for-something-hip Apple marketing department has latched onto Open Source. It seems to me they simply pick any icon of creativity and stamp the Apple logo onto it. Their actual investment in those issues that people care passionately about appears minimal.
In fact, for Apple to assume the "open source" banner while pushing media formats that limit access to a small handful of proprietary formats simply offends me. I almost prefer Microsoft; at least they don't pretend.
Pretty much all high-traffic sites have dynamic content. They are not limited by the kind of web server performance these systems measure, but by the technology you use for generating the dynamic content (Perl, CGI, Servlets, databases, etc.).
Throughput of more than a few megabits per second is also pretty academic, at least for Internet sites and most intranet sites, simply because the network can't handle more than that.
Furthermore, Microsoft has been foremost in doing funny things with their TCP/IP implementation, both on their servers and on their clients, to look better on these kinds of benchmarks. If you look at the TCP/IP specs, it's actually impossible to achieve the kinds of hit rates they claim with a compliant implementation. Microsoft also seems to have done other things with timing and sequence in the past that made their systems look good and other systems trying to interoperate with them look bad (accident? you tell me...). So, even if NT performs better with 95/98 clients, that doesn't necessarily imply that NT is a more efficient system.
Another problem with their study is that it makes little sense to buy a four processor Xeon machine to run web sites with Linux. Four separate Linux machines are going to be more robust, easier to install, easier to maintain, perform better, and cost less. Of course, with Windows NT, because of the hassles of administering machines and because of the cost of the various software licenses involved, people may end up having to buy expensive, high-end SMP machines. I view that as a strike against NT.
They also don't seem to have tested systems where multiple, different server processes need to run on the same machine (web server, database, etc.). NT seems to perform poorly in those situations.
I can't comment as much about the Samba results. What I do know is that the Microsoft SMB servers we use seem to perform very poorly compared to the Samba servers on Solaris in practice. These are both professionally installed and maintained systems on high end hardware with hundreds of clients.
Altogether, their study strikes me as biased and meaningless. To me, NT isn't even in the running for building large, high-performance web services. For the performance characteristics and functionality that matter on real web servers, a Linux or BSD server farm is a cost effective way to go.
To me, the technically obvious solution is MP3 on a UDF DVD disk. Any additional data (track information, etc.) can also be put into the file system. But I guess that's just too simple...