From my perspective, it's not really about the system itself; it's about the people behind it. Any procedure, system, or technological innovation is capable of both proper and improper uses. Is a gun dangerous? It depends on who is holding it, where they are going to point it, and how likely they are to pull the trigger. The same issue applies here.
The Japanese tolerate a national ID system because they are more trusting of their government. Maybe the Japanese government is genuinely trustworthy enough. If so, then a national ID system is not a threat to them.
The American government is not trustworthy. I believe that if a mandatory national ID system comes into existence in America, then the American government will not protect its citizens from the threats that such a system proposes. They will fail to show conscience, and crimes will occur and go unpunished. They will fail to show intelligence, and security breaches will take place from both the inside and outside. They will fail to show restraint, and the system will expand far beyond its intended or even its reasonable limits.
Americans who keep themselves informed are particularly touchy about such things. In recent times, we have seen our government do many things that the general public would disagree with, and fail to do many things that we all believed were critically important. I personally believe that the American government is far more removed from the wishes of its people than most other governments in the world are from their own.
Had anyone considered the possibility of using an offline wiki for simple content creation? (It's an idea I had several years ago, but kept to myself.) I am not an expert, but I bet that wiki software could be modified to run as a self-contained desktop application, and it might be made robust enough to serve as an alternative to an office suite.
Imagine a piece of hypothetical software called WikiOffice for a moment. Users can create files similar to those made with word processors, spreadsheets, slide presentations, help archives, etc., and other types of media could be imported and put to use with plugins. (I bet it could even support applications and "applets" using an internal scripting language.) WikiOffice would use a single file format capable of all such things, and the files themselves would essentially be miniature wiki databases. (For actual editing, the user might choose either to use a WYSIWIG interface or write the markup himself.) Individual pages (or sets of pages) could even be exported to other formats, or the entire file could even be split into two or more independent database files.
Also, if a user wants to distribute a file that can't be modified in certain ways, he can freeze some or all of the pages with a password, or assign group permissions the way an admin for a multi-user application or operating system commonly does. Concievably, copies of the file that have even been modified in different ways can be somewhat merged back into each other by an admin, much like many CMS systems can do.
(Of course, as surely as I post this, another Slashdotter is likely to point out something that already does most or all of this.)
Ouch. A bright red billboard among the more subdued colors of the CS maps. The people who dropped that in there didn't even *try* to make it look like the rest of the game, which is what would annoy me the most. "Obtrusive" is the description I would use. Those ads severely interfere with what game artists call "the suspension of disbelief", which should be the top priority for designing any game.
If the servers running the modified versions of those maps (and/or a mod that inserts the ads into the maps) could sit empty as a lesson to these people, it would be great. It's a shame that people actually have to *play* the maps before they realize that they contain ads, though. Gamers will just try to ignore them, and leave it at that, so this won't get any farther on that front.
Valve is not the one who has the right to complain in this matter; the authors of the modified maps are. (However, if the modified maps were originally made by employees of Valve, then it is most definitely their right to complain.) Most custom maps for virtually all moddable games these days ship with a readme, and this readme has a short legal disclaimer that outlines most or all of the following the following rights:
1. Others may not use the map as a base to build new maps. (But in practice, the author is commonly known to grant such permission if contacted directly.)
2. Commercial exploitation of the map and its supporting files by any method is strictly forbidden. (Such permission is almost never granted under any circumstances.)
3. Otherwise, anyone may freely distribute the map files as long as the readme is distributed along with it.
4. The license ends with a list of copyrights and trademarks that the map author used but that don't belong to him, such as the name of the game that the map was created for.
In general, such mini-licenses are just as binding as the GPL, and should be taken no less seriously. If I wrote a free game engine that people wanted to use for such a method, I would not object. However, I would require them to build their own maps; any maps I built for the engine would be off-limits for commercial purposes. On the other hand, any non-profit modifications they wanted to make to my maps would be perfectly fine, as long as the people playing those maps knew that my map was a base for someone else's work.
A patent on FAT doesn't really have much of a use for them now; at least none that I can think of. Just let the filesystem become an open standard now, MS.
I only wish that were true. The problem is that this is exactly the kind of thing that Microsoft has been after for quite a while. Now that it's everywhere, and it's something that every modern operating system has already implemented, Microsoft is going to go on a licensing spree. After all, they have already been talking about licensing it, long before anyone else considered the idea that the patents might actually be approved.
There are only a few possible ways that this can turn out good:
Microsoft has a change of heart, and decides that the chance to utterly destroy all its competition and leverage a complete monopoly with Windows is not worth the price of temporarily finding itself villified in the eyes of the public. (Unlikely.)
Some intrepid open-source developer(s) quickly cracks open the last few secrets of the NTFS file system, finally allowing the Linux kernel total interoperability with NTFS volumes. The open-source community rips out FAT support and relies more on NTFS volumes, fully expecting Microsoft to try to patent this file system too. In the meantime, additional research is performed either to try and create a more universal file system, or grant ext2 and ext3 more reliable interoperability with Windows and other operating systems. (Wishful thinking.)
Microsoft does indeed go on a licensing spree and begins threatening the markets for all competing operating systems. Commercial OS's will fork over the money; open-source OS's like Linux, BSD, ReactOS, etc. will strip FAT support from their systems, disrupting their interoperability with Windows volumes and each other. The US economy takes such a hard hit from this scandal that the patents get overturned later. Or perhaps, this is the evidence that the free and open-source software advocates in the US need to finally demonstrate that software patents aren't just a hassle, but a genuine liability. (Hard to say.)
At any rate, I hope that I'm wrong, and that this is just excessive paranoia on my part. But with Microsoft in this position, I don't think we should rely on optimism and just say that this will all be fine.
Well, somebody had to explain it to me too, at one point. Still, I find it hard to believe you hadn't at least HEARD of it. Graphics cards that use ordinary PCI interfaces are a joke so old it isn't even funny anymore.
Power sources, batteries, and generators are rather ubiquitous items in this day and age. If they manufacture it (and especially if they refine the design so that it holds a greater charge), then people will INVENT uses for it, which may or may not be a good thing. Right now, I suspect that this could be good as backup power for small electric/electronic items, such as alarm clocks and flashlights, and possibly a PDA (depending on how much battery power it requires).
When they make one of these batteries that can run a modern-day laptop computer for 3 or 4 hours straight, I'll be more impressed. However, it's still good to know that it's environmentally friendly.
AFAIK, Australia is still reeling from the effects of gun control laws. Clearly, they have not learned the lesson that unrealistic attempts at regulation only cause the problem to become worse. I have no sympathy for the politicians that think this will solve anything, even in the remote condition that it manages to work properly. However, I do have sympathy for the people of Australia that will have to deal with this, as well as whatever federal institutions and causes are robbed of money that the Australian government redirects to this misguided endeavor.
Those filters will not be effective by any stretch of the imagination. It's unlikely that pornography can be statistically "filtered out" the way spam is. Also, those who actually have a vested interest in the Australian market for pornography will just start signing up for hosting that's based in another country, like the United States. So the Australian government gets weepy and blows through a large supply of tax money EVERY YEAR on a solution with barely any chance of success and no redeemable returns even if it is a success.
Do these people even stop to think before they open their mouths to speak?
As the chief coder for a singleplayer mod for the first-generation Unreal engine, I have a few things to say about this.
Singleplayer and coop support are a lot more feasible for developers than people would expect, compared to multiplayer. For one thing, MP is usually implemented on top of the SP infrastructure anyway, meaning that coop is not really a big stretch after basic multiplayer is added. In many cases, it would actually be more efficient to implement coop MP first, and then build competitive and team-based MP on top of that. The decision to do otherwise is a marketing strategy, rather than a technological one. SP usually sells the game, and competitive MP keeps it alive and builds a community around it. Coop has less success with this.
As far as design is concerned, it splits into two major fields: netcode and AI. First, your netcode must be as efficient as possible, which means being VERY selective about what type of data your game server spends bandwidth on, which means using a lot of simulated stuff. For example, I personally believe that trying to get map data a piece at a time while the player is playing the map is a serious no-no. The client should be forced to download the map and supporting files such as sounds and textures (preferably from a dedicated mirror), have them verified, and then run this local copy before he is allowed to log into the server as a player.
Netcode must also be built into each object created in the game, which is probably the hardest part. For example, the client doesn't usually need to know a monster's health unless the player has the ability to ask. It's the server's job to keep that information. If a monster's behavior changes because of an increase or decrease in health, then the player is sent THAT information rather than the health. Also, as far as explosions and gratuitous special effects are concerned, the server should usually just say the equivalent of "A rocket just exploded at these coordinates. Render it yourself." to the client. And one player doesn't need to know that another has a shotgun hidden in his inventory, unless he pulls it up as his active weapon.
Then there's the matter of relevancy culling, to decide what is not a priority for transmitting. The monster you're fighting right now is relevant. The flags in a CTF team game are always relevant no matter where they are. The appearance of your teammate's HUD is not relevant. The guy who just got himself fragged on the other side of the map is probably not relevant, unless you saw it through the scope of your sniper rifle at the time. The straight-flying rockets you just fired are not relevant except as they first spawn, because their physics is simulated on the client, and the server will tell you if/when they hit something.
The second part of this design is the map itself, mostly relating to AI. The policy of "stupid code + smart data" has never been so important here. If your bots don't know how to use a weapon, then it's usually the WEAPON that's badly coded, not the bots. The same is true for maps. Only the most bare minimum AI code should exist in the code for bots and monsters (though this is still usually quite a bit). Anything "special" that they need to do should usually be a feature that is scripted by the mapper using custom or preexisting actors, rather than hardcoded into the game's AI by the coder. As an example, the Unreal engine has always relied on AI navigation of its maps through a network of "PathNodes" that mappers place throughout all the reachable areas in the map. This is what enables a bot to concievably navigate a maze-of-the-minotaur style map better than a typical Human player could. (I do not know enough about other gaming engines to comment on them.)
As a result, reasonably selective netcode combined with gametype- and map-centric AI is the most effective way to design a game engine. The kicker is that most of this is not really even a programming endeavor, but is better considered to be an extension of the d
And that's really what this should be about. I'm in favor of the basic idea, but I also agree it could use some polishing. The main feature of it should be that COMPUTERS will be able to determine the existence of pornography to some degree. If they put this in effect, then web browsers can also be modified to warn people when they are heading to a site with such a domain name, or deny access completely if one so desires.
o At any rate, I think that this top-level domain should exist primarily to separate out the "dedicated" pornography websites. Anything in the gray area, such as a website with lewd pictures that has to do with something else, should be left where it is. However, if porn is its market, then this is where it go. bu The law should be left intentionally loose, because false positives on what gets thrown over to *.xxx are a greater potential liability than somebody being upset about a potentially-questionable site. If the two sides of this get particularly ugly, a civil court judge can decide which side of the line something belongs on, for each individual case.
However, even with the law as loose as it is, this allows the *.xxx top-level domain to solve another potential problem. Sometimes a domain name owned by a particular person or organization will expire, and they will lose control of it. For some reason, porn sites like to snatch up expired domain names, and then they slap ronchy ads for their websites behind those names. Loose as it is, this general concept could be used to curb such a practice. It only stops one particular group from doing this, but it's a start.
So, I think it's a good concept, but it won't work automatically and it's not a magic pill that solves all the porn problems of the internet. (And maybe that's not such a bad thing, because we still need to teach our children maturity even when there are filters turned on.)
Manual memory management is similar to assembly language in a certain way: everybody should know how to use it, but they should strongly avoid actually having to use it in most cases. Even though I like to write code in C, I still understand the value of garbage collection. This goes back to the old adage: "Programmer time is more valuable than processor time." On the other hand, there are still a few instances where the manual method is the best tool for the job.
But then, the question is rather ambiguous. Is the writer asking:
"How much does garbage collection affect what language you choose to code in?"
"If you were designing a programming language, would you implement garbate collection? If so, what kind? If not, what memory allocation strategies do you use?"
"In what situations would you find garbage collection to be the most useful? When is manual memory management better?"
I'll leave further interpretation of the writer's words to other posters, as well as more thorough responses.
I'm sorry, but this sounds more than a little problematic. At ten times the write speed of a normal DVD, it sounds like buffer underruns would be the rule rather than the exception, unless you were able to use a medium-sized hard drive as a buffer. That means that you're looking not so much at the problem of disc errors from the drive's own hardware, but rather from disc errors because existing hardware can't keep up with it. It would be nice if write speeds could be decreased for compatibility, but this topic hasn't seem to come up yet AFAIK. ((I am not an expert; I'm just saying what I've read.) CD and DVD burners have this ability, but if HVD's depend on such a parallelized method for writing data, then who knows?)
And yes, I agree with the person who complained the loudest at the fact that the discs are larger. (I'll let you argue among yourselves over which of you that was.) After you invent a disc that can hold that much information, making the concession of perhaps even 20% capacity per disc so that the drive fits in existing computer cases is an excellent tradeoff. An important thing about all the other well-known breakthroughs in computer hardware is that it didn't require everything else to radically conform to the new standard it offered. If I want to build a state-of-the-art box with one of these drives in it, I should not have to make major allowances for this device like I would for...say, the motherboard and processor (32 or 64 bit?) or the graphics card (PCI-Express? Maybe also an AGP port for a legacy card?).
If the drive has to be larger, then so does the case. Consequently, you have to have specially-resized versions of existing CD and DVD drives, and other optical devices that were originally designed for another size. (At the very least, you would need an adapter kit to make a smaller device fit properly inside a larger bay.) Only a manufacturer with arrogance that rivals that of Microsoft would require perfectly-good standards to be rewritten just for them.
So, while I would be one of the first to welcome this technology, I still think it requires a bit more thought before the public should get their hands on it.
That's the whole point. They're databases, and that's where the common ground stops. "Apples and oranges", is the phrase that comes to mind. They cater to different subsets of the public. Right now, this "competition" of theirs is just a self-imposed illusion.
Then again, you bring up another good point in and of itself. It's very likely that both MySQL and Oracle are looking at each other and considering how to market to the other's primary segment of clients.
But also, both databases are open-source. This should make things even more fascinating, unless the open-source community itself starts taking sides.
Slashdot Mirror
From my perspective, it's not really about the system itself; it's about the people behind it. Any procedure, system, or technological innovation is capable of both proper and improper uses. Is a gun dangerous? It depends on who is holding it, where they are going to point it, and how likely they are to pull the trigger. The same issue applies here.
The Japanese tolerate a national ID system because they are more trusting of their government. Maybe the Japanese government is genuinely trustworthy enough. If so, then a national ID system is not a threat to them.
The American government is not trustworthy. I believe that if a mandatory national ID system comes into existence in America, then the American government will not protect its citizens from the threats that such a system proposes. They will fail to show conscience, and crimes will occur and go unpunished. They will fail to show intelligence, and security breaches will take place from both the inside and outside. They will fail to show restraint, and the system will expand far beyond its intended or even its reasonable limits.
Americans who keep themselves informed are particularly touchy about such things. In recent times, we have seen our government do many things that the general public would disagree with, and fail to do many things that we all believed were critically important. I personally believe that the American government is far more removed from the wishes of its people than most other governments in the world are from their own.
Had anyone considered the possibility of using an offline wiki for simple content creation? (It's an idea I had several years ago, but kept to myself.) I am not an expert, but I bet that wiki software could be modified to run as a self-contained desktop application, and it might be made robust enough to serve as an alternative to an office suite.
Imagine a piece of hypothetical software called WikiOffice for a moment. Users can create files similar to those made with word processors, spreadsheets, slide presentations, help archives, etc., and other types of media could be imported and put to use with plugins. (I bet it could even support applications and "applets" using an internal scripting language.) WikiOffice would use a single file format capable of all such things, and the files themselves would essentially be miniature wiki databases. (For actual editing, the user might choose either to use a WYSIWIG interface or write the markup himself.) Individual pages (or sets of pages) could even be exported to other formats, or the entire file could even be split into two or more independent database files.
Also, if a user wants to distribute a file that can't be modified in certain ways, he can freeze some or all of the pages with a password, or assign group permissions the way an admin for a multi-user application or operating system commonly does. Concievably, copies of the file that have even been modified in different ways can be somewhat merged back into each other by an admin, much like many CMS systems can do.
(Of course, as surely as I post this, another Slashdotter is likely to point out something that already does most or all of this.)
Ouch. A bright red billboard among the more subdued colors of the CS maps. The people who dropped that in there didn't even *try* to make it look like the rest of the game, which is what would annoy me the most. "Obtrusive" is the description I would use. Those ads severely interfere with what game artists call "the suspension of disbelief", which should be the top priority for designing any game.
If the servers running the modified versions of those maps (and/or a mod that inserts the ads into the maps) could sit empty as a lesson to these people, it would be great. It's a shame that people actually have to *play* the maps before they realize that they contain ads, though. Gamers will just try to ignore them, and leave it at that, so this won't get any farther on that front.
Valve is not the one who has the right to complain in this matter; the authors of the modified maps are. (However, if the modified maps were originally made by employees of Valve, then it is most definitely their right to complain.) Most custom maps for virtually all moddable games these days ship with a readme, and this readme has a short legal disclaimer that outlines most or all of the following the following rights:
1. Others may not use the map as a base to build new maps. (But in practice, the author is commonly known to grant such permission if contacted directly.)
2. Commercial exploitation of the map and its supporting files by any method is strictly forbidden. (Such permission is almost never granted under any circumstances.)
3. Otherwise, anyone may freely distribute the map files as long as the readme is distributed along with it.
4. The license ends with a list of copyrights and trademarks that the map author used but that don't belong to him, such as the name of the game that the map was created for.
In general, such mini-licenses are just as binding as the GPL, and should be taken no less seriously. If I wrote a free game engine that people wanted to use for such a method, I would not object. However, I would require them to build their own maps; any maps I built for the engine would be off-limits for commercial purposes. On the other hand, any non-profit modifications they wanted to make to my maps would be perfectly fine, as long as the people playing those maps knew that my map was a base for someone else's work.
My apologies. I think I read someone else in this discussion saying that NTFS was already patented by Microsoft.
A patent on FAT doesn't really have much of a use for them now; at least none that I can think of. Just let the filesystem become an open standard now, MS.
I only wish that were true. The problem is that this is exactly the kind of thing that Microsoft has been after for quite a while. Now that it's everywhere, and it's something that every modern operating system has already implemented, Microsoft is going to go on a licensing spree. After all, they have already been talking about licensing it, long before anyone else considered the idea that the patents might actually be approved.
There are only a few possible ways that this can turn out good:
At any rate, I hope that I'm wrong, and that this is just excessive paranoia on my part. But with Microsoft in this position, I don't think we should rely on optimism and just say that this will all be fine.
http://en.wikipedia.org/wiki/PCI_Express
Well, somebody had to explain it to me too, at one point. Still, I find it hard to believe you hadn't at least HEARD of it. Graphics cards that use ordinary PCI interfaces are a joke so old it isn't even funny anymore.
Power sources, batteries, and generators are rather ubiquitous items in this day and age. If they manufacture it (and especially if they refine the design so that it holds a greater charge), then people will INVENT uses for it, which may or may not be a good thing. Right now, I suspect that this could be good as backup power for small electric/electronic items, such as alarm clocks and flashlights, and possibly a PDA (depending on how much battery power it requires).
When they make one of these batteries that can run a modern-day laptop computer for 3 or 4 hours straight, I'll be more impressed. However, it's still good to know that it's environmentally friendly.
AFAIK, Australia is still reeling from the effects of gun control laws. Clearly, they have not learned the lesson that unrealistic attempts at regulation only cause the problem to become worse. I have no sympathy for the politicians that think this will solve anything, even in the remote condition that it manages to work properly. However, I do have sympathy for the people of Australia that will have to deal with this, as well as whatever federal institutions and causes are robbed of money that the Australian government redirects to this misguided endeavor.
Those filters will not be effective by any stretch of the imagination. It's unlikely that pornography can be statistically "filtered out" the way spam is. Also, those who actually have a vested interest in the Australian market for pornography will just start signing up for hosting that's based in another country, like the United States. So the Australian government gets weepy and blows through a large supply of tax money EVERY YEAR on a solution with barely any chance of success and no redeemable returns even if it is a success.
Do these people even stop to think before they open their mouths to speak?
As the chief coder for a singleplayer mod for the first-generation Unreal engine, I have a few things to say about this.
Singleplayer and coop support are a lot more feasible for developers than people would expect, compared to multiplayer. For one thing, MP is usually implemented on top of the SP infrastructure anyway, meaning that coop is not really a big stretch after basic multiplayer is added. In many cases, it would actually be more efficient to implement coop MP first, and then build competitive and team-based MP on top of that. The decision to do otherwise is a marketing strategy, rather than a technological one. SP usually sells the game, and competitive MP keeps it alive and builds a community around it. Coop has less success with this.
As far as design is concerned, it splits into two major fields: netcode and AI. First, your netcode must be as efficient as possible, which means being VERY selective about what type of data your game server spends bandwidth on, which means using a lot of simulated stuff. For example, I personally believe that trying to get map data a piece at a time while the player is playing the map is a serious no-no. The client should be forced to download the map and supporting files such as sounds and textures (preferably from a dedicated mirror), have them verified, and then run this local copy before he is allowed to log into the server as a player.
Netcode must also be built into each object created in the game, which is probably the hardest part. For example, the client doesn't usually need to know a monster's health unless the player has the ability to ask. It's the server's job to keep that information. If a monster's behavior changes because of an increase or decrease in health, then the player is sent THAT information rather than the health. Also, as far as explosions and gratuitous special effects are concerned, the server should usually just say the equivalent of "A rocket just exploded at these coordinates. Render it yourself." to the client. And one player doesn't need to know that another has a shotgun hidden in his inventory, unless he pulls it up as his active weapon.
Then there's the matter of relevancy culling, to decide what is not a priority for transmitting. The monster you're fighting right now is relevant. The flags in a CTF team game are always relevant no matter where they are. The appearance of your teammate's HUD is not relevant. The guy who just got himself fragged on the other side of the map is probably not relevant, unless you saw it through the scope of your sniper rifle at the time. The straight-flying rockets you just fired are not relevant except as they first spawn, because their physics is simulated on the client, and the server will tell you if/when they hit something.
The second part of this design is the map itself, mostly relating to AI. The policy of "stupid code + smart data" has never been so important here. If your bots don't know how to use a weapon, then it's usually the WEAPON that's badly coded, not the bots. The same is true for maps. Only the most bare minimum AI code should exist in the code for bots and monsters (though this is still usually quite a bit). Anything "special" that they need to do should usually be a feature that is scripted by the mapper using custom or preexisting actors, rather than hardcoded into the game's AI by the coder. As an example, the Unreal engine has always relied on AI navigation of its maps through a network of "PathNodes" that mappers place throughout all the reachable areas in the map. This is what enables a bot to concievably navigate a maze-of-the-minotaur style map better than a typical Human player could. (I do not know enough about other gaming engines to comment on them.)
As a result, reasonably selective netcode combined with gametype- and map-centric AI is the most effective way to design a game engine. The kicker is that most of this is not really even a programming endeavor, but is better considered to be an extension of the d
And that's really what this should be about. I'm in favor of the basic idea, but I also agree it could use some polishing. The main feature of it should be that COMPUTERS will be able to determine the existence of pornography to some degree. If they put this in effect, then web browsers can also be modified to warn people when they are heading to a site with such a domain name, or deny access completely if one so desires.
o
At any rate, I think that this top-level domain should exist primarily to separate out the "dedicated" pornography websites. Anything in the gray area, such as a website with lewd pictures that has to do with something else, should be left where it is. However, if porn is its market, then this is where it go. bu The law should be left intentionally loose, because false positives on what gets thrown over to *.xxx are a greater potential liability than somebody being upset about a potentially-questionable site. If the two sides of this get particularly ugly, a civil court judge can decide which side of the line something belongs on, for each individual case.
However, even with the law as loose as it is, this allows the *.xxx top-level domain to solve another potential problem. Sometimes a domain name owned by a particular person or organization will expire, and they will lose control of it. For some reason, porn sites like to snatch up expired domain names, and then they slap ronchy ads for their websites behind those names. Loose as it is, this general concept could be used to curb such a practice. It only stops one particular group from doing this, but it's a start.
So, I think it's a good concept, but it won't work automatically and it's not a magic pill that solves all the porn problems of the internet. (And maybe that's not such a bad thing, because we still need to teach our children maturity even when there are filters turned on.)
But then, the question is rather ambiguous. Is the writer asking:
I'll leave further interpretation of the writer's words to other posters, as well as more thorough responses.
I'm sorry, but this sounds more than a little problematic. At ten times the write speed of a normal DVD, it sounds like buffer underruns would be the rule rather than the exception, unless you were able to use a medium-sized hard drive as a buffer. That means that you're looking not so much at the problem of disc errors from the drive's own hardware, but rather from disc errors because existing hardware can't keep up with it. It would be nice if write speeds could be decreased for compatibility, but this topic hasn't seem to come up yet AFAIK. ((I am not an expert; I'm just saying what I've read.) CD and DVD burners have this ability, but if HVD's depend on such a parallelized method for writing data, then who knows?)
And yes, I agree with the person who complained the loudest at the fact that the discs are larger. (I'll let you argue among yourselves over which of you that was.) After you invent a disc that can hold that much information, making the concession of perhaps even 20% capacity per disc so that the drive fits in existing computer cases is an excellent tradeoff. An important thing about all the other well-known breakthroughs in computer hardware is that it didn't require everything else to radically conform to the new standard it offered. If I want to build a state-of-the-art box with one of these drives in it, I should not have to make major allowances for this device like I would for...say, the motherboard and processor (32 or 64 bit?) or the graphics card (PCI-Express? Maybe also an AGP port for a legacy card?).
If the drive has to be larger, then so does the case. Consequently, you have to have specially-resized versions of existing CD and DVD drives, and other optical devices that were originally designed for another size. (At the very least, you would need an adapter kit to make a smaller device fit properly inside a larger bay.) Only a manufacturer with arrogance that rivals that of Microsoft would require perfectly-good standards to be rewritten just for them.
So, while I would be one of the first to welcome this technology, I still think it requires a bit more thought before the public should get their hands on it.
That's the whole point. They're databases, and that's where the common ground stops. "Apples and oranges", is the phrase that comes to mind. They cater to different subsets of the public. Right now, this "competition" of theirs is just a self-imposed illusion.
Then again, you bring up another good point in and of itself. It's very likely that both MySQL and Oracle are looking at each other and considering how to market to the other's primary segment of clients.
But also, both databases are open-source. This should make things even more fascinating, unless the open-source community itself starts taking sides.