[Wikitech-l] Last chance to reboot precise installs in Labs
Hello Labs project maintainers, Today is your last chance to reboot any instances you may be running that have Ubuntu Precise and have not been rebooted since my notification last week! All instances how have a /usr/local/sbin/reboot-if-idmap script installed which, if run by root or with sudo, will reboot any instance iff it still needs to be rebooted. (Specifically, it does the exact feature test and does nothing if it passes). == What happens if you don't reboot == At some point tomorrow (Apr 23, around 14h UTC) idmap[1] will be turned off on the labs storage servers. Instances that are still trying to use idmap will loose the ability to access files in /home and /data/project that are not globally readable (or writable, as the case may be). This may impact processes running on those instances in various ways. Again, only instances that are running Ubuntu Precise and that have not been rebooted (for any reason) since Apr 13, 2015 12h UTC are affected. If in doubt, you can safely run the reboot-if-idmap script - it will have no effect on instances that do not neet reboot or have already been rebooted. Thank you, -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [Foundation-l] Single login - decision 2004
-- Forwarded message -- From: Keegan Peterzell kpeterz...@wikimedia.org Date: Wed, Apr 22, 2015 at 1:34 AM Subject: Re: [Foundation-l] Single login - decision 2004 To: Wikimedia Mailing List wikimedi...@lists.wikimedia.org On Nov 11, 2004, at 03:27:00 UTC , Erik Moeller erik_moel...@gmx.de wrote [1]: Hi, there's been some movement forward on the Single User Login (SUL) issue. I ask the Board to review this mail carefully as this has significant long- term implications and we need Board input to go ahead. I also ask other developers to correct me if I misrepresent anything. There are currently three competing strategies. Before I describe these strategies, let me point out that one important consideration for any system is scalability. That is, single login will be used on all existing and future Wikimedia projects, and potentially even on non-Wikimedia sites which we allow to participate in our system. The three strategies are: 1) GLOBAL NAMESPACE, IMMEDIATE CONFLICT RESOLUTION We try to move towards a single global user namespace for all Wikimedia wikis. If a name is already taken in the global namespace, you have to find one which isn't. For the migration, any names which clearly belong to the same user are combined into one. If passwords and email addresses are different, the user can manually link together any accounts which belong to him by providing the passwords. For cases of true name conflicts between the existing wikis, there is a resolution phase, where factors like seniority, use on multiple wikis vs. a single one, etc., are weighed in - the loser has to choose a new account name. After the manual resolution phase, any remaining accounts are converted to the new system automatically by making them unique, e.g. by adding a number to the username. The transition is now complete. The old system no longer exists. --- 1) is very complex, and we may not find someone willing to deal with the name conflict resolution issue and take the blame from annoyed users at the same time. Naming conflicts will always be an issue in this scheme, as e.g. all common first names will be taken, and any small wiki hooking up with our SUL system would feel this impact. People can mutate these usernames relatively easily to make them unique - Erik333 - and the system can offer such mutations, but it's still a bit annoying. This is now complete [2]. That wasn't too bad. 1. https://lists.wikimedia.org/pipermail/wikimedia-l/2004-November/061327.html 2. https://lists.wikimedia.org/pipermail/wikimedia-l/2015-April/077576.html -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] For the Sake of Simplicity
On Wed, Apr 22, 2015 at 10:45 AM Ori Livneh o...@wikimedia.org wrote: This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product might be smaller or have fewer features than the previous version, and that this property should be considered a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising and classic ideal — less is more. I remove features from MediaWiki all the time. I think the number of new additions outpaces my removals though :p -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] For the Sake of Simplicity
From http://www.artima.com/weblogs/viewpost.jsp?thread=362327 : That software systems are getting bigger and more pervasive is testament that we can at times muster the wherewithal to manage the inherent complexity of constructing large systems. At other times, however, it simply supports the view that creating complexity is far easier than hiding it — the creeping featurism, physical size, and bugginess of certain operating systems and wordprocessing packages is tantamount to a public admission of software engineering failure. To paraphrase Blaise Pascal, The software to solve your problem is larger and more complex than necessary, because we did not have the ability or resources to make it smaller and simpler. [...] In other words, leaving or taking things out by constantly examining the difference between inherent and actual complexity, questioning and reducing the number of features, and questioning and reducing the amount of code. For benighted management that still measures productivity in terms of KLOCs, this is scary: it appears to represent negative productivity. But... less code, fewer bugs... fewer features, greater ease of use... and so on. This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product might be smaller or have fewer features than the previous version, and that this property should be considered a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising and classic ideal — less is more. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] For the Sake of Simplicity
Hi! This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product might be smaller or have fewer features than the previous version, and that this property should be considered a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising and classic ideal — less is more. Apple is doing it from time to time, and is not shy about it. I'm not sure I personally am a big fan, but it works for many people. Another interesting take on the same topic from ESR: http://esr.ibiblio.org/?p=6737 -- Stas Malyshev smalys...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] For the Sake of Simplicity
On 04/22/2015 01:44 PM, Ori Livneh wrote: That software systems are getting bigger and more pervasive is testament that we can at times muster the wherewithal to manage the inherent complexity of constructing large systems. At other times, however, it simply supports the view that creating complexity is far easier than hiding it — the creeping featurism, physical size, and bugginess of certain operating systems and wordprocessing packages is tantamount to a public admission of software engineering failure. To paraphrase Blaise Pascal, The software to solve your problem is larger and more complex than necessary, because we did not have the ability or resources to make it smaller and simpler. +1. Related concept: https://blog.intercom.io/product-strategy-means-saying-no/ . Obviously, it's really about knowing when to say Yes, and when to say No, but both are very important. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC meeting this week
On 04/22/2015 04:41 AM, Tim Starling wrote:
In the next RFC meeting, we will discuss the following RFC:
* Business Layer Architecture on budget
https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architecture_on_budget
Minutes:
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.html
Log:
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.log.html
Summary of the discussion:
There was a fair amount of discussion about how the request/response
model of the MW API (API here meaning api.php modules) should map to
the proposed wfApi (or replacement). Tim was concerned that done wrong
it will not reflect the stateless nature of the API.
People generally agreed that not all code should do SQL.
There was consensus to rewrite the RFC (particularly the assumptions).
There was not consensus on the underlying RFC, though there was some
support for making FauxRequest better.
I, and others, expressed some concern about the lack of type checking
possible in this approach (since every API request is essentially
{action: 'thank', parameters: {}}, rather than
$$thankServiceInstance-thank( $revision ) or whatever).
A counter-argument to this is that we don't fully take advantage of the
type-checking available. However, there are type checkers for PHP which
some people use, and it's likely that even if we don't move to Hack,
more type-checking features will move into the PHP ecosystem.
Also, we do have basic type-checking at run-time already (type hints, is
it a real method?), though not quite the same thing.
Matt Flaschen
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] For the Sake of Simplicity
Merely removing features is not deep enough. This is fundamentally at its origins an architecture challenge, and a development management challenge. Removing features is rearguard action, not properly conceived engagement with the problem. Complexity can be neutral; code size by itself is not horrible in an era of TB drives. But code size hides bugs, and security flaws, and exponentially more complicated development challenges the more components and parts that one must consider interacting with each other. ESR was wrong; he's asserting that simplicity is too hard and we should give up. We can't give up; software projects and distros / OS versions that get too complex become unsustainable and fail in the market (public opinion, or just financially). He does not seem to understand the harm of complexity, and does not here appear to understand the role that singular architects and dev leaders and style guides and code standards can have. A very few people, or one, can point a project in a direction that both allows lots of participation AND remains focused and architecturally clean. PHK wasn't entirely right; he's gotten down in the weeds on a much larger problem, and the weeds distracted everyone. But he has a point. On Wed, Apr 22, 2015 at 1:26 PM, Trevor Parscal tpars...@wikimedia.org wrote: I'm a fan of removing features when the feature is not currently done well and we aren't going to do it well anytime soon, if ever. Products with fewer high quality features are superior in many ways to products with many low quality features. - Trevor On Wednesday, April 22, 2015, Stas Malyshev smalys...@wikimedia.org wrote: Hi! This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product might be smaller or have fewer features than the previous version, and that this property should be considered a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising and classic ideal — less is more. Apple is doing it from time to time, and is not shy about it. I'm not sure I personally am a big fan, but it works for many people. Another interesting take on the same topic from ESR: http://esr.ibiblio.org/?p=6737 -- Stas Malyshev smalys...@wikimedia.org javascript:; ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; 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 -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] For the Sake of Simplicity
On 15-04-22 05:06 PM, George Herbert wrote: He does not seem to understand the harm of complexity, and does not here appear to understand the role that singular architects and dev leaders and style guides and code standards can have. I'm pretty sure I disagree with this. Any system will begin to show emergent complexity past a certain size or scope, and no amount of precise architecture can prevent it. A good architecture team, style guides and code standard are all beneficial in that they push what 'certain size' is further, and helps mitigate the effects of increasing complexity so that it remains more managable - but they do not prevent either. No matter how well designed, any system will exponentially diverge from expectations and show emergent behaviour as the number of interacting component grows. That is an inevitable reality, no matter how insightful the project lead or how stringent the process. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] For the Sake of Simplicity
At those sizes, insisting on APIs between component levels/layers/areas helps keep sanity and order. Every system's complexity reflects both actual functional requirements, at whatever level of simplicity was realistic to impose, and evolution of the required features as the uses were expanded and understood better. If you planned for orderly solutions and approaches at a higher level of complexity than you had to implement to start with, expecting that growth, then the evolving product can maintain a reasonable organized approach. The question is, what was the forseen growth, the margins for that, and the eventual growth level. With many internet things, forseen growth was 10x and the eventual growth seems to be bimodal into a lot of items at around 2x and a very few very successful ones at 100x. It *is* a perfectly valid question as to whether enough time and architectural experience is available to pre-plan a new internet tool for the potential 100x growth... (This does argue for complete rearchitect/recode projects every so often for very large successful tools...). On Wed, Apr 22, 2015 at 3:17 PM, Marc A. Pelletier m...@uberbox.org wrote: On 15-04-22 05:06 PM, George Herbert wrote: He does not seem to understand the harm of complexity, and does not here appear to understand the role that singular architects and dev leaders and style guides and code standards can have. I'm pretty sure I disagree with this. Any system will begin to show emergent complexity past a certain size or scope, and no amount of precise architecture can prevent it. A good architecture team, style guides and code standard are all beneficial in that they push what 'certain size' is further, and helps mitigate the effects of increasing complexity so that it remains more managable - but they do not prevent either. No matter how well designed, any system will exponentially diverge from expectations and show emergent behaviour as the number of interacting component grows. That is an inevitable reality, no matter how insightful the project lead or how stringent the process. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Foundation-l] Single login - decision 2004
took us over a decade but oh well, Well Done Mr Pretzel :D -- Cometstyles ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Foundation-l] Single login - decision 2004
Awesome, good job guys! *Stryn* 2015-04-22 9:37 GMT+03:00 Keegan Peterzell kpeterz...@wikimedia.org: This is now complete [2]. That wasn't too bad. 2. https://lists.wikimedia.org/pipermail/wikimedia-l/2015-April/077576.html -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation -- Keegan Peterzell Community Liaison, Product 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
[Wikitech-l] RFC meeting this week
In the next RFC meeting, we will discuss the following RFC: * Business Layer Architecture on budget https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architecture_on_budget The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00 -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
