Hi!
Once there was the size of all Wikipedia database dumps at
download.wikipedia.org. In March 9, 2005 I noticed 50 Gigabytes
compressed (15 for just current). I wonder what the actual numbers are.
I assume the change to XML does not make a big difference because data
is compressed but it don't remember if it was compressed with gip oder
bzip2. Anyway a total number would be interesting to give an impression
of how much information we collect. Can anyone with access to the server
please run a simple shell script to get the size you need if you wanted
to download all wikipedias data?
Thanks and greetings!
Jakob
P.S: by the way 20050713_pages_full.xml.bz2 (29.9G) seems to be the
newest full dump of english wikipedia but I bet you don't need a
Terabyte for all compressed full dumps - yet. I found the first plans
for RAID systems with several Terabytes here:
http://meta.wikimedia.org/wiki/Wikimedia_servers/hardware_orders/wishlist
Hello!
You are receiving this email because your project has been select to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we hope
to make sure that you are either aware of things that might break, or to
make sure we don't introduce any strange regressions. With this effort
we hope to build a better relation between the PHP Team and the major
projects.
If you do not want to receive these heads-up emails, please reply to me
personally and I will remove you from the list; but, we hope that you
want to actively help us making PHP a better and more stable tool.
The third release candidate of PHP 5.1.0 can be found at
http://downloads.php.net/ilia/. This is not a final RC, but we hope it
will be followed by a final RC4 that should be released no later then
October 31st. I'd like to ask you to use this 2 week period to test your
application against this release and let us know about any issues that
you discover. We are particularly interested in backwards compatibility
breaks and new issues appeared in this release, but were not present in
prior 5.1 versions. If you find any issues, please contact the PHP QA
team at "php-qa(a)lists.php.net".
In case you think that other projects should also receive this kinds of
emails, please let me know privately, and I will add them to the list of
projects to contact.
regards,
Ilia Alshanetsky
5.1 Release Master
I've enabled file system caching in my LocalSettings.php (and just to be
safe, in the DefaultSettings.php too) file:
$wgUseFileCache = true;
$wgFileCacheDirectory = "/home/wiki/tmp";
but it is not creating the files in that directory as my older version of
MediaWiki did. I've checked and double-checked all of my permissions, and
everything appears to be setup just as the old version was. Except it's not
creating the cached files on the file system. Which makes me wonder,
can 1.5still use the file system cache?
Thanks!
John
Tony Sidaway wrote:
>On 10/17/05, David Gerard <dgerard at gmail.com> wrote:
>> Note that the NTL problem has been solved (presumably through some
>> horribly ugly special cases in the MediaWiki code) -
>My understanding is that NTL passes the client IP via a standard
>protocol and MediaWiki simply interprets it in the standard manner.
>The only place where it gets hairy is that, as I understand it, some
>anonymizing proxies also use this protocol and forward a spoofed IP,
>so you do need to maintain a list of proxies that can be trusted.
Semi-standard - it uses an X-Forwarded-From header and sometimes it
reverses the order of the octets (for no good reason).
That said, I just spotted a MARMOT sock (User:Captain Kreuk and a few
others) with his IP showing as the NTL proxy address, not his actual
address. Bother.
(cc'd to wikitech-l - is this a reportable bug, or hadn't the
NTL-checking code kicked in at that point?)
- d.
Is it possible to have the logged-in-user page view cached too?
What is the ratio of logged-in-user/total page request (among viewing of normal, cacheble page)
For a fixed skin and language what are the things that change on a logged-in user?
*the name of the user and the link to his/her user page (and similar)
*the move link (but this is always the same)
*the watch/unwatch link
Is there something more?
One more question: which is the part (Apache, Squid, Database, etc) which is at the moment the limiting factor in the MediaWiki cluster?
AnyFile
--
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/
The option "rename user" is disappeared. Any hope we will see it return?
--
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be
I'm using MediaWiki to create a corporate wiki, and need to allow access to certain pages only to certain groups. I don't see full support for this in MediaWiki as of 1.4.11 (although there is stub support- you can do this for moderators). Unless this has already been implemented for 1.5 or there is already a 3rd party patch, I'm going to implement this myself, and will be pushing for (and almost will certainly get) permission to give this change back to the community. While Wikipedia may not use it, it would be a nice feature for the wiki in general. And if it brings in more corporate users, those users may always contribute back more useful changes.
This brings me to how to implement this. I have a few ideas, if anyone can comment on them.
Part 1- storing restrictions
I can either use the cur_restricted field of the cur table, or create a new table that has a pair (pagename,group). If the pagename has restrictions, you would need to be in one of those groups. If there were no restrictions, it would default to open. Which of these ways sounds preferable? I sort of like the new table, since then lookups on old versions wouldn't need to access the cur table for restrictions data.
Part 2- storing groups
A new table with pairs (user id, groupname). A user can be in any number of groups.
Part 3- applying restrictions
Any time someone tries to access cur_text, they need to check against permissions. If they fail, they should not actually read the text. Do only Article and EditPage need this protection, or will it need to go elsewhere as well?
I'm thinking of implementing this as a new class (Permission) with a two methods- checkPermission($user,$title) that will return TRUE if user can access the title, and FALSE if not On a FALSE, the calling code will need to push an error up the call stack in whatever way is appropriate. Probably a web page saying that the page is protected, and listing the groups.
The other function is groupList($title) that will return the list of groups with permission to read it. Its there to allow callers to get allowed groups for the error page. (Alternatively, Permission could generate an error page, but that sounds messy).
Part 4- editing permissions
An extra box on the edit page, with a list of groups. Add a group to add it to the restricted to list. You must have edit permissions (in other words, you must be in one of the previously allowed groups or be an admin/beauracrat) to add or remove a group.
Part 5- adding people to groups
Basicly, this is a special page. I'll probably allow, as a basic method, any admin, beauracrat, or existing group member to add you to a group. I'm not as interested in this part of the problem, as I'll be getting my groups from /etc/group.
Any comments on how I plan to implement this? Or if it already exists and I'm being a moron (or missing a 3rd party patch somewhere), please help me out.
Gabe