Anonymous sources are absolutely necessary.
How can people protect themselves from retribution
without it?
How can anyone protect themselves from slanderous and/or libelous accusations if the accusers are guaranteed complete anonymity through technology? There need to be checks and balances against the press as well.
Amendment VI of the Constitution guarantees a defendant the right to face his or her accuser:
Amendment VI
In all criminal prosecutions, the accused shall enjoy the right to a speedy and public trial, by an impartial jury of the state and district wherein the crime shall have been committed, which district shall have been previously ascertained by law, and to be informed of the nature and cause of the accusation; to be confronted with the witnesses against him; to have compulsory process for obtaining witnesses in his favor, and to have the assistance of counsel for his defense.
Yes, I know that the Bill of Rights are the protections of the people against the government; however, the Fifth Estate considers itself to be performing a governmental function (namely, oversight), so one could conceivably argue that the protections of the Bill of Rights could and should be extended to protect against the press, as well as to protect us against each other.
I'd argue that anonymous sources should be permitted so long as the reporter, managing editor, and the affiliated media organization are all on the hook for both civil and criminal complaints arising from stories arising from anonymous sources. Think of it as Sarbanes-Oxley for the press. 8-)
Simply put, you can use anonymous sources so long as you're willing to put your money where their mouth is.
Exactly how is full-scanning a table, sorting it, writing an index, and then performing data access by the index faster than simply full-scanning the table? It seems to me that if you just do the full scan and process based off of that, you've done less work.
If you need absolute control over how data is stored, well, that's why various databases give you various options. Always join two tables? Cluster them (as in physically store together) the two tables. Always want the data in sorted order? Use an index-organized table, or reorg it regularly about a clustering index.
This is the sort of knowledge that database architects and administrators are supposed to have, and are supposed to leverage... except when the coders decide that they're going to use that database as a data dump never bother consulting with them about "how should I get this data?"
Explicit programming of database processing is how you get slow-by-slow, er, row-by-row processing. Database are designed to work on sets of data. You can't outsort it programmatically and you can't outjoin it programmatically. If you try, then you're either wasting your time or wasting money - and probably both.
But given that Jedi can parry gunfire with their lightsabres (neat trick, that - how do you practice?)
Um, I think you put on a blacked out helmet and a training remote zaps the bejeebers out of you. Preferably while an Astromech droid and a Wookie play Holo Battle Chess while you're flying to Alderaan...
A database is not the be-all or end-all of computing; however, it is the be-all and end-all of data storage and access when things such as consistency, concurrency, and recoverability are at issue.
If you take your example of codes in a file, how will you distribute it? How will you maintain it? How can multiple users access it? What happens if someone accidentally deletes it?
Databases are designed to solve exactly these types of problems.
You need to have the One True Copy of the data, in all cases. If you wish to distribute a flat-file or marked up copy of that data provided it's completely static aside from a software revision, then that's fine. But keeping key data unprotected -- or worse, opening up yourself to multiple masters -- demonstrates to me that you're thinking about things at the hobby/toy project level, certainly not at a distributed or COTS level.
Your data is your application. It doesn't matter if the data is static or not. And for goodness sakes, if you're going to be using a database anyway for the dynamic data, eat the storage and keep the master copy in the freaking database!
(And if you're not using a database at all, well, that's further evidence to me that you're thinking at the toy/hobby level of project scope.)
If you were going to store large, binary data sets (such as video) in a database, I'd tell you to use Oracle and either store the data out-of-line with BFILEs, using the database as an indexing mechanism, or store it in the data as BLOBS, depending on whether access time (use BFILES!) or recoverability (use BLOBS!) was more important. I don't know what that project used, but writing either of the apps with those data storage concepts is pretty trivial.
I respectfully disagree with your statement, although likely not the intent.
Every piece of info you serve should be stored in a database, but not every piece of info you serve needs to be served from a database every single time.
Of course, the article leaves one key point unsaid but implied...
Understand the nature of your data.
In any system, there's basically three kinds of data:
-- Static: This is the stuff that changes at a glacial pace, such as state codes, currency codes, and so forth. (for bonus points, put all the static code/description values in a single table with a type identifier for an even larger performance increase at the cost of slightly more complicated code.)
-- Configuration: This is the data that drives the logic of the application. (Go ahead, put it all in code. Good luck with the maintenance.)
-- Data: The actual records that you process or interrogate at some level to do something.
If the JDBC monkeys don't understand the nature of the data at this fundamental level, then telling them to cache data is a recipe for concurrency and consistency nightmares. Not because they mean to, but because they don't know any better.
Caching the static data is probably safe, but the configuration data is only *somewhat* safe to cache. It's too expensive to continually round-trip for everything, so what my project has done is implement a warm-boot process. For every transactional record it attempts to process, it checks a warm-boot status table. If the time has changed, the app flushes and repopulates its caches of both static and configuration data. Sure, it's a little kludgy, but it gives us at least parts of the best of both worlds.
The fact that you do it that way with *more* round-trips to the database makes it the least-right way.
Why put the business logic into the database?
Because the data lives there, and for any application beyond the toy scope, you optimize for your database. Also, anyone else who shares your data with a different application then gets to experience the rare and unique joy of reimplementing your code in his application.
It's not an issue with complexity of implementation, it's an issue with systems architecture.
The archetypical application developer views his application as the source of data entry and validation. As such, business rules and data validation belong there, because he understands them. Sure, some other application may use the same data, but it's got its own application developer and its own application doing the same thing, only probably differently.
The database administrator, on the other hand, knows that business and validation rules for data come in two forms: simple and complicated. Simple is things like data typing and constraints, whether relational (parent-child) or check (list-of-value or range). Complicated means conditional logic, and traditionally, conditional logic means code in an external application. However, the DBA wants the business and validation rules applied *regardless* of input source. Triggers provide that.
After all, we almost never use the fancy application for data entry or manipluation. We use our query tool, whether SQL*Plus or QMF or SPUFI or Command Center or Toad or Access or...
Well, not Access.
My point is, there's more than one way into the database, and logic about the data belongs where the data lives, so that no matter how the data gets into the database, the same rules apply to it. (Sure, triggers and constraints can be disabled. But then it's the DBA's fault for disabling them, as opposed to the DBA's responsibility and some ill-behaved application's fault.)
Presentation logic belongs in the application. Everything else belongs in the database.
Sure, that's what property taxes are for. That's also not how California's property taxes work.
California Proposition 13 capped property tax valuation increases at a maximum of 2% per annum, with the valuation of the property being reassessed when sold. Two adjoining houses owned by Warren Buffett in Laguna Beach in 2003 had effective tax rates that vary by a factor of 10, because one was bought in the 70's while one was purchased in the 90's.
(http://www.berkshirehathaway.com/wsj.html for more details)
California needs greater tax equity, as its current property tax philosophy boils down to "sock it to the new guy".
EA is currently the only game in town for a college football product, and even that is restricted only to consoles. One cannot purchase a college football game for a PC -- the *only* college football game is available on Gamecube, Xbox, and PS2.
One can get FIFA and UEFA games on PC (in the US!), but no college football. Never mind that there are millions of fans of college football who pack stadiums on autumn Saturdays.
It's bordering on criminal. I imagine that EA bought out exclusive NCAA rights in 2002 or 2003, because I don't remember having seen the NCAA Gamebreaker or NCAA 2K(n) games for a couple of years now.
Some software (such as AutoCAD, e.g.) ensures that printouts generated indicate that the work was generated with an educational product. It's not nagware or even really crippleware -- more like tattleware.
Re:How many of us could actually mount a defense?
on
The Basics of EULAs
·
· Score: 2, Informative
When a lawyer's compensation is deferred until after judgment and is predicated on winning the case (and the phat lewt which accompanies it), that's called taking the case on contingency.
Pro bono is when a lawyer works for free -- as in beer -- as it's generally working "for the public good", hence the latin abbreviation of "pro bono publico".
Bzzzt.
Whether count(key_column), count(1), count(*), or count(non_key_column), Oracle will tend to prefer to perform a fast full scan of the primary key index, never accessing the underlying table.
Obviously, this depends on little things like how the optimizer's been tuned, whether there are optimizer statistics, and the version of Oracle.
I'm fairly certain it's not *that* simple -- nothing ever is.
Selling the rights for a flat fee would be criminally stupid on the part of the original developer/publisher or MacSoft's part. There would be some shared reward, more like:
$500,000 up front for the rights, then $2 per unit for the first 100,000 units, then $4 per unit for the next 100,000 units, and $5 per unit for all other units.
Shared profit, mitigated risk.
I'm also sure there's lots and lots of review to ensure that the Mac product/version faithfully reproduces the experience. No one would simply sign away their IP to MacSoft, where MacSoft would then have total control.
That review of the final product costs money and time, both of which are seldom in simultaneous supply from both publisher and original developer.
I believe that Mac fans should hitch their wagon to Linux, and argue for Linux/Posix versions, where the Mac version in an emulated/unix native mode. At least then the breakdown of the market isn't 98-2, it's anywhere from 90-10 to 75-25, and then you're talking about a large enough segment of the market to matter to the publishers.
If Mac ports were free (or purely profitable), every game would have one. The fact that every game doesn't yields one of the following conclusions:
1. There's a conspiracy against the Mac as a gaming platform; or 2. Developers and publishers are too stupid to take free money; or 3. The original hypothesis is flawed.
Shortsidedness is the quality of a golf shot that misses the green near the flag, resulting in a more difficult chip. To hit such a shot is to shortside onesself.
Of course, long term, a software house looking to produce a game for both PCs and Macs long term will choose an agnostic server browser, or host their own, so GameSpy, ultimately, is going to lose with this move.
Of course, that posits that there are such software houses in great quantity that consider the Mac platform a significant market *worth* supporting with time and money.
The value of GameSpy to consumers is a function of the number of other GameSpy users. Do we really believe that eliminating Mac users significantly alters the number of GameSpy users?
... make a decision that inconviences the few while allowing them to realign development resources better. I mean, it's like they're considering things like shareholder value.
The Brent Siennas of the world who are all aflutter about this need to realize that the Mac as a gaming platform is a downright miniscule niche, and one that probably takes nearly the same number of resources to support as any other platform. However, the return on investment derived from that platform is probably negative, and any Mac gamer probably does their hardcore gaming elsewhere because they're not willing to wait months or years for the popular games to finally be ported.
GameSpy feels, rightly or wrongly, that this decision is in their best interest, and I'm pretty confident they've done those suit-like activities like market analysis and return on investment analysis to back up their decision. I'm further pretty sure that the Think Different crowd hasn't, and is motivated solely by their want -- no, need -- not to be considered second-class citizens in the gaming world.
If the Mac were a strategic focus for GameSpy, they probably wouldn't have made the decision to drop support -- companies tend to be willing to tread water for markets and products they consider of primary current or future importance.
Anyone here who isn't a Mac zealot really consider the Mac as a gaming platform to be of primary importance?
Here's a parallel -- I'd venture that the Mac share of the computer gaming market (excluding consoles) is on par with SCO's share of the X86 server market.
If major software vendors dropped support for SCO, would there be the same hue and cry?
Never figured out how to use the shift button, didja? Or was it the putting your sword away and jumping into the mirror that you were never able to figure out?
Prince of Persia and its direct ancestor, Karateka, were fabulous. Hell, I still pull them up on the old ][e emulator from time to time.
I bet you find the special effects in _Star Wars_ super-crappy, too.
Those cross-table constraints are hard to get right, whether you do it in the database or in the application. You need "on insert or update" logic in the first table, and "on update or delete" logic in tables "foo" and "bar". People usually omit one half of that, as you just did.
An excellent point -- however, I was quick-and-dirtying the logic.
Further, IIRC, each of the tables foo/bar/baz could have a single trigger which fires under different conditions (insert/update on baz, update/delete on foo) so that you don't have to have multiple triggers.
Of course, you could also have multiple triggers on a single table, each of which only fires on insert/update/delete of a specified column -- then you wouldn't have "all or nothing" if your RI is being administered through triggers.
I agree that it's hard to get right -- generally, such issues are design-related, as a cleaner or simpler design eliminates if-then-else RI.
We gave-up on using Oracle contraints, because they aren't very featureful.
Exactly what about Oracle's constraints do you not consider featureful?
(and further, logic too complicated for a simple constraint, such as if column A = 1 then column B's value must be a key in table foo, else it must be a key in table bar, can be implemented fairly simple as a PL/SQL trigger).
And on the moderation-front... the fact that you cannot moderate a thread where you participate functionally selects for ignorant moderators, as the informed speak and the ignorant try to determine who's right.
I never said it wasn't a hack or somewhat inefficient -- but it's the best way to get that done in systems which don't support sequences.
Sadly, most people who work in systems without sequences never even consider their existence, so they use identity/autoincrement columns indiscriminately, and you can't undo that kind of design decision simply.
Slashdot Mirror
I'd argue that anonymous sources should be permitted so long as the reporter, managing editor, and the affiliated media organization are all on the hook for both civil and criminal complaints arising from stories arising from anonymous sources. Think of it as Sarbanes-Oxley for the press. 8-)
Simply put, you can use anonymous sources so long as you're willing to put your money where their mouth is.
Exactly how is full-scanning a table, sorting it, writing an index, and then performing data access by the index faster than simply full-scanning the table? It seems to me that if you just do the full scan and process based off of that, you've done less work.
If you need absolute control over how data is stored, well, that's why various databases give you various options. Always join two tables? Cluster them (as in physically store together) the two tables. Always want the data in sorted order? Use an index-organized table, or reorg it regularly about a clustering index.
This is the sort of knowledge that database architects and administrators are supposed to have, and are supposed to leverage... except when the coders decide that they're going to use that database as a data dump never bother consulting with them about "how should I get this data?"
Explicit programming of database processing is how you get slow-by-slow, er, row-by-row processing. Database are designed to work on sets of data. You can't outsort it programmatically and you can't outjoin it programmatically. If you try, then you're either wasting your time or wasting money - and probably both.
A database is not the be-all or end-all of computing; however, it is the be-all and end-all of data storage and access when things such as consistency, concurrency, and recoverability are at issue.
If you take your example of codes in a file, how will you distribute it? How will you maintain it? How can multiple users access it? What happens if someone accidentally deletes it?
Databases are designed to solve exactly these types of problems.
You need to have the One True Copy of the data, in all cases. If you wish to distribute a flat-file or marked up copy of that data provided it's completely static aside from a software revision, then that's fine. But keeping key data unprotected -- or worse, opening up yourself to multiple masters -- demonstrates to me that you're thinking about things at the hobby/toy project level, certainly not at a distributed or COTS level.
Your data is your application. It doesn't matter if the data is static or not. And for goodness sakes, if you're going to be using a database anyway for the dynamic data, eat the storage and keep the master copy in the freaking database!
(And if you're not using a database at all, well, that's further evidence to me that you're thinking at the toy/hobby level of project scope.)
If you were going to store large, binary data sets (such as video) in a database, I'd tell you to use Oracle and either store the data out-of-line with BFILEs, using the database as an indexing mechanism, or store it in the data as BLOBS, depending on whether access time (use BFILES!) or recoverability (use BLOBS!) was more important. I don't know what that project used, but writing either of the apps with those data storage concepts is pretty trivial.
I respectfully disagree with your statement, although likely not the intent. Every piece of info you serve should be stored in a database, but not every piece of info you serve needs to be served from a database every single time.
Of course, the article leaves one key point unsaid but implied...
Understand the nature of your data.
In any system, there's basically three kinds of data:
-- Static: This is the stuff that changes at a glacial pace, such as state codes, currency codes, and so forth. (for bonus points, put all the static code/description values in a single table with a type identifier for an even larger performance increase at the cost of slightly more complicated code.)
-- Configuration: This is the data that drives the logic of the application. (Go ahead, put it all in code. Good luck with the maintenance.)
-- Data: The actual records that you process or interrogate at some level to do something.
If the JDBC monkeys don't understand the nature of the data at this fundamental level, then telling them to cache data is a recipe for concurrency and consistency nightmares. Not because they mean to, but because they don't know any better.
Caching the static data is probably safe, but the configuration data is only *somewhat* safe to cache. It's too expensive to continually round-trip for everything, so what my project has done is implement a warm-boot process. For every transactional record it attempts to process, it checks a warm-boot status table. If the time has changed, the app flushes and repopulates its caches of both static and configuration data. Sure, it's a little kludgy, but it gives us at least parts of the best of both worlds.
The fact that you do it that way with *more* round-trips to the database makes it the least-right way.
Because the data lives there, and for any application beyond the toy scope, you optimize for your database. Also, anyone else who shares your data with a different application then gets to experience the rare and unique joy of reimplementing your code in his application.
It's not an issue with complexity of implementation, it's an issue with systems architecture.
...
The archetypical application developer views his application as the source of data entry and validation. As such, business rules and data validation belong there, because he understands them. Sure, some other application may use the same data, but it's got its own application developer and its own application doing the same thing, only probably differently.
The database administrator, on the other hand, knows that business and validation rules for data come in two forms: simple and complicated. Simple is things like data typing and constraints, whether relational (parent-child) or check (list-of-value or range). Complicated means conditional logic, and traditionally, conditional logic means code in an external application. However, the DBA wants the business and validation rules applied *regardless* of input source. Triggers provide that.
After all, we almost never use the fancy application for data entry or manipluation. We use our query tool, whether SQL*Plus or QMF or SPUFI or Command Center or Toad or Access or
Well, not Access.
My point is, there's more than one way into the database, and logic about the data belongs where the data lives, so that no matter how the data gets into the database, the same rules apply to it. (Sure, triggers and constraints can be disabled. But then it's the DBA's fault for disabling them, as opposed to the DBA's responsibility and some ill-behaved application's fault.)
Presentation logic belongs in the application. Everything else belongs in the database.
Some carriers already use GPS and satellite for tracking their trucks -- it's a selling point in hiring that drivers need not maintain paper logbooks.
Sure, that's what property taxes are for. That's also not how California's property taxes work.
California Proposition 13 capped property tax valuation increases at a maximum of 2% per annum, with the valuation of the property being reassessed when sold. Two adjoining houses owned by Warren Buffett in Laguna Beach in 2003 had effective tax rates that vary by a factor of 10, because one was bought in the 70's while one was purchased in the 90's.
(http://www.berkshirehathaway.com/wsj.html for more details)
California needs greater tax equity, as its current property tax philosophy boils down to "sock it to the new guy".
http://pages.ebay.com/aboutebay/thecompany/executi veteam.html#Whitman
Meg Whitman
President and CEO of Ebay
I'm pretty sure Ebay is every bit as powerful and important as HP might have been once.
Perhaps you've missed this, but one way to be the best is throught the process of elimination.
An only child must by definition be the favorite.
Sure they make plenty -- provided one is plenty.
EA is currently the only game in town for a college football product, and even that is restricted only to consoles. One cannot purchase a college football game for a PC -- the *only* college football game is available on Gamecube, Xbox, and PS2.
One can get FIFA and UEFA games on PC (in the US!), but no college football. Never mind that there are millions of fans of college football who pack stadiums on autumn Saturdays.
It's bordering on criminal. I imagine that EA bought out exclusive NCAA rights in 2002 or 2003, because I don't remember having seen the NCAA Gamebreaker or NCAA 2K(n) games for a couple of years now.
Some software (such as AutoCAD, e.g.) ensures that printouts generated indicate that the work was generated with an educational product. It's not nagware or even really crippleware -- more like tattleware.
When a lawyer's compensation is deferred until after judgment and is predicated on winning the case (and the phat lewt which accompanies it), that's called taking the case on contingency. Pro bono is when a lawyer works for free -- as in beer -- as it's generally working "for the public good", hence the latin abbreviation of "pro bono publico".
Bzzzt. Whether count(key_column), count(1), count(*), or count(non_key_column), Oracle will tend to prefer to perform a fast full scan of the primary key index, never accessing the underlying table. Obviously, this depends on little things like how the optimizer's been tuned, whether there are optimizer statistics, and the version of Oracle.
I'm fairly certain it's not *that* simple -- nothing ever is.
Selling the rights for a flat fee would be criminally stupid on the part of the original developer/publisher or MacSoft's part. There would be some shared reward, more like:
$500,000 up front for the rights,
then $2 per unit for the first 100,000 units,
then $4 per unit for the next 100,000 units,
and $5 per unit for all other units.
Shared profit, mitigated risk.
I'm also sure there's lots and lots of review to ensure that the Mac product/version faithfully reproduces the experience. No one would simply sign away their IP to MacSoft, where MacSoft would then have total control.
That review of the final product costs money and time, both of which are seldom in simultaneous supply from both publisher and original developer.
I believe that Mac fans should hitch their wagon to Linux, and argue for Linux/Posix versions, where the Mac version in an emulated/unix native mode. At least then the breakdown of the market isn't 98-2, it's anywhere from 90-10 to 75-25, and then you're talking about a large enough segment of the market to matter to the publishers.
If Mac ports were free (or purely profitable), every game would have one. The fact that every game doesn't yields one of the following conclusions:
1. There's a conspiracy against the Mac as a gaming platform; or
2. Developers and publishers are too stupid to take free money; or
3. The original hypothesis is flawed.
My money's on #3, but Brent Sienna's is on #1.
Shortsidedness is the quality of a golf shot that misses the green near the flag, resulting in a more difficult chip. To hit such a shot is to shortside onesself.
Of course, that posits that there are such software houses in great quantity that consider the Mac platform a significant market *worth* supporting with time and money.
The value of GameSpy to consumers is a function of the number of other GameSpy users. Do we really believe that eliminating Mac users significantly alters the number of GameSpy users?
... make a decision that inconviences the few while allowing them to realign development resources better. I mean, it's like they're considering things like shareholder value.
The Brent Siennas of the world who are all aflutter about this need to realize that the Mac as a gaming platform is a downright miniscule niche, and one that probably takes nearly the same number of resources to support as any other platform. However, the return on investment derived from that platform is probably negative, and any Mac gamer probably does their hardcore gaming elsewhere because they're not willing to wait months or years for the popular games to finally be ported.
GameSpy feels, rightly or wrongly, that this decision is in their best interest, and I'm pretty confident they've done those suit-like activities like market analysis and return on investment analysis to back up their decision. I'm further pretty sure that the Think Different crowd hasn't, and is motivated solely by their want -- no, need -- not to be considered second-class citizens in the gaming world.
If the Mac were a strategic focus for GameSpy, they probably wouldn't have made the decision to drop support -- companies tend to be willing to tread water for markets and products they consider of primary current or future importance.
Anyone here who isn't a Mac zealot really consider the Mac as a gaming platform to be of primary importance?
Here's a parallel -- I'd venture that the Mac share of the computer gaming market (excluding consoles) is on par with SCO's share of the X86 server market.
If major software vendors dropped support for SCO, would there be the same hue and cry?
Never figured out how to use the shift button, didja? Or was it the putting your sword away and jumping into the mirror that you were never able to figure out?
Prince of Persia and its direct ancestor, Karateka, were fabulous. Hell, I still pull them up on the old ][e emulator from time to time.
I bet you find the special effects in _Star Wars_ super-crappy, too.
An excellent point -- however, I was quick-and-dirtying the logic.
Further, IIRC, each of the tables foo/bar/baz could have a single trigger which fires under different conditions (insert/update on baz, update/delete on foo) so that you don't have to have multiple triggers.
Of course, you could also have multiple triggers on a single table, each of which only fires on insert/update/delete of a specified column -- then you wouldn't have "all or nothing" if your RI is being administered through triggers.
I agree that it's hard to get right -- generally, such issues are design-related, as a cleaner or simpler design eliminates if-then-else RI.
Exactly what about Oracle's constraints do you not consider featureful?
(and further, logic too complicated for a simple constraint, such as if column A = 1 then column B's value must be a key in table foo, else it must be a key in table bar, can be implemented fairly simple as a PL/SQL trigger).
And on the moderation-front... the fact that you cannot moderate a thread where you participate functionally selects for ignorant moderators, as the informed speak and the ignorant try to determine who's right.
... dude looks like a yet-ti...
Perhaps if he shaved occasionally UDB for Unix/Linux/Windows wouldn't be the crufty mess it is today.
I never said it wasn't a hack or somewhat inefficient -- but it's the best way to get that done in systems which don't support sequences.
Sadly, most people who work in systems without sequences never even consider their existence, so they use identity/autoincrement columns indiscriminately, and you can't undo that kind of design decision simply.