Re: [Wikitech-l] Open source mobile image recognition in Wikipedia
Hello Jonas, Similarly, I guess that the search complexity of your hash approach is o(1) while in Pastec this is much more complicated: first tf-idf ranking and then two geometrical rerankings... Close to o(1) at least. How does Pastec scale to many images? You mentioned having about 400,000 currently, which is still a rather fair number, but what about the full ~22M of Wikimedia Commons? I'm assuming that since tf-idf is a well known method for text mining, there are well understood and optimised algorithms to search. Perhaps something like Elasticsearch would be useful right away too? That would be an advantage, since with our blockhash, we've had to implement relevant search algorithms ourselves lacking existing implementations. The tf-idf method used in Pastec is an adaptation of the algorithm for image ranking. So unfortunately, it seems also complicated to reuse implementations designed for texts. To return results in real-time, the Pastec index must fit into the RAM. Having about 1M images per instance seems possible but to target the 22M of Wikimedia Commons, several instances running on several servers would be required. Where there is many images on an instance, the search times also increase significantly. One problem that we see and which was discussed recently on the commons-l mailing list, is the possibility of using approaches like yours and ours to identify duplicate images in Commons. We've generated a list of 21274 duplicate pairs, but some of them aren't actually duplicates, just very similar. Most commonly this is map data, like [1] and [2], where just a specific region differ. I'm hypothesizing that your ORB detection would have better success there, since it would hopefully detect the colored area as a feature and be able to distinguish the two from each other. Unfortunately, ORBs won't help you more here. They are computed only on the luminance place and are located at edge zones. They aim at retrieving similar images and in your example, the two images are perfect candidates for that. In general, my feeling is that your work with ORB and our work with Blockhashes complement each other nicely. They work with different use cases, but have the same purpose, so being able to search using both would sometimes be an advantage. What is your strategy for scaling beyond your existing 400,000 images and is there some way we can cooperate on this? As we go about hashing additional sets (Flickr is a prime candidate), it would be interesting for us if we could generate both our blockhash and your ORB visual words signature in an easy way, since we any way retrieve the images. Currently, I am not planning to scale a lot over ~1M images as I do not have the computational resources. I think that your small hash approach, despite less robust to image modifications, is way more adapted to target such databases. It would be possible to store and search the index on disk but that would be very slow and thus not practical. Best regards, -- Adrien Maglo Pastec developer http://www.pastec.io +33 6 27 94 34 41 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Which old RFCs to discuss on next week's RFC chat
So, Chad wants to talk about getting rid of actions. Anyone want to discuss any of the other RFCs? If not, how about we just declare them closed/stalled/abandoned or whatever? -- daniel Am 04.12.2014 22:41, schrieb Daniel Kinzler: Hi all! The Architecture Committee, and especially Tim, has been going through the RFC backlog over the last moths. Many where discussed at the weekly RFC chat on Wednesdays, and most of these were resolved. But there are some rather old RFCs left, for which it's a bit unclear whether anyone is still interested in discussing them. So, if you like, go through the list below and tell us whether you would like to discuss an RFC, or think it should be abandoned, or amended, or rewritten, or whatever. * https://www.mediawiki.org/wiki/Requests_for_comment/Refactor_on_File-FileRepo-MediaHandler This is a proposal to refactor media handling code. In particular, it proposes to split backend tasks performed by MediaHandler from UI related tasks. * https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_of_page_views_and_special_pages This is a proposal to move away from action= in favor of Special pages. Perhaps obsolete, since action handling was rewritten since? * https://www.mediawiki.org/wiki/Requests_for_comment/Itemise_protection This argues that we should support multiple protections to apply to a page at once, e.g. indefinite semi-protection and at the same time a short-term full protection. I'd personally like to discuss this as part of a larger refactoring that would implement protection based on our permission system. Basically, applying protection would mean overriding which group has which permissions on a given page. * https://www.mediawiki.org/wiki/Requests_for_comment/Regex-based_blacklist A proposal to overhaul SpamBlacklist (from 2008). I'd personally be more interested in integrating this with (a rewrite of) AbuseFilter. We could have multiple lists, accessible from AbuseFilter rules. There are also some RFCs that relate to organizational issues rather than MediaWiki features and architecture as such: * https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation Automatically compose RELEASE-NOTES based on special lines in the git commit message. I like the idea! * https://www.mediawiki.org/wiki/Requests_for_comment/Distribution_and_deployment This looks like a grand design, with very little information about what exactly it is supposed to do, and how. It's from 2010 and marked incomplete. Anyone interested? * https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation This is about creating a governance group for MediaWiki, separate from Wikimedia. The release management for MediaWiki has since been moved to Mark Hershberger and Markus Glaser, but I don't know much about their arrangement with WMF. Is there still demand for a MediaWiki Foundation? Some good ideas here, and some old cruft. I think the most important factor in deciding what to discuss is to see for which RFCs there are people interested in working on them. So, please give us some feedback, ideally until Monday, so we can plan the RFC chat for Wednesday . Cheers, Daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
Seeing no reply here, I've now submitted https://gerrit.wikimedia.org/r/178527 to revert the API change and to update the UI message. On Mon, Dec 1, 2014 at 8:30 PM, Chris Steipp cste...@wikimedia.org wrote: Hi list, I wanted to get some feedback about https://phabricator.wikimedia.org/T74222. In the last security release, I changed the return of the api to remove the action for log entries that had been revdeleted with Hide action and target. However, ever since 2009 / r46917, we've assumed that Hide action and target didn't mean the actual action field in the db, but rather the target and the text of the message about the action, which might include other parameters. So the message about what's being hidden and the intended protection of that option could have slightly different interpretations. I'd like to hear if anyone has intended for the actual log action to be deleted / suppressed. If not, I'm happy to revert the recent patch, and we'll just update the wording in the deletion UI to be more clear about what is being removed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Which old RFCs to discuss on next week's RFC chat
Not sure who is allowed to comment here, so I hope mentioning a +1 to the ones which I understand sufficiently and like might be okay. On Dec 4, 2014 10:41 PM, Daniel Kinzler dan...@brightbyte.de wrote: Hi all! ... * https://www.mediawiki.org/wiki/Requests_for_comment/Itemise_protection This argues that we should support multiple protections to apply to a page at once, e.g. indefinite semi-protection and at the same time a short-term full protection. I'd personally like to discuss this as part of a larger refactoring that would implement protection based on our permission system. Basically, applying protection would mean overriding which group has which permissions on a given page. This makes a lot of sense imo. * https://www.mediawiki.org/wiki/Requests_for_comment/Regex-based_blacklist A proposal to overhaul SpamBlacklist (from 2008). I'd personally be more interested in integrating this with (a rewrite of) AbuseFilter. We could have multiple lists, accessible from AbuseFilter rules. Imo not obsolete... There are also some RFCs that relate to organizational issues rather than MediaWiki features and architecture as such: * https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation Automatically compose RELEASE-NOTES based on special lines in the git commit message. I like the idea! Me too :-) Rupert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Which old RFCs to discuss on next week's RFC chat
Am 09.12.2014 17:41, schrieb rupert THURNER: Not sure who is allowed to comment here, so I hope mentioning a +1 to the ones which I understand sufficiently and like might be okay. Anyone show is interrested in dicussing an RFC can chime in here. If you are willing to *work* on an RFC, please say so too. Thanks for the input Rupert! -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Code-in: First week achievements!
Google Code-in (GCI) has been running for only one week and students have already resolved 35 Wikimedia tasks! Some of the achievements: * Citoid offers export in BibTeX format (and more contributions) * Analytics' Dashiki has a mobile-friendlier view * Echo's badge label text has better readability; Echo uses the standard gear icon for preferences * Wikidata's Wikibase API modules use i18n for help/docs * Two MW extensions got patches to not use deprecated i18n functions * MW displays an error when trying to create a self-redirect * The sidebar group separator in MW's Installer looks like in Vector * Our Phabricator docs have video screencasts and an updated Bug report life cycle diagram * Huggle's on-wiki docs were updated; exceptions received cleanup * Pywikibot's replicate_wiki supports global args; optparse was replaced by argparse * Reasons for MW sites listed as defunct on WikiApiary were researched * We got logo proposals for the European Wikimedia Hackathon 2015 * ...and many more. Sounds good? Then please spend 5 minutes to go through your tasks and identify simple tasks to allow more young people contribute! Got an idea for a task? Become a mentor for that task! And spread the word to other community members who might be good mentors! Read https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner and please contact me if you need help. Thank you! andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] A new extension of content tree about Wikipedia
Hi all! I am thinking about a new idea about a content tree extension of web/desktop/computer Wiki. When I use mobile phone to access website of Wikipedia, I can fold and unfold a content item of the content tree. That's very convenient. However, when I use computer to access Wiki, there is no such feature, I can not fold or unfold a content item. So shall we add this feature from mobile Wiki to the web/computer Wiki? In other words, let the user able to fold and unfold any content item at any level of the content tree. For example, I search Taipei, I get 1. History, 2. Geography, 1.1 First settlements, and 1.2 Japaneses rule ect. So I would like to able to unfold 1. History, and 1.1 First settlements, or I just unfold 1. History and fold 1.1 First Settlements to see 1.2 Japanese rule which is unfolded. So I would like to fold and unfold any level content items to further the visit quality. The mobile side wiki also can improve, since it can only fold and unfold the first level content item. Also,add a go-back button which let the user go back to the content tree from any content item of any level in the content tree. Eallan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new extension of content tree about Wikipedia
On Dec 9, 2014 1:35 PM, Eallan h.yi...@gmail.com wrote: Hi all! I am thinking about a new idea about a content tree extension of web/desktop/computer Wiki. When I use mobile phone to access website of Wikipedia, I can fold and unfold a content item of the content tree. That's very convenient. However, when I use computer to access Wiki, there is no such feature, I can not fold or unfold a content item. So shall we add this feature from mobile Wiki to the web/computer Wiki? In other words, let the user able to fold and unfold any content item at any level of the content tree. For example, I search Taipei, I get 1. History, 2. Geography, 1.1 First settlements, and 1.2 Japaneses rule ect. So I would like to able to unfold 1. History, and 1.1 First settlements, or I just unfold 1. History and fold 1.1 First Settlements to see 1.2 Japanese rule which is unfolded. So I would like to fold and unfold any level content items to further the visit quality. The mobile side wiki also can improve, since it can only fold and unfold the first level content item. Also,add a go-back button which let the user go back to the content tree from any content item of any level in the content tree. Eallan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Im unsure that would be wanted on the desktop wiki. Desktop doesnt have the space constraints of mobile, and extra clicks should usually be avoided if possible. --bawilff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] All non-api traffic is now served by HHVM
On 03/12/14 18:03, Giuseppe Lavagetto wrote: Hi all, [CUT] The API traffic is still being partially served by mod_php, but that will not be for long! As promised, all our API traffic is on HHVM as well as of now. The effects on CPU usage have been quite drastic on this cluster, where the load is higher: http://bit.ly/1Abwwzi Cheers, Giuseppe -- Giuseppe Lavagetto Wikimedia Foundation - TechOps Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
Speaking from my experience as an oversighter, I find it a bit strange that when you oversight something, information that is hidden in the UI is not hidden in the API. That notwithstanding, there is nothing particularly private about the information that is shown in the API only (i.e. the type of the action), but I found it strange. I also find it strange that the fact that this information is still available via the API is not mentioned in the interface. I've been an oversighter for many, many years, and I never knew that this information could be retrieved via the API. Personally, I prefer the way things are after Chris's change. It makes the UI and API more consistent with each other. That said, given that there is no particularly private information given out in the API response, I don't think it's worth complaining about Brad's patch. It's not the way I'd prefer it to be, but it doesn't personally strike me as overtly incorrect or as causing any real problems. Dan On 1 December 2014 at 17:30, Chris Steipp cste...@wikimedia.org wrote: Hi list, I wanted to get some feedback about https://phabricator.wikimedia.org/T74222. In the last security release, I changed the return of the api to remove the action for log entries that had been revdeleted with Hide action and target. However, ever since 2009 / r46917, we've assumed that Hide action and target didn't mean the actual action field in the db, but rather the target and the text of the message about the action, which might include other parameters. So the message about what's being hidden and the intended protection of that option could have slightly different interpretations. I'd like to hear if anyone has intended for the actual log action to be deleted / suppressed. If not, I'm happy to revert the recent patch, and we'll just update the wording in the deletion UI to be more clear about what is being removed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Results of the MediaWiki-Vagrant Survey
Hey all, Thanks again to everyone who participated in the recent MediaWiki-Vagrant survey. Your responses have given us some great insight into how we might improve upon this already invaluable developer tool. A broad summary of the results has been published to MW.org, along with the (further anonymized) data for anyone who's interested.[1] I tried to keep the summary short and sweet but the even shorter and sweeter (tl;dr) is: users of MW-Vagrant are highly satisfied with it overall but there are some improvements to be made in terms of stability, performance, and provisioning speed. Cheers, Dan [1] https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Surveys/2014Q4 -- Dan Duvall Automation Engineer Wikimedia Foundation http://wikimediafoundation.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A new extension of content tree about Wikipedia
Im unsure that would be wanted on the desktop wiki. Desktop doesnt have the space constraints of mobile, and extra clicks should usually be avoided if possible. --bawilff This feature will not add extra clicks, because you can set unfolded as the default status, when you want to fold some content items, then you clicks. Eallan On Tue, Dec 9, 2014 at 12:34 PM, Eallan h.yi...@gmail.com wrote: Hi all! I am thinking about a new idea about a content tree extension of web/desktop/computer Wiki. When I use mobile phone to access website of Wikipedia, I can fold and unfold a content item of the content tree. That's very convenient. However, when I use computer to access Wiki, there is no such feature, I can not fold or unfold a content item. So shall we add this feature from mobile Wiki to the web/computer Wiki? In other words, let the user able to fold and unfold any content item at any level of the content tree. For example, I search Taipei, I get 1. History, 2. Geography, 1.1 First settlements, and 1.2 Japaneses rule ect. So I would like to able to unfold 1. History, and 1.1 First settlements, or I just unfold 1. History and fold 1.1 First Settlements to see 1.2 Japanese rule which is unfolded. So I would like to fold and unfold any level content items to further the visit quality. The mobile side wiki also can improve, since it can only fold and unfold the first level content item. Also,add a go-back button which let the user go back to the content tree from any content item of any level in the content tree. Eallan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
Thanks, Dan... I was going to ask about that, too. I don't understand well enough what is and isn't visible in the API, but I will say that if the API is linking an action (i.e., suppression) to a user (i.e. the specific oversighter) I *do* have a problem with it; we've had experience in the past with people actively harassing oversighters because of legitimate suppressions they've carried out, and perhaps this is exactly how they've found out it was Oversighter A who did that particular suppression. Risker/Anne On 9 December 2014 at 14:01, Dan Garry dga...@wikimedia.org wrote: Speaking from my experience as an oversighter, I find it a bit strange that when you oversight something, information that is hidden in the UI is not hidden in the API. That notwithstanding, there is nothing particularly private about the information that is shown in the API only (i.e. the type of the action), but I found it strange. I also find it strange that the fact that this information is still available via the API is not mentioned in the interface. I've been an oversighter for many, many years, and I never knew that this information could be retrieved via the API. Personally, I prefer the way things are after Chris's change. It makes the UI and API more consistent with each other. That said, given that there is no particularly private information given out in the API response, I don't think it's worth complaining about Brad's patch. It's not the way I'd prefer it to be, but it doesn't personally strike me as overtly incorrect or as causing any real problems. Dan On 1 December 2014 at 17:30, Chris Steipp cste...@wikimedia.org wrote: Hi list, I wanted to get some feedback about https://phabricator.wikimedia.org/T74222. In the last security release, I changed the return of the api to remove the action for log entries that had been revdeleted with Hide action and target. However, ever since 2009 / r46917, we've assumed that Hide action and target didn't mean the actual action field in the db, but rather the target and the text of the message about the action, which might include other parameters. So the message about what's being hidden and the intended protection of that option could have slightly different interpretations. I'd like to hear if anyone has intended for the actual log action to be deleted / suppressed. If not, I'm happy to revert the recent patch, and we'll just update the wording in the deletion UI to be more clear about what is being removed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
On Tue, Dec 9, 2014 at 2:01 PM, Dan Garry dga...@wikimedia.org wrote: Speaking from my experience as an oversighter, I find it a bit strange that when you oversight something, information that is hidden in the UI is not hidden in the API. There's little reason we couldn't surface this information in the web UI, and in fact I almost did when working on this change. But I ran into trouble figuring out what exactly the enhanced watchlist was doing with the grouping and decided it wasn't worth the trouble to figure it out. There's actually a good bit of information that is available from the API that isn't in the web UI (or isn't very visible there). For example, history pages only display timestamps to the minute while the API gives resolution to the second. The timestamp when a page was added to a category isn't exposed in the web UI either, as far as I know, nor are sha1 hashes of revisions, files, and so on. Or are you referring to how the RevDel checkboxes were labeled Hide action and target? That's being fixed. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
On Tue, Dec 9, 2014 at 2:33 PM, Risker risker...@gmail.com wrote:
Thanks, Dan... I was going to ask about that, too. I don't understand well
enough what is and isn't visible in the API, but I will say that if the API
is linking an action (i.e., suppression) to a user (i.e. the specific
oversighter) I *do* have a problem with it; we've had experience in the
past with people actively harassing oversighters because of legitimate
suppressions they've carried out, and perhaps this is exactly how they've
found out it was Oversighter A who did that particular suppression.
No, that's not what this is about.
Consider a log entry such as (taken from my local test wiki):
13:33, 5 December 2014 Anomie (talk | contribs) deleted page
MediaWiki:Revdelete-hide-name (Use default message)
In the API, that information is represented like this:
{
logid: 2412,
action: delete,
ns: 8,
title: MediaWiki:Revdelete-hide-name,
pageid: 0,
logpage: 1016,
type: delete,
user: Anomie,
timestamp: 2014-12-05T18:33:23Z,
comment: Use default message
},
If someone does a RevDel on that log entry and chooses the poorly-described
Hide action and target checkbox, the log entry is now displayed like this:
13:33, 5 December 2014 Anomie (talk | contribs) (log details removed) (Use
default message)
And in the API (before T74222 and after the proposed revert), we get the
following information:
{
logid: 2412,
actionhidden: ,
type: delete,
action: delete,
user: Anomie,
timestamp: 2014-12-05T18:33:23Z,
comment: Use default message
},
All this mess is because someone noticed that the poorly-described checkbox
says Hide action but the API was still reporting that the subtype (here
named 'action') is delete (versus restore, revision, etc).
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
On Tue, Dec 9, 2014 at 11:46 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: All this mess is because someone noticed that the poorly-described checkbox says Hide action but the API was still reporting that the subtype (here named 'action') is delete (versus restore, revision, etc). I don't think action was ever truly hidden in the UI; obscured at best. The li elements for the log items still get an mw-logline-action class even if the action is suppressed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visibility of action in API for deleted log entries
There's actually a good bit of information that is available from the API that isn't in the web UI (or isn't very visible there). For example, history pages only display timestamps to the minute while the API gives resolution to the second. You can actually get up to the second resolution if you change your prefs. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] All non-api traffic is now served by HHVM
On 12/3/14, Giuseppe Lavagetto glavage...@wikimedia.org wrote: Hi all, it's been quite a journey since we started working on HHVM, and last week (November 25th) HHVM was finally introduced to all users who didn't opt-in to the beta feature. Starting on monday, we started reinstalling all the 150 remaining servers that were running Zend's mod_php, upgrading them from Ubuntu precise to Ubuntu trusty in the process. It seemed like an enormous task that would require me weeks to complete, even with the improved automation we built lately. Thanks to the incredible work by Yuvi and Alex, who helped me basically around the clock, today around 16:00 UTC we removed the last of the mod_php servers from our application server pool: all the non-API traffic is now being served by HHVM. This new PHP runtime has already halved our backend latency and page save times, and it has also reduced significantly the load on our cluster (as I write this email, the average cpu load on the application servers is around 16%, while it was easily above 50% in the pre-HHVM era). The API traffic is still being partially served by mod_php, but that will not be for long! Cheers, Giuseppe -- Giuseppe Lavagetto Wikimedia Foundation - TechOps Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Awesome. Any chance the video scalars could be put near the top of the list for servers to upgrade Ubuntu on? The really old version of libav on those servers is causing problems for people uploading videos in certain formats. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Which old RFCs to discuss on next week's RFC chat
Daniel Kinzler wrote: Anyone want to discuss any of the other RFCs? If not, how about we just declare them closed/stalled/abandoned or whatever? Why? It's unclear to me what this would accomplish. I'm pretty strongly in favor of treating RFCs the same way that we treat bugs (now tasks): they live or die by their merits alone. It's largely irrelevant who the author is or when the last activity was. What's important is whether the RFC covers a reasonable, implement-able idea. I'd much rather see energy put into finding volunteers to help move these RFCs forward than I would see energy put into closing down discussions. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Our CAPTCHA is very unfriendly
Robert Rohde wrote: I suspect we could weed out a lot of spammy link behavior by designing an external link classifier that used knowledge of what external links are frequently included and what external links are frequently removed to generate automatic good / suspect / bad ratings for new external links (or domains). Good links (e.g. NYTimes, CNN) might be automatically allowed for all users, suspect links (e.g. unknown or rarely used domains) might be automatically allowed for established users and challenged with captchas or other tools for new users / IPs, and bad links (i.e. those repeatedly spammed and removed) could be automatically detected and blocked. I really like this idea. I filed https://phabricator.wikimedia.org/T78113 to make sure it doesn't get lost. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
