Brad Conte » Computers & Tech http://bradconte.com Why know the ordinary when you can understand the extraordinary? Wed, 16 May 2012 16:58:57 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 A Letter to My Congressmen Regarding SOPA and PIPA http://bradconte.com/congressmen-letter-regarding-sopa-pipa.html http://bradconte.com/congressmen-letter-regarding-sopa-pipa.html#comments Wed, 18 Jan 2012 21:45:16 +0000 Brad Conte http://bradconte.com/?p=348 self-imposed blackout in protest.

I strongly oppose these bills. I do sympathize with the fact that multimedia companies have their legal and moral rights that are violated by mass-piracy, but these bills take far too drastic action to protect the multimedia sector. I won’t re-iterate 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 out.
  • It’s easy to read – about 370 words and about 2/3 of a page when printed, 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. And that’s all you need to give a summary of a position. This makes it also 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 that my position didn’t spell doom and gloom for the opposition. In fact, I trivialized their position as simply being for “convenience”. It isn’t the annihilation of multimedia companies it’s simply 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 hinted at 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 strong and 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 mine. If I would be screaming in opposition to it, 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 them. (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. I’m sure that some of you can do better.]]> http://bradconte.com/congressmen-letter-regarding-sopa-pipa.html/feed 0 Redirect input and output for an existing process on Linux http://bradconte.com/redirect-input-output-for-existing-process-on-linux.html http://bradconte.com/redirect-input-output-for-existing-process-on-linux.html#comments Tue, 01 Mar 2011 23:51:17 +0000 Brad Conte http://bradconte.com/?p=291
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. Another example would be if you needed to redirect the output of an existing process to a file on

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:
$ ls -l /proc/TARGET_PID/fd/
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
$ mkfifo /my/file/name
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:
$ gdb -p TARGET_PID
Within gdb, close the file descriptor using the “close()” system call:
(gdb) p close(TARGET_FD) $1 = 0
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 a 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.
(gdb) p open(“TARGET_FILE”,0600) $2 = TARGET_FD
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:
(gdb) q
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.]]> http://bradconte.com/redirect-input-output-for-existing-process-on-linux.html/feed 0 FoxyProxy, Firefox 3.5, and DNS Leaking http://bradconte.com/foxyproxy-firefox-dns-leaking.html http://bradconte.com/foxyproxy-firefox-dns-leaking.html#comments Sat, 14 Nov 2009 04:18:30 +0000 Brad Conte http://bradconte.com/?p=207 [Update: Jan. 24, 2010] The DNS leaking problem described in this article applied to FoxyProxy v2.14. On Jan. 12, FoxyProxy v2.17 fixed the problem.


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:
network.proxy.socks “” network.proxy.socks_port 0 network.proxy.socks_remote_dns false network.proxy.type 0
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:
network.proxy.socks localhost network.proxy.socks_port 8080 network.proxy.socks_remote_dns true network.proxy.type 1
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:
network.proxy.socks “” network.proxy.socks_port 0 network.proxy.socks_remote_dns false network.proxy.type 0
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:
network.proxy.socks network.proxy.socks_port 0 network.proxy.socks_remote_dns false network.proxy.type 1
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 ensure 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.]]> http://bradconte.com/foxyproxy-firefox-dns-leaking.html/feed 0 Three Tips for the Linux Terminal http://bradconte.com/three-tips-for-the-linux-terminal.html http://bradconte.com/three-tips-for-the-linux-terminal.html#comments Sun, 11 Jan 2009 10:11:47 +0000 Brad Conte http://bradconte.com/?p=79
  • 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”.

    Example:
    user@host : /some/long/path/you/don’t/want/to/retype$ pushd /some/other/path/ /some/long/path/you/don’t/want/to/retype user@host : /some/other/path/$ [do stuff] user@host : /some/other/path/$ popd /some/big/long/directory/you/don’t/want/to/retype user@host : /some/long/path/you/don’t/want/to/retype$
    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.

  • 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. Most shells (all the ones I’ve come across) have a simple means of pasting text into the terminal, but not all have an elegant means of getting text out of the terminal. Yes, highlight-and-middle-click is often an option, but it’s a) not always feasible, and b) not always convenient. Remember, this is the terminal, you don’t necessarily want to be using your mouse. “xclip” removes the annoyance of using the X clipboard.

    xclip can read and store to the clipboard from the standard input. As well, it can output the current contents of the clipboard. Since xclip can manipulate multiple clipboard buffers, the argument “-selection c” must be used to select the standard X clipboard. The “-i” and “-o” arguments tell xclip whether you are inputting or outputting clipboard contents, respectively.

    Example:
    $ pwd /some/long/path/you/don’t/want/to/retype $ ls /some/path | xclip -selection c -i
    You may now paste (standard Ctrl-v, or right-click -> paste) the directory listing where ever you choose. Another example:
    xclip -selection c -o | cat >> /some/file
    This will concatenate the contents of the clipboard to “/some/file”.

    If you only use yourself using xclip to manage the X clipboard, you might want to consider aliasing “xclip” to “xclip -selection c” to make it simpler to type. Or you could take it one step further and alias “xcopy” to “xclip -selection c -i” and “xpaste” to “xclip -selection c -o”, or something similar.

  • 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.

    Thankfully, “head” and “tail” 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. Using -N outputs all but the last N lines.

    • tail -n N — by default outputs the last N lines. Using +N outputs lines starting on the Nth.

    Example:
    /tmp $ cat example 1 2 3 4 5 /tmp $ head -n 2 example 1 2 /tmp $ tail -n 2 example 4 5 /tmp $ head -n -2 example 1 2 3 /tmp $ tail -n +3 example 3 4 5
    Note that tail’s complement mode requires you to specify the first line number to include in the output. Thus if you want all but the top N lines, actually specify N+1.
]]> http://bradconte.com/three-tips-for-the-linux-terminal.html/feed 0 Bash Path Hashing http://bradconte.com/bash-path-hashing.html http://bradconte.com/bash-path-hashing.html#comments Fri, 05 Sep 2008 22:41:29 +0000 Brad Conte http://bradconte.com/?p=63
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.

Example of Bash storing the full path of a script and not recognizing a new one.
(This image can suffice stand-alone — feel free to redistribute it.)

Thankfully, however, the hash table is easily manipulated — by the builtin 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:
If the name is neither a shell function nor a builtin, and contains no slashes, bash searches each element of the PATH for a directory con- taining an executable file by that name. Bash uses a hash table to remember the full pathnames of executable files (see hash under SHELL BUILTIN COMMANDS below). A full search of the directories in PATH is performed only if the command is not found in the hash table. If the search is unsuccessful, the shell prints an error message and returns an exit status of 127. [...] hash [-lr] [-p filename] [-dt] [name] For each name, the full file name of the command is determined by searching the directories in $PATH and remembered. If the -p option is supplied, no path search is performed, and filename is used as the full file name of the command. The -r option causes the shell to forget all remembered locations. The -d option causes the shell to forget the remembered location of each name. If the -t option is supplied, the full pathname to which each name corresponds is printed. If multiple name arguments are supplied with -t, the name is printed before the hashed full pathname. The -l option causes output to be displayed in a for- mat that may be reused as input. If no arguments are given, or if only -l is supplied, information about remembered commands is printed. The return status is true unless a name is not found or an invalid option is supplied.
]]> http://bradconte.com/bash-path-hashing.html/feed 0 How to Review a Linux Distribution http://bradconte.com/how-to-review-a-linux-distro.html http://bradconte.com/how-to-review-a-linux-distro.html#comments Thu, 17 Jul 2008 01:54:47 +0000 Brad Conte http://bradconte.com/?p=61 hundreds of Linux distributions, each one being nothing more than a different collection of software and configurations running on top of the Linux kernel.

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.

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 from-disk install of the distro? (See later points.)
  • 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 would be foolish to overlook reviewing the packages themselves. The packages will be composed of compressed archives, arraigned 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 these concepts can look them up.

    How the operating system uses run-levels is a more complex subject, yet a more 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 technical writer.

If you feel unable to address many of these topics in your review then you probably have no business reviewing the distro and are not as familiar with it as you should be. Many people want to pop in a CD, install the distro, play with it for 40 minutes, and then write a review about it. Unless you did your research beforehand and you made very good use of those 40 minutes, you’re not qualified to offer a review. Spend your time learning more about the distro rather than writing about what you do know.

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, and apparently this will come as a shock to some, 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 over 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.

    Second, the comparison you can make between distros is in how they manage drivers. Some distros have special programs to help the user manage and install drivers. Some distros have lots of automatic scripts set up to help ensure the user never has to manually touch their xorg.conf file, some distros demand the user get involved with the xorg.conf file.

    Driver management is a valid comparison point, but generic “I tried wireless device X and PCI device Y” tests are basically worthless. “Here’s how easy/hard it is to install Nvidia’s video driver (module version or userland version, take your pick), here’s a short summary of what is expected of you to do so, and here’s what was done automatically by tools”, by contrast, is very informative information.

    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”, namely, one or two little problems that often need to be ironed out of a fresh install of the system and are easily solvable by a user with Linux 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 do not count, they only last five minutes and will likely be fixed in one of the upcoming releases anyway. (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 inane 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(n’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 is thus redundant information. And, realistically, nobody cares about it, because most of them will choose whatever distro-neutral artwork they prefer anyway. 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’m not a fan of reviewing the installation process of a distro. 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.
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. (If it is very long, it’s probably more of a guide than a review. Keep manuals as manuals, and reviews as reviews.) If you have an actual depth of information to convey, you can say a lot by using well-crafted sentences.]]> http://bradconte.com/how-to-review-a-linux-distro.html/feed 0 A Simple Partitioning Tip http://bradconte.com/partitioning_for_backup.html http://bradconte.com/partitioning_for_backup.html#comments Tue, 26 Jun 2007 07:57:02 +0000 Brad Conte http://test.b-con.us/tech/partitioning-tip
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/sda
    Use 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.]]>     http://bradconte.com/partitioning_for_backup.html/feed 0