Hello all, and thanks for all your replies.
I think many people have misunderstood my question.
More specifically:
Neofetch, screenfetch too, altough they display only the most important stuff.
If you want something like CPU-Z, its clone for linux is named CPU-X.
Here's a handy GUI tool that details all the essentials hardware information on your Linux system.
itsfoss.com
I made a screenshot of my hardware with hardinfo, it took less than 5 seconds?
View attachment 18340
+1 for Hard Info.
But for some reason, it shows up in the menu and on the desktop icon (if you create one) as "System Profiler and Benchmark." Why; just why?
Yes it's a real shame we don't have any way to check System Information...but wait...
https://gprivate.com/69idk
Htop comes to mind - available in most repositories
View attachment 18372
These are all nice tools, and I have already used htop, neofetch, and others like bpytop.
(I have never used hardinfo, which seems really nice, but it is unrelated to what I was asking for in this thread...)
I do not want a graphical tool or a command line tool to view system information myself.
This is not a end-user question, but rather a developer question.
I want a way to gather system information in an application that I will create.
This means that, I would either need to depend on another tool/package that gathers this information and dumps it as text in an easy to parse format (in this case, the post #2 is interesting, although I am not sure how easily and reliably parse-able are the outputs of these tools), or use a virtual file like
/proc/stat (the same way htop seems to work internally), or find a better way that I am not aware of.
Seeing that htop uses the
/proc/stat method, I am almost convinced this is the "main Linux way".
Unless they have chosen this method only because of compatibility across all Linux and Unix variants.
In any case, I am guessing the authors of htop know what they are doing.
But it seems a bit odd, because this process passes the data through a human-readable form, which is not required for the purpose of a piece of software. That means that, whatever part of the Linux OS feeds data to this
/proc/stat file, takes some numeric values (e.g. float, int, double, etc), formats them into a human-readable form (e.g. a text of "0.7535"), dumps them in the file stream, then the application reads the formatted text, and converts it back into a numeric value (e.g. float, int, double, etc) with parsing. And my point is that, there are many conversions being done in this process that are not really needed.
And my question was focusing on two areas:
1) Weather I am missing something big. Since almost all the responses refer to command line tools that dump the information to the console, probably not.
2) Whether it would be of any value to have this
/proc/stat file, and others like it, replicated in a binary format, where the information is not converted into human-readable formats, or at least be converted into a standard serialization format like JSON, where you can have labels for each value you read and don't have to guess what each value is, or need to refer to manuals. In essence, this is an OS API architectural question. I feel something like this would be of value, but then again I know little about the internals and the philosophy of Linux.
Most of these are command line tools, but the information is there.
lshw
hardinfo
dmidecode
lspci
lsusb
inxi
cpuinfo
glxinfo
Thanks for this list.
I will check which of those support machine-readable outputs, which is what I am really after.
Otherwise, my application could break on each an every update of these tools, which is not so great.
So far, the only tool I found that clearly supports machine-readable output is systemd.
Tools like apt don't appear to support that.
But I haven't search much yet.
I will check the ones above.
Although, another problem is that one would have to assume that these tools are installed.
And assumptions when it comes to software are not a good idea.
I guess, that's why htop uses virtual files instead.
@Beaver763987450, on the matter of system information, you could check this thread, particularly post #55:
Linux is not MS, like Italian is not English despite using the same alphabet.
In any case, the premise of your question is false ... there are numerous ways of easily deriving system information in linux operating systems. It's just a matter of learning ... but I expect you knew that one way or another
.
Yes, I have guessed there are many ways to retrieve system information.
I am trying to find the most reliable and efficient way possible, for software development purposes.
Perhaps my question could be posted in StackOverflow.
But these is an architectural part in it, that would probably require an article or a whole discussion to explain.
I don't have nearly as much knowledge as you about Windows. I did do a lot of poking around and know far more than a lot of people.
Linux Mint is similar enough to Windows that I don't feel completely lost, but a lot of things are VERY different. Commands that work in Windows Power Shell do not work in the Linux terminal. Most of my challenge has been translating what I'm trying to say from Windows to Linux. Actions in Windows are called something different in Linux. If I want to be clear about my question, I need to find out as much I can on my own so I can communicate what I'm trying to say to people who don't use Windows.
Yesterday I was trying to stop processes. In Windows, I would press Ctrl + Alt +Delete to open the Task manager. That doesn't work in Linux and Task Manager is foreign word is Linux. I can 'speak Windows'. I'm learning to 'speak Linux'. As I learn to 'speak Linux' better, things become more apparent. I can then communicate my problem to people who know Linux.
Right now I'm the same place I was when I began with Windows. I look up things every day.
As I said my knowledge isn't anything close to yours. But can say that I had to to understand that Linux is NOT Windows.
I think I am getting to know Linux very well in terms of end-user usage.
E.g., I manage headless Linux servers using terminal multiplexers and all the bells and whistles one can use from the terminal.
I don't know all the tools yet, but I know all of the tools I need.
But I don't think I have captured the design philosophy of the internals of Linux, nor the way Linux programs are encouraged to interact with the OS. I have seen some FreeBSD firewalls executing tasks by spawning external tools and passing command-line arguments. I saw tools like htop using the virtual files. I think, there are also some libraries (I think their extension is *.SO in Linux) that one can link to, but perhaps using those is harder for dealing with compatibility, and I haven't seen many examples of using those yet. And I am not sure what capabilities they offer. Perhaps retrieval of system-resource utilization information is not one of them (or management of installed packages for that matter).
The book: The Linux Programming Interface is also a great resource for systems programming.
Nice.
This books seems interesting!
From a first look, the method for retrieving CPU information suggested by it appears to be
/proc/stat.
But I haven't read it all yet.
But, I am starting to guess that linking against libraries (like *.SO files) is not very much encouraged or preferred.
Probably because of compatibility problems that may appear on each library upgrade.
From a first look, I don't think this book mentions *.SO files at all, but I might be wrong.
Calling methods from a *.SO file could prevent many of the problems I was trying to avoid (converting numerical values to text and back again), but probably it generates new sets of problems.
