Perhaps we could set up test.wikipedia.org as an ISP-style user script directory, i.e. with open_basedir and disable_functions and all that. We could then make a simple upload form which allows people to upload scripts to it using a web interface.
I'm not suggesting someone else do this, I'm suggesting someone try to talk me out of it, if there's any reason it won't work.
-- Tim Starling.
On Friday, Oct 31, 2003, at 03:30 US/Pacific, Tim Starling wrote:
Perhaps we could set up test.wikipedia.org as an ISP-style user script directory, i.e. with open_basedir and disable_functions and all that. We could then make a simple upload form which allows people to upload scripts to it using a web interface.
I'm not suggesting someone else do this, I'm suggesting someone try to talk me out of it, if there's any reason it won't work.
Part of my concern is simply load management. A script gone wild can thrash through a big database and eat up memory and CPU cycles, while we're _trying_ to serve Wikipedia to the world at large.
Security-wise, in addition to files there's the database and memcached; memcached has no application-level security, so we'd probably want a separate daemon for it. Also the memcached daemon would need to be restarted for some tests to clear out bad data, which again would be better if it didn't interfere with the main servers.
-- brion vibber (brion @ pobox.com)
I tried to send this 12 hours ago but I put the wrong from address on it.
Brion wrote:
On Friday, Oct 31, 2003, at 03:30 US/Pacific, Tim Starling wrote:
Perhaps we could set up test.wikipedia.org as an ISP-style user script directory, i.e. with open_basedir and disable_functions and all that. We could then make a simple upload form which allows people to upload scripts to it using a web interface.
I'm not suggesting someone else do this, I'm suggesting someone try to talk me out of it, if there's any reason it won't work.
Part of my concern is simply load management. A script gone wild can thrash through a big database and eat up memory and CPU cycles, while we're _trying_ to serve Wikipedia to the world at large.
Security-wise, in addition to files there's the database and memcached; memcached has no application-level security, so we'd probably want a separate daemon for it. Also the memcached daemon would need to be restarted for some tests to clear out bad data, which again would be better if it didn't interfere with the main servers.
* Disable set_time_limit * Disable socket_create (in the long term, the restricted scripts could call unrestricted scripts, which check to make sure the first four letters of any memcached key are "test") * Restrict access to the script upload function to only trusted users. * Require these users to not test any feature likely to put strain on the database -- i.e. not more than ordinary page loading/saving. If anyone repeatedly violates this rule, then we take away their access.
Our code is slow because there are not enough people working on optimisation. If there were more people working on it, it would get faster. Our code is also inelegant, poorly commented, and lacks important features. All these things require work, not load management.
-- Tim Starling.
On Saturday 01 November 2003 01:17, Tim Starling wrote:
faster. Our code is also inelegant, poorly commented, and lacks important features. All these things require work, not load management.
I noticed that it is poorly commented but not that it is inelegant. And despite the poor commenting, I could do everything I wanted.
Nikola Smolenski wrote:
On Saturday 01 November 2003 01:17, Tim Starling wrote:
faster. Our code is also inelegant, poorly commented, and lacks important features. All these things require work, not load management.
I noticed that it is poorly commented but not that it is inelegant.
See http://meta.wikipedia.org/wiki/Development_tasks under "code quality".
And despite the poor commenting, I could do everything I wanted.
Well Ed Poor, Fred Bauder, Tarquin, Christopher Mahan and Alfio Puglisi seem to think that more comments/documentation are necessary. So I think that means we put more comments in, even if you, Louis and evidently the people who wrote the code, don't need them.
-- Tim Starling.
On Saturday 01 November 2003 01:17, Tim Starling wrote:
faster. Our code is also inelegant, poorly commented, and lacks important features. All these things require work, not load management.
I noticed that it is poorly commented but not that it is inelegant. And despite the poor commenting, I could do everything I wanted.
It is people such as myself who lack experience in coding, who when they need to change something need the comments, however even the most experienced programers reasonably expect good commenting.
Fred
wikitech-l@lists.wikimedia.org