appamatto

Copyfree is not the new copyleft.

2011-12-04T00:00:00-06:00

Copyfree is not the new copyleft.

04 Dec 2011

This article was inspired by Zed Shaw’s essay, Is BSD the New GPL?.

Simple debate, short article. My premises, the requisite conclusions. Androids fighting Brad and Janet.

For the Uninitiated: Copy{right,left,free}

“Copyright is a legal concept, enacted by most governments, giving the creator of an original work exclusive rights to it, usually for a limited time.” Copyright on Wikipedia

“Copyleft is a play on the word copyright to describe the practice of using copyright law to offer the right to distribute copies and modified versions of a work and requiring that the same rights be preserved in modified versions of the work.” Copyleft on Wikipedia

“Copyfree is a term used to identify the freedom to copy, use, modify, and distribute what you possess.” What is Copyfree?

Is it just a matter of taste?

Some like the BSD license. Others, the GPL. Some butter on the top, others on the bottom. (Don’t eat butter.) Unfortunately “taste” in licensing can come back to bite you—the analogy breaks down as choosing Coke over Pepsi won’t run you afoul of a violations site. (And don’t drink sugar drinks either.)

Our decisions have direct legal consequences for those around us. We decide if the nasty emails get sent and how many IP lawyers the world needs.

Information Morality

I think the right and wrong of information and speech is pretty dry and should be less controversial than my parenthetical dietary recommendations:

Think whatever you want.
Express whatever you can think.
Stay silent when you want to.

Can we be friends?

Zed says that we’re on the same side. Well, I think that copyleft disagrees with my (3) above, since it requires expression where one might have preferred silence. I can’t distribute my program without also distributing its sources if it contains a copyleft component.

Not so friendly! Copyleft also contains all the asymmetry of copyright: licensees will have their right to silence violated but the original creator can go ahead and create proprietary derivatives. It’s much harder to create such a monopoly with copyfree software because licensees are equally empowered to derive their own products.

Simulating a World without Copyright

The smoking gun: copyleft cannot exist without copyright. Without copyright there is no way to force the developers of modifications to reveal their source code.

Meanwhile, copyfree licenses attempt to simulate a world without copyright. When copyright meets its maker we’ll effectively be living in a land of copyfree software.

I choose to waive copyright to my public works, effectively putting them into the “public domain”. This isn’t the most favored copyfree strategy because some countries don’t allow you to waive your copyright. I think that the success of sqlite has shown that these fears about the public domain aren’t warranted.

RTFM the T-Shirt

2011-11-29T00:00:00-06:00

RTFM the T-Shirt

29 Nov 2011

Hokey goal number five on my programmer bucket list: see someone I don’t know walking around wearing a nerdy t-shirt I designed. What higher accomplishment is there?

And so after a bit of inkscaping and some wishful thinking, I bring you the green-on-black, early-bird edition of RTFM: Deus Ex Machina the T-Shirt! You loved (to hate) the article, now you can wear it around.

“That is so full of win. I’ve been needing some new shirts, too.” -Chip Camden

And for the those that prefer a smattering of appropriate command-line punnery, RTFM: man -k Up is also available.

“I think I need to get one of those.” -Chad Perrin

I thank you for your out-of-season yet forward-thinking support.

How to RTFM - Tips for a life of discovery

2011-11-22T00:00:00-06:00

How to RTFM – Tips for a life of discovery

22 Nov 2011 – Houston

My friends and I have often discussed the topic of programmer education. The idea is that programming is somehow unapproachable or favors a certain rare learning style. I can sympathize with this perspective. At the same time I feel that learning how to approach the unapproachable is somehow at the core of becoming a good programmer. The name of this all-important technique is RTFM.

Update: RTFM T-Shirts now available. Spread the euphoria!

Everyone was a newb at some point. Chances are some jerk in #latest-fp-language told you to RTFM and that rubbed you the wrong way.

Well, I’m here to tell you that RTFM is like “Amen!” (or “So say we all!” for you BSG fans) for programmers. These kind souls are just trying to remind you of your commitment to reading TFM which should be no less than religious.

Why RTFM?

First, I really recommend reading Vivek Haldar’s article comparing GUIs and CLIs. This is soul food for the aspiring reader of TFM. Internalization is critical for programming. It’s the only thing that separates effective from ineffective programmers. Your goal is to get as much of your daily required knowledge into your brain-RAM as possible. You do not want the syntax of your language of choice or the switches to grep to reside on disk or on the network somewhere.

RTFM forces you to think about what you’re trying to do, and understand the tool you’re using to do it. It also allows you to discover other tasks that the tool might help you with. It is my experience that this extra processing forces one to actually, uh, think?

The Rules of RTFM

These are simple rules that should guide your daily RTFM practice. The goal here is not to simply get things done—we want to get things done and have learned (internalized) new techniques that will help us next time.

Rule #1: Do not Google (or DuckDuckGo) first

Google is a great tool. Google will match you with the guy who had your problem and show you exactly how he solved it. However, Google Is Not Your Friend.

The reason is this: once you’ve found the one-liner that will get you going and you’ve copy-pasted it into zsh, you’re done. That’s it. Google has deprived you of your quality time with TFM.

Using a pure RTFM strategy, the voyage of self-discovery is something like:

Think about what you’re trying to do or why you’re getting that error.
Remember a similar tool or experience you’ve used before.
Read TFM for that tool or related tools.
Discover new techniques or ways to apply your tools.

Google is the deus ex machina of the programming world, punching plot holes in your epic rise to RTFM stardom. Google has weakened your ability to solve problems by jumping straight to discovery. If you absolutely have to Google, then make sure you also take time to understand the results of your Googling and how you might have found the answers through a more organic process.

Rule #2: Do not settle for an example

When people say that humans learn best by example, they really mean that humans avoid learning when they have examples. This is because examples enable one to employ tools without really understanding how they work.

Try to avoid learning things in opaque chunks. If you’re working with the shell, make sure you’re learning what the a, u, and x switches do in ps aux. This means man ps followed by tinkering with the various options until you develop a satisfying freedom of movement along the various axes of the command.

If you’re working from a big section of code, try changing it and seeing what happens. Make sure you can account for each part of the code. Seeing a chunk of code as an indivisible unit is buying a season pass to that same old article on Stack Overflow for the magical incantations.

Rule #3: Sometimes the code is TFM

Not all projects have great documentation. That being said, most of the projects I use have docs in the decent to awesome range. For example, I would consider Android docs better than decent. I’d consider the FreeBSD handbook to be awesome. Most of the programming languages I use are very well-documented.

Hopefully the documentation for your project captures all behavior that is intended to be public. That still leaves a couple of reasons why the code itself may be the best or only documentation for a piece of software.

It’s my guess that writers read much more than they write and filmmakers watch many more hours of film than they produce. A programmer has to read code well especially now that most programming work consists of correctly using libraries and services written by others. In any case, code reading is sometimes the only way to figure out what received software does and how efficiently it does it. Don’t have the code? Try replacing that component with one of these.

Rule #4: Question your questions

It’s a little-known fact that TFM will answer any question you pose it—as long as it’s the one that TFM was written to answer. It’s like one of those movie kung fu teachers. You’re going to be chasing the chicken and waxing on and off until you man -k up and start asking the right questions.

This generally requires knowledge that won’t be cited, linked, or in any way communicated by TFM. You’re not going to understand a language spec without understanding what the heap and the stack are. Insensitivity to the strangeness of one’s questions is the most difficult obstacle to overcome in RTFMing, and it’s also the most likely to be solved by contact with another human being.

Still, resist the urge to talk with someone. If you need some release, open a shell and echo into /dev/null or tell your barber. After much confusion, much RTFMing and some good luck your brain will turn inside-out and you’ll have an epiphany.

Maybe.

Multiple Fossil Repositories Setup

2011-11-13T00:00:00-06:00

Multiple Fossil Repositories Setup

13 Nov 2011 – Houston

Mananging a few fossil repositories can be daunting compared to the ease of using github for projects.

So why fossil?

License – I’m a copyfree guy, so I appreciate the fossil license, which is a 2-clause BSD license. I never know when I’ll need to fix a bug or add a feature to any software I’m using, and I’m highly unlikely to contribute back to a legally-encumbered piece of software.
Organizational Tools – wiki, issue tracker, events, commentary—all sort of metadata inhabit a typical fossil repository. They’re just as decentralized as your source code. When you move your repository your meta-project organizational data move along with you. In contrast, a git clone from your github isn’t going to clone your issues along with it.
Data store – Fossil uses a SQLite database rather than a pile-of-files for storing repository data. Fossil is thus able to take advantage of nice database properties like atomic transactions.

The setup on FreeBSD: nginx and inetd

I host my fossil repositories on the same machine as my blog. nginx serves my blog as static files courtesy of jekyll and it passes fossil requests to the inetd-managed fossil server on port 8080. I’m using FreeBSD, so adjust your setup accordingly.

The relevant section in /usr/local/etc/nginx/nginx.conf:

server {
    server_name fossil.appamatto.com;
    location / {
        proxy_pass http://127.0.0.1:8080/;
        proxy_redirect off;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

To have inetd manage fossil we need to first add it as a service in /etc/services:

fossil 8080/tcp # Fossil repo hosting

and then let inetd know what to do with fossil requests in /etc/inetd.conf (on one line):

fossil stream tcp nowait.1000 root /home/appamatto/bin/fossil
/home/appamatto/bin/fossil http /home/appamatto/fossil

Lastly, make sure to start your servers and enable their start on boot. In /etc/rc.conf:

nginx_enable="YES"
inetd_enable="YES"

and then in the shell:

# /usr/local/etc/rc.d/nginx start
# /etc/rc.d/inetd start

The repositories directory

The above inetd setup assumes that my fossil repositories are stored in ~/fossil. The magic happens in the fossil http command, which is built to serve a directory of fossil files using a url scheme that chops off the .fossil extension. For example, the repository for this blog is stored in ~/fossil/appamatto.fossil and the url for the repository is /appamatto.

Be fruitful and fossilize

Now that I’ve setup my repository server to manage multiple repositories I am no longer afraid to create quick one-off repositories for my smaller projects. I’d love to hear about further fossil management— ~~managing user credentials across multiple repositories~~ (see update) or their web templates/styles.

Update – single sign-on

It turns out that single sign-on between fossil repositories is easy to setup. Fossil creator drh gives a bit of explanation on the mailing list.

Navigate to Login-Group in the Admin area of your fossil repository. Create a new group (I called mine “group”) and then enter the path to the other repository you’re joining. If you’re using the instructions in this post then the path should be something like /foo.fossil. Thanks for the tip, dchestnykh!

Career Update

2011-04-21T00:00:00-05:00

Career Update

21 Apr 2011 – Houston

This week has been crazy. I’ve simultaneously experienced an explosion in the number of projects vying for my attention and a low point in focus and perseverance. Coincidence? I think not!

I’m transitioning over to a new Android development job at Toktumi, makers of the mobile app Line2. Excitement. Let’s hope I can get everything squared away as I transition out of my current job.

I’ve promised my Dhammapada users that I would give them a style editor, or at least a better color scheme. Given that they have been so generous in their ratings of my work-in-progress, I feel I need to give something back, and quick! Dhammapada has 214 users now, which is pretty nice for its niche. (update 2011-11-13: 659 active installs!)

Due to my work volume, I’ve been inactive in [android]. Hopefully this will pick up again, as it’s a great source of learning for me.

Maru saw some action a couple weeks ago due to some really interesting conversations I’ve been having. It was nice to have some new thoughts about its design, especially the first class dictionary/stack hybrid idea. Thanks Evan!

Bitcoin, the Decentralized Cryptocurrency

2010-12-11T00:00:00-06:00

Bitcoin, the Decentralized Cryptocurrency

11 Dec 2010 – Houston

A lot of my current work is inspired by bitcoin, the decentralized crypto-currency. If you haven’t heard of it, or don’t fully understand how and why it works, then I can assure you that spending some time with it will be a much better use of your time than reading this article.

Bitcoin has an interesting proof-of-work structure called a block chain, which is like a collaboratively defined linked list where adding an element involves solving a problem whose difficulty scales such that it is solved by one person (machine?) globally every ten minutes. Bitcoin’s data is packaged along with this solved problem, and thus the control of the bitcoin block chain rotates randomly among its users, each in proportion to his computing resources. This ensures that there is a central data store for bitcoin without a central authority as long as a majority of the compute power is in benign hands.

The system is a marvel! After letting it sink in for a couple weeks I began to consider other systems based on block chains. And many a protocol appeared in my mind like nails ready for some bitcoin-esque hammering.

I started what became a mega-thread on the bitcoin forums about generalizing bitcoin to other applications. I called the generalizion BitX, since it would support many different protocols like bitcoin and a hypothetical BitDNS. The conversation tended toward a discussion of BitDNS specifically, prompted by recent government action, and BitX discussion resumed here.

Simple Implementation of CubeHash

2010-12-07T00:00:00-06:00

Simple Implementation of CubeHash

07 Dec 2010 – Houston

I was curious about hash functions and decided to implement one of the candidates for SHA-3, CubeHash. The algorithm itself is very simple and features three tuning parameters that allow various speed/security trade-offs.

The implementation is nothing special, as it is derived nearly verbatim from the description of CubeHash. One thing I learned while doing this is that programs whose goal is to obfuscate their input are hard to debug, especially when a reference implementation is not available.

I’m dedicating this code to the public domain; it might come in handy for someone who wants to check their own implementation. Mine shouldn’t win any awards for speed, although gcc is able to vectorize some of the loops.

Check out the fossil repository.