It's here! Perl inxi, first official release. So many changes, really too many
to list.
But here's a few:
1. of course, full rewrite to Perl 5.x. Supports as old as 5.008, as new as current.
2. Better line length nandlers. Fully dynamic, robust, shrinks and expands to fit
either taste or viewport.
3. Long options for all options now, plus of course the short options everyone
is used to.
4. New options: --usb; --slots (pci slot report); --sleep (change cpu sleep time);
and many more. Check --help or man page for details.
5. Vastly improved --recommends, now does per distro package recommends, and shows
only Linux data to Linux systems, and BSD data to BSD systems.
6. Hugely improved debugger as well.
7. Far more accurate output, most output is now in key/value pairs, because:
8. inxi now exports to json and xml! See --output/--output-file for info.
9. Enhancedd repo output, added deb822 type, solus
10. Radically enhanced network data, now shows all IP / IF devices connected to
each nic, not just one, both IP v4 and v6.
11. USB audio and network device actual drivers
12. better handling of compiler data.
13. Basic ARM machine data now, if present to inxi
14. Graphics: per card driver info alongside the original xorg drivers.
15. Better integration of partitions, RAID, unmounted partitions, and HDD data.
16. Better sensors handling of free video driver sensor data, well, not better,
it's now there, along with fan speeds for gpus.
17. RAID is enhanced, and now can show > 1 RAID type on a system, and the RAID
is improved.
18. Much improved disk/partition/memory sizing, inxi now always works internally
with KB units, and changes them on output to the appropriate units.
19. Fully redone man page for all the new options and the long options.
And so much more. Anyway, here it is, the first release.
2018-03-19 release. I'm putting the last issue requests on the last forums,
so assuming no real further bugs found, expect Perl inxi 2.9.01 to hit around
Monday or Tuesday. If any bugs are found, of course, those will be fixed before
release of the new Perl inxi.
Basically, if you want to see if you can find bugs, this is the time to do it, not
AFTER release. I've posted on many forums, and have given the various distros a
chance to help squash the bugs their users might see, some have been fantastic
(AntiX, you were the best by far), others, not so much. Their loss in the latter
case since the purpose of beta testing is to find bugs before, not after, release.
If you want to see the differences in recommends, and dependencies, grab pinxi
development branch here:
wget -O pinxi https://github.com/smxi/inxi/raw/inxi-perl/pinxi
or:
git clone https://github.com/smxi/inxi --branch inxi-perl --single-branch
and run: pinxi --recommends
The main thing I'd strongly urge all maintainers to add, for long term stability
and speed and reliability, is dig, which can be used if present to get very fast,
reliable, WAN IP information.
All of the other recommends are pretty much the same, for graphics, xdpyinfo,
xrandr, and glxinfo. For networking, ip or ifconfig, along with dig. For all usb
related identification, lsusb, unfortunately, I wish I could get rid of that tool,
it's very slow, but I can't. The --recommends output shows the complete set.
Obviously, Bash and Gawk are no longer recommends, nor are the tools like grep,
sed, tr, wc, etc, all those are done with Perl, so any shell plus Perl 5.08 or
newer Perl 5.x is all that's really required, beyond normal system reporting
tools like lspci etc.
For json/xml export, two Perl modules are needed, again, see --recommends
Making sure tarball etc is up to date, so it can be stored in 'tarball's branch.
MAINTAINERS:
Pinxi 2.9.00-xxx-p (inxi-perl branch) is nearing completion of its beta test cycle,
and, barring any new issues or bugs (TEST IT NOW AND REPORT ISSUES NOW!), I expect
to release pinxi 2.9.00 as inxi 2.9.01 shortly after I complete the advanced
RAID feature, which should be this week.
If no real issues appear during the following week after the inxi 2.9.0 release, it
will be moved to inxi 3.0.0, as the first stable Perl inxi release.
There will be a new branch, inxi-legacy, that will have the Gawk->Bash inxi 2.3..56
files for historical purposes only. No further work will be done on inxi 2.3 from
now on.
cpu output issues. Now inxi handles > 8 cores in terms of output filters,
descriptions, correctly noting that it's multithreaded.
Because AMD has entered the Multithreading game, I've changed the trade term:
HT - HyperThreading to MT - MultiThreading to support both Intel and AMD variants.
Updated CPU output filters to also account for these very large core counts.
I believe this commit now adds full support for the new Ryzen series, but I'll have
to see when it comes to other variants that may appear. I've tried to future proof
the MT tests, but I won't know of those are fully functional and accurate until
inxi sees the real data.
Because I don't want to break existing cpu logic, I just added in a rizen switch,
which will just use cpu_core_count value, then trigger HT output.
This fix may or may not work, but the issue poster vanished and has not followed up.
For now I'm keeping this a Ryzen specific adjustment, but it may be safe to extend
it further, that is, if siblings > 1 && siblings = 2 * cores then it's HT.
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
easier and more predictable to find. Better section headers, all ordering alpha
by subsections.
Fixed some small debugger gatherer oversights as well.
Note that I made the debugger stuff more portable, so I could use it in another
program.
Note that this is the last choice because it's slow, the order has been revised:
1. curl
2. wget
3. fetch
4. Perl 5 HTTP::Tiny
5. OpenBSD ftp
wget has been downgraded due to the recent 1.19-2 bug with wget -O that did
not get resolved quickly, and which should never have been released since
that's a basic wget action, which means they aren't testing gnu wget the way
they should be.
All inxi downloaders can now use this option. However, in my tests it's signicantly
slower to use HTTP::Tiny than curl or wget, so inxi will test for the downloaders
in that order. While -i uses dig as it's primary IP tool, if dig is not installed,
the IP will follow the same downloader priority. -U and -w/-W use downloaders.
Because HTTP::Tiny is optional, and is merely used if wget/curl/fetch are not
installed, I would not consider Perl to be a real dependency yet, just an option, so
I guess for packager maintainers, Perl should be added as a recommends, or a
dependency if you want to fully support the debugger options (Core Modules).
While I'm still not sure which Perl modules I'm going to be using, I'm sticking
for now to Core Modules, the standard, with some experimental exceptions that
would only be used if the user had them present.
Long term the goal is to get rid of as many dependencies as possible, replacing
them were possible with Perl tools, but this is going to take forever, if it
ever happens, so don't hold your breath.
In the future, I expect more and more components that were gawk to be rewritten
to Perl (Core Modules), slowly, however, very slowly.
Updated --recommends to indicate the downloader options more clearly as well.
Added new options for bypassing curl (-! 41), fetch (-! 42) wget (-! 43), or
curl, fetch, and wget (-! 44) to disable all of them. This is in case one of
those is broken or you want to test Perl downloader, mostly.
Also cleaned up debugger output and made debugger portable to other scripts.
ARM data collection in /sys.
Using 'tree' now instead of ls if it is installed for debugger /sys tree listing.
Added to recommends. Updated bluetooth recommends to note it's dev only. That
should fix issue #127
branches, simplified the options. This corresponds to updates on github where
I'm finally bringing the alternate location self updater back into operational
state after a long dormant period.
Also, and this may be of interest to some maintainers, please note, there is
a new branch: master-plain which does NOT have the gz files inxi.1.gz and
inxi.tar.gz
If you want to avoid the big clones, you can use that branch with this command:
git clone https://github.com/smxi/inxi --branch master-plain --single-branch
And that should only track the basic 3 files: inxi inxi.1 and inxi.changelog
This fixes issue #94
explicitly setting Passive => 1 (true) for some systems and firewall
configurations.
This corrects a failure to upload issue I experienced for a test remote
system that had a different firewall configuration than the dev system has.
nvme disk capacity in full disk capacity listing. Adds nvme name/serial/firmware
revision number. The latter is a new -Dxx output option. Note that as far as I could
tell, so far, nvme is the only disk type that has firmware revision data.
Added support for nvme disk temperature as well, that requires the cli tool nvme.
Updated AMD microarchitecture list to be more granular and complete. Added Intel
microarch type. Note that they are releasing a few new microarchitectures soon but I
was not able to find any model numbers for those.
of the xiin.py tool, which is going to become obsolete when python 3 fully replaces python 2.
Since the odds of perl being around and stable are far higher than the odds of xiin.py
even working on python 3, I'm getting ahead of the race. Plus Perl is nicer to work with.
And Perl is a lot faster. I mean, a lot. Not slightly.
And it also works on much older systems, and does not have that Python version < 2.6
failure due to changing Python syntax even between sub versions. xiin.py never ran on
Python 2.5 even when it was relatively recent, which is one reason I'm removing all Python
from inxi.
Basically xiin.py worked only on Python 2.6 or 2.7, period.
Oh, and also handled issue #115 by not making -B show -M data.
The issue was not so much with xiin.py as with some new values in /sys that would
hang tree traverse, however, in order to remove the python dependency (except for
uploading -xx@ debugger data, until I can figure out how to do it with Perl), I
rewrote the tree traverse tool into Perl, which also makes it a lot faster and
easier to work with.
This issue appeared on kernel 4.11 as far as I can tell, some new values in /sys make
the traverse hang if it tries to read the values, **/parameters/** and **/debug/** seem
to be the main culprits, but inxi doesn't need that data anyway for debugging purposes
so it's just excluded.
in issue #118
The data seems to suggest that using POWER_SUPPLY_VOLTAGE_MIN_DESIGN as the factor will
be right more often than using POWER_SUPPLY_VOLTAGE_NOW.
Also optimized a bit more on the desktop id logic.
the conversion from mA hours to Wh, and had a math glitch too for charge (ma).
Not sure how this went undetected during testing, oh well. I assume that mA h is not
as common internally as Wh or something.
Anyway, it should be fixed.
-o, -p, -l, -u, -P, -S, -G, -N, -A
Now most output should tend to not wrap, though some strings are unpredictable and
will have to be trimmed by adding them to the min size trimmers one by one.
But it's much better than it was.
Note the following changes required to make the wraps more consistent:
-S - the gcc/bits have been made separate, like: bits: 32 gcc: 5.3
-C - the new microarchitecture -x option now is: arch: K7 [for example]
cache wraps to next line with arch. with -f, bmips now shows on same line as
arch/cache
would have caused failure on older systems. Also added Bash version checker.
Most ps aux data is now searched using bash parameter expansion, and several functions
that were in subshells are now printing to globals instead.
as well so you can see which revision of the cpu microarchitecture your cpu has.
Also fixed a few random vm id issues, I found cases where systemd believes it's bochs
but it is actually kvm, so now the systemd data is not fully trusted, but is confirmed.
Will need some updates to bring the family/model ids to fully current, but should show data for most
cpus. Next release will hopefully include latest model/family ids and microarchitecture names.
Note that while /proc/cpuinfo has the family/model id in decimal, the values are actually generally
found as hexadecimal, so inxi translates that interally so we can store the data the way it is presented.
See issue #116 for ongoing additions to this feature.
but Xorg has not started, which means inxi can't get the video driver from Xorg.0.log as with X.
Added in extra data collection from lspci -v to include the driver for graphics card. this is
only used, for now, if the initial Xorg based driver test works.
Note that this may also work for systems that have not yet started X out of X, in console, I'm
not sure about that, but the graphics driver reporting should be improved.
Note that I'm not yet linking the driver to the specific card/device, it's just going to show
in a comma separated list, I couldn't find multi card systems where the card types are different,
like amd gpu with nvidia card, for example.
But this should correct an issue, at least to start, with expanding wayland support for systems
that don't use or have not started the desktop with Xorg/X11 etc.
core profile data being null, which in turn triggered a bash oddity, where if the IFS is
\n for an array, and if the value of one element is '', then bash ignores that and does
not simply set an empty array key as you'd expect. The correction was to change the IFS
to ^, which worked fine for empty array values.
However, since this bug will impact anyone with empty opengl core profile data, I recommend
updating inxi.
Also, added support for two smaller wm, Sawfish and Afterstep.
This is a good source for lists of wm: http://www.xwinman.org/http://www.xwinman.org/others.php
However, that does not show how to ID it, so i have to do it on a case by case, but I'll
add an issue for showing how to get your wm of choice if it's missing to inxi.
long-standing issue where /dev/ram.. data shows in unmounted disks output. This is
now properly filtered out.
Note that the floppy disk output has no information beyond it's /dev id, eg: /dev/fd0
I could find no meaningful data in /sys related to the floppy disk, not the model, etc, so
I'm just showing presence of disk.
wget/fetch/curl. This allows systems with for example out of date certificate stores
to still download without error. Also a legacy system fix where tty size failed to show.
Also cleaned up man page, slightly changed output for compat version to: (compat-v: 3.0)
gfx variable name fixes to make more obvious the logic as well.
Default will get data from display :0, but if you append :[display-number] to -! 40, it will
use that display instead, for example: inxi -! 40:1 would get information from display 1. Note
that most multi-monitor setups use :0 for both monitors, depending on how it's setup.
This will also let users see any desktop information based on xrop -root output, but it will
depend how it works based on how environmental variables have been set. gnome and kde, which use XDG for
primary detection would not work, for example.
used to not work as root in X, but they do now. So I've removed the root tests for graphics
output, and now only rely on the returned data to determine the output when in X. Out of X
behavior remains the same.
Note that at some point I'll have to see if wayland systems have usable reporting tools to get
screen resolution, opengl info, and so on, but that will have to come one step at a time.
-xx option will show OpenGL compatibility version number as well, though that's largely useless
information for most users, thus the -xx. Note that this reverses the default, which previously
showed OpenGL version, which is actually the compatibility version.
This should resolve#105 pull request, though it does it differently, by switching the default
output to what is more relevant, and offering the compatibility version as an optional output item.
Note that much of the glx information will probably change to more neutral terms once wayland support
starts growing, and systems without xwayland etc libraries appear.
Further note that non free drivers showed the OpenGL core profile version numbers all along, so really
this simply corrects misleading output for free drivers.
and compositor support.
This finally implements a first try at mir/wayland detection, along with basic handling of actual
display server type output.
New output for Display Server: Display Server: x11 (X.Org 1.19.0) driver: nvidia
Note that since almost all current Wayland systems will have X.org also installed, for the time
being, the data in the parentheses will be from X.org regardless of what display server is detected running
the actual desktop. Out of the desktop, console, the only thing that will show is x data..
No other data is available to me yet until I get way more debugger data so I can see what information the various
implementations of wayland without x tools actually makes available, my guess is it won't be much.
Also experimental -xx option: -G shows compositor, but only for wayland/mir currently.
I have no idea if this will work at all, but it's worth giving it a try as a rough beginning to
start handling the wide range of wayland compositors being created.
This feature will probably take several versions to get stable.
Also added new debugger data collector data for wayland information, but the pickings are slim, to
put it mildly.
Now there is an -x option for -i that will show the additioanl IPv6 address data for scope global,
temporary, and site. Also a fallback for unhandled scope: unknown. If the tool 'ip' is used, it will
filter out the deprecated temp site/global addresses, ifconfig tool does not appear to offer this
option.
Also changed is that now ipv6 address always shows, it's not an -x option. Probably about time to
start rolling out ip v6 data to users now that ip v6 is starting, slowly, to be used more.
Another small change, the link address for ipv6 is changed from ip-v6: to ip-v6-link so that it's
more clear which IP v6 address it is.
The last commit had a significant logic error in it that did not distinguish between the link address,
which is what should have only shown, and the remaining possible addresses.
I've tried to get a basic bsd support, but it's difficult to know the variants of ifconfig output syntax
Note that this bug is not universal, but I believe this will make inxi more right than wrong
as a general rule. Further note that altitude is NOT actually the altitude of the city/location
requested, in most cases, but rather the altitude of the weather station data assigned to that
location request.
from BIOSTAR. Also fixed a few other sloppy gsub, and fixed a few gensub errors as well.
Since BIOSTAR is a fairly common mobo, I'm surprised I haven't gotten this bug report
before.
This closes issue #102.
While default configs remain in /etc/inxi.conf, the user overrides now use the following order of tests:
1. XDG_CONFIG_HOME / XDG_DATA_HOME for the config and log/debugger data respectively.
2. Since those will often be blank, it then uses a second priority check:
$HOME/.config $HOME/.local/share to place the inxi data directory, which was previously here:
$HOME/.inxi
3. If neither of these cases are present, inxi will default to its legacy user data: $HOME/.inxi as before
In order to make this switch transparent to users, inxi will move the files from .inxi to the respective
.config/ .local/share/inxi directories, and remove the .inxi directory after to cleanup.
Also, since I was fixing some path stuff, I also did issue 77, manual inxi install not putting man pages in
/usr/local/share/man/man1, which had caused an issue with Arch linux inxi installer. Note that I can't help
users who had a manual inxi install with their man page in /usr/share/man/man1 already, because it's too risky
to guess about user or system intentions, this man location correction will only apply if users have never
installed inxi before manually, and have no distro version installed, unlike the config/data directory,
which does update neatly with output letting users know the data was moved.
Note that if users have man --path set up incorrectly, it's possible that the legacy man page would show up
instead, which isn't good, but there was no perfect fix for the man issue so I just picked the easiest way,
ignoring all man pages installed into /usr/share/man/man1 and treating them as final location, otherwise
using if present the /usr/local/share/man/man1 location for new manual install users.
Also, for users with existing man locations and an inxi manually installed, you have to update to inxi current,
then move your man file to /usr/local/share/man/man1, then update man with: mandb command (as root), after that
inxi will update to the new man location.
Also added some more XDG debugger data as well to cover this for future debugger data.
This closes previous issue #77 (man page for manual inxi install does not go into /usr/local/share/man/man1) and
issue 101, which I made today just to force the update.
Just as a side note, I find this absurd attempt at 'simplifying by making more complex and convoluted' re the XDG
and .config and standard nix . file to be sort of tragic, because really, they've just made it all way more complicated,
and since all 3 methods can be present, all the stuff has to be tested for anyway, so this doesn't make matters cleaner
at all, it's just pointless busywork that makes some people happy since now there's even more rules to follow, sigh.
graphics driver, so it would not show in output, which causes support issues for users of that specific
driver, like some cases of Intel. Also inxi would always have failed to show it unloaded in cases where
radeon/nouveau were used but it had been loaded by xorg to begin with. So probably worth updating packages
I'd say.
each disk is on its own line always, this makes it easier to read and/or parse.
Also, the lines now wrap nicely for extra data > console width, or -y 80 for example if
you're trying to force most of the data to fit into 80 columns.
handling, and legacy linux. VM id will remain a work in progress, and will probably
require a few fixes for fringe cases. Nice to have would be things like OpenBSD's
vm which is difficult to detect. However, I believe this should handle roughly 99% of
realworld vm id cases, except for some commercial stuff that will require more data.
Now -M shows device type, like desktop, laptop, notebook, server, blade, vm (and tries to get vm type).
vm detection will take more work, for now I'm just going for the main ones used, but it will certainly
miss some because it's hard to detect them in some cases unless you use root features. Also note, in
most cases a container I believe will display as a vm, which is fine for now.
For BSDs, and older linux, there is a dmidecode fallback detection as well.
Basic support added for Budgie desktop detection. This is waiting more data, so the support will be
missing the version information. Go Budgie!!
Added /var/tmp and /var/log and /opt to basic partition data: -P
This will probably not impact more than a handful of people in the world, but that's fine.
Modified the static BIOS in -M to now show UEFI for actually UEFI booted systems, and, ideally,
UEFI [Legacy] for UEFI booting in bios legacy mode, and BIOS for all others. Hopefully this will
work ok, we'll see.
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
A sloppy unescaped / triggered a failure I didn't notice in partition info.
Please update your inxi packages immediately if your version is 2016-03-21 or newer.
on /etc/issue step to first test for os release and not mint, then lsb verison and
not mint, then /etc/issue. This should keep the mint detection working well, as long
as they keep mint string in the /etc/issue file, that is, but that's out of our control.
test for the non deprecated battery test, /sys/class/power_supply/BAT0 existence.
This resulted in failure to indicate 'portable' where applicable.
I may also now add battery information where applicable since that's easy to get from
/sys
1. Add amdgpu to possible xorg drivers list (and gpu sensors data)
2. switch to default dig command to get WAN ip. This is usually but not always faster than
the http method. Because the IP source is not truly trustworthy (run by cisco), I'm keeping a
fallback mode on 1 second time out failure of the previous http based methods. Added dig
to recommended tools list.
NOTE: missing product name/serial info, because it's not being treated by linux kernel
as a standard disk. Could not find that data anywhere in the system debugger dump.
If you know how to find the model name/number and or serial, let me know.
Also small fix, as noted: ip: should be ip-v4 to match with ip-v6, thanks mikaela.
Also some debugger fixes and updates.
Changes: updated inxi updaters to use github locations.
I will do this commit once for googlecode, and once for github, after that,
all commits will go only to github.
inxi moves to github, despite my dislike of for profit source repos, and git,
I decided that I just don't have the time or energy to do it right, so I'm going
to use github.
The project is already moved, though I have left inxi up for the time being on
code.google.com/p/inxi until I move the wiki to http://smxi.org
Everything is pretty much the same, the project url is:
https://github.com/smxi/inxi
The direct download link for the gz is:
https://github.com/smxi/inxi/raw/master/inxi.tar.gz
git pull is:
git pull https://github.com/smxi/inxi master
svn checkout url:
https://github.com/smxi/inxi
And that's about it.
showing Frameworks version, which is apparently NOT the same as the plasma version.
Also added debugger kde versioning to make this stuff less of an ordeal for data collection.
#kde-devel, now using kf5-config --version which gives similar output to kded4 --version
I use this for both 4 and 5, but since 4 has worked fine for years, I'll just use this for 5
and later.
normal, in this case, sddm decided that using a .pid or .lock file in /run was too easy
so they changed to some session id type string in the /run/sddm/ directory.
Speaking for myself, I find such pointless changes from anything resembling normal behaviors
to the reason that gnu freedesktop systems will never achieve significant desktop use globally.
Also, in the same vein, added debuggers to try to figure out what plasma5/kde 5 is using
internally to give command line version information. Again, something pointless internally
was changed, thus breaking something that had faintly resembled an api, which is of course
why desktop gnu linux will never actually take off, developers in the real world have no
interest in chasing after such pointless and never ending churn in even the most trivial
areas of the OS, let alone the core.
inxi remains however as a log of this ongoing churn and lack of discipline, and so remains
an interesting process of observation, and a way for users to try to avoid the constant
changes in simple system queries that should really never change, so I can see a reason
to keep it going since it's obvious that the actual foss ecosystem itself will not and apparently
cannot grasp that it is the lack of stable apis, methods, etc, that has kept desktop gnu linux
from achieving any actual real world success or popularity, and that is the actual problem
that should be fixed, not some pointless internal change to something.
On the source repo front, maintainers, I still can't find an acceptable alternative to the
impending shutdown of googlecode. github is a for profit venture that people who seem totally
void of any sense of history believe is actually going to be around longer than say, sourceforge,
or googlecode, as a legitimate source hosting site.
I'd welcome any suggestions. So far all the options are bad that I can find.
Top preference is svn, but if git is the absolute only other choice for an otherwise good option,
I'd consider git, but it's a horrible option for inxi because of how inxi development and debugging
works, vs how git works. ie, svn branches are perfect, git branches are totally wrong.
I may end up just hosting the svn on my own servers to avoid having to move yet again when the next
for profit flakey site decides to close up or monetize the source hosting.
The original idea of googlecode was for google to 'pay its dues to the foss community', but apparently
they got bored with that idea, plus of course, the ongoing total failure of google to deal with
automated spam, which has always been a huge bug in the core google corporate culture. But googlecode
was by far the best option I've come across, it was done by a deep pocketed corporation not for profit
for pretty good reasons, and was never intended to be a profit center, which is the closest I could
see for a non free option.
Setting up svn gui stuff however is a royal pain and requires ongoing maintainance for the life of
the software, which is NOT fun, nor will I sign up for that obligation.
I may end up moving to github anyway, even though git truly sucks for inxi and myself, but it's an
idea I find fairly vile, apparently free software (sic) authors seem to have no grasp of the concept
of fredom when it comes to source code hosting, judging by the absurd popularity of github as the
default go to source repo. Their website is pathetic as well, which isn't very promising.
So we'll see where it goes, I think I have until august to decide what to do for source hosting.
Since I'm old enough to have seen sourceforge and now googlecode do the same thing, along with a lot
of other options, to say github won't do this too is delusional, what you can almost certainly say is it
will do it, the only question is when. But, just as Linus did with his non free linux kernel version
control, people will stick with the non free stuff until you realize you can't use it anymore, because
it is non free. Free software hosted on non free source repos is to me one of the most absurd and
stupid things I've ever heard of to be honest.
the switched file name. Kudos to anyone out there fighting to create a working alternative
to the unreliable and buggy and windows emulating systemd, I wish devuan luck. Maybe between
devuan and gentoo and slackware we can save the free software core systems before it's too late.
pet peeve of mine. Now, if -I, -b, -F, or anything that can trigger the memory: used/total
in Information line is not used, -tm will always show the system used/total ram data on the
first line of the Memory item of -t output.
Also, if -xtc (trigger ram data in cpu output) is used, and -I is not triggered, and -tm is
not triggered, will also show system used/total ram data on the cpu first line.
I'd found it odd that this data did not appear when -tcm or -tm or -xtc were used, so this is
now fixed. I used the -t option a fair amount to find memory/cpu use issues, and usually I
don't use the option with other options, so the lack of total system ram data was odd.
long term solution to identify itself, so the hack I had in place fails on new MATE.
We'll see if this does it for various glitches, now quassel and mate latest should
again be working.
fine for all derived distros like Sabayon as well. The test looks for:
/etc/portage/repos.conf/ and type -p emerge
if found will then grab the repos from the source files found.
Note that the logic for this was almost identical to that used for rpm so it was an
easy addon. Please let us know if you have an issue and provide data samples of relevant
files.
1. Tightened runit init detection to use proc, note that if runit works on BSDs inxi will
require more data to properly detect it on BSDs..
2. Use openrc runlevel tests natively if openrc detected.
3. Fixed subtle issue with alias to inxi file and paths.
4. Added rc-status data collection for debugger, improved debugger data collector handling
of bsd and other tests to note absent if not there in file names.
Fixed bugs in Epoch init system detection, caused false positives in systems booted on
SysVinit, but with Epoch installed. Epoch turns out to be in PID 1 == epoch (/proc/1/comm)
so that's easy to fix.
Also fixed spacing isxue with OpenRC output in -I line.
at least on the system I got data from, is not using .pid/.lock extensions, but other systems
are, I'm adding sddm AND sddm.pid detection. This required changing the id to use explicit -f
for test, not the previous -e, which will force only files, not directories, to trigger yes case.
No other changes, but it's worth updating to this because distros may start using sddm in the not so
distant future, it's beta currently though.
as of yet unknown reasons, so rather than wait to see the bug resolved, I'm just removing
uptime as a depenendency, though this is a short term hack only because we don't know
why it was removed from procps or if that was just a mistake, or if other things as well might
be vanishing from procps. Am leaving in however uname as dependency because inxi cannot
determine what platform it is when it starts without that.
output for apt repos. Also refactored duplicated code into a function, no other changes.
Note that this version features the repo debugger tool as well, which is very helpful in
particularly non apt systems to fix issues with its handling of repo formats etc.
fixes a single scenario with apt, where there is only sources.list, no .d/*.list files.
I was assuming that the file name would print out in the output of single file grep,
but that only happens with multiple files.
bsds: removed dragonly specific used mem hack, now will work for any bsd, if avm in vmstat is 0
adds a flag to value, and removes it when used.
Nothing else of note.
Added support, basic, for bsd hard disks, and optical disks.
Added hard disk total/percent used for BSDs, sort of.
These are mostly just hacks since the data isn't easily available from system
standard tools, though I could on freebsd use gpart I guess but that's another tool
needed, and another method, too much work imo for small results.
Now the short form, the -b/-v1 form, and the -C forms are all similar.
Also, added a few hacks to try to extract cpu max speed from cpu model string in
either sysctl -a OR /var/run/dmesg.boot data in freebsd/openbsd. Sometimes it may
work if that data was in the model string. It's a hack, but will do until we get
better data sources or they update their sources to list more data.
handling. Or rather, non handling, since that data only showed in rare cases on short form
(inxi no args) output. Now it uses /sys query to determine min/max speed of cpu, and uses
that data to override any other min/max data discovered.
Still uses /proc/cpuinfo for actual speeds per core. The assumption in this is that all
cares will have the same min/max speeds, which is generally going to be a safe assumption.
Now in short form, inxi, output, it will show actual speed then (max speed) or just (max)
if actual speed matches max speed. Same for -b short CPU output.
For long, -C output, shows max speed before the actual cpu core speeds per core.
With -xx, and in multi cpu/core systems only, shows if available min/max speeds.
Note that not all /sys have this data, so it doesn't show any N/A if it's missing.
permit wget/curl/(openbsd ftp)/(bsd fetch) interchangeably.
This lets more standard downloader defaults in bsds, as well as curl on gnu/linux systems
without triggering an error of missing wget.
1. Fixed cpu core issues on bsds, now shows core count + if > 1, cpus total.
2. Now shows OS instead of Distro on short/long output, since each bsd is an OS.
3. fixed vmstat issues for used memory outputs
Also fixed potential failures with cpu core count array by making it a ',' separated array.
-m/-M would always show requires root for dmidecode no matter what. Also improved dmidecode
error messages/handling.
Also, a fix for no display card data, now shows as expected no card data
Most other fixes are for bsd, mostly openbsd.
1. Added a class for network devices in freebsd pciconf
2. Added -r support for openbsd
3. Fixed some cpu issues for openbsd
4. Fixed an issue in openbsd/freebsd where client version data failed to get cleaned
5. Changed inxi short form output for bsds to show OS data instead of kernel data.
6. BSDs, maybe all, different syntax in xorg.0.log made unloaded gfx drivers not show,
that is fixed now.
-p fixed file system type in -p/-P for openbsd, now shows.
-I / inxi short - fixed used memory, did not show in openbsd, now does.
-f fixed cpu flags in openbsd, now works
-C corrected corrupted cpu data outputs, in openbsd at least, maybe also freebsd
-C added an openbsd hack to sometimes show cpu L2 cache
-m/-M fixed/improved dmidecode error handling for all systems
Modified handling of dmesg.boot data, synched so gawk can parse better.
Now all lines are stripped of ending whitespaces automatically.
Also a dmidecode error handler correction, that was not working right in bsd systems.
Added some debuggers for bsd systems.
output, like so, instead of the old quotes "XFCE4" it shows like this:
XFCE_DESKTOP_WINDOW(WINDOW): window id # 0x1000003
Updated and added a much less strict fallback test case.
I have collected enough datasamples to allow for reasonably fine grained corrections, estimates,
warnings about unreliable capacity now, and have fixed all major failures.
Also, because this stuff is filled out by people somewhere, or not, some fields often are just
empty, or contain the default values, ie, they are worthless. inxi shows N/A for those situations,
it means there is really no actual data to show you.
This feature, sadly, well never be totally reliable, because dmi data is frankly junk, especially
dmi type 5 and 16, which is what is supposed to tell you total capacity of memory array, and the
maximum module size (type 5). However, this data is totally random, often it is right, sometimes
it is wrong. Sometimes type 5 is right and type 16 is wrong, sometimes the other way. And since
type 5 is only present in some systems, it's not reliable anyway.
What is reliable and always right is the actually installed memory per device, ie, sticks. I have
not seen any errors in that, so that seems to be actually coming from the system itself. type 5 / 16
sadly are clearly entered in manually by some poorly paid engineers out there in the world, and are
often total fictions, either far too small, or far too big, or whatever.
inxi will attempt to correct all clear logic errors, and whenever it changes the listed data from
type 5/16, it notes either (est) or (check). (est) means it is a good guess, one I am comfortable making,
(check) means it is either an unreliable guess, or that what the system is reporting is so unlikely that
even though inxi is showing it, it doubts it could actually be true, or at least, it thinks you
should check this yourself.
-m has 3 extra data options, -x prints the part number, if found, and the max module size, if type 5
is present. inxi does NOT attempt to guess at max module size based on what is installed, it only will
correct a listed max module size if installed modules are > than listed max size. Usually part numbers,
if present, are all you need to order a new stick.
-xx shows serial number, manufacturer (often empty, or just random alphanumeric identifiers, but sometimes
they list the actual company name, which is helpful. It also shows, if type 5 data is present, single/double
bank.
-xxx as usual shows largely useless data that may be of interest to soemone, like if ram type is synchronous,
memory bus width data, and module voltage (type 5 data).
This feature will never be reliable I am sad to say because the source data itself is random and much
has been filled out, or not filled out, by engineering drones somewhere out there in the underpaid
world. The ranges of errors are so wide that inxi just has to check what is possible, reasonable, unlikely,
etc, to generate its numbers. In other words, this is NOT just parsing dmidecode output, that is the raw
material only, sad to say.
So this is it, for better or worse. All bug / issue reports with this MUST come with a full:
inxi -xx@14
hardware data upload, run as root.
Also, much to my annoyance, this feature requires root, since /dev/mem needs root to be read, and I assume
the dmi table, so that is a departure from normal inxi standards, as is the low quality input, and thus,
output, data, though I can guarantee that what inxi tells you is in most cases on average more accurate than
what dmidecode tells you, since dmidecode simply prints out what it finds in the dmi table, and nothing else,
in whatever order it finds it, from what I can see, ie, you also cannot trust the order of dmidecode output.
I had been hoping that /sys would start to contain memory data like it does mobo/system data, but it never
happened so I finally decided to just do the ram thing, require dmidecode, require root/sudo, and that's
that.
There will be issue reports, you can help them by looking up the mobo stats/specs yourself and listing them
in the issue, so I don't have to do it. I use the tool at crucial.com which is very accurate and also very
complete in terms of all possible hardware out there.
I would trust that tool before trusting the companies that have the least reliable data, like ASUS.
Much thanks to everyone who is contributing datasets, and the distros, particularly siduction, that really
were very helpful in this process, by finding more and more failure cases that helped me start to tighten
the logic, and make it more and more robust. Special thanks to Mikaela, of #smxi irc.oftc.net, who came up
with two systems that both required a full redo of the logic, and thus who helped a lot in this process.
size, derived mod size 2gb, listed cap 8, but 2 slots, ie, 2gb x 2 == 4. Made this
retain the listed size, but adds (check) to it because either max mod size is wrong
or cap is wrong.
types, in at least one case, it is last, so can't use that as trigger to start loop.
Now using: Table at .. which is always at start of dmi output.
Also, changed size output per module to be in MB GB TB instead of all mB, since modules
are sold by GB or MB, the data should show that as well. Also shortens output.
type 17 in front of type 16), now each array is created as a multidimenstional, 2x array,
and each device is a 3 dimensional array. This seems to clean up the problems with bad
ordering of dmidecode data.
at least making good guesses when the data is bad for ram, and hopefully will not break
too many cases where it was actually right but seemed wrong.
Unfortunately, dmidecode data simply cannot be relied on, and is FAR inferior to the type
of data inxi tries in general to present users, ie, taken directly from the system, and,
ideally, more accurate than most other tools. But in this case, there is just no way to get
the data truly accurate no matter how many hacks I add.
But if you have bad data, then submit: inxi -xx@ 14 so I can take a look at the system,
and see if I can modify the hacks to improve that data.
it is too big, and sometimes too small. Changed data gathering to use arrays, then print/process
the arrays once they are assembled.
Now it will get rid of any max module size if it's greater than the calculated capacity, and it
will generate an estimated capacity/max module size if they are clearly wrong because actual
module sizes are greater than listed max size, or capacity is less than greatest module sizes times
number of devices.
Not perfect, but it never is, this covers more cases now correctly than before.
maximum supported module size, and module voltage. Most systems do not have this data,
but some do. It's Type 5 item in dmidecode.
Getting the type 6 data however is too hard, and even using type 5 assumes that the
system only has one physical memory array, but that's fine given how few systems
probably will have this information in the first place.
features. Changed output syntax to be more consistent, now each main array line starts with:
Array-X capacity: (where X is an integer, counting from 1)
and each device line starts with:
Device-X: (where X is an integer incremented by 1 for each device, and starting at 1
for each array. I have no data sets that contain > 1 physical memory array, if one appears,
I may need to patch the output to link the array handles with the device handles explicitly.
Made memory bus width output more clear, and added in a hack to correct dmidecode output errors,
sometimes total width > data width, and sometimes data width is > total width, so using always
greatest value for total if not equal to other width.
I think this will be close to it barring any user feedback or bugs, if nothing comes to
mind within a few days, I'll move the number to the new major version, 2.2.0
items and am now just generating one: Locator item, usually from Slot/DIMM locator info,
but sometimes from Bank Locator info when it is more reliable based on my data samples.
Updated help menu, updated man page, now shows working -x -xx -xxx extra data. This may
change slightly over time.
Also removed speed output when No Module Installed is returned for device size. This
also wills switch off width if both total/data are empty.
This is much closer now to live 2.2.0, but I'll leave a few more tests before putting
it at 2.2.0.
working, but help/man does not have that yet, until I finalize the order.
Fixed dmidecode issues, showing extra data types for -m, added line length handling
so -m is properly integrated with rest of inxi re max line lengths.
support. This feature requires dmidecode, and usually that needs to be run as root.
Significantly improved dmidecode error handling and output, and have as 2.1.90 testing/initial
release basic ram data.
In subsequent releases, extra info for -x and -xx and -xxx will be added as well to the output.
For those who want to jump on board early for ram data, update your repos, for those who want to
wait for the full featured version, with -x type data, wait for 2.2.0
And that's that.
have the odd feature in our test data of having > 1 IF id, like ib0 ib1 per pcibusid.
Added support for virtual nics as well. This required refactoring the networking functions
significantly, so hopefully nothing breaks for existing systems. It should in theory be more
robust now than it was before, with more accurate output, particularly with multiple port
devices, like two port nics etc.
that this method will be super long lived, I expect LXDE to change how it shows itself
to the system when the gtk variant goes away. Good for lxde by the way in dumping gtk.
added in an abstracted kernel_compiler method, not just gcc, that may work on freebsd,
and in the future, it may also work if distros or kernel people start using either
clang or LLVM-GCC or LLVM for compiling linux kernels. I'd need some data sets to
show that however before adding that full linux kernel support, but the framework
is now there.
That continues the abstraction of certain features, like kernel compiler, init system,
display server. Display server still needs full data sets from mir/wayland, at least
wayland, and the bsd display servers as well, I have no idea how to get that data
at this point, but the starting framework is present anyway for that time I get
those datasets.
Almost all these changes are for darwin osx, and that is about all I will do for that
junky broken platform, they have no tools, they have no discipline when it comes to
following unix like conventions, they even use spaces in program names, like windows.
Given it has no native lspci or pciconf tool that I am aware of, or dmesg.boot,
there's little point in putting more time into it. dmidecode does not run on darwin,
so there's nothing to learn there either, you can get a silly 3rd party program to
generate a dmidecode.bin data file that dmidecode can then read, but since that
requires not one, but two third party programs be installed, that's not going to
happen.
Next time an osx user calls this system 'unix' I will laugh.
experiment, just to get it running, so you can all ignore this release.
Added in darwin cpu, init, distro version support, and updated inxi to support
darwin/osx without exiting.
No linux changes.
used percentage, there are too many possible remote file systems to safely exclude, so
sticking with using the test that partition is /dev mounted.
Howeve, did add excludes of nfs/smbfs types, as well as future bsd excludes of those.
particularly with fringe or broken sensors outputs. See inxi issue 58 for details.
http://code.google.com/p/inxi/issues/detail?id=58
Added temp3, and an override to capture cases where temp3 is the actual cpu temp.
Added PECI overrides for cases like msi/asus mobos have defective CPUTIN return data.
Added core0 overrides as well, for cases where the temp returned is too low.
It is absolutely 100% guaranteed that these changes will break some outputs that were
working, but it's also certain that I believe that more wrong outputs will be corrected.
With sensors, really the only way you can get reliable sensors is to use the lm-sensors
config files for your motherboard, then set: CPU: temp and MB: temp explicitly.
inxi will always use CPU: or MB: to override anything found.
It turns out I'd neglected to include /dev/disk partitions, oops, in the df data.
Since this is a long time bug, it warrants a new release even though I just did
2.1.22.
disk used percentage as well. Since swap space is not available as disk space, it
makes sense to me to count it as used. -P/-p show the percent of swap used as well.
to identify a partition, but rather the basic /dev/sdc for example.
This made -D show wrong disk used percentage.
Also, I added --total for df that have that supported, there is however an oddity which you
can see here:
df --total -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs \
--exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
--exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
awk 'BEGIN {total=0} !/total/ {total = total + $4 }END {print total}'
result:
614562236
df --total -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs \
--exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
--exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
awk 'BEGIN {total=0} /^total/ {total = total + $4 }END {print total}'
result:
614562228
df -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs \
--exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs --exclude-type=procfs \
--exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs --exclude-type=unionfs | \
awk 'BEGIN {total=0} {total = total + $4 }END {print total}'
result:
614562236
In my tests, using --total gives a greater disk user percentage than adding the results
up manually, as inxi did before, and still does for systems without --total for df.
df --total -P -T --exclude-type=aufs --exclude-type=devfs --exclude-type=devtmpfs \
--exclude-type=fdescfs --exclude-type=iso9660 --exclude-type=linprocfs \
--exclude-type=procfs --exclude-type=squashfs --exclude-type=sysfs --exclude-type=tmpfs \
--exclude-type=unionfs
Filesystem Type 1024-blocks Used Available Capacity Mounted on
/dev/disk/by-label/root-data ext3 12479556 12015624 335816 98% /
/dev/sdc9 ext3 20410156 18013360 1979432 91% /home
/dev/sdc7 ext3 4904448 3785460 1016672 79% /media/sdb2
/dev/sdc5 ext3 30382896 27467220 2295720 93% /var/www/m
/dev/sdc8 ext3 61294356 41849300 18196972 70% /home/me/1
/dev/sdb1 ext3 307532728 285159432 20810456 94% /home/me/2
/dev/sdd1 ext3 26789720 18153076 7542620 71% /home/me/3
/dev/sdd2 ext3 213310776 206932912 2040960 100% /home/me/4
/dev/sda7 ext3 10138204 1185772 8434348 13% /home/me/5
total - 687242840 614562156 62652996 91% -
Strange, no? the data is in blocks, and it should of course in theory add up to exactly the
same thing. However, because --total lets df do the math, I'm going to use that for now,
unless someone can show it's not good.
inxi still falls back for bsds and older df to the standard method.
of disk drive lists. Was showing USB ID-1: /dev/sde now shows: ID-1: USB /dev/sde
that is more intuitive and keeps the columns in alignment more or less, easier
to read.
Second, fixes a bug with some file systems / usb drives
where they do not use usb- in the /dev/disk/by-id line but only wwn-
https://access.redhat.com/site/documentation/en
-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html
explains it somewhat.
the fix is adding a second if null test of the device /dev/sdx in by-path, that seems
to fix the issue. by-path does have the usb- item, though it does not have the name
so it's not as reliable in absolute terms, but it's fine as a second step fallback
option.
for the next major feature, -m / memory, so there is no particular reason to package
this release. There is a new development option, -! 33, which lets me override /sys
data use for -M, which is useful to debug dmidecode output for -m and other features.
No new version, new man. There may be a few more of these releases, but functionally
there is no particular reason to make a new package if you are a maintainer, so there
is no new version number. This release is a preparation for some branches/one/inxi
tests that will be run in the future.
The man/help document -! 33 just to have it there, but it should make no difference
to anyone but me at this stage.
