captain-sensible
Well-Known Member
Hazel ?
In today's article, we learn how to install INXI
- Thread starter KGIII
- Start date
captain-sensible
Well-Known Member
An Avid supporter of Slackware i'm told
OP
Probably. I only recall the LFS bits she shared. I'm not sure if she's still using it or not, but I'm pretty sure she knows more about operating systems than I do. Pretty sure...
Brickwizard
Well-Known Member
I always use Inxi and have done for a long time, I find it the easiest to read even at a quick glance I can see if hardware is causing problems,
OP
Something jogged a memory nugget loose. We had someone asking for help testing the next version of inxi a while back. They're probably constantly developing, so probably always needing more testing. If you're into that, here's the old thread:
www.linux.org
Testers for next inxi (pinxi) - USB, Bluetooth, USB upgrades
Since I just joined here, I might as well see if anyone wants to test the latest pinxi (the development branch of inxi) To install pinxi: # you can put it anywhere, but I find putting it in $PATH is easier cd /usr/local/bin && wget -O pinxi smxi.org/pinxi && chmod +x pinxi # or if you already...
www.linux.org
Just a small correction, I believe slackware, Patrick Volkerding, packages inxi directly now, that slackbuilds is way obsolete. Volkerding is listed as the maintainer anyway, and it's in slackware current repos. I think the slackbuilds stuff was a transitional thing. I've dealt with the slackware guys off and on on linuxquestions.org forums, they are pleasant to interact with, always liked that distro even though not the right one for me, very glad it continues to exist. Not always fully current inxi, but usually within a few months.
Manjaro does indeed package inxi themselves, and to their credit, I believe they are doing the best job of that of any distro out there, they often have new inxi out in all their branches within 24 hours.
I am going to be hitting a cpu data reporting issue, well, I've already hit it, that is going to require a lot of data collection etc, I'm working on it now, some of the fixes are already in pinxi, others won't be done for a while because they require so much research to really get solid, and a lot of testing. Can't emulate this one sad to say in vm, has to be on the hardware, it's a cpu data issue.
Currently the worst errors on test systems are now corrected in pinxi, but a new subclass of error may or may not be fixable, I haven't decided on how to handle some of these things yet because they involve a lot of variables and random data and situations that are not predictable in data structures.
Because the current fixes are already giving better results in many cases that were wrong before, I'm probably going to do 3.3.09 when the current fixes are stable and no new issues pop up, but it won't be the final solution, that just requires a lot of time, thinking, research, data, and work, so i'll probably chip away at that very slowly and incrementally.
You'll see these changes on some cpus already, L2 cache will be right for some intels now, no root required for L1 and L3 anymore, will drift out updates and changes over next weeks, but I can't spend all my time on it due to life stuff.
The final goal is to have correct support for stuff like new intel alder lake, the apple M1 cpu, zen 3, some intel core duo and quadro cpus that currently list wrong L2 cache, but it's very complicated, the old inxi cpu logic was not really meant to handle this new generation of complexity.
Manjaro does indeed package inxi themselves, and to their credit, I believe they are doing the best job of that of any distro out there, they often have new inxi out in all their branches within 24 hours.
I am going to be hitting a cpu data reporting issue, well, I've already hit it, that is going to require a lot of data collection etc, I'm working on it now, some of the fixes are already in pinxi, others won't be done for a while because they require so much research to really get solid, and a lot of testing. Can't emulate this one sad to say in vm, has to be on the hardware, it's a cpu data issue.
Currently the worst errors on test systems are now corrected in pinxi, but a new subclass of error may or may not be fixable, I haven't decided on how to handle some of these things yet because they involve a lot of variables and random data and situations that are not predictable in data structures.
Because the current fixes are already giving better results in many cases that were wrong before, I'm probably going to do 3.3.09 when the current fixes are stable and no new issues pop up, but it won't be the final solution, that just requires a lot of time, thinking, research, data, and work, so i'll probably chip away at that very slowly and incrementally.
You'll see these changes on some cpus already, L2 cache will be right for some intels now, no root required for L1 and L3 anymore, will drift out updates and changes over next weeks, but I can't spend all my time on it due to life stuff.
The final goal is to have correct support for stuff like new intel alder lake, the apple M1 cpu, zen 3, some intel core duo and quadro cpus that currently list wrong L2 cache, but it's very complicated, the old inxi cpu logic was not really meant to handle this new generation of complexity.
Last edited:
OP
It has to be a pain in the butt keeping a script like that current. Thanks for doing so.
We use inxi on a daily basis, here on this site, during the troubleshooting stage.
We use inxi on a daily basis, here on this site, during the troubleshooting stage.
This one is a big pain, already about to dump my first attempted solution because it's not good enough, and takes too much research to implement, need something more dynamic, based on what system reports, not on hard-coded values. The next attempt should nail a bunch of cases that were wrong before.
This one I can't ask for help on yet because I don't know what I'm really going to focus on, but yesterday's data (thanks stan!!) highlighted a direction that may work, and may enable me to bypass horrendously tedious manual research and data sets which I would have to always maintain after to keep it reliable.
So far there isn't one global solution however, even sys data fails me in a key way, I find no way to match the mulitthread virtual 'core' to the physical core, I can tell them apart, but I don't know which belongs to which, not yet anyway. I may be missing a key code or value, I don't know, but so far I don't see it.
The main issue I have is this requires the physical hardware and cpu to test on, it can't be emulated.
This type of data can't be done without --debug 22 datasets, I can't walk users through what I need to see unfortunately, it needs the full /sys parser to run, otherwise I can't figure out what's going on with cpus, cores, and caches.
Stuff I still need to see, will check datasets to see if i have it:
1. alder lake cpu, in its several performance/efficiency core variants.
2. Zen 3 ryzen, and Epyc variants
3. This is a long shot, but the first generation Zen 1 low end non multithreaded 2 core per die version, I think only one or two models/steppings used that, but I don't know if it can be differentiated from the replacements, which went to 4 die per core.
4. Bonus: early linux on apple M1, which has a totally new type of cpu architecture too, especially for ARM cpus. I have no idea what that type of complex ARM cpu even looks like internally in the data so far, those types of advanced arm chips are very likely to hit consumer hardware soon, and servers in some form as well, but I have no access to any of that, and it's all going to be brand new hardware, to make it worse.
I think I have the following probably since those cpus have been popular, various generations of core duo and quadro cpus.
My feeling is the refactor which is going to probably replace what is being tried right now since it's going to have better data sources, is generally almost always going to be better than what inxi 3.3.08 currently has going, which is quite often wrong on L2 cache in particular, and sometimes wrong on dies counts.
So far there isn't one global solution however, even sys data fails me in a key way, I find no way to match the mulitthread virtual 'core' to the physical core, I can tell them apart, but I don't know which belongs to which, not yet anyway. I may be missing a key code or value, I don't know, but so far I don't see it.
The main issue I have is this requires the physical hardware and cpu to test on, it can't be emulated.
This type of data can't be done without --debug 22 datasets, I can't walk users through what I need to see unfortunately, it needs the full /sys parser to run, otherwise I can't figure out what's going on with cpus, cores, and caches.
Stuff I still need to see, will check datasets to see if i have it:
1. alder lake cpu, in its several performance/efficiency core variants.
2. Zen 3 ryzen, and Epyc variants
3. This is a long shot, but the first generation Zen 1 low end non multithreaded 2 core per die version, I think only one or two models/steppings used that, but I don't know if it can be differentiated from the replacements, which went to 4 die per core.
4. Bonus: early linux on apple M1, which has a totally new type of cpu architecture too, especially for ARM cpus. I have no idea what that type of complex ARM cpu even looks like internally in the data so far, those types of advanced arm chips are very likely to hit consumer hardware soon, and servers in some form as well, but I have no access to any of that, and it's all going to be brand new hardware, to make it worse.
I think I have the following probably since those cpus have been popular, various generations of core duo and quadro cpus.
My feeling is the refactor which is going to probably replace what is being tried right now since it's going to have better data sources, is generally almost always going to be better than what inxi 3.3.08 currently has going, which is quite often wrong on L2 cache in particular, and sometimes wrong on dies counts.
OP
The offer still stands. Ask whenever you're ready.
He's definitely one of our most helpful.
