Skip to Content.
Sympa Menu

sm-discuss - RE: [SM-Discuss] License Choices

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Phil/CERisE/KG6MBQ <cerise AT littlegreenmen.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: RE: [SM-Discuss] License Choices
  • Date: Tue, 23 Jul 2002 00:09:53 -0700 (PDT)

Jon Svendsen said:

> I'll do this one more time ;)
>
> 1) A gigabyte of RAM will be commonplace pretty soon.

So Microsoft programmers have been telling us...
Remember that Linux was made for those who didn't have 32-bit
processors and/or large amounts of memory.
If it can be done accessibly, then it darn well ought to be, despite
what the future may hold.

> 2) The swap requirement is not "hefty". The space you allocate for swap
> is space you would need to keep available for compilation anyway.

Swap space is essentially unreclaimable. One must repartition
things to do that.
Hard disk space following an rm -r is instantly reclaimable.
However, the point about swap being invoked is speed. A computer
lacking resources will struggle with having to swap things around
instead of keeping BZFlag running at a usable speed. That's annoying.
A severly underprivileged computer (e.g. 386) will take longer than
forever as a result.

> 3) One of the primary benefits of tmpfs compilation is not speed, but
> reduction of filesystem fragmentation and strain. The huge amount of
> tiny writes necessary to keep a system up to date (for years) can
> significantly rape the fs. Compiling in tmpfs avoids that.

"significantly rape the fs", huh? I'd love to see some numbers on
that.
The point of a modern filesystem is that fragmentation isn't a
problem anymore. Personally, I'll take the "tiny writes" every other
day or so (which will be incurred anyway...) over my computer having to
swap things in and out. A small amount of work distributed over time
versus a small amount of work now may be trivial to Joe Blow's single
user linux. On a system with larger throughput, that can make a big
difference.
Fragmentation is more a symptom of those who persist in using FAT
file systems than modern OSes. I can't ever recall seeing a file
system over 5% fragmented on a linux system. And believe me, that's
not for a want of screwed up systems.

> 4) Once more, there is no hefty requirement. You are not using any more
> space than you would need to use anyway.

It's not about space. It's about memory and speed. Linux, once
again, was meant for the 386s. It was meant to avoid the bloat and
high system requirements that we've all come to know Microsoft and
Windows programming for.
Heck, source based systems are meant to take it a step further by
customizing every executable with your system's performance in mind.
With that in mind, why stop there? Why accept the fact that a large
portion of memory goes to holding files and ends up being slower than
writing to disk on a fairly advanced system?
I'll run the argument if pressed, but tempfs can be shown to take a
similar number of disk accesses to compilation in a temp directory.
It runs worse if it requires any swappage at all. This is probably
Since disk is an order of magnitude slower than CPU speed, I think
it's fair to leave it at disk accesses when concerning speed.
tempfs trivially uses more memory to do it's dirty work than using
the native filesystem.
Just on those two things alone, you can be assured that system
updates needn't be planned for the one hour or so that no one will be
on. You could run your updates in parallel with typical user tasks and
not expect too many complaints due to slowdown. I'm thinking of shell
account servers especially when I mention this.
I think it's fair to expect that a system that doesn't have the
resources which Aaron's computer does will widen the gap on those
numbers. A 5 minute gap is fairly significant. After all, it's nearly
a quarter of the 18 and 1/2 which harried Nixon. ; )
Regardless of what the future may bring (higher frequency CPUs,
terabytes of memory, &c), it only makes sense to remember the past.
Failure to do so is to commit one of the many errors of closed source.
I've noticed some people on the list say "Don't take my tempfs."
I can survive if it's at least a choice, but is there a good reason
to keep tempfs in, even as a choice?

-Phil/CERisE







Archive powered by MHonArc 2.6.24.

Top of Page