Wow, that title sounds pretty gloomy and not entirely meant as a news header. It’s true but it was never declared.

Let’s start out by looking at the b.g.o. 206455. Check out the header information on that bug. Let me reproduce the interesting bits:

Perl 5.10.0 was released about a month ago. I attach modified ebuilds and
patches that I used to install it successfully (?) on my system

Reproducible: Always

Opened: 2008-01-17 19:39 0000
Current Status: New

In case you didn’t catch that, check out the bolded text one more time. That’s right, it’s been about 18 months since perl-5.10 was released and Gentoo still does not support it. How could a source based distribution that used to pride itself on bleeding edge support possibly fall so far behind?

Simple: the herd maintainers, both of them, have basically abandoned Gentoo.

This is interested and saddening for many reasons. I’m a long time user and supporter of Gentoo and it pains me to see it fall. In my opinion, Gentoo was the only distribution to get package management correct. I loved being able to test bleeding edge software before everyone else, including Debian and RedHat.

This situation also shows 2 problems with open source projects that you would not typically exist. First, maintaining distribution supplied versions of Perl and CPAN modules is loser’s game. It’s nearly impossible to update all of those ebuilds as fast as the developers of the modules themselves. g-cpan was a terrible project that never really worked well and no one wants to take over (as you can see from some of the recent comments). What I’m taking from this is that CPAN authors themselves are the most likely candidates to keep their modules building and installing since they’re doing something very similar already.

It also points out that with any project, there needs to be some level of satisfaction. It’s apparent from the herd’s (not so) recent commits that they lacked the desire to continue. This could stem from the historically poisonous Gentoo developer community, the difficulty in maintaining the ebuilds, or real life interference.

What can we learn from this? How can we possibly improve the situation? These are difficult questions and it’s heartening to see that concerned parties are finally starting to ask them publically. I think the first thing that needs to happen is to stop asking “where is perl-5.10″. It won’t be released on Gentoo by the herd. I’ve had to live with that for 18 months and now everyone else needs to as well. What we can do is try to improve the tools we have available, fix their problems, and write new tools to fill in the gaps. We need tools to help distributors with the ever-growing nature of CPAN. No one knows what needs to happen for that yet. Time for asking “where is it?” is over; now is the time to roll up our sleeves and get to work.

perl-5.10 on Gentoo should become a case study on how open source projects can succeed and fail. Gentoo itself is a case study with developer relations, but that’s a talk for another day.

I am testing out the new QuickPress posting tool on the (finally) revamped Wordpress dashboard. This new dashboard looks much more useful than the unintuitive dash on the 2.6 release.

Anyways, it’s been hell getting everything setup. IPCop seemed to clear out my dyndns setting and wasn’t updating even though the site had been up for 2 weeks. I’ve been crammed with too much work in the last month for my current class, so I haven’t had time to do much.

We have moved into our house, but maybe 50% of stuff is unpacked, so we’ll have to finish that after the semester is over. I don’t have any pictures of the new house, but I will eventually post a curbside photo.

Back to the grind. Good to be back and up finally.

I have a little gem I figured I’d share with the masses. I just ran through updating my Gentoo ~amd64 system (many many updates in the last 6 months) and found that there were still packages that had not been updated. I threw together a quick shell command to not only find all packages out of date but update them as well:

eix | grep '\[U' | perl -e '@p=<>;map{s/\[U\](.*)\n//;$i.=$1;}@p;print $i;' | xargs emerge -uD

So if you use the eix tool to greatly speedup package lookups, it’s output can be utilized to find packages that were not picked up by a recent emerge -uD world. The perl script most definately could be golfed further but I’d like to keep things readable.

As if straight out of the late 90s when people thought they could control the data they send you, websites across the internet still try to prevent you from saving content directly from your browser. It’s as if these website administrators and content owners just haven’t learned from the lessons of the music and movie industry (those organizations have been exemplified for poor content ownership in a digital era). This is a guide for thwarting those pethetic attempts to prevent the user from right clicking or flat out saving a website to your harddrive.

We’ve all seen it before. You’ll find a picture or movie that the site has feebly attempted to prevent you from saving. Lets first start by going over the most popular methods that websites employ to try and lock down the content they’ve already sent you.

Some of them just disable right clicking via some javascript. This is laughably simple to bypass, just check out the source; you can usually find what you’re looking for if you can read some HTML / JavaScript.

Some of them are slightly craftier in they try to hide the source on the server. This is done through server code that generates client-side code. ASP, servlets, and JSP are the most popular forms of server code that sends the client the actual server code. This makes reading the code more difficult since this server code is usually executed on the other end and a bit tougher to get the raw client-side code. It can be done, but the Ultimate Method listed below will always thwart it.

Then there’s the top tier of cleverness: embedded flash. This is often the most challenging to work around as it basically employs both previous methods. Most Flash players lack any ability to save them by simply right clicking. That would actually make things easy since GNOME now has a prepackaged swf player. There is usually some cryptic method employed with the CGI parameters that are passed to determine which FLV to play. Unless you are very good at mentally debugging JavaScript, you’ll probably want to skip straight to the Ultimate Method below. Otherwise, I would recommend reading the source code of every externally referenced file to find the embed statement. This may be hidden in a JavaScript, server-side code (even server-side includes), or directly into any XHTML/HTML. If you can do this, I commend your abilities but laugh at your inability to think outside the box to save significant amounts of free time.

So lets get on to describing the Ultimate Method already. This technique involves primarily using Epiphany, but I believe it should work just fine with many open source browsers such as Firefox and maybe Konquerer. This demonstration is performed with Epiphany 2.22.1.1 compiled with the following use flags: python spell xulrunner.

GNOME compliant applications drop their working and cache directories under ~/.gnome2. For example, here’s what I have under my gnome2 directory:

s1n@citadel ~ $ ls -1 .gnome2
Brasero
Dia
Totem
accels
accelsgedit
backgrounds.xml
brasero.session
conglomerate
deskbar-applet
devhelp
eog
epiphany
evince
f-spot
file-roller
gcdmaster
gedit
gedit-2
gedit-metadata.xml
gedit-print-config
glade-3
glchess
gnome-alsamixer
gnome-art
gnome-dictionary
gnome-volume-control
gthumb
invest-applet
keyrings
main
nautilus-scripts
panel2.d
rhythmbox
seahorse
session
share
splash-screens.xml
stickynotes_applet
yelp
yelp.d

These are all typical GNOME applications; the one to pay attention to is ~/.gnome2/epiphany. Under this directory, it stores its working information similar to how Firefox used to (it’s been a while since I used Firefox). Of importance is the caching directory: ~/.gnome2/epiphany/mozilla/epiphany/Cache. Notice how the mozilla directory is structured like Firefox. Remember, Epiphany was designed as a lightweight Firefox clone (then known as Galeon) when Firefox was starting to get bloated (provided by the Mozilla team).

This Cache folder is where the magic happens. Every file is given a unique name, probably through something like mkstemp or through a clever hash. None of the files have the proper extensions so if you have a ton of browser cache, you will a ton of files here. I’ll discuss how to find the file you’re looking for through this haystack in a minute.

First, lets go over the basic idea and then I’ll walk you through an example. Essentially, we want to clean up this cache folder, reload any website that hosts the content you want to find, then grep through the Cache folder to find it. By cleaning the cache folder, we have less unrelated files to worry about. Once you reload the website that sends you the content, you’ll find some new cache files and it’ll be much easier to find them. We’ll also use file and the file magic database to make our lives easier. By simply doing a file * | grep filetype to find the files we’re looking for, we’ll get a listing of all possible matches.

Now, let’s follow an example: the Keep Austin Weird photo gallery posted on Austin360. I wanted to get a local copy of the images that are browsable on this page. The content owners definately spent some time trying to block people from downloading them (notice the “BUY THIS PHOTO” link) by herding visitors to pay a small fortune for each photo. Never annoy a software junkie; the owner has already sent me the files and now I just want a local copy, so we will find a way to to take them.

At first inspection, this is either a gallery script such as lightbox or flash file. Once viewing the source, you’ll see that Austin360 is managed by a few code generators, mostly by SiteCatalyst. The code is a hodgepodge of HTML, XHTML, JavaScript, and flash (at least that’s what is generated on the server side). Digging through the code leads you to a script that figures out which Flash file to load. It’s complicated by the fact that it doesn’t actually load the gallery until some more JavaScript is called to actually embed it. Playing with it reveals it becomes a pain in the butt to access the embedded object. There are browser plugins out there that might assist with this, but then if you’ve read this far, you’re probably looking for something that will allow you to access any protected content directly.

So first things first, lets clear out our cache. From Epiphany, go to the Edit -> Preferences dialog. Click on the Privacy tab. Near the bottom, you will see a section titled Temporary Files. Set this to a size as high as you need or can stomach and then click on the Clear button. From this dialog, make sure at least the Temporary Files checkbox is checked, then hit the Clear button again. Close all of those windows. Below is the dialog from the 1.2 version of the application (this was just before they were assimilated into GNOME and had to adopt the same versioning scheme as GNOME).

At this point we want to reload the page. Doing so should start creating cache files. The flash animation has sent us 1 image so far (ironically, a picture of the iconic transgendered vagrant Leslie), so that should be enough to make sure we have something to work with. Lets go to that cache directory and find out what we have to work with. Remember, we’re going to use file magic to find only the files we care about as there will likely be too many unrelated files.

s1n@citadel ~/.gnome2/epiphany/mozilla/epiphany/Cache $ file *
0CEB37D0d01: Macromedia Flash data (compressed), version 7
1AC4830Fd01: ASCII C program text, with very long lines, with CRLF line terminators
944676BCd01: ASCII C program text, with very long lines, with CRLF line terminators
D7218B7Ad01: ASCII C++ program text
FCD476F3d01: JPEG image data, JFIF standard 1.01
FFA69BC3d01: ASCII C program text, with very long lines, with CRLF line terminators
_CACHE_001_: , 44.1 kHz, Stereo
_CACHE_002_: , 44.1 kHz, Stereo
_CACHE_003_: , 44.1 kHz, Stereo
_CACHE_MAP_: GEM Image data 0 x 1, 0 planes, 0 x 0 pixelsize

You may have noticed the Flash file there. Trying to open that with swfdec doesn’t produce anything useful. In fact, it does look like the Flash file we want, but there’s something with the way it’s coded such that it requires some input that’s missing from the standalone file (you’ll get an XML error if opened by doing: swfdec-player 0CEB37D0d01).

There is a single image file, and after inspection with EyeOfGNOME, we find it’s the image of Leslie. Paydirt! The images are downloaded as seperate files. Downside is we have to flip through each of them as only when they are viewed are they cached. After running through the entire slide show we have a bunch of files, mostly JPEGs, and we can begin sifting through them all. First, lets check out the file magic results on everything to see what we have to work with here:

s1n@citadel ~/.gnome2/epiphany/mozilla/epiphany/Cache $ file *
0C86DDDEd01: JPEG image data, JFIF standard 1.01
0CEB37D0d01: Macromedia Flash data (compressed), version 7
1AC4830Fd01: ASCII C program text, with very long lines, with CRLF line terminators
856ED57Dd01: JPEG image data, JFIF standard 1.01
86C5D54Dd01: JPEG image data, JFIF standard 1.01
86D2D54Dd01: JPEG image data, JFIF standard 1.01
87F5D55Dd01: JPEG image data, JFIF standard 1.01
944676BCd01: ASCII C program text, with very long lines, with CRLF line terminators
A28162E3d01: JPEG image data, JFIF standard 1.01
A29062F3d01: JPEG image data, JFIF standard 1.01
A2B26213d01: JPEG image data, JFIF standard 1.01
A2F66273d01: JPEG image data, JFIF standard 1.01
A36F6353d01: JPEG image data, JFIF standard 1.01
A37E6333d01: JPEG image data, JFIF standard 1.01
A4C56263d01: JPEG image data, JFIF standard 1.01
A57E6233d01: JPEG image data, JFIF standard 1.01
A6E76213d01: JPEG image data, JFIF standard 1.01
A6F66273d01: JPEG image data, JFIF standard 1.01
AC9063E3d01: JPEG image data, JFIF standard 1.01
C08161D3d01: JPEG image data, JFIF standard 1.01
C0A36153d01: JPEG image data, JFIF standard 1.01
C0B26133d01: JPEG image data, JFIF standard 1.01
C0C560C3d01: JPEG image data, JFIF standard 1.01
C16F6033d01: JPEG image data, JFIF standard 1.01
C17E6153d01: JPEG image data, JFIF standard 1.01
C1906003d01: JPEG image data, JFIF standard 1.01
C1A36063d01: JPEG image data, JFIF standard 1.01
C1B26013d01: JPEG image data, JFIF standard 1.01
C1D46043d01: JPEG image data, JFIF standard 1.01
C26F6143d01: JPEG image data, JFIF standard 1.01
C2906253d01: JPEG image data, JFIF standard 1.01
C2B26273d01: JPEG image data, JFIF standard 1.01
C2C561E3d01: JPEG image data, JFIF standard 1.01
C2E76123d01: JPEG image data, JFIF standard 1.01
C2F66153d01: JPEG image data, JFIF standard 1.01
C36F6D63d01: JPEG image data, JFIF standard 1.01
C37E6D03d01: JPEG image data, JFIF standard 1.01
C3906D33d01: JPEG image data, JFIF standard 1.01
C3E76113d01: JPEG image data, JFIF standard 1.01
C3F66273d01: JPEG image data, JFIF standard 1.01
C46F6683d01: JPEG image data, JFIF standard 1.01
C47E6693d01: JPEG image data, JFIF standard 1.01
C4816673d01: JPEG image data, JFIF standard 1.01
C5816733d01: JPEG image data, JFIF standard 1.01
C5906723d01: JPEG image data, JFIF standard 1.01
C5B26703d01: JPEG image data, JFIF standard 1.01
C5E76713d01: JPEG image data, JFIF standard 1.01
C66F6763d01: JPEG image data, JFIF standard 1.01
C69067B3d01: JPEG image data, JFIF standard 1.01
C6A36743d01: JPEG image data, JFIF standard 1.01
C6B26753d01: JPEG image data, JFIF standard 1.01
C6D46023d01: JPEG image data, JFIF standard 1.01
C7B26013d01: JPEG image data, JFIF standard 1.01
C7C567B3d01: JPEG image data, JFIF standard 1.01
CC7E62A3d01: JPEG image data, JFIF standard 1.01
CCD46D13d01: JPEG image data, JFIF standard 1.01
CD7E6DC3d01: JPEG image data, JFIF standard 1.01
CD8163F3d01: JPEG image data, JFIF standard 1.01
CD906303d01: JPEG image data, JFIF standard 1.01
CDB263D3d01: JPEG image data, JFIF standard 1.01
CDF662C3d01: JPEG image data, JFIF standard 1.01
D06F6433d01: JPEG image data, JFIF standard 1.01
D0906013d01: JPEG image data, JFIF standard 1.01
D0A361D3d01: JPEG image data, JFIF standard 1.01
D0D46133d01: JPEG image data, JFIF standard 1.01
D1D46753d01: JPEG image data, JFIF standard 1.01
D1F664C3d01: JPEG image data, JFIF standard 1.01
D26F6743d01: JPEG image data, JFIF standard 1.01
D27E6723d01: JPEG image data, JFIF standard 1.01
D2A36773d01: JPEG image data, JFIF standard 1.01
D3C56623d01: JPEG image data, JFIF standard 1.01
D46F6403d01: JPEG image data, JFIF standard 1.01
D4C56413d01: JPEG image data, JFIF standard 1.01
D4D46453d01: JPEG image data, JFIF standard 1.01
D5D46423d01: JPEG image data, JFIF standard 1.01
D6E764A3d01: JPEG image data, JFIF standard 1.01
D7218B7Ad01: ASCII C++ program text
DC6F67B3d01: JPEG image data, JFIF standard 1.01
DC816203d01: JPEG image data, JFIF standard 1.01
DC906DA3d01: JPEG image data, JFIF standard 1.01
DCB262F3d01: JPEG image data, JFIF standard 1.01
DCC56313d01: JPEG image data, JFIF standard 1.01
DCD462A3d01: JPEG image data, JFIF standard 1.01
DCF663F3d01: JPEG image data, JFIF standard 1.01
DDF667C3d01: JPEG image data, JFIF standard 1.01
E46F7423d01: JPEG image data, JFIF standard 1.01
F06F6FC3d01: JPEG image data, JFIF standard 1.01
F0A37743d01: JPEG image data, JFIF standard 1.01
F0F66E63d01: JPEG image data, JFIF standard 1.01
F1906ED3d01: JPEG image data, JFIF standard 1.01
F1A36E33d01: JPEG image data, JFIF standard 1.01
F26F7733d01: JPEG image data, JFIF standard 1.01
F2817743d01: JPEG image data, JFIF standard 1.01
F2907723d01: JPEG image data, JFIF standard 1.01
F2B27773d01: JPEG image data, JFIF standard 1.01
F36F7623d01: JPEG image data, JFIF standard 1.01
F3907633d01: JPEG image data, JFIF standard 1.01
F3A37663d01: JPEG image data, JFIF standard 1.01
F3B27653d01: JPEG image data, JFIF standard 1.01
F3C577F3d01: JPEG image data, JFIF standard 1.01
F3D47673d01: JPEG image data, JFIF standard 1.01
F3E77713d01: JPEG image data, JFIF standard 1.01
F3F67703d01: JPEG image data, JFIF standard 1.01
F46F6143d01: JPEG image data, JFIF standard 1.01
F4907683d01: JPEG image data, JFIF standard 1.01
F4A37793d01: JPEG image data, JFIF standard 1.01
F4B27633d01: JPEG image data, JFIF standard 1.01
F4D47733d01: JPEG image data, JFIF standard 1.01
F4E76E33d01: JPEG image data, JFIF standard 1.01
F5816193d01: JPEG image data, JFIF standard 1.01
F5906013d01: JPEG image data, JFIF standard 1.01
F5B26173d01: JPEG image data, JFIF standard 1.01
F66F6F63d01: JPEG image data, JFIF standard 1.01
F67E6F73d01: JPEG image data, JFIF standard 1.01
F6816F33d01: JPEG image data, JFIF standard 1.01
F6906F13d01: JPEG image data, JFIF standard 1.01
F6B26F23d01: JPEG image data, JFIF standard 1.01
F6C56073d01: JPEG image data, JFIF standard 1.01
F6E76033d01: JPEG image data, JFIF standard 1.01
F6F66013d01: JPEG image data, JFIF standard 1.01
F7A36E33d01: JPEG image data, JFIF standard 1.01
F7C56F43d01: JPEG image data, JFIF standard 1.01
F7D46FA3d01: JPEG image data, JFIF standard 1.01
F7F66F53d01: JPEG image data, JFIF standard 1.01
FC907593d01: JPEG image data, JFIF standard 1.01
FCA37613d01: JPEG image data, JFIF standard 1.01
FCB27583d01: JPEG image data, JFIF standard 1.01
FCD476F3d01: JPEG image data, JFIF standard 1.01
FCF676E3d01: JPEG image data, JFIF standard 1.01
FFA69BC3d01: ASCII C program text, with very long lines, with CRLF line terminators
_CACHE_001_: , 44.1 kHz, Stereo
_CACHE_002_: , 44.1 kHz, Stereo
_CACHE_003_: , 44.1 kHz, Stereo
_CACHE_MAP_: GEM Image data 0 x 1, 0 planes, 0 x 0 pixelsize

You’re probably thinking that I could have skipped showing you that, but I think it’s important to note the file types that we’re working with. In this case, we have nothing but JPEGs, so this will make life much easier. In fact, we can sift through things very quickly. We’ll need a quick script to help us rename the files to have an extension an image browser will recognize:

$ file * | grep -i jpeg | perl -e '@lines = ; `mkdir examine`; for(@lines){ ($file, $junk) = split/:/; print "Filename: $file\n"; `mv $file "examine/$file.jpeg"`;}'

Note we’re just filtering out JPEG files because the previous file magic check revealed they were all JPEGs. If you are looking for other file types, such as PNG, GIF, MOV, and etc, make sure to use the appropriate grep string (that matches something in the file magic string as returned from above) and the appropriate file extension in the mv call in the perl script. This will give us a directory called examine. From here, we have all the content we wanted to download! Just sift through the files with something like gThumb or eog:

$ eog ./examine/

or

$ gThumb ./examine/

Now we have all of the content that the authors wanted to prevent us from downloading. The problem with trying to prevent a user from saving a file when the file clearly has to be sent to their computer is like giving someone access to your house without unlocking your door or giving them a key: it cannot be done easily.

Now you have all the tools you need to thwart useless internet protection schemes. This technique will most likely work with Firefox and all Mozilla derived browsers. I’m guessing even the new Ephiphany that uses WebKit will still allow for this. I’ve downloaded many race photos from photographers that try outsmarting me by disabling the file menu, right clicks, [AJ]SP server side hacks, and so many other futile techniques. This technique works with pretty much all files and filetypes. Some of the larger media formats, such as movies and tarballs end up in /tmp, so that requires a bit more digging, but the Ultimate Method can be applied in a similar fashion.

Happy thieving.

I’ve been using Gentoo Linux for several years now and have been growing increasingly frustrated. There has been a steady decline in quality assurance. The core utils team has repeatedly made changes that cause widespread breakages without warning. Many of the ebuilds languish without active maintainers. The Bugzilla database is growing rapidly out of control. There seems to be anamosity amongst the developers as they have been struggling to keep valuable developers (so devrel has failed horribly). Most importantly, the council has decided they don’t want to following the rules set forth for them (lack of attendence at meetings requires an election). The only really promising Gentoo project is the Sunrise project (users submit ebuilds), but even this comes off as an attempt to solve the problem of a lack of developers.

The problems go on and on, most of which stem from the fact that the organization has greatly strayed from it’s original purpose: source compilable meta-distribution. There has been a large focus on the management and increasingly less focus on Getting Things Done. This is usually what causes the death of a project.

Every so often, I venture into DistroWatch to see what has been popular. Most of the time, I don’t see any promise amongst the distributions to provide the same quality and features that I fell in love with when I found Gentoo. Almost every visit meets with a decrease in Gentoo popularity. Recently I have been watching the rise of a distro called Sabayon. It’s based on Gentoo and seemed to have promise.

Upon further inspection, Sabayon is nothing more than a pre-packaged Gentoo overlay. That’s right, you can check out the overlay from a Gentoo install and quickly change to a Sabayon install. This basically does not impress me. So I continue the search.

Arch looks promising but their application tree is very sparse. I used to use Slackware, and would happily switch back if there was something like an up-to-date repository for packages. The “current” repository is nice but the lack of dependencies with the package maintainer could make things very tricky.

I refuse to use a Debian or RedHat based distribution unless there is something very compelling, like Portage and eutils, to draw my attention away. So if anyone out there has an suggestions, feel free to share.

For the longest time, I’ve put up with grief with the bash history when using multiple terminals. It never seemed to store the history to ~/.bash_history properly. I never invested the time until this morning when I had to find a command in my history for the 100th time only to find that it wasn’t there.

After searching around Google for a while, I eventually stumbled on this gem. Moral of the story: unset HISTSIZE for unlimited history, set histappend to always append the history and not overwrite it, and modify your PROMPT_COMMAND to flush each command to the history file.

Now, in following the spirit of showing the latest in the history, here’s mine:

$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
82 ls
81 cd
40 eix
30 vi
28 svn
22 ps
21 dmesg
14 killall
12 su
10 gphoto2

Bear in mind, this only had the default 500 lines before today, so the history is only the most recent commands. I’ll do an update some months from now when my history file grows to an enormous size.

So after using Gentoo for some 5 years now, I’ve learned there are many ways to manage the cruft on my system. I usually use eix and sift through what it shows as installed. When I find something that I don’t think is being used anymore, I check it with equery depends. If everything looked fine, I removed the package and checked the system by using revdep-rebuild.

There is an option (-i IIRC) that will show all installed multi-slotted packages. That is, if you have 6 versions of the kernel installed, it will show you them. This is a pain in the ass if you manage 1 system for 4 years as I have. I have not done in install in a very long time, but instead update my system on a near monthly basis using Gentoo’s Portage system. The downside is it has the tendancy to leave old unused crap on your system.

Then I discovered a tool that was handy at detecting old packages, even old slotted/unused packages, and removed them. Udept is a rather satisfying tool to stumble-upon. It is very adept at identifying unused junk and cleaning your system of it. It has options to purge the system, perform a recursive dependency check, prune your world file, and much more. While I’m not entirely sure I want to maintain a slim world file, the rest of the tool’s capabilities are inferior to none. Granted, it collects much of the capability that is already present with the gentoolkit, but those tools are loosely banded. Udept neatly ties all of that up into one sweet package that can help you keep the crap off your riced-out desktop or server. Best of all, it’s in portage.

After running it for the first time, it found about 3 dozen packages that I agreed needed to be removed. Give it a whirl, and enjoy never having to install your OS again.