Are roll bars and proper 4 point safety harnesses the answer to problems with cars rolling over. I know it helps in NASCAR. I've seen cars roll over multiple times, and drivers walk away. The question is, if they can mandate 4 point safety harnesses, and special seating for babies, why can't they mandate safer seat belts for adults? If they put as much technology into the seating for the driver as they did for those babies, then i'm sure deaths would be reduced, as would the seriousness of most of the injuries.
Nope. The answer is to build vehicles with a lower center of gravity, such that they will only roll over in extreme circumstances (NASCAR is definitely an extreme circumstance, as you're not going to be driven into a wall at 180mph by a competitor in normal daily driving). As well, 4 (5, 6) point safety harnesses are used in conjunction with other (arm, head) restraints in racing usage, which is not available in your daily driver. That's one of the many reasons why racing harnesses are not DOT approved (and thus not legal for you to use when driving on public roads). I guess cars could put a full harness system in place (high seat bolsters, 4-6 point harness, arm restraints, head restraints, helmet), but it's just not necessary for daily driving. Nevermind all of the extra hardware needed to install such a system (anchoring points and such).
Roll bars are good, though I'd rather see full roll cages. And most cars with roll bars (convertibles) are woefully inadequate, such that your head is going to hit the ground before the rollbar does (look at the S2000's roll bar, or the new MX5's bar, to see what I mean). Enthusiast racing bodies like the SCCA will not allow you to race with those stock roll bars. You're going to fail the "broomstick test", which is laying a broomstick across the windshield and roll bar and seeing whether or not your helmetted head gets in the way. If it does, too bad for you. No racey.
Serves me right? Sorry, I think either I've miscommunicated myself or you're just overly zealous against all SUVs anywhere ever. I'm not contesting that a no-SUV utopia wouldn't be in a lot of ways better, especially for car drivers. However, it's also very unlikely. I think you're right that an "arms race" isn't the solution, and unfortunately that's the way we're heading. But deliberately blinding any SUV you meet makes you a dipshit and you deserve it if he hits you.
I was being extreme. I don't do that myself, but I've been on the receiving end of it from jealous people (I don't drive an SUV, but a bright and flashy sports car that has drawn ire from many folks). I'll just flip my mirror and go on with life. My point was that normal, properly installed, properly adjusted Xenon lights are not a glare problem, and if you constantly run into that it's probably for other reasons (like idiots that run with their high beams on).
Some of us need SUVs. We own a suburban because we have a large family, frequently need to move lots of cargo/ladders, and need the ability to tow trailers of various sizes
Becuase it's what we have and what we need. If all we had was a Prius, we'd never be able to move the family or cargoes, never be able to tow any of the various and sundry loads we have to tow, couldn't transport animals, and would never be able to leave our home during the winter.
I'm going to have to call BS on this. Minivans are safer and more economical for hauling a family than a body-on-frame SUV (and generally have more space even than SUVs with third-row seating). Minivans are also capable of carrying cargo like ladders, and are more efficient at doing so than most SUVs as the entire interior can be removed (some SUVs can do this, but not most). Minivans tow just as well as an SUV, for relatively light towing duties. For heavy towing requirements I'll grant that you need a truck (I'd rather have a truck than an SUV), but unless you're towing 5 days a week you're better off with an older truck that serves just as towing (and is cheap on the insurance) and using something smaller/more efficient for a daily driver. Maybe you just don't like minivans, and that's valid, but it's also one of the main reasons for the rise in SUV usage -- guys felt emasculated driving minivans to haul their kids around, so they bought big, manly SUVs. Get over yourself and get a minivan if that's the appropriate tool for the job. (Intentionally ignoring your specific plight so that I can speak generally.)
Finally, addressing your bad weather argument separately, I have to call complete and utter BS on that. The Pacific Northwest area where you live is very mild (I know, I live there as well). There's absolutely no reason why you should need a four-wheel drive vehicle in this area (maybe if you go up to the mountains for skiing, but even then you're better off with proper tires and the ability to drive in snow). I grew up in the Midwest, where winters are exponentially worse than they are here. Living on a farm, we certainly did have big 4wd trucks and tractors, but we never needed them for daily driving. We'd use a tractor to plow out our road, and then drive our normal FWD cars everywhere we needed to be. As well, during the last snow storm we had here in the Pacific Northwest two winters ago, my little mid-engine RWD sports car outdrove all of the big ol' SUVs (and the AWD Audis and Subarus) with nothing more than a set of snow tires and my Midwest-trained snow driving ability. So you need an SUV to leave the house in the winter? BS. Complete and total BS.
As one who drives a large vehicle, I've always made it my goal to drive as well as they do. I know I don't, but by most people's standards I'm a very defensive driver. I only lane-change or merge, unless forced (by, say, what must have been a half-drunk bus driver who mashe
Utter nonsense. It's not just about one's own driving skills, it's also about the skills of those around you; and you know that. It doesn't matter how good a driver you are if some fuckwad in a Prius runs a red and sideswipes you.
I'm sorry. I assumed you realized that "driving skills" includes "powers of observation". If some fuckwad in a Prius runs a red and sideswipes you (which is physically impossible -- a sideswipe happens by a car travelling parallel to you, while a T-bone happens when a car is travelling perpendicular, like a car running a red light), I'd say you're as much at fault (not in an insurance or legal sort of way) for putting yourself in that situation to begin with. But then I guess your 3500 pounds of metal (which, BTW, is about the size of a small car, as my little roadster sports car weighs just a hair under 3000 pounds and a Prius weights just under 2900 pounds. I'll assume you meant 5500 pounds, like a 4wd Suburban) just doesn't move that well. That's what I meant by active protection vs. passive. You see the Prius speeding down the road to the intersection, and you act to put yourself out of harm's way. And don't give me any crap about traffic not allowing you to move, because in that case you are at legal fault -- it's illegal to block an intersection, even one governed by a stoplight where you have the green. If you can't pass all the way through the interesection without stopping, you're legally required to wait until you can.
Mitsubishi make pens and other office equipment. Yes, that's Mitsubishi, the car company.
Mitsubishi makes much more than cars, pens, and office equipment. They are a huge conglomerate consisting of many companies in many industries. You're most likely to run into the Mitsubishi name on cars and home audio/video equipment in the US, but they do way more than just that even if you don't see the name (like Kirin beer). Mitsubishi has been around for quite a long time as well, having been a major supplier of airplanes during World War II.
Yeah, you're a selfish to drive something that protects your kids? I wonder which is more expensive, the 6 mpg you loose by driving a civic, or the 10 years of productive life you loose to back problems when you get hit in a micro-car.
Maybe not selfish, but certainly "vain, self-centered, and self-absorbed, [...] frequently nervous about their marriages, and [...] [lacking] confidence in [your] driving skills." That last part is the kicker. If you had confidence in your driving skills, you wouldn't need a tank to "protect your kids". Active protection (driving skills, braking and maneuverability, handling) is much better than passive protection (large chunks of metal), but if you must go for passive protection I'd much rather have the crumple zones of a unibody car or crossover SUV than the unyielding chassis of a frame-on-body light truck or SUV. Oh, yeah, and it's "losing", not "loosing". But then, what would you expect from an SUV driver?
While it's true that large SUVs increase fatalities with smaller cars, it seems that as adoption increases we'll eventually have mostly SUVs and be back to ground zero.
The problem is that "building a better tank" only gets you so far. That's why cars have designed crumple areas, side impact protection, and airbags. Your car is more likely to be totalled in an accident, but you're much more likely to survive because your car absorbed most of the energy. A body-on-frame style truck/SUV (like your Suburban) is pretty rigid, and isn't going to crumple much. While you may be safer in that than an old (pre-80s) sedan, you'd be much safer in a modern car design (without even getting into the fact that you've probably killed whatever you've hit). This arms race has to stop, because there will always be something bigger than you. And that's not even getting into rollover problems with larger vehicles (hint: side-curtain aribags are not a solution).
small cars are starting to put in those ridiculous halogeon neon zeon opteron laser beams, so NOBODY in the opposite lane within a hundred miles can see until the car is past.
The word you're looking for is "xenon", and I seriously doubt you're getting glare from that. Xenon lights have a much sharper cut-off, so that you're very unlikely to get glare from above he light, and manufacturers are required to adjust the lights such that they are pointing more towards the passenger side (the right in the US) to avoid blinding oncoming cars. Many cars, like mine, have a leveling system built in, so that even if I'm going over a speed bump I'm not going to blind you. Self-installed lights may not be adjusted properly, but that's a problem with any light as you can certainly be blinded by a maladjusted halogen light just as well as a Xenon.
More likely, you're just reaping the bad will towards SUVs that many car drivers harbor. Because your lights shine directly in their eyes, once you pass them many people will turn on their high beams to give you a taste of your own medicine. Serves you right, IMHO.
What is a problem is the fact that they obstruct lanes, but in my experience SUVs are far from the worst offender in that regard. I'd rather drive behind an Excursion or a Suburban than a tractor-trailer or a full-sized windowless van.
You keep bitching about semis, but you don't mention the fact that tractor trailers are relatively rare in daily traffic. Maybe you live in a major shipping hub, but for the rest of us the biggest vehicles we will encounter on our daily commutes are Suburban-sized SUVs. You're also ignoring the fact that truckers are specially trained and licensed, and in general are some of the best drivers on the road. Don't believe me? Watch all of those semis that you seem to see while driving. See how they try to keep a very large distance between themselves and the traffic in front of them? See how they always use their turn signals, and wait for a good clear patch of traffic before merging? See how they generally don't drive much beyond the speed limit? If all large SUV drivers were required to carry a CDL, our roads would be much safer (and there'd be many less SUVs, too). If you think that's too draconian, consider that you do need a special license to drive a motorcycle.
And again, as cars tend to gravitate toward the SUV model, the issue of sight obstruction will be less of an issue
Sadly, that's going the wrong direction. Sight obstruction would be better if fewer people drove SUVs, not more.
I personally am very uncomfortable in an SUV on freeways unless it has convex mirrors installed -- the the point where I will gladly add half an hour to my commute each way if I can avoid freeways. With a convex mirror though, I feel and drive much more safely.
Side note: Drum brakes are easier than discs. If you can do discs, you won't have any problem w/ drums.
While I haven't had to play with drum brakes, I could only assume they'd be more difficult to deal with given the sheer number of parts (at least according to HowStuffWorks). A disc brake system is pretty trivial, and really the only reason why drum brakes are still used is because they're cheaper (more parts, but none are as expensive as a big chunk of iron for the disc).
My truck has rear drums, so eventually I'll play with them. My car goes through pads and rotors much more quickly (mostly because I do the bulk of my driving in my car, and because I occasionally take it out to the track), so that's where I've had all of my experience.
Have you taken the time to learn how to fix every problem you might have with your car? I'm willing to bet money you know the absolute basics, at best. You can put fuel in it, check the radiator, fill the tires, change a flat, you might know how to check your fluid levels and maybe refill anything that's low. But can you rebuild the transmission? Fix the breaks? Probably not.
Now that's not fair. I could rebuild my transmission if I had the right tools, and I can certainly fix my brakes (have done so many times, if by "fix" you mean "replace pads and rotors as necessary"). I wouldn't want to tackle drum brakes, but again I could do it with the right set of tools.
However, I've played right into your example -- I learned how to do this stuff because I enjoy it. There's also the upside of price -- I can get all the parts I need for a complete brake job (minus fluid flush) for $400 and 2 hours of my time. If I were to have my dealer do it, I would be lucky to walk away at less than $1000. Then again, if I didn't enjoy doing the work, or couldn't make the time to do it, then the $1000 is less expensive to me because it frees me up to do something else that I either enjoy or must do.
By that same rationale, I agree with you. Just because you can do something, or it comes easy to you, doesn't mean that others can do it or even care that they can't. Maybe I can fix a car, but I'd be lost doing my taxes without some app like TaxCut ($30 for the app is worth it compared to figuring out the paper forms). Maybe I can code, but I wouldn't want to try cooking a gourmet meal. Maybe I can brew my own beer, but that's not going to stop me from buying a sixer at the 7-11 on my way to a party because it's convenient.
I would like to add to your third definition. A stored procedure is nothing more than a pre-parsed and pre-planned SQL command.
Slight modification: A stored procedure is nothing more than a pre-parsed and pre-planned SQL batch. You can do much more than a single command in a stored procedure. Not that you couldn't use a stored procedure for a single command, or even shouldn't. I'm a big fan of only interacting via stored procedures between my app and my database. That applies even when all I need is a "trivial" query or update.
You could program a trigger to react when an employee record goes to certain status (say, he/she is fired or quits) and change the status of this employee's records all over the database to 'immobile' or 'retired'.
Bad example. If an employee quits or is fired and you have to change status in many different places, your schema is broken. It's a decent example for a trigger, but as with most uses of triggers it's not something you should actually do. Having triggers available is important, but you need to be very selective about when you use them.
Then again, your trigger example could just be the first step in a system-wide cleanup. By mixing views and triggers, you can slowly change your underlying architecture without affecting your currently-running applications.
This update SQL is a one liner, so maybe it's not the best example, the more complex ones are better candidates.
In most cases, I'd still build a stored procedure for that one-liner. It simplifies your permissions model by allowing you to grant access only to stored procedures, and also allows you to give a user the ability to only change that status column (because that's all the stored proc does). If you were doing this with dynamic sql, you'd have to give UPDATE access on that table, and now the caller could change columns other than status. This also keeps status updates uniform across applications, where each app that needs to update a status calls this stored procedure rather than writing another UPDATE query. Also, using stored procedures helps prevent SQL injection by using typed arguments (you have to call the procedure using bound parameters rather than just passing the dynamic string '"exec sp_foo @id = " + myId', of course), and there is the minor performance benefit of compiling that statement so that the engine doesn't need to parse it every call.
In a performance - conscious application you might want to zap those triggers and instead put all the logic in stored procedures and execute them as needed.
I'd go as far as saying that in most cases you should use stored procedures rather than triggers, as the logic is more straightforward. Triggers have their place, but as I already said you should be careful about when you use them.
To answer your question, if you don't know what they are, you probably don't need them.
More accurately, if you don't what they are, you probably don't know that you need them. Or even better, if you don't know what they are, I really hope you're not supposed to be a DBA, designing and maintaining database systems.
For the record proper transactions have been around for ages, and 5.0 has largely corrected the remaining integrity problems with triggers and the Server Mode variable (options to prevent the insertion of 'bad' data).
Why oh why are not many of these new modes not on by default? For example:
STRICT_TRANS_TABLES: Why would you ever want to insert bad data? If you try to insert bad data, your insert should fail. (where "bad" is defined in several ways, such as "violates a foreign key, check, or unique constraint", or "does not match the data type, like trying to insert a bigint value into an int column.") As for rolling back transactions on such a failure, I'm indifferent. I could go either way, letting the DBMS roll back for me and immediately abort, or allow me to catch the error (have you seen SQL Server 2005's try/catch semantics? Sweet!) and rollback or continue as I choose.
ANSI_QUOTES: Double quotes (") do not define string literals in any SQL language. Don't use them as such. Use single quotes (') like you're supposed to. Double quotes are used when you need to reference a table or column that you unfortunately named the same as a reserved word, or even more unfortunately named with a space (e.g., I could have a table called "select" or "table with a space", and the only way to refer to either is by quoting). While other engines are as bad as MySQL in that they provide their own quoting characters (for example, SQL Server uses square brackets ([ and ])), they also generally allow ANSI quotes by default. So should MySQL.
ERROR_FOR_DIVISION_BY_ZERO: What? I have to enable this? If I divide by zero, something's wrong. Fail. Fail, dammit!
NO_AUTO_CREATE_USER: GRANT should never create users. GRANT grants permissions. It should not have a side effect. If you need a user created, create the user (through whatever database-specific method you must).
NO_ENGINE_SUBSTITUTION: This is another stupid mode. Why would you ever want MySQL to silently choose a different engine? If you mark your tables as InnoDB (don't even get me started about how that's not the default, and how it's stupid that you have to explicitly mark what tables you want to be transactional), chances are you meant that you really want them to be InnoDB. If InnoDB is not available, you need to fix your MySQL deployment. Otherwise, all of the work you did expecting transactions to work correctly is now out the window.
STRICT_ALL_TABLES: Goes along with STRICT_TRANS_TABLES, but why would you need two modes for this? This also goes with NO_ENGINE_SUBSTITUTION. If you set STRICT_TRANS_TABLES and mark all of your tables as InnoDB, but InnoDB is not available and you forgot to set NO_ENGINE_SUBSTITUTION, not only do you lose your transactional capabilities but you also run the risk that your inserts will not work in strict mode and thus may insert bad data. This is just stupid.
Don't get me wrong, it's nice to have these options. I just think that it's silly that some of the more important modes aren't set as the default. Thus, even though the option is there to change it, the default behavior is the same as what people have been complaining about for a long time now, and just having the option to change it is not a full fix.
And we need to stop saying "everyone is ahead of MySQL" when the only valid comparison is Postgres.
That comparison is only valid if the criteria is, "Freely available open source database engines."
Firefox seems to bypass the Activision window blocking access to the "mature" site. All you have to do is open the link in a new tab (middle-click or ctrl-click on the link).
It's just a silly onclick event handler on the link. Turn off javascript, and you're in. Right-click or middle-click and you're in (those don't register a click event). If you're into being productively lazy, write a simple Greasmonkey script that strips onclick event handlers from anchor tags on Activision sites (maybe be smarter about it and only strip those that call the checkCCCookie() method). Use a proxy to dynamically replace http://www.activision.com/cookie/js/global.js with an implementation that stubs out checkCCCookie().
This silly little check isn't going to stop anybody. So far it doesn't appear that they've implemented this half-assed check for patch downloads. If they do, they will have just shot themselves in the other foot.
Call me old fashioned, but I use databases to store information in, not to program in.
Okay, you're old fashioned. It sounds to me like you don't want a DBMS (a la Oracle, Postgres, SQL Server, MySQL *shudder*, etc), but something more along the lines of BDB -- some tuple storage system that stores your data and gives it back to you on demand. That's fine, but that has nothing to do with supposed relational (or not) database management systems. If you're not going to take advantage of the services they provide (and they do provide many, such as the previously-mentioned stored procedures and triggers, along with relational, check, default, and unique constraints for example), then you'd be better off even with just a flat file or XML-based storage system. Nothing wrong with that, but then you're not the target audience for a DBMS.
The SQL database abstraction layer is an important feature of SQLObject, that Ruby on Rails doesn't currently support -- you have to write database dependent SQL code mixed in with your Ruby code.
There's your problem -- you're mixing SQL code in with your app code. Bad developer! Bad! You're introducing SQL injection holes (I don't care how well you think you're filtering your input, chances are you missed something, especially if you're trying to do so in a DBMS-agnostic way). While an abstraction layer like SQLObject may be better in that regard because it's main focus is interfacing with SQL and thus should be more focused on catching these kinds of bugs, if it's mixing in dynamic SQL queries there's a good chance it also has SQL injection holes.
There's a reason why stored procedures are important, and it doesn't have anything to do with perceived performance increases from not having to re-parse the same SQL code every call (that's definitely a benefit, but it's minor). In this case, stored procedures shelter you from SQL injection attacks (assuming, of course, that your stored procedures aren't just dumb "take a string and 'exec' it as SQL code" queries). You may not agree with the people that tell you to use stored procedures to keep your business logic near the data, or that using stored procedures allows you to easily expose only the permissions required (GRANT EXECUTE on the stored proc, rather than having to figure out what tables need INSERT permissions, which ones need SELECT permissions, etc for each app that uses this database), but I don't see how you could argue their protection against injection. Yes, parameterized queries allow you to write dynamic SQL code with some level of injection protection, but that still leaves you with the downside of having SQL mixed into your code.
It's trivial enough to type in some Python code on the keyboard that loops over the results of a query, performs some complex logic, and validates and edits a bunch of rows in the database. Much more powerful and easier to use than anything you can do with raw SQL.
I call BS. First off, SQL is a set-based language. Very rarely do you need to loop over a result set (if you find yourself looping in SQL code, you're not thinking hard enough). Whatever "loop and operate" action you'd take with Python can be done quicker and more efficiently with SQL code than with app code. Second, for Python code to loop over a result set means it has to get that result set. If your database is not local to your web server (bad idea!), that means network I/O costs. You can and should avoid that cost by processing the data first at the SQL Server (hey, stored procedures again! Why return 100,000 rows that you're going to process down to 1,000 when you could just return the 1,000 processed rows in the first place? Why return anything at all when you're going to insert/update data based on what's in a different table?). Finally, while it may be "easier" for a developer proficient in Python and not the SQL dialect used by your chosen DBMS, that's a cop-out. As so many people are so fond of saying, you should use the right tool for the job. In this case, you're trying to use the hammer of Python to pound a screw, when you'd be better off with the screwdriver of SQL. Sure, you may be able to pound that screw into the wood, but it'd be quicker and easier to do it in SQL. Maybe you don't want to learn SQL, in which case you probably shouldn't be working with a database. You have a responsibility to learn how to use the tools you're going to apply to a problem.
I've intentionally ignored the problem of database portability, because a) you should be using stored procedures, which means you'll want to port them yourself anyway for maximum benefit, b) you should be using a proper DBI layer such that you just have to tell it, "I'm using Oracle now instead of Postgres, do the right thing", and c) because you're using stored procedures, you won't be switching to a DBMS that doesn't support the (*cough*MySQL*cough*) (and yes, I know MySQL "will" support them, but that's still some way off in non-beta form).
The do-not-call list started this way, and I have gotten no more calls.
Didn't work for me, on my landline anyway. The only way I was able to stop getting phone spam was by getting rid of my landline. I didn't need it, didn't use it, and the only calls that came in over it were spam. Now my cell phone has never been spammed by voice or text, even before the do-not-call list, so I'm happy using it exclusively as my phone service (it probably helps that I average less than an hour of phone time per month).
However, as of 4.1 most of the connectors out there can convert the truncation warning into an exception,
Wait a second. If that's a warning, it means that it went ahead and did it and warned you that it did so. If a connector translates that into an exception, how do you roll back what MySQL already did? Besides, since when is it the domain of the connection software to handle referential integrity constraints?
5.0 has server modes of varying strictness and SQL standard compliance to solve the problem.
What's the default, and why would I trust them? MySQL has already proven they don't care what you (the developer) want by doing stupid stuff like trying to set defaults when you don't want them, silently ignoring commands (like when you try to create an InnoDB table on a deployment of MySQL without InnoDB), etc. Given that, my assumption would be that the default of MySQL is not the stricter modes, and even if I did choose them they wouldn't be as strict as you would expect.
I'm hardly a MySQL fanboy, but to say it 'sucks' is probably an overstatement.
I'd call it a generous understatement, personally.
There are plenty of operations out there that don't need the features or can't justify the cost of the proprietary systems
Data and referential integrity is not a "feature", but a requirement (if it's not a requirement for you, you don't need a RDBMS). Other features may not be that important, but they're still nice to have for the one or two times you need them. PostgreSQL is free if price is a concern, and there are plenty of other free DBMSs with varying levels of functionality out there.
Which really just leaves Postgres and MySQL - kind of a wash IMHO.
Really? Postgres -- fully functional, powerful RDBMS that routinely competes with the Big Boys in terms of speed and features, but has a funky maintenance system (vacuum) and doesn't run natively on Windows. MySQL -- toy database propelled to stardom by open source fanaticism, notoriously unstable, its vaunted speed only applies to relatively small, simple datasets (let's hope you're not doing something crazy like a join!), with arrogant developers who tell their users that they don't need certain features... right up until the point that they implement the feature and then pretend they never bad mouthed it (yes, that's right, the developers did say that you didn't need row-level locking and transactions because you could do everything you need with a table lock and some programmer "smarts"). Sounds like a wash to me.
Historicaly it was a few more features & better transaction support vs. lightweight/larger community/easy to configure - but the two are rapidly converging.
In comparison to Oracle, Postgres is trivially easy to configure. It also has a very large (but not as vocal as MySQL's) community, and it's not very heavyweight. If anything, MySQL is slowly converging towards Postgres, but it's doing so in a distinctly MySQL sort of way -- deny, deny, deny right up to the point you implement the feature. Because foreign keys will make you slow!
That's retarded. The database shouldn't try to fix buggy code.
You're absolutely right. The database should fail to accept bad data. Integrity doesn't mean that the database tries to make an educated guess about what you meant (MySQL does this, and its one of the many reasons why MySQL sucks). It means that the database isn't going to let you insert data if it's not correct. Take the simple case of a foreign key. Your application may be buggy and try to insert a value into a column with a foreign key constraint that doesn't exist in the referenced table. The database should fail your insert, not try to find the closest match to the value you were asking for, or let you insert the value anyway even though it violates the constraint.
The people that defend MySQL's lack of features by saying that you can fix all of the problems in application code obviously do not know what they're doing when it comes to databases. They may truly be smart people, but as soon as they spout such nonsense you can be sure that any DBA that hears it will never take them seriously again.
Which one? I've read a couple. They're not bad. Not high literature, but fun pulp fiction. If you've ever read any D&D, Star Wars, Star Trek, etc book, these fall into the same category. Worth a quick loan from the library if you're a fan of Halo, at the very least (gives you a good amount of backstory to the Halo world that you just don't get from the games).
Is Microsoft delaying HALO 2 for the PC until it can put out this movie or is it just not planned?... I've been waiting for quite a while to play HALO 2.
Halo only made it to the PC because it had a legacy (first Mac, then PC, then Xbox) of promises and Bungie felt they should follow through on at least one of them (sorry, no Mac version). Halo 2 from the very start was designed as Xbox-exclusive. Neither Microsoft nor Bungie have ever even hinted at a PC release, and in fact have denied it on several occasions. But if you want to keep holding out hope for a PC release that's never been promised and has actively been denied, I can't stop you. You could at least wait in line for Star Wars 7 at the same time and kill two birds with one stone. In the meantime, you could just pick it up for Xbox...
I've been poking through the websites of one of the band members
Oh noes! He works for the Mircosoft! You can't download the music now! (think about it -- Seattle band, guy got a CS degree, works for a "certain large software company"...)
OpenGL is good too, but the audio support is not stellar to say the least.
You could make an even stronger argument if you understood OpenGL. It's for graphics only (OpenGL means Open Graphics Language). DirectX is an entire framework for game (or interactive media in general) development, from graphics (2D and 3D, though DirectDraw is dead) to input (DirectInput) to sound (DirectSound) to networking (DirectPlay) to streaming video (DirectShow). OpenAL (a sister project to OpenGL, conceived long after the creation of DirectX) does audio, but there's nothing else that covers the rest of what DirectX does. As such, even developers that use OpenGL, like id, will also use DirectX for other areas (back in the day, GlQuake used DirectInput for input while using OpenGL for rendering). You already mentioned SDL[1], which when coupled with OpenGL is the only really viable competitor to DirectX. What it lacks in functionality it makes up in being cross platform. Apple tried to position Quicktime to fill in the DirectX void on Mac, but that really went nowhere.
Also, OpenGL is targetted at engineering apps and is not as good for games.
That was more true years ago in DirectX's infancy. Today, OpenGL and Direct3D (DirectX's 3D rendering component) are very similar, with Direct3D moving more towards OpenGL than vice versa. As for being targetted to engineering apps, it's true that OpenGL was historically more concerned with being "correct" than "fast", but the proliferation of 3D accelerators has made that a moot point. OpenGL is perfectly viable technology for building game engines (don't believe me? Go argue with theCarmack), and Direct3D has actually become a viable technology for building engineering apps. What sets DirectX apart is everything else.
[1] For those of you too young/drunk to remember back a few years to when Loki Software was trying to make a business out of porting Windows games to Linux, you may not know that SDL was designed and developed as a way to port DirectX applications to Linux (where there is no DirectX). As such, it's no coincidence that SDL looks a lot like DirectX (to the point of even calling itself Simple DirectMedia Layer), being a suite of technologies that provide what game developers need. They did the right thing by using OpenGL for 3D rendering (in Microsoft's defense, when DirectX was created GlQuake hadn't happened yet and everybody had their own 3D rendering APIs -- Glide, Redline, etc). Even though Loki eventually went under (who would guess that gamers would rather buy the game for Windows than wait 6 months for a Linux version at full price?), SDL lived on. Yay for open source!
You are a bit off with the price calculation: 900 Euro = 1 089.99 US$ (according to google)
Yeah, I realized that not long after posting (but long after previewing, unfortunately). For some reason my eyes saw "euros" and my brain read "pounds", so that's the conversion I did. The Euro price is right about inline with direct-view CRTs in USD. I still stand by my statement that a rear projection CRT would've been the better deal at about the same price.:)
Just a quick rule of thumb.. if you can see the pixels, MOVE BACK!:-) you have either got the picture too big, or you're sitting too close!
It's a rookie mistake. People buy a projector because of its "limitless" size, and then maximize the distance between it and the screen without adjusting their normal seating position. They do the same thing with other TVs as well. Consider that the optimal seating position for a 50" TV is somewhere around 10 feet away from the screen, and then see what most people do -- they replace their old 25" CRT with a screen twice as large or larger, and then sit in the same position. Then they complain that SD content now looks like crap, even though the signal itself hasn't changed. Duh. The image would've looked just as bad if you stuck your nose up to your old 25".
also, not forgetting that the closer you're projector is to the wall, the brighter the light / contrast.
You still need a relatively dark room. And moving the projector closer to the screen negates one of the prime reasons for buying a projector in the first place:) (come on, you know everybody wants to have a 100" image!).
In the end, I bought a CRT 83cm 16:9 "flat" screen for about 900. The thing weights over 80kg, but I don't move it every day, do I? I understand that these days, such a TV is even less expensive because they're pushing Plasma and LCD screens.
For us 'merkans, that's a 32" screen at $1600 weighing over 175 pounds. Pricing is certainly local to the market, but the same TV today in America would cost around $1000 (if not less), and IMHO is not a better deal than a 50"+ CRT RPTV for a couple hundred more. To really put things in perspective, my 46" CRT RPTV I bought nearly four years ago was $2000 (plus $$$ for the stand, and $$$ for shipping, and $$$ for tax, totalling around $2700 when it was all said and done). Now you'd be hard-pressed to find a CRT RPTV below 50", and at half the price (crap, maybe it's time for an upgrade...).
Certainly there are other things to consider. Space is the biggest, as a 50" CRT-based rear-projection TV will take up considerably more space than a direct-view 32" CRT (though they'll weigh about the same). If you're in a dorm room, single-occopancy efficiency apartment, or just generally don't have the space, a smaller CRT or LCD display would be a better bet. Viewing angle is not as much of a concern with projection TVs as it used to be, but it's still something to keep in mind if you're going to have many people watching the same set at the same time.
I'll agree that LCD, plasma, and DLP just aren't up to par with CRT yet, but rear-projection CRTs are a much better deal in my book than a large direct-view CRT. That technology has advanced significantly in the past few years.
Slashdot Mirror
Nope. The answer is to build vehicles with a lower center of gravity, such that they will only roll over in extreme circumstances (NASCAR is definitely an extreme circumstance, as you're not going to be driven into a wall at 180mph by a competitor in normal daily driving). As well, 4 (5, 6) point safety harnesses are used in conjunction with other (arm, head) restraints in racing usage, which is not available in your daily driver. That's one of the many reasons why racing harnesses are not DOT approved (and thus not legal for you to use when driving on public roads). I guess cars could put a full harness system in place (high seat bolsters, 4-6 point harness, arm restraints, head restraints, helmet), but it's just not necessary for daily driving. Nevermind all of the extra hardware needed to install such a system (anchoring points and such).
Roll bars are good, though I'd rather see full roll cages. And most cars with roll bars (convertibles) are woefully inadequate, such that your head is going to hit the ground before the rollbar does (look at the S2000's roll bar, or the new MX5's bar, to see what I mean). Enthusiast racing bodies like the SCCA will not allow you to race with those stock roll bars. You're going to fail the "broomstick test", which is laying a broomstick across the windshield and roll bar and seeing whether or not your helmetted head gets in the way. If it does, too bad for you. No racey.
I was being extreme. I don't do that myself, but I've been on the receiving end of it from jealous people (I don't drive an SUV, but a bright and flashy sports car that has drawn ire from many folks). I'll just flip my mirror and go on with life. My point was that normal, properly installed, properly adjusted Xenon lights are not a glare problem, and if you constantly run into that it's probably for other reasons (like idiots that run with their high beams on).
I'm going to have to call BS on this. Minivans are safer and more economical for hauling a family than a body-on-frame SUV (and generally have more space even than SUVs with third-row seating). Minivans are also capable of carrying cargo like ladders, and are more efficient at doing so than most SUVs as the entire interior can be removed (some SUVs can do this, but not most). Minivans tow just as well as an SUV, for relatively light towing duties. For heavy towing requirements I'll grant that you need a truck (I'd rather have a truck than an SUV), but unless you're towing 5 days a week you're better off with an older truck that serves just as towing (and is cheap on the insurance) and using something smaller/more efficient for a daily driver. Maybe you just don't like minivans, and that's valid, but it's also one of the main reasons for the rise in SUV usage -- guys felt emasculated driving minivans to haul their kids around, so they bought big, manly SUVs. Get over yourself and get a minivan if that's the appropriate tool for the job. (Intentionally ignoring your specific plight so that I can speak generally.)
Finally, addressing your bad weather argument separately, I have to call complete and utter BS on that. The Pacific Northwest area where you live is very mild (I know, I live there as well). There's absolutely no reason why you should need a four-wheel drive vehicle in this area (maybe if you go up to the mountains for skiing, but even then you're better off with proper tires and the ability to drive in snow). I grew up in the Midwest, where winters are exponentially worse than they are here. Living on a farm, we certainly did have big 4wd trucks and tractors, but we never needed them for daily driving. We'd use a tractor to plow out our road, and then drive our normal FWD cars everywhere we needed to be. As well, during the last snow storm we had here in the Pacific Northwest two winters ago, my little mid-engine RWD sports car outdrove all of the big ol' SUVs (and the AWD Audis and Subarus) with nothing more than a set of snow tires and my Midwest-trained snow driving ability. So you need an SUV to leave the house in the winter? BS. Complete and total BS.
I'm sorry. I assumed you realized that "driving skills" includes "powers of observation". If some fuckwad in a Prius runs a red and sideswipes you (which is physically impossible -- a sideswipe happens by a car travelling parallel to you, while a T-bone happens when a car is travelling perpendicular, like a car running a red light), I'd say you're as much at fault (not in an insurance or legal sort of way) for putting yourself in that situation to begin with. But then I guess your 3500 pounds of metal (which, BTW, is about the size of a small car, as my little roadster sports car weighs just a hair under 3000 pounds and a Prius weights just under 2900 pounds. I'll assume you meant 5500 pounds, like a 4wd Suburban) just doesn't move that well. That's what I meant by active protection vs. passive. You see the Prius speeding down the road to the intersection, and you act to put yourself out of harm's way. And don't give me any crap about traffic not allowing you to move, because in that case you are at legal fault -- it's illegal to block an intersection, even one governed by a stoplight where you have the green. If you can't pass all the way through the interesection without stopping, you're legally required to wait until you can.
Mitsubishi makes much more than cars, pens, and office equipment. They are a huge conglomerate consisting of many companies in many industries. You're most likely to run into the Mitsubishi name on cars and home audio/video equipment in the US, but they do way more than just that even if you don't see the name (like Kirin beer). Mitsubishi has been around for quite a long time as well, having been a major supplier of airplanes during World War II.
Maybe not selfish, but certainly "vain, self-centered, and self-absorbed, [...] frequently nervous about their marriages, and [...] [lacking] confidence in [your] driving skills." That last part is the kicker. If you had confidence in your driving skills, you wouldn't need a tank to "protect your kids". Active protection (driving skills, braking and maneuverability, handling) is much better than passive protection (large chunks of metal), but if you must go for passive protection I'd much rather have the crumple zones of a unibody car or crossover SUV than the unyielding chassis of a frame-on-body light truck or SUV. Oh, yeah, and it's "losing", not "loosing". But then, what would you expect from an SUV driver?
The problem is that "building a better tank" only gets you so far. That's why cars have designed crumple areas, side impact protection, and airbags. Your car is more likely to be totalled in an accident, but you're much more likely to survive because your car absorbed most of the energy. A body-on-frame style truck/SUV (like your Suburban) is pretty rigid, and isn't going to crumple much. While you may be safer in that than an old (pre-80s) sedan, you'd be much safer in a modern car design (without even getting into the fact that you've probably killed whatever you've hit). This arms race has to stop, because there will always be something bigger than you. And that's not even getting into rollover problems with larger vehicles (hint: side-curtain aribags are not a solution).
The word you're looking for is "xenon", and I seriously doubt you're getting glare from that. Xenon lights have a much sharper cut-off, so that you're very unlikely to get glare from above he light, and manufacturers are required to adjust the lights such that they are pointing more towards the passenger side (the right in the US) to avoid blinding oncoming cars. Many cars, like mine, have a leveling system built in, so that even if I'm going over a speed bump I'm not going to blind you. Self-installed lights may not be adjusted properly, but that's a problem with any light as you can certainly be blinded by a maladjusted halogen light just as well as a Xenon.
More likely, you're just reaping the bad will towards SUVs that many car drivers harbor. Because your lights shine directly in their eyes, once you pass them many people will turn on their high beams to give you a taste of your own medicine. Serves you right, IMHO.
You keep bitching about semis, but you don't mention the fact that tractor trailers are relatively rare in daily traffic. Maybe you live in a major shipping hub, but for the rest of us the biggest vehicles we will encounter on our daily commutes are Suburban-sized SUVs. You're also ignoring the fact that truckers are specially trained and licensed, and in general are some of the best drivers on the road. Don't believe me? Watch all of those semis that you seem to see while driving. See how they try to keep a very large distance between themselves and the traffic in front of them? See how they always use their turn signals, and wait for a good clear patch of traffic before merging? See how they generally don't drive much beyond the speed limit? If all large SUV drivers were required to carry a CDL, our roads would be much safer (and there'd be many less SUVs, too). If you think that's too draconian, consider that you do need a special license to drive a motorcycle.
Sadly, that's going the wrong direction. Sight obstruction would be better if fewer people drove SUVs, not more.
While I haven't had to play with drum brakes, I could only assume they'd be more difficult to deal with given the sheer number of parts (at least according to HowStuffWorks). A disc brake system is pretty trivial, and really the only reason why drum brakes are still used is because they're cheaper (more parts, but none are as expensive as a big chunk of iron for the disc).
My truck has rear drums, so eventually I'll play with them. My car goes through pads and rotors much more quickly (mostly because I do the bulk of my driving in my car, and because I occasionally take it out to the track), so that's where I've had all of my experience.
Now that's not fair. I could rebuild my transmission if I had the right tools, and I can certainly fix my brakes (have done so many times, if by "fix" you mean "replace pads and rotors as necessary"). I wouldn't want to tackle drum brakes, but again I could do it with the right set of tools.
However, I've played right into your example -- I learned how to do this stuff because I enjoy it. There's also the upside of price -- I can get all the parts I need for a complete brake job (minus fluid flush) for $400 and 2 hours of my time. If I were to have my dealer do it, I would be lucky to walk away at less than $1000. Then again, if I didn't enjoy doing the work, or couldn't make the time to do it, then the $1000 is less expensive to me because it frees me up to do something else that I either enjoy or must do.
By that same rationale, I agree with you. Just because you can do something, or it comes easy to you, doesn't mean that others can do it or even care that they can't. Maybe I can fix a car, but I'd be lost doing my taxes without some app like TaxCut ($30 for the app is worth it compared to figuring out the paper forms). Maybe I can code, but I wouldn't want to try cooking a gourmet meal. Maybe I can brew my own beer, but that's not going to stop me from buying a sixer at the 7-11 on my way to a party because it's convenient.
Slight modification: A stored procedure is nothing more than a pre-parsed and pre-planned SQL batch . You can do much more than a single command in a stored procedure. Not that you couldn't use a stored procedure for a single command, or even shouldn't. I'm a big fan of only interacting via stored procedures between my app and my database. That applies even when all I need is a "trivial" query or update.
Bad example. If an employee quits or is fired and you have to change status in many different places, your schema is broken. It's a decent example for a trigger, but as with most uses of triggers it's not something you should actually do. Having triggers available is important, but you need to be very selective about when you use them.
Then again, your trigger example could just be the first step in a system-wide cleanup. By mixing views and triggers, you can slowly change your underlying architecture without affecting your currently-running applications.
In most cases, I'd still build a stored procedure for that one-liner. It simplifies your permissions model by allowing you to grant access only to stored procedures, and also allows you to give a user the ability to only change that status column (because that's all the stored proc does). If you were doing this with dynamic sql, you'd have to give UPDATE access on that table, and now the caller could change columns other than status. This also keeps status updates uniform across applications, where each app that needs to update a status calls this stored procedure rather than writing another UPDATE query. Also, using stored procedures helps prevent SQL injection by using typed arguments (you have to call the procedure using bound parameters rather than just passing the dynamic string '"exec sp_foo @id = " + myId', of course), and there is the minor performance benefit of compiling that statement so that the engine doesn't need to parse it every call.
I'd go as far as saying that in most cases you should use stored procedures rather than triggers, as the logic is more straightforward. Triggers have their place, but as I already said you should be careful about when you use them.
More accurately, if you don't what they are, you probably don't know that you need them. Or even better, if you don't know what they are, I really hope you're not supposed to be a DBA, designing and maintaining database systems.
Why oh why are not many of these new modes not on by default? For example:
Don't get me wrong, it's nice to have these options. I just think that it's silly that some of the more important modes aren't set as the default. Thus, even though the option is there to change it, the default behavior is the same as what people have been complaining about for a long time now, and just having the option to change it is not a full fix.
That comparison is only valid if the criteria is, "Freely available open source database engines."
It's just a silly onclick event handler on the link. Turn off javascript, and you're in. Right-click or middle-click and you're in (those don't register a click event). If you're into being productively lazy, write a simple Greasmonkey script that strips onclick event handlers from anchor tags on Activision sites (maybe be smarter about it and only strip those that call the checkCCCookie() method). Use a proxy to dynamically replace http://www.activision.com/cookie/js/global.js with an implementation that stubs out checkCCCookie().
This silly little check isn't going to stop anybody. So far it doesn't appear that they've implemented this half-assed check for patch downloads. If they do, they will have just shot themselves in the other foot.
Okay, you're old fashioned. It sounds to me like you don't want a DBMS (a la Oracle, Postgres, SQL Server, MySQL *shudder*, etc), but something more along the lines of BDB -- some tuple storage system that stores your data and gives it back to you on demand. That's fine, but that has nothing to do with supposed relational (or not) database management systems. If you're not going to take advantage of the services they provide (and they do provide many, such as the previously-mentioned stored procedures and triggers, along with relational, check, default, and unique constraints for example), then you'd be better off even with just a flat file or XML-based storage system. Nothing wrong with that, but then you're not the target audience for a DBMS.
There's your problem -- you're mixing SQL code in with your app code. Bad developer! Bad! You're introducing SQL injection holes (I don't care how well you think you're filtering your input, chances are you missed something, especially if you're trying to do so in a DBMS-agnostic way). While an abstraction layer like SQLObject may be better in that regard because it's main focus is interfacing with SQL and thus should be more focused on catching these kinds of bugs, if it's mixing in dynamic SQL queries there's a good chance it also has SQL injection holes.
There's a reason why stored procedures are important, and it doesn't have anything to do with perceived performance increases from not having to re-parse the same SQL code every call (that's definitely a benefit, but it's minor). In this case, stored procedures shelter you from SQL injection attacks (assuming, of course, that your stored procedures aren't just dumb "take a string and 'exec' it as SQL code" queries). You may not agree with the people that tell you to use stored procedures to keep your business logic near the data, or that using stored procedures allows you to easily expose only the permissions required (GRANT EXECUTE on the stored proc, rather than having to figure out what tables need INSERT permissions, which ones need SELECT permissions, etc for each app that uses this database), but I don't see how you could argue their protection against injection. Yes, parameterized queries allow you to write dynamic SQL code with some level of injection protection, but that still leaves you with the downside of having SQL mixed into your code.
I call BS. First off, SQL is a set-based language. Very rarely do you need to loop over a result set (if you find yourself looping in SQL code, you're not thinking hard enough). Whatever "loop and operate" action you'd take with Python can be done quicker and more efficiently with SQL code than with app code. Second, for Python code to loop over a result set means it has to get that result set. If your database is not local to your web server (bad idea!), that means network I/O costs. You can and should avoid that cost by processing the data first at the SQL Server (hey, stored procedures again! Why return 100,000 rows that you're going to process down to 1,000 when you could just return the 1,000 processed rows in the first place? Why return anything at all when you're going to insert/update data based on what's in a different table?). Finally, while it may be "easier" for a developer proficient in Python and not the SQL dialect used by your chosen DBMS, that's a cop-out. As so many people are so fond of saying, you should use the right tool for the job. In this case, you're trying to use the hammer of Python to pound a screw, when you'd be better off with the screwdriver of SQL. Sure, you may be able to pound that screw into the wood, but it'd be quicker and easier to do it in SQL. Maybe you don't want to learn SQL, in which case you probably shouldn't be working with a database. You have a responsibility to learn how to use the tools you're going to apply to a problem.
I've intentionally ignored the problem of database portability, because a) you should be using stored procedures, which means you'll want to port them yourself anyway for maximum benefit, b) you should be using a proper DBI layer such that you just have to tell it, "I'm using Oracle now instead of Postgres, do the right thing", and c) because you're using stored procedures, you won't be switching to a DBMS that doesn't support the (*cough*MySQL*cough*) (and yes, I know MySQL "will" support them, but that's still some way off in non-beta form).
Didn't work for me, on my landline anyway. The only way I was able to stop getting phone spam was by getting rid of my landline. I didn't need it, didn't use it, and the only calls that came in over it were spam. Now my cell phone has never been spammed by voice or text, even before the do-not-call list, so I'm happy using it exclusively as my phone service (it probably helps that I average less than an hour of phone time per month).
Wait a second. If that's a warning, it means that it went ahead and did it and warned you that it did so. If a connector translates that into an exception, how do you roll back what MySQL already did? Besides, since when is it the domain of the connection software to handle referential integrity constraints?
What's the default, and why would I trust them? MySQL has already proven they don't care what you (the developer) want by doing stupid stuff like trying to set defaults when you don't want them, silently ignoring commands (like when you try to create an InnoDB table on a deployment of MySQL without InnoDB), etc. Given that, my assumption would be that the default of MySQL is not the stricter modes, and even if I did choose them they wouldn't be as strict as you would expect.
I'd call it a generous understatement, personally.
Data and referential integrity is not a "feature", but a requirement (if it's not a requirement for you, you don't need a RDBMS). Other features may not be that important, but they're still nice to have for the one or two times you need them. PostgreSQL is free if price is a concern, and there are plenty of other free DBMSs with varying levels of functionality out there.
Really? Postgres -- fully functional, powerful RDBMS that routinely competes with the Big Boys in terms of speed and features, but has a funky maintenance system (vacuum) and doesn't run natively on Windows. MySQL -- toy database propelled to stardom by open source fanaticism, notoriously unstable, its vaunted speed only applies to relatively small, simple datasets (let's hope you're not doing something crazy like a join!), with arrogant developers who tell their users that they don't need certain features ... right up until the point that they implement the feature and then pretend they never bad mouthed it (yes, that's right, the developers did say that you didn't need row-level locking and transactions because you could do everything you need with a table lock and some programmer "smarts"). Sounds like a wash to me.
In comparison to Oracle, Postgres is trivially easy to configure. It also has a very large (but not as vocal as MySQL's) community, and it's not very heavyweight. If anything, MySQL is slowly converging towards Postgres, but it's doing so in a distinctly MySQL sort of way -- deny, deny, deny right up to the point you implement the feature. Because foreign keys will make you slow!
You're absolutely right. The database should fail to accept bad data. Integrity doesn't mean that the database tries to make an educated guess about what you meant (MySQL does this, and its one of the many reasons why MySQL sucks). It means that the database isn't going to let you insert data if it's not correct. Take the simple case of a foreign key. Your application may be buggy and try to insert a value into a column with a foreign key constraint that doesn't exist in the referenced table. The database should fail your insert, not try to find the closest match to the value you were asking for, or let you insert the value anyway even though it violates the constraint.
The people that defend MySQL's lack of features by saying that you can fix all of the problems in application code obviously do not know what they're doing when it comes to databases. They may truly be smart people, but as soon as they spout such nonsense you can be sure that any DBA that hears it will never take them seriously again.
Which one? I've read a couple. They're not bad. Not high literature, but fun pulp fiction. If you've ever read any D&D, Star Wars, Star Trek, etc book, these fall into the same category. Worth a quick loan from the library if you're a fan of Halo, at the very least (gives you a good amount of backstory to the Halo world that you just don't get from the games).
Halo only made it to the PC because it had a legacy (first Mac, then PC, then Xbox) of promises and Bungie felt they should follow through on at least one of them (sorry, no Mac version). Halo 2 from the very start was designed as Xbox-exclusive. Neither Microsoft nor Bungie have ever even hinted at a PC release, and in fact have denied it on several occasions. But if you want to keep holding out hope for a PC release that's never been promised and has actively been denied, I can't stop you. You could at least wait in line for Star Wars 7 at the same time and kill two birds with one stone. In the meantime, you could just pick it up for Xbox ...
Oh noes! He works for the Mircosoft! You can't download the music now! (think about it -- Seattle band, guy got a CS degree, works for a "certain large software company" ...)
You could make an even stronger argument if you understood OpenGL. It's for graphics only (OpenGL means Open Graphics Language). DirectX is an entire framework for game (or interactive media in general) development, from graphics (2D and 3D, though DirectDraw is dead) to input (DirectInput) to sound (DirectSound) to networking (DirectPlay) to streaming video (DirectShow). OpenAL (a sister project to OpenGL, conceived long after the creation of DirectX) does audio, but there's nothing else that covers the rest of what DirectX does. As such, even developers that use OpenGL, like id, will also use DirectX for other areas (back in the day, GlQuake used DirectInput for input while using OpenGL for rendering). You already mentioned SDL[1], which when coupled with OpenGL is the only really viable competitor to DirectX. What it lacks in functionality it makes up in being cross platform. Apple tried to position Quicktime to fill in the DirectX void on Mac, but that really went nowhere.
That was more true years ago in DirectX's infancy. Today, OpenGL and Direct3D (DirectX's 3D rendering component) are very similar, with Direct3D moving more towards OpenGL than vice versa. As for being targetted to engineering apps, it's true that OpenGL was historically more concerned with being "correct" than "fast", but the proliferation of 3D accelerators has made that a moot point. OpenGL is perfectly viable technology for building game engines (don't believe me? Go argue with theCarmack), and Direct3D has actually become a viable technology for building engineering apps. What sets DirectX apart is everything else.
[1] For those of you too young/drunk to remember back a few years to when Loki Software was trying to make a business out of porting Windows games to Linux, you may not know that SDL was designed and developed as a way to port DirectX applications to Linux (where there is no DirectX). As such, it's no coincidence that SDL looks a lot like DirectX (to the point of even calling itself Simple DirectMedia Layer), being a suite of technologies that provide what game developers need. They did the right thing by using OpenGL for 3D rendering (in Microsoft's defense, when DirectX was created GlQuake hadn't happened yet and everybody had their own 3D rendering APIs -- Glide, Redline, etc). Even though Loki eventually went under (who would guess that gamers would rather buy the game for Windows than wait 6 months for a Linux version at full price?), SDL lived on. Yay for open source!
Yeah, I realized that not long after posting (but long after previewing, unfortunately). For some reason my eyes saw "euros" and my brain read "pounds", so that's the conversion I did. The Euro price is right about inline with direct-view CRTs in USD. I still stand by my statement that a rear projection CRT would've been the better deal at about the same price. :)
It's a rookie mistake. People buy a projector because of its "limitless" size, and then maximize the distance between it and the screen without adjusting their normal seating position. They do the same thing with other TVs as well. Consider that the optimal seating position for a 50" TV is somewhere around 10 feet away from the screen, and then see what most people do -- they replace their old 25" CRT with a screen twice as large or larger, and then sit in the same position. Then they complain that SD content now looks like crap, even though the signal itself hasn't changed. Duh. The image would've looked just as bad if you stuck your nose up to your old 25".
You still need a relatively dark room. And moving the projector closer to the screen negates one of the prime reasons for buying a projector in the first place :) (come on, you know everybody wants to have a 100" image!).
For us 'merkans, that's a 32" screen at $1600 weighing over 175 pounds. Pricing is certainly local to the market, but the same TV today in America would cost around $1000 (if not less), and IMHO is not a better deal than a 50"+ CRT RPTV for a couple hundred more. To really put things in perspective, my 46" CRT RPTV I bought nearly four years ago was $2000 (plus $$$ for the stand, and $$$ for shipping, and $$$ for tax, totalling around $2700 when it was all said and done). Now you'd be hard-pressed to find a CRT RPTV below 50", and at half the price (crap, maybe it's time for an upgrade ...).
Certainly there are other things to consider. Space is the biggest, as a 50" CRT-based rear-projection TV will take up considerably more space than a direct-view 32" CRT (though they'll weigh about the same). If you're in a dorm room, single-occopancy efficiency apartment, or just generally don't have the space, a smaller CRT or LCD display would be a better bet. Viewing angle is not as much of a concern with projection TVs as it used to be, but it's still something to keep in mind if you're going to have many people watching the same set at the same time.
I'll agree that LCD, plasma, and DLP just aren't up to par with CRT yet, but rear-projection CRTs are a much better deal in my book than a large direct-view CRT. That technology has advanced significantly in the past few years.