mirror of
https://github.com/smxi/inxi.git
synced 2024-11-16 08:11:39 +00:00
readme file edits
This commit is contained in:
Harald Hope
parent
4af90c3406
commit
e2a7dc73b7
83
README.txt
83
README.txt
|
|
@ -8,19 +8,22 @@ MASTER GIT BRANCH:
|
|||
|
||||
This is the only supported branch, and the current latest commit is
|
||||
the only supported 'release'. There are no, and never will be,
|
||||
and 'releases' of inxi beyond the current commit to master.
|
||||
any 'releases' of inxi beyond the current commit to master.
|
||||
|
||||
git clone https://github.com/smxi/inxi --branch master --single-branch
|
||||
|
||||
OR direct fast and easy install:
|
||||
wget -Nc https://github.com/smxi/inxi/raw/master/inxi
|
||||
|
||||
OR easy to remember shortcut (which redirects to github):
|
||||
wget -Nc https://smxi.org/inxi
|
||||
|
||||
NOTE: I have deleted the master-plain branch to avoid confusion
|
||||
since I've removed the legacy .gz files from the branch, which were
|
||||
only reasons for its existence.
|
||||
|
||||
I auto tag commits I that I feel are somewhat complete at that stage
|
||||
of the coding. There ar NO releases, don't even dream of pretending
|
||||
of the coding. There are NO releases, don't even dream of pretending
|
||||
a tagged release holds any significance at all. I only added auto
|
||||
tagging to get the maintainers to stop annoying me about tagging.
|
||||
There is NO repeat NO meaning to the fact a commit is tagged. A tag
|
||||
|
|
@ -40,26 +43,32 @@ any further.
|
|||
|
||||
=====================================================================
|
||||
DEVELOPMENT BRANCH:
|
||||
All active development is now done on the inxi-perl branch:
|
||||
All active development is now done on the inxi-perl branch (pinxi):
|
||||
|
||||
git clone https://github.com/smxi/inxi --branch inxi-perl --single-branch
|
||||
|
||||
OR direct fast and easy install:
|
||||
wget -Nc https://github.com/smxi/inxi/raw/inxi-perl/pinxi
|
||||
|
||||
Once new features have been debugged and are stable, they will move
|
||||
to the master branch.
|
||||
OR easy to remember shortcut (which redirects to github):
|
||||
wget -Nc https://smxi.org/pinxi
|
||||
|
||||
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:
|
||||
you can find it here, at the inxi-legacy branch (binxi):
|
||||
|
||||
git clone https://github.com/smxi/inxi --branch inxi-legacy --single-branch
|
||||
|
||||
OR direct fast and easy install:
|
||||
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 I will
|
||||
spend any time on it in the future, but it is there in case it's of
|
||||
use or interest to anyone.
|
||||
|
|
@ -70,7 +79,7 @@ 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 refuses to
|
||||
update its inxi version, some are terrible about that.
|
||||
update its inxi version, some are bad about that.
|
||||
|
||||
DOCUMENTATION: http://smxi.org/docs/inxi.htm
|
||||
(smxi.org/docs/ is easier to remember, and is one click away from inxi.htm)
|
||||
|
|
@ -100,7 +109,7 @@ for development and debugging on many user systems.
|
|||
PULL REQUESTS: Please talk to me before starting to work on any patch, unless
|
||||
it's a trivial bug fix. Please: NEVER even think about looking at or using previous
|
||||
inxi commits, previous to the current one, as a base for a patch. If you do,
|
||||
your patch / pull request will be rejected.
|
||||
your patch / pull request will probably be rejected.
|
||||
|
||||
inxi has one and only one release, and that is the current one (plus dev releases,
|
||||
of course, but those should never be packaged). All previous releases are
|
||||
|
|
@ -132,8 +141,9 @@ 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, then make sure to turn off the
|
||||
script colors with the -c 0 flag. Script colors in shell are characters.
|
||||
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,
|
||||
|
|
@ -152,7 +162,7 @@ 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.
|
||||
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 3.0.0 Gawk/Bash inxi will also run
|
||||
|
|
@ -170,22 +180,31 @@ 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 from the issue poster.
|
||||
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.
|
||||
|
||||
2. direct ssh access to at least a comparable live BSD version, that is, if
|
||||
the issue is on a laptop, access has to be granted to the laptop, or a similar
|
||||
one.
|
||||
|
||||
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 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, and in the end, I realized, the
|
||||
only BSDs that are well supported are ones that I have had direct access to for
|
||||
bebugging and testing.
|
||||
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 bebugging 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. inxi sets initial internal
|
||||
flags to identify that it is a BSD system vs a GNU/Linux system, after that
|
||||
it tests for specific applications and resources.
|
||||
and extend BSD support, or add new BSD features, 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.
|
||||
|
||||
inxi will also start on Darwin, OSX's mutated version of a BSD, but my
|
||||
conclusion about Darwin is that it is Unix in name only, and I will not spend
|
||||
|
|
@ -217,9 +236,11 @@ 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 operate. New tools may be required for a new
|
||||
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
|
||||
|
|
@ -232,8 +253,10 @@ 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 gawk, sed, etc. There is never a valid
|
||||
reason to not update inxi in a package pool of any distro in the world.
|
||||
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
|
||||
|
|
@ -249,11 +272,11 @@ inxi uses fairly classic version numbering, where the version numbers actually
|
|||
mean something.
|
||||
|
||||
The version number follows these guidelines:
|
||||
Using example 2.2.28-6
|
||||
Using example 3.2.28-6
|
||||
|
||||
The first digit(s), "2", is a major version, and almost never changes. Only
|
||||
a huge milestone, or if inxi reaches 2.9.xx, when it will simply move up to
|
||||
3.0.0 just to keep it clean, would cause a change.
|
||||
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
|
||||
|
|
@ -268,8 +291,8 @@ 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
|
||||
frequently in branch one,two, etc development since that is used to confirm
|
||||
remote test system updates.
|
||||
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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue