What Fedora makes sucking for me - or why I am NOT Fedora

Richard Hughes hughsient at gmail.com
Tue Dec 9 14:53:03 UTC 2008

On Tue, 2008-12-09 at 01:25 +0100, Robert Scheck wrote:
> PackageKit is resizing windows during installation or updating
> of packages; it's resizing and thus hopping the window if I e.g. select a
> package or if I click around inside of the application. That's something,
> which proves, that there is no usability for end users yet.

If you file a bug I'll fix it.

>  And the
> related GNOME tray utility is also slow and usually is behind the current
> action...that's packagekitd, yes?

gnome-packagekit if you are on GNOME, kpackagekit if you are on KDE. Did
you file a bug about it being slow? It's very fast on my system.

> One of these utilities also often blocks
> the usage of yum with saying, that another application currently holds the
> lock. Why are we locking something when not performing a writing action on
> the RPM database? That seems to be mis-engineered very well.

It only locks the database when there is an active yum transaction
running. I can assure you you don't want two things playing with the
rpmdb at once.

> Independent of that, PackageKit is somehow slow

Not a very useful comment.

> has issues that it doesn't understand
> always where it is or whether an action is already completed. Oh and it
> kills my Firefox nicely during package updating, well-well done.

"kills my firefox" also doesn't seem a great error report. It might help
lower your blood pressure if you filed bugs in bugzilla. Sounds like a
bug in firefox to me.

> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg
> update broke PackageKit stuff - thanks to our cool QA. And clever as we
> are, we did not revoke the update and we also did not push a fixed package
> really immediately out after to solve this.

> I know, that many of the
> desktop people actually love DBUS, but it is horrible stuff, which can
> break down much things with lacking QA like in this case.

The DBus update broke applications not conforming 100% to the spec.
Unfortunately this update was pushed directly into stable (not
updates-testing) and so nobody got a chance to test it. We're all fixing
applications as fast as we can.

> Did you desktop
> people ever think about, that DBUS is not the perfect choice for a server
> system and Fedora is some kind of preview of RHEL?

DBus works very well on a server.

> Yes, Fedora is not the
> playground of Red Hat, but on the other hand, Fedora is - why else is Red
> Hat putting efforts into Fedora if they wouldn't benefit? I really can only
> hope here, that Red Hat removes much of the DBUS breakage and dumbness for
> the next RHEL release and that less DBUS linked packages are making it into
> there...

Maybe you should apply for a job at Red Hat, and then you can give some
opinions on what Red Hat chooses to do with RHEL. I'll tell you a little
secret: RHEL 6 is still going to include DBus.

> And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal
> daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of
> this daemons is written in the memory consuming python

packagekitd, dbus and hal are written in C.

> I'm aware,
> that python is the Red Hat internal defacto default

Erm, unless I missed the memo, there is no "Red Hat internal defacto

> and that scripting is
> much more faster rather coding low-level C. But lets waste ressources as
> e.g. kerneloops daemon does which always consumes a bit of CPU and thus not
> increases the consuming of energy in a positive way. But hey, let's create
> another daemon to monitor where we're wasting and leaking memory...

I don't think this is a reasoned argument, sorry. To be honest, I think
you need to write much shorter, to the point emails. Ranting doesn't
have much affect on anything, whilst filing bugs and getting involved
upstream does.


More information about the fedora-devel-list mailing list