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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
