Because everyone that has nuclear reactors also builds bombs, so they go hand in hand, and cost less in the short run.
No. South Korea, Japan, Belgium, Germany, Switzerland, Spain, Sweden, have nuclear reactors and do not have nuclear weapons. This is not by any means an exhaustive list either.
You do not need nuclear reactors to make nuclear weapons. You can make nuclear fission weapons by using U-235 or Plutonium. If you have a centrifuge cascade like Iran does, or some other means to separate fuel, you can make U-235 weapons without owning a single nuclear reactor. The bomb dropped on Hiroshima (Little Boy) was of this type.
Not quite true. You can't make Plutonium based weapons without a reactor, because it is an artificial element. It exists only as a trace in Uranium ores, and can't be extracted in meaningful quantities, it has to be made. The first nuclear weapons were made with the first reactors.
I just watched the video, where the characters just stand around in the open while under fire (enemy AND friendly), the player's weapon bobs like he's jogging on the spot at 10 steps per second, and an enemy takes an entire clip from a submachine gun to die.
Clearly, they did their research... and ignored it.
It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.
Other kinds of games may work better.
You hit the nail on the head right there, the view direction.
Most games do all sorts of predictive wizardry to make the shooting work over internet latencies, but every game allows the view direction to occur completely locally, because even a slight lag makes the player feel like a drunkard. Many games also allow the local client to compute some of the 'game mechanics' locally, and then 'verify' the results with the server later.
I definitely agree with the article, unrealistic games are terrible. I've found myself gravitating towards games with realistic damage rates and weapon accuracies.
For example:
- Counter Strike: Used to be really good in the early betas, then went to hell once the whiners in the forums resulted in every weapon being nerfed. I stopped playing it after I emptied a clip at point blank into a guy's head, missed with every bullet, and then had him turn around and knife me. Over 90% of players had never played CS when it was good, and have no idea just what they're missing... - Day of Defeat: started off awesome, then slowly went downhill, but never to the same extent as CS. Players who thought they were 'l33t' at CS got massacred when they joined DoD games. - Team Fortress / TF2: feels like you're using nerfbats at first, but there's lots of instant-deaths, more then you'd expect, which makes up for it. (snipers, spies, crits, etc...) - Left 4 Dead 1 & 2: I love the way that one bullet from most guns will kill a dozen zombies in a row. Not only that, but Valve made the guns in #2 better, not worse! Someone at Valve is clearly learning!
Contrast these games with the likes of Quake, Unreal Tournament, Tribes, or the like. In those games, three or four direct hits with a rocket weapon is not enough. It's like using nerfbats. What's worse, Tribes basically had no hitscan weapons, so at range, you couldn't even hit anything moving, and even if you did get a lucky shot in, it would do no significant damage.
I've found that the games with accurate, lethal weapons result in very different game play. People jump around like rabbits less, stick to cover more, crouch, avoid open spaces, etc... Basically, they play just like you see soldiers or SWAT behave in real life. It's also gives me a much bigger adrenaline rush. Periods of quiet stalking interspersed with real terror, ending with either sudden death or a panicked getaway make for great tension. Jumping around like idiots in glowing neon green armor is just boring after a few hours.
We all agreed that in a way, it is almost a shame that kids today are growing up with remarkably better technology than we had at their age (and it hasn't been that long ago that we were their age). We all sort of miss dealing with cobbled together and salvaged parts, trying to eek out any performance we could from our machines. One of the friends present recalled helping me overclock my 33 mhz machine to 36 mhz (woohooo! A 10% gain) and how excited we were.
Here's a fun factoid* for you: most electronic parts have an error tolerance of at least 1%, with 10% not unusual. Even things like the clock source of a PC would probably drift by about 0.1% due to things like humidity, temperature, or whatever. Or to put it another way, a modern 3GHz CPU running at a "fixed speed" loses or gains about 3MHz from the influence of the weather. Given that most modern CPUs do a lot more "work" per clock than old XT era processors, that means that just random variations in the performance of my current CPU account for more processor power gained or lost than my first 2 computers combined.
The next processor I'm buying will have more on-chip cache than the total system memory of my first 3 computers combined, and will be bigger than the capacity of my first hard drive!
But on the topic of modems, around the start of the 56K era, I signed up for some random 'beta tester' program with Netgear through work (summer internship during high school), and I got sent a $1000 "enterprise" modem to beta test. It looked and worked like an ordinary 56K modem, but had very good quality components, and very good noise resistance and reliability. It was one of the best electronic devices I had ever owned. It had amazingly low latency, and was the best for playing games online. It outperformed the latency of the first-generation cable internet here in Australia for years.
*) May not be actually factual, this all depends on the technology used to generate the clock, some are more accurate than others.
I am a teenager, and even I can notice it. 30 seconds with a new piece of software I'm already better at than most adults 20 minutes in with the manual. They are incredulous, "How did you know how to do that?!?!" I have no explanation, it just seemed natural that that button is used for this, and if I want to do some heavy duty photo editing I'm going to need to download a crack for photoshop and etc... It just comes from growing up with technology.
Just leave things the way they are, kids will adapt and they'll probably be better at it than most adults in 20 minutes, just like I am now.
I have to second this.
People assume that just because they had a hard time adapting to technology as adults, that children would have an even harder time. I've found that the opposite is true. A family friend has an AD domain for his children's PCs, and they understood the concept of a 'user', 'logging in', etc... at the age of 4 or 5! I started programming in basic when I was about 7 years old, and I could code proficiently in C++ by 13. I remember having XT-era PCs at school, and even though we had very little time assigned to use them (a few hours a month), many students learned a lot of basic skills in no time at all.
I actually work for a department of education at the moment, and my instructions are not to "dumb down" apps too much for children. About the only thing I did was make some screen elements highlight during the "on mouse over" event, as very young children have poor hand-eye coordination. A strong visual effect helps them target and click more effectively. I've sen similar features in other "for kids" apps too.
I collect search logs from a library app used by about 600,000 children, and they search well enough. Junior kids tend to use shorter words ("dog" and "cat" are very popular terms), but other than that, they seem to find what they're looking for relatively quickly.
Because they often don't need to write kernel modules for Linux. But if they did, and it ever left their premises, they'd be obligated to release said code.
That's not the case, the GPL states that they can either release the source OR stop distributing it.
The math and engineering is well-understood and not technically challenging for a well-funded organization.
It requires exceptionally precise and expensive equipment and a lot of technical know-how to develop several key components to creating a conventional nuclear device. Specifically, the critical function is how to model the compression shock wave in the fissile material that begins the chain reaction.
You're forgetting about "gun type" bombs, which are basically a sawn-off naval cannon, and are so trivial to build that the Americans didn't even bother testing the design before dropping it on Japan.
They were easy to build in the forties, and the only reason they aren't used now is because they're inefficient and too heavy for most launch vehicles.
A rogue state that just wants to build a "few" nukes could easily make these. As long as the intended use was terrorism, and not strategic ICBM warfare, then the weight is not an issue. Several analysts have pointed out that one could simply ship such a weapon to any major city in a standard shipping container, and it's unlikely to be detected, as the gamma radiation scanning devices installed in US ports are trivially defeated by several types of shielding, including the natural Uranium casing used for most gun type bombs!
Just about the only 'hard' part is the purification of Uranium, but even that's getting progressively easier as new techniques are discovered and related industries bring costs down by using the same underlying technologies at a large scale.
Basic physics: the forces involved in a bouncy collision are *greater* than the forces involved in an identical "smooshy" collision. Why? Because the crash has to not just bring you to a stop, but throw you back away again.
What you want is a smooshy collision that takes place over a long time. Thus, airbags.
Reminds me of Hollywood physics, where it's the "ground" that kills, not the "stop". The protagonist is always saved by a safety rope, even if it stops him instantly 1m from the ground after a 1000m fall.
This also bothered me in Stargate: Atlantis the multiple times Atlantis was cloaked to hide it from orbiting Wraith vessels. They know what Atlantis looks like, can't they just scan the ocean's surface and look for the telltale snowflake shape of water displaced by the city?
what bothered me more was the fact they had the capacity to produce anything from thin air with asgard beams, but it never occurred to them to xerox their zpm's or atlantian weapon drones. Don't give me that "unreplicatable" crap either, it's a cop-out which defies even the most liberal sci-fi "suspended disbelief".
Mega geek time... ZPMs aren't just material artifacts, they're a housing for a portal into a pinched off bubble of isolated space-time, from which they draw their zero-point energy. The housing could be replicated, but the bubble is presumably much harder to create.
Most importantly, handsets use less power when on GSM.
I don't see GSM being killed for a long, long time. It's like DVD, an example of "good enough" for majority of population, especially those who basically just call and text. 3G benefits are either not used or manifest themselves in very specific scenarios, "modem" function mostly.
Security also is good enough. As this attempt shows, it's non-trivial to crack. And "lawful wiretapping" bypasses it anyway also for UMTS.
Precisely, my iPhone battery lasts days on GSM, hours on 3G. What I don't understand is why phones can't do some sort of hybrid: GSM for standby and voice, and 3G for data? Best of both worlds!
The problem is, a many-core non cache-coherent x86-like system isn't particularly interesting. The big advantage of Larrabee was that you could treat it like a normal SMP system, including (presumably) running standard multithreaded C code on it. Once you have to deal with memory synchronization explicitly, Larrabee starts to look a lot more (from a programming standpoint) like Fermi, Cypress or whatever other Nvidia/ATI GPUs are out at the time.
There's nothing magic about x86/AMD64 in the HPC world. It's attractive because it is cheap and has good performance. Clusters can, have been, and still are built using POWER and other architectures.
But for "embarrassingly parallel" problems, which are the target application for these chips, cache coherence is often not necessary, and simply imposes a design burden. There are lots of problems where it's better to have 1000x the performance than 1/2 the developer time.
It may not even involve less development time: Others have pointed out that the Unix "fork" mechanism combined with "copy-on-write" at the memory page level would also work, and wouldn't require cache coherency. Similarly, any existing code designed for message-passing supercomputers would work out of the box, with only a recompile using a new library. Developers just have to start thinking in terms of "many processes" instead of "many threads".
I suspect that in the long term (decades), cache coherency will simply not scale, and most computers will use explicit message-passing internally, even at the single processor level. The transition has already started: most new servers are NUMA systems, where there's a concept of "near" and "far" memory visible to the software, and most of the real heavy lifting in PCs are done by the GPUs, some of which do not have complete cache coherency across all cores.
Due to his geographical location [emphasis mine], there's bugger all the majority of Australia can do about it from a voting perspective.
I don't blame game publishers for not releasing stuff here. Effectively we're all just waiting for 'Nanny' Atkinson to become senile and finally leave his post as South Australia's attorney general.
The thing that really worries me is how come they have this veto power for things like this in the first place....
I really don't understand why we've hung on to this ridiculously outdated notion of political power being assigned hierarchically by physical location. I have little in common with my neighbors, let alone people a mere suburb away, but I have the same political interests as other people in my field of employment literally thousands of kilometers away in Perth.
Take a look at the insane degree to which Americans have taken Gerrymandering - formerly simple voting territories have been made almost fractal in outline! It's a bad, half-baked solution to concentrating voter power among like-minded people, to get a representative in to government, where otherwise the votes would be too diluted within a territory.
This is like a sick person self-medicating. It's not the proper solution.
I say, eliminate territory based voting, and simply have a fixed number of representatives voted in. Order the politicians by votes received, and the 'top n' get a seat. We can keep all the other elements of voting that have worked so well in Australia, like proper secret paper-based ballots, preferential voting, political parties, etc... but get rid of this insanity that somehow we're all rich landowners holding onto a feudal system of power that has nothing to do with modern life.
Wow... thanks for your insight! Should have known Intel would be logical even about their failures, and roll them over to something that has a chance of applicability. The only thing I wish they would do is skip the 64-bit crap and make 128-bit architectures that are compatible with both 32- and 64-bit predecessors. It would ease the development of new applications since the life time of 128-bit archs would be decades as opposed to developing all 64-bit apps to only have 128-bit archs appear in 5-10 years.
I'm not sure if you're trolling or not, but 64-bit memory capacity is not "twice" as big as 32-bit, it's 4.3 billion times as big. That's more than just 5 to 10 years of Moore's law, that's more like 50 years. Physical bus widths have nothing to do with architecture bitness either, there are memory buses for 64-bit architectures that only have a few pins.
I think the announcement of the 48-core Intel 'Bangalore' chip just recently is not a coincidence.
When I first read about the Larrabee chip, I thought the decision to make it a cache coherent SMP chip to be simply insane - architectures like that are very difficult to scale, as the inter-core chatter scales roughly as the factorial of the number of cores. Remember how Larrabee was designed around a really wide 1024-bit ring bus? I bet that's required because otherwise the cores would spend all of their time trying to synchronize between each other.
So, Larrabee is effectively cancelled, but only a day or two before Intel announced an almost identical sounding part without cache-coherence! It sounds to me like they've given up on the 100% x86 compatibility, and realised that a chip with some extra instructions around explicit software controlled memory synchronization and message passing would scale way better. Without cache coherence, a "many core" chip is basically just an independent unit repeated over and over, so scalability should be almost infinite, and wouldn't require design changes for different sizes. That sounds like a much better match for a graphics processor.
While Intel kept their cards relatively close to their chest, from all of the presentations I've seen, no first-gen Larrabee chip could scale beyond 24 cores even with a 1024 bit bus, while the new Bangalore chip starts at 48 cores. There's no public info on how many lanes Bangalore has in its on-chip bus but based on the bandwidth of its 80 core experimental predecessor, I'm guessing it's either 32-bit or 64-bit (per core).
If this type of thing is implemented at the file level every application is going to have to do its own thing. That means to many implementations most of which wont be very good or well tested. It also means applications developers will have to be busy slogging though error correction data in their files rather than the data they actually wanted to persist for their application. I think the article offers a number of good ideas but it would be better to do most of them at the filesystem and perhaps some at the storage layer.
Also if we can present the same logical file when read to the application even if every 9th byte is parity on the disk that is a plus because it means legacy apps can get the enhanced protection as well.
Precisely. This is what things like torrents, RAR files with recovery blocks, and filesystems like ZFS are for: so every app developer doesn't have to roll their own, badly.
Damn. I don't even use Java(I'm an embedded C guy), but if DL did it, then it's probably really good. As a C developer I feel the old pthreads style is a throwback to old multi-process hacks on SysV of 25 years ago.
What dragged you to the dark side anyways? (C#/.NET)
The Oswego library was the bomb. It's basically how APIs should be designed: Very simple looking abstract interfaces* with a bunch of reference implementations, some of which are incredibly advanced. You can then pick and choose what you want, reimplement anything at will, and combine like Lego. That guy saved me a LOT of time and bug hunting. Want a queue? Pick from four different flavors! Want priorities? Done! Want to keep the queue but change the execution style or locking mechanism? No problem!
As to switching, I've always generally been a Windows guy, and C# is currently the single fastest way to develop a GUI and not get "stuck" too much, because it can call C or COM style APIs directly. When it was first released, a good former Java/C++ developer could get started with it quickly, and develop GUIs 2-3x quicker than anything else, which then ran smoothly, and looked native.
I still get frustrated, especially with the lack of decent containers, algorithms, and threading frameworks, but C# is still overall the best. I do a lot of very Windows platform specific stuff like Active Directory manipulation, and it would be very hard to do that quickly (but correctly) with any other language.
Java is great for "server side" development. It has better database binding** libraries, threading, third-party support, containers and frameworks, and a much better community. However, its client-side is just terrible, especially the GUI frameworks. SUN apparently still hasn't learned the key to Microsoft's success story: own the client, and you will own the world.
It's only recently that Java IDEs got decent "drag & drop" forms development, while Microsoft is already a generation ahead with WPF which very cleanly separates code and layout, to the point that artists can do layout almost completely independently of the dev team. Think of what HTML and CSS tried but failed to do, but done properly.
*) Microsoft has an allergy to interfaces. It's like they're trying to tell you that they "own" the API, and you, the developer, should keep your dirty little mitts off it.
**) Microsoft's LINQ to SQL is practically a beta at this time. They don't even support multi-columns keys! Its big brother, the "Entity Framework" didn't support foreign keys until.NET 4, which is currently beta, and the GUI editor still fails on all but the simplest models. Something like 60% of the features, if used, disable the GUI editor completely. Microsoft isn't even planning to finish the EF framework GUI, ever. Every couple of years, they come up with a new data binding framework, drop the old ones, never finish it, and then they repeat, not having learned a single lesson. I've lost count.. there's been, what: DDE, ODBC, ADO, ADO.NET, LINQ, EF, and now they're up to some garbage called "M" or "Oslo" or whatever. I'm certain it'll be buggy, slow, incomplete, and replaced in short order. Just watch.
"I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz"
No wonder you can afford to use C!;)
I can buy a $1.20 microcontroller that's more than an order of magnitude faster than the machine I learned to code on. Still, there are still times when a nice bit of assembly makes a big difference. Not much, just as much as you need.
As for the rest of the thread, assembly IS the bare metal. C is the next best thing to bare metal. Not to say that you should code everything in assembly, that would be silly. But being aware that it exists can't hurt.
I hear that Windows 7 / Server 2008 R2 has a pure-software implementation of DirectX 11 that's got some huge percentage implemented in assembler. It's still a useful and current skill that turns up in large scale deployments of production code! 8)
because the modern Microsoft development tools need that infernal Dotnet library to be loaded and then when it gets messes up any software that depends on it does not work.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly. As a result, a lot of new software simply will not run.
Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal, but '.Net' is such a monstrosity that it makes 'DLL Hell' look good in comparison; if even Microsoft can't fix it when it breaks, what chance do users have?
A lot of that comes from badly written fragile apps doing stupid things like writing entries into the "machine.config" file, or depending on things that aren't guaranteed. Oracle and any apps that depend on their client come to mind, it does horrible things to the.NET framework config files. I see the same all the time with Java apps as well, it's not unusual to see even a "point release" of the JRE break apps.
On the other hand I have written (and seen third party) apps for.NET that have worked consistently well across 3 operating system releases (2003/XP, 2008/Vista, 2008 R2/Windows 7), and 3 major.NET revisions (2, 3.x, 4), AND a change from 32-bit to 64-bit without any significant changes. That's not bad. Meanwhile, there are traditional C++ apps that will fall over if you look at them the wrong way.
Then again, Windows 7 actually contains a "stealth" release of.NET: 3.5.1. It's not the same as 3.5 on Vista or earlier. Developer tools target "3.5" as if it was a single platform, but it's not, there are two slightly different point releases. It broke VMware's vCenter client, among other things.
I can't stand it when Microsoft developers talk about multi-threaded programming when the entire corporation has done that absolute bare minimum to make developer's lives easier. No wonder that they don't like using their own tools, because their tools are terrible.
Many years ago, a brilliant third-party multi-threaded library was released for Java, by a professor at Oswego university. I used it in several large production apps, and it absolutely rocked. You could build up safe, reliable, scalable multi-threaded applications by simply snapping together flexible pieces like Lego. It was so good that it became a part of the SUN Java standard library, and it's now called "util.concurrent". Compared to having to "hand craft" multi-threaded code in C++, it was wonderful. It's as if the lights had just turned on, and everything had become clear to me.
Now that I'm a C# dev, it's been a huge step backwards, doubly so because.NET was developed after the Oswego library was already popular, so Microsoft must have seen it and just flat out ignored it. For years afterwards, the whole entirety of multi-threading in both.NET and C++ were "threads" and "locks". The one nicety they included was an anemic thread pool in.NET which was just usable enough for the most basic tasks, but couldn't handle any real load. Even the locks were heavyweight inter-process kernel locks that are unusably slow for many tasks.
It's only now in.NET 4 (which won't be final until 2010) that they are adding a small set of very basic lock-free containers, light-weight locks, and actual interfaces that one can implement in order to customize behavior. It's all still very basic, and nowhere near as flexible, powerful, or comprehensive as the Java APIs that are years old now.
Microsoft's general attitude to API design is so bad that it can only be described as wilful ignorance. Reading articles evangelizing "modern multithreaded programming to better utilize new multi core processors" somehow feels like a religious zealot harping on about their appreciation of pure rational logic and science.
A generation to skip for servers (or move to AMD for a generation) but Core i7s are amazing for home/gaming use. For just about anything other than visualization and server-specific stuff, Core i7s and CPUs with the same architecture have no comparison with what AMD has to offer.
"citation needed"
You're saying that like Microsoft Hyper-V is the only virtualization platform, nobody ever uses a server without virtualization, and there's no way Microsoft could ever release a hotfix for the issue. Sell your Intel stock now!
Yeah, I've always wondered about that. If you go back a mere 130 years, the only sources of emitted light a person would ever see (off the top of my head) were:
Sun Fire Stars Lightening Auroras Lightening bugs, etc Foxfire, etc Fish (or were they too deep then?)
So everything the human eye ever saw was reflected light. Since the advent of the television, people began watching and focusing on emitted light directly, and computers, cell phones, etc have taken that even further.
So what, if anything, does that mean to human vision?
Absolutely nothing, light is light, irrespective of the source.
Note that something like software defined radio tends to do the more protocolish functions in software - the actual signal generation tends to be done in hardware, or on something like a DSP (which is technically software-controlled). It isn't like you can just tune something to 2.4 GHz and sample a few hundred MHz and have a CPU pull the signals out in realtime via FFT...
That's exactly what happens. I've seen demos of ordinary PCs decoding HD TV broadcasts into live video, starting with a 25MHz frequency range sampled 1:1.
You underestimate a CPU's compute power. The memory speed is very much the limit, which is why video cards have such insanely fast memory on them, it's the only way to get more effective computational power. Read up on "clock speed multipliers". Essentially, for every word of memory that's loaded (at the max rate), a typical CPU can execute about half a dozen to a dozen instructions. With SSE4, it can be even more than that. (true only for simple 'math', more complex code with jumps and indirections is a different story)
A good analogy is the ZFS filesystem developed by SUN. They basically figured that the $500 add-in RAID cards were $40 worth of electronics, and $460 marketing and overheads because of low volumes. They usually had outdated 800MHz embedded processors on them, while the main system CPU was a 3GHz multi-core beast. The 'offload' card was causing a bottleneck and slowing down the system! So the latest SUN hardware doesn't have dedicated RAID hardware, they just do it in software. Way more flexible, and actually faster.
And anyway, if you want compute power, NOTHING beats a typical 3D card these days. The latest generation can do 1TB/sec within the chip, 200GB/sec to memory, and have 2TFLOPS of compute power. No sound card that you can buy can even approach that.
Those CPUs are old, and they could still mix an entire orchestra, in real time, without breaking a sweat.
Take a look at the bar graph at the bottom, most CPUs released in the last few years easily do 5GB+ even for "integer" code (SSE3 would be more than double), and the Core i7s do 25GB/sec, which is higher than I thought.
There's just no need to 'standardize' on anything, or even have kernel-mode drivers for anything other than basic "input" or "output". Write your sound mixing code in ordinary C (even Java or C# would be fast enough!), and just send it down the line...
Heck, take a look at software defined radio, there's just no need for dedicated hardware for a lot of things when the CPU is so ridiculously powerful.
And this thread just sums up the problem - in three posts we have now made mention of four different sound systems, and I'll go ahead and mention JACK, oss, and esd right here to make it 7. Various programs are written for each of these, and while some are more deprecated than others, the fact is that getting sound to work on linux is a LOT harder than it needs to be.
Sound stopped being a pain in windows with the advent of Win95 and PnP. Before that the windows bit of it wasn't actually that bad (midi mapping was a little painful, but generally the defaults weren't bad). Getting the DMAs/IRQs right was the real pain.
My linux system has a pretty nice wavetable audio board, but to be honest if I want to play something I just use timidity since I've given up on trying to get the hardware to actually work right. If I needed more than rudimentary sound I'd be really up the creek.
I might be revealing my ignorance here, but is there anything to be even gained from using hardware mixing?
A back of the envelope calculation shows that a typical modern desktop CPU with a nominal memory bandwidth of 10GB/sec can mix 56,000 channels with 48kHz & 32 bit precision. That's... a lot. I suspect that's a few more than even the most wildly fanciful orchestra composition would need, even in 8 channel surround (7000 sounds per channel).
Newer high-end CPUs are now pushing 100GB/sec or higher, so I just can't see what dedicated hardware card could possibly do for your audio that you can't get from some simple mixing software and a "digital out" port on the motherboard!
Even if you're doing some ridiculously complex real-time effects on those sounds, I suspect in the long term audio software would be better off using the GPU of the 3D card for doing the "heavy lifting" instead of low-volume cards with terrible drivers (even in Windows, let alone Linux).
Slashdot Mirror
Because everyone that has nuclear reactors also builds bombs, so they go hand in hand, and cost less in the short run.
No. South Korea, Japan, Belgium, Germany, Switzerland, Spain, Sweden, have nuclear reactors and do not have nuclear weapons. This is not by any means an exhaustive list either.
You do not need nuclear reactors to make nuclear weapons. You can make nuclear fission weapons by using U-235 or Plutonium. If you have a centrifuge cascade like Iran does, or some other means to separate fuel, you can make U-235 weapons without owning a single nuclear reactor. The bomb dropped on Hiroshima (Little Boy) was of this type.
Not quite true. You can't make Plutonium based weapons without a reactor, because it is an artificial element. It exists only as a trace in Uranium ores, and can't be extracted in meaningful quantities, it has to be made. The first nuclear weapons were made with the first reactors.
Actual scientific methods?
I just watched the video, where the characters just stand around in the open while under fire (enemy AND friendly), the player's weapon bobs like he's jogging on the spot at 10 steps per second, and an enemy takes an entire clip from a submachine gun to die.
Clearly, they did their research... and ignored it.
It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.
Other kinds of games may work better.
You hit the nail on the head right there, the view direction.
Most games do all sorts of predictive wizardry to make the shooting work over internet latencies, but every game allows the view direction to occur completely locally, because even a slight lag makes the player feel like a drunkard. Many games also allow the local client to compute some of the 'game mechanics' locally, and then 'verify' the results with the server later.
I definitely agree with the article, unrealistic games are terrible. I've found myself gravitating towards games with realistic damage rates and weapon accuracies.
For example:
- Counter Strike: Used to be really good in the early betas, then went to hell once the whiners in the forums resulted in every weapon being nerfed. I stopped playing it after I emptied a clip at point blank into a guy's head, missed with every bullet, and then had him turn around and knife me. Over 90% of players had never played CS when it was good, and have no idea just what they're missing...
- Day of Defeat: started off awesome, then slowly went downhill, but never to the same extent as CS. Players who thought they were 'l33t' at CS got massacred when they joined DoD games.
- Team Fortress / TF2: feels like you're using nerfbats at first, but there's lots of instant-deaths, more then you'd expect, which makes up for it. (snipers, spies, crits, etc...)
- Left 4 Dead 1 & 2: I love the way that one bullet from most guns will kill a dozen zombies in a row. Not only that, but Valve made the guns in #2 better, not worse! Someone at Valve is clearly learning!
Contrast these games with the likes of Quake, Unreal Tournament, Tribes, or the like. In those games, three or four direct hits with a rocket weapon is not enough. It's like using nerfbats. What's worse, Tribes basically had no hitscan weapons, so at range, you couldn't even hit anything moving, and even if you did get a lucky shot in, it would do no significant damage.
I've found that the games with accurate, lethal weapons result in very different game play. People jump around like rabbits less, stick to cover more, crouch, avoid open spaces, etc... Basically, they play just like you see soldiers or SWAT behave in real life. It's also gives me a much bigger adrenaline rush. Periods of quiet stalking interspersed with real terror, ending with either sudden death or a panicked getaway make for great tension. Jumping around like idiots in glowing neon green armor is just boring after a few hours.
We all agreed that in a way, it is almost a shame that kids today are growing up with remarkably better technology than we had at their age (and it hasn't been that long ago that we were their age). We all sort of miss dealing with cobbled together and salvaged parts, trying to eek out any performance we could from our machines. One of the friends present recalled helping me overclock my 33 mhz machine to 36 mhz (woohooo! A 10% gain) and how excited we were.
Here's a fun factoid* for you: most electronic parts have an error tolerance of at least 1%, with 10% not unusual. Even things like the clock source of a PC would probably drift by about 0.1% due to things like humidity, temperature, or whatever. Or to put it another way, a modern 3GHz CPU running at a "fixed speed" loses or gains about 3MHz from the influence of the weather. Given that most modern CPUs do a lot more "work" per clock than old XT era processors, that means that just random variations in the performance of my current CPU account for more processor power gained or lost than my first 2 computers combined.
The next processor I'm buying will have more on-chip cache than the total system memory of my first 3 computers combined, and will be bigger than the capacity of my first hard drive!
But on the topic of modems, around the start of the 56K era, I signed up for some random 'beta tester' program with Netgear through work (summer internship during high school), and I got sent a $1000 "enterprise" modem to beta test. It looked and worked like an ordinary 56K modem, but had very good quality components, and very good noise resistance and reliability. It was one of the best electronic devices I had ever owned. It had amazingly low latency, and was the best for playing games online. It outperformed the latency of the first-generation cable internet here in Australia for years.
*) May not be actually factual, this all depends on the technology used to generate the clock, some are more accurate than others.
This is exactly it...
I am a teenager, and even I can notice it. 30 seconds with a new piece of software I'm already better at than most adults 20 minutes in with the manual. They are incredulous, "How did you know how to do that?!?!" I have no explanation, it just seemed natural that that button is used for this, and if I want to do some heavy duty photo editing I'm going to need to download a crack for photoshop and etc... It just comes from growing up with technology.
Just leave things the way they are, kids will adapt and they'll probably be better at it than most adults in 20 minutes, just like I am now.
I have to second this.
People assume that just because they had a hard time adapting to technology as adults, that children would have an even harder time. I've found that the opposite is true. A family friend has an AD domain for his children's PCs, and they understood the concept of a 'user', 'logging in', etc... at the age of 4 or 5! I started programming in basic when I was about 7 years old, and I could code proficiently in C++ by 13. I remember having XT-era PCs at school, and even though we had very little time assigned to use them (a few hours a month), many students learned a lot of basic skills in no time at all.
I actually work for a department of education at the moment, and my instructions are not to "dumb down" apps too much for children. About the only thing I did was make some screen elements highlight during the "on mouse over" event, as very young children have poor hand-eye coordination. A strong visual effect helps them target and click more effectively. I've sen similar features in other "for kids" apps too.
I collect search logs from a library app used by about 600,000 children, and they search well enough. Junior kids tend to use shorter words ("dog" and "cat" are very popular terms), but other than that, they seem to find what they're looking for relatively quickly.
Because they often don't need to write kernel modules for Linux. But if they did, and it ever left their premises, they'd be obligated to release said code.
That's not the case, the GPL states that they can either release the source OR stop distributing it.
The math and engineering is well-understood and not technically challenging for a well-funded organization.
It requires exceptionally precise and expensive equipment and a lot of technical know-how to develop several key components to creating a conventional nuclear device. Specifically, the critical function is how to model the compression shock wave in the fissile material that begins the chain reaction.
You're forgetting about "gun type" bombs, which are basically a sawn-off naval cannon, and are so trivial to build that the Americans didn't even bother testing the design before dropping it on Japan.
They were easy to build in the forties, and the only reason they aren't used now is because they're inefficient and too heavy for most launch vehicles.
A rogue state that just wants to build a "few" nukes could easily make these. As long as the intended use was terrorism, and not strategic ICBM warfare, then the weight is not an issue. Several analysts have pointed out that one could simply ship such a weapon to any major city in a standard shipping container, and it's unlikely to be detected, as the gamma radiation scanning devices installed in US ports are trivially defeated by several types of shielding, including the natural Uranium casing used for most gun type bombs!
Just about the only 'hard' part is the purification of Uranium, but even that's getting progressively easier as new techniques are discovered and related industries bring costs down by using the same underlying technologies at a large scale.
Basic physics: the forces involved in a bouncy collision are *greater* than the forces involved in an identical "smooshy" collision. Why? Because the crash has to not just bring you to a stop, but throw you back away again.
What you want is a smooshy collision that takes place over a long time. Thus, airbags.
Reminds me of Hollywood physics, where it's the "ground" that kills, not the "stop". The protagonist is always saved by a safety rope, even if it stops him instantly 1m from the ground after a 1000m fall.
This also bothered me in Stargate: Atlantis the multiple times Atlantis was cloaked to hide it from orbiting Wraith vessels. They know what Atlantis looks like, can't they just scan the ocean's surface and look for the telltale snowflake shape of water displaced by the city?
what bothered me more was the fact they had the capacity to produce anything from thin air with asgard beams, but it never occurred to them to xerox their zpm's or atlantian weapon drones. Don't give me that "unreplicatable" crap either, it's a cop-out which defies even the most liberal sci-fi "suspended disbelief".
Mega geek time... ZPMs aren't just material artifacts, they're a housing for a portal into a pinched off bubble of isolated space-time, from which they draw their zero-point energy. The housing could be replicated, but the bubble is presumably much harder to create.
Most importantly, handsets use less power when on GSM.
I don't see GSM being killed for a long, long time. It's like DVD, an example of "good enough" for majority of population, especially those who basically just call and text. 3G benefits are either not used or manifest themselves in very specific scenarios, "modem" function mostly.
Security also is good enough. As this attempt shows, it's non-trivial to crack. And "lawful wiretapping" bypasses it anyway also for UMTS.
Precisely, my iPhone battery lasts days on GSM, hours on 3G. What I don't understand is why phones can't do some sort of hybrid: GSM for standby and voice, and 3G for data? Best of both worlds!
The problem is, a many-core non cache-coherent x86-like system isn't particularly interesting. The big advantage of Larrabee was that you could treat it like a normal SMP system, including (presumably) running standard multithreaded C code on it. Once you have to deal with memory synchronization explicitly, Larrabee starts to look a lot more (from a programming standpoint) like Fermi, Cypress or whatever other Nvidia/ATI GPUs are out at the time.
There's nothing magic about x86/AMD64 in the HPC world. It's attractive because it is cheap and has good performance. Clusters can, have been, and still are built using POWER and other architectures.
But for "embarrassingly parallel" problems, which are the target application for these chips, cache coherence is often not necessary, and simply imposes a design burden. There are lots of problems where it's better to have 1000x the performance than 1/2 the developer time.
It may not even involve less development time: Others have pointed out that the Unix "fork" mechanism combined with "copy-on-write" at the memory page level would also work, and wouldn't require cache coherency. Similarly, any existing code designed for message-passing supercomputers would work out of the box, with only a recompile using a new library. Developers just have to start thinking in terms of "many processes" instead of "many threads".
I suspect that in the long term (decades), cache coherency will simply not scale, and most computers will use explicit message-passing internally, even at the single processor level. The transition has already started: most new servers are NUMA systems, where there's a concept of "near" and "far" memory visible to the software, and most of the real heavy lifting in PCs are done by the GPUs, some of which do not have complete cache coherency across all cores.
Quick explanation: Pretty much most of Australia would be happy to have an 'R' rating for computer games.
This guy (Michael Atkinson), however would not. He has the power to veto it and continues to do so.
Due to his geographical location [emphasis mine], there's bugger all the majority of Australia can do about it from a voting perspective.
I don't blame game publishers for not releasing stuff here. Effectively we're all just waiting for 'Nanny' Atkinson to become senile and finally leave his post as South Australia's attorney general.
The thing that really worries me is how come they have this veto power for things like this in the first place....
I really don't understand why we've hung on to this ridiculously outdated notion of political power being assigned hierarchically by physical location. I have little in common with my neighbors, let alone people a mere suburb away, but I have the same political interests as other people in my field of employment literally thousands of kilometers away in Perth.
Take a look at the insane degree to which Americans have taken Gerrymandering - formerly simple voting territories have been made almost fractal in outline! It's a bad, half-baked solution to concentrating voter power among like-minded people, to get a representative in to government, where otherwise the votes would be too diluted within a territory.
This is like a sick person self-medicating. It's not the proper solution.
I say, eliminate territory based voting, and simply have a fixed number of representatives voted in. Order the politicians by votes received, and the 'top n' get a seat. We can keep all the other elements of voting that have worked so well in Australia, like proper secret paper-based ballots, preferential voting, political parties, etc... but get rid of this insanity that somehow we're all rich landowners holding onto a feudal system of power that has nothing to do with modern life.
Wow... thanks for your insight! Should have known Intel would be logical even about their failures, and roll them over to something that has a chance of applicability. The only thing I wish they would do is skip the 64-bit crap and make 128-bit architectures that are compatible with both 32- and 64-bit predecessors. It would ease the development of new applications since the life time of 128-bit archs would be decades as opposed to developing all 64-bit apps to only have 128-bit archs appear in 5-10 years.
I'm not sure if you're trolling or not, but 64-bit memory capacity is not "twice" as big as 32-bit, it's 4.3 billion times as big. That's more than just 5 to 10 years of Moore's law, that's more like 50 years. Physical bus widths have nothing to do with architecture bitness either, there are memory buses for 64-bit architectures that only have a few pins.
I think the announcement of the 48-core Intel 'Bangalore' chip just recently is not a coincidence.
When I first read about the Larrabee chip, I thought the decision to make it a cache coherent SMP chip to be simply insane - architectures like that are very difficult to scale, as the inter-core chatter scales roughly as the factorial of the number of cores. Remember how Larrabee was designed around a really wide 1024-bit ring bus? I bet that's required because otherwise the cores would spend all of their time trying to synchronize between each other.
So, Larrabee is effectively cancelled, but only a day or two before Intel announced an almost identical sounding part without cache-coherence! It sounds to me like they've given up on the 100% x86 compatibility, and realised that a chip with some extra instructions around explicit software controlled memory synchronization and message passing would scale way better. Without cache coherence, a "many core" chip is basically just an independent unit repeated over and over, so scalability should be almost infinite, and wouldn't require design changes for different sizes. That sounds like a much better match for a graphics processor.
While Intel kept their cards relatively close to their chest, from all of the presentations I've seen, no first-gen Larrabee chip could scale beyond 24 cores even with a 1024 bit bus, while the new Bangalore chip starts at 48 cores. There's no public info on how many lanes Bangalore has in its on-chip bus but based on the bandwidth of its 80 core experimental predecessor, I'm guessing it's either 32-bit or 64-bit (per core).
If this type of thing is implemented at the file level every application is going to have to do its own thing. That means to many implementations most of which wont be very good or well tested. It also means applications developers will have to be busy slogging though error correction data in their files rather than the data they actually wanted to persist for their application. I think the article offers a number of good ideas but it would be better to do most of them at the filesystem and perhaps some at the storage layer.
Also if we can present the same logical file when read to the application even if every 9th byte is parity on the disk that is a plus because it means legacy apps can get the enhanced protection as well.
Precisely. This is what things like torrents, RAR files with recovery blocks, and filesystems like ZFS are for: so every app developer doesn't have to roll their own, badly.
Damn. I don't even use Java(I'm an embedded C guy), but if DL did it, then it's probably really good. As a C developer I feel the old pthreads style is a throwback to old multi-process hacks on SysV of 25 years ago.
What dragged you to the dark side anyways? (C#/.NET)
The Oswego library was the bomb. It's basically how APIs should be designed: Very simple looking abstract interfaces* with a bunch of reference implementations, some of which are incredibly advanced. You can then pick and choose what you want, reimplement anything at will, and combine like Lego. That guy saved me a LOT of time and bug hunting. Want a queue? Pick from four different flavors! Want priorities? Done! Want to keep the queue but change the execution style or locking mechanism? No problem!
As to switching, I've always generally been a Windows guy, and C# is currently the single fastest way to develop a GUI and not get "stuck" too much, because it can call C or COM style APIs directly. When it was first released, a good former Java/C++ developer could get started with it quickly, and develop GUIs 2-3x quicker than anything else, which then ran smoothly, and looked native.
I still get frustrated, especially with the lack of decent containers, algorithms, and threading frameworks, but C# is still overall the best. I do a lot of very Windows platform specific stuff like Active Directory manipulation, and it would be very hard to do that quickly (but correctly) with any other language.
Java is great for "server side" development. It has better database binding** libraries, threading, third-party support, containers and frameworks, and a much better community. However, its client-side is just terrible, especially the GUI frameworks. SUN apparently still hasn't learned the key to Microsoft's success story: own the client, and you will own the world.
It's only recently that Java IDEs got decent "drag & drop" forms development, while Microsoft is already a generation ahead with WPF which very cleanly separates code and layout, to the point that artists can do layout almost completely independently of the dev team. Think of what HTML and CSS tried but failed to do, but done properly.
*) Microsoft has an allergy to interfaces. It's like they're trying to tell you that they "own" the API, and you, the developer, should keep your dirty little mitts off it.
**) Microsoft's LINQ to SQL is practically a beta at this time. They don't even support multi-columns keys! Its big brother, the "Entity Framework" didn't support foreign keys until .NET 4, which is currently beta, and the GUI editor still fails on all but the simplest models. Something like 60% of the features, if used, disable the GUI editor completely. Microsoft isn't even planning to finish the EF framework GUI, ever. Every couple of years, they come up with a new data binding framework, drop the old ones, never finish it, and then they repeat, not having learned a single lesson. I've lost count.. there's been, what: DDE, ODBC, ADO, ADO.NET, LINQ, EF, and now they're up to some garbage called "M" or "Oslo" or whatever. I'm certain it'll be buggy, slow, incomplete, and replaced in short order. Just watch.
"I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz"
No wonder you can afford to use C! ;)
I can buy a $1.20 microcontroller that's more than an order of magnitude faster than the machine I learned to code on. Still, there are still times when a nice bit of assembly makes a big difference. Not much, just as much as you need.
As for the rest of the thread, assembly IS the bare metal. C is the next best thing to bare metal. Not to say that you should code everything in assembly, that would be silly. But being aware that it exists can't hurt.
I hear that Windows 7 / Server 2008 R2 has a pure-software implementation of DirectX 11 that's got some huge percentage implemented in assembler. It's still a useful and current skill that turns up in large scale deployments of production code! 8)
because the modern Microsoft development tools need that infernal Dotnet library to be loaded and then when it gets messes up any software that depends on it does not work.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly. As a result, a lot of new software simply will not run.
Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal, but '.Net' is such a monstrosity that it makes 'DLL Hell' look good in comparison; if even Microsoft can't fix it when it breaks, what chance do users have?
A lot of that comes from badly written fragile apps doing stupid things like writing entries into the "machine.config" file, or depending on things that aren't guaranteed. Oracle and any apps that depend on their client come to mind, it does horrible things to the .NET framework config files. I see the same all the time with Java apps as well, it's not unusual to see even a "point release" of the JRE break apps.
On the other hand I have written (and seen third party) apps for .NET that have worked consistently well across 3 operating system releases (2003/XP, 2008/Vista, 2008 R2/Windows 7), and 3 major .NET revisions (2, 3.x, 4), AND a change from 32-bit to 64-bit without any significant changes. That's not bad. Meanwhile, there are traditional C++ apps that will fall over if you look at them the wrong way.
Then again, Windows 7 actually contains a "stealth" release of .NET: 3.5.1. It's not the same as 3.5 on Vista or earlier. Developer tools target "3.5" as if it was a single platform, but it's not, there are two slightly different point releases. It broke VMware's vCenter client, among other things.
I can't stand it when Microsoft developers talk about multi-threaded programming when the entire corporation has done that absolute bare minimum to make developer's lives easier. No wonder that they don't like using their own tools, because their tools are terrible.
Many years ago, a brilliant third-party multi-threaded library was released for Java, by a professor at Oswego university. I used it in several large production apps, and it absolutely rocked. You could build up safe, reliable, scalable multi-threaded applications by simply snapping together flexible pieces like Lego. It was so good that it became a part of the SUN Java standard library, and it's now called "util.concurrent". Compared to having to "hand craft" multi-threaded code in C++, it was wonderful. It's as if the lights had just turned on, and everything had become clear to me.
Now that I'm a C# dev, it's been a huge step backwards, doubly so because .NET was developed after the Oswego library was already popular, so Microsoft must have seen it and just flat out ignored it. For years afterwards, the whole entirety of multi-threading in both .NET and C++ were "threads" and "locks". The one nicety they included was an anemic thread pool in .NET which was just usable enough for the most basic tasks, but couldn't handle any real load. Even the locks were heavyweight inter-process kernel locks that are unusably slow for many tasks.
It's only now in .NET 4 (which won't be final until 2010) that they are adding a small set of very basic lock-free containers, light-weight locks, and actual interfaces that one can implement in order to customize behavior. It's all still very basic, and nowhere near as flexible, powerful, or comprehensive as the Java APIs that are years old now.
Microsoft's general attitude to API design is so bad that it can only be described as wilful ignorance. Reading articles evangelizing "modern multithreaded programming to better utilize new multi core processors" somehow feels like a religious zealot harping on about their appreciation of pure rational logic and science.
A generation to skip for servers (or move to AMD for a generation) but Core i7s are amazing for home/gaming use. For just about anything other than visualization and server-specific stuff, Core i7s and CPUs with the same architecture have no comparison with what AMD has to offer.
"citation needed"
You're saying that like Microsoft Hyper-V is the only virtualization platform, nobody ever uses a server without virtualization, and there's no way Microsoft could ever release a hotfix for the issue. Sell your Intel stock now!
Yeah, I've always wondered about that. If you go back a mere 130 years, the only sources of emitted light a person would ever see (off the top of my head) were:
Sun
Fire
Stars
Lightening
Auroras
Lightening bugs, etc
Foxfire, etc
Fish (or were they too deep then?)
So everything the human eye ever saw was reflected light. Since the advent of the television, people began watching and focusing on emitted light directly, and computers, cell phones, etc have taken that even further.
So what, if anything, does that mean to human vision?
Absolutely nothing, light is light, irrespective of the source.
Note that something like software defined radio tends to do the more protocolish functions in software - the actual signal generation tends to be done in hardware, or on something like a DSP (which is technically software-controlled). It isn't like you can just tune something to 2.4 GHz and sample a few hundred MHz and have a CPU pull the signals out in realtime via FFT...
That's exactly what happens. I've seen demos of ordinary PCs decoding HD TV broadcasts into live video, starting with a 25MHz frequency range sampled 1:1.
You underestimate a CPU's compute power. The memory speed is very much the limit, which is why video cards have such insanely fast memory on them, it's the only way to get more effective computational power. Read up on "clock speed multipliers". Essentially, for every word of memory that's loaded (at the max rate), a typical CPU can execute about half a dozen to a dozen instructions. With SSE4, it can be even more than that. (true only for simple 'math', more complex code with jumps and indirections is a different story)
A good analogy is the ZFS filesystem developed by SUN. They basically figured that the $500 add-in RAID cards were $40 worth of electronics, and $460 marketing and overheads because of low volumes. They usually had outdated 800MHz embedded processors on them, while the main system CPU was a 3GHz multi-core beast. The 'offload' card was causing a bottleneck and slowing down the system! So the latest SUN hardware doesn't have dedicated RAID hardware, they just do it in software. Way more flexible, and actually faster.
And anyway, if you want compute power, NOTHING beats a typical 3D card these days. The latest generation can do 1TB/sec within the chip, 200GB/sec to memory, and have 2TFLOPS of compute power. No sound card that you can buy can even approach that.
we can't assume people bought their computer last week
True, but if they've got even a Pentium 4 (remember those?), they can get 2 to 5 GB/sec. See:
A 2Ghz P4 can get 2GB/sec for ordinary "integer" code
and up to 5GB/sec for better optimized SSE2 code.
Those CPUs are old, and they could still mix an entire orchestra, in real time, without breaking a sweat.
Take a look at the bar graph at the bottom, most CPUs released in the last few years easily do 5GB+ even for "integer" code (SSE3 would be more than double), and the Core i7s do 25GB/sec, which is higher than I thought.
There's just no need to 'standardize' on anything, or even have kernel-mode drivers for anything other than basic "input" or "output". Write your sound mixing code in ordinary C (even Java or C# would be fast enough!), and just send it down the line...
Heck, take a look at software defined radio, there's just no need for dedicated hardware for a lot of things when the CPU is so ridiculously powerful.
And this thread just sums up the problem - in three posts we have now made mention of four different sound systems, and I'll go ahead and mention JACK, oss, and esd right here to make it 7. Various programs are written for each of these, and while some are more deprecated than others, the fact is that getting sound to work on linux is a LOT harder than it needs to be.
Sound stopped being a pain in windows with the advent of Win95 and PnP. Before that the windows bit of it wasn't actually that bad (midi mapping was a little painful, but generally the defaults weren't bad). Getting the DMAs/IRQs right was the real pain.
My linux system has a pretty nice wavetable audio board, but to be honest if I want to play something I just use timidity since I've given up on trying to get the hardware to actually work right. If I needed more than rudimentary sound I'd be really up the creek.
I might be revealing my ignorance here, but is there anything to be even gained from using hardware mixing?
A back of the envelope calculation shows that a typical modern desktop CPU with a nominal memory bandwidth of 10GB/sec can mix 56,000 channels with 48kHz & 32 bit precision. That's... a lot. I suspect that's a few more than even the most wildly fanciful orchestra composition would need, even in 8 channel surround (7000 sounds per channel).
Newer high-end CPUs are now pushing 100GB/sec or higher, so I just can't see what dedicated hardware card could possibly do for your audio that you can't get from some simple mixing software and a "digital out" port on the motherboard!
Even if you're doing some ridiculously complex real-time effects on those sounds, I suspect in the long term audio software would be better off using the GPU of the 3D card for doing the "heavy lifting" instead of low-volume cards with terrible drivers (even in Windows, let alone Linux).