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
+
Andrew Purtell 2013-03-17, 17:12
+
Amit Sela 2013-03-17, 17:32
+
Michel Segel 2013-03-18, 12:02
+
Doug Meil 2013-03-18, 19:16
Copy link to this message
-
Re: HBase type support
Thanks for the clarification Doug.

Back to my point, I was saying that MD5 and SHA-1 are already part of the Java package so if you're running Java 1.6_xx or Java 1.7_xx, you will have MD5 available.  So it could be a good thing.
Murmur is released under MIT... Is there going to be a licensing issue? (Thinking back to the delay in getting Snappy.) Note: I don't know which is why I am asking so I don't want to be accused of FUD.
:-P

On Mar 18, 2013, at 2:16 PM, Doug Meil <[EMAIL PROTECTED]> wrote:

>
> Sorry I'm late to this thread but I was the guy behind HBASE-7221 and the
> algorithms specifically mentioned were MD5 and Murmur (not SHA-1).  And
> implementation of Murmur already exists in Hbase, and the MD5
> implementation was the one that ships with Java.
>
> The intent was to include hashing appropriate for use with key
> distribution of rowkeys in tables as is often suggested on the dist-lists.
> SHA-1 is probably overkill for the rowkey case, but I wouldn't want to
> stop anybody from using SHA-1 if it was appropriate for their needs.
>
>
>
>
>
> On 3/18/13 8:02 AM, "Michel Segel" <[EMAIL PROTECTED]> wrote:
>
>> Andrew,
>>
>> I was aware of you employer, which I am pretty sure that they have
>> already dealt with the issue of  exporting encryption software and
>> probably hardware too.
>>
>> Neither of us are lawyers and what I do know of dealing with the
>> government bureaucracies, it's not always as simple of just filing the
>> correct paperwork. (Sometimes it is, sometimes not so much, YMMV...)
>>
>> Putting the hooks for encryption is probably a good idea. Shipping the
>> encryption w the release or making it part of the official release, not
>> so much. Sorry, I'm being a bit conservative here.
>>
>> IMHO I think fixing other issues would be of a higher priority, but
>> that's just me;-)
>>
>> Sent from a remote device. Please excuse any typos...
>>
>> Mike Segel
>>
>> On Mar 17, 2013, at 12:12 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>>
>>>> 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
+
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