Version 0.1.5 of kalu released
A new version of kalu - upgrade notifier for Arch Linux - has just been released. Changes since last version are :
Now using automake & autoconf. (Hopefully) this shouldn't really change much for most people, but if you don't care for kalu's updater and only want to use kalu as update notifier, you can use option
--disable-updaterto configure. You'll get a smaller binary, no second binary (kalu-dbus) nor dependency to DBus/PolicyKit.When starting an external process to perform sysupgrade (or AUR upgrade), kalu now waits for the process to end (being "busy" meanwhile), and runs another check right after, to refresh its state.
What to restart after a system upgrade ?
If you're familiar with Windows, you know rebooting is something pretty common. You're usually asked to reboot after a system upgrade, after (or in order to) installing a new application, after removing one...
And one of the thing you hear about Linux, is that you almost never need to reboot. Unless you install a new kernel, rebooting is not necessary, but that doesn't mean you don't have to restart a few things.
It was actually one question I had early on after moving to Linux : how to know what to restart after a system upgrade ?
Rename a group of files at once
One thing I need to do pretty much every day, is rename a batch of files, using a set of predetermined rules. A few months back, when I was still on Windows, I used to have a tool to do just that, so logically I started looking for a "replacement" now that I'm on Linux.
However, while I did find a few batch renaming utilities, none of them would really fill all the checkboxes of my requirements list. Either because they didn't provide the "rules" I was looking for, or because they would rename files after each rule has been applied, or because they couldn't be used from scripts (that way I wanted), or whatever the reason.
Keep Arch Linux Up-to-date with kalu
Keeping one's system up-to-date is something that should be done regardless of one's system. It's not that it's more true with Arch Linux, just that updates are (likely to be) more frequent, due to its rolling-release nature.
One way to do so is to remember to manually do a syu (or whatever alias you
have set for sudo pacman -Syu), but that might not be ideal. If you work
within a X session, using an upgrade notifier might feel like a very logical
solution.
There are already a few "update notifier" out there, which will run in the background and let you know as soon as a package has been updated, but I couldn't find one that would fit my needs (granted I didn't search too hard, I was also interested in making my own as a fun exercice...) so I decided to make a new one.
kalu: Keeping Arch Linux Up-to-date
One thing you (should) do quite often, as a good Arch Linux user, is
upgrade your system. Arch is, after all, a rolling-release distribution. As a
result something one ends up doing often is sudo pacman -Syu (in fact, if
you're like me, lazy, you probably have an alias set, e.g. syu)
There are already a few "update notifier" out there, which will run in the background and let you know as soon as a package has been updated, but I couldn't find one that would fit my needs (granted I didn't search too hard, I was also interested in making my own as a fun exercice...) so I decided to make a new one.
PkgClip: Does your pacman cache need a trim?
pacman - Arch Linux's package manager - is a great application, and one I probably use every single day, which - given Arch's rolling release principle - I'm sure is the case of many others as well.
Whenever pacman downloads a package, whether because you install something new,
or when you do an update, said packages will be stored in its cache (usually in
/var/cache/pacman/pkg). And then, nothing.
pacman will never remove anything from its cache (*), and it's a good thing because should you e.g. ever want to downgrade some package to a previous version for one reason or another, your cache is probably the best place to find what you're looking for.
(*) Actually, it can, but only if you ask him to. See below.
But if your cache keeps growing and only ever growing, over time it'll get pretty fat. And while keeping old versions is good, there's no point to keep every single version of everything you ever installed.
Scrolling/mouse wheel improvments (VTE-like) in urxvt
When I started, and having decided to use XFCE, I did originally
install it with a lot of what it comes with. That is, I used the panel of
course, which I still use & like very much, but also XFCE's own window manager
(xfwm4), terminal emulator (terminal), and more.
Over time though, I did not keep using all that. I kept some things because I
liked them, such as xfce4-panel or xfwm4 (which is full of nice
tricks), others I
removed because I didn't see a need for (xfce4-session), and others I
replaced, like terminal. If I decided to look for a replacement, it was
because of a little bug that would regularly occur, and annoy me.
But once I found rxvt-unicode, aka urxvt, I realized that even if that bug
got fixed, I would not go back. urxvt is really a nice terminal emulator, comes
with a lot of options and I am really enjoying using it every day. It would
pretty much be perfect, if it wasn't for one thing, one pretty annoying little
thing...
XFCE Window Manager
I am using XFCE as my Desktop Environment, and that includes XFWM - XFCE's own window manager. I could have used another one, but I find XFWM to be quite good.
I did look briefly at what other WMs are out there, and what I pretty much ended with was that a Compositing window manager would be best (XFWM is one), and not just for fun visual effects. Actually, if that's what you're looking for Compiz might be what you want to give a try. But I'm not really looking for all those visual effects, and XFWM offered what I needed, so I didn't see the need to look for anything else.
Having been using it for a little while now, I did however figure out a few nice tips & tricks that I thought I might share. Some might be quite known, and/or even common with other WMs, but either way they're pretty nice and might come in handy every once in a while.
pmount & safe removal of USB device
When you plug an USB device on your computer, under Windows it automatically becomes available. Under Arch, not so much. It makes sense, I didn't install/configure anything to do so, so why would it?
So I started wondering about auto-mounting of USB devices, although I must admit that I'm not a fan of such automated tasks, just like I hate (and always disabled) any & all form of autorun that Windows provides. (And on a side note, it's also a potentially major security risk. I think I read recently that Microsoft concluded that by simply turning that damn autorun off, people would see a huge drop (around 50% or something) of virus/malware infections.)
Anyways, I don't really mind having to mount things. Right now I need to call
mount whenever I put a CD/DVD in the drive, why should it be any different for
an USB device? But the thing is, with a CD I only need to call mount and
umount to do the work, no need for sudo Which begs the question, why should
it be any different for an USB device?
Middle-click in Firefox
It's a very common thing in Linux, but coming from Windows this was new to me: select something, and the mere fact that it was selected/highlighted is enough to make it available for "paste" using the middle-click. It's a common thing that should work pretty much everywhere in Linux it seems, and once you're used to it, it can be quite useful.
Firefox, my browser of choice for a few years now, naturally supports this.
However, its behavior in that matter is regulated through a couple of options,
and their default values aren't the same on Windows and Linux. On linux, both
middlemouse.paste and middlemouse.contentLoadURL default to true (while on
Windows both default to false).