Re: dmesg submission service -- please submit today
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 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
I don't see how "dark pattern" applies because this doesn't trick you into an ongoing subversive data-sharing arrangement. In this idea, install asks you if you want to share stats once--you are not opted in to a system. Then, when processing upgrades, the Handbook would remind you that the report ability exists and this is a good time to do it if you've made any changes. Nothing happens without your explicit agreement during install, and nothing happens afterwards unless you type in a command, every time. If the current data is adequate for the project's needs, nothing needs to change. If the project needs to know more about hardware stats, the request to get hardware info needs to be somewhat visible. Making it an optional part of installing/updating seems reasonable to me. I'm assuming we trust the project, but if the idea of easier stat-sharing is offensive, then I guess there's nothing to talk about. On Mon, Oct 8, 2018 at 10:09 AM blubee blubeeme wrote: > > > On Tue, Oct 9, 2018 at 12:48 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. >> >> 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@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > https://en.wikipedia.org/wiki/Dark_pattern > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On Tue, Oct 9, 2018 at 12:48 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. > > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > https://en.wikipedia.org/wiki/Dark_pattern ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On Sun, Oct 7, 2018 at 11:23 PM Peter Jeremy wrote: > On 2018-Oct-07 23:41:43 +, Roger Leigh wrote: > >Out of interest, has FreeBSD considered implementing an equivalent of > >Debian's "popularity-contest" package, which periodically submits > >anonymised lists of installed packages? On FreeBSD this could be from > >the pkg database, and could also include hardware information. > > There's ports/sysutils/bsdstats but I'm not sure how popular that is. > It appears to be broken :( Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On 2018-Oct-07 23:41:43 +, Roger Leigh wrote: >Out of interest, has FreeBSD considered implementing an equivalent of >Debian's "popularity-contest" package, which periodically submits >anonymised lists of installed packages? On FreeBSD this could be from >the pkg database, and could also include hardware information. There's ports/sysutils/bsdstats but I'm not sure how popular that is. -- Peter Jeremy signature.asc Description: PGP signature
Re: dmesg submission service -- please submit today
On Sun, Oct 7, 2018 at 5:45 PM Roger Leigh wrote: > On 07/10/2018 05:40, Warner Losh wrote: > > >> I'd like to request as many people as possible submit > >> their current dmesg to the service at > http://dmesgd.nycbug.org/index.cgi so > >> that we have a better basis for future preliminary lists of drivers for > >> other parts of the tree. > > > This one-liner works to submit, though you'll need to change username, > > email and maybe tweak the description if your system doesn't have decent > > smbios entries. It's also x86 centric, since other systems won't have > this > > information as readily available. > > Out of interest, has FreeBSD considered implementing an equivalent of > Debian's "popularity-contest" package, which periodically submits > anonymised lists of installed packages? On FreeBSD this could be from > the pkg database, and could also include hardware information. > > In Debian, it's opt-in at install time, or installable afterward. If > FreeBSD had a similar package and installer opt-in, this could > potentially provide useful usage statistics without any privacy concerns. > We've talked about that, but haven't implemented it. I'd like to figure out how we can send anonymized structured data about the system, including hardware and software installed. bsdstats kinda sorts did something like this, but their data is unavailable (which is what motivated my current experiment). Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On 07/10/2018 05:40, Warner Losh wrote: I'd like to request as many people as possible submit their current dmesg to the service at http://dmesgd.nycbug.org/index.cgi so that we have a better basis for future preliminary lists of drivers for other parts of the tree. This one-liner works to submit, though you'll need to change username, email and maybe tweak the description if your system doesn't have decent smbios entries. It's also x86 centric, since other systems won't have this information as readily available. Out of interest, has FreeBSD considered implementing an equivalent of Debian's "popularity-contest" package, which periodically submits anonymised lists of installed packages? On FreeBSD this could be from the pkg database, and could also include hardware information. In Debian, it's opt-in at install time, or installable afterward. If FreeBSD had a similar package and installer opt-in, this could potentially provide useful usage statistics without any privacy concerns. Regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On Sun, Oct 7, 2018 at 11:27 AM Kevin Oberman wrote: > He's looking for information on what drivers are still needed, so only if > the SCSI drives require in different drivers (unlikely) would that be > needed. I suspect that, unless you use CardBus type stuff, just the > /var/run/dmesg.boot should be all that i required. > CardBus, PC Card and USB are much harder to quantify. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On Sun, Oct 7, 2018 at 11:11 AM Roderick wrote: > > On Sat, 6 Oct 2018, Warner Losh wrote: > > > As you can tell, the project is looking to clear some of the deadwood > from > > its driver lists. One problem is that we have to guess what's in used > based > > on our personal experience. This has proven to be less reliable than > hoped > > in the 10/100 discussions that are going on now. > > Should I dump a dmesg with any device I have connected to every computer > I have? Deadline today? > > Or better I risk not be able to read data on old SCSI discs I am not > using now? > There's no deadline, per se. And there will be at least two drivers that will survive the purge (ahc and mpt). At the present time, they are the only two known to be working for real workloads. So chances are you are already using one of these devices, and if not they are cheap, so there will be a fallback to getting data off of parallel SCSI disks, as well as continued support for parallel scsi tape drives, scsi CD, etc. FreeBSD will support a way to access these devices for years to come. The reason I'm looking at this is because CAM has become rather twisted in places over the years. Many of the reasons for the twistiness can be traced directly to weird workarounds for devices that are almost certainly no longer in use. I'd like to eliminate them. Some can be eliminated because they were for a particular ISA device that's no longer in the tree. But I can't do the others until I know which ones, if any, need to remain. This is why I was asking for dmesgs now so I can start to get a feel for which devices are even still in use on any FreeBSD version, let alone more modern ones. Looking at the NIC data it's clear that we have devices that are wildly popular, and then ones that aren't used with very little in between. Unlike in NIC land, there's a more real and tangible cost that I can point to for continuing old devices in the tree, and I said 'about a month from now' so I can come up with examples of what's a problem, as well as look at data to see what devices still have users, etc, to avoid some of the back-and-forth that we had at the start of the 10/100 discussions as people with devices that turned out to be popular rightly complained. I think having a well articulated reason other than 'it's old' will also help the community understand the cost of keeping things in the tree so we can better judge of the current level of 'benefit' justifies that cost. And any elimination will be safely past 12.0 and won't be back-ported, so anything that works today should work for 12.x releases over the next 3-5 years at the very least. I know that these kinds of discussions can be fraught and I'm doing my best to be honest and open about what's going in, why we want to do thing, and giving plenty of time for the communities that are using FreeBSD to let us know of that use in advance of any decisions being made. I'm hoping the extra data people provide will help us make the initial selection process be more data driven rather than 'best guess' which turned out to be not very good. tl;dr: Not removing anything before 12, devices documented as still working will remain, there's cheap alternatives for removed drivers, don't panic. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
Warner said that he would look at submissions in about a month. "I'll be using the data in about a month to look at old parallel scsi driver use." He's looking for information on what drivers are still needed, so only if the SCSI drives require in different drivers (unlikely) would that be needed. I suspect that, unless you use CardBus type stuff, just the /var/run/dmesg.boot should be all that i required. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Sun, Oct 7, 2018 at 10:11 AM Roderick wrote: > > On Sat, 6 Oct 2018, Warner Losh wrote: > > > As you can tell, the project is looking to clear some of the deadwood > from > > its driver lists. One problem is that we have to guess what's in used > based > > on our personal experience. This has proven to be less reliable than > hoped > > in the 10/100 discussions that are going on now. > > Should I dump a dmesg with any device I have connected to every computer > I have? Deadline today? > > Or better I risk not be able to read data on old SCSI discs I am not > using now? > > Best regards > Rodrigo > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On Sat, 6 Oct 2018, Warner Losh wrote: As you can tell, the project is looking to clear some of the deadwood from its driver lists. One problem is that we have to guess what's in used based on our personal experience. This has proven to be less reliable than hoped in the 10/100 discussions that are going on now. Should I dump a dmesg with any device I have connected to every computer I have? Deadline today? Or better I risk not be able to read data on old SCSI discs I am not using now? Best regards Rodrigo ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On Sat, Oct 6, 2018 at 9:23 PM Warner Losh wrote: > [[ I sent this to -current earlier in the day, but I thought I'd widen the > scope ]] > > Greetings, > > As you can tell, the project is looking to clear some of the deadwood from > its driver lists. One problem is that we have to guess what's in used based > on our personal experience. This has proven to be less reliable than hoped > in the 10/100 discussions that are going on now. > > So, to that end, I'd like to request as many people as possible submit > their current dmesg to the service at http://dmesgd.nycbug.org/index.cgi so > that we have a better basis for future preliminary lists of drivers for > other parts of the tree. Please take the time to make these submissions > regardless of what your current hardware is. Please submit for any machine > you'd like to upgrade to FreeBSD 12 or 13. Heck, submit for any machine you > have running, if you'd like. Identifying information is generally masked > out. > > This is just a request by me. I'll be using the data in about a month to > look at old parallel scsi driver use. Though not definitive, it will be > suggestive of what's in use. The data is currently a bit thin, so I thought > I'd see what a message like this could do to improve that situation. This > should be viewed as a personal suggestion right now... > > Warner > > P.S. I know there's other user generated data sites out there, but this > appears to be the only one that's actually still working. > This one-liner works to submit, though you'll need to change username, email and maybe tweak the description if your system doesn't have decent smbios entries. It's also x86 centric, since other systems won't have this information as readily available. curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@/var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi Hope helps facilitate submission of entries. Thanks to Charles Sprickman for the idea of using a curl one-liner. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
dmesg submission service -- please submit today
[[ I sent this to -current earlier in the day, but I thought I'd widen the scope ]] Greetings, As you can tell, the project is looking to clear some of the deadwood from its driver lists. One problem is that we have to guess what's in used based on our personal experience. This has proven to be less reliable than hoped in the 10/100 discussions that are going on now. So, to that end, I'd like to request as many people as possible submit their current dmesg to the service at http://dmesgd.nycbug.org/index.cgi so that we have a better basis for future preliminary lists of drivers for other parts of the tree. Please take the time to make these submissions regardless of what your current hardware is. Please submit for any machine you'd like to upgrade to FreeBSD 12 or 13. Heck, submit for any machine you have running, if you'd like. Identifying information is generally masked out. This is just a request by me. I'll be using the data in about a month to look at old parallel scsi driver use. Though not definitive, it will be suggestive of what's in use. The data is currently a bit thin, so I thought I'd see what a message like this could do to improve that situation. This should be viewed as a personal suggestion right now... Warner P.S. I know there's other user generated data sites out there, but this appears to be the only one that's actually still working. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
