I do a fair amount of work to keep OpenBSD and FreeBSD (+derived versions) working reasonably well, though the BSDs will probably never have the depth of data I can generate for GNU/Linux systems.
I can't comment on OpenBSD's views of security since they are whatever they are, and I tend to respect OpenBSD's views on security above everything else out there, and greatly appreciate their ongoing contributions to global internet security (OpenSSH, LibreSSL). I have no idea how they view things like inxi, but inxi is Perl, and uses programs that are found in the system running inxi, so it's no more or less secure than Perl or the programs it runs. If you have dig installed, which I believe is a default on the BSDs, the WAN ip data would come from dig, not an HTTP IP tool, which is the fallback.
Note that I have given up and drawn a line of support after seeing the huge differences between say an OpenIndiana and one of the main BSDs like OpenBSD, FreeBSD, NetBSD (+variants), it's a question of diminishing returns plus man hours of dev time vs user per variant in the end, so I finally decided to just focus on the 3 main BSDs and just make sure the other unixes don't crash or show errors, and call it good there. Further note that NetBSD so far has stumped me so I haven't done any testing on it yet beyond very basic stuff.
ports
I think an inxi port was made a while ago, but never updated, by GhostBSD, technically speaking, there's very little reason to create different ports between the various BSDs, it's all the same program running, so I would expect 1 port cross BSD family should work assuming man pages go in the same place on each BSD variant (that is, why reinvent the wheel, one port should work for everything unless there are bigger differences between the 3 bsds than I am aware of, which is probable).
Download/install shortcuts
I have made redirect shortcut urls at smxi.org/inxi and dev version smxi.org/pinxi that redirect to the actual full long github repo url, so even if I get off of github, the shortcuts will just be changed to point to the new repo files. There's also direct download links if your downloader can't handle redirects.
Note that inxi has a self-updater in it, -U, so it's not particularly difficult to install it once, then use the -U option to update from then on. It is, as noted, a single file, or two, if you include the man page.
This will pull in the github inxi plus the github man, unless you specificy the --no-man option, which will not get the man page as well on update.
csh: no problems
Note that in the following examples, the FreeBSD one is running in csh, and there are zero issues. Nor should there be any, the only thing that uses the shell is the initial start command you run, and whatever the default user shell is for subshells internal to inxi.
Further note that I test on a network of FreeBSD boxes remotely always during pinxi/inxi development, and did every step of the way during the relatively recent refactor to Perl5, and in fact, I had the great good fortune that those boxes were running older FreeBSDs, then moved to newer FreeBSDs, during the development process, so I was able to get all the stuff working and tested on several major release variations of FreeBSD. Always running csh as default shell.
BSD development challenges
My time on BSD dev necessarily is limited to the machines I have direct access to, which is one reason FreeBSD support tends to be better than OpenBSD (though I spent a fair amount of time enhancing OpenBSD support over the last 6 months, ongoing process...), and there's actually more OpenBSD data collected internally than is being used for output (battery data, sensors data) because those are very difficult to implement to create consistent output. Always easy to create human readable output, not so easy to have automated reading 'understand' the various strings involved in that.
There are always challenges in the process, for example, I saw on GarryR's example that OpenBSD has just changed in vmstat the column count and order, as well as changed a KiB integer value for fre/avm to a human readable M MiB value, including the M character, which of course broke inxi's BSD memory tool. So the ability to support the BSDs is always a bit harder than it should be due to this type of change year over year. But I do try.
For example, the development version of inxi, pinxi, now has the memory issue corrected.
Data sources
I use dmesg.boot a bit for BSD data, but it's by no means the primary tool, in fact, I'd say it's maybe 3rd on the list of where the data comes from. That is, if I run inxi on a system where I don't have read privileges for dmesg.boot, I still get a pretty full report.
As soon as you get into the reality of trying to do these type of blends of data from different sources, the idea of reading a single data source starts to get quite a bit less attractive in my view.
The thing that has puzzled me the most is the inability to get from a file the actual current CPU speeds, per core, or just anything, in the BSDs, something like /proc/cpuinfo, that is, or /sys/.../current_freq type data.
With this said, the set of data sources i have available on the BSDs is significantly smaller than the set I have available in GNU/Linux, and that's just a reality, though I'm always happy to extend within reason the tools used as long as it doesn't take too much work (or too many lines of code), and has reasonably reliable syntax and structure - another thing that, as we see with the OpenBSD 6.1 to 6.3 vmstat changes, simply can never be assumed.
I wish it could be, but experience has shown me it can't, so that's what I have to handle, for instance, to handle just this single OpenBSD vmstat change, I had to full refactor the memory tool to dynamically detect which columns fre and avg are, then I had to detect if the values contain an M, then do the math on this, and this is just for one single BSD between 2 versions of the same major version set (6.x), so it's a challenge.
OpenBSD with root
Here's current latest pinxi/inxi full data plus filters, you can see the variations between FreeBSD and OpenBSD (though there would be a bit more data available if the OpenBSD was on bare metal, not a vm).
A few key things stand out on this system, first, I can't match the Network Device to the IF that belong to it, or the IPs attached to that IF. I can do this on the FreeBSD example below. This is subtle unless you understand what inxi is actually telling you here (IF-ID-x means that it had an IF that it could not match to a device).
Code:
System: Host: obsd63.my.domain Kernel: OpenBSD 6.3 amd64 bits: 64 compiler: N/A Desktop: FVWM 2.2.5 dm: xenodm
OS: OpenBSD 6.3
Machine: Type: N/A Mobo: innotek model: VirtualBox v: 1.2 serial: N/A uuid: 0cc3b369-0563-45c1-9389-6dccdbd1ca99
BIOS: innotek v: VirtualBox rev: 2.5 date: 12/01/2006
Battery: Unknown-error: dmidecode was unable to generate data
Memory: RAM: total: 1007.9 MiB used: 97.0 MiB (9.6%)
RAM Report: unknown-error: dmidecode was unable to generate data
PCI Slots: Unknown-error: dmidecode was unable to generate data
CPU: Topology: Single Core model: AMD Ryzen 5 2600 bits: 64 type: UP arch: N/A family: N/A model-id: N/A
stepping: N/A microcode: N/A L2 cache: N/A
Speed: 3400 MHz min/max: N/A Core speed (MHz): No speed data found for 1 cores.
Features: N/A
Vulnerabilities: No CPU vulnerability/bugs data available.
Graphics: Device-1: InnoTek VirtualBox Graphics Adapter driver: N/A bus ID: 0:2.0 chip ID: 80ee:beef
Display: server: X.Org 1.19.6 driver: vesa alternate: vboxvideo resolution: 1024x768~61Hz
OpenGL: renderer: Gallium 0.4 on softpipe v: 3.3 Mesa 13.0.6 compat-v: 3.0 direct render: Yes
Audio: Device-1: Intel 82801AA AC97 driver: N/A bus ID: 0:5.0 chip ID: 8086:2415
Network: Device-1: Intel 82540EM driver: N/A port: N/A bus ID: 0:3.0 chip ID: 8086:100e
Device-2: Intel 82371AB Power type: network bridge driver: N/A port: N/A bus ID: 0:7.0 chip ID: 8086:7113
IF-ID-1: em0 state: active speed: 1000baseT duplex: full-duplex mac: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
WAN IP: <filter>
Drives: Local Storage: total: 15.62 GiB used: 943.6 MiB (5.9%)
ID-1: /dev/wd0 vendor: VirtualBox model: VBOX HARDDISK size: 15.62 GiB serial: N/A
Optical-1: /dev/cd0 vendor: VBOX model: CD-ROM rev: 1.0 dev-links: N/A
Features: speed: Ultra-DMA mode 2 multisession: N/A audio: N/A dvd: N/A rw: none state: N/A
RAID: Message: No RAID data was found.
Partition: ID-1: / size: 551.1 MiB used: 62.0 MiB (11.2%) fs: local dev: /dev/wd0a label: N/A uuid: N/A
ID-2: /home size: 3.76 GiB used: 18 KiB (0.0%) fs: local dev: /dev/wd0k label: N/A uuid: N/A
ID-3: /tmp size: 767.2 MiB used: 14 KiB (0.0%) fs: local dev: /dev/wd0d label: N/A uuid: N/A
ID-4: /usr size: 1.26 GiB used: 691.5 MiB (53.6%) fs: local dev: /dev/wd0f label: N/A uuid: N/A
ID-5: /usr/X11R6 size: 618.8 MiB used: 177.7 MiB (28.7%) fs: local dev: /dev/wd0g label: N/A uuid: N/A
ID-6: /usr/local size: 2.17 GiB used: 6.8 MiB (0.3%) fs: local dev: /dev/wd0h label: N/A uuid: N/A
ID-7: /usr/obj size: 3.27 GiB used: 2 KiB (0.0%) fs: local dev: /dev/wd0j label: N/A uuid: N/A
ID-8: /usr/src size: 1.41 GiB used: 2 KiB (0.0%) fs: local dev: /dev/wd0i label: N/A uuid: N/A
ID-9: /var size: 1.11 GiB used: 5.6 MiB (0.5%) fs: local dev: /dev/wd0e label: N/A uuid: N/A
ID-10: swap-1 size: 904.5 MiB used: 0 KiB (0.0%) fs: swap dev: /dev/wd0b label: N/A uuid: N/A
Unmounted: Message: No unmounted partition data found for this BSD system.
USB: Hub: 0-1:1 info: Apple OHCI root hub ports: 12 rev: full speed chip ID: 0000:106b
Sensors: Platform: No Openbsd support. Is a comparable sensors tool available?
Repos: OpenBSD pkg mirror: /etc/installurl
1: https://cloudflare.cdn.openbsd.org/pub/OpenBSD
Info: Processes: 46 Uptime: 6h 04m Init: init (BSD) v: N/A Compilers: gcc: 4.2.1 clang: 5.0.1 Shell: ksh
pinxi: 3.0.26-20
FreeBSD remote server with restricted permissions
This example is useful to demonstrate just how little data comes from dmesg.boot, just the cpu flags, and the disk data.
Code:
pinxi -v8 --no-host -zy80
System:
Kernel: FreeBSD 10.4-RELEASE-p12 amd64 bits: 64 compiler: clang v: 3.4.1
Console: tty 0 dm: N/A OS: FreeBSD 10.4-RELEASE-p12
Machine:
Permissions: Unable to run dmidecode. Are you root?
Battery:
Permissions: Unable to run dmidecode. Are you root?
Memory:
RAM: total: 23.98 GiB used: 22.94 GiB (95.7%)
RAM Report: permissions: Unable to run dmidecode. Are you root?
PCI Slots:
Permissions: Unable to run dmidecode. Are you root?
CPU:
Topology: 8-Core model: Intel Core i7 930 bits: 64 type: MCP arch: N/A
family: N/A model-id: N/A stepping: N/A microcode: N/A L2 cache: N/A
Speed: 2800 MHz min/max: 1600/2801 MHz
Core speeds (MHz): No speed data found for 8 cores.
Features: dmesg.boot permissions
Vulnerabilities: No CPU vulnerability/bugs data available.
Graphics:
Device-1: Matrox Systems MGA G200eW WPCM450 driver: vgapci bus ID: 0:8:4.0
chip ID: 102b:0532
Display: server: No display server data found. Headless machine? tty: 102x40
Message: Unable to show advanced data. Required tool glxinfo missing.
Audio:
Message: No Device data found.
Network:
Device-1: Intel 82574L Gigabit Network driver: em port: N/A bus ID: 0:6:0.0
chip ID: 8086:10d3
IF: em0 state: active speed: 1000baseT duplex: full-duplex mac: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
IP v6: <filter> scope: link
IP v6: <filter> scope: N/A
IP v4: <filter> scope: N/A broadcast: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
IP v4: <filter> scope: N/A broadcast: <filter>
Message: Output throttled. IPs: 435; Limit: 10; Override: --limit [1-x;-1
all]
Device-2: Intel 82574L Gigabit Network driver: em port: N/A bus ID: 0:7:0.0
chip ID: 8086:10d3
IF: em1 state: no mac: <filter>
WAN IP: <filter>
Drives:
Local Storage: total: dmesg.boot permissions used: 631.50 GiB
Drive Report: dmesg.boot permissions
Optical Report: dmesg.boot permissions
RAID:
Device-1: tank type: zfs status: ONLINE size: 1.81 TiB free: 1.20 TiB
allocated: 628.00 GiB Components: online: ada2 ada1 ada3
Device-2: cache type: zfs status: no-status raid: no-raid size: 25.90 GiB
free: 1.17 GiB Components: online: ada0s2
Partition:
ID-1: / size: 53.27 GiB used: 26.91 GiB (50.5%) fs: ufs dev: /dev/ada0s1a
label: N/A uuid: N/A
ID-2: /usr/boxes size: 1.43 TiB used: 296.82 GiB (20.2%) fs: zfs
raid: tank/boxes label: N/A uuid: N/A
ID-3: /usr/home size: 1.26 TiB used: 116.68 GiB (9.1%) fs: zfs
raid: tank/home label: N/A uuid: N/A
ID-4: /usr/public_ftp size: 1.15 TiB used: 2.57 GiB (0.2%) fs: zfs
raid: tank/public_ftp label: N/A uuid: N/A
ID-5: /usr/www/users size: 1.29 TiB used: 150.63 GiB (11.4%) fs: zfs
raid: tank/www-users label: N/A uuid: N/A
ID-6: /usr/wwws/users size: 1.14 TiB used: 35 KiB (0.0%) fs: zfs
raid: tank/wwws-users label: N/A uuid: N/A
ID-7: /var/mail size: 1.18 TiB used: 36.12 GiB (3.0%) fs: zfs
raid: tank/var-mail label: N/A uuid: N/A
ID-8: swap-1 size: 5.00 GiB used: 1.75 GiB (35.0%) fs: swap
dev: /dev/ada0s1b label: N/A uuid: N/A
Unmounted:
Message: No unmounted partition data found for this BSD system.
USB:
Missing: Required tool usbdevs not installed. Check --recommends
Sensors:
Platform: No Freebsd support. Is a comparable sensors tool available?
Repos:
BSD ports server: /etc/portsnap.conf
1: portsnap.FreeBSD.org
FreeBSD update server: /etc/freebsd-update.conf
1: update.FreeBSD.org
BSD enabled pkg servers in: /etc/pkg/FreeBSD.conf
1: pkg+http://pkg.FreeBSD.org/$ABI/quarterly
Processes:
CPU top: 5 ( 4 processes)
1: cpu: 0.0% command: sshd: pid: 89410 mem: 4.54 MiB (0.0%)
2: cpu: 0.0% command: -csh pid: 89415 mem: 2.51 MiB (0.0%)
3: cpu: 0.0% command: pinxi started by: perl pid: 99104 mem: 21.6 MiB (0.1%)
4: cpu: 0.0% command: ps pid: 99109 mem: 1.70 MiB (0.0%)
Memory top: 5 ( 4 processes)
1: mem: 21.6 MiB (0.1%) command: pinxi started by: perl pid: 99104 cpu: 0.0%
2: mem: 4.54 MiB (0.0%) command: sshd: pid: 89410 cpu: 0.0%
3: mem: 2.51 MiB (0.0%) command: -csh pid: 89415 cpu: 0.0%
4: mem: 1.70 MiB (0.0%) command: ps pid: 99109 cpu: 0.0%
Info:
Processes: 4 Uptime: 28d 18h 55m Init: init (BSD) v: N/A Compilers:
gcc: 6.4.0 clang: 3.7.1 Shell: csh v: 6.20.00 running in: tty 0 (SSH)
pinxi: 3.0.26-23
The present and future
These changes in pinxi 3.0.26-2x will be turned into next inxi, 3.0.27, shortly, for example.
I like to maintain BSD support to the best level I can given time/energy constraints, but it is difficult, and particularly so given the key and or minor differences between variants, and even between the same OS but between releases of that OS.
In terms of raw man hours / energy, I think I probably spend about 10x more on the BSDs than I 'should', but I feel it's important to maintain as much support as I can, it's always been something I considered valuable even if nobody else does.
In terms of the reality of development between BSDs and GNU/Linux, I can tell you that I'm using /sys data more and more, along with always having used the /proc files, and that's one reason that in some areas, Linux support is expanding much more rapidly than BSD support, the data is simply not there in the BSDs as far as I can tell. This becomes particularly important with ARM features, which are in inxi almost exclusively coming from /sys data now, that is, there is no ARM support beyond super basic things for the BSDs, nor do I see any way forward in that regard since all the data is coming from /sys or /proc.