Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] smallest board that can handle 32 GB RAM



Kent Borg <kentborg at borg.org> writes:
> Here is why I ask: I am just shifting things over to a new 16GB
> machine. I got that much because I could and it was pretty cheap. But
> I don't know what I am going to do with all that. That is a *bleep* of
> a lot of RAM.

I was just reading the release notes for gcc 4.9. When I
read this part, I thought of this thread, your post in
particular:

       Memory usage building Firefox with debug enabled
       was reduced from 15GB to 3.5GB; link time from
       1700 seconds to 350 seconds.
                    -- http://gcc.gnu.org/gcc-4.9/changes.html

And just the other day I thought I'd like to build
firefox with debugging info since I see crashes running
with the X security extension (or is it XACE I'm
actually using, I don't even know... never mind).  Given
that my laptop has 1.5 GB and my desktop 384 MB that
seems right out.

But if you have 16 GB (or 32 GB!?!) you should
definitely recompile all your programs with debugging
symbols in case one crashes. It's very annoying when
programs crash and you don't have symbols. Or heck, with
that much memory isn't it about time our programs failed
more like this...

EVAL: undefined function MEMCPY
   [Condition of type SYSTEM::SIMPLE-UNDEFINED-FUNCTION]

Restarts:
 0: [USE-VALUE] Input a value to be used instead of (FDEFINITION 'MEMCPY).
 1: [RETRY] Retry
 2: [STORE-VALUE] Input a new value for (FDEFINITION 'MEMCPY).
 3: [RETRY] Retry SLIME REPL evaluation request.
 4: [*PROCESS-INPUT] Continue reading input.
 5: [ABORT] Return to SLIME's top level.
 --more--

Backtrace:
  0: [460] frame binding variables (~ = dynamically):
       | ~ SWANK::*SLDB-STEPPING-P* <--> NIL
  1: [457] frame binding variables (~ = dynamically):
       | ~ SWANK::*SLDB-LEVEL* <--> 0
  2: [454] frame binding variables (~ = dynamically):
       | ~ *PACKAGE* <--> #<PACKAGE COMMON-LISP-USER>
... 



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org