Testers for next inxi (pinxi) - USB, Bluetooth, USB upgrades

Well, that is all certainly understandable. One reason I don't join the forum there is that I don't feel I can even speak the BSD language properly. I'm still way too much of a noob, and it will be quite some time before I might have any more confidence with their OS.

I've been to your smxi.org website and GitHub page... trying to follow along. I will visit again too, and see if there is anything that I might can add or contribute or suggest.... or maybe just make a small donation at some point. I definitely value your work on this project, as I know that many others do also.
 


The best place to catch my attention is filing an issue on github, just say you're stan from linux.org so I don't mistake it. You're one of the best, most patient, testers, I've come across in recent years, that's a rare skill I have to say.

If you want a chuckle read the changelogs, until your eyes cross and you have to give up, lol. But those are as complete as memory allows, usually they are based off of the inxi-perl/pinxi branch commit comments, though I'm trying to change that now to use something a bit easier to keep track of.

I'm glad to hear people find use in inxi, it's a lot of work, no idea why I do it beyond my finding originally that the hodgepodge of suggestions every time a user posted some question about how to get data was sure to drive anyone not already committed and involved away.

I used to do forum/irc support, a lot, and after a while, you realize, man, ok, graphics questions, always the same, what do they need to know? card, driver, xorg, wayland, xorg driver, etc, ok,, that's -G. And so on as the lines grew. I think the original inxi was sort of like -b minus the machine line, and minus the networking IF device lines, and minus many of the -S and -I items. -S and -I are different types of lines than most of the others, they are collections of features, not a single or two single features.

There's a guy behind the scenes who gives frequent suggestions, he still does active forum support, and many of the latest inxi features were things he wanted for user support, -Ga, -y1, for example.

Oh, yes, -y 1, if you want to understand inxi data, use -y1 output, that was enormously useful for me to keep inxi working and reliable, since it lets me see that I've actually organized the data correctly. It also helps for very complicated things like complex lvm setups, but I think one of its most useful things is for support people themselves to actually learn which data items belong to which.

Code:
pinxi -Gay1
Graphics:
  Device-1: NVIDIA GT218 [GeForce 210]
    vendor: Gigabyte
    driver: nouveau
      v: kernel
      alternate: nvidiafb
    bus-ID: 09:00.0
    chip-ID: 10de:0a65
    class-ID: 0300
  Display: x11
    server: X.Org 1.20.10
    driver: 
      loaded: modesetting
    display-ID: :0.0
    screens: 1
    Screen-1: 0 
      s-res: 2560x1024
      s-dpi: 96
      s-size: 677x270mm (26.7x10.6")
      s-diag: 729mm (28.7")
      Monitor-1: DVI-I-1
        res: 1280x1024
        hz: 60
        dpi: 96
        size: 338x270mm (13.3x10.6")
        diag: 433mm (17")
      Monitor-2: VGA-1
        res: 1280x1024
        hz: 60
        dpi: 86
        size: 376x301mm (14.8x11.9")
        diag: 482mm (19")
  OpenGL: 
    renderer: NVA8
    v: 3.3 Mesa 20.2.6
    direct render: Yes
 
For kicks, this is from the original fork of infobash, version 0.1. (oct, 2008), the first working prototype. Note how ugly the output is, and how crude and almost useless, but you can see the very basic raw ideas. The reason I forked it was a guy in the distro I was with was a dick, and flat out refused a tiny patch from me that would add general debian version support to the distro id, not just their distro id, so I decided, knowing he was a dick, to just fork it and not waste any time arguing with him.

Back then multithreaded multi core cpus were not a thing, so the redundant output wasn't as big a deal.

If you see that 'Client: shell' item, that's the logic that was causing so many issues for me here recently, it was almost literally older than inxi itself, and had just sat there, modified, but not questioned, for so many years.

Code:
./inxi-0.1.0 -v3
Host/Kernel/OS "yawn" running Linux 5.10.0-4.3-liquorix-amd64 x86_64 [ Debian GNU/Linux bullseye/sid ]
CPU Info       (1) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2989.876 MHz ]
               (2) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 3347.264 MHz ]
               (3) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2256.677 MHz ]
               (4) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2278.274 MHz ]
               (5) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2772.382 MHz ]
               (6) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2290.398 MHz ]
               (7) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 1525.439 MHz ]
               (8) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 1533.779 MHz ]
               (9) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 1987.390 MHz ]
               (10) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2859.210 MHz ]
               (11) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 2850.186 MHz ]
               (12) AMD Ryzen 5 2600 Six-Core 512 KB cache flags( sse3 nx lm svm ) clocked at [ 3673.816 MHz ]
Videocard      NVIDIA GT218 [GeForce 210]  X.Org 1.20.10  [ [email protected], [email protected] ]
Network cards  Intel I211 Gigabit Network Connection, at port: f000
Processes 501 | Uptime 6days | Memory 8879.9/32126.9MB | HDD  Size 3184GB (57%used) | GLX Renderer NVA8 | GLX Version Yes | Client Shell | inxi 0.1.0
 
You're one of the best, most patient, testers, I've come across in recent years, that's a rare skill I have to say.
Thank you! You caught me on a good day! Okay, well, a few good days! ;) I have some frustrations too, and I've been thinking of "retiring" from forum support. Sometimes I think I am turning into one of the people I encountered way back in my early Linux days (one of the RTFM types)... and I don't want to do that. Okay, I'll take a peek at the changlogs! ;) Might help me get to sleep at night! LOL


For kicks, this is from the original fork of infobash, version 0.1.0, the first working prototype. Note how ugly the output is, and how crude and almost useless, but you can see the very basic raw ideas.
Wow, that is very basic, for sure. I looked at the inxi code too... can't follow it, but it's mighty impressive. But it's the output that is really impressive, and so well formatted. Even without knowing the best options to use, we can scroll through a full output and quickly find any items we're after. It is tremendously helpful.
 
Great to hear! that was the goal, re having the data you need for support be available without having to jump through hoops. As an aside, while following forums on bluetooth, I realized, they are at it again, and making people jump through hoops just to provide basic bluetooth data, and also, telling people stuff that's consistently wrong about why their bluetooth isn't working, something I learned quite early when testing and realizing my bluetooth wasn't working and didn't even show up. The man page tells you what to do for bluetooth -E option if you see no device. But unlike other tools, the good one, no root, reliable, consistent, well designed, hciconfig, was deprecated, and the replacements are all not as good, and have all kinds of hiccups when used, some seriously bad design decisions, so they can't even be used at all if bluetooth service isn't running.

The formatting was a big deal to me because I do web work for money, and having pro data layyouts and structures is kind of what making web pages is all about, so I tried to make the shell do that as well, never could get it to really follow modern stuff until the rewrite to perl though due to lack of control of output width handlings, that was one of the very first items I did in the rewrite, make the full on dynamic width handler, that's why -y 1 was possible too,, though I had to do some significant refactoring to make that work but it wasn't that hard because the core logic was designed to be flexible for widths.


For further kicks, while I don't have a 1.0 version around readily, here's -v5 from 1.1.0

Code:
./inxi_1.1.0 -v5
grep: ./inxi: No such file or directory
System:    Host yawn Kernel 5.10.0-4.3-liquorix-amd64 x86_64 (64 bit) Distro Debian GNU/Linux bullseye/sid
CPU:       Hepta core AMD Ryzen 5 2600 Six-Core (HT) cache 3584 KB flags (sse3 nx lm svm)
           Clock Speeds: (1) 1470.508 MHz (2) 1476.770 MHz (3) 1412.433 MHz (4) 1382.871 MHz (5) 2283.413 MHz (6) 1672.106 MHz (7) 1558.326 MHz (8) 1559.250 MHz (9) 1546.663 MHz (10) 1548.673 MHz (11) 3821.608 MHz (12) 3649.857 MHz
Graphics:  Card NVIDIA GT218 [GeForce 210] X.Org 1.20.10 Res: [email protected], [email protected]
           GLX Renderer NVA8 GLX Version 3.3 (Compatibility Profile) Mesa 20.2.6
Audio:     Card-1 Advanced Micro Devices [AMD] Family 17h (Models 00h-0fh) HD Audio Controller driver snd_hda_intel
           Card-2 NVIDIA High Definition Audio Controllerdriver snd_hda_intel
           Card-3 C-Media Electronics Inc. Audio Adapter (Planet UP-100 Genius G-Talk) driver snd-usb-audio
           Card-4 C-Media Electronics Inc. USB PnP Sound Device driver snd-usb-audio
           Sound: Advanced Linux Sound Architecture Version k5.10.0-4.3-liquorix-amd64
Network:   Card Intel I211 Gigabit Network Connection driver igb
Disks:     HDD Total Size: 3184.6GB (57.9% used) 1:  2:  3:  4:
           5: 
Partition: ID:/ size: 59G used: 19G (34%) ID:/home size: 48G used: 27G (58%) ID:swap-1 size: 16.78GB used: 0.16GB (1%)
Sensors:   System Temperatures: cpu: 51.0°C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes 503 Uptime 6 days Memory 9012.0/32126.9MB Client Shell inxi

That's pretty recognizable as inxi by then. Note how this worked in 2008, and it works today, same logic, same code, that's why I get so frustrated at the BSD guys, they just don't seem to grasp the value of having good reliable system data for tools to use. Hmm, actually, no, the disk names got lost, that's an outrage!!! failure!! but otherwise it's pretty complete.
 
Many times that simple output is all that's needed: audio, network, graphics. But I just ran with -Gay1 and it was amazing how much information you can collect and show us. That's a shame about the Bluetooth group... sounds a lot like the BSD group too. :oops:

It's good that you've had some free time to make these improvements, but I hope that hasn't been Covid related and keeping you from your workplace. Doing web work seems like you might be used to working from home, but perhaps not. I retired from my full time job (in a steel mill) about 6 months before the pandemic, so I really lucked out with that timing. I tell people now that I am a "professional piddler".... I piddle on one project, then piddle on something else. No goals, no deadlines, no direction. It's all that I hoped retirement would be. :)
 
Oops, I just deleted the first report.... I had forgot to update pinxi that time.

just a quick question - stan did you need me to undelete that post you accidentally deleted between current #65 and current #66?

Sing out if you do.

Wiz
 
stan did you need me to undelete that post you accidentally deleted between current #65 and current #66?
No, but thanks, Chris! I deleted it because the report was inaccurate (old pinxi). :oops:
 
Last edited:
-Gay1 was largely at the request of a fairly well known linux forum support guy, he asked for the extended -a data, and, while not directly asking for -y1, asked for some output granularity that could only be done with a feature like -y1, those were both really hard to do, but massively boosted the data available for debugging.

The drag there is that the wayland project made a HUGE, massive, possibly non fixable error, by not enforcing debugger data into their spec, which makes wayland literally impossible to support in any real way, there is NO data available beyond a few environmental variables that let inxi determine it's wayland, not xorg. NONE of the dat you see in the Display part of -Ga is available from wayland, and I'm frankly mystified totally how wayland ever expected to be able to debug wayland issues without a builtin wayland debugger that is always present and available. There aren't wayland log files, there's nothing, zero.

That's in my view the top reason for the overall failiure to move to wayland, it's taken way longer than it should have, and that's because the way they designed the spec guaranteed that it would not be debuggable in any easy way. Shouldn't have been a spec n the first place, should have been a real software project like Xorg, with open implementations that let people use the code base the way they want, but with consistent reporting tools available always.

Not only does inxi have barely no wayland data, it can NEVER have wayland data, which is totallly absurd, it's very hard for me to believe that adults with software experience would have made a new protocol with no native way to debug it, that's just beyond belief, total full fail. Imagine the linux kernel with no way to debug it consistently, I mean, that's absurd. The first major featurse I added to inxi when rewriting it were the debugger and the self updater, so people could easily update to new patch versions instantly.

Re the bluetooth group, sadly, there is no such thing, what there was was a guy or two who did the hcitools suite of software, those were super well done, very clean, super large amounts of data, reliable, could be run always, without hangs if bluetooth wasn't running, they are good software, but they stopped maintaining it. The new stuff is badly done, and I've read repeated issue reports they reject about the tools hanging endlessly waiting for input if bluetooth service is not running, and they don't consider this a problem!!! I mean!!! somehow the hciconfig guys managed to solve that issue, but the new stuff can't, which makes it unusable in many cases.

But the issue re bluetooth was the same old support stuff, where endless well intentioned but basically wrong people on forum threads suggest a b c d, and fail to suggest the real solution, and ask the user to run various tools to report status of bluetooth, same old support mess as usual, but unlike most other features, due to the big bugs in the current bt tools, bt-adapter and bluetoothctl, which neglects to even tell you which hci device it is, which is the only way you can link the bluetooth data to the device, and neither can be used if bluetooth service is not running, I mean, yes, you got it, figuring out the trivial task of exiting if bluetooth service is not running was too hard for those developers, sigh...

So I can't come out with out of the box fantastic reliable bluetooth data the way inxi does for networking data, which uses good, reliable, tools, like ifconfig for ip addr. That was disappointing to me, and it's actually why I didn't do the bluetooth feature when a guy first asked for it.
 
Wow! There is so much popular movement toward Wayland, this lack of ability to identify features and functions for troubleshooting is going to be a nightmare, it seems. Maybe it already is. I use primarily old, old junk computers here and have not made any serious attempt to use Wayland. I've probably tried a little with a VM or a live USB, but it's never been a part of my daily desktop.

Things keep moving forward, but not necessarily making things better. Did the move toward systemd affect your inxi development? Make it easier or harder?
 
Wayland is so slowed by their errors in design that it's hard to really say when it can truly replace xorg. Their whole thing, which after typing that, I honestly believe is that the primary developer, who was a primary Xorg developer, simply did not want to carry the burden for the rest of his life of supporting software like he has had to do with Xorg, so he washed his hands of all responsibility, with the 'wayland is a specification' stuff, and 'compton is only a reference implementation of wayland', again, to avoid actually making something that has to be maintained and debugged. That's what makes it a true nightmare, every compositor can introduce its own bugs, the spec can have bugs, and now it's impossible to say, ok, we can fix this because we know where the bug comes from.

The only way you can use wayland, not an xorg wayland, is if you never use any xorg programs, only stuff made to work on wayland. That's basically not possible to do. So all the desktop data you see in -Ga from wayland users is actually using xorg reporting tools, like xprop, glxinfo, Xorg.0.log, xdpyinfo, xrandr - notice all the 'x' there? all Xorg tools.

Systemd.... sigh, did it make it better or worse? I can say, for a good solid 10 years, it made my dev life worse, since I couldn't do safe upgrades due to the bugs in systemd, those seem to be, now, finally, roughly ironed out, that took way too long because the main systemd devs kept saying they wouldn't fix the bugs, and denied they were bugs. Systemd is not really used by inxi, it's very slow and I try to avoid various systemd tools because they are just super slow, absurdly so in some cases.

Now what really worked, and is getting better all the time, is /sys data, that's from the kernel, /sys data improves yearly, and lets inxi do more and more stuff with no dependencies at all, the kernel guys have always been super good about creating highly usable live kernel data, like the stuff in /proc, and then in /sys, to me, that's one area where flat out they shine, best in class, nobody does it better. BSDs should have copied that idea long ago, but failed to. The basic idea is so simple, the essence of unix like systems is to be made out of files, so what better way to present system data than as virtual files? that's files made live by the kernel when you request it or read it. I am truly puzzled by why the BSDs didn't take this idea and run with it, because stuff like /proc/partitions, /proc/cpuinfo, /proc/meminfo, are simply better ideas, more flexible, easy to implement, and don't require compromising a single thing for BSD licensing or anything, these were just excellent engineering ideas, made for excellent reasons, and designed so well that they have been largely stable for possibly decades now.

This is something good engineers should have gotten together about and said, we need to do this too, these are just too good, but BSDs totally failed to do so, I do not understand why that happened to be honest. Not calling it /proc or /sys, just a virtual file system that you can read in a predictable, consistent, way, across operating systems, that was one of the things that linux did that helped them take over from bsds, and I don't understand why something this elementary is too much for the bsd guys to do. Sure they have sysctl -a, but that's not consistent across OSes, and it's unreliable, and not that well done imo, but it was a start, but they dropped the balll big time, which makes supporting them much harder than it should be.

Re systemd, I finally found out what caused the drastic failures, I was reading something from I think runnit or s6 types, and they explained the issue more clearly than I'd ever read, systemd, in a foolish attempt to try to optimize and speed boottimes, parallelized so much that sometimes the system would hit a boot situation where it literally did not know even how to print out a console screen, it was totally jumbled. This was a design error that I think was finally fixed, but it took at least 10 years too long to fix it.

But systemd toolsl no, they are slow, badly designed, and not appropriate for inxi use, I've checked them now and then, I do use a tiny subset, for example, systemd is the first tool queried to see if it's a virtual machine for the -M report if it didh't detect it any other way, there's a tiiny handful of other systemd specific things, bluetooth status for instance on systemctl containing systems comes from systemd, and it's report is actually quite good, maybe the best one of all the init management tools I saw, the most useful data, so sometimes it's pretty good, I have to be fair.
 
ash-5.0$ ps -p 1
PID TTY TIME CMD
1 ? 00:00:00 init
bash-5.0$
init - i don't seem to have systemd nor wayland to my knowledge - i'm on slackware (not so current, current ) . I do try to read up though on stuff that has not got into slackware tree , (so far) such as wayland.

I always find this site entertaining : https://www.dedoimedo.com/computers/wayland-2021.html

unfortunately nearest i can get to inxi is something like lshw
 
unfortunately nearest i can get to inxi is something like lshw

Andy, a Google search under

slackware inxi

seems to indicate otherwise, have you tried any of that?

Actually DON'T answer that here, please, perhaps a separate thread. Don't want to sidetrack what Harald and Stan are working on.

Cheers

Wizard
 
Thanks, Chris, but I don't mind more comments here, if Harald doesn't. Our work is finished, at least for now, but I have been very much enjoying the conversation and knowledge and insights he is sharing with me... with all of us. :)

Andy, I think this below will work in Slackware to install the latest version of inxi... run the commands as root (or sudo) from inside /usr/local/bin so it will work from whatever directory you call it from.
Code:
# wget -O inxi smxi.org/inxi
# chmod +x inxi

If you install the above, it is easily updated as root/sudo with inxi -U.

I think the man pages were just updated... and they are EXTENSIVE, with many options available to tweak the inxi output. We were testing the development version (pinxi) but I would guess that the options are the same, or nearly so. Try inxi -zyv8 to see a lot of information about your system, if you decide to install it. Or, as the Wizard hinted, you may find Slackware packages available as well, if you prefer those.

And thank you again, Harald, for sharing so much with us. These backstories about bluetooth, bsd, wayland, and systemd, have all been very interesting to me! :)
 
Likewise Harald :)

As an inxi user for years, I have watched this with considerable interest.

Wiz
Avagudweegend
 
captain-sensible, as stan noted, all linux distros have inxi, and if it's not packaged, or not current, it's a simple matter to install it, then use -U to update it the first time, which will also install the man page when run as sudo/root. Slackware does seem to fit your nick, lol, sensible choice if it suites you, but don't forget about the good old tools like wget or curl, that's all you ever need to install inxi. I even package inxi for tinycore linux, now and then, when I feel like updating the package, lol.

The first thing I do when installing anything is:

as root:
Code:
cd /usr/local/bin
wget -O pinxi smxi.org/pinxi
chmod +x pinxi
chown h2:h2 pinxi

h2 is the username I use on my vm systems usually, so I try to always do it all the same so I don't have to think about what I used on each one. You're replace that with your own.

The latter is so I can update it easily, pinxi in my case because I only use the development version, for most users, that's inxi, unless they want the newest stuff always.

wizardfromoz, stan is right, the heavy lifting work is done, and this is how big stuff gets done, very intensive effort over short time, ideally with one or more others involved in whatever way suites them.

Just so it's clear, the reason I show great annoyance about certain things, like unreliable inconsistent BSD data, wayland with no data to speak of, etc, is that in actual fact, I _want_ inxi to be always right on everything, with complete data, and I find it super frustrating that people who are supposed to be good at what they do, at least in theory, fail so utterly to, well, be good at what they do. This makes my job MUCH MUCH harder, and for no reason beyond being unable to implement things that should just be common sense.

With this said, I remain fond of OpenBSD, their purity of vision, they total refusal to compromise core principles, I find very appealing, same reason I admire Slackware by the way.
 
stan, re the man page, it always gets updated as I do the changes in pinxi, they are co-developed, otherwise I'd never keep it up to date, that is, if I extend say, -Sxxx to show vt: virtual terminal number, as I did after realizing some stuff about old inxi shell data logic, as soon as I add the feature, I add it in the help menu and the man page, otherwise I can't remember the stuff. so all of pinxi is usually very reflective of what is coming next, unless I am testing a feature, decide I don't like it, or find something really wrong with it, and remove it, that's in pinxi, of course.

At the request of, in fact, a slackware user, there's the -U --no-man flag to keep inxi man from updating with -U, and the -U --man flag to make pinxi update man plus itself.

I am however, sadly, going to have to have to extend bluetooth ever further, nobody seems to have the tools installed, even though I added one, not as good as hciconfig, but in current bluez-tools in most distros, it still doesn't seem to be present in most systems, so I may have to dig even deeper, and try to inject some rfkill data, if that's even installed, which isn't always the case. This is why I put off bluetooth feature for some 5 years, if hciconfig was standard on all systems, not deprecated, inxi bluetooth support would be quite excellent out of the box, it's ok with bt-adapter, and just shows the hardware data without any of those, not super useful. At least rfkill shows users if their bluetooth is up or down, I think I will add that as a fallback, if not hciconfig, and if either bluetooth service down, or no bt-adapter, look for rfkill and at least see if bluetooth appears in its report. Not ideal, not good tools, sadly.
 
With this said, I remain fond of OpenBSD, their purity of vision, they total refusal to compromise core principles, I find very appealing, same reason I admire Slackware by the way.
I think Andy just became your friend for life! ;) He is one of our die-hard Slackers (in a good way, of course). :)

I am lucky in many ways to be content running "old junk" computers. I practically never use bluetooth, practically never use wayland, systemd has not caused any undue grief, and I more frequently use Ethernet instead of wireless (although I've had fairly good luck with wireless and Linux, but not so much with BSD).
 
Last edited:
captain-sensible, as stan noted, all linux distros have inxi, and if it's not packaged, or not current, it's a simple matter to install it, then use -U to update it the first time, which will also install the man page when run as sudo/root. Slackware does seem to fit your nick, lol, sensible choice if it suites you, but don't forget about the good old tools like wget or curl, that's all you ever need to install inxi. I even package inxi for tinycore linux, now and then, when I feel like updating the package, lol.

The first thing I do when installing anything is:

as root:
Code:
cd /usr/local/bin
wget -O pinxi smxi.org/pinxi
chmod +x pinxi
chown h2:h2 pinxi

h2 is the username I use on my vm systems usually, so I try to always do it all the same so I don't have to think about what I used on each one. You're replace that with your own.

The latter is so I can update it easily, pinxi in my case because I only use the development version, for most users, that's inxi, unless they want the newest stuff always.

wizardfromoz, stan is right, the heavy lifting work is done, and this is how big stuff gets done, very intensive effort over short time, ideally with one or more others involved in whatever way suites them.

Just so it's clear, the reason I show great annoyance about certain things, like unreliable inconsistent BSD data, wayland with no data to speak of, etc, is that in actual fact, I _want_ inxi to be always right on everything, with complete data, and I find it super frustrating that people who are supposed to be good at what they do, at least in theory, fail so utterly to, well, be good at what they do. This makes my job MUCH MUCH harder, and for no reason beyond being unable to implement things that should just be common sense.

With this said, I remain fond of OpenBSD, their purity of vision, they total refusal to compromise core principles, I find very appealing, same reason I admire Slackware by the way.
maybe i wasn't looking hard enough before - i just found it :

bash-5.0# slpkg -F inxi

Packages with name matching [ inxi ]

+==============================================================================
| Repository Package Size
+==============================================================================
slack inxi-20201016_e45c6960-noarch-1.txz 228 K
sbo inxi-3.0.37 0 K



but looks like latst release inxi is 3.3.03 so as usual slackbuilds.org are behind. Will have a look at slackbuild which evokes /sbin/makepkg to actually complete a pkg , that can of course cleanly install a package and cleanly remove it (the slackware way ) to build with latest src over next week probably


the slackbuild was short and simple (luckily) i used it with src inxi-3.3.03-1.tar.gz

..it built package inxi-3.3.03-noarch-1_SBo.tgz(which is more recent than at slackbuild.org) if any other slacker on here wants it- let me know ; i've installed it

inxi --help
//gives a lot of output , will play with it now over next few days

$ man inxi

//also working
 
Last edited:
Just as an aside, the reason -h actually helps you understand the options, is almost all from working with BSDs, where they seem to believe that putting in even the faintest hint beyond listing the physical options in a help menu is a great sin. I followed better examples, like rsync, when I designed the original help for inxi, those are help menus that actually help you, at the cost of being long.

The man page, likewise, is negatively influenced by bad incomplete almost useless man pages (I've seen some recently that literally had less information in them than the -h option!!!), that do not actually tell you what to do, and are likewise positively influenced by great, awesome man pages, like i3's, for example, where the man page actually has everything most users need to know to understand and use i3, all the primary configs, everything.

I was also influenced by nano's help menu and man page, for example [but mostly rysncs, except for not being alphabetical, which I cannot figure out why rysnc doesn't fix], and, as noted, every time I use a BSD, I am really annoyed at how little data they believe is needed to help, it's usually totally not helpful, and incomplete, and then when you go to the man page, it's too short too, and doesn't help much.

In a funny turn of events, the same guy who helped re-edit the rsync man page did the same for the inxi man page, though he doesn't like taking public credit for doing that. All current man page errors and bugs are my fault, not his, since it's evolved a lot since then.

For example, the -a / --admin data in inxi is complicated, it's a small area where I do not have to try to make stuff userfriendly, it's more technically accurate, uses the right terms, etc, and in the man page, those are almost all fully explained so you know what's going on, it's admin data, that is, not newbie data, though I think newbies can benefit from seeing what the system actually is made from and how that stuff works.
 
Last edited:

Members online


Top