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

[Robert Scheck]

On Mon, 08 Dec 2008, Jon Stanley wrote:
> CD's are as slow as the reader, which is agonizingly slow on any
> computer, not really restricted to older ones.  Obviously newer
> computers would probably have faster drives, more RAM, etc, and I've
> found various LiveCD's acceptable on newer hardware. I unfortunately
> don't have anything to test on that would be considered "older
> hardware" - I did before I moved to a tiny apartment, but that stuff
> had to stay behind :)

Even a Fedora 9 Live-CD (GNOME) took on a 2.x GHz laptop with 40x CD-ROM
drive and 4 GB RAM ~ 7 minutes to boot. And when opening up e.g. the GNOME
menu, further 5-10 seconds were needed to open the menu. The hardware is
something, that already can be named as "older". At least it is no bleeding
edge hardware ;-)
 
> I certainly don't think that, even though I'm an American.  This
> really falls into the area of usability and QA.  Most of our QA
> contributors are in the US, and I didn't have as much time as I would
> have liked this time around due to $DAYJOB constraints.  However, my
> local mirror is set up in MirrorManager, such that it gets delivered
> to me first in mirrorlists, so I likely wouldn't have noticed this
> anyway, unfortuantely.

Well yes, for Fedora Mirror Manager maybe does the job depending on the
IP range. But as Anaconda from Fedora will go to RHEL and Mirror Manager
and RHEL (or CentOS) will likely not exist the same way as Fedora and the
Mirror Manager do, there really should be some dialog as before, maybe as
"Advanced" option or similar.

> MirrorManager was designed for use in Fedora Infrastructure, which
> happens to run on RHEL5.  No one ever claimed that it was possible to
> run it on RHEL4, however efforts were made to get it working for you.

That's maybe the problem. But software like Mirror Manager has a much wider
distribution as maybe thought. Mirror Manager seems to be exactly developed
for the need of the Fedora Project but no bit more, like for other repos
such as RPM Fusion or their contributors as I'm as well. So we're lacking
the flexibility somehow here.

I already got some pings after that mail by webteam and infrastructure on
IRC to investigate a bit more and hopefully solve it. 

> Package pushes continue to b e a manual process. However, the last
> package that I pushed took less than 24 hours.

Lucky guy. But that's not always the case - especially in the past when
excluding e.g. the last month maybe.

> No need to kill bodhi, simply implement a signing server in a secure
> fashion.

If a signing server solves that issue, we should go there.

> Again, I can't really comment on this except for the last part.  We
> are not wanting to "beat" Ubuntu to anything - there's not an arms
> race here or anything like that.  We are simply normally the first to
> adopt

Well, "Package management has to improve in Fedora to be competitive with
Ubuntu." seems for me to be some case of race and "beating" something. Or
am I such wrong when reading that from the citate?

> You are free to turn them off if you find that you don't need them. How
> else would you suggest we implement these services?

The mcstransd was implemented before as non-daemon. But for some reason it
got a daemon and since, the performance is more poor. Yum-updatesd could
get a cronjob - I think being up-to-date is nice, but being too up-to-date
can hurt very much for a Fedora user nowadays (e.g. dbus).

> Ubuntu also simply uses the compatibility mode.  Some features of upstart
> to enable us to make more use of it did not make it into 0.5, so we're
> continuing in compatibility mode.  Casey Dahlin could shed more light on
> this.

But why do we use upstart, if we only use compatibility mode and if there
seems to be no progress at all?


Greetings,
  Robert