I hate to break the news to you, but Doom wasn't out ~15 years ago. ^_^ Personally, I wrote nasty DOS user interface shells in QBASIC for my step-grandfather (who was completely inept but expected to use the glorious 386 computer to write news articles), and snuck off to play shareware CD volumes and Carmen Sandiego games. One of my favorites was a game where you tried to dive down into the ocean and evade sharks and stuff. It was really whacky. XD I didn't get a 486 for a few years, it was a Compaq 486/66 DX2 (no FPU of course) and I mostly played evil little boring games and got gaming hints off of school Macintoshes (it was -amazing- after all when Netscape 2.0 was finally released).
C++ isn't a "better C", really, so I suppose I'm somewhat in agreement. C++ seriously breaks compatibility with C, of course, though uses roughly the same syntax to extend itself over the top. Objective C is compatible with the underlying C (it's compatible with C99 too, last time I checked), while using a different "new" syntax for the object orientation, as well as providing a nifty class library and dynamic type checking. In some respects, it's like C#, including the decently poor class library API (compared to Java, anyway), but to me, it's basically what C++ should've been. The only real "downside" in my opinion has been that it doesn't have class-local storage, but instead uses the exact same storage as C, which can make tracking data "globally" through an application slightly difficult, since you're either forced with global storage, or function-local storage (and then passing it around through everything via pointers), or some other more "traditional" means of throwing data about. C++ is nice that it's compatible with C libraries in general, and you can keep functions and data together in classes, which makes a decent amount of sense, though I've been told that the way C# does some of the more "trivial" data types (bools, attributes, etc) is a little more efficient relating to class storage. But...here I am going on and on, too.
It's worse for dogs from Russia, too. Now you'll be hearing all of the Dog versions of the Soviet Russia jokes! "Kibble is Red, French Poodles are Blue, In Soviet Russia, Testicles Lick You!"
It seems as if they're moving way too prematurely on this. In the article it said they posted to a Microsoft newsgroup and didn't receive a reply, and that this means that Microsoft will never fix the bug. Obviously there -may- be some tech support people roaming the newsgroups, but it would've made much more sense to simply contact Microsoft's technical support department and talked with someone directly about this error. This is similar to having your car found defective, and then placing a flyer downtown to ask the company to contact you about options instead of picking up the phone and dialing the correct number. I'm not a fan of Microsoftian ideals, but wouldn't that have made more sense before going all this way?
...and say, "Don't use that electric shaver, the magnetism will kill you!", along with the old stand-bys of other varities like: "Your eyes will stick that way one day", and don't forget "some storks dropped you off at our house one day, and that's how children are made".
Actually, Intel seems decently smart about support. At least for their -paid- customers (I get an 'Access Forbidden' on their Premier support site, even though it says I should be able to get there with the free version too), there are pretty frequent minor patches that you don't notice if you just happen to check on the website once every few weeks.
It may be easy to some to patch their version of GCC for a bug they happen to hear about, but it's not a realistic expectation for most users. GCC is pretty "sluggish" on even bugfix updates, let alone noticing some of the bugs. gcc -march=athlon-tbird (and at least -march=athlon as well) can generate -really- grody incorrect code in even general situations, giving out really sub-par speed, even compared to -march=i686. The unfortunate thing being that this bug has been known about since circa 3.0.1, and hasn't been fixed by 3.3.2, and I've heard no mention of it being fixed in the 3.4 CVS branch (nor with my tests about five months ago).
Personally, I'm hoping an "alternative" compiler like TenDRA gets off the ground and can fill that void between overwhelming most-every-platform cross-compiler, and "beedy eyed" binary-only x86-optimized compiler, neither of which operates with any other particularly well.
idb 'kinda works' if you don't use the debug flags, but the main difference between gcc and icc, and gdb and idb, is that idb generally doesn't pick anything up unless you compile with debug flags explicitly, while gdb can at least give you intelligible "debugging" even without explicitly using -g. Though using icc itself doesn't usually make debugging -impossible- either, using -fomit-frame-pointer with gcc will quite horribly ruin your day if you're trying to debug those cross icc/gcc glitches.
Actually, just to note, there is (as there has been since 7.0 or so) a non-commercial version of the Linux compiler. You're not "allowed" to compile commercial stuff with it, but $0 is still cheaper than paying for 8.0 if you don't go for that sort of thing or just want to see how well it'll work with your libraries. (not to sound like an Intel saleswoman, gah)
I don't mean to be particularly critical, but how can anyone miss so many underrated classics?
Sid Meier's Covert Action comes first and foremost to mind, with it's witty "double-oh-seven" style action and puzzle-solving as one of the best but critically missed classics. Perhaps its only flaw is that it has circa-1988 graphics, but I still play it every few weeks just to see if I'm still 'on my game'.
There are also mid-range 'kinda unknown near classics', which would've been big blockbusters with just a little more marketting, or a little more polish. Games such as Syndicate, Magic Carpet, (I'm not a Bullfrog saleswoman) and Daggerfall.
Though, it seems to've missed some of the other fine more mainstream classics out there, such as Neuromancer. What about Descent? Or Descent: Freespace?
None of these were really Genre-setting benchmarks, but they all pushed the envelope for their time, and truly made you think about what games could be capable of one day. Games like these are the reason I got into game programming in the first place. They were innovative, smart, and often overlooked, as this list seems to've done.
Perhaps instead of listing three Maxis "sim" games, perhaps it should've made room for a few of these underdogs.
Are you sure it shouldn't be 'arctic sea warriors'?
I just don't know why they didn't pick FreeBSD, though. A bunch of Daemons running around with M16A2s and P90s would be a lot more fearsome to whoever the US is planning to invade next! *cough*
No offense, but...*shifty eyes darting around* Perhaps with that great idea, you should probably be nominated for the Tyrannical Overloard poll currently on Slashdot.
The US government would be proud, though I hope they don't start making us Mutants register anytime soon.:D
Now all you have to do is bury and compress your yard refuse and add a few million years...then FIND it, drill for it, barrel it, refine it from crude into usable gasoline, and pour it into your car. Then, drive somewhere between 15-27 miles (I hope you don't drive a Porsche or SUV), and then wash, rinse, and repeat. ^_^
Though, I hope you write this down. Slashdot archives may not be available in 15 million years (give or take), but...then again, neither probably will your car!
I think hard-working open-source developers are often neglected, particularly for things like this, which started over adamant refusal of CVS access to someone effectively maintaining a platform.
CVS access is like giving someone the keys to the T-Bird. Everyone's excited to get it, but the parents are always terrified the kid will crash into a tree...and wreck the T-Bird (aww, don't worry, the kid will be FINE...). But CVS has this marvelous feature. You can create tags, and still quickly get around botched commits.
I work on an open-source game (I'm not going to plug it), and most of my commits revolve around a particular area, but occasionally I go over and revamp the configure.in/Makefile.am system and rip out all of the cruft. Ah, there's something nice about that efficiency, but...I could just as easily make it unusable if I made a large commit and didn't check everything first.
But that comes to my other point. You have to appreciate HOW much time each developer puts in. Some will only put in an hour every month or two, while some will simply stay and work on something, a dozen hours a day (or equivilent for their busy life), until it's done, even if small, like autoconf/automake files. Even a relatively unnoticable change from a user's perspective can have huge developer benefits, and people often forget that. Some developers will go for every last user-noticable feature, and some, perhaps like me, will often help out the other developers as much as they can, so that they can be more productive. Project leads often don't realize what a difference that makes until six months after a commit. *grins sheepishly at her 'boss'*
Slashdot Mirror
I hate to break the news to you, but Doom wasn't out ~15 years ago. ^_^
Personally, I wrote nasty DOS user interface shells in QBASIC for my step-grandfather (who was completely inept but expected to use the glorious 386 computer to write news articles), and snuck off to play shareware CD volumes and Carmen Sandiego games. One of my favorites was a game where you tried to dive down into the ocean and evade sharks and stuff. It was really whacky. XD
I didn't get a 486 for a few years, it was a Compaq 486/66 DX2 (no FPU of course) and I mostly played evil little boring games and got gaming hints off of school Macintoshes (it was -amazing- after all when Netscape 2.0 was finally released).
C++ isn't a "better C", really, so I suppose I'm somewhat in agreement. C++ seriously breaks compatibility with C, of course, though uses roughly the same syntax to extend itself over the top.
Objective C is compatible with the underlying C (it's compatible with C99 too, last time I checked), while using a different "new" syntax for the object orientation, as well as providing a nifty class library and dynamic type checking.
In some respects, it's like C#, including the decently poor class library API (compared to Java, anyway), but to me, it's basically what C++ should've been. The only real "downside" in my opinion has been that it doesn't have class-local storage, but instead uses the exact same storage as C, which can make tracking data "globally" through an application slightly difficult, since you're either forced with global storage, or function-local storage (and then passing it around through everything via pointers), or some other more "traditional" means of throwing data about. C++ is nice that it's compatible with C libraries in general, and you can keep functions and data together in classes, which makes a decent amount of sense, though I've been told that the way C# does some of the more "trivial" data types (bools, attributes, etc) is a little more efficient relating to class storage.
But...here I am going on and on, too.
It's worse for dogs from Russia, too. Now you'll be hearing all of the Dog versions of the Soviet Russia jokes!
"Kibble is Red, French Poodles are Blue,
In Soviet Russia, Testicles Lick You!"
It seems as if they're moving way too prematurely on this. In the article it said they posted to a Microsoft newsgroup and didn't receive a reply, and that this means that Microsoft will never fix the bug. Obviously there -may- be some tech support people roaming the newsgroups, but it would've made much more sense to simply contact Microsoft's technical support department and talked with someone directly about this error.
This is similar to having your car found defective, and then placing a flyer downtown to ask the company to contact you about options instead of picking up the phone and dialing the correct number.
I'm not a fan of Microsoftian ideals, but wouldn't that have made more sense before going all this way?
...and say, "Don't use that electric shaver, the magnetism will kill you!", along with the old stand-bys of other varities like: "Your eyes will stick that way one day", and don't forget "some storks dropped you off at our house one day, and that's how children are made".
The only way to make that idea any better is have Jay and Silent Bob do it from their old convenience store stomping grounds.
Actually, Intel seems decently smart about support. At least for their -paid- customers (I get an 'Access Forbidden' on their Premier support site, even though it says I should be able to get there with the free version too), there are pretty frequent minor patches that you don't notice if you just happen to check on the website once every few weeks.
It may be easy to some to patch their version of GCC for a bug they happen to hear about, but it's not a realistic expectation for most users. GCC is pretty "sluggish" on even bugfix updates, let alone noticing some of the bugs. gcc -march=athlon-tbird (and at least -march=athlon as well) can generate -really- grody incorrect code in even general situations, giving out really sub-par speed, even compared to -march=i686. The unfortunate thing being that this bug has been known about since circa 3.0.1, and hasn't been fixed by 3.3.2, and I've heard no mention of it being fixed in the 3.4 CVS branch (nor with my tests about five months ago).
Personally, I'm hoping an "alternative" compiler like TenDRA gets off the ground and can fill that void between overwhelming most-every-platform cross-compiler, and "beedy eyed" binary-only x86-optimized compiler, neither of which operates with any other particularly well.
idb 'kinda works' if you don't use the debug flags, but the main difference between gcc and icc, and gdb and idb, is that idb generally doesn't pick anything up unless you compile with debug flags explicitly, while gdb can at least give you intelligible "debugging" even without explicitly using -g. Though using icc itself doesn't usually make debugging -impossible- either, using -fomit-frame-pointer with gcc will quite horribly ruin your day if you're trying to debug those cross icc/gcc glitches.
Actually, just to note, there is (as there has been since 7.0 or so) a non-commercial version of the Linux compiler. You're not "allowed" to compile commercial stuff with it, but $0 is still cheaper than paying for 8.0 if you don't go for that sort of thing or just want to see how well it'll work with your libraries. (not to sound like an Intel saleswoman, gah)
I don't mean to be particularly critical, but how can anyone miss so many underrated classics?
Sid Meier's Covert Action comes first and foremost to mind, with it's witty "double-oh-seven" style action and puzzle-solving as one of the best but critically missed classics. Perhaps its only flaw is that it has circa-1988 graphics, but I still play it every few weeks just to see if I'm still 'on my game'.
There are also mid-range 'kinda unknown near classics', which would've been big blockbusters with just a little more marketting, or a little more polish. Games such as Syndicate, Magic Carpet, (I'm not a Bullfrog saleswoman) and Daggerfall.
Though, it seems to've missed some of the other fine more mainstream classics out there, such as Neuromancer. What about Descent? Or Descent: Freespace?
None of these were really Genre-setting benchmarks, but they all pushed the envelope for their time, and truly made you think about what games could be capable of one day. Games like these are the reason I got into game programming in the first place. They were innovative, smart, and often overlooked, as this list seems to've done.
Perhaps instead of listing three Maxis "sim" games, perhaps it should've made room for a few of these underdogs.
Are you sure it shouldn't be 'arctic sea warriors'?
I just don't know why they didn't pick FreeBSD, though. A bunch of Daemons running around with M16A2s and P90s would be a lot more fearsome to whoever the US is planning to invade next! *cough*
No offense, but...*shifty eyes darting around*
:D
Perhaps with that great idea, you should probably be nominated for the Tyrannical Overloard poll currently on Slashdot.
The US government would be proud, though I hope they don't start making us Mutants register anytime soon.
Now all you have to do is bury and compress your yard refuse and add a few million years...then FIND it, drill for it, barrel it, refine it from crude into usable gasoline, and pour it into your car. Then, drive somewhere between 15-27 miles (I hope you don't drive a Porsche or SUV), and then wash, rinse, and repeat. ^_^
Though, I hope you write this down. Slashdot archives may not be available in 15 million years (give or take), but...then again, neither probably will your car!
M-x order-quarter-pounder
I think hard-working open-source developers are often neglected, particularly for things like this, which started over adamant refusal of CVS access to someone effectively maintaining a platform.
CVS access is like giving someone the keys to the T-Bird. Everyone's excited to get it, but the parents are always terrified the kid will crash into a tree...and wreck the T-Bird (aww, don't worry, the kid will be FINE...). But CVS has this marvelous feature. You can create tags, and still quickly get around botched commits.
I work on an open-source game (I'm not going to plug it), and most of my commits revolve around a particular area, but occasionally I go over and revamp the configure.in/Makefile.am system and rip out all of the cruft. Ah, there's something nice about that efficiency, but...I could just as easily make it unusable if I made a large commit and didn't check everything first.
But that comes to my other point. You have to appreciate HOW much time each developer puts in. Some will only put in an hour every month or two, while some will simply stay and work on something, a dozen hours a day (or equivilent for their busy life), until it's done, even if small, like autoconf/automake files. Even a relatively unnoticable change from a user's perspective can have huge developer benefits, and people often forget that. Some developers will go for every last user-noticable feature, and some, perhaps like me, will often help out the other developers as much as they can, so that they can be more productive. Project leads often don't realize what a difference that makes until six months after a commit. *grins sheepishly at her 'boss'*