The evidence needed to show plausible cause for a search warrant is very low
"Probable cause", not "plausible cause"; see U.S. Constitution, Amendment IV:
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
Sure, it's possible that they could change their tune if, and I stress IF, their new client asks them to. However, we have to assume that they were hired because of their experience. What experience do you think caught the eye of their new employers? Let's see, we have five lawyers from the RIAA. What experience could they all have in common?
They could have lots of skills and experience in common; or they could have all been chosen for different reasons. Of course, people to whom the RIAA is the most significant force in the universe are likely to fixate on that, rather than looking at the whole spectrum of each attorney's past clients, experience, legal publications, etc.
Just because something is all you care about doesn't mean its the basis other people are using for making decisions. The war between filesharers and the RIAA, MPAA, et al., may be the most important legal issue in the universe to many slashdotters, but, you know, outside of Slashdot there are some other legal issues that tend to overshadow it. Now, if they were five attorneys whose only substantial legal experience was representing the RIAA and similar organizations, and whose only legal publications were in support of the RIAA, MPAA, etc., then I might think there was something besides people thinking that what is important to them is also the first thing on the mind of everyone else in the world.
Honestly, looking at Google's repertoire of products, most of them don't make money. Only the advertising seems to.
The advertising is the main product they sell. Most of Google's services are tools to bring in eyeballs to increase the revenue that can be realized by advertising.
Do you think these guys are suddenly going to change their tune after arguing against freedom for years?
Its possible that some RIAA lawyers are ideologues, though I doubt many of them are. I suspect most of them are zealous advocates of the interests their paying clients communicate to them. So, yeah, their tune will change when their client changes if their new boss communicates a different set of interests from those that were communicated by their old boss.
these numbers are likely calculated as loss based on the potential for gains or sales
No, if you read TFA, they are clearly based on guesses as to the total revenues of YouTube (which range over a huge area) and estimates of its total actual operational costs (which, while also based on all kinds of assumptions, are pretty close between the Credit Suisse and Bear Stearns estimates, unlike the revenue numbers.)
So its an guesstimate of the actual operating profit/loss, not loss based on the potential for gains. Neither of the two guesstimates is, of course, worth putting any reliance on.
"The average visitor to YouTube is costing Google between one and two dollars, according to new research that shows Google losing up to $1.65 million per day on the video site."
Er, no.
That's not research, its almost pure guesswork. The key part being the guesses as to revenue. The two different estimates (from Credit Suisse and Bear Stearns) come pretty close on total daily cost ($2,064,054 vs. $1,906,520), but they are differ by a huge amount in the estimates of daily revenues ($657,534 vs. $246,575) so there may be some reasonable basis for the cost numbers (or the same assumptions may be made by different analysts), but the revenue numbers (and consequently the profit/loss estimate) seem to be pulled out of the air.
no, 9,999 years from now some conspiracy theorists will use this clock as a proof that our civilization foresaw the end of the world for the following year.
Just like Mayan calendar ends in 2012 with the last words from the Mayan guy who was working on it: "damn, i got to get a life, I'm done".
The Mayan (Long Count) calendar doesn't end in 2012; OTOH, I suppose the idea that our concept of time ended at the end point of the 10,000 year clock's coverage would the kind of preliminary mistake as "the Mayan calendar ends in 2012" that could precede and support a further mistaken belief that we expect the end of the world at that time.
Again, no. The microwaves don't interact with organic matter, they pass through.
Yes, this non-interaction of microwaves with organic matter is what makes it impossible to, say, use microwaves to heat food containing organic matter.
It is also what makes microwave area denial weapons impossible, and makes it safe to be very close in front of a powerful directional microwave transmitter.
Yeah, but the other theys aren't being paid to do it. If they do it, awesome, but it should be Google that does it.
And how much are you paying Google for the software that the Updater came with? If the answer is $0, Google isn't being paid, by you at least, to do it, either.
Sun's problem is that they are working up to the general launch of their cloud computing services, and Google AppEngine supporting more than just Python makes it that much harder for any new launch to get traction.
What Google should have done was engage in the JCP to define a new profile for supported "device", along the lines of the CDC/CLDC and MIDP. At least that way it would have been within the framework of practice understood and used by Java developers.
I really don't think that Java developers have much trouble understanding or using a clearly defined subset of existing functionality.
This actually looks a lot like what Microsoft got in trouble for with their MS Java.
What Microsoft did was create an incompatible implementation of core Java classes, supporting similar features but requiring different behavior with the same classes. This has much more serious negative impact than implementing a well-defined subset, since the former makes it hard to move code either way between implementations, and the latter (what Google is doing) makes it very easy to move code off the non-standard implementation (AppEngine) and onto a standard implementation, but somewhat challenging to move code using the unsupported features from the standard implementation onto the non-standard one.
It's actually a really bad thing to do if you want to create lock-in to your non-standard implementation, since it does nothing to keep people from moving off your platform, but makes it harder than supporting the standard would for them to move on to your platform.
Seems to me they should put their money where their mouth is...
Sun actually is launching their own cloud computing environment this summer, and has been announcing tie-ins to a lot of their existing products for it ("Save to Cloud", "Load from Cloud" in OpenOffice.org, Cloud related functionality in Netbeans 6.7, etc.) If their attempts to market their cloud offerings fall flat (which AppEngine supporting more than just Python makes somewhat more likely, as they have more competition, though I think Amazon is still the main direct competition for what they plan to offer), Sun's going to have wasted a lot of money and effort.
The real problem is that Google created their own version of Java ME. Instead of sticking with the existing standard, they came up with their own.
Since AppEngine, Google's cloud platform is (while, like mobile devices, a different environment from the standard desktop or server environment for which the Java Standard Library is designed) not a mobile platform, and doesn't have the same constraints that shape the development of Java ME, it's not surprising that they did something different.
OTOH, the justification is the same for having Java ME when Java SE already exists: the environment in which AppEngine Java is being used is very different from that for which SE was conceived, putting unique constraints on it.
I think that Phipps is upset because Sun is in the process of gearing up their own cloud services, and the last thing they want is Google's Java support drawing enterprise interest to AppEngine while they try to get Sun's cloud service off the ground.
IrI'm fine with the GOOG not offering Java support, but what's the justification for only offering half-assed support?
The justification is the same as Sun has when it creates a limited profile of Java for a special environment, like Java ME: the demands of a special environment.
Here in the US, criminal trespass is a crime, and can result in 6 months to a year in jail. Repeated offenses, or trespass with a weapon doubles that.
Unless its, e.g., on federal property or certain other exceptional cases, criminal trespass isn't within federal jurisdiction, and is, therefore, not the same crime with the same punishment everywhere in the US. It may be more or less severe than this in any of the very many US jurisdictions, and the conditions which aggravate it will also be different from jurisdiction to jurisdiction. And criminal trespass, in most if not all US jurisdictions, requires more than the mere unauthorized presence which constitutes civil trespass (e.g., California Penal Code Sec. 602 spells out, and considerable length, California's rather complex general criminal trespass provision, though there are special provisions for certain kinds of property a couple other places in the penal code.)
"Commodity" desktops will never be able to process 2500 simultaneous transactions in the same database. Even in Beowulf clusters.
Sure they will. With a sufficiently large cluster of commodity systems, processing lots of simultaneous transactions to the same database using a consensus algorithm somewhat similar to those in the Paxos family should be quite doable. Given the current interest in cloud computing and various aspects of distributing databases, I think that this is an area where the next decade or so will see a lot of movement from "should conceivably be doable" to "is routinely done".
No, its not. It has tags which are meant to convey data to a user agent and affect the rendering of the "plain old text" content, but not to be rendered as "plain old text".
what exactly is the need for this canonical business again?
The need for a mechanism of communicating the preferred and reliable short-form URL for an HTML document within the document is similar to the need to communicate a permalink within the document -- to provide something that can be stored or transmitted that the resource owner asserts will link back to the document reliably over an extended time. The particular need for the short-form URL is to support something that can easily be communicated in media that rely on a human reading and reproducing the URL -- SMS is one such medium, but print is also a medium which benefits from having reliable short-form URLs (and actually is more likely to be affected by whether those are durable over time than SMS.)
I have no idea what you are trying to say with those http URL examples. As for why the particular use of the rev link attribute or the canonical value, since I said in the post you responded to that those were bad choices to fill this need, you probably shouldn't ask me why they are good choices. OTOH, you seem to be suggesting that you'd use something in the URL rather than a link attribute, which doesn't seem to make any sense. Perhaps I'm misunderstanding you and you'd like to clarify what it is you are suggesting.
If ones twitter post requires several individual SMSezes all muxed up transparently by the phone, then in this day and age, it really needs to 'just work already'
The issue, which you seem to be missing entirely, is providing information in webpages identifying URL that can be used to access the page itself which is suitable for media where (1) hypertext is not supported, and (2) characters are at a premium for cost or other reasons, and (3) a human will need to transfer the link from that medium to a browser rather than relying on a computer to do it.
I'd prefer using tags with an appropriate rel attribute to using tags with a rev or rel attribtue, since tags are just as easy to harvest programmatically, and can be accessed by users with browsers with no special support, and because visibility is good.
If they fix twitter to support links with proper labels or tag contents
Isn't the point of Twitter to have something that works in a variety of media including, particularly, SMS?
SMS doesn't support hypertext and has message size limits, which is a problem with using HTML entity attributes to carry links instead of the text of the message, and a problem for full URLs.
OTOH, both the rev="canonical" and rel="alternate short*" forms proposed are, IMO, bad specific proposals -- the latter because it relies on the order of linktypes, the former, among other things, because it uses rev as a primary relationship rather than the reverse when the main relationship is described with rel (and, arguably, given how problematic rev has been, because it relies on rev at all.) I'd prefer something that used rel with a single link type, 'rel="short-url"' and 'rel="canonical-url"' to identify the shortened and canonical URLs for the current document, perhaps.
I'm talking about what would be a useful addition to Oracle's assets.
I didn't say anything about Oracle having different backends,
No, I said something about MySQL being useful to Oracle because it can support different backends.
I said that PostgreSQL already fits well into the Oracle world,
PostgreSQL, of open source DB servers, does a great job of approximating what Oracle's existing DB products do, but, Oracle doesn't need to acquire anything to replicate what it already has.
MySQL is a joke to anyone except crappy web developers (read as PHP hackers) fresh out of school.
MySQL's multi-backend architecture is generally useful and gives it the capacity to be a flexible framework, which would have some synergy with Oracle's existing assets. I don't think PostgreSQL offers as much to Oracle that they don't already have (even though I think that PostgreSQL is a far better DB product for most uses than MySQL.)
PostgreSQL makes a natural first step to later moving to Oracle because PostgreSQL can already be made to act A LOT like Oracle without the high end features.
Oracle has a whole series of products based on the same code base that do that already, and if they wanted to scale them down to a simpler versions, it would be a whole lot easier to do that from that code base than to acquire or fork PostgreSQL for that purpose.
Making MySQL anywhere near as powerful as PostgreSQL would almost require starting from scratch as all of its 'high end' features are bolted on in an absolutely horrible way because they are an after thought.
So? Does Oracle need to acquire anything it doesn't already own to have a database engine as powerful as PostgreSQL.
If you're going to have to rewrite it to make it not suck and fit into your world, you might as well take the other system that already fits into your world instead.
Again, Oracle doesn't need to acquire something that provides what they already have, they benefit by acquiring technology that's useful features are substantially different from what it already has.
I have a distinct feeling you haven't actually used a real database engine.
I use Oracle in an enterprise environment daily; I've used PostgreSQL, MySQL, and SQLite on a smaller scale and less frequently, and I've done a tiny amount of toying around with Oracle XE, SQL Server, DB2, and a number of non-relational databases. Of those, I see MySQL as the least useful on its own, but I think that it has some unique value to bring to Oracle that PostgreSQL doesn't have in the same way, and that has the potential for interesting synergy with Oracle's existing strengths. I have a distinct feeling you have trouble understanding what adds value to an existing product line.
But hearing a company's CEO say he won't hire people who aren't constantly willing to put in hours beyond the workweek is definitely disheartening.
In a field that is almost entirely non-unionized, particularly in a recession with high and still rising unemployment, employers treat employees badly because employees have, generally, few protections and little recourse.
This should not be surprising.
The job of executives is to make money for their shareholders. The general interest of executives, beyond their job, is to make money for themselves. In both cases, particularly in the present economic climate, the focus tends to be on the short term rather than the long term, which means, ultimately, milking the most out of people on the bottom of the food chain in the short term with the minimum cost. Which means, if they are on salary with no compensation for or limits on overtime, working them as many hours as possible as long as there is some increased output for the increased time worked, even if the per-hour productivity is dropping.
They'd probably rather have PostgreSQL which already has front ends for it that can make it behave a lot like Oracle and take direct connections from Oracle clients, since it is an actual transactional database, unlike the afterthought MySQL calls transaction support.
Eh, I think Oracle already has a few actual transactional database engines. MySQL, as an SQL-wrapper with modular storage backends that useful for a variety of purposes (including using at least one of Oracle's engines) is probably a more useful addition to Oracle's portfolio.
If your looking for features and price isn't a big barrier, something like DB2 is more likely to be the best alternative. If license cost is a big concern, Postgres is probably the best alternative for people for whom Oracle would, license cost aside, be a sensible choice. I won't say there aren't places where MySQL is a good choice, but I tend to think there are very few where Oracle would be a good choice and MySQL a good second choice or vice versa.
No, you see, the non-interactive labels that the user actually *sees* still say Name:, Email:, etc., but the *names* of the fields that are passed to the form processor are pseudo-random garbage.
So, essentially, this works as long as its not a common technique, but as soon as it becomes common enough to matter to the overall volume of forum spam in the world, there is a trivial way for spammers to adapt to it and defeat it.
Sure, sender-pay systems like the postal service see some volume of advertising, but the volume is kept down by the relatively high marginal cost.
"Some volume", for the postal service, is an understatement; almost all of Standard Mail and a significant fraction (somewhere around half) of First Class Mail is advertising, so probably somewhere around 2/3 of the total volume of mail. Its not quite as saturated by advertising as email, but it is still, by far, mostly advertising.
SPAM is sent from compromised computers. If you make people pay for posts then the owners of compromised computers will be billed - not the real senders of SPAM.
If the computer was so compromised that the spambot was able to log-in to secure websites (which any site that used a pay-to-post system would need to be) as if it was the legitimate operator of the computer, it makes sense to charge the operator of the computer. This will also, very quickly, encourage adoption of good security practices, as when the improper activity is (a) visible to the owner of the computer, and (b) has a direct financial cost to the owner of the computer, it won't continue without some kind of effective response. Spam bots operate on people's computers because they can do so without the owner of the computer ever realizing it. If every piece of spam sent out resulted in an immediate financial transaction for which the owner of the computer was responsible, you can bet that that owner would (a) notice, and (b) do whatever was necessary to stop the spam.
Slashdot Mirror
"Probable cause", not "plausible cause"; see U.S. Constitution, Amendment IV:
They could have lots of skills and experience in common; or they could have all been chosen for different reasons. Of course, people to whom the RIAA is the most significant force in the universe are likely to fixate on that, rather than looking at the whole spectrum of each attorney's past clients, experience, legal publications, etc.
Just because something is all you care about doesn't mean its the basis other people are using for making decisions. The war between filesharers and the RIAA, MPAA, et al., may be the most important legal issue in the universe to many slashdotters, but, you know, outside of Slashdot there are some other legal issues that tend to overshadow it. Now, if they were five attorneys whose only substantial legal experience was representing the RIAA and similar organizations, and whose only legal publications were in support of the RIAA, MPAA, etc., then I might think there was something besides people thinking that what is important to them is also the first thing on the mind of everyone else in the world.
The advertising is the main product they sell. Most of Google's services are tools to bring in eyeballs to increase the revenue that can be realized by advertising.
Its possible that some RIAA lawyers are ideologues, though I doubt many of them are. I suspect most of them are zealous advocates of the interests their paying clients communicate to them. So, yeah, their tune will change when their client changes if their new boss communicates a different set of interests from those that were communicated by their old boss.
No, if you read TFA, they are clearly based on guesses as to the total revenues of YouTube (which range over a huge area) and estimates of its total actual operational costs (which, while also based on all kinds of assumptions, are pretty close between the Credit Suisse and Bear Stearns estimates, unlike the revenue numbers.)
So its an guesstimate of the actual operating profit/loss, not loss based on the potential for gains. Neither of the two guesstimates is, of course, worth putting any reliance on.
Er, no.
That's not research, its almost pure guesswork. The key part being the guesses as to revenue. The two different estimates (from Credit Suisse and Bear Stearns) come pretty close on total daily cost ($2,064,054 vs. $1,906,520), but they are differ by a huge amount in the estimates of daily revenues ($657,534 vs. $246,575) so there may be some reasonable basis for the cost numbers (or the same assumptions may be made by different analysts), but the revenue numbers (and consequently the profit/loss estimate) seem to be pulled out of the air.
The Mayan (Long Count) calendar doesn't end in 2012; OTOH, I suppose the idea that our concept of time ended at the end point of the 10,000 year clock's coverage would the kind of preliminary mistake as "the Mayan calendar ends in 2012" that could precede and support a further mistaken belief that we expect the end of the world at that time.
Yes, this non-interaction of microwaves with organic matter is what makes it impossible to, say, use microwaves to heat food containing organic matter.
It is also what makes microwave area denial weapons impossible, and makes it safe to be very close in front of a powerful directional microwave transmitter.
And how much are you paying Google for the software that the Updater came with? If the answer is $0, Google isn't being paid, by you at least, to do it, either.
Sun's problem is that they are working up to the general launch of their cloud computing services, and Google AppEngine supporting more than just Python makes it that much harder for any new launch to get traction.
I really don't think that Java developers have much trouble understanding or using a clearly defined subset of existing functionality.
What Microsoft did was create an incompatible implementation of core Java classes, supporting similar features but requiring different behavior with the same classes. This has much more serious negative impact than implementing a well-defined subset, since the former makes it hard to move code either way between implementations, and the latter (what Google is doing) makes it very easy to move code off the non-standard implementation (AppEngine) and onto a standard implementation, but somewhat challenging to move code using the unsupported features from the standard implementation onto the non-standard one.
It's actually a really bad thing to do if you want to create lock-in to your non-standard implementation, since it does nothing to keep people from moving off your platform, but makes it harder than supporting the standard would for them to move on to your platform.
Sun actually is launching their own cloud computing environment this summer, and has been announcing tie-ins to a lot of their existing products for it ("Save to Cloud", "Load from Cloud" in OpenOffice.org, Cloud related functionality in Netbeans 6.7, etc.) If their attempts to market their cloud offerings fall flat (which AppEngine supporting more than just Python makes somewhat more likely, as they have more competition, though I think Amazon is still the main direct competition for what they plan to offer), Sun's going to have wasted a lot of money and effort.
Since AppEngine, Google's cloud platform is (while, like mobile devices, a different environment from the standard desktop or server environment for which the Java Standard Library is designed) not a mobile platform, and doesn't have the same constraints that shape the development of Java ME, it's not surprising that they did something different.
OTOH, the justification is the same for having Java ME when Java SE already exists: the environment in which AppEngine Java is being used is very different from that for which SE was conceived, putting unique constraints on it.
I think that Phipps is upset because Sun is in the process of gearing up their own cloud services, and the last thing they want is Google's Java support drawing enterprise interest to AppEngine while they try to get Sun's cloud service off the ground.
The justification is the same as Sun has when it creates a limited profile of Java for a special environment, like Java ME: the demands of a special environment.
Unless its, e.g., on federal property or certain other exceptional cases, criminal trespass isn't within federal jurisdiction, and is, therefore, not the same crime with the same punishment everywhere in the US. It may be more or less severe than this in any of the very many US jurisdictions, and the conditions which aggravate it will also be different from jurisdiction to jurisdiction. And criminal trespass, in most if not all US jurisdictions, requires more than the mere unauthorized presence which constitutes civil trespass (e.g., California Penal Code Sec. 602 spells out, and considerable length, California's rather complex general criminal trespass provision, though there are special provisions for certain kinds of property a couple other places in the penal code.)
Sure they will. With a sufficiently large cluster of commodity systems, processing lots of simultaneous transactions to the same database using a consensus algorithm somewhat similar to those in the Paxos family should be quite doable. Given the current interest in cloud computing and various aspects of distributing databases, I think that this is an area where the next decade or so will see a lot of movement from "should conceivably be doable" to "is routinely done".
No, its not. It has tags which are meant to convey data to a user agent and affect the rendering of the "plain old text" content, but not to be rendered as "plain old text".
The need for a mechanism of communicating the preferred and reliable short-form URL for an HTML document within the document is similar to the need to communicate a permalink within the document -- to provide something that can be stored or transmitted that the resource owner asserts will link back to the document reliably over an extended time. The particular need for the short-form URL is to support something that can easily be communicated in media that rely on a human reading and reproducing the URL -- SMS is one such medium, but print is also a medium which benefits from having reliable short-form URLs (and actually is more likely to be affected by whether those are durable over time than SMS.)
I have no idea what you are trying to say with those http URL examples. As for why the particular use of the rev link attribute or the canonical value, since I said in the post you responded to that those were bad choices to fill this need, you probably shouldn't ask me why they are good choices. OTOH, you seem to be suggesting that you'd use something in the URL rather than a link attribute, which doesn't seem to make any sense. Perhaps I'm misunderstanding you and you'd like to clarify what it is you are suggesting.
The issue, which you seem to be missing entirely, is providing information in webpages identifying URL that can be used to access the page itself which is suitable for media where (1) hypertext is not supported, and (2) characters are at a premium for cost or other reasons, and (3) a human will need to transfer the link from that medium to a browser rather than relying on a computer to do it.
I'd prefer using tags with an appropriate rel attribute to using tags with a rev or rel attribtue, since tags are just as easy to harvest programmatically, and can be accessed by users with browsers with no special support, and because visibility is good.
Isn't the point of Twitter to have something that works in a variety of media including, particularly, SMS?
SMS doesn't support hypertext and has message size limits, which is a problem with using HTML entity attributes to carry links instead of the text of the message, and a problem for full URLs.
OTOH, both the rev="canonical" and rel="alternate short*" forms proposed are, IMO, bad specific proposals -- the latter because it relies on the order of linktypes, the former, among other things, because it uses rev as a primary relationship rather than the reverse when the main relationship is described with rel (and, arguably, given how problematic rev has been, because it relies on rev at all.) I'd prefer something that used rel with a single link type, 'rel="short-url"' and 'rel="canonical-url"' to identify the shortened and canonical URLs for the current document, perhaps.
I'm talking about what would be a useful addition to Oracle's assets.
No, I said something about MySQL being useful to Oracle because it can support different backends.
PostgreSQL, of open source DB servers, does a great job of approximating what Oracle's existing DB products do, but, Oracle doesn't need to acquire anything to replicate what it already has.
MySQL's multi-backend architecture is generally useful and gives it the capacity to be a flexible framework, which would have some synergy with Oracle's existing assets. I don't think PostgreSQL offers as much to Oracle that they don't already have (even though I think that PostgreSQL is a far better DB product for most uses than MySQL.)
Oracle has a whole series of products based on the same code base that do that already, and if they wanted to scale them down to a simpler versions, it would be a whole lot easier to do that from that code base than to acquire or fork PostgreSQL for that purpose.
So? Does Oracle need to acquire anything it doesn't already own to have a database engine as powerful as PostgreSQL.
Again, Oracle doesn't need to acquire something that provides what they already have, they benefit by acquiring technology that's useful features are substantially different from what it already has.
I use Oracle in an enterprise environment daily; I've used PostgreSQL, MySQL, and SQLite on a smaller scale and less frequently, and I've done a tiny amount of toying around with Oracle XE, SQL Server, DB2, and a number of non-relational databases. Of those, I see MySQL as the least useful on its own, but I think that it has some unique value to bring to Oracle that PostgreSQL doesn't have in the same way, and that has the potential for interesting synergy with Oracle's existing strengths. I have a distinct feeling you have trouble understanding what adds value to an existing product line.
In a field that is almost entirely non-unionized, particularly in a recession with high and still rising unemployment, employers treat employees badly because employees have, generally, few protections and little recourse.
This should not be surprising.
The job of executives is to make money for their shareholders. The general interest of executives, beyond their job, is to make money for themselves. In both cases, particularly in the present economic climate, the focus tends to be on the short term rather than the long term, which means, ultimately, milking the most out of people on the bottom of the food chain in the short term with the minimum cost. Which means, if they are on salary with no compensation for or limits on overtime, working them as many hours as possible as long as there is some increased output for the increased time worked, even if the per-hour productivity is dropping.
Eh, I think Oracle already has a few actual transactional database engines. MySQL, as an SQL-wrapper with modular storage backends that useful for a variety of purposes (including using at least one of Oracle's engines) is probably a more useful addition to Oracle's portfolio.
If your looking for features and price isn't a big barrier, something like DB2 is more likely to be the best alternative. If license cost is a big concern, Postgres is probably the best alternative for people for whom Oracle would, license cost aside, be a sensible choice. I won't say there aren't places where MySQL is a good choice, but I tend to think there are very few where Oracle would be a good choice and MySQL a good second choice or vice versa.
So, essentially, this works as long as its not a common technique, but as soon as it becomes common enough to matter to the overall volume of forum spam in the world, there is a trivial way for spammers to adapt to it and defeat it.
"Some volume", for the postal service, is an understatement; almost all of Standard Mail and a significant fraction (somewhere around half) of First Class Mail is advertising, so probably somewhere around 2/3 of the total volume of mail. Its not quite as saturated by advertising as email, but it is still, by far, mostly advertising.
If the computer was so compromised that the spambot was able to log-in to secure websites (which any site that used a pay-to-post system would need to be) as if it was the legitimate operator of the computer, it makes sense to charge the operator of the computer. This will also, very quickly, encourage adoption of good security practices, as when the improper activity is (a) visible to the owner of the computer, and (b) has a direct financial cost to the owner of the computer, it won't continue without some kind of effective response. Spam bots operate on people's computers because they can do so without the owner of the computer ever realizing it. If every piece of spam sent out resulted in an immediate financial transaction for which the owner of the computer was responsible, you can bet that that owner would (a) notice, and (b) do whatever was necessary to stop the spam.