If it's not worth looking at then why do people care if there is DRM on it, or why do people continue to make and distribute unauthorized copies?
If "Welcome to The Scene" has shown anything it's that the general mentality of the sources in The Scene is that being first to distribute something makes you the best. Regardless of whether someone wants it or not, having it first is what matters.
I think it's that mentality that drives most piracy - especially when it comes to getting something out before it's "out."
It's the people that download it that decide whether or not it's crap.
I have mixed feelings, myself. I always thought that the benefits of research into manned space missions trickle down into the general scientific body and thus have clear justification; however, that justification is tempered by the fact that a manned crew is exposed to fairly high risk factors. Nobody gets injured in space, it seems - they either make it there and back again, or die trying.
Let me posit a question for you: Assume you work for either NASA or another aerospace organization whose purpose is extra-terrestrial exploration. You've been given a grant for several million dollars (or more, depending on your proposal) to prepare a scientific vehicle to study a particular interesting target - perhaps the moon - and you are given essentially a blank slate to work with; you can do whatever you want for the excursion. You are then confronted with a choice:
Design and build a small lunar lander base station and assosciated robotic devices to explore the lunar surface by remote control. You will feel the exhileration of discovering things no one else will, and you will get to be the first person to see any of the data.
Design and build a manned lunar lander in which better-trained professional astronauts will be sent to the moon to collect samples and information that can be physically returned to Earth. You will probably get to see the data and samples before your colleagues.
Design and build a manned lunar lander in which even inexperienced astronauts could be sent to the lunar surface. You will have the opportunity to go yourself and see, feel, and experience everything for yourself, and you will have the prestigious chance to bring back samples and data with your own hands.
The article summary (no, I won't RTFA, not with a summary like this) suggests they have no idea that Ruby can replace PHP and that they needn't use Rails at all. They sound as if they think Ruby is Rails, and that PHP is somehow superior because the Rails framework failed them.
If this isn't the case, ban the summary writer from ever submitting again. Maybe we can get better summaries some day.
Believe it or not, it's actually both. It is the official standard API documentation, but it's written for the benefit of both implementers and users. Because the standard describes very specific behavior (including side-effects) of implementations, it's the most important and useful resource for users of the API. That, and the book describes in very clear terms how to use the API. It's not a beginner's HOWTO manual, but it's very, very close.
I own 5th edition, and it's the OpenGL reference I use the most.
- Standard Fare, Browser, email, etc. (got that covered with Linux or OSX)
Of course. And if you ever get in a pinch and your company requires IE for some reason, IE 4-6 all run very well in Wine. The Evolution email client also integrates with Exchange fairly well, from what I understand.
- Quicken 2008.
If you're willing to jump through hoops, GNUCash might be able to import some of your data. It's my understanding that Quicken does not run well in Wine, and, in fact, Intuit seems to be deliberately introducing lock-in "features" that get worse with each new version. If you want to keep your financial data, I'd highly recommend getting it out of Quicken ASAP.
- Excel
OpenOffice.org Calc is the most equivalent in functionality (and should have no trouble importing/exporting most documents, provided they don't rely on Excel bugs or heavily on scripts. KFormula (part of KOffice) also comes to mind. Pre-2007 Office apps also work very well in Wine, if you need it. I don't know if 2007 does, if at all.
- Visual Studio 2005 (Mostly.NET 2.0/ASPX/C#) (I know I can not convince my employer to switch, so I have to be able to develop for it).
Mono produces code that will run on.NET (as it is, after all, a.NET-compatible suite), and GCC produces object files that will link with those produced by Visual Studio. Unless you need the UI for some reason, you can pretty well ditch most of it. All Mono is missing at the moment is Windows.Forms (and other similar interfaces), but they are well on the way to getting clones.
What I'd suggest is to try using some open source apps that have been released on Windows and get yourself used to them - bring then into your workflow. Once you've dropped Quicken and are comfortable with working with Mono, you should be pretty well set to start experimenting in Linux. This isn't going to be a format-the-hard-drive-and-install-Linux-today kind of migration for you, until you've unleashed yourself from the worst parts of vendor lock-in.
It mentions 600-900mhz, is that per core or per total CPU? While 64 900mhz cores sounds nice, 900mhz made up of 64 14mhz cores is kinda pointless.
I think you're confused. Never once in the history of computing has the frequency been a factor of the number of CPUs. A CPU's frequency is the measurement of the number of times the CPU's clock or timer asserts in a second. In an SMP environment, all CPUs operate on a synchronized clock, and therefore operate at the same clock speed. All 64 cores operate at 900MHz.
When you said "Blizzard and id are examples of games companies who are moving away from DirectX" what you actually meant to say was, "Blizzard and id are examples of games companies that both use DirectX in their latest products." You can see the confusion that resulted.
I didn't say that myself, but I can see how you got confused. What I think the OP meant to say was "Blizzard and iD are examples of companies who use OpenGL extensively in their titles," which is far closer to the truth. If you want to support Mac OS X, you ned to support OpenGL. Likewise, if you want to keep from pissing off some of the more vocal NVIDIA users, you'll probably want OpenGL support - the opposite being true for ATi users: NVIDIA's OpenGL support is second to none, and ATi's support for DirectX is unparallelled - but NVIDIA's DirectX support is lacking and ATi's OpenGL support is a bad joke.
Seriously, though, if these are the best examples you can come up with, it seems to me that DirectX has a very secure future after all. I mean, if a "naive/beginner" games company like id uses DirectX, it seems that it has a pretty secure footing.
Now I know you're really confused. iD is the company that brought us the 3D FPS genre on PCs. They have used OpenGL almost exclusively since GLQuake! Carmack's well-known comparison of DirectX (5) and OpenGL showed that he saw nothing but problems with DirectX for many years, so the only 3D APIs he ever used in his games were OpenGL and his in-house software engines. It is only recently (DX9.0c) that Carmack has made any indication that he's reconsidering his position on DirectX vs. OpenGL. Every iD game since GLQuake (including Quake II, Quake III, Quake IV, Doom III, and the upcoming Quake Wars, mong others) has used OpenGL exclusively for the graphics engine. (Also, as an aside, Doom 3 and Quake 4 use OpenAL on Linux - I don't know if the same is true on Windows.)
Blizzard, on the other hand, has always been faithful to their Mac fans: All of their games are simultaneously released on Windows and Mac, which, since Warcraft 3, has required that they have an OpenGL codepath for their games. Like I said, War3 and WoW both use the DirectX codepath by default on Windows, but use OpenGL on Macs and as a command-line option and configuration option on Windows. I would expect them to continue in that manner for the forseeable future.
They are, of course, not the only companies that use OpenGL, just the biggest and highest-profile developers of OpenGL titles.
And don't confuse the whole of DirectX with DirectGraphics/Direct3D. DirectX is composed of many parts: DirectSound, DirectPlay, DirectGraphics, DirectInput, etc. Each of them has a functionally equivalent open API: OpenAL, BSD sockets or SDL_Net, OpenGL, SDL, etc. Just because a game requires DirectX doesn't mean that it uses DirectGraphics over OpenGL.
1) Syntactic ambiguity: you can't tell from a glance whether your function call is sending a copy of an object or a reference to an object. A fault with C also, but this should've been fixed
template<class T1, class T2> T1* f1(T2); template<class T1, class T2> T1& f1(const T2&);
The first takes a copy of an object of type T2 and returns a pointer to an object of type T1. The second takes a const reference to an object of type T2 and returns a reference to an object of type T1. What's so difficult about that?
2) Templates: buggy and inefficient. I would've preferred STL to work on a generic object class.
Templates are incredibly efficient, though difficult to write correctly the first time around. A template class has zero code presence if it's never referenced, and complex recursive templates can compile down to a single constant. It's turing-complete, and therefore capable of any operation. The most infamous use of templates was a template that returned successive prime numbers as error messages! Most bugs show up at compile time, and are thus easy to fix. (Error messages will get help in C++0x.)
4) Operator Overloading: another case of ambiguity. You'll never be quite sure what your code is doing.
This is why you need to ship strong documentation with your libraries. But when you're actually using operator overloading, it actually makes a lot of sense and simplifies otherwise verbose code. For example:
template<class T> vector3 { vector3(T x, T y, T z) : _x(x), _y(y), _z(z) {} T _x, _y, _z; vector3<T> operator+ (vector3<t>& r) { return vector3<T>(_x+r._x, _y+r._y, _z+r._z); } }
Of course, there are the coders who do weird things with mislabeled functions, but who in their right mind would use that code anyway?
5) Lack of Garbage Collection: I would've at least liked a reference counting pointer without having to download BOOST.
It is being considered (AFAIK) for C++0x. But why would you want garbage collection that hurts your program's performance and takes up precious memory that could be better used by your program in 256KiB of memory on your embedded system? Or, for that matter, would you want it interrupting things in your massive 4GiB program just to clean up a huge heap that is under extremely heavy use? (Like in a database.)
GC is not for everyone. It's be nice to have a little help, but it gets in the way.
6) Non-standard ABI: C object files are reusable across multiple compilers, since their format is standardized. In C++ it's not. Everything must be compiled in the same version of the same compiler.
This is only true when you're using virtual functions in your publicly exposed interfaces. GCC now supports the MSVC++ ABI (and can link with DirectX!), so it's clearly not an unsurmountable problem. I really don't see why this is a valid complaint now. (It certainly was a problem, but no more.)
Some clarification: Doom 3/Quake 4 is an OpenGL title. They use DirectX for the DirectInput and DirectSound APIs, I believe. Doom 3 had to use EAX for sound output, I'm sure - I'm just not familiar with it. WoW is a DirectX title with an OpenGL engine (like War3): It uses DirctX for graphics by default, but with the -opengl switch, it uses OpenGL for graphics, which works better for NVIDIA and Wine users and is a carryover from Mac OS X support.
1) DirectX does a hell of a lot more than OpenGL does. It does input, sound, some networking I believe.
... For which most OpenGL developers use APIs like SDL, OpenAL, and Allegro, among others. (Incidentally, no one uses DirectPlay except for very small, low-budget projects. It's notorious for sucking. Most developers just use the raw sockets API.)
2) DirectX is easier to program, because it's designed to be games-centric, where as OpenGL is designed to be more general-purpose. I've not programmed either myself, so I can't personally comment, but I've heard it from multiple people.
DirectX is notorious for requiring very complex (and, historically, horrendously inefficient) blocks of code for some simple operations, which are usually done in OpenGL in far less code. Historically, OpenGL was developed by SGI for their high-end workstations for high-quality 3D graphics. When they opened the spec and it was (eventually) ported to Windows, it immediately saw use for games. Most games don't need half of the core API, but nearly all of the updates to OpenGL since have been for features game developers want and use.
The extension mechanism seems arcane to novice developers, but it's actually quite simple and elegant, and offers a wide range of flexibility that isn't offered by DirectX. Many features (especially from NVIDIA) see light in OpenGL extensions long before they're ever finalized in DirectX (which requires a whole new DX revision to add).
3) Most video cards support DirectX better than they support OpenGL. Again, cards are used for games, and DirectX is used for games, but OpenGL is general-purpose. Nobody makes general-purpose video cards, except possibly Matrox.
OpenGL only really sucks if the IHVs have a poor implementation of OpenGL's backend - as in the case of ATi.
For the more powerful cards, AMD/ATi still (to my knowledge) make the FireGL cards, and NVIDIA still sells their Quadro line (which is little more than their consumer GeForce line with some driver tweaks and a beefier BIOS). Matrox hasn't made a decent 3D card in years. The market is held mostly by NVIDIA Quadros and 3DLabs' Wildcat (which I'm unsure whether they still make). FireGL is an also-ran these days, from what I understand.
From the customer's standpoint, generally DirectX games handle things like Alt-Tab, or running in windowed mode better than OpenGL games. It also doesn't help that all the games that specifically advertise themselves as being OpenGL kind of suck, or have non-impressive graphics.
Generally, in Windows, there's a lot of fancy tricks you have to perform to properly handle alt-tabbing and minimizing. Windows lose their device context and have to re-acquire it when a fullscreen window loses focus, IIRC. There's a blurb on the issue in the DirectX programmer's guide, and I believe it's a similar issue with OpenGL. That's entirely the fault of the developers, not the APIs.
Many OpenGL games also tend to target a wider audience (including MacOS and Linux users), so most developers mainly stick to the extensions and parts of the core that are well-known to be widely hardware accelerated. This hampers somewhat the things that they can do, but there's nothing at all keeping OpenGL developers from using OpenGL 2.1 features on 1.3 hardware - anything that isn't directly hardware-accelerated is required to be done in software by the specification.
I would love to see more PC games developers target OpenGL, but for that to happen the little things that make DirectX attractive need to either be brought to OpenGL or to an open support API that accompanies OpenGL.
What, you mean like SDL, OpenAL, OpenML, Allegro, QT, GTK+, or any of dozens of other APIs that have either OpenGL hooks or simply complement it? The gamut of APIs that run on every platform known to man and then some?
SDL provides an API to the developer that offers sound, input, GL initialization, etc. in the same way that DirectX provides an API to developers that offers sound, input, graphics, etc.
SDL serves the same purpose as the rest of DirectX does. That it uses DirectX to provide that support is irrelevant.
If a game targets DirectX10.1 then 4xAA is guaranteed to be there, period. If a game does not require 4xAA then it doesn't have to target DirectX10.1.
So get used to it otherwise you'll be shitting yourself for every single DirectX release going forward. This is how it works now.
I nearly shat myself when I realized that DirectX stifles the innovation of graphics IHVs by forcing them to conform to a single, non-extensible set stndard.
Now I nearly shit myself when I hear about a new DX release because I know that there's still no extension mechanism and no way for developers on either side of the API to go beyond the standard when they can. It scares me to realize that this is the selling point.
I was actually quite surprised that, while performing a nation-wide cross-spectrum interference study of the FM radio band, the entire nation is *shockingly* bare. (Clark Parrish and I changed that somewhat by using that information to submit 4221 FM translator applications, but it's still surprisingly sparse, even post-Radio Assist Ministry.) We even accounted for 2-channel and 3-channel interference patterns, and still found numerous very large areas on every channel.
I'd be very surprised indeed if the same was not true of TV stations.
Probably. Everyone else has already figured out that it comes with spyware and violates the protocol and hammers trackers enough to get banned at all of the private trackers.
It's a sin to use anything except the latest Azureus, libtorrent, or uTorrent.
Although, apparently, soon it may be also a sin to use uTorrent since it's not Free.
Yes it does. And it does that to encourage the development and sale of the patented item for the improvement of society overall...
However the manufacture and sale of a product does not need to be by the inventor. The framers of the constitution understood that an inventor may not have the resources to bring something to market, this was probably more true in their day than ours, hence the licensing of rights to patented technology to someone who does have the necessary resources.
Quoth the OP:
Unless they have a competing unit in production, or are already collecting license fees from companies that have competing units in production, they should lose this patent!
Probably, but the GPU is quite acceptable and the SPUs' dedicated memory (and DMA) makes it possible to do more: more physics, more image processing, more audio/video decoding, etc. Games rely heavily on data processing, and having 7 dedicated Altivec units with their own memory access makes it possible to do a lot of data processing that would have to be done on the main processor or in the GPU otherwise.
A few moments ago, Linus posted a message explaining why he rejected plugsched: He detests politically-motivated code.
So I absolutely detest adding code for "political" reasons.
I personally feel that modal behaviour is bad, so it would introduce what
is in my opinion bad code, and likely result in problems not being found
and fixed as well (because people would pick the thing that "works for
them", and ignore the problems in the other module).
And while I disagree with the choices he made regarding SD and plugsched, I do see his point: Each of those schedulers would become too specialized and would ignore the issues exposed in other workloads. SD works extremely well in most situations, but has trouble in specific high-load server environments. CFS, likewise, has problems with desktop usage. Both developers had different goals.
(I just think Con met goals beyond his own better than Ingo did.)
The problem with giving away driver source code is that it inhibit a company from being able to recover its research and development costs effectively because of the likelihood of somebody else figuring out the hardware interface specs from the driver and reverse engineering a compatible product for a fraction of the cost (because figuring out a way to do something that somebody else has already done is a lot easier than inventing the idea in the first place), and it would price the first company's product out of the market before they've recovered their R&D costs.
I have trouble parsing long run-ons, but I think I figured out what you're saying. And I really don't see your point.
Knowing how a driver interfaces with a chip does not make it easier to understand how a chip works. The only way to understand that is to have a deep knowledge of the silicon.
Example: While Intel used the 80x86 mnemonic for their commodity CPUs, there was no legal means by which Intel could prevent the duplication of those chips in their primary market. (In fact, when AMD began producing AM386 and AM486 chips that were pin-compatible with Intel's 80386 and 80486 chips, Intel sued AMD and lost, since this is common practice throughout the semiconductor industry. For example, the 74xx and its low-power variants - 74Cxx, 74HCxx, etc. - has been manufactured by everyone from National Semiconductor to Motorola, where the competition for price has been tradtitionally very good.) Thus, after Intel failed to prevent AMD and Cyrix from producing clones of their chips, they tademarked the "name" of the chip, calling it the Pentium. IIRC, AMD licensed the x86 ISA to continue producing their AM586 chips. When their license terminated, they began developing a "80x86-compatible ISA" that made it possible to produce the K6, and later the Athlon and friends. They have invested billions in R&D to produce a chip that is ISA-compatible, but not pin-compatible with Intel's offerings. Cyrix (now ViA) and Transmeta did the same.
Simply because one is "intimately familiar" with the x86 instruction set because it is well-documented does not mean it is therefore "easy" to produce such chips. They contain an enormous amount of complexity at the logic level, just to interpret a 0x90 byte as "no-op." Previously, any company wishing to produce an electrically-compatible variant of another company's offering would crack open the plastic case and analyze the silicon (if it was complex, as in the case of the 80x86) or simply work their design around the electrical properties of the package (as in the case of the 74xx), especially since the components are well-understood: all engineers are familiar with the operation of a transistor.
Thus, I don't see how your argument applies. If a Chinese company wishes to duplucate NVIDIA's GPUs, they would either crack open and analyze the silicon or conduct industrial espionage (i.e., raid TSMC). However, knowing what commands mean when sent over a PCI bus to the chip in question is a completely different aspect of the problem. It's truly like saying you know how to build a car because you assembled a steering wheel.
Again it's their hardware, instead of taking years of flak in the media, why not just write up to date drivers?! What? Does it take 100 software engineers working around the clock for 5 years to have a working driver?!
The math doesn't have to do just with geography or number of subscribers, but a combination of the two: United States: 302.44 million people / 9.16 million square kilometers = 33.02 people per square kilometer. Japan: 127.76 million people / 0.37 million square kilometers = 345.30 people per square kilometer That's a big difference.
You're missing a huge detail here: about 50% of the US' geography is very nearly empty. It would be much fairer to divide the population by an estimate of the occupied land area: 302.44 million people / 35% of 9.16 million square kilometers = 94.34 people per square kilometer. Yes, there is a total average of 33.02 people per sq.km., but the rural areas of the US are both uncovered by cellular networks and unoccupied by statistically significant numbers of people.
He did prove his code superior. Repeatedly. To my knowledge, the only "issue" was Mike Galbraith's complaint that CPU time was divided evenly among processes at the same priority. (Reading back over the thread, I noticed that Mike mentioned the default nice value was 4, when it's actually 10, and his "test" was a pair of nice +5 lame processes. I couldn't find any other complaints against Con's code.)
But then, over the course of a single week, Ingo had a replacement scheduler written that immediately competed against SD, and only one week later, CFS was considered "ready" for 2.6.23.
If you were in Con's place, wouldn't this upset you? Especially given that SD has a history of testing and refinements going back several years? Several years for a well-proven (and quite small!) chunk of code that simplified scheduling, versus a 1-week rewrite that got maybe 1 week of serious public testing before being committed to head?
As a programmer and as a user, this pisses me the fuck off. CFS is young and unproven. It seems to work just as good as SD, but it simply doesn't have the background and code maturity that SD does.
Add to this the fact that Con only gets a "this was his idea" mention, and this situation, to me, seems absolutely ludicrous. Ingo seriously needs some slapping around, both because of the audacity of CFS and because he ignored Con for so goddamn long.
Yes, I'm glad the kernel finally has a scheduler usable on the desktop and that is tunable to individual (read, servers, among others) needs. I'm glad Ingo finally came around and put interactivity at a priority. But the way this was done was wrong in every respect.
Slashdot Mirror
If "Welcome to The Scene" has shown anything it's that the general mentality of the sources in The Scene is that being first to distribute something makes you the best. Regardless of whether someone wants it or not, having it first is what matters.
I think it's that mentality that drives most piracy - especially when it comes to getting something out before it's "out."
It's the people that download it that decide whether or not it's crap.
Let me posit a question for you: Assume you work for either NASA or another aerospace organization whose purpose is extra-terrestrial exploration. You've been given a grant for several million dollars (or more, depending on your proposal) to prepare a scientific vehicle to study a particular interesting target - perhaps the moon - and you are given essentially a blank slate to work with; you can do whatever you want for the excursion. You are then confronted with a choice:
Which would you choose? I'd sure as hell pick 3.
The article summary (no, I won't RTFA, not with a summary like this) suggests they have no idea that Ruby can replace PHP and that they needn't use Rails at all. They sound as if they think Ruby is Rails, and that PHP is somehow superior because the Rails framework failed them.
If this isn't the case, ban the summary writer from ever submitting again. Maybe we can get better summaries some day.
Believe it or not, it's actually both. It is the official standard API documentation, but it's written for the benefit of both implementers and users. Because the standard describes very specific behavior (including side-effects) of implementations, it's the most important and useful resource for users of the API. That, and the book describes in very clear terms how to use the API. It's not a beginner's HOWTO manual, but it's very, very close.
I own 5th edition, and it's the OpenGL reference I use the most.
Of course. And if you ever get in a pinch and your company requires IE for some reason, IE 4-6 all run very well in Wine. The Evolution email client also integrates with Exchange fairly well, from what I understand.
If you're willing to jump through hoops, GNUCash might be able to import some of your data. It's my understanding that Quicken does not run well in Wine, and, in fact, Intuit seems to be deliberately introducing lock-in "features" that get worse with each new version. If you want to keep your financial data, I'd highly recommend getting it out of Quicken ASAP.
OpenOffice.org Calc is the most equivalent in functionality (and should have no trouble importing/exporting most documents, provided they don't rely on Excel bugs or heavily on scripts. KFormula (part of KOffice) also comes to mind. Pre-2007 Office apps also work very well in Wine, if you need it. I don't know if 2007 does, if at all.
Mono produces code that will run on .NET (as it is, after all, a .NET-compatible suite), and GCC produces object files that will link with those produced by Visual Studio. Unless you need the UI for some reason, you can pretty well ditch most of it. All Mono is missing at the moment is Windows.Forms (and other similar interfaces), but they are well on the way to getting clones.
What I'd suggest is to try using some open source apps that have been released on Windows and get yourself used to them - bring then into your workflow. Once you've dropped Quicken and are comfortable with working with Mono, you should be pretty well set to start experimenting in Linux. This isn't going to be a format-the-hard-drive-and-install-Linux-today kind of migration for you, until you've unleashed yourself from the worst parts of vendor lock-in.
I think you're confused. Never once in the history of computing has the frequency been a factor of the number of CPUs. A CPU's frequency is the measurement of the number of times the CPU's clock or timer asserts in a second. In an SMP environment, all CPUs operate on a synchronized clock, and therefore operate at the same clock speed. All 64 cores operate at 900MHz.
I didn't say that myself, but I can see how you got confused. What I think the OP meant to say was "Blizzard and iD are examples of companies who use OpenGL extensively in their titles," which is far closer to the truth. If you want to support Mac OS X, you ned to support OpenGL. Likewise, if you want to keep from pissing off some of the more vocal NVIDIA users, you'll probably want OpenGL support - the opposite being true for ATi users: NVIDIA's OpenGL support is second to none, and ATi's support for DirectX is unparallelled - but NVIDIA's DirectX support is lacking and ATi's OpenGL support is a bad joke.
Now I know you're really confused. iD is the company that brought us the 3D FPS genre on PCs. They have used OpenGL almost exclusively since GLQuake! Carmack's well-known comparison of DirectX (5) and OpenGL showed that he saw nothing but problems with DirectX for many years, so the only 3D APIs he ever used in his games were OpenGL and his in-house software engines. It is only recently (DX9.0c) that Carmack has made any indication that he's reconsidering his position on DirectX vs. OpenGL. Every iD game since GLQuake (including Quake II, Quake III, Quake IV, Doom III, and the upcoming Quake Wars, mong others) has used OpenGL exclusively for the graphics engine. (Also, as an aside, Doom 3 and Quake 4 use OpenAL on Linux - I don't know if the same is true on Windows.)
Blizzard, on the other hand, has always been faithful to their Mac fans: All of their games are simultaneously released on Windows and Mac, which, since Warcraft 3, has required that they have an OpenGL codepath for their games. Like I said, War3 and WoW both use the DirectX codepath by default on Windows, but use OpenGL on Macs and as a command-line option and configuration option on Windows. I would expect them to continue in that manner for the forseeable future.
They are, of course, not the only companies that use OpenGL, just the biggest and highest-profile developers of OpenGL titles.
And don't confuse the whole of DirectX with DirectGraphics/Direct3D. DirectX is composed of many parts: DirectSound, DirectPlay, DirectGraphics, DirectInput, etc. Each of them has a functionally equivalent open API: OpenAL, BSD sockets or SDL_Net, OpenGL, SDL, etc. Just because a game requires DirectX doesn't mean that it uses DirectGraphics over OpenGL.
The first takes a copy of an object of type T2 and returns a pointer to an object of type T1. The second takes a const reference to an object of type T2 and returns a reference to an object of type T1. What's so difficult about that?
Templates are incredibly efficient, though difficult to write correctly the first time around. A template class has zero code presence if it's never referenced, and complex recursive templates can compile down to a single constant. It's turing-complete, and therefore capable of any operation. The most infamous use of templates was a template that returned successive prime numbers as error messages! Most bugs show up at compile time, and are thus easy to fix. (Error messages will get help in C++0x.)
This is why you need to ship strong documentation with your libraries. But when you're actually using operator overloading, it actually makes a lot of sense and simplifies otherwise verbose code. For example:
Of course, there are the coders who do weird things with mislabeled functions, but who in their right mind would use that code anyway?
It is being considered (AFAIK) for C++0x. But why would you want garbage collection that hurts your program's performance and takes up precious memory that could be better used by your program in 256KiB of memory on your embedded system? Or, for that matter, would you want it interrupting things in your massive 4GiB program just to clean up a huge heap that is under extremely heavy use? (Like in a database.)
GC is not for everyone. It's be nice to have a little help, but it gets in the way.
This is only true when you're using virtual functions in your publicly exposed interfaces. GCC now supports the MSVC++ ABI (and can link with DirectX!), so it's clearly not an unsurmountable problem. I really don't see why this is a valid complaint now. (It certainly was a problem, but no more.)
Some clarification: Doom 3/Quake 4 is an OpenGL title. They use DirectX for the DirectInput and DirectSound APIs, I believe. Doom 3 had to use EAX for sound output, I'm sure - I'm just not familiar with it. WoW is a DirectX title with an OpenGL engine (like War3): It uses DirctX for graphics by default, but with the -opengl switch, it uses OpenGL for graphics, which works better for NVIDIA and Wine users and is a carryover from Mac OS X support.
... For which most OpenGL developers use APIs like SDL, OpenAL, and Allegro, among others. (Incidentally, no one uses DirectPlay except for very small, low-budget projects. It's notorious for sucking. Most developers just use the raw sockets API.)
DirectX is notorious for requiring very complex (and, historically, horrendously inefficient) blocks of code for some simple operations, which are usually done in OpenGL in far less code. Historically, OpenGL was developed by SGI for their high-end workstations for high-quality 3D graphics. When they opened the spec and it was (eventually) ported to Windows, it immediately saw use for games. Most games don't need half of the core API, but nearly all of the updates to OpenGL since have been for features game developers want and use.
The extension mechanism seems arcane to novice developers, but it's actually quite simple and elegant, and offers a wide range of flexibility that isn't offered by DirectX. Many features (especially from NVIDIA) see light in OpenGL extensions long before they're ever finalized in DirectX (which requires a whole new DX revision to add).
OpenGL only really sucks if the IHVs have a poor implementation of OpenGL's backend - as in the case of ATi.
For the more powerful cards, AMD/ATi still (to my knowledge) make the FireGL cards, and NVIDIA still sells their Quadro line (which is little more than their consumer GeForce line with some driver tweaks and a beefier BIOS). Matrox hasn't made a decent 3D card in years. The market is held mostly by NVIDIA Quadros and 3DLabs' Wildcat (which I'm unsure whether they still make). FireGL is an also-ran these days, from what I understand.
Generally, in Windows, there's a lot of fancy tricks you have to perform to properly handle alt-tabbing and minimizing. Windows lose their device context and have to re-acquire it when a fullscreen window loses focus, IIRC. There's a blurb on the issue in the DirectX programmer's guide, and I believe it's a similar issue with OpenGL. That's entirely the fault of the developers, not the APIs.
Many OpenGL games also tend to target a wider audience (including MacOS and Linux users), so most developers mainly stick to the extensions and parts of the core that are well-known to be widely hardware accelerated. This hampers somewhat the things that they can do, but there's nothing at all keeping OpenGL developers from using OpenGL 2.1 features on 1.3 hardware - anything that isn't directly hardware-accelerated is required to be done in software by the specification.
What, you mean like SDL, OpenAL, OpenML, Allegro, QT, GTK+, or any of dozens of other APIs that have either OpenGL hooks or simply complement it? The gamut of APIs that run on every platform known to man and then some?
SDL provides an API to the developer that offers sound, input, GL initialization, etc. in the same way that DirectX provides an API to developers that offers sound, input, graphics, etc.
SDL serves the same purpose as the rest of DirectX does. That it uses DirectX to provide that support is irrelevant.
I nearly shat myself when I realized that DirectX stifles the innovation of graphics IHVs by forcing them to conform to a single, non-extensible set stndard.
Now I nearly shit myself when I hear about a new DX release because I know that there's still no extension mechanism and no way for developers on either side of the API to go beyond the standard when they can. It scares me to realize that this is the selling point.
... But didn't SkyNet go online 10 years ago last Saturday?
I was actually quite surprised that, while performing a nation-wide cross-spectrum interference study of the FM radio band, the entire nation is *shockingly* bare. (Clark Parrish and I changed that somewhat by using that information to submit 4221 FM translator applications, but it's still surprisingly sparse, even post-Radio Assist Ministry.) We even accounted for 2-channel and 3-channel interference patterns, and still found numerous very large areas on every channel.
I'd be very surprised indeed if the same was not true of TV stations.
Probably. Everyone else has already figured out that it comes with spyware and violates the protocol and hammers trackers enough to get banned at all of the private trackers.
It's a sin to use anything except the latest Azureus, libtorrent, or uTorrent.
Although, apparently, soon it may be also a sin to use uTorrent since it's not Free.
Rule number 1: we do not talk about the USENET.
Rule number 2: we do not talk about the USENET.
Quoth the OP:
Emphasis mine.
Probably, but the GPU is quite acceptable and the SPUs' dedicated memory (and DMA) makes it possible to do more: more physics, more image processing, more audio/video decoding, etc. Games rely heavily on data processing, and having 7 dedicated Altivec units with their own memory access makes it possible to do a lot of data processing that would have to be done on the main processor or in the GPU otherwise.
A few moments ago, Linus posted a message explaining why he rejected plugsched: He detests politically-motivated code.
And while I disagree with the choices he made regarding SD and plugsched, I do see his point: Each of those schedulers would become too specialized and would ignore the issues exposed in other workloads. SD works extremely well in most situations, but has trouble in specific high-load server environments. CFS, likewise, has problems with desktop usage. Both developers had different goals.
(I just think Con met goals beyond his own better than Ingo did.)
I have trouble parsing long run-ons, but I think I figured out what you're saying. And I really don't see your point.
Knowing how a driver interfaces with a chip does not make it easier to understand how a chip works. The only way to understand that is to have a deep knowledge of the silicon.
Example: While Intel used the 80x86 mnemonic for their commodity CPUs, there was no legal means by which Intel could prevent the duplication of those chips in their primary market. (In fact, when AMD began producing AM386 and AM486 chips that were pin-compatible with Intel's 80386 and 80486 chips, Intel sued AMD and lost, since this is common practice throughout the semiconductor industry. For example, the 74xx and its low-power variants - 74Cxx, 74HCxx, etc. - has been manufactured by everyone from National Semiconductor to Motorola, where the competition for price has been tradtitionally very good.) Thus, after Intel failed to prevent AMD and Cyrix from producing clones of their chips, they tademarked the "name" of the chip, calling it the Pentium. IIRC, AMD licensed the x86 ISA to continue producing their AM586 chips. When their license terminated, they began developing a "80x86-compatible ISA" that made it possible to produce the K6, and later the Athlon and friends. They have invested billions in R&D to produce a chip that is ISA-compatible, but not pin-compatible with Intel's offerings. Cyrix (now ViA) and Transmeta did the same.
Simply because one is "intimately familiar" with the x86 instruction set because it is well-documented does not mean it is therefore "easy" to produce such chips. They contain an enormous amount of complexity at the logic level, just to interpret a 0x90 byte as "no-op." Previously, any company wishing to produce an electrically-compatible variant of another company's offering would crack open the plastic case and analyze the silicon (if it was complex, as in the case of the 80x86) or simply work their design around the electrical properties of the package (as in the case of the 74xx), especially since the components are well-understood: all engineers are familiar with the operation of a transistor.
Thus, I don't see how your argument applies. If a Chinese company wishes to duplucate NVIDIA's GPUs, they would either crack open and analyze the silicon or conduct industrial espionage (i.e., raid TSMC). However, knowing what commands mean when sent over a PCI bus to the chip in question is a completely different aspect of the problem. It's truly like saying you know how to build a car because you assembled a steering wheel.
They're Canadians. This surprises you?
You're missing a huge detail here: about 50% of the US' geography is very nearly empty. It would be much fairer to divide the population by an estimate of the occupied land area: 302.44 million people / 35% of 9.16 million square kilometers = 94.34 people per square kilometer. Yes, there is a total average of 33.02 people per sq.km., but the rural areas of the US are both uncovered by cellular networks and unoccupied by statistically significant numbers of people.
I'm still waiting for someone to explain to me why this isn't even touched on in most CS programs.
In fact, I'm still waiting for someone to help me understand it. :\
He did prove his code superior. Repeatedly. To my knowledge, the only "issue" was Mike Galbraith's complaint that CPU time was divided evenly among processes at the same priority. (Reading back over the thread, I noticed that Mike mentioned the default nice value was 4, when it's actually 10, and his "test" was a pair of nice +5 lame processes. I couldn't find any other complaints against Con's code.)
But then, over the course of a single week, Ingo had a replacement scheduler written that immediately competed against SD, and only one week later, CFS was considered "ready" for 2.6.23.
If you were in Con's place, wouldn't this upset you? Especially given that SD has a history of testing and refinements going back several years? Several years for a well-proven (and quite small!) chunk of code that simplified scheduling, versus a 1-week rewrite that got maybe 1 week of serious public testing before being committed to head?
As a programmer and as a user, this pisses me the fuck off. CFS is young and unproven. It seems to work just as good as SD, but it simply doesn't have the background and code maturity that SD does.
Add to this the fact that Con only gets a "this was his idea" mention, and this situation, to me, seems absolutely ludicrous. Ingo seriously needs some slapping around, both because of the audacity of CFS and because he ignored Con for so goddamn long.
Yes, I'm glad the kernel finally has a scheduler usable on the desktop and that is tunable to individual (read, servers, among others) needs. I'm glad Ingo finally came around and put interactivity at a priority. But the way this was done was wrong in every respect.