Ben's Blog

While working on a project this week, I was trying to see what some silk screen art would look like on a PCB I’m working on, but the “photo realistic” export mode of gEDA pcb was restricted to only green solder mask, tin plating, and white silk screen. The fab house I plan to use only provides purple solder mask, gold plating, and white silk screen. Rather than try to tweak the green image in GIMP until it looks half decent, then repeating the process for each candidate silk screen image (and then each future project as well), I decided I would just write a patch!

My patch for gEDA pcb allows the user to now select a solder mask colour of green, blue, red, purple, black, or a (questionable) white, a pad plating colour of regular tin or gold, and a silk screen colour of white or black. All of these options are pictured above. You can find my proposed patch here, and hopefully it be accepted into the core software soon so that you can get it from your system’s repository.

I’ve been a fan and advocate of open source software for some time now, but I am pretty sure that this is the first time that I have actually submitted a patch to a somewhat mainstream open source project. I’m pretty pumped and I hope to do more soon. I heartily recommend it.

Update 2012-06-14: After some suggested improvement to my patch (additional yellow silk as well as the addition of copper and silver pad plating) my patch has officially been accepted into the gEDA pcb repository! You can get the latest version of the code here: git clone git://git.geda-project.org/pcb.git

A while ago I read this excellent article by Evil Mad Scientist Laboratories describing the need for some form of visual diff tool for open hardware projects. I had been thinking this was a great idea, but while working on a recent project, decided to actually start implementing something. I use the gEDA suite of tools, so that is what I’m creating this for, but the majority of the plumbing should be reusable for other file formats.

The first piece of this puzzle for me was automatically making image files of my schematics and PCBs that have changed and adding them to each commit. GitHub has image diffing capabilities built in, so this works great. I implemented this a pre-commit hook in .git/hooks/. My git hooks can be found here. I have designed them to work with the git-hooks tool by Benjamin Meyer.

This script seems to work fine for me, though I’m open to suggestions for improvements. My major issues with how the hooks work (which are more issues with git than my hook) are

1. The status message in the auto-generated commit comments is not being updated with the new image files and
2. Hooks don’t get pushed into remotes

The first issue feels like a bug to me, but I suspect that it was done intentionally for some reason I’m not aware of. I have played with a work around by adding a prepare-commit-msg hook that just regenerates the commit message comments, but I have tested the pre-commit hook enough that I don’t feel I need to be aware of the addition of the images.

The second issue I am told is a security issue as it would cause arbitrary code to be executed on the machines of others who might clone (and possibly even the server). One nice feature of the git-hooks tool is that it can use hooks in a local repo directory, so if you include my scripts in the git_hooks repository, you just need to run ‘git hooks –install’ and you will have the hooks working. Without that tool, you can just manually copy them into the proper file in the .git/hooks/ directory.

This method works well if I want to view visual diffs online, but sometimes I might be offline or perhaps I just don’t want to push my project to a public GitHub repo. For that, I plan to make some simple scripts that call visual diffing tools on my local repository. Git has the capability to set your git diff tool, so my plan is to write a wrapper script that picks the right tool based on file types. This script might also generate an image from files that cannot be diffed directly and don’t have the above auto generated files

Edit: Of course not 20 minutes after I publish this post I discover schdiff, a tool bundled with gEDA since the start of 2012 that is designed to hook into git-difftool to provide a visual diff of gschem .sch files. One format down, some more to go.  

Edit 2: Less than a day later and I discover there is also a pcbdiff tool on my computer that came with gEDA pcb. In Arch Linux, it installs to /usr/share/pcb/tools/pcbdiff, but it is not in the path, so in my .bashrc I just added ‘export PATH=”$PATH:/usr/share/pcb/tools”‘ at the end. I feel pcbdiff outputs images that are too low a resolution, plus it can’t handle when the .pcb files change in physical size, so I might submit a patch or two. Long story short, now I just need to make a script that auto-calls these diff tools based on the file type.

At the end of last year, Microsoft launched the Kinect, a motion tracking add-on for the Xbox 360 gaming platform. Adafruit Industries, an open source hobbyist hardware company, announced that they would be offering a bounty to whomever first released an open source driver for the Kinect. The bounty started at $1000, but each time Microsoft complained about it, they raised the bounty. After only a week, the bounty had increased to $3000 and was awarded to a man in Spain. Within a few weeks of that, and having seen all of the interesting things that people were doing with the Kinect (and the large volume of sales they were receiving because of it), Microsoft changed their story, saying that they had originally left the Kinect open for such 3rd party projects.

I followed the story pretty much from the beginning and it was pretty interesting to see how things progressed. However, a few days ago Johnny Lee, a former developer of the Kinect and author of the Procrastineering blog, announced that he had been pushing for Microsoft to release Kinect drivers, but that they were unwilling. As a result, he had sponsored Adafruit to organize the Open Kinect challenge. While it probably would have been in Microsoft’s best interests to release the driver themselves, keeping Kinect development largely done on their platform, the Open Kinect challenge made a cross platform driver available which ends up benefiting everyone.

I have been using an Apple MacBook as my primary computer for almost four years now. The hardware is great (compact, light, and powerful) I have enjoyed that it has a clean interface and the same solid backend as some of my other favourite operating systems (after all, it is basically a customized, rebadged FreeBSD).

Today, however, I was prompted to install the latest OS X update and see that it mandates the installation of the Mac App Store. Anyone who has spent any time with me near an iPhone/iPad/Touch knows how I dislike the App Store. I will try not to rant too much here, but the basic points of my dislike of the system are as follows.

1. The App Store is a bottle neck for app developers, necessitating a long delay between completion of an app and release to the world. Many apps also get blocked, often with poor rational as to why. This leads me to my second point.
2. The App Store rejects apps for very hypocritical reasons. Two main examples come to mind. Google Voice was an app blocked because it replaced iPhone functionality. They also removed other 3rd party, Google Voice related apps at the same time. In reality no functionality was replaced as the iPhone had no support for using Google Voice on its own. In fact, there are a number of alternative dialers on the App Store that do replicate the iPhone’s features, yet they were permitted to stay. Another case was one where a dictionary app was blocked because it contained adult words. Meanwhile, the built in dictionary that comes with iOS contains all the same adult words and is included with the phone without an option to exclude those words.
3. The above points are both ones that I feel are valid concerns, but are mostly just annoyances. My last concern is with the fact that the App Store blocks un-approved apps and leaves Apple with the power to remove any app from your phone that they don’t want you to have (as was demonstrated with the third party Google Voice apps). This demonstrates that Apple has no desire to respect their customer’s rights as product owners. I know that they masquerade as doing this to maintain a high quality product (their success at which is debatable, at best). However, if that were truly their concern, they could provide an “approved” and “unsupported” section in the App store. Apps that are queued up in the approval process could be put into the unsupported section until they get the Apple stamp of approval. An even better option, if you ask me (and just about any free software advocate) would be to provide repositories that users could add to the App Store. They would work just like the unsupported section, possibly right along side it, and would remove the ability for Apple to pull the plug on user software.

This brings me back to the Mac App Store. This new store, to my understanding, requires an iTunes account to access it and, like the iOS App Store, contains Apple approved apps only. At the present, I am still able to install all my favourite apps without Apple’s help, but things are looking bleak in that area. It seems to me that it is only a matter of time before Apple locks down their Mac OS X system as much as they have the iOS devices. Seems like now is a good time to finally jump ship and move on to a system that respects its users.

I just read an article the other day about an interesting conflict between those that speak out for pro-piracy and those fighting for free (as in freedom) software. In Sweden, the political party that is aptly named the “Pirate Party” is lobbying for new copyright laws, specifically that any copyrighted material will become public domain 5 years after first being published, among other things. The free software advocates, however, depend on the current indefinite copyright law in order to keep their licenses, such as the GPL, working to protect free software from being utilized in proprietary software. Richard Stallman, founder of the Free Software Foundation, has pointed out that, if this new copyright law was introduced, proprietary software would only have the binaries released to the public domain and not the source code. Not only that, but these software providers could put time bombs in the software making it cease to function after the copyright has expired. Add to that the fact that after 5 years, any open source technology could be utilized by these proprietary software companies without passing on the freedoms to the user, this new law could actually end up doing more harm than good.

Stallman proposes a few solutions to this dilemma. The first option would be to allow an extended copyright for free software, but the Pirate Party accurately argues that this opens the doors to other kinds of exceptions, which could quite quickly defeat the whole expiry proposal. The second option Stallman suggests, which in a perfect world I think would be the best, is that proprietary source code would have to be released to the public domain upon expiry as well as the binaries. I suspect that enforcing this kind of ruling would be quite difficult, however, especially if you consider software providers that have faded away within the copyright period of their software and simply aren’t around to release source code. The final solution, which is likely the most feasible, is to have a variable copyright expiration where the most open/free content would be allowed to retain its copyright the longest. This way they do not have to allow for any special exceptions for different groups. The trick here is to find an accurate way of determining where any content fits on this continuum. Fully open and fully locked down software would be easy to pick out, but the gray area would be a tough call. Even amongst the open source community, licenses such as BSD might not be considered as open as ones such as the GPL as the BSD license allows commercial use, but one could also argue the opposite as the GPL locks out users who want to use the software for commercial use.

Lately I have been quite a big fan of Free and Open Source Software (FOSS). In fact, this blog runs purely on FOSS. However, not too long ago I was an advocate for digital piracy and anti-copyright thinking (and I am still not fond of copyright or “intellectual property”). It is interesting how two groups who have quite a number of common sentiments towards copyright law and “the man” can have drastically different demands for the industry as a whole. The fact that a small thing such as copyright expiry which seems beneficial to everyone can end up hurting a a group that is so similar in mindset is quite eye opening. I still fully agree with the Pirate Party that something needs to be done about copyright laws, but if that comes at the expense of FOSS, something needs reconsidering.