fcron compatibility with vixie-cron’s /etc/cron.* directories

vixie-cron has cron.hourly, cron.daily, cron.weekly, and cron.monthly directories. Your system might have something slightly different.

If you’re like me, you’ve done your research on cron daemons, and found vixie-cron to not only be one of the more resource-hungry options, but also one of the less usable. The system has really gotten stale over time. fcron not only does everything vixie-cron does, it also does everything anacron does, and in a nice, small package.

Problem is, fcron also doesn’t like to look back to the past. It doesn’t utilize the /etc/cron.* directories, unless you tell it to do so:

%hourly * /bin/run-parts /etc/cron.hourly
%daily * * /bin/run-parts /etc/cron.daily
%weekly * * /bin/run-parts /etc/cron.weekly
%monthly * * * /bin/run-parts /etc/cron.monthly

Add this to your system’s crontab by running:

sudo fcrontab -e

As soon as you save and quit, fcrontab will run all the jobs once, and then continue according to schedule.

Removing WINE’s Default Application Entries

Today I double-clicked an image, and it opened with WINE Internet Explorer. What in the world? Why would I want that?

Anyways, odd developer choices aside, there’s a way to get rid of WINE’s software completely from your “Open With” menus. Shut down winemenubuilder.exe. Here’s how to do it:

1. Open winecfg
2. Go to the libraries tab
3. In the dropdown, type in “winemenubuilder.exe” without the quotes. It’s not in the list, but you can type it.
4. Once added, click on the new entry and click the Edit button.
5. Click the Disabled radio button, and save everything.

You’ll want to go through the .local/share/mime and .local/share/applications directories and delete anything relating to WINE. On my system, the only reason .local/share/mime exists is because WINE creates it, so I deleted the mime directory entirely. If you keep it, be sure to run:

update-mime-database .local/share/mime

If you’re running a good DE, like LXDE (hint, hint), all your menus will update almost immediately.

Source: WineHQ bug #19182

screen to tmux: A Humble Quick-start Guide

An online friend named bmc_ on Twitter introduced me to tmux. It reportedly has simpler, cleaner code than screen, which implies that it’s more robust, in addition to more very useful features.

The problem is tmux is very different from screen. It wasn’t at all easy to jump straight into tmux, without doing a thorough read of the man pages, which is not exactly how great first impressions are made.

That’s why I decided to write this.

This quick-start guide will assume you are familiar with screen.

Desktop Revolution: Stage 1: Notifications Bar

I have a lot of ideas about how the Linux desktop can be improved, perhaps revolutionized, and these ideas all come from running up against walls repeatedly. I’m going to write the best ones down, the ones I will eventually turn into an open-source project (years down the road, mind you) if no one else does.

The Linux tech world has come up with numerous solutions for notifications, and I use as many as possible to satisfy my needs. Chrome has TweetDeck, Linux has libnotify, or notify-osd if you’re using Ubuntu, and all operating systems have an icon “tray.” They all serve similar purposes: they want to give you information about what’s going on right now, and that’s incredibly useful.

However, I dislike the icon tray. It’s messy, hard to notice, and hard to click on.

I dislike the pop-up notifications. They get in the way of something every time and disappear if I don’t give them the attention they crave right at that particular moment.

TweetDeck doesn’t have any of these problems, but it runs as its own app that wants lots of screen space, and is so super-specific that it really can only be used for so many things.

My idea is to take the best of all these worlds and put them together into this new application I’ll call “notifications bar”.

“git svn” Cheatsheet for Git Rebels in an SVN Workplace

This is my own use of git svn. No one in Google seems to have this mix listed out for a Subversion project with a proper trunk/branch/tag setup, so I decided to post what I’ve got.

Getting a repository:

git svn clone --tags <tags subfolder> --trunk <trunk subfolder> --branches <branches subfolder>

Updating SVN-tracking remote branches in git:

git svn fetch

Working on trunk:

git checkout master; git svn rebase

Working on a branch for the first time:

git checkout -b local/<branchname> <remote branchname>

Working on a branch:

git checkout local/<branchname>; git svn rebase

After committing, merging, or any other action that changed the local git repository, push to SVN:

git svn dcommit

Making a new branch in SVN:

git checkout master; git svn branch <branchname> -m "Branching for <reason or bug#>"

Making a new tag in SVN:

git checkout <tagged commit>; git svn tag -m "Tagging for <reason or release>"

Deleting a branch in SVN:

svn rm svn://host/path/to/branch; git branch -D local/<branchname>; git branch -D -r <branchname>; rm -rf .git/svn/refs/remotes/<branchname>

Deleting a tag in SVN:

svn rm svn://host/path/to/tag; git branch -D -r tags/<branchname>; rm -rf .git/svn/refs/remotes/tags/<branchname>

Merging a branch (properly):

git checkout <merge-to branch>; git merge --squash <merge-from branch>; git commit; git svn dcommit # --squash is key

Gentoo-built Desktop Managers and Their Lack of Integration

I don’t know if anyone else noticed this, but I certainly have. It’s not that it can’t be worked around. It’s that Gentoo-built desktop managers lack the polish other pre-mangled distributions like Ubuntu provide. I miss that.

Presently, I’m using KDE, and as it turns out, it has the most integration issues, in my experience. The only thing in GNOME that felt thrown together was super-user authentication and printing, whereas KDE has issues with NetworkManager, PulseAudio, super-user authentication, and external storage mounting, and I’m sure I’ve only scratched the surface.

The plan is to spend the rest of my summer reporting on these issues so they can be resolved. With fingers crossed, bug reports will be filed and fixed.

Stay tuned.

How can I be a KDE power user?

As far as I can tell, KDE is essentially a desktop environment shell layered on top of many very useful libraries. The difficulty is, how does one test each individual layer?

Here’s a recent example. I started by using Amarok as my music player, a default choice it seems for many KDE users. I put an audio CD in the drive, and it appeared in Amarok. When I tried to play or rip the CD, though, the interface just wouldn’t respond.

Fast-forward many, many hours later, and I’ve traced the issue through logs spit out by Amarok, Phonon, Kscd, gstreamer, ffmpeg, and the kernel itself, and I narrow the issue down to KDE I/O layer. cdparanoia reads disks just fine. No KDE-based app can. There’s a lot of seek errors in the kernel logs, which appear only when a KDE-based app is up and running with a CD in the drive.

So what’s the big deal, you might ask? I figured it out. What’s the problem?

Perhaps I’m spoiled, but in GNOME I debugged issues quite differently. If I had an issue, I’d go through each API layer, and use each one’s executables. Note the difference between KDE and GNOME: GNOME makes every layer, every setting easy to access, if you look for it. KDE gives you everything at once, and hides everything else in a wall of libraries. There’s no intermediate executables I can use to debug each layer, by manually running through steps myself. There’s no ability to get a work-around, or to helpfully narrow down the area where the bug exists for Google searching.

How do I make my debugging with KDE more productive? What steps do I take? How have you debugged KDE-based applications? I know about the KDE wiki page, but is there anything else?

Gentoo (and a little Ubuntu) on a MacBook Pro (5,3)

Getting Started

The Google-size summary: I’ve gotten Gentoo working on my MacBook Pro (5,3) again.

I’m going to attempt to recount all the little issues I ran across while installing Gentoo. If you notice I missed something, post it in the comments and I’ll try to figure it out and/or add it here. I also hope to add my findings to the Gentoo wiki, although the wiki is such an outdated mess that I’d almost feel like scratching the whole thing and having the Gentoo+MacBook community write their experiences back in.

Non-obvious, Unannounced Gentoo Update

I’m not too happy the devicekit-power package has become unsupported but still remains in the tree as stable, with not even a word in elog or similar. This package depends on libusb:0, which has some pretty unfortunate bugs, resulting, at least for me, in power management only half working. I praise the developers of GNOME yet again for solid code writing that chugs along and still recognizes my battery and other things despite crashes like this.

It’s pretty easy to update and move on. Simply run emerge -1v upower and portage will handle the transition.

qemu-user: Turning your dual-core 2.6GHz processor into a dual-core 500MHz processor

I just discovered qemu-user, thanks to lu_zero on #gentoo-embedded. It’s brilliant. They took QEMU’s ability to simulate an entire processor, tossed out the other hardware emulation, and packaged it up. qemu-user’s primary use is for running foreign binaries.

So far, I’ve been running all my stage generation for Neuvoo on the BeagleBoard, which has a 500MHz armv7a processor. Everything compiles very slowly, but at least it’s native and stable.

There’s a couple problems with that setup. First, everything is running off an SDHC card. We’re talking slow. Second, the beagle has 128M of RAM, and after that it’s using the swapfile. Which is on the SDHC card. Now we’re really talking slow.

qemu-user deftly solves these problems. Of course, running stage generation on my hefty 2.6GHz Core2 Duo processor is going to slightly speed up compiling, just because of the dual cores. But not only that: now I have a huge, fast 7200rpm hard-drive to run everything off of, and 4G of RAM (2 of which is almost always cache) to run it all within.

Think of it like this: qemu-user enables you to run a chroot (and possibly other things) for almost any processor on a system of your choice, as though it were running natively.

Setting up qemu-user is a piece of cake, so I won’t go into details here. Just follow these instructions. One thing I didn’t get at first was why they use “USE=static”. The reason is this: if you’re going to be running an armv7a chroot, you need something inside the chroot to be translating (qemu-user). The problem is, that something can’t link dynamically against any libraries, because they’ll all be armv7a libraries. Static linking means the binary is self-contained and portable.

Let me know if there are other cool uses for qemu-user. I’m all ears. 🙂