Eucalyptus has a lot of vulnerability when it comes to ethical assessment.  Eucalyptus puts the power of a cloud at the keyboard of its users.  It is open-source and the community could potentially use it with malicious intent.  Who can be held accountable if the software is used for destructive purposes?

Eucalyptus has a very broad terms of use policy.  It simply states that contributors and users are responsible for the contributions they make toward the project and the implementation of the software. Users agree that it will only be used for lawful purposes.  Though, in the technology world, there is a lot of grey area. Laws often vary from state-to-state and even more so on the international level.  What if a cloud is hosted in one state, where the laws are loose, and is utilized in another state where they are very tight?  What legislature applies?  This area is still very undefined, and proposes great risk to contributors, users, and Eucalyptus’ responsibility.

On the other hand, the more detailed the terms of use becomes, the less versatility and flexibility you have with the software.  You begin to remove the open-source aspect that the project is based on.  The more you tell users what the software can and can’t be used for, the less likely they are to use it.  It becomes more of a burden to follow all of the terms of use than is worth it.  It’s essentially a catch-22.

I think the most obscene part of the whole project is the business structure.  When I buy something, I prefer to be told up-front how much it’s going to cost.  Eucalyptus gives a trial of there software, then you face a fee for continued use.  If you can’t quite figure out the incredibly dense and technical documentation, you’ll be charged a service fee for any help.  If you want to further specialize the software with add-ons, you’ll probably pay for those too.  Welcome to the Americanized version of marketing, where we nickel-and-dime you to death before you even have a working product.

I still think Eucalyptus has a lot of potential, but it requires a great deal of attention to business structure and project management.  Implement release dates, and stop nickel-and-diming to reach profitability.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

Karl asked me to compile all of the FAIL Meters (Tom Calloway) and come up with one final review.  Here are the results with details elaborating each factor they accrued FAIL points for:

Size: +10pts

Eucalyptus received a total of 10 points of fail due to size and compression.  This suggests a great amount of obsolete code.  The first step would be to dedicate an individual to removing this obsolete code and standardizing the software.

Source Control: +5pts

Many people said the documentation for the source control was extensive, hard to follow, and  dependent on a programming background.  It is slightly more acceptable to require a background in programming when it comes to source control, but not to the point where even those with a background struggle to get through it.  Remember, the goal is to make this project as open-source as possible.  We want even those with no background able to contribute.  If the Wiki is so long that a new user is instantly turned away by the sheer size of the source control documentation, it probably needs to be edited.

Building From Source: +15pts

A few people said that it could be difficult to understand the documentation if you had little programming background.  So I tagged on 5 more points of fail.  This is probably the easiest part to fix.  Within a short time the documentation could be improved and use language that essentially anyone could understand.  This would also allow new users the ability to utilize Eucalyptus without requiring them to have a background in programming.

I also tagged on 10 points for containing hand-written scripts.  This isn’t a world ending add-on.  In fact, we might want to waive this, considering the type of project Eucalyptus is.  It’s a specialized architecture project, so you can expect some custom shell scripts to be included.

System Installs: +10pts

Many people tried to get Eucalyptus out of the 10 pts, explaining that it ‘recommends’ installing in ‘/opt’, but you can choose a different directory.  At the end of the day, it doesn’t matter.  It installs into a directory that it doesn’t/shouldn’t have too.

Releases: +5pts

I added a small amount of fail to releases because of the time frame of releases.  There isn’t any established consistent release date for new versions.  Releases come periodically, every 7-9 months or so.  Establishing a deadline and project goals would greatly increase Eucalyptus interest and drive.  People tend to procrastinate without deadlines.  Having a deadline with project goals gives the community something to look forward too, and the engineers something to work on.

History: +5pts

Eucalyptus started as a University project, and wasn’t open-source until some time after.  I gave them a reduced +5pts because they have earned it in regards to how open-sourced they are now.

Final: 50 Points of Fail “Babies cry when your code is downloaded”

I don’t think this is a bad place to be.  You can see a clear direction for Eucalyptus, and there is a lot of potential.  However, there are a lot of areas that can be improved.

The FAIL Meter assessment allowed me to take a look at the entire Eucalyptus project with a completely unbiased opinion.  Interestingly, the fail meter doesn’t dive deep into the source control.  Eucalyptus could use some improvements in the source code, particularly documentation and standardization.

The bigger problem lies within the management of the project.  Eucalyptus doesn’t follow any release deadlines.  Without release dates, software engineers don’t have a vested interest in the project.  They can get around to their assignment when they feel like it.  The community doesn’t have anything to look forward to and be excited about.  If you think about a successful open source project like Ubuntu, not only do they have planned release dates, but their releases are reflected in their version numbers.  There is always a lot of hype when a release is around the corner.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

Last week, Brian Labbe and I looked at the best computers we could get for the amount we had (~$1000).

This seemed to be the best deal:

http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=1262860&CatId=333

Then, IT said they had a handful of machines.  We scrapped the new hardware idea and waited for delivery.  Unfortunately, Spring break was coming up, and few people were willing to come in over Spring break to set the new machines up.  Dave, Mike, and I stepped up to the plate and came in on Monday and set up the machines to avoid an entire week of delay.  Within a few hours, all of the machines were swapped and ready to go.  We also had lunch at Bushel N’ Peck down the street.  Great food, great price, great service.  I highly recommend trying it!

Meanwhile, I just got back from the conference in DC at the NSF.  I had a lot of fun, it was great to meet everyone and get out-of-town during Spring Break.  It was also an all expense paid trip – so who wouldn’t be excited! It’s back to work at EMC in the morning.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

Of course, something would go wrong.  The fan in one of the machines has died.  We are also running into compatibility issues.  Dave fears the hardware in the current machines may not be supported.  Today, we discussed plausible alternative solutions.  Red hat has provided us with a small amount of money that we could use to buy a couple of new machines to get up and running.  Karl is also going to check with IT and see if they have any newer machines that we could use.

Meanwhile, Dave is going to see what he can do as far as software progress while we wait for a new hardware solution.  He will switch around one of the nodes and the CLC and try to continue so little time is lost.  I seem to be so busy with work at EMC, and numerous meetings that it has been very difficult to keep up with everything.  I have a conference at the NSF next week during Spring break too.  It feels like for every fire I put out, 3 more start.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

Finally, we get to dive into some good stuff.  The Git assignment seemed pretty easy, but a lot of the commands were typos.  I guess that’s what you get for copy and pasting 😉.  I thought it was going to take me quite a bit of time to learn the ins and outs of Git, but I picked it up pretty quick.  Trevor Hodde also pointed me in the direction of GitK, which is a GUI representation of Git.  It gives a visual representation of the last time you pulled from the Git repo.  I would strongly suggest GitK to anyone who is knew to Git.  My group seems to be having some difficulty grasping Git, as two of them have yet to complete the Git assignment, but I am holding out hope.

My group also didn’t follow the details of the assignment, the purpose was to invoke a conflict when multiple people edit the same file.  Instead, they created a new file – no conflicts were made.  I finished the assignment for completeness, but I hope they understand the purpose of Git and version control.  The assignment actually had you set the user.name to “Your Name” and then color.ui, which is legal.  You can have the name variable contain multiple things.  Then, when you when to change it using git config –global user.name ‘James Forkey’ it threw an error saying multiple instances of the variable existed.  The fix I found was to edit the .gitconfig file itself and make it so there was only one name variable with the appropriate context.

I don’t really have much Git experience prior to this, but I know how it works and it’s critical role in the real world.  I can’t wait to really utilize Git to its fullest potential.  I am interested to see if there will be one person committing, or if everyone will be committing, potentially overwriting working code with either broken code, or less efficient code.  I guess this is something we should discuss in the near future.  Dave and Mike have done a great job with the infrastructure portion.  We are almost ready to get our hands dirty.  Exciting!

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

Today was focused on what project to work on.  The potential candidates were VLC, Firefox, Eucalyptus, Irrlicht, and Libre Office.  I joked, we should play the 5-3-1 game.  The 5-3-1 game is where you have a set of 5 options, the first person (The professor in this case) eliminates two options, and the second person (the students in the case) eliminate two more, leaving you with the winner.  We played something similar.  Each student ranked the 5 from least to most favorite, and then we tallied it up.  Eucalyptus won!  This project seems like a really good fit, since we will be able to work with the lead developers and gets everyone’s hands wet in cloud computing.

I also have very little experience with Python, so it will be interesting to pick up a new language along the way.  There is an infrastructure portion that will let the students who are less program-driven and more network-driven a chance to contribute equally.   There are a handful of students who aren’t intrigued by writing code.  Hopefully they are willing to get some hands-on experience early on with the infrastructure.

There was a lot of hard feelings when we came to the conclusion to work on Eucalyptus.  It’s important that they realize that this is the class project, and are willing to contribute to the best of their ability.  It doesn’t mean they can’t contribute to another open source project, but they’ll just have to do it on their own free time.  I have finally installed X-chat on my home desktop, so I can idle the appropriate channels.  This will help me keep up-to-date on the project and assist me with any questions I have once the project gets off the ground floor… which is hopefully sooner rather than later…

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

Week 2 was focused on learning IRC and Wikis. I have a lot of prior experience with IRC.  In the past, I used mIRC for windows, but since I have moved to using Linux as my main OS, it was a little different to get used too.  First, I had to research GUI IRC clients.  I first connected through the terminal, but the interface just isn’t clean enough for me.  I don’t want to have to type a command to see who is currently in the server.  I wanted something that I could see everything on one clean screen.  I finally stumbled on X-Chat.  This is very similar to mIRC for Windows.  It has all the information you need in a simple, easy-to-use, interface.

The Eucalyptus project sounds interesting, but I was also interested in another 3D graphics project too.  Unfortunately, I don’t have the time to work on both projects simultaneously.  The main developers have us working on the eutester portion of the project.  They said there is more documentation than actual code to write.  I wasn’t very thrilled with this idea, but I guess we will see how everything falls into place.

I wasn’t present for the class, and I never made the Wiki, but I have some experience in editing Wikis from a robotics class last semester.  I would really like to see this project get off the ground floor and some serious progress made, but my group hasn’t but the most cooperative at this point.  We’ll just have to wait and see how things develop over the next few weeks.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.

I have been waiting for this class for 7 semesters, and it’s finally here.  The climax of the undergraduate degree in Computer Science.  I hope to learn a lot in this class, and with a group like this:

1. James Celona
2. Long Nguyen
3. Armindo Andrade
4. Marcos Knight
5. James Forkey

Who wouldn’t be excited?

I can’t wait to start our project and get some real experience with VCS and working in a group dynamic.  Utilizing a VCS effectively and learning to work with a diverse group of programmers is the most exciting part of this class.  I’m hoping this class will further my readiness for the ‘real world.’  Regardless of the fact that I have already been accepted to WPI’s graduate program.  Yeah, that’s pretty exciting in and of itself!

I am hoping we get to work on a really cool OSS project.  Obviously, having your name on an OSS project looks great, and it increases your self-esteem to a degree.  You can really respect yourself, having contributed to an OSS project.

From the blog jforkey » wsu-cs by jforkey and used with permission of the author. All other rights reserved by the author.