mirror of
https://github.com/smxi/inxi.git
synced 2024-11-16 08:11:39 +00:00
changelog edits/cleanups
This commit is contained in:
Harald Hope
parent
84d3c866ae
commit
452a19eb41
|
|
@ -18,7 +18,7 @@ KNOWN ISSUES BUT CAN'T OR WON'T BE FIXED:
|
|||
rpm based systems. We were seeing delays of up to 30+ seconds just to list the
|
||||
rpm package count, which is absurd, even after the rpm optimizations inxi
|
||||
already runs. To allow rpm users to get excluded by default for rpm package list
|
||||
counts, added --pkg flag plus a short message telling them to use that flag to
|
||||
counts, added --pkg flag plus a short message telling them to use that flag to
|
||||
get the installed package count if they want it.
|
||||
|
||||
Changes like this are very unfortunate, but in 2021 for a package manager at
|
||||
|
|
@ -124,7 +124,7 @@ BSD parsers run, the regex are pulled apart and made more granular so a small
|
|||
syntax change ideally won't break the detections as easily.
|
||||
|
||||
2. Cleaned up sub cpu_arch() and made all the arch values line up nicely, over
|
||||
time I notice that almost invariably stuff done to save lines of code makes
|
||||
time I notice that almost invariably stuff done to save lines of code makes
|
||||
code harder to read as the feature expands, so it's generally worth just
|
||||
unravelling it so it all stacks and is easy to scan/read. Also removed extra
|
||||
white space in parens, which is something I'm leaning more towards but it's not
|
||||
|
|
@ -133,7 +133,7 @@ worth fixing all at once so it's just done where it's noticed.
|
|||
That's using:
|
||||
if ( /test/ ){
|
||||
rather than:
|
||||
if (/test){
|
||||
if (/test/){
|
||||
|
||||
I believe using more white space helped with Perl comprehension in the
|
||||
intermediate stages, but is not required anymore and just looks like extra
|
||||
|
|
@ -185,7 +185,7 @@ since softraid is the primary device, I opted to call Crypto and RAID types all
|
|||
RAID, same as with linear zfs.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
KNOWN ISSUES BUT CAN'T OR WON'T BE FIXED:
|
||||
KNOWN ISSUES BUT CAN'T OR WON'T BE FIXED:
|
||||
|
||||
1. FreeBSD: USB drivers. I really gave this a try, but could not get any logic
|
||||
to be stable across systems and varying syntaxes used. Will wait for FreeBSD to
|
||||
|
|
@ -473,7 +473,7 @@ This basically means the -B and -s features are largely feature complete for the
|
|||
BSDs as far as practical, though due to difficulties in getting the data in a
|
||||
consistent clear way, some more advanced features, like gpu temps, which are now
|
||||
available in Linux kernel values and lm-sensors, do not yet appear to be present
|
||||
in the BSDs, though if this changes, the structures are in place to make
|
||||
in the BSDs, though if this changes, the structures are in place to make
|
||||
updates to these logics very easy to implement now.
|
||||
|
||||
Note that the --sensors-include and --sensors-exclude items, or config items,
|
||||
|
|
@ -621,12 +621,11 @@ content.
|
|||
--------------------------------------------------------------------------------
|
||||
CODE CHANGES:
|
||||
|
||||
1. Complete rewrite of BSD disk/partition data tools, now there is one core
|
||||
tool that generates a mega-disk/partition hash, which is then used for all
|
||||
features that need partition/disk data. This worked out super well, and allowed
|
||||
new features like BSD Unmounted disk data to be generated for the first time
|
||||
ever, along with filling in various block device fields that were missing
|
||||
before.
|
||||
1. Complete rewrite of BSD disk/partition data tools, now there is one core tool
|
||||
that generates a mega-disk/partition hash, which is then used for all features
|
||||
that need partition/disk data. This worked out super well, and allowed new
|
||||
features like BSD Unmounted disk data to be generated for the first time ever,
|
||||
along with filling in various block device fields that were missing before.
|
||||
|
||||
2. Change 1 also went along with a refactor of dmesg data tool for BSDs, which
|
||||
allowed for much more granular data generation, along with a complex %dboot hash
|
||||
|
|
@ -684,7 +683,7 @@ more robust and to rely less on very fragile regex parsing patterns, takes more
|
|||
lines of code, but better than having the detections break every other BSD
|
||||
release. This was part of the %device and %usb refactors as well.
|
||||
|
||||
11. Fixed system_files() too, which was really silly logic, it used a global
|
||||
11. Fixed system_files() too, which was really silly logic, it used a global
|
||||
packed hash of system files, then would do a function call for the paths when
|
||||
required, which was redundant since the values were already in a hash which
|
||||
could be used directly. This was a throwback to inxi gawk/bash, where hashes
|
||||
|
|
@ -1173,10 +1172,10 @@ they should probably all become package/classes, with set/get I think.
|
|||
|
||||
10. Optimized reader() and grabber() and set_ps_aux_data(), all switched from
|
||||
using grep/map to using for loops, that means inxi doesn't have to go through
|
||||
each array 2x anymore, actually 4x in the case of set_ps_aux_data(). This saved
|
||||
each array 2x anymore, actually 4x in the case of set_ps_aux_data(). This saved
|
||||
a visible amount of execution time, I noticed this lag when running pinxi
|
||||
through NYTProf optimizer, there was a quite visible time difference between
|
||||
grabber/reader and the subshell time, these optimizations almost removed that
|
||||
grabber/reader and the subshell time, these optimizations almost removed that
|
||||
difference, meaning only the subshell now really takes any time to run.
|
||||
|
||||
Optimized url_cleaner and data_cleaner in RepoData, those now just work directy
|
||||
|
|
@ -1242,7 +1241,7 @@ drifting out. Note that if inxi is using drivetemp values, drive temps will
|
|||
appear as regular user with -Dx, and will be to 1 decimal place. hddtemp temps
|
||||
are integers, and requires sudo to display the temps.
|
||||
|
||||
4. To handle issue #239 which I'd thought of trying off and on, but never did,
|
||||
4. To handle issue #239 which I'd thought of trying off and on, but never did,
|
||||
added option to -Dxxx to show SSD if a positive SSD ID was made to rotation: So
|
||||
rotation will show either nothing, if no rotation or ssd data is detected, the
|
||||
disk speed in rpm, or SSD if an SSD device. There may be corner cases where this
|
||||
|
|
@ -1701,7 +1700,7 @@ RAID running.
|
|||
Sample: inxi -D
|
||||
Drives: Local Storage: total: raw: 340.19 GiB usable: 276.38 GiB
|
||||
lvm-free: 84.61 GiB used: 8.49 GiB (3.1%)
|
||||
|
||||
|
||||
lvm-free is non assigned volume group size, that is, size not assigned to a
|
||||
logical volume in the volume group, but available in the volume group. raw: is
|
||||
the total of all detected block devices, usable is how much of that can be used
|
||||
|
|
@ -1709,7 +1708,7 @@ in file systems, that is, raid is > 1 devices, but those devices are not
|
|||
available for storage, only the total of the raid volume is. Note that if you
|
||||
are not using LVM, you will never see lvm-free:.
|
||||
|
||||
7. An anonymous user sent a dataset that contained a reasonable alternate
|
||||
7. An anonymous user sent a dataset that contained a reasonable alternate
|
||||
syntax for sensors output, that made inxi fail to get the sensors data. That was
|
||||
prepending 'T' to temp items, and 'F' to fan items, which made enough sense
|
||||
though I'd never seen it before, so inxi now supports that alternate sensors
|
||||
|
|
@ -1861,7 +1860,7 @@ something is always a big improvement!! LVM reports require root/sudo. This
|
|||
will, finally, close issue #135.
|
||||
|
||||
3. Going along with -L, and serving as a model for the logic of -L, was the
|
||||
complete refactor of -R, RAID, which was a real mess internally, definitely one
|
||||
complete refactor of -R, RAID, which was a real mess internally, definitely one
|
||||
of the messiest and hardest to work with features of inxi before the refactor.
|
||||
It's now completely cleaned up and modularized, and is easy to add raid types,
|
||||
which was not possible before, now it cleanly supports zfs, mdraid, and lvm
|
||||
|
|
@ -1925,7 +1924,7 @@ anonymous array and hash refernce assignments, which again removes redundant
|
|||
array/hash creation, copy, and assignment.
|
||||
|
||||
5. Also added explicit -> dereferencing arrows to make the code more clear and
|
||||
readable, and to make it easier for perl to know what is happening. The lack of
|
||||
readable, and to make it easier for perl to know what is happening. The lack of
|
||||
consistency actually created confusion, I was not aware of what certain code was
|
||||
doing, and didn't realize it was doing the same thing as other code because of
|
||||
using different methods and syntaxes for referencing array/hash components. I
|
||||
|
|
@ -2167,7 +2166,7 @@ BUGS:
|
|||
1. There was a glitch in the pattern that made -D samsung / seagate not ID
|
||||
right, fixed.
|
||||
|
||||
2. I do not like calling this a bug, because it's not an inxi bug, it's an
|
||||
2. I do not like calling this a bug, because it's not an inxi bug, it's an
|
||||
upstream regression in the syntax used in /proc/version, they changed a fully
|
||||
predictable gcc version .... to a random series of embedded/nested parentheses
|
||||
and other random junk. inxi tries to deal with this regression, which will be
|
||||
|
|
@ -2228,7 +2227,7 @@ blank, only inxi short, which I rarely use so I didn't notice.
|
|||
|
||||
2. Failed to test pacman-g2 for packages, had wrong query argument, so it
|
||||
failed. Also failed to test for null data, so showed errors for packages as
|
||||
well. Both fixed.
|
||||
well. Both fixed.
|
||||
|
||||
3. A big bug, subtle, and also at the same time, an enhancement, it turns out
|
||||
NVME drives do NOT follow the age old /proc/partitions logic where if the minor
|
||||
|
|
@ -2266,7 +2265,7 @@ Both accept comma separated list of sensors, 1 or more, no spaces.
|
|||
|
||||
The refactor however is more far reaching, now inxi stores and structures data
|
||||
not as a long line of sensors and data without differentiation, but by sensor
|
||||
array/chip ID, which is how the exclude and use features can work, and how
|
||||
array/chip ID, which is how the exclude and use features can work, and how
|
||||
granular default hardware sensor exclusions and uses can happen. This is now
|
||||
working in the gpu sensors, and will in the future be extended to the newer
|
||||
5.7/5.8 kernel disk temperature sensors values, which will lead in some cases to
|
||||
|
|
@ -2531,7 +2530,7 @@ Another tiny optimization was hard resetting the print_data iterator hash, while
|
|||
this would never matter in the real world, it showed that resetting the iterator
|
||||
hash manually was slightly more efficient than resetting it with a for loop.
|
||||
|
||||
10. While not seen inside inxi, I updated and improved a number of the vm's
|
||||
10. While not seen inside inxi, I updated and improved a number of the vm's
|
||||
used to test inxi and various software detections, so now I have a good
|
||||
selection, going back to 2008 or so, up to current. This is helpful because
|
||||
things like shells and window managers and desktops come and go, so it is hard
|
||||
|
|
@ -3062,7 +3061,7 @@ most recent on an absolute level Xorg log file. This issue was caused by gdm
|
|||
moving from Xorg.0.log to Xorg.1.log on some systems, but not all, and also, the
|
||||
location is often but not always now: ~/.local/share/xorg/Xorg.[01234..].log
|
||||
[except for root, which is why root has to search for all user Xorg log files to
|
||||
find the most recent one.
|
||||
find the most recent one.
|
||||
|
||||
There were many red-herrings in this issue report, so it took some research to
|
||||
dig through those to the real data sources.
|
||||
|
|
|
|||
Loading…
Reference in a new issue