[ If you're not into reading why I find git history useful, you may jump right into the command-line coolness! ]
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.
Sometimes my laptop gets to a state in which sound works through the built-in speakers, but not through the headphone jack. Possibly my solution is too brutal, but it works - restarting the whole sound subsystem. I guess that it may come handy in other situation: the ability to restart a subsystem instead of rebooting the machine, is always an advantage.
The rationale is simply reloading the kernel module that acts as a driver to our sound hardware. Reloading isn't easy, as:
- Kernel modules use this module.
- User processes use this module.
As a power text-mode user, I was both surprised and glad to hear (10x @erikzaadi!) about two interesting tools: tmux & ConqueTerm, which significantly changed the way I use the shell/terminal. I'll try to keep it short and to the point, and briefly explain the most notable behavior-changing features the way I see them. Or in other words: why should you give them a try.
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.
Complex tools for a simple task
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: Continue reading
There's lots of info on the net on achieving that, but I found it a bit too scattered, and had to combine instructions from multiple sources.
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:
- 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>
- Convert the vmx (VM's settings) to xml (requires vmware2libvirt tool found in virt-goodies package)
# vmware2libvirt -f <source.vmx> > target.xml
A recipe, for a change: it's super tasty, it doesn't involve killing animals (advantage if you're an animal or vegeterian), and it's full of nutrition goodies - equivalent to a whole meal: Continue reading
Ever since I've been using exceptions, uncertainty has always been there: when are we better off with return codes? when is it smart to catch the exceptions? when should they better be left untouched and propagate higher? Create a separate exception class, or just pass an argument to the constructor?
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:
I've noticed a few significant issues with Network Manager on GNOME 3.2, when connecting to WiFi networks that require password (e.g. WPA, EAP). Trying to find existing bug reports, I've found quite a mess: multiple bug reports, both downstream (Debian, Ubuntu, Fedora) and upstream (GNOME bugzilla).
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.
- NM (gnome applet?) forgets passwords:
- GNOME Bugzilla: , , 
- Debian BTS: , 
- Ubuntu BTS: 
- Mint forum post with a workaround
- NM takes too long to re-connect after resume (possibly problem in popping up the enter-password dialog box):
- GNOME: ,
- Debian: , 
- NM-gnome double password dialog box case:
- GNOME: ,  - mentioned in 1st comment,
- Debian: 
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.
My laptop's battery had just died. It made me realize how much I depend on it, for changing my working location, either when computer is awake or asleep for many hours. Without a battery, the sleep (aka suspend-to-ram) feature is less useful, for the tiniest power interruption would kill it. Continue reading
[Executives' summary (in case any executive uses Vim) - get this updated pylint.vim for compatibility with pylint 0.24.0 changes]
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:
- Doing it manually requires understanding of the unpleasant errorformat syntax and some other vim tricks.
- 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).