On the whole, that's probably good for Linux. Linux should stop being perceived as something that exists only in opposition to Microsoft.
I use Linux because it works well for me, not because of anything having to do with Microsoft. I wouldn't care about Microsoft or their market share at all if it weren't for the fact that their policies affect the availability of content and drivers on other platforms.
Reilly recites the standard litany political ideas represented by well-funded think tanks at the right end of the political spectrum:
Only the desire to maximize profits drives people; since Linux doesn't make any profits, it must be shoddy.
Windows is popular and exists in a free market, therefore it must represent consumer preferences accurately.
The value of a product is measured by how much people are paying for it; because Linux is free, it doesn't have any economic value.
Any information, creative or incidental, automatically represents a property right, so requiring companies to disclose their APIs amounts to "deprivation of property rights".
There is more, but that let that suffice. (I'm reminded of Dilbert's comment that he likes circular reasoning because it leaves no loose ends.)
A careful economic analysis of these issues needs to take into account, among many others, notions of public goods, cooperation, non-monetary economic goods, opportunity costs, and multi-attribute utility.
One of the most blatant problems with Reilly's ideas (and it is representative of a particular political agenda, not sound economics) is that it incorrectly describes human behavior in a quite fundamental way. It should be obvious to most people who have spent any amount of time at top research and development labs that it isn't profit that drives top quality researchers and developers (but, I suppose given that Reilly works at a conservative Washington think tank, that lack of experience is understandable).
In fact, one of the reasons for the low quality of Microsoft products is that their development seems primarily driven by short term profit considerations rather than an interest in quality. This actually seems quite reminiscent of the US auto industry, which produced large, inefficient cars and ran into serious problems when nimble, small, cheap Japanese and European cars became available. The analogy to Microsoft and OSS should be fairly obvious.
Reilly's piece is full of misrepresentations and factual mistakes. It's not worth expending time on analyzing them all, becaue the most fundamental blunder he makes is that he thinks that OSS is an alternative to the free market.
Far from it: OSS succeeds because of the free market. That has nothing to do with a short-term desire of harming Microsoft (a kind of "software dumping"?), but because it makes long term sense for individuals and companies to cooperate on operating system development. It's free market economics at its best.
People like Reilly like to assume the mantle of "free market economics" and "conservatism", but they really just represent economic interests that want to avoid free market competition as much as possible. Ensuring a functioning free market requires that the market is governed by orderly rules and regulations; otherwise, we would have social Darwinism and anarchy. Given the economics of software development, I'm sure an orderly free market is all OSS requires for its long-term success; at least OSS is up for the challenge.
And for consumers who actually like Microsoft software, I don't think he has to be concerned: OSS and Microsoft will live side-by-side, hopefully with dozens of other choices, as is proper and desirable in a free market.
I think the idea of having a single file system span multiple disks in the way LVM does is flawed in principle. The LVM implementation itself also has some serious limitations (you can't shrink them, it gets difficult to predict their performance, it gets difficult to figure out which physical partitions and disks a file system actually depends on, etc.).
I think there are better approaches to the same problem:
provide better quota systems to achieve similar hard resource limits that separate volumes give you, but on one file system
do something at the file system level rather than the volume level that lets files get stored on different disks/ partitions transparently; a kind of "concatenated mount"
use a RAID architecture that lets you add new storage dynamically
use a distributed storage architecture
I like Sun's approach to LVM. In AIX, I have to deal with LVM whether I want to or not, and it really makes disk and system management significantly more complex.
BTW, the CMU group that did AFS has come out with CODA, a successor that also offers some neat new features like disconnected operation. It's worth looking into. They are concentrating on Linux and NT clients and servers.
Currently, SETI looks for modulated carrier signals. But that seems like pretty outdated technology.
Accidental radio emissions from earth (and any other civilization using spread spectrum technology) are going to look increasingly like noise.
Even deliberate attempts at contact might use some kind of spread spectrum technology, possibly even without a carrier.
What would obvious sequences be for anybody trying to establish contact? Pi in binary? What would they be synchronized to? Does spread spectrum have an advantage over modulated signals for interstellar communications?
These supposed advantages don't hold up under close scrutiny:
JFS only makes transactional guarantees for the file system structure, not for the actual data.
JFS can't protect you against bad blocks, administrative mistakes (quite likely because of the really messy LVM on AIX), and other failures. So, you still need backups.
The overhead of JFS is much larger than "7-14%" in my experience. I have had cases where extraction of a tar archive with lots of little files took five times as long on a fast AIX machine (high performance SCSI disk) than on a low-end PC with Linux (IDE drive).
The risk of data loss with JFS is not hypothetical: despite all the journalling, I have lost data on JFS volumes and whole JFS volumes even without hardware failures or sysadmin mistakes. On the whole, JFS doesn't look any more reliable to me than ext2, but it sure is a lot slower. Why do you want to pay a big overhead for each file system operation if you can simply run a simple, efficient fsck at boot time on the very rare occasion that the system wasn't shut down cleanly?
This is a particularly relevant question for AIX systems, because they are very stable. Left alone, AIX servers will run for months and years doing whatever they are doing. When they do go down, it's for hardware or software upgrades, which require some extended downtime anyway. Making the file system slow in order to save on an fsck under those circumstances is a bad tradeoff. And AIX machines boot horribly slowly anyway because of the way their SCSI subsystem is implemented: an AIX desktop workstation takes 8 minutes to boot, and large servers can take literally hours.
Data warehousing applications usually use databases anyway, and those go to the raw disk for best performance (DB2 on AIX does). Those databases do their on transactioned updates.
Thinking that you can make individual nodes robust by twiddling with the file system is outdated mainframe thinking. The only robust, reliable way to safeguard your data is to use a distributed, redundant storage architecture. That way, you are protected against hardware and software failures. And you can concentrate on making the individual nodes fast and simple.
The idea itself isn't new, and similar techniques are already used with some cellular phone systems.
But their particular version, sending lots of bursts of digital data without a carrier, is not very nice: it fills a broad band of radio spectrum with noise.
If this became a widely used way of communicating through radio, it would interfere with conventional radio broadcasts, amateur radio, and other uses of the radio spectrum.
I don't like Windows for technical reasons, not because it isn't open source. Mostly, Windows has suffered feature and code bloat. Open sourcing it is not going to fix that. For commercial reasons, Microsoft simply can't remove features.
Distributing Windows sources will simply mean that more and more developers will start to depend on Windows internals. And just like the "Java Community License" access to Windows sources, "open" or not, will likely prohibit developers from using information they can get from the sources for improving clones like Wine.
Furthermore, open sourcing Windows is not going to address the two areas where Linux really needs access: proprietary drivers and proprietary content formats. Those are usually offered by other companies and often mired in patents. Opening Windows sources won't help.
The best thing with Microsoft is to let them go on with whatever they are doing. If current open source efforts deliver more value (as I think they do), OSS will win more marketshare. We don't all need to take the same approach to software development. There is a diversity of needs that is best met by a diversity of approaches. There are people who actually like programming Windows and see nothing wrong with it. Why spoil their day? And if a single model really were superior to all others, we will also only find out if we try a diversity of models.
It's not clear to me that large scale SMP is where enterprise computing is going, or even ought to be going, in the long run. SMP is kind of a kludge that lets people extend existing software and hardware to an environment with some parallel processing. A likely long-term path is a large number of processors without shared memory but with very fast networking. Linux isn't much better at that either, but neither is any of the other current crop of operating systems.
NT5 is millions of lines of code with what appears to be lots of dependencies. That will be difficult to squeeze down, and it will continue to be expensive to maintain.
In addition, NT doesn't have a tradition of remote administration or remote access, while Linux/UNIX has been used that way for a long time. Furthermore, a lot of server software, even for Windows, is written to POSIX APIs, and Microsoft doesn't enjoy the API advantage that they enjoy on the client. And the "high-end features" of NT that give it appeal in the business marketplace (Windows GUI based admin tools, fancy file system, etc.) matter much less on a thin server.
One thing in Microsoft's favor is that they do have all the software necessary to make this work in-house (the OS, SQL Server, IIS), and the incremental cost to them of putting that onto a thin server is small.
If they come out with a high performance, interoperable, thin database server at a good price, I'd actually be interested. I suspect, though, that that will be hard for them; with Linux, Oracle, and others, they are up against some good and established competition. But one can't fault them for trying.
good for Microsoft, bad for the rest of us
on
Open Source Windows
·
· Score: 1
I don't like using Windows because I don't think it's well designed or well implemented.
Open sourcing it isn't going to fix that. Microsoft isn't going to give up control of the evolution of Windows, so people won't be able to fix some of the more broken aspects of Windows. And the ways in which Windows is broken are so deep that I doubt that an open source effort could fix them. Neither are they likely to cut of their operating system revenue stream, so open source or not, you will probably still have to pay for a license.
In addition, on of the reasons why I like open source software is because the frugality and limited resources surrounding its creating necessarily keep it lean and simple. But Windows has its roots in a well-funded, corporate development effort, and it shows a lot of complexities and compromises as a result. (Mozilla is in the same boat, and that's probably why I never really got very excited about it.)
No matter how the Windows OS source code would be released (even if it were released under GPL), it would make things worse because it would mean that more people are going to use it and more people are going to start depending on Windows internals. For this reason, I never understood why the attorneys general considered open sourcing Windows a solution to Microsoft's monopoly position.
Open sourcing Windows would be a great thing for Microsoft, and a bad thing for anybody who doesn't like their technology. I'm surprised Microsoft hasn't done it already.
As far as I am concerned, 3Dfx is spinning out of control:
They haven't learned that the more of your APIs people adopt, the better.
Their packages claim OpenGL compatibility, but they have never delivered on many of their products.
Their strategy for the next generation 3Dfx chipset seems a bit greedy, too.
There are better chips around these days.
If 3dfx were the only game in town, this might be worth fighting. It might not be all that hard either: it seems pretty questionable to me whether they have a legal leg to stand on (in particular in Europe, where the ability to re-implement APIs is actually considered a right).
But there are a lot of other good 3D graphics board vendors out there. If 3Dfx doesn't want more developers and users of their APIs, let's just buy different boards and use more standard APIs.
Run that by me again? Why would someone do this? Any decent videocard is supplied with an OpenGL ICD. What would be the advantage of emulating OpenGL, when the real thing is available?
Some pretty good video cards actually don't have OpenGL drivers (often, if they claim to support OpenGL they actually only support some subset that's good enough for games but not much else).
In addition to the practical utility, it also shows that given the compute power of modern hardware, Microsoft's attempts to control APIs are getting more and more futile. Microsoft may have wanted to see OpenGL die, but people are going to wrap OpenGL around Direct3D anyway.
Systems programming languages need raw access to memory. C-style pointers do a lot more than provide raw access to memory, and they do it in a way that plays havoc with error checking and debuggability. Neither Ada nor Modula 2, both commonly used for system programming, have C-style pointers (the kind of pointers those languages provide are very similar to the kinds of pointers Java has).
To transform Java into a systems programming language as capable as C/Modula/Ada, it would be sufficient to add a "java.unsafe" module that adds support for reading, writing, and executing raw memory.
If UDI turns out to be a nice interface to write to, it may actually be advantageous to make it available on Windows as well (whether Microsoft likes it or not). That way, vendors could get by with writing just a single set of drivers, and they would be to the native UNIX APIs.
This is happening in other areas with Windows anyway. A lot of code is written to C++ and POSIX APIs rather than Microsoft's native APIs. And people have wrapped OpenGL around the Direct3D interface (with at least some success). And in all those cases, the non-Microsoft APIs are a lot nicer to use.
I completely agree that for individuals, it is rational not to switch if the cost of switching is more than the (discounted) long-term gain. For society as a whole, in the long term, it would still be efficient to switch, however (assuming, of course, that the standards in question are meaningful in the long term).
What I take exception with is calling that an "efficient" market. The notion of "efficiency" is an equilibrium notion. If you try to extend it to non-equilibrium states, economic reasoning becomes circular: anything the market does becomes by definition "efficient", and an "efficient" market would not mean "a market that allocates resources optimally" anymore.
Mostly, it seems to me, that many free market economists cannot accept the simple fact that even in the ideal case, markets do not always lead to optimal allocations of resources and production. Rather than admitting that simple fact, they attempt to redefine notions of "efficiency".
Markets implement only one particular method for optimizing in a complex space of constraints. Necessarily, they get stuck in local minima. It may be a bitter pill to swallow, but it is pretty much a trivial and inevitable mathematical fact that non-market mechanisms will sometimes lead to better allocation of resources, something ordinary human beings would call "more efficient".
In the case of QWERTY, that means that a government mandate to use DVORAK might be overall more efficient, even if it results in short term costs. In the case of QWERTY, I don't think there is a good argument to be made for that. In the case of cellular phone standards (Europe vs. US) or writing systems (Turkey), it seems that government intervention in the market has indeed resulted in significantly better efficiency. And in the case of operating systems, government intervention through standards setting could possibly also result in higher efficiency than the market by itself might achieve.
Implicit in these comparisons between Linux and Windows is the assumption that Linux should compete with Windows. It's far from clear to me that it should.
I like Linux the way it is, with its powerful, text-based typesetting, database, software development, and data-analysis tools. If I wanted a very visual desktop, I'd be using Windows (it already comes "free" with all the PCs I have), and I think the same is true for most current Linux users and contributors.
In my experience, non-computer types have no problem learning systems like LaTeX, SQL, or AWK. The initial learning curve is a little steeper than for the GUI-based equivalents, but people seem to come up to speed on the more powerful aspects more quickly than on Windows. Windows is designed for quick and easy selling; it promises to be usable by anybody without any investment of time, but it only delivers that for the most trivial aspects of its programs. That is appealing to customers, though, and it is achievable only with something Linux cannot easily compete with: expensive marketing and public relations.
Windows-style GUI apps isn't even where the next generation of mainstream applications is going. Rather, they are going to be web-based, server-based, and use small Java GUIs downloaded on demand. Linux is in an excellent position to cover the server end of that, and if Mozilla doesn't completely disintegrate, it will also be a reasonable client. KDE and Gnome are looking towards the past, not the future.
If Linux just became a free Windows clone, it would lose something in the process. While there are still some rough edges even in the text-based tools, I believe that efforts should be directed at addressing those. It seems to me that a focus on beating Windows at all cost is harmful.
Maybe Linux can retain its current user base and also acquire a serviceable complement of Windows look-alike GUI apps. But I'd rather tread very carefully in that direction; there are a lot more important areas to worry about it seems to me.
PS: Yes, Linux is easier to install than Windows.
The Economist gets their economics wrong.
on
The Myth of QWERTY
·
· Score: 2
if you have learned to type on a QWERTY keyboard, the cost of retraining for Dvorak (however modest) is not worth paying. This implies, in turn, that the QWERTY standard is efficient. There is no market failure.
The Economist needs some basic lessons in economics, it seems. If the Dvorak layout is indeed more efficient and it is only the cost of retraining that keeps people from adopting it, then the market is not efficient because, clearly, the most efficient technology is not being used.
This argument is only the tip of an iceberg of economic discussion (follow the references from the article). To many economists, the notion that markets cannot be anything but efficient is so ingrained that they try to explain away common sense facts using circular reasoning. "If people use QUERTY, it must be efficient [no matter what experiments may show]." "If people use Windows, it must be the optimal choice [no matter what the technical experts may say]."
Mostly what I would like an electronic book for is to read content that is already on-line; it's simply too much of a pain to print it (even with a 100ppm printer).
Unfortunately, all the electronic book companies have a model where I'm largely limited to what they offer in their on-line bookstores.
I'm not convinced that this is a viable long-term market anyway. A pen-based Windows CE machine, for example, is more versatile than an electronic book and has about the same battery life.
Before engaging in a lot of speculation, let me say that all that really matters is when Intel delivers, how well the chip is supported by then, and what performance it gives on the software people care about. At least in the UNIX universe, processors are so interchangeable that buying an Alpha now and switching to Merced if that looks like a better choice a year later shouldn't be a big deal.
Maybe my view of Merced is colored by the fact that I have used VLIW machines in the past. My experience has been: a lot of code will not run at even close to the theoretical capabilities of the machine (because the compiler couldn't figure out how to squeeze the logic into the parallel instruction set) and there were few compilers and little software available for them.
So far, I see little reason why Merced should be any different. Despite many years of research, compilers that are actually in use still haven't gotten very smart in understanding aspects of programs that need to be understood for parallelization and optimization. And Intel may try to help with C, C++, and Fortran backends, but what about all the other languages that are coming into use? We need chips that encourage the use of post-1970's languages, not chips that write them into stone.
Merced will probably perform well on some very structured problems (geometric transformations, optimizations, other numerical problems, text search, etc.). But for those, adding vector processing units to a more traditional processor might be cheaper and result in better overall performance than Merced's architecture.
There also seem to be questions about the way the VLIW architecture is implemented by Merced; supposedly, code compiled for one generation of the chip will not take advantage of more parallelism available in a later generation.
I think there is a good chance that the Alpha will save Intel. People already know how to write compilers for the Alpha, and the chip is fast. According to an article in Byte (but, hey, where are they now:-), Alpha will have twice the performance of Merced at the time Merced finally gets released.
On the one hand, I'm glad that some company is finally breaking with the dull tradition of processor design over the last 20 years. On the other hand, I'm not sure that this is the right way to do it.
Actually, there is another rather radical change in processor design that has happened recently: the complete system on a chip (from IBM and maybe others). Those might allow very dense multiprocessor systems, leading possibly to very different designs.
If quick expansion is your goal, a BSD-style license is probably going to have some advantages over (L)GPL.
In the long run, however, the BSD-style license is at a disadvantage. Until XFree86, there was virtually no code sharing among developers of X servers. That led to incompatibilities and lots of reinventing the wheel.
And when OSF took over X11, there was a very serious and real threat that new releases of X11 would revert to becoming proprietary. That would have been enormously disruptive for Linux and BSD users. The only thing that saved X11 was that OSF is largely a non-entity commercially these days and didn't have the clout to market and push through the next proprietary release of X11, so they eventually gave up.
The fact that "vi" is bundled is largely unrelated to its license. "vi" was bundled even when it was completely unavailable in source form and fell under strict AT&T licenses. In fact, many free versions of UNIX still don't bundle the BSD "vi": the open source alternatives are simply better.
I have nothing against people making profits. But the fact that the (L)GPL prevents people from making profit off (L)GPL'ed software in some ways is incidental. The main purpose of (L)GPL is to ensure that orderly, long-term community maintenance of open source software is possible. So far, I have not seen another license that achieves that as well.
It's regrettable how little Loukides understands and appreciates the value that GPL and LGPL have had for free software and open source software in a corporate framework.
Corporations don't make decisions as a coherent whole, and their decision making is not necessarily consistent in time either.
If corporate developers go to corporate legal staff and say "we want to release our bug fixes to [package X] to the world at large", the answer is going to be a predictable "no way". I know: I have been there.
But if the same developers can say "we decided (in consultation with our legal department) to go with a GPL/LGPL package at the beginning of the project and now we are bound by the licenses to release our fixes", that's something everybody can live with. I know: I have been there, too.
It is the developers inside companies that are driving the move to open source, and GPL/LGPL give them the tools to establish corporate commitment (by having the legal department initially approving the use of GPL/LGPL programs) and enforce follow-through.
Or, to put it more concisely: the GPL and LGPL establish a simple contract: you can use this software if you help improve it. That is crucial for making free software work.
Note that GPL and LGPL are licenses for software that is both "free" (in the GNU sense) and "open source". While all free software is open source, the reverse isn't true. I want to be clear that I think there are many other useful open source models. For example, I have no problem with Sun's Java community license, and I think for Java, it is actually the right license at this point.
However, Loukides claims that GPL/LGPL has been detrimental in general, and I strongly disagree. Without GPL/LGPL, projects like Linux, Apache, and GNU would not be where they are today.
I believe that Loukides's careless and uninformed criticism of GPL/LGPL is doing a grave disservice to the free software and open source community. I think it (and other recent statements from O'Reilly employees) also suggest to me that O'Reilly's vision for open source and free software isn't compatible with mine.
The short answer to anybody trying to install Linux from a book or a distribution is: don't.
Most people can't install Windows from a distribution (in particular on hardware that isn't Windows-certified), so why would we expect them to be able to install Linux?
I also have rather mixed feelings about efforts like KDE and Gnome. It's not clear to me that trying to make Linux into a consumer operating system is desirable. People who need something that's Windows-like are not very likely to contribute usefully to an open source effort, so why do we want to expend a lot of the efforts of our community to attract those people? Why not let them pay the $100 for Windows to Gates and leave him with the support headaches and complaints?
Linux needs a user base of a certain size to get hardware vendors interested in releasing information about their hardware so that we can build drivers. Beyond that, more isn't necessarily better.
My recommendation: use Linux where it makes sense, but be careful proselytizing. And by all means make sure people understand what they are going to get (powerful text-based applications that require some investment of time and effort to learn) and that they should buy Linux preinstalled on Linux-compliant hardware to get started.
Comparing actual memory usage of Java and C/C++ is rather tricky because memory is handled so differently. For example, in C/C++, the GUI libraries are "shared" and not necessarily counted against memory usage of the process, but they still take up space. The Java GUI libraries, however, are stored on the Java runtime's heap.
Because Java isolates different software components from one another, you can run different applications and services within the same runtime, and that's really the right comparison to make (at least in the long run when more and more applications run in Java).
That may seem like a distant hypothetical future, but it actually already has a lot of practical significance. For example, when writing servlets in Java, the footprint of each additional servlet is tiny, yet servlets are isolated from one another as well as if they were running in separate processes. In contrast, CGI scripts and even shared library implementations of web services have enormous overhead.
Holding on to too much memory is not a practical problem in languages with GC. If you are really concerned about it, you can use many of the standard techniques from C/C++ for dealing with it and you still retain the advantages of GC (including the runtime safety).
Java's Hello World does not take 80M of memory. In fact, Java runs in pretty small footprints and on the whole is probably smaller than current C/C++ runtimes. The only reason you don't see the C/C++ runtimes is because they are usually loaded at boot time these days and you consider them part of the OS.
Slashdot Mirror
I use Linux because it works well for me, not because of anything having to do with Microsoft. I wouldn't care about Microsoft or their market share at all if it weren't for the fact that their policies affect the availability of content and drivers on other platforms.
- Only the desire to maximize profits drives people; since Linux doesn't make any profits, it must be shoddy.
- Windows is popular and exists in a free market, therefore it must represent consumer preferences accurately.
- The value of a product is measured by how much people are paying for it; because Linux is free, it doesn't have any economic value.
- Any information, creative or incidental, automatically represents a property right, so requiring companies to disclose their APIs amounts to "deprivation of property rights".
There is more, but that let that suffice. (I'm reminded of Dilbert's comment that he likes circular reasoning because it leaves no loose ends.)A careful economic analysis of these issues needs to take into account, among many others, notions of public goods, cooperation, non-monetary economic goods, opportunity costs, and multi-attribute utility.
One of the most blatant problems with Reilly's ideas (and it is representative of a particular political agenda, not sound economics) is that it incorrectly describes human behavior in a quite fundamental way. It should be obvious to most people who have spent any amount of time at top research and development labs that it isn't profit that drives top quality researchers and developers (but, I suppose given that Reilly works at a conservative Washington think tank, that lack of experience is understandable).
In fact, one of the reasons for the low quality of Microsoft products is that their development seems primarily driven by short term profit considerations rather than an interest in quality. This actually seems quite reminiscent of the US auto industry, which produced large, inefficient cars and ran into serious problems when nimble, small, cheap Japanese and European cars became available. The analogy to Microsoft and OSS should be fairly obvious.
Reilly's piece is full of misrepresentations and factual mistakes. It's not worth expending time on analyzing them all, becaue the most fundamental blunder he makes is that he thinks that OSS is an alternative to the free market.
Far from it: OSS succeeds because of the free market. That has nothing to do with a short-term desire of harming Microsoft (a kind of "software dumping"?), but because it makes long term sense for individuals and companies to cooperate on operating system development. It's free market economics at its best.
People like Reilly like to assume the mantle of "free market economics" and "conservatism", but they really just represent economic interests that want to avoid free market competition as much as possible. Ensuring a functioning free market requires that the market is governed by orderly rules and regulations; otherwise, we would have social Darwinism and anarchy. Given the economics of software development, I'm sure an orderly free market is all OSS requires for its long-term success; at least OSS is up for the challenge.
And for consumers who actually like Microsoft software, I don't think he has to be concerned: OSS and Microsoft will live side-by-side, hopefully with dozens of other choices, as is proper and desirable in a free market.
I think there are better approaches to the same problem:
I like Sun's approach to LVM. In AIX, I have to deal with LVM whether I want to or not, and it really makes disk and system management significantly more complex.
BTW, the CMU group that did AFS has come out with CODA, a successor that also offers some neat new features like disconnected operation. It's worth looking into. They are concentrating on Linux and NT clients and servers.
Accidental radio emissions from earth (and any other civilization using spread spectrum technology) are going to look increasingly like noise.
Even deliberate attempts at contact might use some kind of spread spectrum technology, possibly even without a carrier.
What would obvious sequences be for anybody trying to establish contact? Pi in binary? What would they be synchronized to? Does spread spectrum have an advantage over modulated signals for interstellar communications?
The risk of data loss with JFS is not hypothetical: despite all the journalling, I have lost data on JFS volumes and whole JFS volumes even without hardware failures or sysadmin mistakes. On the whole, JFS doesn't look any more reliable to me than ext2, but it sure is a lot slower. Why do you want to pay a big overhead for each file system operation if you can simply run a simple, efficient fsck at boot time on the very rare occasion that the system wasn't shut down cleanly?
This is a particularly relevant question for AIX systems, because they are very stable. Left alone, AIX servers will run for months and years doing whatever they are doing. When they do go down, it's for hardware or software upgrades, which require some extended downtime anyway. Making the file system slow in order to save on an fsck under those circumstances is a bad tradeoff. And AIX machines boot horribly slowly anyway because of the way their SCSI subsystem is implemented: an AIX desktop workstation takes 8 minutes to boot, and large servers can take literally hours.
Data warehousing applications usually use databases anyway, and those go to the raw disk for best performance (DB2 on AIX does). Those databases do their on transactioned updates.
Thinking that you can make individual nodes robust by twiddling with the file system is outdated mainframe thinking. The only robust, reliable way to safeguard your data is to use a distributed, redundant storage architecture. That way, you are protected against hardware and software failures. And you can concentrate on making the individual nodes fast and simple.
But their particular version, sending lots of bursts of digital data without a carrier, is not very nice: it fills a broad band of radio spectrum with noise.
If this became a widely used way of communicating through radio, it would interfere with conventional radio broadcasts, amateur radio, and other uses of the radio spectrum.
Distributing Windows sources will simply mean that more and more developers will start to depend on Windows internals. And just like the "Java Community License" access to Windows sources, "open" or not, will likely prohibit developers from using information they can get from the sources for improving clones like Wine.
Furthermore, open sourcing Windows is not going to address the two areas where Linux really needs access: proprietary drivers and proprietary content formats. Those are usually offered by other companies and often mired in patents. Opening Windows sources won't help.
The best thing with Microsoft is to let them go on with whatever they are doing. If current open source efforts deliver more value (as I think they do), OSS will win more marketshare. We don't all need to take the same approach to software development. There is a diversity of needs that is best met by a diversity of approaches. There are people who actually like programming Windows and see nothing wrong with it. Why spoil their day? And if a single model really were superior to all others, we will also only find out if we try a diversity of models.
It's not clear to me that large scale SMP is where enterprise computing is going, or even ought to be going, in the long run. SMP is kind of a kludge that lets people extend existing software and hardware to an environment with some parallel processing. A likely long-term path is a large number of processors without shared memory but with very fast networking. Linux isn't much better at that either, but neither is any of the other current crop of operating systems.
In addition, NT doesn't have a tradition of remote administration or remote access, while Linux/UNIX has been used that way for a long time. Furthermore, a lot of server software, even for Windows, is written to POSIX APIs, and Microsoft doesn't enjoy the API advantage that they enjoy on the client. And the "high-end features" of NT that give it appeal in the business marketplace (Windows GUI based admin tools, fancy file system, etc.) matter much less on a thin server.
One thing in Microsoft's favor is that they do have all the software necessary to make this work in-house (the OS, SQL Server, IIS), and the incremental cost to them of putting that onto a thin server is small.
If they come out with a high performance, interoperable, thin database server at a good price, I'd actually be interested. I suspect, though, that that will be hard for them; with Linux, Oracle, and others, they are up against some good and established competition. But one can't fault them for trying.
Open sourcing it isn't going to fix that. Microsoft isn't going to give up control of the evolution of Windows, so people won't be able to fix some of the more broken aspects of Windows. And the ways in which Windows is broken are so deep that I doubt that an open source effort could fix them. Neither are they likely to cut of their operating system revenue stream, so open source or not, you will probably still have to pay for a license.
In addition, on of the reasons why I like open source software is because the frugality and limited resources surrounding its creating necessarily keep it lean and simple. But Windows has its roots in a well-funded, corporate development effort, and it shows a lot of complexities and compromises as a result. (Mozilla is in the same boat, and that's probably why I never really got very excited about it.)
No matter how the Windows OS source code would be released (even if it were released under GPL), it would make things worse because it would mean that more people are going to use it and more people are going to start depending on Windows internals. For this reason, I never understood why the attorneys general considered open sourcing Windows a solution to Microsoft's monopoly position.
Open sourcing Windows would be a great thing for Microsoft, and a bad thing for anybody who doesn't like their technology. I'm surprised Microsoft hasn't done it already.
- They haven't learned that the more of your APIs people adopt, the better.
- Their packages claim OpenGL compatibility, but they have never delivered on many of their products.
- Their strategy for the next generation 3Dfx chipset seems a bit greedy, too.
- There are better chips around these days.
If 3dfx were the only game in town, this might be worth fighting. It might not be all that hard either: it seems pretty questionable to me whether they have a legal leg to stand on (in particular in Europe, where the ability to re-implement APIs is actually considered a right).But there are a lot of other good 3D graphics board vendors out there. If 3Dfx doesn't want more developers and users of their APIs, let's just buy different boards and use more standard APIs.
Some pretty good video cards actually don't have OpenGL drivers (often, if they claim to support OpenGL they actually only support some subset that's good enough for games but not much else).
In addition to the practical utility, it also shows that given the compute power of modern hardware, Microsoft's attempts to control APIs are getting more and more futile. Microsoft may have wanted to see OpenGL die, but people are going to wrap OpenGL around Direct3D anyway.
To transform Java into a systems programming language as capable as C/Modula/Ada, it would be sufficient to add a "java.unsafe" module that adds support for reading, writing, and executing raw memory.
This is happening in other areas with Windows anyway. A lot of code is written to C++ and POSIX APIs rather than Microsoft's native APIs. And people have wrapped OpenGL around the Direct3D interface (with at least some success). And in all those cases, the non-Microsoft APIs are a lot nicer to use.
Those are some nifty micromachines, but it isn't nanotechnology.
What I take exception with is calling that an "efficient" market. The notion of "efficiency" is an equilibrium notion. If you try to extend it to non-equilibrium states, economic reasoning becomes circular: anything the market does becomes by definition "efficient", and an "efficient" market would not mean "a market that allocates resources optimally" anymore.
Mostly, it seems to me, that many free market economists cannot accept the simple fact that even in the ideal case, markets do not always lead to optimal allocations of resources and production. Rather than admitting that simple fact, they attempt to redefine notions of "efficiency".
Markets implement only one particular method for optimizing in a complex space of constraints. Necessarily, they get stuck in local minima. It may be a bitter pill to swallow, but it is pretty much a trivial and inevitable mathematical fact that non-market mechanisms will sometimes lead to better allocation of resources, something ordinary human beings would call "more efficient".
In the case of QWERTY, that means that a government mandate to use DVORAK might be overall more efficient, even if it results in short term costs. In the case of QWERTY, I don't think there is a good argument to be made for that. In the case of cellular phone standards (Europe vs. US) or writing systems (Turkey), it seems that government intervention in the market has indeed resulted in significantly better efficiency. And in the case of operating systems, government intervention through standards setting could possibly also result in higher efficiency than the market by itself might achieve.
I like Linux the way it is, with its powerful, text-based typesetting, database, software development, and data-analysis tools. If I wanted a very visual desktop, I'd be using Windows (it already comes "free" with all the PCs I have), and I think the same is true for most current Linux users and contributors.
In my experience, non-computer types have no problem learning systems like LaTeX, SQL, or AWK. The initial learning curve is a little steeper than for the GUI-based equivalents, but people seem to come up to speed on the more powerful aspects more quickly than on Windows. Windows is designed for quick and easy selling; it promises to be usable by anybody without any investment of time, but it only delivers that for the most trivial aspects of its programs. That is appealing to customers, though, and it is achievable only with something Linux cannot easily compete with: expensive marketing and public relations.
Windows-style GUI apps isn't even where the next generation of mainstream applications is going. Rather, they are going to be web-based, server-based, and use small Java GUIs downloaded on demand. Linux is in an excellent position to cover the server end of that, and if Mozilla doesn't completely disintegrate, it will also be a reasonable client. KDE and Gnome are looking towards the past, not the future.
If Linux just became a free Windows clone, it would lose something in the process. While there are still some rough edges even in the text-based tools, I believe that efforts should be directed at addressing those. It seems to me that a focus on beating Windows at all cost is harmful.
Maybe Linux can retain its current user base and also acquire a serviceable complement of Windows look-alike GUI apps. But I'd rather tread very carefully in that direction; there are a lot more important areas to worry about it seems to me.
PS: Yes, Linux is easier to install than Windows.
The Economist needs some basic lessons in economics, it seems. If the Dvorak layout is indeed more efficient and it is only the cost of retraining that keeps people from adopting it, then the market is not efficient because, clearly, the most efficient technology is not being used.
This argument is only the tip of an iceberg of economic discussion (follow the references from the article). To many economists, the notion that markets cannot be anything but efficient is so ingrained that they try to explain away common sense facts using circular reasoning. "If people use QUERTY, it must be efficient [no matter what experiments may show]." "If people use Windows, it must be the optimal choice [no matter what the technical experts may say]."
Unfortunately, all the electronic book companies have a model where I'm largely limited to what they offer in their on-line bookstores.
I'm not convinced that this is a viable long-term market anyway. A pen-based Windows CE machine, for example, is more versatile than an electronic book and has about the same battery life.
Maybe my view of Merced is colored by the fact that I have used VLIW machines in the past. My experience has been: a lot of code will not run at even close to the theoretical capabilities of the machine (because the compiler couldn't figure out how to squeeze the logic into the parallel instruction set) and there were few compilers and little software available for them.
So far, I see little reason why Merced should be any different. Despite many years of research, compilers that are actually in use still haven't gotten very smart in understanding aspects of programs that need to be understood for parallelization and optimization. And Intel may try to help with C, C++, and Fortran backends, but what about all the other languages that are coming into use? We need chips that encourage the use of post-1970's languages, not chips that write them into stone.
Merced will probably perform well on some very structured problems (geometric transformations, optimizations, other numerical problems, text search, etc.). But for those, adding vector processing units to a more traditional processor might be cheaper and result in better overall performance than Merced's architecture.
There also seem to be questions about the way the VLIW architecture is implemented by Merced; supposedly, code compiled for one generation of the chip will not take advantage of more parallelism available in a later generation.
I think there is a good chance that the Alpha will save Intel. People already know how to write compilers for the Alpha, and the chip is fast. According to an article in Byte (but, hey, where are they now :-), Alpha will have twice the performance of Merced at the time Merced finally gets released.
On the one hand, I'm glad that some company is finally breaking with the dull tradition of processor design over the last 20 years. On the other hand, I'm not sure that this is the right way to do it.
Actually, there is another rather radical change in processor design that has happened recently: the complete system on a chip (from IBM and maybe others). Those might allow very dense multiprocessor systems, leading possibly to very different designs.
In the long run, however, the BSD-style license is at a disadvantage. Until XFree86, there was virtually no code sharing among developers of X servers. That led to incompatibilities and lots of reinventing the wheel.
And when OSF took over X11, there was a very serious and real threat that new releases of X11 would revert to becoming proprietary. That would have been enormously disruptive for Linux and BSD users. The only thing that saved X11 was that OSF is largely a non-entity commercially these days and didn't have the clout to market and push through the next proprietary release of X11, so they eventually gave up.
The fact that "vi" is bundled is largely unrelated to its license. "vi" was bundled even when it was completely unavailable in source form and fell under strict AT&T licenses. In fact, many free versions of UNIX still don't bundle the BSD "vi": the open source alternatives are simply better.
I have nothing against people making profits. But the fact that the (L)GPL prevents people from making profit off (L)GPL'ed software in some ways is incidental. The main purpose of (L)GPL is to ensure that orderly, long-term community maintenance of open source software is possible. So far, I have not seen another license that achieves that as well.
Corporations don't make decisions as a coherent whole, and their decision making is not necessarily consistent in time either.
If corporate developers go to corporate legal staff and say "we want to release our bug fixes to [package X] to the world at large", the answer is going to be a predictable "no way". I know: I have been there.
But if the same developers can say "we decided (in consultation with our legal department) to go with a GPL/LGPL package at the beginning of the project and now we are bound by the licenses to release our fixes", that's something everybody can live with. I know: I have been there, too.
It is the developers inside companies that are driving the move to open source, and GPL/LGPL give them the tools to establish corporate commitment (by having the legal department initially approving the use of GPL/LGPL programs) and enforce follow-through.
Or, to put it more concisely: the GPL and LGPL establish a simple contract: you can use this software if you help improve it. That is crucial for making free software work.
Note that GPL and LGPL are licenses for software that is both "free" (in the GNU sense) and "open source". While all free software is open source, the reverse isn't true. I want to be clear that I think there are many other useful open source models. For example, I have no problem with Sun's Java community license, and I think for Java, it is actually the right license at this point.
However, Loukides claims that GPL/LGPL has been detrimental in general, and I strongly disagree. Without GPL/LGPL, projects like Linux, Apache, and GNU would not be where they are today.
I believe that Loukides's careless and uninformed criticism of GPL/LGPL is doing a grave disservice to the free software and open source community. I think it (and other recent statements from O'Reilly employees) also suggest to me that O'Reilly's vision for open source and free software isn't compatible with mine.
Most people can't install Windows from a distribution (in particular on hardware that isn't Windows-certified), so why would we expect them to be able to install Linux?
I also have rather mixed feelings about efforts like KDE and Gnome. It's not clear to me that trying to make Linux into a consumer operating system is desirable. People who need something that's Windows-like are not very likely to contribute usefully to an open source effort, so why do we want to expend a lot of the efforts of our community to attract those people? Why not let them pay the $100 for Windows to Gates and leave him with the support headaches and complaints?
Linux needs a user base of a certain size to get hardware vendors interested in releasing information about their hardware so that we can build drivers. Beyond that, more isn't necessarily better.
My recommendation: use Linux where it makes sense, but be careful proselytizing. And by all means make sure people understand what they are going to get (powerful text-based applications that require some investment of time and effort to learn) and that they should buy Linux preinstalled on Linux-compliant hardware to get started.
Because Java isolates different software components from one another, you can run different applications and services within the same runtime, and that's really the right comparison to make (at least in the long run when more and more applications run in Java).
That may seem like a distant hypothetical future, but it actually already has a lot of practical significance. For example, when writing servlets in Java, the footprint of each additional servlet is tiny, yet servlets are isolated from one another as well as if they were running in separate processes. In contrast, CGI scripts and even shared library implementations of web services have enormous overhead.
Java's Hello World does not take 80M of memory. In fact, Java runs in pretty small footprints and on the whole is probably smaller than current C/C++ runtimes. The only reason you don't see the C/C++ runtimes is because they are usually loaded at boot time these days and you consider them part of the OS.