Wednesday, August 8, 2012

luckyBackup: rsync GUI/front end

I can read you're mind and right now you're thinking "Pfft, why aren't you extreme enough to use rsync without a front end?" Well, I'm not.

There are plenty of frontends for rsync using all the various toolkits like Qt or GTK or etc. The best I've found (best==most-polished) is called luckyBackup. It's a Qt 4 program, and I love me some Qt.

Anyway, that's all.

Tuesday, August 7, 2012

Epic Pokemon wallpaper collection

Wallpapers are awesome. Pokemon is awesome. Whoever decided to combine them and make a minimalistic version of each pokemon is epic.

The 493 is just that: all 493 Pokemon, captured in a very unique minimalistic style. You can grab your favorite, or download them all and get a wallpaper rotator. It's your choice, but I personally think that you gotta catch em all.

Click to be teleporter


2012 Zombie Event Tracker

Ever since that whole incident with the bath salts, people seem to be much more afraid of the whole "zombie threat". While it's not exactly a true viable threat, for those of us who tend to perk up at the idea of "Z-Day", this little map showing "Zombie Events" in 2012 is quite interesting. Not in any real sense of the word, mind you; few of the events could actually be described as "zombie attacks", since they're usually over things that us  sentient folk tend to worry about, like money for car parts. But it's still interesting to see the strange trend of zombie-like fighting tactics used by people all over the world. (And there's either been a recent influx of it this year, or this has been going on for a long time and you never hear about it. Not sure which.)


Monday, August 6, 2012

I love LOVE

If you haven't heard of mari0, get your head out of the ground and go download it. It was an awesome idea and awesome implementation, but more important to me is that it introduced LOVE to me.

LOVE (technically "LÖVE", but I'm too lazy to type it like that all the time) is a 2D framework for Lua for games. A while ago, I got bored and tried to make 2 different card games in C++, because I had thought of how I could do certain things in OOP. But as soon as it came to UI, I screeched to a halt. Now that I've found LOVE, and Lua is OO, I'll probably be able to port what little I had for both and continue.

I haven't used LOVE too much so far but it is really simple to use (especially on Linux.) Running Arch, the several different entries in the AUR failed, so I just downloaded and compiled it with no problems. (packer probably grabbed the dependencies, so I'd recommend at least trying the AUR first.) After that, it was as simple as downloading the example and typing 'love' to see my LOVE install in action.

There's a really helpful guide on getting started with LOVE, even with a "Hello World" example, but I didn't want to have to keep compressing the Lua files to Love files just to mess around, so to get around this, I discovered that all you had to do was just to pass a directory to love, like "love example" or "love .".

I also love that there is an entire "Programming in Lua" book available online, just like Git. That will probably be my next read, especially if I want to move forward in LOVE.


Richard Stallman's speech requirements

This is really more out of interest than trying to bash RMS, but I found this quite a while ago and it really does shape your perception on how you see someone.

Click here

As an ideologist, I tend to stand behind Richard (although not 100%), but as a person, this just seems so extremely persnickety. This is something that you'd expect to hear on a movie where some extremely important royal figure wants everything correct down to a T. I mean, he talks about how much sugar he likes in his drinks and what temperature he prefers to sleep at. The stuff concerning GNU and free software, I understand, it's all the more picky stuff that -quite frankly- most of us just learn to make small compromises (if choosing regular Pepsi over Dier Pepsi could even even be considered a "compromise"). Like I said though, this isn't at all to insult Richard; some of the points he makes are just things that a lot of people probably think but don't have the courage to say:
When I'm trying to decide what to do, often I mention things that
MIGHT be nice to do--depending on more details, if it fits the
schedule, if there isn't a better alternative, etc.  Some hosts take
such a tentative suggestion as an order, and try moving heaven and
earth to make it happen.  This excessive rigidity is not only quite
burdensome for other people, it can even fail in its goal of pleasing
 I'm just saying that it seems like Richard could be a bit more tactful when discussing some of the points:
I do not eat breakfast.  Please do not ask me any questions about
what I will do breakfast.  Please just do not bring it up.

It's kind of an interesting read, although decently useless, unless you want to prepare to meet RMS someday or something.

Sunday, August 5, 2012

A newbies few thoughts on Git

Being an absolute newbie to version control (aside from Dropbox...), my experience with Git over the last few days has been extremely enlightening. I haven't used anything else like Subversion or CVS, but Git seems extremely elegant, yet powerful. It's definitely a daunting task, especially with no other version control software experience under one's belt, but the free online book called "Pro Git" is by far the best resource I could ask for. It explains everything you need to know (at least for a beginner) in the right order and in a way that is very easy to understand.

I started out using Git on Windows and then moved into Linux and I've noticed that the Git client on Linux seems much more strict. I'm currently working with Google Code as a remote repository and after a frustrating dozens of searches, I discovered that the Windows version of git is ok with the .netrc file being multiple lines: the Linux version is not.

That's all for now. I think I'm definitely glad that I chose Git to start out with.

Friday, August 3, 2012

OSS licenses summarized in one sentence

Up until now, I've used the GPL for all of my open-source ventures because they've mostly been things that I've just been working on for fun, on the side. My newest project isn't by any means a startup, but it is more involved than anything I've done before so I'd like to use more discretion when choosing a license. The problem is, many licenses are just legal mumbo jumo, and their "summaries" tend to copy/pasted portions from the license itself. So without further ado, here's a very, very simplified version of many of the popular open-source licenses from a developer's standpoint, which might just help you decide in general what route to take.

The Licenses

More Restrictive:
  • GPL - GNU Public License v2
    Your source code can be redistributed and changed, but any changes must also be redistributed under the GPL (meaning no proprietary forks), and any code you use with this code must also be under the GPL.
  • GPL - GNU Public License v3
    Identical to the GPLv2 with the several additions (patents, restrictive hardware, DRM., etc), most of which you will most likely not have to be concerned about if you're not a giant multi-billion dollar company, or Linus Torvalds.

Less Restrictive:
  • LGPL - Lesser GNU Public License
    Like the normal GPL, but allows it to be dynamically linked with non-GPL applications, and it also adds the "attribution requirement" -acknowledging your work when creating a derivative; this is used a lot for libraries that want to be under the GPL, but want non-GPL programs to be able to use them.
  • MPL - Mozilla Public License
    As far as I can tell, identical to the LGPL, except that people can use any code you release via static linking while the LGPL only allows dynamic; static linking means combining the source code into an executable, whereas dynamic means keeping it separate, like in a DLL file.
  • OSL - Open Source License
    Very similar to the LGPL, even including the attribution right; the main difference is that when anyone distributes your "work" (not sure if that means just code or includes binaries) or any derivative, they must make a "reasonable effort" to make sure that whomever is using it agrees to the license.
    ("You must make a reasonable effort under the circumstances to obtain the express assent of
    recipients to the terms of this License.")
  • MIT License
    There are no restrictions on what people can or can't do with your code, it just must be accompanied by the license; quite simply, as FossWire puts it, "Here's the source code, do whatever you want with it, but if you have problems, it's your problem."
  • BSD License
    Essentially identical to the MIT license, only anyone who uses your works to create a derivative are not allowed to use your name to promote their derivative; you can also include a clause that forces them to include "This includes code under the BSD license" in their program.
  • Apache 2.0 LicenseEssentially an extension of the BSD License, adding on a requirement that anyone who changes your work must mark the files in which changes were made; it also handles things that are more the concerns of big companies like patents and trademarks.
  • zlib/libpng License
    Anyone can use your code for anything they wish, but anyone who uses your code cannot claim that they wrote it and altered versions need to be identified as not being the original.
  • WTFPL - Do What The Fuck You Want To Public License
    Anyone can do, quite literally, whatever they want with your code.
    (This license is not endorsed by the Open Source Initiative.)

Believe it or not, there really aren't a lot of good resources on what license to choose, from what I've found; most of them just copy and paste information directly from the license, as if that's supposed to be some kind of summary. And this list is certainly not supposed to be the resource to end all resources, it's supposed to help point you in the right direction. After reading this, hopefully you can narrow it down to 1 or 2 and then do research on them to make sure that they are what you are after.

More Resources

That being said, I did find a very, very excellent slideshow on this matter called "Making Sense of Open Source Licenses". I only wish that I could listen to whatever lecture went along with it. He basically divides them up into the following categories:

  • Give Me Credit: BSD, MIT, Apache
  • Give Me Fixes: LGPL, MPL
  • Give Me Everything: GPL 
He also makes some good points such as:
"Different licenses create different communities."

Another good resource is an article on "How to choose a free software license" that basically breaks down a developer's motivations and then suggest licenses from there. There are a ton of resources like this, but this one seems to get to the heart of the matter much better. He doesn't really branch beyond the GPL and BSDL though.

Another neat site I found was called TLDRLegal which lays out licenses in a very, very easy to understand manner. The explanations could use a little work, but the three categories of "Can", " Can't", and "Must" really help.

By far, the best resource I found is a site is a PDF on OReilly's website that walks you through the licenses actual texts and explains what they mean in plain English. Not quite one sentence, but probably the next step after choosing a license to investigate.

Lastly, whilst researching, I just happened to find an excellent comment on StackExchange:
A friend of mine once pointed out that licenses tell you what the license authors were scared of.
If you're scared of having your name dragged through the mud, then the BSD license will seem better. If you're scared of having your software put into a proprietary piece of software, then the GPL will seem better. Whatever the license, the author chooses it because it protects them against what they are afraid of.
Different people have different concerns and so use different licenses.
To me, this is interesting because it kind of examines the other side of the coin as the previous article: consider not only what you want, but also what you don't want.

Final Notes

Please note that -as a developer writing this article- every one of these licenses permits you to sell your software -even the GPL. Also, as owner of the code (assuming the code you're using is...ya know, yours), you can release one version of your program under one license, say, the GPL, and then release another version under another, such as BSD or even closed source. The only thing to keep in mind is that with some of the more restrictive licenses, you cannot change what license a version of your software that has already been released is available under: you can only change what future versions will be under.

Dual-licensing is another thing to take into consideration, but the term itself is really kind of misleading; it makes it sound like the code is subject to 2 licenses, but that is not the case. In reality, your code is essentially under the least restrictive license, but gives the user the ability to distribute it under any of the more restrictive licenses. You're mostly going to see dual-licensing with Copy-left licenses; it makes no sense to license something under BSD/GPL because someone can just release a derivative under the BSD license, making the GPL utterly useless.

I hope this was helpful, and make sure to read the full text of the license before deciding on one.

PS - It actually took quite a bit of research to find out the nuances between some of these, such as the MPL and the LGPL, or the BSD and the MIT, but some people ask the dumbest questions. "What's the difference between the GPL and MIT?" Wow, really? They only happen to be directly opposite.