On Thu, May 7, 2015 at 1:10 PM, Chuck Thier wrote:
> I think most are missing the point a bit. The question that should really
> be asked is, what is right for Swift to continue to scale. Since the
> inception of Openstack, Swift has had to solve for problems of scale that
> generally are not s
On 05/08/2015 12:13 AM, Clint Byrum wrote:
Excerpts from Clay Gerrard's message of 2015-05-07 18:35:23 -0700:
On Thu, May 7, 2015 at 3:48 PM, Clint Byrum wrote:
I'm still very curious to hear if anybody has been willing to try to
make Swift work on pypy.
yeah, Alex Gaynor was helping out w
Excerpts from Clay Gerrard's message of 2015-05-07 18:35:23 -0700:
> On Thu, May 7, 2015 at 3:48 PM, Clint Byrum wrote:
>
> > I'm still very curious to hear if anybody has been willing to try to
> > make Swift work on pypy.
>
>
> yeah, Alex Gaynor was helping out with it for awhile. It worked.
Well put, Clay. Totally Agree.
On Fri, May 8, 2015 at 10:19 AM, Clay Gerrard wrote:
>
>
> On Thu, May 7, 2015 at 5:05 PM, Adam Lawson wrote:
>>
>> what sort of limitations have you discovered that had to do specifically
>> with the fact we're using Python?
>
>
> Python is great. Conscious deci
On Thu, May 7, 2015 at 5:05 PM, Adam Lawson wrote:
> what sort of limitations have you discovered that had to do specifically
> with the fact we're using Python?
>
Python is great. Conscious decision to optimize for developer wall time
over cpu cycles has made it a great language for 20 years -
On Thu, May 7, 2015 at 7:05 PM, Adam Lawson wrote:
> Chuck (and/or others who understand tor have experienced the limits of
> Python)
>
> I found this comment of yours incredibly intriguing: "we are running out
> of incremental improvements that can be made with Python".
>
> Given your work with
On Thu, May 7, 2015 at 3:48 PM, Clint Byrum wrote:
> I'm still very curious to hear if anybody has been willing to try to
> make Swift work on pypy.
yeah, Alex Gaynor was helping out with it for awhile. It worked. And it
helped. A little bit.
Probably still worth looking at if you're curiou
Chuck (and/or others who understand tor have experienced the limits of
Python)
I found this comment of yours incredibly intriguing: "we are running out of
incremental improvements that can be made with Python".
Given your work with Swift thus far, what sort of limitations have you
discovered that
Excerpts from Chuck Thier's message of 2015-05-07 13:10:13 -0700:
> I think most are missing the point a bit. The question that should really
> be asked is, what is right for Swift to continue to scale. Since the
> inception of Openstack, Swift has had to solve for problems of scale that
> genera
On Thu, May 7, 2015 at 2:10 PM, Chuck Thier wrote:
> What started as a simple experiment by Mike Barton, has turned into quite
> a significant improvement in performance and builds a base that can be
> built off of for future improvements. This wasn't built because of it
> being "shiny" but out
I think most are missing the point a bit. The question that should really
be asked is, what is right for Swift to continue to scale. Since the
inception of Openstack, Swift has had to solve for problems of scale that
generally are not shared with the rest of Openstack.
When we first set out to w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/04/2015 11:42 AM, Flavio Percoco wrote:
>> Using something different isn't innovating.
>>
>> Finding a way to do something significantly better is
>> innovating.
>
> FWIW, I didn't say using something different is innovating. It's
> what you
On 04/05/15 11:33 -0500, Ed Leafe wrote:
On May 4, 2015, at 7:26 AM, Flavio Percoco wrote:
TBH, I'm a bit torn. I'm always cheering for innovation, for using the
right tool, etc, but I also agree with Monty, the linked post and some
of the arguments that have been made in this thread.
Using
On May 4, 2015, at 7:26 AM, Flavio Percoco wrote:
> TBH, I'm a bit torn. I'm always cheering for innovation, for using the
> right tool, etc, but I also agree with Monty, the linked post and some
> of the arguments that have been made in this thread.
Using something different isn't innovating.
> On May 4, 2015, at 5:26 AM, Flavio Percoco wrote:
>
> On 04/05/15 12:17 +0200, Thierry Carrez wrote:
>> Monty Taylor wrote:
>>> On 04/30/2015 08:06 PM, John Dickinson wrote:
>> What advantages does a compiled-language object server bring,
>> and do they outweigh the costs of using a di
On 04/05/15 12:17 +0200, Thierry Carrez wrote:
Monty Taylor wrote:
On 04/30/2015 08:06 PM, John Dickinson wrote:
What advantages does a compiled-language object server bring,
and do they outweigh the costs of using a different language?
Of course, there are a ton of things we need to explore o
On 30/04/15 10:54 -0700, Clint Byrum wrote:
* +1 for compiled languages that are less-daunting than say C++, but
still help find problems early. Anybody up for a Rust version too? ;-)
/me is always up for some Rust
--
@flaper87
Flavio Percoco
pgpe5UOvbPWsd.pgp
Description: PGP signature
___
Monty Taylor wrote:
> On 04/30/2015 08:06 PM, John Dickinson wrote:
What advantages does a compiled-language object server bring,
and do they outweigh the costs of using a different language?
Of course, there are a ton of things we need to explore on this
topic, but I'm ha
On 1 May 2015 at 09:04, Dean Troyer wrote:
> On Thu, Apr 30, 2015 at 3:28 PM, Robert Collins
> wrote:
>>
>> Blaming pip for our problems, when we haven't been willing to go and
>> contribute fixes to pip is massively unfair to the pip developers.
>
>
> So I _really_ do not blame pip, it is by far
On Thu, Apr 30, 2015 at 3:28 PM, Robert Collins
wrote:
> Blaming pip for our problems, when we haven't been willing to go and
> contribute fixes to pip is massively unfair to the pip developers.
>
So I _really_ do not blame pip, it is by far the best of the options, it is
just (still) incomplete
On 1 May 2015 at 06:11, Dean Troyer wrote:
> Honestly I don't think Go's dep system, which is still developing, is any
> worse than Python's, which is also still developing. The big win for us
> (devs, ops, everyone!) is that the hassles are build-time, not
> install/run-time. Once you have a bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/30/2015 08:06 PM, John Dickinson wrote:
>
>> On Apr 30, 2015, at 9:52 AM, Jay Pipes
>> wrote:
>>
>> On 04/30/2015 12:40 PM, John Dickinson wrote:
>>> Swift is a scalable and durable storage engine for storing
>>> unstructured data. It's bee
maybe its less of an issue...
Thanks,
Kevin
From: Ryan Brown [rybr...@redhat.com]
Sent: Thursday, April 30, 2015 11:18 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [swift] Go! Swift!
On 04/30/2015 01:54 PM, Clint Byrum wrote:
>
On 04/30/2015 12:52 PM, Jay Pipes wrote:
On 04/30/2015 12:40 PM, John Dickinson wrote:
Swift is a scalable and durable storage engine for storing
unstructured data. It's been proven time and time again in production
in clusters all over the world.
We in the Swift developer community are constan
On 04/30/2015 01:54 PM, Clint Byrum wrote:
> * Go's import and build system is rather odd. Python's weird distribution
> issues are at least well known in the OpenStack community. This is
> actually the main reason I've never gravitated toward Go, as I feel
> it is trying to be magical rather
> On Apr 30, 2015, at 10:54 AM, Clint Byrum wrote:
>
> Excerpts from John Dickinson's message of 2015-04-30 09:40:02 -0700:
>> Swift is a scalable and durable storage engine for storing unstructured
>> data. It's been proven time and time again in production in clusters all
>> over the world.
On Thu, Apr 30, 2015 at 12:54 PM, Clint Byrum wrote:
> * Go's import and build system is rather odd. Python's weird distribution
> issues are at least well known in the OpenStack community. This is
> actually the main reason I've never gravitated toward Go, as I feel
> it is trying to be ma
> On Apr 30, 2015, at 9:52 AM, Jay Pipes wrote:
>
> On 04/30/2015 12:40 PM, John Dickinson wrote:
>> Swift is a scalable and durable storage engine for storing
>> unstructured data. It's been proven time and time again in production
>> in clusters all over the world.
>>
>> We in the Swift devel
Excerpts from John Dickinson's message of 2015-04-30 09:40:02 -0700:
> Swift is a scalable and durable storage engine for storing unstructured data.
> It's been proven time and time again in production in clusters all over the
> world.
>
> We in the Swift developer community are constantly looki
On 04/30/2015 12:40 PM, John Dickinson wrote:
Swift is a scalable and durable storage engine for storing
unstructured data. It's been proven time and time again in production
in clusters all over the world.
We in the Swift developer community are constantly looking for ways
to improve the codeba
Swift is a scalable and durable storage engine for storing unstructured data.
It's been proven time and time again in production in clusters all over the
world.
We in the Swift developer community are constantly looking for ways to improve
the codebase and deliver a better quality codebase to u
31 matches
Mail list logo
