Available formats: [.txt] [.pdf] [.mp3]
So What’s It About?
“Underground” by Suelette Dreyfus is a great historical fiction narrative detailing the rise and fall of some crackers and phreakers and their opponents: phone company employees, system administrators, and Feds. It takes place between 1988 and 1994, when multi-user BBSes were starting to pop up and a telephone call was the ONLY way to access other computers. It’s about 99 times better than this review. In fact, I request that you stop reading this immediately and just read it yourself. It’s really that good.
That being said, most of the stories are told from the perspective of the attackers, except for a few spurious tales of BBS operators and virus attacks. All of the attacker stories have similar plot themes:
- Personal Background: Who were their friends? How was their family life?
- The first taste: How did they get into the scene? Who were their friends and mentors? How did they get free international calling? Were they chasing a white whale, or were they just enjoying themselves?
- The glory days: Usually describes a list of big fish that the attacker accessed, as well as the social support the attacker got in his home community. At this point, the Feds notice the attacker and start playing cat-and-mouse with him.
- The Law Won: The Feds make an identification, and either the attacker goes on the lam or gets busted at his computer. Nobody who got away would be at liberty to contribute to the book, so logically the attackers mentioned in the book are all caught. The court cases are described, as well as public reaction.
- Where they are today: How the legal system treated them, what they did after their legal troubles were over, and are they currently employed?
Literary Freeware
The author, Suelette Dreyfus released the book as “Literary Freeware,” allowing anyone with an internet connection to download the book for free. The text of the book was released to Project Gutenberg, and the author herself wrote a special forward for the free version of the book, describing the reasons a book’s author might decide NOT to get paid for the book:
From the forward:
Because part of the joy of creating a piece of art is in knowing that many people can – and are – enjoying it. Particularly people who can’t otherwise afford to pay $11 USD for a book. People such as cash strapped hackers. This book is about them, their lives and obsessions. It rubs clear a small circle in the frosted glass so the reader can peer into that hazy world. ‘Underground’ belongs on the Net, in their ephemeral landscape.
[...]
By releasing this book for free on the Net, I’m hoping more people will not only enjoy the story of how the international computer underground rose to power, but also make the journey into the minds of hackers involved. When I first began sketching out the book’s structure, I decided to go with depth. I wanted the reader to think, `NOW I understand, because I too was there.’ I hope those words will enter your thoughts as you read this electronic book.
The book’s website also hosted dozens of different formats/languages of the book. However, don’t try to go there anymore! It’s been taken over by some crappy hacker book e-commerce website. A reader named Rory Gordon searched the internet much more thoroughly than I did and discovered that http://www.underground-book.net is apparently the website’s actual address. Also the Wayback Machine has you covered! It even archived the 26 language/file format combinations the author made available.
How Was It?
It is good. How good? I dislike reading e-books. I like to read on my bed and sometimes write on my copy of the book. By the time I drag my desktop computer over to my bed and plug it in, I’m no longer in the mood for reading, and when I draw on the monitor, I can’t use it for other things. I actually ordered a hard copy of A New Kind of Science — review coming, whenever I summon the courage to read the last two chapters — so that I didn’t have to print out 1000 pages or read it on my computer monitor.
Despite all of this, I read the whole PDF (~300 pages) within 48 hours when I first got my hands on it — summer of 2007, for those keeping track. I stayed up late, I snuck peeks in my school IT job, and I couldn’t put it down to save my life.
At times, the pace is a lot like The Da Vinci Code, but with much longer chapters. If you don’t like that, the pacing is a lot like Harry Potter. If you don’t like that, the pacing is similar to the action sequences of Snow Crash. If you don’t like any of them, then I feel you need a good hug and some cake.
Highlights
First and foremost, it is well-written from a technical standpoint. There aren’t any “Law and Order” moments where images are super enhanced and Visual Basic GUIs are prototyped to track IP addresses. The author accessibly writes like she knows Unix systems, which is refreshing, given the number of errors I find in technical articles written by non-techies.
As for content, the story of Par is by far the best out of all of them. On a tip, he found a computer that was almost literally a gold mine: dialing it at certain times of the day caused it to spit out a large list of valid credit card numbers owned by rich Saudis. He ends up handing them out and using them like they’re free candy, which ends up drawing the eye of the Secret Service. He ends up having to go on the lam, surviving on the kindness of fellow hackers — and his 23-year-old Swiss girlfriend, Theorem. What follows is a great description of the techniques the Secret Service used to track him down (involving agencies working together on a few different continents), as well as his dumb luck in evading capture for so long.
Also, the book is chalk-full of moments like this:
If, however, the line did not have a trace on it, the company’s modem would search for its lost connection to the hacker’s modem. Without the continuous flow of electronic signals, the NorTel modem would hang up after a few seconds. If no-one reactivated the line at the NorTel end, the connection would time-out 90 seconds later and the telephone exchange would disconnect the call completely.
Mendax listened anxiously as the NorTel modem searched for his modem by squealing high-pitched noises into the telephone line. No modem here. Go on, hang up.
Suddenly, silence.
OK, thought Mendax. Just 90 seconds to go. Just wait here for a minute and a half. Just hope the exchange times out. Just pray there’s no trace.
Then someone picked up the telephone at the NorTel end. Mendax started. He heard several voices, male and female, in the background. Jesus. What were these NorTel people on about? Mendax was so quiet he almost stopped breathing. There was silence at the receivers on both ends of that telephone line. It was a tense waiting game. Mendax heard his heart racing.
A good hacker has nerves of steel. He could stare down the toughest, stony-faced poker player. Most importantly, he never panics. He never just hangs up in a flurry of fear.
Then someone in the NorTel office–a woman–said out loud in a confused voice, ‘There’s nothing there. There’s nothing there at all.’
She hung up.
Mendax waited. He still would not hang up until he was sure there was no trace. Ninety seconds passed before the phone timed out. The fast beeping of a timed-out telephone connection never sounded so good. Mendax sat frozen at his desk as his mind replayed the events of the past half hour again and again. No more NorTel. Way too dangerous.
In Conclusion
Read the book! This whole paragraph is a big link to the PDF. Just read it! It’s good!
Popularity: 26% [?]
I believe that everyone hates the feeling of starting from scratch, regardless of age or experience. This will cause people who should know better to make bad decisions, even misleading people who are conscious of the effect.
In my mental model of knowledge, I split skills between three major mastery levels:
- Those we can use professionally. I program professionally, and I practice daily to strive for mastery. I’m getting to the point where I can handle any task that is thrown at me.
- Those we can use. I can cook without killing myself of burning down my apartment complex, even though I can’t make many types of food and wouldn’t recognize a Mother Sauce if it was poured down my shirt.
- Those we couldn’t really use if our life depended on it. I’m not good at drawing. I’ve never spent time on it, and I have no motivation to learn. I can “draw” diagrams and get my point across, and this is enough for me.
All people treat the skills from the first category differently than the other two: we use them with confidence. Some people use them with arrogance. We know these fields well enough to absorb innovations and new ways of thinking. We can confidently discuss them with other people.
In my mental model, starting from scratch in our expert area causes people to reject a change. For instance: an Excel or Word guru would never willingly switch to a completely unrelated product. Relearning things line inserting line-breaks and adding pictures to a text document is completely orthogonal to anything they actually have to do on the job, much less something more complicated like Mail Merge. Instead of using it like it should be used, they would likely try using it like they used their old product, declare that it can’t ramrod the flimjam, and switch back to their old way of doing things, regardless of which is really better.
Interfaces and APIs
Altered interfaces are difficult for the end user. This isn’t just about GUIs or the placement of buttons in a menu; this extends to software APIs as well.
An altered menu causes all users to waste time looking for new ways to do something they could do 5 minutes ago. Changes to an API cause the programmers relearn a library they already knew — not to mention the laundry list of changes that need to happen to the new stuff!
APIs and Interfaces
The interface for a library or class develops massive unavoidable dependencies with use. I’ve called this “code inertia” in the past. Joel and Jeff’s recent discussion of dependencies between unit tests and code is a perfect example of code inertia: making nontrivial changes to an application can force a nontrivial number of changes to your automated testing environment.
This has not only a physical effect on the code, but also a mental effect for programmers! I’ve actually heard arguments from programmers based on the IDEA of possible future change: we shouldn’t use this library because it’s changed significantly in the past, and it might change again! Having to relearn the API combined with the frustration of updating broken code leaves a giant red flag in a programmer’s mind, even though any codebase that is being properly maintained will go through interface changes as new versions are released.
Excel
I was fortunate enough to take a Numerical Methods and Analysis class during my senior year of college.
If you’re not familiar, it’s the mathematics of computation: finding efficient approximations, determining rate of convergence, and knowing the margin of error at each stage.
This was my only college class where a calculator was ever useful. Most of our homework involved finding the values and error in iterative processes, so the professor suggested a “complex math package” for our homework: Excel.
Despite my initial skepticism, Excel is AWESOME with iterative numerical computation: type in a relative formula, highlight 50 rows, and click “fill down.” Voila! You can put a bunch of results in adjacent columns and compare convergence rates visually before you even prove that it converges at a certain rate. It’s quick, it’s interactive, and it supports easy experimentation.
Why is this relevant? My college upgraded to the Microsoft Office 2007 suite the previous summer, toolstrip and all. Every single class was punctuated by my professor loudly complaining that she HATED the new Excel because the interface was WORSE and she couldn’t find anything.
Even though she knew where everything was after 2 weeks of use, we got the same complaint every week. She had already made up her mind: it was worse.
KDE and Linus
A few years ago, Linus Torvalds publicly announced his Linux desktop preference on the GNOME message boards:
I personally just encourage people to switch to KDE.
This “users are idiots, and are confused by functionality” mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don’t use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn’t do what I need it to do.
Please, just tell people to use KDE.
Linus
The different camps typed their representative emoticons — 
and D: — and then life continued as normal. However, Linus was eventually forced to switch when the next version of KDE changed too much:
Interviewer: Another open source project that underwent a big change was KDE with version 4.0. They released a lot of fundamental architectural changes with 4.0 and it received some negative reviews. As a KDE user how has this impacted you?
Linus: I used to be a KDE user. I thought KDE 4.0 was such a disaster I switched to GNOME. I hate the fact that my right button doesn’t do what I want it to do. But the whole “break everything” model is painful for users and they can choose to use something else.
I realise the reason for the 4.0 release, but I think they did it badly. They did so may[sic] changes it was a half-baked release. It may turn out to be the right decision in the end and I will re-try KDE, but I suspect I’m not the only person they lost.
I got the update through Fedora and there was a mismatch from KDE 3 to KDE 4.0. The desktop was not as functional and it was just a bad experience for me. I’ll revisit it when I reinstall the next machine which tends to be every six to eight months.
The GNOME people are talking about doing major surgery so it could also go the other way.
Linus realizes that it might be the right decision in the long run, but there’s no escaping the fact that even the big guns in the field can’t spend his time relearning the basics every day, even if it’s the right thing to do. He has a mental model of how the desktop is supposed to work, and when KDE broke it, he fixed the problem.
Adult Learning and Malcolm Knowles
To me, a lot of the principles of API and interface design fall under adult learning. To state the obvious, most of the indended clients for interfaces are adults. We’d like them to learn how to use our products with the minimal amount of fuss.
However, if your interface is exactly like every other interface, there would be no reason to use it. You’re trying to solve a problem for yourself, and you’re trying to solve a problem for your intended users. Your users will have to learn how to solve their problems with your interface, and it had better be easy.
Enter the research of Malcolm Knowles. He is one of the big-shots in the field of adult learning, having done a lot of the early theoretical work. This site has a good description of his life’s work with researching, for the interested.
In particular, Knowles attempted to find the theory of what caused adults to best learn. Believe it or not, there hadn’t been extensive research in the field before he started. The closest that he was able to come was his theory of informal learning, through group sessions or other kinds of informal meetings. He also developed his assumptions by which adults learn:
Malcolm Knowle’s Assumptions on Adult Learning
- Self-concept: As a person matures his self concept moves from one of being a dependent personality toward one of being a self-directed human being.
- Experience: As a person matures he accumulates a growing reservoir of experience that becomes an increasing resource for learning.
- Readiness to learn. As a person matures his readiness to learn becomes oriented increasingly to the developmental tasks of his social roles.
- Orientation to learning. As a person matures his time perspective changes from one of postponed application of knowledge to immediacy of application, and accordingly his orientation toward learning shifts from one of subject-centeredness to one of problem centredness.
- Motivation to learn: As a person matures the motivation to learn is internal.
The salient bullet point is #2: experience. It’s directly listed as a basis for adult learning. I’m not saying that this is a direct proof of my mental model of knowledge, because quite honestly it’s just not a proper conclusion. However, designers of APIs and GUIs should take this as an indication that experience is something to build on, not disregard.
To use an aforementioned example, I really like the ribbon interface in Office 2007! I was proficient after only a few hours, and I enjoyed using fewer keystrokes to achieve my goals. I thought that it mapped pretty well to the old menu-based methods, and it was pretty obvious when it didn’t. If I could use only keyboard shortcuts to navigate, it would be the ideal control.
However, it’s probably a bad idea releasing it in the same year as Vista, which already scrambled some menus, changed some positions, altered some interfaces, renamed some popular folders, added UAC, etc. It all added up to too much of a change: when people sat down at it for the first time, nobody couldn’t use the darned thing.
Live and learn!
Footnote
I remember a minor fuss when Linux 2.6.0 came out because the device driver interface changed. Linus himself descended from the cloud to state that he makes the right design choices for Linux without regard to compatibility issues. It was going to tie in really nicely with my point, and my Google Fu has failed me. up. The device driver interface changed from 2.4 to 2.6, and that there was a of device driver complaints. At this point, I just want to know if I was making this up.
Popularity: 20% [?]
BattleCode is an annual programming competition hosted by MIT students. Teams of 1 to 4 people design real-time strategy AI and compete head-to-head with other teams.
Overview of BattleCode
The competition’s focus tends to vary from year to year. Last year’s competition could be won either by capturing most of the towers on the map or by completely wiping out the players on the other team.
It’s even better this year: it’s primarily a resource-managing competition. Certain tiles on the game board contains a resource (flux) that you can gather. If you have more when the round ends — or cross a magic threshold during the match — then your team will be declared the winner.
It’s probably still possible to create a winning team that is entirely militaristic, but I have a feeling that the organizers are trying to reward teams that split-up. Most of the teams that split up into groups last year were defeated by monolithic swarms, but this mechanism of resource mining and control might better side with teams that split.
The good news is that it seems like there is a core group of functionality that remains the same from year to year, so code that is written for a previous BattleCode tournament is still usable the next year. I just found out about it, so I’m in the process of developing a player from scratch.
Great Design Decisions
A great BattleCode design decision involves the maximum number of units: it’s self-regulating. There is no ‘official’ limit to the number of units that can run at any one time, but all units must return to one of 6 central energon-producing units (Archons) from time-to-time or they die. The Archons produce Energon at a constant rate, preventing too many units from existing at once.
The genius of the design of the soft-cap is that it allows two extra strategies into the game: first, you can send some of your units on a suicide run guilt-free! If a unit decides that it’s FUBAR, it can send a message home saying “Just trying to kill some bugs, sir!” and its parent can feel free to spawn a new unit at its earliest convenience.
As a result, the Archons are as valuable as a King in chess: it’s not very powerful, but you can’t afford to lose it.
Java-Based Programming
The competition software uses the Java VM to control the matches. The user overrides a Runnable class named RobotPlayer. The run() function lets the user define the behavior of the AI agent. They provide a default function that solely moves the AI, but it probably won’t get you very far in the main competition.
The run() function is written as a loop, and robots don’t have a clear idea of a separation of turns: they are limited to 3000 Java bytecodes per “turn,” and the controller switches to the next robot automatically. A “yield()” function is provided that artificially ends a turn.
Very Algorithm-Friendly
There is no centralized user-written player to pass strategy and tactics to individual units: they have to decide that amongst themselves. You need to tell them how to move, how to fight, and they need to be able to manage their own health.
The two major categories of algorithms that need to be developed are dynamic path-finding algorithms (because a robot needs to know where it’s going!) and distributed organization. You need to be able to use your units to protect your Archons, they need to be effective fighters, and it would be a poor unit that gets stuck on the first non-passable square it encounters.
I have no doubt that some teams are eventually able to publish papers on some of the organization techniques that they use: quite a bit of work can be accomplished in 3000 bytecodes, and I bet that some of the organization and attack techniques are more sophisticated than many papers that have been actually published.
My Plans
My goal is to have a force that can fully spawn, move, and fight by the end of January, and my final strategy and tactics to be decided by the end of February. I will most likely merge with a team that has a few of my friends by the end of the month, but you’ll be able to find me by my username (jakevoytko).
Popularity: 20% [?]
