[lm-sensors] Submitting motherboard-specific support? (w/ attached

[lm-sensors] Submitting motherboard-specific support? (w/ attached

[Romain Dolbeau]

Hi,

I've (a long time ago) written an conf entry for my Supermicro H8DC8
(attached to this mail).

Since about forever, the wiki has been read-only, even in the Sandbox ;
what's the recommended way of submitting motherboard-specific 
configuration theses days?

-- 
Romain Dolbeau
<romain@dolbeau.org>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Juerg Haefliger]

And CC the list...

> Hi Romain,
>
>
> > Hi,
> >
> > I've (a long time ago) written an conf entry for my Supermicro H8DC8
> > (attached to this mail).
>
> Attachment is missing. If you send it again, I'll put it in the wiki.
>
>
> > Since about forever, the wiki has been read-only, even in the Sandbox ;
> > what's the recommended way of submitting motherboard-specific
> > configuration theses days?
>
> Send it to the list or open a ticket.
>
> ...juerg
>
>
> > --
> > Romain Dolbeau
> > <romain@dolbeau.org>
> >
> >
> > _______________________________________________
> > lm-sensors mailing list
> > lm-sensors@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> >
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Juerg Haefliger]

Hi Romain,


> Juerg Haefliger wrote:
>
> > Attachment is missing. If you send it again, I'll put it in the wiki.
>
> Here it comes, sorry about that.

Ok, it's in the wiki now.

> > Send it to the list or open a ticket.
>
> Open a ticket with the config files, or a ticket about the wiki?

Ticket with the config file.


> I've already done the later a while ago. By curiosity, what
> is the point of a read-only wiki? In particular the sandbox...

Not sure. You'd have to ask one of the maintainers (Jean, Marc?).

...juerg


> --
> Romain Dolbeau
> <romain.dolbeau@caps-entreprise.com>
>
>
> # settings for the supermicro H8DC8
> # here are the details supplied by the technical support:
> ##Bus Type = SMBus
> ##One WindBond W83627HF, One Analog Devices ADM1026
> ##
> ##Analog Devices ADM1026, Slave Address=0x2c (0x58 in 8-Bit format)
> ##===============================
> ##Fan1 Fan Speed, Offset 0x38           RPM\x1350000/8/Reading
> ##Fan2 Fan Speed, Offset 0x39           RPM\x1350000/8/Reading
> ##Fan3 Fan Speed, Offset 0x3a           RPM\x1350000/8/Reading
> ##Fan4 Fan Speed, Offset 0x3b           RPM\x1350000/8/Reading
> ##Fan5 Fan Speed, Offset 0x3c           RPM\x1350000/8/Reading
> ##Fan6 Fan Speed, Offset 0x3d           RPM\x1350000/8/Reading
> ##Fan7 Fan Speed, Offset 0x3e           RPM\x1350000/8/Reading
> ##Fan8 Fan Speed, Offset 0x3f           RPM\x1350000/8/Reading
> ##CPU1 Core Voltage, Offset 0x2d                Voltage=(Reading * 3)/256
> ##CPU2 Core Voltage, Offset 0x37                Voltage=(Reading * 2.5)/256
> ##+5VSB Voltage, offset 0x30            Voltage=(Reading * 6)/256
> ##+1.5V Voltage, offset 0x32            Voltage=(Reading * 3)/256
> ##+5V Voltage, offset 0x2c              Voltage=(Reading * 6.66)/256
> ##+12V Voltage, offset 0x2e             Voltage=(Reading * 16)/256
> ##-12V Voltage, offset 0x2f             Voltage=((Reading* 18.5)/256)-16
> ##DIMM Voltage, offset 0x33             Voltage=(Reading * 3)/256
> ##Battery Voltage, Offset 0x26
> ##Voltage=(((Reading-128)*2)/128)+2)
> ##System Temperature, Offset 0x1f               C=Reading
> ##CPU1 Temperature, Offset 0x28         C=Reading
> ##CPU2 Temperature, Offset 0x29         C=Reading
> ##Chassis Intrusion, Offset 0x23, BitMask@
> ##
> ##
> ##Power Supply Failure (From W82627HF), GP12
> #
> # Notes:
> # 1) no section for the W82627HF yet.
> # 2) the temperature min/max are ballpark estimate,
> #    you may need to fix them depening on your environment
> #    such as the setting of your air conditionner.
> # 3) According to the support, in11 and in12 (both +3.3V
> #    lines) aren't hooked up, yet they supply proper readings
> #    (as specified by the manufacturer of the chip for those
> #    lines).
> #    You may want to disable them.
> #
> # Originally written by Romain Dolbeau <romain@dolbeau.org>
> # Uses at your own risk !
>
> chip "adm1026-i2c-*-2c"
>
>    label fan0 "FAN0 Speed"
>    label fan1 "FAN1 Speed"
>    label fan2 "FAN2 Speed"
>    label fan3 "FAN3 Speed"
>    label fan4 "FAN4 Speed"
>    label fan5 "FAN5 Speed"
>    label fan6 "FAN6 Speed"
>    label fan7 "FAN7 Speed"
>
>    set fan0_div 8
>    set fan1_div 8
>    set fan2_div 8
>    set fan3_div 8
>    set fan4_div 8
>    set fan5_div 8
>    set fan6_div 8
>    set fan7_div 8
>
>    label in0 "+5VSB Voltage"
>    compute in0 @*2,@/2
>    set in0_min 5*0.90
>    set in0_max 5*1.1
>
>    ignore in1
>
>    label in2 "+1.5V Voltage"
>    set in2_min 1.5*0.95
>    set in2_max 1.5*1.05
>
>    label in3 "DIMM Voltage"
>    set in3_min 2.5*0.95
>    set in3_max 2.5*1.05
>
>    ignore in4
>    ignore in5
>    ignore in6
>
>    label in7 "CPU2 Core Voltage"
>    set in7_min 1.35*0.95
>    set in7_max 1.35*1.05
>
>    ignore in8
>    ignore in9
>
>    label in10 "Battery Voltage"
>    set in10_min 3*0.95
>    set in10_max 3*1.05
>
>    # for in11 & in12, see comments above
>    #ignore in11
>    #ignore in12
>
>    label in11 "3.3V Standby"
>    set in11_min 3.3*0.95
>    set in11_max 3.3*1.05
>
>    label in12 "3.3V Main"
>    set in12_min 3.3*0.95
>    set in12_max 3.3*1.05
>
>    label in13 "+5V Voltage"
>    set in13_min 5*0.95
>    set in13_max 5*1.05
>
>    label in14 "CPU1 Core Voltage"
>    set in14_min 1.35*0.95
>    set in14_max 1.35*1.05
>
>    label in15 "+12V Voltage"
>    set in15_min 12*0.95
>    set in15_max 12*1.05
>
>    label in16 "-12V Voltage"
>    set in16_max -12*0.95
>    set in16_min -12*1.05
>
>    label temp1 "System Temperature"
>    set temp1_min 18
>    set temp1_max 40
>    label temp2 "CPU1 Temperature"
>    set temp2_min 20
>    set temp2_max 45
>    label temp3 "CPU2 Temperature"
>    set temp3_min 20
>    set temp3_max 45
>
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Jean Delvare]

On Mon, 20 Aug 2007 10:27:34 -0700, Juerg Haefliger wrote:
> > I've already done the later a while ago. By curiosity, what
> > is the point of a read-only wiki? In particular the sandbox...
> 
> Not sure. You'd have to ask one of the maintainers (Jean, Marc?).

Because otherwise spambots create random accounts and spam all the wiki
pages and tickets. If a future version of track implements more strict
account creations (as bugzilla does for example) then we can allow
users to create their own account and edit the wiki, but not before
then.

Also, storing the configuration files in the wiki is probably the worse
thing we could come up with in these conditions, but hopefully we'll
have something better shortly after lm-sensors 3.0.1 is released.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Hans de Goede]

Jean Delvare wrote:
> 
> Also, storing the configuration files in the wiki is probably the worse
> thing we could come up with in these conditions, but hopefully we'll
> have something better shortly after lm-sensors 3.0.1 is released.
> 

Hmm,

Do you have something planned? As you know I've had several students work on a 
motherboard config website without much success, I do think Ivo's 
sensors-detect changes for dmi based autoconf are good (we need to get those 
integrated, plan?). But the website delivered by one of his fellow students is 
less good.

I do have a friend who is a php guru who is willing to write a php driven site 
for us if we can provide him with proper specs.

I can start writing a spec for the website as time permits, then discuss it 
here, and once approved ask him to write it (under an OSS license of course).

Another option would be to stay with the wiki, add some special markup comments 
for the dmi strings and write a script to generate a tarbal / "database" for 
the dmi based detect code. For me putting the info in the wiki works well, its 
not like we are getting multiple motherboard configs per day, and the wiki 
keeps history which can be benifitial (a sufficiently advanced website could do 
this too).

Regards,

Hans



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Ivo Manca]

> Jean Delvare wrote:
>>
>> Also, storing the configuration files in the wiki is probably the 
>> worse
>> thing we could come up with in these conditions, but hopefully we'll
>> have something better shortly after lm-sensors 3.0.1 is released.
>>
>
> Hmm,
>
> Do you have something planned? As you know I've had several students 
> work on a
> motherboard config website without much success, I do think Ivo's
> sensors-detect changes for dmi based autoconf are good (we need to get 
> those
> integrated, plan?). But the website delivered by one of his fellow 
> students is
> less good.
I still need to work on the CPU sensors detected by the script, as you 
stated before. It shouldn't take too long, but I sadly don't have much 
time available for the next two weeks, since I'm moving and almost 
always busy with either working in the new house, or my job ;/

> I do have a friend who is a php guru who is willing to write a php 
> driven site
> for us if we can provide him with proper specs.
>
> I can start writing a spec for the website as time permits, then 
> discuss it
> here, and once approved ask him to write it (under an OSS license of 
> course).
Everyone with enough PHP knowledge is capable of making a sufficient 
site within not too much time. It's not rocket science after all ;)
I'm willing to help, if possible, and I will (ofcourse) give feedback to 
the specs.

> Another option would be to stay with the wiki, add some special markup 
> comments
> for the dmi strings and write a script to generate a tarbal / 
> "database" for
> the dmi based detect code. For me putting the info in the wiki works 
> well, its
> not like we are getting multiple motherboard configs per day, and the 
> wiki
> keeps history which can be benifitial (a sufficiently advanced website 
> could do
> this too).
As long as the wiki has an index with all available configs (either 
sorted/linked per motherboard, or directly into one page), this won't be 
hard to write.

Ivo

> Regards,
>
> Hans
>
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Jean Delvare]

Hi Hans,

On Mon, 20 Aug 2007 22:44:02 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > Also, storing the configuration files in the wiki is probably the worse
> > thing we could come up with in these conditions, but hopefully we'll
> > have something better shortly after lm-sensors 3.0.1 is released.
> 
> Do you have something planned? As you know I've had several students work on a 
> motherboard config website without much success, I do think Ivo's 
> sensors-detect changes for dmi based autoconf are good (we need to get those 
> integrated, plan?). But the website delivered by one of his fellow students is 
> less good.

Your students' work was obviously what I was thinking about here.

> I do have a friend who is a php guru who is willing to write a php driven site 
> for us if we can provide him with proper specs.
> 
> I can start writing a spec for the website as time permits, then discuss it 
> here, and once approved ask him to write it (under an OSS license of course).

Writing it is one thing, hosting it is another. Axel, maybe I already
asked, can't remember: can we host a PHP app on lm-sensors.org?

> Another option would be to stay with the wiki, add some special markup comments 
> for the dmi strings and write a script to generate a tarbal / "database" for 
> the dmi based detect code. For me putting the info in the wiki works well, its 
> not like we are getting multiple motherboard configs per day, and the wiki 
> keeps history which can be benifitial (a sufficiently advanced website could do 
> this too).

I'd prefer a dedicated interface where anyone can contribute its
configuration. The target configuration count is in hundreds if not
thousands, that's not something we want to handle manually.

That being said, if someone _else_ is going to take care, it doesn't
matter that much to me ;) The usual open development rule applies:
whoever does the job decides how it should be done. I simply haven't
looked enough into it all yet, for now I'm focusing on getting
libsensors4 ready so that we can release it before the end of the year.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 2335 bytes --]

On Tue, Aug 21, 2007 at 10:45:10AM +0200, Jean Delvare wrote:
> > I do have a friend who is a php guru who is willing to write a php driven site 
> > for us if we can provide him with proper specs.
> > 
> > I can start writing a spec for the website as time permits, then discuss it 
> > here, and once approved ask him to write it (under an OSS license of course).
> 
> Writing it is one thing, hosting it is another. Axel, maybe I already
> asked, can't remember: can we host a PHP app on lm-sensors.org?

Sure, as long as someone manages the app and any involved security
issues. PHP is rather tricky and needs good care security-wise.

> > Another option would be to stay with the wiki, add some special
> > markup comments for the dmi strings and write a script to generate
> > a tarbal / "database" for the dmi based detect code. For me
> > putting the info in the wiki works well, its not like we are
> > getting multiple motherboard configs per day, and the wiki keeps
> > history which can be benifitial (a sufficiently advanced website
> > could do this too).
> 
> I'd prefer a dedicated interface where anyone can contribute its
> configuration. The target configuration count is in hundreds if not
> thousands, that's not something we want to handle manually.
> 
> That being said, if someone _else_ is going to take care, it doesn't
> matter that much to me ;) The usual open development rule applies:
> whoever does the job decides how it should be done. I simply haven't
> looked enough into it all yet, for now I'm focusing on getting
> libsensors4 ready so that we can release it before the end of the
> year.

I would also tend to recommend a wiki. The stumbing block is the spam
issue, and I think if we write a simple mailman like registration
module (for example in PHP :) we could have people register once and
then use wiki/trac/tickets/svn etc. as you like (not as flat as it
sounds, but with some lm-sensors heads elevating permissions as
needed, e.g. self-registration allows wiki/ticket editing, and svn
write access needs a bit flip by an lm-sensors leader etc)

Hans, maybe your PHP friend expert (is that Romain copied in the Cc?)
would be interested in this general purpose registration module
stealing some methods from mailman?
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Romain Dolbeau]

Axel Thimm wrote:

> Hans, maybe your PHP friend expert (is that Romain copied in the Cc?)

Nope, I'm just the guy who brought the issue up, I always
try to have accurate sensors description of my servers'
motherboards, and wanted to share them...

-- 
Romain Dolbeau
<romain.dolbeau@caps-entreprise.com>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 1661 bytes --]

On Tue, Aug 21, 2007 at 02:53:31PM +0200, Hans de Goede wrote:
> Let me check if I understand you correctly, you want to have a registration 
> module, for users to register themselves as trac user, which has some spam bot 
> prevention methods, like sending a confirmation mail and maybe also such a 
> picture with bad readable text? (which has a name I know, but not right now :)
> 
> But wouldn't it be better to write such a thing in python and submit it for 
> upstream trac inclusion? Has anyone already searched the web to see if such a 
> thing exists?

Yes, there are some attempts at a trac specific solution, but I was
thinking of a generic one, e.g. one that feeds an LDAP server and then
trac/mediawiki/moin/apache/you_name_it can simply query the login
credentials. That way this solution will be usable by far more than a
trac instance.

The LDAP part is dealt with at CLI level. What is missing is the Web
interface. I envision it as such:

 o User gives in data required, this would be Name (but split in
   first/last), email & password. This is protected by a
   (re)captcha. There is already a lib for PHP for recaptcha.
 o The system stores a cookie and sends the authentication code to the
   email specified (just like mailman)
 o The user clicks on the web authentication URL and the web app calls
   a cli app that creates the account

In our case the cli app will be pushing the credential data to an LDAP
server, another implementation could use htdiegst files, /etc/passwd,
(l)useradd etc.

It is not much different from what mailman does other than adding a
captcha.
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Jean Delvare]

On Tue, 21 Aug 2007 14:53:31 +0200, Hans de Goede wrote:
> Axel Thimm wrote:
> > Hans, maybe your PHP friend expert (is that Romain copied in the Cc?)
> > would be interested in this general purpose registration module
> > stealing some methods from mailman?
> (...)
> Let me check if I understand you correctly, you want to have a registration 
> module, for users to register themselves as trac user, which has some spam bot 
> prevention methods, like sending a confirmation mail and maybe also such a 
> picture with bad readable text? (which has a name I know, but not right now :)
> 
> But wouldn't it be better to write such a thing in python and submit it for 
> upstream trac inclusion? Has anyone already searched the web to see if such a 
> thing exists?

I was about to suggest the very same. Trac really lacks this feature
and it would benefit to all communities using it if written in python
and integrated cleanly. I can't believe that we are the only community
being hurt by the spam in trac.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Jean Delvare]

Hi Axel,

On Tue, 21 Aug 2007 16:38:48 +0200, Axel Thimm wrote:
> Yes, there are some attempts at a trac specific solution, but I was
> thinking of a generic one, e.g. one that feeds an LDAP server and then
> trac/mediawiki/moin/apache/you_name_it can simply query the login
> credentials. That way this solution will be usable by far more than a
> trac instance.
> 
> The LDAP part is dealt with at CLI level. What is missing is the Web
> interface. I envision it as such:
> 
>  o User gives in data required, this would be Name (but split in
>    first/last), email & password. This is protected by a
>    (re)captcha. There is already a lib for PHP for recaptcha.
>  o The system stores a cookie and sends the authentication code to the
>    email specified (just like mailman)
>  o The user clicks on the web authentication URL and the web app calls
>    a cli app that creates the account
> 
> In our case the cli app will be pushing the credential data to an LDAP
> server, another implementation could use htdiegst files, /etc/passwd,
> (l)useradd etc.

This sounds more complex than a trac-driven project should need.

> It is not much different from what mailman does other than adding a
> captcha.

Do we really need a mail validation mechanism (as bugzilla and mailman
do) AND a captcha? I thought that we only needed one method. I've
always seen the captcha as a replacement for email validation when
email validation is considered too much. In the case of trac we want an
email address anyway (for ticket change notifications).


-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Axel Thimm]

[-- Attachment #1.1: Type: text/plain, Size: 3104 bytes --]

Hi,

On Tue, Aug 21, 2007 at 07:17:34PM +0200, Jean Delvare wrote:
> On Tue, 21 Aug 2007 16:38:48 +0200, Axel Thimm wrote:
> > Yes, there are some attempts at a trac specific solution, but I was
> > thinking of a generic one, e.g. one that feeds an LDAP server and then
> > trac/mediawiki/moin/apache/you_name_it can simply query the login
> > credentials. That way this solution will be usable by far more than a
> > trac instance.
> > 
> > The LDAP part is dealt with at CLI level. What is missing is the Web
> > interface. I envision it as such:
> > 
> >  o User gives in data required, this would be Name (but split in
> >    first/last), email & password. This is protected by a
> >    (re)captcha. There is already a lib for PHP for recaptcha.
> >  o The system stores a cookie and sends the authentication code to the
> >    email specified (just like mailman)
> >  o The user clicks on the web authentication URL and the web app calls
> >    a cli app that creates the account
> > 
> > In our case the cli app will be pushing the credential data to an LDAP
> > server, another implementation could use htdiegst files, /etc/passwd,
> > (l)useradd etc.
> 
> This sounds more complex than a trac-driven project should need.

I don't belive so. This is just a bullet-proof way of setting this up
and forgetting about it for the next couple of years. In the last
decade I've seen a lot of arms races between attackers and
defenders. Any obstructions gets bend sooner or later. I wonder why it
takes so long that bots start automatically subscribing themselves to
mailing lists.

> > It is not much different from what mailman does other than adding a
> > captcha.
> 
> Do we really need a mail validation mechanism (as bugzilla and mailman
> do) AND a captcha? I thought that we only needed one method. I've
> always seen the captcha as a replacement for email validation when
> email validation is considered too much. In the case of trac we want an
> email address anyway (for ticket change notifications).

See above. You are correct for trac's needs today. But two years ago
people would had been laughing at you if you would talk about upcoming
wiki spam. I just want a solution I can really use and not need to
upgrade to a better one every couple months or so. That's also the
reason why the mailing list filtering is rather more sophisticated
than the usual protection methods. You invest once a little more and
then you relax for a longer while (until "they" catch up ...)

But I wouldn't be disappointed if someone writes a trac-only captcha
plugin either. trac-hacks has some starting implementations, also for
registration modules. The problem is that Darwinism prevails and what
is picked today may not be what will end up in trac proper.

Aynway my favourite is to have LDAP accounts created via a web form as
it also enables later adding existing people to the project in ssh
accounts and similar, e.g. people grow from wiki maintainers to
developers and have a single sign-on for all services.
-- 
Axel.Thimm at ATrpms.net

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Submitting motherboard-specific support? (w/

[Sebastian Flothow]

Am 21. Aug 2007 um 19:17 Uhr schrieb Jean Delvare:
> Do we really need a mail validation mechanism (as bugzilla and mailman
> do) AND a captcha? I thought that we only needed one method. I've
> always seen the captcha as a replacement for email validation when
> email validation is considered too much.

My experience from running online fora (using phpBB) suggests that 
captchas are actually a harder test than email verification - 
apparently spambots do read their mail and follow through on 
confirmation links.

So, email verification has its place for confirming address ownership 
(to catch typos and prevent abuse), but it's not much use when the 
spambot _is_ the legitimate owner of an email address. Also, even the 
bots who don't go to this trouble still end up creating loads of bogus 
user accounts.

Captchas aren't perfect, either - some bots succeed reading them, but 
maybe phpBB's captcha generator is too deterministic. Still, they have 
reduced the amount of spam by many orders of magnitude, to about two or 
three posts per month, making manual deletion feasible.


> In the case of trac we want an email address anyway (for ticket change 
> notifications).

Which would indeed suggest having both mechanisms, IMO.


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors