On Sat, Jan 9, 2010 at 11:40 PM, Aryeh Gregor
> wrote:
> On Sat, Jan 9, 2010 at 11:26 PM, Anthony wrote:
> > Depends on the machine's securelevel.
>
> Google informs me that securelevel is a BSD feature. Wikimedia uses
> Linux and Solaris.
Well, Greg's comment wasn't specific to Linux or Sola
On Sat, Jan 9, 2010 at 11:26 PM, Anthony wrote:
> Depends on the machine's securelevel.
Google informs me that securelevel is a BSD feature. Wikimedia uses
Linux and Solaris. It might make sense to have backups be sent to a
server that no one has remote access to, say, but the point is that
the
On Sat, Jan 9, 2010 at 11:09 PM, Aryeh Gregor
> wrote:
> On Fri, Jan 8, 2010 at 9:40 PM, Anthony wrote:
> > Isn't that what the system immutable flag is for?
>
> No, that's for confusing the real roots while providing only a speed
> bump to an actual hacker. Anyone with root access can always j
On Sat, Jan 9, 2010 at 7:54 AM, Bryan Tong Minh
wrote:
> These could all be readily migrated to the API. However, this would
> mean that they will become unavailable if the API is disabled. Would
> that considered to be a problem?
No. At this point we should remove $wgEnableAPI and set it to tru
On Fri, Jan 8, 2010 at 9:40 PM, Anthony wrote:
> Isn't that what the system immutable flag is for?
No, that's for confusing the real roots while providing only a speed
bump to an actual hacker. Anyone with root access can always just
unset the flag. Or, failing that, dd if=/dev/zero of=/dev/sda
Casey Brown wrote:
> On Fri, Jan 8, 2010 at 4:14 PM, Lars Aronsson wrote:
>> Exactly! This is poor design. I have an account (through SUL)
>> on the Ukrainian Wikipedia because I sometimes add interwiki
>> links there. I want the same gadgets there, but I don't speak
>> Ukrainian and I can't go ar
Hi!
I have an extension, which submits and renders polls defined with parser
tag hooks. To have the article view properly re-generate dymanical
content of tag, the typical approach is to use $parser->disableCache()
in hook's function. However, in my case, the dynamically generated
content is ch
On Sat, Jan 9, 2010 at 5:03 PM, Daniel Kinzler wrote:
> Bryan Tong Minh schrieb:
>> Hi,
>>
>>
>> As you may know there are currently two entry points in MediaWiki for
>> javascript that wants to perform certain actions, action=ajax and
>> api.php. Only the following features still use action=ajax:
* Gregory Maxwell [Fri, 8 Jan 2010 21:06:11 -0500]:
>
> No one wants the monolithic tarball. The way I got updates previously
> was via a rsync push.
>
> No one sane would suggest a monolithic tarball: it's too much of a
> pain to produce!
>
> Image dump != monolithic tarball.
>
Why not to extend
2010/1/9 Daniel Kinzler :
> Oh, also: action=ajax supports http cache control. can this be done with the
> api
> yet?
>
Yes, with the maxage and smaxage parameters. AFAIK those are currently
broken on Wikimedia, however, because Squid overrides the caching
headers set by the API.
Roan Kattouw (Ca
Bryan Tong Minh schrieb:
> Hi,
>
>
> As you may know there are currently two entry points in MediaWiki for
> javascript that wants to perform certain actions, action=ajax and
> api.php.
Oh, also: action=ajax supports http cache control. can this be done with the api
yet?
-- daniel
___
Bryan Tong Minh schrieb:
> Hi,
>
>
> As you may know there are currently two entry points in MediaWiki for
> javascript that wants to perform certain actions, action=ajax and
> api.php. Only the following features still use action=ajax: ajax
> watch, upload license preview and upload warnings che
On Sat, Jan 9, 2010 at 9:27 AM, Carl (CBM) wrote:
> On Sat, Jan 9, 2010 at 8:50 AM, Anthony wrote:
>> The original version of Instant Commons had it right. The files were sent
>> straight from the WMF to the client. That version still worked last I
>> checked, but my understanding is that it wa
On Sat, Jan 9, 2010 at 8:50 AM, Anthony wrote:
> The original version of Instant Commons had it right. The files were sent
> straight from the WMF to the client. That version still worked last I
> checked, but my understanding is that it was deprecated in favor of the
> bandwidth-wasting "store
On Sat, Jan 9, 2010 at 5:37 AM, Robert Rohde wrote:
> I know that You didn't want or use a tarball, but requests for an
> "image dump" are not that uncommon and often the requester is
> envisioning something like a tarball. Arguably that is what the
> originator of this thread seems to have been
On Sat, Jan 9, 2010 at 7:44 AM, Platonides wrote:
> Robert Rohde wrote:
>> Of course, strictly speaking we already provide HTTP access to
>> everything. So the real question is how can we make access easier,
>> more reliable, and less burdensome. You or someone else suggested an
>> API for grabb
Hi,
As you may know there are currently two entry points in MediaWiki for
javascript that wants to perform certain actions, action=ajax and
api.php. Only the following features still use action=ajax: ajax
watch, upload license preview and upload warnings check. I don't
really see much point for t
Robert Rohde wrote:
> Of course, strictly speaking we already provide HTTP access to
> everything. So the real question is how can we make access easier,
> more reliable, and less burdensome. You or someone else suggested an
> API for grabbing files and that seems like a good idea. Ultimately
>
On Fri, Jan 8, 2010 at 6:06 PM, Gregory Maxwell wrote:
> No one wants the monolithic tarball. The way I got updates previously
> was via a rsync push.
>
> No one sane would suggest a monolithic tarball: it's too much of a
> pain to produce!
I know that You didn't want or use a tarball, but requ
On Sat, Jan 9, 2010 at 3:49 PM, Tim Starling wrote:
> John Vandenberg wrote:
>> On Sat, Jan 9, 2010 at 12:10 PM, Tim Starling
>> wrote:
>>> Platonides wrote:
What were the reasons for replacing lighttpd with Sun Java System Web
Server ?
>>> Probably the same reason that the toolserver
20 matches
Mail list logo
