Of course there's a standard. (Standards, anyway.) We have USB and Firewire interconnect. We have vfat and hfs file systems (and maybe ext2/3, jffs2, and ufs). We have mp3, Ogg, and AAC file formats.
Let the in-dash gadget treat your player as an external drive, and play whatever's on it. How hard could it be?
It would have helped if the lead story had actually said what this thing is that it was promoting. I had visions of some kind of headset with electromagnetic neurocouplers to bypass my (damaged) ears.
Instead, it's just some damn car accessory, and I don't even have a car (or an iPod, for that matter.)
JVMs are highly compatible. No-one specifies which manufacturer's VM to run on. If they do, its just to show which ones they have tested.... This is fact. If you don't believe me, try it yourself.
Compatibility was always the claim, but that's "marketing". Experience shows that it is elusive. Saying it doesn't make it so. Wishful thinking doesn't make it so.
C/C++ library compatibilities always have been a problem. apt-get simply allows you to automatically fix compatibility issues, but other packaging systems such as rpms don't do this...
Yes, the RPM packaging conventions are stupidly broken. That obviously has nothing to do with the various languages of the programs packaged. Java program and library RPMs suffer the same "RPM hell" as everything else. Apt (and Debian packaging policies) don't "fix" anything, they just avoid creating the problems in the first place. JVM incompatibilities are of an entirely different order.
Speed and language implementation issues with C++ aren't trivial or simple. Virtual method lookup is a simple idea in principle, but making it efficient is very important when you might be making millions of such calls each second. Other matters are the overheads of constructor and destructor calling, particularly with deep inheritance. Fast code requires a lot of skill from the coder and quality compilers.
Fast code always depends on skilled coding, and always will, but "virtual method lookup" really is trivial. To pretend otherwise is just blowing smoke. There are only two ways to do it -- function pointer calls, and thunks -- both perfectly understood from day one, and both trivial to implement optimally. Constructors and destructors are just functions. Deep inheritance is a systemic architectural flaw, in any language; you can't draw meaningful conclusions from stupid code.
As for management issues and C++ coding, you can't have it both ways. Either C++ is so good that its features prevent problems such as buffer overruns, or it is necessary for management to impose good practice because it is easy for developers.
That's stupid. Netscape coding standards forbade use of modern language features. That is an example of management failure.
As for memory and resource management, Java has full control of any resources it needs. You can either let garbage collection deal with files, network sockets, threads, GUI objects etc., or you can manually close those resources. You don't have to do this by hand in Java, but you can if you want to. Garbage collection is not, and never has been, just to do with memory.
In other words, any resource to be managed has to be known to the runtime, and it will be gathered "someday" (or maybe never), in more or less random order. If that's not good enough, you have no other choice but to do it manually, like C.
It would be hard to say whether GNOME coming to depend on Mono or on Java would be worse. Each outcome, on reflection, looks worse than the other. Sun and Microsoft both have submarine patents on the runtime techniques, and both are deeply hostile to Free Software: MS would like to kill it, while Sun hopes to "0wn" it. The only saving grace in Java's case is Gcj, which might be proof against patent risks. There's no equivalent for C#.
Both are cargo-cult languages, with features shoveled in without understanding how they interact. (As a result, e.g., using exceptions in Java doesn't actually lead to simpler code.) We still have no other language as useful for serious application and library development as C++. It's a pity that the GNOME crew are so ridden with superstition by their exposure to early (and badly broken) MSVC++ as to be unable to perceive the merits of ISO standard C++. It's is free, legally safe, and (like Algol-60) "an improvement not just on its predecessors, but on its intended successors". Someday there will be a language that deserves to replace C++ for serious work, but it won't be Java or C#.
Most people who run Java programs have no idea that they are running Java programs.
First they had to get a JVM installed. Then they had to try installing another to see if the program would work on that one, instead.
Java apps can be packaged as a single JAR or WAR file that can be run just by clicking on it, or putting into the right directory of an app server. Alternatively, you can set up networked installs via WebStart. The thing is you can prepare a single binary for all platforms.
So, these JAR things identify for me which JVM (and version) they actually have been tested to work with, and install it for me, or find the right one (among the half-dozen JVMs I had to install for the other programs) if it's already installed?
With C++ you need to get the right compiled binary for the processor, and the right versions of system libraries: just look at the trials of installing something via rpms.
One line: "apt-get install <program>". Why would I want a binary for some machine other than what I have?
As for speed - you must have a short memory. In the 80s and early 90s there were serious worries about C++ performance, with many complaints that it was far too slow when compared with C or assembler. Remember the complaints about the speed of early versions of Mozilla? It was so bad that many of us assumed it was some interpreted system. No - it was C++!
Comments pretending to compare speed of C and C++ were obvious fabrications. The compilers generate the same code for the same constructs, C or C++. We have since learned that programs written using exceptions run faster than those in C style.
Mozilla, of course, really is largely interpreted: the language is XUL. However, it doesn't seem slow any more.
(Does repeating others' lies from the '90s improve your own credibility?)
As for 'just working' and 'security flaws' this is directly contrary to evidence. Unless you code using bounds-checked collection libraries (which can be intrinsically slow) there is absolutely no difference between C++ and C in terms of memory access, and an equal possibility of buffer overruns.
C coders and C++ coders code differently. In particular, C++ coders have access to a very rich standard library (not to mention other libraries) in which it would actually be extra work to write code with buffer overruns. Errors are possible in any language; what matters is how easy they are to avoid without giving up performance and control.
It's not very persuasive to experienced people to cite "evidence" without actually presenting any of it.
As for garbage collection: The comment about niche uses is just nonsense. Not by any rational definition could languages such as Java and C# be defined as 'niche'.
I suppose that when you're stuck in a niche, it looks like the whole world. "They ain't ignorant, they just don't know no different."
The Soviet Union used to publish positively wonderful introductory textbooks, in multiple
languages, written by heads of major institutes.
In many cases, these texts are still the best book in their respective fields (e.g. electromagnetics).
These texts can still be found occasionally in used-book stores. They would make an excellent basis for a library of Free texts, if they could be liberated.
Re:They should stick with C
on
The GNOME Roadmap
·
· Score: 3, Insightful
They don't need to "consider" C++. It's already fully supported, via Murray Cummings's gtkmm and gnomemm wrappers. He also has an application framework called "Bakery" to make it easier to churn out apps. All we need is to transcribe programs written in the proprietary languages into Free, standard C++, and make them faster, more robust, and easier to install at the same time.
Miguel and his cronies are oddly superstitious toward C++. They have probably never actually seen it in its modern (standard) form, probably having been exposed only to early MSVC++. You generally don't even know if you're running a C++ program; they are easy to install (no buggy JVM) and they don't tend to crash or leak, so they don't call attention to themselves. Apt-get is a C++ program; were you ever obliged to notice?
It's a shame that Ximian are planning to make Evolution 2 depend on Mono. Looks like it's time to fork. I'd be happy to stick with Evo 1.4.x, myself. Nothing they talk about adding for 2 is anything I want.
Notice that nowhere in the article does he actually report the speed of any program not in Erlang; in particular, not C++. Whenever he mentions comparing the readability of his code to the same thing in some other language (although he ever actually does) he compares to C, despite that everything he does would be easy and clean in C++.
This essay is a disgracefully misleading piece of legerdemain.
The lesson to take away is that (1) C is almost always a poor choice, if alternatives (such as C++) are organizationally possible; (2) Erlang is not appreciably nicer to code or optimize than C++ (else he would have compared to it instead of C); and (3) the C++ code, optimized in the same way he did his Erlang code, would have been embarrassingly faster (else he would have clocked it).
We are still waiting to see the language that can take the mantle from C++, for industrial uses. Unfortunately, we have become used to reading lies from promoters of slow or otherwise insufficiently capable languages. It will be hard to recognize the language that ought to replace C++, because what is said about it will read a lot like the lies.
Reference counting can be an inefficient way to do memory management if, in fact, it is the only way one does memory management. In practice, in C++ programs, only very few of the objects are reference-counted, so that argument is irrelevant, in context.
... most languages let you manually manage non-memory resources
The goal is to enable encapsulation of resource management. In C++ one normally encapsulates management of all resources the same way. In most GC languages, as in C, you are left with no choice but to manage them manually, because you are offered no other alternative. That's the problem. GC is often an attempt to hide the problem "under the rug". In academia, where programs often manage no resources other than memory, the problem may easily remain hidden. Languages that are successful in academia have a way of failing to escape it, for sound practical (but avoidable!) reasons.
We sorely need a replacement for C++, but
academia has thus far failed to provide one.
You have misunderstood the whole thing completely.
How insightful to know precisely what I do and do not understand.
Of course sloppiness in memory management (as practiced in all invisible GC systems) is far more easy to tolerate than mismanagement of other resources. Even yet, users complain legitimately about enormous memory footprints and code that spends most of its time idle, waiting on main memory. It may be that the majority of programs have no need to manage anything but memory, and for those, GC is the ideal solution, assuming (as is common) that performance doesn't matter.
Some of us would like nice notation, but need practicality, and we don't get it from the languages that offer the nice notation. The fault lies with those who offer us languages with nice notation but without practical usefulness. (More fault lies with those who offer us neither, such as is embodied in Java.) Is practicality inherently contrary to pleasant notation? I say not.
I will be the first to abandon C++ when a language that really is practically better comes along, because I have work to do. Pretenses don't help anybody but academics, and not them in the long run.
But I think you're confusing two concepts here. Compile-time vs. runtime semantics is a whole other axis for comparing languages. We use C++ in circumstances where a "method not implemented" (in Smalltalk parlance) message thrown in the customer's face at random intervals is considered evidence of incompetence. We like compile-time verification and only wish we had more of it.
Of course it can be fun to have a compiler in your runtime system, and generate code for it on the fly.
I have heard of people programming GNULinux systems in languages other than C. I myself have used C++ and Python to write industrial applications on GNU/Linux. Each such program used POSIX C libraries underneath.
I can't think of any program I would write on GNU/Linux that I would voluntarily choose to write in C. C is "the language for Linux" only if you only write kernel code. The kernel maintainers have enforced this restriction not because C is powerful, but rather because it is not powerful, and thus can't surprise anybody much (modulo macros).
The continued common usage of C for application programming is probably a result of language and library ABI instability in other languages, leaving C as the lingua franca for interoperability, at least in libraries. C++ ABI-instability, at least, will soon be a thing of the past, probably before gcc-3.5. After libraries built to a stable ABI make it into the distributions, it will be a lot less risky to depend on them.
how... do iostream's go faster than glibc's fstreams, when the iostreams ultimately _call_ the f*() functions?
Simple: they don't. They call read() and write(),
and do their own buffering. Even if they did use
fread() and fwrite(), they would still be able to do their their own per-character buffering, and their own numeric formatting and parsing, and thus be faster.
No, he said it was the sound chip built into his Intel motherboard. That is necessarily a plain vanilla sound chip.
Anyway, the admitted he did get it working, and then rebooted and couldn't hear it any more. Apparently he never reset the default volume level, and when he rebooted, it was at zero. It really was working, but he just couldn't hear it.
Instead of checking the volume level, then, he went on a rampage installing a dozen other distros (but not any of the ones that would have worked because they use ALSA by default), and never tried ALSA again. This is not a guy who wants something to work, this is a guy desperate to come up with something to complain about in print.
That said, it's pretty stupid that ALSA defaults to a zero volume level. Speaker/amps have analog volume controls, so it would better default to maximum. At least then it would be obvious that it was working, and stand a good chance of being right already. (I always set my mixer to maximum volume.)
Used to be the pundits said Linux could never go mainstream because there were no office apps, or was too hard to install, or because you couldn't get phone support.
Now it can't go mainstream because one pundit has trouble with one easily-replaced $10 sound card. Next, they'll say it can't go mainstream because the borders on the "Cancel" buttons are not quite the right shade, or because you can't install MS security patches.
Remarkably, it is not considered fraud to promote perpetual motion machines like this in the U.S. A century's worth of case law has established firmly that it's the investor's responsibility to discover the trick underneath, and the "inventor" can tell any lies he likes.
The Xbox is a loss-leader, which means each one sold costs them money. They make it up on the games. This means that every game sold to play on CXBX makes them more money than if you bought it to play on an Xbox.
What would hurt MS would be if people found ways to use Xboxes that didn't involve playing any of MS's or otherwise-licensed games. Setting up a Linux workstation -- or a whole lab full of Linux stations -- would be one such use. At $200 it was not clearly a better value than a white box, but at $150 the balance might have shifted. The next price drop (I'm guessing late September) should clinch it.
For every message their lawyer sends, ask questions that will take lots of time. Stall, ask for further explanations, examples. The client gets billed for it all at extortionate rates. While it enriches the lawyers inequitably, it also makes the client less inclined to keep pursuing the matter when it's just something stupid.
Ask for proof that they have registered "hard radio" in addition to the one-word bumpycaps "HardRadio".
Ask for proof that in addition to "HardRadio" they registered "hardradio". Ask if they are claiming the words "hard" and "radio" individually. Ask if they are claiming "radio hard". Use your imagination.
There is a U.S. "ANSI" (now "NCITS", I think) official standard for defining flowchart formats. ANSI standards come up for review and revision, or retirement. every five years.
Each time the flowcharting standard comes up, there is some discussion about whether to retire it. They always decide not to, because there are many contracts that specify a flowchart, and would have to be renegotiated if there were no such standard. The most reasonable change, were it to be changed, would be to allow a single blank sheet
to qualify as describing any program.
Most contractors nowadays run a program over the completed source code, and produce a several-inch-thick line-printer listing. It gets stuck in a warehouse with all the other ones, stored for N decades, and then shredded on schedule, all at government expense.
All the graphs looked alike to me: an icon in the middle of a rectangle. Would anybody care to post PNGs?
(Note: I am very happy, otherwise, that flash ads don't clutter my Galeon window. If I could click on any flash that I actually want to see, that might be OK, as long as it didn't execute any actual buggy, insecure Macromedia code. But what good is it, really? Tufte had the word: "chartjunk".)
First, Sun is not interested in sharing success with Free Software, even if not sharing might mean failure. All the value for Sun in Java lies in its possible use against perceived competitors; to give that up would be to eliminate all its value, because it has no monetary value. As we will see, it wouldn't matter if they were willing, but it degrades Free Software to be seen begging for scraps when it is, in fact, in the position of strength in the real world outside of the Java fence.
Second, Free Software would not benefit from any influx of Java usage; it is to our credit that Java usage is substantially confined to those already obliged to use it for various more-or-less proprietary reasons, and that JVMs are only very spottily deployed on Linux and BSD hosts. Java's design was meant to attack problems that Free Software just doesn't have, and its means of solving those problems actually interferes with addressing the problems we do have. Every problem solved without Java is to our credit, and every problem solved with it creates further problems.
Third, any merit that might be found in Java inheres necessarily to a greater degree in C#, which is already substantially Free (as an ECMA standard) and which corrects many (but not most) of Java's fundamental design flaws. While C# has the same fundamental problems alluded to in the second point above, it bypasses the legal and proprietary problems Sun has imposed, even though it still reserves a rapacious corporation's ability to stab Free Software in the back at any opportune future moment.
Therefore, if Java were the answer to anything, C# would be a better answer, and any attention devoted to begging Sun for Java bones would be better spent on implementing the ECMA C# standard. In any case, that would be pointless, because Free Software doesn't need Java or C#. Their only value is to the proprietary software industry. Any Free Software attention to them delivers value to the Free Software community only insofar as it helps lead proprietary software users over the fence to freedom.
Slashdot Mirror
Of course there's a standard. (Standards, anyway.) We have USB and Firewire interconnect. We have vfat and hfs file systems (and maybe ext2/3, jffs2, and ufs). We have mp3, Ogg, and AAC file formats.
Let the in-dash gadget treat your player as an external drive, and play whatever's on it. How hard could it be?
It would have helped if the lead story had actually said what this thing is that it was promoting. I had visions of some kind of headset with electromagnetic neurocouplers to bypass my (damaged) ears.
Instead, it's just some damn car accessory, and I don't even have a car (or an iPod, for that matter.)
Of course Ray Bradbury got that title from Walt Whitman. (Funny that he is demanding that Moore change the title of his movie, considering...)
Compatibility was always the claim, but that's "marketing". Experience shows that it is elusive. Saying it doesn't make it so. Wishful thinking doesn't make it so.
C/C++ library compatibilities always have been a problem. apt-get simply allows you to automatically fix compatibility issues, but other packaging systems such as rpms don't do this...
Yes, the RPM packaging conventions are stupidly broken. That obviously has nothing to do with the various languages of the programs packaged. Java program and library RPMs suffer the same "RPM hell" as everything else. Apt (and Debian packaging policies) don't "fix" anything, they just avoid creating the problems in the first place. JVM incompatibilities are of an entirely different order.
Speed and language implementation issues with C++ aren't trivial or simple. Virtual method lookup is a simple idea in principle, but making it efficient is very important when you might be making millions of such calls each second. Other matters are the overheads of constructor and destructor calling, particularly with deep inheritance. Fast code requires a lot of skill from the coder and quality compilers.
Fast code always depends on skilled coding, and always will, but "virtual method lookup" really is trivial. To pretend otherwise is just blowing smoke. There are only two ways to do it -- function pointer calls, and thunks -- both perfectly understood from day one, and both trivial to implement optimally. Constructors and destructors are just functions. Deep inheritance is a systemic architectural flaw, in any language; you can't draw meaningful conclusions from stupid code.
As for management issues and C++ coding, you can't have it both ways. Either C++ is so good that its features prevent problems such as buffer overruns, or it is necessary for management to impose good practice because it is easy for developers.
That's stupid. Netscape coding standards forbade use of modern language features. That is an example of management failure.
As for memory and resource management, Java has full control of any resources it needs. You can either let garbage collection deal with files, network sockets, threads, GUI objects etc., or you can manually close those resources. You don't have to do this by hand in Java, but you can if you want to. Garbage collection is not, and never has been, just to do with memory.
In other words, any resource to be managed has to be known to the runtime, and it will be gathered "someday" (or maybe never), in more or less random order. If that's not good enough, you have no other choice but to do it manually, like C.
It would be hard to say whether GNOME coming to depend on Mono or on Java would be worse. Each outcome, on reflection, looks worse than the other. Sun and Microsoft both have submarine patents on the runtime techniques, and both are deeply hostile to Free Software: MS would like to kill it, while Sun hopes to "0wn" it. The only saving grace in Java's case is Gcj, which might be proof against patent risks. There's no equivalent for C#.
Both are cargo-cult languages, with features shoveled in without understanding how they interact. (As a result, e.g., using exceptions in Java doesn't actually lead to simpler code.) We still have no other language as useful for serious application and library development as C++. It's a pity that the GNOME crew are so ridden with superstition by their exposure to early (and badly broken) MSVC++ as to be unable to perceive the merits of ISO standard C++. It's is free, legally safe, and (like Algol-60) "an improvement not just on its predecessors, but on its intended successors". Someday there will be a language that deserves to replace C++ for serious work, but it won't be Java or C#.
Nat remarked in a recent interview that Evo 2 would depend on Mono. Did I understand correctly?
First they had to get a JVM installed. Then they had to try installing another to see if the program would work on that one, instead.
Java apps can be packaged as a single JAR or WAR file that can be run just by clicking on it, or putting into the right directory of an app server. Alternatively, you can set up networked installs via WebStart. The thing is you can prepare a single binary for all platforms.
So, these JAR things identify for me which JVM (and version) they actually have been tested to work with, and install it for me, or find the right one (among the half-dozen JVMs I had to install for the other programs) if it's already installed?
With C++ you need to get the right compiled binary for the processor, and the right versions of system libraries: just look at the trials of installing something via rpms.
One line: "apt-get install <program>". Why would I want a binary for some machine other than what I have?
As for speed - you must have a short memory. In the 80s and early 90s there were serious worries about C++ performance, with many complaints that it was far too slow when compared with C or assembler. Remember the complaints about the speed of early versions of Mozilla? It was so bad that many of us assumed it was some interpreted system. No - it was C++!
Comments pretending to compare speed of C and C++ were obvious fabrications. The compilers generate the same code for the same constructs, C or C++. We have since learned that programs written using exceptions run faster than those in C style.
Mozilla, of course, really is largely interpreted: the language is XUL. However, it doesn't seem slow any more.
(Does repeating others' lies from the '90s improve your own credibility?)
As for 'just working' and 'security flaws' this is directly contrary to evidence. Unless you code using bounds-checked collection libraries (which can be intrinsically slow) there is absolutely no difference between C++ and C in terms of memory access, and an equal possibility of buffer overruns.
C coders and C++ coders code differently. In particular, C++ coders have access to a very rich standard library (not to mention other libraries) in which it would actually be extra work to write code with buffer overruns. Errors are possible in any language; what matters is how easy they are to avoid without giving up performance and control.
It's not very persuasive to experienced people to cite "evidence" without actually presenting any of it.
As for garbage collection: The comment about niche uses is just nonsense. Not by any rational definition could languages such as Java and C# be defined as 'niche'.
I suppose that when you're stuck in a niche, it looks like the whole world. "They ain't ignorant, they just don't know no different."
These texts can still be found occasionally in used-book stores. They would make an excellent basis for a library of Free texts, if they could be liberated.
Miguel and his cronies are oddly superstitious toward C++. They have probably never actually seen it in its modern (standard) form, probably having been exposed only to early MSVC++. You generally don't even know if you're running a C++ program; they are easy to install (no buggy JVM) and they don't tend to crash or leak, so they don't call attention to themselves. Apt-get is a C++ program; were you ever obliged to notice?
It's a shame that Ximian are planning to make Evolution 2 depend on Mono. Looks like it's time to fork. I'd be happy to stick with Evo 1.4.x, myself. Nothing they talk about adding for 2 is anything I want.
Most Free Software platforms have Gcc on them already. Gcc could be part of the runtime, in place of some anonymous JITter.
This essay is a disgracefully misleading piece of legerdemain.
The lesson to take away is that (1) C is almost always a poor choice, if alternatives (such as C++) are organizationally possible; (2) Erlang is not appreciably nicer to code or optimize than C++ (else he would have compared to it instead of C); and (3) the C++ code, optimized in the same way he did his Erlang code, would have been embarrassingly faster (else he would have clocked it).
We are still waiting to see the language that can take the mantle from C++, for industrial uses. Unfortunately, we have become used to reading lies from promoters of slow or otherwise insufficiently capable languages. It will be hard to recognize the language that ought to replace C++, because what is said about it will read a lot like the lies.
The goal is to enable encapsulation of resource management. In C++ one normally encapsulates management of all resources the same way. In most GC languages, as in C, you are left with no choice but to manage them manually, because you are offered no other alternative. That's the problem. GC is often an attempt to hide the problem "under the rug". In academia, where programs often manage no resources other than memory, the problem may easily remain hidden. Languages that are successful in academia have a way of failing to escape it, for sound practical (but avoidable!) reasons.
We sorely need a replacement for C++, but academia has thus far failed to provide one.
How insightful to know precisely what I do and do not understand.
Of course sloppiness in memory management (as practiced in all invisible GC systems) is far more easy to tolerate than mismanagement of other resources. Even yet, users complain legitimately about enormous memory footprints and code that spends most of its time idle, waiting on main memory. It may be that the majority of programs have no need to manage anything but memory, and for those, GC is the ideal solution, assuming (as is common) that performance doesn't matter.
Some of us would like nice notation, but need practicality, and we don't get it from the languages that offer the nice notation. The fault lies with those who offer us languages with nice notation but without practical usefulness. (More fault lies with those who offer us neither, such as is embodied in Java.) Is practicality inherently contrary to pleasant notation? I say not.
I will be the first to abandon C++ when a language that really is practically better comes along, because I have work to do. Pretenses don't help anybody but academics, and not them in the long run.
But I think you're confusing two concepts here. Compile-time vs. runtime semantics is a whole other axis for comparing languages. We use C++ in circumstances where a "method not implemented" (in Smalltalk parlance) message thrown in the customer's face at random intervals is considered evidence of incompetence. We like compile-time verification and only wish we had more of it.
Of course it can be fun to have a compiler in your runtime system, and generate code for it on the fly.
The continued common usage of C for application programming is probably a result of language and library ABI instability in other languages, leaving C as the lingua franca for interoperability, at least in libraries. C++ ABI-instability, at least, will soon be a thing of the past, probably before gcc-3.5. After libraries built to a stable ABI make it into the distributions, it will be a lot less risky to depend on them.
Simple: they don't. They call read() and write(), and do their own buffering. Even if they did use fread() and fwrite(), they would still be able to do their their own per-character buffering, and their own numeric formatting and parsing, and thus be faster.
p.s. I call "Troll".
Instead of checking the volume level, then, he went on a rampage installing a dozen other distros (but not any of the ones that would have worked because they use ALSA by default), and never tried ALSA again. This is not a guy who wants something to work, this is a guy desperate to come up with something to complain about in print.
That said, it's pretty stupid that ALSA defaults to a zero volume level. Speaker/amps have analog volume controls, so it would better default to maximum. At least then it would be obvious that it was working, and stand a good chance of being right already. (I always set my mixer to maximum volume.)
Now it can't go mainstream because one pundit has trouble with one easily-replaced $10 sound card. Next, they'll say it can't go mainstream because the borders on the "Cancel" buttons are not quite the right shade, or because you can't install MS security patches.
(Ianal.)
What would hurt MS would be if people found ways to use Xboxes that didn't involve playing any of MS's or otherwise-licensed games. Setting up a Linux workstation -- or a whole lab full of Linux stations -- would be one such use. At $200 it was not clearly a better value than a white box, but at $150 the balance might have shifted. The next price drop (I'm guessing late September) should clinch it.
Therefore, you can write about "xeroxing", "googling", "windsurfing", "jetskiing", etc., and there's nothing Xerox or Google etc. can do but whine.
Ask for proof that they have registered "hard radio" in addition to the one-word bumpycaps "HardRadio". Ask for proof that in addition to "HardRadio" they registered "hardradio". Ask if they are claiming the words "hard" and "radio" individually. Ask if they are claiming "radio hard". Use your imagination.
Each time the flowcharting standard comes up, there is some discussion about whether to retire it. They always decide not to, because there are many contracts that specify a flowchart, and would have to be renegotiated if there were no such standard. The most reasonable change, were it to be changed, would be to allow a single blank sheet to qualify as describing any program.
Most contractors nowadays run a program over the completed source code, and produce a several-inch-thick line-printer listing. It gets stuck in a warehouse with all the other ones, stored for N decades, and then shredded on schedule, all at government expense.
(Note: I am very happy, otherwise, that flash ads don't clutter my Galeon window. If I could click on any flash that I actually want to see, that might be OK, as long as it didn't execute any actual buggy, insecure Macromedia code. But what good is it, really? Tufte had the word: "chartjunk".)
Second, Free Software would not benefit from any influx of Java usage; it is to our credit that Java usage is substantially confined to those already obliged to use it for various more-or-less proprietary reasons, and that JVMs are only very spottily deployed on Linux and BSD hosts. Java's design was meant to attack problems that Free Software just doesn't have, and its means of solving those problems actually interferes with addressing the problems we do have. Every problem solved without Java is to our credit, and every problem solved with it creates further problems.
Third, any merit that might be found in Java inheres necessarily to a greater degree in C#, which is already substantially Free (as an ECMA standard) and which corrects many (but not most) of Java's fundamental design flaws. While C# has the same fundamental problems alluded to in the second point above, it bypasses the legal and proprietary problems Sun has imposed, even though it still reserves a rapacious corporation's ability to stab Free Software in the back at any opportune future moment.
Therefore, if Java were the answer to anything, C# would be a better answer, and any attention devoted to begging Sun for Java bones would be better spent on implementing the ECMA C# standard. In any case, that would be pointless, because Free Software doesn't need Java or C#. Their only value is to the proprietary software industry. Any Free Software attention to them delivers value to the Free Software community only insofar as it helps lead proprietary software users over the fence to freedom.