public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev]  Re: Amount of useflags enabled by default
Date: Sat, 7 Nov 2009 07:46:26 +0000 (UTC)	[thread overview]
Message-ID: <pan.2009.11.07.07.46.26@cox.net> (raw)
In-Reply-To: 4AF4B3EE.5070700@wildgooses.com

Ed W posted on Fri, 06 Nov 2009 23:40:30 +0000 as excerpted:

> I often hear this general kind of commentary.  Just out of interest,
> how/why do you care about the byte count that much? Apart from embedded
> work, or perhaps virtualised servers, I find it surprising to imagine
> that "most people" find the "cost" of minimising installed size (well
> more than the obvious stuff)  to be worth the effort (in general)?

> If you are worried about security issues in dependencies then do also
> look at hardened (esp. with the gcc-4.4 hardened overlay) and perhaps
> grsecurity - this can very effectively mitigate the effects of many
> security holes.

What a lot of (at least non-dev) folks don't realize is that particularly 
on a distribution such as Gentoo, in addition to the size bloat, and 
security considerations, both of which you brought up, there's the simple 
or general ongoing maintenance consideration.  Of course that's not quite 
so big of an issue on embedded, where presumably you install it and let 
it be for long periods of time (perhaps for the life of the unit), but 
for general "computer" use, at /least/ desktop, the ongoing updates and 
maintenance costs **FAR** outweigh any size consideration in the usual 
case, and really, except to the extent that updates and security are tied 
together, they outweigh the security aspect of the additional features as 
well.

It was actually a couple years into my Gentoo experience that the effect 
of "bloat" in the form of optional dependencies (USE flags on Gentoo) 
began to dawn on me, and I've only appreciated it more, since, 
with the effect /particularly/ emphasized to me while I had both kde3 and 
kde4 installed (luckily without Gnome to worry about as well).  That's a 
/huge/ number of additional packages to worry about keeping updated, for 
the revdep-rebuild I run after every update to check and maybe flag for 
rebuild, etc.

To a rather lessor but more frequent extent, updating codecs and/or 
imagemagick invariably triggers a revdep-rebuild on transcode, mplayer, 
xine-libs, and k3b -- and that's with --as-needed in my LDFLAGS, without 
it things would be MUCH MUCH worse.

So if I'm not using a codec, or if I /might/ use it say once every year 
or two, it's DEFINITELY better to have that USE flag off and not have to 
deal with that codec triggering revdep-rebuilds every time it updates, 
and in the event that I DO run across somethign that needs it, just turn 
it on --single-shot, compile what I need with it, do what I want, then 
turn it off and emerge -N and revdep-rebuild to put everything back to 
not using it again.

Of course with the big DEs the effect is far bigger.  It's to the point 
where when looking for an app for some new purpose, if it's dependent on 
the desktop I don't run (GNOME, for me, but KDE for others), that's an 
almost insurmountable barrier to overcome to have me even try it, because 
the cost of continual maintenance of even the basics of an entire DE are 
simply way too high to be worth it for a single app or even two or three, 
unless they happen to be primary functionality for what I'm doing, of 
course, in which case may I'll switch DEs.  I long since settled on KDE 
apps for most of my primary functionality, and the cost of doing 
otherwise is high enough that's unlikely to change unless KDE or my own 
needs change enough that I dump KDE entirely.  (Actually, with kde4, a 
lot of folks have found just that, that KDE changed out from under them 
and no longer meets their needs, so they're switching away from it.  I 
came close, but had enough other reasons to stick with it that I found or 
in some cases scripted my own solutions to the missing or b0rk3n kde4 
functionality, so ended up sticking with it... but at enormous personal  
time and resources investment to do so... enough that comparably, paying 
a grand for MS software would be a reasonable tradeoff... if there 
weren't bigger issues I was worried about.)

But you didn't even mention the cost of continuing maintenance factor for 
all that "bloat", and on a Gentoo system, at least desktop, that's really 
the big one.

BTW, if you could, please turn off the HTML.  Some people find it 
troublesome to deal with.  You (or your client) do include plain text, 
which helps, but do you /really/ need the HTML, at the cost of making 
life harder for some readers?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




      reply	other threads:[~2009-11-07  7:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-23 16:56 [gentoo-dev] Amount of useflags enabled by default Thomas Sachau
2009-10-23 19:32 ` Sebastian Pipping
2009-10-24 16:14   ` Thomas Sachau
2009-10-23 19:54 ` Petteri Räty
2009-10-24 16:03   ` Pacho Ramos
2009-10-24 16:24   ` Thomas Sachau
2009-10-24 19:38     ` William Hubbs
2009-10-24  0:55 ` Alistair Bush
2009-10-24 16:35   ` Thomas Sachau
2009-11-06 23:40     ` Ed W
2009-11-07  7:46       ` Duncan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2009.11.07.07.46.26@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox