What is sad about Windows is how dependent it is on old technology (read: DOS)
Didn't you get the memo? DOS is dead. No, really this time. Windows NT is not DOS. Windows 2000 is Windows NT. Windows XP is Windows NT. Windows 2003 is Windows NT. Longhorn as well will be Windows NT. None of those have anything to do with DOS. Do you perhaps mean that Microsoft is still using DOS's command.com-style batch scripting and console interface? (cmd.exe is not DOS, but it emulates the interface passingly well.) That's set to change. Unless you're still using Windows 98 or ME (both of which have been end-of-lifed), you are no longer using DOS when you use Windows.
Someone else should come in and write a layer that gives the junior guys them what they need.
Think longer-term. Someone else certainly should come in and write a layer that gives the junior guys what they need, but that person should also take to educating the junior guys at the same time. How else will the junior devs become non-junior devs if they're not given the opportunity to learn and grow, and make mistakes? Besides, in the long run, it'll be horribly inefficient to have to push all database access through a single person. Get a good system in place, write queries and such that are needed right now, and then start teaching the junior devs, perhaps by pair programming with them, or code reviewing with them, or giving talks or short classes on best practices.
I actually miss them in my current job with mySQL. I used to like the way you could run a stored proc every X period to copy "live" data to "public" areas. Or, archive "public" data after "x" period of time. But then again, I am a micro$oft developer at heart, and all this Perl, CGI, Java, (even COBOL) on old RS6000 systems gives me a headache sometimes
You miss stored procedures because you can use them to fake replication? Ugh. I can think of any number of other reasons to miss stored procedures, but your example isn't one of them. Any good database will have replication support built-in, so you don't have to fake it with scheduled jobs.
One thing superid asks is In addition, you either have to have a dedicated T-SQL or PL/SQL coder who then is the weak link in your coding chain,. Like I mentioned above most developers can't write good/efficient SQL, so as long as your hired properly then your PL/SQL developer shouldn't be the weak link. (But don't get me started on hiring practices, most interviews are a joke and rarely ask difficult technical questions even for senior positions.)
Also, it's possible for a T-SQL or PL/SQL coder to also be proficient in another language. It's good to have an expert on the team, but unless your project is almost pure database, the best expert will be someone who's also proficient in your main application language (java, C/C++, C#, php, perl). Your expert doesn't have to be a weak link, but not having one is certainly a detriment.
It's harder to write stored procedures than it is to write code in a managed language like Java or C# (thirty-line SELECT statements are not very intuitive).
This depends solely on your own discipline. I've seen quite a bit of horrible T-SQL code, but in 90% of the cases the worst part about it was not the logic. That could be followed, somewhat. It was the formatting. In the same way that you wouldn't write C code all on a single line (even though you could), you shouldn't do that with SQL code, either. And yet, it still happens all the time. Which is easier to read:
select fb.foo,fb.bar,fz.baz,fx.xyzzy,fr.froboz,u.unf,p.po o from foobar fb inner join foobaz fz on fb.foo = fz.foo inner join fooxyzzy fx on fb.foo = fx.foo left outer join froboz fr on fx.froboz = fr.froboz inner join unf u on fz.baz = u.baz inner join poo p on u.poo = p.poo where fb.foo = 1 and fx.xyzzy in (select xyzzy from oldxyzzy where bump = 13)
or:
select fb.foo
, fb.bar
, fz.baz
, fx.xyzzy
, fr.froboz
, u.unf
, p.poo from foobar fb
inner join foobaz fz on fb.foo = fz.foo
inner join fooxyzzy fx on fb.foo = fx.foo
left outer join froboz fr on fx.froboz = fr.froboz
inner join unf u on fz.baz = u.baz
inner join poo p on u.poo = p.poo where fb.foo = 1
and fx.xyzzy in (select xyzzy from oldxyzzy where bump = 13)
I know which one I'd rather read, and which one will more quickly make sense to me. And yet, most programmers still write their SQL code as the former, and not the latter. Nasty, nasty "programmers"!
Generally speaking, the compiler of a managed language does a better job at catching errors than a compiler for stored procedures, where a lot of the errors will be caught at runtime.
That's a deficiency of your build process, then. At work, we have our build process setup to "compile" (ie, load objects and stored procedures into a database) T-SQL code at build-time, helping us catch errors long before we get to runtime. It's not perfect, but it's quite a bit better than waiting until runtime to find our your query is broken.
Stored procedures are not portable.
Big deal. Chance are, you're not going to be writing portable SQL code in the first place if you're doing anything more advanced than simple select, insert, update, or delete.
I can't speak for PL/SQL but T-SQL is pretty simple to pick up and anyone who knows a 4th generation language should have no problems designing their own logic
While it's true that the language and syntax is not difficult to pick up, that doesn't mean you'll instantly be proficient, or understand concepts in the language. For example, and from experience, I've found that it takes most people some time (couple weeks to a couple months) to fully wrap their head around T-SQL's set-based approach. Most people come into T-SQL and immediately start writing cursors and iterative logic. While it certainly works to do things that way, it's going to be horribly slow in most cases (hey, sometimes you have to use cursors). So, the biggest hurdle is not learning the language, but learning how to think in ways the language wants.
SPs turn your database into an application server, centralizing things that needn't be, and raising load on that central machine.
When was the last time you saw the CPU sustain a high load on your database server? Database machines are constrained by I/O (disk and network) and memory, not by CPU in most cases. Therefore, your 8-way SQL box is sitting at 10% utilization. Why not get a bit more use out of it?
SPs invite use of vendor-specific features, and therefore lock-in and loss of portability.
Portability for the sake of portability is a waste of time. More importantly, given that every vendor has non-standard extensions, and the SQL definitions (SQL-92, SQL-99) don't go far enough, you'll find that you almost always need to use some vendor-specific features, whether you're writing ad-hoc queries or stored procedures. At least with stored procedures, you only have to change it in one place when you migrate, rather than changing it all over your code. Tell me, how do you add an AUTOINCREMENT/IDENTITY/auto-numbering column to a table in vendor-neutral SQL?
SPs are not typically amenable version control and are maintained outside the rest of your code base.
Says you. In my team, all of our stored procedures are stored in the same code tree as everything else, controlled by the same source control. We take it even a step further, and check in all of our database object generation code (tables, keys, indexes, triggers, etc). So, just because you don't track your stored procedures in a source control system doesn't mean it can't be done.
SPs represent "premature optimization." There may be a time and a place for SPs, but they are used a lot more than needed in many applications. For example, one application at my company has over 1,000 SPs, and quite a number are just wrappers for simple select statements.
You're assuming that the speed benefit from stored procedures typically comes from the fact that they're compiled. While that's true, it's also not much of a benefit (you might win 50-100ms per query, yay!). No, what's more important is that your queries are centralized, so that you can optimize them more easily. What's easier to optimize: A single query to <insert operation here> in a stored procedure, with the procedure called by 100 different methods; or 100 different queries to <insert operation here> across all of your code? Yeah, sure, you can centralize that as well, but what's stopping a developer from writing his own query rather than using the optimized one you've already provided for him? With stored procedures, you can deny access to individual tables and force that person to use your stored procedure.
Why would they do that? Epic and id thrive on engine sales. Licensing a game engine to other developers has become a very lucrative business, perhaps even more lucrative than selling the games themselves (would you rather have a single million-selling game, or a license fee off of a number of million-selling games?).
After all, linux don't have price by quantity (i.e. for devices where price matters is a big advantage), could be use with no x86 processors, could be tweaked for supporting better the surrounding hardware and could require a lot less hardware/memory/etc.
While I can't get to the product listings on the site at the moment, I assume that they're talking about "Windows Embedded" as the latest version of Windows CE, and not Windows XP Embedded. In that context, not all of your arguments stand up. For example, Microsoft's licensing on CE has been very relaxed. Yes, there's still a licensing fee, but it's not all that expensive anymore.
Also, CE supports several CPUs. The most popular currently seems to be ARM chips, but it also works on x86, MIPS, SH3/4, and I believe even PowerPCs. So, while you could choose to use a x86 processor, you certainly don't have to.
Finally, the code to CE has been opened up, and while I don't know the exact restrictions on redistributing binaries containing code changes to the core system, I do know that in most cases you don't need to do that at all. Windows CE (and XP Embedded) was designed in a very modular way, and you only need to include the pieces that your application needs. For example, if you want a headless, inputless embedded controller that does all I/O via network, you would include the core kernel and the networking stack, but not the input or output modules. I'm sure you can do the same thing with Linux, but since Linux wasn't designed from the ground up for embedded applications (Windows CE was), the solutions may be more "hacky".
On a side note, don't confuse Windows CE with Windows NT. The only similarities between the two are the name "Windows" and support for some subset of Win32 (which CE initially wasn't going to support at all, until the designers got smart and realized that there was no reason they couldn't support a small subset of Win32 and allow skills from the large pool of Win32 developers to carry over to the embedded space). The Windows CE kernel was designed independently of NT, and was intended to enforce real-time constraints from the very start. The OS itself really is quite elegant, and even was back in its early life, though the applications (clamshell and pocket PCs) were poor in comparison to competitors (Palm) at the time.
I'm not a huge fan of platformers, but I liked the first PoP, and I very much enjoyed Super Metroid.
You should pick up Metroid: Zero Mission and Metroid Fusion for the GBA if you liked Super Metroid. Everything that's good about Metroid (well, Fusion is a little linear in places, and seems rushed since you have actual objectives in the game, but you can still take time to explore if you like), and none of the bullshit from Metroid Prime (*cough*control scheme*cough*). It makes me sad to see that the currently-planned Nintendo DS Metroid game is using Prime's first-person perspective rather than the classic 2D play that made Metroid great.
Also, they were rumored to be thinking about making a Porsche version of the Audi TT, which is a modified VW Beetle 2.0. Try the one with Quattro and you won't believe it is a Beetle, but it is.
I haven't heard this rumor. What would Porsche gain from this? They already have a superior roadster in the Boxster, and while it would ruin the car they could easily turn it into a coupe. Porsche also isn't crazy go nuts about AWD, either, instead prefering only to use it where it's useful (ie, for stability at speed in the 911 Turbos and Carrera 4s and even then it's still balanced with the majority of the power delivery to the rear wheels, or for off-road capability in the Cayenne).
<rant>AWD is not a panacea. It's useful if you're off-roading, or perhaps to get you started moving in bad weather, but otherwise it's useless for 99% of driving conditions. Too many people put too much stock in AWD to save them, and learn the consequences first hand. For example, my light, RWD roadster outdrove all of the various different SUVs, Subarus, Audis, and such in the snowstorms in the Pacific Northwest last winter. All I did was put on proper winter tires, and that was all I needed. I fear the day when you can not longer buy a non-AWD car.</rant>
The Audi TT is a beautiful car, but it handles like a big fat pig, and the Quattro AWD system just adds more unneeded weight. If you want a roadster, you'd be better off with a Boxster, Z4, or even a Miata, unless you just want the Audi style (which I will admit is very attractive).
Anyway, I've heard rumors of a possible fifth model as a touring car in the 924/928/944/968 line, but that's only rumor (with the other four model lines being the Boxster, 911, Cayenne, and Carrera GT).
What Porsche will eventually take from Audi is the DSG double-clutch sequential manual gearbox. However, Porsche has been burned in the past by sequential manuals (several Porsche racecars in the late-70s/early-80s had experimental sequential manuals that were very fragile and actually increased lap times, so they ditched the system), so I don't expect them to pick up Audi's technology until it has been thoroughly tested in real-world applications for several more years.
Just to add another datapoint, the new Saab 9-2x is apparently a rebadged Impreza wagon.
GM has a "working relationship" with Subaru, rather than outright ownership. On another side note, the new Saab 9-3 is the same as the new Chevy Malibu. Sad what GM has done to Saab.
Which they bought for a steal from BMW after they [BMW] spent a fortune designing the new Rangie)
And BMW = Mini = Rolls Royce, which is just about the ideal spread. They've got the Mini for the young, entry-level market. The BMW cars and SUVs range anywhere from the younger market with more disposable income (the 3-series cars), to upscale mid-size cars (5-series), to affordable luxury (7-series). Rolls Royce obviously caters to the obscenely rich, which is a very desired segment of car buyers (see the recent fight for these high-end brands between BMW for Rolls, M-B for Maybach, and Audi for Bentley).
= Subaru = Holden (Australian Car Company, who recently replaced their localy built V8 with the US-sourced GenIII V8 - unfortunately)
= Opel = Hummer = Suzuki. And Holden also did the new Pontiac GTO in the US (which is little more than a re-badged Holden model with a bit of the trademark Pontiac body-cladding, though I'm not familiar enough with Holden to say what that model is...)
The CTS is NOT identical to the Chevy Impala. The CTS is built on GM's rear wheel drive Sigma platform.
Well, I knew I'd screw something up. Seriously, I knew that the CTS was rear-wheel drive, and thus a completely different platform than the Impala/Monte Carlo/Grand Prix/Regal. I just wasn't thinking about that, and instead thought, "The CTS body looks quite a bit like the Impala body, so I'll compare the two," which was dumb.
= Pontiac = Oldsmobile (dead now) = Cadillac = Saab
Chrysler = Dodge
= Mitsubishi = Mercedes-Benz
Toyota = Lexus = Scion
= Chevy = GM (well, not quite -- Toyota rebrands the Cavalier in Japan, but otherwise there's little sharing between the two companies)
Volkswagen = Audi = Porsche
And this one is wrong. Volkswagen = Audi, but not Porsche. While it's true that Dr. Ferdinand Porsche started Volkswagen, and the Pieche and Porsche families have controlling interests in both the VAG (Volkswagen Automotive Group, including Audi, Bentley, and Lamborghini) and the PAG (Porsche Automotive Group, which is just Porsche), the Porsche car company is independently owned and is not part of Volkswagen. Parts and platforms are shared (the original 356 engine was a VW, as was the engine for the 914; the Boxster and 996 share relays and other mechanical parts with VW and Audi models; the Cayenne and the Touareg are built on the same platform; etc), but the companies are not the same. In all of your other examples, the companies are partially or fully owned.
The automobile family tree runs back over itself in so many different ways. Ford owns part of Mazda, and they both produce an identical SUV... with different name badging.
And it's only getting smaller. Gone are the days of many different manufacturers (for example, the single company Audi, which is now only a part of a larger company, started life as four independent companies -- thus the four interlocked circles of the Audi badge), but even back in the early days of automotive development there was a lot of "cross-polination". For example, Dr. Ferdinand Porsche helped built a number of early cars long before he built the first Volkswagen (and even longer before the first 356). Among others, he did plenty of work for Mercedes-Benz and the German military (the Panzer Tiger was designed by Porsche). Porsche still does non-Porsche design work today, such as the engine on the Harley-Davidson V-Rod (this by the Porsche car company, and not the independent Porsche industrial design company).
That's not to say that the different badges don't bring something more to the table. I doubt you'd object that a Lexus ES500 is more luxurious than a corresponding Toyota Camry, or an Acura TSX compared to a Honda Acura. The platforms may be shared, but in many cases the "up-market" brand model will have a larger engine, better suspension (either tigher or softer, depending on the goal -- sports car or luxury car), fancier interiors (leather, woods, metals instead of plastics and vinyls), more options (navigation, sound options), etc. That's not always the case, since many Chevy and Pontiac cars are exact matches minus body cladding (Grand Prix and Monte Carlo, especially before the late-90s/early-00s body redesigns of the cars; Camaro and Firebird prior to the cancellation of the F-body line; Cavalier and Sunfire; etc), but Cadillac is GM's upscale brand, and it shows. The Cadillac CTS (not CTS-V) may be nearly identical to a Chevy Impala, but the CTS is going to be more luxuriously appointed. Perhaps not enough to justify the $10,000+ price difference, but enough to justify some increase in price.
assuming that you could even approach a real throughput of 10 gbps on 10gbps ethernet, you'd have 5 channels (with no sound).
And why would I need more than one channel at a time? Okay, I could see having two, possibly three channels at once (Tivo one, watch another, pic-in-pic a third?), but any more than that is pointless. If you were to provide such a feed, it would be trivial to provide a mechanism to choose what channel you want and only stream that channel.
... I can tie it into a cellphone JAMMER on my car, so I can detect moron drivers on phones as they come close, and jam them when they become a danger.
Because the previously inattentive driver wasn't enough a danger, now you have a confused and angered driver more concerned with why his cell phone stopped working than paying attention to the road?
CRT projection isn't going to burn-in on you if you're even the least bit aware that it can happen
I worked in a high-end consumer electronics store at one point, and given the choice between any TV set I would definitely go with a 5 lens CRT
You should be well-familiar with the shady tactics manufacturers use to sell their sets, then. Most (all) sets on display are set to "torch mode" contrast, and often have varying degrees of "red push" (the red component is stronger, because it makes the display look more vibrant, thus drawing the consumer's eye away from competing models without). Nevermind the fact that such a jacked up contrast is the main factor in burn-in, and red push just looks awful outside of a showroom. Unfortunately, the display models are exactly the same as the for-sale models, so if the set has red push and a high contrast in the store, you can bet the set you bring home will have the same.
However, you can do something about it. Get your set professionally calibrated. For a CRT-based set, you really should let it wear in for a couple hundred hours before calibration. For non-CRTs, I'm unfamiliar with the process but that site and others like Home Theater Spot can help you determine what your set needs. Frankly, I'm surprised that salespeople don't push calibration during a sale, since any competent high-end shop will have at least one ISF-certified technician on staff, and the fee is pure labor ($300 for ~4 hours of work, not too shabby). That said, for the price you're going to pay for a good set, the calibration cost is a drop in the bucket, and will really make a difference.
Finally, so long as you live in a well-controlled home (ie, no crazy dogs, children, or drunken friends), you really should consider removing the protective screen on a RPTV set. It just adds glare, and is not really a filter of any sort (they exist for protection, nothing more). You'll get a better picture without it, at the cost of a higher chance of damage. That's where the "well-controlled home" comes in. If you have people or pets that will damage the screen, leave it on. Otherwise, take it off, throw it away, and enjoy a superior picture.
the 3rd party cables aren't exactly of the highest quality....
The first-party cables aren't exactly of the highest quality, either. The GCN and PS2 cables are short, thin-gauge pieces of crap. To be fair, the cables that come with the XBox HD pack are also thin-gauge pieces of crap, but they're longer, and most importantly, they're replaceable. I don't buy Monster cables, because they're overpriced for the supposed quality, in the same way that Bose is overpriced for home theater equipment (except that at least Monster is a bit more ethical). I prefer AudioQuest's CinemaQuest cables (warning, stupidly huge and annoying Flash site), but unfortunately only Monster makes decent quality PS2 cables (don't know about GCN cables). I rarely use my PS2 so I haven't bothered, but if I ever do I'll probably end up with Monster. If you have an XBox and must buy Monster, at least buy the Microsoft HD pack and a set of standard component cables, rather than Monster's half-assed attempt at an XBox-specific cable. Too many people have had too many problems with those.
Hopefully the console manufacturers learn from Microsoft's example for the next generation and either incorporate proper outputs on the back of the box (non-proprietary YPrPb being required, with S-CART and DVI optional, ideally), or use a break-out box that lets you provide your own cabling (provide low-quality shit for people that don't care, but give those of us who do the ability to use good cables).
Still, ignoring mods for proprietary commercial games, how can a member of the general C++-speaking public create and distribute games for consoles? Sure, there's the Linux add-on for American and European PlayStation 2 consoles, but how can a homebrew developer test programs on systems such as Xbox, GameCube, or GBA, without using tools manufactured by companies that the console makers are trying to sue into oblivion?
The Linux add-on for the PS2 is pretty useless for making games, though I guess you could use it to make some simpler games. You're right, though, that developing for consoles is very inaccessible. That said, homebrew communities are out there, such as GBADev or DC Developer. Linux on the XBox has also opened up some homebrew opportunities, as well. If you want to make games, though, you don't need any of those. What you need is skill, passion, and a portfolio of devleopment (or art, or whatever), which you can certainly do on a PC. PC mods are great for building up a portfolio, but they're certainly not the only way. Think, what did people do before Doom and Quake created the game modification craze?
If you're going to quote me, quote the entire thing. What you missed:
ATI has a component dongle, but no other manufacturer does -- you'll have to get a VGA transcoder for anything else, and in either case you'll have to play with resolutions and refresh rates to get a good picture with little or no overscan
ATI has put in the work to try to setup good display resolutions on HDTVs using their dongles. Other manufacturers have not, and it's an excercise in frustration to use PowerStrip (windows) and a VGA to YPrPb transcoder to get the right resolution, refresh rate, etc to get a good picture with little or no overscan. RGBHV doesn't need a transcoder, just a different cable, but you still have to go through the same pain of setting up your resolutions.
Until it's as simple to use a HDTV with a PC as connecting the two and picking a HD resolution, I'll not be happy. Some folks may enjoy playing with modelines and such, but I'm not one of them.
Obviously many games support system link gaming. Most of the games on that list also support XBox Live. However, Halo is far and away the most popular XBox LAN party game out there.
As for sleeper games on that list, I'd definitely recommend:
Moto GP 1 and 2 (both are playable on Live, though you'll have to find a demo disk from the original Live! package to get the Moto GP Live! demo). Awesome superbike racing on real-world tracks. Also, one of the best implementations so far of Live! features such as lobbies. Only PGR2 does it better.
Deathrow. A little bit like basketball, a little bit like hockey, a little bit like lacrosse, a little bit like rugby. It's a futuristic new sport where you can win the game by scoring, or you can beat the crap out of your opponents and make them forfeit for lack of players. Warning: Excessive violence and very strong language. Still a very fun game that didn't get the love it deserved (and thus won't be getting a Live-enabled sequel, sadly).
Okay, so only two (three, but MGP1 and 2 are very similar) games on that list that are real sleepers. The rest are obviously good (depending on what you like, the Tom Clancy games, Halo, Tony Hawk, etc), or had big marketing push, or aren't that great. I definitely recommend you find Deathrow, though. It's awesome.
And is there a specific reason why you can't plug quality analog sticks into your PC?
Ha ha! You called PS2 controllers "quality". Funny.
The big problem with console games is that users can't mod them.
XBox Live is working on user-created content, but I doubt it'll ever go more than just creating logos or maps. You'll never get a TeamFortress or Counter-Strike from a console game. However, the big benefit with online console games is that users can't mod them to cheat.
Slashdot Mirror
Didn't you get the memo? DOS is dead. No, really this time. Windows NT is not DOS. Windows 2000 is Windows NT. Windows XP is Windows NT. Windows 2003 is Windows NT. Longhorn as well will be Windows NT. None of those have anything to do with DOS. Do you perhaps mean that Microsoft is still using DOS's command.com-style batch scripting and console interface? (cmd.exe is not DOS, but it emulates the interface passingly well.) That's set to change. Unless you're still using Windows 98 or ME (both of which have been end-of-lifed), you are no longer using DOS when you use Windows.
Think longer-term. Someone else certainly should come in and write a layer that gives the junior guys what they need, but that person should also take to educating the junior guys at the same time. How else will the junior devs become non-junior devs if they're not given the opportunity to learn and grow, and make mistakes? Besides, in the long run, it'll be horribly inefficient to have to push all database access through a single person. Get a good system in place, write queries and such that are needed right now, and then start teaching the junior devs, perhaps by pair programming with them, or code reviewing with them, or giving talks or short classes on best practices.
You miss stored procedures because you can use them to fake replication? Ugh. I can think of any number of other reasons to miss stored procedures, but your example isn't one of them. Any good database will have replication support built-in, so you don't have to fake it with scheduled jobs.
Also, it's possible for a T-SQL or PL/SQL coder to also be proficient in another language. It's good to have an expert on the team, but unless your project is almost pure database, the best expert will be someone who's also proficient in your main application language (java, C/C++, C#, php, perl). Your expert doesn't have to be a weak link, but not having one is certainly a detriment.
This depends solely on your own discipline. I've seen quite a bit of horrible T-SQL code, but in 90% of the cases the worst part about it was not the logic. That could be followed, somewhat. It was the formatting. In the same way that you wouldn't write C code all on a single line (even though you could), you shouldn't do that with SQL code, either. And yet, it still happens all the time. Which is easier to read:
or:I know which one I'd rather read, and which one will more quickly make sense to me. And yet, most programmers still write their SQL code as the former, and not the latter. Nasty, nasty "programmers"!That's a deficiency of your build process, then. At work, we have our build process setup to "compile" (ie, load objects and stored procedures into a database) T-SQL code at build-time, helping us catch errors long before we get to runtime. It's not perfect, but it's quite a bit better than waiting until runtime to find our your query is broken.
Big deal. Chance are, you're not going to be writing portable SQL code in the first place if you're doing anything more advanced than simple select, insert, update, or delete.
While it's true that the language and syntax is not difficult to pick up, that doesn't mean you'll instantly be proficient, or understand concepts in the language. For example, and from experience, I've found that it takes most people some time (couple weeks to a couple months) to fully wrap their head around T-SQL's set-based approach. Most people come into T-SQL and immediately start writing cursors and iterative logic. While it certainly works to do things that way, it's going to be horribly slow in most cases (hey, sometimes you have to use cursors). So, the biggest hurdle is not learning the language, but learning how to think in ways the language wants.
When was the last time you saw the CPU sustain a high load on your database server? Database machines are constrained by I/O (disk and network) and memory, not by CPU in most cases. Therefore, your 8-way SQL box is sitting at 10% utilization. Why not get a bit more use out of it?
Portability for the sake of portability is a waste of time. More importantly, given that every vendor has non-standard extensions, and the SQL definitions (SQL-92, SQL-99) don't go far enough, you'll find that you almost always need to use some vendor-specific features, whether you're writing ad-hoc queries or stored procedures. At least with stored procedures, you only have to change it in one place when you migrate, rather than changing it all over your code. Tell me, how do you add an AUTOINCREMENT/IDENTITY/auto-numbering column to a table in vendor-neutral SQL?
Says you. In my team, all of our stored procedures are stored in the same code tree as everything else, controlled by the same source control. We take it even a step further, and check in all of our database object generation code (tables, keys, indexes, triggers, etc). So, just because you don't track your stored procedures in a source control system doesn't mean it can't be done.
You're assuming that the speed benefit from stored procedures typically comes from the fact that they're compiled. While that's true, it's also not much of a benefit (you might win 50-100ms per query, yay!). No, what's more important is that your queries are centralized, so that you can optimize them more easily. What's easier to optimize: A single query to <insert operation here> in a stored procedure, with the procedure called by 100 different methods; or 100 different queries to <insert operation here> across all of your code? Yeah, sure, you can centralize that as well, but what's stopping a developer from writing his own query rather than using the optimized one you've already provided for him? With stored procedures, you can deny access to individual tables and force that person to use your stored procedure.
Well, considering that Microsoft doesn't make a product called "Windoze", it must be the former.
Huh? What's that? Oh, you were trying to be cute. Ah, I see. No, you're just a moron. Thanks.
Why would they do that? Epic and id thrive on engine sales. Licensing a game engine to other developers has become a very lucrative business, perhaps even more lucrative than selling the games themselves (would you rather have a single million-selling game, or a license fee off of a number of million-selling games?).
While I can't get to the product listings on the site at the moment, I assume that they're talking about "Windows Embedded" as the latest version of Windows CE, and not Windows XP Embedded. In that context, not all of your arguments stand up. For example, Microsoft's licensing on CE has been very relaxed. Yes, there's still a licensing fee, but it's not all that expensive anymore.
Also, CE supports several CPUs. The most popular currently seems to be ARM chips, but it also works on x86, MIPS, SH3/4, and I believe even PowerPCs. So, while you could choose to use a x86 processor, you certainly don't have to.
Finally, the code to CE has been opened up, and while I don't know the exact restrictions on redistributing binaries containing code changes to the core system, I do know that in most cases you don't need to do that at all. Windows CE (and XP Embedded) was designed in a very modular way, and you only need to include the pieces that your application needs. For example, if you want a headless, inputless embedded controller that does all I/O via network, you would include the core kernel and the networking stack, but not the input or output modules. I'm sure you can do the same thing with Linux, but since Linux wasn't designed from the ground up for embedded applications (Windows CE was), the solutions may be more "hacky".
On a side note, don't confuse Windows CE with Windows NT. The only similarities between the two are the name "Windows" and support for some subset of Win32 (which CE initially wasn't going to support at all, until the designers got smart and realized that there was no reason they couldn't support a small subset of Win32 and allow skills from the large pool of Win32 developers to carry over to the embedded space). The Windows CE kernel was designed independently of NT, and was intended to enforce real-time constraints from the very start. The OS itself really is quite elegant, and even was back in its early life, though the applications (clamshell and pocket PCs) were poor in comparison to competitors (Palm) at the time.
You should pick up Metroid: Zero Mission and Metroid Fusion for the GBA if you liked Super Metroid. Everything that's good about Metroid (well, Fusion is a little linear in places, and seems rushed since you have actual objectives in the game, but you can still take time to explore if you like), and none of the bullshit from Metroid Prime (*cough*control scheme*cough*). It makes me sad to see that the currently-planned Nintendo DS Metroid game is using Prime's first-person perspective rather than the classic 2D play that made Metroid great.
I haven't heard this rumor. What would Porsche gain from this? They already have a superior roadster in the Boxster, and while it would ruin the car they could easily turn it into a coupe. Porsche also isn't crazy go nuts about AWD, either, instead prefering only to use it where it's useful (ie, for stability at speed in the 911 Turbos and Carrera 4s and even then it's still balanced with the majority of the power delivery to the rear wheels, or for off-road capability in the Cayenne).
The Audi TT is a beautiful car, but it handles like a big fat pig, and the Quattro AWD system just adds more unneeded weight. If you want a roadster, you'd be better off with a Boxster, Z4, or even a Miata, unless you just want the Audi style (which I will admit is very attractive).
Anyway, I've heard rumors of a possible fifth model as a touring car in the 924/928/944/968 line, but that's only rumor (with the other four model lines being the Boxster, 911, Cayenne, and Carrera GT).
What Porsche will eventually take from Audi is the DSG double-clutch sequential manual gearbox. However, Porsche has been burned in the past by sequential manuals (several Porsche racecars in the late-70s/early-80s had experimental sequential manuals that were very fragile and actually increased lap times, so they ditched the system), so I don't expect them to pick up Audi's technology until it has been thoroughly tested in real-world applications for several more years.
I am the dumb! I meant "Honda Accord", of course. Stupid fingers.
GM has a "working relationship" with Subaru, rather than outright ownership. On another side note, the new Saab 9-3 is the same as the new Chevy Malibu. Sad what GM has done to Saab.
And BMW = Mini = Rolls Royce, which is just about the ideal spread. They've got the Mini for the young, entry-level market. The BMW cars and SUVs range anywhere from the younger market with more disposable income (the 3-series cars), to upscale mid-size cars (5-series), to affordable luxury (7-series). Rolls Royce obviously caters to the obscenely rich, which is a very desired segment of car buyers (see the recent fight for these high-end brands between BMW for Rolls, M-B for Maybach, and Audi for Bentley).
= Opel = Hummer = Suzuki. And Holden also did the new Pontiac GTO in the US (which is little more than a re-badged Holden model with a bit of the trademark Pontiac body-cladding, though I'm not familiar enough with Holden to say what that model is ...)
Well, I knew I'd screw something up. Seriously, I knew that the CTS was rear-wheel drive, and thus a completely different platform than the Impala/Monte Carlo/Grand Prix/Regal. I just wasn't thinking about that, and instead thought, "The CTS body looks quite a bit like the Impala body, so I'll compare the two," which was dumb.
= Mazda = Volvo = Aston Martin = Jaguar
= Pontiac = Oldsmobile (dead now) = Cadillac = Saab
= Mitsubishi = Mercedes-Benz
= Chevy = GM (well, not quite -- Toyota rebrands the Cavalier in Japan, but otherwise there's little sharing between the two companies)
And this one is wrong. Volkswagen = Audi, but not Porsche. While it's true that Dr. Ferdinand Porsche started Volkswagen, and the Pieche and Porsche families have controlling interests in both the VAG (Volkswagen Automotive Group, including Audi, Bentley, and Lamborghini) and the PAG (Porsche Automotive Group, which is just Porsche), the Porsche car company is independently owned and is not part of Volkswagen. Parts and platforms are shared (the original 356 engine was a VW, as was the engine for the 914; the Boxster and 996 share relays and other mechanical parts with VW and Audi models; the Cayenne and the Touareg are built on the same platform; etc), but the companies are not the same. In all of your other examples, the companies are partially or fully owned.
And it's only getting smaller. Gone are the days of many different manufacturers (for example, the single company Audi, which is now only a part of a larger company, started life as four independent companies -- thus the four interlocked circles of the Audi badge), but even back in the early days of automotive development there was a lot of "cross-polination". For example, Dr. Ferdinand Porsche helped built a number of early cars long before he built the first Volkswagen (and even longer before the first 356). Among others, he did plenty of work for Mercedes-Benz and the German military (the Panzer Tiger was designed by Porsche). Porsche still does non-Porsche design work today, such as the engine on the Harley-Davidson V-Rod (this by the Porsche car company, and not the independent Porsche industrial design company).
That's not to say that the different badges don't bring something more to the table. I doubt you'd object that a Lexus ES500 is more luxurious than a corresponding Toyota Camry, or an Acura TSX compared to a Honda Acura. The platforms may be shared, but in many cases the "up-market" brand model will have a larger engine, better suspension (either tigher or softer, depending on the goal -- sports car or luxury car), fancier interiors (leather, woods, metals instead of plastics and vinyls), more options (navigation, sound options), etc. That's not always the case, since many Chevy and Pontiac cars are exact matches minus body cladding (Grand Prix and Monte Carlo, especially before the late-90s/early-00s body redesigns of the cars; Camaro and Firebird prior to the cancellation of the F-body line; Cavalier and Sunfire; etc), but Cadillac is GM's upscale brand, and it shows. The Cadillac CTS (not CTS-V) may be nearly identical to a Chevy Impala, but the CTS is going to be more luxuriously appointed. Perhaps not enough to justify the $10,000+ price difference, but enough to justify some increase in price.
And why would I need more than one channel at a time? Okay, I could see having two, possibly three channels at once (Tivo one, watch another, pic-in-pic a third?), but any more than that is pointless. If you were to provide such a feed, it would be trivial to provide a mechanism to choose what channel you want and only stream that channel.
Because the previously inattentive driver wasn't enough a danger, now you have a confused and angered driver more concerned with why his cell phone stopped working than paying attention to the road?
You should be well-familiar with the shady tactics manufacturers use to sell their sets, then. Most (all) sets on display are set to "torch mode" contrast, and often have varying degrees of "red push" (the red component is stronger, because it makes the display look more vibrant, thus drawing the consumer's eye away from competing models without). Nevermind the fact that such a jacked up contrast is the main factor in burn-in, and red push just looks awful outside of a showroom. Unfortunately, the display models are exactly the same as the for-sale models, so if the set has red push and a high contrast in the store, you can bet the set you bring home will have the same.
However, you can do something about it. Get your set professionally calibrated. For a CRT-based set, you really should let it wear in for a couple hundred hours before calibration. For non-CRTs, I'm unfamiliar with the process but that site and others like Home Theater Spot can help you determine what your set needs. Frankly, I'm surprised that salespeople don't push calibration during a sale, since any competent high-end shop will have at least one ISF-certified technician on staff, and the fee is pure labor ($300 for ~4 hours of work, not too shabby). That said, for the price you're going to pay for a good set, the calibration cost is a drop in the bucket, and will really make a difference.
Finally, so long as you live in a well-controlled home (ie, no crazy dogs, children, or drunken friends), you really should consider removing the protective screen on a RPTV set. It just adds glare, and is not really a filter of any sort (they exist for protection, nothing more). You'll get a better picture without it, at the cost of a higher chance of damage. That's where the "well-controlled home" comes in. If you have people or pets that will damage the screen, leave it on. Otherwise, take it off, throw it away, and enjoy a superior picture.
The first-party cables aren't exactly of the highest quality, either. The GCN and PS2 cables are short, thin-gauge pieces of crap. To be fair, the cables that come with the XBox HD pack are also thin-gauge pieces of crap, but they're longer, and most importantly, they're replaceable. I don't buy Monster cables, because they're overpriced for the supposed quality, in the same way that Bose is overpriced for home theater equipment (except that at least Monster is a bit more ethical). I prefer AudioQuest's CinemaQuest cables (warning, stupidly huge and annoying Flash site), but unfortunately only Monster makes decent quality PS2 cables (don't know about GCN cables). I rarely use my PS2 so I haven't bothered, but if I ever do I'll probably end up with Monster. If you have an XBox and must buy Monster, at least buy the Microsoft HD pack and a set of standard component cables, rather than Monster's half-assed attempt at an XBox-specific cable. Too many people have had too many problems with those.
Hopefully the console manufacturers learn from Microsoft's example for the next generation and either incorporate proper outputs on the back of the box (non-proprietary YPrPb being required, with S-CART and DVI optional, ideally), or use a break-out box that lets you provide your own cabling (provide low-quality shit for people that don't care, but give those of us who do the ability to use good cables).
The Linux add-on for the PS2 is pretty useless for making games, though I guess you could use it to make some simpler games. You're right, though, that developing for consoles is very inaccessible. That said, homebrew communities are out there, such as GBADev or DC Developer. Linux on the XBox has also opened up some homebrew opportunities, as well. If you want to make games, though, you don't need any of those. What you need is skill, passion, and a portfolio of devleopment (or art, or whatever), which you can certainly do on a PC. PC mods are great for building up a portfolio, but they're certainly not the only way. Think, what did people do before Doom and Quake created the game modification craze?
If you're going to quote me, quote the entire thing. What you missed:
ATI has put in the work to try to setup good display resolutions on HDTVs using their dongles. Other manufacturers have not, and it's an excercise in frustration to use PowerStrip (windows) and a VGA to YPrPb transcoder to get the right resolution, refresh rate, etc to get a good picture with little or no overscan. RGBHV doesn't need a transcoder, just a different cable, but you still have to go through the same pain of setting up your resolutions.
Until it's as simple to use a HDTV with a PC as connecting the two and picking a HD resolution, I'll not be happy. Some folks may enjoy playing with modelines and such, but I'm not one of them.
Obviously many games support system link gaming. Most of the games on that list also support XBox Live. However, Halo is far and away the most popular XBox LAN party game out there.
As for sleeper games on that list, I'd definitely recommend:
Okay, so only two (three, but MGP1 and 2 are very similar) games on that list that are real sleepers. The rest are obviously good (depending on what you like, the Tom Clancy games, Halo, Tony Hawk, etc), or had big marketing push, or aren't that great. I definitely recommend you find Deathrow, though. It's awesome.
Ha ha! You called PS2 controllers "quality". Funny.
XBox Live is working on user-created content, but I doubt it'll ever go more than just creating logos or maps. You'll never get a TeamFortress or Counter-Strike from a console game. However, the big benefit with online console games is that users can't mod them to cheat.