On 15-08-13 08:31 PM, Matthew Flaschen wrote:
Being a contributor does not give someone a get-out-of-jail-free card
for bad behavior.
Sorry, I see you missed a typo: s/does not/should not/
In practice, it very much does. Our communities have a long history of
letting outright sociopathic
After a long and painful recovery process, here is the incident report
for the June 17 outage of Labs NFS:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20150617-LabsNFSOutage
-- Marc
___
Wikitech-l mailing list
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,
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
On 15-03-17 10:56 AM, Risker wrote:
It just strikes me as weird that the software that we keep being told will
improve communication and collaboration is deliberately designed in such a
way that it is difficult for the human users (as opposed to the software)
to be able to immediately discern
On 15-02-19 09:27 AM, MZMcBride wrote:
n a second or third
iteration, we'd ideally have an intermediate post-login screen that allows
the user to select an account to use.
That would be a catastrophe, from a privacy standpoint; even if we
restrict this to verified email addresses, there is no
On 15-02-12 01:13 AM, Pine W wrote:
What would it take to implement a new tool edit flag userright
In the time-honored spirit of bikeshedding, I'd suggest that the right
name for this is automated edit rather than tool edit.
-- Marc
___
On 15-01-16 02:48 AM, Max Semenik wrote:
Can't agree on this, as the number covers [...]
An extra datapoint here: I think I can reasonably consider myself an
atypical user at the tail end of the sysadmin curve, and yet the
principal reason why I had delayed installing VisualEditor on a
, Marc A. Pelletier wrote:
The expecte impacts is:
* Starting at the beginning of the window, /home and /data/project will
switch to readonly mode; any attempt to write to files to those trees
will result in EROFS errors being thrown. Reading from those
filesystems will still work as expected, so
On 15-01-12 08:47 PM, Maximilian Klein wrote:
So how can I have submit the rebroadcast job to the grid and have the
rebroadcasted websocket be accessed by a static address, so that external
people can read it? What is the best strategy?
I can think of several strategies; part of the difficulty
On 15-01-09 03:19 PM, Trevor Parscal wrote:
3. social media behaviors are not often seen has helpful to our mission.
That's a near-universal attitude amongst old hands; and has spawned a
number of We are not Facebook meme and a great deal of knee-jerk
reaction to any feature that can
On 15-01-07 12:17 PM, Petr Bena wrote:
Nightly builds for all platforms would be cool. (I can do that for
ubuntu only right now, using wikimedia labs).
We'll have Debian Jessie soon in Labs as well (we're waiting for an
upstream bug); that may help.
-- Marc
On 15-01-06 11:49 AM, Federico Leva (Nemo) wrote:
Getting an extension enabled for Wikibooks or Wikisource is a
practically impossible task.
Wait, why would that be?
I'm pretty sure the criteria for those projects are the same as
everywhere else - and may in fact be slightly more lax as
On 11/09/2014 10:20 AM, Brian Wolff wrote:
Does anyone have any attack scenario that is remotely plausible which
requiring a verified email would prevent?
Spambots (of which there are multitude, and that hammer any mediawiki
site constantly) have gotten pretty good at bypassing captchas but
On 11/09/2014 12:33 PM, MZMcBride wrote:
Hmmm, I imagine many spambots have already made this investment if they're
dealing with popular systems that require e-mail address confirmation.
No doubt there are some that do; but it's a very different technical
hurdle and the management tradeoff
On 10/12/2014 12:50 PM, Arlo Breault wrote:
The people on this list can best answer that.
What the people on this list cannot answer is /whether/ and under what
conditions it would desirable to allow proxy editing in the first place.
-- Marc
___
On 10/02/2014 01:27 AM, Kevin Wayne Williams wrote:
Focusing on what signature we can obtain from (or plant on) the device
and how to make that signature available to and manageable by admins is
the key.
... wait. Did you just suggest that we mitigate the inability to use an
anonymizing
On 10/02/2014 09:07 PM, Kevin Wayne Williams wrote:
Anybody that risks death by editing Wikipedia is an idiot: no privacy
system is secure enough and no information is important enough to make
that a reasonable decision.
I wouldn't have put it that way, but I've been saying something to that
On 10/02/2014 09:57 PM, Kevin Wayne Williams wrote:
I'm just amused by people that view making such edits anonymously as
some intrinsic right.
I would expect that most of the people who (sincerely) feel strongly
about a putative right to edit anonymously are more likely to be looking
for edits
On 09/30/2014 09:08 AM, Derric Atzrott wrote:
[H]ow can we quantify the loss to Wikipedia, and to society at large, from
turning away anonymous contributors? Wikipedians say 'we have to blacklist all
these IP addresses because of trolls' and 'Wikipedia is rotting because nobody
wants to edit
On 09/09/2014 09:00 AM, Quim Gil wrote:
with
no-holidays uploading new patches.
Wouldn't volunteers' output _increase_ as their free time increases? :-)
-- Marc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 09/02/2014 01:09 PM, Quim Gil wrote:
For all these reasons and more, we have decided to evolve Rachel's role as
Events Coordinator at the Engineering Community team.
Our loss is your gain, Quim! Grats, Rachel - it's well deserved!
-- Marc
___
On 07/19/2014 05:47 AM, Mark Clements (HappyDog) wrote:
I've never been to a hackathon before! What should I expect? Are any
of you guys coming?
Hackathons tend to cover the range from complete newbie to Brion;
it's the meeting place for everyone who are involved - or want to get
involved -
On 07/11/2014 09:34 AM, John Mark Vandenberg wrote:
Could ops confirm they have the username of each logged in edit at
their finger tips (i.e. roughly as easy to access as the user-agent)?
Pywikibot doesnt permit logged out edits.
We do, after the fact, from the same data Checkusers have
On 07/11/2014 10:07 AM, Jeremy Baron wrote:
I can recall more than a few past conversations about this with mzmcbride,
Tim Starling and others.
Keep in mind I've only been around for ~18 months, so I am going to be
unaware of some previous discussion on the subject.
But yeah, /clearly/ the
On 06/26/2014 10:15 AM, David Gerard wrote:
NDAs for security bug
access are pretty much standard, aren't they?
I don't know about standard but they are certainly common in cases
where said software has a large installed base and early disclosure of a
vulnerability would place them at risk
On 06/01/2014 02:44 AM, ENWP Pine wrote:
I would like to talk with someone who has broad knowledge on the tech side of
the Wikimedia universe so I can ask some questions about hardware, Labs, and
MediaWiki.
Feel free to look me up on IRC for most ops stuff, though mostly Labs of
course (I'm
On 05/27/2014 12:37 PM, Christian Müller wrote:
Point 2) should be considered the easiest implementation, 1) is harder to
implement but gives even more freedom to SVG creators and would adhere more
closely to SVG standard. However, another argument for 2) would be the
licensing issue: It
On 05/27/2014 09:05 PM, C. Scott Ananian wrote:
I agree that a simple whitelist might be workable, but it does depend
on a bit of code auditing of librsvg to ensure that it can be done
robustly.
That works to protect the image scalers, if correct, but it does nothing
to protect the clients,
Hey all,
Me and Andrew Bogott will be travelling to Zürich for the Hackaton[1] in
the coming days; this means limited online availability during actual
travel time, but vastly increased physical availability in Zürich
itself. :-)
I will be available for help in porting tools to the Tool Labs,
On 04/04/2014 11:48 AM, Quim Gil wrote:
Open is open. What would be the best practice with these changesets? Just
leave them open like now, abandon them, mark them with some tag...?
I can think of two broad categories we'd be interested in: waiting for
review and waiting for submitter action.
That was fun.
Hello, everyone. The hard part of the migration is over for all but two
tools[1].
If you had not already migrated your tools manually during the migration
period that ended this Monday, the data for all your tools has now been
copied to the new datacenter, and your tools are ready
On 03/18/2014 09:08 PM, Faidon Liambotis wrote:
I'm not sure what embed in our architecture or embed in our
processes means, could you clarify that?
Only Quim can clarify what he means, of course, but I read the
distinction as is used for actually producing output vs. we use it
for our daily
On 03/11/2014 12:37 PM, Mark Bergsma wrote:
Chase comes to us from DeviantArt
Welcome, Chase.
... is there anyone /left/ at DeviantArt? :-)
-- Marc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 03/08/2014 04:38 PM, Tyler Romeo wrote:
Tell me something, what about the developers of MariaDB? Should they be
responsible for WMF's stability? If they accidentally release a buggy
version, are they expected to revert it within hours so that the WMF
operations team can redeploy?
I'm going
Hello All,
As should come as no surprise given the number of advance warnings sent
over the past couple months, the time for migration of the tool labs
project from pmtpa to eqiad is at hand!
[This email applies to tools on the Tool Labs /only/; if you have
projects in labs, then you want to
On 03/04/2014 05:05 PM, Quim Gil wrote:
If I understood correctly the
proposals listed so far, we seem to have only one hacking sprint.
It's difficult to classify some of the activities. I, for instance,
will set up a 'Migrate to Tool Labs / work on Labs' corner intended to
last the entire
On 02/20/2014 04:51 PM, Brion Vibber wrote:
TLD proliferation is a scam by money-hungry registrars who want people to
register (and thus pay) in multiple TLDs to protect their brands.
Well, the ostensible pretext is that .com. is now ridiculously
overloaded with myovercomplicateddomain.com
On 02/18/2014 01:10 PM, Faidon Liambotis wrote:
However, last I heard, platform engineering is focusing on HHVM now
instead, so I'm not sure if it actually makes sense to spend resources
to move to PHP 5.4 right now.
My understanding is that those are two orthogonal questions. I don't
think
On 02/17/2014 02:45 PM, Derric Atzrott wrote:
NVC values honestly expressing your own needs and feeling and empathetically
listening to those of others.
You know, I'm generally considered to be reasonably skilled at
communications; and I think that I have had some success in remaining
cordial
On 02/05/2014 03:53 PM, Chris Steipp wrote:
The Whirlpool algorithm by Tim would force password cracking software to do
a custom implementation for our hashes.
No judgment is passed on Tim, but rule number one of crypto is never try
to roll your own unless you happen to have years and years of
On 02/05/2014 09:34 PM, Tim Starling wrote:
Maybe Chris's phrasing misled you: I didn't invent the Whirlpool
algorithm
And so it did; something a quick google would have revealed. In my
defense, The Whirlpool algorithm by Tim was pretty convincing
attribution. :-)
I'd need to read up on that
On 01/17/2014 01:21 PM, Erik Moeller wrote:
This seems like a valid reason for a global exemption to me, so I'm
not sure the current global policy is sufficient.
To be fair, Erik, I don't think it's fair to expect that one would be
granted IPBE (especially globally) simply by just remembering
On 01/17/2014 02:15 PM, Thomas Gries wrote:
In the further passages Peter Wayner explains a one straight-forward solution
is to use some form of certificates with a *blind signature*, a technique that
borrows from some of the early solutions for building anonymous digital cash
(A typical
On 01/17/2014 04:26 PM, Erik Moeller wrote:
I understand. Wikimedia's current abuse prevention strategies rely on
limits to user privacy being maintained, and any technical solution
that attempts to broaden access for Tor users is unlikely to be
successful at any significant scale unless this
On 01/13/2014 11:32 AM, Zack Weinberg wrote:
Assume a person under continual surveillance.
If they have to reveal their true IP address to Wikipedia in order to
register their editor account, the adversary will learn it as well,
and can then attribute all subsequent edits by that handle to
On 01/13/2014 12:15 PM, Faidon Liambotis wrote:
What do you mean by endpoints?
The computer from which the edit is made is the salient one. Or, indeed
even visual observation of the person of interest coupled with rubber
hose crypto.
The scenario I am trying to explain is that which starts
On 01/13/2014 12:55 PM, Greg Grossmeier wrote:
That's a strawman (both your statement and mine).
That wasn't /my/ statement, I was just pointing out its straw nature
myself. :-) My point was exactly that trying to use emotional
statements as rationale for change won't lead to anything good.
On 01/06/2014 04:42 PM, Tobias wrote:
This could be done in the most simplest form by checking whether a
namespace string is a prefix of the search string (perhaps excluding
exotic namespaces such as MediaWiki) or even if the namespace name is
contained in the search string.
Perhaps an even
On 01/06/2014 08:00 PM, Luis Villa wrote:
I have seen only one place with poutine in the entire city, and it is
conveniently two and a half blocks from the office.
I don't know if it's the same place you are referring to, but the Club
Quarters restaurant actually has a selection of poutines
On 01/01/2014 12:34 AM, George Herbert wrote:
Tyler, websites everywhere blacklist offensive words (and with some
regularity, look and sound-alikes) from the random captcha generator...
Yes, and then we end up with the Scunthorpe problem instead.
I agree it's a little bit silly, and also a
On 12/30/2013 06:49 PM, Risker wrote:
I disagree fundamentally with your position here.
I have to agree with Risker here (Oy! Twice in one year!)
The problem isn't that it is technically difficult to allow edits
through TOR, but that the vast majority of edits coming in from TOR are
abusive,
On 12/30/2013 09:48 PM, Gregory Maxwell wrote:
This isn't perfect— it creates a bias towards people in wealthier nations
which can afford the tokens, but most people don't need their tokens and
so it would be reasonable to expect substantial token charity to exist.
Your scheme has thought
On 12/09/2013 09:29 PM, MZMcBride wrote:
* Minification is a form of obfuscation and it harms the open Web.
That's true iff there isn't a readily available way of getting the
non-obfuscated source. For normal day-to-day browsing you /want/ to
shave those extra ms off (all the more so if you are
More news:
It turns out the DDOS was inadvertent and caused by an ill-considered
addition to several projects rather than malice: a script hosted on tool
labs intended to tie Wikidata to search results was made to load on
every page view rather than just upon searching, causing every hit to a
On 12/02/2013 03:04 PM, Quim Gil wrote:
The deadline for submissions to the Wikis devroom at FOSDEM has been
extended until the end of DECEMBER 15
I would have submitted a second one if I had a better idea of the scope
of the dev room. Obviously, my own expertise and interests surrounds
the
On 11/23/2013 01:26 AM, Quim Gil wrote:
Please add it to
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
{{done}}
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Distributed_cron_replacement
-- Marc
___
On 11/22/2013 07:50 PM, Quim Gil wrote:
We might start with one project with 4 students to try this program out.
If you are interested, please reply and create / update your entry at
the Possible Projects page.
Interestingly enough, I /do/ have a project I'd be happy to put forward
that's
On 11/18/2013 04:39 AM, Happy Melon wrote:
I'm sure spam directed at, say, enwiki, would get very subtle very quickly
if spammers thought there was a real chance of it being able to use
enwiki's pagerank weight. Don't underestimate spammers' ability to learn
and adapt.
Also +1; pagerank is a
On 10/16/2013 03:40 AM, Ken Snider wrote:
I'm extremely pleased to announce that we've had two promotions within the
Technical Operations team!
Grats to both of you!
And like I said earlier, Ryan, don't think that this means I'll start
paying attention to what you say. :-P
-- Marc
On 10/11/2013 06:51 AM, Petr Bena wrote:
It actually can reconnect when
connection die, but problem is that wm-bot is using bouncer, and this
bouncer doesn't forward signal when remote server disconnect. This
needs to be fixed by some more coding and that again requires some
other petan who
On 10/11/2013 09:30 AM, Petr Bena wrote:
What is dickson server? Why it works better?
dickson.freenode.net as also known as dickson.wikimedia.org: the
freenode node that is on our network. (Which isn't advertized or in the
round robins yet because it is still in burn-in).
It doesn't
On 10/01/2013 09:25 AM, Brion Vibber wrote:
(I also strongly recommend having an official MediaWiki hosting support
service, with ad- and ad-free options, various degrees of customization vs
automated service, etc. This'd cover a huge portion of the I just need to
stick a wiki somewhere cases
On 09/04/2013 10:49 AM, Tyler Romeo wrote:
No because the geoip check is performed at the time of each request,
meaning it's not stored in the database or anything.
Isn't that a relatively expensive operation that would gain from caching
anyways?
-- Marc
On 08/30/2013 10:21 AM, Brion Vibber wrote:
I definitely recommend fixing the geohack page to work properly over SSL...
Given that the actual webserver fully allows https, I expect the only
issue is protocol specified in some constructed URLs and should be
fairly simple to fix. The listed
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually still
want that I can attempt to revive that part of my patch. I think it'd be of
especial interest to require HTTPS for checkusers and oversight people, due
to the legal problems
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a
second set of credentials over a https only page?
You're missing the point. People who have (for instance) checkuser or
oversight should be simply disallowed from logging in
On 08/23/2013 04:02 PM, Mark Holmquist wrote:
And in the future: If a URL has wmflabs.org in it...don't put anything,
ANYTHING, important there. The purpose of labs is to let us experiment with
new technology without having to worry about reliability.
It'd be more correct to say that any
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support
Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are the one we
/least/ want to have their password snooped, and the ones
On 08/23/2013 05:33 PM, Risker wrote:
there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those geographical regions from serving Wikimedia communities
Interesting. Would you care to share with whom that offline
On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
Would you care to share with whom that offline discussion
is happening?
... and, more importantly, /why/ is that discussion taking place offline
in the first place?
-- Marc
___
Wikitech-l mailing
On 08/21/2013 01:24 PM, Tilman Bayer wrote:
Running 450 servers for Wikipedia, 150
staff. On AWS you could run that with 2-4 sysadmins
Obvious troll is obvious.
Anyone who says something this with a straight face is either insane or
has absolutely no idea what they're talking about. The one
On 08/20/2013 11:05 PM, Risker wrote:
Perhaps then you might want to re-familiarize yourself with the WMF's
policy on political advocacy
I'm sorry Risker, but you've got this backwards. Making a long-overdue
/minimal/ fix to our login process is not political advocacy.
Compromising the
On 07/29/2013 04:38 AM, Lydia Pintscher wrote:
Let's not have it just as a feel-good thing
that isn't really influencing anything.
Right now, it's the Bugzilla equivalent of the close doors button on
most elevators. :-)
-- Marc
___
Wikitech-l
On 07/27/2013 08:37 AM, Petr Bena wrote:
So that it would mostly
consist of a daemon that based on user subscriptions insert stuff to
redis queues.
Wouldn't it be much easier to implement it as, say, a dbus and allow
people to subscribe to the feed, instead?
-- Marc
On 07/27/2013 11:10 AM, Yuvi Panda wrote:
grrrit-wm and suchabot already use this architecture for gerrit
streams, no reason it can't scale for Wiki RC Changes.
That's actually a persuasive argument (i.e., let's not multiply mechanisms).
-- Marc
On 07/18/2013 05:18 PM, David Gerard wrote:
They're local to each wiki, but they should indeed be metadata.
Worf and Sapir would have a field day with that idea. :-)
-- Marc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 06/24/2013 11:17 AM, Ct Woo wrote:
The Technical Operations team is pleased to announce Sean Pringle joined us
today
Welcome! You'll like it here.
-- Marc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 06/25/2013 01:20 AM, S Page wrote:
sell for
amounts of money so vast that the base license includes the very souls of
[at least one] fairly recent management school grads
About $5? :-)
-- Marc
___
Wikitech-l mailing list
On 06/19/2013 11:35 AM, Chad wrote:
I doubt it. I imagine we'll look to the new LTS when it comes out.
In the meantime, for an entirely different reason, I'm currently working
on a backport of Apache 2.4 onto precise, and that includes having to
rebuild PHP. Right now, the build defaults to 5.5
On 06/07/2013 11:43 AM, Asher Feldman wrote:
Why not - would the patrol cost really be too high?
I can only speak for enwp, of course, but with my experience as a
checkuser and arb there (and a couple years as an admin before that) I
can say without a doubt that I would strenuously oppose
On 06/04/2013 11:37 AM, John Erling Blad wrote:
It is like writing a
document with no spell checker vs using a spell checker.
Which would be the right moment to remind you of the Cupertino effect
that illustrates so well how the combination of automation and trust in
that automation is known to
On 06/04/2013 12:57 PM, Nikolas Everett wrote:
The thing is quite a few of us have seen cases where people bend over
backwards for test coverage, sacrificing code quality and writing tests
that don't provide any real value.
Probably better expressed than I did.
My point is: clearly test
On 05/31/2013 05:48 PM, Rob Lanphier wrote:
It is my pleasure to introduce Nik Everett as a new Senior Software
Engineer specializing in Search, working remotely from his home in
Raleigh, North Carolina.
Jumping *peppers*!! This is *smiley* time!
Do not forget to *enjoy the sauce*!
-- Marc
On 05/22/2013 04:03 PM, Tuszynski, Jaroslaw W. wrote:
So are there any non-toolserver based alternatives for database queries?
Well, there are always the Tool Labs[1]. Database replica access is
still experimental/in trial but it works.
-- Marc
[1]
On 05/21/2013 04:28 PM, Derk-Jan Hartman wrote:
Does anyone else think something like that might be a nice idea ?
The idea, she is good.
-- Marc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 05/10/2013 06:12 PM, Steve Summit wrote:
(Obviously that's incomplete, but as someone who only understands
conventional repositories that you check files out of and in to,
I don't yet get git at all, myself, either.)
Despite the snark, this is also my experience. I've yet to get really
On 05/07/2013 05:33 PM, Juliusz Gonera wrote:
Seems interesting. Is there anyone who'd be interested in giving a talk
or participating in a panel there?
Given that it's very close to me, and that I have quite a bit of
experience with the API, this is something I could do.
I actually had an API
On 04/23/2013 11:29 PM, Erik Moeller wrote:
(Keeping in mind that some
pages would be multilingual and would need to be identified as such.)
If so, this seems like a major architectural undertaking that should
only be taken on as a partnership between domain experts (site and
platform
TronGreetings, Programs!/Tron
So, not many updates for a while, as things have been progressing at a
fair clip in the oh, my god boring gruntwork front.
The biggest news is the addition of Petr Bena to the tools project
sysadmin team as its first volunteer. Petr has been very involved in
the
On 04/08/2013 12:13 PM, Sumana Harihareswara wrote:
Since those dates are now in the past :-) can you help provide new
estimated times of arrival? Thanks!
I think those dates are in the past because those bits are complete. :-)
As far as I know, we're still on track.
-- Marc
On 04/04/2013 03:22 AM, Jeroen De Dauw wrote:
SMW will make any wiki uber-complicated and explode. This certainly does
not include concerns with deployment on the big WMF project wikis, which
should be taken seriously.
As a point of anecdotal data, I've used SMW with success at two of my
past
On 04/04/2013 10:04 AM, K. Peachey wrote:
Plus we already have another system that is getting worked on and
rolled out to a few of the production wikis that will seem to do
similar features (based on comments in this thread already).
I'm honestly not familiar enough with Wikidata to be able to
On 04/03/2013 09:48 AM, Yury Katkov wrote:
IMO stuff related to inner projects of Wikimedia foundation should be
located on wikitech. Manuals that are related to MediaWiki as a software
and its extensions should live on MediaWiki.org. No Wikimedia-specific
materials here.
This seems like a
Toto, I've a feeling we're not on the toolserver any more.
So, things are progressing at a fair clip; there is now a database
available to the tools, which means that most tools that do not depend
on the presence of the database replicas should be workable in the new
environment. Maintainers
On 03/08/2013 01:34 AM, Petr Bena wrote:
this shouldn't be very
dangerous
Even if it isn't in practice in the typical cases, it exposes a third
party to a risk they are unable to assess if they use that OpenID. (And
it doesn't require a 'crat going rogue even here -- renames are
sometimes
On 03/05/2013 12:22 PM, Tyler Romeo wrote:
it is nonetheless *legally
required* to do so, regardless of the technical aspect of it
I think that determination needs to be made by Counsel, not on a guess.
I've quite some knowledge of copyright myself, and I know enough that
the matter is
On 03/04/2013 09:58 AM, David Gerard wrote:
That counts as documentation.
Law of Murphy for devops: if thing can able go wrong, is mean is
already wrong but you not have Nagios alert of it yet. counts as
enlightenment. :-)
-- Marc
___
Greetings, programs!
This week's update will be brief, if optimistic:
On the news front, there have been performance and reliability issues
with Gluster than are being worked on by Ryan Lane. He is experimenting
with an upcoming network driver and tweaking with automount timing to
improve
On 02/26/2013 02:14 PM, Luke Welling WMF wrote:
Do we have an official position on cross database compatibility?
It would be nice if we did. In my own production environments, I always
use postgres. To date, mw has been good enough with its support that
I've never had significant
1 - 100 of 112 matches
Mail list logo
