I have a Tyan Thunder K8SD Pro (S2882-D) set up with dual Opteron 275 CPUs, running Linux. Works fine. I would expect other Tyan motherboards to work as well.
You will need a pretty recent version of Linux. I am running SuSE Linux Enterprise Server (SLES) 9 Update 2, except that I've upgraded the kernel to a 2.6.14 from kernel.org. My suggestion: go with the latest Red Hat Enterprise, or wait for SLES 10, due out any week now.
http://www.ampcast.com/ is another site that has been providing non-DRM downloads of indie music for years. There's some great music on there that you've likely never heard of -- my favorite is the jazz group Viral Variations. Also, the site design is great -- lots of genres, well organized.
Anyone remember Metricom? Paul Allen reportedly lost some $600M on that. That's more than halfway to your $1B target.
For those who never heard of it or don't recall, Metricom was blanketing entire cities with their "Ricochet" wireless Internet access coverage. Yes! In 1999 and 2000! I was a subscriber, and got some real use out of the thing, though the service was expensive ($70/month) and slow (the claimed 128kbps rarely materialized). (But then, back then, most people were using dialup anyway.)
If they had moved more carefully, instead of madly rolling out a service for which demand had not yet developed, they might be sitting very pretty indeed by this point. Oh well, hindsight...
I agree. I refused to buy a 17" PowerBook for a long time because 1440x900 was flat inadequate. When they went to 1680x1050, I did buy one, and I consider it _barely_ adequate, but would happily have paid more for 1920x1200.
I don't do video editing -- I just like the screen real estate, and don't mind small text.
It's ironic to see the death of PDAs being predicted when, IMO, they only recently became really useful. The high-res backlit color screen and the Fitaly tap-optimized soft keyboard make my Tungsten T3 a very useful note-taking device. (I don't like the Treos -- the screen is smaller, the thumb keyboard is less effective than Fitaly, and they're bulkier.)
I've wondered about this for years. In 1981 I had a CP/M system -- CP/M!!! -- that could happily handle 128-, 256-, 512-, or 1024-byte sectors on its 8-inch floppy drives. (I wrote the reblocking code in the BIOS myself.) There was no question that larger sizes were better for both capacity and performance, if perhaps slightly more prone to unrecoverable errors (not that I really noticed, though). But somehow the idea that drivers could support multiple sector sizes was forgotten.
To answer someone's question, if all disk transfers are multiples of 4K anyway, you're better off using that as the hardware sector size because there's less overhead -- less spatial overhead on the disk because you have fewer sector headers and intersector gaps, and less temporal overhead in the I/O protocol because you're only sending one transfer command instead of eight.
... I'm impressed that they've simulated the game in such detail (down to the dust that accumulates in the center of the racket!!)... but I'd much rather play the real game and get some exercise.
Re:What ever happened to high res laptop displays?
on
MacBook Pro Reviewed
·
· Score: 2, Interesting
Dell has for some time sold laptops with 1920x1200 resolution, so they haven't disappeared.
I was interested in a 17" PowerBook for a long time, but couldn't get past the dismal 1440x900 resolution (I also have an older 1600x1200 Dell). FINALLY Apple bumped the resolution to 1680x1050, which I consider barely adequate, so I bought one. I'm happy enough with it, but of course I would have preferred 1920x1200.
I had terrible trouble getting a SATA RAID 5 array set up on my home server, a dual-processor box running a slightly old Linux distro (SuSE 9.0, 2.4.21). I went through several controllers. First, a HighPoint RocketRaid; it kinda worked, but the driver was buggy on 2.4 SMP kernels. Then an Adaptec, but that was a non-starter as the driver is not open source and they did not have one built for this kernel. Then I just got a Promise SATA controller and ran software RAID, and that worked for a couple of months, but I ultimately saw filesystem corruption, which I attribute to the driver, again, not being fully debugged (maybe the SMP was again a problem).
Finally I gave up trying to use a low-cost controller and picked up a 3ware 9500S-8. This seems to be working fine. (The reason those controllers are so much cheaper than the 3ware is that they are basically software RAID anyway. The 3ware, and other high-end controllers like the Areca, do much more work (like all the XORing) on the card.)
Also, on a different machine (this one 64-bit) I just wanted to set up a SATA software RAID 1 pair, and I had trouble with that also, until I installed a very recent kernel (2.6.14).
My conclusions:
It's possible that a low-cost SATA RAID controller like the HighPoint could work, but be sure you have a reasonably recent kernel, supported by the manufacturer, and I would still be wary of SMP.
However, software RAID also works fine, AFAIK, if you have enough controller ports. Avoid SATA, however, unless you have a quite recent kernel.
For minimal hassles, if you don't mind spending the money, 3ware seems to be the best.
BTW the 250GB drives have the lowest price per byte, or did when I last looked.
Your suspicions were true concerning the first copying collectors, but all modern, production-quality copying collectors are generational. This means that memory is divided up into at least two generations. Objects are originally allocated in the youngest generation, which is given a fairly small amount of memory and collected frequently; those that survive some number of collections are promoted to the next older generation, which is substantially larger and collected considerably less frequently; and so on for as many generations as the collector supports. Since most objects die young, most of the garbage is picked up by the youngest-generation collections, which are fast because the amount of memory involved is small. Thus, the oldest generations fill up more slowly.
What you want to do as the oldest, largest generation fills up depends on the application. Collecting this generation is indeed going to take some time. In many situations it makes more sense to kill the process and restart it than to try to collect that generation.
I'm speaking generally here and not about the JVMs in particular. Sun and IBM have both put a huge amount of work into their collectors and may have a workable way to collect the oldest generation. With the Lisp implementations with which I am familiar, however, restarting the process is almost always more practical. The advantage of the generational collectors is that one doesn't have to do that too often, as the older generations tend to fill slowly.
I did not compare Lisp to C++. I compared macros to functions-accepting-closures.
C++ does not even have closures, so your comparison is a strawman.
Sorry, I was arguing with the wrong person:) Alas, I've had lots of time lately to hone my Lisp-vs.-C++ arguments, since I work with C++ lovers:)
I've only written a little Python and don't know a lot about it, but I have worked for years in an obscure language called Refine, which is higher-order but lacks macros. I've done all the things you're talking about involving closures, many times, and I still prefer to use macros in many cases. (Specifically, when the purpose of delaying evaluation is to set up some dynamic context before evaluating the forms, and tear it down thereafter, I find the macro approach to be clearer and more elegant. Passing functions as arguments absolutely has its place, and I do it all the time, but I don't find it to be the most natural expression of these particular cases.)
You say, in your response to someone else, that you don't want to learn a new language to read a program. In over 25 years of Lisp programming, I have not very often found other people's macros to be a particular barrier to understanding (not nearly as often as their data structures and algorithms are). Certainly macros can be and sometimes are misused, and junior programmers are perhaps best advised to avoid them. There is even one well-known macro that is part of the Common Lisp standard that I personally just absolutely detest (loop); but still, if you ask me whether the benefits of macros outweigh the cost, I don't have to think about the answer -- the benefits far outweigh the costs.
As for the class-definition macro example, if there's some way to do that in Python, that's great. I'm curious, though, what you do for syntax -- you still have to create a syntax for the high-level class definitions, and write a parser for that syntax, do you not?
You are right that macros effectively change the evaluation rules of the language. As such they need to be well designed, well documented, and used sparingly. And it helps a lot if the documentation is available at the touch of a key, as indeed it was in the Lisp Machine system -- one just put the editor cursor on a function or macro name and hit Control-Shift-D, and up would pop whatever documentation the author had written.
The point of with-open-file, as I should have explained, is that it promises that on any exit from the body, including nonlocal exits to an outer context, the file will be closed. I'm not sure what with in your with(open_file(...)) example is supposed to mean, so I won't comment on that.
Let me give you a real-world example that I would love to be able to do in C++ today, if only I could. I'm working on a parser in C++, and like most parsers, it builds an Abstract Syntax Tree (AST). The AST is constructed from nodes of various classes, and the definitions of those node classes follow a certain pattern. For example, each such class has, in general, some instance variables that hold the children of the node within the tree, and others that hold annotations that are not part of the tree structure per se, such as type information. Each such class should have a method children that gathers up the children into a set and returns it.
In C++, I have no way to abstract these rules; all I can do is manually write out the definition of each class, making sure to include all the necessary bits. This makes the class definition both harder to write correctly, since there are plenty of details to get wrong, and harder to read, since the high-level structure of the class is somewhat obscured by the details.
In Lisp it is a fairly straightforward matter to write a new class definition macro that allows one to simply list the instance variables that hold tree children, and automatically generates the various methods such as getters/setters and the children method. This would provide a much more elegant and less error-prone way of getting these classes defined, and the resulting definitions would be much easier to read (though yes, one would have to learn the syntax of the macro).
There's no support in C++ for doing anything like this. Preprocessor macros don't begin to be powerful enough. The only way to do it is to create another preprocessor that parses the high-level class definitions and outputs the C++ definitions -- which is certainly possible, but far more work than one has to do in Lisp.
You are one of a very tiny minority,
I'm keenly aware of that. But I have to use C++ at the office, and I'm also keenly aware of how much time I waste doing that, by comparison to working in Lisp. I'm easily twice as productive in Lisp, maybe more so.
It just saddens me that so many programmers don't know what they're missing, so when I see people arguing that the benefits of Lisp -- benefits I experience every day -- are not real, naturally I want to speak up.
The above is wrong in so many ways I hardly know where to start.
Well, I'll start at the beginning. Macros are not like functions. As David Moon famously said, "Functions compute; macros translate." A macro is a syntactic abstraction, not a procedural or functional one.
It is true that some simple macros can be implemented as procedures that are passed closures of the code that would have been the macro subforms. In general, however, this is not the case. Macros can, for instance, establish variable bindings that capture free references within the body. For example, consider the well-known Common Lisp macro with-open-file:
The variable stream is bound to the stream that results from opening pathname; the body of the macro, which in this example consists of a single form, can refer to that variable.
It's true that one could get the same effect with closures:
and in fact, that's exactly the kind of thing one has to do when working in functional languages with no macros, but (a) it's less elegant because you're making the programmer do some of the macro's work, and (b) this is still a pretty simple macro.
Macros empower the developer by enabling the construction of syntactic abstractions -- each of which extends the syntax of the language. Like any other power, it is sometimes abused by the inexperienced; one can certainly write utterly unfathomable code using macros. But used well, macros greatly enhance the elegance, readability, and maintainability of code.
As for why macros are not more widely used, there are a couple of reasons. Lisp's minimalist syntax, so strange-looking at first glance, turns out to be one of its greatest advantages. The very simplicity of the syntax is exactly what makes it so powerful and general: user-defined constructs are invoked just like built-in constructs. While in principle a language with keywords and infix expressions could have an extensible grammar, syntactic extensions get much harder to manage in such a language because they tend to interact, causing ambiguities in the grammar.
And the second reason is one the above post touches on when it mentions the representation of code as data. Lisp is the only major language to give programmers access to a standardized tree representation of source code. The fact that the representation is a tree makes Lisp macros powerful (contrast the pitifully weak "preprocessor macros" of C/C++, which operate on a character string representation), and the fact that the representation is standardized makes them portable.
I have plenty of experience in more mainstream languages, but when programming for myself, I almost always use Common Lisp. Macros are a major reason.
Anyone have a guess when the Opteron 280 is likely to be out? That would be the dual-core 2.4GHz part. They have a dual-core Athlon 64 at that speed (the "4800+"), so I'm hoping the Opteron won't be much longer... anyone know?
Now that this sacred cow is dead meat, please Steve, can you get past your dogma that all Macs should have 100dpi screens? Dell has for some time been shipping a 1920x1200 laptop, but the best you can offer me is 1440x900 -- which just doesn't cut it.
I agree that support and updates are important to business customers, but do you really believe that Microsoft would make just as much money on Office if they open-sourced it? Not only would they lose all revenue from individuals and many small businesses, but even large corporations would wind up paying a lot less for updates, since they could just buy one copy and pass it around. Maybe some would pay for support as well, but how many? I don't know what support Microsoft offers for Office -- all I've ever heard is that Microsoft's support isn't very good in general.
So although I can see Microsoft still making some money on an open-source Office, I don't think it would be nearly as much. In contrast, switching to the NCU model would cost them much less -- not that they have any reason to do that either.
I have become convinced, over the years, that in our rush to embrace various forms of the open-source model, we have not given due consideration to another potentially useful model, in which the use of a piece of software would be free if that use were non-commercial -- by individuals, nonprofit organizations (including almost all educational institutions), or for evaluation and prototyping purposes by for-profit entities -- but actual commercial deployment would require payment of a license fee.
I've posted this in another forum and didn't receive a very enthusiastic response, so I'm not expecting one here either. But I ask you to set aside your preconceptions for a moment and listen to what I have to say.
There is a downside to releasing your software on an open-source basis. And it's very clear: businesses would, in many cases, be willing to pay something to use it, since they're making money by doing so. You are leaving money on the table -- money that could be used to support your project.
In contrast, with a non-commercial use ("NCU") model, you would still make your software available, with source, to lots of users who probably wouldn't have been willing to pay for it and who you would like to see using it, but those who use it to make money would have to pay you some. Doesn't that seem like a sensible arrangement?
A downside to the NCU model, which I'm sure many of you are eager to point out, is that it complicates the process of getting other developers to contribute to your project. For relatively minor contributions it should be possible to get them to simply release their code to you -- they are, after all, compensated by the increased functionality they enjoy. But for more important contributors, it will normally be necessary to give them a piece of the action -- to negotiate terms under which they will receive some portion of the license fees you collect. That's extra effort, but may well be worthwhile.
I'm not suggesting that the NCU model is appropriate for all projects or that it should supplant the open-source model. I would, however, like to see it more widely used than it is now -- and better supported, with readily available model licenses, and wider recognition as a viable approach, one that fits somewhere between open-source and shareware on the spectrum of possibilities.
Whether the NCU model would solve Sun's problem I don't know (see, this post wasn't entirely off topic:). But I think that wider use of it would benefit the cottage software industry considerably.
Slashdot Mirror
You will need a pretty recent version of Linux. I am running SuSE Linux Enterprise Server (SLES) 9 Update 2, except that I've upgraded the kernel to a 2.6.14 from kernel.org. My suggestion: go with the latest Red Hat Enterprise, or wait for SLES 10, due out any week now.
There's also a lot of mediocre stuff. YMMV :)
For those who never heard of it or don't recall, Metricom was blanketing entire cities with their "Ricochet" wireless Internet access coverage. Yes! In 1999 and 2000! I was a subscriber, and got some real use out of the thing, though the service was expensive ($70/month) and slow (the claimed 128kbps rarely materialized). (But then, back then, most people were using dialup anyway.)
If they had moved more carefully, instead of madly rolling out a service for which demand had not yet developed, they might be sitting very pretty indeed by this point. Oh well, hindsight...
I don't do video editing -- I just like the screen real estate, and don't mind small text.
Well, I hope they don't go away entirely...
When Steve Jobs was growing up, a common quip was "Don't trust anyone over 30".
To answer someone's question, if all disk transfers are multiples of 4K anyway, you're better off using that as the hardware sector size because there's less overhead -- less spatial overhead on the disk because you have fewer sector headers and intersector gaps, and less temporal overhead in the I/O protocol because you're only sending one transfer command instead of eight.
... I'm impressed that they've simulated the game in such detail (down to the dust that accumulates in the center of the racket!!)... but I'd much rather play the real game and get some exercise.
I was interested in a 17" PowerBook for a long time, but couldn't get past the dismal 1440x900 resolution (I also have an older 1600x1200 Dell). FINALLY Apple bumped the resolution to 1680x1050, which I consider barely adequate, so I bought one. I'm happy enough with it, but of course I would have preferred 1920x1200.
Maybe this will wake up some parents. A lot of kids these days get too little exercise anyway.
I had terrible trouble getting a SATA RAID 5 array set up on my home server, a dual-processor box running a slightly old Linux distro (SuSE 9.0, 2.4.21). I went through several controllers. First, a HighPoint RocketRaid; it kinda worked, but the driver was buggy on 2.4 SMP kernels. Then an Adaptec, but that was a non-starter as the driver is not open source and they did not have one built for this kernel. Then I just got a Promise SATA controller and ran software RAID, and that worked for a couple of months, but I ultimately saw filesystem corruption, which I attribute to the driver, again, not being fully debugged (maybe the SMP was again a problem).
Finally I gave up trying to use a low-cost controller and picked up a 3ware 9500S-8. This seems to be working fine. (The reason those controllers are so much cheaper than the 3ware is that they are basically software RAID anyway. The 3ware, and other high-end controllers like the Areca, do much more work (like all the XORing) on the card.)
Also, on a different machine (this one 64-bit) I just wanted to set up a SATA software RAID 1 pair, and I had trouble with that also, until I installed a very recent kernel (2.6.14).
My conclusions:
BTW the 250GB drives have the lowest price per byte, or did when I last looked.
Good luck!
The real threat to civilization is this phrase "the lowest common denominator". It's right up there with "I could care less".
Except they're going with Intel, not AMD... sigh...
(See recent /. discussion on the poor performance of the dual-core Xeons)
Huh. I have a Tyan Tiger MPX with two Athlon MP 2800+ and 2.5GB -- it's been rock solid for two years -- great machine, as far as I'm concerned.
What you want to do as the oldest, largest generation fills up depends on the application. Collecting this generation is indeed going to take some time. In many situations it makes more sense to kill the process and restart it than to try to collect that generation.
I'm speaking generally here and not about the JVMs in particular. Sun and IBM have both put a huge amount of work into their collectors and may have a workable way to collect the oldest generation. With the Lisp implementations with which I am familiar, however, restarting the process is almost always more practical. The advantage of the generational collectors is that one doesn't have to do that too often, as the older generations tend to fill slowly.
C++ does not even have closures, so your comparison is a strawman.
Sorry, I was arguing with the wrong personI've only written a little Python and don't know a lot about it, but I have worked for years in an obscure language called Refine, which is higher-order but lacks macros. I've done all the things you're talking about involving closures, many times, and I still prefer to use macros in many cases. (Specifically, when the purpose of delaying evaluation is to set up some dynamic context before evaluating the forms, and tear it down thereafter, I find the macro approach to be clearer and more elegant. Passing functions as arguments absolutely has its place, and I do it all the time, but I don't find it to be the most natural expression of these particular cases.)
You say, in your response to someone else, that you don't want to learn a new language to read a program. In over 25 years of Lisp programming, I have not very often found other people's macros to be a particular barrier to understanding (not nearly as often as their data structures and algorithms are). Certainly macros can be and sometimes are misused, and junior programmers are perhaps best advised to avoid them. There is even one well-known macro that is part of the Common Lisp standard that I personally just absolutely detest (loop); but still, if you ask me whether the benefits of macros outweigh the cost, I don't have to think about the answer -- the benefits far outweigh the costs.
As for the class-definition macro example, if there's some way to do that in Python, that's great. I'm curious, though, what you do for syntax -- you still have to create a syntax for the high-level class definitions, and write a parser for that syntax, do you not?
The point of with-open-file, as I should have explained, is that it promises that on any exit from the body, including nonlocal exits to an outer context, the file will be closed. I'm not sure what with in your with(open_file(...)) example is supposed to mean, so I won't comment on that.
Let me give you a real-world example that I would love to be able to do in C++ today, if only I could. I'm working on a parser in C++, and like most parsers, it builds an Abstract Syntax Tree (AST). The AST is constructed from nodes of various classes, and the definitions of those node classes follow a certain pattern. For example, each such class has, in general, some instance variables that hold the children of the node within the tree, and others that hold annotations that are not part of the tree structure per se, such as type information. Each such class should have a method children that gathers up the children into a set and returns it.
In C++, I have no way to abstract these rules; all I can do is manually write out the definition of each class, making sure to include all the necessary bits. This makes the class definition both harder to write correctly, since there are plenty of details to get wrong, and harder to read, since the high-level structure of the class is somewhat obscured by the details.
In Lisp it is a fairly straightforward matter to write a new class definition macro that allows one to simply list the instance variables that hold tree children, and automatically generates the various methods such as getters/setters and the children method. This would provide a much more elegant and less error-prone way of getting these classes defined, and the resulting definitions would be much easier to read (though yes, one would have to learn the syntax of the macro).
There's no support in C++ for doing anything like this. Preprocessor macros don't begin to be powerful enough. The only way to do it is to create another preprocessor that parses the high-level class definitions and outputs the C++ definitions -- which is certainly possible, but far more work than one has to do in Lisp.
You are one of a very tiny minority,
I'm keenly aware of that. But I have to use C++ at the office, and I'm also keenly aware of how much time I waste doing that, by comparison to working in Lisp. I'm easily twice as productive in Lisp, maybe more so.
It just saddens me that so many programmers don't know what they're missing, so when I see people arguing that the benefits of Lisp -- benefits I experience every day -- are not real, naturally I want to speak up.
Well, I'll start at the beginning. Macros are not like functions. As David Moon famously said, "Functions compute; macros translate." A macro is a syntactic abstraction, not a procedural or functional one.
It is true that some simple macros can be implemented as procedures that are passed closures of the code that would have been the macro subforms. In general, however, this is not the case. Macros can, for instance, establish variable bindings that capture free references within the body. For example, consider the well-known Common Lisp macro with-open-file:
The variable stream is bound to the stream that results from opening pathname; the body of the macro, which in this example consists of a single form, can refer to that variable.It's true that one could get the same effect with closures:
and in fact, that's exactly the kind of thing one has to do when working in functional languages with no macros, but (a) it's less elegant because you're making the programmer do some of the macro's work, and (b) this is still a pretty simple macro.Macros empower the developer by enabling the construction of syntactic abstractions -- each of which extends the syntax of the language. Like any other power, it is sometimes abused by the inexperienced; one can certainly write utterly unfathomable code using macros. But used well, macros greatly enhance the elegance, readability, and maintainability of code.
As for why macros are not more widely used, there are a couple of reasons. Lisp's minimalist syntax, so strange-looking at first glance, turns out to be one of its greatest advantages. The very simplicity of the syntax is exactly what makes it so powerful and general: user-defined constructs are invoked just like built-in constructs. While in principle a language with keywords and infix expressions could have an extensible grammar, syntactic extensions get much harder to manage in such a language because they tend to interact, causing ambiguities in the grammar.
And the second reason is one the above post touches on when it mentions the representation of code as data. Lisp is the only major language to give programmers access to a standardized tree representation of source code. The fact that the representation is a tree makes Lisp macros powerful (contrast the pitifully weak "preprocessor macros" of C/C++, which operate on a character string representation), and the fact that the representation is standardized makes them portable.
I have plenty of experience in more mainstream languages, but when programming for myself, I almost always use Common Lisp. Macros are a major reason.
Anyone have a guess when the Opteron 280 is likely to be out? That would be the dual-core 2.4GHz part. They have a dual-core Athlon 64 at that speed (the "4800+"), so I'm hoping the Opteron won't be much longer... anyone know?
Yes. But the same goes for atheism :)
Now that this sacred cow is dead meat, please Steve, can you get past your dogma that all Macs should have 100dpi screens? Dell has for some time been shipping a 1920x1200 laptop, but the best you can offer me is 1440x900 -- which just doesn't cut it.
I agree that support and updates are important to business customers, but do you really believe that Microsoft would make just as much money on Office if they open-sourced it? Not only would they lose all revenue from individuals and many small businesses, but even large corporations would wind up paying a lot less for updates, since they could just buy one copy and pass it around. Maybe some would pay for support as well, but how many? I don't know what support Microsoft offers for Office -- all I've ever heard is that Microsoft's support isn't very good in general.
So although I can see Microsoft still making some money on an open-source Office, I don't think it would be nearly as much. In contrast, switching to the NCU model would cost them much less -- not that they have any reason to do that either.
I have become convinced, over the years, that in our rush to embrace various forms of the open-source model, we have not given due consideration to another potentially useful model, in which the use of a piece of software would be free if that use were non-commercial -- by individuals, nonprofit organizations (including almost all educational institutions), or for evaluation and prototyping purposes by for-profit entities -- but actual commercial deployment would require payment of a license fee.
I've posted this in another forum and didn't receive a very enthusiastic response, so I'm not expecting one here either. But I ask you to set aside your preconceptions for a moment and listen to what I have to say.
There is a downside to releasing your software on an open-source basis. And it's very clear: businesses would, in many cases, be willing to pay something to use it, since they're making money by doing so. You are leaving money on the table -- money that could be used to support your project.
In contrast, with a non-commercial use ("NCU") model, you would still make your software available, with source, to lots of users who probably wouldn't have been willing to pay for it and who you would like to see using it, but those who use it to make money would have to pay you some. Doesn't that seem like a sensible arrangement?
A downside to the NCU model, which I'm sure many of you are eager to point out, is that it complicates the process of getting other developers to contribute to your project. For relatively minor contributions it should be possible to get them to simply release their code to you -- they are, after all, compensated by the increased functionality they enjoy. But for more important contributors, it will normally be necessary to give them a piece of the action -- to negotiate terms under which they will receive some portion of the license fees you collect. That's extra effort, but may well be worthwhile.
I'm not suggesting that the NCU model is appropriate for all projects or that it should supplant the open-source model. I would, however, like to see it more widely used than it is now -- and better supported, with readily available model licenses, and wider recognition as a viable approach, one that fits somewhere between open-source and shareware on the spectrum of possibilities.
Whether the NCU model would solve Sun's problem I don't know (see, this post wasn't entirely off topic :). But I think that wider use of it would benefit the cottage software industry considerably.