kernelwanderers/ocsysinfo

Basic, high-level and efficient CLI for discovering, outputting and parsing hardware information from the current system.

ocsysinfo's Issues

[BUG]: Follow up to 'Module not found (in discussions)

Describe the bug
"error opening libpython3.10.dylib"

To Reproduce
Simply running MacOS app with Python 3.12

Expected behavior
Run without errors :)

Screenshots

Platform (please complete the following information):

• OS: [macOS]
• Version Catalina 10.15.7

Additional context
Add any other context about the problem here.

[BUG]:

Describe the bug
Linux version not work on my asus x555l machine and throw an error:
Traceback (most recent call last):
File "main.py", line 13, in
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "PyInstaller/loader/pyimod02_importers.py", line 352, in exec_module
File "info.py", line 24, in
File "info.py", line 26, in AppInfo
File "info.py", line 15, in get_latest_version
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/_MEIZUp7tu/src/util/version.json'
[230178] Failed to execute script 'main' due to unhandled exception!

Platform (please complete the following information):

• OS: [LinuxMint 21.1]
• Version []

Proposal: Change the way MemoryType is obtained on Windows

My Windows laptop showed this:

─ Memory
  ├──  (Part-Number)
  │   ├── Type: Unknown
  │   ├── Slot
  │   │   ├── Bank: BANK 0
  │   │   └── Channel: ChannelA-DIMM0
  │   ├── Frequency (MHz): 2400 MHz
  │   ├── Manufacturer: 04CB
  │   └── Capacity: 8192MB
  └──  (Part-Number)
      ├── Type: Unknown
      ├── Slot
      │   ├── Bank: BANK 2
      │   └── Channel: ChannelB-DIMM0
      ├── Frequency (MHz): 2400 MHz
      ├── Manufacturer: 04CB
      └── Capacity: 8192MB

Corresponding source code：

https://github.com/iabtw/OCSysInfo/blob/da2632b192bd59ff094052326e1f1531da862982/src/dumps/Windows/win.py#L190

According to this link:

Many newer memories do not have a typenumber assigned.  This is- very much true of newer laptops.  THis has nothing to do with VBScript or PowerShell.

My output of wmic:

C:\Users\nemo>wmic memorychip get banklabel, manufacturer, partnumber, speed, MemoryType, SMBIOSMemoryType, devicelocator
BankLabel  DeviceLocator   Manufacturer  MemoryType  PartNumber  SMBIOSMemoryType  Speed
BANK 0     ChannelA-DIMM0  04CB          0                       26                2400
BANK 2     ChannelB-DIMM0  04CB          0                       26                2400

I don't quite know how to fix it without breaking current usage of wmi, but there maybe a solution.

[BUG]: libpython3.10.dylib (which was built for Mac OS X 11.7)

Describe the bug
when I run the app on MacOS 10.15.7 (19H1615) Catalina, it is not working and showing below output:

Last login: Thu Sep 14 18:01:26 on ttys000
/Applications/OCSysInfo.app/Contents/MacOS/OCSysInfo ; exit;
➜  ~ /Applications/OCSysInfo.app/Contents/MacOS/OCSysInfo ; exit;
[13047] Error loading Python lib '/var/folders/xp/8wys6y8s38g1jgc5v_p9nfp00000gn/T/_MEIBxy3R8/libpython3.10.dylib': dlopen: dlopen(/var/folders/xp/8wys6y8s38g1jgc5v_p9nfp00000gn/T/_MEIBxy3R8/libpython3.10.dylib, 10): Symbol not found: _preadv
  Referenced from: /var/folders/xp/8wys6y8s38g1jgc5v_p9nfp00000gn/T/_MEIBxy3R8/libpython3.10.dylib (which was built for Mac OS X 11.7)
  Expected in: /usr/lib/libSystem.B.dylib
 in /var/folders/xp/8wys6y8s38g1jgc5v_p9nfp00000gn/T/_MEIBxy3R8/libpython3.10.dylib

[Process completed]

python3 main.py
Traceback (most recent call last):
  File "/Users/mxninja/dev/os/OCSysInfo/main.py", line 5, in <module>
    main()
  File "/Users/mxninja/dev/os/OCSysInfo/src/main.py", line 24, in main
    or os.environ.get("DEBUG", "0") == "1"
       ^^
UnboundLocalError: cannot access local variable 'os' where it is not associated with a value

To Reproduce
Just run the application or run the command python3 main.py
...

Expected behavior
Showing the hardware

Screenshots
From the APP

From the SC

Platform (please complete the following information):

• OS: MacOS Catalina
• Version 10.15.7 (19H1615)

ocsysinfo.exe exits after launching on windows 10.

Failure to open application

The application appears to be failing to open due to dependency-related issues, which I have been able to replicate on two devices (both running Windows 11) with version 1.0.2 (versions 1.0.0 and 1.0.1 can launch properly on both devices).

The two failures appear to be originating from the src\util\missing_dep.py file (it's not fully clear to me if there may be something going on elsewhere).
The error on 1.0.2 (from Releases) states

Traceback (most recent call last):
  File "main.py", line 5, in <module>
ModuleNotFoundError: No module named 'src.util.missing_dep'
[38048] Failed to execute script 'main' due to unhandled exception!

and an error from a self-built executable (built from bd74915) stating

Package "requests" is not installed!
Package "dicttoxml" is not installed!
Package "distro" is not installed!
Package "xmltodict" is not installed!
Package "wmi" is not installed!
Package "pywin32" is not installed!

Do you wish to install the aforementioned missing packages? [y/n]: n
Exited successfully.
Traceback (most recent call last):
 File "main.py", line 22, in <module>
 File "util\missing_dep.py", line 52, in install_reqs
NameError: name 'exit' is not defined
[27728] Failed to execute script 'main' due to unhandled exception!

I have self-built the application using the same configuration used in Actions (Build Windows binaries), shown below:
https://github.com/kernelBPD/OCSysInfo/blob/bd74915b54c4eca3b9b9cd99b095c2449efc8845/.github/workflows/release.yml#L59-L63

*I am able to run/debug main.py via PyCharm, building from origin/main (commit at this time bd74915). I believe there may be an issue with the release pipeline that is causing this issue to occur.

If any more information is required, I will provide it in this thread.

[HELP WANTED] Implementations for platforms

There are a few features lacking on Linux platforms, most notably:

• Block device detection (storage devices); Solved: #13
• Memory (RAM) module detection; Solved: 64aa1bd
• Optimizations for hardware discovery

These aren't core features, besides the optimization, but they'd be nice to implement, so the information extracted is consistent, structure-wise; with a little bit of spid.

There's one feature that's lacking in Windows, and it's only complimentary to Input device detection:

• Precise "interface type" of each device (SMBus, PS2, I2C, HID, etc.) Solved with a0667d8 and d59f293

That's basically all for now. I'm simply putting this issue here so that each user is aware that we know it's missing. But we simply need time, and possibly help, to implement all these features.

However, @rvstry has taken it upon themselves to attempt to implement block device detection for Linux platforms, and to optimize the hardware discovery part. In the situation that they do, I will update this issue accordingly.

• Block device detection implemented in #13 - special thank you to @rvstry for choosing to implement block device detection.
• Memory (RAM) module detection implemented in 64aa1bd

Multiple issue caused by poor network connection

Proposal: add hints when pulling detailed information from Internet

I have a normal or maybe poor Internet connection, so it stuck here with no hints:

Maybe it's better to add some flashing words indicating which phase the script is working on?

[TRACKER]: Features to be implemented

As the base of this application continues to expand, and as it gets more and more complex overtime, I think opening up a “tracker” of sorts so that both users and potential contributors are very well aware of what is to (hopefully) be implemented over the years to come.

First off, let's get basic features, refactoring and further implementations necessary (or well, more-so “preferred”):

• (1.) Building an efficient and responsive TUI to toggle displaying particular data (GPUs, Device IDs, Connector types for input devices, etc.)

  • This would also include toggling data of particular groups/categories (CPU, GPU, Memory, ...)

  • Ideally, the TUI should be written in Rust, and it can then communicate with the Python codebase (using an event emitter, or something of the sorts) to tell the application what data to toggle on/off, and the device manager's methods would be called accordingly when needed.

  • However, if we, for whatever reason, decide to write the TUI in Python, there is an interop¹ already written in Rust for capturing key presses (and key combos, such as Ctrl + C), which should alleviate the concern as far as that subject is concerned. Otherwise, we would likely need to refactor the entire application to implement some adaption of curses.
  • Say the user toggles off the entire GPU category - the TUI would emit an event—which we'll arbitrarily name data_off—which the application would listen for, and remove the entire category from the device manager instance's info attribute. If the user toggles it back on, it should call the DM's (from hereon out, this is what I'll use to refer to the device manager instance) gpu_info() method.

• (2.) To quickly mention, the development team has been working on another project, whose purpose is to “pack” the core of this application (for hardware discovery) into a single, versatile library called PySysInfo². With this library, we could focus more on maintaining the core of OCSysInfo without bothering about retaining stability and hardware discovery. Here are some of the benefits of this approach:

  • More attention to pay to UI/UX design;

  • Makes the codebase a lot cleaner, more easy to preview, shorter, etc.;

  • We could eventually consider adapting a GUI version, which may or may not be detrimental, but this is still in discussion.

• (3.) Add detection for Display devices (resolution, which parent GPU it's attached to, refresh rate, model, etc.) — this would be rather convenient for our end-users, as I've seen a lot of individuals struggle to find the exact model of their monitor on the occasion.

• (4.) Implement codename detection for Apple ARM64 chips (M1, M1 Pro, M1 Max, etc.); this would be a hard-coded list, which we can gradually update as each new model comes around.

• (5.) Refactor CPU codename managers (for Intel and AMD) to pull from a hardcoded list instead of fetching them online (so that offline compatibility remains)

• (6.) Add detection for chipsets; this would be rather challenging, because I'm not entirely certain if Windows and Linux expose this information anywhere, but it is still worth looking into.

That is pretty much it for now, it is going to be a long journey, but I'm hoping they'll come around eventually.

I will be continuously updating this as features are implemented, or if there are any other features that may be useful which require implementations.

Footnotes

1. https://github.com/KernelWanderers/OCSysInfo/tree/main/interops ↩

2. https://github.com/KernelWanderers/PySysInfo ↩

v1.0.9-beta [BUG]: Not working on windows 10

Describe the bug
Open and close on windows 10 (clicking on it)
or show error messages when using Cmd

To Reproduce
Click to open or by Cmd

Expected behavior
Open menu with options

Platform (please complete the following information):

• OS: Windows 10