DevHeads.net

Suggestions

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: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=550321" title="https://bugzilla.redhat.com/show_bug.cgi?id=550321">https://bugzilla.redhat.com/show_bug.cgi?id=550321</a>

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 ( <a href="https://bugzilla.redhat.com/show_bug.cgi?id=551201" title="https://bugzilla.redhat.com/show_bug.cgi?id=551201">https://bugzilla.redhat.com/show_bug.cgi?id=551201</a>)
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

Comments

Re: Suggestions

By Matt Domsch at 01/26/2010 - 22:26

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

Re: Suggestions (how to choose mirrors)

By Roberto Ragusa at 01/27/2010 - 04:50

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

Re: Suggestions (how to choose mirrors)

By Garrett Holmstrom at 01/27/2010 - 09:51

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.

Re: Suggestions (how to choose mirrors)

By James Antill at 01/27/2010 - 10:35

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.

Re: Suggestions (how to choose mirrors)

By James Antill at 01/27/2010 - 09:42

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.

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

Pipelining is on the TODO, and will likely be done sometime this year.
The rest of it is blocked behind that.

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

Re: Suggestions (how to choose mirrors)

By Rahul Sundaram at 03/11/2010 - 07:38

yum install yum-plugin-download-order

Rahul