Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lscpu for OpenBSD/FreeBSD

github.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Lscpu for OpenBSD/FreeBSD

#31

Post by X86BSD »

glandium wrote: post #29
X86BSD wrote: post #23

Earlier quoted context omitted.

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…

And Solaris has zones and I/O completion ports. So what?

Solaris is dead. Maybe you didn't get the memo?

And your comment has absolutely nothing to do with Linux or the Linux community.

Re: Lscpu for OpenBSD/FreeBSD

#32

Post by alyandon »

GalacticDomin8r wrote: post #30
alyandon wrote: post #28

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. 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 -…

> lscpu has predictable output compared to the dmesg.boot log file 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…

  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.
The initial blob of CPU info, sure. I never really argued otherwise other than to say the log file is unstructured data and the relevant CPU information is not grouped together.

  # grep -n CPUs /var/run/dmesg.boot
  21:FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
I don't have a ton of other FreeBSD machines handy to check. Is the number of cpus always line 21 of the dmesg.boot log? I mean sure, if it is there is some consistency there but that information isn't grouped with the other.

  And yes the extra info provided by lscpu is very irrelevant for nearly all use cases.
Maybe for your use cases? Seems a little presumptuous to declare what information is irrelevant for other people's use cases.

  Sure, but if your argument is that you can't easily do this without the reinvention of the wheel, I disagree.
That wasn't my argument at all.

Re: Lscpu for OpenBSD/FreeBSD

#34

Post by floatboth »

X86BSD wrote: post #31
glandium wrote: post #29

Earlier quoted context omitted.

And Solaris has zones and I/O completion ports. So what?

Solaris is dead. Maybe you didn't get the memo? And your comment has absolutely nothing to do with Linux or the Linux community.

Solaris™ is dead, but everyone calls illumos "Solaris" :D

Re: Lscpu for OpenBSD/FreeBSD

#35

Post by floatboth »

X86BSD wrote: post #23
gigatexal wrote: post #20

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…

To be fair, cgroups appeared before we got rctl/racct.

More actual disasters though: signalfd (https://ldpreload.com/blog/signalfd-is-useless), ALSA, wireless_tools/iproute2(ip command)/iw (was it SO HARD to just keep improving ifconfig?!), procfs/sysfs & udev.

Re: Lscpu for OpenBSD/FreeBSD

#36

Post by floatboth »

alyandon wrote: post #32
GalacticDomin8r wrote: post #30

Earlier quoted context omitted.

> lscpu has predictable output compared to the dmesg.boot log file 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…

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. The initial blob of CPU info, sure. I never really argued otherwise other than to say the log file is unstructured data and the relevant CPU information is not grouped together. # grep -n CPUs /var/run/dmesg.boot 21:FreeBSD/SMP: Multiprocessor System Detected: 4 CP…

Not always line 21. Some stuff can appear before CPU info — like hypervisor info and some weird errors:

    …
    SRAT: Ignoring memory at addr 0x80000200000
    VT(efifb): resolution 1024x768
    Hyper-V Version: 10.0.15063 [SP0]
      Features=0x2e7f
      PM Features=0x0 [C2]
      Features3=0xed7b2
    Timecounter "Hyper-V" frequency 10000000 Hz quality 2000
    CPU: AMD Ryzen 7 1700 Eight-Core Processor           (3000.00-MHz K8-class CPU)
    Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
    …
but it's always in the first part of dmesg.

Re: Lscpu for OpenBSD/FreeBSD

#38

Post by X86BSD »

floatboth wrote: post #35
X86BSD wrote: post #23

Earlier quoted context omitted.

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…

To be fair, cgroups appeared before we got rctl/racct. More actual disasters though: signalfd ( https://ldpreload.com/blog/signalfd-is-useless ), ALSA, wireless_tools/iproute2(ip command)/iw (was it SO HARD to just keep improving ifconfig?!), procfs/sysfs & udev.

If I logged on to a UNIX box, and ifconfig was not there I would install a real UNIX. Seriously I am not going to hunt down or figure out why basic UNIX tools, interfaces, or APIs are not there. I'm just going to write the OS off as a busted trash fire and fix it using the above fix.

Re: Lscpu for OpenBSD/FreeBSD

#39

Post by vogon_laureate »

floatboth wrote: post #37
vogon_laureate wrote: post #19

Earlier quoted context omitted.

you can use fstyp command https://www.freebsd.org/cgi/man.cgi?query=fstyp

doesn't recognize ZFS :D

"When the -u flag is specified, fstyp also recognizes certain additional metadata formats that cannot be handled using mount(8), such as geli(8) providers, and ZFS pools."

https://www.freebsd.org/cgi/man.cgi?query=fstyp

Post reply on HN