cpu overheating

Gordon Messmer yinyang at eburg.com
Tue Dec 12 17:38:30 UTC 2006


Tim wrote:
> Gordon Messmer:
>> What's htdig got to do with pie charts?
> 
> Nothing, it was part of another conversation:  A minimal, headless,
> X-less, server installation installing graphical library files.

Oh.  Sorry, I missed some connection.  To address that, then:

# rpm -q --whatrequires `rpm -q --provides libpng` | grep -v '^no '
cups-libs-1.1.22-0.rc1.9.11
# rpm -q --whatrequires `rpm -q --provides cups-libs` | grep -v '^no '
cups-1.1.22-0.rc1.9.11
# rpm -q --whatrequires `rpm -q --provides cups` | grep -v '^no '
redhat-lsb-3.0-8.EL

So, there you go.  "libpng" is needed by cups.  "cups" is needed for LSB 
conformance.  That's why you have graphics libraries on a headless server.

> Only if you're harping on about KDE.  In the other case, there was no
> sane reason for installing some of what got included on a bare bones
> install.  The silliness of the situation was precisely the point
> (alleged requirements, that really are not required).

Some of these things are required to conform to some standard or other 
expectation of functionality, but by and large, they're components 
without which things just won't *work*.

I'm not sure if you're familiar with the way that linking works, but for 
the most part, a library which provides functionality that's optional to 
an application stops being optional as soon as the software is compiled. 
  Once it's built with support for that library, the binary requires it 
to function.  If the library is missing, the linker can't complete its 
task  and the application can't initialize.

If you're into minimalism, you can go the LFS route, or maybe even 
Gentoo.  Most of us, I think, prefer stable systems that offer 
predictable results.  A bare installation is still somewhere in the 
neighborhood of six or seven hundred megs (of which, around two hundred 
is manual pages, documentation, and string translations, vastly out 
sizing the "optional" dependencies), which is hardly unreasonable.

I understand that the source of some dependencies isn't obvious, but if 
it really eats you up, I suggest that you take the time to find out why 
they're required.  The situation is hardly as dire as you seem to think.

> Ignoring KDE, for the moment, it all adds up.  When this programmer
> decides that his program depends on another 20 meg program, and that
> programmer decides that his program on another 50 meg program, it all
> snowballs.

Well, you have these alternative scenarios:
* The developer decides that he doesn't want his application to support 
whatever function.  Users who aren't worried about two cents worth of 
disk space will probably appreciate the functionality more. ($80 / 
260,000MB * 50MB == 1.6 cents)
* The developer implements the features himself.  It takes him 
additional time, which means that bugs in the whole application take 
longer to fix, and new features take longer to come out.  There's no 
guarantee that his implementation is any smaller than the original.

> Other distros can manage barebone installations on systems
> with really small drives and RAM requirements, a fraction of what Fedora
> considered to be a barebones system.

It's not widely advertised, but you can do an installation with only the 
"core" group, rather than "Base", and come out with something around 
300MB, IIRC.  Fedora *probably* lets you customize things more than you 
believe.

> Even then, why it is a requirement to be able to search the
> documentation for KDE?  Perhaps I mightn't want to search the documents.
> Perhaps I mightn't even want to install the documentation.  Don't make
> what should be optional extras into unavoidable dependencies.

Breaking the documentation (and documentation reader) out into its own 
package results in more maintenance for the Fedora team, and more work 
for users, either the ones who want it or the ones who don't.  Requiring 
a 3MB dependency (Around 1/10 cent of disk) to avoid that extra work is 
a reasonable compromise, I think.




More information about the fedora-list mailing list