birger wrote:
1. Applying updates at install time is good. Randomly choosing a mirror
isn't, even if it gets lucky.
1a. Threatening to give up if the mirror is a bit flaky is seriously bad
form. Several times it failed to fetch a package and proposed to reboot.
However, on retrying, the package was downloaded successfully. The one
package I investigated was an update, installing a local copy would have
been better even if out of date - a "yum update" at some time would fix
it. An option of "skip" would be good too, not every package is
critically important, and I could well do without gnome themese.
Doing without packages could also be seen as bad form, and falling back
to an older, local version could lead to a domino effect of
dependencies. Not as easy to fix as it sounds.
I could, but it could evaluate the problem and proffer solutions. An
obvious solution is only to apply "simple" updates or even none at all.
It's easier for me to get the system updated acceptably later than to
start from the beginning.
Importantly, which I do should be my choice.
Of course the robustness could be better. I have not played with f12 in
this respect, but in earlier releases anaconda was more prone to fail on
ftp repos than on http ones (fewer retries if the repo was too busy),
but required more manual input on http repos if there were problems. For
FTP it just retried by itself, for http you had to klick in a dialog for
each retry.
I don't think _I_ use ftp repos. Local mirrors are http, and install
media may be optical disk (real or virtual) or http.
I would say randomly choosing a mirror is good if it is robust enough to
go on choosing new ones until it finds a stable one.
Not if it causes the user download quota or real money. In Oz, Internode
mirrors are best (free) to Internode users, but they cost from my
download quota. OTOH iinet mirrors are free to me but not to Internode
users. iinet should be fastest, I can download at 1.5Mbytes/sec and
better, but Internode is pretty fast too.
Which brings me to
2 Installing stuff I don't want. How hard must it be to do something
equivalent to a ubuntu "server" install, with absolutely no GUI stuff,
especially xorg GUI stuff with Gnome, KDE, XFCE and all the rest?
Dependencies that lead to some packages having to split into non-gui and
gui parts, I would guess? Perhaps also some apps need to have the stuff
depending on gui bits moved into a plugin that could be packaged
separately.
I just did a test remove of CUPS on RHEL5-clone. It wanted to remove
ImageMagic, but ImageMagic is useful without its display abilities -
it's good for batch resizing photos.
I am not too worried about getting a load of X libraries and support
files on a server, as I often need those anyway for tools that I run
with remote display. On the other hand I agree that it should be
possible to install a lean and clean server if I want to. We could call
it - let's see - Fedora Core? :-D
:-)
Regarding languages, I would also like to have the number of languages
and input methods reduced to what I need. Why spend all that cpu and
bandwith updating packages I will never need? Again, I suspect
dependencies are the culprit. This is an issue on desktop systems as
well as servers.
On the other hand, I would like a group that would add all possible
language support. There are lots of places where it is desirable to have
absolutely all possible language support loaded by default.
Really? How many places could need First Nation fonts?
Still a group encompassing all languages comprising all <language>
Supprt packages is pretty simple and has no bearing on "too much."
But not on
servers...
The other current discussion on increasing grub timeout is also
something that is mostly needed on servers.
My proposal would be that with only 'base' selected no gui stuff should
get pulled in. Tall order, yes. Can it be done in time for F13? With
only base, grub should present the good old menu with a 10 second
Yes. hiddenmenu is silly.
timeout. Selecting any workstation-type group (gnome, kde, whatever)
could then pull in a package that modifies grub config to the f12
default?
Let's not get too silly, what is the F12 default?
system-config-grub would be the tool to run. It might use different
defaults depending on the class of user - er - install. Speed demons get
1 second. Ordinary servers get ten. Client machines for ordinary users
get 100 (with might just be enough a server's dhcpd to be up and running
before the client asks for an IP address).
A client machine could be defined as one using DHCP do configure a
network interface.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
