Author: DrCos

As you have seen in my last post or elsewhere, Facebook has recently added a dubious patent clause in the license of multiple projects including ReactJS. And predictably, a number of organizations, companies, and open-source advocates made it clear that it’s way too dangerous to keep on using the code with such restrictions because of possible legal repercussions.

Well, I am pleased to tell to all my readers, that they have back-tracked on this after Apache Foundation, WordPress, and many others have express their clear intention of switching to safe alternatives to React.js and other frameworks from FB, or banning their use. As you all know, FOSS is a free market ecosystem; it is thriving from the forces of intellectual competition, always offering multiple choices to its users. And this approach won again: facing the danger of loosing their user base and, effectively, rendering themselves irrelevant, they made the decision to, once again, re-license some of their projects under MIT.

Namely, ReactJS will be released under the new license. So if you are using it – make sure to update your dependencies to v.16 once it is out next week. Remember, re-licensing isn’t usually retroactive, so don’t fall into that trap.

Disclaimer: I am not using, planning nor recommending to use any Facebook’s sponsored projects

In somewhat recent revelation about the pitfalls of infamous Facebook “BSD + Patents” license, FOSS developers becoming more acutely aware and alarmed about the consequences.

I won’t bother you with much details, as they are readily available elsewhere. I just want to point out that Facebook is hedging their open-source “exposure”. What they are effectively saying is “Go ahead and use our awesome stuff. But if we ever decide that you’re competing with us, we’ll yank your licence to use our frameworks so fast your shoes will fall off.” It doesn’t matter if someone has developed this code for you: you won’t be able to use it anyway.

That’s the essence. It is the original intention of the license behind ReactJS and a few other frameworks. And that’s why Apache Foundation has moved the license to Cat-X, prohibiting any of its projects to touch things like ReactJS. Facebook software is NOT compatible with the projects developed under widely accepted and respected ALv2.

Here’s the excerpt:

Facebook BSD+Patents license

The Facebook BSD+Patents license includes a specification of a PATENTS file that passes along risk to downstream consumers of our software imbalanced in favor of the licensor, not the licensee, thereby violating our Apache legal policy of being a universal donor. The terms of Facebook BSD+Patents license are not a subset of those found in the ALv2, and they cannot be sublicensed as Alv2.

These are the unintended consequences of meddling with well thought open-source software licenses. That is the beauty of open-source: if you trying to lock people in or out – they will move. It doesn’t matter how much money you have, how big you are, nor what your SJW position is. Developers will go, and the users will as well.

I’m sure we haven’t heard the last of it yet. And that’s the damning and loud application of the golden rule!

A few days ago, I gave this talk about the Apache Software Foundation processes (however few of them are there) and how communities operate. If you are interested, there’s the recording of the webinar.

As you might have noticed, my blog is no longer hosted on Blogger.com (actually Google).

I did it for two reasons:

I was planning on it for a long time because of somewhat mediocre functionality of the Blogger.

What was the last straw is the Google’s reaction to the intellectual argument of James Damore (if you aren’t familiar with the story, it means you probably were a part of the first Mars expedition). I cannot trust my content to a company that suppresses the free speech in full disregard to the individual rights, protected by the law of the land.

I made an effort to make sure that old URLs are working properly and redirect you to the new location. That should take care about cached searches and bookmarks. If you notice that something is missing – please let me know, so I can fix it ASAP.

Well, ever since the company behind the read-only open-source project called Tachyon has decided to change the name of the project, I was puzzled. If you build something successful, you want the name of it to be recognized, right? In marketing, it is called “brand recognition”.

Why would Coca-Cola rename their product into SludgeWaters? Indeed, it doesn’t make much sense! The most infamous brand-recognition screw-up was when SUNW (Sun Microsystems) got renamed to JAVA on the NASDAQ. And _that_ ended well, for sure. The brilliant idea belonged to the Silicon Valley class-clown with the pony-tail. I am sure you know, whom I refer to.

At any rate, why an allegedly successful software project would change its name in a middle of the rise? I have a hypothesis, that it has been caused by the fact that any time one searches for Tachyon on Google (or elsewhere), the first link popping-up would be to my blog from last year and the close second would point to the story how Tachyon BDFL has decided to remove my benign answer from their public mail list.

So, in the interest of the history preservation, I am putting up the new one, but correcting the name to reflect new reality of Alluxio project. The technical findings stand the same, so just go and read the year old blog to figure where the old application with the new name is falling short.

The last but not least, since the time of the original write-up, Apache Ignite has graduated to Apache TLP project, that’s why the “(incubating)” suffix is dropped as well 😉

Today we will be looking into how we can speed Hive using Apache Ignite. For this particular exercise I will be using Apache Bigtop stack v1.0 because I don’t care wasting my time with manual cluster setting; nor I do want to use any of the overly complex stuff like Cloudera Manager or Ambari. I am a Unix command-line guy, and CLI leaves all these fancy yet semi-backed contraptions biting the dust. Let’s start.

For the simplicity I’d suggest to use docker. If you don’t know how to use docker you can do the same on your own system and clean the mess later. Or better yet – learn how to use docker (if you’re on Mac – you’re on your own!). Despite all the hype around it, it is still a useful tool in some cases. I’ll be using one from an official Bigtop Ubuntu-14.04 image:

Now you can follow bigtop-deploy/puppet/README.md on how to deploy your cluster. Make sure you have selected hadoop, yarn, ignite-hadoop, and hive while editing /etc/puppet/hieradata/site.yaml (as specified in the README.md). Once puppet apply command is finished you should have a nice single node cluster, running HDFS, YARN, and ignite-hadoop w/ IGFS. Hive should be configured and ready to run. Let’s do a couple more steps to get the data in place and ready for the experiments:

and now to Hive. Make sure it is executed with proper configuration to take advantage of in-memory data fabric provided by Apache Ignite. Let’s start Hive CLI to work with Ignite cluster, set the tables and run some queries:

Notice the times of both queries.Quit the hive session and restart it with standard config to run on top of YARN:

% hive cli

;; All the tables are still in place, so let’s just repeat the queries:SELECT COUNT(*) FROM batting WHERE year > 1909 AND year <= 1969;SELECT a.year, a.player_id, a.runs from batting a JOIN (SELECT year, max(runs) runs FROM batting GROUP BY year ) b ON (a.year = b.year AND a.runs = b.runs) ;

Once again: notice the execution times and appreciate the difference! Enjoy!