Proposal: Slightly tweaked version of inxi-gui

Forum Forums antiX-development Development Proposal: Slightly tweaked version of inxi-gui

  • This topic has 47 replies, 7 voices, and was last updated Feb 20-7:25 pm by h2.
Viewing 3 posts - 46 through 48 (of 48 total)
  • Author
  • #129292

      Dear Wallon – I do not intend to further change inix-gui – I spent a lot of time with it in the last days, and all I intended to do was a simple cosmetic change.
      I even added a space after “Save” and “Close” to make it easier for translators. I recommend using it as is and inserting a comment in the localization file, stating that the parts with the icon names should not be changed.
      I went trough hoops to make sure that those 3 buttons could be localized. I won’t spend more effort on them, sorry.


      Brian Masinick

        @PPC You did excellent work on inxi GUI. I found the version in /use/local/bin this morning and it looks good and functions well. I agree with you. It’s helpful as it is. Anything else should come from people using the standard tools throughout the system, which are very good and do everything.

        Congratulations on another valuable tool!

        Brian Masinick


          Just a bit of w warning: block devices are very tricky to get right, and a one liner, or set of them, is not going to work.

          I have to add modifications, file system filters, etc, all the time. The main inxi block devices logic is spread out across RAID, Logicial, Drives, Partitions, Swap, and Unmounted. These all share data to some degree.

          Trying to replicate this to me is not worth it, though you can generate some simple rules that will catch many to most of primary block devices,
          ls /dev/{sd,hd,nvme,mmc}*
          but it’s not easy and I would not try it. nvme in particular is tricky because it’s a fundamentally different type of storage, which uses fundamentally different access methods, and which the kernel sees in a sort of hybrid between RAM and Drive storage. NVMe also uses different tools, different ways to identify individual physical devices, etc.

          df -h -T is good however to see the raw current mount data, as is mounts and lsblk, though lsblk uses cached data and is not reliable for live systems. If I was going to use 1, for raw data, however, it’s df -hT, that’what inxi uses, plus some extra exclude and filter options, as well as output width switches. Plus /proc/partitions.

          I may one day migrate most of this logic to /sys block device data sources but that would require rewriting way too much code so I leave it alone for the time being.

          When you get to any type of overlay, remote, networked, distributed, etc, file systems all bets are pretty much off. inxi uses white and black lists for those.

          Just as an aside, the more options, and in particular the more granular options, you present users, the lower the odds of them seeing any of them. The brain just sort of switches off once the number or complexity or granularity is too high. So you want the fewest possible to achieve the purpose.

          And yes, I am wincing at the verbosity of verbose inxi output levels and modes, but either I stop making feature requests myself, and stop accepting any, or it just has to sail on its own path, and yes, inxi itself suffers now from too many options, and peopole not learning what it can do, and thus replicating what it does in awkward ways.

          Commonly missed ones: inxi -J [–usb] – of all the big new features brought in with 3.0.0, this has to be the most unknown one, but the most useful since otherwise it’s very hard to actually see how your USB buses actually work. As I found when I had thought that my mobo lied about its usb 3 bus, not realizing that all usb 2 devices tunnel to the nearest usb 2 hub, so it might appear that your entire board has only one bus, with odd mixtures of usb 3 hubs tossed in.

          The hardest by far to do was the -L/–logical, which is essentially unknown, though you can see bits of it running with the similarly redone RAID report.

          The failure to get those two options, particularly –usb, is I think one thing that made me roughly stop adding new primary line features, and focus instead only on upgrading existing features, and extending them.

          Having something like an inxi-gui is a good idea for support though, one click, making it easy for users to provide system data makes it more likely they will.

          • This reply was modified 5 months ago by h2.
        Viewing 3 posts - 46 through 48 (of 48 total)
        • You must be logged in to reply to this topic.