Post by Richard OwlettMy formal programming background is limited to an introductory course
using CORC/CUPL (Dartmouth's BASIC being years in future). My last
production code used 8080 assembler - my employer hadn't yet switched
completely to 8085. I've owned a variety of machines - early a PET and
a Kim. Still have a Kaypro 10 in a back room - haven't booted in
decades.
Thank you for the history lesson? I don't see how it impacts how you
should interact with people who tried to help you on a public forum.
Post by Richard OwlettPost by Michael StoneDid the documentation tell you to run lscpu and do something with
the architecture field?
No *GRIN* But is one of reasons I asked.
Over a half century of real real world experience suggested lscpu
would be a suitable reporting tool.
Adding a GRIN doesn't improve things at this point.
When people tried to assist you, you complained:
Not Debian documentation.
Though x86_64 is mentioned in footnotes there is none to indicate that i686
can run Debian 64 bit software (only mention is about 32 bit)
but *you* are the one who brought i686 into the discussion, based on
reading the wrong line in lscpu and going off on a tangent. It's not
their fault that you can't find a reference in the documentation to
information not relevant to the question.
As a matter of fact lscpu can help answer the question, but it's the
second line ("CPU op-mode(s)") that indicates whether the CPU supports
64-bit instructions even if running on a 32 bit kernel, not the
"Architecture" line. *But*, I'm not sure the op-mode line is fully
determinative in the presence of machines which don't support booting
into 64 bit mode even though the CPU supports 64 bit instructions. (I
simply can't recall if the CPU on such a system would mask out support
for 64-bit instructions; I suspect not, but it's been a long time since
I encountered one of those and have no way to confirm the behavior.)
That's why I said you need to either go on a fruitless search for good
system documentation or simply boot the thing to answer the question.
I guess one could argue that it isn't clear that "64-bit op-modes"
aren't referenced specifically in the documentation, but the
countargument would be that the documentation doesn't try to answer the
question based on lscpu output in the first place, probably because it
assumes that anyone who's gotten to the point of running lscpu could very
well run the installer itself.
Post by Richard OwlettPost by Michael StoneIt seems to me that you're doing your own thing in your own way and
expecting us to accomodate that, which seems at least somewhat
unreasonable. For background: the lscpu architecture field doesn't
tell you what kind of cpu you're running. Instead, it tells you the
architecture of the system on which lscpu is running, and more
specifically, what architecture the *kernel* is built for.
lscpu - display information about the CPU architecture
That in no way conflicts with what I wrote. The specific "Architecture"
field is information about the CPU architecture, but comes from the
kernel running on the CPU and does not necessarily reflect the full
capabilities of the CPU itself (without regard to limitations of the
booted kernel). Other fields do come directly from the CPU. All of the
information together is useful to determine what programs can execute on
the system.
Post by Richard OwlettPost by Michael StoneFWIW, there isn't any reasonably general x86 OS that maintains a
comprehensive list of every possible computer model it will run on.
That was *NOT* the question.
I ask "What doth DEBIAN require of my CPU?"
Check the subject line--are you sure that's what you actually asked?
Your original message said: "I'm looking for for where *Debian*
documents which processors support current Debian release." In any
event, the question has been answered multiple times: you need a
processor that supports the AMD64 or Intel 64 instruction sets. You've
referenced that documentation yourself. You've been told that you need
to figure out if your system supports those instructions because debian
doesn't know, and that the easiest way to do so is to simply boot the
installer.
For most people it's sufficient to know that basically any mainstream
computer for the past 10 years supports amd64. Or, they'd just boot it
and find out. But you're in the singular position of demanding a more
complex and technical answer, while simultaneously demanding that the
answer be aimed at a reader with no technical expertise. Sorry, nobody
has written that because the audience of people who have no technical
knowledge but want to gain expertise in a complex area based solely on
reading an installation document is extremely small. In simple cases the
answer is really simple and straightforward ("just assume it will
work"), and in complex cases where that simple answer is wrong it takes
a good deal more background knowledge to understand why things aren't
working. It's far more practical for people to simply try it, and
perhaps ask why it *isn't* working if it does not, than it is for
someone to try to write a simple document explaining complex failure
modes.