Johns thoughts on F13

Wed Nov 25 01:13:52 UTC 2009

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 at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- 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:-)