|Problems? Is your data what you think it is?|
Run your own perlmonks!by theorbtwo (Prior)
|on Sep 28, 2003 at 16:19 UTC||Need Help??|
This post will probably make me quite unpopular with some people, and quite popular with others. Please, vote your conscience, in any case, it will get the cat out of the bag.
I've always thought that the administration of this site should be more open. In particular, though perlmonks is based on an open source engine, and is about an open source language, it is not open source. I've tried to talk about this before, most notably in Let the doors open wide!, but I think it's time to say it again, and hopefully write it better. Also, this time, I have working (if ugly as hell, and incomplete) code to share... yes, on a social post.
The code is what gives the title to this node. It's a pair of scripts (at present), which make it possible to fetch nodes from PM, and put them into a DB in the same form. To put it simply, this will allow you to clone PM... if you have the rights to read the relevant bits. (The code itself will be in a reply, because I can edit it better that way.)
That brings me to my other point. For the majority of the users of this site, this code will be of no use. This is because the nodes that form most of the infrastructure of this site, you cant read. I think this is a terrible shame. We have here a community of motivated hackers, who know the language that PM is implemented in. We have a body of software. Why not apply one to the other?
There is currently a group called pmdev. Users in this group can read most of the site's code, and can write patches to be considered by the gods, and possibly apply. Note that they do not have the power to find out anything about a user, or a user's node, that they would not have the power to see anyway. They do not have the power to change nodes, or code, they can only suggest it.
This limit to their power means that, barring bugs, they have no power to mess up the site, or find out confidential information.
There are two reasons that these powers are reserved for pmdevils. The first is the fear of bugs. There have, in the past, been times when security flaws were found in PM code, specificly SQL injection flaws. These bugs can be read with pmdev access, and then used. For that matter, if discussion of security holes was public, they could be exploited between discovery and fix.
The software development community has, in general, decided that these arguments are poppycock. The security flaws will be found sooner or later by people guessing at them. The people who guess at them are less likely to behave nicely. As to the window between when a flaw is discovered and when it is announced, that will get shorter if the flaw is public, now won't it. Security through obscurity may make you sleep better at night, but it's hardly security.
The other reason is that there are already more patches then the gods know what to do with. More eyeballs would make that worse, not better. My response to this takes several forks. The first is that more gods should help, or the ones we have could take some interest. The second is that patches should be votable on, and replyable to. The current structure of things allows for discussion, but does not make it easy, nor open. IMnsHO, the things currently spoken about on the pmdev wiki should be talked about in the (public) perl monks discussion. Getting patches to be public, commentable, and votable would take some work, but IMHO the work is well worth it. For that matter, it would become easier, and more likely to happen, as more people could see the code and do the work.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).