Not music nerds, obviously.

I don’t know anything about music. I know there are letters but sometimes the letters have squiggles; I know an octave doubles in pitch; I know you can write a pop song with only four chords. That’s about it.

The rest has always seemed completely, utterly arbitrary. Why do we have twelve notes, but represent them with only seven letters? Where did the key signatures come from? Why is every Wikipedia article on this impossible to read without first having read all the others?

A few days ago, some of it finally clicked. I feel like an idiot for not getting it earlier, but I suppose it doesn’t help that everyone explains music using, well, musical notation, which doesn’t make any sense if you don’t know why it’s like that in the first place.

Here is what I gathered, from the perspective of someone whose only music class was learning to play four notes on a recorder in second grade. I stress that I don’t know anything about music and this post is terrible. If you you so much as know how to whistle, please don’t read this you will laugh at me.

I mentioned recently, buried in a post about UI changes, that Twitter’s latest earnings report included this bombshell:

We are going to fix the broken windows and confusing parts, like the .@name syntax and @reply rules, that we know inhibit usage and drive people away

There’s an interesting problem here. UI is hard. You can’t just slap a button on the screen for every feature that could conceivably be used at any given time. Some features are only of interest to so-called “power users”, so they’re left subtle, spread by word-of-mouth. Some features you try to make invisible and heuristic. Some features are added just to solve one influential user’s problem. Some features are, ah, accidental.

A sufficiently mature, popular, and interesting product thus tends to accumulate a small pile of hidden features, sometimes not documented or even officially acknowledged. I’d say this is actually a good thing! Using something for a while should absolutely reward you with a new trick every so often — that below-the-surface knowledge makes you feel involved with the thing you’re using and makes it feel deeper overall.

The hard part is striking a balance. On one end of the spectrum you have tools like Notepad, where the only easter egg is that pressing F5 inserts the current time. On the other end you have tools like vim, which consist exclusively of easter eggs.

One of Twitter’s problems is that it’s tilted a little too far towards the vim end of the scale. It looks like a dead-simple service, but those humble 140 characters have been crammed full of features over the years, and the ways they interact aren’t always obvious. There are rules, and the rules generally make sense once you know them, but it’s also really easy to overlook them.

Here, then, is a list of all the non-obvious things about Twitter that I know. Consider it both a reference for people who aren’t up to their eyeballs in Twitter, and an example of how these hidden features can pile up. I’m also throwing in a couple notes on etiquette, because I think that’s strongly informed by the shape of the platform.

Last month @zandrmartin asked me on Twitter:

i would love to read a post about things you would recommend newish programmers learn, esp those coming from a php web background ⮹

not even tutorials as such, just like ‘you should learn about x and how to implement it effectively’ would be great ⮹

like when you were talking about bit masks a while back, i have no idea what those are or why you’d use them, but i want to ⮹

I’ve opined on this sort of thing briefly in various impermanent places, but somehow never tried to consolidate it at all. So here you go, some stream of consciousness on being more better at computers.

Do you just hate Git? Are you perfectly happy with Mercurial (or, yikes, Subversion) but once a month you have to brave Git because everyone and their damn dog is now using GitHub? Are you vaguely aware that about half of all Git commands will probably delete all your work forever, but you don’t know which ones and you don’t want to spend three weeks poring over the documentation?

Good news! I wrote you this amazing Internet post. I hope I can mash just enough Git into your face that you will be less likely to set things on fire, and also less terrified that you might set things on fire. This should also be enough to make the Git documentation a little more comprehensible; it’s extremely thorough, but also overwhelming and nonsensical if you haven’t already read half of it.

I’m trying to keep this brief but also potentially useful to people who have never touched version control at all, so there are some 101 bits sprinkled throughout. Fear not! I don’t actually think Mercurial users have no idea what a patch is.

Technical people can probably skip this one; if you’re even remotely aware of what open source is, you probably have a working grasp of copyright.

Alas! It seems no one else does. So here is my primer.

Legal disclaimer, of course: I am not a lawyer and have no idea what I’m talking about, but this is my current understanding of how stuff works.

Egocentric disclaimer: This is all pretty specific to the United States, assuming any of it is correct at all, but as far as I’m aware the Berne Convention should mean that this is at least faintly similar is most other countries.

What copyright does

Copyright is literally that thing it says: the right to copy. If you own copyright over a work, you have the exclusive right to copy that work as you please. (The point being that no one else does.) “Copy” here is pretty broad; it can mean literally reproducing, selling, performing, or even creating something new based on it. All of these involve copying the original work in some form.

This is also why it’s not spelled “copywrite”.

Thus, when you hold copyright over something, you are the only person who is allowed to do pretty much anything with it except enjoy it. If someone else copies or sells or shares your work, you can go sue them out the butthole.

There are details.

Works

Copyright applies to creative works. You can copyright stories, artwork, music, designs, sculptures, software, and more or less anything you can actually create in some form, but you cannot copyright ideas, you cannot copyright information, and you cannot copyright facts.

This has funny implications for fictional characters; see below.

Claiming copyright

Copyright is automatic. When you create something, you have copyright on it. You don’t have to use the © or whatever; if you make it, it’s yours. The © really just makes it easier to show a court that you’re the original creator, and might let you sue for more since the jackass ripping you off can’t claim ignorance. Speaking of which…

Restitution

If someone violates your copyright, your only real recourse is to sue. And if you’re reading this instead of talking to your lawyer, you probably aren’t going to sue anyone. Oh and the amount you sue for is probably going to be pretty meager unless you’re rich or a corporation. Which makes this all kind of hilariously pointless in the end. Sorry.

Luckily, in practice, the kinds of people who run hosting companies and sites for hosting creative work are pretty interested in copyright, so you can probably just go up the chain of command and ask to have something removed without ever involving the legal system.

Work for hire

There is a single exception to the rule of automatic copyright: if you create something for your employer as part of your job, it’s called “work for hire”, and your employer owns the copyright.

Commissions are not work for hire; if you call it a “commission”, you’re not an employee. At best you’re an independent contractor, but that’s still not an employee—the only way a one-off work done on personal time could be considered a work for hire is if all parties involved sign a contract agreeing to such. And if you’re willing to do that, you should charge out the ass, because you’re selling your rights away too.

So when you get paid to create a one-off painting or story or drawing or song or program, unless otherwise specified in writing, you still hold the copyright and the buyer gets squat. You’re selling your time, not the work itself. Arguably the buyer has implied performance rights (and I suspect a court would agree), but the buyer does not have the right to modify it, the buyer does not have the right to sell copies of it, and above all the buyer does not have the right to tell you what you can do with it.

Licensing

If copyright were truly limited to the original creator and no one else, the world would be a rather blander place. Which is why we have licensing!

A license is what it sounds like: permission to certain people to do certain things. As the creator, you have free reign to do whatever you want with your own work, but you can give other people license to do some of those things too. (By contrast, you’ve probably seen “all rights reserved”, which literally means “I’m keeping all the exclusive rights I have and you can’t have any of them.” This blurb was actually necessary to claim copyright, before 1976.)

Lots of licenses are informal. You might say “I made this, feel free to use it if you want.” It would make a lot of lawyers cry, but it’s a license given to everyone to do whatever they please with your work.

There are also formal licenses, like Creative Commons, which are designed to actually hold up in court.

To the best of my understanding, unless it explicitly says otherwise, a license can’t be revoked. Once you share your rights, you can’t take them back.

You’re also free to sell your copyright at any time to anyone else, as it’s your property to do with as you please. But if you do, you have zero special treatment over your work. If the new owner doesn’t grant you some rights with a license, you’re no different than anyone else. (It’s a massive tragedy that a great many record labels have contracts that grant them automatic copyright over the songs the artists make. Yes, many mainstream musicians don’t actually own their own music.)

Of course, since you hold the copyright and can do whatever you want, you aren’t bound by the terms of whatever license you give out. You can even give out one license to some people, and a different license to other people. A license only gives other people permission to do some of the things you’re allowed to do automatically. More on this in a bit.

Fair use

“Fair use” refers to a brief list of excuses for copying someone else’s work, e.g. criticism, parody, research, reference, news reporting, and so on. The general idea is that there are legitimate types of work that are useful and necessary, but that can’t exist without copying someone else’s work. The rules are pretty fuzzy and pretty much up to a court’s discretion, though, so claiming “fair use” is unlikely to be a bulletproof defense.

Look at a copyrighted image on Wikipedia sometime, and you might see a fair use rationale given. It usually claims that (a) the article would be significantly less useful without the image, (b) the image is only a small low-resolution part of the entire original work, and (c) Wikipedia’s use of the image poses no real threat to the owner’s business model or reputation. Those are pretty much the criteria for successfully claiming fair use.

Delete ROMs after 24 hours

Yeah, no.

What copyright is

All that was just about how copyright actually works. What it is is not so much legal as philosophical.

Copyright originally lasted 14 years (with the option of requesting a single extension); now it lasts up to 120 years. 120 years! That’s so ridiculously long that we don’t even bother talking about copyright expiration any more, because it has zero practical impact on anyone who’s actually creating new things today.

Now we have this strange and self-contradictory culture of ownership. A lot of creators tend to feel very protective of what they create—after all, it’s theirs, and it will be for the rest of their lives. Yet, simultaneously, piracy is commonplace and at least moderately acceptable socially—how many artists have pirated Photoshop, how many musicians have pirated FL Studio, how many students have pirated Microsoft Office?

I think the difference is that people feel somewhat entitled to experience culture. If all of your friends are watching a show, it’s not just the creative output of some group of people any more; it’s part of your shared culture, and by not watching it, you’re missing out on something socially tangible. If every professional artist uses Photoshop (or, more likely, Sai) and you don’t, then not only are you missing out on a powerful tool, but you’re missing out on the vast resources and discussions constantly happening around you related to those tools.

In many cases, by not having access to very popular copyrighted material, it’s easy to feel that you are being actively denied something.

Which brings me (almost) to what I think copyright is, and which I suspect a lot of people intuitively feel about work that isn’t obviously created by a peer.

Without copyright, anyone’s work could be copied and freely redistributed or sold by anyone else. That’s not very nice of the rest of us, and would discourage people from creating things in the first place.

But! The point of publishing work in the first place is to share it with society, to contribute it to our culture at large. What is culture if not a distinct collection of creative works and ideas?

So the idea that a creator is owed multiple lifetimes of control over work sounds really weird to me. Copyright can’t just be a power grab.

Rather, I think copyright is a polite nod from the rest of us, to show our appreciation for having contributed to our culture. Cool, you made this; you can do what you want with it for a little while, but after that, it’s part of the collective consciousness and up for grabs.

It’s unfortunate that copyright term has been dragged out to absurd lengths, mostly to preserve portfolios of work created by people who are now long-dead. Lengthy copyright stagnates culture: the very companies with the resources to create lots of new ideas are encouraged to recycle instead, and no one else can give old work a new twist in the meantime.

This sort of belief is what produced the open source/free software movements.

Copyleft, copyfree, and software licensing

With the rise of computers, a strange problem arose. Previously, a “machine” was something mechanical, built out of physical parts. The design of a machine is an idea and thus can’t be copyrighted—it can be protected by a patent, but patents don’t prevent you from tinkering with your car in your own garage.

Software, on the other hand, is something we describe as being written. It’s considered creative work, and thus is subject to copyright. But unlike almost all other creative works, software can be compiled: you can run it and use it and appreciate it without actually being able to see what it is. You can fairly easily observe the strokes in a painting, the pixels in a digital drawing, the notes in a song, and the words in a story… but you can’t pop open progman.exe in a text editor and see what it’s doing.

You also can’t actually buy software. Since it has no (useful) physical representation, software exists solely as digital copies, and controlling digital copies is virtually meaningless. Instead, you are actually buying a license to use the software, which grants you an unintelligible list of rights. (That’s the legalese you don’t bother reading when you install something: the End User License Agreement, or EULA.) This is a question that never really came up before, as everything had always been distributed as a physical copy, but it’s getting a little weird as more work is sold digitally. Am I buying this ebook, or just a license to read it? Why can’t I sell that license like I can sell the physical book? To the best of my knowledge this is all still very gray legally; some courts have rejected EULAs as not being legally enforceable, there’s growing tension over the inability to resell digital work (like Steam games), and so on.

Where was I.

Right, so. “Free” or “permissive” licenses came as a reaction to copyright and the control it established over software. Developers who didn’t want their software to be locked up in a black box could choose to use a specific license that grants everyone the right to use and inspect and modify their software. In recent years we’ve seen the creation of such licenses for other types of creative work too, but permissive licenses for software in particular tend to require that the source code be made available, so users can see how the software they’re running actually works.

These are two major camps here, with a bit of friction between them.

A copyfree license allows anyone to do basically anything with your work. If there are any restrictions at all, they’re usually just that your name has to stay on any copies, modifications, or derivatives. The ISC license and CC-BY are copyfree licenses. (The term “copyfree” actually isn’t used very much; unlike “copyleft”, there isn’t much of an organized presence behind it.)

A copyleft license is one that allows anyone to do basically anything with your work, with the critical condition that anyone who releases modifications of your work must use the same license. The GNU Public License is the archetypical copyleft software license and the root of the whole idea of licensing away copyright; the equivalent Creative Commons license is the CC-BY-SA.

Both types of license tell the world that you created your work for their benefit, and they can do as they please with it from here. They promote a sort of freedom of ideas. But in the case of copyleft licensing, that freedom is enforced on anyone who wants to reuse the work. The difference is a question of your philosophy: do you support freedom more by enforcing it on others, or by giving others the freedom to not support freedom?

In the case of software, copyleft licensing is particularly controversial, because anyone who modifies your work must also give out the source code for their modifications. A lot of software shops are very protective of their source code and thus don’t take kindly to copyleft licensing—Apple, for example, forbids using it at all in anything they ship. And this is the intended effect of copyleft licensing: anyone who’s willing to play by the same rules can take advantage of a great amount of existing work, but anyone who’s not has to look elsewhere or start from scratch.

(Being protective of source code is a slightly strange thing. Copyright already protects it, and not having the source code doesn’t prevent anyone from bootlegging the finished product. I’ve even met plenty of e.g. homebrew developers who make a point of giving away little tools freely, but are still very protective of their code.)

A particular point of confusion that arises with these licenses is that of selling work. Remember, as the creator, you are never bound by the terms of the licenses you use anyway—but copyfree and copyleft licenses don’t forbid you or anyone else from selling work. However, since the licenses say that anyone can freely give out copies, it’s perfectly fine for one person to buy the work and then give it away to anyone else who wants it. There’s no such thing as piracy with permissive licensing, because you’ve given everyone permission to make all the copies they want.

To recap: if you use a permissive license, anyone can use, reuse, remix, copy, give away, or sell your work. I’m inclined to think permissive licensing has accelerated software development quite a bit, and I wish it were more popular in other fields. Maybe give it a try. Yeah, some jerk might sell mousepads of your work, but he was going to do that anyway. Think of well-meaning people and what they could create with more resources. And sell your own mousepads.

Public domain

Public domain is the realm of work whose copyright has expired. A public domain work thus has no owner, and everyone is free to do anything with it. (Government-created work can automatically be public domain under some circumstances I’m not qualified to explain, by virtue of being created by the public in the first place.)

Note that, at least in the United States, you can’t choose to put your work in the public domain. Public domain is defined only as where work goes after its copyright expires; there’s no legal mechanism by which you can discard copyright before it was set to expire. I doubt this will ever come up in court, since only the copyright holder can sue someone for violating copyright, and someone who tried to put something in the public domain is unlikely to then sue over it.

As a somewhat more robust alternative, Creative Commons offers the CC0 license, which just grants everyone everywhere a license to do absolutely anything. Software has the far more entertaining WTFPL.

Fictional characters

The copyright of fictional characters is an extremely gray area, and I’ve been unable to find any solid guidelines.

Strictly speaking, you can’t copyright a character, because a character is an idea rather than a work. So anyone claiming “my OC is copyright me” is already full of it.

That said, the legal system does recognize characters as being a part of the works in which they appear, and thus sharing in the copyright of that work. This requires that the character be distinct rather than just an archetype—again, the rules are pretty fuzzy. This is probably better left to human decency than to the legal system.

An interesting case that came up very recently was that a court ruled Sherlock Holmes (the character) to be in the public domain. Only some of the original Holmes stories have lapsed into the public domain, but the court felt that the first few books established the character, and thus the copyright on him expired with the copyright on the books, even though other original books starring him are still copyrighted.

What does this mean for, say, Superman? Copyright on the original Superman comics is due to expire in a few years. I guess we’ll see.

That's all I got

I hope this was at least moderately intelligible for anyone not familiar with the subject. Lemme know if anything is unclear or missing or outright incorrect so I don’t get sued for linking this to people who know even less about this than I do.

Final disclaimer: I mean “brief” in the legal sense, obviously.

(This article has been translated into Spanish (PDF, with some additions) by Jorge Amado Soria Ramirez — thanks!)

Preface

I’m cranky. I complain about a lot of things. There’s a lot in the world of technology I don’t like, and that’s really to be expected—programming is a hilariously young discipline, and none of us have the slightest clue what we’re doing. Combine with Sturgeon’s Law, and I have a lifetime’s worth of stuff to gripe about.

This is not the same. PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. Go on, ask! It makes for interesting conversation.

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. (Hence, fractal.)

PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

But I’ve got to get this out of my system. So here goes, one last try.

An analogy

I just blurted this out to Mel to explain my frustration and she insisted that I reproduce it here.

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

People occasionally ask me why tmux is significantly better than screen, and I end up mumbling the first few things that come to mind. This has yet to sway anyone. Here, then, are some things that I enjoy about using tmux.

First, some terminology, so the rest of this makes any sense at all.

• tmux and screen, if you were not aware, are multiplexers—they let you run multiple terminals (or terminal programs) at the same time, switch between them, and disconnect or close your terminal without killing everything you were running. If you didn’t know this then you should probably stop now and poke around tmux’s site or something.
• A session is a particular group of terminals owned by tmux (or screen). When you run tmux bare, you get a new session.
• A window is a numbered terminal inside a session.
• A pane is each compartment within a split window. (I lied above; a window might actually have several panes and thus several terminals. But a window is identified by one number.)
• An xterm is a single GUI terminal window (or tab). You may be using another terminal emulator, or you may be in a non-GUI virtual terminal; I’m using “xterm” as an umbrella term for all of these.

I’m also assuming that ^A is your multiplexer trigger key, although tmux defaults to the more awkward ^B.

Works out of the box

Here’s my .screenrc, fiddled by hand over the course of many months after I started using screen.

1caption always "%{= kw}%?%-Lw%?%{Kw}%n*%f %t%?(%u)%?%{kw}%?%+Lw%? %=%{= dw} %H "
2
3# terminfo and termcap for nice 256 color terminal
4# allow bold colors - necessary for some reason
5attrcolor b ".I"
6# tell screen how to set colors. AB = background, AF=foreground
7termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
8# erase background with current bg color
9defbce "on"

What the fuck is any of this? The only real configuration here is the first line, which sets a fairly simple status bar. The rest is unreadable sludge picked off of Google to make terminals inside screen work the same way as terminals outside it. I see this as a serious failing in the one core feature that defines a multiplexer: being invisible.

Some of this might not be necessary any more; maybe termcaps have been improved in the meantime. Part of the very problem is that I can’t know; the best I can do is delete bits of it and see if screen still behaves correctly, assuming I remember all the quirks I was trying to fix in the first place. It’s 2012. I shouldn’t ever see the word “termcap”.

Contrast with tmux, which just worked. The only terminal-related fudging I ever had to do was set my $TERM to xterm-256color for it to respect 256-color sequences. Not entirely unreasonable.

tmux can also inherit parts of the environment when it’s detected a change; by default it looks for some common X and SSH stuff. The upshot of this is that your SSH agent continues to work across SSH connections; the new environment only applies to newly-created windows, but zero hacks are necessary.

By default as of tmux 1.6 (I think), when you create a new window, it’ll get the same current working directory as the current window.

I lurk in #python. It gets a lot of questions that are, shall we say, frequently asked. This is my attempt to catalogue interesting and useful questions. The answers will gradually become separate posts—perhaps on other blogs if someone else gets to them first. Let me know if there should be other questions, if the answers are unclear, or the answers have bugs in them!

I hate to rank my own skill at anything, but if you forced me to, I’d say I’m pretty good at Perl. I get paid for it, at the very least. I’ve been around it a long time, and I know it well enough to tell you in intricate detail why I now use Python, instead.

But this is not that post. This post is about a particular wart of Perl: that it has a lot of warts. Large chunks of Perl are antequated, bug-prone, or outright obsolete. The trouble is that there are no warnings in the interpreter or documentation for many of these things, so a newcomer—or even an old-timer—won’t know to avoid such pitfalls until told by someone else.

Such secret knowledge has been documented in bits and pieces in many places, but none of them are complete, and some of them are similarly antequated. So, here’s my list.