Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Shlomi Fish shlo...@shlomifish.org [2011-07-29 13:25]: One reason I have not converted wholesale to metacpan is because it redirects all http:// requests to https:// . Very annoying. http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. […] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine!
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. [?] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine! These comments are pretty funny once you consider that you're making a secure connection to an independent party who has a commercial and fiduciary responsibility to exploit every bit of data you give them. With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
* Arthur Corliss corl...@digitalmages.com [2011-08-28 19:55]: On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy *no additional machines* and *no special hardware*. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: *SSL/TLS is not computationally expensive any more*. […] Also, don't forget that we recently deployed encrypted web search on https://encrypted.google.com. Switch your search engine! These comments are pretty funny once you consider that you're making a secure connection to an independent party who has a commercial and fiduciary responsibility to exploit every bit of data you give them. With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, Aug 28, 2011 at 9:41 PM, Lyle webmas...@cosmicperl.com wrote: On 28/08/2011 19:30, Aristotle Pagaltzis wrote: * Arthur Corlisscorliss@digitalmages.**com corl...@digitalmages.com [2011-08-28 19:55]: With friends like Google protecting your information, who needs encryption? ;-) --Arthur Corliss Live Free or Die Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? I always find it amusing when comments against google seem to get at people. After all, Google is just another Microsoft :P You clearly misunderstood Aristotle. He doesn't care about a comment against Google, and I'm sure he has no special affinity towards it. He simply had a good remark on a discussion of the effectiveness and CPU costs of SSL encryption and it was ignored with a completely irrelevant comment. Google might be another Microsoft, it might be worse, but it is *irrelevant* to the question of SSL security and the costs of enabling it by default. Aristotle, for what it's worth, I've learned that people always want to have their say, even if in an inappropriate time. Such as the politician, who when asked what do you think about the current financial crisis? will answer: I think the weather is excellent, and golf sounds like a wonderful idea! :)
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Aristotle Pagaltzis wrote: Right, so just let everyone in any coffee shop or any other open network you connect to sniff all your traffic. Did you have an actual point? Yep, but it appears you completely missed it. I use encryption all the time, but outside of authentication its merit is questionable when it concerns information that is a) public information (especially in the context of published open source) and b) information going to an untrustable third party like Google. Personally, I have no use for metacpan, and don't care what they do. But as a general operating principle, I like to use the appropriate tools where they're *appropriate*. I expect my bank's websites to be fully SSL, I expect my on-line brokerage's sites to be fully SSL. But what exactly is the risk with a search engine of a highly specialized and highly public information? I fail to see the benefit, and I tend towards paranoia naturally. OSS is about freedom choice. As long as users have a choice (an alternative to metacpan) feel free to force your preferences on the users. But in the unfortunate circumstance where metacpan becomes the only choice it'd be nice if the maintainers try to be a little less dogmatic about it. They should be inclined towards maximum accessibility, not maximum pedagoguery. I know I didn't get the memo but I think someone did claim that metacpan was the de facto interface these days... --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
# from sawyer x # on Sunday 28 August 2011 12:03: a discussion of the effectiveness and CPU costs of SSL encryption I didn't think it was a question of CPU speed anytime in the past decade. How does a proxy cache encrypted data? Atwood's Law of Computer Latency: Processor cycles, storage density, and network bandwidth are increasing, faster than the speed of light is getting faster. --Eric -- Insert random misquote here --- http://scratchcomputing.com ---
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, sawyer x wrote: You clearly misunderstood Aristotle. He doesn't care about a comment against Google, and I'm sure he has no special affinity towards it. He simply had a good remark on a discussion of the effectiveness and CPU costs of SSL encryption and it was ignored with a completely irrelevant comment. Google might be another Microsoft, it might be worse, but it is *irrelevant* to the question of SSL security and the costs of enabling it by default. My humor was perhaps too subtle, since you didn't get the relevance of my reply. Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. In the latter case you have a search engine whose use is basically the retrieval of information based on *published* open source software, and highly published at that, given the world-wide replication of CPAN itself. What exactly is metacpan protecting? Is it that embarrasing that programmer Joe can't remember what module function foo was defined in? Can someone really derive significant benefit from witnessing Harry browse the API for WWW:Retrieval::LOLCats or what have you? So, regardless of the incremental costs of implementing SSL, *why* is the mandatory use of SSL even considered intelligent, rational, or any other way beneficial? I wasn't going to get involved in this thread, but the Google bait was too spot on to ignore. --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Eric Wilhelm wrote: I didn't think it was a question of CPU speed anytime in the past decade. How does a proxy cache encrypted data? Bringing up proxies is an excellent point. While most proxies do support SSL tunnelling, this does make the request uncacheable since the proxy never knows anything about the connection outside of the host port it's tunnelling to. I run a proxy cluster myself, and I do force caching of search engine responses for a short window (typically on the order of a few hours), and it does tend to pay off, especially when notable events occur in the world. Obviously, SSL bypasses the cache altogether. And I can only get away with this because the businesses I support all want the same safe levels applied to all requests, so I don't have to worry about inappropriate content in some people's results. Which brings to mind yet another point: for those of us providing content filtering services via proxies SSL is a huge problem. The only good solution is to do transparent interception of SSL connections with your proxies serving up a private CA-signed certificate using wild cards, but that requires installing your private CA's root certificate on all clients, and even then there's clients that that still won't work on. Never mind that the concept of spoofing external organization certificates is insanely dangerous in its own right. --Arthur Corliss Live Free or Die
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, 28 Aug 2011, Arthur Corliss wrote: snip Which brings to mind yet another point: for those of us providing content filtering services via proxies SSL is a huge problem. The only good solution is to do transparent interception of SSL connections with your proxies serving up a private CA-signed certificate using wild cards, but that requires installing your private CA's root certificate on all clients, and even then there's clients that that still won't work on. Never mind that the concept of spoofing external organization certificates is insanely dangerous in its own right. I'm going to preemptively qualify this brain dump as relevant to the metacpan debate because I would consider metacpan's content, search results, etc., to be highly cacheable. Moreso than a general purpose engine like Google, metacpan's results would tend to be more applicable to multiple users' searches. And yet the whole SSL-only mindset would hamper an individual network operator's ability to control and shape its network. Hopefully no one misconstrues this as me being against SSL sites, I'm extremely in favor of them, particularly with organizations hosting my sensitive information. I only think metacpan should offer both HTTPS and HTTP interfaces. Let those ultra-paranoids among us use the HTTPS, and the rest of us HTTP. --Arthur Corliss Live Free or Die
Statistics::R comaint to FANGLY
Hello list, Hopefully a PAUSE admin is listening. I would like to have Florent Angly added as comaint to Statistics::R (and Statistics::R::Bridge). I had taken over the module from GMPASSOS a while back, but have been unable to do any work on it of late. Florent Angly (CPAN ID: FANGLY) has agreed to step in and continue the work. Unfortunately, I am unable to grant him comaint as GMPASSOS retains the primary maintainer-ship. Thanks in advance, -- Brian Cassidy (brian.cass...@gmail.com)
Module::Build::Tiny
Hi, I find this module intriguing. In my understanding, the complexity of Module::Build piled up because the same tool tries to cover both installation and authoring use cases. I believe the Dist::Zilla approach is a better way to take care of authoring: a separate toolchain that can be as complex as the author would prefer. The installer can then be trivial, as indeed it should; as well as pure Perl – as indeed, it should. So Dist::Zilla plus the *idea* of Module::Build::Tiny seem to fulfil the original concept of Module::Build better than that module itself ever has. But is the implementation up to par? Essentially: if I’m using Dist::Zilla for authoring, what regular features not explicitly mentioned in MBT’s POD would I have to avoid? Do things like optional or build-/test-only deps work? (I’d assume these do.) Or can I assume that everything will work unless otherwise pointed out? I could answer this for myself if I had *exact* understanding of how much of the work falls upon the .PL at install time, and how many of the toolchain features are implemented in the CPAN client and thus unaffected by MBT’s minimalism. So the answer to that is what I’d like. (I’d also be interested in whether any omissions mentioned in the POD are design choices or the idea is to add them in the future, and which if so.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
