[gentoo-dev] Re: Packages up for grabs

[Duncan <1i5t5.duncan@cox.net>]

Tom Wijsman posted on Tue, 25 Jun 2013 01:18:07 +0200 as excerpted:

> On Mon, 24 Jun 2013 15:27:19 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Throwing hardware at the problem is usable now.
> 
> If you have the money; yes, that's an option.
> 
> Though I think a lot of people see Linux as something you don't need to
> throw a lot of money at; it should run on low end systems, and that's
> kind of the type of users we shouldn't just neglect going forward.

Well, let's be honest.  Anyone building packages on gentoo isn't likely 
to be doing it on a truly low-end system.  For general linux, yes, 
agreed, but that's what puppy linux and etc are for.  True there's the 
masochistic types that build natively on embedded or a decade plus old 
(and mid-level or lower then!) systems, but most folks with that sort of 
system either have a reasonable build server to build it on, or use a pre-
built binary distro.  And the masochistic types... well, if it takes an 
hour to get the prompt in an emerge --ask and another day or two to 
actually complete, that's simply more masochism for them to revel in. =:^P

Tho you /do/ have a point.

OTOH, some of us used to do MS or Apple or whatever and split our money 
between hardware and software.  Now we pay less for the software, but 
that doesn't mean we /spend/ significantly less on the machines; now it's 
mostly/all hardware.

I've often wondered why the hardware folks aren't all over Linux, given 
the more money available for hardware it can mean, and certainly /does/ 
mean here.

>> Truth is, I used to run a plain make -j (no number and no -l at all) on
>> my kernel builds, just to watch the system stress and then so elegantly
>> recover.  It's an amazing thing to watch, this Linux kernel thing and
>> how it deals with cpu oversaturation.  =:^)
> 
> If you have the memory to pull it off, which involves money again.

What was interesting was doing it without the (real) memory -- letting it 
go into swap and just queue up hundreds and hundreds of jobs as the make 
continued to generate more and more of them, faster than they could even 
fully initialize, particularly since they were packing into swap before 
they even had that chance.

And then with 500-600 jobs or more (custom kernel build, not all-yes/all-
mod config, or it'd likely have been 1200...) stacked up and gigs into 
swap, watch the system finally start to slowly unwind the tangle.  
Obviously the system wasn't usable for anything else during the worst of 
it, but it still rather fascinates me that the kernel scheduling and code 
quality in general is such that it can successfully do that and unwind it 
all, without crashing or whatever.  And the kernel build is one of the 
few projects that's /that/ incredibly parallel, without requiring /too/ 
much memory per individual job, to do it in the first place.

Actually, that's probably the flip side of my getting more conservative.  
The reason I /can/ get more conservative now is that I've enough cores 
and memory that it's actually reasonably practical to do so.  When you're 
always dumping cache and/or swapping anyway, no big deal to do so a bit 
more.  When you have a system big enough to avoid that while still 
getting reasonably large chunks of real work done, and you're no longer 
used to the compromise of /having/ to dump cache, suddenly you're a lot 
more sensitive to doing so at all!

>> Needlessly oversaturating the CPU (and RAM) only slows things down and
>> forces cache dump and swappage.
> 
> The trick is to set it a bit before the point of oversaturating; low
> enough so most packages don't oversaturize, it could be put more
> precisely for every package but that time is better spent elsewhere

Indeed. =:^)

> Not everyone is a sysadmin with a server; I'm just a student running a
> laptop bought some years ago, and I'm kind of the type that doesn't
> replace it while it still works fine otherwise. Maybe when I graduate...

Actually, I use "sysadmin" in the literal sense, the person taking the 
practical responsibility for deciding what goes on a system, when/if/what 
to upgrade (or not), with particular emphasis on RESPONSIBILITY, both for 
security and both keeping the system running and getting it back running 
again when it breaks.  Nothing in that says it has to be commercial, or 
part of some huge farm of systems.  For me, the person taking 
responsibility (or failing to take it) for updating that third-generation 
hand-me-down castoff system is as much of a sysadmin for that system, as 
the guy/gal with 100 or 1000 systems (s)he's responsible for.

My perspective has always been that if all those folks running virus 
infested junk out there actually took the sysadmin responsibility for the 
systems they're running seriously, the virus/malware issue would cease to 
be an issue at all.

Meanwhile, I'll admit my last system was rather better than average when 
I first set it up (dual socket original 3-digit Opteron, that whole 
spending all the money I used to spend on software, on hardware, now, 
thing, my first 64-bit machine and my first and likely last real dual-
CPU... socket); in fact, compared to peers of its time it may well be the 
best system I'll ever own, but that thing lasted me 8+ years.  My goal 
was a decade but I didn't make it as the caps on the mobo were bulging 
and finally popping by the time I got rid of it.  (The last month or so I 
ran it, last summer here in Phoenix, it'd run if I kept it cold enough, 
basically 15C or lower, so I was dressing up in a winter jacket with long 
underwear and a knit hat on, with the AC running to keep it cold enough 
to run the computer inside, while outside it was 40C+!)

But OTOH, that was originally a $400 mobo alone, for quite some time 
worth probably 2-3 grand total as I kept upgrading bits and pieces of it 
as I had the money.  But FTR, I /am/ quite happy with the 6-core 
Bulldozer-1 that replaced it, when I finally really had no other choice.  
And the replacement was *MUCH* cheaper!

But anyway, yeah, I do know a bit about running old hardware, myself, and 
know how to make those dollars strreeettcchh myself. =:^)

-- 
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