Installing Ubuntu and Debian for a triple-boot machine

I recently installed Ubuntu and Debian for the first time. Here's how I did it.

The first thing I did was order a second 2.5" hard drive. I chose 320 GB drive, which is the largest size you can get without Advanced Format. I figured that I didn't need tons of space and I didn't want to worry about partitioning issues with an Advanced Format drive. My laptop is a Thinkpad T400. The great thing about Thinkpads is their modular design. Normally, the T series Thinkpads come with a DVD drive, but it is removable. So I took out the DVD drive and swapped it for a second hard drive. I found a third party hard drive adapter for the Thinkpad Serial Ultrabay Slim form factor. This way, I was able to keep my Windows 7 install on my main hard drive and not worry about breaking it with a Linux install.

I followed this partitioning guide and used GParted to split the second hard drive into four partitions: two root partitions (30 GB each for Ubuntu and Debian), a swap partition (8 GB), and a share partition (230 GB). I used Tuxboot to install GParted on a bootable flash drive.

Everything went great up to this point. Following the recommendation on the Ubuntu install page, I used Pen Drive's Universal USB Installer to load up Debian and Ubuntu on bootable USB drives. Then I tried to install Debian Squeeze and it kept failing to find my wifi. I tried my wired connection, but that failed, too. Since I was doing a net install (minimal Debian) off of a USB flash drive, I needed an internet connection to download all the GUIs and other packages which make Debian usable. However, because I had no internet connection, I kept ending up with a "command line" style Debian. I even tried downloading the "non-free" Debian which contains software that hard core Debian people consider proprietary. Didn't work. Ugh. After trying to get this to work all night, I gave up and installed Ubuntu 12.04 LTS on my other root partition. It booted up fine the first time, but the second time, I got a black screen. I finally went to sleep as the sun was rising.

When I woke up, I booted up Windows and remembered that I forgot to change my BIOS settings for the graphics card. My Thinkpad has switchable graphics, meaning that it can switch between integrated graphics and the discrete graphics card. I turned this off and set my computer to always use the discrete graphics card. Then Ubuntu booted up correctly and consistently. As for Debian, I went to the #debian IRC channel and presented my problem. People told me to avoid the current stable release ("Squeeze") and use the testing release ("Wheezy"). In addition, they told me to use the non-free version of Wheezy and to make sure I had all the firmware files for my wifi card. When I followed these directions, Wheezy found my wifi card and installed the packages off the internet. Now I had a desktop for Debian. Finally, I had both Ubuntu and Debian working!!!

The last thing to do was to fix my GRUB screen. The Ubuntu and Debian installers are really smart and automatically added themselves to the GRUB screen, allowing me to triple boot in Windows 7, Ubuntu, and Debian. However, after installing two distros and updating Ubuntu, my GRUB screen contained many useless entries. So I installed the GRUB customizer package on Ubuntu and used that to clean up my GRUB. Here's my edited GRUB screen:

All this work took two days, but in the end, success! In retrospect, installing Linux was a pretty smooth experience, with the exception of the Debian wifi problem.

Link of the day: "To know, but not understand"

I liked the essay "To know, but not understand" by David Weinberger in The Atlantic. Weinberger discusses one of the major shifts in science today -- the data deluge. Here's the issue in a nutshell:

In 1963, Bernard K. Forscher of the Mayo Clinic complained in a now famous letter printed in the prestigious journal Science that scientists were generating too many facts. Titled Chaos in the Brickyard, the letter warned that the new generation of scientists was too busy churning out bricks -- facts -- without regard to how they go together. Brickmaking, Forscher feared, had become an end in itself. "And so it happened that the land became flooded with bricks. ... It became difficult to find the proper bricks for a task because one had to hunt among so many. ... It became difficult to complete a useful edifice because, as soon as the foundations were discernible, they were buried under an avalanche of random bricks."

And that letter is from 1963! Weinberger points out that thanks to computer power (Moore's Law) and cheap digital storage, we have even more data than we know what to do with. But as much as it seems like computers are the problem, they might also be the solution. He talks about modelling science, which uses computers to perform simulations and software like Eureqa which looks for patterns in data and generates equations to encapsulate those patterns. Of course, this isn't as satisfying as Maxwell's equations and the like, but it looks like this is something we'll have to live with. As Weinberger states,

The world's complexity may simply outrun our brains capacity to understand it.

Physics as a subject for a kids comic book and how to get kids interested in science

For several years now, I've wanted to write a physics comic book with the goal of getting kids interested in science. The problem is that I just don't have a good idea how to do it. I need a really great idea because a comic book has to compete with TV, video games, internet, and all the other entertainment children are exposed to in the modern world.

I'm starting to feel like physics is simply not a good subject for a kids comic book. Anything that is abstract like physics will be difficult to pick up quickly and therefore you need to be able to play with it, experiment. Programming is abstract but lots of kids pick it up because you can write code and run it immediately. You can quickly progress to the point where you can make images fly across the screen. You know if the program works, because either the image flies across the screen or it doesn't. Instant feedback. That is fun, exciting, and addictive (in a good way). When you do a physics problem and you get an answer, it's very difficult to know if your answer is correct or if it makes sense. You could do a real physics experiment, but physics experiments are notoriously difficult to do right and require special equipment. I was always amazed in high school at how much equipment we needed to do simple experiments let measuring the velocity of an object moving along a track. When you do a chemistry experiment, you mix two solutions and the color changes. You can see or feel the result qualitatively. Physics experiments require too much precision; you actually have to measure the exact numbers to see if you're doing it right.

I'm starting to think that if you want to get kids interested in science and engineering without much equipment, the appropriate subjects are programming and math. I've already discussed programming. You can come up with all sorts of interesting math problems at all different levels. You can get a sense of whether your answer is correct by plugging in numbers. For geometric problems, you can often solve them by drawing pictures. Best of all, you don't have to worry about equipment failing in your experiments. Mathematics isn't constrained by the physical world, so there are lots of different ideas you can talk about, whereas in physics you are stuck discussing Newton's laws, Maxwell's equations, etc. For older kids who want to do something hands-on, I would recommend electronics. The parts are small and you don't need to go a machine shop.

Thought of the day: Can you teach a computer good taste?

I don't know much about artificial intelligence or learnabilty, but it's fun to think about what a computer might be able to learn. One characteristic that separates a novice from an expert is "good taste". (I first heard of this idea from a Paul Graham essay.) Supposedly, "good taste" is something that is not a characteristic that is easy to acquire quickly, unlike simple "knowledge." Then it would be a interesting challenge to see if a computer could learn good taste. If it's hard for humans, it would be probably be even harder for computers. Scientists already have enough trouble in machine vision research, getting computers to see things that humans find obvious.

Code complexity

An oft-uttered mantra in programming is to write "good" code that is well-organized and understandable. One obvious question is how do you know if you have "bad" code that is too complicated and unintelligible?

People have researched this question and have come up with "complexity metrics" to quantify how complicated a piece of code is. A well-known metric is the McCabe complexity metric or "cyclomatic complexity." It roughly counts how many different paths you can take to get from the beginning to the end of the code. The more branching statements and loops in the code, the more complicated it is. A rule of thumb is that a module should have a cyclomatic complexity of no more than ten (CC < 10). If the cyclomatic complexity is larger, you should refactor the code. This is really cool. It's great to have a non-human, automated method to test the complexity of code. I'll have to try running some complexity metric tools on the next programs I write. For further reading, check out Reg. Charney's article on code complexity metrics in Linux Journal or this IBM development article on cyclomatic complexity.

Stack Overflow and question-and-answer websites

I found that I learn a lot by reading forums. I learned about hockey equipment at ModSquadHockey and about musical theater at Musicals dot Net. This is a great way to learn about relatively obscure topics. Unfortunately, this method is also very time consuming because forums are almost completely unorganized. Even if you search for keywords, you have to filter through a lot of noise.

Wikis are much more structured and easier to read. Unfortunately, they require a lot of work because the contributors need to write decent articles and there are the issues of who can edit the wiki and multiple authors of the same article. These difficulties are the reasons you see a lot of incomplete wikis on the web.

A nice compromise between forums and wikis are question-and-answer websites like Quora and Stack Exchange. Instead of having threads like on forums, question-and-answer websites organize by question. For each question, other users post answers. This seems pretty much the same as forums so far. The key difference between forums and question-and-answer sites is that the users can dynamically tag questions and vote on how much they like a particular question or answer. The users do the filtering and that makes the website so much easier and enjoyable to read.

Quora is a very general Q&A site, with the philosophy that you have to stand by your answers. You're supposed to use your real name when you answer and you are asked to give qualifications as to why you are an "expert" in the topic. The site is closed to the public. You have to register and login. I think the reason is it is semi-private is to prevent Quora from becoming like Yahoo Answers which attracts a lot of random, "bad" answers. Stack Exchange is a group of Q&A websites on mostly technical topics. You don't have to login to see the answers, which is why I think Stack Exchange is more popular. I see Stack Exchange websites show up in Google searches whereas I never see anything from Quora. The most famous Stack Exchange site is Stack Overflow, which is focused on non-expert programming (though "expert" is subjective). I have fun reading through the top voted Stack Overflow questions for particular topics like Python and Mathematica. So far I like Stack Overflow better than Quora. Jon Evans wrote a comparison of the two sites in TechCrunch.

Link of the day: "The Web Browser Address Bar is the New Command Line"

The title of the post pretty much says it: "The Web Browser Address Bar is the New Command Line." By the way, I love the command line. It's fast and succinct. The only problem I can think of is that the command line relies on a good memory. If I don't use commands after a while, I forget them. When you add the shell to the command line, you get Unix magic!

The post mentions the site yubnub which really is the embodiment of the address bar as command line. I've tried yubnub but for some reason, I've never really felt a need for it.

High performance Scheme?

In college, my favorite class was the introductory programming class. It was amazing. We used Scheme and touched upon almost every programming topic under the sun, including compilers, streams, lambda calculus, and object-oriented programming. (So, it wasn't an ordinary intro class and we didn't use no ordinary textbook.)

I haven't used Scheme much these days, but a few days ago, a colleague asked me if I knew of ways to improve the performance of Scheme code. He was wondering if there was software analogous to Python calling C or Fortran code.

I found a good discussion of fast Scheme compilers at this forum. Apparently, Bigloo allows communication between C code and Scheme code. There are also some really fast Scheme compilers like Chicken, Gambit and Chez.

One thing I've wondered is how to translate loop-heavy C/Fortran code into Scheme. My programming class hardly even discussed loops. I did find a short discussion on how to write a loop in Scheme at the MIT ab-initio wiki.

I don't have any reason to look further into this right now, but these compilers could be useful someday in the future.

Amateur computation

I finally got around to reading Brian Hayes's essay "Calculemus!" from the American Scientist. The essay and many of Hayes's other works are available on bit-player.org.

Hayes talks about making computation more accessible to laypeople so the average computer user can do "inquisitive computing." He gives some examples of inquisitive computing from mathematics, for instance, perfect medians. A positive integer m is a perfect median if it satisfies the equality 1 + 2 +... + m-1 = m+1 + m+2 + ... N for some number N.

Inquisitive computing is a cool idea. I have often thought about becoming a better programmer by challenging myself with little problems. I don't have the kind of personality to work on mathematical puzzles, but I would like to learn enough so I can write scripts to solve tedious everyday problems. For example, a week ago, I wanted to import my calendar file to Yahoo. The support staff at Yahoo told me that in order to safely import my 16,000 line CSV file, I should divide it into 1000 line chunks. If I hadn't been so lazy, I should have written a Python script to read the CSV file line-by-line and spit out a 1000 line CSV file after each 1000 line chunk. I was lazy because I don't know Python well enough yet.

These types of problems come up all the time and I'm always really impressed when I see a person post a script solution on a computing forum. One of my goals is to someday become that person -- the scripting guru.

Quote of the day: Backgammon vs chess

This quote comes from a Dr. Dobb's interview with computer science professor Christos Papadimitriou.

Frankly, I think backgammon is a much more interesting game [than chess], much harder to learn... In chess, when you play like an idiot, you always lose, so you learn. In backgammon, you can play 10 games, not play well, and win. So you think you are great but you have made a great number of mistakes. Tragically, life is closer to backgammon, because you can play a perfect game and lose!

Link of the day: "The Ultimate Code Kata"

At Coding Horror, Jeff Atwood writes about "The Ultimate Code Kata." To quote a quote from his post:

Contrary to what you might believe, merely doing your job every day doesn't qualify as real practice. Going to meetings isn't practicing your people skills, and replying to mail isn't practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something.

I know a lot of great engineers -- that's one of the best perks of working at Amazon -- and if you watch them closely, you'll see that they practice constantly. As good as they are, they still practice. They have all sorts of ways of doing it, and this essay will cover a few of them.

The great engineers I know are as good as they are because they practice all the time. People in great physical shape only get that way by working out regularly, and they need to keep it up, or they get out of shape. The same goes for programming and engineering.

The way I interpret this idea is that quality of practice matters over quantity. As Atwood says, you have to be focused (you are telling your mind "I'm practicing this skill right now") and you have to find ways to challenge yourself. Frequently, physicists will think of small problems and try to work them out. I talked to one of my fellow grad students once and he said that when he was tired of research, he would practice programming in Mathematica. For example, he would try to have Mathematica compute the prime numbers between 500 and 1000.

Off and on, I practice hockey shooting by shooting off a board into a lacrosse net. I realized that I didn't want to keep shooting from the same position, so I tried various challenges like moving the board, shooting off balance, shooting from an extended reach, shooting from a squeezed reach, trying to shoot as high as possible, picking a corner to shoot at, etc. I think this is an example of "kata."

Python mutable defaults

In the short time that I've learning Python, the most annoying "feature" is Python's mutable defaults. You can define a default parameter for a variable in a function, but if the variable happens to be mutable (like a list), you get strange side effects. The book Learning Python by Mark Lutz gives a detailed explanation on pages 373-374. I will follow some of Lutz's discussion with a few of my own comments.

Suppose you write the following function.

def saver(x=[]):
... x.append(1)
... print x
...

Then you run it like so:

>>> saver([2])
[2, 1]
>>> saver()
[1]
>>> saver()
[1,1]

The third output is probably not what you wanted. You probably wanted [1]. The problem is that the default parameter is only evaluated once, when the function definition is evaluated. A common solution is to stick an if statement at the beginning of the function body.

def saver3(x=[]):
... if x is None
... x = []
... x.append(1)
... print x
...

Another solution is to use an or statement.

def saver3(x=[]):
... x = x or []
... x.append(1)
... print x
...

Both solutions give the same behavior because they force the default parameter to be evaluated for every function execution, rather than just once as with saver(). It's really confusing, isn't it? The x in if x is None evaluates the default value, but the x in x.append(1) doesn't. I can't really think of any logical way to remember this difference. I guess I just have to memorize it.

However, as Lutz notes in his book, saver2() and saver3() aren't quite the same because if you pass an empty list, saver2([]) keeps the passed list whereas saver3([]) creates a new empty list.

EAFP vs LBYL

I've been learning Python in the last few weeks. Many of my friends have switched to using it, making me think that it's the scientific programming language of the future (if not now).

I've been working my way through the official Python tutorial. I was amused to find the following in the tutorial glossary:

EAFP
Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style that is common in many other languages such as C.

And what is LBYL, you may ask?

LBYL
Look before you leap. This coding style explicitly tests for pre-conditions before making calls or lookups. This style contrasts with the EAFP approach and is characterized by the presence of many if statements.

Link of the day: Structure and Interpretation of Computer Programs video lectures

I was so psyched when I found out that my all-time favorite course had video lectures available for download! I took the fabled Structure and Interpretation of Computer Programs course (known as 6.001 to the students) as an undergraduate (though not with the creators of the course, Abelson and Sussman). I loved how we went through all the cool stuff in CS in just one course! We covered recursion, object oriented programming, compilers, streams, and of course lambda calculus (keep in mind that this was meant to be an introductory course). My favorite project was the object-oriented adventure game.

Link of the day: Colloqium talk on community-based data management

I learned about a really interesting talk via Dave Bacon's blog. Here Raghu Ramakrishman talks about the emergence of social websites (e.g. flickr, del.icio.us, etc) and how the future of the web may lie in leveraging community input to improve data extraction. In the beginning, we had the web which was just static text and pictures. Then Alta Vista and other search engines used anchor text to improve searching. After that, Google came up with the concept of page rank. By looking at the many levels of linkage and giving more reputable sources a higher weight, you can come up with the most relevant search result. The next step in the evolution of the web may be using the direct input of users (e.g. tags) to improve data extraction.

Ramakrishman has been doing research on a very small-scale example called DBLife. It is a site that tries to extract data about academic researchers in the field of databases. If you search for a particular researcher, DBLife will attempt to generate pictures of the researchers, his/her list of publications and talks, and other information. You (the user) can then submit input on whether you think the information is accurate. So Ramakrishman's great hope is that we can develop software that is easily maintained by a community of users, that it will be easy to abstract the underlying structure of DBLife and apply it to other communities like Hollywood (e.g. HollywoodLife). In other words, one could give the software to another community without them having to look at any code.

The video of the talk is available here.

Link of the day: Paul Graham essay collection

Paul Graham has written a collection of 50+ essays on wide-ranging intellectual topics. He's made his living programming and doing seed funding, but he apparently dabbles in many other areas like art and philosophy.

I haven't had time to read all the essays, but here are a few I like: "Copy What You Like", "How To Do What You Love", and "Good and Bad Procrastination".

I find it interesting to hear what computer scientists and programmers think of difficult, creative, intellectual work.

What programming languages should a theoretical condensed matter physicist learn?

I have a question: What programming languages should a theoretical condensed matter physicist learn? I know there are the old staples of C and Fortran, but surely there are better languages for less-heavy-duty applications. I understand using C for supercomputing since computing time is the primary concern and C is optimized for efficiency. But I have heard that scripting languages like Python and Perl are easier to use for lightweight calculations. These dialects are known for emphasing programmer usability over computational efficiency.

Link of the day: Make the computer useful, not easier to use

I enjoyed this editorial article from OSNews. Now that our population getting more computer literate, it should be legitmate to scale back on the "user-friendliness" designs which may look nice to novices but are in fact counter-productive for heavy computer users. The opinions of the author seem right on.

Publish or perish

If you don't have enough papers on your CV, maybe you can try using SCIGEN, a program written by three MIT computer science graduate students. It generates computer science research papers that are superficially plausible, but complete gibberish.

Cuts in federal money towards basic research

The New York Times reports that DARPA is scaling back funding of basic computer science research.

Physicists have been complaining for the last few years as the NSF budget for basic physical science research keeps dropping. Now the computer scientists are in trouble, too.

This trend is disturbing, particularly for young scientists. How can we convince Congress to fund basic research?