Chuck Burns posted on Sun, 05 May 2013 07:46:18 -0500 as excerpted:
> If you -aren't- using your RAM, then you are wasting it. Free RAM means
> your system is not operating at peak performance.
Only to a point. Beyond that, not so much.
If he's "only" running a 4-gig RAM system (I say "only", because I
remember my first x86, with 4 /MB/ RAM... and I was rather late to the
game, KB of ram..., but "only" definitely applies if a single app's using
half of it!) and a single app's using half of it... he's well under that
mark, and any memory freed from unnecessary bloated apps should be
automatically put to use as cache, if nothing else.
But as someone who /has/ grown from a 4-meg memory system all those years
ago, to a 16-gig system today, where much of it really /is/ free memory
most of the time, not even cache filling it...
My application memory set is running ~750 MB ATM, about 3/4 gig. I'm
running ~380 MB buffer memory, and a bit over half a gig of cache. Total
usage including buffers and cache is ~1.7 gigs, so one could argue (as
you apparently would) that I'm "wasting" 14 gigs. As it happens I
rebooted only about 12 hours ago, and haven't done much to fill cache or
use much app memory since then, but I my general working set is around a
gig of app memory and several gigs of cache, still leaving perhaps half
that 16 gigs entirely unused.
However, it isn't entirely wasted, because as I know from my 8-gig days,
when I get the system busy doing something big, app memory will increase
by several gigs, as will cache, until total use is over 8 gigs (including
cache). With 8 gigs physical that ends up topping off memory and
discarding cache, thereby forcing the system to read data back in from
disk the next time I want to look at something that had been cached but
that was discarded from cache when memory got full.
With 16 gigs RAM (tho 12 would work about as well for my case, but 4 4-
gig sticks was technically better balanced), having all that normal-usage
entirely free RAM means that when I do something big that ups both cache
and app usage, I still don't end up over the top, which means full cache
is retained and effectively, once I read something in from disk, it's
cached until reboot (or for temporary mounts like my media and package
repo mount, until I unmount...). I no longer have to worry about going
over the top. Given that 16 gigs cost me well under $100 (IIRC it was
about $80, $20/4-gig-stick, 4-sticks, or ~$5/gig), I'd say it was a
worthwhile investment, even tho most of it is "wasted" most of the time.
But just running something to bloat out that memory so I'm not "wasting"
it isn't going to help anyone, and the system certainly won't be running
any more efficiently as a result, the argument you seem to be making.
Sure, most of the time I've the memory to put to use, but that's the
point, having the memory there to put to use when I need it, without
having to kick out cached data that I'm going to need again reasonably
soon, in ordered to use the memory for whatever else.
>From what I've seen, BTW, for my usage at least, a good generalized rule
of thumb seems to be 1-2 GB RAM per core, somewhat more as the cores
decrease toward 1, less as they increase toward the double-digits. 8
gigs RAM was a very reasonable upper limit for my quad-core, 12 would be
reasonable if stretching it a bit for my 6-core, but due to the
packaging, 8 or 16 was most efficient so 16 it was. But that gives me
room to upgrade to an 8-core without worrying about RAM, if I decide to,
later. Still, 4 gig /is/ sort of wasted ATM, as I really don't often
bust the 12 gig cap let alone the 16-gig. But 8 gig would be a bit tight
on a 6-core, tho not uncomfortably so, and I have 4 slots and wanted
balanced RAM, so 4x4=16-gig it was.
> As far as "low fat kde" goes, sorry, but Linux is not the only player
> here. But the OS that Gentoo took inspiration for it's portage system
> from, has also had custom compilation options for KDE, including not
> building Nepomuk, nor requiring the use of pulseaudio... FreeBSD and
> it's ports system.
It's true that I wasn't counting the non-linux *ixs. Thanks for
broadening the discussion horizon by bringing them in.
> Also, with ArchLinux, you have also -always- been able to get just parts
> of KDE as they were needed/wanted. Plus, even though many KDE-based
> distros ship their systems with pretty much everything including the
> kitchen sink, does NOT mean you cannot simply remove the parts you do
> not want, including disabling Nepomuk completely.
Except... run-time disabling doesn't always mean you can get by without
something installed. If the library was linked in at build-time and it's
not there at run-time, you get a segfault trying to run the app that
linked it in. (Yes there's certain caveats about lazy symbol loading and
etc, but in general...) In that case, it really /is/ a build-time
decision -- you either build with support and force all users to have it
available to link to even if they don't actually use that support to do
anything, or you build without that support, and without the features it
enabled.
Since some user somewhere is likely to find the support useful, most
binary distros tend toward the bloated side, enabling far more than most
of even the most demanding users actually use, because they don't all use
the same features. Other distros deliberately target a slimmed down
profile, but that means some users do without features they'd use if they
were included. There's certainly a convenience of the binary distro, but
that convenience just as certainly has a cost. Some find that cost a
good bargain for what they get, others don't.
However, I don't know to what extent nepomuk/virtuoso/et-al. fit the
build-time-optional, run-time-required-if-linked-at-build-time, model. I
know the rather dramatic differences I saw here when I turned the build-
time options off as opposed to turning it off at runtime, but it's
plausible that on binary distros at least some of that difference is
available by uninstalling some of the components, as well. I don't know
to what extent they really are linked in and thus run-time-required even
if turned off, in this particular case.
> Just because you enjoy "watching shit scroll by since 2005" doesn't mean
> it's the only way to get your system customized. :)
Who does that? Certainly not /this/ gentoo user. I run the update, then
go do something else (like responding to these posts) while it does its
thing. After that it's not much different between binary and from-
source. Major updates require the same config updates and period of
adjusting to the new version, regardless of whether the user built it or
the distro built it, and THAT's the part that takes the time, not the
build process, which I think most gentooers eventually do in the
background while they do something more interesting, once the newness of
watching the build scroll by wears off, which doesn't take long...
(There's also the rather separate question of rolling update vs periodic
update, controlling whether those major updates come one or two at a time
or all at once a time or two a year, but that really /is/ a different
question, since both binary and source-based releases come in both
flavors.)
But, just as I'm very glad there's gnome around for the devs who think
there's "one true way" (aka the gnome-3 syndrome, previous aka the gnome2-
syndrome...) and the users who don't like all those confusing config
options to worry about, because that keeps them out of the hair of the
folks who recognize that people are different and that the dev's "one
true way" might not fit a particular user's idea of /their/ true way, and
thus exposing a config option allowing /both/ ways is a reasonable idea,
so too am I very glad that there are binary distros for those who prefer
them, who would rather someone else make those build-time decisions for
them and find the loss of customization on the one hand and the extra
bloat on the other a very reasonable cost indeed, to pay. But neither of
those cases is me! =:^)
--
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
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
