21–30 of 39 posts
This is cool don’t get me wrong but why Linux-ify the BSDs when you can just adapt to the BSD way and use already existing tools (many of which are mentioned in previous comments)?
FreeBSD has dmidecode https://www.freebsd.org/cgi/man.cgi?query=dmidecode So you can do: dmidecode -t processor -t cache which produces the following output on my system: # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0400, DMI type 4, 40 bytes Processor Information Socket Designation: CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: 52 06 02 00 FF FB EB BF Signature: Type 0, Family 6, Model 37, Stepp…
Obviously they should match, but if they don't, DMI is going to be the one lying.
FreeBSD has the dmidecode command https://www.freebsd.org/cgi/man.cgi?query=dmidecode eg. dmidecode -t processor -t cache which on my system produces the following output: # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0400, DMI type 4, 40 bytes Processor Information Socket Designation: CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: 52 06 02 00 FF FB EB BF Signature: Type 0, Family 6, Model 37, Step…
This is neat and all, but I'm not sure I understand how it's better than 'less /var/run/dmesg.boot'? Which is not to say that this doesn't have any merit, I just don't understand it.
A trivial inspection of my FreeBSD 11.1 system's /var/run/dmesg.boot shows that it doesn't contain all the information displayed by lscpu. So what's hard to understand? lscpu displays CPU information in a predictable, concise format whereas 'less /var/run/dmesg.boot' requires you to read through a log file that contains a subset of the same information that also happens to be interspersed among unrelated log entries?…
I'd argue that the reason you think lscpu is predictable and concise is that you're used to reading it.
FreeBSD has the dmidecode command https://www.freebsd.org/cgi/man.cgi?query=dmidecode eg. dmidecode -t processor -t cache which on my system produces the following output: # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0400, DMI type 4, 40 bytes Processor Information Socket Designation: CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: 52 06 02 00 FF FB EB BF Signature: Type 0, Family 6, Model 37, Step…
What about platforms that don't support DMI?
Earlier quoted context omitted.
A trivial inspection of my FreeBSD 11.1 system's /var/run/dmesg.boot shows that it doesn't contain all the information displayed by lscpu. So what's hard to understand? lscpu displays CPU information in a predictable, concise format whereas 'less /var/run/dmesg.boot' requires you to read through a log file that contains a subset of the same information that also happens to be interspersed among unrelated log entries?…
As far as I can see (and comparing with the output on the github page), the only thing missing from dmesg is the amount of cache and byte order within the first 20 or so lines. One depends on CPU purchase, the other depends on the ISA. Either way, they're not something I can do anything about even if I need to know them - which, most of the time, I don't. I'd argue that the reason you think lscpu is predictable and c…
As far as I can see (and comparing with the output on the github page), the only
thing missing from dmesg is the amount of cache and byte order within the first 20 or so lines.
One depends on CPU purchase, the other depends on the ISA. Either way, they're not something
I can do anything about even if I need to know them - which, most of the time, I don't.
I'd argue that the reason you think lscpu is predictable and concise is that you're used to reading it.
I actually based my statement on:
lscpu -> gives CPU information
less dmesg.boot -> contains CPU information mixed in with other log entries
lscpu -> fields have fixed fieldnames
less dmesg.boot -> unstructured log entries
In my world parsing output from command line tools that use predictable identifiers in their output is easier than parsing similar data out of unstructured logs.
This is cool don’t get me wrong but why Linux-ify the BSDs when you can just adapt to the BSD way and use already existing tools (many of which are mentioned in previous comments)?
What you ask is what many outside the Linux community are so annoyed and frustrated with. The Linux communities complete inability to look outside their echo chamber. Constantly reinventing the wheel poorly and in a broken screw portability way. Instead of hacking together cgroups and namespaces they should have simply ported the jail framework. Instead of epoll they should have simply adopted kqueue. All they see is…
Earlier quoted context omitted.
As far as I can see (and comparing with the output on the github page), the only thing missing from dmesg is the amount of cache and byte order within the first 20 or so lines. One depends on CPU purchase, the other depends on the ISA. Either way, they're not something I can do anything about even if I need to know them - which, most of the time, I don't. I'd argue that the reason you think lscpu is predictable and c…
As far as I can see (and comparing with the output on the github page), the only thing missing from dmesg is the amount of cache and byte order within the first 20 or so lines. Well, yes. A subset of the information and interspersed among unrelated log entries as I stated. One depends on CPU purchase, the other depends on the ISA. Either way, they're not something I can do anything about even if I need to know them -…
The CPU info appears in the same place each time, assuming no other changes took place. Even if something did it would effect only it's relative position.
And yes the extra info provided by lscpu is very irrelevant for nearly all use cases.
> In my world parsing output from command line tools that use predictable identifiers in their output is easier than parsing similar data out of unstructured logs.
Sure, but if your argument is that you can't easily do this without the reinvention of the wheel, I disagree.