I don't think it's fair to compare Ubuntu to Fedora. Ubuntu encompasses the mindset of both RHEL and Fedora. With Ubuntu versions, the LTS releases are like RHEL and the non-LTS releases are like Fedora.
I'm a proponent of RHEL/Fedora, but still, Ubuntu can upgrade from LTS to bleeding edge fairly easily. Try that with RHEL.
My experience has been to have trouble with both bleeding edges, Fedora or non-LTS Ubuntu. I don't freak out though, as I know the purpose of the bleeding edge is to suffer the bugs so the RHEL/LTS folks of the world don't have to. That said, using a release backward from current for Fedora or non-LTS Ubuntu usually is pretty stable, supposing you're on your game enough to upgrade before repo EOL.
Interesting - I think your prejudices are out of date. Ubuntu has been an out-of-the-box thing for me for the last two or three years, on old and new hardware, laptop and desktop. Of course I avoid Acer on principle, preferring to stick with Toshiba wherever possible, and I admit I'm not thrilled with its battery sensor support, but the old problems with dual monitors, suspend/resume, sound cards, video cards etc are a shadow of what they used to be.
Meanwhile, my own experience with the Red Hat family is with CentOS, which is either kept artificially out of date for security reasons ("bleeding edge" is well-named, generally) or else I only ever saw poorly-configured old versions. So I don't know enough to compare it, but I'm comfortable with the Debian family so I'm sticking with Ubuntu.
Both have a dependency system, but they are quite different in how they work and resolve dependencies.
Apt/dpkg is also a lot more careful about its treatment of configuration files. Debian packages generally ask questions during preconfigure, build a config file, and then run out of the box. But if you already have a config file it will either be left alone or ask you to resolve the merge.
Only differences that I have noticed and cared about as a home user: Yum lets you do `yum search` but Apt splits that off with `apt-cache` (this is annoying because with yum I can just swap out that 'search' with my line editor). Apt tends to be faster for equivalent operations.
If you use aptitude instead of apt* you get most of the features rolled into one command, and it also provides a curses based interface if you prefer that to the command line but are in a situation where a full GUI is not available to you can use an X based tool. I'm not sure about Ubuntu but it has been standard issue in Debian for some time.
I hope one day there's a command line package manager that works with both DPKG and RPM. Something tells me that will expose the real reason people stick with one over the other; remembering the package manager syntax. I feel no great allegiance to one side or the other, there's nothing of real merit I can differentiate them on, the only real result of the split is package maintainers duplicating work.
I have a set of shell scripts which wrap apt, yum, and macports, so i only have to remember one set of commands. They only cover a small fraction of what those tools can do, but they cover 90% of what i do day to day. They were not at all hard to write.
dpkg -S /some/file # tells you what package provides that file
dpkg -L some-package # lists all the files provided by a package
apt-get search <regex> # lists all package names matching <regex>
There used to be a massive difference. Mostly because debian had apt-get and Redhat had just rpm. That's why we still have sites like rpmfind. Nowadays there is not that big of a difference from end user point of view.
As a dev I still love dpkg-buildpackage way more than rpmbuild.
