Quantcast
Channel: Serverphorums.com - HAProxy
Viewing all 11674 articles
Browse latest View live

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Am 12-03-2016 10:50, schrieb Willy Tarreau:
> Hi Benoit,
>
> On Sat, Mar 12, 2016 at 09:45:25AM +0100, Beno?t GARNIER wrote:
>>
>> > On Sat, Mar 12, Willy Tarreau wrote:

[snipp]

>> > An extra benefit of proceeding like this is that when we move to
>> > multi-threading, we won't have to lock for something which will only
>> > have to be initialized twice :-)
>> Wow, I didn't think haproxy would move to multi-threading one day.
>
> Don't be too excited, it will take decades :-)

Well when you stay tuned you well see a multi-threaded haproxy also ;-)

I think this will be a major version change worth ;-).

cheers Aleks

Re: There is kind of a spam issue on this ML no?

$
0
0
On Sat, Mar 12, 2016 at 11:08:08AM +0100, Hoggins! wrote:
> Oh don't say that !
> Last time I did, I was told that I had a bad spirit, and that my
> antispam was just bad.
>
> The thing is : unlike other popular mailing-lists, ANYTHING or ANYONE
> can post on this one without prior subscription, hence that huge spammy
> noise.

Yes and that's the point. If you have ever been rejected from a
development mailing list because you were not subscribed, you know
how painful it is. And precisely the fact that the list is open means
you *don't* have to be subscribed to post messages. So in short, people
who complain about spam are those who are willing to receive these spam
and I invite them to unsubscribe. They cause more noise on this list
than the spams because you have to read their e-mails before knowing
you're wasting your time.

Willy

Car Tire Pressure Monitor System

$
0
0
Hi ,
 
Good days!
 
The Broadya Industrial is making Car TPMS ( Tire Pressure Monitor System) with reliable quality and hope to help you if interesting with new items .
 
Please contact us for more information !
 
Regards !
 



 
Tony / Sales Director
 ---------------------------------------------------------------------------------- 
Broadya Industrial Group Limited
Email:       info@broadya.net  
Add:         No.2 Liuwu Jiwei,Xiasha Cun, Shipai Town,Dongguan,China
----------------------------------------------------------------------------------
 Parking Assist System / Car TPMS / Car ADAS / Car Jump Starter / Car DVR 
 

全国独家办理学历学位学籍档案haproxy(AD)

$
0
0
全国独家电子注册学历!!

免考免读快速获得真实正规学历文凭!!

www.chsi.com.cn 全国独家权威代办!!
高薪 晋升 职称 报考 户口 出国 移民 轻松搞定!!定能让你快速成功!!

目前所有企事业用人单位在聘雇人员时,都要求有正规的学历文凭或学位,所以拥有一张真实正规经得起任何形式审核验证的大学文凭将远胜过那些没有大学文凭的求职者!!

你是否一度因为没有大学学历学位而找不到一份理想的工作?或者尽管你在实际工作中积累了丰富的经验却因自己从未进过大学,没有学位文凭而失去了被提升的机会? 还犹豫什么拥有一个大学学历文凭学位,大大增加你在工作和事业上成功的机会!!

你还为没有文凭而找不到好工作烦恼吗? 还为没有文凭职称无法大幅提高待遇收入而忧虑吗?还为单位职称评定,提拔重用,晋级加薪而没有正规大学学历犯愁吗?还在因为学历不够而担心被用人单位拒之门外吗? 如果你在求职升迁道路上面临着学历文凭所带来的种种困扰,我处将为你排忧解难,学历文凭改变命运创造财富!!

长年独家办理:
正规学历文凭: 全日制统招(重点,普通)高等院校学历证书,自学考试(专科,本科)毕业证书,成人教育(全脱产,半脱产)毕业证以及学位证书(学士,硕士,博士等),均提供有效完备学籍档案,成绩单,派遣证,电子注册入正规数据库 !! 可经公证处公证,确保顺利通过各种形式的审验,可用于参加公务员考试,各种资格考试,考研,出国,升职,评职称等用途,

本公司网站 www.chsi.com.cn 北京学信咨询服务公司

教育部唯一指定学历查询验证地址: www.chsi.com.cn/xlcx/bgcx.jsp

办理学历学位学籍档案联系电话: 13261888681 李老师
 
本处所办证书由各地各级院校内部渠道关系以正规手续办理,欢迎各地客户办理,也欢迎代理!!

几个问题:
1. 为什么要办理?
节约考试就读的时间金钱精力, 彻底解决工作和发展问题, 如报考 落户 评职称 应聘 跳槽 提拔 晋级 加薪 等

2.证书和学位的价格?
按不同标准 普通到重点 专科到博士 从10000元-50000元不等

3.办理周期多久?
3-5个工作日内

来电须知:
1.适合办理的人群: 具备一定专业技能和工作能力, 不想绕弯路浪费复习考试时间成本精力者
2.办理前请先明确所需办理的学历文凭性质( 统招 自考 成教 在职研究生) , 层次(专科 本科 硕士研究生), 地区院校(主考学校)名称, 院系专业, 毕业时间
3.无实践专业能力工作经验,年龄太小及无经济能力者勿扰

办理流程:
将申请资料备齐传来→审核确认→预付20%定金→办好后扫描证书验证满意→支付余款收取档案证书学位原件

本公司网站 www.chsi.com.cn 北京学信咨询服务公司

教育部唯一指定学历验证查询地址: www.chsi.com.cn

办理学历学位学籍档案联系电话:13261888681 李老师

最好的口碑和信誉, 独家雄厚资源,已成功为大量海内外客户圆满了梦想!! 我们的宗旨是帮助广大有才无证的朋友发展,帮助一切需要文凭证书帮助的人!!

确保真实合法,确保低价快捷。 一、真实合法,教育部认证网和学校网均可以查询,可供用人单位和有关部门电话咨询和上网调查,都是准确无误的。 二、有完整齐全的档案、学籍、考试成绩单、入学登记表、毕业登记表等。对求职、就业、应聘、晋级、涨薪、职称评定、资格报考、等级认证、出国、留学、移民、学历 公证等都具有效力。 三、 保证快捷价优:因为是学校直接出证直接办理,所以保证了出证快速,价格优惠。 市场无可限量,欢迎加盟代理!! 一次批量提交办理客户数超过30人,可来本公司面谈签约!!

公司地址 北京市海淀区学院路北京航空航天大学柏彦大厦1205室

本公司网站 www.chsi.com.cn 北京学信咨询服务公司

教育部唯一指定学历验证查询地址: www.chsi.com.cn/xlcx/bgcx.jsp

办理学历学位学籍档案联系电话:13261888681 李老师

Re: There is kind of a spam issue on this ML no?

$
0
0
I dont get any. My spam box is full of it but then thats what its there for..

Sent from my iPhone

> On 12 Mar 2016, at 10:08, Hoggins! <fuckspam@wheres5.com> wrote:
>
> Oh don't say that !
> Last time I did, I was told that I had a bad spirit, and that my
> antispam was just bad.
>
> The thing is : unlike other popular mailing-lists, ANYTHING or ANYONE
> can post on this one without prior subscription, hence that huge spammy
> noise.
>
> Hoggins!
>
> Le 11/03/2016 10:00, Arnaud B. a écrit :
>> On the last 2 or 3 days :
>> https://lut.im/jsIGNMzLDL/OuRdpkM9ZpVTIH47
>
>

--


Trustpay Global Limited is an authorised Electronic Money Institution
regulated by the Financial Conduct Authority registration number 900043.
Company No 07427913 Registered in England and Wales with registered address
130 Wood Street, London, EC2V 6DL, United Kingdom.

For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and
remain the property of Trustpay Global Ltd unless agreed by contract. It is
intended solely for the person to whom or the entity to which it is
addressed. If you are not the intended recipient you may not use, disclose,
copy, distribute, print or rely on the content of this email or its
attachments. If this email has been received by you in error please advise
the sender and delete the email from your system. Trustpay Global Ltd does
not accept any liability for any personal view expressed in this message.

AW: There is kind of a spam issue on this ML no?

$
0
0
> -----Ursprüngliche Nachricht-----
> Von: Kobus Bensch [mailto:kobus.bensch@trustpayglobal.com]
> Gesendet: Sonntag, 13. März 2016 11:18
> An: Hoggins!
> Cc: haproxy@formilux.org
> Betreff: Re: There is kind of a spam issue on this ML no?

> I dont get any. My spam box is full of it but then thats what its there for.

That's in my point of view not a valid answer. Trueth is, there come a lot of spam mails along the list.
Not every one has controll over the spam filter for his/her mail account. Furthor more
when every spam filter is as good as you say, nobody would send any more spam-mails.
And I don't wan't to mention false positives. So in my case I have at least to skim headlines
and it's a pain.

But at the end it's the decission of the owner oft this list. He made clear, he dont want to change a thing.

We as users have the opportunity choose to leave this list. It's not an ideal solution but there isn't at the moment
a good alternative to haproxy. So in my case I haven't to like, but I have to live with it.



> Sent from my iPhone

> On 12 Mar 2016, at 10:08, Hoggins! <fuckspam@wheres5.com> wrote:
>
> Oh don't say that !
> Last time I did, I was told that I had a bad spirit, and that my
> antispam was just bad.
>
> The thing is : unlike other popular mailing-lists, ANYTHING or ANYONE
> can post on this one without prior subscription, hence that huge
> spammy noise.
>
> Hoggins!
>
> Le 11/03/2016 10:00, Arnaud B. a écrit :
>> On the last 2 or 3 days :
>> https://lut.im/jsIGNMzLDL/OuRdpkM9ZpVTIH47
>
>

--


Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043.
Company No 07427913 Registered in England and Wales with registered address
130 Wood Street, London, EC2V 6DL, United Kingdom.

For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message.

Paints and coatings

$
0
0
&#20320;&#22909;
&nbsp;&nbsp;&nbsp;
&nbsp;
&nbsp;

&nbsp;

Re: There is kind of a spam issue on this ML no?

$
0
0
On Sun, Mar 13, 2016 at 11:40 AM, Dieter Späth <dieter.spaeth@gmx.de> wrote:
>
> Not every one has controll over the spam filter for his/her mail account.
>

HI Dieter

I don't use my main mail domain for mailing lists, I use a gmail
account, which has passable spam filtering

This is NOT an endorsement of gmail, just pointing out that some
people might use different email providers for different things...

Cheers

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hi Benoit,

On Sat, Mar 12, 2016 at 09:45:25AM +0100, Benoît GARNIER wrote:
> You just need to call tzset() once before chrooting to initialize the
> timezone subsystem.

Finally I did it directly in your patch, it was not worth delaying a
release for such a small change.

Thanks,
Willy

Íâó¿Í»§ËÑË÷¿ª·¢Èí¼þ£¬½µµÍÍâó¿Í»§¿ª·¢Í¶×ÊÃż÷º£ÍâµÄ¿Í»§ÕæµÄÄÇôÄÑ¿ª·¢Âð£¿

$
0
0
&#20027;&#21160;&#20986;&#20987;&nbsp; &#36194;&#28023;&#22806;&#21830;&#26426;
&nbsp;
&#21452;&#21916;&#22806;&#36152;&#23458;&#25143;&#24320;&#21457;&#31995;&#32479;&#65306;(1).&#20851;&#38190;&#35789;&#25628;&#32034;&#22269;&#22806;&#20080;&#23478;&#65292;&#36731;&#26494;&#25630;&#23450;&#65292;&#20302;&#25104;&#26412;&#65292;&#39640;&#25928;&#29575;&#12290;(2)&#20840;&#29699;&#24341;&#25806;&#31934;&#20934;&#24555;&#36895;&#25628;&#32034;(3)&#27169;&#25311;&#25163;&#24037;&#19968;&#23545;&#19968;&#32676;&#21457;&#37038;&#20214;(4)&#27599;&#22825;&#25628;&#32034;&#36807;&#19975;&#23458;&#25143;&#25968;&#25454;(5)&#27599;&#22825;&#21487;&#21457;&#36865;&#19978;&#19975;&#30340;&#37038;&#20214;(6)&#26368;&#20302;&#30340;&#36153;&#29992;&#25214;&#20219;&#24847;&#22269;&#23478;&#30340;&#28508;&#22312;&#23458;&#25143;(7)&#36991;&#24320;&#20013;&#38388;&#21830;&#65292;&#23547;&#25214;&#32456;&#31471;&#20080;&#23478;&#65292;&#36194;&#24471;&#39640;&#21033;&#28070;&#65292;&#25104;&#35746;&#21333;&#12290;
&nbsp;
&nbsp;
&#26356;&#22810;&#35814;&#32454;&#21672;&#35810; 173561765 (QQ) &#20813;&#36153;&#22312;&#32447;&#28436;&#31034;&#36719;&#20214;&#30340;&#21151;&#33021;&#21644;&#25928;&#26524;-----------------------------&#33509;&#19981;&#38656;&#35201;&#27492;&#31867;&#37038;&#20214;&#35831;&#35774;&#32622;&#25298;&#25910;&#65292;&#25265;&#27465;&#25171;&#25376;
&nbsp;

Re: AW: There is kind of a spam issue on this ML no?

$
0
0
If you dont have anti spam then get a gmail account. Or get antispam as part of your av.

Sent from my iPhone

> On 13 Mar 2016, at 11:40, Dieter Späth <dieter.spaeth@gmx.de> wrote:
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Kobus Bensch [mailto:kobus.bensch@trustpayglobal.com]
>> Gesendet: Sonntag, 13. März 2016 11:18
>> An: Hoggins!
>> Cc: haproxy@formilux.org
>> Betreff: Re: There is kind of a spam issue on this ML no?
>
>> I dont get any. My spam box is full of it but then thats what its there for.
>
> That's in my point of view not a valid answer. Trueth is, there come a lot of spam mails along the list.
> Not every one has controll over the spam filter for his/her mail account. Furthor more
> when every spam filter is as good as you say, nobody would send any more spam-mails.
> And I don't wan't to mention false positives. So in my case I have at least to skim headlines
> and it's a pain.
>
> But at the end it's the decission of the owner oft this list. He made clear, he dont want to change a thing.
>
> We as users have the opportunity choose to leave this list. It's not an ideal solution but there isn't at the moment
> a good alternative to haproxy. So in my case I haven't to like, but I have to live with it.
>
>
>
>> Sent from my iPhone
>
>> On 12 Mar 2016, at 10:08, Hoggins! <fuckspam@wheres5.com> wrote:
>>
>> Oh don't say that !
>> Last time I did, I was told that I had a bad spirit, and that my
>> antispam was just bad.
>>
>> The thing is : unlike other popular mailing-lists, ANYTHING or ANYONE
>> can post on this one without prior subscription, hence that huge
>> spammy noise.
>>
>> Hoggins!
>>
>> Le 11/03/2016 10:00, Arnaud B. a écrit :
>>> On the last 2 or 3 days :
>>> https://lut.im/jsIGNMzLDL/OuRdpkM9ZpVTIH47
>
> --
>
>
> Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043.
> Company No 07427913 Registered in England and Wales with registered address
> 130 Wood Street, London, EC2V 6DL, United Kingdom.
>
> For further details please visit our website at www.trustpayglobal.com.
>
> The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message.
>

--


Trustpay Global Limited is an authorised Electronic Money Institution
regulated by the Financial Conduct Authority registration number 900043.
Company No 07427913 Registered in England and Wales with registered address
130 Wood Street, London, EC2V 6DL, United Kingdom.

For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and
remain the property of Trustpay Global Ltd unless agreed by contract. It is
intended solely for the person to whom or the entity to which it is
addressed. If you are not the intended recipient you may not use, disclose,
copy, distribute, print or rely on the content of this email or its
attachments. If this email has been received by you in error please advise
the sender and delete the email from your system. Trustpay Global Ltd does
not accept any liability for any personal view expressed in this message.

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hello Willy,

Le 13/03/2016 23:49, Willy Tarreau a écrit :
> Hi Benoit,
>
> On Sat, Mar 12, 2016 at 09:45:25AM +0100, Benoît GARNIER wrote:
>> You just need to call tzset() once before chrooting to initialize the
>> timezone subsystem.
> Finally I did it directly in your patch, it was not worth delaying a
> release for such a small change.

I did not send the patch earlier because I was trying to gather some
more informations about chroot() and local times.
It seems that my patch would not play nicely with some versions of glibc
and could introduce a subtle bug.

Some time functions call tzset() internally. This is the case for
strftime() or localtime() (but not localtime_r() or gettimeofday()).
So when populating the GMT offset cache, a hidden call to tzset() is done.
The issue is that some old glibc, when not finding /etc/localtime (this
is the case after a chroot), would reset the timezone to GMT.
Thus, the first log would have a localtime with a GMT offset (wrongly)
set to +00:00, and subsequent logs would be in full GMT time.

See the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=444043

In this case the only solution is to copy /etc/localtime to
<chroot>/etc/localtime.
So, I was trying to elaborate on your previous suggestion: prepare the
cache at startup, but without messing with the tm_isdst flag.

Benoit GARNIER

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hi Benoit,

On Mon, Mar 14, 2016 at 08:32:35AM +0100, Benoît GARNIER wrote:
> Hello Willy,
>
> Le 13/03/2016 23:49, Willy Tarreau a écrit :
> > Hi Benoit,
> >
> > On Sat, Mar 12, 2016 at 09:45:25AM +0100, Benoît GARNIER wrote:
> >> You just need to call tzset() once before chrooting to initialize the
> >> timezone subsystem.
> > Finally I did it directly in your patch, it was not worth delaying a
> > release for such a small change.
>
> I did not send the patch earlier because I was trying to gather some
> more informations about chroot() and local times.
> It seems that my patch would not play nicely with some versions of glibc
> and could introduce a subtle bug.
>
> Some time functions call tzset() internally. This is the case for
> strftime() or localtime() (but not localtime_r() or gettimeofday()).
> So when populating the GMT offset cache, a hidden call to tzset() is done.
> The issue is that some old glibc, when not finding /etc/localtime (this
> is the case after a chroot), would reset the timezone to GMT.
> Thus, the first log would have a localtime with a GMT offset (wrongly)
> set to +00:00, and subsequent logs would be in full GMT time.
>
> See the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=444043

Interesting.

> In this case the only solution is to copy /etc/localtime to
> <chroot>/etc/localtime.

Well, in the worst case it means we'll fall back to the previous behaviour
(I mean before your patch) if this happens, so that's not the end of the
world.

> So, I was trying to elaborate on your previous suggestion: prepare the
> cache at startup, but without messing with the tm_isdst flag.

Since the libc doesn't seem well suited to these tricks, let's start the
simple way first and only contemplate alternatives if people still have
the problem, then we'll know what OS is affected and will be able to
contemplate some workarounds (one of them still being "cp").

Thanks,
Willy

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hello Willy,

Le 14/03/2016 08:45, Willy Tarreau a écrit :
> Hi Benoit,
>
> On Mon, Mar 14, 2016 at 08:32:35AM +0100, Benoît GARNIER wrote:
>> Hello Willy,
>>
>> Le 13/03/2016 23:49, Willy Tarreau a écrit :
>>> Hi Benoit,
>>>
>>> On Sat, Mar 12, 2016 at 09:45:25AM +0100, Benoît GARNIER wrote:
>>>> You just need to call tzset() once before chrooting to initialize the
>>>> timezone subsystem.
>>> Finally I did it directly in your patch, it was not worth delaying a
>>> release for such a small change.
>> I did not send the patch earlier because I was trying to gather some
>> more informations about chroot() and local times.
>> It seems that my patch would not play nicely with some versions of glibc
>> and could introduce a subtle bug.
>>
>> Some time functions call tzset() internally. This is the case for
>> strftime() or localtime() (but not localtime_r() or gettimeofday()).
>> So when populating the GMT offset cache, a hidden call to tzset() is done.
>> The issue is that some old glibc, when not finding /etc/localtime (this
>> is the case after a chroot), would reset the timezone to GMT.
>> Thus, the first log would have a localtime with a GMT offset (wrongly)
>> set to +00:00, and subsequent logs would be in full GMT time.
>>
>> See the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=444043
> Interesting.
>
>> In this case the only solution is to copy /etc/localtime to
>> <chroot>/etc/localtime.
> Well, in the worst case it means we'll fall back to the previous behaviour
> (I mean before your patch) if this happens, so that's not the end of the
> world.

No really, the first log would have a localtime with a GMT offset,
following logs would be in full GMT format.

>> So, I was trying to elaborate on your previous suggestion: prepare the
>> cache at startup, but without messing with the tm_isdst flag.
> Since the libc doesn't seem well suited to these tricks, let's start the
> simple way first and only contemplate alternatives if people still have
> the problem, then we'll know what OS is affected and will be able to
> contemplate some workarounds (one of them still being "cp").

Another more portable solution is to code an equivalent of
strftime(..."%z"...) with no call to tzset().
We can get back to an GMT time and extract the GMT offset from that. It
would be slow, but we'd only do this twice, once for each tm_isdst value.
Anyway, this is what glibc reverts to when tm_gmtoff is not defined in
struct tm. I think this is the most portable and less risky solution.

> Thanks,
> Willy
>
Benoit GARNIER

Re: There is kind of a spam issue on this ML no?

$
0
0
> We as users have the opportunity choose to leave this list. It's not an ideal solution but there isn't at the moment
> a good alternative to haproxy. So in my case I haven't to like, but I have to live with it.


Do you mean you could switch to an other product because of an amount
of spam on a mailling list purposely widely opened to everyone?
While some solutions exists to fight spams?

As others have mentionned it, I use gmail, it's quite efficient for
this type of usage.

Baptiste

Re: [PossibleSpam] Re: SNI Support for Health Check on Backend Server

$
0
0
Hi,

As far as I know, SNI for the health check is not yet supported.

Baptiste

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
On Mon, Mar 14, 2016 at 09:19:27AM +0100, Benoît GARNIER wrote:
> >> In this case the only solution is to copy /etc/localtime to
> >> <chroot>/etc/localtime.
> > Well, in the worst case it means we'll fall back to the previous behaviour
> > (I mean before your patch) if this happens, so that's not the end of the
> > world.
>
> No really, the first log would have a localtime with a GMT offset,
> following logs would be in full GMT format.

I find this strange, it would mean that glibc would perform file system
accesses for each call to localtime() which doesn't match my observations
(would be terribly slow for logging).

> >> So, I was trying to elaborate on your previous suggestion: prepare the
> >> cache at startup, but without messing with the tm_isdst flag.
> > Since the libc doesn't seem well suited to these tricks, let's start the
> > simple way first and only contemplate alternatives if people still have
> > the problem, then we'll know what OS is affected and will be able to
> > contemplate some workarounds (one of them still being "cp").
>
> Another more portable solution is to code an equivalent of
> strftime(..."%z"...) with no call to tzset().
> We can get back to an GMT time and extract the GMT offset from that. It
> would be slow, but we'd only do this twice, once for each tm_isdst value.

Doesn't this bring us back to the initial principle of caching the offset
for each possible value ?

> Anyway, this is what glibc reverts to when tm_gmtoff is not defined in
> struct tm. I think this is the most portable and less risky solution.

Actually there is another possibility which would be even more portable
and reliable, consisting in offering the option to configure the TZ
offsets in the global section for both !dst and dst, something like
this :

time.tz-offsets +0100 +0200

It's not unreasonable to ask for this in chrooted environments in my
opinion. Of course if we can get such information more easily and
without user intervention, it would be better (eg by finding *one*
date on each dst inside a whole year).

Willy

PATCH 1/1: OPTIM: args

$
0
0
Hi all,

This patch is in fact not exactly an OPTIM's kind but did not find any
better ...
After a discussion with Willy about the need to increase the number of
arguments list for sample fetch / convertors hence the patch which is up to
12. The change applied in the sample part will follow.

About backporting to 1.6 or not ... Well there is some pros and cons, I
leave the decision to the commiters :-) If the patches are merged, I will
apply changes to DeviceAtlas module as well in the near future.
Thanks in advance.

PATCH 2/2 : OPTIM: sample

$
0
0
Hi,

this is the second part of the change, updating sample/convertors mask
fields.

Regards.

Re: There is kind of a spam issue on this ML no?

$
0
0
You heard the man, Arnaud.
Just live with it.

Cheers !

Le 12/03/2016 17:11, Willy Tarreau a écrit :
>> Oh don't say that !
>> > Last time I did, I was told that I had a bad spirit, and that my
>> > antispam was just bad.
>> >
>> > The thing is : unlike other popular mailing-lists, ANYTHING or ANYONE
>> > can post on this one without prior subscription, hence that huge spammy
>> > noise.
> Yes and that's the point. If you have ever been rejected from a
> development mailing list because you were not subscribed, you know
> how painful it is. And precisely the fact that the list is open means
> you *don't* have to be subscribed to post messages. So in short, people
> who complain about spam are those who are willing to receive these spam
> and I invite them to unsubscribe. They cause more noise on this list
> than the spams because you have to read their e-mails before knowing
> you're wasting your time.
>
> Willy
>
Viewing all 11674 articles
Browse latest View live