if you're really giving something away "out of the goodness of your heart," maybe you just want as many people to have it as possible. if you're truely giving something away, shouldn't it be up to the person you give it to what they do with it? if you give someone a gift, to you normally stipulate that they can't use it to make money? your sig makes no sense whatsoever.
sorry, i was unclear. i've previously read the article you linked to, and re-read it just now. but i didn't mean to imply that the GPL was unenforcable; indeed, i also see no real reason why that would be so. my point was rather that the BSD license is at least as enforcable as the GPL, and has had more weight brought to bear upon it. either should be enforcable, but "should" is a funny word. the DMCA "should" be clearly illegal, but still it stands... the author of your linked article notes that he's never had to take it to trial. this is generally a good sign for the GPL, as it shows the lawyers on the other side give it enough weight to not take it that far. but a trial (or at least court-apointed mediation) is sort of the strongest trial-by-fire in our legal system; it'd be nice confirmation if the GPL could get that, and thus establish precidence.
my favorite bit on this site is right on the front page, down towards the bottom: it's on display at a modern art museum! that's just wonderful. i like. well, that and the intent of exploring this "or similar" planets...
first, you write "The only thing they can do is to spread FUD...", then you follow shortly on with this gem:
...all form of GPL-bashing or trying to put bad words in the mouth of the FSF people are to be looked at with a critical eye.
now who's spreading the FUD? you're advocating, basically, that people be discouraged from debating - and thus improving - the GPL. further, the FSF does take very clear positions on things, and it's often not necassary to put any words in their collective mouths to find something to take issue with. RMS has very strong ideas on the future of software licensing, and many people legitamatly take issue with them. your suggestion is harmful both to the public good and propriatary interests.
Never forget that the BSD and most other license are very weak at protecting our collective work
what? what on earth are you talking about? can you show a single case where a BSD license was found un-enforcable? in fact, BSD's gone to court, which i don't believe can be said for GPL (am i wrong?), and found explicitly enforcable. the BSD license places far fewer restrictions on the recipient of the license than the GPL does, and is thus likely to continue to be better enforceable. what GPL does - and BSD doesn't - is give you the right to see other people's work who used yours; BSD protects yours just fine. and enforcing restrictions on other people's works certainly seems somewhat less fundamental than putting protections on your own.
Under BSD, any company could take our code, slightly change a protocol, patent it and sue the original authors
this is bullshit, pure FUD, and it makes me very angry. in the case you describe, the patent would likely not be awarded, due to the existance of prior art. should it be awarded, it would be overturned if it ever went to court, for the same reason. what you're doing here is dishonest and vicious. you're playing on the fact that the BSD license - unlike the GPL - implicitly preserves the right for the licensee to release propriatary modifications. but, again, BSD still protects the original work (and has for longer, under better testing, than GPL). whether or not to allow propriatary derivative works is something a software author must decide. there are valid arguments on either side, but to reduce the complex issue to the ignorant statement above is just plain wrong.
this is an overly-simplistic understanding of what's going on. note that in the U.S., virtually no political speach is illegal (some is, like plots to overthrow the gvt., but very little). it China, all sorts of stuff is prohibited. in germany, pro-Nazi stuff is prohibited. any "compromise" represents a reduction in the fredoms of people in the U.S. - not good for us here. the problem is that in many place, like China, what's valued is the system (current gvt, communism, whatnot); in the U.S. (in theory, anyway) it's the freedoms, valued above the system in which they exist. the US already allows pro-communist sentiment.
this is slightly off-topic (mod away), but i note the assumption that non-US laws are inherently more restrictive than US laws. this is increasingly not the case. note DMCA and USA-Patriot, among others, and recent high-profile cases of foreign nationals being arested in the U.S. for breaking such laws. mind you, i think your assumption was true a decade ago, and i'd like to see it be true again...
...it is human nature to recomemend what one knows...
i agree entirely, and if you had done that, i'd have no problem with what you wrote. but you explicitly said you'd try to convince your future employers that Solaris is crap (right after you said you didn't know Solaris). i have no issue with you going into a job saying "i don't know Solaris, but i know FreeBSD (or whatever) can do the job; use that". that's fair and reasonable. but that's not what you said.
OpenBSD supports SPARC, SPARC64...
...and so on. i know. what's your point? i said Solaris still has alot to recomend it, particularly on the upper end. this remains true. sure, you could run Open/NetBSD on the huge Sun boxes. but you're not going to get the same performance and reliability you get from Solaris on those platforms, because they're not optimized for it. Solaris still has lots to recomend it there. you should look into that (which you can do at least minimally by reading) before criticizing what you don't know (as opposed to recomending what you do). it is the mark of a prudent, reasonable person to recomend what they know over what they don't. but i repeat: it is the mark of a very small mind to criticize something just because it's unfamiliar. that's what you did.
this is a fairly close-minded view of the world, don't you think? something must either be FSF-approved Free Software (with proper capitalization), or else it's propriatary? that's bogus. Darwin is open source (and Open Sorce); it is free software (but not Free Software); it is built on standards (and, in my limited tests, adheres to them better than Linux). in what way is it propriatary?
...and I'll try to convince my future employers that Solaris is a proprietary piece of shit and that they're much better off with something of the BSD family.
uh, because you don't know anything about Solaris? great, remind me not to hire you. god forbid a new job should expect you to learn something, or even admit what you do and don't know. Solaris still has alot to recomend it, particularly on the upper end, where x86 hardware just can't compete. it is the mark of a very small mind to criticize something just because it's unfamiliar.
mmm, no. having run Solaris/x86 and BeOS for years, Solaris, while quite poorly supported on x86 hardware, still soundly trounced BeOS. which is not to say it was very good: all the BSDs and Linux beat Solaris at least as much as Solaris beat BeOS, but be fair. also, i'm curious what sort of SMP problems you had. i ran it on quad-processor boxes, and it performed quite nicely; quick and stable. the biggest problem in my mind was always the application suport, which was almost non-existant.
first off, remember that Sun's primary source of income is from their (very nice) SPARC hardware, not from Solaris (which you can often get free). they have no real incentive to work on an x86 version at all, unless it seems to be significantly helping their Solaris markent (and thus encouraging more SPARC hardware sales). note also that while your suggestion would reduce their support costs, it would not be trivial, and would likely not reduce them by nearly as much as you'd think. there'd need to be a certification process, and some detailed tracking of what cards of various types are/arn't supported, beyond just the base system. remember that when you by a "Dell Whatever" pre-built system, you have no real idea what exact video, network, or whatever card's in it; Dell (and all the others) think it's fine to change revisions of cards.
the site's a bit low on details, no? i want a bit more tech info. for example, if it's driverless, why list the three(Win32, MacOS, and Linux) OS's they "support" at all? shouldn't anything with USB drivers work? and, oh, why're they making Win32 drivers available, if it's driveress?
personally, i'll hold out for a firewire version. transfering up to 1GB at USB speeds is a bit slow for me.
It really depends on the speech recognition you are trying to do.
agreed. but remember, when dealing with music, you've got a much broader range of amplitude and frequency variations. the sampling needs to be good enough to avoid the cut out, pre-fade, and jitter effects common in many digital encodings, and the side-effects of trying to deal with them. also, keep in mind that "real time" is a much less stringent requirement for speech - which has frequent short breaks in the energy, and fairly unique energy/data characteristics (at least in english) - than for music - which is often constant, varrying energy, all of which could reasonably be considered data.
I doubt people moshing in a pit somewhere exactly qualify as audiophiles
again, agreed, but this is mainly targeted as a MIDI replacement/evolution. that's only got limited use in live performances, anyway; its primary funcion is in recording, especially in studios (but also in-line recording of live shows). so this technology needs to be able to satisfy an audiophile listening to a CD on her $20,000 home stereo setup.
funny, i used to work on a speech recognition/tts project for a currently beleagured telecom equipment manufacturer. i'm also a musican (comments on quality aside). and i'm quite certain pushing guitar is harder. modern speech recognition systems are highly forgiving compared to the ears of an audiophile. we did multi-chanel streaming ASR (over TCP/IP over ethernet and ISDN), and typically a 64kbit pipe was plenty for a chanel. they go over in pretty good detail in the spec how they use the bandwidth, and it all seems quite reasonable. further, note that they're using multiple chanels, for multiple instruments, possibly over a given link. and what's more (and is clear in the spec) they do have broadcast, if only for negotiation, device enumeration, and whatnot. but their lowest sample rate is CD-quality (44.1), and they go up from there.
yeah, so it's not ethernet. big deal. what's your issue? did you read the spec? there's good reasons they don't want any extra overhead, even the relatively minimal overhead imposed by ethernet. it's not like they're running IP over the link, or any other higher-level protocol. everything's designed for exactly one function, and highly optimized for it. real-time uncompressed live audio at analog quality is tough. you'd loose your bet. now, as other people have mentioned, they might have been able to get away with using straight FireWire and had it just work...
well, gmake isn't available for Plan 9, for one thing, and that's the system i personally care most about (well, and Inferno, but i wouldn't expect it be work there). i tried building it some time ago, and couldn't: problems, ironicly enough, getting their autoconf-generated configure scripts to work on Plan 9. i spent alot of time trying to get it to work, and couldn't. having just pulled down the latest version now, and poked breifly, it doesn't look like the situation's improved there. more practically, i've admined many unix (primarialy Solaris, but others as well) boxes which didn't have gmake installed. when i want package foo, i don't want to have to install gmake to get it, particularly on sensative systems or in situations where time and/or space is a concern. i've also been a user on boxes other people administer. disk quotas often make builiding and storing my own build tools impractical when what i really want is some other package. i've written makefiles for several (admitedly small) projects, and not found it to be a problem. mk is better, but less commonly available. i still think if you're aiming at portability or generality of your build process, use the straight make.
There's nothin in autoconf that mandates sloppy programming.
true, but that's not what i claimed. rather, i've found (by observing code quality in numerous commercial and Free Software projects) that autoconf/configure encourages sloppy coding by eliminating many of the things which otherwise encourage it, such as portability concerns.
...what if I want to set a different prefix...
um, "prefix=/my/path make install"? environment variables work well for many such things. further, editing a well-written makefile for such things is simple; about as dificult, in my experience, as finding the desired options to different configures. this is even more true if any debugging is needed.
I've seen straight make builds where this information is distributed across several Makefiles...
true, and that does suck. you can build awful makefiles, and you can write truely elegant, portable code and use autoconf. they're tools. my point is what these tools encourage, what is generally true about projects in which they are used.
i may well be in the minority among this crowd, but i think you should avoid autoconf like the plauge. people's most common reason for using autoconf/configure is portability, but that's a cop-out. basically, the autoconf/configure school of portability says "forget about actually writing portable code, just write it for each variant and let the build process pick". that's whacked. you'll continually be running accross new variants, new ways in which systems are different, or just new systems. for example, i use Plan 9, which has a very good ANSI/POSIX compatability system (better than many *nix systems). despite being near-fully ANSI compliant, pretty much every autoconf fails because it doesn't recognize the output of uname or something stupid like that (of course, that says noting about when programs that claim to be ANSI or POSIX arn't, like including non-ANSI/POSIX headers, typically BSD stuff). this school of portability also typically makes your code far less readable - littering it with ifdef's every third line - and much larger. it ends up taking much more time than just slowing down and disiplining yourself to write real portable code. the argument 'configure ; make ; make install' is easy is stupid, as well. y'know why? 'cause 'make install' is easier. build your makefiles well. the 'install' target should have prerequisits, obviously. make will build them for install. and 'configure' is slower and more prone to failure than 'cp makefile.linux.386 makefile'. and light years more reliable. and editing an example makefile is way easier than putzing with autoconf/configure if something doesn't work. not to mention easier to debug (uh, 'echo' anyone?).
on a personal note, having done portability work a good bunch, i'd offer just a little extra advice: do not require GNU-specific stuff. don't use any of the gmake-specific features or gcc language extentions. GNU propaganda, that'll just kill your portability. and if you need something both simpler and more powerful than make, check out mk from the Plan 9 and Inferno distrubutions. Vita Nuova's got a version that runs on various unixes and win32 systems. it's very similar to make, but a bit more general and flexible. but, given that you've already got all the makefiles, i'd suggest your best bet is just sticking with plain makefiles and cleaning them up.
Public Domain, unfortunatly, isn't really a practical licensing model for individuals or institutions with alot to loose who want anyone to use their stuff; it provides no protections for the author/developer. the BSD license was originally developed (by University of California Berkeley) to address just this problem. i agree that the GPL is too restrictive to be appropriate in this case, but i want the universities protected more than PubDom offers. the BSD license also permits closed-source commercial modifications and redistribution.
Almost all research is funded by federal agencies...
well, i'm not sure about that 10% number (my university contacts say it's a bit more than that), but your point still stands. and, thank you very much, it reinforces mine. again, these federal agencies are funded with public money, primarialy via taxes, like public universities are funded primarialy via taxes. the fact that the money goes through the federal gvt. first does nothing to change the fact that it's fundamentally public money, entrusted to state and federal governments to act in the public interst.
in my mind, the eventual disposition of the IP rights depend on where the funding for the research came from. in public institutions, like state schools, this should be clear: they're public institutions, funded by public money, so the public should get the benefits. that's simply an evolution of the original concept of public educations: we give money to educational institutions so society as a whole can benefit. in private institutions, it's less clear, since the public money (almost all private universities still get lots of public money) is usually a minority. but lots of big companies help fund research in public schools and still expect to get the results, and that doesn't make sense.
you are correct on pretty much everything here. but there's more. to summarize:
M$'s monopoly has helped keep Linux out of schools
Linux not being in schools discouraged edu. app writers from porting to or writing for Linux
putting Linux into schools would encourage greater edu. app support for Linux
this would increase Linux' momentum, impacting M$'s monopoly
this would acomplish the real goal here, punishing M$ and preventing future offenses.
all this is true, entirely logical, and valid reasoning. the problem here is that it would, until the software companies catch up, very much degrade the usefulness of those computers to the schools that recieve them. while it's certainly a huge improvement over M$'s "offer", something that doesn't diminish the positive effects would be even better. to which i'd propose swapping Apple for Linux. administratively, it's much more familiar to the people who'll be running these boxes, Apple can absorb the support costs better than Red Hat, and Apple's already got both a very positive reputation and good app support in the education sector. and, of course, Apple's been hurt probably much worse than Linux (since they've been abused my M$'s monopoly before Linux was a concern), so it's a further improvement to the punative nature of the settlement.
you're right, linux isn't (currently?) up to the task, primarialy because of software base (questions about Linux's suitability for non-geek desktops aside). but Red Hat's offer still has some good ideas in it. helping the schools is always nice, since no government in the US gives them the cash they should have, and the counter-offer does take M$'s obviously self-serving ploy and turn it into something really punative. targeting the poorest schools is also a nice move (on the part of M$ and Red Hat). and, most importantly, it's likely to have some lasting effect as it may (hopefully) encourage a viable long-term competitor to M$. so, if it's a good idea, but RH and Linux can't pull it off, who can? simple: Apple. they've already got a good reputation in the education sector, they've got good app support, and it's their traditional strong suit anyway. it'd also avoid subsidizing one of M$'s biggest de facto partners (Intel), who've also benefited quite a bit from M$ abusing their monopoly.
so, how 'bout it, Apple? wanna step up to bat for the kids, put M$ in their place, and improve your long-term prospects for years to come, just for the cost of some support?
Slashdot Mirror
if you're really giving something away "out of the goodness of your heart," maybe you just want as many people to have it as possible. if you're truely giving something away, shouldn't it be up to the person you give it to what they do with it? if you give someone a gift, to you normally stipulate that they can't use it to make money?
your sig makes no sense whatsoever.
sorry, i was unclear. i've previously read the article you linked to, and re-read it just now. but i didn't mean to imply that the GPL was unenforcable; indeed, i also see no real reason why that would be so. my point was rather that the BSD license is at least as enforcable as the GPL, and has had more weight brought to bear upon it. either should be enforcable, but "should" is a funny word. the DMCA "should" be clearly illegal, but still it stands...
the author of your linked article notes that he's never had to take it to trial. this is generally a good sign for the GPL, as it shows the lawyers on the other side give it enough weight to not take it that far. but a trial (or at least court-apointed mediation) is sort of the strongest trial-by-fire in our legal system; it'd be nice confirmation if the GPL could get that, and thus establish precidence.
my favorite bit on this site is right on the front page, down towards the bottom: it's on display at a modern art museum! that's just wonderful. i like.
well, that and the intent of exploring this "or similar" planets...
this is an overly-simplistic understanding of what's going on. note that in the U.S., virtually no political speach is illegal (some is, like plots to overthrow the gvt., but very little). it China, all sorts of stuff is prohibited. in germany, pro-Nazi stuff is prohibited. any "compromise" represents a reduction in the fredoms of people in the U.S. - not good for us here. the problem is that in many place, like China, what's valued is the system (current gvt, communism, whatnot); in the U.S. (in theory, anyway) it's the freedoms, valued above the system in which they exist. the US already allows pro-communist sentiment.
this is slightly off-topic (mod away), but i note the assumption that non-US laws are inherently more restrictive than US laws. this is increasingly not the case. note DMCA and USA-Patriot, among others, and recent high-profile cases of foreign nationals being arested in the U.S. for breaking such laws.
mind you, i think your assumption was true a decade ago, and i'd like to see it be true again...
it is the mark of a prudent, reasonable person to recomend what they know over what they don't. but i repeat: it is the mark of a very small mind to criticize something just because it's unfamiliar. that's what you did.
this is a fairly close-minded view of the world, don't you think? something must either be FSF-approved Free Software (with proper capitalization), or else it's propriatary? that's bogus. Darwin is open source (and Open Sorce); it is free software (but not Free Software); it is built on standards (and, in my limited tests, adheres to them better than Linux). in what way is it propriatary?
it's not clear weather QNX is a Unix or not (they're conflicted themselves), and Darwin isn't commercial (being largely Mach + FreeBSD).
mmm, no. having run Solaris/x86 and BeOS for years, Solaris, while quite poorly supported on x86 hardware, still soundly trounced BeOS. which is not to say it was very good: all the BSDs and Linux beat Solaris at least as much as Solaris beat BeOS, but be fair.
also, i'm curious what sort of SMP problems you had. i ran it on quad-processor boxes, and it performed quite nicely; quick and stable. the biggest problem in my mind was always the application suport, which was almost non-existant.
first off, remember that Sun's primary source of income is from their (very nice) SPARC hardware, not from Solaris (which you can often get free). they have no real incentive to work on an x86 version at all, unless it seems to be significantly helping their Solaris markent (and thus encouraging more SPARC hardware sales).
note also that while your suggestion would reduce their support costs, it would not be trivial, and would likely not reduce them by nearly as much as you'd think. there'd need to be a certification process, and some detailed tracking of what cards of various types are/arn't supported, beyond just the base system. remember that when you by a "Dell Whatever" pre-built system, you have no real idea what exact video, network, or whatever card's in it; Dell (and all the others) think it's fine to change revisions of cards.
the site's a bit low on details, no? i want a bit more tech info. for example, if it's driverless, why list the three(Win32, MacOS, and Linux) OS's they "support" at all? shouldn't anything with USB drivers work? and, oh, why're they making Win32 drivers available, if it's driveress?
personally, i'll hold out for a firewire version. transfering up to 1GB at USB speeds is a bit slow for me.
funny, i used to work on a speech recognition/tts project for a currently beleagured telecom equipment manufacturer. i'm also a musican (comments on quality aside). and i'm quite certain pushing guitar is harder. modern speech recognition systems are highly forgiving compared to the ears of an audiophile. we did multi-chanel streaming ASR (over TCP/IP over ethernet and ISDN), and typically a 64kbit pipe was plenty for a chanel.
they go over in pretty good detail in the spec how they use the bandwidth, and it all seems quite reasonable. further, note that they're using multiple chanels, for multiple instruments, possibly over a given link. and what's more (and is clear in the spec) they do have broadcast, if only for negotiation, device enumeration, and whatnot. but their lowest sample rate is CD-quality (44.1), and they go up from there.
yeah, so it's not ethernet. big deal. what's your issue? did you read the spec? there's good reasons they don't want any extra overhead, even the relatively minimal overhead imposed by ethernet. it's not like they're running IP over the link, or any other higher-level protocol. everything's designed for exactly one function, and highly optimized for it. real-time uncompressed live audio at analog quality is tough. you'd loose your bet.
now, as other people have mentioned, they might have been able to get away with using straight FireWire and had it just work...
well, gmake isn't available for Plan 9, for one thing, and that's the system i personally care most about (well, and Inferno, but i wouldn't expect it be work there). i tried building it some time ago, and couldn't: problems, ironicly enough, getting their autoconf-generated configure scripts to work on Plan 9. i spent alot of time trying to get it to work, and couldn't. having just pulled down the latest version now, and poked breifly, it doesn't look like the situation's improved there.
more practically, i've admined many unix (primarialy Solaris, but others as well) boxes which didn't have gmake installed. when i want package foo, i don't want to have to install gmake to get it, particularly on sensative systems or in situations where time and/or space is a concern. i've also been a user on boxes other people administer. disk quotas often make builiding and storing my own build tools impractical when what i really want is some other package.
i've written makefiles for several (admitedly small) projects, and not found it to be a problem. mk is better, but less commonly available. i still think if you're aiming at portability or generality of your build process, use the straight make.
communities have been developing around web logs for thousands of years? wow. huh. i wonder if Moses had to worry about first post noise or trolls.
i may well be in the minority among this crowd, but i think you should avoid autoconf like the plauge. people's most common reason for using autoconf/configure is portability, but that's a cop-out.
basically, the autoconf/configure school of portability says "forget about actually writing portable code, just write it for each variant and let the build process pick". that's whacked. you'll continually be running accross new variants, new ways in which systems are different, or just new systems. for example, i use Plan 9, which has a very good ANSI/POSIX compatability system (better than many *nix systems). despite being near-fully ANSI compliant, pretty much every autoconf fails because it doesn't recognize the output of uname or something stupid like that (of course, that says noting about when programs that claim to be ANSI or POSIX arn't, like including non-ANSI/POSIX headers, typically BSD stuff).
this school of portability also typically makes your code far less readable - littering it with ifdef's every third line - and much larger. it ends up taking much more time than just slowing down and disiplining yourself to write real portable code.
the argument 'configure ; make ; make install' is easy is stupid, as well. y'know why? 'cause 'make install' is easier. build your makefiles well. the 'install' target should have prerequisits, obviously. make will build them for install. and 'configure' is slower and more prone to failure than 'cp makefile.linux.386 makefile'. and light years more reliable. and editing an example makefile is way easier than putzing with autoconf/configure if something doesn't work. not to mention easier to debug (uh, 'echo' anyone?).
on a personal note, having done portability work a good bunch, i'd offer just a little extra advice: do not require GNU-specific stuff. don't use any of the gmake-specific features or gcc language extentions. GNU propaganda, that'll just kill your portability. and if you need something both simpler and more powerful than make, check out mk from the Plan 9 and Inferno distrubutions. Vita Nuova's got a version that runs on various unixes and win32 systems. it's very similar to make, but a bit more general and flexible. but, given that you've already got all the makefiles, i'd suggest your best bet is just sticking with plain makefiles and cleaning them up.
Public Domain, unfortunatly, isn't really a practical licensing model for individuals or institutions with alot to loose who want anyone to use their stuff; it provides no protections for the author/developer. the BSD license was originally developed (by University of California Berkeley) to address just this problem. i agree that the GPL is too restrictive to be appropriate in this case, but i want the universities protected more than PubDom offers. the BSD license also permits closed-source commercial modifications and redistribution.
in my mind, the eventual disposition of the IP rights depend on where the funding for the research came from. in public institutions, like state schools, this should be clear: they're public institutions, funded by public money, so the public should get the benefits. that's simply an evolution of the original concept of public educations: we give money to educational institutions so society as a whole can benefit. in private institutions, it's less clear, since the public money (almost all private universities still get lots of public money) is usually a minority. but lots of big companies help fund research in public schools and still expect to get the results, and that doesn't make sense.
- M$'s monopoly has helped keep Linux out of schools
- Linux not being in schools discouraged edu. app writers from porting to or writing for Linux
- putting Linux into schools would encourage greater edu. app support for Linux
- this would increase Linux' momentum, impacting M$'s monopoly
- this would acomplish the real goal here, punishing M$ and preventing future offenses.
all this is true, entirely logical, and valid reasoning. the problem here is that it would, until the software companies catch up, very much degrade the usefulness of those computers to the schools that recieve them. while it's certainly a huge improvement over M$'s "offer", something that doesn't diminish the positive effects would be even better.to which i'd propose swapping Apple for Linux. administratively, it's much more familiar to the people who'll be running these boxes, Apple can absorb the support costs better than Red Hat, and Apple's already got both a very positive reputation and good app support in the education sector. and, of course, Apple's been hurt probably much worse than Linux (since they've been abused my M$'s monopoly before Linux was a concern), so it's a further improvement to the punative nature of the settlement.
you're right, linux isn't (currently?) up to the task, primarialy because of software base (questions about Linux's suitability for non-geek desktops aside). but Red Hat's offer still has some good ideas in it. helping the schools is always nice, since no government in the US gives them the cash they should have, and the counter-offer does take M$'s obviously self-serving ploy and turn it into something really punative. targeting the poorest schools is also a nice move (on the part of M$ and Red Hat). and, most importantly, it's likely to have some lasting effect as it may (hopefully) encourage a viable long-term competitor to M$.
so, if it's a good idea, but RH and Linux can't pull it off, who can? simple: Apple. they've already got a good reputation in the education sector, they've got good app support, and it's their traditional strong suit anyway. it'd also avoid subsidizing one of M$'s biggest de facto partners (Intel), who've also benefited quite a bit from M$ abusing their monopoly.
so, how 'bout it, Apple? wanna step up to bat for the kids, put M$ in their place, and improve your long-term prospects for years to come, just for the cost of some support?