Hello. First of all: thank you, fedora developers, for making such a great linux distro.
I think I have some good ideas and suggestions that might help you improve Fedora:
1) Create a new plymouth theme (or in other words, ask the artwork team to do so): The current default plymouth theme is almost the same theme from fedora 11. I think we need to change it.
2) Plymouth boot splash background should match the gdm background as I've explained here: https://bugzilla.redhat.com/show_bug.cgi?id=550321
3)Plymouth needs a graphical user interface to select the boot splash screen, with a preview of the selected theme, so the user wouldn't have to reboot to see if he likes the theme.
4) yum should select the mirror to download from in a smarter way, considering the current load on the mirror and the distance of the mirror from the user. This will help reduce the load on the mirrors and make the download faster for the user. The mirrorlist server should know what is the load on each mirror, and give yum the mirrorlist sorted by the load and the distance from the user. yum should prefer the less busy and closest mirror it can find.
5)PackageKit UI improvements: 5.1)When downloading packages, display the percentage of the download progress on the progress bar 5.2)Fix bug #551201 ( https://bugzilla.redhat.com/show_bug.cgi?id=551201) 5.3)Make it possible to undo transactions using gpk-log 6)BiDi problems with translations: this problem is the most annoying thing in fedora for me. gnome-terminal for example doesn't have any bidi support. terminals are not supposed to support BiDi but the problem begins with applications like pkcon or diff, in which terminal output is also translated. that causes unreadable output. e.g if the output was supposed to be שלום it will display םולש. there are two ways to fix this problem 1) make gnome-terminal and others support BiDi output 2) put a comment in each POT file that warns the translator about strings which will be written in the terminal so translators would know what should be translated I think the first way is better.
7)Combine all hardware listing programs (e.g hwbrowser, usbview, lshw-gui) into one, comprehensive, easy to use GUI.
thank you for listening.
-Elad
On Tue, Jan 26, 2010 at 04:09:35PM +0200, ???????? wrote:
yum should select the mirror to download from in a smarter way, considering the current load on the mirror and the distance of the mirror from the user. This will help reduce the load on the mirrors and make the download faster for the user. The mirrorlist server should know what is the load on each mirror, and give yum the mirrorlist sorted by the load and the distance from the user. yum should prefer the less busy and closest mirror it can find.
MirrorManager (used by yum through Fedora and rpmfusion's repository files) partially implements this. It uses BGP routing data and GeoIP to guess at the distance from the user, in decending order, * specific network blocks (IPv4 and v6) * same Autonomous System * both client and server on Internet2 or related high-speed research network * same country * same continent * any other mirror
Further, it weighs the choice in each of the above lists by the nominal bandwidth available by a particular mirror (e.g. if mirror A is capable of serving 100Mbps, while mirror B is capable of serving 1Gbps, mirror A will be chosen 1/10 as often as mirror B).
Fedora has 244 public mirrors listed at the moment, and hundreds more private mirrors. We have no way, nor really any desire, to know in real time the load and network capacity of any connection between each mirror and each specific user. Perhaps Akamai does, but that's not a service we pay for.
Thanks, Matt Fedora Mirror Wrangler, and MirrorManager author
Matt Domsch wrote:
Fedora has 244 public mirrors listed at the moment, and hundreds more private mirrors. We have no way, nor really any desire, to know in real time the load and network capacity of any connection between each mirror and each specific user. Perhaps Akamai does, but that's not a service we pay for.
Just an idea: instead of (or in addition to) "blind" planning, based on net topology, geography, declared bandwith etc., yum could use an exploration approach:
1) choose a few good mirrors candidate 2) download one file from each of them (first file from first mirror, second file from second mirror, ....) 3) gather speed statistics 4) reevaluate best mirrors according to statistics for the remaining files
If the downloads are sorted by increasing size, you basically use the small ones to sample the mirrors and make a good choice for the big ones at the end of the list.
(doing many downloads in parallel would be the real plus, so the slow and ugly mirror taking 1 minute for the 40kB file will complete while the good mirrors are serving you the kernel and openoffice.org)
This would also be automatically optimal for local mirrors.
Note that this is almost how P2P sharing works (just missing the sub-file granularity).
On Wed, 2010-01-27 at 10:50 +0100, Roberto Ragusa wrote:
Matt Domsch wrote:
Fedora has 244 public mirrors listed at the moment, and hundreds more private mirrors. We have no way, nor really any desire, to know in real time the load and network capacity of any connection between each mirror and each specific user. Perhaps Akamai does, but that's not a service we pay for.
Just an idea: instead of (or in addition to) "blind" planning, based on net topology, geography, declared bandwith etc., yum could use an exploration approach:
- choose a few good mirrors candidate
- download one file from each of them (first file from
first mirror, second file from second mirror, ....) 3) gather speed statistics 4) reevaluate best mirrors according to statistics for the remaining files
This is fine in theory, but there are a few problems. And more than a few changes have to be made before we can do it.
If the downloads are sorted by increasing size, you basically use the small ones to sample the mirrors and make a good choice for the big ones at the end of the list.
Except we got significant complaints when we did that sort, so I'm not dying to do it again (even though I did it, and thought it was better).
(doing many downloads in parallel would be the real plus, so the slow and ugly mirror taking 1 minute for the 40kB file will complete while the good mirrors are serving you the kernel and openoffice.org)
Pipelining is on the TODO, and will likely be done sometime this year. The rest of it is blocked behind that.
This would also be automatically optimal for local mirrors.
Unlikely, the problem with local mirrors is that it's often optimal to download from them as we are atm. ... any attempt to use another mirror is slower (and sometimes more expensive). In fact my local mirror is often so fast that I seriously doubt whether much improvement could be made due to pipelining etc. (which is not the case with anything outside my network).
On 01/27/2010 08:12 PM, James Antill wrote:
On Wed, 2010-01-27 at 10:50 +0100, Roberto Ragusa wrote:
If the downloads are sorted by increasing size, you basically
use the small ones to sample the mirrors and make a good choice for the big ones at the end of the list.
Except we got significant complaints when we did that sort, so I'm not dying to do it again (even though I did it, and thought it was better).
yum install yum-plugin-download-order
Rahul
On Wed, Jan 27, 2010 at 3:50 AM, Roberto Ragusa mail@robertoragusa.it wrote:
Just an idea: instead of (or in addition to) "blind" planning, based on net topology, geography, declared bandwith etc., yum could use an exploration approach:
- choose a few good mirrors candidate
- download one file from each of them (first file from
first mirror, second file from second mirror, ....) 3) gather speed statistics 4) reevaluate best mirrors according to statistics for the remaining files
You're basically describing yum-plugin-fastestmirror. Of course that doesn't get one any sort of parallelism when downloading packages, but it answers one of your complaints by rating actual data rates.
-- Garrett Holmstrom
On Wed, 2010-01-27 at 08:51 -0600, Garrett Holmstrom wrote:
On Wed, Jan 27, 2010 at 3:50 AM, Roberto Ragusa mail@robertoragusa.it wrote:
Just an idea: instead of (or in addition to) "blind" planning, based on net topology, geography, declared bandwith etc., yum could use an exploration approach:
- choose a few good mirrors candidate
- download one file from each of them (first file from
first mirror, second file from second mirror, ....) 3) gather speed statistics 4) reevaluate best mirrors according to statistics for the remaining files
You're basically describing yum-plugin-fastestmirror. Of course that doesn't get one any sort of parallelism when downloading packages, but it answers one of your complaints by rating actual data rates.
fastestmirror does not do "data download measuring", which the above implies. It measures latency (via. connect), which is often a good substitute and has the advantage of being fast enough. But it can do obviously wrong things, like ignore a local mirror that had a temporary problem.
It also uses measured data for upto 10 days, by default.
So personally I'd prefer to just rely on MirrorManager. But saying all that a lot of people swear by it, and CentOS (who don't use MirrorManager) require it.
-
Elad -
Garrett Holmstrom -
James Antill -
Matt Domsch -
Rahul Sundaram -
Roberto Ragusa