Nintendo already have GBA base, and if it would release free SDK and make it easy to get license it will attract a lot of small/indie developers. Of cause most of this games will be crap, but by sheer numbers there bound to be some gems among them. And numer of titels have strength in itself too.
Bad idea. That type of mentality ("Flood the market with games and one or two are bound to be good") caused the video game crash in the early 80s. I'm all for homebrew games and screwing around with the hardware, and I'm sure Nintendo could come up with a good incubator program that will give independents the ability to get system information and a shot at publishing, but quality still needs to be strictly controlled.
But when you think about these quick puzzle games, what comes to mind besides tetris, that isn't a blatant tetris knock-off?
WarioWare! Okay, so it's not really a puzzle game so much as a twitch game, but the combination of 5 second games and a large number of minigames make it a perfect play for short periods of time. Pick it up if you haven't already.
The *other* successful games for handhelds were ones that didn't need to have anything saved, as the original Game Boy couldn't handle it. Imagine playing Final Fantasy I and not being able to save...
Huh? Ever hear of Final Fantasy Legend and it's sequels on the original gameboy? Saving games is not a function of the player hardware on a cartridge system, but of the cartridge itself. Battery-backed games were certainly possible in 1989 when the original GameBoy was released (NES games had been doing it for years, a la Zelda and Final Fantasy), and the GameBoy certainly didn't go backwards in that respect.
There are many original GameBoy games where you can save state (Metroid II, different Super Mario Land sequels, the afore-mentioned Final Fantasy Legend series, Zelda: Link's Awakening, Pokemon (technically a GB Color game, but the hardware was still essentially the same), etc). The most important part about being able to save on a handheld game is when you can save. Games like Final Fantasy Tactics: Advance get it right, where you can save anywhere (even during a battle). Older games like Metroid II that make you hunt down a save spot before you can quit got it wrong. The recent Mario & Luigi game got this wrong IMHO, because they only let you save at certain save points that were few and far between. At least the GBA has a sleep mode that lets you put the hardware into a battery saving mode without losing your current state. That's better than nothing, but not as good as a "save anywhere" feature.
Of course, putting a good old fun classic (like Street Fighter II) could spell success in a whole new way...
You're not really up on the portable gaming scene, are you? Street Fighter II has already been released on GBA, and a large majority of the GBA's library consists of "classic" ports from the SNES and even the Genesis (Sonic ports and such). There's no better platform for such "classic" gaming at the moment.
Seriously, though, how does someone steal a network card (much less three) so important to the operations of a major colocation center? Wouldn't the cards, oh, I don't know, be in use?? If they weren't in use, they couldn't have been that critical, could they?
You assume the thieves cared about not damaging anything. I'd expect the sequence of actions was closer to:
One more tip: If you're going to submit your own review to Slashdot, try to write a separate blurb than simply the first paragraph of your review. This is doubly important if you're submitting someone else's review and not your own. Also, if it's your own review, it's a good idea to state that in your submission.
If one of the distros wanted that kind of market, the first choice should be: Standard Workstation, or Costum configuration. Then if they picked standard, that's it, just wait until it comes time to enter a username like the XP install.
That type of setup has been available for a long, long time (I seem to recall Redhat 4.x or 5.x had that, and SuSE 5.x definitely did as well). Setup as a measurement of success is completely pointless and totally overrated. How often do you setup new machines or redeploy existing ones? If you're an IT person, then you may do it fairly often (if you're smart, you have images already set aside to do this for you). If you're a distro reviewer, you apparently do it every single day, because setup seems to be one of the main review points. If you're a normal user (power or otherwise), you might do it once every year or two, if even that often. That's a miniscule portion of a distro's usage profile, and as long as it's "good enough" then it's a solved problem.
As far as I'm concerned, setup is a solved problem for nearly every distribution of linux out there (Debian's initial installer sucked last time I used it, but I haven't had to touch it in 3+ years). Stop focusing on putting tetris and web browsers and all the other bullshit into the setup process. Nobody cares. Focus on the important stuff like a usable, consistent interface across major applications, or device compatibility and ease of use. For example, I plug my digital camera into my XP box via USB, XP automatically recognizes what it is and gives me a choice of actions I can take to extract and manipulate the images contained therein. I'm not saying Linux doesn't have that, but that's the type of stuff that Linux should be focusing on to gain more widespread desktop acceptance.
the thing is most windows installers are graphical. i could make the.bat script run the installer but i would still have to click through all the windows. i guess i could dig through my machine and figure out where the installer put each of the bazillion files it puked onto my system, but jeez what a pain.
Wrong. Most graphical installers also support a "silent" installation where you can give it the necessary parameters either on the commandline or through a config file. This is especially true if you're dealing with a MSI installer, rather than older InstallShield Setup.exe installers. Check out msiexec.
besides i'm a contractor. i'll be gone in a month and how many companies out there are using extreme programming. hopefully not very many
If using a different workstation every day is your employer's idea of XP, they're completely missing the point. Hell, you don't even need pair programming to successfully use XP. The core is a testing-first mentality and short cycles making incremental improvements and refactoring.
The bottom line for me is the cost -- $12.95/mo on top of the unit price for what? Dialing up to download a program guide & upload my preferences? Forget it.
Buy the lifetime subscription (it will pay for itself after ~2 years, if you were to pay monthly instead), and connect your TiVO to your network (wired or wireless). My TiVO hasn't been connected to a phone line for months, and I've never paid a monthly fee.
Of course, it's only been recently (within the past year or so) that my digital cable box has been able to go phone-less, and Comcast doesn't offer a PVR in my area (that I know of). The new On-Demand stuff is pretty nice, since most of the content is free and I don't have to pay for the service, but I won't give up my TiVO unless Comcast can provide something better (ie, HDTV recording with functionality on par with TiVO, or at least not much worse)
Your test is flawed. DDL (Data Definition Language) constructs generally are not transactioned in any database. That means creating a table, altering a table, dropping a table, or any other object don't care whether or not you're in a transaction. (also, I don't care for the "begin/rollback" syntax, since "begin" should be paired with "end" as block constructions similar to "{" and "}" in C/C++ while "rollback/commit" should be paired with "begin tran[saction]"). Try your test on an insert instead.
MySQL does have transaction support. My problem with it is that it's not always obvious that the transaction support is available, and even if it is you have to specifically take steps to allow your tables to work with transactions. If you don't have "type = innodb", or you do have that but your installation (or your hosting provider's installation, or your work's installation) of MySQL doesn't have innodb, you're screwed and probably don't even know it. MySQL should throw an error if you try to set a table to a type that doesn't exist in the target server, but it doesn't. That goes along with MySQL's other half-assed attempts at figuring out what you meant to do and getting it wrong rather than just throwing an error and letting you fix it properly.
Not everyone is a database elitist. Not everyone has to worry about transactions nor store procedures. Triggers are neat, but not always necessary. (Insert obligatory VHS/Beta comment here.)
You're right, not everybody has to worry about those issues, but maybe they should. However, the problem is not so much with MySQL itself (it's a good, fast, lightweight storage system for simple and small amounts of data). It's with the perception that MySQL is every bit as good as a more robust engine (Oracle, MSSQL, DB2, take your pick) for any application. That is definitely not the case. As well, knowing MySQL does not make you uniquely qualified to decide that it's better than one of the other choices for a system that needs that level of robustness. The biggest problem is that people who only know MySQL choose MySQL because that's all they know, even when it's completely unsuited to the task.
Add to that the arrogance of the MySQL developers ("These aren't the stored procedures you're looking for..."), and the zealotry of the user base, and it's easy to see why those of us who do know a thing or two are bitter about MySQL. I laugh anytime someone tells me that they can enforce data integrity from their application layer instead of using foreign keys (usually while trying to clean up their mess of a data set so the data itself can be trusted). I find it hysterical when I'm told that stored procedures are a complete waste of time (typically while fixing someone else's SQL injection problems because they insisted on writing dynamic SQL queries from their code).
I'm all for making databases and db technology more available to the Average Joe, but MySQL is not the way to do it. If you need free, there are many better alternatives to MySQL (especially if you only need free for training purposes, because then the big three are available to you as well).
Pushing the data integrity code to the app instead of asking the RDBMS to do all the heavy lifting will come to bite you in the arse when scalability becomes important.
Hell, I don't even care about scalability. How about simply being able to trust your data? I'm currently working on a database-backed project that has aboslutely no foreign key constraints at all (among other problems, though the SQL engine is not MySQL and we are slowly but surely fixing the issues). We're constantly trying to clean up our data sets (not fun when you're talking about several tens of millions of rows) and track down the offending code so we can add constraints and then handle the insert errors properly, but it's been a long and arduous process. We're actually at the point where we're willing to throw away the current system and start over (or, well, run side-by-side for a while). It's not fun.
If MySQL works for the majority of installations, so be it. You never get to be number one in your pack by following the pack. You have to innovate and do what you do really well. "Good enough" only gets you outsourced.
Very true. Let me also add for those who think that MySQL is a good learning tool -- it's not. While MySQL does support much of the ANSI standard, you're going to run into problems (some of which are MySQL's fault, some aren't):
The tricks and hacks you have to do to work around MySQL's limitations (subselects, views, stored procedures, triggers, etc) are unnecessary in a real RDBMS, but you won't know that because you only know MySQL.
More importantly, the hoops you have to jump through in MySQL often lead to suboptimal SQL code. You may not really notice this on the light data sets where MySQL excels, but you will as soon as you try to migrate this knowledge to a larger system.
MySQL gives you a false sense of performance. Your data sets are small (ideally, otherwise you're going to be in for some shit with MySQL), and so you don't care about proper indexing, whether you're doing index seeks versus table scans, whether your data is well-normalized versus normalization trade-offs for performance, etc. What performance tuning you do learn from MySQL likely won't translate well to other systems.
MySQL has its own non-ANSI syntax additions that don't apply to other RDBMSs (AUTO_INCREMENT column type, for example)
Similarly, other RDBMSs have their own set of specific keywords, so you still have to put in the time to learn them (do you know how to do an auto-incrementing column in SQL Server? MySQL won't teach you that)
If you want to learn, get yourself a real RDBMS. Microsoft's desktop engine version of SQL Server is free, and Oracle has free downloads available as well. If you don't qualify for either of those or don't agree with the licensing, at least use something more robust like PostgreSQL. If you're trying to learn, you'll be much better off learning on any of those platforms than you will with MySQL.
It has no row locking, no transaction support, and minimal cross-platform compatibility. But, it's free and it works more or less ok on Linux
Before all of the MySQL zealots jump all over you, I should point out that MySQL does have transaction support (with the proper table type, and so long as it's built in, and you're using a current enough version, and you made sure to tag your tables with the right syntax to make sure they are of the right table type, etc), and does cross-platform well enough (better than PostgreSQL, as much as I love that engine). I don't know about row-level locking, but I'm sure it can't be far now.
The biggest problem with MySQL is inconsistencies in both the engine itself and the development community. For years, the MySQL community told developers, "You don't need [transactions | foreign keys | triggers | stored procedures | subselects |...]! You can work around those limitations in your application code and be better off for it!" Only they then go and implement those features that developers "don't need". That would be fine, except that the implementation of the features often leaves something to be desired, and have too many quirks. For instance, I mentioned above that you can only get transactions and referential integrity if you're using the correct table type. However, that table type is not the default, and even if you do create your tables properly to take advantage of those features, MySQL doesn't fail if the table type is not supported, choosing instead to make your table an inferior type. Now you think you have transactional support and referential integrity because your database built just fine, but what you don't know is that your hosting provider didn't build that table type into their deployment of MySQL, and you really don't have those features at all. Good luck trying to figure out why your data is corrupted even though you had proper transactioning in your code.
MySQL has other problems as well. For example, if I want a column to be NOT NULL, I want any code that tries to insert a NULL into that column to fail. I don't want the engine to try to pick some default value for me. If I wanted a default, I would've added a default. That's why default constraints exist. By that same token, if I want a column to allow NULLs, I want to be able to put a NULL in the column. I don't want the current date/time instead of a NULL. If I define a column as auto-incrementing, I want to get an error if I try to insert something into that column. I don't want it to quietly succeed.
There's plenty more on that page, though most MySQL apologists will tell you either that the problem is fixed (which is fine, except that being fixed in the latest beta is far different from being fixed in the most widely-deployed versions from different hosting providers and such), or that it "will be in the next release". These are the same people that will tell you that stored procedures are unecessary, and anybody that thinks they are is stupid (or they'll tell you that the performance gains from being able to compile your SQL code is negligible, while completely ignoring all of the other benefits of stored procedures... *COUGH*security*COUGH*...). And so on. MySQL is fine for what it does, but it's not the end-all of SQL software. Far from it.
WORK FOR LESS. Foreigners are working for less and they end up getting the work.
try something a bit more constructive - such as finding some people to room with in a co-op so you can lower your cost of living
Now hold your breath... wait for it... here's comes the onslaught of troglodytes who'll lambast me for advocating the simplification of America's legal system. Heaven forbid we don't have the FDA to protect us from those nasty corporations!
Fixing the laws is a good thing. Your other suggestions are not always so feasible. Not everybody is a recent college graduate still acclimatized to living in a 4'x9' dorm room. Many of us have families (not me in particular, but...), and don't relish the idea of living 8 people to a 3 bedroom apartment so that we can pay $200/mo for rent and still have money left over for food. Assuming we can even get $200/mo. Many of the off-shore workers make even less than that, but the difference is that basic living requirements (food, shelter, clothing) cost relatively less. If you can meet all of your basic needs for the equivalent of $50/mo, then of course you don't mind working for $200/mo. When basic needs here run upwards of $1000-$1500/mo (depending on where you live, of course), we just can't compete on price alone.
I don't care how much less you're willing to work for, you're not going to be a more cost-effective choice than some off-shore IT worker if the only criteria is money. That's what the article poster is asking about. How do you differentiate yourself enough to make you an attractive employee in spite of the cost to keep you versus replacing you with an Indian?
Modern automobiles have gotten so reliable that people fully expect them to run for 100,000+ miles without anything more than gas, oil changes and new tires and brakes.
I know people that expect to run for 100,000+ miles without anything but gas! Some of them care enough to change their oil periodically, but I don't think they've ever considered new tires and brakes. When you consider that many people lease cars for only 2-3 years these days, they often won't even bother with oil changes. Modern engines and synthetic oils really can last 30,000+ miles without major problems for the driver (the next owner of the car is going to be in hell, though), so these leasees don't bother. Why should they spend their time and money on a car that they're going to turn in at the end of the lease?
I find it frightening that Jiffy Lube has been running advertisements reminding people that they need to change the oil in their cars. I guess people don't realize that basic maintenance is still required to keep their cars running reliably.
Maybe they should be checked every 3k miles or be gyro stablized. They are a bad solution to fixing the problem of it is dark at night.
My HID lights are auto-leveling. I would expect that all high-end cars with xenon lights from the factory are auto-leveling. It's the aftermarket pieces that cause the problem.
surprise, surprise: seems like SQL server is the odd one out.
Nope, SQL Server handles that syntax just fine. However, unlike C, the ; is unnecessary unless you're stringing multiple commands together on the same line. This is not SQL Server syntax, but ANSI SQL syntax. Most (all?) SQL developers don't bother with semicolons unless they're doing multiple commands on a single line. And since any good DB developer is not writing dynamic SQL (ie, "SELECT * from foo" from PHP, ASP, Perl, etc), but calling stored procedures through proper mechanisms (ie, not creating a dynamic query of "EXEC sp_foo param1, param2"), they typically don't bother.
This is really excessively especially true if you own a Nissan, because Nissan's manuals are super-fantastic. But it's true of any car.
The full service manuals for my car cost $2000. Also, there's no Chilton's for it, either. Now what do I do? Thankfully there's a number of very active online communities for my particular brand and model of car, so I have many good resources to work from. My car's still under warranty so I have most work done at the dealership, but I do brakes myself and may start doing oil changes, too.
Incidentally, if you're looking to start doing basic maintenance and you have a relatively modern car with disk brakes, that's an excellent place to start. If the car has drums, leave them alone (for now; drum brakes are more complicated but you can learn them). A fixed-caliper disk brake system is hilariously easy to change pads. Floating-calipers are only a touch more difficult. And perhaps most importantly, you don't need to crawl under the car to change pads, so if you don't currently own a set of jack stands you can get by without them. You'll need a torque wrench and socket (19mm seems to be the standard), though, for putting your wheels back on (find the torque specifications in your manual, but it's likely somewhere around 95-97 lb-ft or 130 N-m). Even if you don't need new pads, going through the motions and putting the old pads back in when you get to the step of putting in the new pads is still a good learning experience.
Actually an xbox targetted game would work better if it hit the hardware directly, this would improve performance by not needing the extra overhead of the directx api
Yes, but XBox games are not to the point where they have to write directly to the hardware yet. Even the most graphically advanced games (Halo2, Ninja Gaiden, etc) still use the XDK and the XBox version of DirectX. Writing directly to the hardware costs time and money on internal frameworks (or buying someone else's framework, and then tweaking it to do what you want), and most developers only go that far these days when they have to. XBox games will eventually get to the point where they have to write directly to the hardware to squeeze out every last bit of potential to stay competitive, but that's still a year or more away as I see it.
That's in contrast to Sony's approach. Because developers forsook Sony's development kit later in the life of the Playstation because it didn't provide the performance to stay competitive, they assumed that developers wouldn't want such a kit for the PS2. PS2 developers have to write their own libraries (or buy them from someone who already has), because Sony provides nothing.
DirectX is great for PC Games - but for real scientific/commercial work it *SUCKS*.
No, really? DirectX was designed explicitly for games. That means that early in its life, it sacrificed accuracy for speed (compared to OpenGL, which took the opposite approach and didn't really gain speed on consumer hardware until 3D accelerators took off). Even now, DirectX is driven by games and multimedia, not CAD and scientific/engineering requirements. There's absolutely nothing wrong with that, and in fact it's better for games that it's focused on games and multimedia rather than engineering applications, because the requirements for games are different.
If you're writing scientific software, use OpenGL. If you're writing a (Windows- or XBox-targetted) game, use DirectX.
Oh, yeah, it's also possible to use DirectX and OpenGL together. Like SDL, DirectX is an entire framework, not just a 3D rendering interface. Id and theCarmack use DirectX for input and sound while rendering their 3D visuals in OpenGL.
If a console game manages to do this, its newsworthy. You know why? Because it hasn't been done before.
That should say, "If an offline console game," because XBox Live games have been tracking stats since day one (and more recently, the stats have been available on xbox.com). The hack value in this is that it was done for a game with no network interface at all (not even a LAN interface like Mario Kart: Double Dash or Halo, which can be co-opted to be a real network interface).
Since Soul Calibur II is available on PS2, XBox, and GC and the interface differs only slightly between the versions, would this hack work with other versions of the game? Too bad there's no economical high-definition capture card, though. This hack will limit you to playing 480i via S-Video. What a waste of a beautiful game. Soul Calibur II looks great in 16x9 480p (my TV doesn't do 720p, or I'd comment on that) on the XBox, and should look nearly as good in 16x9 480p on the Gamecube as well.
(It's a flash page, so I can't link to the ingredients directly. Make up an age over 21, click on the Beer menu item, then "All About the Beer" at the bottom, then the "Making It" choice on the top left, then Ingredients.)
well, will at least be sucked up to by sales droids to open their wallets and pay for the wooden ones
Who needs fancy wood speaker cones when sales droids can already sell a set of piece of shit $2.50 paper cone speakers for $3000+? (yes, I'm talking about Bose). However, I wouldn't trash the idea that audiophiles can tell the difference between cone materials. I'm no audiophile, but I've listened to enough mid- to high-range systems that I can tell what sounds good to me and what doesn't.
If Bose systems sound good to you, and you don't mind paying 3 to 5 times more than necessary, then enjoy! My own shitty Definitive satellite system set me back less than $1000, and sounds just as good to me as a friend's $3000 Lifestyle system from Bose (both suffer from being satellite speakers rather than full-range, but at least I saved $2000 with my purchase).
Microsoft likely didn't do this but it would not surprise me at all if they did, because I've never known Bill Gates to part with any money without getting something in return
Your method (no method will, actually, except for doing what everyone else is doing) will not work when driving from Las Vegas to LA on I-15 on a sunday afternoon. It is not possible to maintain an average speed when traffic speeds up to 60 and drops to 0 as soon as you reach 60 mph, so you just try to keep the space in front of you from being too tempting... It's a fun thing to do for 90 or so miles...
I take it you didn't actually read the page I linked, did you? The 0-60-0 wave is exactly what it's referring to. You're hitting a standing wave, and then you accelerate away from it only to hit another, and then another, and then another. Rather than accelerating away like a maniac, why not speed up to a speed of 45-50mph or so, leaving 10 or so car lengths ahead of you, so that the next time you hit a wave it's eaten up by that space (depending on traffic, you may have to go slower and leave a larger gap). People like you will merge into that gap, but that's fine. Most people on the road aren't that stupid. They figure they're in for the long haul, and so they don't bother weaving through lanes like a loon. You may only be going 30-40mph but I guarantee that your trip will go faster at that speed than it will rocketing up to 60 and then braking right back down to 0 every few miles.
I'm sure I've been trolled, but I had to respond:)
Slashdot Mirror
Bad idea. That type of mentality ("Flood the market with games and one or two are bound to be good") caused the video game crash in the early 80s. I'm all for homebrew games and screwing around with the hardware, and I'm sure Nintendo could come up with a good incubator program that will give independents the ability to get system information and a shot at publishing, but quality still needs to be strictly controlled.
WarioWare! Okay, so it's not really a puzzle game so much as a twitch game, but the combination of 5 second games and a large number of minigames make it a perfect play for short periods of time. Pick it up if you haven't already.
Huh? Ever hear of Final Fantasy Legend and it's sequels on the original gameboy? Saving games is not a function of the player hardware on a cartridge system, but of the cartridge itself. Battery-backed games were certainly possible in 1989 when the original GameBoy was released (NES games had been doing it for years, a la Zelda and Final Fantasy), and the GameBoy certainly didn't go backwards in that respect.
There are many original GameBoy games where you can save state (Metroid II, different Super Mario Land sequels, the afore-mentioned Final Fantasy Legend series, Zelda: Link's Awakening, Pokemon (technically a GB Color game, but the hardware was still essentially the same), etc). The most important part about being able to save on a handheld game is when you can save. Games like Final Fantasy Tactics: Advance get it right, where you can save anywhere (even during a battle). Older games like Metroid II that make you hunt down a save spot before you can quit got it wrong. The recent Mario & Luigi game got this wrong IMHO, because they only let you save at certain save points that were few and far between. At least the GBA has a sleep mode that lets you put the hardware into a battery saving mode without losing your current state. That's better than nothing, but not as good as a "save anywhere" feature.
You're not really up on the portable gaming scene, are you? Street Fighter II has already been released on GBA, and a large majority of the GBA's library consists of "classic" ports from the SNES and even the Genesis (Sonic ports and such). There's no better platform for such "classic" gaming at the moment.
You assume the thieves cared about not damaging anything. I'd expect the sequence of actions was closer to:
Be a man! Throw that girly puff away and wash like you were meant to wash -- bare hands and a bar of soap.
One more tip: If you're going to submit your own review to Slashdot, try to write a separate blurb than simply the first paragraph of your review. This is doubly important if you're submitting someone else's review and not your own. Also, if it's your own review, it's a good idea to state that in your submission.
That type of setup has been available for a long, long time (I seem to recall Redhat 4.x or 5.x had that, and SuSE 5.x definitely did as well). Setup as a measurement of success is completely pointless and totally overrated. How often do you setup new machines or redeploy existing ones? If you're an IT person, then you may do it fairly often (if you're smart, you have images already set aside to do this for you). If you're a distro reviewer, you apparently do it every single day, because setup seems to be one of the main review points. If you're a normal user (power or otherwise), you might do it once every year or two, if even that often. That's a miniscule portion of a distro's usage profile, and as long as it's "good enough" then it's a solved problem.
As far as I'm concerned, setup is a solved problem for nearly every distribution of linux out there (Debian's initial installer sucked last time I used it, but I haven't had to touch it in 3+ years). Stop focusing on putting tetris and web browsers and all the other bullshit into the setup process. Nobody cares. Focus on the important stuff like a usable, consistent interface across major applications, or device compatibility and ease of use. For example, I plug my digital camera into my XP box via USB, XP automatically recognizes what it is and gives me a choice of actions I can take to extract and manipulate the images contained therein. I'm not saying Linux doesn't have that, but that's the type of stuff that Linux should be focusing on to gain more widespread desktop acceptance.
Wrong. Most graphical installers also support a "silent" installation where you can give it the necessary parameters either on the commandline or through a config file. This is especially true if you're dealing with a MSI installer, rather than older InstallShield Setup.exe installers. Check out msiexec.
If using a different workstation every day is your employer's idea of XP, they're completely missing the point. Hell, you don't even need pair programming to successfully use XP. The core is a testing-first mentality and short cycles making incremental improvements and refactoring.
Buy the lifetime subscription (it will pay for itself after ~2 years, if you were to pay monthly instead), and connect your TiVO to your network (wired or wireless). My TiVO hasn't been connected to a phone line for months, and I've never paid a monthly fee.
Of course, it's only been recently (within the past year or so) that my digital cable box has been able to go phone-less, and Comcast doesn't offer a PVR in my area (that I know of). The new On-Demand stuff is pretty nice, since most of the content is free and I don't have to pay for the service, but I won't give up my TiVO unless Comcast can provide something better (ie, HDTV recording with functionality on par with TiVO, or at least not much worse)
Your test is flawed. DDL (Data Definition Language) constructs generally are not transactioned in any database. That means creating a table, altering a table, dropping a table, or any other object don't care whether or not you're in a transaction. (also, I don't care for the "begin/rollback" syntax, since "begin" should be paired with "end" as block constructions similar to "{" and "}" in C/C++ while "rollback/commit" should be paired with "begin tran[saction]"). Try your test on an insert instead.
MySQL does have transaction support. My problem with it is that it's not always obvious that the transaction support is available, and even if it is you have to specifically take steps to allow your tables to work with transactions. If you don't have "type = innodb", or you do have that but your installation (or your hosting provider's installation, or your work's installation) of MySQL doesn't have innodb, you're screwed and probably don't even know it. MySQL should throw an error if you try to set a table to a type that doesn't exist in the target server, but it doesn't. That goes along with MySQL's other half-assed attempts at figuring out what you meant to do and getting it wrong rather than just throwing an error and letting you fix it properly.
You're right, not everybody has to worry about those issues, but maybe they should. However, the problem is not so much with MySQL itself (it's a good, fast, lightweight storage system for simple and small amounts of data). It's with the perception that MySQL is every bit as good as a more robust engine (Oracle, MSSQL, DB2, take your pick) for any application. That is definitely not the case. As well, knowing MySQL does not make you uniquely qualified to decide that it's better than one of the other choices for a system that needs that level of robustness. The biggest problem is that people who only know MySQL choose MySQL because that's all they know, even when it's completely unsuited to the task.
Add to that the arrogance of the MySQL developers ("These aren't the stored procedures you're looking for ..."), and the zealotry of the user base, and it's easy to see why those of us who do know a thing or two are bitter about MySQL. I laugh anytime someone tells me that they can enforce data integrity from their application layer instead of using foreign keys (usually while trying to clean up their mess of a data set so the data itself can be trusted). I find it hysterical when I'm told that stored procedures are a complete waste of time (typically while fixing someone else's SQL injection problems because they insisted on writing dynamic SQL queries from their code).
I'm all for making databases and db technology more available to the Average Joe, but MySQL is not the way to do it. If you need free, there are many better alternatives to MySQL (especially if you only need free for training purposes, because then the big three are available to you as well).
Hell, I don't even care about scalability. How about simply being able to trust your data? I'm currently working on a database-backed project that has aboslutely no foreign key constraints at all (among other problems, though the SQL engine is not MySQL and we are slowly but surely fixing the issues). We're constantly trying to clean up our data sets (not fun when you're talking about several tens of millions of rows) and track down the offending code so we can add constraints and then handle the insert errors properly, but it's been a long and arduous process. We're actually at the point where we're willing to throw away the current system and start over (or, well, run side-by-side for a while). It's not fun.
Very true. Let me also add for those who think that MySQL is a good learning tool -- it's not. While MySQL does support much of the ANSI standard, you're going to run into problems (some of which are MySQL's fault, some aren't):
If you want to learn, get yourself a real RDBMS. Microsoft's desktop engine version of SQL Server is free, and Oracle has free downloads available as well. If you don't qualify for either of those or don't agree with the licensing, at least use something more robust like PostgreSQL. If you're trying to learn, you'll be much better off learning on any of those platforms than you will with MySQL.
That's excellent! The arrogance of the MySQL developers is astounding. Do you happen to have a link with that documentation for posterity?
(Moderators, feel free to mod me down, but please mod up the anonymous parent. Thanks.)
Before all of the MySQL zealots jump all over you, I should point out that MySQL does have transaction support (with the proper table type, and so long as it's built in, and you're using a current enough version, and you made sure to tag your tables with the right syntax to make sure they are of the right table type, etc), and does cross-platform well enough (better than PostgreSQL, as much as I love that engine). I don't know about row-level locking, but I'm sure it can't be far now.
The biggest problem with MySQL is inconsistencies in both the engine itself and the development community. For years, the MySQL community told developers, "You don't need [transactions | foreign keys | triggers | stored procedures | subselects | ...]! You can work around those limitations in your application code and be better off for it!" Only they then go and implement those features that developers "don't need". That would be fine, except that the implementation of the features often leaves something to be desired, and have too many quirks. For instance, I mentioned above that you can only get transactions and referential integrity if you're using the correct table type. However, that table type is not the default, and even if you do create your tables properly to take advantage of those features, MySQL doesn't fail if the table type is not supported, choosing instead to make your table an inferior type. Now you think you have transactional support and referential integrity because your database built just fine, but what you don't know is that your hosting provider didn't build that table type into their deployment of MySQL, and you really don't have those features at all. Good luck trying to figure out why your data is corrupted even though you had proper transactioning in your code.
MySQL has other problems as well. For example, if I want a column to be NOT NULL, I want any code that tries to insert a NULL into that column to fail. I don't want the engine to try to pick some default value for me. If I wanted a default, I would've added a default. That's why default constraints exist. By that same token, if I want a column to allow NULLs, I want to be able to put a NULL in the column. I don't want the current date/time instead of a NULL. If I define a column as auto-incrementing, I want to get an error if I try to insert something into that column. I don't want it to quietly succeed.
There's plenty more on that page, though most MySQL apologists will tell you either that the problem is fixed (which is fine, except that being fixed in the latest beta is far different from being fixed in the most widely-deployed versions from different hosting providers and such), or that it "will be in the next release". These are the same people that will tell you that stored procedures are unecessary, and anybody that thinks they are is stupid (or they'll tell you that the performance gains from being able to compile your SQL code is negligible, while completely ignoring all of the other benefits of stored procedures ... *COUGH*security*COUGH* ...). And so on. MySQL is fine for what it does, but it's not the end-all of SQL software. Far from it.
Fixing the laws is a good thing. Your other suggestions are not always so feasible. Not everybody is a recent college graduate still acclimatized to living in a 4'x9' dorm room. Many of us have families (not me in particular, but ...), and don't relish the idea of living 8 people to a 3 bedroom apartment so that we can pay $200/mo for rent and still have money left over for food. Assuming we can even get $200/mo. Many of the off-shore workers make even less than that, but the difference is that basic living requirements (food, shelter, clothing) cost relatively less. If you can meet all of your basic needs for the equivalent of $50/mo, then of course you don't mind working for $200/mo. When basic needs here run upwards of $1000-$1500/mo (depending on where you live, of course), we just can't compete on price alone.
I don't care how much less you're willing to work for, you're not going to be a more cost-effective choice than some off-shore IT worker if the only criteria is money. That's what the article poster is asking about. How do you differentiate yourself enough to make you an attractive employee in spite of the cost to keep you versus replacing you with an Indian?
I know people that expect to run for 100,000+ miles without anything but gas! Some of them care enough to change their oil periodically, but I don't think they've ever considered new tires and brakes. When you consider that many people lease cars for only 2-3 years these days, they often won't even bother with oil changes. Modern engines and synthetic oils really can last 30,000+ miles without major problems for the driver (the next owner of the car is going to be in hell, though), so these leasees don't bother. Why should they spend their time and money on a car that they're going to turn in at the end of the lease?
I find it frightening that Jiffy Lube has been running advertisements reminding people that they need to change the oil in their cars. I guess people don't realize that basic maintenance is still required to keep their cars running reliably.
My HID lights are auto-leveling. I would expect that all high-end cars with xenon lights from the factory are auto-leveling. It's the aftermarket pieces that cause the problem.
Nope, SQL Server handles that syntax just fine. However, unlike C, the ; is unnecessary unless you're stringing multiple commands together on the same line. This is not SQL Server syntax, but ANSI SQL syntax. Most (all?) SQL developers don't bother with semicolons unless they're doing multiple commands on a single line. And since any good DB developer is not writing dynamic SQL (ie, "SELECT * from foo" from PHP, ASP, Perl, etc), but calling stored procedures through proper mechanisms (ie, not creating a dynamic query of "EXEC sp_foo param1, param2"), they typically don't bother.
The full service manuals for my car cost $2000. Also, there's no Chilton's for it, either. Now what do I do? Thankfully there's a number of very active online communities for my particular brand and model of car, so I have many good resources to work from. My car's still under warranty so I have most work done at the dealership, but I do brakes myself and may start doing oil changes, too.
Incidentally, if you're looking to start doing basic maintenance and you have a relatively modern car with disk brakes, that's an excellent place to start. If the car has drums, leave them alone (for now; drum brakes are more complicated but you can learn them). A fixed-caliper disk brake system is hilariously easy to change pads. Floating-calipers are only a touch more difficult. And perhaps most importantly, you don't need to crawl under the car to change pads, so if you don't currently own a set of jack stands you can get by without them. You'll need a torque wrench and socket (19mm seems to be the standard), though, for putting your wheels back on (find the torque specifications in your manual, but it's likely somewhere around 95-97 lb-ft or 130 N-m). Even if you don't need new pads, going through the motions and putting the old pads back in when you get to the step of putting in the new pads is still a good learning experience.
Yes, but XBox games are not to the point where they have to write directly to the hardware yet. Even the most graphically advanced games (Halo2, Ninja Gaiden, etc) still use the XDK and the XBox version of DirectX. Writing directly to the hardware costs time and money on internal frameworks (or buying someone else's framework, and then tweaking it to do what you want), and most developers only go that far these days when they have to. XBox games will eventually get to the point where they have to write directly to the hardware to squeeze out every last bit of potential to stay competitive, but that's still a year or more away as I see it.
That's in contrast to Sony's approach. Because developers forsook Sony's development kit later in the life of the Playstation because it didn't provide the performance to stay competitive, they assumed that developers wouldn't want such a kit for the PS2. PS2 developers have to write their own libraries (or buy them from someone who already has), because Sony provides nothing.
No, really? DirectX was designed explicitly for games. That means that early in its life, it sacrificed accuracy for speed (compared to OpenGL, which took the opposite approach and didn't really gain speed on consumer hardware until 3D accelerators took off). Even now, DirectX is driven by games and multimedia, not CAD and scientific/engineering requirements. There's absolutely nothing wrong with that, and in fact it's better for games that it's focused on games and multimedia rather than engineering applications, because the requirements for games are different.
If you're writing scientific software, use OpenGL. If you're writing a (Windows- or XBox-targetted) game, use DirectX.
Oh, yeah, it's also possible to use DirectX and OpenGL together. Like SDL, DirectX is an entire framework, not just a 3D rendering interface. Id and theCarmack use DirectX for input and sound while rendering their 3D visuals in OpenGL.
That should say, "If an offline console game," because XBox Live games have been tracking stats since day one (and more recently, the stats have been available on xbox.com). The hack value in this is that it was done for a game with no network interface at all (not even a LAN interface like Mario Kart: Double Dash or Halo, which can be co-opted to be a real network interface).
Since Soul Calibur II is available on PS2, XBox, and GC and the interface differs only slightly between the versions, would this hack work with other versions of the game? Too bad there's no economical high-definition capture card, though. This hack will limit you to playing 480i via S-Video. What a waste of a beautiful game. Soul Calibur II looks great in 16x9 480p (my TV doesn't do 720p, or I'd comment on that) on the XBox, and should look nearly as good in 16x9 480p on the Gamecube as well.
Budweiser, the king of rice beers.
(It's a flash page, so I can't link to the ingredients directly. Make up an age over 21, click on the Beer menu item, then "All About the Beer" at the bottom, then the "Making It" choice on the top left, then Ingredients.)
Who needs fancy wood speaker cones when sales droids can already sell a set of piece of shit $2.50 paper cone speakers for $3000+? (yes, I'm talking about Bose). However, I wouldn't trash the idea that audiophiles can tell the difference between cone materials. I'm no audiophile, but I've listened to enough mid- to high-range systems that I can tell what sounds good to me and what doesn't.
If Bose systems sound good to you, and you don't mind paying 3 to 5 times more than necessary, then enjoy! My own shitty Definitive satellite system set me back less than $1000, and sounds just as good to me as a friend's $3000 Lifestyle system from Bose (both suffer from being satellite speakers rather than full-range, but at least I saved $2000 with my purchase).
Really? That Bill Gates is such a bastard!
(Okay, you could make a case that donation to charity still brings some sort of return, but then isn't that the case with everything?)
I take it you didn't actually read the page I linked, did you? The 0-60-0 wave is exactly what it's referring to. You're hitting a standing wave, and then you accelerate away from it only to hit another, and then another, and then another. Rather than accelerating away like a maniac, why not speed up to a speed of 45-50mph or so, leaving 10 or so car lengths ahead of you, so that the next time you hit a wave it's eaten up by that space (depending on traffic, you may have to go slower and leave a larger gap). People like you will merge into that gap, but that's fine. Most people on the road aren't that stupid. They figure they're in for the long haul, and so they don't bother weaving through lanes like a loon. You may only be going 30-40mph but I guarantee that your trip will go faster at that speed than it will rocketing up to 60 and then braking right back down to 0 every few miles.
I'm sure I've been trolled, but I had to respond :)