Responses to people who insist on using Tumblr

Ban Software Patents

Sun, 15 Mar 2009 13:53:45 -0500

rcrowley:

cowsandmilk:

blah blah, whatever I wrote earlier. scroll down.

You make an important distinction but I still believe software patents are not useful. Differentiation in implementation purely to skirt a patent’s claims is useless.

I spent some time tracking down the account of expert witness Philip Greenspun when Amazon sued Barnes & Noble to enforce the one-click patent. In particular:

I was asked “Why didn’t you patent this yourself, if you developed it first?” My reply was “It only took me an hour to build; if I went down to the patent office after every hour of programming, I wouldn’t get very much done.”

Real programmers don’t bother with software patents, they’d rather spend their time building new things rather than deciding who owns old things (to paraphrase Greenspun). Ban software patents.

Now that I’ve had my first beer of the night, and you stimulated my mind, things I don’t like about software patents have come back to me. When a software patented algorithm becomes a standard, that is rough. The whole gif vs. png wars were a sad time. I’m glad I chose the side of png, but I still find a lot of people have no idea what they are. (Also, I’m surprised at the number of people who won’t believe me that png is a lossless format, but that has nothing to do with patents.) There are similar issues with ffmpeg and the video formats. In all these cases, ideas for how to compress data were patented, then used in a standard format. Not a fan of that. But this isn’t completely unique to software. In chemical engineering, when making a P&ID, you are required to be a member of ISA to use their standard symbols. So, you have to pay $85 a year (apparently $100 in 2009) to legally talk the language of chemical plant design.

Anyways, one beer tells me, one-click purchase patent was lame. File formats based on patented algorithms are lame. (I’m digging Firefox 3.1/3.5 and actually am preparing some screencasts in Ogg Theora to natively play.) Maybe software patents are lame. In an academic setting, the people in my lab have generally found that the things we have considered patenting are too complicated for most companies to write on their own, so copyright of our own code has protected us from stealing. Maybe my judgement has been too clouded by the fact that anything we consider patenting takes much longer than an hour to implement, and generally mathematical knowledge that stretches the limits of most math/scientific C libraries to their capacity.

You’re like the small town bank who’s been doing things Right for the last 10 years only to have its reputation tarnished by big bank asshats. Your mention of copyright as enough protection plus the higher standard internally for what is patentable tells me your lab is thinking about protecting itself and not about making a quick buck. Lawsuits are not desirable for people who do the Right thing. And that’s just it: for any program sufficiently complicated to need a patent, copyright works just fine.

Ban Software Patents

Sat, 14 Mar 2009 20:50:12 -0500

Ban Software Patents:

cowsandmilk:

I don’t know how this blog post showed up in one of my browsers, but it’s proof to me of how little most people understand software patents. And it was probably linked to by someone high profile who also doesn’t understand software patents. In this person’s view, there are these 2 patents that both patent the idea of ORM. Neither patent is for ORM. They are each for a way of performing ORM. You can’t patent the idea of generating code to perform the task. You patent the method of generating code to perform the task.

In case you have trouble understanding the difference, let’s move to a hardware patent as an example. Say, one for a VGA controller card. These people didn’t patent VGA controller cards. In fact, the abstract specifies that they are hardware compatible to things already on the market. So, like the pre-existing cards, they can be put in between a computer and a display and talk the right way on both sides. And you can come up with something that does the exact same thing and get your own patent, as long as it does it in a different way than they do it. This is what is happening with there being multiple ORM patents. Each patent talks to a database and creates objects in a language, but the way they do it is different, so they get different patents. And you can come up with a different way and not infringe.

I’m not saying software patents are good (or bad). I’m just tired of seeing so much ignorant commentary on the topic. In science, I frequently see things that superficially look the same as what has been seen before. But I find when I probe deeper, there are crucial non-obvious innovations that separate the new idea. Acting like patents are always for extremely superficial things is unfortunate.

You make an important distinction but I still believe software patents are not useful. Differentiation in implementation purely to skirt a patent’s claims is useless.

I spent some time tracking down the account of expert witness Philip Greenspun when Amazon sued Barnes & Noble to enforce the one-click patent. In particular:

I was asked “Why didn’t you patent this yourself, if you developed it first?” My reply was “It only took me an hour to build; if I went down to the patent office after every hour of programming, I wouldn’t get very much done.”

Real programmers don’t bother with software patents, they’d rather spend their time building new things rather than deciding who owns old things (to paraphrase Greenspun). Ban software patents.

A note on OpenClip

Wed, 20 Aug 2008 18:45:00 -0500

cowsandmilk:

marco:

Using this, an app can read any saved authentication information in any other apps — for example, an app could steal your Flickr API key from any other apps that you’ve trusted with access to your Flickr account. Or an arbitrary app could read saved passwords from a password-manager app.

I don’t think it would be possible for another app to steal your app’s access to Flickr. Your secret key would be hardcoded in your app and short of some magic crawling through the binary, noone could send a message as you, even if they had your api key (easy to get for an app as it’s clear text in your POST/GET) and they pulled the user auth_token out of your app’s data directory. (Hopefully Richard will correct me if I’m wrong about this).

As for a password manager app, God help you if your password manager is storing stuff in plain text. OnePasswd sure doesn’t. And if the iPhone has Keychain, noone with a brain should. In fact, if the iPhone has Keychain, hopefully your app accessing Flickr put the user auth_token in there.

Richard Crowley: man strings
David Hall: I knew there had to be a way to do that
Richard Crowley: however
Richard Crowley: run strings on the flickr uploadr’s binary
Richard Crowley: and you’ll find no api secret
Richard Crowley: Richard 1, strings 0
Richard Crowley: char secret[16]; secret[0] = ‘7’; secret[1] = ‘a’; …..
Richard Crowley: strings works by dumping the .text segment from elf binaries
Richard Crowley: so doing the character-by-character thing effectively hides it from anything that isn’t actually executing your code
Richard Crowley: you could certainly still get uploadr’s secret via gdb or some other debugger
David Hall: alright, well, that still is nice to know you can make it annoying for people to get it
Richard Crowley: yessir

cowsandmilk: marco: Nice people at Slicehost. AMEN! Alas, they’re not Wash U kids. Still...

Mon, 18 Aug 2008 22:34:35 -0500

cowsandmilk:

marco:

Nice people at Slicehost.

AMEN!

Alas, they’re not Wash U kids. Still rockin’ service, though.

halle: with dr. sanjay gupta and lance armstrong I’m...

Sat, 26 Jul 2008 01:41:31 -0500

halle:

with dr. sanjay gupta and lance armstrong

I’m very jealous Halle got to meet Lance Armstrong. I’m watching the Tour de France right now, actually.

The UUID vs. the Integer

Sat, 05 Jul 2008 11:16:56 -0500

cowsandmilk:

In the world of distributed systems, integer indexes are left behind in favor of UUIDs. Since there’s no shared counters between two unconnected systems, this is a great solution.

I think that the UUID in general is better than integers though for indexing a relational database for a couple reasons:

There are millions of pages on the internet about autoincrementing of database indexes and Postgres serial vs. MySQL auto_increment and a whole bunch of balogna about how to get your index. If you just create a UUID in your app and use it, you avoid all that bull.

Security is much improved. I mean this in two ways. There is the classical incrementing of numbers to get to the next blog entry or photo album or whatever that is supposed to be private. UUIDs have long been used here. But let’s say you have a permissions to user table. And someone figures out a sql injection that lets them put in their userid and a permission id into the table. If your permissions are indexed on a UUID, they’re just stabbing in the dark trying to get a valid, useful permission. They’ll probably need to do enough stabbing that you’ll notice the attack and shut them off. (This assumes the sql injection doesn’t let them read from the permissions table).

It might not be traditional, it might have implications on the speed of joins (number comparison vs. string comparison? well, they should just be a bunch of bytes, so no big difference? well, the string is probably many more bytes…), database size, and other performance issues, but I think it’s well worth it.

The speed thing isn’t really an issue since you’d probably store the data in a fixed-width binary format which will be plenty fast. The issue is disk use. 128-bit UUIDs will mean more disks and very quickly more servers. Ted wrote a bit about this the other day. (Pay no attention to the base64 distraction at the end.)

"The culture of free, seductive as it is, is destructive to everyone involved. Everyone is..."

Sun, 29 Jun 2008 02:17:39 -0500

“The culture of free, seductive as it is, is destructive to everyone involved. Everyone is undercutting everyone, until nobody is making a profit. At best, the winner is the group that can survive off of (usually meager) ad revenues.”

- Matt Maroon: Bubble 2.0 (via marco)

My fear is the destruction of software innovation as I’ve written about before. (via kyleshank)

The important place for innovation in an increasingly ad-driven web is in increasing the signal-to-noise ratio. I think services that bring in direct revenues are the ideal but the second-best are those services that use advertising and markets to enhance experiences rather than exploit members.

kyleshank: Whats wrong with the beer we got? It drank pretty...

Wed, 25 Jun 2008 17:07:43 -0500

kyleshank:

Whats wrong with the beer we got? It drank pretty good don’t it.

Watch from 5:20 in. This is an actual session from the Alabama state House on the alcohol content of beers.

Danville, Kentucky went moist* in 2004 and it was quite a fight. The Baptists came out in force against it but we beat them back with our economics stick.

* “moist” in this case means that restaurants that seat more than 100 people and make at least 70% of their revenue from food sales can serve beer, wine and liquor. One restaurant was nearly pressured out of business because of its “bar-like atmosphere” though it was meeting those numbers easily.

kyleshank: Feeling the new Coldplay. Myself, I’m rather...

Tue, 17 Jun 2008 11:03:30 -0500

kyleshank:

Feeling the new Coldplay.

Myself, I’m rather obsessed with the title track. It’s embarrassing — I have a feeling my neighbors have heard it on repeat.

First post!

Sun, 08 Apr 2007 15:47:31 -0500

This is new and interesting. Perhaps Tumblr will not seem as silly to me as Twitter.