Finalizing the features of the display API upgrade in #pinxi. I know I'm getting closer because I did the first updates to the man page and the help options to reflect the new features. I'd been holding off on that since didn't want to change all the time. Started testing on very old systems, Debian Etch, Lenny, fixed some glitches. Also added in some belated OpenGL data features, which I wasn't really aware of, but stuff changes and it's hard to keep up with everything. #inxi 3.3.30 nears.

Coming over next week to #pinxi, aka, next #inxi, #EGL, #vulkan display API output.

These will use eglinfo and vulkaninfo as data sources, so should not be that hard to implement.

More reorganizations, this time in the inxi-perl/data directory. That's for #inxi development, mostly fake data files used to emulate system features. Added a lot of files, and updated #pinxi to use the new paths. As usual, all the interesting stuff for #inxi lives in the inxi-perl branch.

It's worth noting that everything actually related to #inxi development lives either on smxi.org or in inxi-perl branch of the inxi github repo. The main html docs are also found in the inxi-docs branch.

This way of organizing data come from the original use of #SVN, which was perfectly designed for my work flow, including having real physical directories for branches etc, making it very clean and easy to understand. Trying to force git to behave this way is very difficult, so I use a hack: >

You can peruse these #inxi docs to your heart's content should be you be so inclined but no issues will ever be accepted for those that do not have a corresponding pull request that is well done and clear, since I am not looking for more work. https://github.com/smxi/inxi/tree/inxi-perl/docs

This goes along with the documentation you can find at https://smxi.org/docs/inxi.htm which offer a fairly large amount of better organized and intended for public view resources.

One of those tiresome projects finally done: putting all the random #inxi data documentation that had accumulated in inxi-perl/docs/inxi-data.txt and inxi-resources.txt, which started out with good intentions but grew to be unmanageably large. Now all are split into granular specific data type files, which should make long term documentation control much better. Note these were never intended to be authoritative, they are notes, which sometimes get organized and cleaned up, and sometimes don't.

Odd how derived distros choose to make themselves identifiable, #Bodhi Linux decided to pop their distro file into /etc/bodhi/info which is similar to /etc/lsb_release, so added a way to use the same logic to get data from either source in #pinxi #inxi next. Not to pick on Redhat's Poettering,, but the design of /etc/os-release totally failed to consider complex cases of derived distros, probably because the redhat ecosystem is so sparse with no derived from derived etc... See xkcd on standards

And the #TinyCore #inxi package for 3.3.29 was accepted unusually rapidly, so that is now available in tiny core. I have been fairly successful in my attempts to be a better packager, for a while I was being a bit lax in terms of not releasing often enough, but now I only skip packaged releases that definitely do not matter for tiny core re the changes etc. Most of the time they do matter.

#inxi 3.3.29 zips out the door. I waited 5, 6 days since last looks/issues/comments, and nothing new showed up, so looks like a good time to release since there are some real bug fixes in inxi this time around.

Changes here: https://github.com/smxi/inxi/blob/master/inxi.changelog

And so it goes, where it stops, nobody knows!

There was also a bug fix which I have no idea how happened, there's a feature in #inxi network IF reports to apply a limit of 10 lines of IPs per device unless you reset that with --limit, to avoid hundreds of IF lines on servers that have a lot of IPs per device, like web servers.

For some inexplicable reason, I had the counter counting the total lines of the Network report, NOT the IP lines per Device. Luckily someone with > 10 lines before the IP line tripped this while testing an issue..

#inxi 3.3..29 is shaping up into a nice release, though I should try to release soon due to some real bugs that have been corrected.

New feature, in #pinxi now, for -j/--swap, shows zswap data, and for zram devices, shows zram compression information.

Thanks to another #slackware user, found even more bugs with the USB network/bluetooth device type logic, symptom was a bluetooth device falling through and detected as network. That was bad test parentheses pluls regex issues.

Significant USB regex bug in #inxi, found by a #slackware user, who happened to have the perfect hardware to expose all stages of the bug, which had 3 components at least.

This led to certain USB networking devices failing to show in -N report, and could have led to failures in other device types too, but networking had the most issues.

This is corrected in #pinxi, and should be out as inxi 3.3.29 fairly soon.

After deciding to be less proactive re #inxi hacking, to let users file issues or request improvements, much to my surprise, the last week saw 3 valid issues, all resolved. Even a #FreeBSD one, small bugs that had crept into -S kernel compiler.

That's bluetooth enhanced, the system kernel clocksource feature, and now the FreeBSD fix. Plus one RTFM manual, invalid issue.

I don't think I'd gotten more than a handful of valid github issues over past several months, then suddenly 3 in a week.

New #inxi 3.3.28 out the door, including the nice Memory fixes/upgrades, and of course, the big update on file systems of various types.

Here's hoping no issues pop up from these changes. I waited an extra month, hoping something would show, but in the end, everything has been peaceful.

Still ongoing issue of passive users expecting 'somebody else' to do all the work and research for the feature they might want. I can't find a way to fix this, so I just set the feature request to low priority.

@jeffmcneill I'm researching this a bit since while I can't make IBM's redhat division be something they aren't (free of IBM owner), I can take steps to help identify the various RHEL rebuilds in #inxi. I've been doing that for a few releases, tedious because I have to install each in a vm to verify the distro ID and system base detections. I already got oracle, rocky, alma, covered in previous inxi, and am now adding some more, eurolinux, springdale, etc, and verifying things work as expected.

3 moduri de a utiliza comanda inxi

https://www.hardxroot.guru/3-moduri-de-a-utiliza-comanda-inxi/

#hardxrootro #hardxroot #hadware #sysadmin #inxi #system

This fulfills what is probably the longest standing feature wish I've had for #inxi, a non dmidecode based way to determine info about RAM. While not perfect, inxi can no do a very decent job trying to synthesize RAM total on system without having to touch dmidecode, and as an added bonus, in some, but not all, cases, also can make a good guess at iGPU VRAM assigned from system RAM, which is a nice extra bit.

Won't work for non superuser without /sys/devices/system/memorry, but that's fine.

\2

However, the refactor makes adjustments really easy, and the improved documentation https://github.com/smxi/inxi/blob/inxi-perl/docs/inxi-partitions.txt makes it easier to check in one place for what the file systems are, roughly. Note that as with all #inxi docs, no issue will ever be accepted re their utility and readabilty that does not include a patch to attempt to correct the issue. Doing these is really tedious and time consuming, and since they get very little public use, they are mainly for me, unless someone wants to help.

\4

The accuracy with /proc/iomem math took several iterations before it's usually quite accurate on most systems, with some cases being not so much wrong, but not possible to improve with that data source.

Fallback when -m/--memory is used is to jsut use the dmidecode data if it's avaible, but it isn't always available, like for embedded RAM, so this is the first time #inxi will be able to show reasonably reliable RAM totals along with the recently revised available: field name.

\2

Fine tuning #pinxi for next #inxi release, with help from the #slackware people, found some corner cases, so was able to tighten the code to show memory total: more accurately, with better messages for checking and estimate. Using /sys/devices/system/memory when present as user fulfills a long standing wishlist to be able to show at least some RAM data as user, and with superuser, /proc/iomem gives more, but both can be inaccurate, so had to add in protections and checks.

\1