[sf-lug] installing minimal debian and building on that

Sat Dec 8 13:17:14 PST 2018

Rick, I can't thank you enough for your answer to this as well as so 
many other questions in the past.
After studying it, a quick look at 'cat /proc/meminfo' seemed in order 
and the following came up:
"""
MemTotal:        3933692 kB
MemFree:          368748 kB
MemAvailable:    1385608 kB
Buffers:           43076 kB
Cached:          1364376 kB
SwapCached:            0 kB
Active:          2442652 kB
Inactive:         798016 kB
Active(anon):    1726280 kB
Inactive(anon):   374412 kB
Active(file):     716372 kB
Inactive(file):   423604 kB
Unevictable:          16 kB
Mlocked:              16 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB
Dirty:              1504 kB
Writeback:             4 kB
AnonPages:       1833160 kB
Mapped:           360976 kB
Shmem:            267476 kB
Slab:             210260 kB
SReclaimable:     162460 kB
SUnreclaim:        47800 kB
KernelStack:       12208 kB
PageTables:        48964 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4063992 kB
Committed_AS:    7082000 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
.... """

... which I interpret to mean my machine has 4G of RAM (which has served 
me well for many years and I fore see no need to increase it- Indeed 
that may be the limit for my ThinkPad X301 machine anyway.)  That 
coincides with the limit you mention for the (called by Debian) i386 OS.

It's unlikely that either I or my machine will live long enough for 2038 
to be a problem!

My guess there fore is that given this additional info, you'd change 
your recommendation to i386.

Am I correct?

Alex

PS I've never heard anyone on this list speak ill of top posting 
although it is seriously frowned upon by the people at Python Tutor.  
Does this list have an opinion?

On 2018-12-08 11:41, Rick Moen wrote:
> Quoting Alex Kleider (akleider at sonic.net):
> 
>> I've been following the discussion of Desktop and window manager
>> options with interest and would like to try my hand at beginning
>> with a minimal (terminal only) installation and then gradually
>> building  a 'to suit my needs' system.
> 
> Coolness.
> 
>> My first hurdle is which of the following to choose:
> [...]
> 
> cat /proc/cpuinfo:
> 
> [...]
>> model name  : Intel(R) Core(TM)2 Duo CPU     U9400  @ 1.40GHz
> 
> x86 family, which narrows it down to IA32 (which Debian calls 'i386')
> or x86_64 (which for historical reasons Debian still calls 'amd64')
> architectures.  We could look up that processor on the Internet to find
> out if it is x86_64-capable, but instead we can determine this from the
> CPU flags:
> 
> 
> [...]
>> flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni
>> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1
>> lahf_lm kaiser tpr_shadow vnmi flexpriority dtherm ida
> 
> The flag 'lm' stands for 'long mode', indicating that this is x86 with
> 64-bit extensions, i.e., x86_64, which Debian calls amd64.  So, that
> would be the binary image that leverages the Intel Core 2 Duo's ability
> to do 64-bit memory addressing.  But let's talk for a moment about
> memory.
> 
> The main benefit of x86_64 over IA32, aside from increasing problems
> from the approaching 32-bit Unix epoch
> (https://en.wikipedia.org/wiki/Year_2038_problem) is the ability of
> 64-bit CPUs to address dramatically more RAM.  32-bit CPUs are limited
> to a 4GB possible address space,  Because of tricks required such as
> reserved stretches of the memory space, the effective free RAM 
> available
> to the OS on a 32-bit CPU can be a bit less, even if there is 4GB
> physical RAM available.
> 
> By contrast, with a 64-bit CPU, dramatically larger total addressable
> RAM is possible.  In theory, this could be 16.8 million terabytes of
> memory, or 2^64 byte, but real-world motherboard implementations always
> have (so far) had limits imposed elsewhere in the hardware that lower
> the limit to something that's very spacious but not _that_ staggeringly
> high.
> 
> https://stackoverflow.com/questions/8869563/how-much-memory-can-be-accessed-by-a-32-bit-machine
> 
> So, cutting to the chase, that means you should always use an x86_64 OS
> and applications if your x86 CPU has the 'lm' flag indicating 64-bit
> capability, right?
> 
> Well, sorta.  It depends.  Most cases, the answer would be yes.  But
> consider a x86_64 machine that has 2GB total RAM and you're certain it
> will never have more.  In that case, the theoretical ability to address
> more than 4GB of RAM is never going to be used, so you might consider
> for a while running an IA32 build, at least until problems from the
> approaching 32-bit epoch in 2038 become prominent.
> 
> What's the advantage of an IA32 build in that situation?  Binaries and
> data require more RAM in 64-bit computing, because 64-bit pointers take
> up more memory and for some other reasons.  So, it's a bit of a
> tradeoff.  Other subtle aspects are covered here:
> https://en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons
> 
> To get the best of all worlds, have an 86_64 CPU, run an x86_64 OS, and
> have lots of RAM.  Then, you won't mind the slight bloat from 64-bit
> pointers, and will be able to party on January 19, 2038 like it's 2037.
> 
> 
>> I think the amd64 version is the one I want but perhaps it's i386?
> 
> Almost certainly the former.
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>