Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
For more information on smolt see:
https://hosted.fedoraproject.org/projects/smolt/wiki and https://hosted.fedoraproject.org/projects/smolt/wiki/Scope
Current stats can be found at:
http://smolt.fedoraproject.org/stats
You can have your machine send its stats by installing smolt with yum and typing "smoltSendProfile"
*Note: this is not LHCP, which is going to be a much larger project. Smolt has a much smaller scope and will ultimately (hopefully) be replaced by LHCP when it is ready.
-Mike
On Wednesday 31 January 2007 16:26, Mike McGrath wrote:
Current stats can be found at:
I want to propose to gather and provide statistics about installed packages and maybe version, too.
Regards, Till
On Wed, 2007-01-31 at 09:26 -0600, Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
OK, now that you have asked, you'll be prepared to facing a very clear answer: NO, NEVER.
It must be strictly optional and even then, it should require explicit interactive user activation.
I am not willing to accept any unsupervised, non-opt-in data transmission from any package in Fedora and will prepare a proposal to change the Fedora Package Guidelines accordingly.
Ralf
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 09:26 -0600, Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
OK, now that you have asked, you'll be prepared to facing a very clear answer: NO, NEVER.
It must be strictly optional and even then, it should require explicit interactive user activation.
I am not willing to accept any unsupervised, non-opt-in data transmission from any package in Fedora and will prepare a proposal to change the Fedora Package Guidelines accordingly.
Ralf
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
-Mike
On Wed, 2007-01-31 at 10:11 -0600, Mike McGrath wrote:
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 09:26 -0600, Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
OK, now that you have asked, you'll be prepared to facing a very clear answer: NO, NEVER.
It must be strictly optional and even then, it should require explicit interactive user activation.
I am not willing to accept any unsupervised, non-opt-in data transmission from any package in Fedora and will prepare a proposal to change the Fedora Package Guidelines accordingly.
Ralf
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
Wouldn't it be better as an opt-in? Sure, you'll probably get less data due to uninformed/lazy/security conscience/or tinfoil hat types not opting in (I might be one of the above), but you'll probably make more people feel comfortable with adding it...
Brian
On 1/31/07, Ralf Ertzinger fedora@camperquake.de wrote:
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
It should not be easy to out out of. It might be acceptable to be easy to opt in into.
Meh, if someone is clicking next, next, next. That's their problem. Try out the firstboot method first... It defaults to no with a "are you sure you mean no" dialog. I'm sure the verbage could be made more clear... Seriously, try it first.
-Mike
At 10:20 AM -0600 1/31/07, Mike McGrath wrote:
On 1/31/07, Ralf Ertzinger fedora@camperquake.de wrote:
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
It should not be easy to out out of. It might be acceptable to be easy to opt in into.
Meh, if someone is clicking next, next, next. That's their problem. Try out the firstboot method first... It defaults to no with a "are you sure you mean no" dialog. I'm sure the verbage could be made more clear... Seriously, try it first.
I haven't tried it. I probably wouldn't freak if it came up on first boot.
How about the smolt package having a list of "well known" hardware: hardware that is already known to work, or to not work for good reason. If the computer has only "well known" hardware, don't bother the user at all. (Unless some of it is known to be bad; it might be polite to mention that.) If there is unlisted hardware, offer to query a server to find out how "interesting" it is, in order to help the user make an informed choice. (Be sure to mention that /all/ the hardware will be reported on opt-in, in case of interactions.) Even secretive people might want to opt in if they thought it would really help, and they'd surely be less offended in the first place.
On Wednesday 31 January 2007 6:16 pm, Tony Nelson wrote:
How about the smolt package having a list of "well known" hardware: hardware that is already known to work, or to not work for good reason. If the computer has only "well known" hardware, don't bother the user at all. (Unless some of it is known to be bad; it might be polite to mention that.) If there is unlisted hardware, offer to query a server to find out how "interesting" it is, in order to help the user make an informed choice. (Be sure to mention that /all/ the hardware will be reported on opt-in, in case of interactions.) Even secretive people might want to opt in if they thought it would really help, and they'd surely be less offended in the first place.
All of the above, in my opinion, would be especially useful on the Fedora Live CD. Shopping for a new PC would become interesting.
Thank you for your consideration, Davide Bolcioni
Hi.
On Wed, 31 Jan 2007 10:20:49 -0600, Mike McGrath wrote:
Meh, if someone is clicking next, next, next. That's their problem. Try out the firstboot method first... It defaults to no with a "are you sure you mean no" dialog. I'm sure the verbage could be made more clear... Seriously, try it first.
Is there a way to run firstboot in a kind of "just look" mode on an already installed system? I'm willing to look at it, but I do not want it to actually change something about my system.
On Thursday 01 February 2007 02:24, Ralf Ertzinger wrote:
Is there a way to run firstboot in a kind of "just look" mode on an already installed system? I'm willing to look at it, but I do not want it to actually change something about my system.
firstboot --debug
On Wed, Jan 31, 2007 at 05:16:27PM +0100, Ralf Ertzinger wrote:
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
It should not be easy to out out of. It might be acceptable to be easy to opt in into.
Anything collecting personal data must be opt-in. Personal data in this context would include things like email address, arguably IP address.
On 1/31/07, Alan Cox alan@redhat.com wrote:
On Wed, Jan 31, 2007 at 05:16:27PM +0100, Ralf Ertzinger wrote:
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
It should not be easy to out out of. It might be acceptable to be easy to opt in into.
Anything collecting personal data must be opt-in. Personal data in this context would include things like email address, arguably IP address.
Is there any place that might list what personal data actually is? At present I'm not storing email address or IP in the smolt db.
-Mike
On Wed, 2007-01-31 at 10:11 -0600, Mike McGrath wrote:
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 09:26 -0600, Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
OK, now that you have asked, you'll be prepared to facing a very clear answer: NO, NEVER.
It must be strictly optional and even then, it should require explicit interactive user activation.
I am not willing to accept any unsupervised, non-opt-in data transmission from any package in Fedora and will prepare a proposal to change the Fedora Package Guidelines accordingly.
Ralf
Lucky for me then, I based the firstboot integration off of the EULA. Its very easy to opt out of.
It must be opt-in.
1. May-be you should consider to talk to RH legal. In many parts of this world opt-out is ILLEGAL.
2. It should be is a matter of fairness to make it opt-in.
3. In many parts of this world SPY-WARE like yours is a very hot political topic. You are at risk at exposing Fedora to be subjects to such flames. Even Microsoft has learned their lessons and made "registration opt-in", now you are committing the same FAULT.
Ralf
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
It must be opt-in.
- May-be you should consider to talk to RH legal.
In many parts of this world opt-out is ILLEGAL.
Ralf, seriously. We get it. Use firstboot. You'll see that it is in fact opt-in. You're arguing for something to stay the way it is with no one disagreeing with you.
-Mike
On Wed, 2007-01-31 at 11:20 -0600, Mike McGrath wrote:
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
It must be opt-in.
- May-be you should consider to talk to RH legal.
In many parts of this world opt-out is ILLEGAL.
Ralf, seriously. We get it. Use firstboot. You'll see that it is in fact opt-in. You're arguing for something to stay the way it is with no one disagreeing with you.
Where is the button/switch to disable it?
Show us the part of your sources.
Ralf
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 11:20 -0600, Mike McGrath wrote:
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
It must be opt-in.
- May-be you should consider to talk to RH legal.
In many parts of this world opt-out is ILLEGAL.
Ralf, seriously. We get it. Use firstboot. You'll see that it is in fact opt-in. You're arguing for something to stay the way it is with no one disagreeing with you.
Where is the button/switch to disable it?
Show us the part of your sources.
Ralf
You'll find people are more amenable to your ideas if you actually do what they ask you to. In my case, actually LOOK at the firstboot. The source is open and you can look at it but instead have prefered to be a squeaky wheel. I'll play this game but only because I feel it is important to get smolt in and being used.
Code: https://hosted.fedoraproject.org/projects/smolt/browser/firstboot/smolt.py
Screen Shot: https://hosted.fedoraproject.org/projects/smolt/attachment/wiki/WikiStart/sm...
Notice the word "No" is selected by default.
-Mike
You'll find people are more amenable to your ideas if you actually do what they ask you to. In my case, actually LOOK at the firstboot. The source is open and you can look at it but instead have prefered to be a squeaky wheel. I'll play this game but only because I feel it is important to get smolt in and being used.
Code: https://hosted.fedoraproject.org/projects/smolt/browser/firstboot/smolt.py
Screen Shot: https://hosted.fedoraproject.org/projects/smolt/attachment/wiki/WikiStart/sm...
This may be shocking, but I have an actual development suggestion. It'd probably be good if you thought up some better text for the title and the sidebar. That way, people will know what the screen means without having to know the name of the program and what it does. I know it's early on in the project, but still.
You may also want to add a very short text blurb to the top that explains what this screen does, and perhaps refers people to how they may submit their info later if they choose not to now. However, any text like that should really be kept to just a few sentences.
- Chris
On 1/31/07, Chris Lumens clumens@redhat.com wrote:
This may be shocking, but I have an actual development suggestion. It'd probably be good if you thought up some better text for the title and the sidebar. That way, people will know what the screen means without having to know the name of the program and what it does. I know it's early on in the project, but still.
Do you mean to imply that most users haven't heard of smolt :-D
Yeah, now that you mention it that screen is pretty confusing as to what it actually does. I'll put some text in there..
-Mike
Chris Lumens wrote:
You may also want to add a very short text blurb to the top that explains what this screen does, and perhaps refers people to how they may submit their info later if they choose not to now.
Plus: add something which explains why sending the info can later help should they experience problems. I.e., maintainers can ask for the UUID and immediately see the hardware details.
On Wednesday 31 January 2007 11:15, Ralf Corsepius wrote:
It must be opt-in.
- May-be you should consider to talk to RH legal.
In many parts of this world opt-out is ILLEGAL.
It should be is a matter of fairness to make it opt-in.
In many parts of this world SPY-WARE like yours is a very hot
political topic. You are at risk at exposing Fedora to be subjects to such flames. Even Microsoft has learned their lessons and made "registration opt-in", now you are committing the same FAULT.
Ralf,
it is not registration, it is not spy ware. it is a voluntary hardware profile. there is no way to know that a profile is yours unless you give me your unique hardware id that is generated on your system at package install time. This will help fedora in many ways.
it is opt-in you can choose to install or not install smolt. you can choose to sumbit a profile at any time or you can chose to never submit a profile.
Right now what we would like to do is have at firstboot time a screen where the user can say yes send my hardware profile in. nothing more nothing less.
Feel free to look at the code. there is no package list sent, no ip, no anything that can be associated to you without you giving me your id.
Say you are having a weird X issue you could give your ID to the x team and they can look at your profile and try to replicate it to determine the bug, fix, and possibly test it.
from http://publictest4.fedora.redhat.com/raw
UUID cc4dfded-42d8-489d-af68-c2ff14438d1c OS Aurora SPARC Linux release 2.90 (Aurora Corona) platform sparc64 bogomips 2001.0 systemMemory 16229 systemSwap 3996 CPUVendor sun4v - ultrasparc t1 (niagara) numCPUs 32 CPUSpeed 1000.0 language en_US.UTF-8 defaultRunlevel 3 vendor sun system Sun Fire(TM) T1000 Bus Class Driver Description pci OTHER unknown Broadcom|EPB PCI-Express to PCI-X Bridge pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5714 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5714 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER unknown Broadcom|HT1000 PCI/PCI-X bridge pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5704 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5704 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci SCSI mptsas LSI Logic / Symbios Logic|SAS1064 PCI-X Fusion-MPT SAS scsi HD unknown ATA|ST3320620AS
thats one of my systems that is all that gets sent.
And again to re-iterate it is entirely voluntary "you choose" to submit or not your profile
On Wed, 2007-01-31 at 11:30 -0600, Dennis Gilmore wrote:
from http://publictest4.fedora.redhat.com/raw
UUID cc4dfded-42d8-489d-af68-c2ff14438d1c OS Aurora SPARC Linux release 2.90 (Aurora Corona) platform sparc64 bogomips 2001.0 systemMemory 16229 systemSwap 3996 CPUVendor sun4v - ultrasparc t1 (niagara) numCPUs 32 CPUSpeed 1000.0 language en_US.UTF-8 defaultRunlevel 3 vendor sun system Sun Fire(TM) T1000 Bus Class Driver Description pci OTHER unknown Broadcom|EPB PCI-Express to PCI-X Bridge pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5714 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5714 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER unknown Broadcom|HT1000 PCI/PCI-X bridge pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5704 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5704 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci SCSI mptsas LSI Logic / Symbios Logic|SAS1064 PCI-X Fusion-MPT SAS scsi HD unknown ATA|ST3320620AS
thats one of my systems that is all that gets sent.
And again to re-iterate it is entirely voluntary "you choose" to submit or not your profile
I also presume the stats web page would be expanded on to provide more than just Top 20 devices and such? The reason I ask is that as a device driver maintainer, it would certainly be interesting to be able to get some ideas on how many people have the device/are using the driver and platforms.
On 1/31/07, David Hollis dhollis@davehollis.com wrote:
On Wed, 2007-01-31 at 11:30 -0600, Dennis Gilmore wrote: I also presume the stats web page would be expanded on to provide more than just Top 20 devices and such? The reason I ask is that as a device driver maintainer, it would certainly be interesting to be able to get some ideas on how many people have the device/are using the driver and platforms.
Yeah, i'm actually working on a special device stats page. Its just not there yet.
-Mike
On 1/31/07, David Hollis dhollis@davehollis.com wrote:
I also presume the stats web page would be expanded on to provide more than just Top 20 devices and such? The reason I ask is that as a device driver maintainer, it would certainly be interesting to be able to get some ideas on how many people have the device/are using the driver and platforms.
We also totally need a section for the most snaztastic set of hardware running fedora. I mean seriously, if someone is running fedora on the equivalent audio/video setup as a 20 screen Movie Theature Multiplex.. that would be interesting to highlight... if they choose to let us know about it of course.
-jef"lspci 02:00.0 Brainwave Orbital Laser controller: Starbucks Coffee Co. BOL203x (rev 09)" spaleta
On Wed, Jan 31, 2007 at 01:17:54PM -0900, Jeff Spaleta wrote:
On 1/31/07, David Hollis dhollis@davehollis.com wrote:
I also presume the stats web page would be expanded on to provide more than just Top 20 devices and such? The reason I ask is that as a device driver maintainer, it would certainly be interesting to be able to get some ideas on how many people have the device/are using the driver and platforms.
We also totally need a section for the most snaztastic set of hardware running fedora. I mean seriously, if someone is running fedora on the equivalent audio/video setup as a 20 screen Movie Theature Multiplex.. that would be interesting to highlight... if they choose to let us know about it of course.
I know I'm not much of a regular contributor to the list, but I think this is a great idea: I've had more people ask me about fedora (and linux in general) thanks to my snazzy mythtv+fedora box at home than my "because its free!" argument, and I'm betting Jarod Wilson would agree.
-Tim
On Jan 31, 2007, at 22:11, Tim Fenn wrote:
On Wed, Jan 31, 2007 at 01:17:54PM -0900, Jeff Spaleta wrote:
On 1/31/07, David Hollis dhollis@davehollis.com wrote:
I also presume the stats web page would be expanded on to provide more than just Top 20 devices and such? The reason I ask is that as a device driver maintainer, it would certainly be interesting to be able to get some ideas on how many people have the device/are using the driver and platforms.
We also totally need a section for the most snaztastic set of hardware running fedora. I mean seriously, if someone is running fedora on the equivalent audio/video setup as a 20 screen Movie Theature Multiplex.. that would be interesting to highlight... if they choose to let us know about it of course.
I know I'm not much of a regular contributor to the list, but I think this is a great idea: I've had more people ask me about fedora (and linux in general) thanks to my snazzy mythtv+fedora box at home than my "because its free!" argument, and I'm betting Jarod Wilson would agree.
Definitely. :)
On Wednesday 31 January 2007 11:15, Ralf Corsepius wrote:
It must be opt-in.
- May-be you should consider to talk to RH legal.
In many parts of this world opt-out is ILLEGAL.
It should be is a matter of fairness to make it opt-in.
In many parts of this world SPY-WARE like yours is a very hot
political topic. You are at risk at exposing Fedora to be subjects to such flames. Even Microsoft has learned their lessons and made "registration opt-in", now you are committing the same FAULT.
Ralf,
it is not registration, it is not spy ware. it is a voluntary hardware profile. there is no way to know that a profile is yours unless you give me your unique hardware id that is generated on your system at package install time. This will help fedora in many ways.
it is opt-in you can choose to install or not install smolt. you can choose to sumbit a profile at any time or you can chose to never submit a profile.
Right now what we would like to do is have at firstboot time a screen where the user can say yes send my hardware profile in. nothing more nothing less.
Feel free to look at the code. there is no package list sent, no ip, no anything that can be associated to you without you giving me your id.
Say you are having a weird X issue you could give your ID to the x team and they can look at your profile and try to replicate it to determine the bug, fix, and possibly test it.
from http://publictest4.fedora.redhat.com/raw
UUID cc4dfded-42d8-489d-af68-c2ff14438d1c OS Aurora SPARC Linux release 2.90 (Aurora Corona) platform sparc64 bogomips 2001.0 systemMemory 16229 systemSwap 3996 CPUVendor sun4v - ultrasparc t1 (niagara) numCPUs 32 CPUSpeed 1000.0 language en_US.UTF-8 defaultRunlevel 3 vendor sun system Sun Fire(TM) T1000 Bus Class Driver Description pci OTHER unknown Broadcom|EPB PCI-Express to PCI-X Bridge pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5714 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5714 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER unknown Broadcom|HT1000 PCI/PCI-X bridge pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5704 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci OTHER tg3 Broadcom Corporation|NetXtreme BCM5704 Gigabit Ethernet MISC NETWORK unknown Networking Interface pci SCSI mptsas LSI Logic / Symbios Logic|SAS1064 PCI-X Fusion-MPT SAS scsi HD unknown ATA|ST3320620AS
thats one of my systems that is all that gets sent.
And again to re-iterate it is entirely voluntary "you choose" to submit or not your profile
On Wed, 2007-01-31 at 11:32 -0600, Dennis Gilmore wrote:
On Wednesday 31 January 2007 11:15, Ralf Corsepius wrote:
It must be opt-in.
- May-be you should consider to talk to RH legal.
In many parts of this world opt-out is ILLEGAL.
It should be is a matter of fairness to make it opt-in.
In many parts of this world SPY-WARE like yours is a very hot
political topic. You are at risk at exposing Fedora to be subjects to such flames. Even Microsoft has learned their lessons and made "registration opt-in", now you are committing the same FAULT.
Ralf,
it is not registration, it is not spy ware.
It unattendedly collects various data which is not publically available from a local machine => SPY-WARE
Connecting this information with IP-numbers opens many opportunities for abuse => Opens many chances to privacy breaches.
I don't have any reasons to trust this URL smolt sends it data too.
it is a voluntary hardware profile. there is no way to know that a profile is yours unless you give me your unique hardware id that is generated on your system at package install time.
You have this (BTW: absolutely not unique and forgable) hardware id in connection with IP-numbers. This allows backtracking.
You might have heard about the fuzz HW CPU-ID had caused in the past?
This will help fedora in many ways.
I guess, I don't have to mention: My opinion differs very much.
it is opt-in you can choose to install or not install smolt.
Mike asked about making installation the default. That's why I am so embarrassed.
Having a script that is not being run automatically (not used by first boot), but being run at user-request as part of eg. a bug-report (similar to bug-buddy) is a completely different topic.
Feel free to look at the code. there is no package list sent, no ip, no anything that can be associated to you without you giving me your id.
I'll pretty soon add an "Obsoletes: smolt" into the base package of my local repos.
And again to re-iterate it is entirely voluntary "you choose" to submit or not your profile
OK, I will have a look at the sources and look if something has changed since it was under review. At that time I did not notice any opt-in, but noticed a scripts being run at installation time.
In this particular case, I'll continue to be VERY stubborn.
There is not way to convince me about such spy-ware. If you want to collect statics with an opt-in, you can achieve the same by launching a counter website.
Ralf
On ons, 2007-01-31 at 18:54 +0100, Ralf Corsepius wrote:
There is not way to convince me about such spy-ware. If you want to collect statics with an opt-in, you can achieve the same by launching a counter website.
What a brilliant way to have a debate "nothing you can say can change my mind".. that is the rhetoric of conspiracy theorists and other breeds of true believers.
- David Nielsen
On Wed, 2007-01-31 at 19:01 +0100, David Nielsen wrote:
On ons, 2007-01-31 at 18:54 +0100, Ralf Corsepius wrote:
There is not way to convince me about such spy-ware. If you want to collect statics with an opt-in, you can achieve the same by launching a counter website.
What a brilliant way to have a debate "nothing you can say can change my mind".. that is the rhetoric of conspiracy theorists and other breeds of true believers.
Would you have preferred me to say: "Hell needs to freeze in before I'll install this piece of crap?"
And it's not related to conspiracy - It's about privacy. Less politely: My HW profile is none of your business.
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
Ralf
On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote:
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
So your web browser sends no useragent string?
(troll, troll)
- ajax
On Wed, 2007-01-31 at 20:55 -0500, Adam Jackson wrote:
On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote:
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
So your web browser sends no useragent string?
Guess why users fake them?
Ralf
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 20:55 -0500, Adam Jackson wrote:
On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote:
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
So your web browser sends no useragent string?
Guess why users fake them?
To get to IE only websites?
Ralf Corsepius wrote:
On Wed, 2007-01-31 at 20:55 -0500, Adam Jackson wrote:
On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote:
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
So your web browser sends no useragent string?
Guess why users fake them?
Silly me. I actually believed for a second that you were using evolution-2.8.2.1-3.fc6 to send your emails...
On Wednesday 31 January 2007 21:25, Christopher Aillon wrote:
Silly me. I actually believed for a second that you were using evolution-2.8.2.1-3.fc6 to send your emails...
From a machine with a local address of 192.168.1.100, external address hsi-kbw-082-212-056-027.hsi.kabelbw.de ([82.212.56.27]) blah blah blah...
On Wed, 2007-01-31 at 21:38 -0500, Jesse Keating wrote:
On Wednesday 31 January 2007 21:25, Christopher Aillon wrote:
Silly me. I actually believed for a second that you were using evolution-2.8.2.1-3.fc6 to send your emails...
Yes, it exposes me to be a likely victim of certain type of evolution (esp email) exploits. In other words, the fact evo transmits this info is a security relevant BUG in evolution.
Nevertheless, evo is still is a client, not a server, so should exploits happen their impact is likely to be limited. On servers the situation is different, faking/suppressing id strings is pretty effective to at least to irritate potential attackers.
From a machine with a local address of 192.168.1.100, external address hsi-kbw-082-212-056-027.hsi.kabelbw.de ([82.212.56.27]) blah blah blah...
Yes, you apparently know to read mail headers.
It doesn't tell you which NIC or GPU or CPU this machine has, if this is a physical machine at all (I could be masquerading) nor how many machines I have in my network, nor ... does it tell you the uptime, nor the bogomips nor does this allow you any conclusion on my income.
Ralf
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 19:01 +0100, David Nielsen wrote:
On ons, 2007-01-31 at 18:54 +0100, Ralf Corsepius wrote:
There is not way to convince me about such spy-ware. If you want to collect statics with an opt-in, you can achieve the same by launching a counter website.
What a brilliant way to have a debate "nothing you can say can change my mind".. that is the rhetoric of conspiracy theorists and other breeds of true believers.
Would you have preferred me to say: "Hell needs to freeze in before I'll install this piece of crap?"
And it's not related to conspiracy - It's about privacy. Less politely: My HW profile is none of your business.
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
Ralf
Go on and define 'silent' now.
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine.
BTW, this is my personal definition of FUD. Don't participate Ralf. Seriously, its ok. If you don't want your hardware counted, don't. But sounding off and trying to prevent others from participating is bad form.
-Mike
"Ralf" == Ralf Corsepius rc040203@freenet.de writes:
Ralf> I don't have any reasons to trust this URL smolt sends it data too.
In principle I think this site should be controlled by the fedora project. I didn't look to see whether it is or not. But in any case IMO it ought to be approximately as trustworthy as the standard yum servers.
The smolt data looked quite nice to me. Good stuff to know.
Tom
On Wed, 2007-01-31 at 11:10 -0700, Tom Tromey wrote:
"Ralf" == Ralf Corsepius rc040203@freenet.de writes:
Ralf> I don't have any reasons to trust this URL smolt sends it data too.
In principle I think this site should be controlled by the fedora project.
Why do you think are people disabling log-in prompts, forging/suppressing server id-strings, not using HINFO records in named etc. ?
.. for not exposing details to the public to prevent them from exposing them from avoidable unnecessarily vulnerabilities.
Not worth mentioning, jerks sneaking on connections, theft of the data base, connecting this data with data available from other sources and selling this data ...
This consideration alone is sufficient reason for me to classify smolt as non-acceptable.
I didn't look to see whether it is or not. But in any case IMO it ought to be approximately as trustworthy as the standard yum servers.
The smolt data looked quite nice to me. Good stuff to know.
Pardon, but you'd better never mention the word "security" in a Fedora context again ;)
Ralf
"Ralf" == Ralf Corsepius rc040203@freenet.de writes:
The smolt data looked quite nice to me. Good stuff to know.
Ralf> Pardon, but you'd better never mention the word "security" in a Fedora Ralf> context again ;)
Yeah. It's kind of hard to want to get involved again.
I understand you're more worried about people somehow getting your hardware profile than I am. That's even understandable. What I don't understand is why clicking "No" is not enough.
Tom
On Wed, 2007-01-31 at 17:11 -0700, Tom Tromey wrote:
"Ralf" == Ralf Corsepius rc040203@freenet.de writes:
The smolt data looked quite nice to me. Good stuff to know.
Ralf> Pardon, but you'd better never mention the word "security" in a Fedora Ralf> context again ;)
Yeah. It's kind of hard to want to get involved again.
I understand you're more worried about people somehow getting your hardware profile than I am. That's even understandable. What I don't understand is why clicking "No" is not enough.
It's probably a cultural difference.
In Europe, esp. in Germany, "data collectionitis of certain enterprises" and "data privacy" are _VERY_ _HOT_ political topics.
This manifests at various places, e.g. Germany having very restrictive laws on "data privacy" and the public/press/media's attitude being very hostile against anybody "collecting data". Also, probably unlike in many other parts of the world people around here are conscious about "data privacy" and often have a negative attitude against institutions collecting data.
Fact is, what you seem to take for granted, isn't in Germany. The legal details are complicated, it would require to be a laywer to elaborate, but German's laws mandate "explicit opt-in" and mandate explicit regulations on many other details (e.g. timed deletion of data) in many situations.
Though this isn't 100% legally mandated, this has lead to many people in Germany to consider "opt-in" as a matter of fairness and consider enterprises choosing "opt-out" to be playing foul and to be jerks. I had mentioned this aspect in a very early mail of this thread, but ... this had been pushed aside.
IMO, you and Fedora are vastly underestimating the situation. You understand you are playing with a loaded gun here and are better off taking concerns about it seriously.
Ralf
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 17:11 -0700, Tom Tromey wrote:
> "Ralf" == Ralf Corsepius rc040203@freenet.de writes:
The smolt data looked quite nice to me. Good stuff to know.
Ralf> Pardon, but you'd better never mention the word "security" in a Fedora Ralf> context again ;)
Yeah. It's kind of hard to want to get involved again.
I understand you're more worried about people somehow getting your hardware profile than I am. That's even understandable. What I don't understand is why clicking "No" is not enough.
It's probably a cultural difference.
In Europe, esp. in Germany, "data collectionitis of certain enterprises" and "data privacy" are _VERY_ _HOT_ political topics.
This manifests at various places, e.g. Germany having very restrictive laws on "data privacy" and the public/press/media's attitude being very hostile against anybody "collecting data". Also, probably unlike in many other parts of the world people around here are conscious about "data privacy" and often have a negative attitude against institutions collecting data.
Ok.
Fact is, what you seem to take for granted, isn't in Germany. The legal details are complicated, it would require to be a laywer to elaborate, but German's laws mandate "explicit opt-in" and mandate explicit regulations on many other details (e.g. timed deletion of data) in many situations.
So what you're saying is that the hardware profiler should be opt in only?
Though this isn't 100% legally mandated, this has lead to many people in Germany to consider "opt-in" as a matter of fairness and consider enterprises choosing "opt-out" to be playing foul and to be jerks. I had mentioned this aspect in a very early mail of this thread, but ... this had been pushed aside.
Ok
IMO, you and Fedora are vastly underestimating the situation. You understand you are playing with a loaded gun here and are better off taking concerns about it seriously.
I dislike people who corrupt everything I like with legal mumbo jumbo
On Thu, 2007-02-01 at 00:04 -0600, Arthur Pemberton wrote:
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 17:11 -0700, Tom Tromey wrote:
>> "Ralf" == Ralf Corsepius rc040203@freenet.de writes:
The smolt data looked quite nice to me. Good stuff to know.
Ralf> Pardon, but you'd better never mention the word "security" in a Fedora Ralf> context again ;)
Yeah. It's kind of hard to want to get involved again.
I understand you're more worried about people somehow getting your hardware profile than I am. That's even understandable. What I don't understand is why clicking "No" is not enough.
It's probably a cultural difference.
In Europe, esp. in Germany, "data collectionitis of certain enterprises" and "data privacy" are _VERY_ _HOT_ political topics.
Fact is, what you seem to take for granted, isn't in Germany. The legal details are complicated, it would require to be a laywer to elaborate, but German's laws mandate "explicit opt-in" and mandate explicit regulations on many other details (e.g. timed deletion of data) in many situations.
So what you're saying is that the hardware profiler should be opt in only?
Yes, this would be the minimum requirement to "not let Fedora to appear as jerks".
The more explicit and detailed, the better.
Ralf
Hi.
On Thu, 1 Feb 2007 00:04:51 -0600, Arthur Pemberton wrote:
So what you're saying is that the hardware profiler should be opt in only?
That is the long and short of it, I think (at least it is for me). Integrate it into firstboot, advertise it all you want, but please let it default to "no".
Mike mentioned a user clicking "Next, Next, Next" somewhere else in this thread (and most of us know this behaviour, I think). Someone doing this ought to be treated with the principle of least surprise (and default and good security).
Just clicking next will enable SeLinux, because it is good for the average user, and protects his machine. Just clicking next will enable the Firewall, because it is good for the user, and protects his machine. Just clicking next will require the user to enter a root password, and create an account (during firstboot, correct me if I'm wrong) to work as.
In the same line I think that the default for sending this hardware information ought to be no.
On Thu, 2007-02-01 at 08:35 +0100, Ralf Ertzinger wrote:
Hi.
On Thu, 1 Feb 2007 00:04:51 -0600, Arthur Pemberton wrote:
So what you're saying is that the hardware profiler should be opt in only?
That is the long and short of it, I think (at least it is for me). Integrate it into firstboot, advertise it all you want, but please let it default to "no".
Mike mentioned a user clicking "Next, Next, Next" somewhere else in this thread (and most of us know this behaviour, I think). Someone doing this ought to be treated with the principle of least surprise (and default and good security).
Just clicking next will enable SeLinux, because it is good for the average user, and protects his machine. Just clicking next will enable the Firewall, because it is good for the user, and protects his machine. Just clicking next will require the user to enter a root password, and create an account (during firstboot, correct me if I'm wrong) to work as.
In the same line I think that the default for sending this hardware information ought to be no.
It is. To quote Mike, 'It defaults to no with a "are you sure you mean no" dialog.' Which means it is opt-in, not opt-out. Which means this whole debate is pointless.
On Thu, Feb 01, 2007 at 06:46:19AM +0100, Ralf Corsepius wrote:
Fact is, what you seem to take for granted, isn't in Germany. The legal details are complicated, it would require to be a laywer to elaborate, but German's laws mandate "explicit opt-in" and mandate explicit regulations on many other details (e.g. timed deletion of data) in many situations.
The UK likewise, although they are hopeless at enforcing it, especially when government is (as usual) the offender. Any contract based approach the same would apply as contract normally can only be created by active acceptance (I cannot for example say "I'll sell you a car for $250,000 unless you say you don't want it" and expect that to be an enforcable contract)
Thus from a simple practical "what is allowed" point of view, personal data collection must be opt-in
IMO, you and Fedora are vastly underestimating the situation. You understand you are playing with a loaded gun here and are better off taking concerns about it seriously.
Agreed.
Alan
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 11:10 -0700, Tom Tromey wrote:
> "Ralf" == Ralf Corsepius rc040203@freenet.de writes:
Ralf> I don't have any reasons to trust this URL smolt sends it data too.
In principle I think this site should be controlled by the fedora project.
Why do you think are people disabling log-in prompts, forging/suppressing server id-strings, not using HINFO records in named etc. ?
No idea what you're talking about, and I consider myself somewhat paranoid.
.. for not exposing details to the public to prevent them from exposing them from avoidable unnecessarily vulnerabilities.
Well I guess the public could look at the large textbox with the data that could be sent, or open up ethereal to watch the unencrypted data....or they could just not click 'yes'.
Not worth mentioning, jerks sneaking on connections, theft of the data base, connecting this data with data available from other sources and selling this data ...
We're still talking about data which contains solely of hardware information which is individually publicly available, but collectively somewhat unique to a computer right?
This consideration alone is sufficient reason for me to classify smolt as non-acceptable.
Okay. But your non-logical red-herring field arguments are getting somewhat annoying.
I didn't look to see whether it is or not. But in any case IMO it ought to be approximately as trustworthy as the standard yum servers.
The smolt data looked quite nice to me. Good stuff to know.
Pardon, but you'd better never mention the word "security" in a Fedora context again ;)
Now that's just uncalled for.
Ralf
Arthur
On Wed, 2007-01-31 at 20:00 -0600, Arthur Pemberton wrote:
On 1/31/07, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2007-01-31 at 11:10 -0700, Tom Tromey wrote:
>> "Ralf" == Ralf Corsepius rc040203@freenet.de writes:
Ralf> I don't have any reasons to trust this URL smolt sends it data too.
In principle I think this site should be controlled by the fedora project.
Why do you think are people disabling log-in prompts, forging/suppressing server id-strings, not using HINFO records in named etc. ?
No idea what you're talking about, and I consider myself somewhat paranoid.
Many servers/service return an id-string identifying the version of a particular piece of SW - If this string is correct it, it provides clear information to which vulnerabilities it is likely to be vulnerable.
Therefore many server admins use faked id-strings or don't provide this kind of information.
Not worth mentioning, jerks sneaking on connections, theft of the data base, connecting this data with data available from other sources and selling this data ...
We're still talking about data which contains solely of hardware information which is individually publicly available,
It is not publicly available!! You don't know which hardware I am running nor how many machines I have, nor what I am using them for.
Otherwise smolt would not exist!
All you know is me using Fedora 6/i686 on a certain IP address.
Ralf
Ralf Corsepius rc040203@freenet.de wrote:
[...]
Many servers/service return an id-string identifying the version of a particular piece of SW - If this string is correct it, it provides clear information to which vulnerabilities it is likely to be vulnerable.
In my experience, the use of those for troubleshooting is much more important than any vulnerabilities exposed this way. Crackers (particularly automated attacks) usually just dive in, without any regard to any version strings. Besides, it is easy to guess (quite accurately, via something like nmap) what is at the other end. Hiding what you are running is an example of what is dismissed with the quip "Security through obscurity, isn't". It is uniformly regarded as almost completely useless. Fix the vulnerabilities, don't pretend they aren't there.
Therefore many server admins use faked id-strings or don't provide this kind of information.
That is detrimental to legitimate uses, and stops no cracker.
On Thu, 2007-02-01 at 01:05 -0300, Horst H. von Brand wrote:
Ralf Corsepius rc040203@freenet.de wrote:
[...]
Many servers/service return an id-string identifying the version of a particular piece of SW - If this string is correct it, it provides clear information to which vulnerabilities it is likely to be vulnerable.
In my experience, the use of those for troubleshooting is much more important than any vulnerabilities exposed this way. Crackers (particularly automated attacks) usually just dive in, without any regard to any version strings. Besides, it is easy to guess (quite accurately, via something like nmap) what is at the other end. Hiding what you are running is an example of what is dismissed with the quip "Security through obscurity, isn't".
It will surprise you: I share this opinion.
Nevertheless, it's still seems pretty common practice.
It is uniformly regarded as almost completely useless. Fix the vulnerabilities, don't pretend they aren't there.
I've recently read an article, claiming that most server attacks these days would be quite simple ("Is this a win server? If yes, attack, if no stop the attack.) because the overall amount of "easy to intrude, wide-open, high-bandwith home-servers" would make deep crack attacks against "real servers" less attractive.
This article also claimed that there is a market for people collecting, validating and selling such "potentially vulnerable" addresses esp. to spammers.
This would indicate the issue is less "not to pretend to have a bug fixed", but to let a machine appear unattractive for being a candidate for a deeper attack.
Now, it's up to the beholder to draw his conclusions. Is a machine identifying as "Fedora linux i386" or "WinServer XYZ" or not providing an id is more likely to be attacked? - I don't know.
Therefore many server admins use faked id-strings or don't provide this kind of information.
That is detrimental to legitimate uses,
Legitimate uses should not need them at all.
and stops no cracker.
True. Real crackers will probe and find out.
Ralf
Ralf Corsepius rc040203@freenet.de wrote:
On Thu, 2007-02-01 at 01:05 -0300, Horst H. von Brand wrote:
Ralf Corsepius rc040203@freenet.de wrote:
[...]
Many servers/service return an id-string identifying the version of a particular piece of SW - If this string is correct it, it provides clear information to which vulnerabilities it is likely to be vulnerable.
In my experience, the use of those for troubleshooting is much more important than any vulnerabilities exposed this way. Crackers (particularly automated attacks) usually just dive in, without any regard to any version strings. Besides, it is easy to guess (quite accurately, via something like nmap) what is at the other end. Hiding what you are running is an example of what is dismissed with the quip "Security through obscurity, isn't".
It will surprise you: I share this opinion.
Nevertheless, it's still seems pretty common practice.
Yes, as the saying here goes, if dumb people could fly, you'd never see the sun.
It is uniformly regarded as almost completely useless. Fix the vulnerabilities, don't pretend they aren't there.
I've recently read an article, claiming that most server attacks these days would be quite simple ("Is this a win server? If yes, attack, if no stop the attack.) because the overall amount of "easy to intrude, wide-open, high-bandwith home-servers" would make deep crack attacks against "real servers" less attractive.
Why? Most attacks go after "easy targets" (obviously), mostly because they are after numbers of anonymous machines, not particular machines. And the most realiable way to find out if something is an crackable target or not is just to try the attack. Fell for one recently, on rawhide PAM got broken and random passwords worked against disabled accounts. Hole lasted less than a day, but "just try stupid passwords against common account names over SSH" got them into an otherwise well protected machine. Crackers have almost unlimited computing power at their disposal (other cracked machines by the score), so careful scouting before a planned attack isn't needed at all.
That doesn't mean deep attacks aren't going on, but they are much less visible overall (because they are few in between, better planed (and thus less easy to detect), and many targets have a high embarrasment factor to booth).
This article also claimed that there is a market for people collecting, validating and selling such "potentially vulnerable" addresses esp. to spammers.
Sure thing.
This would indicate the issue is less "not to pretend to have a bug fixed", but to let a machine appear unattractive for being a candidate for a deeper attack.
Now, it's up to the beholder to draw his conclusions. Is a machine identifying as "Fedora linux i386" or "WinServer XYZ" or not providing an id is more likely to be attacked? - I don't know.
I'd guess it makes very little difference.
Therefore many server admins use faked id-strings or don't provide this kind of information.
That is detrimental to legitimate uses,
Legitimate uses should not need them at all.
They do. Why doesn't that MTA blackhole mail from here? Oh, yet another badly configured Trend Micro anti-spam thingie. Grelisting stops all mail from some.site.org? An Exchange who hasn't got a clue about 400 error messages. Those are just two recent examples here. Yes, standards are terrific, but next to nobody implements them correctly, and knowing what you are talking to goes a long way to finding out why things break.
and stops no cracker.
True. Real crackers will probe and find out.
Or just dive in just in case.
On Wednesday 31 January 2007 20:46, Ralf Corsepius wrote:
Not worth mentioning, jerks sneaking on connections, theft of the data base, connecting this data with data available from other sources and selling this data ...
Don't forget hacking the Gibson.
On Wed, 2007-01-31 at 18:54 +0100, Ralf Corsepius wrote:
I'll pretty soon add an "Obsoletes: smolt" into the base package of my local repos.
No problem, you can do whatever you like - but I think smolt is a really good idea, and the various different opt-in concerns have been settled.
Seriously, if you don't want to send your data to the smolt server, then just keep the default to no. I really don't see what the big problem is.
Richard.
Ralf Corsepius wrote:
It unattendedly collects various data which is not publically available from a local machine => SPY-WARE
It only does so if you explicitly select the "Yes" option. Otherwise, NOTHING IS SENT WITHOUT YOUR PERMISSION. That's about as simple as it can be said...
Connecting this information with IP-numbers opens many opportunities for abuse => Opens many chances to privacy breaches.
IP addresses and other personally-identifable information is not sent, only the hardware listing.
You have this (BTW: absolutely not unique and forgable) hardware id in connection with IP-numbers. This allows backtracking.
Only if you tell others the UUID stored on your computer. This UUID is not sent as part of the data report, as I understand it.
Having a script that is not being run automatically (not used by first boot), but being run at user-request as part of eg. a bug-report (similar to bug-buddy) is a completely different topic.
No, it's virtually the same thing: Nothing happens without the user's explicit consent.
There is not way to convince me about such spy-ware. If you want to collect statics with an opt-in, you can achieve the same by launching a counter website.
Fine, then according to your "definition," Yum and virtually every web browser are all also spyware, among others. They also send with their requests your hostname/IP information, User-Agent information, timestamp, etc.
On Wednesday 31 January 2007 11:54, Ralf Corsepius wrote:
On Wed, 2007-01-31 at 11:32 -0600, Dennis Gilmore wrote:
it is not registration, it is not spy ware.
It unattendedly collects various data which is not publically available from a local machine => SPY-WARE
where does it do this? right now we are wanting to add it to the default install and ask the user to submit a profile. the profile is sent ONCE ONLY you are free to not select and install smolt at all or say no to sending your profile. I generally don't install firstboot.
Connecting this information with IP-numbers opens many opportunities for abuse => Opens many chances to privacy breaches.
IP's are only stored in the web logs same as any other web service.
I don't have any reasons to trust this URL smolt sends it data too.
it is a voluntary hardware profile. there is no way to know that a profile is yours unless you give me your unique hardware id that is generated on your system at package install time.
You have this (BTW: absolutely not unique and forgable) hardware id in connection with IP-numbers. This allows backtracking.
It was never claimed that the ID will be unique where is the ip ? its not sent in the data. the only place it exists on the back end is in the web logs.
You might have heard about the fuzz HW CPU-ID had caused in the past?
This will help fedora in many ways.
I guess, I don't have to mention: My opinion differs very much.
Tell me how it will not help. You have not done anything to convince me that I see this the wrong way and you have done nothing to prove your point.
it is opt-in you can choose to install or not install smolt.
Mike asked about making installation the default. That's why I am so embarrassed.
Having a script that is not being run automatically (not used by first boot), but being run at user-request as part of eg. a bug-report (similar to bug-buddy) is a completely different topic.
thats how it works. you really have not looked at this in any rational sane manner have you. the firstboot module does not just send your profile. it gives you the option to opt in. you can send your profile by yourself at any time you choose
Feel free to look at the code. there is no package list sent, no ip, no anything that can be associated to you without you giving me your id.
I'll pretty soon add an "Obsoletes: smolt" into the base package of my local repos.
you are free to not install or if you do remove smolt at any time of your choosing
And again to re-iterate it is entirely voluntary "you choose" to submit or not your profile
OK, I will have a look at the sources and look if something has changed since it was under review. At that time I did not notice any opt-in, but noticed a scripts being run at installation time.
%post if ! [ -f %{_sysconfdir}/sysconfig/hw-uuid ] then /bin/cat /proc/sys/kernel/random/uuid > %{_sysconfdir}/sysconfig/hw-uuid /bin/chmod 0644 %{_sysconfdir}/sysconfig/hw-uuid /bin/chown root:root %{_sysconfdir}/sysconfig/hw-uuid fi the Id is generated and saved on the local system if it doesnt exist. again its not rocket science and doesnt attempt to be globally unique
In this particular case, I'll continue to be VERY stubborn.
There is not way to convince me about such spy-ware. If you want to collect statics with an opt-in, you can achieve the same by launching a counter website.
Ralf
Mike McGrath (mmcgrath@fedoraproject.org) said:
*Note: this is not LHCP, which is going to be a much larger project. Smolt has a much smaller scope and will ultimately (hopefully) be replaced by LHCP when it is ready.
So, the issue I see is that the data appears to be stored as HAL descriptive strings - these could change over time. Storing it as vendor/id pairs might be more flexible.
(Or is this actually done that way, and the display on the website is what's doing the conversion?)
Bill
On 1/31/07, Bill Nottingham notting@redhat.com wrote:
Mike McGrath (mmcgrath@fedoraproject.org) said:
*Note: this is not LHCP, which is going to be a much larger project. Smolt has a much smaller scope and will ultimately (hopefully) be replaced by LHCP when it is ready.
So, the issue I see is that the data appears to be stored as HAL descriptive strings - these could change over time. Storing it as vendor/id pairs might be more flexible.
(Or is this actually done that way, and the display on the website is what's doing the conversion?)
They're presently being pulled from the hardware object created using the RHN client tools. I'll look to see what it would take to get vendor/id pairs.
-Mike
Mike McGrath wrote:
On 1/31/07, Bill Nottingham notting@redhat.com wrote:
Mike McGrath (mmcgrath@fedoraproject.org) said:
*Note: this is not LHCP, which is going to be a much larger project. Smolt has a much smaller scope and will ultimately (hopefully) be replaced by LHCP when it is ready.
So, the issue I see is that the data appears to be stored as HAL descriptive strings - these could change over time. Storing it as vendor/id pairs might be more flexible.
(Or is this actually done that way, and the display on the website is what's doing the conversion?)
They're presently being pulled from the hardware object created using the RHN client tools. I'll look to see what it would take to get vendor/id pairs.
Ouch. The way RHN currently deals with hardware is pretty painful, at least server-side; a bunch of us are interested in pursuing something more HAL'ish, drop me a line if you're interested, and maybe we can see if there are points of commonality.
--Bret
Bret McMillan wrote:
Mike McGrath wrote:
On 1/31/07, Bill Nottingham notting@redhat.com wrote:
Mike McGrath (mmcgrath@fedoraproject.org) said:
*Note: this is not LHCP, which is going to be a much larger project. Smolt has a much smaller scope and will ultimately (hopefully) be replaced by LHCP when it is ready.
So, the issue I see is that the data appears to be stored as HAL descriptive strings - these could change over time. Storing it as vendor/id pairs might be more flexible.
(Or is this actually done that way, and the display on the website is what's doing the conversion?)
They're presently being pulled from the hardware object created using the RHN client tools. I'll look to see what it would take to get vendor/id pairs.
Ouch. The way RHN currently deals with hardware is pretty painful, at least server-side; a bunch of us are interested in pursuing something more HAL'ish, drop me a line if you're interested, and maybe we can see if there are points of commonality.
--Bret
As we'll probably be reusing a lot of that hardware probing code in LHCP as well i'd be really interested about what/how we can do that better, so it would be awesome if you could get me in the loop. Our current code in LHCP is very basic for now (just a prove of concept), so doing that the same way in smolt and LHCP should be really benefical.
Read ya, Phil
On ons, 2007-01-31 at 09:26 -0600, Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Rock on.. count me in!
Do we as a community want to include this by default in Fedora 7?
Absolutely, this is a great tool for finding not only well known hardware but also troublesome combinations. I imagine long term this would be a good addition to bugreports and I'm all for making the nice developers lives easier when my shit breaks.
- David Nielsen
Mike McGrath wrote :
You can have your machine send its stats by installing smolt with yum and typing "smoltSendProfile"
Done that, worked great for my home machines, but apparently my machines sitting in the office behind a transparent squid proxy can't seem to complete the sending, and hang after a few "sent device data" (never the same number). Strange.
I also saw some 500 errors from the CherryPy server in tracebacks... certainly some temporary errors on the server side, but you might want to handle those a bit more gracefully in the client ;-)
Hmmm, now I got some "X-Squid-Error: ERR_READ_ERROR 104" headers and "HTTP Error 500: Server: Squid/2.4.STABLE7" errors from my proxy :-(
Matthias
On 1/31/07, Matthias Saou thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net wrote:
Mike McGrath wrote : I also saw some 500 errors from the CherryPy server in tracebacks... certainly some temporary errors on the server side, but you might want to handle those a bit more gracefully in the client ;-)
Hmmm, now I got some "X-Squid-Error: ERR_READ_ERROR 104" headers and "HTTP Error 500: Server: Squid/2.4.STABLE7" errors from my proxy :-(
Fun, i'll take a look :-D
-Mike
mmcgrath@fedoraproject.org ("Mike McGrath") writes:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
mmh... what the heck is this tool doing? When I try to install it on my servers I get
----------- Installing: smolt noarch 0.6.1-3.fc6 extras 123 k Installing for dependencies: at i386 3.1.8-84.fc6 updates 55 k bc i386 1.06-21 base 106 k beecrypt i386 4.1.2-10.1.1 base 116 k binutils i386 2.17.50.0.6-2.fc6 updates 2.9 M bzip2 i386 1.0.3-3 base 48 k cairo i386 1.2.6-1.fc6 updates 406 k cups i386 1:1.2.7-1.7.fc6 updates 2.8 M cups-libs i386 1:1.2.7-1.7.fc6 updates 181 k dbus i386 1.0.1-9.fc6 updates 471 k dbus-glib i386 0.70-6.fc6 updates 152 k dbus-python i386 0.70-6 base 161 k ed i386 0.3-0.fc6 updates 54 k elfutils-libelf i386 0.125-1.fc6 updates 52 k expat i386 1.95.8-8.2.1 base 77 k file i386 4.17-8 base 319 k fontconfig i386 2.4.1-3.fc6 base 175 k freetype i386 2.2.1-16.fc6 updates 312 k gettext i386 0.14.6-4.fc6 updates 1.4 M gnutls i386 1.4.1-2 base 349 k groff i386 1.18.1.1-11.1 base 1.9 M libICE i386 1.0.1-2.1 base 53 k libSM i386 1.0.1-3.1 base 27 k libX11 i386 1.0.3-5.fc6 updates 793 k libXau i386 1.0.1-3.1 base 18 k libXdmcp i386 1.0.1-2.1 base 19 k libXext i386 1.0.1-2.1 base 36 k libXft i386 2.1.10-1.1 base 44 k libXi i386 1.0.1-3.1 base 25 k libXrender i386 0.9.1-3.1 base 27 k libXt i386 1.0.2-3.1.fc6 base 174 k libXxf86vm i386 1.0.1-3.1 base 14 k libdrm i386 2.3.0-1.fc6 updates 24 k libgcrypt i386 1.2.3-1 base 174 k libgpg-error i386 1.4-2 base 60 k libjpeg i386 6b-37 base 139 k libpng i386 2:1.2.10-7 base 242 k libtiff i386 3.8.2-6.fc6 base 312 k libuser i386 0.54.7-2 base 434 k libxml2 i386 2.6.27-1.FC6 updates 807 k libxml2-python i386 2.6.27-1.FC6 updates 705 k m4 i386 1.4.5-4 updates 133 k make i386 1:3.81-1.1 base 465 k man i386 1.6d-2.fc6 updates 263 k mesa-libGL i386 6.5.1-8.fc6 updates 9.7 M neon i386 0.25.5-5.1 base 96 k pango i386 1.14.8-1.fc6 updates 330 k paps i386 0.6.6-17.fc6 updates 32 k passwd i386 0.73-1 base 20 k patch i386 2.5.4-29.2.2 base 64 k pax i386 3.4-1.2.2 base 63 k redhat-lsb i386 3.1-11 base 21 k rpm i386 4.4.2-32 base 639 k rpm-libs i386 4.4.2-32 base 973 k sqlite i386 3.3.6-2 base 213 k time i386 1.7-27.2.2 base 17 k tmpwatch i386 2.9.7-1.1 base 18 k vixie-cron i386 4:4.1-64.fc6 base 89 k xorg-x11-filesystem noarch 7.1-2.fc6 base 5.5 k ----------
The generated output does not seem to require more than bash, gawk, curl (for sending the report) and some hardware diagnostic tools (dmidecode, lspci...).
Enrico
On Wed, 2007-01-31 at 13:32 -0600, Tom 'spot' Callaway wrote:
Hey, this is 3D hardware profiling. Strap in and hold on.
I just ran smoltSendProfile and it just started sending data without asking me "is this okay (y/N)?" - this is with the version in extras.
Not an issue for me, but might be one to sort before F7.
Richard.
On Wednesday 31 January 2007 14:03, Richard Hughes wrote:
On Wed, 2007-01-31 at 13:32 -0600, Tom 'spot' Callaway wrote:
Hey, this is 3D hardware profiling. Strap in and hold on.
I just ran smoltSendProfile and it just started sending data without asking me "is this okay (y/N)?" - this is with the version in extras.
Not an issue for me, but might be one to sort before F7.
Richard.
there is always run smoltPrint to just view your profile without sending
On Wednesday 31 January 2007 14:28, Enrico Scholz wrote:
mmh... what the heck is this tool doing? When I try to install it on my servers I get
Run this again with debug. Most likely smolt requires something which in turn has some heafty requires.
On 1/31/07, Jesse Keating jkeating@redhat.com wrote:
On Wednesday 31 January 2007 14:28, Enrico Scholz wrote:
mmh... what the heck is this tool doing? When I try to install it on my servers I get
Run this again with debug. Most likely smolt requires something which in turn has some heafty requires.
redhat-lsb I might get rid of that. Does anyone here care about the output from lsb_release?
-Mike
At 12:21 PM 1/31/2007, Jesse Keating wrote:
On Wednesday 31 January 2007 15:04, Mike McGrath wrote:
redhat-lsb  I might get rid of that.  Does anyone here care about the output from lsb_release?
Does anybody care about LSB _at_ _all_ ?
Yes, we care about LSB. What is Fedora Project and RedHat's position on LSB?
Thanks.
On Wednesday 31 January 2007 15:36, Daniel Yek wrote:
Yes, we care about LSB. What is Fedora Project and RedHat's position on LSB?
That it sounds like almost a useful thing, but in practice its practically useless?
Oh wait, that's just my opinion.
2:04pm Mike McGrath said:
On 1/31/07, Jesse Keating jkeating@redhat.com wrote:
On Wednesday 31 January 2007 14:28, Enrico Scholz wrote:
mmh... what the heck is this tool doing? When I try to install it on my servers I get
Run this again with debug. Most likely smolt requires something which in turn has some heafty requires.
redhat-lsb I might get rid of that. Does anyone here care about the output from lsb_release?
Negative.
On another note, I just fired up smolt on a Xen Dom0 and noticed that it reports varying values for systemMemory depending on how many DomUs are running. If it's trying to report hardware, then it should look beyond the hypervisor in this case.
And of course, running smolt in a DomU is almost pointless.
../C
Mike McGrath (mmcgrath@fedoraproject.org) said:
redhat-lsb I might get rid of that. Does anyone here care about the output from lsb_release?
Realistically, for something like this, I'd track the distro release, and let the distro release <-> LSB release association be elsewhere.
Bill
On Thu, 2007-02-01 at 11:12 -0500, Bill Nottingham wrote:
Mike McGrath (mmcgrath@fedoraproject.org) said:
redhat-lsb I might get rid of that. Does anyone here care about the output from lsb_release?
Realistically, for something like this, I'd track the distro release, and let the distro release <-> LSB release association be elsewhere.
You could always run lsb_release if it exists only (but it's pretty pointless I guess).
Nils
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
For more information on smolt see:
https://hosted.fedoraproject.org/projects/smolt/wiki and https://hosted.fedoraproject.org/projects/smolt/wiki/Scope
Current stats can be found at:
http://smolt.fedoraproject.org/stats
You can have your machine send its stats by installing smolt with yum and typing "smoltSendProfile"
*Note: this is not LHCP, which is going to be a much larger project. Smolt has a much smaller scope and will ultimately (hopefully) be replaced by LHCP when it is ready.
Does the profile give any indication whether the hardware is installed and working properly (or providing some limited functionality) or is it just cataloging its existence?
If it isn't verifying that what is listed is actually functioning as it should then I don't really see the value of collecting all that data at first boot. It would be just giving a statistical sampling of hardware that exists in the world ... however broken it may be on Linux. It also wouldn't tell you anything about hardware that is so broken and unsupported that it is not even detected.
It would be far more valuable as an automated tool to send in consistent data along with a bug report.
If it does do some health/functionality checking of the driver for hardware then including it in firstboot makes a lot more sense.
/Mike
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote: Does the profile give any indication whether the hardware is installed and working properly (or providing some limited functionality) or is it just cataloging its existence?
The LHCP guys are doing this. Smolt has a much smaller scope.
If it isn't verifying that what is listed is actually functioning as it should then I don't really see the value of collecting all that data at first boot. It would be just giving a statistical sampling of hardware that exists in the world ... however broken it may be on Linux. It also wouldn't tell you anything about hardware that is so broken and unsupported that it is not even detected.
It would be far more valuable as an automated tool to send in consistent data along with a bug report.
Extremely valuable. But there's only so many hours in the day. The LHCP guys are working on this as well.
-Mike
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote:
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
Does the profile give any indication whether the hardware is installed and working properly (or providing some limited functionality) or is it just cataloging its existence?
The LHCP guys are doing this. Smolt has a much smaller scope.
I think that the LHCP idea is fantastic!
So if Smolt does not give any indication that hardware is working, it seems only useful when talking with tech support/bugzilla and you need a simple way to gather all the data on your machine to give to someone more knowledgeable to figure out.
So what is derived from putting it into firstboot and collecting statistics that won't tell you anything other than the range of hardware that exists in the world? What the motivation is for collecting this data from everyone? I see Smolt as a useful tool for interactive troubleshooting but I can see much beneficial use for the data collected. Can you offer some examples?
/Mike
On Wed, 2007-01-31 at 21:48 -0500, Michael Wiktowy wrote:
So what is derived from putting it into firstboot and collecting statistics that won't tell you anything other than the range of hardware that exists in the world? What the motivation is for collecting this data from everyone? I see Smolt as a useful tool for interactive troubleshooting but I can see much beneficial use for the data collected. Can you offer some examples?
For one thing, it gives us data on what hardware is the most commonly in use by Fedora users. This can help to focus testing, hardware purchases as well as some help when dealing with hardware vendors to improve drivers (or even write them in the first place)
Jeremy
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
So if Smolt does not give any indication that hardware is working, it seems only useful when talking with tech support/bugzilla and you need a simple way to gather all the data on your machine to give to someone more knowledgeable to figure out.
So what is derived from putting it into firstboot and collecting statistics that won't tell you anything other than the range of hardware that exists in the world? What the motivation is for collecting this data from everyone? I see Smolt as a useful tool for interactive troubleshooting but I can see much beneficial use for the data collected. Can you offer some examples?
/Mike
Tons.
Hey Dell, did you know (insert number) people are using Fedora Linux on your systems? Mind helping us with driver support?
Hey Nvidia, We've seen (insert number) people trying to use the nvidia cards. Unfortunately because your driver is not open source, many of them are unable to use all the features of your card.
Hey dev's (insert popular hardware) we had no idea this many people were using this setup. Lets get one and test everything for them.
Hey dev's almost no one is using (insert un-popular arch here) perhaps we should think about making it a secondary arch.
Hey (insert popular university here) we've got a TON of users now, would you be interested in partnering with us to host some things? Perhaps we could propose some curriculum for your CS department?
Depending on how the LHCP development goes we may add a "doesn't or does" work feature. But its not there right now. For Smolt I wanted to stay away from feature creep :-D Its initial inception was just for Metrics but as demands come about, we'll see.
-Mike
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote:
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
Can you offer some examples?
Tons.
<snip tons of good examples>
Depending on how the LHCP development goes we may add a "doesn't or does" work feature. But its not there right now. For Smolt I wanted to stay away from feature creep :-D Its initial inception was just for Metrics but as demands come about, we'll see.
OK ... I'm sold. I was under the impression that it was aggregating all the stats together on the server but it you (and hopefully all the users offering their personal data) are able to have complex queries like that (i.e. the association of which hardware is on which box), that is valuable from a marketing/strategic partnership perspective.
Is it only in the FC6 yum repo at the moment? I tried installing it on my FC4 box and yum couldn't find it.
/Mike
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote: Is it only in the FC6 yum repo at the moment? I tried installing it on my FC4 box and yum couldn't find it.
Watch for these in the next couple of days. I'm hoping to get FC3, 4 and 5 out. I'm not sure if I can get them into the yum repo (there's policies and FC3 and 4 are EOL'd) but you'll be able to download it and install it directly.
-Mike
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote:
Watch for these in the next couple of days. I'm hoping to get FC3, 4 and 5 out. I'm not sure if I can get them into the yum repo (there's policies and FC3 and 4 are EOL'd) but you'll be able to download it and install it directly.
Count on your "Number of people still using FC4" numbers being skewed ;]
I thought EOL meant no new official security updates, not a ban on developers putting their goods into Extras. Hmmm. I was planning on hopping back on the treadmill soon anyways ... after I do some research on the hardware compatibility and proper configuration of my Sil 3112 RAID controller ... hopefully you can tell me soon how many others out there have one of those :]
/Mike
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
Count on your "Number of people still using FC4" numbers being skewed ;]
I thought EOL meant no new official security updates, not a ban on developers putting their goods into Extras. Hmmm. I was planning on hopping back on the treadmill soon anyways ... after I do some research on the hardware compatibility and proper configuration of my Sil 3112 RAID controller ... hopefully you can tell me soon how many others out there have one of those :]
I'm not sure what the official policy is actually or even if there is one. But I do know the builders have disabled fc3 and 4 builds.
-Mike
"MM" == Mike McGrath mmcgrath@fedoraproject.org writes:
MM> I'm not sure what the official policy is actually or even if there MM> is one. But I do know the builders have disabled fc3 and 4 MM> builds.
You can't branch new packages to FC3 and FC4 (nor anything older, obviously), but you can still commit things to existing old branches if you like. (There's still one package that I keep updated because I still need it on FC3 and it's easier to maintain everything together.) And of course since there's no buildsys for FC3 and FC4.
- J<
Mike McGrath wrote:
On 1/31/07, Michael Wiktowy michael.wiktowy@gmail.com wrote:
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote: Does the profile give any indication whether the hardware is installed and working properly (or providing some limited functionality) or is it just cataloging its existence?
The LHCP guys are doing this. Smolt has a much smaller scope.
Exactly. I've already received some really valuable feedback to various components and we'll be integrating as many of them as possible.
As we'll also be trying to work with the smolt guys as closely together as possible we hope to get to a point where the manual testing you can do with LHCP can be integrated with the data collected from smolt. But it'll take some more time until LHCP reaches that point.
Read ya, Phil
Mike McGrath wrote :
Current stats can be found at:
Three quick comments :
- The current CPU vendor percentages seem wrong (12% Intel, 12% AMD, all others below 1%... far from 100% total!) - CPU cores seem to be counted as CPUs. Maybe HT CPUs are also counted as multiple CPUs. It would be best to try and separate those informations (real CPUs, HTs, cores). - Some "< 512" should probably be "=< 512".
Anyway, it's pretty cool to see all those stats :-)
Matthias
On 2/1/07, Matthias Saou thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net wrote:
Mike McGrath wrote :
- The current CPU vendor percentages seem wrong (12% Intel, 12% AMD, all others below 1%... far from 100% total!)
- CPU cores seem to be counted as CPUs. Maybe HT CPUs are also counted as multiple CPUs. It would be best to try and separate those informations (real CPUs, HTs, cores).
- Some "< 512" should probably be "=< 512".
re cpu vendor. Yeah.. just ignore that for now, I've completely horked up the query it uses to get that stuff. I should probably comment it out.
Re: HT. I might have to come up with something clever there. I'm also wondering if we should just leave it the way the host sees it. Someone mentioned that speed was getting reported as cpuspeed reports it, not maximum.
-Mike
Mike McGrath wrote :
- The current CPU vendor percentages seem wrong (12% Intel, 12% AMD, all others below 1%... far from 100% total!)
- CPU cores seem to be counted as CPUs. Maybe HT CPUs are also counted as multiple CPUs. It would be best to try and separate those informations (real CPUs, HTs, cores).
- Some "< 512" should probably be "=< 512".
re cpu vendor. Yeah.. just ignore that for now, I've completely horked up the query it uses to get that stuff. I should probably comment it out.
It would be interesting to get the real AMD vs. Intel numbers :-)
Re: HT. I might have to come up with something clever there. I'm also wondering if we should just leave it the way the host sees it. Someone mentioned that speed was getting reported as cpuspeed reports it, not maximum.
I can confirm this. A dual dual-core 5140 2.33GHz system gets reported : numCPUs: 4 CPUSpeed: 1999 As it is currently running at 2GHz indeed (ondemand governor).
Matthias
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote:
Current stats can be found at:
http://smolt.fedoraproject.org/stats
You can have your machine send its stats by installing smolt with yum and typing "smoltSendProfile"
Is there any mechanism in place to prevent bogus profiles being submitted?
It would be stupid and malicious for people to do that but there is no shortage of stupid malicious people. Also there have been people who already edited their kernel dumps to hide that they were using binary-only modules when seeking help. So that would be another class of people who might do this. I can't really think of a way to prevent this sort of thing in an open system but at least there are way to harden against it and detect some tampering and be able to purge it from the database after.
Things I can think of to harden: - flood protection: limit to one submission per time period per IP ... tar pitting might make massive corruption too tedious - whitelist of known hardware: might be hard to capture every single different string that could be generated by your hardware detection but at least some fields have a finite number of different things that it could be and might prevent a lot of "D3wd ... I 0wz0r yur 57475!!!" cpu architectures being submitted. - stats query subset of the whole: If you set up the stats query page to only include what the user wants to look for (rather than have global stats including everything submitted), then you have a human in the loop that can choose whether something looks fishy or not and whether they want to include it in their generated stats. Then the existence of vandalized stats won't matter since the users can easily exclude them from their stats. So the user can query "Out of the cpu architectures X, Y and Z, what percentage is X." as they don't care about the "l337" cpu type and don't want to include those in the total number.
Just some thoughts.
/Mike
Michael Wiktowy wrote:
On 1/31/07, Mike McGrath mmcgrath@fedoraproject.org wrote:
Current stats can be found at:
http://smolt.fedoraproject.org/stats
You can have your machine send its stats by installing smolt with yum and typing "smoltSendProfile"
Is there any mechanism in place to prevent bogus profiles being submitted?
When this was said, I got the image of some company padding the submitted profiles, so they could then say, "Look the number of people using our hardware is > than the number of people using their hardware!" and then trying to leverage that to some effect. Crazy, but there are people that hire people to go and edit Wikipedia into their favor.
Brent
Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
I can also see this as an extremely useful tool for IT-departments and companies trying to keep track of their hardware. So a nice feature would be to get a local copy of the smolt-server running, and then have all servers and workstations report to that server - either instead of or in addition to the fedora server.
That way it would be easy to keep track of which workstations have been upgraded with more RAM, what chipset the different servers have and so on.
Ofcourse one could also add a "module" for the local reporting that adds info such as ip and mac-address for network cards, different configuration parameters and so on.
Rgds.
On Thu, 2007-02-01 at 19:22 +0100, Ola Thoresen wrote:
Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
I can also see this as an extremely useful tool for IT-departments and companies trying to keep track of their hardware. So a nice feature would be to get a local copy of the smolt-server running, and then have all servers and workstations report to that server - either instead of or in addition to the fedora server.
That way it would be easy to keep track of which workstations have been upgraded with more RAM, what chipset the different servers have and so on.
Ofcourse one could also add a "module" for the local reporting that adds info such as ip and mac-address for network cards, different configuration parameters and so on.
+1 - that sounds like a very good idea.
-sv
seth vidal wrote:
On Thu, 2007-02-01 at 19:22 +0100, Ola Thoresen wrote:
Mike McGrath wrote:
Hey guys, smolt is in a state now where it can be released and tested by the general public. Currently smolt-firstboot has firstboot integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
I can also see this as an extremely useful tool for IT-departments and companies trying to keep track of their hardware. So a nice feature would be to get a local copy of the smolt-server running, and then have all servers and workstations report to that server - either instead of or in addition to the fedora server.
That way it would be easy to keep track of which workstations have been upgraded with more RAM, what chipset the different servers have and so on.
Ofcourse one could also add a "module" for the local reporting that adds info such as ip and mac-address for network cards, different configuration parameters and so on.
+1 - that sounds like a very good idea.
In the local use case, it might be nice to add something like tracking package installs as well (hmm, that sounds familiar for some reason...). Ditto the kickstart, install log, etc.
It could also be useful to send up the type of info found in sysreport. I think someone even started writing a module python based one at one point.
Adrian
On Wed, 2007-02-07 at 12:06 -0500, Adrian Likins wrote:
In the local use case, it might be nice to add something like tracking package installs as well (hmm, that sounds familiar for some reason...). Ditto the kickstart, install log, etc.
It could also be useful to send up the type of info found in sysreport. I think someone even started writing a module python based one at one point.
I ran this by a few folks at my office. They suggested:
- packages installed - services chkconfig'd on - daemons running
which all seemed like good ideas in the local use case.
-sv
On 2/7/07, seth vidal skvidal@linux.duke.edu wrote:
On Wed, 2007-02-07 at 12:06 -0500, Adrian Likins wrote:
In the local use case, it might be nice to add something like tracking package installs as well (hmm, that sounds familiar for some reason...). Ditto the kickstart, install log, etc.
It could also be useful to send up the type of info found in sysreport. I think someone even started writing a module python based one at one point.
I ran this by a few folks at my office. They suggested:
- packages installed
- services chkconfig'd on
- daemons running
which all seemed like good ideas in the local use case.
Cool, so I've got a few more things to harden in the public view. After that we can extend smolt and smoon (the local smolt) to do those things probably without many problems. I'm having a heck of a time getting the python dbus bindings to do what I want.
-Mike
I can also see this as an extremely useful tool for IT-departments and companies trying to keep track of their hardware. So a nice feature would be to get a local copy of the smolt-server running, and then have all servers and workstations report to that server - either instead of or in addition to the fedora server.
That way it would be easy to keep track of which workstations have been upgraded with more RAM, what chipset the different servers have and so on.
Ofcourse one could also add a "module" for the local reporting that adds info such as ip and mac-address for network cards, different configuration parameters and so on.
You should have a look à OCS NG : http://ocsinventory.sourceforge.net/
Client already in the Extras. I'm working on RPM for the servers...
Remi.