In all fairness, when did Microsoft ever have fanfare? Informed computing enthusiasts were sick of Windows after 10 minutes, opting to at least diversify into Apple and free Unix, and nobody else even knew there was anything other than Windows, and treated it as part of the computer.

Now that people realise they have choices, Microsoft is scrambling to do what it never had to do - actually market its operating system - and has shown all of the competency of a high school dropout.

Using Linux' frequency controls, the Turbo just increases your maximum multiplier by 1, and that's it. If you're configured to maximum performance, you get the Turbo, otherwise you don't. Maybe it's more complicated in Windows, but it's clear that the feature is controllable from the operating system.

The real fix would be to make PulseAudio use OpenAL optionally, so that cards that have accelerated mixing can be made to use it. I don't see the point though - not only are modern CPUs more than powerful enough to do it in userspace, they can't possibly have per-card defects while doing it.

Now that we do have PulseAudio it's best to trim as much fat and necrotic code from the kernel as possible. If the remaining realtime issues can be resolved, for which there is much experimental literature, it'll be perfect.

Linux and open source in general are a theoretically infinite competition to Microsoft. After a big spike in proprietary models, the trend of all software industries is now towards more open standards, more open software and smaller companies offering small sets of products that together solve big problems. This is exactly where open source most naturally thrives, and it's the exact opposite of how Microsoft has always operated - one vendor, one set of products, nothing open. Microsoft's executives know this, they're not stupid, so they're trying to hold back the trend with patents and faux-open standards like OOXML. It's like trying to hold off a global ice age by burning your house down.

It's a scheduler term, not a hardware requirement strategy. Leave the tech to the people who know (certainly not me, but Con is epic).

I first saw it on http://cdtdoug.blogspot.com/2009/05/wascana-is-over.html. I don't have the links I found later but that post and its comments all say the same thing.

Why do people keep repeating that? Even Microsoft's own developers admit that their C/C++ indexing is primitive and broken, while Eclipse's CDT, which has had maybe 0.0001% of the funding and man-hours, is already far superior.

Was elementary school hard for you, with math skills like that? Try to keep up:

500 * 500 = (5 * 5) * (100 * 100) = 25 * 10,000 = 250,000

If it doesn't, it is still far better for your software quality to use cpp (literally, the C preprocessor) to get assertions into the source code. There is basically no alternative to assertions, except for expanding them to a manual if each time, which is *still* better than not having them at all.

If you aren't using RAII semantics, you aren't really using C++, but C+-. If you're using RAII and sane integrity guarantees, exceptions avoid a lot of redundant and bug-prone code.

Even the most primitive data flow analysis would help track that down, but if the code isn't written with assertions all over, you never really know if it's consistent with assumptions or only fooling you all along. I don't write anything without assertions these days.

I for one completely agree. As someone for whom generality is code porn[1], it's been my experience that every little extra bit of generality introduces an order of magnitude more code. In practice this should still save you code compared to repeating yourself for every case, but at some point the costs outweigh the gains and you have to draw a line.

[1]: I like to combine C++ templates and polymorphism. Most people don't, but if you're willing to battle those demons, you can make extremely reusable code, that's still type-safe at compile time. I'll take Scala over that any day, but it's a fun exercise.

Let's say that programming is /already/ composition from a hierarchical tree of components, and that the most basic components (that we care about) are CPU and device instructions. Then let's say that above that level we have system calls, low-level functions, resource abstractions, classes, domain-specific modelling, etc. and that all of this is a perfectly valid composition of components.

Then let's say that the only difference you actually want is to put all of this together with a graphical editor instead of a text editor. Is that fair to say? If that's all you want, then learn to write code, because that's a lot more practical. You're the one that's wrong, not the industry.

If you seriously want components to be designed specifically for graphical composition instead of logical composition, well, that's when you know you're in the wrong industry.

You are ignoring, either through sheer ignorance or a commercial agenda, the wealth of literature and experience on how incredibly impractical it is to shoehorn complex logic and relationships into graphical forms, and especially how difficult it is for a human to interpret (let alone manipulate) the result of such a transformation. Return to the material plane and learn to program correctly, or stay out of the industry.

Well sure, you're from the past. It's best you get used to admitting that.

So who do you think will be writing the "components" for your magic system, and the infrastructure to make the system executable, designable, testable and usable? We have been progressing to increasingly high level code (and in some cases, as you say, component architectures), but the amount of code being written and maintained continues to grow, not shrink.

So the amount of code is growing, and it does more per unit mass, and software engineering skills are increasingly valuable and applicable, and you think this is a trend towards the elimination of code and software engineers? You may want to check your water and food sources for contamination.