They have audible sirens so you know to look around. The colors help you spot it once you're looking. (Good drivers check their mirrors fairly often, but...)
No, NUMA in general. It's useful for all kinds of things. Beowulf is limited by its interconnects relative to a good NUMA implementation, so this is useful to people who need lots of CPUs and one big virtual address space.
AFAIK, no. Not with ext2 at least if you're moving the file from one place on a filesystem to another on the same filesystem. The data doesn't actually get moved. All that changes is the link to the inode. (can somebody correct me / elaborate)
You're right. Moving a file within the same filesystem is actually just renaming it. This is what the rename(2) system call does. Making link(2)s and unlink(2)ing from other places also has no effect, as long as there is at least one link or a program still has the file open. There is no system call to move a file between filesystems, but mv(1) will copy and then delete the source if rename(2) fails (which it will if the source and dest aren't on the same filesystem.)
... collect the body heat with a cooling system, and radiate away in the ultraviolet rather than in the IR). It should also be possible to radiate away the heat in a suitably directed narrow beam, rather than uniformly.
The fatal flaw is that you can't stick all your heat into something small without using a lot of extra energy. (Think thermodynamics.) You can't generate e.g. electrical energy from the temp. diff. between your body and the surroundings efficiently (because they are of similar temp.). Most of the heat flows through anyway. That rules out converting to some other energy form to power a narrow-band UV emitter (or, more usefully, your radio!). There are other problems with blackbody emitters for this job:
If the only emission is going to be through blackbody radiation, its wavelength distribution will follow the Planck distribution. Thus, even if the peak is in the UV, there will still be a large component at nearby lower energies, including the visible spectrum. The equation for brightness as a function of wavelength, for a fixed temperature perfect blackbody, is
\begin{equation}I_\lambda = \frac{2\pi h c^2}{\lambda^5 (e^{hc/\lambda k_B T} - 1)}\end{equation}
plot it or check a textbook, and you will see it has a large tail. If you wanted to avoid visible emissions, you would either have to shield the emitter with something that only transmitted UV, or you would have to operate in the X-ray region, which means even higher temperature! Carrying around a pinpoint of light is not very stealthy.
The "peak" wavelength is inversely proportional to temperature (by Wien's displacement law). For it to be 100nm, your blackbody would have to be at 30000 Kelvin. That's going to be pretty hard to do, even with good heat pumps:) Also, note that total emission power of a blackbody goes as T^4, and 30000K is 100 times higher than body temperature. The blackbody would have to have 10^8 times less surface area than the human body to stay that hot with an input of 1 human's entire heat dissipation.
I have been assuming a perfect blackbody, which need not be the case. Something that didn't radiate as much at certain wavelengths would help, but not enough. Still, I don't think you could surmount the problem of carrying around anything that small and hot, with the heat all localized.
RobertFisher had it right; To blend in to the background, you need to transfer your thermal energy to the environment without creating hot spots. Thus, you need something with really good emissivity so that the emitter doesn't have to be as warm to transfer the same amount of energy. Conduction to the air will certainly be a big factor at such a low temperature (remember the T^4 law!). What helps here is large surface area, so you can spread your heat out. Another poster mentioned a sci-fi thermal suit that had disposable "chill cans" that lasted a couple hours. I suppose an endothermic chemical reaction could do the trick. Short of that, you have to spread your heat out so it doesn't leave bright spots.
On the other hand, using convection would not help at all (the heated air would radiate in the IR just like the human body does).
If you have a high flow rate, the air won't be much higher than ambient temperature. IR detectors detect only the photons emitted, and that goes as T^4, so small hot spots are way worse than large, slightly warm, areas. Even though you affect a much larger volume, spreading out your heat should be a win.
He's obviously talking about the picture on this page, not the anime-style one used by the other articles. I'm pretty sure the bulging chest is just pectoral muscles. The anime picture is very distinctively female, though:)
The simple fact of the matter is that the average woman is nowhere near the average man in strength and fighting ability.
The armies of modern nations fight with guns and other long range weapons, not hand to hand. I think you mean soldier, not fighter. Soldiering includes all the stuff you do when you're not fighting, like carrying around heavy packs, building things, and lifting things. Women tend to have better leg strength relative to arm strength, but less overall than men, FWIW. Given all that, women can probably fight similarly to men, but they wouldn't make as good infantry.
Women who decide to go into the military are probably in better shape relative to the average woman than for guys who go into the military. (And the ones who manage to survive the negative attitudes are probably pretty tough.) This would help to make up for the gap in the averages. AFAIK, there's still a sizeable gap.
Not that there's anything wrong with that. The average man is nowhere near the average woman in other areas. We're just different, as any three-year-old can figure out, but apparently grown-up PC-types need to have explained.
Agreed. People should do what they're good at. Liking something makes you better at it, and if that makes you good enough to compensate for your lack of physical strength, then you should be allowed to do it.
I guess I should have a point to this message, or something. Here goes: Affirmitive action is dumb, unless it is needed to combat actual discrimination, not just a naturally occurring imbalance. When considering someone's qualifications for a job, military or otherwise, all non-relevant criteria should be ignored. For the army, esp. when pack-carrying and emplacement-building will be done, strength and stamina are relevant. Everyone should be judged on the same scale, male of female. The tests need to be set up to actually test the kind of strength and stamina needed, though. The correlation between the ability to run, and do chin-ups and push ups, and the ability to build things and carry packs is different for men and women. Women are smaller and have less upper body strength, etc.
People who want to command battleships or drive tanks have different physical requirements than foot soldiers, so tests for positions that aren't so physically demanding should allow people who are mentally very tough and smart to get in.
I've heard of women who failed physical tests because of sexist testers who judged as harshly as possible to try to keep women out. That's obviously a problem, the solution to which is to kick out the assholes, or put them in a battalion by themselves, or something. Easier said than done, but it causes a problem no matter what the standards are, even if there are lower standards for women.
Anyway, I don't have a problem with women being in the military, or being firefighters, or anything else. I do have a problem with standards being lowered too low. The minimum standards need to reflect what people will have to do. Maybe firefighters who aren't so strong (women or men) shouldn't be assigned to carry people down fire ladders.
Try writing a memory manager some time. I had to for a CS class, and I screwed it up big time. (I'm usually pretty good at designing software to do what I want, so my point it that it's hard.) Also, if the MM has to be able to handle double-freeing, it would have to keep more lists of stuff, and that would slow things down. For some things, allowing double-frees would be faster, while for other things I would guess that the performance benefits from not having to be able to detect it would be greater than the trouble the application has to go to to avoid it. Portable applications need to avoid it anyway, since ANSI C says it might not work. Guaranteeing it to work on GNU systems would make it that much harder to port programs written for GNU systems to other, non-GNU systems. (And what a nasty, only occasionally harmful, probably little known incompatibility it would be, too.)
Since the C standard is already established, there is little point in considering changing glibc.
BTW, I don't know about the Micros~1 "game" you referred to, so I don't know how accurate your analogy is.
They said they ran in single user mode, no GUI, on OSX and linux. That would probably mean that it was basically a text-console FreeBSD system. With no other processes running, the OS would have to waste time on purpose to slow down the benchmark!
He might care that it runs quake, or any other game, faster. AMD's hammer processors have a whole new FPU that is significantly faster than the stack-based x87 FPU.
Of course people won't care if they don't do anything that depends on the speed of their computer. Nobody said that this is for everyone.
IA64 processors can run IA32 in hardware, just not very fast. They actually boot up in IA32 mode, then switch to IA64. The reason it's slow is that they don't devote many transistors to the IA32 hardware. I don't know anything about it, but I wouldn't be surprised if the IA32 hardware is not superscalar (i.e. it has only a single pipeline.)
I don't know if it would be faster to translate IA32 to IA64 on the fly, but probably not, given how much work a compiler has to do to optimize for IA64.
You're right. UDP is just bare IP packets, but with port numbers and a checksum. IPX is like that too. IPX has SPX, which is like TCP, but over IPX instead of IP.
I'm not sure why you pointed this out, since both IP and IPX networks provide packet and stream services. I don't think IPX packets are "reliable", but I don't know.
The bandwidth 'guarantees' mentioned were in that IPX only works over ethernet, therefore it was built to rely on that speed. TCP/IP has no such inherent bandwidth.
I don't know enough about IPX to comment, but I do know that TCP/IP, and UDP/IP, have no trouble taking advantage of the speed that fast ethernet can provide. They also work fine on slower networks.
TCP/IP on an internal LAN will work fine if you have an internal IP server and router. Otherwise you may go to external routers and (depending on your uplink type) you may have severe problems related to this.
That sounds like crap to me. Your network would have to be set up very strangely for the TCP layer to think it should send packets to hosts that are on the same ethernet (and the same IP network) to a router and back. Normally configured TCP stacks, even Microsoft's, put a TCP packet destined for a machine on the same LAN into an ethernet frame addressed to that machines ethernet MAC address.
What do you mean by an IP server anyway? It sounds like you mean a DHCP server, since you say that a stand-alone IP network is harder to set up than IPX with "no IP server". That would make sense, and I agree with you on that. However, you don't seem to know that the DHCP server is consulted every few hours or days to tell it you still want your IP address (renew your lease). You don't need to send all your packets through it.
You also don't need a router. Just put all the machines that are connected to the LAN on the same IP network, e.g. 10.x.x.x.
The only advantage IPX has is that it's easier to set up an isolated IPX network because you don't have to select unique IP addresses. That's not a very good reason to force people to use that instead of TCP, since LANs, other than at parties, are set up for a long time, and usually run IP, but not usually IPX unless they were set up for games.
Considering more people have TCP/IP running by default I find it hard to beleive that it's a problem to setup at a lan party or otherwise.
Setting up a windoze LAN with TCP requires that either there is a DHCP server, or people know how to enter appropriate IP addresses. This isn't an issue when the LAN is already set up, like it would be in any home setup.
For some reason, IPX doesn't require any configuration, other than installing the drivers so the computer can talk IPX, when you're setting up 'doze computers to play LAN games. That's a good thing, since I don't have any desire to learn more about IPX than the minimal info on it in the networking classes I took.
Anyway, I have to admit that setting up IPX is probably easier for non-geeks than setting up TCP/IP on a private LAN (where you have to choose unique IP numbers from the 10.0.0.0/8 network, or one of the other local-use ones.) Even given that, there is no reason not to support TCP/IP for anything and everything.
Some people enjoy kicking the shit out of monsters, even if it isn't challenging. Some of these people are willing to pay real-world money to have more fun while playing a game. Of course they realize it's a game; They just want to spend money to increase their enjoyment of it. You can't just dismiss this out of hand.
Whether they succeed or not is a different question. You won't know how much fun you would have had if you hadn't had super-gear. I don't have anything to add to that debate.
There was also this ask slashdot. A lot of the suggested solutions were made on the assumption that it would be a security system. The person who asked the question seemed really reluctanct to divulge any information.
Distributed.net's RC5 client is _not_ and integer benchmark. It was not written to give any kind of useful comparison of different CPUs. The Athlon RC5 core is hand-tuned specially for that CPU. There is no hand-tuned core for the P4, which is one reason it does so poorly. Search the rc5 mailing list: This has already been discussed.
If you want an integer benchmark, stick with SPEC marks.
why not preallocate a chunk of memory as scratch space, so that it can be guaranteed that there is always enough memory to spawn another shell? You might even make it possible for the operator to selectively grant usage of the scratch space to memory starving processes, allowing them to complete gracefully, thus easing the memory pressure. As the original poster said, how much space is used as scratch space and which processes can access this scratch space could be site specific tunable parameters.
I don't think that solves anythink. How is the kernel going to know when to dip into the scratch space to allow a new shell to start? If it lets anything dip into it, so they can compete "gracefully", then we need a mechanism for graceful competition. We're back to square one. Why not let processes "gracefully compete" for the whole system memory in the first place. An earlier post from someone who said he'd worked on such graceful systems claimed that it would be possible to make linux gracefully handle running low on mem.
> it makes the switch time linar O(1) as opposed to exponetial O(p)
No, it makes it constant, instead of linear with the number of processes that are ready to run. Processes that are waiting for I/O (or otherwise sleeping) are not on this queue, and thus aren't slowing you down with even with the old scheduler. Your 80 processes are _not_ all running.
Besides the algorithmic complexity improvement, Ingo says he's improved CPU affinity, and made fork()+exec() more efficient by running the child on the same processor.
But as you say, the main improvement will be in large multiproc systems that are worked to the limit (so they have lots of _runnable_ processes). You won't, of course, see 600% improvement in Oracle performance or anything. That was only in synthetic benchmark. The 600% improvement is in something that takes up a fairly small (but not insignificant) part of a DB server's time.
Another thing this should help is people who run distributed.net or SETI clients. They run at nice 19, and if I read Ingo's message correctly, such processes will be treated as SCHED_IDLE: That is, they will get _no_ CPU time while you're recompiling something, or compressing a vorbis audio file, instead of the usual 7% or so they get now, when a nice=0 process wants all the CPU it can get.
Well, I'm impressed. I like how well he presented his work, it was pretty easy to understand.
Holy shit, you mean they don't even want to let us decode MP3s any more!?! Well, I won't bother transcoding the stuff I've got, I'll just hang on to some MP3-decode source code, in case I ever need to transcode. I remember seeing a shell script or similar that could do a large batch of them. Maybe it came with some vorbis package or something...
You're missing the point. If you don't have a reason to convert your MP3s to vorbis, then leave them as MP3s. All fancy playback programs (e.g. XMMS, freeamp) that support Ogg also support MP3. There are no restrictions on MP3 decoders the way there are on encoders, so The Man can't come after you and stop you decoding your MP3.
The people who are telling you not to transcode your MP3s to vorbis don't mean that you have to re-encode from the original CDs, they mean that you should not waste your time, and leave your MP3s the way they are. (If you want to re-encode from CD to get more quality, like if you just got better speakers and want more audio quality, so much the better, of course.)
Note that the vorbis codec didn't take advantage of 3DNow! at all, last time I checked (rc2), but some people were thinking about maybe putting in some 3dn support to speed up some parts of it. Anyway, MP3 has a lot of FP anyway, unless you use an integer decoder on purpose. Other than on a Cyrix, you probably want to use the FP hardware. (as for your MP3 decoder not showing up as using any CPU on Linux, that might be an illusion. Some multi-threaded decoders somehow don't show up as using as much as they are...)
Anyway, I'm pretty sure you'll be a lot happier with vorbis once you try it on an Intel chip, or an Athlon.
Sure that keeps it legal, but you do realize that you're just paying Celine Dion, don't you? I care a more about my own ethics/morals than I do about the law. I try to buy at least some CDs from artists who created music I've downloaded music and liked, unless they're already super-rich, retired, and/or dead (e.g. Jimi Hendrix, Chris Rock).
Re:There are major problems with compartmentalizat
on
HP-LX 1.0 Secure Linux
·
· Score: 1
No, you would need to use capabilities (lcap and stuff) to stop any processes from giving themselves IO priviledges. You can't turn off iopl(2) and ioperm(2) support in the kernel config, but you can remove the capability once the kernel is started, I'm pretty sure. Also, you have to disable module loading (with lcap, so you can do this after the mods you want are loaded), otherwise someone who gets root can load a kernel module that can do anything and everything they want.
Even if you were serious, what would the problem be? If they had any good ideas in the design of the systems, we can use them because the code is GPL. If not, why do I care that racist rednecks are using linux.
The only problem I could see would be the media getting it all wrong and making it look like the linux community supported them, and somehow giving linux in general a bad name because disreputable people repackage it. The worst part it that the media seems to like doing that sort of thing, since I guess it sells to the public, who apparently like to read about scandals...?
IMHO, the KKK using linux is no better and no worse than the KKK breathing air. That's is how Free software works; It's like air, free for the taking, and free to be used however you want to use it. You can pay to get the to air smell nice, or to filter the junk out of it. You can pay people to write Free software, if you don't have the time, skill, or resources to write it yourself.
Slashdot Mirror
They have audible sirens so you know to look around. The colors help you spot it once you're looking. (Good drivers check their mirrors fairly often, but ...)
No, NUMA in general. It's useful for all kinds of things. Beowulf is limited by its interconnects relative to a good NUMA implementation, so this is useful to people who need lots of CPUs and one big virtual address space.
The fatal flaw is that you can't stick all your heat into something small without using a lot of extra energy. (Think thermodynamics.) You can't generate e.g. electrical energy from the temp. diff. between your body and the surroundings efficiently (because they are of similar temp.). Most of the heat flows through anyway. That rules out converting to some other energy form to power a narrow-band UV emitter (or, more usefully, your radio!). There are other problems with blackbody emitters for this job:
If the only emission is going to be through blackbody radiation, its wavelength distribution will follow the Planck distribution. Thus, even if the peak is in the UV, there will still be a large component at nearby lower energies, including the visible spectrum. The equation for brightness as a function of wavelength, for a fixed temperature perfect blackbody, is
\begin{equation}I_\lambda = \frac{2\pi h c^2}{\lambda^5 (e^{hc/\lambda k_B T} - 1)}\end{equation}
plot it or check a textbook, and you will see it has a large tail. If you wanted to avoid visible emissions, you would either have to shield the emitter with something that only transmitted UV, or you would have to operate in the X-ray region, which means even higher temperature! Carrying around a pinpoint of light is not very stealthy.
The "peak" wavelength is inversely proportional to temperature (by Wien's displacement law). For it to be 100nm, your blackbody would have to be at 30000 Kelvin. That's going to be pretty hard to do, even with good heat pumps :) Also, note that total emission power of a blackbody goes as T^4, and 30000K is 100 times higher than body temperature. The blackbody would have to have 10^8 times less surface area than the human body to stay that hot with an input of 1 human's entire heat dissipation.
I have been assuming a perfect blackbody, which need not be the case. Something that didn't radiate as much at certain wavelengths would help, but not enough. Still, I don't think you could surmount the problem of carrying around anything that small and hot, with the heat all localized.
RobertFisher had it right; To blend in to the background, you need to transfer your thermal energy to the environment without creating hot spots. Thus, you need something with really good emissivity so that the emitter doesn't have to be as warm to transfer the same amount of energy. Conduction to the air will certainly be a big factor at such a low temperature (remember the T^4 law!). What helps here is large surface area, so you can spread your heat out. Another poster mentioned a sci-fi thermal suit that had disposable "chill cans" that lasted a couple hours. I suppose an endothermic chemical reaction could do the trick. Short of that, you have to spread your heat out so it doesn't leave bright spots.
If you have a high flow rate, the air won't be much higher than ambient temperature. IR detectors detect only the photons emitted, and that goes as T^4, so small hot spots are way worse than large, slightly warm, areas. Even though you affect a much larger volume, spreading out your heat should be a win.
He's obviously talking about the picture on this page, not the anime-style one used by the other articles. I'm pretty sure the bulging chest is just pectoral muscles. The anime picture is very distinctively female, though :)
Trebuches are for when the parachutes aren't working, I guess :)
Try writing a memory manager some time. I had to for a CS class, and I screwed it up big time. (I'm usually pretty good at designing software to do what I want, so my point it that it's hard.) Also, if the MM has to be able to handle double-freeing, it would have to keep more lists of stuff, and that would slow things down. For some things, allowing double-frees would be faster, while for other things I would guess that the performance benefits from not having to be able to detect it would be greater than the trouble the application has to go to to avoid it. Portable applications need to avoid it anyway, since ANSI C says it might not work. Guaranteeing it to work on GNU systems would make it that much harder to port programs written for GNU systems to other, non-GNU systems. (And what a nasty, only occasionally harmful, probably little known incompatibility it would be, too.)
Since the C standard is already established, there is little point in considering changing glibc.
BTW, I don't know about the Micros~1 "game" you referred to, so I don't know how accurate your analogy is.
They said they ran in single user mode, no GUI, on OSX and linux. That would probably mean that it was basically a text-console FreeBSD system. With no other processes running, the OS would have to waste time on purpose to slow down the benchmark!
He might care that it runs quake, or any other game, faster. AMD's hammer processors have a whole new FPU that is significantly faster than the stack-based x87 FPU.
Of course people won't care if they don't do anything that depends on the speed of their computer. Nobody said that this is for everyone.
IA64 processors can run IA32 in hardware, just not very fast. They actually boot up in IA32 mode, then switch to IA64. The reason it's slow is that they don't devote many transistors to the IA32 hardware. I don't know anything about it, but I wouldn't be surprised if the IA32 hardware is not superscalar (i.e. it has only a single pipeline.)
I don't know if it would be faster to translate IA32 to IA64 on the fly, but probably not, given how much work a compiler has to do to optimize for IA64.
You're right. UDP is just bare IP packets, but with port numbers and a checksum. IPX is like that too. IPX has SPX, which is like TCP, but over IPX instead of IP.
I'm not sure why you pointed this out, since both IP and IPX networks provide packet and stream services. I don't think IPX packets are "reliable", but I don't know.
I don't know enough about IPX to comment, but I do know that TCP/IP, and UDP/IP, have no trouble taking advantage of the speed that fast ethernet can provide. They also work fine on slower networks.
That sounds like crap to me. Your network would have to be set up very strangely for the TCP layer to think it should send packets to hosts that are on the same ethernet (and the same IP network) to a router and back. Normally configured TCP stacks, even Microsoft's, put a TCP packet destined for a machine on the same LAN into an ethernet frame addressed to that machines ethernet MAC address.
What do you mean by an IP server anyway? It sounds like you mean a DHCP server, since you say that a stand-alone IP network is harder to set up than IPX with "no IP server". That would make sense, and I agree with you on that. However, you don't seem to know that the DHCP server is consulted every few hours or days to tell it you still want your IP address (renew your lease). You don't need to send all your packets through it.
You also don't need a router. Just put all the machines that are connected to the LAN on the same IP network, e.g. 10.x.x.x.
The only advantage IPX has is that it's easier to set up an isolated IPX network because you don't have to select unique IP addresses. That's not a very good reason to force people to use that instead of TCP, since LANs, other than at parties, are set up for a long time, and usually run IP, but not usually IPX unless they were set up for games.
Some people enjoy kicking the shit out of monsters, even if it isn't challenging. Some of these people are willing to pay real-world money to have more fun while playing a game. Of course they realize it's a game; They just want to spend money to increase their enjoyment of it. You can't just dismiss this out of hand.
Whether they succeed or not is a different question. You won't know how much fun you would have had if you hadn't had super-gear. I don't have anything to add to that debate.
There was also this ask slashdot. A lot of the suggested solutions were made on the assumption that it would be a security system. The person who asked the question seemed really reluctanct to divulge any information.
Distributed.net's RC5 client is _not_ and integer benchmark. It was not written to give any kind of useful comparison of different CPUs. The Athlon RC5 core is hand-tuned specially for that CPU. There is no hand-tuned core for the P4, which is one reason it does so poorly. Search the rc5 mailing list: This has already been discussed. If you want an integer benchmark, stick with SPEC marks.
> it makes the switch time linar O(1) as opposed to exponetial O(p)
No, it makes it constant, instead of linear with the number of processes that are ready to run. Processes that are waiting for I/O (or otherwise sleeping) are not on this queue, and thus aren't slowing you down with even with the old scheduler. Your 80 processes are _not_ all running.
Besides the algorithmic complexity improvement, Ingo says he's improved CPU affinity, and made fork()+exec() more efficient by running the child on the same processor.
But as you say, the main improvement will be in large multiproc systems that are worked to the limit (so they have lots of _runnable_ processes). You won't, of course, see 600% improvement in Oracle performance or anything. That was only in synthetic benchmark. The 600% improvement is in something that takes up a fairly small (but not insignificant) part of a DB server's time.
Another thing this should help is people who run distributed.net or SETI clients. They run at nice 19, and if I read Ingo's message correctly, such processes will be treated as SCHED_IDLE: That is, they will get _no_ CPU time while you're recompiling something, or compressing a vorbis audio file, instead of the usual 7% or so they get now, when a nice=0 process wants all the CPU it can get.
Well, I'm impressed. I like how well he presented his work, it was pretty easy to understand.
Holy shit, you mean they don't even want to let us decode MP3s any more!?! Well, I won't bother transcoding the stuff I've got, I'll just hang on to some MP3-decode source code, in case I ever need to transcode. I remember seeing a shell script or similar that could do a large batch of them. Maybe it came with some vorbis package or something...
You're missing the point. If you don't have a reason to convert your MP3s to vorbis, then leave them as MP3s. All fancy playback programs (e.g. XMMS, freeamp) that support Ogg also support MP3. There are no restrictions on MP3 decoders the way there are on encoders, so The Man can't come after you and stop you decoding your MP3.
The people who are telling you not to transcode your MP3s to vorbis don't mean that you have to re-encode from the original CDs, they mean that you should not waste your time, and leave your MP3s the way they are. (If you want to re-encode from CD to get more quality, like if you just got better speakers and want more audio quality, so much the better, of course.)
Note that the vorbis codec didn't take advantage of 3DNow! at all, last time I checked (rc2), but some people were thinking about maybe putting in some 3dn support to speed up some parts of it. Anyway, MP3 has a lot of FP anyway, unless you use an integer decoder on purpose. Other than on a Cyrix, you probably want to use the FP hardware. (as for your MP3 decoder not showing up as using any CPU on Linux, that might be an illusion. Some multi-threaded decoders somehow don't show up as using as much as they are...)
Anyway, I'm pretty sure you'll be a lot happier with vorbis once you try it on an Intel chip, or an Athlon.
Sure that keeps it legal, but you do realize that you're just paying Celine Dion, don't you? I care a more about my own ethics/morals than I do about the law. I try to buy at least some CDs from artists who created music I've downloaded music and liked, unless they're already super-rich, retired, and/or dead (e.g. Jimi Hendrix, Chris Rock).
No, you would need to use capabilities (lcap and stuff) to stop any processes from giving themselves IO priviledges. You can't turn off iopl(2) and ioperm(2) support in the kernel config, but you can remove the capability once the kernel is started, I'm pretty sure. Also, you have to disable module loading (with lcap, so you can do this after the mods you want are loaded), otherwise someone who gets root can load a kernel module that can do anything and everything they want.
Even if you were serious, what would the problem be? If they had any good ideas in the design of the systems, we can use them because the code is GPL. If not, why do I care that racist rednecks are using linux.
The only problem I could see would be the media getting it all wrong and making it look like the linux community supported them, and somehow giving linux in general a bad name because disreputable people repackage it. The worst part it that the media seems to like doing that sort of thing, since I guess it sells to the public, who apparently like to read about scandals...?
IMHO, the KKK using linux is no better and no worse than the KKK breathing air. That's is how Free software works; It's like air, free for the taking, and free to be used however you want to use it. You can pay to get the to air smell nice, or to filter the junk out of it. You can pay people to write Free software, if you don't have the time, skill, or resources to write it yourself.