#inxi — Public Fediverse posts

@EpiphanicSynchronicity @ozamidas @anildash yes re excellent #i3 docs. When I was extending #inxi window manager and desktop support I installed everything available, in some vms. i3 had by far the best docs of anything I tested. Best man page, best web docs, so I figured if their docs are this good their code must be as well. Sadly the same could not be said for #sway, the wayland i3 clone. Maybe that's gotten better by now. i3 docs also inspired me to upgrade inxi docs and public data.

Oh I nearly forgot. New #inxi 3.3.40 rolled out. This is mainly a critical bug fix for a feature very few people use (export to json/xml), plus a key name change. I have a rule that key names can't hold values, but I'd slipped and used BIOS or UEFI as the keyname, instead of firmware: BIOS. Plus a few small fixes. I tend to wait until there are enough updates to warrant a new release, but a bug that makes a feature always fail forced the early release.

Bug was a silly bad copy/paste, sigh.

The classic #x11 window manager and desktop site xwinman.org came up in an unrelated #inxi issue on #codeberg. I had used that site to create the original list of window managers inxi supported, but then I didn't think about it.

One thing led to another and I found most of the site, except the /archive/ section, which is at archive.org.

Since this is roughly my skill, I grabbed the site, upgraded it to modern responsive html/css standards: https://smxi.org/wm/

Try it on your phone!

With a faint whoosh #inxi 3.3.39 goes out the door. Some nice battery upgrades and more cpu variants handled. I got a flurry of pretty good #codeberg issues which led to most of the improvements and fixes. Also added a section to the inxi.changelog UPDATES: which are all the manually generated matching tables etc.

Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

It's absurdly hard to find this cpu data.

Amazingly, someone showed up in #codeberg with an #inxi issue about #Loongson CPU support, something I have looked for data on for years. He provided 5 full sys-ci file pairs, which let me crudely emulate the cpu in test mode. Turned out the #MIPS detection failed because as of Loongson 3A5000 they have their own ISA, in other words it's its own type, forked from MIPS. Fixed the detection and many other glitches, added --loongson emulation flag, and now support works better than ever.

More battery updates in #pinxi next #inxi

Added more values and updated docs using kernel.org /sys/class/power_supply items.

They have been busy and added many new values.

#codeberg issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.

Fun fun.

Turns out 3.3.39 will be the battery upgrade release

@[email protected] I had to think about it. #xfce-terminal. I use #inxi almost every day but I always use the terminal, and inxi does many things. Since I use it to be a terminal only, I guess that's the closest I get to something that does one thing well on a daily basis. Also Kate but it does several things but it is really just a code editor. And #Filezilla. And often #acxi. I like using tools I made for my needs.

In #pinxi (next #inxi ) a full refactor of the venerable Battery module. A #Codeberg issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the #perl rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

#Inxi est un excellent utilitaire en ligne de commande pour obtenir des informations détaillées et complètes sur le matériel, la configuration du système, les processus, la configuration réseau, etc.

Un de mes utilitaires préférés auquel j'ai régulièrement recours pour mon ordi sous #Linux quand j'ai besoin d'une info système particulière.

😉

https://www.linuxtricks.fr/wiki/inxi-un-script-complet-d-informations-systeme

But wait, there's more #inxi cpu arcana!

Intel, for inexplicable reasons, decided to keep their family stuck on 6. Which leads to them running out of the 256 possible model ids (16x16). This leads them to resort to using stepping id to tell various series apart, which is a royal pain to track. I was hoping they'd stop and use 12 when they did 12th gen Alder Lake, but no such luck.

Why? I'm guessing some vendor hardcoded in family 6, or it's just a symptom of intel engineering problems.

4/

(#inxi arcana con'd)
Amd for family does this:
Extended Family : Family is:
Extended family + family.
So for say zen 2, cpuid shows 8F as family. 8 + F = 23, the hex of which is 17h, aka 16 + 7. 23 is what cpuinfo shows. 17h is what inxi uses internally.

Since this makes zero logical sense, I've had to update each family block with these 3 values.

I had zen 5 as Family 20, not 1A, cpuid BF, aka 11 + 15 aka 26 aka 1A.

Got that? Why isn't cpuid simply 1A? Who knows.
3/

Here's a peek into the arcana of #inxi research, which is then added to docs and tools, in #pinxi repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
This is the data provided by cpuid binary. These are hex values.
https://en.m.wikipedia.org/wiki/CPUID
Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
/proc/cpuinfo shows this as an integer. So far so good.

But then amd does something which makes my head hurt:
(Con'd)
2/

Meanwhile on the #inxi front, https://youtu.be/bvHrJzB4-MQ?si=LCrrymqnQc5lVH4c
MooresLawIsDead got leaked specs for AMD Zen 7 cpus. With earlier zen 6 specs, this let me try to get support in before actual data appears. That's rare for cpus and gpus. I also realized I'd used the wrong family id for zen 5 cpus, which means advanced architecture data probably never showed.

This is an easy mistake to make because the way amd does their extended family id is different from how they do their extended model ids.
1/

With the quietest of whispers new #inxi 3.3.38 goes out the door. A few fixes, a few enhancements. But maybe the fewest changes in a new release. The main one was a syntax change for vulkan driver that made inxi show N/A always on newer systems.

Plus an actual sensors bug I found by pure chance. And an anonymous #OpenBSD dataset from a vm that exposed some invalid assumptions about values always being present for any given field name.

@dumpsterqueer you'll never miss github. All that happens when you move to @Codeberg is the signal to noise ratio skyrockets and you end up with mostly good issues. That's been my experience anyway.

At first I worried about losing all those eyeballs and followers but it quickly dawned on me their quality on gh was so low they were negatives.

My #inxi project keeps getting starred on gh despite having no commits for 1 yr and saying moved to cb. Not reading was my other peeve about gh users lol.

@arstechnica
Checked for #inxi gpu support. I'm not sure why this story was put out. Seems like every 6 months or so some site/channel discovers the #nvidia driver story. But doesn't research it.

Current status. Maxwell, Pascal, Volta (those 3 next legacy), along with Turing and newer (supported by #linux #kernel foss wrapper) supported in active driver branch (565.xx). The wrapper is not a driver.

Announced with git repo May 2022.

The actual foss driver is Nova. I think.
5/

@arstechnica I have to track nvidia drivers for #inxi and #sgfxi in *nix. What's surprising is how long it's taking to make pre Turing/Ampere drivers legacy. That was supposed to come over a year ago. Legacy does not mean no support. Legacy drivers get several years more support. There's nothing new here.

The cut happens because Turing and newer have moved most of driver into firmware. #Linux kernel will use open source wrapper to talk to firmware.
1/

Fastfetch liefert Systeminformationen

Dieses Werkzeug stellt Systeminformationen im Termin übersichtlich dar. Durch seine Konfigurierbarkeit lässt sich Fastfetch an die eigenen Bedürfnisse anpassen.

#fastfetch #Neofetch #System_Information #Inxi #Linux

https://gnulinux.ch/fastfetch

Got a good #inxi #codeberg issue report. Graphics #Vulkan API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in #pinxi but sadly just missed the 3.3.37 release by a few days. Oh well. A #Mint user reported it after seeing driver: N/A always.

Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.

These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.

Wish I'd noticed side before inxi 3.3.37 went out but this always happens.

And yes, just sent the #inxi 3.3.37 package off to #TinyCore - which is the last step of the process.

So that completes this 4 month release cycle. It would have been less but the monitor scaling feature of course turned into a rabbit hole.

But read the changelog if you are curious. It's long and thorough by design because it's the actual record of what changed, why, and what isn't currently doable. I use it often to find when why and how features are added or removed or changed.

New #inxi 3.3.37 goes out the door. Includes last minute workaround for 32 bit intel gen2 gpu eglinfo hang #mrmazda found. Probably a regression in i915 driver. And the big monitor scaling feature.
Full changelog here:
https://codeberg.org/smxi/inxi/src/branch/master/inxi.changelog

This is the longest between releases in quite a while so nice to get some nifty enhancements and fixes in.

This also introduces the improved option syntax for -b -e, which gets rid of a peeve of -F being impossible to explain.

Churning through an unexpectedly complicated series of updates in #pinxi next #inxi

Got the gpu monitor scaling handled which required fixing xrandr and wayland tool parsing and logic. False assumptions led to errors in output.

--force options were glitchy and inconsistently used and documented. Cleaning that up exposed more glitches, like --no-man not working in inxi due to opaque hash names.

It's surprising how fixing docs, help, and man exposes bugs in logic. Still polishing that up.

#viernesdeescritorio

Feliz finde, pinwuinos :ablobcatrave:
#Void
#Hyprland
#waterfox
#fastfetch
#inxi
#cmatrix

Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.

Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.

I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.

Updated graphics docs with new res section.

I should probably get off my butt and release next #inxi. There haven't been any real issues for a while now. Though #mrmazda had an advanced display resolution enhancement request but it takes work and thinking to do. And testing.

@jk your fundamental error was obvious in your Initial pist. You believe distros are little corporations competing against each other for supreme dominance.

This is profoundly wrong.

Distro means distribution. Of what? An often massive set of free software projects, #Linux kernel and #LibreOffice being 2 of the larger. #inxi being a smaller.

Manjaro Linux Introduces Opt-Out Telemetry with Manjaro Data Donor #Manjaro #ManjaroDataDonor #MDD #Inxi #SystemInformation #DataCollection #Opensource #Linux
https://ostechnix.com/manjaro-data-donor/

#inxi #codeberg has slowly been collecting stars. As with #acxi, on github where I considered 1 star equal to 50 inxi stars because it's a very focused and specific tool, so too I think will I consider 1 codeberg inxi star equal to about 50 gh stars. Despite inxi gh not getting an update since 2023-12, and being marked as archived, it keeps getting forked and starred, which is the EXACT reason I realized there was no loss leaving gh in terms of eyeballs. Eyes with nothing behind them = no value

Next #inxi is shaping up well, all running in #pinxi now. Came across an ancient distro I'd never heard of, #TDSDE, which apparently preceded Gentoo by a few months. Poor docs, unreliable source builds, but got everything inxi cares about working, and found some weak spots. These corner case distros often expose weak assumptions.

Also locked down #rpm packages, #urpm #eopkg #pisi repo reports, which were not great, or not working.

Took a while to get enough fixes to warrant a new release.

Found issues in #inxi repo report for some software sorced repo lists.: #mageia's #urpmq, #pisi, #solus #eopkg. These all are roughly similar and all had same report glitch of showing one repo data source per output line instead of source then all repos. The output was also weird. Corrected in #pinxi. Thanks #mrmazda for noticing.

Then noticed the #rpm package count failed for mageia. Turns out they are using different version of rpm, missing some options so no results. Will add workaround.

In terms of the #acxi code itself, because #inxi is far larger and more complex, and requires far more code discipline to maintain, and gets refactors all the time to achieve that goal, acxi tends to follow along like inxi's little brother, and benefits from all the improvements I introduce internally in inxi code. Particularly #Perl syntax and structures. In this sense, inxi really benefits acxi since acxi's code basically gets a 'free' upgrade using my latest stress tested inxi techniques

And that closes the very first @Codeberg #acxi issue. And creates the first proper #codeberg acxi release, 3.6.02.

acxi is designed to be very stable, unlike #inxi which evolves constantly, and only gets updates for fixes, like this one, or to introduce new features wanted by me or a small handful of acxi users I know. eg --tagllst, which the #slackware packager requested. A feature I now use all the time. This has happened with several powerful features. Benefit of a few good eyes.

First @Codeberg #acxi issue (silly mistake, and good issue). acxi is a specialized CLI audio processing tool that, unlike #inxi (which is made as general utility for the wider #FreeSoftware ecosystem), is intended to meet specific audio file processing needs. It makes no effort to be 'easy' or 'user friendly', although it is immensely powerful. But not for newbies. Unlike inxi, which is fully operational out of the box, acxi does nothing until configured or run with the right CLI switches.,

#inxi 3.3.25 goes out the door, last matching tables updates for cpu, disk vendor. Features gpu device id updates, various fixes, the new --config options, some documentation updates.

Some other #acxi stuff I used for inxi was the organization of sub categories in the changelog, which helps readability, and makes it easier to maintain and update.

In a sense, the recent acxi updates moved its code closer to inxi style, but also some stuff moved back into inxi that I found useful.

With with a faint pop, just missed Chinese New Year release, #acxi 3.6.00 goes out the door. Now to move on to do other things.

For those watching, #pinxi is moving very slowly towards next #inxi, but nothing pressing really calls for a release yet, but features/enhancements are slowly building up. Better intel/amd gpu IDs for example.

@ChristosArgyrop @mjgardner nothing, lol.

Number 1 requirement for #inxi is that it runs anywhere on any system back to Perl 5.008, which was based on running on old redhat servers mainly.

As I noted a few posts back, the time I accidentally introduced a post 5.010 feature to #acxi (state with assignment of array), I got an almost immediate bug report from someone running it on old os.

With this said, maybe in a few years I'll bump inxi to 5.010, to get say and state.

@mykhaylo #inxi and #acxi, backend tools for those, and some for work. Not a lot at work, but I found it far better in production in any scenario where I had used shell + php before. inxi is an extreme practical extraction and reporting tool, and is in a sense exactly what perl was designed for. #acxi not as extreme. Core requirement for inxi in particular is to work on 15+ year old os/hardware, so you can run it on old servers. No other language has the feature stability of perl 5.

Te be slightly politically incorrect in these circles, I am just enough of a geek to think bare metal stuff is interesting, but not enough of one to then dedicate all of my life to that pursuit. #inxi is basically at this point a public service to the foss community, my giving back since I use free software top to bottom, and #acxi is a tool I make to do real things that have almost nothing to do with tech at all. I also recognize that free software itself is on a dangerous slippery slope...

To me, the 'marketing' of #perl would benefit greatly from focusing on the areas where it excels, it's true power and utility, which is being a practical extraction and reporting language, which is why I picked it for #inxi and #acxi, though it does more than extract in acxi, but that is part of what it does.

True native regex too, coupled with advanced complex data structures, unlike say python, where regex has to be added as a library, requiring functions to access, like php.

@mjgardner I find it useful to pause to reflect on things like this when I hit completion of major project, which I am doing in #acxi now, to sort of mull over what the tools are doing when pushed past areas I'd used them before. I am genuinely surprised I never hit this issue before in #inxi because it uses data structures heavily. My current sneaking suspicion is that I did hit them, and then worked around them without realizing why it failed and why fixes worked.

@mjgardner in this case, I can quite literally count on zero fingers the number of times I have seen php crash without trapping the error and giving me something to go on. 20+ years. I'm not blaming anything, I'm noting an event that occurred that should not have occurred, and when it occurred, should have been trapped. And always has been in the past, with everything, and both #acxi and #inxi see immense amounts of garbage data. Not excluding other causes, but don't have time to spend on it.