On a side note, and not wanting to criticize the people that spend their time working on something like this, that UI is the main reason why I still use Windows and macOS. Light grey on a white background, dark grey on a that blue background, a black AMD logo on a dark grey background, the padding around the text inside boxes...
I feel bad saying this when it's a free tool, but it's a shame that open source projects struggle so much with UI stuff.
tvier [3 hidden]5 mins ago
That's just the theme the author is running. If you use a use a standard theme, you'll get a higher contrast text color.
The UI is pretty much a copy of CPU-Z's UI. The color scheme comes from the theme and you can use any theme you like, you don't have to use what the author uses.
amlib [3 hidden]5 mins ago
MacOS and specially Windows has their fair share of great and useful software with questionable UI/UX, this is far from a problem affecting only Linux.
Take a look at modern KDE and specially GNOME software, they are pretty well made regarding UI/UX best practices and GNOME even has a great HIG that they follow strictly on their stuff, you can't even say that regarding Microsoft own software anymore.
bb88 [3 hidden]5 mins ago
Gnome is not bad, but GTK has been historically a pain point for development.
XorNot [3 hidden]5 mins ago
I just people to do menu bars on desktop again.
Add the Jetbrains search anywhere function if you really just innovate.
the daemon separates userspace from root domain, and ensures that the code running with root privileges is very small and easily auditable
__turbobrew__ [3 hidden]5 mins ago
Maybe I am dumb, but why does it have to be a daemon? Why not have the user process fork off the privileged binary to collect data and return the results through stdout?
unaindz [3 hidden]5 mins ago
Forking a process is not free and starting one every hundred of a millisecond* seems very expensive. *I'm do not know which frequency it updates the data but it's usually 1 sec to 0.1 sec.
dmitrygr [3 hidden]5 mins ago
$ man dmidecode
preisschild [3 hidden]5 mins ago
At least in the Flatpak, it can be started by just clicking the "Start daemon" button.
whalesalad [3 hidden]5 mins ago
I use it without the daemon. I don't even know what the daemon does.
mmh0000 [3 hidden]5 mins ago
[flagged]
petabyt [3 hidden]5 mins ago
This tool does benchmarks and lists vulkan/opengl capabilities. It's a bit more than a glorified command line frontend.
Brian_K_White [3 hidden]5 mins ago
There are similar commands for those. It is exactly a bit more than a front end.
izacus [3 hidden]5 mins ago
This is absolutely "Who cares about Dropbox, just use rsync!" level of silly and lazy HN answer :D
jcelerier [3 hidden]5 mins ago
When I type all that (if I type them correctly, I do a lot of mistakes so I need simple icons to click sometimes), it really doesn't look like CPU-Z in my terminal, I wonder what I'm doing wrong?
Brian_K_White [3 hidden]5 mins ago
Those commands do provide the information. They never claimed it exactly matches the graphical layout.
And I don't think they are even claiming that a graphical presentation of the same info is necessarily wrong or pointless, they are simply saying, that's a lot of c++ for merely wrapping the text in some gui widgets.
It's a fair observation.
I can imagine generating say an html rendition that looks almost the same in a few k of shell. Maybe there's more to it and it wouldn't be so simple, but that is what it looks like.
jcelerier [3 hidden]5 mins ago
> Those commands do provide the information. They never claimed it exactly matches the graphical layout.
but that's the thing, the target audience for "CPU-Z for Linux" is not people who want the information (because if you do it's of course trivial to google and find out about /proc/cpuinfo), it's people who want to use a software which is as close as possible to the original CPU-Z (so HTML layout definitely does not cut it either).
> I can imagine generating say an html rendition that looks almost the same in a few k of shell.
considering that the source code assumes that dmidecode won't be present (it embeds it) I doubt you'd reimplement the whole dmidecode in only a few k lines of shell. And that's just a small part of what CPU-X does.
HN.zip
On a side note, and not wanting to criticize the people that spend their time working on something like this, that UI is the main reason why I still use Windows and macOS. Light grey on a white background, dark grey on a that blue background, a black AMD logo on a dark grey background, the padding around the text inside boxes...
I feel bad saying this when it's a free tool, but it's a shame that open source projects struggle so much with UI stuff.
From their wiki: https://camo.githubusercontent.com/04c2219de0884fc8e6bf4d264...
Take a look at modern KDE and specially GNOME software, they are pretty well made regarding UI/UX best practices and GNOME even has a great HIG that they follow strictly on their stuff, you can't even say that regarding Microsoft own software anymore.
Add the Jetbrains search anywhere function if you really just innovate.
No more Hamburger menus.
https://github.com/i-nex/I-Nex
https://gambaswiki.org/wiki/app/i-nex
https://gambaswiki.org/website/en/main.html
the daemon separates userspace from root domain, and ensures that the code running with root privileges is very small and easily auditable
And I don't think they are even claiming that a graphical presentation of the same info is necessarily wrong or pointless, they are simply saying, that's a lot of c++ for merely wrapping the text in some gui widgets.
It's a fair observation.
I can imagine generating say an html rendition that looks almost the same in a few k of shell. Maybe there's more to it and it wouldn't be so simple, but that is what it looks like.
but that's the thing, the target audience for "CPU-Z for Linux" is not people who want the information (because if you do it's of course trivial to google and find out about /proc/cpuinfo), it's people who want to use a software which is as close as possible to the original CPU-Z (so HTML layout definitely does not cut it either).
> I can imagine generating say an html rendition that looks almost the same in a few k of shell.
considering that the source code assumes that dmidecode won't be present (it embeds it) I doubt you'd reimplement the whole dmidecode in only a few k lines of shell. And that's just a small part of what CPU-X does.