It really seems like the project would benefit from having better hardware stats. If you make it a package, people have to be educated to get it and use it--not that it doesn't have value, it just isn't well exposed and you will only get stats from the most clueful users. I would suggest making anonymized stat upload part of the install and upgrade process, to get wider coverage. - When installing, there's a new step or checkbox with an opt-in for hardware data sharing, defaulting to off - If you opt in, your info is uploaded as part of the install process - Expose the same functionality in a new system-level command like 'freebsd-uploadstats' and make it an optional but suggested part of the upgrade process, which is something most users will see repeatedly if they continue to be users. Perhaps the local machine can generate a hash of the report, check that with the server before the upload goes through. Hardware doesn't change that often. I do not want the project to turn in to Google or Microsoft, but knowing the hardware in use is a pretty worthy goal. MS
On Tue, Oct 9, 2018 at 12:48 AM Matt S <staroscik at gmail.com> wrote:> It really seems like the project would benefit from having better hardware > stats. If you make it a package, people have to be educated to get it and > use it--not that it doesn't have value, it just isn't well exposed and you > will only get stats from the most clueful users. > > I would suggest making anonymized stat upload part of the install and > upgrade process, to get wider coverage. > > - When installing, there's a new step or checkbox with an opt-in for > hardware data sharing, defaulting to off > - If you opt in, your info is uploaded as part of the install process > - Expose the same functionality in a new system-level command like > 'freebsd-uploadstats' and make it an optional but suggested part of the > upgrade process, which is something most users will see repeatedly if they > continue to be users. > > Perhaps the local machine can generate a hash of the report, check that > with the server before the upload goes through. Hardware doesn't change > that often. > > I do not want the project to turn in to Google or Microsoft, but knowing > the hardware in use is a pretty worthy goal. > > MS > _______________________________________________ > freebsd-stable at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >https://en.wikipedia.org/wiki/Dark_pattern
On 9/10/18 3:15 am, Matt S wrote:> It really seems like the project would benefit from having better hardware > stats. If you make it a package, people have to be educated to get it and > use it--not that it doesn't have value, it just isn't well exposed and you > will only get stats from the most clueful users. > > I would suggest making anonymized stat upload part of the install and > upgrade process, to get wider coverage. > > - When installing, there's a new step or checkbox with an opt-in for > hardware data sharing, defaulting to off > - If you opt in, your info is uploaded as part of the install process > - Expose the same functionality in a new system-level command like > 'freebsd-uploadstats' and make it an optional but suggested part of the > upgrade process, which is something most users will see repeatedly if they > continue to be users. > > Perhaps the local machine can generate a hash of the report, check that > with the server before the upload goes through. Hardware doesn't change > that often.There is the bsdstats port for system version and hardware details, as the site has had errors listing hardware details for some time it may not last much longer. With the amount of TrueOS entries, it would indicate that they probably have (had?) it as a default install. If the FreeBSD project or foundation doesn't want to collect this data then a company that relies on *BSD, like iX Systems, may want to step up and provide servers to collect this data. I do think it would be better as an official project data collection rather than a third party service. -- FreeBSD - the place to B...Software Developing Shane Ambler