If you are coding in C/C++, you can give OpenMP a try. I haven’t tried it yet, but I surely want to, as it seems extremely easy: you just add a couple #pragma instructions in your code and it automagically parallelizes it for you! Really, check our their tutorials!

For those that are more Python-oriented, like me, you can try Parallel Python. Not only it can explore the available cores in your computer, but it may also use cores in other computers connected in your local network! I did some testing of this and it worked remarkably well. I plan on doing something fun with this someday.

Last, but not least, if you just have to run the same application several times and would like to use your several cores instead of queueing it all on a single one, then you might want to learn something about xargs… It can do the job for you!

Detailed explanation of the use of xargs is out of the scope of this blog post, so I’ll just point you to the -P switch: it controls how many simultaneous processes it should run at a time. As soon as one terminates, it spawns another one. Great, isn’t it? Credit goes to this blog.

What about you? Any tips for exploring the processing powers of multicore CPUs? Share in the comments!

My solution for a while was to use screen. This way, I reconnect and continue where I stopped. Better, but the timeouts are still annoying as my terminal becomes unresponsive and I have to close it and reconnect on a new one.

So I decided it was time to solve this. Turns out a simple Google Search found the solution on this blog, and it is dead simple:

Edit your ~/.ssh/config file and add a line containing ServerAliveInterval 60. This sends a keep-alive packet every 60 seconds, which is more than enough to keep your connection from timing out.

Painless, right? Now go and configure your machine, too!

One day I was determined to make file uploads work, and started Googling. I didn’t really find out an easy way to do this, but found two very friendly scripts that do exactly this. They’re only a single file, so it is very easy to “install”: just place them somewhere convenient and put it in your PATH environment variable. (Personally, I just copied them to /usr/local/bin)

droopy

The first one is also unidirectional, but on the direction that complements the trick in the previously mentioned post. Droopy allows you to open a web server that displays a single upload file field. Simple as that.

You can just run it without any parameters and receive files on the current working directory, or you can configure the directory and port, along with a display message and even a picture that will show up on the page for your uploaders.

Also, don’t worry about them overriding your files. A quick test will show you that droopy will append numbers to files that would otherwise overwrite your original ones.

quickserve

This one allows file sharing in both directions: download and upload. Quickserve is a little bit more verbose than previous solutions, but not inconvenient in any way.

To serve files, you must provide a upload directory as a command-line parameter, but a smart user will just type in “.” for the current working directory. To serve them, you will need to type in a bit more: --upload=. but perfectly manageable.

Differently from droopy, quickserve will overwrite files by default. This could be a desireable feature, just maybe not as default. To avoid this, add --no-clobber to your command line and numbers will be appended to them.

An ideal command line would be as long as quickserve . --upload=. --no-clobber, but nothing you can’t keep on a conveniently placed shell script.

Conclusions

Droopy is probably your first choice because of its simplicity, but quickserve is a much more complete solution, so I’d grab them both and decide which one to use depending on the situation.

Have you ever tried looking at the history for any page in Wikipedia? It’s beautiful, intuitive, and word-centered. Forget about lines, they’re not suitable for text. Words, however, are.

Example of the word-by-word diff in Wikipedia

Well, version control systems use the line-by-line diffs, which don’t really help when comparing two versions of a text file. What to do now?

I have googled a bit, and found about wdiff. Seemed interesting, but the output was really ugly. I first thought of using it as an external diff tool in git, but gave up. Nice to know it exists, though.

Then, for some reason, I decided to read the git-diff help one more time and, to my surprise, the feature we want is already there! Introducing to you… git diff --color-words!

Sample output of git diff --color-words

Amazing, right? Notice how deleted words are in red, added words in green, and the unchanged text surrounding it in white (or black, if you’re not into dark backgrounds). Much more natural and easier to spot differences than the original git diff! But you should be asking yourself “Am I going to have to write this long command every time?”. Certainly not! Git allows you to create aliases, which I just learned about. You can create an alias named wdiff, and the result is a new command, git wdiff, that perfectly fits our needs! Great, isn’t it?

Here’s two ways to do it:

• Via command-line: git config --global alias.wdiff diff --color-words; or
• Editing your ~/.gitconfig, add the following lines:
  [alias]
    wdiff = diff --color-words


Piece of cake, right? Hope you liked it, and happy word-diffing!

Special thanks to my friend Carlos Eduardo, who helped me find a good way to illustrate the word-by-word diff!

Update: Better tokenization for LaTeX files

It seems that Git 1.6.2 and earlier now support the use of a regular expression to define what is a word for --color-words. Also, the manpage for the .gitattributes file shows that some filetypes already have useful built-in configurations, including the regular expressions in question, and LaTeX is one of those formats.

In practical terms, this means that \section{Title} can now be seen as several tokens instead of a single word, so renaming the section will provide you with a smarter highlighting.

So, if you don’t have a .gitattributes file yet, you should create one. I just found out about them, and it’s pretty cool. It adds other interesting functionalities such as hints on the diffs for which point in the file (for instance, the LaTeX chapter/(sub)section name) those diffs are taking place. The manpages can tell you more about it, so I’ll keep it short. It’s very easy to enable this, just add the following line to a .gitattributes file in your repository (its syntax is very similar to .gitignore) and everything is set for you:

*.tex    diff=tex

Even if your version is older than 1.6.2, the other benefits are much probably available for you and are well worth it, so give it a try anyway!

It’s quite common for programmers to use light-colored text on dark background. It is much more true for those keen on Linux and terminals. That’s because the dark background emits less light, and thus makes it more comfortable for the eyes if you’re going to stare at it for a long time, like we programmers do.

What about reading? Isn’t that just the same? Long hours, staring at a PDF full of dark letters on white background. Wouldn’t it be more comfortable the other way around? As a matter of fact, it is! But how do we do that?

Well, my colleague uses a Mac, and the key combination to invert the colors of your screen apparently is Command+Option+Control+8. Counter-intuitive, I know. More info and a graphical way to do it can be found on this link, which Google helped me find. On Linux, if you use Compiz, there’s a nice plugin that should probably be already installed (I know it is on my Ubuntu) called Negative. It was also enabled by default, and the key combinations are Super+N for the active window and Super+M for the whole screen. If you’re a Windows user… Well, Google didn’t help much, but if you know an easy way to do it in Windows, please leave a comment!

After all this time using Compiz, I finally understand why someone would ever use the Negative plugin… Being a dark background terminal kind of guy, I really wish I had thought of this sooner!

Wouldn’t it be awesome if you could find out how long that process took to run? How about if it were as simple as typing timelast or another command that makes sense to you? Well, awesomeness now exists.

I’ve poked around and have put together a script that, once sourced from your .bashrc, will give you this exact functionality I just talked about. Take a look at a quick example:

[eduardo@dudubuntu:~]$ sleep 3s
[eduardo@dudubuntu:~]$ timelast
3s
[eduardo@dudubuntu:~]$ sleep 90s
[eduardo@dudubuntu:~]$ timelast
1m30s
[eduardo@dudubuntu:~]$ sleep 3666s
[eduardo@dudubuntu:~]$ timelast
1h1m6s

Cool, uh? The source code is available here (sorry about the pastebin, I can’t upload it to the blog). I’d say it is fairly well commented, but feel free to contact me if you’re wondering what is going on under the hood.

Well, here it goes. First, you need a pair of keys for your local machine. In case you don’t have one already, type this to generate one:

$ ssh-keygen -t dsa

When asked for a password, leave it blank (hit Enter). This will create two files: ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub. These are, respectively, your private and public keys.

Now, you want to copy the public key (id_dsa.pub) to the remote machine, and copy its contents to the file ~/.ssh/authorized_keys, which may not exist yet. Makes sure the permissions for this file do not allow reading or writing for anyone other than you. This is essential, as OpenSSH will not make use of it in case it finds it too permissive. This is for safety reasons, and 600 is probably a good set of permissions (read/write only for the owner). The easiest way to do all this is probably the following sequence of commands:

me@local$ cd ~/.ssh
me@local$ sftp username@remotemachine
sftp> cd .ssh
sftp> put id_dsa.pub
sftp> quit
me@local$ ssh username@remotemachine
me@remote$ cd .ssh
me@remote$ cat id_dsa.pub >> authorized_keys
me@remote$ rm id_dsa.pub
me@remote$ chmod 600 authorized_keys


So what I did was send the file using SFTP, appended it to the authorized_keys file (just in case it already existed), and deleted the public key file. I have also made sure the permissions are adequate.

Update: It seems the whole copying-and-setting-permissions step can be replaced by the convenient command ssh-copy-id. It is now as simple as ssh-copy-id username@remotemachine.

Now log out, and try logging back in. If everything goes right, you won’t be asked for a password anymore!

Additional tips for saving keystrokes

Ok, now for the bonus part. How about instead of typing long commands such as this:

$ ssh remoteuser@remotemachine.something.com

you could type just this:

$ ssh remote

and everything just worked? You can configure it so SSH handles all that for you, saving you some keystrokes. Interested? Ok, here’s how to do it!

You’ll need to edit (or create if needed) the file ~/.ssh/config, where you can add all configuration parameters you might want, just like in the server’s configuration file. Here’s a sample:

Host remote remotemachine.something.com
    User remoteuser
    HostName remotemachine.something.com
    ForwardX11 yes
    Compression yes

You could also use * as a host if you wanted to setup stuff for every connection. Sweet, uh?

Hope you liked it! If you want, you can learn more about all this from the same places that I did. Enjoy!

How many times have you wanted to serve a file on an HTTP server for someone to download it from? Well, just install Apache, you’d say. I used to do that, but it feels like overkill. Maybe Lighttpd? I honestly found it was easier to just host it somewhere else than install and configure any of these in case they’re not already in use.

But here’s another solution: use Python! It is installed by default on most Linux distributions, if not all. It is so widespread right now that, if you’re not using it already – be it for programming or as a dependency for something else you use – you will need it sooner than you think. And not only it should already be installed, it needs zero configuration!

Fire up your terminal and try this:

$ python -m SimpleHTTPServer 8000

Next, point your browser to http://localhost:8000. Voilà! You just got yourself a web server! In case you haven’t tried this yourself yet, a directory listing for the current directory should appear. Close it with Ctrl-C when you’re done with it.

Extra tip: you can create a directory under your home such as webjail, or whatever name suits you, and start your webserver from there. Create symbolic links for stuff you want avaiable so you can keep your other files “secret”. Unlike my previous Apache setups with public_html, symlinks do work, so there is no need for hard copies. The only difference from regular files is that they will show a “@” appended to the filename on the listing, but that’s not really an issue, is it?

Ctrl + Shift + N is my favorite shortcut ever on gnome-terminal, but when I am not physically on the machine but working via SSH, it is not nearly as fun. In fact, it is annoying as hell as it opens a new local terminal, and I have to log in again, go to the path I am interested in, and only then being able to do whatever I want to do (which, sometimes, is pretty quick and I end up closing the terminal, just to regret next time I need it again). Thankfully, I found a nice way to solve this!

Normal Use (under Linux)

Well, a friend of mine reminded me of cool switch that is ssh -X. What it does is enable X11 forwarding. In other words, it redirects to your local (from your point of view) computer all X/graphical applications you run remotely; that is, if you run, let’s say, gnome-terminal, it will show a terminal on your computer that is actually running on the remote (again, from your point of view) machine.

Ok, so what do I do with that? How about Ctrl + Shift + N? Cool, uh?

Enough stories, this tip is about opening multiple remote terminals through SSH and only having to log in once. What I do is:

$ ssh -X mylogin@remotemachine gnome-terminal
Password: ...
[Ctrl+Z]
$ bg
$ exit

Ok, that sounded complicated, so I’ll go over it line-by-line:

1. The syntax for ssh is ssh [options] [login@]host [command]. So what I am doing is connecting with the -X switch, and running gnome-terminal remotely. If you provide a command like this, after the process terminates, the connection is closed.
2. I enter my password to connect…
3. By now, the terminal we ran remotely should pop on your screen. Go back to your local terminal and hit Ctrl + Z to pause the ssh process. You’ll get a prompt back.
4. On the prompt, type bg, which unpauses the paused process, but runs it on background.
5. You now close your terminal with exit. It is important to use exit and not clicking on the close button from your window manager, otherwise the ssh process we sent to background will be terminated too, and your remote terminals will disappear. I’m not sure why, but it works like that.

Now you try it… It’s fun, isn’t it? But why, oh why haven’t I just gone with the ssh -X mylogin@remotemachine gnome-terminal & one-liner? Well, because I couldn’t type my password that way. I know there are ways to allow direct login without password, but I have never fiddled with that that’s covered in anoter post. In case you got direct login working, you could use the one-liner.

If you’re not much into GNOME, things should probably be just the same with other terminals. However, if you’re on a Windows machine… fear not, as you can use this too!

Using it under Windows

A friend once told me about a X Server you can install on Windows that, along with PuTTY (a.k.a. the stuff that makes your Windows useful), can be used to make your terminal windows pop as if you were running Linux! (why aren’t you, by the way? )

The name of the program is Xming, and that’s all you should need. He gave me the instructions back then, but it’s been a while, so I found this (30sec tutorial with screenshots) and this (text-only, with some troubleshooting info) on Google, tested it, and it worked nicely. A bit slower than on Linux (and the terminal looked pretty ugly – maybe I needed to install the fonts package), but worked.

Quick note, although it is out of the scope of this post: you could set up some shortcuts on the system tray icon for applications you launch regularly, like this. I haven’t tried it, and it is up to you to learn how. In case you feel like writing a nice tutorial or something, I’d be happy to post it here.

Ubuntu Troubleshooting

I was perfectly able to use the above method to connect to the Fedora machine where I work, but couldn’t do the same to my home Ubuntu, where the X applications never ran. I googled around, and found this blog post that might be useful for people running Ubuntu Server. However, that is not my case, but the interesting part for me was this link on the blog post indicating the necessary configs on /etc/ssh/ssh_config (note it is not the daemon config – not sure why!) which were turned off for me. After that, everything worked perfectly.

On the same blog, there was also this tip for speeding up X11 forwarding, which could be useful eventually.

Wrapping up

Hope you liked it. In case you were wondering, yes, this was what got my friend so excited that made me go ahead and create this blog. Took me a while because I wanted to make it all nicely detailed. So if you get all excited too, I’d love to hear about it on the comments!

This blog is probably the realization of a long latent, dormant idea of having a personal website. A place to put little programs/utilities I tend to do every once in a while, be it as a fancy repository for myself in the future or as a place to share with others; ideas or cool things I found out by myself and, as such, have no way to bookmark in del.icio.us or similar…

It was inspired by a enthusiastic reaction of a friend of mine after I told him of a cool thing I thought of, and which sounded very clever and helpful for me. At that exact moment, I felt the urge to share things with the world, and I went on this blogging spree.

I’m not sure what the future will bring (if I’ll keep this on WordPress or if I’ll eventually take a step further and make a real website), but I plan on posting cool stuff that computer geeks, programmers, linux users and people alike (that should be enough to cover you) might find useful or interesting.

Hope you like it! Please leave a comment when you stop by, it is good to know we’re not writing to ourselves sometimes, and what people think about it!