aboutsummaryrefslogtreecommitdiffstats
path: root/README.txt
diff options
context:
space:
mode:
authorLibravatarUnit 193 <unit193@ubuntu.com>2018-05-12 16:25:51 -0400
committerLibravatarUnit 193 <unit193@ubuntu.com>2018-05-12 16:25:51 -0400
commit8e2439019187be5e6576b6a400d48aed4731354a (patch)
tree1130528b92e83e1d33a5717d54fcc0582f2609e2 /README.txt
parent2f191c302fed4463b1192d2595184a65411adf25 (diff)
downloadinxi-8e2439019187be5e6576b6a400d48aed4731354a.tar.bz2
inxi-8e2439019187be5e6576b6a400d48aed4731354a.tar.xz
inxi-8e2439019187be5e6576b6a400d48aed4731354a.tar.zst
New upstream version 3.0.09-1upstream/3.0.09-1
Diffstat (limited to 'README.txt')
-rw-r--r--README.txt574
1 files changed, 287 insertions, 287 deletions
diff --git a/README.txt b/README.txt
index 5443b0b..1970c17 100644
--- a/README.txt
+++ b/README.txt
@@ -1,32 +1,61 @@
README for inxi - a command line system information tool
-The new Perl inxi is now here! File all issue reports with the master
-branch. All support for versions prior to 3.0 is now ended, sorry.
+The new faster, more powerful Perl inxi is here! File all issue reports
+with the master branch. All support for versions prior to 3.0 is now ended,
+sorry.
-Make sure to update to the current inxi from the master branch before
-filing any issue reports. The code in pre 2.9 versions literally no
-longer exists in inxi 3. Bugs from earlier versions cannot be solved
-in the new version since the pre 2.9 and the 2.9 and later versions
-are completely different internally.
+Make sure to update to the current inxi from the master branch before filing
+any issue reports. The code in pre 2.9 versions literally no longer exists in
+inxi 3. Bugs from earlier versions cannot usually be solved in the new version
+since the pre 2.9 and the 2.9 and later versions are completely different
+internally.
-inxi strives to support the widest range of operating systems and
-hardware, from the most simple consumer desktops, to the most advanced
-professional hardware and servers.
+===============================================================================
+Help inxi development! Submit a user debugger dataset.
-The issues you post help maintain or expand that support, and are
-always appreciated since user data and feedback is what keeps inxi
-working and supporting the latest or not so latest hardware and
-operating systems.
+This is easy to do, and only takes a few seconds. These datasets really help
+the project add and debug features. You will generally also be asked to provide
+this data for non trivial issue reports.
-See the BSD section below for qualifications re BSDs, and OSX in
-particular.
+Note that the following options are present:
-=====================================================================
+1. Generate local gz'ed debugger dataset. Leaves gz on your system:
+ inxi version 3: inxi --debug 20
+ inxi version <= 2.3: inxi -@14
+2. Generate, upload gz'ed debugger dataset. Leaves gz on your system:
+ inxi version 3: inxi --debug 21
+ inxi version <= 2.3: inxi -xx@14
+3. Generate, upload, delete gz'ed debugger dataset:
+ inxi version 3 only: inxi --debug 22
+
+You can run these as regular user, or root/sudo, which will gather a bit more
+data, like from dmidecode, and other tools that need superuser permissions
+to run.
+
+ARM and BSD datasets are particularly appreciated because we simply do not
+have enough of those.
+
+===============================================================================
+Make inxi better! Get more support, fix broken items!
+
+inxi strives to support the widest range of operating systems and hardware,
+from the most simple consumer desktops, to the most advanced professional
+hardware and servers.
+
+The issues you post help maintain or expand that support, and are always
+appreciated since user data and feedback is what keeps inxi working and
+supporting the latest (or not so latest) hardware and operating systems.
+
+See the BSD section below for qualifications re BSDs, and OSX in particular.
+
+===============================================================================
+BRANCHES
+-------------------------------------------------------------------------------
MASTER BRANCH:
-This is the only supported branch, and the current latest commit is
-the only supported 'release'. There are no 'releases' of inxi beyond
-the current commit to master. All past commits are not supported.
+This is the only supported branch, and the current latest commit/version is
+the only supported 'release'. There are no 'releases' of inxi beyond the
+current commit/version in master. All past versions are not supported.
git clone https://github.com/smxi/inxi --branch master --single-branch
@@ -37,18 +66,15 @@ OR easy to remember shortcut (which redirects to github):
wget -Nc https://smxi.org/inxi
wget -Nc smxi.org/inxi
-'Tagging' is purely a formality that certain distros can't figure out
-how to do without, that's all. A tag is a pointer to a commit, and has
-no further meaning.
+'Tagging' is purely a formality that certain distros can't figure out how to
+do without, that's all. A tag is a pointer to a commit, and has no further
+meaning.
-NOTE: Just because github calls tagged commits 'Releases' does not
-mean they are releases! I can't change the words on the tag page.
-They are tagged commmits, period. I did not want to use tags precisely
-to avoid the idea that inxi has any release that exists that is other
-than it's current master version, but I decided that it was less pain
-to add tags than to argue this point any further.
+NOTE: Just because github calls tagged commits 'Releases' does not mean they
+are releases! I can't change the words on the tag page. They are tagged
+commmits, period.
-=====================================================================
+-------------------------------------------------------------------------------
DEVELOPMENT BRANCH:
All active development is now done on the inxi-perl branch (pinxi):
@@ -61,13 +87,13 @@ OR easy to remember shortcut (which redirects to github):
wget -Nc https://smxi.org/pinxi
wget -Nc smxi.org/pinxi
-Once new features have been debugged, tested, and are stable, they
-will move to the master branch.
+Once new features have been debugged, tested, and are stable, they will move
+to the master branch.
-=====================================================================
+-------------------------------------------------------------------------------
LEGACY BRANCH:
-If you'd like to look at or check out the Gawk/Bash version of inxi,
-you can find it here, at the inxi-legacy branch (binxi):
+If you'd like to look at or check out the Gawk/Bash version of inxi, you can
+find it here, at the inxi-legacy branch (binxi):
git clone https://github.com/smxi/inxi --branch inxi-legacy --single-branch
@@ -77,42 +103,40 @@ wget -Nc https://github.com/smxi/inxi/raw/inxi-legacy/binxi
OR easy to remember shortcut (which redirects to github):
wget -Nc https://smxi.org/binxi
-This version will not be maintained, and it's unlikely that any time
-will be spent on it in the future, but it is there in case it's of
-use or interest to anyone.
+This version will not be maintained, and it's unlikely that any time will be
+spent on it in the future, but it is there in case it's of use or interest to
+anyone.
-=====================================================================
+===============================================================================
SUPPORT INFO:
-Do not ask for basic help that reading the inxi -h / --help menus, or
-man page would show you, and do not ask for features to be added that
-inxi already has. Also do not ask for support if your distro won't
-update its inxi version, some are bad about that.
+Do not ask for basic help that reading the inxi -h / --help menus, or man page
+would show you, and do not ask for features to be added that inxi already has.
+Also do not ask for support if your distro won't update its inxi version, some
+are bad about that.
DOCUMENTATION: https://smxi.org/docs/inxi.htm
-(smxi.org/docs/ is easier to remember, and is one click away from
-inxi.htm). The one page wiki on github is only a pointer to the real
-resources.
+(smxi.org/docs/ is easier to remember, and is one click away from inxi.htm).
+The one page wiki on github is only a pointer to the real resources.
https://github.com/smxi/inxi/tree/inxi-perl/docs
-Contains specific Perl inxi documentation, of interest mostly to
-developers. Includes internal inxi tools, values, configuration items.
-Also has useful information about Perl version support, including the
-list of Core modules that _should_ be included in a distribution's
-core modules, but which are unfortunately sometimes removed.
+Contains specific Perl inxi documentation, of interest mostly to developers.
+Includes internal inxi tools, values, configuration items. Also has useful
+information about Perl version support, including the list of Core modules that
+_should_ be included in a distribution's core modules, but which are
+unfortunately sometimes removed.
HTML MAN PAGE: https://smxi.org/docs/inxi-man.htm
INXI OPTIONS PAGE: http://smxi.org/docs/inxi-options.htm
-NOTE: These may not always be up to date, but generally track the most
-recent inxi commits.
+NOTE: These may not always be up to date, but generally track the most recent
+inxi commits.
ISSUES: https://github.com/smxi/inxi/issues
-No issues accepted for non current inxi releases. See below for more on
-that. Unfortunately as of 2.9, no support or issues can be accepted for
-older inxi's because inxi 2.9 (Perl) and newer is a full rewrite, and
-legacy inxi is not being supported since our time here on earth is
-finite (plus of course, one reason for the rewrite was to never have
-to work with Gawk->Bash again!).
+No issues accepted for non current inxi versions. See below for more on that.
+Unfortunately as of 2.9, no support or issues can be accepted for older inxi's
+because inxi 2.9 (Perl) and newer is a full rewrite, and legacy inxi is not
+being supported since our time here on earth is finite (plus of course, one
+reason for the rewrite was to never have to work with Gawk->Bash again!).
SUPPORT FORUMS: https://techpatterns.com/forums/forum-33.html
This is the best place to place support issues that may be complicated.
@@ -123,254 +147,230 @@ DEVELOPER FORUMS: https://techpatterns.com/forums/forum-32.html
SOURCE VERSION CONTROL: https://github.com/smxi/inxi
MAIN BRANCH: master
DEVELOPMENT BRANCHES: inxi-perl, one, two
-inxi-perl is the dev branch, the others are rarely if ever used. inxi
-itself has the built in feature to be able to update itself from
-anywhere, including these branches, which is very useful for development
-and debugging on various user systems.
-
-PULL REQUESTS: Please talk to me before starting to work on patches of
-any reasonable complexity. inxi is hard to work on, and you have to
-understand how it works before submitting patches, unless it's a trivial
-bug fix. Please: NEVER even think about looking at or using previous
-inxi commits, previous to the current master version, as a base for a
-patch. If you do, your patch / pull request will probably be rejected.
-Developers, get your version from the inxi-perl branch, pinxi, otherwise
-you may not be current to actual development versions. inxi-perl pinxi
-is always equal to or ahead of master branch inxi.
-
-Man page updates, doc page updates, etc, of course, are easy and will
-probably be accepted, as long as they are properly formatted and
-logically coherent.
-
-inxi releases early, and releases often, when under development.
+inxi-perl is the dev branch, the others are rarely if ever used. inxi itself
+has the built in feature to be able to update itself from anywhere, including
+these branches, which is very useful for development and debugging on various
+user systems.
+
+PULL REQUESTS: Please talk to me before starting to work on patches of any
+reasonable complexity. inxi is hard to work on, and you have to understand how
+it works before submitting patches, unless it's a trivial bug fix. Please:
+NEVER even think about looking at or using previous inxi commits, previous to
+the current master version, as a base for a patch. If you do, your patch / pull
+request will probably be rejected. Developers, get your version from the
+inxi-perl branch, pinxi, otherwise you may not be current to actual development
+versions. inxi-perl pinxi is always equal to or ahead of master branch inxi.
+
+Man page updates, doc page updates, etc, of course, are easy and will probably
+be accepted, as long as they are properly formatted and logically coherent.
+
+When under active development, inxi releases early, and releases often.
PACKAGERS: inxi has one and only one 'release', and that is the current
-commit to master branch (plus pinxi inxi-perl branch, of course, but
-those should never be packaged).
+commit/version in the master branch (plus pinxi inxi-perl branch, of course,
+but those should never be packaged).
-=====================================================================
+===============================================================================
ABOUT INXI - CORE COMMITMENT TO LONG TERM STABILITY
-inxi is a command line system information tool. It was forked from the
-ancient and mindbendingly perverse yet ingenius infobash, by locsmif.
-
-That was a buggy, impossible to update or maintain piece of software,
-so the fork fixed those core issues, and made it flexible enough to
-expand the utility of the original ideas. Locmsif has given his thumbs
-up to inxi, so don't be fooled by legacy infobash stuff you may see
-out there.
-
-inxi is lower case, except when I create a text header here in a file
-like this, but it's always lower case. Sometimes to follow convention
-I will use upper case inxi to start a sentence, but i find it a bad
-idea since invariably, someone will repeat that and type it in as the
-command name, then someone will copy that, and complain that the
-command: Inxi doesn't exist...
-
-The primary purpose of inxi is for support, and sys admin use. inxi
-is used widely for forum and IRC support, which is I believe it's most
-common function.
-
-If you are piping output to paste or post (or writing to file), inxi
-now automatically turns off color codes, so the old suggestion to
-use -c 0 to turn off colors is no longer required.
-
-inxi should always show you your current system state, as far as
-possible, and should be more reliable than your own beliefs about
-what is in your system, ideally. In other words, the goal in inxi
-is to have it be right more than it is wrong about any system that
-it runs on. And not to rely on non current system state data if at
-all possible. Some things, like memory/ram data, rely on radically
-unreliable system self reporting based on OEM filling out data
-correctly, which doesn't often happen, so in those cases, you want to
-confirm things like ram capacity with a reputable hardware source,
-like crucial.com, which has the best ram hardware tool I know of.
-
-The core mission of inxi is to always work on all systems all the
-time. Well, all systems with the core tools inxi requires to operate
-installed. Ie, not Android, yet. What this means is this: you can
-have a 10 year old box, or probably 15, not sure, and you can install
-today's inxi on it, and it will run. It won't run fast, but it will
-run. I test inxi on a 200 MHz laptop from about 1998 to keep it
-honest. That's also what was used to optimize the code at some
-points, since differences appear as seconds, not 10ths or 100ths
-of seconds on old systems like that.
-
-inxi is being written, and tested, on Perl as old as 5.08, and will
-work on any system that runs Perl 5.08 or later. Pre 2.9.0 Gawk/Bash
-inxi will also run on any system no matter how old, within reason,
-so there should be no difference.
-
-=====================================================================
+inxi is a command line system information tool. It was forked from the ancient
+and mindbendingly perverse yet ingenius infobash, by locsmif.
+
+That was a buggy, impossible to update or maintain piece of software, so the
+fork fixed those core issues, and made it flexible enough to expand the utility
+of the original ideas. Locmsif has given his thumbs up to inxi, so don't be
+fooled by legacy infobash stuff you may see out there.
+
+inxi is lower case, except when I create a text header here in a file like
+this, but it's always lower case. Sometimes to follow convention I will use
+upper case inxi to start a sentence, but i find it a bad idea since invariably,
+someone will repeat that and type it in as the command name, then someone will
+copy that, and complain that the command: Inxi doesn't exist...
+
+The primary purpose of inxi is for support, and sys admin use. inxi is used
+widely for forum and IRC support, which is I believe it's most common function.
+
+If you are piping output to paste or post (or writing to file), inxi now
+automatically turns off color codes, so the old suggestion to use -c 0 to turn
+off colors is no longer required.
+
+inxi should always show you your current system state, as far as possible, and
+should be more reliable than your own beliefs about what is in your system,
+ideally. In other words, the goal in inxi is to have it be right more than it
+is wrong about any system that it runs on. And not to rely on non current
+system state data if at all possible. Some things, like memory/ram data, rely
+on radically unreliable system self reporting based on OEM filling out data
+correctly, which doesn't often happen, so in those cases, you want to confirm
+things like ram capacity with a reputable hardware source, like crucial.com,
+which has the best ram hardware tool I know of.
+
+The core mission of inxi is to always work on all systems all the time. Well,
+all systems with the core tools inxi requires to operate installed. Ie, not
+Android, yet. What this means is this: you can have a 10 year old box, or
+probably 15, not sure, and you can install today's inxi on it, and it will run.
+It won't run fast, but it will run. I test inxi on a 200 MHz laptop from about
+1998 to keep it honest. That's also what was used to optimize the code at some
+points, since differences appear as seconds, not 10ths or 100ths of seconds on
+old systems like that.
+
+inxi is being written, and tested, on Perl as old as 5.08, and will work on any
+system that runs Perl 5.08 or later. Pre 2.9.0 Gawk/Bash inxi will also run on
+any system no matter how old, within reason, so there should be no difference.
+
+===============================================================================
BSD SUPPORT
Real BSDs:
-BSD support is not as complete as GNU/Linux support due to the fact
-some of the data simply is not available, or is structured in a way
-that makes it unique to each BSD. This fragmentation makes supporting
-BSDs far more difficult than it should be in the 21st century. The
-BSD support in inxi is an ongoing process, with more features being
-added as new data sources and types are discovered.
-
-All BSD issue reports unless trivial and obvious will require 1 of
-two things:
-
-1. a full --debug 21 data dump so I don't have to spend days trying
-to get the information I need to resolve the issue file by painful
-file from the issue poster. This is only the start of the process,
-and realistically requires 2. to complete it.
-
-2. direct SSH access to at least a comparable live BSD version/system,
-that is, if the issue is on a laptop, access has to be granted to the
-laptop, or a similar one.
-
-Option 2 is far preferred because in terms of my finite time on this
-planet of ours, the fact is, if I don't have direct (or SSH) access,
-I can't get much done, and the little I can get done will take 10 to
-1000x longer than it should. That's my time spent (and sadly, with
-BSDs, largely lost), not yours.
-
-I decided I have to adopt this much more strict policy with BSDs
-after wasting untold hours on trying to get good BSD support, only
-to see that support break a few years down the road as the data inxi
-relied in changed structure or syntax, or the tools changed, or
-whatever else makes the BSDs such a challenge to support. In the end,
-I realized, the only BSDs that are well supported are ones that I have
-had direct access to for debugging and testing.
+BSD support is not as complete as GNU/Linux support due to the fact some of the
+data simply is not available, or is structured in a way that makes it unique to
+each BSD. This fragmentation makes supporting BSDs far more difficult than it
+should be in the 21st century. The BSD support in inxi is an ongoing process,
+with more features being added as new data sources and types are discovered.
+
+All BSD issue reports unless trivial and obvious will require 1 of two things:
+
+1. a full --debug 21 data dump so I don't have to spend days trying to get the
+information I need to resolve the issue file by painful file from the issue
+poster. This is only the start of the process, and realistically requires 2. to
+complete it.
+
+2. direct SSH access to at least a comparable live BSD version/system, that is,
+if the issue is on a laptop, access has to be granted to the laptop, or a
+similar one.
+
+Option 2 is far preferred because in terms of my finite time on this planet of
+ours, the fact is, if I don't have direct (or SSH) access, I can't get much
+done, and the little I can get done will take 10 to 1000x longer than it
+should. That's my time spent (and sadly, with BSDs, largely lost), not yours.
+
+I decided I have to adopt this much more strict policy with BSDs after wasting
+untold hours on trying to get good BSD support, only to see that support break
+a few years down the road as the data inxi relied in changed structure or
+syntax, or the tools changed, or whatever else makes the BSDs such a challenge
+to support. In the end, I realized, the only BSDs that are well supported are
+ones that I have had direct access to for debugging and testing.
I will always accept patches that are well done, if they do not break
-GNU/Linux, and extend BSD support, or add new BSD features, and follow
-the internal inxi logic, and aren't too long. inxi sets initial internal
-flags to identify that it is a BSD system vs a GNU/Linux system, and
-preloads some data structures for BSD use, so make sure you understand
-what inxi is doing before you get into it.
+GNU/Linux, and extend BSD support, or add new BSD features, and follow the
+internal inxi logic, and aren't too long. inxi sets initial internal flags to
+identify that it is a BSD system vs a GNU/Linux system, and preloads some data
+structures for BSD use, so make sure you understand what inxi is doing before
+you get into it.
OSX:
-Do not insult real BSDs by calling OSX a BSD. OSX is the least
-Unix-like operating system I've ever seen that claims to be a Unix,
-its tools are mutated, it's data randomly and non-standardly organized,
-and it totally fails to respect the 'spirit' of Unix, even though it
-might pass some random tests that certify a system as a 'Unix'.
-
-If you want me to use my time on OSX features or issues, you have to
-pay me, because Apple is all about money, not freedom (that's what
-the 'free' in 'free software' is referring to, not cost), and I'm not
-donating my finite time in support of non-free operating systems.
-
-=====================================================================
+Do not insult real BSDs by calling OSX a BSD. OSX is the least Unix-like
+operating system I've ever seen that claims to be a Unix, its tools are
+mutated, it's data randomly and non-standardly organized, and it totally fails
+to respect the 'spirit' of Unix, even though it might pass some random tests
+that certify a system as a 'Unix'.
+
+If you want me to use my time on OSX features or issues, you have to pay me,
+because Apple is all about money, not freedom (that's what the 'free' in 'free
+software' is referring to, not cost), and I'm not donating my finite time in
+support of non-free operating systems.
+
+===============================================================================
INXI FEATURES AND FUNCTIONALITY
-inxi's functionality continues to grow over time, but it's also
-important to understand that each core new feature usually requires
-about 30 days work to get it stable. So new features are not trivial
-things, nor is it acceptable to submit a patch that works only on your
-personal system. One inxi feature (-s, sensors data), took about
-2 hours to get working in the alpha test on the local dev system, but
-then to handle the massive chaos that is actual user sensors output
-and system variations, it took several rewrites and about 30 days to
-get somewhat reliable for about 98% or so of inxi users. So if your
-patch is rejected, it's likely because you have not thought it through
-adequately, have not done adequate testing cross system and
-platform, etc.
-
-=====================================================================
-INXI RELEASE/SUPPORT/ISSUES/BUGS INFORMATION:
-
-Important: the only version of inxi that is supported is the latest
-current master branch release. No issue reports or bug reports will be
-accepted for anything other than current master branch. No merges,
-attempts to patch old code from old releases, will be considered or
-accepted. If you are not updated to the latest inxi, do not file a
-bug report since it's probably been fixed ages ago. If your distro
-isn't packaging a current inxi, then file a bug report with them, not
-here. The only valid working code base for inxi is the current
-release of inxi.
-
-Distributions should never feel any advantage comes from using old
-inxi releases because inxi has as a core promise to you, the end user,
-that it will NEVER require new tools to run. New tools may be required
-for a new feature, but that will always be handled internally by inxi,
-and will not cause any operational failures. This is a promise, and I
-will never as long as I run this project violate that core inxi
-requirement. Old inxi is NOT more stable than current inxi, it's just
-old, and lacking in bug fixes and features. For pre 2.9 releases, it's
-also significantly slower, and with fewer features.
-
-inxi is a rolling release codebase, just like Debian Sid, Gentoo, or
-Arch Linux are rolling release GNU/Linux distributions, with no
-'release points'.
-
-Your distro not updating inxi ever, then failing to show something
-that is fixed in current inxi is not a bug, and please do not post it
-here. File the issue with your distro, not here. Updating inxi in a
-package pool will NEVER make anything break or fail, period. It has no
-version based dependencies, just software, like Perl 5.xx, lspci, etc.
-There is never a valid reason to not update inxi in a package pool of
-any distro in the world (with one single known exception, the Slackware
-based Puppy Linux release, which ships without the full Perl language.
-The Debian based one works fine).
-
-Sys Admin type inxi users always get the first level of support. ie,
-convince us you run real systems and networks, and your issue shoots
-to the top of the line. As do any real bugs. Failure to supply
-requested debugger data will lead to a distinct lack of interest on
-our part to help you with a bug. ie, saying, oh, x doesn't work,
-doesn't cut it, unless it's obvious why.
-
-=====================================================================
+inxi's functionality continues to grow over time, but it's also important to
+understand that each core new feature usually requires about 30 days work to
+get it stable. So new features are not trivial things, nor is it acceptable to
+submit a patch that works only on your personal system. One inxi feature (-s,
+sensors data), took about 2 hours to get working in the alpha test on the local
+dev system, but then to handle the massive chaos that is actual user sensors
+output and system variations, it took several rewrites and about 30 days to
+get somewhat reliable for about 98% or so of inxi users. So if your patch is
+rejected, it's likely because you have not thought it through adequately, have
+not done adequate testing cross system and platform, etc.
+
+===============================================================================
+INXI VERSION/SUPPORT/ISSUES/BUGS INFORMATION:
+
+Important: the only version of inxi that is supported is the latest current
+master branch version/commit. No issue reports or bug reports will be accepted
+for anything other than current master branch. No merges, attempts to patch old
+code from old versions, will be considered or accepted. If you are not updated
+to the latest inxi, do not file a bug report since it's probably been fixed
+ages ago. If your distro isn't packaging a current inxi, then file a bug report
+with them, not here.
+
+Distributions should never feel any advantage comes from using old inxi
+versions because inxi has as a core promise to you, the end user, that it will
+never require new tools to run. New tools may be required for a new feature,
+but that will always be handled internally by inxi, and will not cause any
+operational failures. This is a promise, and I will never as long as I run this
+project violate that core inxi requirement. Old inxi is NOT more stable than
+current inxi, it's just old, and lacking in bug fixes and features. For pre 2.9
+versions, it's also significantly slower, and with fewer features.
+
+inxi is 'rolling release' software, just like Debian Sid, Gentoo, or Arch Linux
+are rolling release GNU/Linux distributions, with no 'release points'.
+
+Your distro not updating inxi ever, then failing to show something that is
+fixed in current inxi is not a bug, and please do not post it here. File the
+issue with your distro, not here. Updating inxi in a package pool will NEVER
+make anything break or fail, period. It has no version based dependencies, just
+software, like Perl 5.xx, lspci, etc. There is never a valid reason to not
+update inxi in a package pool of any distro in the world (with one single known
+exception, the Slackware based Puppy Linux release, which ships without the
+full Perl language. The Debian based one works fine).
+
+Sys Admin type inxi users always get the first level of support. ie, convince
+us you run real systems and networks, and your issue shoots to the top of the
+line. As do any real bugs. Failure to supply requested debugger data will lead
+to a distinct lack of interest on our part to help you with a bug. ie, saying,
+oh, it doesn't work, doesn't cut it, unless it's obvious why.
+
+===============================================================================
INXI VERSION NUMBERING:
-inxi uses 'semantic' version numbering, where the version numbers
-actually mean something.
+inxi uses 'semantic' version numbering, where the version numbers actually mean
+something.
The version number follows these guidelines:
Using example 3.2.28-6
-The first digit(s), "3", is a major version, and almost never changes.
-Only a huge milestone, or if inxi reaches 3.9.xx, when it will simply
-move up to 4.0.0 just to keep it clean, would cause a change.
-
-The second digit(s), "2", means a new real feature has been added.
-Not a tweaked existing feature, an actual new feature, which usually
-also has a new argument option letter attached. The second number goes
-from 0 to 9, and then rolls over the first after 9. It could also be
-adding a very complicated expansion of existing features, like Wayland.
-It depends.
-
-The third, "28", is for everything small, can cover bug fixes, tweaks
-to existing features to add support for something, pretty much anything
-where you want the end user to know that they are not up to date. The
-third goes from 0 to 99, then rolls over the second.
-
-The fourth, "6", is extra information about certain types of inxi
-updates. I don't usually use this last one in master branch, but you
-will see it in branches one,two, inxi-perl, inxi-legacy since that is
-used to confirm remote test system patch version updates.
-
-The fourth number, when used, will be alpha-numeric, a common version
-would be, in say, branch one: 2.2.28-b1-02, in other words, a branch 1
-release, version 2.
-
-In the past, now and then the 4th, or 'patch', number, was used in
-trunk/master branches of inxi, but I've pretty much stopped doing that
-because it's confusing.
-
-inxi does not use the fiction of date based versioning because that
-imparts no useful information to the end user, when you look at say,
-2.2.28, and you last had 2.2.11, you can know with some certainty that
-inxi has no major new features, just fine tunings and bug fixes. And
-if you see one with 2.3.2, you will know that there is a new feature,
-almost, but not always, linked to one or more new line output items.
-Sometimes a fine tuning can be quite significant, sometimes it's a
-one line code fix.
-
-A move to a new full version number, like the rewrite of inxi to Perl,
-would reflect in first version say, 2.9.01, then after a period of
-testing, where most little glitches are fixed, a move to 3.0.0. These
-almost never happen. I do not expect for example version 4.0 to ever
-happen after the 3.0 release of early 2018, unless so many new
-features are added that it actually hits 3.9, then it would roll
-over to 4.
+The first digit(s), "3", is a major version, and almost never changes. Only a
+huge milestone, or if inxi reaches 3.9.xx, when it will simply move up to 4.0.0
+just to keep it clean, would cause a change.
+
+The second digit(s), "2", means a new real feature has been added. Not a
+tweaked existing feature, an actual new feature, which usually also has a new
+argument option letter attached. The second number goes from 0 to 9, and then
+rolls over the first after 9. It could also be adding a very complicated
+expansion of existing features, like Wayland. It depends.
+
+The third, "28", is for everything small, can cover bug fixes, tweaks to
+existing features to add support for something, pretty much anything where you
+want the end user to know that they are not up to date. The third goes from 0
+to 99, then rolls over the second.
+
+The fourth, "6", is extra information about certain types of inxi updates. I
+don't usually use this last one in master branch, but you will see it in
+branches one,two, inxi-perl, inxi-legacy since that is used to confirm remote
+test system patch version updates.
+
+The fourth number, when used, will be alpha-numeric, a common version would be,
+in say, branch one: 2.2.28-b1-02, in other words: branch 1 patch version 2.
+
+In the past, now and then the 4th, or 'patch', number, was used in trunk/master
+branches of inxi, but I've pretty much stopped doing that because it's
+confusing.
+
+inxi does not use the fiction of date based versioning because that imparts no
+useful information to the end user, when you look at say, 2.2.28, and you last
+had 2.2.11, you can know with some certainty that inxi has no major new
+features, just fine tunings and bug fixes. And if you see one with 2.3.2, you
+will know that there is a new feature, almost, but not always, linked to one or
+more new line output items. Sometimes a fine tuning can be quite significant,
+sometimes it's a one line code fix.
+
+A move to a new full version number, like the rewrite of inxi to Perl, would
+reflect in first version say, 2.9.01, then after a period of testing, where
+most little glitches are fixed, a move to 3.0.0. These almost never happen. I
+do not expect for example version 4.0 to ever happen after 3.0 (early 2018),
+unless so many new features are added that it actually hits 3.9, then it would
+roll over to 4.
### EOF ###