Amarok wins again...

So apparently, all you have to do to horribly break amarok, is embed one of these little guys in a file name "�". If you can't see it, don't worry, it's some weird unicode character, byte value 0xc281 (UTF-8) better described here. Granted, it's a weird character to have in a filename, but hey, that's what robustness is all about. So, what does amarok do, when it encounters such a character?

Does it:
(a) Fail gracefully
(b) Fail silently and continue as if nothing happened
(c) Corrupt your database
(d) Wedge your CPU
(e) Spam you with error messages, and then hang
(f) All of the above (except a)

If you answered  (f), you're right!!

So once again, I have managed to reset all of my song ratings and preference data.  "Again?"  I hear you cry.  Well, when I upgraded from Amarok 1.4 to the "New and Improved*" Amarok 2.0 (*The developers admit, that while the UI was new and shiny, there are several major features that were present in 1.4, that were not yet written in Amarok 2.0.  They weren't really ready for a release), it decided to store all of its configuration data in a new location ~/.kde3 instead of ~/.kde4.  (Note: This may be Gentoo's fault.)  So I lost my metatag database.  "But," I hear you cry again, "there was an import tool!"  Ah yes, but unfortunately, it was hidden deep inside the configuration menu, so I didn't find it until the week after I deleted my old database (after leaving it around for months).

Now, I use amarok, because quite honestly I couldn't find a better music player for linux (and I looked really hard).  The feature that finally sold me on it was the ability to filter my playlist based on search terms.  At least, that used to work... Somewhere in the process of upgrading from 2.0 to 2.3.0 it stopped working.  Maybe it's time for me to look around again....  I would've kept my old version, but, Gentoo made it increasingly difficult to retain kde3, and I finally had to give it up.

Let me see if I can summarize some of it's wonderful features for you, and compare how it's improved.  (Granted, I'm probably being harsher than usual, seeing as I'm in a bad mood, because it just trashed my database!)

Features:

• Playlist Filtering!
• Amarok 1.4: It worked!
• Amarok 2.0: It worked! (although a search is accompanied by no less than a minute of the program stalling and using 100% of a CPU....I think it's sorting things?)
• Amarok 2.3: It still stalls, but the playlist no longer filters.  (at least on my Gentoo setup)
• Song Queueing:  Queue songs at the beginning of your random play list!
• Amarok 1.4: It worked!
• Amarok 2.x: If you're listening to a song, and you queue some more, it goes back and repeats whatever you were listening to before you queued anything... (I am assured that this is fixed in the development sources, but 2 gentoo releases later I have yet to see any results.  Maybe Gentoo is behind...)
• Queue Management!
• Amarok 1.4: You had a nice window that displayed your queue.  My favorite menu option was "Toggle Queued Status."  If you selected things where some were already in your queue, and some weren't, you could "Toggle Queued Status" on them.  No "Enqueue All" no "Dequeue All," just "Toggle Queued Status" ...
• Amarok 2.x: The window has not yet been added.
• Fast Startup!
• Amarok 1.4: About a minute, CPU bound, on my 3.0 Ghz Phenom II
• Amarok 2.0: Still a minute!
• Amarok 2.3: Only a few seconds!  ( I have to admit there was a definite improvement).  It will still hang on major operations though (like, adding or removing single tracks from the play list... I think it's sorting things?)
• This isn't really a fair comparison, apparently you're not supposed to use "large playlists" because they have "problems."  I like to load my entire collection into my playlist so I can filter it, and pick random songs.  They have this nifty little "dynamic playlist" that will randomly pick songs for you, but then there's no way to search your collection.  I'm told it's very fast for small playlists...
• XML Playlists!
• Apparently, someone decided it'd be cool to dump your playlist information in XML format.  Which sounds great, except it stores your current playlist this way too.  Which sounds great, except it's loading and storing this from disk every time it modifies something.  Which sounds great, until you realize how big XML is.  And it saves backup copies.  So every time I modify my playlist, it dumps a 5MB text file to the disk.  I think marshalling and unmarshalling this might be the source of my 30-60 second pause when I add a track to my playlist.  Or maybe it's sorting things.... (It's hard to tell.  Updating a single track's metadata gets the same pause...) Then it rotates the 10 backup copies of the playlist in case I ever wanna "undo."  I kid you not, though Amarok 2.x seems to have removed the backup copies... or maybe it just moved them somewhere weird.  I had to special case this in my backup script, because amarok 1.4 was generating over 200 MB of updated files every time I ran rsync.
• Magnatune Integration!
• I'm gonna be honest, I have no idea what this is, (some kinda online store?), but they pay people to make it work.  So I'm told it works very well.
• Collection Management!
• Amarok 1.4:They had some support for this in a side bar.
• Amarok 2.x: Yeah, not so much.
• Delete files from the disk!
• I actually use this all the time.  I downloaded most of ocremix at one point, and have been going through and deleting stuff as it comes up and sucks.
• Amarok 1.4: It worked!
• Amarok 2.0: It worked!
• Amarok 2.3: You can no longer access this from your play list.  You have to go find the track in their excuse of a Content Manager called "Media Sources", sorted by Genre.
• Weighted, Randomized Playlists!
• Amarok 1.4: It worked!  And was easy to find.
• Amarok 2.0: They decided that having a menu option was too confusing.  Instead, it's hidden under a button at the bottom of the screen that took me 2 weeks to find (and I'm not the only one).  I've just been trained to ignore their random buttons.
• Customized Sorting Ability!
• Amarok 1.4:  Their sort operation was stable (preserves existing order), so you can fake this yourself by clicking on the columns you want in the reverse order.  Again, I got pauses of a minute to do any of this.
• Amarok 2.x: They added this, but didn't make it savable (unlike everything else in the UI).  So it's an improvement, but if I switch to sort by ratings for a minute, I have to rebuild my 8-layer sorting preference after.  Still pauses for about a minute.
• Cover support!
• Amarok 1.4: If you had a cover available, it would display it.  There was also a the ability to import covers from amazon and let you pick the right one.
• Amarok 2.x: If you don't have a cover, it displays this ugly blank CD icon.  You can import covers from amazon, but only for everything at once.  And you don't get to pick.
• On Screen Display!
• Amarok 1.4: Cool blue, rounded box.  I think it had transparency support (but maybe I'm dreaming of imaginary better days).
• Amarok 2.x: Ugly Gray Rectangle (TM)  No apparent transparency support.  You have the ability to "Use Custom Colors!" (ie, text only)
• Customizable Layout!
• Amarok 1.4: The layout was pretty static.
• Amarok 2.x:  Everything moves.  It took me several hours over 3 weeks to figure out how to duplicate the setup they had in Amarok 1.4.  It's still not perfect.  Several nested layers deep you can control font sizes on the display... by guessing  the field width?  Random songs have an indented album name, no idea why.  (Like, you see "Final Fantasy 8 OST" going down the column, and then suddenly it's all "    Final Fantasy 8 OST").  Also, I somehow managed to turn "Open Script Console at Startup" on (no apparent menu option), and couldn't turn it off for months.  (Apparently it saves the "you had it open" but not the "you closed it.")  I finally nuked my configuration directory and it went away.  Back to customizing the UI.
• Automatically Find Content on your Disk!
• Amarok 1.4:  They had two buttons for "Update Collection" and "Rescan Collection". I still have no idea what the difference is.
• Amarok 2.x: Now they just have "Update."  However, there is no way to remove anything from your collection.  So I had to move some of my songs outside my music folder, so that they would never play again (like my "Learning French" CDs).

Welcome to the Music Player of the Future!   I could keep going, but my rage is fading.  I really can't find a better player for Linux though... so I guess I gotta cut them some slack.  This is free software after all, most of them are volunteers (give or take the magnatune guys).

In the true spirit of Open Source, I actually tried to get in and fix some of this myself.  Repeatedly (after getting particularly annoyed about something or another).  But there was so much weird QT interaction that I couldn't figure anything out.  I spent several hours trying to figure out how (or if) the weighted random tracks feature worked, only to conclude that if the button did anything at all, it was doing the randomization in QT itself (or some arcane callback hidden somewhere).

Oh well, back to re-rating everything by hand....

man gcc

To whom it may concern:

gcc -O3 does NOT enable -funroll-loops, and has not done so since at least version 2.95.3 (released March 16, 2001). I don't know if it used to back in the olden days (like last millennium), but it doesn't now.

gcc 2.95.3:
-O3
Optimize yet more. `-O3' turns on all optimizations specified by `-O2' and also turns on the `inline-functions' option.

gcc 3.04
-O3
Optimize yet more. `-O3' turns on all optimizations specified by `-O2' and also turns on the `-finline-functions' and `-frename-registers' options.

gcc 3.1.1
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options.

gcc 3.2.3
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options.

gcc 3.3.6
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options.

gcc 3.4.6
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -fweb, -frename-registers and -funswitch-loops options.

gcc 4.0.4
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options.

gcc 4.1.2
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options.

gcc 4.4.3
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize options.

gcc 4.5.0
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize options.

This has been a public service announcement regarding gcc.
Thank you for your time. You may return to your regularly scheduled blogging.

More optimizations...

As half a followup to my last post, I just tried to recompile all of the C/C++ code I've written on my system (and a few small projects I didn't) with -O3 -ftree-vectorizer-verbose=2 to see what it could actually vectorize.

The results were rather dismal. It optimized one loop that looked like this:

for(int x=0;x<mySize;x++) {
    t[x] = myItems[x];
}

And a bunch that were constant initialization like this:

for(int x=0;x<mySize;x++) {
    t[x] = 0;
}

There were also a couple more in my BitArray that had errors, but looked like I might be able to rewrite them to be vectorizable. Granted, you spend a lot of time in loops, so a few optimizations go a long way, but overall it looks like it has a hard time working with most code.

Optimizations and CFLAGS in an ideal world...

I was messing around with my make.conf today, and decided to play with my CFLAGS again. Now, I realize that realistically, there are some seriously diminishing returns for turning on additional compiler flags on a system-wide basis. Even with a single package, if you don't know what you're doing you can make things worse, and if you do know what you're doing, you might just be able to spend a few hours to squeeze out that extra 1% reduction in execution time. Playing with your whole system is likely to make some things marginally better and others marginally worse. And, when all is said and done, you're probably never going to notice anyway, because amarok still takes several minutes to filter your playlist. (Amarok and I have a love-hate relationship, but that's another rant.)

But, (like many Gentoo users) I twiddle with them anyway. Partly because it's fun learning about weird compiler optimizations, but truth be told, I'm also lured by the imaginary speed gains, and the vanity of turning on weird things and knowing what they do.

So, I was reading the Linux Magazine benchmarks comparing different Gentoo Optimization levels, and there's basically no significant difference from -O2 and -O3 with a couple of weird exceptions.

One of the UT2004 demos has a 20 FPS gain for -O2 over -O3, but none of the rest of them do. So that's a weird fluke.

The Dbench filesystem tests show a huge difference between optimization levels, with -O3 losing quite dramatically, with the difference diminishing as the number of clients goes up. This one's kinda concerning, it's definitely not worth setting -O3 if it's going to halve my disk access speed. But (perhaps in my ignorance), I really have no idea how changing your optimization levels will affect disk I/O. That should all be handled in the kernel, which is optimized separately. So I'm gonna assume that's some kinda weird behavior in the test harness, because I dunno anything about Dbench.

The image processing tests show a predictable bonus for -O3, since that's the kind of CPU bound task that would benefit from vectorization and inlining.

And last but not least, is the GtkPerf results for "AddText," where -O3 takes half as long as -O2. In my ignorance, I would guess that the gain is from inlining functions, since from what little gtk programming I've done it seems like there's tons of small functions you call for everything. But I really have no idea. All the AddText test does is keep adding short text fragments into a scroll box, so maybe there's a copy loop that gets optimized somewhere, I dunno. But, I know how to run GtkPerf, so I decided to check this out.

Turns out, because of Gentoo Bug #133469, gtk filters your cflags, and doesn't even distinguish between -O3 and -O2. Since the bug was dealt with in 2006, (and they're still filtering today), and the benchmark was done sometime in 2009, I'm going to assume that they were using the standard Portage tree and were running the same gtk library in both tests. So any speed gains they saw must've been some underlying system library they were calling into. So, I'd put my money on some string copy function which runs about twice as fast under -O3.

Now, the bug report was describing some pretty catastrophic failures, (and I'm sure there were), but after hacking the ebuild to use -O3, and playing with my system, I haven't seen anything crash yet. So why is it still filtered? Well, since Gentoo actually lets users set their own CFLAGS, a bunch of crazy idiots like me decide to go through and turn on whatever they can turn on for kicks, speed and glory, and then complain and file bugs when stuff breaks. They honestly don't want to deal with that, and I can't blame them. So their general policy (as far as I understand it) is to ignore any issues where people have something other than "-march=native -O2" set. And I can't fault them there, especially when most of them are volunteers, and there are lots of idiots who want to muck with CFLAGS that break things. And granted, you can't test every gcc release to see if it stops some random, unpredictable crash. But I've seen things like this come up often enough that I wanna put in my two cents.

First off, a lot of these issues come up because there's really no way to set package specific CFLAGS. The people who are seriously about optimizing, want to set different weird flags for each program, or at very least set all their weird crazy flags, and then filter them for package they know break. (Like this guy...) Yes, I know a couple people have hacked up their own techniques to do this, but they're not integrated into Portage very well, and they're all shunned by the developers. Personally, I don't think this problem is going away. There's always going to be people (crazy or guru) who want to set custom flags for custom packages, to fix known bugs if nothing else. I was once unable to compile a working gmp with my arch setting because of some weird bug, and at that point all you can do is manually adjust the flags yourself to emerge gmp, and then put them back afterwards. Granted that works, but it kinda sucks. And the more packages you want to do that with the more it sucks. I think they should just stick a package.cflags into portage, the same way package.use works now, and let people trash their system if they're retarded. That also has the advantage of letting them put all the cflag filtering that they do into one file, the way they manage package.mask.

But what's a sensible cflags policy? Well, let me describe the imaginary, ideal world first. Ideally, there's really only 3 kinds of optimizations (for whatever you're looking for, speed, size, etc). Optimizations that always work, optimizations that sometimes work, and optimizations that make assumptions in order to work.

Things that always work, are reasonable for any user to turn on, and make their own cost-benefit determination of compile-time/running-time/memory. Setting gcc -O2 turns on more or less things that always work, and anything that breaks with these settings is a bug.

Optimizations that sometimes work, include things like loop-unrolling, and is reasonable for someone to turn on if they know what they're doing. These might actually hurt your performance, but they shouldn't actually break anything, or it's a bug. Enabling gcc -O3 turns on some things in this category like inline-functions. In my opinion, users shouldn't be protected from their own ignorance if they're slowing their system down by setting things beyond their competence level. But if these actually break things, you've probably hit a compiler bug, and to me it seems reasonable to filter them out with a warning message.

Finally optimizations that work with assumptions, are the ones you shouldn't set without knowing what you're doing, and should (probably) never set them system wide. These are things like disabling exception handling in C++, or enabling fast-math. It might help under certain circumstances, but it will break if you don't satisfy the assumptions (like you're using exceptions). Anyone using these system-wide is probably stupid, or at very least they're trying to do something weird on their own.

So ideally, you should filter out everything known to break because of a compiler bug, temporarily, until the compiler can be fixed, and then allow them again. But, we don't live in an ideal world. Compiler bugs are hard to find, hard to prove, and hard to fix. And the crazier the optimization, the harder it is to verify.

So what do you do in the real world?

First, if Portage had a package.cflags, anyone who wants to do turn on weird optimizations globally can have their own place to fix it, without filing a bunch of bugs demanding ebuild filtering for everyone. And, you now have a place to store package-specific performance information. If somebody on their own wants to publish a set of "known fastest CFLAGS for this arch" by package, they can.

Second, I think that a policy of "if you're not using -O2, we don't care" is a bit much. I think it's fair to designate -O2 as stable, and -O3 as unstable, but if there are known issues with -O3 where things actually break, it seems like you should go ahead and filter the flags. So in other words, you don't verify that anything works at -O3, but if its clear something doesn't, then go ahead and make it work for everyone else. It's not that hard, and things really shouldn't be breaking at -O3 (on a theoretical level anyway). But any weird flags making assumptions about math or runtime or whatever, it's fair to ignore, because if you were guru enough to have a reason to need that flag on, you can filter it out yourself in a package.cflags, and if you weren't that guru, you should probably turn it off. And I'm only talking genuine, verifiable crashes or errors at -O3. Slowing your system down is your problem, and if -O3 is designated "unstable," I think it's fair to let other people find and verify the problems as they come up.

Of course, I say -O3 "shouldn't" break things, but I really have no idea how risky it is, or how often bugs come up. I have random parts of my system compiled at -O3 and haven't noticed any problems, but I'm just one guy with my weird setup. If Gentoo decided to start ignoring -O3 crashes because there were too many for them to handle otherwise, I can understand. But if not, it seems like they're worth noting and fixing in the ebuilds when they come up. For the record, I think Gentoo does an excellent job on the whole, and it's really probably not worth a developer's time to chase down weird CFLAG bugs people report when they could be fixing other things. I also totally agreed with the rationale behind filtering gtk+, though if the problems are gone, it might be time to remove the filtering (but I can't tell that from my setup).


So when all is said and done, I went and ran gtkperf with just my gtk+ optimized differently. The final results?

No optimizations: Total time: 76.99
-O2: Total time: 74.25
-O3: Total time: 74.02

There's really no difference.

My XFCE Setup

I use XFCE for my desktop environment in Linux, and I think it strikes a nice balance between minimalism and functionality.  You can add lots of crazy panels and menus if you want, but you don't have to.  Personally, I find that the crazier, more "user friendly" setups of KDE or Gnome provide way more interface than I need, and are just annoying.  I can launch anything I want by typing it into the terminal, so I don't need to navigate pages and pages of GUI to find something when I already know what it's called.

My setup has a floating taskbar which gives me quick access to the stuff I want to use quickly (like Firefox, Thunderbird, gedit...), but I can still pull up a menu to dig around if I need to find a particularly weird program (which is rare, I pretty much do everything in a terminal).

The coolest thing about my setup (at least I think), is that I've got a huge list of wallpapers loaded up, that change on a cron job every half hour. Here's the relevant shell code:

Dump the current wallpaper image:

xprop -root | grep 'XFDESKTOP_IMAGE_FILE_0(STRING)' | cut -f 2 -d\"

Reload a new image off the list:

xfdesktop -reload

(Note that to do this in a cron job, you may need to set the DISPLAY and XAUTHORITY right.)

I've got another set of scripts that removes the current wallpaper from the list (just using text manipulations on the file), so I can remove the one's I don't like. I'm thinking about auto generating the lists using everything in my "wallpapers" folder, but so far it's been easier to use find and then merge them by hand.

So that was the easy part. The hard part was getting xfdesktop to do something intelligent with it's "auto" setting for stretching/tiling them. In the defense of XFCE, I wanted some weird rules for my distorted aspect-ratio LCD screen. The xfdesktop defaults are to zoom anything that's not tile-able, which makes more sense if the aspect ratios match standard wallpaper sizes. The only really wonky thing they do is zoom in on the upper square of particularly bad aspect-ratio images, but I suppose normal people don't have manga pages and raw hubble footage in their rotation.

So to set that up I had to hack XFCE (see my previous post for getting this to work nice with Gentoo). I'm happy to report that it wasn't too hard. The xfdesktop code I looked through was pretty easy to read.

Basically I made it tile slightly more things, and then not distort things too much. (The specific numbers were chosen by looking at how the standard wallpaper resolutions looked on my monitor.) Here's my final patch:

diff --git a/src/xfce-backdrop.c b/src/xfce-backdrop.c
index 486a796..a028f3f 100644
--- a/src/xfce-backdrop.c
+++ b/src/xfce-backdrop.c
@@ -805,17 +805,34 @@ xfce_backdrop_get_pixbuf(XfceBackdrop *backdrop)
     }
     
     if(backdrop->priv->image_style == XFCE_BACKDROP_IMAGE_AUTO) {
-        if(ih <= h / 2 && iw <= w / 2)
+        xscale = (gdouble)w / iw;
+     yscale = (gdouble)h / ih;
+     gdouble sDiff = xscale - yscale;
+     if(sDiff < 0) {
+      sDiff = -sDiff;
+     }
+     
+     int xTile = (ih <= h/2);
+     int yTile = (iw <= w/2);
+        
+        if(xTile && yTile) {
             istyle = XFCE_BACKDROP_IMAGE_TILED;
-        else
-            istyle = XFCE_BACKDROP_IMAGE_ZOOMED;
-    } else
+        } else if ((xTile || yTile) && sDiff < 0.36) {
+         istyle = XFCE_BACKDROP_IMAGE_TILED;
+        } else if ( sDiff < 0.30) {
+            istyle = XFCE_BACKDROP_IMAGE_STRETCHED;
+        } else {
+         istyle = XFCE_BACKDROP_IMAGE_SCALED;
+        }
+    } else {
         istyle = backdrop->priv->image_style;
+    }
     
     /* if the image is the same as the screen size, there's no reason to do
      * any scaling at all */
-    if(w == iw && h == ih)
+    if(w == iw && h == ih) {
         istyle = XFCE_BACKDROP_IMAGE_CENTERED;
+    }
     
     /* if we don't need to do any scaling, don't do any interpolation.  this
      * fixes a problem where hyper/bilinear filtering causes blurriness in

Now all I have to do is go through my wallpapers and figure out which ones I really want in my rotation...

Hacking in Gentoo

I started using Linux as my primary OS some 4 years ago, but as much as I liked to brag that I had the theoretical ability to modify (almost) anything on my system, the reality was that getting a generic source package to work on whatever particular distribution I had was difficult (or at least intimidating). At best the paths would all be screwed up, and at worse I'd get library issues. Not to mention the hassle of specially handling that package from then on in my package manager.

Enter Gentoo.

In Gentoo's package manager, Portage, every package is installed by running a custom Python script, and you can store custom versions of it using their overlay system, while keeping all the dependency tracking information. The Bottom Line: I can patch anything as it's being installed onto my system, and I get all their fancy install scripts for free.

So, for the Gentoo aficionado, here's how I fixed xfdesktop to do exactly what I wanted when auto-sizing my wallpapers.

Howto install custom software versions in Gentoo:

1. Setup a Portage overlay
   
   See the Gentoo Handbook or this site for more details but basically you make the /usr/local/portage folder, and add PORTDIR_OVERLAY=/usr/local/portage to your /etc/make.conf
   
   
2. Copy over the package you want to customize from the regular tree
   
   ie Copy everything from /usr/portage/xfce-base/xfdesktop to /usr/local/portage/xfce-base/xfdesktop
   
   
3. Make your patch
   
   Use the actual distfiles Gentoo is already using (emerge -f xfdesktop will list them) to save yourself headaches later.
   Personally I just unpack the source, setup a git repository, muck with the code, and then use git format-patch to give me the patch file I need.
   
   
4. Modify the ebuild to use your patch
   
   If you have a particularly weird package, this can be tricky until you get better at writing ebuilds. But for most packages, this is cake. Just add your patch to the list of patches they're already applying. (Or checkout other ebuilds that have some patches to add and copy what they did). Here's the diff -u of my new ebuild.
   
   

   --- /usr/portage/xfce-base/xfdesktop/xfdesktop-4.6.1-r1.ebuild    2010-01-18 16:38:19.000000000 -0800
   +++ /usr/local/portage/xfce-base/xfdesktop/xfdesktop-4.6.1-r1.ebuild    2010-01-27 17:26:10.355164734 -0800
   @@ -56,7 +56,8 @@
   $(use_enable debug)"
   DOCS="AUTHORS ChangeLog NEWS TODO README"
   PATCHES=( "${FILESDIR}/${P}-automagic.patch"
   -        "${FILESDIR}/${P}-assert.patch" )
   +        "${FILESDIR}/${P}-assert.patch"
   +        "${FILESDIR}/0001-Rewrote-backdrop-AUTO-selection.patch" )
   }

5. Put your patch file in the files/ directory.

That's it. Emerge and enjoy!

I currently run custom versions (read 1-10 line patches) of 4 packages, and I'm getting less afraid to try to muck with things. The funniest is probably nethack, which has the username for debug mode hard-coded into the source, so you can't access it unless your username is "wizard". I guess nethack dev's make a custom user to do their debugging? I'm not really sure how that one was supposed to work.

Anyway, Happy Hacking!

First Post!

So, I'm experimenting with starting a m/(web?)?bl(o|a)g/i . I've always preferred just managing a website myself to using a hosted platform like this, and I'm not a big fan of the word "blog" either, but there's a couple things that are hard to do when your "content management system" consists of text files edited with nano. (Notably, tracking titles, categories, and using punctuation in your titles.) So I decided to give it a shot. If I hate it, I'll go back to text files.

So uh, WYSIWYG for now.