Re: [PROPOSAL] Etch
On Thursday 07 August 2008 14:33:57 Paul Fremantle wrote: > Niclas > > I offered as a backup. I'm perfectly happy for the proposal to go > forwards with the three original mentors. I will probably join the > mailing lists anyway. Ok, noted in proposal. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept project PicaGalley into the Incubator
Hi, On Tue, Aug 5, 2008 at 6:14 PM, Roland Weber <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: >> I also think the names are too similar > > I have re-opened the naming discussion on [EMAIL PROTECTED] > Should we keep this vote running, or should we start a > new one after we settle for a different name? For the record, my vote is -0 due to the naming concern. It seems to me that this vote has enough +1 votes to pass, so IMHO there's no need to restart it unless you do want to change the name. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Folks, Can I ask if anyone has compared Etch with Apache Tuscany and the SCA specifications? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
From my understanding, Tuscany could leverage Etch to offer a wire format that can be consumed by a variety of different languages and environments, not a contestant to it. Ciao Henning Mike Edwards schrieb: Folks, Can I ask if anyone has compared Etch with Apache Tuscany and the SCA specifications? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Henning, I'd be grateful if you could explain this further. When I look at the Etch proposal page, it does not seem that Etch is simply about a wire format, so I am puzzled by your reply. There are some things I'm clearly not getting about Etch. Yours, Mike. Henning Schmiedehausen wrote: From my understanding, Tuscany could leverage Etch to offer a wire format that can be consumed by a variety of different languages and environments, not a contestant to it. Ciao Henning Mike Edwards schrieb: Folks, Can I ask if anyone has compared Etch with Apache Tuscany and the SCA specifications? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Doug is a wise man and that is how we picked the name etch 18 month ago. Scott out -Original Message- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:12 PM Pacific Standard Time To: general@incubator.apache.org Subject:Re: [PROPOSAL] Etch Doug Cutting has a few nice and short naming rules that I liked when I read them. I believe one of them was that a Google search for the proposed name should yield very few matches. Hadoop and Lucene are/were good examples of that. Here is another naming example. I created this bookmarking service called "simpy" - simpy.com . Great name - short, memorable, easy to spell, etc. people said. The problem with it is that "simpy" is a common misspelling of "simply". So, another thing to keep in mind. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: James Dixson (jadixson) <[EMAIL PROTECTED]> > To: general@incubator.apache.org > Sent: Tuesday, August 5, 2008 6:03:28 PM > Subject: RE: [PROPOSAL] Etch > > I have heard the name concern a couple of times now... > > When we picked the name Etch about 18 months ago, we knew about the > Debian release, but frankly we were unconcerned. Debian etch is the name > of a release of Debian, no different than "4" being a release of Fedora. > Eventually Debian etch will fade into memory just as sarge and woody > have. > > Etch, in our line of thinking (if it could be said we were doing any > thinking :-) ) was the name we were giving to the technology, not a > release. There were no other technologies named Etch or similar, so we > declared victory and moved on. > > So I guess my question back to everyone is this: > >What is the concern about the name Etch, really? > > 1. Is there a legal trademark issue or a formal Apache branding policy > issue with using the name Etch such that the use of the name is simply > not going to be allowed. > > - or - > > 2. Is there a concern that during incubation, we might have to be > explicit in communication and always say "Apache Etch" rather than just > "Etch" because of a fear that a reference to "Etch", taken out of > context, could be confused with Debian 4.0? > > If "1" is true then, absolutely the name should be changed. > > But if only "2" is true, then I will need a bit more convincing. I am > after all very, very lazy and changing the name of a working toolset is > well... work :-) > > > --- > James Dixson > Manager, Software Development > CUAE Engineering, Cisco Systems Inc. > Direct: 512-336-3305 > Mobile: 512-968-2116 > [EMAIL PROTECTED] > > -Original Message- > From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2008 3:33 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] Etch > > On Thu, Jul 31, 2008 at 6:16 PM, James Dixson > wrote: > > This a proposal to enter Etch in to the incubator. > > > > See http://wiki.apache.org/incubator/EtchProposal for updates. > > +1 for incubation (non-binding). While I find this area to be a bit > overcrowded lately, having both Etch and Thrift at Apache and Protocol > buffers under ASL 2.0 does offer some interesting opportunities for > competition as well as cooperation. > > I do share the concerns about naming conflicts. Debian is by far more > well known and trying to establish this project under a conflicting > name would be hard. > > /niklas > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
Hey, I was apple's rep to the omg for awhile and a member of the persistent comittee. As the etch architect, that experience has informed my every move. Keep it simple, make it fast. Scott out >From the monterey bay aquarium -Original Message- From: Craig L Russell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:41 PM Pacific Standard Time To: general@incubator.apache.org Subject:Re: [PROPOSAL] Etch A modern replacement for CORBA? Just resist the temptation to implement Persistence Services on top. ;-) +1 Craig On Jul 31, 2008, at 9:16 AM, James Dixson wrote: > This a proposal to enter Etch in to the incubator. > > See http://wiki.apache.org/incubator/EtchProposal for updates. > > In particular, we are looking for an interested Champion. > > We welcome any and all comments. :-) > Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: [VOTE] accept Tashi into the Incubator
Niclas Hedhman wrote: On Tuesday 05 August 2008 01:48:13 Doug Cutting wrote: -1. You get my +1 vote when the proposal text is part of the [VOTE] thread. ;-) See below. The wiki page has not been changed since the vote was called. Doug - = Tashi Proposal = A proposal to the Apache Software Foundation Incubator PMC by David O'Hallaron^*+^, Michael Kozuch^*^, Michael Ryan^*^, Steven Schlosser^*^, Jim Cipar^+^, Greg Ganger^+^, Garth Gibson^+^, Julio Lopez^+^, Michael Strouken^+^, Wittawat Tantisiriroj^+^, Doug Cutting^#^, Jay Kistler^#^, Thomas Kwan^#^ ^*^Intel Research Pittsburgh, ^+^Carnegie Mellon University, ^#^Yahoo! July 10, 2008 == 1. Abstract == Tashi is a cluster management system for cloud computing on Big Data. == 2. Proposal == The Tashi project aims to build a software infrastructure for cloud computing on massive internet-scale datasets (what we call ''Big Data''). The idea is to build a cluster management system that enables the Big Data that are stored in a cluster/data center to be accessed, shared, manipulated, and computed on by remote users in a convenient, efficient, and safe manner. The system aims to provide the following basic capabilities: (a) ''On-demand provisioning of storage and compute resources.'' Users request a number of compute nodes, which can be either virtual or physical machines, and a set of disk images to boot up on the nodes. In response they receive their own persistent logical cluster of compute and storage nodes, which they can then manage and use. (b) ''Extensible end-to-end system management.'' Tashi will define open non-proprietary interfaces for management tasks such as observation, inference, planning, and actuation. This will keep the system vendor-neutral and allow different research and development groups to plug in different implementations of different management modules. (c) ''Cooperative storage and compute management.'' The system will define new non-proprietary interfaces and methods that will allow compute and storage management to work together in concert. (d) ''Flexible storage models.'' The system will support a range of different storage models, such as network-attached storage, per-node storage, and hybrids, to allow developers, researchers, and large scale cluster/data center operators to experiment with different kinds of file systems. (e) ''Flexible machine models.'' The system will support different machine models. In particular, it will be VMM-agnostic, able to run different virtual machine monitors such as KVM and Xen. Also, in order to address the cluster squatting problem (when clusters are balkanized by users who reserve and hold nodes for their exclusive use) the system will support a novel bi-model booting capability, in which virtual machine and physical machine instances can boot from the same disk image. == 3. Rationale and Approach == Digital media, pervasive sensing, web authoring, mobile computing, scientific and medical instruments, physical simulations, and virtual worlds are all delivering vast new datasets relating to every aspect of our lives. A growing fraction of this Big Data is going unused or being underexploited due to the overwhelming scale of the data involved. Effective sharing, understanding, and use of this new wealth of raw information poses one of the great challenges for the new century. In order to compute on this emerging Big Data, many research and development groups are purchasing their own racks of compute and storage servers. The goal of the Tashi project is to develop a layer of utility software that turns these raw racks of servers into easily managed cloud computers that will allow remote users to share and explore their Big Data. To our knowledge there are no open source projects addressing cluster management for Big Data applications. We need a project such as Tashi for a number of reasons: (1) No cloud computing cluster management systems have tackled the problem of having both compute and storage management working together in concert, which we believe will be necessary to support Big Data. (2) We need non-proprietary interfaces for cloud computing, and open source is the way to develop these. For example, Google's new App Engine and Amazon's web services require people to build to proprietary API's, so that their applications are no longer vendor neutral, but are tied to a particular service provider. (3) We need an extensible system that can serve as a platform to stimulate research in cluster management for cloud computing. The Tashi system is targeted at two (not always distinct) communities: (1) As a production system for organizations who want to offer medium to large scale clusters to their users. For example, many companies and university departments are purchasing such clusters, and a system like Tashi would help them provide their users with access to the cycles and
Re: [VOTE] accept Tashi into the Incubator
On Mon, Aug 4, 2008 at 6:48 PM, Doug Cutting <[EMAIL PROTECTED]> wrote: > Please vote on accepting Tashi into the Incubator. > > Tashi's proposal is at: > > http://wiki.apache.org/incubator/TashiProposal > > Thanks! +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Etch
http://www.google.com/search?&q=etch -- 12MM hits for an unreleased product (this Etch) http://www.google.com/search?&q=hadoop -- < 600K hits for a product that's been out for over a year Why such resistance to name change? There is this proverb that might be suitable here. The loose translation is: When one person tells you you are a donkey, ignore him. When two people tell you you are a donkey, go buy yourself a saddle." Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Scott Comer (sccomer) <[EMAIL PROTECTED]> > To: general@incubator.apache.org; general@incubator.apache.org > Sent: Thursday, August 7, 2008 2:50:37 PM > Subject: Re: [PROPOSAL] Etch > > Doug is a wise man and that is how we picked the name etch 18 month ago. > > Scott out > > > > > > -Original Message- > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] > Sent:Wednesday, August 06, 2008 12:12 PM Pacific Standard Time > To:general@incubator.apache.org > Subject:Re: [PROPOSAL] Etch > > Doug Cutting has a few nice and short naming rules that I liked when I read > them. I believe one of them was that a Google search for the proposed name > should yield very few matches. Hadoop and Lucene are/were good examples of > that. Here is another naming example. I created this bookmarking service > called "simpy" - simpy.com . Great name - short, memorable, easy to spell, > etc. > people said. The problem with it is that "simpy" is a common misspelling of > "simply". So, another thing to keep in mind. > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message > > From: James Dixson (jadixson) > > To: general@incubator.apache.org > > Sent: Tuesday, August 5, 2008 6:03:28 PM > > Subject: RE: [PROPOSAL] Etch > > > > I have heard the name concern a couple of times now... > > > > When we picked the name Etch about 18 months ago, we knew about the > > Debian release, but frankly we were unconcerned. Debian etch is the name > > of a release of Debian, no different than "4" being a release of Fedora. > > Eventually Debian etch will fade into memory just as sarge and woody > > have. > > > > Etch, in our line of thinking (if it could be said we were doing any > > thinking :-) ) was the name we were giving to the technology, not a > > release. There were no other technologies named Etch or similar, so we > > declared victory and moved on. > > > > So I guess my question back to everyone is this: > > > >What is the concern about the name Etch, really? > > > > 1. Is there a legal trademark issue or a formal Apache branding policy > > issue with using the name Etch such that the use of the name is simply > > not going to be allowed. > > > > - or - > > > > 2. Is there a concern that during incubation, we might have to be > > explicit in communication and always say "Apache Etch" rather than just > > "Etch" because of a fear that a reference to "Etch", taken out of > > context, could be confused with Debian 4.0? > > > > If "1" is true then, absolutely the name should be changed. > > > > But if only "2" is true, then I will need a bit more convincing. I am > > after all very, very lazy and changing the name of a working toolset is > > well... work :-) > > > > > > --- > > James Dixson > > Manager, Software Development > > CUAE Engineering, Cisco Systems Inc. > > Direct: 512-336-3305 > > Mobile: 512-968-2116 > > [EMAIL PROTECTED] > > > > -Original Message- > > From: Niklas Gustavsson [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 05, 2008 3:33 PM > > To: general@incubator.apache.org > > Subject: Re: [PROPOSAL] Etch > > > > On Thu, Jul 31, 2008 at 6:16 PM, James Dixson > > wrote: > > > This a proposal to enter Etch in to the incubator. > > > > > > See http://wiki.apache.org/incubator/EtchProposal for updates. > > > > +1 for incubation (non-binding). While I find this area to be a bit > > overcrowded lately, having both Etch and Thrift at Apache and Protocol > > buffers under ASL 2.0 does offer some interesting opportunities for > > competition as well as cooperation. > > > > I do share the concerns about naming conflicts. Debian is by far more > > well known and trying to establish this project under a conflicting > > name would be hard. > > > > /niklas > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscrib
