Changes to the time are not random at all, they're clearly defined. Of course those definitions are periodically changed randomly with minimal notification, but that's not the same problem.
There is, in fact, something they can do: tell browser makers to consider all content to be application/xml+xhtml for a day, and let the idiots find out just how stupid they really are.
No, they can't. No browser maker (except maybe Opera) would take them seriously.
"Our current estimate for re-establishing Bing Travel functionality is 5pm PST," says a notice at Bing
When someone in a technical role screws up a timezone designation, for me that is always a red flag that they are sloppy with facts, and I need to closely watch their other decisions, actions and statements, because they may be in over their head.
It's quite likely that this message was not posted by somebody in a technical role, but a managerial role. The technical people may very well have just said "by 5:00" or possibly "by 5:00 Pacific Time", and whoever posted the notice on the web site (while the technical people were busy working on trying to fix things) added "PST" instead of "PDT".
I guess my real beef is that I see so much potential in the web platform and the reason that it doesn't advance is because two of the major players have their own competing platforms. Neither Microsoft or Apple have an incentive to make the web platform powerful. Their only motivations are to make sure that the web platform works well enough. If it becomes too powerful, their OS's become irrelevant.
Actually, Apple is sort of in a position where they want the OS to become irrelevant... because the dominant OS isn't theirs. Of course there are limits to this, but they do support cross-platform interoperability to an extent.
I understand the reasons, but I just cringe at having to keep backward compatibility. It's just really sad and depressing that over several years we can only come to a standard that is incrementally better.
Actually what happened was, the W3C was trying to push a standard that nobody wanted to follow. All the browser developers mostly ignored it, until WHATWG was formed, and HTML5 was created outside of the W3C. Finally the W3C realized WHATWG's HTML5 really was the right way to go, and they adopted HTML5 as an official W3C project.
This could have all happened years ago, but the W3C had their heads up their butts. The other significant factor was Firefox reigniting the browser wars, and making Microsoft realize that just sitting on IE6 wasn't going to be good for them.
I think once HTML5 is finalized and Microsoft builds IE9, it will become a lot easier to move forward into the future.
When fed invalid XHTML, the browser chokes, which would have gone a long way to eliminating much of the crap code, and crap "web developers" out there. I don't see why it's the browsers business to be THAT lenient, and second guess the developer all the time.
The problem is, a lot of web pages today are not a single coherent document, they're a bunch of little code fragments concatenated together (template, content, advertising, etc.). When coders get sloppy, this can result in invalid markup. When browsers choke, the content producer may have no idea how to fix the problem - it may not even be their problem.
What HTML5 tries to do is clearly define exactly how broken markup is supposed to be handled, so all browsers can try to "second guess the developer" in exactly the same way.
Kudos to Firefox for reigniting the browser war. In Browser War 2.0, all the major players are striving toward standards compliance, trying to bring their behavior in line with a single unified goal instead of adding their own proprietary features to HTML itself. Five years from now, when IE6 and IE7 are as distant a memory as IE4 and IE5 are now, web development is going to be a lot easier.
But, XHTML has corrected many wrong thing that HTML developpers used to do.
No it hasn't! Writing valid code (be it HTML 4.01, XHTML, or HTML 5) and checking it with a validator is what has corrected many wrong things that HTML developers used to do. Valid HTML 4.01 is still just as legitimate as XHTML ever was.
XHTML has some great features, notably the ability to embed MathML and SVG in it (great for academic sites) and strict error handling. Unfortunately these features never caught on because Internet Explorer doesn't understand the XHTML MIME type at all. What a shame.
I'm not familiar with the MathML and SVG features. Hopefully there's another (if less elegant) way to do what you want in HTML5.
As for strict error handling, one of the things HTML5 is doing is defining exactly how errors are supposed to be handled. This doesn't mean "strict" error handling in the sense that any page that contains an error will completely fail to load at all, but it does mean we can expect a consistent behavior across multiple browsers even when the HTML doesn't validate.
The trouble with XHTML is that many web pages today are generated from multiple sources; a single page may not really be a single coherent document, but a conglomeration of little pieces. When coders get sloppy, this results in a document that doesn't validate. If you're using XHTML with strict error handling, this can break the entire page. If you're using HTML with clearly defined but less strict error handling, it may result in some of your content not looking quite right, or the browser may be able to guess how it's supposed to work and it ends up looking just fine. This isn't an ideal world, but we don't live in an ideal world; this is what the Web has evolved into, and we need to accept that.
What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?
You're right, of course. HTML5 is an improvement over what we have today, both for documents and for applications. It's not a final solution, but it's a feasible evolution. It's not good, but it's better, and it's possible.
Yes, it will be five years before we can safely count on all of HTML5's features. However, if HTML5 wasn't in development now, then five years from now, we'd still be stuck on HTML 4.01. If we scrap HTML5 now and start designing something better, then in five years, we won't even have that.
Right now, all the major browser vendors are on board (in part because of compromises that have been made to keep them on board, including dropping the Ogg Theora requirement). They're all working toward compliance, which wasn't true a few years ago. The development of HTML5 is part of the reason why in five years we'll have an improved level of compatibility between browsers: they have a clear goal to work toward.
For years, as web developers we've had to fight with IE6, and IE7 isn't much better. IE8 doesn't completely suck though, and IE9 will be better still. Web development in five years will be a lot less painful than it is today, in part because of minor improvements in HTML5, but mostly because of the spirit of cooperative competition between browser vendors.
If you have any ideas about how HTML can be improved, in a way that won't break backwards compatibility with existing web sites, I suggest joining the WHATWG mailing list and participating in the discussion.
The history of Apple proprietary hardware which they only recently (mostly) gave up?
Oh come on. Apple started moving away from proprietary hardware in 1998, when they abandoned ADB, DB-15 video, 8-pin mini-DIN serial, and variable-speed floppy drives (although they had already stopped using the variable speed capability with the introduction of HD floppies, which is why Mac HD floppies are 1.44MB instead of the incompatible 1.6MB they could have been). They had already switched from NuBus to PCI, SCSI to IDE, and worked with IBM to develop CHRP.
But all you care about is the second time the Mac switched CPU architectures?
Even if the javascript "promised" not to use document.write() somehow, the DOM manipulations may still require redrawing the entire page, in which case the browser may still say "well, we'll wait until the javascript is done, then show the page". There's no solution to this at all, other than to tell people not to use JS to create the whole page.
You can dynamically manipulate the DOM from JavaScript without using document.write at all; for example this page I made generates the entire Search section dynamically. Notice the performance doesn't suck. If you're doing something more complicated than that with your JavaScript, then you're right, there's no solution - the browser can't guess what the results of your JS code is eventually going to be, so it will have to redraw.
All the major browsers are working on improving JS performance. Perhaps that will help.
Valid XML, all the time. Require that the tags balance, as in XHTML. This will make the document tree well-defined, which, at the moment, it is not. So all software that works on the DOM will behave consistently.
You're wrong. The document tree is well-defined in HTML 5. You don't need XML, you just need to follow the HTML spec. Of course, we can't force people to follow the spec, and the Web is currently full of non-conforming pages that include half-assed attempts at using bits and pieces of XHTML mixed with HTML. XHTML doesn't make anything better.
Errors put the browser in "dumb rendering" mode. Rather than a "best effort" approach, browsers should, upon detecting a serious error in the input, drop to "dumb mode" - default font, default colors, etc., after displaying an error message. Much of the incompatibility between browsers comes from inconsistent handling of bad HTML. So there should be a penalty, but not a fatal one, for bad code.
You're wrong. If your browser does this, users will use some other browser (regardless of whether it conforms to the HTML5 spec or not, because users don't care about that). You're right that broken code is a problem, but HTML5 addresses this by more clearly defining how broken code should be handled, so that all browsers can try to render even bad code in a consistent and compatible way.
No more upper code pages. The only valid character sets should be Unicode, or ASCII with HTML escapes. Chars above 127 in ASCII mode are to be rendered as a black dot or square. No more "Latin-1", or the pre-Unicode encodings of Han or Korean. So all pages will render in all browsers, provided only that they have some full Unicode font.
You're wrong. If you make a browser that doesn't support these other character sets, users will choose something else (see above). Of course everybody should be using UTF-8 these days, but we can't force them to.
Downloadable fonts. Netscape used to have downloadable fonts. The font makers bitched. Bring that feature back, despite the whining. No more having to express fonts as images.
WebForms. Get the WebForms proposal back on track. Any needed processing for input should be do-able without Javascript.
HTML5 includes Web Forms 2.
2D layout The "div"/"clear" model of layout was a flop. Horrors of Javascript are needed just to make columns balance. Absolute positioning is overused as a workaround for the limits of "div"/"clear". (Text on top of text happens all too often.) Tables were actually a better layout tool, because they're a 2D system. HTML needs a 2D layout model that can't accidentally result in overlaps. There are plenty of those around; most window managers have one. There's been a quiet move back to tables for layout, but people are embarrassed to admit it.
CSS layout has some problems. Balanced columns is certainly one of them (although tables certainly doesn't fix that). They're working on it, but this can be addressed by improving CSS, outside of HTML.
Better parallelism. Pages must do their initial render without "document.write()". Forcing sequentiality during initial page load should be considered an error. This will make pages load faster. Some ad code will have to be rewritten.
I'm not sure what you're talking about exactly, but this sounds like a JavaScript implementation issue and not an HTML issue at all.
In the case of Safari, it does. Safari uses QuickTime to play videos, so you can use the <video> tag with any format that QuickTime supports. If you install XiphQT, then that includes Ogg Theora (I just checked, the video here plays just fine in Safari 4 with XiphQT installed).
That's a nice theory, but the W3C has absolutely no authority to force anybody to follow their standards. None. Browser developers follow W3C standards because they want to, not because they have to. They want to, because the W3C standards give them a sensible and clearly documented behavior that other browsers are also aiming for. However, Apple has chosen not to support Ogg, and it's likely that Microsoft won't either (both companies have their own alternatives they want people to license). If the W3C makes Ogg support a part of the standard, these browser vendors will ignore the standard, and there's nothing anybody can do about it. This makes the standard less useful.
You're right, though, about needing a killer app. If a popular web site started requiring Ogg support, and offered a Firefox download link for anyone who didn't support it, other browser vendors would be more interested in adding Ogg support.
In particular, when people say that MySQL works "well enough" for what they need, I simply do not believe them. They are simply not counting the amount of time they've wasted on data integrity issues over the years, because they just don't know better that with a superior RDBMS, those problems could be solved from day one.
But I haven't had issues with data integrity. No, I don't have a large database. I simply don't have that much data. If I did, and I had enough users accessing the data that data integrity ever became an issue, then yeah, of course I would want to fix it. That would be a compelling reason to switch, certainly. But my future projects aren't likely to be much bigger than my previous projects, and MySQL has performed well enough in the past that I expect it to work in the future too.
Does anyone even use mySQL when they have features like this? The only issue I have ever had with this DB was when I was trying to connect a.net app to it and it took me a while to find a workaround.
Because I don't need features like this, and don't know how to use them. At least, as far as I know, I don't need features like this. Since I don't know how to use them, it doesn't really matter, does it?
MySQL is what I've been running for several years; I'm familiar with the software. I use DBD::mysql in my Perl scripts; I'm sure most things would work fine if I simply switched to DBD::Pg, but would any queries need to be changed? I have no idea. Of course I'd need to migrate my data from MySQL to PostgreSQL; I'm not even sure of the "correct" way to migrate data from one installation of MySQL to another (copying the data files and then fixing whatever's broken usually works well enough). Of course, I'm running a few PHP-based webapps that currently use MySQL; I don't know if it's possible to get them to work with PostgreSQL or not (switching database engines in PHP isn't as simple as it is in Perl).
I could take the time to do the research and find answers to these questions. Or I could keep using what I know works just fine. Maybe someday I'll have some compelling need to try PostgreSQL and see if switching is practical. Today is not that day.
I, too, was planning to buy this. Now, I'm going to wait until someone comes up with a hacked pirated version that works on a LAN somehow, and just copy that. Not because I'm angry with them or anything, but because it sounds like that will be the easiest way to get the game to work the way I want (easier to copy the hacked version from somebody else, than to patch my own legal copy). If they won't sell me what I want, I won't buy what they won't sell me.
I was planning to buy it (like I bought Warcraft II and Starcraft and Warcraft III), but now I'll just wait until there's a cracked pirated version that can play on a LAN somehow, and just copy that from somebody. I have no interest in playing on BattleNet.
Uh, ok, sure, if your friends weren't in the same room, you had to futz with modems. I do have a couple friends who live in another state, that I wouldn't mind playing with over BattleNet. Mostly, though, I want to play on a LAN, without needing a high speed Internet connection. That's how I played Warcraft II a decade ago.
You're an idiot. That wasn't an opinion. It was a statement of fact. It may be wrong (I don't care), but just because something is wrong doesn't mean it's an opinion.
Slashdot Mirror
I'd rather have them look stuff up on Wikipedia than not do any research at all, I suppose. At least they'll be right some of the time.
Changes to the time are not random at all, they're clearly defined. Of course those definitions are periodically changed randomly with minimal notification, but that's not the same problem.
Slashdot's idea of "plain text" differs from that of any rational human. The option you're looking for is labeled "extrans".
There is, in fact, something they can do: tell browser makers to consider all content to be application/xml+xhtml for a day, and let the idiots find out just how stupid they really are.
No, they can't. No browser maker (except maybe Opera) would take them seriously.
Not really sure what you are complaining about... PST == Pacific Standard Time. I don't see anything wrong with this.
And that's exactly why these kinds of mistakes are made.
Seattle is currently on PDT (GMT -0700), not PST (GMT -0800). The switch back to PST happens in November.
"Our current estimate for re-establishing Bing Travel functionality is 5pm PST," says a notice at Bing
When someone in a technical role screws up a timezone designation, for me that is always a red flag that they are sloppy with facts, and I need to closely watch their other decisions, actions and statements, because they may be in over their head.
It's quite likely that this message was not posted by somebody in a technical role, but a managerial role. The technical people may very well have just said "by 5:00" or possibly "by 5:00 Pacific Time", and whoever posted the notice on the web site (while the technical people were busy working on trying to fix things) added "PST" instead of "PDT".
I guess my real beef is that I see so much potential in the web platform and the reason that it doesn't advance is because two of the major players have their own competing platforms. Neither Microsoft or Apple have an incentive to make the web platform powerful. Their only motivations are to make sure that the web platform works well enough. If it becomes too powerful, their OS's become irrelevant.
Actually, Apple is sort of in a position where they want the OS to become irrelevant... because the dominant OS isn't theirs. Of course there are limits to this, but they do support cross-platform interoperability to an extent.
I understand the reasons, but I just cringe at having to keep backward compatibility. It's just really sad and depressing that over several years we can only come to a standard that is incrementally better.
Actually what happened was, the W3C was trying to push a standard that nobody wanted to follow. All the browser developers mostly ignored it, until WHATWG was formed, and HTML5 was created outside of the W3C. Finally the W3C realized WHATWG's HTML5 really was the right way to go, and they adopted HTML5 as an official W3C project.
This could have all happened years ago, but the W3C had their heads up their butts. The other significant factor was Firefox reigniting the browser wars, and making Microsoft realize that just sitting on IE6 wasn't going to be good for them.
I think once HTML5 is finalized and Microsoft builds IE9, it will become a lot easier to move forward into the future.
That's an interesting version of history. It's not all true, but it's interesting.
Which parts aren't, and what really happened?
XHTML would have been great standard.
When fed invalid XHTML, the browser chokes, which would have gone a long way to eliminating much of the crap code, and crap "web developers" out there.
I don't see why it's the browsers business to be THAT lenient, and second guess the developer all the time.
The problem is, a lot of web pages today are not a single coherent document, they're a bunch of little code fragments concatenated together (template, content, advertising, etc.). When coders get sloppy, this can result in invalid markup. When browsers choke, the content producer may have no idea how to fix the problem - it may not even be their problem.
What HTML5 tries to do is clearly define exactly how broken markup is supposed to be handled, so all browsers can try to "second guess the developer" in exactly the same way.
Kudos to Firefox for reigniting the browser war. In Browser War 2.0, all the major players are striving toward standards compliance, trying to bring their behavior in line with a single unified goal instead of adding their own proprietary features to HTML itself. Five years from now, when IE6 and IE7 are as distant a memory as IE4 and IE5 are now, web development is going to be a lot easier.
But, XHTML has corrected many wrong thing that HTML developpers used to do.
No it hasn't! Writing valid code (be it HTML 4.01, XHTML, or HTML 5) and checking it with a validator is what has corrected many wrong things that HTML developers used to do. Valid HTML 4.01 is still just as legitimate as XHTML ever was.
XHTML has some great features, notably the ability to embed MathML and SVG in it (great for academic sites) and strict error handling. Unfortunately these features never caught on because Internet Explorer doesn't understand the XHTML MIME type at all. What a shame.
I'm not familiar with the MathML and SVG features. Hopefully there's another (if less elegant) way to do what you want in HTML5.
As for strict error handling, one of the things HTML5 is doing is defining exactly how errors are supposed to be handled. This doesn't mean "strict" error handling in the sense that any page that contains an error will completely fail to load at all, but it does mean we can expect a consistent behavior across multiple browsers even when the HTML doesn't validate.
The trouble with XHTML is that many web pages today are generated from multiple sources; a single page may not really be a single coherent document, but a conglomeration of little pieces. When coders get sloppy, this results in a document that doesn't validate. If you're using XHTML with strict error handling, this can break the entire page. If you're using HTML with clearly defined but less strict error handling, it may result in some of your content not looking quite right, or the browser may be able to guess how it's supposed to work and it ends up looking just fine. This isn't an ideal world, but we don't live in an ideal world; this is what the Web has evolved into, and we need to accept that.
What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?
You're right, of course. HTML5 is an improvement over what we have today, both for documents and for applications. It's not a final solution, but it's a feasible evolution. It's not good, but it's better, and it's possible.
Yes, it will be five years before we can safely count on all of HTML5's features. However, if HTML5 wasn't in development now, then five years from now, we'd still be stuck on HTML 4.01. If we scrap HTML5 now and start designing something better, then in five years, we won't even have that.
Right now, all the major browser vendors are on board (in part because of compromises that have been made to keep them on board, including dropping the Ogg Theora requirement). They're all working toward compliance, which wasn't true a few years ago. The development of HTML5 is part of the reason why in five years we'll have an improved level of compatibility between browsers: they have a clear goal to work toward.
For years, as web developers we've had to fight with IE6, and IE7 isn't much better. IE8 doesn't completely suck though, and IE9 will be better still. Web development in five years will be a lot less painful than it is today, in part because of minor improvements in HTML5, but mostly because of the spirit of cooperative competition between browser vendors.
If you have any ideas about how HTML can be improved, in a way that won't break backwards compatibility with existing web sites, I suggest joining the WHATWG mailing list and participating in the discussion.
The history of Apple proprietary hardware which they only recently (mostly) gave up?
Oh come on. Apple started moving away from proprietary hardware in 1998, when they abandoned ADB, DB-15 video, 8-pin mini-DIN serial, and variable-speed floppy drives (although they had already stopped using the variable speed capability with the introduction of HD floppies, which is why Mac HD floppies are 1.44MB instead of the incompatible 1.6MB they could have been). They had already switched from NuBus to PCI, SCSI to IDE, and worked with IBM to develop CHRP.
But all you care about is the second time the Mac switched CPU architectures?
They fixed that, by the way.
Even if the javascript "promised" not to use document.write() somehow, the DOM manipulations may still require redrawing the entire page, in which case the browser may still say "well, we'll wait until the javascript is done, then show the page". There's no solution to this at all, other than to tell people not to use JS to create the whole page.
You can dynamically manipulate the DOM from JavaScript without using document.write at all; for example this page I made generates the entire Search section dynamically. Notice the performance doesn't suck. If you're doing something more complicated than that with your JavaScript, then you're right, there's no solution - the browser can't guess what the results of your JS code is eventually going to be, so it will have to redraw.
All the major browsers are working on improving JS performance. Perhaps that will help.
Valid XML, all the time. Require that the tags balance, as in XHTML. This will make the document tree well-defined, which, at the moment, it is not. So all software that works on the DOM will behave consistently.
You're wrong. The document tree is well-defined in HTML 5. You don't need XML, you just need to follow the HTML spec. Of course, we can't force people to follow the spec, and the Web is currently full of non-conforming pages that include half-assed attempts at using bits and pieces of XHTML mixed with HTML. XHTML doesn't make anything better.
Errors put the browser in "dumb rendering" mode. Rather than a "best effort" approach, browsers should, upon detecting a serious error in the input, drop to "dumb mode" - default font, default colors, etc., after displaying an error message. Much of the incompatibility between browsers comes from inconsistent handling of bad HTML. So there should be a penalty, but not a fatal one, for bad code.
You're wrong. If your browser does this, users will use some other browser (regardless of whether it conforms to the HTML5 spec or not, because users don't care about that). You're right that broken code is a problem, but HTML5 addresses this by more clearly defining how broken code should be handled, so that all browsers can try to render even bad code in a consistent and compatible way.
No more upper code pages. The only valid character sets should be Unicode, or ASCII with HTML escapes. Chars above 127 in ASCII mode are to be rendered as a black dot or square. No more "Latin-1", or the pre-Unicode encodings of Han or Korean. So all pages will render in all browsers, provided only that they have some full Unicode font.
You're wrong. If you make a browser that doesn't support these other character sets, users will choose something else (see above). Of course everybody should be using UTF-8 these days, but we can't force them to.
Downloadable fonts. Netscape used to have downloadable fonts. The font makers bitched. Bring that feature back, despite the whining. No more having to express fonts as images.
It's back, but in CSS, not HTML.
WebForms. Get the WebForms proposal back on track. Any needed processing for input should be do-able without Javascript.
HTML5 includes Web Forms 2.
2D layout The "div"/"clear" model of layout was a flop. Horrors of Javascript are needed just to make columns balance. Absolute positioning is overused as a workaround for the limits of "div"/"clear". (Text on top of text happens all too often.) Tables were actually a better layout tool, because they're a 2D system. HTML needs a 2D layout model that can't accidentally result in overlaps. There are plenty of those around; most window managers have one. There's been a quiet move back to tables for layout, but people are embarrassed to admit it.
CSS layout has some problems. Balanced columns is certainly one of them (although tables certainly doesn't fix that). They're working on it, but this can be addressed by improving CSS, outside of HTML.
Better parallelism. Pages must do their initial render without "document.write()". Forcing sequentiality during initial page load should be considered an error. This will make pages load faster. Some ad code will have to be rewritten.
I'm not sure what you're talking about exactly, but this sounds like a JavaScript implementation issue and not an HTML issue at all.
In the case of Safari, it does. Safari uses QuickTime to play videos, so you can use the <video> tag with any format that QuickTime supports. If you install XiphQT, then that includes Ogg Theora (I just checked, the video here plays just fine in Safari 4 with XiphQT installed).
That's a nice theory, but the W3C has absolutely no authority to force anybody to follow their standards. None. Browser developers follow W3C standards because they want to, not because they have to. They want to, because the W3C standards give them a sensible and clearly documented behavior that other browsers are also aiming for. However, Apple has chosen not to support Ogg, and it's likely that Microsoft won't either (both companies have their own alternatives they want people to license). If the W3C makes Ogg support a part of the standard, these browser vendors will ignore the standard, and there's nothing anybody can do about it. This makes the standard less useful.
You're right, though, about needing a killer app. If a popular web site started requiring Ogg support, and offered a Firefox download link for anyone who didn't support it, other browser vendors would be more interested in adding Ogg support.
WebKit doesn't support any video codecs. WebKit just sends videos to the appropriate media framework. This is as it should be.
The problem is Apple's decision not to include Ogg support in QuickTime.
In particular, when people say that MySQL works "well enough" for what they need, I simply do not believe them. They are simply not counting the amount of time they've wasted on data integrity issues over the years, because they just don't know better that with a superior RDBMS, those problems could be solved from day one.
But I haven't had issues with data integrity. No, I don't have a large database. I simply don't have that much data. If I did, and I had enough users accessing the data that data integrity ever became an issue, then yeah, of course I would want to fix it. That would be a compelling reason to switch, certainly. But my future projects aren't likely to be much bigger than my previous projects, and MySQL has performed well enough in the past that I expect it to work in the future too.
Does anyone even use mySQL when they have features like this? The only issue I have ever had with this DB was when I was trying to connect a .net app to it and it took me a while to find a workaround.
Because I don't need features like this, and don't know how to use them. At least, as far as I know, I don't need features like this. Since I don't know how to use them, it doesn't really matter, does it?
MySQL is what I've been running for several years; I'm familiar with the software. I use DBD::mysql in my Perl scripts; I'm sure most things would work fine if I simply switched to DBD::Pg, but would any queries need to be changed? I have no idea. Of course I'd need to migrate my data from MySQL to PostgreSQL; I'm not even sure of the "correct" way to migrate data from one installation of MySQL to another (copying the data files and then fixing whatever's broken usually works well enough). Of course, I'm running a few PHP-based webapps that currently use MySQL; I don't know if it's possible to get them to work with PostgreSQL or not (switching database engines in PHP isn't as simple as it is in Perl).
I could take the time to do the research and find answers to these questions. Or I could keep using what I know works just fine. Maybe someday I'll have some compelling need to try PostgreSQL and see if switching is practical. Today is not that day.
Does this answer your question?
I, too, was planning to buy this. Now, I'm going to wait until someone comes up with a hacked pirated version that works on a LAN somehow, and just copy that. Not because I'm angry with them or anything, but because it sounds like that will be the easiest way to get the game to work the way I want (easier to copy the hacked version from somebody else, than to patch my own legal copy). If they won't sell me what I want, I won't buy what they won't sell me.
I was planning to buy it (like I bought Warcraft II and Starcraft and Warcraft III), but now I'll just wait until there's a cracked pirated version that can play on a LAN somehow, and just copy that from somebody. I have no interest in playing on BattleNet.
Uh, ok, sure, if your friends weren't in the same room, you had to futz with modems. I do have a couple friends who live in another state, that I wouldn't mind playing with over BattleNet. Mostly, though, I want to play on a LAN, without needing a high speed Internet connection. That's how I played Warcraft II a decade ago.
You're an idiot. That wasn't an opinion. It was a statement of fact. It may be wrong (I don't care), but just because something is wrong doesn't mean it's an opinion.