Perhaps you could default it to –dry-run then it would be easy to remove this if required?
Telemetry should always be viewed very critically, especially in times of NIS2 / CRA / GDPR and some other regulations. As a developer, I can understand the desire for it, but please ALWAYS with the active consent of the user!
The type of data plays absolutely no role, it’s about something very fundamental, my computer and whether it sends data or not, should ALWAYS be left up to the user, because if I didn’t care, I could just stay with Windows, where unfortunately more trackers are running than applications actually used, but that’s a different topic.
I don’t understand what the problem with Opt-IN is, just put it as another button in Manjaro Hello (that’s how you can help us…), be transparent, offer individual setting options (i.e. update frequency, auto feature if necessary, or pop-up window…) and put everything that is sent directly on the desktop as a copy.
Since the machine ID is unique in the best case, I don’t have to send it every day, but 4 times a year or every month would be enough, for example, and you could also create statistics about the things being used.
If the metric is more up to date, i.e. every day, like at the moment, this is almost like a monitoring system and that is something completely different than just collecting a few pieces of information about what kind of machines we use Manjaro on.
For a good comparison, take a look at the annual Steam hardware survey, where I am also asked every year whether I want to take part and the data is displayed before sending so that I can check it and then send it with another click. (Your script doesn’t do that by default)
In other words, ask first → am I even allowed to collect?
If YES.…collect at time x and then ask before sending
→ look, what I’ve collected, can i send it out?
Something like this would bring much more acceptance, and if you then report afterwards on what practical advantage it has brought you and thank everyone who took part, acceptance will probably increase even further.
The sovereignty over the behavior of the telemetry/monitoring/etc should always lie with the user, because this is the only way he can make his own free decision according to his own free will.
11 Likes
It’s real time.
It was pitch black in the Far East, but when I sent the message a small dot lit up in Japan.
There aren’t many users in Japan? 
By the way, what does this date indicate?
This manjaro is at least 5 years old.
"install_date": "2023-12-25T08:38:28+00:00",
1 Like
It should indicate when the system was installed. For that the script executes stat -c %W /.
This gives the “birth” of the root directory in seconds since Epoch.
What does stat -c %w / (small w) give you?
1 Like
The problem is the following: For every daily active user in our forums we have according to our current counting methodology over 1,000 users of our distribution who don’t interact with us in any way.
And that’s their good right. I have brought family members and friends to Linux who I’m certain won’t ever contribute in any way to open source or even understand what this is all about. It’s great to have you guys here in the forum be engaged and help the project, but MDD is not about people like you or us.
It’s about the hundred of thousands of other Manjaro users. They will build the statistical pool of significance for MDD as they are much more than us here in the forum.
Now asking these users to opt-in could be done through some technical means, but as I tried to just describe this population, imagine somebody different than us, somebody who doesn’t know much about software, maybe even not know that he or she uses Manjaro.
Now suddenly out of nowhere a random popup is grabbing the attention asking for something the user might not understand but definitely something he did not ask for right now. How should he react? Does he really want to read a long explanation why he should click “yes” here? If he only ever uses Manjaro to get his computing needs done without much other involvement?
I think such a popup is user hostile - at least for the users who are not involved with Linux more than they need to, and these are, according to the numbers we have until now, the absolute majority.
Or put it another way: of our many thousand current users my assumption is less than 1% mind if this impersonal data is being shared with us and put into some nice diagrams. Why should >99% of users have to interact with some popup and consider an action instead of the <1% who are actually interested in it and then act accordingly?
The other option is to put this opt-in button somewhere in the settings and ask through our social media channels or other means to activate it. The result will be that we again only can statistically cover the people who are already engaged with us.
When I think of me as a user of other software: what I want from this software is not getting annoying popups asking me to do stuff or decide things. I want my stuff get done. But what I also don’t want is for the software to spy on me, collect personal information and cross-share this with other companies. We do nothing at all like this here. Not in the slightest. And that’s why I’m also on a personal level fine with making this opt-out.
1 Like
I see. I understand.
This partition has been restored many times (by DD)
and has been repeatedly converted from ext4 to btrfs and btrfs to ext4.
It should NOTHING ! What’s wrong with you @manjaro trying to “invent” this telemetry-BS ???
And for your notice @romangg !!! manjaro is seated in germany and has to strictly follow the rules for data-security-laws as it is a GmbH ! You don’t ! Get serious ! It’s a shame how you disrespects the basic and fundamental rules of all our linux-community !
1 Like
For … reasons … prompted by questions asked here in the forum
I decided to install Fedora (Workstation) in a VM.
They install the system - and on first boot have the user configure it, personalize it.
(different than how the Manjaro and most other installers do it - which do that work during the initial install)
One of the first questions they ask is whether to share some data on usage and such.
They don’t even go into detail what that shared info will be.
It is a switch, turned to “on” by default.
If the person doesn’t turn it off, it stays on.
I’m aware that this is quite different than retroactively introducing this question into every already installed Manjaro system.
It should always be opt-in - in whatever context the question is presented to the users.
My analogy is whether to be an organ donor in case something happens:
I’d like it to be opt-in rather than opt-out.
Most people don’t and won’t care to think about that situation - and what the default is if they didn’t say anything matters - with opt-out by default many will get something they wouldn’t actually have wanted as a result.
Germany (where I’m from) is currently opt-in.
But “they” want to change it to opt-out - which is common in many if not most of the European states.
… essentially forcing the people to deal with the question - or subject them to the new default …
not good IMO
and:
I think you are overreacting @Olli 
3 Likes
That’s the point,
and that is what a USER could and should expect from a trustfully software!
Further take a look in the → “cyber resilliance act”, which aim to the same target, it will apply to all products that are connected either directly or indirectly to another device or to a network. (also software and operating systems) (also to open source products)
That this is today not the reality on many products, i know very well.
As german company you have to care about CRA for all users in European Economic Area (EEA), and it is already adoped by our council (10th October 24), clock is ticking backwards, already in 2026 you need to be prepared in case of reporting obligations.
1 Like
Not everything that is technically possible is allowed by law and that’s the wrong point where @romangg and @philm still reside.
1 Like
If i was one of those 99% and i noticed unauthorized data collection of any sort i would be mighty annoyed and deeply suspicious.
6 Likes
You can be “suspicious”.
But what actually is (rather: what will be - it’s still in development) will clear that up.
I’d likely be a bit annoyed by the question - if I decide to follow up I’d know, if I decide to ignore it and go with default - nothing should change.
I’d answer in the affirmative - I’d want to help out.
Yes and no.
As a GNU/Linux distribution, Manjaro is a community project, even if only because most of the software in a Manjaro installation comes directly from Arch in its unmodified form.
However, Manjaro does also have a commercial arm, the Manjaro GmbH, registered in Germany, and it is this commercial arm which maintains partnerships with hardware vendors and third-party commercial software vendors.
Yes, it’s complicated. 
@romangg, I’ve just uploaded my data, but I manually installed mdd in my ~/.local/bin, as opposed to via the package manager — I’ll explain why in a minute.
I did however notice — or perhaps it’s my misinterpretation — that the script reports my root filesystem as being only 1 GiB, which is correct, but it may misrepresent things at the larger scale.
The reason why my root filesystem is only 1 GiB is that I have installed my system with everything split off from the root filesystem that could be split off, which is a solid UNIX tradition. 
[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] > lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 512M 0 part /boot
├─sda3 8:3 0 1G 0 part /
├─sda4 8:4 0 22G 0 part /usr
├─sda5 8:5 0 512M 0 part /usr/local
├─sda6 8:6 0 2G 0 part /opt
├─sda7 8:7 0 1.5G 0 part
├─sda8 8:8 0 400G 0 part /srv
├─sda9 8:9 0 450G 0 part /home
├─sda10 8:10 0 10G 0 part
└─sda11 8:11 0 20G 0 part /var
sdb 8:16 0 698.6G 0 disk
├─sdb1 8:17 0 10G 0 part
└─sdb2 8:18 0 683.6G 0 part
sr0 11:0 1 1024M 0 rom
Among other things — and this is why I have for now installed mdd manually instead of system-wide via the package manager — this allows me to mount all of the crucial filesystems (such as /usr) read-only.
Given that mdd is still a work in progress and thus likely to evolve very quickly, I don’t want to have to go through the trouble of having to remount /usr read/write all the time, update the script, run an fstrim on /usr and then remount /usr read-only again, the latter often failing when sddm is still running.
But this also popped an idea into my head. I don’t know whether this could influence the stats on systems with more than one user account, but if mdd were implemented via the Autostart mechanisms of XDG-compliant desktop environments instead of via systemd, then it would make it much easier to pop up a dialog window in the user’s GUI in order to ask them for their consent.
Just a thought. I’m not a developer (anymore), and I don’t know Python. 
2 Likes
I appreciate the move, just my 2cents:
Most arguments against opt-out are obvious as well as those for opt-in(so I am not gonna repeat that here rn),
as for now I would just encourage you to approach it a little more slowly.
I.e. first only put it into unstable/testing, before instantly dropping it this year on stable. So that if further backlash arises it can be addressed and it doesn’t fell rushed.
In addition maybe don’t enable the “full” set of telemetry at the start, as it could be too sensitive or if bugs appear etc. just in case.
Why does mmd need to know if PipeWire is installed on a PulseAudio system?
Why not just check active audio servers with inxi?
$ inxi -A | grep Server
Server-1: JACK v: 1.9.22 status: active
Server-2: PulseAudio v: 17.0 status: active
I don’t understand precisely what is going on in the python script for PulseAudio and PipeWire but it appears to be using pacman and pactl rather than inxi or other commands that work in root
Manjaro Metrics is not showing any information about audio servers
mmd also seems to be collecting other data about systems that is not displayed on Manjaro Metrics, so I have a concern about excess data being collected
For informed consent purposes
Users on a proprietary OS have to interact with a EULA and tick a box to confirm they have read the terms and conditions
2 Likes
This (frequency) is very problematic in my eyes, especially since the device_id (or even something seemlngly harmless as the install_date) is indeed suitable to track a single device.
Your users aren’t dumb - don’t treat them as such.
If you have trouble explaining your data collection reasons, contents and processing in short and concise paragraphs to them, it’s not your users fault.
I think data collection without consent and opt-in is user hostile.
You’re not acting on a “personal level” here but as manjaro CTO and it very much looks like you’ve not fully grasped the seriousness of unwanted telemetry.
8 Likes
It seems my question about how you plan to notify new users of telemetry collection decided to ignore, this is sad.
It seems like nothing will convince you to make this optional.
The rejection of telemetry was one of the reasons for my migration to Linux and here we are again 10 years later.
6 Likes
no problem,
it is hashed by SHA-256 then from the hash value a uuid is generated, thats done fine in my eyes.
The Telemetry well has already been poisoned as every man and his dog seeks to capitalise on user data, hardware and otherwise.
Its no wonder that people, including myself, are suspicious of what the long term plans are for the use of that information and what information will be included as essential in the future.
I feel uneasy about a systemd service whose sole function is to collect data and would prefer not to have such a feature in my installation.
5 Likes
I miss the emoji plugin.
I’d have given this a: 
You can be suspicious - but you can find out.
It’s very unclear - but realistically:
nothing can be done about that
That is entirely on you.
Why do you feel uneasy?
It’s easy to find out what the thing does / proposes to do.
No need to be uneasy - no feelings necessary
you can know instead of feel …
and can either decline or accept