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.

Continue reading

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”. Continue reading

“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

Rule of Thumb for Detecting Poor Design

You know you’ve got a bad design, or at least one that could be improved, when you start copying and pasting code around. (Note: this doesn’t mean the design needs improving.)

Now, to brace myself for the rotten tomatoes I see headed my way…

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.

Spotify vs. MOG

This is as much for myself as for anyone who reads this. Now that Spotify landed in the US, it’s attracted my attention. I’m already paying $10/month for MOG. Can Spotify take my $10 and make my experiences even better?

Music Selection

So far, so good. I had one of my family members suggest a few (tiny) artists, and they’ve come up. I found Sarah Fimm, which is always a good sign. However, some odd things were missing. MOG has more of the Lord of the Rings soundtrack than Spotify. (MOG has “The Last March of the Ents”, while Spotify does not.)

Nevertheless, Spotify seems very strong. No other service besides MOG has pulled up search results for some of the terms I’ve pulled in, until now. Spotify so far matches MOG in almost every way.

Edit: since I’ve started finding more disparities between the two’s catalogs, I’ve decided to keep a list:

  • MOG has more Lord of the Rings soundtrack albums than Spotify.
  • MOG has the artist Arcade Fire; Spotify does not.

Write in the comments area if you have any other artists or albums you want me to look for.

Access to that Music Selection

Ahh, yes. Now it gets interesting. MOG doesn’t use a downloaded client. They stick to a lightweight web interface. This means I can listen to MOG wherever I am. With Spotify, not so much.

Once you’re logged in, though, how do the services compare? Spotify wins in more ways than one.

Spotify doesn’t just have everything MOG does, which includes playlists, favorites, “What’s New”, and a nicely-organized search. Spotify’s client is also fast. Searches return results right away, and navigation through their library is snappy and responsive. It feels almost like their entire library index is sitting on my computer. Spotify is also linked to my Facebook account, which means my friends’ playlists and favorites can be browsed and played.

Music playback is much better in Spotify. Skipping songs, or skipping around within a song, all happens so fast sometimes I wonder if it even had to stream to play it. To make that even faster, Spotify can seamlessly link my locally-stored music into the Spotify catalog, so that music I already have downloaded is used (as long as they’re MP3 or MP4) instead of streaming it. Any DRM-encrypted or unplayable formats are still recognized, but streamed whenever I attempt to play them.

MOG won’t do any of that.


There really is no competition here.

First of all, the user interface feels much more native in Spotify than MOG. Buttons, menus, and lists are clearly buttons, menus, and lists, rather than a stylized collection of black, white, and red boxes, however pretty it looks. Consistency wins every time.

Different areas in Spotify are accessible almost immediately, thanks to a menu across the bottom of the screen. In MOG, to access another area, one has to use the hardware back button to get back to the main menu.

Spotify will not only sync all my playlists and favorites, but also my local files. Imagine that. Google Music still wins in format support, but if you have a library full of mp3 and mp4 songs, that won’t be an issue. Besides, Spotify syncs over the network. Google Music will sync at any location, but always over the Internet. Spotify also watches your mobile phone or iPod storage, and restrains itself from reducing your free space below than a specified percentage (10% by default). In addition, this sync is available for free! It’s the streaming you have to pay for. MOG won’t do any of that.


I actually don’t have enough experience in this area, at least for Spotify. I can tell you that MOG is a company that seriously listens to their customers. If they’re missing music, they have an e-mail address where customers can e-mail requests, and a human replies with either a satisfactorily-detailed reason why MOG couldn’t get you that album, or a date when the album will be available. They also have a website set up where users can post ideas and vote up others’ ideas they think deserve attention. It’s been very effective, because they listen.

Spotify seems to have a similar system going for feature requests. Their community also seems a little bit stronger due to the open nature of their support forums. (MOG keeps all support requests private.) Spotify, however, doesn’t seem to be ready to receive music requests, which, in my opinion, is a big problem, considering music is the point the service exists.


If you can get past accessing the client, and finding the music you like, Spotify seems superior in every way. The user experience in all their software, including their website, is polished and solid. $10 with Spotify is going to get you quite a few more features than MOG.

However, when it comes down to just listening to music, both services are equal. MOG may have more music than Spotify, and both services allow you to listen to music in some easy fashion or other. The mobile apps for both are also easy to use and reliable. Everything for both services “Just Works”.

I use Linux, 64-bit. I have Spotify for Windows installed under WINE, and it works very well. However, the various problems I had reaching this point (howto coming soon) highlights why web-based platforms generally are better than native ones. It’s both a blessing and a curse, actually: by going native, it’s snappier, but it’s also only available on my various computers. If I can’t play my music where I’m at, what’s the point in paying for the service?

That’s what it seems to come down to, at least for me personally. If you can handle your availability limited to wherever the Spotify client is installed, you’ll enjoy Spotify much more than MOG. If you’d really much rather have a web-based interface, accessible anywhere where there’s a browser, I’d go for MOG.

What’s my choice? I’m still deciding.

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. Continue reading