Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # user >> HBase type support


+
Nick Dimiduk 2013-03-13, 16:42
+
David Koch 2013-03-14, 16:51
+
Michel Segel 2013-03-15, 12:25
+
Nick Dimiduk 2013-03-15, 17:06
+
Michel Segel 2013-03-15, 22:35
+
Nick Dimiduk 2013-03-19, 20:34
+
Nick Dimiduk 2013-03-15, 17:11
+
James Taylor 2013-03-15, 17:55
+
Nick Dimiduk 2013-03-15, 17:57
+
lars hofhansl 2013-03-16, 05:45
+
Michel Segel 2013-03-16, 12:18
+
Michel Segel 2013-03-16, 12:26
+
Andrew Purtell 2013-03-16, 12:59
+
Michael Segel 2013-03-17, 16:13
Copy link to this message
-
Re: HBase type support
> This then leads to another question... suppose Apache does add encryption
to Hadoop. While the Apache organization does have the proper paperwork in
place, what then happens to Cloudera, Hortonworks, EMC, IBM, Intel, etc ?

Well I can't put that question aside since you've brought it up now
twice and encryption feature candidates for Apache Hadoop and Apache HBase
are something I have been working on. Its a valid question but since as you
admit you don't know what you are talking about, perhaps stating uninformed
opinions can be avoided. Only the latter is what I object to. I think the
short answer is as an Apache contributor I'm concerned about the Apache
product. Downstream repackagers can take whatever action needed including
changes, since it is open source, or feedback about it representing a
hardship. At this point I have heard nothing like that. I work for Intel
and can say we are good with it.

On Sunday, March 17, 2013, Michael Segel wrote:

> Its not a question of FUD, but that certain types of encryption/decryption
> code falls under the munitions act.
> See: http://www.fas.org/irp/offdocs/eo_crypt_9611_memo.htm
>
> Having said that, there is this:
> http://www.bis.doc.gov/encryption/encfaqs6_17_02.html
>
> In short, I don't as a habit export/import encryption technology so I am
> not up to speed on the current state of the laws.
> Which is why I have to question the current state of the US encryption
> laws.
>
> This then leads to another question... suppose Apache does add encryption
> to Hadoop. While the Apache organization does have the proper paperwork in
> place, what then happens to Cloudera, Hortonworks, EMC, IBM, Intel, etc ?
>
> But lets put that question aside.
>
> The point I was trying to make was that the core Sun JVM does support MD5
> and SHA-1 out of the box, so that anyone running Hadoop and using the
> 1.6_xx or the 1.7_xx versions of the JVM will have these packages.
>
> Adding hooks that use these classes are a no brainer.  However, beyond
> this... you tell me.
>
> -Mike
>
> On Mar 16, 2013, at 7:59 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>
> > The ASF avails itself of an exception to crypto export which only
> requires
> > a bit of PMC housekeeping at release time. So "is not [ok]" is FUD. I
> > humbly request we refrain from FUD here. See
> > http://www.apache.org/dev/crypto.html. To the best of our knowledge we
> > expect this to continue, though the ASF has not updated this policy yet
> for
> > recent regulation updates.
> >
> > On Saturday, March 16, 2013, Michel Segel wrote:
> >
> >> I also want to add that you could add MD5 and SHA-1, but I'd check on us
> >> laws... I think these are ok, however other encryption/decryption code
> is
> >> not.
> >>
> >> They are part of the std sun java libraries ...
> >>
> >> Sent from a remote device. Please excuse any typos...
> >>
> >> Mike Segel
> >>
> >> On Mar 16, 2013, at 7:18 AM, Michel Segel <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Isn't that what you get through add on frameworks like TSDB and Kiji ?
> >> Maybe not on the client side, but frameworks that extend HBase...
> >>>
> >>> Sent from a remote device. Please excuse any typos...
> >>>
> >>> Mike Segel
> >>>
> >>> On Mar 16, 2013, at 12:45 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> I think generally we should keep HBase a byte[] based key value store.
> >>>> What we should add to HBase are tools that would allow client side
> apps
> >> (or libraries) to built functionality on top of plain HBase.
> >>>>
> >>>> Serialization that maintains a correct semantic sort order is
> important
> >> as a building block, so is code that can build up correctly serialized
> and
> >> sortable compound keys, as well as hashing algorithms.
> >>>>
> >>>> Where I would draw the line is adding types to HBase itself. As long
> as
> >> one can write a client, or Filters, or Coprocessors with the tools
> provided
> >> by HBase we're good. Higher level functionality can then be built of on

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
+
Amit Sela 2013-03-17, 17:32
+
Michel Segel 2013-03-18, 12:02
+
Doug Meil 2013-03-18, 19:16
+
Michael Segel 2013-03-19, 00:42
+
Mohamed Ibrahim 2013-03-17, 17:24
+
ramkrishna vasudevan 2013-03-18, 03:01
+
Michel Segel 2013-03-18, 11:51
+
Nick Dimiduk 2013-03-19, 20:35
+
Jonathan Hsieh 2013-03-18, 23:54
+
Michael Segel 2013-03-19, 00:31
+
Nick Dimiduk 2013-03-19, 20:38
+
Nick Dimiduk 2013-03-19, 20:30
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB