#inxi is such a cool tool, it has local and external IP information on inxi -i, it has weather information in inxi -w. I used to think it was just a great fetch tool, but it literally does everything!
@tripplehelix I laugh every time I see someone utterly clueless say, oh, #inxi is bloated, I could do that in a 100 line shell script and it would be 100x faster. Every significant feature requires massive amounts of work, raw data collection, and unfortunately, the most boring, matching table updates, which there are no single data sources for so those are basically manually generated, using some backend tools for some. Recent complex features only work because #slackware users interested.
1/
It continues to strike me that now, almost 4 months after last commit on any #github project, including #inxi, gh users keep starring my gh repos, even though all of them clearly state that the code is migrated to @Codeberg in the README, which is why I got sick of gh users, they don't read as a whole, and tended to post annoying issues. The users who read, tend to post good issues. that's what I see on codeberg smxi repos now. Not perfect, nothing is, but better. So happy with switch.
And with a whiz bang, #inxi 3.3.33 goes out the door, a quick bug / point release to get the fixed version out before the #ubuntu LTS package freeze happens, which is pretty soon, a week or two I believe.
Managed to squeeze in nice use of the new PsData tool, for a network service/daemon report, and also, to add in nice consistent printers that generate white spaces if certain rules are met in the field values, which allows those values to then wrap to the next line.
I'm also happy to report that @Perl continues to not get in my way, and in fact, the more strict I make my use, the faster it gets, though you can't see the speed increase because there's a lot of new features added at the same time, result being that the new code runs roughly the same speed as the old #inxi code, only does more.
Cutting down on copies, increasing use of references, and in particular, anonymous references, thus avoid creating a variable at all in the first place in a sense.
Initial testing of the udevadm based system RAM report in #inxi / #pinxi are now running well. Most of the logic from dmidecode mapped pretty closely to the udevadm output, though the udevadm output requires one further processing step, but it's pretty similar.
This is a first, showing non root, non dmidecode based system RAM info.
There's one udevadm data glitch, it shows RAM module voltage as 1 always, which looks like a bug, so added a note about that if it's the case.
1/
Testing calls now out for #pinxi (next #inxi), it will be exciting to see if this one gets enthusiastic attention or not, in theory it should since this is one of the longest standing weak spots, not being able to get decent ram per stick and array data.
Getting testers used to be a lot easier, now it's hit and miss if a specific feature will catch anyone's attention. My bet is on #slackware forums, those guys tend to really like core hardware stuff, they were massive help for CPU refactor.
More #inxi / #pinxi CPU issues, it looks like #fedora / #rhel have changed a default standard path in /sys for unknown reasons, thus breaking inxi cpu speed collection. This tripped need to do more refactors, this time to the fake cpu data debugger logic, it was not complete.
Also, a new codeberg issue pointed out that in many #Linux I can get basic RAM/RAM array data from udevadm, which appears to dump some dmi data into itself, available to user.
@adamw other fun changes #fedora / #rhel have done is split apart @Perl core modules, which when I told perlmonks about they correctly said I should file a bug report since that's a bug, but I laughed when they said that. This leads to expected always there Perl modules not being there, which is why it's a bug. Not an #inxi bug, a #fedora / #rhel bug. Note that when upstream says it's a bug, it's irrelevant what the distro says beyond offering some silly excuses.
@adamw nobody packaging @Perl has to ask this, and if they do, they should be fired instantly for total incompetence.
corelist -v 5.036
works for all Perl versions.
See, it's so important that corelist itself is a core part of the Perl package.
This is so critical that it was the first thing I documented when converting #inxi to #perlhttps://codeberg.org/smxi/pinxi/src/branch/master/docs/perl-version-support.txt
There is no scenario where anyone can offer a non bs excuse for this, which is why #perlmonks tell you to file bug report against #rhel.
@adamw nope, that's not the only workaround for missing core modules #inxi has. I'm fortunate that a guy who tests on fedora keeps me up to date, and reports all the issues he finds so I can fix them, or should I say, #fedora / #rhel / #alma / #rocky users are lucky. The debugger doesn't work at all for example until you install the missing modules.
My care is mainly for the sys admins stuck having to maintain these rhel systems over years, otherwise I'd just drop support and call it a win.
@adamw basically I am locked in by my own core requirement: #inxi has to run on anything from anytime that has @Perl 5.008 or newer, that's a hard non-negotiable requirement.
The main benefit users get from these #rhel fixes is sometimes they spread to other distros, but sometimes they make the code more robust and reliable for everything.
You are correct, once this mistake was made, it was permanent, the bug was in the culture that allowed it to exist and allowed the excuses to be accepted.
Fedora/Redhat doesn't include File::Find File::Copy in
core modules. why? Or rather, they deliberately removed them. Maybe File::Spec::Functions but those are only used in the debugger, which means, of course, that when they are needed most they are not there unless you installed the #inxi package, which has those as dependencies, I think.
I just fix the stuff as the guy finds the failures, I don't track it. You guys should thank #mrmazda.
@adamw can you see the idiocy here? one after another core modules, the bug is they were removed, the fix is to ban breaking up @Perl core modules. This entire discussion is so silly, it's not about this or that core modules being there or not there this or that fedora release, it's about core modules being broken up in the first place. You fix bugs by fixing the core cause, not by adding bandaids. That's what I spent a few hours on today in #inxi, dumping the bandaidds. @mjgardner
@adamw@Perl@mjgardner the core concept appears to be remarkably difficult to communicate. As I said, #tinycore has no problems with this. I'm curious if anyone actually cares about this alleged reason to have newer versions, if they do, you are breaking the entire perl ecosystem to cater to probably a handful of users who could just install the updated versions themselves.
All the workarounds in #inxi were added due to fedora failures due to breaking core m odules over past 3 years.
@adamw@mjgardner also, from my perspctive, there's no difference re support between #rhel etc and #fedora since #inxi has to support all of it, if one is bad, they are all bad basically.
I'm not on work time either, which is why this stuff bugs me so much, it's stupid and always has been, and should never have been allowed, and the excuses are just as stupid.
My only real hope is to get rh to once and for all stop this stupid behavior, but I have no hopes for that.
@adamw I think we’re misunderstanding the #OpenSource division of labor here:
@smxi writes #inxi so it can run wherever it needs to
you tell #Fedora to fix their problems because you heard from him and you’re in that organization
I help @smxi write good #Perl given his requirements and constraints, and cajole you to get Fedora to package it and Perl correctly so the next dev doesnt avoid it
By the way, I can now state categorically that by far the worst part of switching to #Perl has been the language never getting in the way of progress and features, since if the language helps consistently, one tends to not avoid doing features and fixes. 37,129 LOC and counting. Oh, and the speed boost too, always astounds me to see how relatively peppy #inxi is. As I once described it, it's like a duck swimming slowly on the water, its little legs churning furiously under the surface. #NYTProf
I have a nice set of packages ready for KDE Plasma6 Beta2 which was just announced two days ago.
As you see from below screenshot, it runs nicely as a Wayland session, both logged in via the SDDM login manager and by running "startkwayland" from a console in runlevel 3.
@alien it's also useful to see that some of the commands #inxi might test are actually already running with sddm start, but that's why the file being in /run is a more reliable as a test. I will check my #Alpine vm to see, I forgot to check if their dbus-run-service sway leaves a /run file, or just a process.
Hmm, I'm going to have to figure out a way to separate my tech personae from other interests, is that best done by creating a different username on a different instance? I'm not up on the intricacies of #mastodon#fediverse but I do know I don't really like mixing the tech part of me with other parts.
@proactiveservices ah, so that does work, I will look into that. I honestly don't want to force #inxi followers to listen in on totally non-related areas, glad I asked. How does the mastodon client then handle switching? I will have to check on this. Thanks.
Two small bugs were exposed by pure chance after #inxi 3.3.31 was released, one was a small #perl error I made in the release, and one has always been around since /sys based temp feature was added. The second has never appeared before and showed literally by pure chance, #mrmazda typed -vs instead of --vs, which tripped sensors on one system that has this issue.
Because this was 1 extra line to fix, and fixing a second, I did a 3.3.31-2 tagged version to make sure the fixed version is master
New #inxi 3.3.30 out the door! First release that is #codeberg primarily. Note that all the new data and docs in the codeberg #pinxi repo are not on github, and that's basically all the dev data/docs for inxi.
Here's hoping the #codeberg and #gitea devs can manage to keep the servers running and not have significant issues, I'd like to stay there a while if possible.
The tags were updated on github/codeberg since gh is mirrored to cb, but that won't last forever. Hopefully packagers adjust.
The #Debian/#Ubuntu#inxi packager becomes the first person to package inxi from the #codeberg repos. So the new era is under way, I should package it for #tinycore, maybe I will tonight.
@Codeberg A core requirement of #inxi is that it always works on everything, going back to about 2005-2008. The only hard requirement is #Perl 5.008 or newer. inxi is in #Debian sid, which can be accessed via pinning to stable and adding sid sources, or you can just replace inxi package with inxi files, there's no difference really. Each new inxi tends to have a lot of new stuff, and new hardware etc support.