Does inxi really contains something that can invade your privacy šŸ¤”?

Because they don’t want to get invaded in their privacy :joy:
I wonder , does inxi really contains something that can invade your privacy :thinking: ?
It’s just about hardware specs and your DE right ?
(sorry for OT)

1 Like

The output has been intentionally curated to not contain any sensitive information like addressing info or unique device identifiers. It only contains useful diagnostic info.

In fact, I’m not sure how many folks remember this but originally the output listed device vulnerabilities and relevant mitigation implementations. It’s part of the more verbose --cpu output. If you want to see what I am talking about, run:

inxi -Ca

We decided to remove that part, because we already have folks reluctant to provide the output for whatever reason, and thought maybe people who didn’t understand what that information was would be uneasy about sharing it. Plus, it has never once been useful for solving an issue on the forum.

The funny thing is, some of the people who are reluctant to share their inxi love sharing their neofetch output! I’m just thinking out loud here, but maybe if we incorporate some ASCII art into the garuda-inxi then people would be more forthcoming with providing their system’s diagnostic information…:thinking:

14 Likes

Then it will be put more on Screenshot of garuda linux thread than in issues :rofl:

1 Like

I was happy to see this.

inxi -Ca
CPU:
  Info: model: AMD Ryzen 5 5600X bits: 64 type: MT MCP arch: Zen 3+ gen: 4
    level: v3 note: check built: 2022 process: TSMC n6 (7nm) family: 0x19 (25)
    model-id: 0x21 (33) stepping: 2 microcode: 0xA20120A
  Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
    L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 3 MiB desc: 6x512 KiB
    L3: 32 MiB desc: 1x32 MiB
  Speed (MHz): avg: 2760 high: 3700 min/max: 2200/4650 boost: enabled
    scaling: driver: acpi-cpufreq governor: schedutil cores: 1: 2200 2: 3700
    3: 3700 4: 3059 5: 3261 6: 2200 7: 2473 8: 3081 9: 2200 10: 2200 11: 2846
    12: 2200 bogomips: 88797
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow mitigation: safe RET, no microcode
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
    prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
    STIBP: always-on, RSB filling, PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
2 Likes

We already have an easter egg in garuda-inxi, I can totally see this working out :laughing:

For those who didn’t know about it, try running it as follows: garuda-inxi funstuff :smiley:

7 Likes

needed

sudo pacman -S pacutils
5 Likes

i’m blind, i don’t see it.
but then again, i don’t know what to look for either lmfao and i installed pacutils to try and find it too >.>

/derp

1 Like

There are a couple ā€œbonusā€ lines at the bottom.

Hint: Failed units is usually the last line.

Spoiler
/usr/bin/garuda-inxi

[...]

if [ "$1" == "funstuff" ]; then
  update_count="$(paclog --grep="starting full system upgrade" | wc -l)"
echo -e "${c_134}  Total system updates:   ${c_off} ${update_count}"
echo -e "${c_134}  --> Updates per week:   ${c_off} $(( ${update_count}/(($(date +%s) - $(date --date="$install_date" +%s) )/(60*60
fi
4 Likes

image

Since electricity has become so expensive, I don’t use this computer that often anymore :frowning:

:wink:

2 Likes

yeap, in my face and i don’t see it lmfao thank you

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.