Testers needed: Manjaro Data Donor

[papajoke]

Output:

• L457 and L468 :
  round disk size: "size_gb": min_size // (1024**3)

• as “memory”, but round up
  15.30331039428711 → 16
  "ram_gb": math.ceil(psutil.virtual_memory().total / (1024**3)),

• Monitor:
  “model” ? why ? # for me to remove : commercial use

• graphics:
  - “vendor” ? why ? # for me to remove

• cpu - threads ? useful ?

• boot - uptime_seconds ? useful ?

• system - kernel
  for help OK, but for stats ! convert to package name version “6.6.54-2-MANJARO” → “66”
  or (best) for dashboard, in get_system_info()

  kernel = platform.release()
  if not "MANJARO" in kernel.upper():
      raise Exception("Only for manjaro")
  kernel = ".".join(kernel.split(".", 2)[:2])
  

• cli:

  "desktop": {
          "cli": "/bin/bash",
          "gui": "KDE Plasma",
  

  ok, but in my default session konsole, i use fish

---

Python code, a quick first look:

• list to tuple:
  L38, L103, L198

• get_compositor() use : “ps -eo comm”

• not use morse ! example :

    desktop = get_inxi_val(item, "#Desktop")
    if desktop:
       ...
    display = get_inxi_val(item, "#Display")
    if display:
        ...
  

  it’s:

  if desktop := get_inxi_val(item, "#Desktop"):
  if display := get_inxi_val(item, "#Display"):
  

• in get_desktop_info()

      "wayland"
       if os.getenv("XDG_SESSION_TYPE") == "wayland"
       else "x11"
       if os.getenv("XDG_SESSION_TYPE") == "x11"
       else "unknown"
  

  is (more pythonic) :

   {"wayland": "Wayland", "x11": "X11"}.get(os.getenv("XDG_SESSION_TYPE"), "unknown")
  

---

*“Only for manjaro” : server side, hard to verif if data is not a fake easy to generate a random “device_id”. Promote my desktop, my country, … or attack manjaro

FOR TEST : (re-)send (new machineid, kernel: 22.6 and 480Go ram), i can view this in dashboard
for remove it : "device_id": "18240054-b94c-5e43-8c55-9d7a044e8c15",

[andreas85]

@omano

//EDIT: for the OPT-IN, I guess the tool could be a “dependency” of Manjaro (with a service regularly collecting data), and a popup could ask user if he wants to help send data after installation on an update, and a reboot, and if user says NO, no more popup and disable the service collecting data regularly.

I have a system with 2 seats. Inxi detects both graphic-cards, but only one monitor is detected. (But both do work, and are on at this time)

sudo loginctl list-seats

SEAT 
seat0
seat1

if OPT-in i will OPT-in

if OPT-out i will OPT-out

[Aragorn]

@romangg

With this systemd service later in place, sending the hardware data with MDD will be opt-out because I believe, if you do opt-in, the data you gather will be so heavily skewed you can just leave it be.

While I understand your vantage, I firmly believe that it should be opt-in, rather than opt-out, even if only for ethical reasons.

Furthermore, having any kind of telemetry enabled by default and opt-out is — as you noted — a very contentious affair in this day and age, and especially so in light of big tech companies like Google, Canonical, Meta/Facebook and even Mozilla resorting to telemetry that is either opt-out or doesn’t even allow for opting out.

We’ve already had quite a few issues here at the forum over the past five years with members who wrongfully suspected that we already had telemetry enabled because of the ping, and from this experience, I firmly believe that having it enabled by default — even if only on new installs, not to mention pushing it out onto existing installations as well via an update — will come around to bite us in the hind side quite quickly and quite ferociously.

If anything, then past experiences have demonstrated that it doesn’t take a whole lot — as the matter of fact, a storm in a teacup is already enough — for Manjaro users to jump ship in droves and leave Manjaro for Arch proper, Endeavour OS, Garuda, or similar distributions.

I think this issue is worth serious contemplation, and especially so because @philm gave the members his word that any upcoming telemetry features in Manjaro would be opt-in only — which is also how KDE do it, by the way.

---

Additional note: Manjaro Metrics looks cool, but the “tooltips” when hovering over certain elements often fall outside of the browser window’s dimensions. Perhaps something to tweak a little?

[romangg]

@papajoke

FOR TEST : (re-)send (new machineid, kernel: 22.6 and 480Go ram), i can view this in dashboard

Haha, yea, I’m still in the process of filtering such things out server-side. My naive hope was that everybody would behave.

[omano]

It will be difficult for malevolent people to restrain themselves from injecting wrong data to screw up the data collection. Some security about that should be included if even possible.

@Aragorn

While I understand your vantage, I firmly believe that it should be opt-in, rather than opt-out, even if only for ethical reasons.

I don’t think it is a choice, it SHOULD be OPT-IN, you don’t collect data about users in Europe without consent.

[Aragorn]

@omano

@Aragorn

While I understand your vantage, I firmly believe that it should be opt-in, rather than opt-out, even if only for ethical reasons.

I don’t think it is a choice, it SHOULD be OPT-IN, you don’t collect data about users in Europe without consent.

True, that. I wasn’t even thinking about the GDPR when I wrote that.

[AlexBoldt]

Nice metrics, but I’m a little confused on how to interpret the core/thread diagram?

By the way, I agree with Aragorn… it should be opt-in. I think Linux users in particular are very sensitive when it comes to data collection.
I think there should rather be an introductory dialog during the installation or something like that, explaining the background and politely asking for consent.
More social engineering instead of technical engineering.
Just my two cents…

[Aragorn]

@AlexBoldt

I think there should rather be an introductory dialog during the installation or something like that, explaining the background and politely asking for consent.

For new installations, the opt-in could be made part of the manjaro-hello package.

For existing installations, it would be a little more difficult to implement an opt-in. Pushing it out as part of an update would bypass the required consent, so that’s a definitive no-no.

So then it would most likely just need to be implemented by way of an announcement — which wouldn’t reach everyone, even if only because most of the members only ever connect to the forum when they’re having a problem — and the voluntary installation of the systemd service.

[andreas85]

@Aragorn

Additional note: Manjaro Metrics looks cool,

Something seems to be wrong with the numbers for XFCE. I reported 5 machines/vms alone (and all of them have XFCE), but only 2 XFCEs appear on the website

[AlexBoldt]

I’m still trying to understand the core/thread diagram.
The numbers for cores >= 2*threads are clear. (for example 4 cores/8 threads). And core > threads are probably allocated virtual cores of VMs.
But e.g. 1 core with 9 threads?

PS: I know it’s not a competition…but we are leading…it’s so exciting

[romangg]

@andreas85

I reported 5 machines/vms alone (and all of them have XFCE), but only 2 XFCEs appear on the website

I promise it’s not a conspiracy against Xfce!

I just looked up the values in the database and I only see 4 entries from 2 different devices.

What is the output of mdd from your machines when you send it?

[romangg]

@AlexBoldt

I’m still trying to understand the core/thread diagram.

I admit it’s kind of confusing and maybe we should go for a different depiction. I wanted to show both: how many systems there are that have x threads independent of cores and on the other side the number of systems that have y cores in the same diagram.

Usually one thinks them together though, i.e. I have 12 cores and 24 threads.

But here a point x on the x-axis is just x cores or x threads and there isn’t a relation between them.

I just added a second diagram in the end that might be clearer. Can you take a look? It looks a bit less fancy though…

[andreas85]

@romangg

What is the output of mdd from your machines when you send it?

Summary

desktop xfce dual seat:

  "desktop": {
        "cli": "/usr/bin/zsh",
        "gui": "Xfce",
        "dm": "LightDM",
        "wm": "xfwm4",
        "display": "x11",
        "display_with": "Xwayland"
    }  "desktop": {
        "cli": "/usr/bin/zsh",
        "gui": "Xfce",
        "dm": "LightDM",
        "wm": "xfwm4",
        "display": "x11",
        "display_with": "Xwayland"
    }

server xfce (login via ssh)

"desktop": {
        "cli": "/bin/zsh",
        "display": "unspecified",
        "display_with": null
    }

laptop (login via ssh), greeter active, but no running xfce session

 "desktop": {
        "cli": "/usr/bin/zsh",
        "display": "unspecified",
        "display_with": null
    }

desktop single seat (login via ssh), greeter active, but no running session

 "desktop": {
        "cli": "/usr/bin/zsh",
        "display": "unspecified",
        "display_with": "Xwayland"
    }

vm (login via ssh)

 "desktop": {
        "cli": "/usr/bin/zsh",
        "display": "unspecified",
        "display_with": null
    }

vm (login via ssh), greeter active, but no running session

"desktop": {
        "cli": "/bin/bash"
    }

It seems, desktop is only detected, while a session is running for a user

[Teo]

I think you can do only with core number, without thread.

Indeed, GDPR. That solves it for the opt-in.

[romangg]

@andreas85 Hmm, I don’t see stuff obviously wrong here. Can you send me the whole output of at least two of your systems? If you want to per pm.

[nl.smart]

ARM, install done…

[nls@lap ~]$ ssh nls@127.0.0.1
nls@127.0.0.1's password: 
Welcome to Manjaro ARM
~~Website: https://manjaro.org
~~Forum:   https://forum.manjaro.org/c/arm
~~Matrix:  #manjaro-arm-public:matrix.org
Last login: Sat Nov  2 15:27:50 2024 from 127.0.0.2
[nls@c4 ~]$ date -u
sam. 02 nov. 2024 19:26:43 UTC
[nls@c4 ~]$ mdd
Welcome to MDD - The Manjaro Data Donor
Preparing data submission...
cat: /sys/devices/virtual/dmi/id/product_name: No such file or directory
cat: /sys/devices/virtual/dmi/id/product_family: No such file or directory
cat: /sys/devices/virtual/dmi/id/sys_vendor: No such file or directory
cat: /sys/devices/virtual/dmi/id/board_name: No such file or directory
Traceback (most recent call last):
  File "/usr/bin/mdd", line 744, in <module>
    main()
  File "/usr/bin/mdd", line 709, in main
    data = get_device_data(args.telemetry)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/bin/mdd", line 651, in get_device_data
    "cpu": get_cpu_info(),
           ^^^^^^^^^^^^^^
  File "/usr/bin/mdd", line 259, in get_cpu_info
    [
IndexError: list index out of range
[nls@c4 ~]$ 

[AlexBoldt]

Now I got it
And the confusing “Devices” on the X-axis is also gone.
Much easier to understand than before. Although I’m not sure whether the type of diagram is the optimal choice.

[cscs]

@omano

I don’t think it is a choice, it SHOULD be OPT-IN, you don’t collect data about users in Europe without consent.

Except apparently they already were since the implementation of counting via NetworkManager connectivity test.

@romangg

Until now what has been done, was counting systems via ping.manjaro.org . These pings are sent from Manjaro systems via the NetworkManager.

So manjaro was in breech of then?
Because this use was never disclosed.

This stands in stark contrast to the archlinux default.

Note: Although automatic connectivity checks are a potential privacy leak, Arch Linux’s default connectivity URL is committed to not logging any access. See [3] [4].

[AlexBoldt]

OMG…forget everything I said.
The new diagram was out of my screen

[cfinnberg]

@cscs

Except apparently they already were since the implementation of counting via NetworkManager connectivity test.

To be fair, I don’t think that counting pings can be considered “data collection”.