Home | About | Sematext search-lucene.com search-hadoop.com
 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
Michael Segel 2013-03-19, 00:42
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