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

[Richard Hughes]

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
default"...

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

Richard.