Friday, April 17, 2009
Defunction!
This site has kind of fallen by the wayside... I tend to post at http://www.robdickerson.net instead.
Friday, November 14, 2008
Oblivion + DRM = Fail
A few months back I bought the Oblivion Game of the Year Edition. I know I'm a little behind the times, but I didn't have time to play Oblivion when it first came out. I've always been a huge Elder Scrolls fan, and I was having a lot of fun catching up.
When I first bought the game, I had a Windows machine laying around to play it on. Sadly, the machine developed some problems and had to be cannibalized.
Everything I'd read made it seem like I should be good getting it running in Ubuntu under Wine.
A few frustrating hours later, I learned that the newer Game of the Year (GOTY) editions of Oblivion, like the one I had purchased, used a version of SecuROM not yet supported by Wine.
This really angers me for two reasons. Firstly, SecuROM is evil borderline-malware, and I'm disappointed that Bethesda (a company I -- used to? -- like) decided to use it at all to begin with.
Secondly, the non-GOTY editions that already exist don't use this type of DRM. Since, to the best of my knowledge, no difference exists between gameplay in the GOTY and regular versions of Oblivion, it seems to me this new DRM actually weakens the security of the game. If you're a pirate, you get to pick one of two DRM systems to break in order to redistribute the game -- before, you were just locked into the one.
The new DRM hurts people like me who actually bought the game (no surprise), but I would argue it actually helps software pirates at the same time.
It's ridiculous.
Since Linux isn't officially supported by Bethesda, I don't really have an argument to bring to the company. But it really sucks that buying a newer version of the game has severely limited my ability to play it.
Can we get a law or something that requires DRM-ed products to be clearly labeled with the DRM they ship with? I'm tired of being caught by surprise with this junk.
When I first bought the game, I had a Windows machine laying around to play it on. Sadly, the machine developed some problems and had to be cannibalized.
Everything I'd read made it seem like I should be good getting it running in Ubuntu under Wine.
A few frustrating hours later, I learned that the newer Game of the Year (GOTY) editions of Oblivion, like the one I had purchased, used a version of SecuROM not yet supported by Wine.
This really angers me for two reasons. Firstly, SecuROM is evil borderline-malware, and I'm disappointed that Bethesda (a company I -- used to? -- like) decided to use it at all to begin with.
Secondly, the non-GOTY editions that already exist don't use this type of DRM. Since, to the best of my knowledge, no difference exists between gameplay in the GOTY and regular versions of Oblivion, it seems to me this new DRM actually weakens the security of the game. If you're a pirate, you get to pick one of two DRM systems to break in order to redistribute the game -- before, you were just locked into the one.
The new DRM hurts people like me who actually bought the game (no surprise), but I would argue it actually helps software pirates at the same time.
It's ridiculous.
Since Linux isn't officially supported by Bethesda, I don't really have an argument to bring to the company. But it really sucks that buying a newer version of the game has severely limited my ability to play it.
Can we get a law or something that requires DRM-ed products to be clearly labeled with the DRM they ship with? I'm tired of being caught by surprise with this junk.
Thursday, November 13, 2008
Living With Bad Systems
When a system is first created, it's easy to find criticism. People new to the system see its behavior constantly colliding with their expectations, and it's a goldmine of ideas for making the system more intuitive and easier to use.
After a system has been around for a while, though, people start to get used to its little problems and quirks, and I think it gets harder to find good criticism about the larger scale issues.
People are so good at learning to live with inconveniences that after a certain point they don't complain about the barn-sized flaws in a system's design or behavior. Things like poor performance, unnecessary redundancies, poor integration with external systems -- after a while, people don't complain because That's Just The Way Things Work (tm).
To illustrate my point a little, follow me on a magical journey to an imaginary men's room. Can you feel the imaginary tile and smell the imaginary urinal cakes? Good. Now, look over towards the imaginary sinks.
Many public restrooms these days use motion detectors to turn the sinks on and off. You probably know what I'm talking about -- a small black sensor sits right under the faucet, and when someone's hands appear in front of it, it turns the water on. Similar setups are usually on the soap and paper towel dispensers.
The motion detectors are far from perfect, and most of the time you have to work a bit to get the water or soap or paper towels to come out. So, in order to wash and dry your hands, you sometimes spend a good two minutes trying to convince some machine, some harsh mechanical eye, that you do, in fact, exist. You stand in front of the motion detector, waving your hands around foolishly, doing little dances, saying, "I'm here! I'm real!"
And you know what? Sometimes you fail. You fail to convince a machine that you're real, and no water or soap or paper towels come out. It's downright Orwellian.
So if these machines routinely and blatantly deny your very existence, and they are completely accepted and commonplace, how many other egregious behaviors in systems across the world must be going unreported at this very moment?
If you take a step back and look at your system's design from afar, can you spot any gaping problems that everyone is just used to dealing with?
After a system has been around for a while, though, people start to get used to its little problems and quirks, and I think it gets harder to find good criticism about the larger scale issues.
People are so good at learning to live with inconveniences that after a certain point they don't complain about the barn-sized flaws in a system's design or behavior. Things like poor performance, unnecessary redundancies, poor integration with external systems -- after a while, people don't complain because That's Just The Way Things Work (tm).
To illustrate my point a little, follow me on a magical journey to an imaginary men's room. Can you feel the imaginary tile and smell the imaginary urinal cakes? Good. Now, look over towards the imaginary sinks.
Many public restrooms these days use motion detectors to turn the sinks on and off. You probably know what I'm talking about -- a small black sensor sits right under the faucet, and when someone's hands appear in front of it, it turns the water on. Similar setups are usually on the soap and paper towel dispensers.
The motion detectors are far from perfect, and most of the time you have to work a bit to get the water or soap or paper towels to come out. So, in order to wash and dry your hands, you sometimes spend a good two minutes trying to convince some machine, some harsh mechanical eye, that you do, in fact, exist. You stand in front of the motion detector, waving your hands around foolishly, doing little dances, saying, "I'm here! I'm real!"
And you know what? Sometimes you fail. You fail to convince a machine that you're real, and no water or soap or paper towels come out. It's downright Orwellian.
So if these machines routinely and blatantly deny your very existence, and they are completely accepted and commonplace, how many other egregious behaviors in systems across the world must be going unreported at this very moment?
If you take a step back and look at your system's design from afar, can you spot any gaping problems that everyone is just used to dealing with?
Thursday, September 18, 2008
The Limits of Proving Programs Correct
My university required senior computer science students to complete a capstone project before they graduated. The idea was to have every person perform a research project or internship that brought together all that he or she had learned over the last four years.
My capstone project was of the independent research variety. I'm very interested in formal logic and proof systems, and wanted to examine parallels between generating a formal proof and writing a computer program.
What I ended up doing was creating a system that started out with a formal program specification written in Z-notation, and simultaneously generated a working Spark-Ada program and a proof of that program's conformity to the Z spec.
(Since each line of code transforms the program from one state to another, you can figure pre- and post- conditions of individual lines of code. So, the problem becomes a search for a list of statements whose pre- and post- conditions chain together to take the Z-specified preconditions to the Z-specified post conditions. The sequence of statements make up the working code, and the chain of line-by-line pre- and post- conditions are the correctness proof.)
The programs it could generate were very simple (they could only use a ridiculously small subset of Ada). It could write methods that did things like swapping the values of two variables. But it worked for the most part. And it was a lot of fun to work on, and I learned a lot.
The biggest thing I learned was the limited utility of proving code correct.
Something a fellow named Benjamin Russell said on the Haskell mailing list today got me thinking about software proofs (and inspired this post). He said that, "[b]asically, if you can prove that the program is correct, then you don't need to test it."
I disagree.
What I learned doing my senior capstone is that when you prove a program correct, what you're actually proving is that the program conforms to some specification. Maybe it's a specification formally defined in a language like Z, or maybe it's a non-formal specification that resides in your head.
But really, a specification is prone to error just like program code. As your specification gets more detailed, it starts to become another programming language. With my capstone, all I really did is write a Z-to-Spark compiler. I'd shifted the opportunity for human error up a level -- now, instead of making mistakes in Ada code, people were free to make mistakes in their Z spec.
It's like saying you can write provably correct assembly code that matches a C specification. Maybe C or Z is an easier language to reason in, but you still have to take a lot of time to examine your specification, to make sure everything in the system meshes together -- really, the formal specification becomes your new coding language.
On the flip side of the coin, as your specification becomes less formal, that opportunity for error shifts back toward the coding process. Less constraints in the specification mean more freedom in writing the code, which means more opportunity for mistakes in your actual program.
I guess what I'm saying is that in this approach:
1) come up with an over-arching specification for everything
2) write code that matches the specification
being able to prove code correct (prove it meets some spec) only gets you step two. Step one is just has hard (or harder). Creating a really formal specification means you have a new programming language to deal with, and a less-formal spec means you can have inconsistencies or missing information that bleed into your code base.
There is some essential complexity in developing software that cannot be eliminated by correctness proofs -- you're just moving opportunity for error from the "coding" side of the balance to the "specification" side.
All of that being said, if you're doing something that has to be right, like air traffic control or data encryption, and you're willing to spend a lot of time thinking about your formal specification, then I think provably correct software is the right goal. But correctness proofs are just one part of the process. Even if everything is proved correct, you still have to really test your software. If not to test the code, then to test the spec.
I think this is one of the reasons that test-driven development is such a practical idea for "normal" software development. It recognizes that your specifications are just as incomplete and subject-to-change as your code. With TDD, your formal specification is your suite of tests, and proving your code meets the spec is easy -- just run the tests.
As far as program specifications go, unit tests are a nice balance between a formal approach (a machine checks conformity) and an informal approach (the tests are always changing and never complete).
For most programming, I think this balance is the best we have.
My capstone project was of the independent research variety. I'm very interested in formal logic and proof systems, and wanted to examine parallels between generating a formal proof and writing a computer program.
What I ended up doing was creating a system that started out with a formal program specification written in Z-notation, and simultaneously generated a working Spark-Ada program and a proof of that program's conformity to the Z spec.
(Since each line of code transforms the program from one state to another, you can figure pre- and post- conditions of individual lines of code. So, the problem becomes a search for a list of statements whose pre- and post- conditions chain together to take the Z-specified preconditions to the Z-specified post conditions. The sequence of statements make up the working code, and the chain of line-by-line pre- and post- conditions are the correctness proof.)
The programs it could generate were very simple (they could only use a ridiculously small subset of Ada). It could write methods that did things like swapping the values of two variables. But it worked for the most part. And it was a lot of fun to work on, and I learned a lot.
The biggest thing I learned was the limited utility of proving code correct.
Something a fellow named Benjamin Russell said on the Haskell mailing list today got me thinking about software proofs (and inspired this post). He said that, "[b]asically, if you can prove that the program is correct, then you don't need to test it."
I disagree.
What I learned doing my senior capstone is that when you prove a program correct, what you're actually proving is that the program conforms to some specification. Maybe it's a specification formally defined in a language like Z, or maybe it's a non-formal specification that resides in your head.
But really, a specification is prone to error just like program code. As your specification gets more detailed, it starts to become another programming language. With my capstone, all I really did is write a Z-to-Spark compiler. I'd shifted the opportunity for human error up a level -- now, instead of making mistakes in Ada code, people were free to make mistakes in their Z spec.
It's like saying you can write provably correct assembly code that matches a C specification. Maybe C or Z is an easier language to reason in, but you still have to take a lot of time to examine your specification, to make sure everything in the system meshes together -- really, the formal specification becomes your new coding language.
On the flip side of the coin, as your specification becomes less formal, that opportunity for error shifts back toward the coding process. Less constraints in the specification mean more freedom in writing the code, which means more opportunity for mistakes in your actual program.
I guess what I'm saying is that in this approach:
1) come up with an over-arching specification for everything
2) write code that matches the specification
being able to prove code correct (prove it meets some spec) only gets you step two. Step one is just has hard (or harder). Creating a really formal specification means you have a new programming language to deal with, and a less-formal spec means you can have inconsistencies or missing information that bleed into your code base.
There is some essential complexity in developing software that cannot be eliminated by correctness proofs -- you're just moving opportunity for error from the "coding" side of the balance to the "specification" side.
All of that being said, if you're doing something that has to be right, like air traffic control or data encryption, and you're willing to spend a lot of time thinking about your formal specification, then I think provably correct software is the right goal. But correctness proofs are just one part of the process. Even if everything is proved correct, you still have to really test your software. If not to test the code, then to test the spec.
I think this is one of the reasons that test-driven development is such a practical idea for "normal" software development. It recognizes that your specifications are just as incomplete and subject-to-change as your code. With TDD, your formal specification is your suite of tests, and proving your code meets the spec is easy -- just run the tests.
As far as program specifications go, unit tests are a nice balance between a formal approach (a machine checks conformity) and an informal approach (the tests are always changing and never complete).
For most programming, I think this balance is the best we have.
Wednesday, September 17, 2008
Stack Overflow and the Tyranny of the Majority
As a reader of Joel, I was interested to try out Stack Overflow, which he has been talking about for some time, and just came out into a public beta.
It's a project developed in conjunction with Jeff Atwood that lets programmers ask questions, and other programmers answer them. The idea is that programmers vote up the questions and answers they think are good, and vote down the ones they think are bad.
In cases where there is a widely-known right answer, it works nicely. For example, the question, "how do you print information to the console in Java?" would be easy -- everyone knows to use System.out.println(), so answers that were way off base would be obvious to detect, and the question voted to the top would likely be the one to include extra information about redirecting output streams or whatever.
When I tried it out, I answered questions in the Java arena, since I know the subject well. Most things went smoothly, because many programmers know Java.
However, I also answered questions in the mathematics arena, since I'm ok at math. This is where things did not go as well. The right answers for the math questions seem to constantly lose out to the answers that would seem right to the average person who gives them a cursory glance, but are actually incorrect.
In some cases, the top voted answer contains some minor logical flaw. In other cases, the top voted answer is way off and comes to the exact wrong conclusion. No matter how hard I know and can argue for the right answer, I only have the same voting power as everyone else. If the majority of programmers think that you can reverse-project a 2D shape into a unique 3D shape, then that's what's going to show up as the "right" answer on stackoverflow.com.
Edit: Since I wrote this post, the right answer for the reverse-projection question has made it to the top, ruining my example. (Yes, I wrote it... how arrogant of me to assume my answer is right, eh?) But, if you browse around the "math" tagged questions, you'll probably see what I mean.
This phenomenon has a name: it's a tyranny of the majority. It's not the best answer that necessarily wins, it's the answer that most people are convinced is right.
It's a project developed in conjunction with Jeff Atwood that lets programmers ask questions, and other programmers answer them. The idea is that programmers vote up the questions and answers they think are good, and vote down the ones they think are bad.
In cases where there is a widely-known right answer, it works nicely. For example, the question, "how do you print information to the console in Java?" would be easy -- everyone knows to use System.out.println(), so answers that were way off base would be obvious to detect, and the question voted to the top would likely be the one to include extra information about redirecting output streams or whatever.
When I tried it out, I answered questions in the Java arena, since I know the subject well. Most things went smoothly, because many programmers know Java.
However, I also answered questions in the mathematics arena, since I'm ok at math. This is where things did not go as well. The right answers for the math questions seem to constantly lose out to the answers that would seem right to the average person who gives them a cursory glance, but are actually incorrect.
In some cases, the top voted answer contains some minor logical flaw. In other cases, the top voted answer is way off and comes to the exact wrong conclusion. No matter how hard I know and can argue for the right answer, I only have the same voting power as everyone else. If the majority of programmers think that you can reverse-project a 2D shape into a unique 3D shape, then that's what's going to show up as the "right" answer on stackoverflow.com.
Edit: Since I wrote this post, the right answer for the reverse-projection question has made it to the top, ruining my example. (Yes, I wrote it... how arrogant of me to assume my answer is right, eh?) But, if you browse around the "math" tagged questions, you'll probably see what I mean.
This phenomenon has a name: it's a tyranny of the majority. It's not the best answer that necessarily wins, it's the answer that most people are convinced is right.
Tuesday, September 9, 2008
Physical Health and Mental Acuity
Yesterday, I came across this post by a fellow named Jon Davis about "brain health." The post was inspired by a PBS special on the same topic, which I happen to have seen before. The PBS special, in turn, drew from the book Change Your Brain, Change Your Life by Daniel G. Amen, which I have not read -- looking over descriptions of the book, I'm doubtful I would like it at all, but that's beside the point.
PBS (and Jon) talk about many aspects of brain health -- things as diverse as learning new things, wearing a seatbelt, and avoiding drugs.
In this particular post, I'd like to talk about just the diet and exercise stuff, because I have some personal experience to share.
Oh, and I'm not a doctor or a nutritionist or anything, so take what I say with a grain of salt. Or not salt, really -- salt is not healthy! Take what I say with a grain of non-fat vitamin enriched saline substitute.
Firstly, I very much believe that if you're a programmer, engineer, lawyer, or whatever -- anyone that makes a living solving problems with your brain -- your personal physical health directly and dramatically affects your job performance.
If you don't believe me that being physically healthy improves your ability to solve problems, try a little experiment. Three of the big physical health habits the PBS special (and Jon) hit on that are pretty easy to change are:
In high school, I had completely opposite feelings about this kind of thing. I cared about math, computers, and Latin, and I didn't see why diet or exercise really mattered. Know what I took for my P.E. credit? Bowling. Seriously.
In college, though, I was lucky enough to have friends that understood the value of taking care of your body. I went to the gym a couple times with them, mostly out of beginning-of-the-semester freshman boredom. After only a couple times, I was feeling great physically, but also (surprisingly, to me) feeling mentally sharper.
I settled into just a fifteen minute run three times a week. The weekly 45 minutes I was investing at the gym paid off tenfold when I could stay focused so well while studying. Even in the middle of tough seventeen-hour math/CS loaded semesters, I would find time to go to the gym, knowing that failing to take care of myself would only lead to longer nights of unfocused and unproductive "studying."
As a bonus, eating well became sort of natural. I didn't feel like devouring half a bag of chips, because I knew it would make me feel gross while I ran later. Instead of force-feeding myself the "right" kinds of food, those kinds of food were just what started sounding good.
So, here's what I do these days to try to keep my health up:
PBS (and Jon) talk about many aspects of brain health -- things as diverse as learning new things, wearing a seatbelt, and avoiding drugs.
In this particular post, I'd like to talk about just the diet and exercise stuff, because I have some personal experience to share.
Oh, and I'm not a doctor or a nutritionist or anything, so take what I say with a grain of salt. Or not salt, really -- salt is not healthy! Take what I say with a grain of non-fat vitamin enriched saline substitute.
Firstly, I very much believe that if you're a programmer, engineer, lawyer, or whatever -- anyone that makes a living solving problems with your brain -- your personal physical health directly and dramatically affects your job performance.
If you don't believe me that being physically healthy improves your ability to solve problems, try a little experiment. Three of the big physical health habits the PBS special (and Jon) hit on that are pretty easy to change are:
- diet
- sleep
- exercise
- eat well: avoid junk food, drink plenty of water, etc
- go to bed early: shoot for at least 9 hours of sleep
- get some exercise: go for a walk or run -- 15 or 20 minutes is enough
In high school, I had completely opposite feelings about this kind of thing. I cared about math, computers, and Latin, and I didn't see why diet or exercise really mattered. Know what I took for my P.E. credit? Bowling. Seriously.
In college, though, I was lucky enough to have friends that understood the value of taking care of your body. I went to the gym a couple times with them, mostly out of beginning-of-the-semester freshman boredom. After only a couple times, I was feeling great physically, but also (surprisingly, to me) feeling mentally sharper.
I settled into just a fifteen minute run three times a week. The weekly 45 minutes I was investing at the gym paid off tenfold when I could stay focused so well while studying. Even in the middle of tough seventeen-hour math/CS loaded semesters, I would find time to go to the gym, knowing that failing to take care of myself would only lead to longer nights of unfocused and unproductive "studying."
As a bonus, eating well became sort of natural. I didn't feel like devouring half a bag of chips, because I knew it would make me feel gross while I ran later. Instead of force-feeding myself the "right" kinds of food, those kinds of food were just what started sounding good.
So, here's what I do these days to try to keep my health up:
- I still exercise regularly -- I'll go for a 20 minute run two or three times a week, do a little weight lifting, and fence a couple times a week. (By the way, picking up a sport, especially one with a strong mental component like fencing, is a fantastic way to up your level of exercise while still having a good time).
- My diet is what I like to think of as "reasonable." Most of the time, I think I do a good job keeping everything in balance. I'm not afraid to eat delicious things that are bad for me, I just try not to do it too often.
- I take a daily multivitamin as a catchall for things I might be missing in my normal diet
Monday, September 8, 2008
Posta Prima Vera!
Which is Italian for first post!
And that's what this is -- a first post. Well, sorta.
See, I have this other blog at http://robdickerson.net.
The problem is that I mostly want to write about software. But I also have hobbies and a personal life and stuff, and I end up with this 80/20 split between software and personal posts.
I guess the site's identity crisis isn't a problem for my readers, because I don't have any, but it bugs me. I think most people reading the front page of robdickerson.net (if anyone ever did, which they don't) would either get bored by the software stuff or annoyed at the irrelevant personal stuff.
I know I feel that way when I read the site, and it's my own writing for crying out loud.
Anyway, I've started this blog to be a place where I can write just about software. And maybe my other site will wither and die, which would be cool, since I have better things to do than maintain a Wordpress install anyway.
Speaking of which, this seems like a good time to kind of explain what I do (software-wise).
First of all, I write code for a living.
Like -- oh, let's say 70% -- of programmers around the world, I make my living with Java. And then make up statistics about how most programmers also have to use Java, so I don't feel too bad about it.
Non-professionally, I do have the occasional Java project, but I like to work in other languages because a) it's fun, and b) I don't want to get stuck thinking in Java (or any single language) all the time. I've toyed with a bunch languages in the past, but I think my current favorites are Python and Haskell.
Of course, I have all kinds of awesome opinions about software -- opinions that are always completely right, now and forever -- that I plan on sharing here in the future.
And that's that. Welcome to Programming Rob.
And that's what this is -- a first post. Well, sorta.
See, I have this other blog at http://robdickerson.net.
The problem is that I mostly want to write about software. But I also have hobbies and a personal life and stuff, and I end up with this 80/20 split between software and personal posts.
I guess the site's identity crisis isn't a problem for my readers, because I don't have any, but it bugs me. I think most people reading the front page of robdickerson.net (if anyone ever did, which they don't) would either get bored by the software stuff or annoyed at the irrelevant personal stuff.
I know I feel that way when I read the site, and it's my own writing for crying out loud.
Anyway, I've started this blog to be a place where I can write just about software. And maybe my other site will wither and die, which would be cool, since I have better things to do than maintain a Wordpress install anyway.
Speaking of which, this seems like a good time to kind of explain what I do (software-wise).
First of all, I write code for a living.
Like -- oh, let's say 70% -- of programmers around the world, I make my living with Java. And then make up statistics about how most programmers also have to use Java, so I don't feel too bad about it.
Non-professionally, I do have the occasional Java project, but I like to work in other languages because a) it's fun, and b) I don't want to get stuck thinking in Java (or any single language) all the time. I've toyed with a bunch languages in the past, but I think my current favorites are Python and Haskell.
Of course, I have all kinds of awesome opinions about software -- opinions that are always completely right, now and forever -- that I plan on sharing here in the future.
And that's that. Welcome to Programming Rob.
Subscribe to:
Posts (Atom)