Older blog entries for apenwarr (starting at number 547)

2 May 2010 (updated 2 May 2010 at 19:03 UTC) »

sshuttle: a new kind of userspace VPN

I just spent an afternoon working on a new kind of VPN. You can get the first release, sshuttle 0.10, on github.

As far as I know, sshuttle is the only program that solves the following common case:

  • Your client machine (or router) is Linux.
  • You have access to a remote network via ssh.
  • You don't necessarily have admin access on the remote network.
  • The remote network has no VPN, or only stupid/complex VPN protocols (IPsec, PPTP, etc). Or maybe you are the admin and you just got frustrated with the awful state of VPN tools.
  • You don't want to create an ssh port forward for every single host/port on the remote network.
  • You hate openssh's port forwarding because it's randomly slow and/or stupid.
  • You can't use openssh's PermitTunnel feature because it's disabled by default on openssh servers; plus it does TCP-over-TCP, which has terrible performance (see below).
This is how you use it:

  • git clone git://github.com/apenwarr/sshuttle
    on your client and server machines. The server can be any ssh server with python available; the client must be Linux with iptables, and you'll need root or sudo access.
  • http://apenwarr.ca/log/sshuttle -r username@sshserver 0.0.0.0/0 -vv
That's it! Now your local machine can access the remote network as if you were right there! And if your "client" machine is a router, everyone on your local network can make connections to your remote network.

This creates a transparent proxy server on your local machine for all IP addresses that match 0.0.0.0/0. (You can use more specific IP addresses if you want; use any number of IP addresses or subnets to change which addresses get proxied. Using 0.0.0.0/0 proxies everything, which is interesting if you don't trust the people on your local network.)

Any TCP session you initiate to one of the proxied IP addresses will be captured by sshuttle and sent over an ssh session to the remote copy of sshuttle, which will then regenerate the connection on that end, and funnel the data back and forth through ssh.

Fun, right? A poor man's instant VPN, and you don't even have to have admin access on the server.

Theory of Operation

sshuttle is not exactly a VPN, and not exactly port forwarding. It's kind of both, and kind of neither.

It's like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the "real" IP addresses of each host rather than faking port numbers on localhost.

On the other hand, the way it *works* is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn't care about individual connections; ie. it's "stateless" with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.

You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the "real live serial port" days, because serial ports had predictable latency and buffering.

But you can't safely just forward TCP packets over a TCP session (like ssh), because TCP's performance depends fundamentally on packet loss; it must experience packet loss in order to know when to slow down! At the same time, the outer TCP session (ssh, in this case) is a reliable transport, which means that what you forward through the tunnel never experiences packet loss. The ssh session itself experiences packet loss, of course, but TCP fixes it up and ssh (and thus you) never know the difference. But neither does your inner TCP session, and extremely screwy performance ensues.

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It's just data-over-TCP, which is safe.

Useless Trivia

Back in 1998 (12 years ago! Yikes!), I released the first version of Tunnel Vision, a semi-intelligent VPN client for Linux. Unfortunately, I made two big mistakes: I implemented the key exchange myself (oops), and I ended up doing TCP-over-TCP (double oops). The resulting program worked okay - and people used it for years - but the performance was always a bit funny. And nobody ever found any security flaws in my key exchange, either, but that doesn't mean anything. :)

The same year, dcoombs and I also released Fast Forward, a proxy server supporting transparent proxying. Among other things, we used it for automatically splitting traffic across more than one Internet connection (a tool we called "Double Vision").

I was still in university at the time. A couple years after that, one of my professors was working with some graduate students on the technology that would eventually become Slipstream Internet Acceleration. He asked me to do a contract for him to build an initial prototype of a transparent proxy server for mobile networks. The idea was similar to sshuttle: if you reassemble and then disassemble the TCP packets, you can reduce latency and improve performance vs. just forwarding the packets over a plain VPN or mobile network. (It's unlikely that any of my code has persisted in the Slipstream product today, but the concept is still pretty cool. I'm still horrified that people use plain TCP on complex mobile networks with crazily variable latency, for which it was never really intended.)

That project I did for Slipstream was what first gave me the idea to merge the concepts of Fast Forward, Double Vision, and Tunnel Vision into a single program that was the best of all worlds. And here we are, at last, 10 years later. You're welcome.

Update 2010/05/02: Oops, maybe it works a little too well. If you're one of the people who was surprised to see eqldata.com where apenwarr.ca should have been this morning, that's because I left my sshuttle proxy running - connected to the "real" server on eqldata.com - as a stress test. Seems that even my DynDNS provider thought my unreliable home PC was part of the eqldata.com network :) (Also, it failed the stress test: some sort of file descriptor leak after a few hours. Will fix.)

Syndicated 2010-05-02 07:40:46 (Updated 2010-05-02 19:03:35) from apenwarr - Business is Programming

24 Apr 2010 (updated 26 Apr 2010 at 07:04 UTC) »

Three types of distributed system designers

1. Paranoid privacy nuts. Systems designed by these people never become popular because paranoid people don't have any friends. (Examples: ZKS, Freenet, GPG.)

2. Redundancy leeches. These people want to back up their files (encrypted) to your computer for added redundancy. Unfortunately, you gain nothing by doing this for them; there's no way to force a leech to contribute space back to other leeches. So these tend to end up as for-profit services. (Examples: AllMyData, Dropbox, S3.)

3. Sharers. These people have data they want to share with other people. They benefit by giving you the data; you benefit by receiving the data, and if you like it, you'll feel nice by sharing it further. (Examples: Debian, Wikipedia, BitTorrent.)

(Free) distributed storage systems in groups 1 and 2 don't seem to ever succeed, because there's no network growth effect.

Systems in group 3 succeed regularly. And they don't need encryption.

Syndicated 2010-04-23 19:19:47 (Updated 2010-04-26 07:04:37) from apenwarr - Business is Programming

Why alienating developers is a winning strategy

I love this new iPhone SDK rule - the one that says you have to write all your apps in pure Objective C with no translation layers. Not because it's good for me (it isn't), but because it's fun to watch an old-school titan - Apple - play the platform game like they mean it. There hasn't been fun like this since Bill Gates left Microsoft.1

Here's the story so far:

  1. Lots of people bought iPhone 1.0 (without apps) because it was inherently awesome.
  2. Lots of people developed apps for it because there were so many users *and* it was awesome.
  3. About 10x more people bought it because it was even more awesome because of all the apps.
  4. Every other platform (hi, Android) is inferior because it has fewer users and developers and thus apps.2
  5. Go back to step 2 and repeat.

(You might have seen this story before; see Crossing the Chasm and its highly-relevant-to-this-discussion sequel, Inside the Tornado.)

Then, suddenly, Apple clamped down even further on its SDK and app store.3 Shocking! People argue that this breaks the positive feedback cycle: this will mean fewer developers, which means fewer apps, which means less awesome, which means fewer users, which means other platforms can compete, and so on.

No.

Here's the paradox. Apple does need developers to maintain the cycle of awesomeness. What Apple's doing is not good for developers. And developers will continue the cycle anyway.

This is why:

Apple owns the platform; if their platform wins, they win bigger than anybody else. All they need to do to win is to continue to deliver awesomeness to end users as fast as possible so that nobody can catch up. Because they're the biggest platform, they have the most money, so this isn't that hard to do.

The other players are the end users. They have to buy Apple stuff in order for the cycle to continue. The awesomeness must be there or they won't buy stuff. Java and Flash are the opposite of awesomeness. Thus, Apple rejects them outright.4

Developers are not part of the strategy. As a developer, you don't make decisions based on awesomeness at all. You might think you do, and the first iPhone developers ("early adopters") did, but that's not you. The modern developers, the ones with the pre-made market and fully-debugged SDK and profitable clients paying you to write iPhone apps, build for iPhone only because it's the leading platform.

In the long term, developers like you would be better off if they would boycott Apple and only develop awesome apps for something more open, like Android or even Blackberry.5 Users, as they do, would rapidly switch to the platform with the widest variety of awesome stuff, and everybody would win.

But you aren't going to do that, are you? Because nobody else will either. Unless all the developers switch, the only developers who switch will be suckers. You don't want to be a sucker. You want to make as much money in the short term before the whole thing inevitably implodes. Because it will implode, right? ...right?

Microsoft won on the desktop by being developer-friendly and Apple won in mobile by being developer-hostile. Developers never had anything to do with it.

Footnotes

1 The closest we have right now is Google vs. Yahoo vs. Microsoft, ie. a bunch of clueless losers shaking their fists at each other. Google isn't winning in search/advertising because of their awesome strategy; they're winning because the competition keeps producing crap. Which is an okay reason to win, but it's not thrilling. Apple vs. World is thrilling.

2 Actually #4 isn't even strictly true; last I heard, there are still way more Blackberries than iPhones in active use. But people believe it's true, which is all that matters for this discussion.

3 To be honest, the Apple app store was kinda fascist from day 1, so we're just comparing on a relative scale here. But people get upset anyway.

4 All apps written in Java or Flash are ugly and stupid, so end users benefit directly from this restriction. Another reason for Apple to reject such cross-platform apps is admittedly self-serving: if you own the leading platform, you will always get the app. So if you make it hard to port apps between platforms, you're sabotaging the other platforms, not yours.

5 Ha ha, I just called the Blackberry "open," even though the only language you could use to develop apps for it for years has been Java. Somehow Java people manage to spin horrible restrictions as features. "100% Pure Java!" and so on.

Syndicated 2010-04-21 00:05:55 from apenwarr - Business is Programming

I may be internet famous, but I am not a primary source of original research

Particularly if you're thinking of footnoting my high school English essay as one of your references in a book about high-bandwidth network communications.

Yeah, I remember my teacher gave me a 10/10 on that one. 15 years ago. But seriously.

(Thanks to Eduardo for pointing out what happens when you search for "apenwarr" or "Avery Pennarun" in Google Books. Answer: silly things.)

Syndicated 2010-04-17 04:51:58 from apenwarr - Business is Programming

Open source is stupid

Not the software. The people. And not the people who make the software. The people who comment about it. I guess now that includes me, which is appropriate, since writing this post will obviously have no positive outcome.

Background: I love Linux. I've written far more Linux software (commercial and open source) than software for any other platform. Back in the 1990's, I even wrote a Linux kernel driver and poem that's (to my ongoing dismay) still in use today.

So yesterday's random post, in which I said something nice about Apple, naturally tagged me instantly as an "Apple Fanboy." (Of course, the accuser here is "somewhat of an exception" because he "really loves Linux." Uh huh. Yay you.)

By the way, yes, thank you for asking, I do have a Blackberry, and I have used the SDK, and the Blackberry simulator is 100% pure crap compared to the iPhone simulator. This is obvious after 0.5 seconds of comparing the two, after which the iPhone one has finished loading your app and the Blackberry one hasn't even made its window appear yet, let alone booted the simulated Blackberry OS.

Nevertheless, it's true. I am probably officially an Apple fanboy now. I mean, I've had an iPod since 2005, which is nearly the beginning of time. I even upgraded to an iPod Touch recently. Also I have a Mac laptop because they're the only ones where power management actually works. Plus I totally downloaded their SDK last week.

Speaking of which, XCode sucks.

Anyway. Fanboy. Yes. Probably. I do have to admit that it's interesting following along with the whole Evil/Artist dichotomy. Or is it a dichotomy at all? I mean, how can you be a serious artist and then let people use Java? Yes, Android, I'm talking to you.

And oh, speaking of Android. While I'm flaming people needlessly, let me just add one more thing:

Top 10 Paid apps in the Android App Store

See the list here.

  • Abduction! World Attack: 2D game in 1980's style, but with more colours.
  • Power Manager: because multitasking kills your battery.
  • Baseball Superstars: they're afraid to show any screenshots.
  • Open Home: Replace your home screen to further reduce usability.
  • Jewellust: a Bejewelled clone. Guess Bejewelled guys didn't bother.
  • MyBackup Pro: like backing up with iTunes, only not free.
  • Tangram Pro: something Chinese.
  • aHome: Yes, another one. Replace your home screen replacement.
  • dxTop: Oh look! 3/10 of the top paid apps replace the home screen!
  • Aevum Obscurum: the ancient game of Risk, only now you get to pay for it.
Looking at the top 10 free apps is even more apalling. The top 10 free arcade/action games include Pac Man, Tron, Rescue Copter (with realistic 1980's 4-colour graphics!), BrickBreaker, Nibbles, and worse. I'm not kidding about worse.

Remember, folks, Google is the worldwide expert at showing the very best stuff at the top of your search list. Just think what the next 10 look like!

Guys. This is what happens when you let Java people write apps for your platform. Who's evil, again?

Top 10 Paid apps in the Apple App Store

  • The Simpsons(tm)
  • Mega Man(tm) II
  • Scrabble(tm)
  • Monopoly(tm)
  • The Sims(tm) 3
  • Bejeweled(tm) 2
  • plus some garbage
Oddly, the ridiculously addictive and awesome Space Miner isn't even in the top 10.

You will note that Apple actually explicitly prohibits Java developers from coming anywhere near their SDK. It's part of the license. I'm not even kidding. This is not a coincidence.

There. Glad I got that out of my system.

apenwarr. Lowering the quality of discussion since... the 1990's sometime. Aw, who can remember exactly when. Whatever.

Syndicated 2010-04-08 21:58:00 from apenwarr - Business is Programming

8 Apr 2010 (updated 8 Apr 2010 at 20:06 UTC) »

How to run an iPhone app in the simulator without using XCode

I spent a lot of time looking around on the Internet for this answer, and the results were basically nonexistent. The answer is: iphonesim on github. (Despite its name, iphonesim isn't an iPhone simulator; you still need the iPhone SDK to be installed so it can use their simulator.)

The bad news is there's no obvious way to run your app in a Debugger using this system. Hopefully someday it'll be added or I'll figure it out, and then I'll be rid of XCode for good.

Why the iPhone Simulator is Awesome

While we're here, I'm very impressed by the whole concept on which the iPhone simulator works. Most embedded devices (including Blackberry, Android, and other phones) use software to emulate the embedded CPU, which then runs the embedded OS, which then runs your app. This kind of sucks, because the emulator has to work really hard (it often runs at only a fraction of the speed of a real device), and if you crash it you have to reboot it. Plus loading apps onto a simulated device is extra crappy, because you have to simulate a slow USB connection, and so on.

The iPhone simulator works nothing like that. Instead, you compile your app for your native CPU, and they made the iPhone simulator just a native program that runs on your workstation and provides the iPhone API (using native libraries). You simulate and test your program, and when you're finally happy with it, you recompile your app for the target CPU that actually runs on an iPhone. Then it won't work on the simulator anymore.

The result is that the simulator starts instantly and there's no insane two-layer debugging scheme in which you're running a native debugger and decoding non-native (and usually JITted) CPU instructions.

Some people would argue that this method is "less accurate" than precisely emulating the target CPU, and thus the simulator doesn't add much value, since you'll have to test the native app in the end anyhow. It's true that simulating this way is inaccurate and you should do final tests on a real device. The misconception, though, is that the old, annoying, slow, "emulate everything" method is any more accurate. In fact, it's worse.

The fact is, emulators are never perfect. CPU/hardware emulators are really hard to get right, especially if you're trying to make them run fast. If you're not trying to make them run fast, you have a whole different set of problems, because now your simulator is way slower than the real device, so all the animations/etc will be wrong. Try debugging an OpenGL app when your framerate is 1/10th what it should be.

By contrast, the iPhone simulator's method seems magically wonderful. Since the iPhone OS is MacOS, all the kernel APIs are the same. The natively-compiled frameworks, libraries, and display engine are built from the same source code, so you know they're the same too. And your Mac's CPU is a lot faster than the iPhone's CPU, so the simulator can slow down your program to iPhone speed, which is a lot easier than speeding it up (although admittedly imperfect).

In fact, with this method, the only potential sources of incorrect simulation are a) speed (which they seem to have gotten right); b) cross-platform bugs in gcc (I don't know of any); or c) differences in memory layout making memory corruption behave differently. (c) could be a problem, but they seem to provide a lot of debugging tools and you shouldn't be depending on memory corruption anyhow.

Incidentally, this design justifies the fact that you have to have a Mac to do iPhone development, and you have to have the latest MacOS (Snow Leopard) to run the latest SDK. This annoyed me when I first heard of it; I thought Apple was just trying to lock more people into buying a Mac. But now it totally makes sense: iPhone OS *is* Snow Leopard, so if you want to run the native simulator, of course you need Snow Leopard, or the simulator can't possibly work.

That's a really brilliant design tradeoff with huge benefits. And they get to lock more people into buying a Mac.

Update 2010/04/08: A few people have pointed out that the Blackberry "emulator" is apparently not actually an "emulator" but in fact runs a natively-compiled version of the Blackberry JVM. Okay, I guess, but that's not really the point. The point is that it still spends upwards of 30 seconds booting the "virtual Blackberry" before it even gets to the point where you can run your program. (And you have to do this every time you want to run your program.) This is annoying, slow, and pointless, and the (apparently native??) JVM still runs everything horrendously slowly - slower than a real Blackberry. So if it's not a native device emulator, then congratulations, it's somehow even stupider. Yes, I've done real Blackberry development, and the difference between the Blackberry and iPhone simulators is night and day.

Syndicated 2010-04-07 17:54:06 (Updated 2010-04-08 20:06:46) from apenwarr - Business is Programming

Dear StartupCampMontreal:

You are not a "camp." You are a "conf."

The xxxCamp naming scheme appears to have originated with O'Reilly's "FooCamp," which was an informal event where a bunch of famous techie people came to discuss stuff. The more commonly known "BarCamp" series was created as a backlash to the invitation-only FooCamp, but in the same "unconference" style. Thus, the "xxxCamp" series of events is defined primarily by its unconference attributes, to wit:

  • Poorly organized (in a good way)
  • Informal
  • No prearranged agenda
  • More conversations than presentations
  • No cabal of unelected organizers who decides who gets to speak
  • No keynote presentations
  • No direct financial upside for any participants
StartupCampMontreal claims to have an "unconference component," but this component is obviously a second-class citizen. Among the many reasons that this is obvious (from my observations when I attended it last year), one is especially egregious: the unconference portion is from 1pm to 6pm in the afternoon... on a weekday.

It's reasonably possible for many people to get a day off work to go to a conference; company-sponsored "professional development" days are common. Getting a free day off to go to an unconference is very unlikely. And you know this, because you put the "core" (non-unconference, ie. conference) part of your so-called camp in the evening, when people will be easily able to attend.

I don't actually like "conferences." I find them tedious. Keynote speakers, no matter how famous, are almost universally cliches. Presentations selected by a cabal of organizers are almost never the presentations that would have been selected by an audience (as they do at StartupCampWaterloo, which is a real "camp") - they are therefore boring. And a highly structured set of presentations leaves little time for socializing and unstructured discussion, which is the main purpose of an unconference.

Basically, StartupCampMontreal is not actually interesting to me, because it is not actually a StartupCamp. Your name is essentially false advertising.

Your conference is well organized, well marketed, smoothly running, and attracts a lot of people including numerous sponsors, reasonably famous keynote speakers, and an ever-increasing number of attendees. I'm sure that many of those people are happy to go to StartupConfMontreal, and I'm not suggesting that you change your format just for me.

But what I want and expect from a StartupCamp is an unconference. This is why I will not be attending StartupCampMontreal in the future.

Best of luck and have fun,

Avery

Syndicated 2010-03-24 18:55:49 from apenwarr - Business is Programming

bup is now more popular than all my other projects combined

...at least if you measure it by counting the number of watchers on github.

It is also featured in the top 100 or so interesting github repositories, although there's no particular indication of what they mean by "interesting."

(Previously: bup: it backs things up. It's matured quite a bit since then, though, and is now usable for backing up real work that you care about.)

Syndicated 2010-03-03 21:27:20 from apenwarr - Business is Programming

The problem with stealing movies is you *can't* pay for them after

Imagine you go into a clothing store and steal a pair of pants. And you get away with it.

Not long after, you realize that, you know, these pants are *really great*. And never mind that, these physical object thingies really do cost people time and effort to produce. You feel guilty. So what do you do?

Well, you sure don't go back to the store and pay retroactively, that's for sure. Not only will you single yourself out and look like a weirdo, but you risk having the police called on you anyway. After all, you just admitted to a crime.

Nonphysical objects like movie downloads aren't quite the same. It doesn't cost the creator a dime if you make your own copy. Obviously it still cost them to create it, so they'll need to get paid somehow. And let's be honest, if someone creates a product - even a digital one that costs nothing to copy - that improves the lives of hundreds of millions of people, they deserve more than just a pittance. They deserve millions of dollars. Maybe hundreds of millions, which is still only a couple of dollars per person. We all know this is true. Even if we think the producers and marketers are morons who seem intent on making our lives worse instead of better, we know that somebody who made this awesome entertaining stuff deserves to get paid. A lot.

Copying a TV series from a friend, watching a few episodes, enjoying it, and then deciding to buy it is easy - and not something that will get you into trouble, because nobody will know but you and your friend. But somehow you'll still feel like a weirdo if you go out to a store and buy it just to relieve your guilt.

Why is that? Why don't people pay for stuff they stole, even if they love it, even if it won't get them into trouble?

Of course I don't know for sure. But I have a couple of thoughts. First of all, going out to the store and buying a DVD is silly; it wastes time and energy, plus you end up with a useless DVD, which is an obsolete form factor much less convenient than the one (file on hard disk) that you got for free. What are you going to do with the DVD? Either throw it away (not likely), sell it (defeats the purpose), or keep it on your shelf forever. Dumb.

You could go buy it on iTunes, I guess. But then you're sponsoring a wannabe monopolist, plus you know you're paying some middleman at Apple for their bandwidth, which you're not even planning to use. You already downloaded the thing.

You could buy it online and have it shipped to you - but then you end up with the useless physical DVD, plus you pay for shipping the useless physical DVD. (Even if the shipping is "free," you know it's hidden in the price somewhere.)

And you also might figure the price is too high. $47 for Season 5 of House, MD? You don't have that kind of money just lying around. Plus you didn't even watch the whole season.

Another reason you don't pay is simple: you just never quite get around to it. And by the time the guilt is overwhelming, you've watched so many shows from so many seasons of so many series that you can't even keep track of what you owe anymore, other than it's now way more money than you have lying around.

What if there was a service that could help?

PayUp.com: "Because you should."

(Note: payup.com is not a real domain name as of this writing. It's just an example.)

Imagine there was a plugin integrated into, say, Boxee or XBMC, that would track what you watched - and give you a dollar value based on the cost of the DVDs. If you have a season of House, MD and a season of Firefly, and you watch half of each one, your total would come to ... half the cost of the two added together.

Then what if, on the first of each month, the plugin pops up a list of the shows you watched but haven't paid for, calculates a bill, and offers to send money to the manufacturers on your behalf?

The amount of money could default to the auto-calculated amount. Or you could assign a monthly budget, and divide it between the shows you watched. Or you could manually override it and send whatever amount you wanted. Or you could have it round up to buy the whole DVD after you watch 50% of it, or whatever.

Then, after you approve the payment, it debits your credit card and the cards of all the other users, and buys a bunch of DVDs from Amazon.com (or whatever) based on what the users chose to pay for.

So if you pay for 10% of House, MD, Season 5, and nine other people do too, the service buys 1 copy on your behalf. Amazon ships the DVD to Payup.com, which promises never to open the DVD, and just stores it in the warehouse forevermore (or just destroys it). Maybe they charge 5-10% of the purchase price for being the middle man. Maybe they can get a bulk distribution deal somewhere and not charge any extra at all (since, after all, there's no more "free" shipping and handling charge).

A typical cost for cable TV is $60 a month or more; that's more than a full season of House, MD, which is more TV than I can handle in a month. (Of course, some people watch much more TV than me.) What if you cancelled your TV subscription and just assigned $60 a month for payup fees instead?

This won't make your movie stealing any more legally sound. But morally? That's up to you.

Business Considerations

The Payup.com service, of course, would be a bit of a strange entity. Think of it as Netflix without the distribution. Sure, business people think distribution is everything, but that's old fashioned thinking. This is the 21st century. In the 21st century, distribution is free and everybody can do it, so you'd better find some other way to add value.

Think about that. Distribution is free and everybody can do it. Of course, it's not really free yet. It seems free to you and me, because we pay our monthly internet bill, and as long as we don't go over the limit, we don't pay extra. And we can copy DVDs for our friends for less than $0.50 each. But if you're Apple or Amazon or Hulu or Google, distribution sure the heck isn't free. Outside of licensing, it's probably your #1 cost, your most complicated technical overhead, and it hurts your business every time you have to pay for it.

So distribution isn't valuable. What's valuable is getting money back to the copyright holders. Because when copyright holders don't get paid, all we have left is Youtube, and God help us all.

What if you could build a business around not the distribution, but just the paying for licenses? Okay, sure, BitTorrent sharing of movies is illegal and all, but that's kind of a side issue. It's not like your service is making it easier to steal stuff. That's already easy. You're just making it easy to give money to the copyright holders. You're totally taking the moral high ground here. You're turning a net loss - piracy - into a net gain - vastly reduced distribution costs (zero) and paying customers.

The Pirate Bay deserved to lose their court case because as much as they tried to pretend otherwise, they totally lacked the moral high ground, and were playing legal tricks to try to dodge that simple fact. The Pirate Bay could only reduce, never increase, income for copyright holders. Payup.com will be different; not only will it directly provide income to copyright holders, but it'll make services like The Pirate Bay retroactively less evil. Suddenly not all the piracy it caused would be a loss of income.

Of course the copyright holders won't see it that way. Your Payup.com will probably get sued. But when that happens, how can you lose? You're not doing anything wrong. Basically, you're accepting donations from users and forwarding them on to the copyright holders. You're not copying content, indexing content, linking to content, sharing content, or anything of the sort. In fact, you have nothing to do with the content whatsoever. That can't be illegal, can it? (Disclaimer: I really don't know. Talk to a lawyer.)

What about your users? Are they at risk? After all, sending you 10% of the cost of House, MD seems to suggest that they copied the other 90% without paying... or that they copied any of it without a license. But is it really true? Is it sufficient evidence for the police to demand your customer list and start arresting people? I don't know. If it's framed as just donations - I really like this show, and I want to pay you extra for it, but I really don't want another useless DVD - then maybe not.

Is the only reason this won't work, the same reason you can't go back to the store and pay for your stolen pants? If so, that's pretty sad.

Or maybe people just won't pay for stuff if you don't force them to. I don't want to live in such a world. Maybe I'm just a naive Canadian and/or a communist. But I'd pay for this service if it existed. Firefly and Futurama need more donations than the cost of a mere DVD.

Syndicated 2010-02-07 22:56:01 from apenwarr - Business is Programming

A git-subtree tutorial

Jakub Suder has a nice tutorial on how to use my git-subtree tool to manage git repositories that track other projects in subdirs.

It's quite nicely written, and unlike my own documentation, it has pretty diagrams.

Syndicated 2010-02-04 19:43:11 from apenwarr - Business is Programming

538 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!