Talk:Critical views of MediaWiki
From Wikinfo
rant
re. the GFDL corpus: I admit I have not read enough about it to figure out what it is. This is true of the entire corpus (corpora?) of GNU-derived licensing schemes. This is due mainly to the fact that I am not an attorney. In terms of techniques of freeing, dispossessing, copylefting or 'licensing' content, my personal preference/choice, at least for venues not already covered by some other content 'licensing' scheme, has been the Cypherpunks' Anti-License. Of all the many alternatives to conventional copyright that have been concocted, the CAL is the only one I have found so far that is stated in terms I understand clearly.
re. the Rube Goldberg nature of MediaWiki implementation: I had no idea. If they value complexity for its own sake, though, why migrate from the Byzantine Perl to the allegedly elegant PHP? I disclaim that I know nothing of PHP except what it says in the Wikipedia article on PHP, and I don't understand even that. My computer skills are sadly outdated. What little such skills I possess I acquired in the gloriously innocent early 90's 'taking classes' in a misguided attempt to somehow change my major, retroactively, from the udderly useless field of mathematics to the putatively applicable one of computer science.
re. Wikia: As the apparent author of the present main-article is most likely aware, I have become addicted to Wikia. In this context I mean addicted not in the sense of compulsive so much as addicted in the sense of dependent. My informational agenda going on six years has consisted of attempts to weasel into the 'marketplace' (ugh!) of ideas at least a little serious discussion of the concept of seriously open source (and method, of course) implementation of serious data mining. So far I've been talking to myself, and the 'project' probably looks to the uninitiated (pretty much anyone) like the agnostic take of the concept of 'prayer.'
Nevertheless, I figured Wikia (then Wikicities) was at worst a more appropriate venue than Yahoo! GeoCities. I appreciated at least the theoretical possibility of advancing the pubwan concept to a small "movement." I also appreciated the more-or-less free-form naming methodology of the non-CamelCase MediaWiki as I was starting to get tired of CamelCasing every (expletive deleted) concept in EmacsWiki. I first encountered CamelCase in early textbooks of Pascal. Back then I thought it was a cute concept. But later CorporateNames rendered in CamelCase became trendy and CamelCase itself became a cliché.
Being a 20th century klutz when it comes to computers, I didn't even realize the reason one never finds backlinks features in those CamelCase WikiEngines I had come to see as without virtue. How simple and elegant. Thanks for the point-out. I have no complaint with the fact that my wikicity/wikium proposal was relegated to 'scratchpad' status. I have no dissatisfaction with the mechanics of scratchpad.wikia.com save the apparent value-subtraction feature of modeling individual wikis/namespaces as MediaWiki objects of the 'Category' class. They inform the general public of this need, but still it seems to serve no purpose other than enforcement by humans of the putative laws of economics. The fact that content hosting is not (in general) a charitable undertaking bothers me not in the least. I am, however, bothered by the fact that more people aren't making more 'hay' about the apparent counterexample to the law of economics that says the laws of economics are self-enforcing. The manual-transmission type imposition of a 'Simon Says' requirement (i.e. make sure you put your Category:Pubwan or whatever in each addition to pubwan scratchpad) for tree/graph growth seems to have a nasty side effect. While exhaustively listing the contents of a wiki/Category is trivially easy to do, even that can require some site navigation to find the jump-off point (page) where that featured is offered. Besides, how does the Wikia implementation of MediaWiki know whether a given scratchpad is too big for such a seemingly unconstrained offering? More troubling, it seems the wiki/Category (i.e. scratchpad) model also doesn't allow for the cardinal feature that, more than any other, makes wikis in general good for anything--the ability to request unmerged single-wiki 'recent changes' lists. The most obvious explanation for this is the obvious fact that you get what you pay for. Actually it is the converse of the statement that is actually true, but you get what I mean. I still figure being dependent on Wikia is a lesser evil than being dependent on Yahoo! I should probably be grateful that overtly pants-down transparentist propaganda such as mine is even tolerated anywhere, given that the fact that information doesn't want to be free is a proven law of science.
What I really can't figure out--Wikia's reasons for being stingy with non-hobbleware are understandable for obvious economics-based reasons. But why are they so generous with bureaucratic privileges? They appointed me bureaucrat-in-chief of the <a href="http:/datamining.wikia.com/">data mining wikia</a> sight unseen, even though I have virtually no background in data mining.
Re. MySQL: I've tried it, but haven't bothered to actually try to use it for something. I read the story of MySQL and learned that its design prioritizes speed over what its author calls 'generality.' Being a Generation-X person of below average salescrittership quotient, my computer skills are limited to textbook concepts, therefore generality seems to me the whole point behind SQL. Certainly the ability to do table joins and set-theoretic queries on the fly is the closest a non-yuppie like me will ever have to 'information sharing,' let alone my pipe dream of recruiting amateur data miners. Clearly I am missing something. If one's need is speed, why not KISS by simply using the UN*X dbm utilities?
One wikia project, called Barcode wikia makes more sense to me as a database system than as a wiki of any flavor. Wikis seem to me limited to concepts that can be expressed in paragraph form. What barcode wikia illustrates is that what the world needs is a port of the wikiconcept from natural language data to tabular (spreadsheet-or-database-format) data. Or at least some built in XML parsing, or at least accommodation of exogenous parses. Granted, bots are probably a bigger free rider problem even than giving away above-scratchpad-level access for free. And what's this about hard-reverse-encoding non-HTML tags as > < (> <) literals????
Check any of my barcode.wikia contribs for a visual explanation. So many potentially powerful applications of the barcode wikia concept would be so much easier without this feature. I won't remove my own XML-mockup contribs for aesthetic reasons (unless of course barcode.wikia management vocally objects to my methods), because a consumer public without barcode indexing, XML parsing, and SQL-querying (hell, data mining capability) may as well be sheep to the slaughter in today's ultra-asymmetric information economy. Just visit a freaking dupermarket, esp. a Kroger's.
Re. talk pages. I decided to post the present talk to talk to avoid putting something of non-encyclopedic tone on a non-talk page. Given that this practice is a good way to bury information, perhaps I should move it to somewhere else. But where? Posting comments below pages would seem to demote wikis to webboards, a seemingly more primitive means of expression. Or do they do it in some scoop or slashdot way that offers for free the services of some kind of 'SNR engine?'
Why, by the way, does MediaWiki insist on initcasing all article titles? Who wants to read about E. e. cummings?
- N8chz
- Your rant is very interesting. I also find the initcasing of titles a bad-bad Wikipedian habit that we are forced to deal with here on Wikiinfo. It seems to me that an encyclopedia would be an example of good title practices... -proteus 13:59, 9 Mar 2007 (EST)
good work
Good work - I'd suggest moving this to Critical views of MediaWiki (which I've already pointed to in MediaWiki), in case there is more than one critical view, as it already looks that way, and it would "match" the Critical views of Wikipedia pageset - indeed, it can be included in it, of course. I plan to help contribute to this, but as I'm a biased party on this topic, I'll first let you flesh out as you think best ;) -proteus 22:50, 17 Aug 2006 (EDT)
mysql criticism misplaced
Kernigh, the MySQL stuff isn't a criticism of MediaWiki, but a slightly incorrect argument for another page. SQL in general, and especially MySQL, is way faster than any flat file system, and provides a level of tiered storage and security that file systems do not. The problem is that a hugely traffic-pounded site like Wikipedia pushes the limits of any database system, and for us on Wikinfo (where GetWiki also proudly uses MySQL), the shared-host environment means that the dataabase server is overworked for another reason. A MS SQL or Oracle server would fair no better, and a flat file system would crash Apache. Debate of the argument aside, it doesn't quite belong here, but probably on the wiki engine page. -proteus 14:06, 9 Mar 2007 (EST)
