FYI, the hw-probe-git AUR package still depends on edid-decode, but it doesn’t actually need it anymore. Use one of the official packages mentioned above.
User has to include an option to upload data sudo hw-probe -all -upload or data is saved to root folder on system only
hw-probe is also available as an appimage; snap; flatpak and for docker
(but they do not collect as much information as AUR package)
and included on Live ISOs for ArcoLinux, Debian and Open Mandriva
I use this package to keep track of hardware on 3 systems when they are cleaned and serviced, or upgraded
The downside of this being opt-in is that there are only 8339 tested systems running Manjaro and Arch has 9608 tested systems, whereas Debian has 15698 and Open Mandriva has 19049
The database has been running since 2016 so there are also 49 tested systems for Antergos
Meanwhile, Manjaro forum has been running since 2020 and has 20,651 TL1 users
14 days have passed and my personal deadline is coming to an end,
so I would be interested in the current status.
The result of the survey is very clear, with 75%, even if it is not representative of just 179 users who took part, out of 2.2k users (forum active users last 30 days)
As a senior IT admin, I am responsible for a certain number of users (50+) and might even have been interested in the business services, but without clarity, there is a big problem.
The fact that the Cyber Resilience Act comes into force on December 2024 plus an implemtation phase, NIS2 is expected in March, and the discussion about data collection that has been going on here since 2021 seems to have no end, unfortunately forces me to clearly decide against Manjaro.
I pleased all, please don’t start a detailed discussion again,
there is already so much content on all sides about MDD.
I wish to get a clear statement,
because on the one hand, I am very happy with Manajaro,
but on the other hand I also have to keep an eye on and comply with various European regulations,
and this will be the case for years to come,
so clarity is needed, especially when it comes to data collection.
Therefore i ask again,
is there now a final and carved in stone decision regarding MDD?
and also similar ideas for the future?, or not?
But there is also no desicion, it not to do it next week/month/year!,
and the complete discussion starts again.
Further i do not let the survey decide, as it is not representative,
the EU regularities have more impact on decision and therefore the opt-out plan is a huge problem.
Of course, my using manjaro experience say stay, regularities say move away, as it could broke tomorrow, then you have the salat, therefore i hoped that this discussion about data collecting find a final end, but when it not, okay, no problem, then plan b will roll on.
Why worry about something that may or may not happen, may or may not be what was originally proposed, and if it does happen, will certainly be announced well in advance of implementation?
the discussion shows, that there is a strong will, to collect data, my feeling from all posts overall, therefore it is just a question of time, when it will be rolled out.
as user (opt-out) is breaking → privacy-by-default which should the way to go
often the argument “firefox” came up, and look there is a fork “zen browser” with privacy-first, and yes crash reports can be send directly to mozilla (but only as opt-in) take a look in the privacy policy → Zen Browser ← that’s a really good policy, i’ve seen so far.
Why Manjaro does not have such a policy?
The answer you know, from all the posts about MDD, going back to 2021.
That should be enough, i wish u all well,
i’ve found my decission and going to work on plan b.
Ah, so just paranoid… can’t fix that. There’s NO WAY this would be ‘rolled out’ just like that - certainly without a very obvious notification with an option to install and enable such a feature.
It is very unreasonable to even suggest this as a possibility… but then, it’s also unreasonable to attempt to engage in reasonable discussion with someone who brings up unreasonable feelings not based on facts, and states that they are the reasoning for such conclusions.
It might be better to avoid connecting your computer to any form of networking, and thus further take measures to protect your data.
Manjaro Data Donor was first mentioned in request for testers posted 18 days ago (2 Nov 2024) Testers needed: Manjaro Data Donor
Topic was closed 6 Nov 2024
take a look at the date, scroll down, it is the same context/Idea… we need telemetry…, same as in MDD, and also the nice firefox example is as old as the discussion about any kind of telemetry.
@Kobold read upper link, and say me after it, that it is not just the same as mdd → we need telemetry, and look on the date
2021 the same like MDD:
That describes nearly exact where we are with MDD today, and still no clarifikation about this point, if it is or not done in future. I think telemetry will come, as the will for it is big (my feeling from discussion)
Interestingly, the following article about the limitations of KDE’s KUserFeedback (KUF) for doing data-driven UX work was in my Planet KDE RSS feed this morning:
The basic problem is that we currently send all the raw data to the KDE servers to get the answers we need. And the data we need to collect in order to get the above described desired user insights could of course be used to “identify a specific user” – which is not allowed by our telemetry policy for good reason.
And yet we need even more data. We want to target all users, or only users who exhibit certain behaviors. We want them to fill out questionnaires to better understand why they behave the way they do, to understand their goals and intentions. This would be extremely helpful in understanding bug reports. Or to support our design discussions with relevant data from real users.
All of this can only be achieved with a fundamental change in the way we do telemetry.
Existing alternatives, such as the opt-out Endless OS metrics system, also do not allow enough user insights and share the problem that the data leaves the property of the data owners, the users. That is why we have been working on the privact ecosystem, which allows all the insights described above, while fully preserving users’ privacy. And because of that, we can not only ask for more intimate data, but we can also make participation opt-out and so get data from substantially more people. And why is that? Because with the privact ecosystem, there is no technical possibility that any individual’s personal data can ever be shared remotely. Never. But it would finally enable good user-data-driven UX work. For the sake of KDE and our users.
There is an open discussion about moving KDE’s KUserFeedback (KUF) to the privact ecosystem on invent.kde.org:
The current state of KUserFeedback is limited. The main symptom KUF suffers from is the lack of interesting data, especially for UX work, marketing, or user support. The data we currently get from KUF only gives us hints to make top level decisions like “do we still need to support technology XY”? But there is no way to understand our user base more deeply.
Wearing UX glasses: This takes away an important pillar of usability — data-driven UX work. Currently we often have to guess, trust internal experts, or simply copy what others are doing. This is a significant problem for the quality of UX work we can achieve.
The fundamental problem is that KUF actually pushes real user data to the KDE servers. Since we currently have to do this, we:
ask users to opt in to sending their data, which results in a very small percentage of real users actually sharing their data.
apply our very restrictive telemetry policy, which allows only rather uninteresting data to be sent when it comes to UX issues.
have no actionable path to changing the data that gets sent, because this would require re-approval for those who already opted in, and no such functionality was ever written
As a result, we get uninteresting data from a too small (and definitely very biased) sample of users.
In privact.org, we have been working to fundamentally solve this problem. We have started to build an infrastructure that allows:
storing user data only on the user’s system
evaluating collective data with an algorithm that ensures individual privacy
In the privact system, all locally collected data is under the full control of the user and is never sent as a blob anywhere. Instead, software on the system is able to respond to specific individual questions and return one answer; a random system is chosen to aggregegate the results from everyone using a combined federated, homomorphic and e2e encryption scheme that results in only the final aggregated answer being decryptable. This encrypted answer is sent to privact’s servers, and then along to the final recipient (e.g. KDE). This ensures zero identifiability for every user. Integrating this technology into KDE would hence solve the problems described above:
We could make the use of this technology opt-out, resulting in significantly more users participating.
We could ask for more meaningful data, resulting in better insights into user behaviour.
The set of locally collected data could be changed at will, with no negative privacy implications
This would actually allow us to do data-driven UX work and thus significantly improve the quality of KDE software.
I just spotted this too - certainly the feelings of paranoia about data do seem to me to be going way too far.
The first things I would always do is to enable KDE telemetry, and I would do the same for Manjaro - but the normal behaviour of people seems to be that zero data is acceptable… even with complete and open implementation.
However, I find it annoying that 1. I’m in a minority, so that data is very limited in it’s usefulness and 2. Any suggestion that this data might be offered is met with stiffer resistance than Russia’s invasion of Ukraine.
I don’t understand how respect would be an issue - you can use the free software, respectfully giving you an option to accept or deny the telemetry option - with a complete list of information that we will monitor in order to determine the allocation of our development resources.
Interestingly, the User’s comments (in 2021) seem to be based on random documents found elsewhere (no longer accessible) that might have suggested kUserFeedback is spyware.
Obviously, it’s now 3 years later, however the comment from @LordTermor “Ah, it’s that very funny article” at least has me intrigued as to the validity of the source.