I love reading git logs! First, because it reveals the people and processes behind software. Software is not just a bunch of code that works (or more commonly, doesn't work...) - it's also a bunch of people crafting something together for a long time. Not only adding features and fixing bugs, but they also refactor, do dirty tasks and ugly workarounds, explaining their motives in the commit messages.

A second, more concrete reason - quick access to git history helps me make better software. It helps me find out when and how exactly a bug was introduced, learn whom to talk to about a certain change or code, or simply find a desired code snippet in a huge repository - even if it was already deleted. Am I stating the obvious here? I guess so! but I do believe that sometimes this tool is underestimated and underused.

Of course, the better we know git's secrets, the more effective use of git history we could make. I'll try to share here some useful tricks I've collected in the recent years... I bet you know some; I believe you may still find some of them useful.

Alright, enough human communication - let the command-line part begin:

1. Find commits by their commit message - --grep

Impress your boss at how quickly you find this commit!

git log -p --grep "nasty bug"

# Feeling lucky? 
git show :/'nasty bug'

2. Search by commit content - -S

This one will show you only commits that contain the provided string in the commit content itself. Super useful!

git log -p -S 'Date.new'

3. Search by author

You know who's responsible for this change you're looking for, so why not use this to ease the search?

git log -p --author='Linus Torvalds'

# Can even use parts of the name or email:
git log -p --author=orvalds
git log -p --author=gmail.com

4. Find by date

git log -p --since=2013-01-01 --until=2012-02-01

5. By path!

git log -p -- path/to/file1 path/to/directory ...

# Add --follow to follow changes through file renames:
git log -p --follow -- path/to/file1

6. Search ALL branches

Lost something?

git log -S 'populate_database' --all

7. Putting (some of) it all together

I actually find such commands useful in practice.

git log -p --author=linus --since=2012-06-01 --until=2013-01-01 --grep fix -S 'Date.new' -- that_directory/

8. A few useful revision-range tricks

a. What's new in my branch compared to remote?

git log -p origin/master..master

# But I like the following syntax better; it's exactly the same but self-explanatory:
# all commits of master branch that are not contained in origin/master branch. 
git log -p master ^origin/master

# Also possible to put multiple arguments
git log -p master ^origin/master ^my_github/master

(Note: I've noticed that zsh needs the '^' character to be escaped!)

b. 3-dots operator: symmetric difference

The less-widely-known-but-very-useful 3-dots operator, shows any commit that is in any of the branches but not in both:

git log -p mybranch...master

# --cherry-pick is often useful to avoid seeing "duplicate commits". 
# common when cherry-picking, where commits identical content get 
# different hashes.
git log -p --cherry-pick mybranch...master

Read more!

git help log
git help revisions
git help blame

The rationale is simply reloading the kernel module that acts as a driver to our sound hardware. Reloading isn't easy, as:

1. Kernel modules use this module.
2. User processes use this module.

So the solution is to first kill all processes which use the sound (on a healthy system nowadays it's only pulseaudio), recursively unload sound driver and the modules that depend on it, then reload the main kernel module. On my system, with Intel sound card, the sound driver's module name is snd_hda_intel.

Therefore here is the full, 3-step process:

[cc lang="bash"]$ killall pulseaudio; sleep 3; killall -9 pulseaudio[/cc]

Note: you'll need sudo if there are pulseaudio processes running as other users.

[cc lang="bash"]$ sudo modprobe -r snd_hda_intel[/cc]

Note: make sure modprobe didn't throw an error. If it did, there's probably still a process using the kernel module. Sometimes that's because a new pulseaudio process got created.

[cc lang="bash"]$ sudo modprobe snd_hda_intel[/cc]

tmux

tmux is screen-like. I didn't get to learn much of screen (absolutely my bad), so it's really not a "why tmux is better than screen" post, but simply what goodies does tmux provide.

tmux goodies:

• Detach and reattach to the whole session. Even when X/ssh dies: this is basic, and that's what screen is most widely known for, but it's so important.
  > list all sessions: tmux ls
  > attach a certain session: tmux attach [-t <num>]
  
• Keep multiple copy-paste buffers. It'll stay there for as long as the session is alive. It'll not live through reboots, but will live multiple days through ssh logins, X crashes. When using multiple tmux sessions (e.g. I have one on each screen), all share the same copy-paste buffer. Bonus: no mouse involved
  > Copy: Ctrl+B+[ . I find it much easier keyboard-wise with  'set -g mode-keys vi' in ~/.tmux.conf. So that I move with vim keys (0, $, b, B, w, W), Space starts selection, Enter finishes.
  > Paste: Ctrl+B+]
  > View clipboard buffers and choose what to paste: Ctrl+B+=  (so cool!)
• Keyboard controlled tabs ("windows") and window splits ("panes"). It's hard to explain its strength, but think of running some long running command - you want to see the output but in the meantime to run something else. Ctrl+B+^ will split the screen and provide bring a new shell above it. Much nicer than shell job control.
  > Create panes: Ctrl+B+", Ctrl+B+% . Navigate: Ctrl+B+Arrow keys
  > Create window: Ctrl+B+c . Navigate:Ctrl+B+(p/n/#)
  • Run command in a split: this one is very handy. Split dies when command dies.
    > tmux split [-h] top
    > tmux new-window tar -xvf /tmp/my.tar.gz
• Scrollable, searchable, copyable, super-long buffer: basic, but well-made.
• Remote pair programming: it's a killer one. I know, screen has it too, but it's worth mentioning. The other peer, being logged in to the same host as the same user as you, simply needs to use 'tmux attach' to attach to the specific session.
• tmuxinator: I didn't yet make good use of it, but it certainly redefines the meaning of "cool".

You can check out my tmux.conf, and this ssh-agent-restore helper.

ConqueTerm - a console buffer inside vim

I never got to play well with Emacs. But I must admit it's strong. One of the features I got excited about was that anything is a buffer, either a text file or a console. And since seeing it, I was looking for a vim equivalent. And just when I gave up, ConqueTerm appeared.

ConqueTerm goodies:

• Output is a vim buffer: it's fun using the familiar vim tools on your output: search, navigate, select and copy, % for brace matching, etc.
• Copy-and-paste between a regular edited file and the terminal buffer in both directions.
• Brace matching on command line: running a complex command line with all sorts of braces? a well-configured VIM would highlight the matching brace when cursor is over it.
• Keyboard-controlled window sizing and position: create the terminal buffer as a vertical split, resize, etc.
  > Also possible to modify after creation: I found Ctrl+W+J (capital J) pretty useful, as well as the other H,K,L vim navigation keyskeys). It changes the window layout by saying "current window stays on bottom and uses all of it.

It's common for us, users and admins, to check what is the ip of the host we are logged in to. Currently on Linux, this task is commonly done by the ip and ifconfig tools. However, I find them way too complex for the simple task of checking what's the IP. their output is full of confusing, irrelevant details, and they have tons of command-line arguments.

But you can pipe it all through grep, sed and awk!

Well... I'm not even going to explain why it isn't friendly.

myip for the rescue

So after I failed to find a simple tool for displaying IPs, I started writing it myself. Some command line samples:

1. Show primary IP:
# myip
192.168.1.100
2. Show all IPs:
# myip --all
1.2.3.4
192.168.1.100
192.168.122.1
3. Show IP of a specific interface:
# myip eth0
1.2.3.4
More info & download on the github page, Check it out and submit pull requests

I'm not certain it's the right way, but it workedâ„¢. So I'll share, and get your feedback in case I've done anything stupid:

1. Convert VMDKs (VM's disk), even when having multiple files,  to qcow2 format (note: QVM/QEMU should be able to deal with vmdk files (multiple as well?), so possibly this step is redundant):
   

   # qemu-img convert <vmdk wildcard> <qcow2 file>

2. Convert the vmx (VM's settings) to xml (requires vmware2libvirt tool found in virt-goodies package)
   

   # vmware2libvirt -f <source.vmx> > target.xml

3. import the xml:
   

   # virsh -c qemu:///system define file.xml

4. re-add the disk as a qcow2 disk:
   Shame on me, I did it through the GUI:
   1. Run virt-manager
   2. You should see the new VM now, cool! Open it.
   3. From the view menu, switch to 'details' mod
   4. Remove the existing (VMDK) disk, and re-add the qcow2 disk instead:
      1. Find the disk and remove it from the VM. Your probably want to make sure the checkbox for deleting the data is unchecked.
      2. Add Hardware -> Storage -> Select "managed or other existing storage" -> Browse -> choose your qcow2 file
      3. At "device type" select box, choose the proper type (IDE worked for me)
      4. At "storage format" select box, choose 'qcow2'.
      5. Click "Finish"

       

5. Uninstall vmware

A few notes:

• I used a very simple VM configuration (e.g. Linux, single harddisk, NAT networking, no sound)
• I guess I lost the original snapshots

cc-by-sa Jason McHuff

During the recent few years, I've been gathering some best practices I learned from my peers and by experience, which I'll dump here to a short series of posts. I hope it'll help to provoke some discussion on this rather important design matter. As it's a highly debatable matter, discussions are more effective than trying to declare the ultimate truth of proper usage of exceptions.

Most of my experience in this area is related to Python, but I believe the same discussion usually applies to all dynamic languages, and possibly to languages that use throw rather than raise.

Enough disclaimers, let's get started. An easy one for starters:

Part 1: Should a function raise an exception or return a failure value?

Exceptions, as their name suggests, should be raised in exceptional cases. To differentiate between exceptional and normal, I usually ask myself what's the purpose of the function. If a function is well-named (it should be!), it gets easy to deduce that. [I also find TDD very helpful in deciding what's the purpose of a function, and thus how to properly name it]

To sum up my take on this, in a single sentence:
Exceptions should be raised only when the function encounters a case that is out of the scope of its purpose.

Distinctive examples

Do raise an exception - something out-of-scope has occurred:

• read_file_contents(file_handle), may raise an exception if file handle is closed or if read has unexpectedly failed.
  e.g. FileReadError()
  Update: My assumption here is that the file open operation occurred earlier and succeeded; this makes read errors exceptional and not expected.
• parse_configuration(data) may raise an exception if given data is bad.
  e.g. BadConfigurationDataError()
  Update: I refer here to an internal not-user-modifiable configuration file, which renders a parsing failure exceptional and not expected.

Don't raise (return a value) - something normal, in-scope, has occurred:

• file.is_open() should NOT throw an exception if file is not open: its name suggests its a boolean function, therefore it should return False. A closed file is a normal case for this function.
• 

  cc-by-nc msr

  apples.count() - if apple count is 0, I would expect the function to return 0, rather than  raising ZeroApplesError() exception. Zero apples is a normal case for a the scope of the count() function.
  But it's not always that obvious! In the larger context (e.g. an apple juice factory control program), zero apples may seem like an exceptional case - but we should look at the scope of the function and not beyond. In this hypothetical juice factory case, it WILL make sense to raise an exception at a higher-level function such as squeeze_apples(), if apples.count() == 0.

Of course in reality we encounter cases which are harder to differentiate, but I find it useful to compare the real cases to these fictional edge cases. Furthermore, even these edge cases DO happen sometimes...

Do you agree? disagree? Do you find cases where even the most unexpected error should return -1 rather than raise an exception? Add your comments.

I suspect many of these bugs are related to the same root cause (or max. 2-3 root causes). In order to try and make sense of this, I tried to categorize the bugs I've found. I hope it'll help to gather more info to resolve the bugs, and reject dups.

1. NM (gnome applet?) forgets passwords:
1. GNOME Bugzilla: [666465], [665431], [665503]
2. Debian BTS: [651445], [646018]
3. Ubuntu BTS: [904666]
4. Mint forum post with a workaround
2. NM takes too long to re-connect after resume (possibly problem in popping up the enter-password dialog box):
1. GNOME: [664289],
2. Debian: [651358], [653076]
3. NM-gnome double password dialog box case:
1. GNOME: [661208], [665503] - mentioned in 1st comment,
2. Debian: [651097]

I'll try to update this post when new info arrives, please add your comments.

Generally speaking, I think that FOSS community lacks some "dirty-work" QA workforce for bug scrubbing, such as what I'm trying to do here. I don't even know how to name this non-coding activity. Thoughts?

Update1: This Linux Mint forum post suggests that only the applet "forgets" passwords.

So I had to go back and use the old hibernate feature (aka suspend-to-disk), as powering off-and-on the computer on daily basis is not a reasonable option. But, hibernate never worked for me for quite a while - clicking in my GNOME "System -> Shut Down -> Hibernate" did nothing more than a hard-to-notice flicker. So I had to research this:

• Insight #1: suspending/hibernating from GNOME 2 indirectly triggers the tools: pm-suspend, pm-hibernate (from pm-utils package). Running pm-hibernate manually from a terminal  revealed the problem I had by printing the error to screen (and also later I found it in /var/log/pm-suspend.log):

s2disk: Could not stat the resume device file. Reason: No such file or directory

• Insight #2: pm-utils make use of uswsusp (userspace software suspend utils): s2disk, s2ram, s2both
• Insight #3: /etc/initramfs-tools/conf.d/resume defines the resume device file (swap device) for the initrd.
• Insight #4: If swap device is a device-mapper device (such as a Logical Volume on LVM) - one should be using RESUME=/dev/mapper/<name>. Notations such as UUID=<ID> or /dev/dm-nn don't seem to work, triggerring the following error on boot:

resume: could not stat the resume device file '# RESUME=/dev/sda6
UUID=UUID=038df595-f105-4653-a2a4-7c051f90dd10'
             Please type in the full path name to try again or press
ENTER to boot the system:

• Insight #5: dpkg-reconfigure uswsusp reconfigures the whole thing, and regenerates the initrd (thus applying the newly defined RESUME device).

To summarize, that's how I solved it:

• updated /etc/initramfs-tools/conf.d/resume to:

RESUME=/dev/mapper/myvg-swapvol

• Ran dpkg-reconfigure uswsusp 
• Tested it by running pm-hibernate

Additional tip: suspend-hybrid is very cool - both writes to disk and RAM: if RAM power survived, wake-up process would be instantaneous. Otherwise, it'll behave as regular hibernate. To use it, simply use pm-suspend-hybrid. GNOME2 doesn't seem to have it in its GUI, I haven't checked GNOME3 out yet.

Integrating Python code checker into Vim is really cool. It lets Vim provide (relatively) quick feedback on your code, be it a conventions warning or syntax error. That, in my opinion, increases coding productivity slightly.

The problem is, that configuring the vim-pylint integration is hell. for two reasons mainly:

1. Doing it manually requires understanding of the unpleasant errorformat syntax and some other vim tricks.
2. No good zero-setup plugin is available: official pylint.vim is unmaintained. I used to use this fork, but its not really active anymore.

Specifically, since I upgraded to latest pylint (0.24.0),  Vim stopped showing pylint's hints. That's because pylint's output was modified to contain the column number as well.

I've re-forked it, and updated it to support pylint 0.24.0. Note that it will probably fail with older versions. Please try it and send feedback (you can comment this post if easier).

---

Starting with 5.7p1, ssh client on specific environments fails connecting to specific (usually old versioned) servers. I reproduced it on a particular network, while trying to connect using new ssh client (5.8p1, Ubuntu 11.04) to an old server (default SSH server on RedHat 5.4).

Motivation

This issue is around for quite a while, but is very tricky to reproduce or understand. What bothered me most is that many people reported it to different forums, each posting only a few (different) pieces of the puzzle. So my motivation here is to try and summarize the relevant info from multiple places. I'll do my best to update this post when I hear something new.

Complete Fact list

1. Problem is present on 5.7p1, 5.8p1.
2. Exact same version (e.g. 5.7p1) works on some environments, and fails on others. (My definition to "environment": particular client machine, particular server machine, on a particular network)
3. On the "bad" environments, the problem is 100% reproducible. SSH dies immediately right after connection with the "connection reset by peer" message. Running ssh -vvv don't shed too much light on this problem (see here).
4. Workarounds: On the "bad" environments, the two following workarounds are known to always work around the problem:
   1. Shortening the cipher list ('ssh -c aes256-ctr').
   2. Shortening the HostKeyAlgorithms list
5. On the "bad" environments, enlarging the cipher list manually using '-c aes256-ctr,,,,,,' with enough commas, triggers the problem. It's easy to find a deterministic (per-environment) threshold for the length of the cipher list. More than this threshold - breaks ssh client, less - works perfectly.
6. On "bad" environments, downgrading to an older release (5.5p1) resolves the problem.
7. I (among many others) reported the problem to openssh-unix-dev mailing list, but the openssh developers couldn't reproduce the problem on their place, and therefore couldn't yet investigate it properly.

Guesses

1. It occurs on networks with Cisco equipment, possibly some "smart" Deep Packet Inspection filter ruins specific packets.
2. It has to do with the packet size of one of the "handshaking" packets. Setting a short cipher list/HostKeyAlgorithms list simply shortens the packet size below some threshold.
3. The buggy behavior HAS something to do with some change in OpenSSH, probably starting in 5.7p1. It's probably a fair change which just triggers the problem innocently.
4. I didn't rule out the possibility that another 3rd party lib is involved (e.g. openssl).

Resources

1. Ubuntu bug
2. Debian Bug
3. Serverfault [1]
4. Threads on openssh-unix-dev: [1] [2]
5. A report that correlates the problem to Cisco, a surprising progress!