For fun, I wrote a mock comment thread for a hypothetical link to a tech guru blog post. The parody comments attempt to humorously encapsulate the quirks that stand out to me when I read such a comment thread. Such quirks include things like differences in attention to detail, which posts garner the most replies, knowledge grand-standing, which comments end up at the bottom, and popular off-topic tangents. Some of it isn't unique to HN, but it was fun to include anyway.

Ignoring the rule of not explaining your jokes, here is some of the effort I put into the parody. (Don't read this before you read the actual page.)

• Some of the comments are meant to be taken verbatim, others are just meta-commentary on their content. The two styles are interspersed without any markings to distinguish them. I was afraid that giving the two types different formatting would detract from the formatting parody so hopefully it will be obvious which way they should be taken.
• All the URLs are mini-jokes. (The "reply" URLs are meta-jokes about potential replies that didn't work as well as actual comments, usually because they're the type of thought or comment that we I consider briefly before moving on. The links to HN resources are commentary about those resources.)
• The timing of the posts isn't arbitrary, and some of the positions of comments with their time ordering are mini-jokes too.
• Some of the usernames are commentary on the type of person who I think of when reading such a comment, some of them are just gibberish, and some are just juxtaposition jokes.
• All of the numbers in the page source are mini-jokes themselves.
• I kept the downvote arrows for those who crave, but have not earned, the ability to downvote comments. (Voting does nothing, obviously.)
• I used the actual HN page markup, although I now hate myself for doing so.

I hope I covered my bases for parody work. I tweaked the main logo and site title, none of the page's resources are being pulled from the original website, and there's a big "parody" banner at the top.

It's worth noting this is not the first Hacker News parody: HN front page parody.

It was fun to make, and I hope HN readers enjoy it. Here's my account on HN and the parody's submission to HN.

[Edit, 1.5 hours later]: The response on HN was fantastic - thanks guys! The comment thread is at least as funny as the parody itself, one should definitely read it after reading the parody.

I recently tried an isolation chamber, aka "float" tank, for the first time. A float tank allows the participant to come as close as possible to not experiencing any of their physical senses for a prolonged period of time (hence another name, "sensory deprivation chamber"). The the tank allows virtually no light or sound and has a shallow pool of highly dense salt water that keeps a human body afloat, permitting you to float while touching, seeing, or hearing anything. The goal is that, once inside for a while, you feel like you are disconnected from your senses while you float in nothing.

People have various motivations for using float tanks. Using them for just 40 minutes can alleviate stress, allow the body to heal injuries more efficiently, allow muscles to relax, and provide a other skin and edge case medical benefits. Some people, like me, just find the idea relaxing. Most people I talk to don't think they would enjoy the experience (and they're probably right), but I'm a very introverted person and I spend much more time inside my head than out of it. When I'm thinking I find external stimuli to be distracting, too much of it can be annoying or even tiring. I enjoy having quiet time with very little stimulation, and a float tank is the quietest session you can have. When I found commercial sensory deprivation chambers being marketed as flotation tanks I was instantly intrigued and bid my time until I had the chance to try one.

My Experience

I went to a local salon and spa, which offered a couple of float tanks among its services. Float tanks aren't too easy to find, but after some searching around it seems that most metropolises have at least one place that offers them. The float tank itself was essentially a large, covered bathtub in a small, dark room just a couple feet wider and longer than the tank itself. The procedure was to shower, enter the tank, close the hatch behind yourself, and an attendant would knock on the room's door once the time was up (taking further measures to wake you if necessary). I opted not not use background music (recommended) and to float in the nude (to avoid feeling any clothing, also recommended).

Closing the hatch behind me for the first time felt odd. I can't say I've ever stepped into a small box with no practically no light or sound. There was a sudden rush as I could almost feel the light and sound leaving my brain and I was suddenly very aware of how much of both I had been processing just before closing the hatch. The tank was virtually sound proof; I couldn't hear anything; no hallway chatter, no honking cars, no footsteps, nothing.

The Physical Aspect

The water was just one foot deep, but the extreme salt density made that plenty to keep me afloat. I extended my arms and legs to touch the sides of the tank and center myself, then pulled my limbs slowly off the side to let myself sit motionless in the middle. This was tricker than it may sound, since the slightest bit of momentum can cause drift and eventually touching the sides. I had to try a couple times to succeed.

At that point I experienced a very unique feeling. I saw nothing, heard nothing, and felt almost nothing. The water was body temperature and whenever I was motionless for an extended period of time the water feeling would subside to being minimally noticeable. But any movement or conscious thought about it would allow me to feel it. The feeling wasn't distracting by any means, but it was still a sensory connection to outside world.

One of the keys to floating is to relax as much as possible, both mentally and physically. Relaxing physically was actually a bit trickier than I had expected. I tend to be somewhat highly strung internally and I often tense muscles without realizing it. (I believe most people do this to some extent or another.) It took longer and more focus than I expected to relax all my muscles. After about 5 minutes I realized that I still had some of my facial muscles on the left side of my mouth tensed slightly, a little later I realized my right quadriceps were a little tensed, yet later I realized I had re-tensed my face, etc.

After about 20 to 30 minutes of being completely motionless it felt like my muscles were almost dead. While I knew I could move any muscle I wanted to, it felt like it would require tremendous effort to do so. At one point I twitched my foot, just for fun. It felt like there was a 10 pound force working against my foot as I twitched it. I think it may have produced some muscular benefits, since I felt several brief localized muscle spasms that were possibly tight muscles relaxing.

The sensation of lying in the tank was nothing like lying in bed. For one thing, my posture, suspended in the water on my back, let my head sit farther back than it would if I were lying on a normal hard surface. Initially it was a bizarre feeling, since it felt like my head was sitting too far back and of my control, but I got used to it. The rest of my body was held in a perfectly comfortable floating equilibrium. You can still feel a bed, the sheets feel soft, the mattress offers firm, albeit ignorable, resistance. The float tank offered no sensation or feeling. It wasn't snuggly, warm, or just kind of quiet. It felt like as close to nothing as possible. (Interestingly, tests have shown that replacing dense water with a bed does not provide the same benefits.)

The Mental Aspect

Once I was centered and relaxed I was very comfortable and felt completely alone with my thoughts. I let my mind wander for some of the time, and I let myself focus my thinking for other times. Aside from my own heartbeat, it kind of felt like time stopped.

My brain felt so unencumbered while thinking. It was like a CPU able to run a dedicated process without interruption from I/O and other processes seeking time-share. When they were focused, my thoughts were in one of those extremely laser-like grooves that come along only occasionally. I had compiled a general list of things to think about in the tank before hand, and without going into specifics they covered various ideas from my programming projects to philosophical quandaries. I was able to analyze and organize things very quickly, and had extra time to pursue other ideas that came up I felt no time pressure while thinking, I moved from step to step as I felt comfortable doing so.

My biggest motivations for using the float tank was relaxation along with my thoughts. I was not disappointed.

Other Things

Unfortunately, I did make a mistake. At some point early on I instinctively touched my face with my hand, probably to scratch an itch. At about the 15 minute mark I opened my eyes, just to see how much light there was in the tank now that my eyes were adjusted (answer: almost none, I could barely make out the walls 2 to 3 feet away). That allowed some very salty water to run into my eyes. I was doomed because I couldn't get it out of my eyes with my salt-water covered body. I tried ignoring it, but after my eyes burned for 20 seconds I gave in. I exited the tank, wiped my face off with a towel, got some water from the shower and cleaned my face and thoroughly flushed my eyes, and got back in. The problem took only a minute to fix, but it was still a disruption.

I ended up floating for a total of 1 hour 45 minutes. That's a long time to be without any physical stimulation, but I really enjoyed it. I came out of it very relaxed and feeling pretty good. I didn't even fall asleep once, although I had kind of expected to. I would do it again.

Advice to Potential Floaters

Based on my experience, here is what I would offer to anyone planning to try float session.

• Spend a minute in the beginning getting yourself positioned. - You don't want to touch any of the sides of the float tank. Unfortunately, any bit of momentum causes you to drift, and if you start drifting you likely will probably bump into a side. Any time I made any noticeable movement I extended my arms and legs to the side until they touched the sides, used them to center myself, then slowly withdrew them.
• Avoid getting salt water in your eyes. - This may seem extremely obvious, but it's worth emphasizing. Don't even get salt water on your face, and avoid opening your eyes regardless.
• Spend some time focusing on relaxing your muscles. - I think that focusing on your body too much would defeat part of the purpose of floating, but it's worth spending some time up front intentionally relaxing all your muscles. It may not be as easy as lying down and telling yourself to relax. I'd recommend spending 5 or so minutes just focusing on relaxing every muscle from your face to your toes. It's very easy to tense them unintentionally.

How do you know if you would enjoy floating? It's probably impossible to know short of actually doing it, but here's a pseudo-test to screen out some who definitely would not like it: Take a pair of the best earmuffs or headphones you can find, put them on, and lie on a bed in a dark room without a pillow for five minutes. If you feel like ending before the time is up, you would probably not enjoy it. If you find it relaxing, floating may be enjoyable for you. (I enjoy doing that sort of thing, that's why I was fairly certain I would enjoy a float tank.)

(My profile.)

I'm not exactly not their target audience, though. I received a B.S. in pure math about 3 years ago, so my math background is far beyond the current content offering of Khan Academy (which is basically U.S. high school AP).

I was motivated to try the exercises for a couple reasons. First, I hadn't really checked out Khan Academy before, despite the fact that it had generated a lot of interest on the Internet over the last couple years, I saw it referenced a lot as a math review resource, and I heard undergraduate engineering students swear by it. Second, I'm a big fan of doing consistent mental exercises. I definitely exercise my brain during the work/reading/fun cycle, but I like having some sort of consistent activity to warm up my brain. I usually prefer puzzles that require focus but don't stretch your brain. I hadn't had a set of such exercises in a while and I thought that basic math review would work well for that purpose.

I did all the exercises and watched a small handful of videos. My comments are only about the exercises, not the videos.

Doing the Exercises

I worked through the exercises by following their exercise dependency tree. It's an inter-connecting tree of all the exercises and how they relate to each other. The top/root of the tree starts with an exercise on basic one-digit addition, branches out through the rest of arithmetic, continues into geometry, algebra, etc, and then eventually collapses down to Differential Calculus. There are 37 groups, each with between about 3 and 20 individual exercises. From the zoomed out perspective you can see how all of the high-level groups relate to each other and if you zoom in you can see how the exercises within each group inter-relate, with a few of the edge exercises connecting to exercises from nearby groups.

I followed the tree very methodically from the top down, working left-to-right when a tie-breaker was needed. Exercises are presented in sets of 8 questions and you earn "proficiency" at an exercise by demonstrating sufficient skill at the exercise. You can choose to do problems just from one specific exercise or a mix-up of questions from all the exercises in the group. I chose to do just one exercise set at a time because I enjoy getting into a focused "zone" while solving problems and I was largely doing this as a brain warm-up. I'm not sure it was best, though, if I continue doing exercises I will probably use group questions.

I worked through the exercises at varying rates. In the beginning I would usually do exercises for a couple 10 minute sessions over the day, one in the morning and another one at lunch or during the mid-afternoon. After a couple weeks I enjoyed the process more, especially as I moved past the elementary exercises and into the more fun ones like probability and systems of linear equations. I had never used a math question-answer format like this before, being able to get a stream questions in an easy-to-answer format was downright fun. I found myself putting more free time into the exercises. After all, who doesn't love to do some math problems here and there? (It was a rhetorical question. The majority of you can put your hands down now.)

As expected, the exercises weren't challenging. As a math major, I was not only well-trained in mathematical thinking but I also used the principles of geometry and algebra constantly, so there was nothing there I was not familiar with. However, a handful of exercises used tricks (like converting repeating decimals into fractions) or identities (like trig identities) that didn't come to mind and prompted me to use the "I'd like a hint" button to see a solution strategy.

To make the exercises more engaging I restricted myself to not using scratch-work or a calculator whenever it was possible. This made some of the exercises more difficult and lead to various mistakes in some of exercises requiring multiple steps. It was a good challenge, though, and some of the exercises forced me to keep more objects in working memory than was comfortable. I actually had a few exercises where I constantly made mistakes due to bad mental work, typos, or hasty shortcuts (such not bothering to check whether 221/299 can be reduced by a factor of 13).

While I worked from start to finish fairly linearly, I didn't race through the material. I backed up and re-did exercises that I found particularly fun and re-did some exercises using slightly different methods. (Although I'd estimate only 1/5 of my total points came from re-doing exercises, I think they are worth fewer points once you are proficient at them.) I finished all 380 exercises in about 2 months of consistent work. Khan Academy is constantly adding content, so I plan to do future exercises they add.

The Educational Experience

Although I couldn't see the exercises from the point of view of a student with little mastery of the content, I had some thoughts on their educational value.

I think that the biggest benefit of the Khan Academy exercises is that they can supply an unlimited number of practice problems and provide immediate feedback and explanations. This is something that's hard to do in a non-computer setting. A teacher can only spend time on so many examples during class and homework doesn't give a student immediate feedback. The strength of automation is that examples are infinite and feedback is instant and I think they leveraged both of those aspects well.

The tree of interconnected math concepts was well done. I wish I knew of a similar detailed tree for higher math topics. A very select few of the tree relationships did seem backwards, where I had a hard time believing that the a latter exercise offered any challenge a former exercise didn't. (I now wish I had saved examples, but I didn't.)

The exercises did a good job of focusing on one thing at a time. When learning any new skill it usually helps to isolate it in a familiar environment and focus on the unfamiliar part, so by focusing only on one idea per exercise these exercises would likely be a very helpful learning aid for someone who is trying to improve a specific weak point in their math skills. Combined with the tree as a whole, it would probably be easy to backtrack from an exercise full of confusing ideas to the lowest point of weakness and then work on refining the relevant skills from the bottom up. I can see a coach being able to do this easily for a student, or a motivated student doing it them self.

The system uses some clever math and machine learning to estimate when students are have achieved proficiency in an exercise (but all the student sees is a progress bar). Not knowing this when I began, it was still immediately clear that solving the first several problems in a set quickly and accurately earned proficiency but a couple of mistakes required numerous correct problems to earn proficiency. The system was well-tailored and let an initial burst of obvious competence pass quickly, while not passing mostly-right-but-still-struggling performance.

The "I'd like a hint" button was not the learning resource I hoped it would be. It offered step-by-step solutions (allowing the user to reveal one step of the solution at a time) but the steps were very formulaic without much explanation. For example, a typical step would read like "next we take the X and blah it with the Y", but with no mention of why this was necessary or possible. The exercises definitely were not teaching resources by themselves. Each problem did have a link to the associated teaching video, though, so they weren't designed to stand-alone.

Here are some of exercises that I thought were particularly interesting:

• The group of triangle proofs. This set allows for a unique chance to walk through geometry proofs step by step. The way they set it up, each step was verified as you input it, so it was pretty much impossible to get it wrong. The geometry diagrams would light up the relevant portions each time you input a new step or hovered over an old step, so I think it would give nice feedback for students who have a harder time "seeing" the geometrical aspects of what they're doing.
• The exercise on derivative intuition. A simple introductory concept that was well-illustrated. I'd recommend all beginning calculus students do this exercise. There were a couple other exercises oriented at building "intuition" for a topic. I really liked this, since I'm in favor of teaching intuitive concepts. (These should be replaced by rigor later on, of course, but many students, such as myself, benefit from these sorts of "gimme a clue or view as to what's happening here" explanations.)
• The group of logical reasoning. A quick review of the basic steps of logic and the relevant syntax. This is typically covered in the first few weeks of a first-year introduction to math college course for math or computer science students. I'd recommend everyone in such a class go through the exercises to help cement those ideas.

Unfortunately, some of the exercises lacked diversity in the problem sets. As examples, when reducing fractions there were never common factors larger than 13 (possibly to keep it mentally doable, though), polynomials often seemed to be picked out of only a few sets of styles, and there were a limited number of triangle ratios used. Some of the problem sets were constrained by the intent of the problem, such as trying to pick a problem that resulted in clean answers, and those constraints left only a handful of possible starting values. Those were understandable, but some of them didn't have any such constraints. With problems that didn't vary much, a student could unconsciously get into a rote system of "take the number there, blah it against that number, blah the result and write it down". The entire point of Khan Academy is self-study so I'm not suggesting it needs to take anti-cheating measures, but there were some problems sets that seemed unnecessarily bland considering the pool of potential problems. With some of those exercises I would actually consistently get the exact same question twice within a span of eight questions.

There weren't many exercises on the deeper/more challenging topics. The practice exercises don't cover as much depth as the video lessons do and I would like to see more of the topics fleshed out. For example, there are very few Linear Algebra exercises yet many Linear Algebra videos. Calculus is limited to Differential Calculus only. Even in Algebra they covered a lot of specific skills, but left out some worthwhile ones. They're consistently adding new exercises, though, (they've added 13 exercises in the past three months alone) so hopefully these areas will be expended in the future.

Miscellaneous Observations

On grading:

• You can achieve proficiency at any point during the exercise set, not just the end. You can keep an eye on the green star in the left-hand bar to see when you get it. Once achieved it can't be lost, although it can be recommended for review.
• I could almost always pass a problem set in four questions if I answered them correctly and within their "fast" time slot.
• The most efficient strategy that I found for passing a problem set was to get the first five questions right with three of them done at "fast" speed. Focusing on speed for all four would encourage hasty mistakes. Better to let the easy ones be fast and give them all good attention.
• Once a mistake was made, it would take at least 6, usually more, correct answers to pass the set. Wrong answers were weighted much more negatively than slow answers.
• A mistake seems to set your progress bar for the exercise down to at most half-filled.

On answers:

• Their scratch pad interface is a nice idea, but it's impractical to draw/write things with the mouse if you need to be fast. I just used a pen and sticky notes when I wanted scratch paper.
• Allowable answer formats varied somewhat inconsistently. Fractions almost always had to be in reduced form, but not always, rounding varied from 0 to two decimal places, and these were across exercises that had nothing to do with reducing fractions or rounding decimals. It was worth checking their little "acceptable format" indicator to see what types of input was allowed.
• The answer parsing was reasonably flexible. For example, when entering multiples of pi you could write "5pi" or "5 pi". It was flexible enough to not be annoying.

Final Thoughts

The Khan Academy exercises are a good source of practice material. They are not, however, a learning resource and do not replace real homework assignments and feedback by teachers. But I think they're solid supplementary material. I also think they would help someone who was once comfortable with material and wants to re-learn it.

I think Khan Academy did a good job making the exercise format pain-free and enjoyable.

It's no wonder why the figure doesn't balance. It connects to the stand at one point, the trailing foot, and from the face-on view the entire 8 inch figure is forward (toward the viewer) and left of this anchor point. The figure's center of gravity is nowhere near the anchor to the stand and the anchor connection is not very tight, so the foot pulls loose and the figure falls easily. The foot seems to do a half decent job of preventing the figure from falling left (from the face-on view), but it offers very little support against falling face-forward. My figure will fit firmly into place initially, but the weight of the figure causes the foot to start sliding out of place within 5 minutes and it will fall forward within an hour. Unfortunately, there is just no way for me to set it up solely on its base. Here are some photos of my figure about 10 minutes after being set up:

Making an Extra Support

I knew about the stability problem before getting the figure, but I was fairly sure I could add some support to fix the issue. I really liked the figure and never enjoy storing figures in boxes.

The key to fixing the stability is that the figure's left leg is nearly parallel to ground and passes pretty close to the figure's center of gravity, making it an great place to wedge an additional support. Placing a pole carefully underneath the left leg can alleviate both the figure's forward and left tilt. I went to a craft store and got

• a 1/8" thick wood dowel
• a 3/16" thick foam sheet
• black matte acrylic paint

and made a make-shift stand to support the left leg for less than $5. Making the support pole was simple, I:

1. cut a 3 1/2" section of the dowel
2. glued a small 1/4" foam square to both ends of the pole
3. painted the dowel and the sides of the foam
4. placed the support pole under the left leg, about 1/2" from the tip of the left knee angled toward the figure slightly

The result wasn't too bad for someone whose entire "crafty" experience to date had consisted of, well, this. Here's the final result.

Details and Comments

The height of the support pole was very critical and it took me a couple attempts to get it right. Too short and it allowed the figure to lean forward, but too tall and it pushed the figure backwards. Letting it lean a little bit wasn't a bad thing, I just didn't want the pole to be able to slip after a long period of time. I chose the thickest foam I found at the store because that allowed for the height to adjust somewhat dynamically to the weight the figure placed on it, alleviating the need to cut the pole exactly correctly. One helpful thing about the leg is that it isn't perfectly parallel to the ground, it's height varies by about 1/8" from knee to ankle, so you can push a support underneath starting from the knee and slide it until it hits a good firm point. The foam and leg angle both alleviate some of the need to cut the pole to the right height.

That said, I did find that the pole needed to be placed precisely. I found that about 1/2" from the tip of the left knee slightly angled toward the figure provided the best support against the front and the side. It took some trial and error to get a combination of the right pole length and the right brace point on the leg that was thoroughly satisfying, although it was easy to find one that did most of the job.

I used foam on both ends of the pole to avoid scratching the figure or the stand and to provide stability at the base. The deeper foam allowed the figure's leg to form an indentation that helped hold it in place. When cut to the right height (with some tension on the pole by the figure), the pole stood somewhat firmly in place. I can pick the figure up and move it gently with dislodging the support pole. The foam didn't keep paint on well, so starting with black foam was a good idea.

I actually bought three different dowel sizes and made various samples to see which size I liked better. The stoutest one, 1/4" thick, definitely felt the sturdiest and seemed the easiest to position such that it held the figure still. But it looked too distracting and out of place, probably because it was about as thick as her legs. And in retrospect, I should have sanded the dowel before painting it for a smoother look up close.

Also, I made multiple supports. I may lose or break one some day and I probably don't want to repeat the process. There were plenty of left over materials for it, since one pole and one foam sheet could make almost a dozen.

Conclusion

This figure may not have a chance at supporting itself, but you don't have to let it sit in a box. Spend $5 and prop it up. It may not look perfect, but it looks better than it would in a box.

Mikuru a la Atelier-Sai is standing stably. Where is your god now?

Oh, yeah, on the same shelf.

The project was set up to address some shortcomings in the popular math teaching of the time and the difficulties that math education faced. One of the biggest problems in teaching mathematics, particularly at the primary education levels, is that it is difficult to convey good understanding of mathematics, and it is also difficult to learn if the student has gotten a good understanding or if they are simply memorizing and repeating steps. Much of the usefulness of math stems from understanding what is happening and why it is happening, and a student who doesn't understand that is missing out on the majority of what learning math has to offer. So there has been a lot of debate and experimentation about the "right" way to teach math and what styles are or are not effective.

I liked a lot of what the author had to say about teaching math, and I think a lot of it applies to learning and teaching in general. A lot of it resonated with my inner mathematician (I'm a math major) and reminded me of ways that I like to learn and ways that I think are effective in tutoring other people in math. (Teaching math is a subject I'm very interested in right now, as I think about starting to teach my children math in the next few years.)

Here are some interesting quotes from the article, although I recommend reading the whole thing. I think that a lot of it applies to most learning topics in most learning scenarios, not just math in a class room. (All emphasis in quotes is preserved.)

No child can be expected to "discover" historical accidents or what is in the teacher's mind. Only after a task is clearly understood can the creativity and inventiveness of children take over the agenda. The correct understanding of the [Madison] project's approach might better have been stated as, "If, at this moment in the lesson, what is needed is an intellectual breakthrough of some sort, please wait and let a student take the first step." If you wait, someone will.

- pg. 637

I like this point because I'm very convinced that we both understand and remember things better when we make the connections ourselves. It's certainly possible to feed people answers prematurely, either for the sake of keeping up a pace or because we're too excited ourselves and we want to share our knowledge, and in doing so we hinder the listener's ability to play with key pieces of the puzzle themselves. Providing an answer too soon can deny the listener a "light bulb" moment, which is key for understanding ideas.

When I'm explaining an idea to somebody, perhaps one that itself involves several different ideas, there will inevitably be a time where a few ideas come together and the listener doesn't instantly make sense of everything. (This arises frequently, almost whenever a relatively deep conversation has gone on for 10 or so minutes.) They're not dumb, just taking a moment to sift through things. When I feel like this has happened, I usually like to just go quiet for a moment and let the other person think. Even if they ask a question, I may just ignore it for a little bit (politely, of course, perhaps with a little "hm..." and a pregnant pause). The idea will make more sense to them and be more useful if they put it together in their own head, and I'm usually certain that nothing I can say will substitute for their own effort.

Besides demonstrating the assimilation paradigm, the preceding example shows another way in which the project provided help to students: the use of clear, unambiguous language and notations. We had been aware that David Page was using small raised symbols for positive and negative, as in ⁺2 or ^-3, and carefully using the words positive and negative when that was the idea (as opposed to plus and minus in the situation where those meanings were intended and nonraised symbols were used). We had not chosen to follow his example in this usage until some seventh graders, asked to invent a sensible way to add, subtract, and multiply signed numbers, responded that

(+2) x (-3)

should be equal to 3. How come? "Because two times three is six, and then you have to subtract three." We converted immediately to Page's notation, and this difficulty disappeared.

Probably, if we were telling the students what to do, alternative interpretations such as the one above might not arise --or, at least, might not see the light of day and might not come to be noticed. But if the children themselves are building up the mathematics, if they are inventing ways to proceed, then exactly how they are thinking about the ideas becomes directly relevant. In traditional "teaching by telling," the question of which notation is used may be seen as unimportant.

- pg. 640

When a teacher is emphasizing a conceptual understanding of math, clear notation is necessary. This example looks like a very interesting case where seemingly simple notation obscured the math problem. The student tried to derive a mathematical meaning from the notation, but the notation was imperfect. It was a simple example, and the author points out that this is easily solved by just telling the student what to do (they will eventually memorize the rules through repeated practice), but it illustrates how notation can be an artificially imposed difficulty.

I think that good notation should distinguish between what something is and what actions are happening. There is probably a more formal way of expressing that thought, but that's my basic idea. In the example above, the student confused what quantity existed (negative 3) for what action needed to be done (subtracting 3). Obviously, the two ideas are closely related, but technically the notation (aka, "-3") was ambiguous by itself, the intent had to be inferred from the context, and the interpretation mattered. (This last point is important because, particularly in higher math, ambiguous notation may be permitted when various interpretations/definitions are equivalent, so the reader is free to choose the interpretation they like best.) Such seemingly simple things can, at a minimum, create confusion, and once the student is confused their progress will be slowed down. I don't really see a need for such ambiguous notation, and in an ideal system we wouldn't have it. Since notation is mostly established by popular tradition, it's no surprise that odd quirks like this exist.

The essay closed with:

By imagining that mathematics means knowing when to invert and multiply, we have come to trivialize mathematics, knowledge itself, and even the nature of human thought. Anyone who listens carefully to what children really think about the world will know otherwise.

-pg 645

Another re-iteratation of the thesis: Students, even young ones, can understand ideas and find motivations for those ideas on their own given sufficient guidance. Rote memorization of using tools doesn't teach the same skills.

Math can be a difficult subject to teach. One reason it's hard is because a good understanding of it is generally a very "internal" feeling. Mere words don't really convey what a person understands about math, much like words fail when trying to describe a piece of music. Differences of viewpoints, preferred approaches, and mental strengths between teachers and students can raise barriers when trying to take knowledge from the teacher's head and get it into the student's head. But it's not an impossible task, and there are definitely some techniques have tend to produce better success rates than others. Good teaching will allow the student to build math understanding in their own head, instead of cramming a pre-defined structure in there. The Madison project tried to accomplish this, and it seems like they had a lot of good ideas that students of any generation would benefit from.

Making a device image is not difficult. Unix-based systems have long had the "dd" utility. For Windows, Vista introduced a built-in utility for creating image backups. There are also many third-party software applications like Partition Magic provide this sort of functionality.

The biggest disadvantage of a raw device image is that space unused by the filesystem is still saved. If a 20 GB file system only has 4 GB of data on it, all 20 GB will still be saved in the image. If there are many images that need to be stored (such as images from multiple devices, or images from multiple points in time from the same device) this isn't very space efficient. Users with space concerns often compress the images, but the unused space often contains normal data since it is likely that it was used at least once in the past as files were created, deleted, and moved. So, unfortunately, the unused portion of the filesystem usually compresses only a little better than the used portion. Since the contents of the unused portion of the filesystem are often arbitrary, it is undesirable to have such high overhead for storing then.

(Note that filesystem based images do not have this problem. But these are more complicated and do not work on full disks, which is necessary to preserve the MBR, partition boundaries, etc.)

However, if the unused space of the file system is filled with zeros before compression then the image containing the filesystem is compressed the unused space will be trivially compressed to almost nothing. Compressing 4 GB of data is practically the same as compressing 4 GB of data and 16 GB of zeros.

Implementation

Zeroing out unused filesystem space is simple. First mount the file system to be imaged, then create a temporary file on the file system and fill this file with zeros until either a) the file system runs out of space, or b) the file system's maximum file size limit is reached. In the case of the latter, continue creating and filling temporary files until the file system is full. Delete all the temporary files once you are finished. At this point practically all unused space has been allocated for one of the zero-filled files that was created, and thus has had physical zeros written to it.

On a Unix/Linux system, the dd utility makes this easy. The following command:

reads from virtual device /dev/zero which supplies and unlimited quantity of zeros and writes the zeros to an output file, automatically terminating when the file can not grow anymore. The argument bs=16M is included to speed up the operation, since by default dd will read and write in chunks of 512 bytes and the constant switching between read and write operations in very inefficient and can make the process take tens of times longer.

I've written a quick platform independent C++ program that will create files full of zeros until the files are as large as they can grow and no more files can be created. While "dd" is certainly more convenient, this should work on Windows systems and on filesystems that don't support sufficiently large files. Execute this program with one argument pointing to a path on the partition you want to zero-ize, no argument will default to the current working path.

Obviously, it may not be a good idea to perform this zero-ization operation on a filesystem that is in active use. After the filesystem is filled, but before the temporary file(s) are deleted, there will be almost no room to write data to disk. While this will be a very small window of time, any applications (including the operating system) that need to write to disk will possibly be denied the ability to do so and since it is rare for applications to be denied write access to open file handles, their behavior may be unpredictable. In the majority of my own personal tests I have not encountered a problem, but a couple times the system froze or slowed down noticeably until I deleted the temporary files. Just be careful, filling a live filesystem to the brim is not standard good practice.

An astute reader may note two technical issues with this method of filling the filesystem with zeroed files:

1. Filling a file with zeros does not guarantee that all unused space will be used as partially-used sectors will not have the unused portion zeroed out. But these sectors will represent a negligible percentage of the total disk. They typically occur as the last sector of a file that isn't an integral multiple of the sector size. A typical Windows 7 install will probably have less than 500,000 files, and 500,000 sectors means about 125 MB of space on average.
2. Writing to and then deleting a file does not guarantee the file to be written to disk due to both the OS/filesystem and disk-level caches. Cached data that never gets written to disk will be abandoned when the file is deleted, and the space on disk it was supposed to zero will be left untouched. But only a small portion of the data to be written will be cache-able by the OS and the disk. Home disks rarely have larger than 32 MB caches, and the OS/filesystem will likely cache at most a gigabyte or so. This has the potential to be non-negligible size, but even an aggressive cache would have a small total impact. Since so much is being written to disk, the caches will overflow quickly and be forced to write most of it to disk.

A fast compression scheme is probably better than a good compression scheme, unless time is not important. It's likely that the majority of used space will be binary data (executables, already-compressed media formats, etc) and will yield very low compression no matter how hard you try. Any simple compression method, like GZIP, will be able to make efficient use of the sections of 0s and not waste too much time compressing the rest of the image.

Concluding Notes

The difference in compressed image between the original device contents and the zero-ized device contents will depend on the filesystem(s) involved, how full they are, how much data has been added and deleted, how long it's been since the last time the device(s) were wiped, and similar factors. However, since this is a fairly easy procedure, it wouldn't hurt to try this if saving device image backup space is helpful. In my personal experience, I've seen the size of the compressed image as much as halved. On a device where not much data is copied, this may only need to be applied once or twice in the lifetime of the device to keep the majority of the unused space zeroed.

Somewhat obviously, this technique should not be used on a device that requires forensic analysis, as sectors unclaimed by the filesystem may still have contents that need to be examined.

I strongly oppose these bills. I do sympathize with the fact that multimedia companies have legal and moral rights to exercise over their content and that these rights are violated by mass-piracy, but these bills take far too drastic action to protect said rights. I won't re-iterate all the reasons why these bills are bad, even in spite of recent tamer modifications.

So I wrote my three congressmen today to voice my opposition. I'd like to share the letter publicly, as a wider proclamation of my position on this issue and hopefully as an aid for anyone writing their congressmen on a political issue. It's not a master-piece, but I thought it might be helpful. I'll explain some of the reasoning and structure below. Here it is:

To the Honorable [insert congressman's full name],

I would like to add my voice of support to the millions of people who oppose [SOPA/PIPA].

I am sympathetic to the motivation of the bill. I understand that multimedia companies have proper motivation to protect their intellectual property. I support their moral and legal rights to own their content.

However, I do not believe that their efforts to protect their property should be at the expense of humanity's convenience and technological development. We the people do not exist to listen to music, we listen to music while we live our lives. Similarly, technology does not exist to play music, it exists to enable us to do what we want, some of which is to listen to music. Legislation like [SOPA/PIPA] takes a multimedia-centered viewpoint of the universe, assuming that we should hinder productivity and change the dynamics of an entire industry just to protect the convenience of one sector of that industry.

The multimedia industry has a history of resisting technological development due to their reluctance to change business models. They tried to legally combat cassette tapes, video tapes, and CDs under the pretense of fighting piracy that would hurt them. Yet those very mediums enabled them to distribute their content in better, more widely-reaching ways than before. They resist change, yet change and progress is what technology, and humanity itself, is about. Every sector of an industry faces critical changes over time, and while it can be difficult for them to adjust they should not seek legal aid pass their difficulties onto us, the common citizen. This is a capitalist society, the multimedia sector needs to adjust, not be pampered.

My request, congressman, is that your position be to protect the progress of the general public. I support the multimedia sector's desire to protect its content - once again, I sympathize with their motivation - but not at the expense of all our development. Their history and the current [SOPA/PIPA] legislation show that they are not seeking to provide us with multimedia enjoyment while we live our lives, they prefer to limit our lives to fit their existing business models.

Thank you for your time. For what it's worth, I voted for you. To protect me.

--Brad Conte

Some thoughts on this letter, in no particular order:

• I used SOPA or PIPA where appropriate for the recipient. One bill is in one house, the other bill in the other house. Writing a blanket statement like "SOPA and PIPA", or worse yet just the popular one "SOPA", sounds more like a form letter. Who wants to get a letter that mentioning a bill that they can't even vote on?
• I wanted to paint a big picture perspective. 1) I gave a very quick history of similar actions in the industry and their outcomes. 2) I noted that the multimedia industry is just a sub-sector of the larger industry that this bill effects. 3) I remembered international concerns; the U.S. is the country most impacted immediately, but this likely has implications for the whole world, hence I slipped in the word "humanity" a couple times. The goal wasn't to be dramatic, but to always remind them of how wide-reaching the implication would be. The overall point was that this was far too invasive an action to protect one specific sector.
• As a general rule for opinions and debates, you should always separate general intent from specific implementation and you should separate analysis of the consequences from debate over what the consequences are. If you want to get your point across to someone, decide which perspective you're arguing and make it clear, too many conversations are completely wasted due to a missing of the minds on those simple topics and jumping confusingly between perspectives. In my letter, I opposed this implementation of copyright and laid out the consequences for what happened. If the congressmen doesn't agree that the assessments that I asserted, that's the subject for a separate, much longer e-mail. I would suggest that it's best to go for lots of detail or very little, because few things are as weak as an argument that uses just a few details strewn about.
• It's easy to read - about 370 words and about 2/3 of a printed page, so easily readable in a few minutes. There are 5 paragraphs (the closing line isn't really a paragraph), but only 3 have the bulk of the content; it looks very digestible at a quick glance. That's all you need to give a summary of a position. This makes it easily skim-able: a) while each paragraph is unique, you could omit any one and get the majority of the argument, b) you could read the first sentence of each paragraph and still get the message (that's actually a good rule in general), and c) you could read the first and last paragraphs and understand it. Given the popularity of this topic, it's likely that if the congressman is reading my letter, it is just one of hundreds on the same topic.
• I emphasized what impact my position would have on the opponents (the multimedia industry). Actually, I somewhat trivialized their position as simply being for "convenience". It isn't a matter of preserving the multimedia companies, it's simply about them finding and adjusting to a new business model, just like they've done several times in the past. It's important to know what's at stake in a situation like this, and I wanted to contrast humanity's technological stifling against their convenient business model. (In retrospect, trivializing it as "convenience" was a pretty strong statement to make without supporting evidence, maybe it should've been a little tamer.)
• Similar to the above, the secondary focus of the letter was on priorities. "We the people" are not befitted in general by this bill. I said and implied that a couple of times.
• The tone is unemotional, yet a little grave. It's a serious subject but it won't kill my grandmother, so there's no need to sound like it would.
• The closing line ("...I voted for you. To protect me.") might come off a bit snarky, but it conveys a valid point. Congressmen are put in place by "the people" and those people are who will lose (and lose very badly) should the legislation pass. Obviously there are times where a congressmen needs to put aside the individual or short-term benefits of each person for the big picture, but I wanted to remind them that my hope is that their voice will do its best to echo ours. If I would be strongly opposed to the bill, that should count for something. I didn't make any threats (ie, "I won't vote for you if you don't oppose this"), I just reminded them of established fact. And, for what it's worth, I did actually vote for the congressmen I wrote to. (I shouldn't have to point that out, but it's an easy statement to lie about and I've seen it done elsewhere.)

Hopefully the letters will do some good. (Update: For what it's worth, I only received back form replies from a couple of the congressmen.)

But that only works if stdin or stdout are switching before the process is launched. What if we have a pre-existing process that we would like to change a file handles for, but we would like to avoid restarting the process? For example, say you have a cron script execute sudo my_command from an environment where you can't provide input (perhaps you meant to use gksudo instead). You might be able to kill the sudo process, but perhaps when sudo exits the script will proceed with undesirable results. You could kill the script too, but assume that you very badly don't want to abort the script in a semi-completed state. (Obviously a well-written script shouldn't have this sort of behavior, but the assumption is that we are in an unusual situation.) The ideal solution would be to redirect input into the hanging sudo process allowing it to succeed and your script to continue.

Thankfully, we can perform redirection on existing processes by explicitly manipulating the existing file descriptors. The method for doing so is fairly straight forward:

1. Determine which file descriptor you need to change.
2. Attach to the target process via gdb.
3. Create a file (to redirect output) or named pipe (to redirect input).
4. Use gdb to point the desired file descriptor to the file or pipe.
5. If applicable, send the necessary content through the pipe.

In terminal A, find the PID of the process, call it TARGET_PID. First, list the target's existing file descriptors:

When we are done we will double check this list to ensure we made the changes we wanted to.

Now you need to determine which file descriptor (hereon "FD") you want to change. Remember, we can only manipulate existing FDs, not add new ones. (For those who don't know: FD 0 is stdin (standard input), FD 1 is stdout (standard output), FD 2 is stderr (standard error output). These are the the base FDs that every process will have, your target process may or may not have more.) Examples:

• To change the input for a typical terminal program you likely need to to change stdin.
• To change output file X to a different file Y, you need to find which FD on the list is linked to X.
• For sudo, to change the input that accepts the user password you actually need to change FD 4, which should point to /dev/tty or something similar.

We'll call the the FD number that you want to change TARGET_FD.

For using a named pipe: First create the pipe using

We'll call this path TARGET_FILE. Then provide input to the pipe, or else gdb will not be able to open it in a later step. Provide the content by, for example, echo MyContent > TARGET_FILE from a separate terminal or as a backgrounded process. MyContent should be the content you want to send the process.

For using a normal file: Create an output file called TARGET_FILE.

Attach gdb to the process:

Within gdb, close the file descriptor using the close() system call:

The right-hand side of the output is the return value of the call we just executed. A value of 0 means that all went well.

Now create an FD using the open() system call. This must be done after "close()", because file descriptors are issued sequentially from the lowest unused non-negative integer and we are making use of the fact that once we delete TARGET_FD it is now the lowest unused file descriptor, so the next one created will use the same number.

If the right-hand side number is equal to TARGET_FD, that means we just successfully created an FD and it got the same FD that we just closed, which is perfect. Remember, if you are using a named pipe, this step may (will?) hang if there is no output going into the named pipe.

Now quit gdb:

At this point, you should be done. If you are redirecting output, the redirection should be under way. If you are redirecting input, the first input should be consumed from the pipe and you can continue to provide input as necessary by sending it into the pipe; when you are done simply delete the pipe using rm.

We can verify hat we were successful by checking the target process's FDs. Run ls -l /proc/TARGET_PID/fd/ again and compare the output against the output from the first time. If all went well then TARGET_FD should be changed to point at TARGET_FILE.

FoxyProxy is a popular Firefox extension that enables users to, setup, easily manage, and quickly switch between multiple proxy configurations. One of the most common uses of a proxy server is for security/privacy. By establishing an encrypted connection (usually via SSH) with a proxy server on a trusted network, you can have your web traffic go through an encrypted "pipe" to that server and have that server send and receive web requests on your behalf, relaying data to and from you only through that pipe. By doing this you eliminate the risk that someone on your current network could see your HTTP traffic. Maybe you don't trust other clients on the network, maybe you don't trust the gateway, it doesn't matter -- your HTTP(S) traffic is encrypted and shielded from prying eyes. (Readers unfamiliar with the concept of using HTTP proxies through SSH tunnels are encouraged to research the matter, there are many well-written tutorials available.)

There are many other popular uses of proxy servers, but the application of encrypted web traffic is of concern in this case for the following reason: A key problem that arises when using web proxy servers is the issue of handling DNS requests. DNS does not go through the HTTP protocol, so even if HTTP is being forwarded to a proxy the DNS requests may not be. If DNS requests are sent out over the network like normal then eavesdroppers can still read them. So although the actual traffic may be encrypted, the DNS queries behave normally and may cause the same problems that using an encrypted tunnel was designed to avoid in the first place. A situation in which HTTP traffic is encrypted but DNS is not is referred to as "DNS leaking". When using a proxy for the benefit of security or privacy, DNS leaking may be just as bad as non-encrypted traffic.

Solving the DNS leaking problem is simple. One type of proxy, SOCKS5, can forward DNS requests as well as HTTP(S) data. A user simply needs to tell their browser to use the SOCKS5 proxy for both HTTP(S) and DNS and then both will be routed through the encrypted stream, allowing the user to surf the web with greatly strengthened security and privacy.

However, Firefox users who use FoxyProxy at the moment will encounter a problem when using DNS forwarding to a SOCKS5 proxy. When using FoxyProxy, DNS leaking occurs even when it is configured not to, which has made many users very upset. Initially many people thought the problem was with Firefox 3.5, but others confirmed it was only present with FoxyProxy installed. Unfortunately, however, not everyone is convinced that this is FoxyProxy-related behavior and I have not found anyone who has presented a solution yet. I plan to do both.

This is the basic setup for my tests:

• I set up an SSH server.
• I established an SSH connection and used the built-in SOCKS5 functionality of the SSH server daemon:$ ssh username@myserver -D localhost:8080(For the non-SSH inclined: This command forwarded all traffic my client sends to itself on port 8080 through the SSH connection to the SSH server, which then acts as a SOCKS5 proxy and sends the data on to the destination.)
• I used Wireshark to monitor all packets, specifically DNS requests, sent or received my network's interface. Note that DNS requests tunneled over the SSH connection to the SOCKS5 proxy are not visible to the packet sniffer.
• I monitored my Firefox configuration in about:config. (All network proxy-related settings are under the filter network.proxy.)
• I used Firefox v3.5.5 and FoxyProxy v2.14.

Using this I was able to monitor all DNS requests while I experimented with Firefox and FoxyProxy using a SOCKS5 proxy. I did a base test with no proxy configuration, a test using Firefox's included proxy management, and a test using Foxyproxy for proxy management.

Using no proxy

Starting with a default configuration (SSH SOCKS connection established but no proxy settings configured to use it) I visited several websites such as google.com, yahoo.com, and schneier.com. This was the simple base test.

I checked showmyip.com to get my IP address.

The relevant about:config settings:

Via Wireshark I watched as the websites generated normal DNS requests over the standard network.

Using Firefox to configure proxy settings

I restarted Firefox to avoid any cached DNS entries. Then, without FoxyProxy installed, I setup my SOCKS5 proxy. (Note that FoxyProxy replaces the standard Firefox proxy editor, so it is impossible to not use FoxyProxy when it is installed.)

Under Firefox's Preferences/Tools (depending on your operating system) I went to the "Advanced" tab, "Network" sub-tab, and opened "Settings". I chose "Manual proxy configuration" and entered "localhost" for the SOCKS Host and "8080" for the port.

Unfortunately, Firefox v3.5 does not support a GUI method of enabling DNS SOCKS5 proxying, so I had to manually go to about:config and enable it by setting network.proxy.socks_remote_dns to "true".

I checked showmyip.com to ensure that my IP address displayed as coming from the server and not my client. It did show as coming from the server, so Firefox was using the proxy.

The final about:config settings were:

I visited the same websites. Via Wireshark, I did not see any DNS requests sent over the standard network. Firefox channeled both the HTTP and DNS data through the SSH tunnel perfectly.

Using FoxyProxy to configure proxy settings

I reset all the about:config settings back to their defaults. Then I installed FoxyProxy Standard v2.14. I went to FoxyProxy's options and, under the "Proxies" tab, created a new proxy entry whch I named "SSH SOCKS5". I set it to connect to "localhost" on port 8080. As well, I check-marked the "SOCKS proxy?" box and selected "SOCKS v5". I went to the "Global Options" tab and checked the box "Use SOCKS proxy for DNS lookups". To let this take effect, I had to restart Firefox.

When Firefox had restarted, I went to the Tools > FoxyProxy menu and selected to "Use proxy SSH SOCKS5 for all URLS". I checked showmyip.com to ensure that my IP address displayed as coming from the server and not my client. It did show as coming from the server, so Firefox was using the proxy.

I checked about:config:

The configuration was the same as the default, so apparently FoxyProxy does not adjust about:config to do its work.

Watching the DNS requests via Wireshark, I watched as all the website visits generated DNS requests over the normal network. Complete and thorough DNS leaking. And I would like to emphasize that I had selected "Use SOCKS proxy for DNS lookups", which is FoxyProxy's option to address the DNS leaking issue.

Fixing DNS leaking

There was no question about it, FoxyProxy caused the DNS leaking in my test. I wanted to solve the problem so I fiddled with about:config.

In about:config I manually set network.proxy.type to 1. I verified my IP address was from the server via showmyip.com.

The new about:config:

I watched for DNS requests again via Wireshark. I saw none. It seemed that just manually setting network.proxy.type to 1 fixed the FoxyProxy DNS leaking problem.

I also tried other about:config settings, such as manually changing network.proxy.socks_remote_dns to "true", but that didn't work. The above was the only change in about:config that I found that fixed the problem.

Summary

I repeated the results above three times in different orders on different computers on both Linux and Windows to ensure I made no configuration mistakes and to verify that the behavior was consistent and cross-platform. All the tests yielded the same results. Here is the final summary:

• Firefox v3.5 does not suffer from DNS leaking by itself.
• DNS leaking occurs when FoxyProxy is managing the proxies.
• FoxyProxy does not suffer from DNS leaking when network.proxy.type is manually set to 1.

It is obvious that FoxyProxy does not adjust about:config in order to configure proxy settings, but I do not know why. Many Firefox extensions adjust about:config in order to accomplish their goals and I know of no reason they should not. It's possible that FoxyProxy has not had a need to do so before, but in light of this serious problem that may need to change. The quickest/simplest solution for FoxyProxy may to set network.proxy.type to 1 if the currently enabled proxy is SOCKS5 and if the global options for FoxyProxy (or the about:config for Firefox) are set to enable DNS forwarding.

However, although this seems to indicate that FoxyProxy has made a mistake, I don't know that FoxyProxy is the party at fault. Clearly FoxyProxy does not have to alter about:config in order to change the other proxy settings, so why must network.proxy.type be set in about:config in order for DNS forwarding to work? Note that network.proxy.type isn't related to DNS forwarding, it just specifies which type of proxy is enabled. For all I know someone implemented a hack in Firefox that checks about:config when it shouldn't. Of course, I don't know that and I don't know if this is expected behavior from Firefox or not. It could be that FoxyProxy isn't setting whatever hidden configuration for DNS forwarding that exists on the same plane as the other invisible proxy settings it uses. Or maybe FoxyProxy is relying on an unreliable hack in order to avoid changing about:config. I don't know about any of that. What I do know is that Firefox by itself does not have this DNS leaking problem, FoxyProxy does, and a simple solution exists.

Again, I am certainly not the first person to note this problem, but a) I have seen many people blame Firefox for this bug, and b) I have not yet seen anyone else mention the solution that I noted above.

I leave it to someone with more time and knowledge about these software projects to determine which project should have which bug report filed. This needs to be fixed permanently.

Interact with the X clipboard

Before I discovered xclip, one of the most annoying things about being in a terminal was my lack of access to the X clipboard. Some terminal/shell combinations work well with a standard desktop environment, but "highlight-and-middle-click" a) isn't always feasible, and b) doesn't always work. Thankfully, xclip makes it easier.

xclip can output from and write to the clipboard from the standard input. The "-i" and "-o" arguments tell xclip whether you are inputting or outputting clipboard contents, respectively.

Example:

You may now "Control-V" paste that path where ever you choose. Another example:

This will download the file from the URL that is in the clipboard. I have found that "pasting" the contents of xclip into the shell using backticks (aka, `) a very convenient work-flow. The result of `xclip -o` is basically having the code right were you would have pasted it in the shell.

You can use xclip to read from and write to the different X clipboards, which allows you to interact with the clipboards for pasting via middle-click or Control-V. The "middle-click" clipboard is selected with the arguments -selection primary and the "Control-V" clipboard is selected with the arguments -selection clipboard.

I might suggest aliasing "xclip" to xclip -clipboard X, where X is your preferred clipboard to operate on.

Use "head" and "tail" more powerfully

You probably know how to use "head" to extract the first N lines from a file and "tail" to extract the last N lines of a file. While this is useful, it's often just as useful to extract the complement of those selections, namely, everything except the first N lines or everything except the last N lines.

The head and tail utilities are powerful enough to accommodate those needs. head allows you to extract either a finite quantity of text from the top or everything but a finite quantity of text from the bottom, and tail allows you to extract a finite quantity of text from the bottom or everything but a finite quantity of text from the top.

• head -n N -- by default outputs the first N lines (equivalent to using +N). Using -N outputs all but the last N lines.
• tail -n N -- by default outputs the last N lines (equivalent to using -N). Using +N outputs lines starting on the Nth.

Example:

Note that tail's complement mode requires you to specify the first line number to include in the output, so if you want all but the top N lines actually specify the argument N+1.

Change directories with the directory stack

The Bash shell (as well as others, like Zsh) have a built-in "back" feature for navigating directories. The built-in pushd command will put your current working path at the top of a shell-maintained stack and allow you to change to another directory. To go back to the saved path you can use popd. This one is more commonly known than the first two, but worth including because it's so incredibly convenient.

Example:

Since "pushd" stores the directories in a stack, you can push multiple directories onto the stack and later pop them off in the reverse order you pushed them. It's basically the standard "cd" only with a "back" feature. Speaking of which, the command cd - will always take you back to the previous directory you were in.

]]> http://bradconte.com/three-tips-for-the-linux-terminal/feed 0 http://bradconte.com/bash-path-hashing http://bradconte.com/bash-path-hashing#comments Fri, 05 Sep 2008 22:41:29 +0000 Brad Conte http://bradconte.com/?p=63 Bash is a Unix shell of many features. One of those features, which is both useful and potentially annoying, is the path hash table.

The environment variable we are probably most familiar with is PATH -- it contains all the paths that should be searched when we specify an executable to run. Bash starts with the first path specified in PATH and looks to see if there is an executable present, if there is not it checks the second directory, and so on until it either finds an executable with the specified name or it runs out of paths to search.

The path of an executable practically never changes. "ls" is always in the same place, as is "cat", and every other executable you might have. Thus, to save time, the first time Bash executes an executable it saves the path it finds the executable in, this way Bash can avoid searching for the executable again. The first time you execute "ls", Bash has to search for it. The second through bajillionth times you execute it, Bash will just look up the full path from the table -- much more efficient. It is important to note that every instance of bash maintains its own path hash table -- thus if you have multiple terminals open they will not share path tables.

However, if the actual desired path of an executable changes, problems can arise. By default, Bash will not look for an executable again. If an executable changes paths, Bash will not find it. If an executable is duplicated to a new path, Bash will execute the original executable even if the new one is in a path of higher priority (namely, listed first in PATH). As can be imagined, this can cause quite a headache in these rare scenarios if one is unfamiliar with Bash path hashing. If you create a script, execute it, then edit it and copy it somewhere else (say from your personal "bin" to a global "bin"), the old version will still execute. If you simply move an executable between paths, bash will not find the new executable despite the fact that it seemingly should. Observe the following example, in which I create "myscript" in my home bin, run it, copy it to a global bin, run "myscript" again, and execute the one in my home bin again.

(This image can serve as a stand-alone explanation -- feel free to redistribute it.)

Thankfully the hash table is easily manipulated -- by the built-in shell command "hash" no less. There are four switches that are likely of the most interest to you:

• "-d [name]" will delete a specific entry from the table
• "-r" will remove all entries from the table
• "-t [name]" will list the save path for the given executable name
• "-l" will list all existing executable -> path entries in the table

Using this tool you can view existing hashes and remove old stale ones as you see fit. To solve an out-of-date path hash problem, simple removing it will suffice. The next time the command is run the path hash will be re-updated. For more details, I refer you to the following key excerpts from the Bash man page:

Because of the number of Linux distributions and the degree to which their styles/configurations can vary, a given user usually has the ability to choose a distribution closely suited to their specific needs. To aid the ever-prevalent distro-seeker, many Linux users have sought to provide written reviews of various Linux distros. Unfortunately, many reviews fall short. With the increasing population of Linux users, and the increasing number of Linux distributions, there has been a notable increase in unhelpful reviews.

Which leads to the point of this article, namely, how to review a Linux distro. The idea of reviewing a Linux distro is to inform the reader as to how the specific Linux distro in question is different from the other Linux distros. To do this, a reviewer must provide an analysis of the software and configurations that set the disto in question apart from other distros, putting solid emphasis on the big differences, less emphasis on the minor differences, and no attention to the things that are inherent in all Linux distributions. (If you are writing to inform the writer about Linux, you should do that instead, rather than pretend you are reviewing any specific distro.) This basic principle holds for almost any review of any product. For example, movie reviews tell you why one movie, a four-star action flick, is different than another movie, a two-star romantic comedy. The movie reviewer doesn't spend time explaining the concepts of cut-scenes and character development, it merely explains the aspects of a movie that make it unique.

This article is aimed at the potential Linux distro review writer. It is split into two main sections: things one should review, and things one should not review. Most of the points have sample topics for that point, some of the points and sample topics are more advanced/technical, some are less so. No good review must cover every point and sample topic in this article, this is just a broad list of good ideas. Suit your information for the knowledge level of your target audience.

Good Things to Review

Here's a list of things that make for a good review. This is not an exhaustive list, but it covers a lot of ground.

• Philosophy

  Every Linux distro has a philosophy, namely, a statement of purpose and a set of guidelines for development that support that purpose. "Linux for human beings," "KISS," "Free, robust, stable," "Design for control," are some philosophies that describe various distros. Anyone using a distro with one of those philosophies would instantly recognize it.

  This topic is not optional, you must state the distro's philosophy and exemplify it throughout your review. Consequentially, it is probably the best place to start your distro review, as what you write thereafter should exemplify the philosophy. Remember, your goal is to show how the distro is unique, and it is the philosophy that dictates why the distro unique. All criticisms or negative points against the distro should be held in light of the distro's philosophy. Is the distro complicated? That might be worth mentioning, but if the distro strives to put user control first and simplicity is of no concern then complexity is not a short-coming of the distro but rather a side-effect of its philosophy. Rather than criticizing a distro for being too complex, instead note that it is designed for experts. Many reviews fail to evaluate a distro for what it is and criticize a distro for lacking things it does not strive to have.

  As boring as it may seem, a quick history of the foundations of the distro might prove very informative. Understanding why a distro was created in the first place can say a lot about what its like today and where it might be tomorrow.

  Sample topics:

  • Who is the distro's intended audience? The newbie, the guru, the average home user, the developer, the server administrator?
  • Does the distro tend to value stability or bleeding edge software? (See later points.)
  • Is the distro designed for users who like to control everything?
  • What is the history of the development of the distro? Why was it created?
  • How robust is a base level install of the distro? (More on this later.)

• The parent distro

  If the distro in question is itself based on another distro (many are) you should mention the parent distro and how this spin-off/child distro differs from its parent. Some parent-child relationships are distant, some are close. Some spin-off distros maintain their own package repositories and make their own configuration decisions, some are nothing more than the parent distro with a different default window manager and a few extra pre-installed packages. Telling the reader what the parent distro is and how closely the child is related to it is extremely informative for those either familiar with the parent or who will seek to become familiar with the parent.

• The package manager

  The package manager is the heart of a Linux distro. It is how the user most intimately adds to and subtracts from his system. The package manager is arguably the most important and unique component of a distro. Even though most package managers offer the same rudimentary functions, you should review the package manager. And the word "review" does not imply that you should confirm that there are indeed commands for installing and removing packages. You need to provide enough information that it's clear how the package manager feels to the user. Explain what sets the package manager apart from other package managers. Different distributions make it easier/harder to eliminate orphaned packages or check dependency information, and many have different ideas of what security precautions to take.

  Sample topics:

  • Does the package manager have a GUI?
  • How easy is it to upgrade all the packages in the system?
  • Does it provide clear output informing the user what its doing?
  • What level of security is offered? Package authenticity verification? SSL downloads?
  • Does it ever require that the user perform manual tasks to complete a package installation/integration into the system? (Ie, removing certain configuration files or backups.)
  • How is the package database stored? How easily human-readable is it? How easily backup-able is it?
  • How many tools are a part of the package manager? How many are necessary for day-to-day use?
  • How easy is it to perform a system upgrade?

• Support/Documentation

  The level of support and/or documentation available for a distro will likely be one of the most significant influences in a user's experience with a distro.

  The interactive support offered by a forum (and the archived support offered by its search function) can be priceless as a user gets started with a distro and has questions as they encounter Linux phenomena they are not familiar with. A wiki can help the user through the install and/or basic system setup, setup common software, configure it the way they want, and fix common bugs. The absence of a wiki can mean many hours of Googling for decentralized information and exasperation, leading to unfixed problems and a poorer user experience. A documentation tree (somewhat rare outside of behemoth distros) can help a user dig deeply into the distro and modify/fix it if they are so inclined.

  Sample topics:

  • Does the distro have an official forum? How large is it?
  • Does the distro have a wiki? How expansive is it? Does it cover the configuration of sudo? What are some of the more obscure articles it has?
  • Does the distro have developer-written/contributed documentation?

• The Packages

  While the package manager controls the addition/removal of packages to/from the system, it might be silly to overlook reviewing the packages themselves. The packages will be composed of compressed archives, arrainged with file hierarchy and package metadata that handles dependency checking, integrity verification, and the like.

  It is arguable that the layout of the filesystem be included in this topic. Many distros have their own ideas about how the filesystem should be laid out. If the distro has any peculiarities or quirks to how it uses the filesystem tree, its usually related to the compilation destination of packages.

  Sample topics:

  • What type of packaging standard does the system use? How easy is it for a user to create their own packages? (Some users like to assemble their own software and use the package manager to mange their installation. See point on compiling from source below.)
  • Is package downgrading supported?
  • How quickly are packages updated when their official upstream versions are updated? (Don't be to picky here: Are we talking about weeks or months?)
  • Continuing from the Philosophy point and the above sample topic, does the distro lean towards being bleeding edge or being stable? (This has been mentioned twice. Hint.)
  • Do the developers do extensive modification of the original packages (security patches, extra functionality), or are they provided vanilla as-is? (For example, Debian developers tend to modify packages as they see fit, Arch Linux developers only apply very common patches occasionally.)
  • How are the packages compiled by default? (For example, with or without debug information?)
  • How is Gnome/KDE split up? How many packages compose a full Gnome/KDE suit? (For example: Is Kolour Paint an individual package, or only available as part of the larger KDE Graphics package?)
  • Are there any filesystem layout quirks, additions, or reservations? (For example, is /usr/local ever used by packages or is it reserved for the user? Is Firefox installed into /var?)

• Support for compiling from source

  The package manager's job is (usually) only to manage pre-compiled packages. But some users like to manually compile some packages from source, such as to apply custom patches to a program or to get speed by optimizing the program for their specific machine. Many users don't compile much (if any) from source, but the Linux philosophy is deeply rooted in the distribution and manual compilation of source code, and there are many who like/need to do so. How an operating system lets the user compile/managed compiled programs is important to how the operating system works. Those who rely on it will find their experience very dependent on how manual compilation is handled.

  If there exist any distro-specific methods for handling the compilation of both supported (packages in the repositories) and/or un-supported (packages not in the repositories) software, it should definitely be included in a review. If the distro has any form of a ports-like system, a review without mention of it is by default incomplete.

  And do not ever, ever waste space explaining that you can do "./configure && make && make install", that you can use "checkinstall", or that you can use the "install" program itself -- every distro has those, they aren't worth mentioning in the slightest.

  Sample topics:

  • Do there exist any specific tools for the system that aid the user in compiling programs from source?
  • How are users supposed to recompile the kernel? Is initramfs or initrd used?
  • If a user does manually compile a program/package, how easily can it be managed by the package manager? (This has been mentioned twice. Hint.)
  • How is the presence of different kernel versions handled?
  • Is there risk of having the manually-compiled program conflict with the packages managed by the package manager, or is there a way to keep manually installed non-package programs separate?

• Release system

  Distros have different styles of updating the end-users installed distro to be the most current version. Some distros have a new, fully-updated version released every 6 months. Some just release all package upgrades on-the-fly and have no concept of different versions. The way the distro handles version releases is significant to the end-user, as usually full version upgrades mean that the developers reserve the right to move stuff around and/or reconfigure things in a noticeable way if they want to, and push those changes through in the next major release. It also means that developers reserve the right to stop providing package upgrades for a given version, resulting in obligatory periodic upgrades.

  Sample topics:

  • What factors decide the version releases (if there are any)?
  • How big are the changes between releases?
  • How often are the releases?
  • How long is there support for old releases?
  • Does evidence seem to suggest that performing a version upgrade is smooth, or is the user better off performing a clean install of the new version?

• Startup style

  Summarizing how a distro manages startup scripts/daemons is easy: All you have to do is say whether the distro uses System V or BSD-style init scripts. (Users unfamiliar with those can look them up.)

  How the operating system uses run-levels is a more complex subject, yet still an interesting on. Fewer users will care about this level of detail but more advanced users might be able to intuit more about the nature of a distro from it.

• Robustness of a default install

  Distros vary in what software they provide for a from-disk installation. Some have more, some have less. Some have roughly equal quantities but the theme of the offered software is completely different.

  After you install the distro, how much work must be done to get the system up and running with a graphical desktop and a decent collection of tools? What kind of packages are installed, and what aren't?

  Sample topics:

  • Is a default display manager installed or offered? (Which one?)
  • Does the distro rely heavily on sources from the servers, or can you obtain multiple CD/DVDs for a more robust from-disk install?
  • Does the default install include tools for compiling? (GCC, make, etc.)
  • Does the default install offer Apache for install?
  • What are some of the most specific/obscure programs install/offered by the installer? (For example, if a distro provides Compiz and OpenOffice.org straight from disk, that implies the sort of other packages that are installed.)

The above topics cover a lot of ground. Obviously not every detail need be included in a good review, but many of these points are very critical to how the distro works and failure to address a significant number of them will result in an incomplete review of the distro. If there seem to be too many points to address, remember that you're writing a technical review, not a grand work of fiction. Wordiness can usually be eliminated. If you know what you're talking about and put some thought into what you write, you can cram a lot of information into three sentences.

One key to remember is that that not all of the information may seem important to you, the author of the review, but it is what separates one distribution from another. Obviously the information has to be appropriate for the audience you are writing for; that is a decision faced by every writer.

If you feel unable to address many of these topics in your review then you probably not as familiar with the distro as you should be in order to do a good review of it. Many people want to pop in a CD, install the distro, play with it for 30 minutes, and then write a review about it. Unless you did your research beforehand and you made very good use of those 30 minutes, you're probably not qualified to offer a review. Spend some time learning more about the distro.

Bad Things to Review

Now a list of things you should not review.

• Plug-n-play drivers

  Do not ever review a distro by saying "I plugged my external wireless card X and it did(n't) work". This is the lamest review you can provide, and is my pet peeve to boot. First of all, almost all distros use the same drivers. Support for hardware is pretty much universal, the same drivers that manage your hardware in one distro probably manage it in most other distros, and this only becomes more true with time. Comparing hardware support between distros is basically pointless. It's even more pointless when your analysis consists of just one generic external wireless card. If it didn't work, odds are you didn't set something up correctly.

  Note that it is obviously acceptable to review the quantity of drivers provided by a distro if they seem to have a noticeable shortage/abundance of them, but most distros will have about the same drivers. Don't mention driver quantity unless its very noticeable.

• Five minute quirks

  At various times, some distros have what you might call "five minute quirks". These are one or two little problems that need to be ironed out of a fresh install of the system and are easily solvable by a user with the skills that the distro is oriented towards. Sometimes an environment variable needs to be set, sometimes a file needs to be configured, etc. These are bugs not unique to anyone's specific install of the distro, but rather a very large (if not the entire) user base. One of the developers mis-configured something before release, or some default setting doesn't work with the majority of hardware, or something like that.

  Do not write about these little five minute hiccups in your review, they don't count. They only effect you for five minutes and will likely be fixed in one of the upcoming releases. (See the next point.) Usually the distro's forum and/or wiki has an easily accessible guide to tell you how to fix the quirks and after a day of usage, the user will not remember it. At absolute most you should say that "minor quirks exist" and say where/how the site addresses these issues. This could be part of your review of the distro's documentation. Any quirks you fix within five minutes of attempting to do so should not be mentioned. Their fix in the next release will out-date your review.

  What's more, do not write about the stability of a distro based on its five-minute hiccups. Nothing says "I didn't do any actual research about this distro" like a stability evaluation based on the initial five-minute quirks the distro had as of some arbitrary date.

• Unrelated/temporary bugs

  Do not write about temporary bugs. If the bug is the type that will be fixed within four months, don't use it as basis for your evaluation of the distro's stability. This point bears repeating: Whatever you do, do not base your assessment of a distro's stability on little quirks that will be gone in a couple months. If your readers wanted to read an bug listing, they'd browse bugzilla.org.

  On that note, do not assess the distro, in any way, based on bugs that are not specific to the distro itself. If the developers of a software package X make a mistake, don't blame the developers of the Linux distro in question, it's outside of their control, not their fault, and not their responsibility. It's irrelevant to your review, so ignore it. If distro X has a bug but distro Y does not, it is possibly that distro Y did not push the new version of the software and thus does not have the buggy version -- you can use this to exemplify how "bleeding edge" the distro is. Or its possible that distro Y manually patched the software -- you can use this to exemplify how the developers do (or don't) manually patch packages.

  You can obviously cite the presence of bugs in your analysis of the stability operating system, but don't focus on petty bugs. Instead, focus on the release/testing cycle of packages, the speed of security fixes, and frequency of distro-specific bugs. If this means that you actually have to spend some time using a distro and learning about it before you evaluate its stability, cry me a river. If you aren't willing to do that, don't comment on it's stability because you don't know anything useful about it.

• Artwork

  No one cares what the default desktop color theme of the distro is. Or the default desktop wallpaper. Or whatever. This is my other distro-review pet peeve. As shocking as this may sound, every desktop environment and window manager in the entire universe, throughout every civilization, all of time, and every dimension, can have its color theme changed. If a user doesn't like the default wallpaper, they will change it. If they don't like the default Gnome color theme, they will change it. Defaults are irrelevant.

  Don't mention the quantity of community artwork, in the sense of backgrounds and color themes. This is directly proportional to the number of users the distro has and thus redundant information. And, realistically, nobody makes a distro decision based on it. And many users routinely become attached to a certain color theme and will take it with them from distro to distro.

• Installation Process

  This is not a terribly important point, but I think that reviewing the installation process of a distro is almost pointless. Most installers, even text-based ones, guide the user through the installation very clearly. Sure a text interface may look a bit daunting to some, but if one just reads the instructions, one can usually just click-through (or, tab-enter-through) the installation with relative ease.

  This item might warrant a quick mention, perhaps tying into the distro's philosophy (ie, in analyzing whether the distro is oriented towards casual or power users), but unless the installation process is exceptionally complicated or buggy don't devote much space to it. It's a one-time experience by the user, and a determined user won't change their opinion on whether to install it based on the installation graphics. Mention if it's GUI or text based, and move on.

Remember, your goal, as a reviewer, is simple: Review things from the perspective of the average user you are writing for. Don't go into pain-staking detail unless you're aiming to provide an in-depth guide, minor details/quirks are often best left for their own special article and are of interest to few readers. Don't waste time on things that were (likely) very unique to your experience, because almost no one else cares.

Even though this article was somewhat long, your distro review doesn't have to be. A lot of useful information can be packed into one paragraph.

The idea behind port knocking is simple: The administrator of a server sets up a server with an Internet-accessible service. The administrator then closes all the ports on the server, including the ports that the service uses, and starts a daemon that monitors all incoming packets to the server. The daemon then opens the port corresponding to the service when and only when the daemon receives a series of packets on a specific set of ports in the correct order. The packets can be any type -- TCP SYNs, TCP ACKs, UDPs, whatever -- but they must be sent to the server on the correct ports and in the correct order to cause the daemon to open a service's port. Thus a port remains closed until someone "knocks" on the correct ports to cause the daemon to temporarily open it.

(Example: If the required sequence is TCP ACK packets on ports 333, 4444, and 55555, then the sequence of ACKs "27, 333, 4444, 55555, 42" would open the port, whereas the sequence "333, 27, 4444, 55555, 42" would not. I would tend to use TCP ACK packages, because they look the most boring to someone sniffing a network -- more below.)

Thus port knocking adds the security equivalent of another "password" to a service, because a client has to successfully knock on a server's ports in the correct order in order to open a port for business. Given 2^16 possible ports, about 4 possible protocols, and (usually) about 4 necessary correct port guesses, standard port knocking comes out to the equivalent of a ((2^16 * 4) ^ 4) = 2^72 bit key. This isn't too shabby a number, in terms of key size, especially if port knocking is just an extra layer of security for a service.

Thus begins the debate on the security practicality of using port knocking.

The main advantage of port knocking is that it conceals the very existence of a service until the port knock sequence is complete. An attacker cannot attack a service he cannot find, and until he finds out how to properly knock, every port on the host will appear closed to him. Thus port knocking is very helpful in situations where a server administrator wishes to conceal the very existence of a service. Service concealment was the primary motivation behind the development of port knocking.

Another advantage of port knocking is that it allows a port, when it is opened, to only be open for connection from a specific IP address. The port knocking daemon monitors all incoming packets and when it detects the correct "knock" it can not only open up a port but can open a port that accepts packets from the knocking IP only. Thus a WAN-side service can be told to accept connections only from certain IPs, but those IPs can be decided in real time.

Unfortunately, however, port knocking is a very fragile security policy. Since the knocking packets must always be sent in the clear it has the equivalent security of a password sent in cleartext. Anyone sniffing your network on either the client or server (or anyone who can trick the client into sending the knock sequence to a spoofed server, ie via DNS poisoning) end can tell what "knock" is used and replay the packets, effectively negating the security of port knocking. The good news is that unless an attacker is actively looking for a port knock sequence, the knock will look like normal boring network traffic. But if a sniffer is on the lookout for a knock sequence -- especially if they know which server it is destined to -- it's impossible to slip the knock past him.

Also, because port knocking requires the equivalent of a symmetric key problem, port knocking does not scale well to services that must handle many individual connections. The pork knocking "key" must be distributed securely to everyone who needs access to the server's service. Any cryptographer and/or security auditor will tell you that the symmetric key distribution infrastructure for this sort of thing is both annoying and brittle -- the larger the infrastructure to be maintained, the larger the hassle and the larger the potential for single point failure.

Obviously, scalability does not matter to the individual wishing to SSH into his home computer, but it is of major concern to anyone operating a server with more than four or five users, especially if users must be added, revoked, and have their "knocking keys" rotated. This is a classic (annoying) symmetric key distribution problem.

Port knocking is also impractical for popular/busy servers because the popularity of a server contradicts the very goal of port knocking: to conceal the very existence of a service on a server. If an attacker is aware of the nature of his target and knows (or at least has an idea of) what services the server has, he will not be satisfied if his port scan turns up empty. If he expects certain services to exist on the server, and if he is in any way persistent, he will investigate the server until he finds the services he knows exist, thus he will investigate the potential use of port knocking sooner or later. This does not result in instantaneous defeat of course, but the port knock is only a secure as a password sent in cleartext, which is a bad security measure to have to fall back on. The exact situation will dictate how easy the knock will be to sniff.

This quick assessment should make it obvious that the only practical use for port knocking is on small servers. Realistically, the service itself should be secure enough in both configuration and implementation to not require the additional security of port knocking -- it is an Internet service, after all -- but port knocking does add yet another level of plausible security, and the paranoid never underestimate defense in depth.

All things considered, port knocking is not too useful, despite being a fun idea. The only place I've actually observed it in use was by people at DefCon looking for any way to add any level of security to their home computers. But, obviously, those are the "I will because I can" types. Plus, when you're at DefCon you use anything to secure your home server that you can get. But outside of the experimental world, port knocking is only an interesting notion, it never sees wide-scale usage for a reason.

Note that Port knocking is not the same thing as Single Packet Authentication. Port knocking was the initial attempt to gain security by service invisibility. SPA is the more secure successor to port knocking, developed to address key problems in port knocking.

Unfortunately, this sweatshirt is not explicitly for sale anywhere. I had it custom made because I couldn't find anything like it.

Summary

I love my sweatshirt, I'd sell it on a store like CafePress if I could find one that sells black sweatshirts. Since I can't, the next best thing is to provide the instructions to get one.

The image: You can get the image I used for the screen-printing here. However, the company I used for the screen-printing required you to upload an inverted version of the image (at least as of the last time I used their services), which you can download here. If one doesn't work try the other.

The company: The company I used to screen-print the image is Blue Cotton. I chose the Hanes Pullover sweatshirt (Printing -> Sweats -> Hooded Sweatshirt -> F170 Hanes Pullover Hood), but they do offer other sweatshirts. The Hanes sweatshirt has the advantage of having the lowest polyester content (90% cotton) of any of their sweatshirts, which is a good thing for a screen print and has the side benefit of being very comfortable.

The image sizing: For my sweatshirt, an extra-large, I chose to make the image 9.5 inches wide (be sure you lock the width/height ratio when scaling the image on the sweatshirt) and centered it 2 inches below the collar (you'll have to eyeball this measurement). It took a long time for me to decide on those dimensions, but I finally did and I think they're perfect, which is saying something. You might want to scale the width for sweatshirts of different sizes, my rough guess would be to subtract/add .75 to 1 inches per size smaller/larger.

So all you have to do is go to the website, select your sweatshirt, upload the image, set the width/placement, and order it.

Background for the sweatshirt

I'm a math major, and I like elegance. Euler's Identity is my favorite mathematical expression: it's a simple expression of universal truth via constants. It's fascinating how the five most fundamental constants of math are all uniteable in a single, simple expression.

In addition to math, I like t-shirts. I tend to treat t-shirts as billboards for things that I like -- you won't find a blank shirt in my drawer. As need had it, in winter of '07/'08 I found myself in need of a new sweatshirt. Like the rest of my upper-body apparel, I wanted it to say something interesting. I wanted the sweatshirt to be "nice-ish" so that I could wear it to "nice-ish" events, so I didn't want a busy/complicated design. it had to be simple, yet elegant. Settling on a simple expression of Euler's Identity was easy. My second stipulation was that the sweatshirt had to be black.

I started my search at the obvious place for a weird request like that: CafePress. I found a couple of sweatshirts with Euler's Identity, but a) They had obnoxious brand logos, and b) Cafepress doesn't sell black sweatshirts. After an extensive search of the Internet, it became obvious that no one offered anything like what I was looking for (shocking, considering the obvious demand). So I decided to have the shirt custom screen-printed.

The design of the sweatshirt

Thus I was faced with two tasks. The first task was creating the image I wanted to be screened onto the sweatshirt. The second task was finding someone to screen-print the image. Neither task turned out to be as simple as it might seem.

Creating the image was difficult because the only decoration for the black sweatshirt was going to be the bold, white text of Euler's Identity. Thus the styling of the text was very important. In order to truly do the equation justice, and make the sweatshirt look as simply elegant as possible, the font had to be perfect. Not fancy, but not boring. Just slightly elegant.

Getting the image screen-printed turned out to be difficult because there were two major conditions for the screen-printing: I had to be able to have a transparent background, and I was not going to order in bulk. Most custom screening companies violated the former of these two requirements, and the few that allowed background colors required bulk orders. In addition, some companies didn't offer sweatshirts in black.

The final solution

Finally, however, a solution was reached. I designed the image using the "i" and "pi" symbols generated by a Linux-based LaTeX front-end called eqe. I generated the rest of the equation using characters from the Tahoma font in the Linux-based image editor KolourPaint. I needed a very large size image to achieve a sufficient DPI, which was recommended to be at least 90. Both programs allowed me to create the images at a large size with excellent quality, but not a size quite large enough. So I used Gimp to expand the size and I used its anti-aliasing feature to keep the font's smooth despite being enlarged. The result is shown here. (This is a scaled-down version of the image, for bandwidth reasons. Click the image to download the full-size image, the one you would use for actual screen-printing.)

View the inverted version.

I also found a company, called Blue Cotton that allows one to screen-print an image, choose a color to make transparent, and doesn't require a bulk order. (Choose Printing -> Sweats -> Hooded Sweatshirt -> F170 Hanes Pullover Hood.) Thrilled to have a working image and a working company, all I had to do was manually place the image on the sweatshirt. I spent (no joke) probably 3 hours total moving the image around on the shirt, higher, lower, bigger, smaller, trying to get it just the right size and at just the right height. Finally I decided on a 9.5 inch width at 2 inches below the collar, which I am pleased to say is the perfect size/placement (for an XL).

Also, kudos go out to my girlfriend for her extreme patience with me. The sweatshirt was a Christmas present from her to me. Being a nit-picky perfectionist, it was decided that I had actually best do the bulk of the designing. I didn't even finish the design until the end of January. Giving it to me was an excellent idea, and it's one of my all-time favorite articles of clothing.

Index of Links

• Pre-Cryptography Concepts
• Fundamental Cryptography Concepts
• Simple Encryption Algorithms
• Advanced Encryption Algorithms
• One-Way Hashes / Checksums
• Cryptographic Attacks
• Online Books/Papers
• Encryption Programs
• Encryption Libraries
• Resources on Cryptographers
• Historical Background
• Cryptography Conferences

Pre-Cryptography Concepts

• Why Cryptography is Harder Than it Looks
• Security Pitfalls in Cryptography
• Cryptography is not Security

Fundamental Cryptography Concepts

• Definition of Cryptography by RSA Security
• Symmetric/Private Keys
• Asymmetric/Public Keys
• Kerckhoffs' Law (Security Through Obscurity)
• Block Ciphers
  • Block ciphers explained by Wikipedia
  • Block cipher modes of operation defined by the NIST
  • Cipher block modes of operation explained by Wikipedia
• Stream Ciphers / Pseudo-Random Number Generators

Simple Encryption Algorithms

• Substitution/Ceaser Cipher
  • Defined by Wikipedia
  • ROT-13 variant
  • Atbash variant
• Pig Pen Cipher
• RC4
• Rail Fence Cipher
• Solitaire Cipher
  • As explained by Bruce Schneier (author)
  • Weaknesses in the algorithm
• Vernam Cipher / One-Time Pad
  • Cryptology and Data Secrecy : The Vernam Cipher
  • Vernam Cipher, A Perfect Cipher
• Viginere Cipher
• XOR

Encryption Algorithms

• AES / Rijndael
  • NIST Standard
  • Is AES Secure?
  • Javascript walk-though of AES implementation
  • Error-checking your implementation of AES
• Blowfish
  • Explained by Bruce Schneier (author)
  • Explained by Wikipedia
• (Triple) DES
  • DES defined by the NIST
  • The DES Algorithm Illustrated -- (Contains test vectors lacking in the NIST specification.)
• Serpent
  • Serpent Specification
  • The Case for Serpent
• Twofish
  • Home Website
  • Explained by Bruce Schneier (co-author)
• Quantum Cryptography
  • Simple Introduction by HowStuffWorks
  • Quantum Cryptography Overview (PDF)

One-Way Hashes / Checksums

• Definition of a cryptographic hash
• An illustrated guide to cryptographics hashes
• CRC
• MD5
  • As explained by Wikipedia
  • RFC specification of MD5
  • MD5 walk-through in JavaScript
  • MD5 Weakness
    • Paper on MD5 collisions
    • MD5 collisions visualized
    • Sample MD5 collisions
    • Implementation for generating MD5 collisions
• RIPEMD
  • RIPEMD-160 Specification
  • General Info
• SHA
  • NIST specification for SHA-1, SHA-256, SHA-384, SHA-256
  • SHA-1 explained by Wikipedia
  • SHA-1 Weakened

Cryptanalysis

• Analyzing and Breaking Ciphers
• General Block Cipher Attacks
• General Stream Cipher Attacks
• Breaking a Polyalphabetic Substitution Cipher (PPT)
• Breaking Polyalphabetic Substitution Ciphers
• Breaking a Vigenère Cipher
• Basic Text-Based Cryptanalysis by the US Army
• NIST's Guide to Statistical Tests
• Linear Cryptanalysis (with demo)
• Brute-force
• Man in the middle
• Side-Channel Attacks
• Confusion and Diffusion
• Communication Theory of Secrecy Systems -- The paper by Claude Shannon that introduced the concept of "confusion and diffusion".
• AES Competition (Purity Noise) Tests

Online Resources

• Databases of Papers
  • The Cryptology ePrint Archive
  • Crypto Conference Papers -- Papers that have been submitted at the conferences Crypto, Eurocrypt, and Ches.
  • Cryptographer's World -- Statistics on published cryptography authors and papers.
  • Ron Rivest's Collection of Links
  • arXiv - Cryptography and Security
• Books / Compilations of Notes
  • MIT summer course -- Notes from an MIT summer course on cryptography (1996-2001).
  • Graduate-level notes by Mihir Bellare (UCSB) and Phillip Rogaway (UCD)
  • Handbook of Applied Cryptography -- A free ebook that provides a good introduction to mathematical cryptography.
  • A Computational Introduction to Number Theory and Algebra
  • An Overview of Cryptography -- An overview of cryptography and a look into real-life modern programs.
• Course Materials
  • MIT - Spring 2005 - Cryptography and Cryptanalysis
  • University of Washington - Winter 2006 - Practical Aspects of Modern Cryptography
  • A Self-Study Course in Block Cipher Cryptanalysis
• Introduction to Cryptography
• Security Engineering -- A practical approach to employing cryptography.
• Peter Gutmann's Crash Course on Cryptography
• PKCS #5 -- A cryptographic standard for using user-specified keys in encryption.

Encryption Programs

• TrueCrypt -- Symetric key, disk/virtual disk encryption.
• GPG -- Public key, multiple encryption options.
• PGP -- Public key, multiple encryption options.
• AxCrypt -- Symmetric key, individual file encryption.
• DriveCrypt -- Symmetric key, whole disk encryption.
• dsCrypt -- Symmetric key, individual file encryption (stand-alone EXE).
• Snake Oil Encryption Software -- This isn't an encryption program, but it's a good article on how to evaluate encryption software.

Encryption Libraries

• Crypto++ -- A C++ library under a custom, permissive license.
• PolarSSL -- A C library under the GNU GPL license.
• OpenSSL -- A C++ library under an Apache-style license.
• Brian Gladman -- C source code for AES, SHA, and HMAC.

Cryptographer Resources

• Bruce Schneier
• Peter Guttmann
• Matt Blaze
• Ron Rivest
• Xiaoyun Wang
• Neils Ferguson
• Professor Michael Anshel
• David Wagner
• Dr. Vlastimil Klima
• Claude Shannon

Historical Background

• Historical Overview
• Crypto AG - The NSA backdoor
• The AES Competion

Cryptography Conferences:

• Crypto
• Eurocrypt
• CHES
• Financial Cryptography

Page info:

• List Started: October 27, 2007
• Last Content Update: November 15, 2009 - Removed stale links, added more links, reorganized some existing links.

That word "hacker" carries with it a lot of baggage. The word intrigues teenagers, scares politicians, and causes computer geeks to endlessly debate its exact definition.

Computers have created an deep, complex, intertwined world that few people are truly familiar with. A world in which most of its users can't even begin to comprehend the complexity or functionality of it. Even people who would be labeled as relatively computer literate, in all likelihood, don't really know much about how their computer works. Average Joe hasn't really a clue what his computer actually does or how it actually works beyond the point-and-click GUI he sees. And that's fine, because thousands of man-hours have gone into the design of everything computers do and it's unreasonable to expect Average Joe to understand a large portion of it.

But hackers make a point of knowing what happens inside a computer. What's more, they try to manipulate what happens. The combination of their knowledge and skill sets scares a lot of people (and excites others). Hackers have a knowledge base that many others do not. And they have a skill set that many others do not.

Odds are you're reading this because the concept of "hacking" interests you and you want to learn more about it. If you are an aspiring "hacker" (we'll see if you truly are in a bit), this if for you. For others, this will give an introspective into the mind of the hacker. I assume that the "aspiring hacker" is somewhat familiar with computers but hasn't really touched on hacking and computer security in any depth. My goal here is to provide a first introduction to what you'll need to do to pursue "hacking". The most daunting part of any task is usually just finding a place to start, and giving you that start is my goal.

However, my goal is not to teach you how to hack; it is just to tell you were to start. First I'm going to explain what the concept of hacking entails, so that you know what you're getting into. Next I'm going to lay forth the learning mentality and efforts you're going to need to expend, namely, what you're going to need to do to become a hacker. Third, I'm going to show you what your goal should be, namely, what it is you should eventually arrive at. Last, I'm going to give you a starting point so that you can go off and actually begin your studies, because that's what you probably want anyway.

I'm going to spend a lot more time elaborating on this topic than need be. A lot of good advice for the aspiring hacker could be condensed in just a couple sentences. But all of that has been said and done before, it's my goal to give the exhaustive explanation that covers every relevant conceptual topic. And since every hacker, more or less, follows a similar path of development, this can also give the non-hacker an insight into the mind of a hacker.

Remember, this is only an article about where and how to start learning, it's not my goal to actually give you your first Hacking 101 lesson.

What You're Getting Into

Hacking requires a lot of knowledge and understanding. If you just want to find one computer program you can download so that you can click a couple buttons and impress your friends by breaking some stupid thing on their computer then you aren't aspiring to be a hacker, you're aspiring to be a script kiddie. And script kiddies are to hackers what construction workers are to structural engineers. Script kiddies are out to, usually, amuse themselves. They act without purpose and rarely have any ethic standards.

First you'll need to understand what it is that hackers do. In the beginning, rules to govern the everyday aspects of computing were created. These rules are for networking, web design, programming, graphics design, etc. They govern everything that computers do and dictate how they do it. Most developers live by these rules.

Hackers, however, have what might be likened to a second layer of rules, a layer of rules built on the first layer. At the risk of using a cheesy analogy, the normal rules of computer are can be described by the line from The Matrix where Morphius tells Neo (in the sparring chamber): "Like any rules, they can be bent, others can be broken." That's fairly true of computing. The normal rules of computing can be manipulated, others can be completely bypassed. The realm of hacking lies on the second layer of rules, rules that are based on the first layer and can manipulate the functionality of the first layer.

Note the lack of the phrase "breaking into computers" in my definition of "hacking". Hacking is about learning, changing, and manipulating. Whether you use those skills to break into someone else's computer is a separate, unrelated issue. The mainstream media uses the buzzword "hacker" too narrowly, the roots of the term are far more broad than what modern mainstream usage implies.

For example, take the ARP networking protocol. It doesn't matter if you know what ARP is or how it works, suffice it to say that it's a networking protocol. ARP is a "first level" set of rules that govern how computers communicate on a network. Every network administrator must be familiar with how it works. However, a hacker knows how ARP works and knows how to use those rules to perform a different task than the goal of the original rules. Using the ARP protocol is standard computer networking. Manipulating ARP to do something you want it to is hacking. ARP is a normal rule, but it is a rule you can build from and it is a rule you can manipulate.

Thus in computer security/hacking it should be obvious that it pays to know the normal operating rules. Everything hackers do is based on the normal rules and unless you understand those rules you won't be a decent hacker. You're going to have to study how things work, why they work, learn how they work successfully under normal conditions, learn how they fail under abnormal conditions, and then figure out how to use them abnormally and make them achieve different goals.

So to begin your hacking endeavors you're going to have to do a lot of reading and a lot of question asking. If you already assumed this then you're in the right frame of mind. If you thought you just needed to find those one or two magic programs that would let you crash Windows boxes by the second day, rethink your plans.

How to Learn

In brief, you're going to need to read. A lot. Everyone's learning style is different and there are a lot of perfectly valid learning methods, but all of them will include a lot of reading.

Let me offer this bit of advice: Do not start by reading RFCs or any other sort of extremely technical specification. (RFCs are technical papers describing many common computing standards.) Some people will give you that advice and, frankly, I don't think it helps very much when you're very new to hacking. Instead, start by reading articles/essays/tutorials that are more than a listing of facts and specifications. Read what one person has to say on a topic, then go read technical documentation if you want to know very specific details about it. RFC's and other technical documentation can be complex, and sometimes downright unhelpful to a beginner. They make create resources to consult later, however.

To start your reading, get a browser that has tabs and makes both searching the Internet and searching a rendered web page easy (such as Firefox). Then find an online article about some security topic that interests you and seems roughly at your level of understanding.

There are two things I would like to emphasize from just that last sentence. First, I would like to stress that you find something roughly on your level. You will kill your ambition if you try to understand and dissect concepts too far over your head. Some stuff is very complicated, don't discourage yourself by trying to take it on before you're ready. You'll get frustrated trying to bench press a 500lb weight on your third day at the gym, it may be out of your league at the moment and just isn't worth your time trying to lift. This isn't to say you should forget about any complex topic you come across, you should just make a note to come back to that topic later when you know more and can assimilate information on that complex topic better. Go spend some serious time researching and learning what you need to in order to understand that topic and come back to it when you're ready. If it takes a day before you're ready, great. If it takes a month, that's fine too. The important thing is that you're learning. You don't get any sort of points for reading the articles you originally decided to, you get points for what you learn.

My second point may seem a bit obvious but I do encourage that you start your research online, as opposed to going out and buying a hacker book or magazine. The newer you are to hacking the less you'll know, and the less you know the more likely you are to find heaps of material about what you're looking for online for free anyway, so it may not be worth buying hard copy material. Plus the less you know the more you'll need to look up as you read. It's easier to look stuff up on the fly if you're on the Internet. Every new golfer likes to go out and buy their first new set of clubs, but that mentality doesn't work as well here. You will likely not need to spend a dime for anything (other than a computer and/or basic accessories) for a long time. Most stuff is available, in some form, for free.

Anyway, find an article on something that looks like material you want to learn. Read it and make note of all the words or terms you don't recognize. As you find them, highlight them, right-click them with your mouse, and search Google for them (one of the nice features of Firefox). All of them. If you have to open 20 new tabs from one article then that's fine, remember, you only get points for what you learn, not for whether you finish the initial article you started to read. Sometimes you'll come across a tutorial, paper, or audio lecture that does nothing but provide you with a long list of topics to go research. You may not be able to make much sense of it for months, but that's OK.

Read on all of those topics you just searched Google for. You don't have to read just one article per topic, if the article you read seemed short and didn't satisfy your curiosity then read another article to make sure you're not missing anything important. If those articles themselves have terms you don't know, look those up too. Make it a habit to instinctively always look up terms or concepts you don't know. The number of open tabs you have can balloon quickly but that's OK, you're out to learn.

A word of sympathy to those who find themselves with dozens of open tabs and dozens of topics that need to be researched: It can get very big very fast and you will sometimes have to call it quits on a topic. Don't be a wimp, though, call it quits only when you've truly hit a wall or are getting into a subject that truly bores you. Even if you don't learn the details about a subject, just learn the vague idea behind it. For example, even if you don't fully understand how ARP poisoning works and how to do it yourself, understand what it allows you to do that way you know what it means the next time you hear the term. You can learn how to perform an ARP poison attack some other time, and when you do learn it will be easier if you already understand what it is. Be flexible with what you learn in depth. If something frustrates or bores you, move on to something else -- there's plenty of interesting topics to study. (If everything bores you, you might not be cut out for it after all.)

Which topics should you be pursuing more than others? This is up to you. There are dozens of topics you can research and you'll have to determine for yourself which ones you spend the bulk of your time pursuing. Almost everyone will recommend that you have at least minimal well-rounded knowledge in most fields but that you find some topic that specifically interests you and you pursue it.

As you read more and more articles, you should come across fewer and fewer terms you don't understand. You will always run across unfamiliar terms -- no one knows everything -- but the quantity of those terms should diminish with time. Even if you don't necessarily remember every acronym you read (there are a lot of them) a quick Google search for one you've forgotten and a quick glance down the results page should spark the "Duh, now I remember that," light bulb.

Remember, never hesitate to use Google (or your search engine of choice), no matter what your question is about. If you're new to hacking and seriously trying to learn it would not be unreasonable for you to be executing 15 Google queries an hour during any given period of research. (This wouldn't be unreasonable for a veteran to do either if they're delving into new territory.) Google isn't a sign of weakness. And it's free. Use it. Often.

There will be some questions you have that Google doesn't answer, or doesn't answer to your satisfaction. When this happens, ask someone who might know. The best way to do that is to post your question to a hacker / computer security forum.

At some point you're going to need to start doing some actual hands-on work. All knowledge and no experience makes Jack a condescending pseudo-guru. If you want to be a hacker you're going to have to actually do something sooner or later. Feel free to experiment on your own computers on your own network. Port scan your desktop various ways from your laptop, try an ARP attack against your laptop from your desktop, etc.

And remember, for the sake of all that is good in this world, don't attack computers you don't own. It's tempting, but don't do anything against other computers, you'd be surprised how easily people can get upset. And I've seen enough hackers more competent than you will likely be who got into legal trouble to last me a life time. It seems tempting to try, but it's not worth it.

The obvious question is, "When do I actually start doing hands-on work?" This is up to you. Some people prefer to research to their heart's content before touching any tools, some prefer to experiment with tools as they learn everything. Do whatever helps you learn the most, but always research a concept at least a little bit before you try it out -- I'm not a big fan of "try it then learn it". Otherwise you won't know what you're doing, you might get confused, and you'll waste your time. And, most importantly, if you're really unlucky you'll break something by accident. If you don't know what your tools are doing and how they work when you use them, you're more of a script kiddie.

When you do start doing hands-on work is when you might want to start reading technical manuals. I assumed that you started very new to hacking, but by the time you're attempting to try things you should be able to read and understand RFCs and similar documentation on the subjects that you're experimenting with. Because by then you're more concerned with the more nitty-gritty details of how stuff works, and then the mumbo jumbo in RFCs and other technical documentation should make sense.

I would also advise that you focus more on technical understanding than on technical memorization. Its important to know how you can use ARP for a man-in-the-middle attack. Its much less important to be able to construct an ARP header frame from memory. If you ever need to do that, you can look it up. If you understand how something works, you can get the precise details when you need them.

Where You're Headed

In your endeavors to learn about hacking, eventually you should hit a point where your tools stop dictating what you do and you start dictating what your tools should do. You should be continuously learning and feeling more in control of what you do, and eventually you should hit a point where you know that "I need a program that explicitly allows me to perform this specific function," and you go to Google and type in a precise seven word query looking for such a program. It may not exist so you have to make hack together something using other tools. Or, better yet, you may find yourself writing the tool yourself.

In other words, eventually the worker is going to have to start buying tools that will build what he wants and stop building what his tools will allow him to. He needs to design a building that he likes, then he needs to go find tools that will allow him to do that.

Some people don't understand this concept and live in an infinite loop of never doing anything that their four favorite tools can't do. Don't let this be you. Govern what your tools do, don't let your tools govern what you do. This isn't to say you can't find some nice, multi-functional tools out there, but don't just download a couple programs with pretty interfaces and stick with just those, you'll hold yourself back.

Usually hackers will eventually learn at least one or two programming languages, so that they can write at least small programs themselves. I would advise you to learn at least some programming. Even if you don't do much with it, learn at least one or two languages semi-fluently. Most security-oriented hacking requires knowledge on the level of C, and learning a scripting language is helpful for automating tasks.

A Starting Point

Enough advice. You need to start doing something. Where do you start? My first bit of advice involved finding those first articles of interest to read and branch out from, but how do you find those articles?

Start with the following concepts and vocabulary words. What I provide is a list to get you started researching computer security/hacking. Remember, don't just read one article on each of these topics and call it quits, use these topics to start your Google research from. Read on these topics and everything related to them, then everything related to those topics, and related to those topics, and so on. This list is just to help you figure out what your first Google queries should be. The items on this list were not chosen to give you a comprehensive grasp of hacking but to rather give you a starting point in the most important fields. If you want to hack, you're going to need to branch out into all the different fields from these starting points.

• Man in the middle
• SQL injections
• Packet sniffing
• ARP poisoning
• Buffer overflows
• SSH
• Public and private key cryptography (RSA, AES, DES, Blowfish)
• Cryptographic Hashes (MD5, SHA1, SHA2)
• Proxies
• DOS attacks
• Reverse engineering
• Worm / virus / trojan
• Router / hub / switch
• Networking OSI (TCP, IP, UDP, ICMP, ARP protocols)
• Port scanning (stateful filters, half-open scans, open/closed/filtered ports)

Hackerthreads.org has "start here" thread with a collection of links to actual articles on topics such as these for newbies. If you're looking for material to read on a topic, or material to read in general, you can start there.

When you want to start actually doing stuff, you're going to need tools. The following are interesting/handy tools of the trade. Remember, don't think that you have to stop learning when you start using tools. You can learn a lot from the tools you use. Visit a tool's homepage and read on what it does. More importantly, if the tool offers a complex function/feature, read articles on how it does what it does. Most tools come with their own tutorials/manual on how to use them that explain what the tool does and provides some descriptive information about why what it does works. Read it.

• wireshark
• nmap
• nessus
• ettercap
• nemesis
• hping
• dsniff
• Cain & Abel

For a larger list of useful tools, see the list of tools included in Backtrack 2.0 (a Linux-based security-auditing oriented OS) and the tools included in Arudius (the parent OS of Backtrack).

Unfortunately, once you start using tools reality will kick in and you may have to decide which operating system you're going to use. Before now I've said nothing specific to any specific operating system or software, but unfortunately not all tools work for all operating systems. Most of them can be run on both Linux and Windows, and a lot of Linux programs can be run on Windows with Cygwin (which requires Linux knowledge to use effectively), but the deeper you get into actually doing stuff the more OS-specific some things are going to get. I'm not going to officially endorse one operating system over another because an operating system itself just another tool, but I encourage you to do hands-on research and to select your favorite.

A list of recommended operating systems to try would include one or two basic systems from each major family. Linux: Ubuntu/Debian, Fedora, Arch, FreeBSD, and the popular Windows and Mac operating systems. Many more Linux and BSD distros exist, but if you're new to hacking then odds are that you're not looking for the more complex/powerful ones, that was just a beginners list for those who don't know what to try. (If you know which distro you want to use, you don't need a recommended starting point. Use what you already like.) Feel free to hop around operating systems for a time. When you find one you like, and you know why you like it, stick with it. Practically, your operating system will limit what you can do, I advise that if you decide to stick with Windows, you at least give Linux a serious try. There's a lot to be learned from it, and like all Unix-like systems it will inherently be more hacker-friendly. But the choice is yours. Use what works. Best yet, keep more than one OS around and use multiple OSs that work.

Good luck in your studies. Have fun with them. Be responsible with your knowledge. And when you can, contribute back to the global hacking community that's provided you with all the information, articles, and tools you've been able to utilize.

• 2WIRE made a decision to only use numerals in their customers' default 64-bit WEP network setup.
• In doing so, the necessary time for launching a brute force attack against such a network is decreased from about 3.6 weeks to about 5.5 hours.
• These networks are easily identifiable via a default SSID that starts with "2WIRE".
• Despite the advantages this compromise of keyspace gives the attacker, there are still many faster (but more complicated) ways to break a WEP network.

• is faster (20 minutes possible break times)
• requires active attack (attacker must collect packets for a long time)
• requires more specific hardware/firmware (requires injection mode)
• is more complicated / less reliable

• is longer
• does not require active attacks, a few packets can be saved and attacked later
• requires less specific hardware/firmware (only monitor mode required, this is very standard)

I will use the *nix tools fdisk (the Windows version of fdisk will not suffice) and dd, and consequentially assume that the reader has minimal *nix experience and access to some form of a *nix like system. Linux live CDs are adequate, as will (I believe) OSX. The *nix system will be used to perform the delicate initial partitioning and the partition clones thereafter.

I always dual-boot Windows and Linux, keep a third partition around for experimenting with other operating systems, and have a fourth partition blank. All four of these partitions are the exact same size, which offers me flexibility in moving them around. The biggest advantage is that it allows me to perform a byte-for-byte clone any one partition onto a second partition, perform whatever perverse thing I'm experimenting with on the first partition, and then restore it if something goes wrong. Or I can just boot straight to the new copy of the partition I cloned. Somewhat time consuming, but simple and error-proof.

I know this concept may strike some as a waste of time and space, but it's not inefficient as it may sound. Cloning a 20GB partition can be done over lunch and, like many others, I have a hard disk exclusively devoted to operating systems, no one of which needs more than 25GB.

There are several reasons why you might want to backup an entire partition. The need to do so for a *nix system is less pronounced, because the flexibility of *nix systems lets you do a file-level copy between partitions without adverse effects. But doing a byte-for-byte direct copy isn't much longer than a file-based copy, and removes any of the file-based copy complications. As well, Windows systems are attached to their partitions and if they are copied on the file level to a new file system they will not work, so doing a byte-by-byte image of a Windows system is almost a must for backup purposes.

The problem, though, is that if you rely on a partition manager like the default Windows manager or GParted (which is the default partition manager in the Ubuntu installation process) to create your partitions for you, as odd as it may seem, you aren't guaranteed to get partitions the exact size you specified. I don't know the details, but creating two 20GB partitions does not guarantee you of getting two partitions of the same size. Thus when you go back to try and clone one partition to another you may discover that the destination partition is, say, 8MB smaller than the source partition, and there will be hell to pay.

Creating Precisely-Sized Partitions

• Open the disk to partition with fisk:# fdisk /dev/sdaUse the "p" command to get a printout of my current table. If the disk is new, the printout should be empty.
• Determine how large you wish the partitions to be. Create a new partition and choose the starting first sector (use the default if you are creating them sequentially). Then select the last sector by using the +XG to indicate that the last sector should be X gigabytes worth of sectors after the first. This should work with both primary and extended partitions, with one exception noted below.
• Exception: There is a special partition that requires a non-default starting sector. The first partition within an extended partition will start in the same cylinder as the extended partition marker, and thus share some space with said marker and not be the exact size specified. To correct this, create the first "inner" extended partition one sector after the beginning of the "outer" extended partition. This will result in a few bytes of wasted space, but if both partitions start on the same sector then size of the final partition will be slightly too small.

Copying Partitions

• Decide which partition will be the source and which will be the destination. Use dd to copy from the source to the destination:# dd if=/dev/sda2 of=/dev/sda4 bs=8M

  A key parameter here is the "bs" option, which tells dd how many bytes to read and write each time. Read/write operations to disks are relatively slow and have significant overhead so you want to make each read/write operation worth your computer's time. I've found 8MB to be about the most efficient block size to use for each read and write. If you fail to specify a value then the default of 512 bytes will be used, this can make the process take on the order of 100 times longer to finish.

Obviously, copying partitions also applies to copying entire disks if the disks are the exact same size. This can be used make manual backups of entire drives.

At a glance ABeka may seem like the perfect answer to a lot of home schoolers' needs. They provide the books, materials, instruction, grades, and a diploma. All you have to do is send them a few thousand dollars per year and grade the student's quizzes with an answer key ABeka provides.

But for all ABeka does, there's a lot they don't do. I'm an ABeka high school student, and everything I say comes from three years of experience in ABeka's high school program, and I say that ABeka is not all they're made out to be. (Note that I only spent three years in ABeka -- I'll explain later.)

Like a lot of students, I joined the ABeka high school program my freshman year because I needed the instruction their DVD courses offer. My mom's teaching was adequate until then, but she had three younger kids to take care of and home school as well and the material I was covering in school was getting harder for her to explain. So when I started high school, we decided it would be easier for both of us if I did all my schooling via ABeka. We did the same research that basically all other prospective ABeka students have done, and they appeared to be a solution for our needs. As it turned out, we didn't know as much about them as perhaps we should have.

I took classes at a community college during high school. Not being the type of person who wanted to take two classes when one would suffice, I asked ABeka if they would give me credit for my college classes and count them towards my high school record. This seemed like a reasonable request, since every public and private school I know of does so, on the grounds that a college class should meet the standards for a high school class.

But no. My college classes may have been good enough for UC Davis and UC Berkeley (the two schools that accepted me when I transfered out of community college years later), but they were not good enough for ABeka. ABeka said that they would not give me credit for college classes, and, when pressed for the reason why, said that it was because they could not validate that the classes I took would satisfy their standards. That is, seriously, what we were told. My college classes weren't veritably good enough for their high school requirements.

Now, I could understand why ABeka might frown on an anthropology class, biology class, or any class in that general area because of the philosophical and (potentially) anti-Christian teachings commonly associated with such classes (ABeka is, after all, a Christian school) but I was asking ABeka to accept computer and math classes -- classes that carry no such philosophical baggage. In fact, they were classes that ABeka didn't even offer but that I would need for my college major later in life. (Ironically, ABeka is big on "preparing you for college", by the way.) It is standard procedure for kids in high school to take a community college class when their high school doesn't offer an equivalent class –- I've shared classes with a couple of them myself - but ABeka apparently doesn't see fit to accommodate anyone in this area, and their refusal to credit students for college classes boxes some students into a very tight corner, as I'll explain later.

Along the lines of ABeka's high standards, they're very anal about problem solving methods. I happen to be gifted in mathematics. Since an early age I've always excelled in math; I was actually factoring and solving elementary Algebra problems by age 8 when most kids are doing arithmetic. Math and logic come naturally to me and I usually solve problems quickly and with minimal work.

As it turns out, doing so is not a practice ABeka encourages. They wanted to see every little step and sub-step of my math work. I would sit down and breeze through a test with 98% accuracy, and lose 10% because I "didn't show enough work". I can understand that, as the graders, they need to see some work between my beginning and ending steps, so I would always show my work at important intervals. But I didn't show enough, even though anyone looking at what I did could tell what I was doing. I could combine three steps in my head and turn what they deemed an eight-step problem into a four or three step problem just by my normal way of solving problems. I wouldn't condense the steps too much, though, and would usually include a step or two more than I personally needed to just for good measure. But I would, consistently, get scrawled red-ink notes on my tests informing me that I wasn't showing enough work because doing work, showing the important steps of the solution, and getting the correct answer wasn't good enough. If I were shortening 10 step problems to four step problems I might see their point, but, like I said, I wasn't doing that. I can recall multiple instances where I actually lost points for shortening a four-step problem down to a two or three step problem.

Wanting to see the steps a student uses to solve a math problem is reasonable, but ABeka wasn't insisting I be reasonable. They were insisting I memorize and regurgitate their step-by-step solutions.

Throughout ABeka's math courses, I found myself painfully trying to find extra sub-steps to write down, so that I would actually get full credit for my work. There were many tests where I actually lost more points to not showing enough work than to making mathematical errors.

Unfortunately, this is very typical of ABeka. They don't encourage creativity and ingenuity; they encourage memorization and regurgitation. Understanding math isn't important, following steps 1, 2, and 3 is. That's a horrible way to teach math. At the end of such a class, a student will not have learned anything life-applicable, they will have learned how to memorize math steps. And, as a math major, I'm here to tell you that that flat out doesn't work. Ask any math student or math professor at any university and they'll tell you that that learning method isn't worth beans to students.

Another issue I have with their math department is that they only offer three real years of traditional, consecutive math study, their fourth year is devoted exclusively to consumer math –- if you opt to take math at all. That's fine, I have nothing against people taking consumer math, but not everyone benefits from it. No disrespect to anyone who has taken consumer math, but anyone who plans on majoring in something science, engineering, or math related does not want to waste an entire year on consumer math. It isn't going to help them in anything. If they're going to be an engineer, they obviously have the math skills necessary to understand consumer math as it comes in life. What they need for their careers is a strong understanding of trigonometry and calculus. They have so much math they'll need to study they can't afford to spend a year not progressing towards higher math.

But ABeka doesn't offer calculus. The highest level of math they offer is a hybrid trigonometry/advanced geometry/pre-calculus class. If you could just go down to the local community college and get your calculus class that way it wouldn't be so bad, but, as I discussed earlier, that isn't exactly an option. ABeka won't accept college classes, so you're stuck with what they offer unless you double up and do ABeka's full school load in addition to calculus at college. Possible, yes. Reasonable? Not really.

If you'd hoped, in lieu of getting any calculus, to get a good, solid trigonometry foundation (which, believe me, you future engineers and mathematicians will need), you're in for a disappointment. Their hybrid trigonometry/advanced geometry/pre-calculus class is, in my opinion, the worst math class they offer. They try to cram too much into one class, and the class as a whole is devoid of direction. You have a semester of trigonometry, then you have a semester of geometry, and at the end they announce that you're ready for calculus. I've taken college pre-calculus, and it's nothing like what their pre-calculus is. So for the record, you're not usually ready for calculus by the time you're done with that class. If you have the option of doing so without hurting your planning, take a real pre-calculus class at your community college your senior year of high school. It'll get you better prepared for actual calculus and it'll help keep your mind in shape during your year of vacation from math at ABeka.

Also, I'd go so far as to say that their hybrid trigonometry/advanced geometry/pre-calculus textbook(s) are the worst textbooks I have ever used. The books are confusing, very poorly organized, vaguely worded, and sometimes just ramble about nothing that make sense. A good math textbook will be something (if you go on in a field related to math) that you reference in later years when you have a question on that topic. I myself have referenced every math textbook I've used since Algebra II -- except their trigonometry/geometry one.

Along the lines of bad math classes, trigonometry/advanced geometry/pre-calculus isn't the only bad one, so are Algebra I and II. The Algebra series is almost the same subject both years, as best I could tell. Half of Algebra II is contained in Algebra I, just a little differently, which logically means that either their Algebra II moves back to overlap traditional Algebra I or their Algebra I moves ahead to overlap traditional Algebra II. Anyone familiar with ABeka definitely knows the answer to that. (For non-Abeka’ers, Algebra I moves ahead. ABeka never reaches backward for anything. When in doubt push too fast and slow down later. That is their motto.) Students don't get the opportunity to take math gradually and let it grow on them; they get it shoved into their face. There's a difference between memorizing math and understanding math. Students can memorize math in the same way they memorize poems, and then forget it a couple years (or weeks) later. Math, taught properly, shouldn't be like that. What good is it that way?

The algebra textbooks are nothing to brag about either. They're poorly organized and confusing. Woe to the student, or mother, who doesn't have the DVDs and opts to learn the material straight from the book. I taught myself exclusively almost all of the math I learned in school through their 8th grade math level, but, once I hit their Algebra I textbook, it all came to a shuttering halt. I couldn't teach myself the material any more, and that prompted us to to sign up for their video program. Their math textbooks are good and I would recommend them up to 8th grade. After that they're horrible and I would recommend you look elsewhere.

(I've heard many other people voice the exact same thing about ABeka's textbooks. In the beginning I wondered if it was just my mom and I who didn't like the difference between ABeka's lower grade math books and their high school text books, but I've met a lot of people who agree. I've even had people e-mail me, after reading what I say, who say the exact same thing, "ABeka was great, right up until high school.")

For those who don't know me, and for those who do know me, let me remind you, I'm a math major. Math is what I do, math is what I understand, and math is what I've studied. I would confidently say that I'm more than qualified to speak on their math program. And doing so, I grade it a C. Sure it could be worse, but that's almost a failing grade. (I guess it's better than it sounds. A C is, after all, by ABeka's standards, about, what, an 85%?*)

* This is meant to be funny. ABeka students won't find this funny, though, because this is too close to reality to be funny.

Now, leaving the realm of math and going to the complete opposite side of the spectrum...

Their English program is somewhat insane. Each year's English class is basically two classes rolled into one. It was like they couldn't decide whether to focus on grammar or literature, so they just decided to get the best of both worlds and decided to do both. Looking back, I think that English was by far their most intense subject. There was always grammar homework to do, literature to read and comprehend, and poems to memorize. Constantly, constantly, constantly. Write this, memorize that, etc. Due to the amount of material covered, English had about twice the number of quizzes of any other subject. There were actually quite a few classes composed of nothing but a pile of 15-minute quizzes.

I'm all for students having good grammar and being able to write well because it's a necessary life skill. I think less highly of literature, but it has its merits. But ABeka needs to decide what they want to do with their English program. Forcing students to concurrently deal with two nearly full time subjects is just stupid. I can't help but notice, at my college, that the English Writing and English Literature classes are in completely separate categories, and I don't think that's by chance. One class. One subject. It works best that way. Someone should point that out to ABeka.

I don't know why the four years of high school English aren't split into two years of each subject. The fact that they try to teach grammar in English for all four years of high school is just weird. I mean, you don't need four years of English grammar. Eventually you need to concentrate on just writing (enough with the sentence diagrams already). But no. They try to fit the exact same material into each English class for four years. I think they should just split their classes up into two years of writing and two years of literature (or some other ratio). The writing classes would consist of learning to write, and the literature classes would consist of learning to comprehend literature and poem memorization. Each class would be object-oriented, and just maybe you wouldn't find yourself diagramming sentences going into your senior year. I have never heard of anyone else having to do that.

Overall, their English program seems to be aimless. You do four years of it, and at the end you've spent countless hours writing the same essays multiple times, diagramming the same sentences over and over, and memorizing of poems that, honestly, you don't remember a tenth of by the end. For a private school with their reputation, it sure is easy to go through their program and not improve your writing abilities. It could be argued I'm proof of that.

This brings up yet another subject I want to point out. ABeka is known for being tough, which isn't bad. Tough isn't a bad thing, in and of itself, and I personally like tough. My problem with ABeka is how tough they are in combination with how inflexible their schedules are. They don't give students homework to complete by the end of the chapter, or by the end of the week, rather, by every class the last assignments are due and new assignments are issued. There's no buffer period for students to manage. If you do all the homework and assignments for each class, every day is an exact repetition of the last.

In college, and I have report that this is similar in public schools, my workloads rise and fall in each subject over each week. Each day has different priorities and different subjects that need to be studied. In ABeka, it's the same thing every day. Every day you have to do x, y, and z, and it has to be done today so that tomorrow you can do the new and improved X, Y, and Z. Not only does it not allow for personal interruptions in life it gets very old very fast. If you're not a good "just grinding away at it" person, you'll get bored of ABeka in about a month. It'll become a seemingly endless, boring chore.

Like I said at the beginning, I only did three years of ABeka's high school program. I left at the start of my senior year. But hopefully, by now, you understand why I left. I didn't leave because I was a failing, lazy student. I left because they couldn't meet my needs. I needed math and computer classes; they didn't provide them and wouldn't accept college alternatives. Their grading was obnoxious and discouraged creativity and originality. Their English workloads were irritatingly heavy with no sense of direction or real accomplishment and distracted me from beneficial activities. And in general, I grew to simply loathe their classes.

I left Abeka a straight A student after three fairly miserable years and joined the ACAEA in my senior year, graduated half way through the year, and promptly started college.

On that note, going from ABeka's high school program to college was a huge change. And I have to say, in all honesty, ABeka's scholastic training didn't help a bit. Their environment was completely different from college. Nothing ABeka teaches or encourages by way of study habits and scholastic conditioning will be useful in any normal college. And nothing they say you'll need in college you actually will need in college. The teachers in ABeka's video lectures make the occasional remark about how you're going to need skill X or knowledge Y to survive in college and/or the rest of life, and nine times out of ten it's completely bogus. The exception is their Bible classes. Those are by far the most practical and best classes they offer.

In college, they're interested in creativity and ingenuity. They're concerned that you get the right answer, rarely how you got there. Your homework, if you even have any that is obligatory to turn in, is collected sporadically in chunks, allowing you to pick it up and do it at your own pace whenever you need to. The focus is to gain understanding and brainpower, and they're usually pretty relaxed about it.

In summary, here are my complaints about ABeka Academy. I've talked a lot, but this list summarizes the main points that I've talked about:

1. ABeka will not accept college classes.
• They don't offer calculus.
• Their trigonometry/advanced geometry/pre-calculus math class is bad, and doesn't prepare you for when you eventually do take calculus.
• Their algebra series is too aggressive.
2. Their English program is heavy, time consuming, and redundant.
3. Their overall teaching style is too anal and procedure oriented.
4. They don't prepare you for real life, despite the fact they incessantly insist that they do.

How do you know if you're right for ABeka? If you're a casual, independent, questioning person, ABeka probably won't be a good fit. Conversely, if you like memorizing 15 20-line poems a year, having your homework dictated to you day by day, and taking only three real years of math, you probably will fit with ABeka. And that's fine. I'm not saying ABeka is morally evil, I'm just saying that I personally don't like them. And I think that a lot of other people, judging from ABeka's turnover rate, don't like them either, but don't know enough when they begin to know that.

But, ultimately, it's all about education. Never forget the primary function of school. School is to teach you knowledge and, most importantly, expand your understanding. Pick what works with your personality and educational mindset the best.

The thing, though, is that I wonder if I'm delinquent in this area because I don't make strong symbolic associations that other people do.

Take, as my main point of interest, flags. Flags and the graphical symbols they bear were designed for the purpose of easy identification, usually from a distance. Images have no language barrier, and having a simple picture to represent you and the people you are associated with makes it easy to label people and places. Whether it's old-style battles where flags would be carried, maps with flags on each country, or just a display of patriotism for your country, they're good for communicating the simple concept "This flag represents the people X."

That I understand.

What I don't get is when people turn a symbol itself into a sacred image of whatever it represents.

Take religious idols, for example. Basically every religion has had some sort of idol system and usually those idols are sacred, having special rules like "do not touch" or "whenever you see it you must sacrifice to it", or whatever. But, through the history of major religions, those idols were rarely (as far as I know) actual gods themselves. Rather, actual gods were said to have dwelt in the seas, the air, the sun, or really anywhere else. But although they weren't gods, people would treat the idols as if they were. That rock over there is insignificant and the atoms that compose it uninteresting, but the atoms that compose that specific idol are sacred and should be treated different.

Back to flags. I don't know about other countries, but here in America some people basically treat the American flag like an idol. It is not to touch the ground, it is to be fully raised initially even when flown at half-mast, it is not to be touched with a hand that has touched raw meat in the past 24 hours, or whatever. Rules, rules, rules, and rules some people worship. If you let a flag brush the ground and actually don't really care about it, you're disgracing their nation and you risk assault by a high caliber weapon. (Note that I'm not talking about people's view of America itself, I'm just talking about their view of it's flag.)

But all that is just about a symbol. A symbol that represents something else. And what I don't get is how people can elevate a symbol to the position of, if not sometimes actually higher than, that which the symbol represents. That just makes no logical sense to me.

A symbol, by indisputable definition, is something that is not what it represents and it merely serves as a placeholder to be used when the thing itself would not suffice. For example, you can't fly the country of America from a pole, at least not without some serious hydraulic work, but it would be easy to simply display a picture that represented the United States, thus a flag makes logical sense. But treating the flag as if it were sacred?

If a symbol is as sacred as what it represents, where does it end? If a symbol (in this case, a flag) is as sacred as that which it represents (America), is the symbol the original symbol (for example, a bumper sticker of a flag) just as sacred? If Symbol1 = Object, does Symbol2 = Symbol1 = Object? Is a bumper sticker just as important as a fifty-foot flag? Is a picture of a bumper sticker in a catalogue just as sacred as the nation of America itself?

A flag is a piece of cloth with a logo on it, and that logo just represents America. But it's only a representation of America, America itself relies a grand total of nothing on the well-being of that flag. There are an innumerable number of flags around, all made of pretty cheap material, many not even made in America, all of which have no impact whatsoever on the operational status or well being of anything related to America.

If I see someone burning a flag to make a political statement, I don't burst arteries, I'm just glad they're taking out their anger in a way that doesn't hurt anyone. They're burning a symbol, a symbol that can be replaced for $7.99 USD at one of many stores within a 10 minute drive.

I think I understand why people make those symbolic connections, though. I'm not a psychologist, but I think it's common knowledge that most people love having something physical over something that's abstract. The United States is abstract in the sense of being huge in physical area, population, philosophical ideals, laws, customs, etc, but a flag is a small, physical, comprehensible object, and people like that better. It's easier to comprehend and imagine a flag than it is 2,263,960,000 acres of land, 300,000,000 people, and all the civil, social, political, and technological complexities they have. People can look at a flag and be proud of it, but they can't look at America and be proud of it, they have to just imagine it and be proud of it.

I suppose I do understand why people elevate symbols to the levels of that which they represent, I just think it's stupid.

I guess I was born without whatever gland that's responsible for that type of emotion because I have never made a big deal out of symbols. They're just... symbols. I'd be ticked if you attacked America, but I really don't care if you burn our flag. One down, fifteen million to go. Big deal. It's the same thing as yelling "**** America". Your complaint has been duly noted. I probably knew that you hated America before I saw you burn a flag, I still know that you hate America. You've done nothing more than communicate your hatred for America, and the odds are pretty good that I don't care about your opinion to anyway.

Flag burning is stupid. When you burn a flag, all you do is communicate that you hate the nation (or organization) that flag represents. But there are many ways that you can communicate that idea, most of which are more efficient and don't make you look quite so stupid. Burning a flag is just a overly-passionate person assigning unwarranted emotional attachment to a flag... which sounds familiar.

But in the end, regardless of the logical sense an emotional connection to a symbol may or may not make, people have the right to do it. If you want to make a flag sacred, you can. But, similarly, if you want to burn a flag you can do that too. Both acts are stupid in my opinion, but you're free to do both. All I really ask is that you try your best to keep your illogical, raging emotions to yourself. Not only do I not care, you're probably wasting time and effort from doing something productive.