[管理] 关于SHLUG里的OT讨论
Cheng
虽然我们没有精确的对于OT数量的统计，但每月目前近2000贴里OT比例的确有愈演愈烈的趋势。
邮件列表是一个公开讨论，畅所欲言的地方。我们几位管理成员与大家一样也不希望对OT讨论完全噤声，只在这里单纯的讨论技术话题。
但SHLUG毕竟是一个技术性的社区，技术讨论是我们的主旨。
所以特此我们向大家征求意见，对于OT内容的讨论我们现在在思考以下的举措：
1. 维持现状，大家自觉不要太严重以及太多的OT
2. 在SHLUG的网站上开一个web论坛供OT帖子讨论专用，SHLUG的邮件列表保持较为单纯的技术话题讨论
3. 新开启一个邮件列表供OT帖子讨论用，本邮件列表保持较为单纯的技术话题讨论
注：OT贴子的判定标准由群体讨论产生，凡在该范围内以外的主题都请在OT列表中讨论。
欢迎大家讨论，在一周之内（截止时间为9月13日）提出自己的观点与想法，我们将根据大家的意见采取相应的举措，谢谢。
SHLUG Coreteam
rex Ji
水贴一下，阿里的垃圾邮件非常严重，OT的邮件多得吓人，按照内网教程详细的分类自己的邮件，只看你自己需要的，效果不错。
李俊
小马xiaoma
这就好比是BBS多开几个版面，一个技术交流版，一个招聘版，一个新闻版等。
这些标签可以由管理员来制定，以后每个发帖必须带标签，不带标签的都作为默认的技术交流。
l5g
--
Lightning
> 这些标签可以由管理员来制定，以后每个发帖必须带标签，不带标签的都作为默认的技术交流。
这个方案要良好运行的话要有一个前提条件：每位发信人都能自觉地、分类正确地
为自已所发的邮件注上标签。
Bruce Du
2，3号方案，未来也会很麻烦，增加load。
。
建议一号，，严格执法，一经发现立即踢掉。不通知不警告。这样给力 不？
小马xiaoma
第一次警告，第二次禁言一周，第三次才踢掉，这样比较人性化。
Thomas Iverson
> 2，3号方案，未来也会很麻烦，增加load。
>
> 。
>
> 建议一号，，严格执法，一经发现立即踢掉。不通知不警告。这样给力 不？
我觉得你这样的说法不对，然后不通知不警告，直接踢掉，你会怎么想?
--
ghosTM55
Shanghai Linux User Group
Keep It Simple Stupid
http://www.ghosTunix.org
http://facebook/ghosTM55
http://twitter.com/ghosTM55
Shen Chenjun
小马xiaoma
我只是希望，发水帖的人，能主动给个标签，然后邮件客户端有自动分类的功能，想看的人可以看，不想看的人可以不看。
Shell Xu
无能者无所求，饱食而遨游，泛若不系之舟
Thomas Iverson
> 用gmail的表示没问题。
> 我做了个[OT]的过滤器。
> 只要别忘记加OT，没时间看就点到OT组里面全部看过一把。
> 世界清静了。
一般都是这么做的，主要还是觉得很多人OT不OT分不太清楚，呵呵
--
ghosTM55
Shanghai Linux User Group
Keep It Simple Stupid
http://www.ghosTunix.org
Su Wang
We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.
Shell Xu
无能者无所求，饱食而遨游，泛若不系之舟
Su Wang
Shell Xu
无能者无所求，饱食而遨游，泛若不系之舟
Liao Wei
同意这个方案，在每个标题前面加上固定标签，然后由大家自己分类筛选。
这就好比是BBS多开几个版面，一个技术交流版，一个招聘版，一个新闻版等。
这些标签可以由管理员来制定，以后每个发帖必须带标签，不带标签的都作为默认的技术交流。
同意邮件自觉分类！这就需要麻烦各位管理者纠正，警告，惩戒几个月，就自然可以形成风气。
这方面的经验可以借鉴TopLanguage group，它的用户量非常的大，分类也很多，照样管理的很好。
2，3方案不推荐，因为就算你是讨论技术，走着走着就OT了，没法界定。这还真的没什么好办法！
有两种方法可以尝试：
1. 感觉主题能够引起一个新的有趣的话题，可以给邮件换一个分类。
2. 需要shlug的常客抵制及纠正这些歪楼的现象。社区靠靠大家！
我在想技术贴是否也贴个标签分类，这样发先主题的时候，用户就会先想，我这个到底是技术呢还是招聘什么别的分类呢？
不分类，就要提醒，删帖然后再重新发。
Ben Luo
Linux是个大框，什么都可以放进去。如果把它分解开，就会发现每个软件，或每类软件几乎都有高质量的 maillist or forum or
irc chanel. 如果真的要找答案，可能去那边得到的回答的机会更多。
我们这个列表的技术类的 email 定位在哪？需要解决什么问题？有什么问题是别的maillist/forum/irc
解决不了，或者不容易解决的？我觉得有这么两类
1. 需要现场指导的。在同城比较方便
2. 同城的技术活动
我觉得OT贴也反映了2个情况，1. 大家能通过别的渠道解决大部分问题，2. 大家渴望和同城的兄弟姐妹们加强人际间的交流。
我们是不是立足于同城，而不是立足于技术？来这里的都是对linux/freesoftware有兴趣的朋友。我们用各种方法解决问题，但shlug是我们有地域归属感的一个列表。我觉得应该强化这样一种地域感。而不是强化技术感。
小马xiaoma
Thomas Iverson
Ben，如果立足于同城，KDS一个就够了，何况还有个豆瓣
你说的专业领域的列表，很多都是英文的，那么有很多朋友比如想交流kvm，交流xen，没有官方的中文列表，怎么办，只能求助于shlug这样卧虎藏龙比较多的技术列表了
如果shlug不以技术立足，不是我说大话，三个月内列表可以发展到解散的程度
Ben Luo
那怎么定位？学战略管理的时候，有蓝海这种说法。我们现在就是要发现maillist的蓝海。
2010/9/7 Thomas Iverson <tho...@shlug.org>:
Ben Luo
2010/9/7 小马xiaoma <cnxi...@gmail.com>:
Thomas Iverson
> KDS没去过。因为没习惯逛论坛。喜欢maillist，只要打开gmail就可以了。不过你说的很有可能。
>
> 那怎么定位？学战略管理的时候，有蓝海这种说法。我们现在就是要发现maillist的蓝海。
>
什么是蓝海，不要用专家的方式讲话阿，你知道的别人不一定知道的
定位的问题我还是觉得是面向于所有一切与Linux相关的技术交流，然后的话侧重于LUG本身活动的组织与讨论，这个是没有问题的
这也是LUG应该做的事情，有一份LUG How-to，其实写的不错的:
http://tldp.org/HOWTO/User-Group-HOWTO.html
Chaos Eternal
2010/9/7 小马xiaoma <cnxi...@gmail.com>:
Liu Yu Fei, Eric
貌似我OT了。。。
Best regards,
Liu Yu Fei, Eric
Computer Science, CUHK
S‘LeX
weibin li
在 10-9-7，S‘LeX<hot...@gmail.com> 写道：
--
-----------------------------------------------------------
Keep It Simple Stupid
Shanghai Linux User Group
Best & Regards.
Jacky.Li
李伟斌
http://yoyojacky.vicp.net
-----------------------------------------------------------
姚毅捷
Raymon
贴一个Perlchina group的邮件，应该这样专业的态度看齐。
---------------------------------------------------------------------
求教一个算法，上次问过，但是还是没有搞清楚。
比如有这样一个矩阵：
sex 7.2 3.8 6.8 9.2 5.6
sex 5.4 2.3 4.6 8.9 9.0
sex 6.7 NA 7.8 9.0 3.1
goo 2.4 6.7 NA 9.0 2.1
goo 2.1 5.6 7.8 9.7 1.2
pkk 2.5 4.3 6.5 4.9 0.2
pkk 2.1 3.4 3.2 NA 4.6
pkk 3.2 5.6 6.7 9.1 2.2
...
...
...
这个矩阵很简单，就是有一些同名的行，现在我要做的是，把这些同名的行的数据按每一列合并起来，按什么合并，按照每一列的平均值来合并
就是说，比如行名为sex的行，第一列数据为: 7.2, 5.4, 6.7 那么第一列的平均值就是(7.2+5.4+6.7)/3=6.4,
第二列数据为3.8, 2.3, NA, 那么平均值就是 (3.8+2.3)/2=3, 以此类推，得到每一列的平均值，作为最后的值，那么行名为
sex的行最后就合并为：
sex 6.4 3 ....
就是要写这样一个程序，原理很简单吧，但是鄙人的水平有限，写的程序效率上不去。
我是这样写的，
先用一个hash存下所有的行名：sex, goo, pkk.....
然后遍历这个hash, foreach (%hash) { }
每一次，把相同行名的行取出来放到一个数组@num中
这个矩阵有一个值是确定的，那就是列数是确定的，所以对每一个数组@num, 我用for($i=0;$i<列数;$i++) 循环，把每一列取出来，
放到一个新的数组@haha中
然后for($j=0;$j<@haha;$j++) 把@haha的平均值算出来，作为这一列的最后的值
就是这样。。。
程序我是写出来了，对于行数和列数都比较少的情况，程序没有什么问题。但是如果我有大量的行和列，比如有40000行，500列，这种情况下，这个程序
就不是一两天能跑完的了。我跑了三天，还没有跑完。工作情况是不允许我跑这么久的。
恳请高手们帮忙指教。非常感谢！
reply 1:
一个简单的提高效率的办法：
在读入数据的同时进行处理，不要用反复的循环。
while(<FILE>)
{ my @itmes=split(/\s+/);
foreach (1..$#items)
{ next if $items[$_] eq 'NA';
$hash{$items[0]}->[$_]->{sum}+=$items[$_]; #这是总和
$hash{$items[0]}->[$_]->{count}++; #这是计数
}
}
这样在读取完输入文件后，进行遍历计数均值同时输出。
不过，这里可能会有一个bug，就是当某个key的某一个列全部是NA的情况下，就会完全不输出而被跳过......
总之，不能反复的做循环。
估计这样运行起来的时间应该也就是几分钟的事情。
On Sep 7, 10:33 am, Thomas Iverson <tho...@shlug.org> wrote:
> 2010/9/7 Ben Luo <ben...@gmail.com>:
>
> > 我觉得可能还是有深层次的原因。
>
> > Linux是个大框，什么都可以放进去。如果把它分解开，就会发现每个软件，或每类软件几乎都有高质量的 maillist or forum or
> > irc chanel. 如果真的要找答案，可能去那边得到的回答的机会更多。
>
> > 我们这个列表的技术类的 email 定位在哪？需要解决什么问题？有什么问题是别的maillist/forum/irc
> > 解决不了，或者不容易解决的？我觉得有这么两类
>
> > 1. 需要现场指导的。在同城比较方便
> > 2. 同城的技术活动
>
> > 我觉得OT贴也反映了2个情况，1. 大家能通过别的渠道解决大部分问题，2. 大家渴望和同城的兄弟姐妹们加强人际间的交流。
>
> > 我们是不是立足于同城，而不是立足于技术？来这里的都是对linux/freesoftware有兴趣的朋友。我们用各种方法解决问题，但shlug是我们有地 域归属感的一个列表。我觉得应该强化这样一种地域感。而不是强化技术感。
丁一恒
非常同意，口水太多，导致Maillist都成垃圾邮件了，这里不是大家即兴聊天的地方，这里不是QQ，宁缺勿滥。
贴一个Perlchina group的邮件，应该这样专业的态度看齐。
这个问题还是另外开一个thread来讨论吧，这个thread是专门讨论OT的问题的，所以，不好意思了
Shell Xu
--
无能者无所求，饱食而遨游，泛若不系之舟
Hades Enduos
Richard Shi
小马xiaoma
You don't have permission to access / on this server.
Apache/2.2.14 (Ubuntu) Server at www.rootguide.org Port 80
该网站的安全证书不受信任！
尝试访问的是 rootguide.org，但服务器出示的证书由您计算机的操作系统不信任的实体颁发。这可能表明服务器自行生成了安全凭据，谷歌浏览器认为其中的身份信息不可靠；也可能表明攻击者正尝试拦截您的通信内容。您应该停止操作，如果以前从来没有看到过针对此网站的警告，则更应特别留意。
Hades Enduos
Regards,
Richard Shi
--------------------------------------------------
From: "��xiaoma" <cnxi...@gmail.com>
Sent: Wednesday, September 08, 2010 3:47 PM
To: <sh...@googlegroups.com>
Subject: Re: [shlug] Re: [����] ����SHLUG���OT����
> Forbidden
>
> You don't have permission to access / on this server.
>
> Apache/2.2.14 (Ubuntu) Server at www.rootguide.org Port 80
>
> ����վ�İ�ȫ֤�鲻�����Σ�
> ���Է��ʵ��� rootguide.org������������ʾ��֤����������IJ���ϵͳ�����ε�ʵ��䷢������ܱ�����������������˰�ȫƾ�ݣ��ȸ��������Ϊ���е������Ϣ���ɿ���Ҳ���ܱ��������������������ͨ�����ݡ���Ӧ��ֹͣ�����������ǰ����û�п�������Դ���վ�ľ��棬���Ӧ�ر����⡣
>
>
> �� 2010��9��8�� ����3:41��Hades Enduos <hades_...@hotmail.com> ���
>> ��ʵ��¥Ҳ�Ѿ����ˣ���Ŀǰ���ڻָ�www.rootguide.org��ubuntu����Դ��˳���Լ���mailman���˸�maillist��
>> ϲ��OT�Ŀ��Լ�һ�£�˳�����æ���ԣ�10����ǰ�ս��õġ���Ŀǰ�Ҿ���������״̬������ϸ������Ū��
>>
>> ���϶��ĵ�ַ��
>> https://rootguide.org:10000/virtualmin-mailman/unauthenticated/listinfo.cgi/cnshrg-zh
>>
>>
>> Regards,
>> Richard Shi
>> From: Shell Xu
>> Sent: Wednesday, September 08, 2010 3:31 PM
>> To: sh...@googlegroups.com
>> Subject: Re: [shlug] Re: [����] ����SHLUG���OT����
>> �Ǹ���OT�����е�OT������Ա��ban�ҡ�
>> ��ֻ��������㷨��map-reduce��
>> ��ij��������ÿһ�У������Ա�ӳ��Ϊ��ô���һ������
>> hash_map(key<->((v1, 1), (v2, 1)...))
>> ���У�v1����ԭ����ֵ��1������ֵ�ļ���0���NA��vΪ0��
>> ���������������˺ϲ���
>> ���key1 != key2���ϲ�
>> key1 == key2����ÿ��Ԫ�ؼӺͣ�����Ӻ͡�
>> ���������������Ա��ϲ�Ϊһ������
>> ���������з���ӳ�䣬�Ϳ��Եõ���Ҫ��ֵ��
>> �� 2010��9��8�� ����10:49��Raymon <raymon...@gmail.com>���
>>>
>>> �dz�ͬ�⣬��ˮ̫�࣬����Maillist���������ʼ��ˣ����ﲻ�Ǵ�Ҽ�������ĵط������ﲻ��QQ����ȱ���ġ�
>>>
>>> ��һ��Perlchina group���ʼ���Ӧ������רҵ��̬�ȿ��롣
>>> ---------------------------------------------------------------------
>>> ���һ���㷨���ϴ��ʹ��ǻ���û�и������
>>>
>>> ����������һ������
>>>
>>> sex 7.2 3.8 6.8 9.2 5.6
>>> sex 5.4 2.3 4.6 8.9 9.0
>>> sex 6.7 NA 7.8 9.0 3.1
>>> goo 2.4 6.7 NA 9.0 2.1
>>> goo 2.1 5.6 7.8 9.7 1.2
>>> pkk 2.5 4.3 6.5 4.9 0.2
>>> pkk 2.1 3.4 3.2 NA 4.6
>>> pkk 3.2 5.6 6.7 9.1 2.2
>>> ...
>>> ...
>>> ...
>>>
>>>
>>> �������ܼ�������һЩͬ����У�������Ҫ�����ǣ�����Щͬ����е���ݰ�ÿһ�кϲ���������ʲô�ϲ�������ÿһ�е�ƽ��ֵ���ϲ�
>>>
>>> ����˵����������Ϊsex���У���һ�����Ϊ: 7.2, 5.4, 6.7 ��ô��һ�е�ƽ��ֵ����(7.2+5.4+6.7)/3=6.4,
>>> �ڶ������Ϊ3.8, 2.3, NA, ��ôƽ��ֵ���� (3.8+2.3)/2=3, �Դ����ƣ��õ�ÿһ�е�ƽ��ֵ����Ϊ����ֵ����ô����Ϊ
>>> sex�������ͺϲ�Ϊ��
>>> sex 6.4 3 ....
>>>
>>> ����Ҫд����һ������ԭ��ܼɣ����DZ��˵�ˮƽ���ޣ�д�ij���Ч���ϲ�ȥ��
>>>
>>>
>>> ��������д�ģ�
>>>
>>> ����һ��hash�������е�����sex, goo, pkk.....
>>>
>>> Ȼ��������hash, foreach (%hash) { }
>>>
>>> ÿһ�Σ�����ͬ�������ȡ�����ŵ�һ������@num��
>>>
>>> ���������һ��ֵ��ȷ���ģ��Ǿ���������ȷ���ģ����Զ�ÿһ������@num, ����for($i=0;$i<����;$i++) ѭ������ÿһ��ȡ������
>>> �ŵ�һ���µ�����@haha��
>>>
>>> Ȼ��for($j=0;$j<@haha;$j++) ��@haha��ƽ��ֵ���������Ϊ��һ�е�����ֵ
>>>
>>> ����������
>>>
>>> ��������д�����ˣ��������������Ƚ��ٵ����������û��ʲô���⡣����������д������к��У�������40000�У�500�У���������£��������
>>> �Ͳ���һ������������ˡ����������죬��û�����ꡣ��������Dz�����������ô�õġ�
>>>
>>> ��������ǰ�æָ�̡��dz���л��
>>>
>>> reply 1:
>>> һ�������Ч�ʵİ취��
>>> �ڶ�����ݵ�ͬʱ���д��?��Ҫ�÷�����ѭ����
>>> while(<FILE>)
>>> { my @itmes=split(/\s+/);
>>> foreach (1..$#items)
>>> { next if $items[$_] eq 'NA';
>>> $hash{$items[0]}->[$_]->{sum}+=$items[$_]; #�����ܺ�
>>> $hash{$items[0]}->[$_]->{count}++; #���Ǽ���
>>> }
>>> }
>>> �����ڶ�ȡ�������ļ����б�������ֵͬʱ�����
>>> ����������ܻ���һ��bug�����ǵ�ij��key��ijһ����ȫ����NA������£��ͻ���ȫ����������......
>>>
>>> ��֮�����ܷ�������ѭ����
>>> ������������������ʱ��Ӧ��Ҳ���Ǽ����ӵ����顣
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sep 7, 10:33 am, Thomas Iverson <tho...@shlug.org> wrote:
>>> > 2010/9/7 Ben Luo <ben...@gmail.com>:
>>> >
>>> > > �Ҿ��ÿ��ܻ��������ε�ԭ��
>>> >
>>> > > Linux�Ǹ����ʲô�����ԷŽ�ȥ��������ֽ���ͻᷢ��ÿ���������ÿ������������и������� maillist or forum or
>>> > > irc chanel. ������Ҫ�Ҵ𰸣�����ȥ�DZߵõ��Ļش�Ļ���ࡣ
>>> >
>>> > > ��������б�ļ������ email ��λ���ģ���Ҫ���ʲô���⣿��ʲô�����DZ��maillist/forum/irc
>>> > > ������ˣ����߲�������ģ��Ҿ�������ô����
>>> >
>>> > > 1. ��Ҫ�ֳ�ָ���ġ���ͬ�DZȽϷ���
>>> > > 2. ͬ�ǵļ����
>>> >
>>> > > �Ҿ���OT��Ҳ��ӳ��2�������1. �����ͨ����������������⣬2.
>>> > > ��ҿ����ͬ�ǵ��ֵܽ����Ǽ�ǿ�˼ʼ�Ľ�����
>>> >
>>> > >
>>> > > �����Dz���������ͬ�ǣ����������ڼ�����������Ķ��Ƕ�linux/freesoftware����Ȥ�����ѡ������ø��ַ���������⣬��shlug�������е�
>>> > > ������е�һ���б?�Ҿ���Ӧ��ǿ������һ�ֵ���С�����ǿ�������С�
>>> >
>>> > Ben�����������ͬ�ǣ�KDSһ�����ˣ��ο����и�����
>>> >
>>> > ��˵��רҵ������б?�ܶ��Ӣ�ĵģ���ô�кܶ����ѱ����뽻��kvm������xen��û�йٷ��������б?��ô�죬ֻ��������shlug�����Ի�����Ƚ϶��
>>> > �������
>>> > ���shlug���Լ������㣬������˵����������б���Է�չ����ɢ�ij̶�
>>> >
>>> > --
>>> > ghosTM55
>>> > Shanghai Linux User Group
>>> >
>>> > Keep It Simple
>>> > Stupidhttp://www.ghosTunix.orghttp://twitter.com/ghosTM55
>>
>>
>> --
>> ������������ʳ�����Σ�������ϵ֮��
>>
>
Hades Enduos
���ں�������ˡ���
Regards,
Richard Shi
--------------------------------------------------
From: "Hades Enduos" <hades_...@hotmail.com>
Sent: Wednesday, September 08, 2010 3:51 PM
丁一恒
Regards,
Richard Shi
--------------------------------------------------
From: "Hades Enduos" <hades_...@hotmail.com>
Sent: Wednesday, September 08, 2010 3:51 PM
To: <sh...@googlegroups.com>
Subject: Re: [shlug] Re: [管理] 关于SHLUG里的OT讨论
域名@解析好像有点问题。。。。悲剧。。。
Regards,
Richard Shi
--------------------------------------------------
From: "小马xiaoma" <cnxi...@gmail.com>
Sent: Wednesday, September 08, 2010 3:47 PM
To: <sh...@googlegroups.com>
Subject: Re: [shlug] Re: [管理] 关于SHLUG里的OT讨论
Forbidden
You don't have permission to access / on this server.
Apache/2.2.14 (Ubuntu) Server at www.rootguide.org Port 80
该网站的安全证书不受信任！
尝试访问的是 rootguide.org，但服务器出示的证书由您计算机的操作系统不信任的实体颁发。这可能表明服务器自行生成了安全凭据，谷歌浏览器认为其中的身份信息不可靠；也可能表明攻击者正尝试拦截您的通信内容。您应该停止操作，如果以前从来没有看到过针对此网站的警告，则更应特别留意。
在 2010年9月8日 下午3:41，Hades Enduos <hades_...@hotmail.com> 写道：
其实这楼也已经歪了，我目前正在恢复www.rootguide.org的ubuntu镜像源，顺手自己用mailman建了个maillist。
喜欢OT的可以加一下，顺便可以帮忙测试，10分钟前刚建好的。。目前我觉得是能用状态，具体细节慢慢弄。
附上订阅地址：
https://rootguide.org:10000/virtualmin-mailman/unauthenticated/listinfo.cgi/cnshrg-zh
Regards,
Richard Shi
From: Shell Xu
Sent: Wednesday, September 08, 2010 3:31 PM
To: sh...@googlegroups.com
Subject: Re: [shlug] Re: [管理] 关于SHLUG里的OT讨论
那个，OT帖子中的OT，管理员别ban我。
我只想出个简单算法，map-reduce。
你的超级矩阵的每一行，都可以被映射为这么样的一个对象：
hash_map(key<->((v1, 1), (v2, 1)...))
其中，v1是你原本的值，1代表这个值的计数，0代表NA，v为0。
而两个对象可以如此合并：
如果key1 != key2，简单合并
key1 == key2，对每个元素加和，计数加和。
最后，你的整个矩阵可以被合并为一个对象。
这个对象进行反向映射，就可以得到你要的值。
在 2010年9月8日 上午10:49，Raymon <raymon...@gmail.com>写道：
非常同意，口水太多，导致Maillist都成垃圾邮件了，这里不是大家即兴聊天的地方，这里不是QQ，宁缺勿滥。
贴一个Perlchina group的邮件，应该这样专业的态度看齐。
---------------------------------------------------------------------
求教一个算法，上次问过，但是还是没有搞清楚。
比如有这样一个矩阵：
sex 7.2 3.8 6.8 9.2 5.6
sex 5.4 2.3 4.6 8.9 9.0
sex 6.7 NA 7.8 9.0 3.1
goo 2.4 6.7 NA 9.0 2.1
goo 2.1 5.6 7.8 9.7 1.2
pkk 2.5 4.3 6.5 4.9 0.2
pkk 2.1 3.4 3.2 NA 4.6
pkk 3.2 5.6 6.7 9.1 2.2
...
...
...
这个矩阵很简单，就是有一些同名的行，现在我要做的是，把这些同名的行的数据按每一列合并起来，按什么合并，按照每一列的平均值来合并
就是说，比如行名为sex的行，第一列数据为: 7.2, 5.4, 6.7 那么第一列的平均值就是(7.2+5.4+6.7)/3=6.4,
第二列数据为3.8, 2.3, NA, 那么平均值就是 (3.8+2.3)/2=3, 以此类推，得到每一列的平均值，作为最后的值，那么行名为
sex的行最后就合并为：
sex 6.4 3 ....
就是要写这样一个程序，原理很简单吧，但是鄙人的水平有限，写的程序效率上不去。
我是这样写的，
先用一个hash存下所有的行名：sex, goo, pkk.....
然后遍历这个hash, foreach (%hash) { }
每一次，把相同行名的行取出来放到一个数组@num中
这个矩阵有一个值是确定的，那就是列数是确定的，所以对每一个数组@num, 我用for($i=0;$i<列数;$i++) 循环，把每一列取出来，
放到一个新的数组@haha中
然后for($j=0;$j<@haha;$j++) 把@haha的平均值算出来，作为这一列的最后的值
就是这样。。。
程序我是写出来了，对于行数和列数都比较少的情况，程序没有什么问题。但是如果我有大量的行和列，比如有40000行，500列，这种情况下，这个程序
就不是一两天能跑完的了。我跑了三天，还没有跑完。工作情况是不允许我跑这么久的。
恳请高手们帮忙指教。非常感谢！
reply 1:
一个简单的提高效率的办法：
在读入数据的同时进行处理，不要用反复的循环。
while(<FILE>)
{ my @itmes=split(/\s+/);
foreach (1..$#items)
{ next if $items[$_] eq 'NA';
$hash{$items[0]}->[$_]->{sum}+=$items[$_]; #这是总和
$hash{$items[0]}->[$_]->{count}++; #这是计数
}
}
这样在读取完输入文件后，进行遍历计数均值同时输出。
不过，这里可能会有一个bug，就是当某个key的某一个列全部是NA的情况下，就会完全不输出而被跳过......
总之，不能反复的做循环。
估计这样运行起来的时间应该也就是几分钟的事情。
On Sep 7, 10:33 am, Thomas Iverson <tho...@shlug.org> wrote:
> 2010/9/7 Ben Luo <ben...@gmail.com>:
>
> > 我觉得可能还是有深层次的原因。
>
> > Linux是个大框，什么都可以放进去。如果把它分解开，就会发现每个软件，或每类软件几乎都有高质量的 maillist or forum or
> > irc chanel. 如果真的要找答案，可能去那边得到的回答的机会更多。
>
> > 我们这个列表的技术类的 email 定位在哪？需要解决什么问题？有什么问题是别的maillist/forum/irc
> > 解决不了，或者不容易解决的？我觉得有这么两类
>
> > 1. 需要现场指导的。在同城比较方便
> > 2. 同城的技术活动
>
> > 我觉得OT贴也反映了2个情况，1. 大家能通过别的渠道解决大部分问题，2. > > 大家渴望和同城的兄弟姐妹们加强人际间的交流。
>
> >
> > 我们是不是立足于同城，而不是立足于技术？来这里的都是对linux/freesoftware有兴趣的朋友。我们用各种方法解决问题，但shlug是我们有地
> > 域归属感的一个列表。我觉得应该强化这样一种地域感。而不是强化技术感。 > > >
> Ben，如果立足于同城，KDS一个就够了，何况还有个豆瓣
>
> 你说的专业领域的列表，很多都是英文的，那么有很多朋友比如想交流kvm，交流xen，没有官方的中文列表，怎么办，只能求助于shlug这样卧虎藏龙比较多的
> 技术列表了
> 如果shlug不以技术立足，不是我说大话，三个月内列表可以发展到解散的程度
>
> --
> ghosTM55
> Shanghai Linux User Group
>
> Keep It Simple > Stupidhttp://www.ghosTunix.orghttp://twitter.com/ghosTM55
--
无能者无所求，饱食而遨游，泛若不系之舟
Hades Enduos
Richard Shi
丁一恒
Cheng
Hades Enduos
Richard Shi
姚毅捷
你们看LINUX系统不适合玩游戏，LINUX的使用者都是一些高端人才，他们非常封闭。
Thomas Iverson
> 刚刚我突然发现一个问题，我们的论坛叫shlug。。。。。上海linux
> group。。。那你具体是什么问题就完全没有说明过。那为什么不能OT呢？如果理解的话就是所有linux
> 的问题都可以，linuxer的问题也可以。那有明显的说明过哪些问题是可以哪些是不可以的吗？没有吧。本来就是个包容所有的地方。
我们哪里说过不能OT?
> 你们说的那种只说相关问题的MAILLIST有。像gapproxy。我在这个还有人boog啥的，做事件记录的。人家是只对该软件交流。
> 还是那句话，为什么要把LINUX搞的好像很高深一样，难道LINUXER不需要游戏？不需要打屁？然后就又变成微软攻击LINUX的一个方式。
引用chaos的话，你的理解能力，令人发指
--
ghosTM55
Shanghai Linux User Group
Keep It Simple Stupid
http://www.ghosTunix.org
http://twitter.com/ghosTM55
STRONG
1 基本上赞同OT贴加标签，但可操作性方面可多想想。 要求了OT贴要加标签，是否有一个好的通告方式，比如群发邮件给所有成员以知晓此规定，有些
从web访问的用户能在首页的介绍里也能明确了解到这个规定。 对新人默认发送一个邮件列表的礼仪介绍。 说这个事情我也是猜测可能有个情况是，
group里的成员层次不同，不能说加OT是邮件列表的常识大家就真的有常识了，所以规定了通告到位才是靠谱的。
2 对于习惯邮件订阅的用户来说，规定好OT，而理想状态大家都遵从的话，选择订阅完整邮件发送可在邮箱设置过滤器，将shlug 非OT的过滤出
来，是最完美的。
然而规矩有时总是被打破的，如果邮件列表本身包括OT非OT，且活跃度比较高，选择订阅摘要是必要的，否则不遵从规定的OT贴绝对叫你跳起
来。
3 我主要是web浏览为主，感觉是否OT对web用户影响不大，但web用户要翻墙才能访问估计这部分的用户也不多～ 我只邮件订阅自己团队的邮
件
On Sep 8, 6:22 pm, Thomas Iverson <tho...@shlug.org> wrote:
> 2010/9/8 姚毅捷 <594d...@gmail.com>:
Lavande
> 2010/9/8 姚毅捷 <594...@gmail.com>:
> > 刚刚我突然发现一个问题，我们的论坛叫shlug。。。。。上海linux
> > group。。。那你具体是什么问题就完全没有说明过。那为什么不能OT呢？如果理解的话就是所有linux
> > 的问题都可以，linuxer的问题也可以。那有明显的说明过哪些问题是可以哪些是不可以的吗？没有吧。本来就是个包容所有的地方。
>
> 我们哪里说过不能OT?
>
> > 你们说的那种只说相关问题的MAILLIST有。像gapproxy。我在这个还有人boog啥的，做事件记录的。人家是只对该软件交流。
> > 还是那句话，为什么要把LINUX搞的好像很高深一样，难道LINUXER不需要游戏？不需要打屁？然后就又变成微软攻击LINUX的一个方式。
>
> 引用chaos的话，你的理解能力，令人发指
>
这个问题，可能讨论到最后，要讨论到本邮件列表究竟是为了什么而建立的了。
管理学上有个这样的结构，就是一个组织，应该依次有：
Mission Statement（我们的组织为何而建立，我们创造什么价值之类的，觉得这
一点最重要了）
Vision (desired future state)
Goal (the general statement of aim or purpose)
Objectives (quantification or precise statement of the goal)
Strategies (methods used to achieve the objectives)
Control (monitoring of progress towards the goal --assess effectiveness
of strategies --change actions or strategies if necessary)
大概应该是上一条决定下一条=====================
Core Competences (what the organization does better than its competitors
which cannot be imitated)
今天课上刚学的哦，虽然我们不是什么公司，但是至少是一个组织，应该多多少少
可以使用这些原理，管理员童鞋可以参考一下，希望能派上用场：）
gundam0523
Lightning
> 加入列表好久了，第一次发话……
> 这个问题，可能讨论到最后，要讨论到本邮件列表究竟是为了什么而建立的了。
> 管理学上有个这样的结构，就是一个组织，应该依次有：
> Mission Statement（我们的组织为何而建立，我们创造什么价值之类的，觉得这
> 一点最重要了）
> Vision (desired future state)
> Goal (the general statement of aim or purpose)
> Objectives (quantification or precise statement of the goal)
> Strategies (methods used to achieve the objectives)
> Control (monitoring of progress towards the goal --assess effectiveness
> of strategies --change actions or strategies if necessary)
> 大概应该是上一条决定下一条=====================
> Core Competences (what the organization does better than its competitors
> which cannot be imitated)
> 今天课上刚学的哦，虽然我们不是什么公司，但是至少是一个组织，应该多多少少
> 可以使用这些原理，管理员童鞋可以参考一下，希望能派上用场：
>
姚毅捷
ablo
北京linux爱好者 组。
我创建的。我欢迎爱好者加入，同时也不限制讨论话题。其实用gmail 应该不会怕水了。
--
http://abloz.com
http://twitter.com/ablozhou
Thomas Iverson
> http://groups.google.com/group/linuxbj
>
>
> 北京linux爱好者 组。
> 我创建的。我欢迎爱好者加入，同时也不限制讨论话题。其实用gmail 应该不会怕水了。
banned
weibin li
电子邮件礼仪
引言
本文旨在为电子邮件用户提供向导。它不是“用户手册”，而是提供一些建议，不仅帮你“玩转”电邮（玩转的程度或许会出乎你的想象），还能帮你提防未来的“囧”境。
收件人，抄送和密抄
收信人地址的填写方式有三种：“收件人”，“抄送”和“密抄”，也许你会认为这是小菜一碟。不幸的是，事实往往出人意表。
首先，有些用户完全无视“抄送”的存在。就算邮件只针对某一个人，他们也要把所有地址（译者注：这里指收件人、抄送地和密抄地址）统统塞到“收件人”。如此一来，所有收到信的人都弄不清楚究竟谁应该负责回复。结果，他们要么都回复，要么都不回复。
其次，有些用户不管三七二十一，把通讯录的所有联系人都作为每一封邮件的收信人。他们是那种“渴望他人注意”的人。
最后，有些用户从来不关心同一封邮件的其它收信人。这类人属于“喂，你收到没？”一族。举个例子，X给A，B和C发送了一封邮件。C不先检查A和B是否也是收到信，而是立刻转发，还画蛇添足地问道“喂，你收到没？”。
总的来说，关于如何填写收信人地址，下面有几条简单的建议：
· “收件人”地址应该是直接收信人。
· “抄送”地址应该是间接收件人。他们只想参考一下邮件，或者发信人觉得有必要知会他们（译者注：此处是意译，建议参考原文）。过犹不及，“抄送”给需要的人就够了，不必搬上整本通讯录。
· “密抄”和“抄送”差不多，唯一的区别就是：在同一封邮件中，“收件人”和“抄送”的收信人看不到“密抄”的邮箱地址，即“密抄”对于“收件人”和“抄送”不可见。相信你也猜到，使用“密抄”有点偷偷摸摸，所以并不被提倡。
全部答复
尽管“全部答复”只是一个小小的按钮，它却可以产生一大堆不必要的邮件。举个例子，如果我给12个人发送了邮件，请问他们是否能在某某时间出席会议。那么，我应该收到12封回复，不多也不少。但是，如果每个收信人都按了“全部答复”。那么，不单单我会收到12封，再算上其它人，邮件总数将达到144！
当然，我并不是说不能使用“全部答复”，而是应该谨用。
不要把自己当成小说家
邮件应该简洁切题。它和电话只是用手（打字）和用口（说话）的区别。迄今为止，还没有人凭打电话摘下普利策奖。所以将来也不会有人靠写邮件拿奖。
有一点很重要：某些人每天都要处理成百上千封邮件（这种人确实存在）。他（她）们最不想在邮件看到某人以为自己是未来的狄更斯。
太多标点符号
不要拘泥于语法和标点符号，尤其是滥用后者。你会常常看到有人为了强调，硬要在句子后面追加一大堆感叹号。对于滥用标点符号不能掉以轻心。感叹号（计算机术语叫做“bangs”）只是另一种结束句子的方式而已。
重要的事情应该体现在字里行间，而不是标点符号。
格式不是万能膏药
格式很管用，但不是万能膏药。（书写邮件）用语直白。句号。就够了。
用HTML（超文本标记语言）或者“天理难容”的Microquish富文本格式去“打扮”邮件，把字体和颜色弄得花里花俏，可谓自讨苦吃。殊不知许多电子邮件客户端（和某些服务器）都无法支持这些格式。结果把邮件弄得不知所云，更严重的还会使客户端崩溃。我就亲眼目睹过这种事。
如果你仍然斩钉截铁地坚持html，那么我劝你尽量使用默认的字体和简单的格式，把那些五颜六色的背景，千奇百怪的字体和动感十足的图片留给你的个人网站。
缩略语
缩略语在电子邮件中无处不在。为了少敲点键盘，人们用晦涩难解的缩略语（除非双方都能够明白其的含义）代替了一目了然的全称。下表罗列了部分常用的缩略语。我建议使用常见的英文缩略语，如“FYI”（For your information，仅供参考）或“BTW”（By the way，顺便说说），否则会把对方搞糊涂。
缩略语
含义
BCNU
be seeing you（再见）
BTW
by the way（顺便说说）
FWIW
for what it's worth（不论如何）
FYI
for your information（仅供参考）
IMHO
in my humble opinion（依我愚见）
OBO
or best offer（优惠价格）
ROTFL
rolling on the floor laughing（捧腹大笑）
RTFM
read the funny manual（参考有趣的手册）
TNSTAAFL
there's no such thing as a free lunch（没有免费午餐）
TTFN
ta ta for now（再见）
TTYL
talk to you later（再见）
字符表情
一定程度上，视觉提示是成功地面对面沟通的关键。究竟表情和肢体语言对于沟通有多重要？一个简单的眼神就可以区分“肯定”和“非常肯定”。那么听觉提示呢？答案显然也一样。
因为电子邮件无法使用视觉或听觉提示，所以人们发明了“字符表情”。它们是一些简单的字符串，穿插于邮件之间，用于表达作者的情绪（或暗示）。最常见的字符表情莫过于:-)。如果你把头向左转，就会看到一个笑脸（分号是眼睛，破折号是鼻子，右括号代表嘴巴）。下面有更多的例子：
字符表情
含义
:-)
Smiley face 笑脸
;-)
Wink (light sarcasm) 调皮地笑
:-|
Indifference 不关心
:->
Devilish grin (heavy sarcasm) 邪恶地笑
8-)
Eye-glasses 戴眼镜的人
:-D
Shock or surprise 惊讶
:-/
Perplexed 困惑
:-(
Frown (anger or displeasure) 皱眉 (生气或不开心)
:-P
Wry smile 鬼脸
;-}
Leer 斜眼看
:-Q
Smoker 吸烟的人
:-e
Disappointment 失望
:-@
Scream 尖叫
:-O
Yell 大喊大叫
:-*
Drunk 醉酒
:-{}
Wears lipstick 涂口红的人
请不要（随便拿个字符表情）来让我解释，我也没办法统统弄懂。它们通常出现在句末，其意思要联系上下文来解释。我建议你使用字符表情要适可而止。它们不仅数量惊人，而且意思也模棱两可（一不小心“表错情”可能会惹火上身）。
称呼
这里有一个问题：“（对于电子邮件）到底多亲密才算太亲密？”说得再具体点，就是你如何为邮件开头：“亲爱的先生”，“亲爱的史密斯先生”，“乔”还是其它。
如果你拿这个问题去请教礼仪专家，我估计她会不假思索地答道——跟着标准规范走吧——不过我并不同意。
对于非商务邮件的称呼，我建议你跳过标准规范。我顶多也只是使用像“亲爱的维吉尔”之类的称呼，或者直接“维吉尔”。
商务邮件则复杂得多。如何称呼应该具体问题具体分析。不过我通常会遵守这些规则：如果你经常称呼某人为史密斯小姐/夫人/先生，不妨在邮件中依样画葫芦。对于直呼其名的朋友，我要么省略称呼，要么遵循上一段的做法。实在无法确定的话，标准规范就是最安全的做法。
签名
如果你想猜猜什么是“电子邮件的签名”，我估计你的答案八九不离十。
在纸质文档（保护树木，请用电邮）的末尾，使用手工签名是一种常见的做法，如下所示。
Gene Wicker, Jr.
I Will Follow... Services由于电子邮件无法使用手工签名（至少目前如此），于是人们有时会在邮件后面添加一些固定不变的信息（不妨称之为“准签名”）。
我强烈推荐这种做法，因为并非每个收信人都认识发信人。许多公司使用员工姓名的缩写或数字作为其邮箱地址。可是，这些缩写和数字对于陌生人毫无意义。
另外，我也建议把在“准签名”中加入你的邮箱地址。有时收信人收到的信息是残缺的，尤其是那些依靠Internet传播的电邮（注：并非所有邮件都是通过Internet传播，比如公司的内部邮件）。因此收信人有时很难确定发信人是谁。
如果你使用商务邮箱，不妨把你的职位和公司也添加到“准签名”中。这通常相当于信件抬头的一部分，不过电子邮件并没有“信件抬头”这个概念（浪费空间）。
你有时会在“准签名”中看到人名后面还跟着一句格言（类似于“。。。生命的秘密就是没有秘密”）。这种做法已经蔚然成风。如果你也如此，我的建议是：你是一个怎样的人，就选择怎样的格言。还要保持简短，你不会想要比正文还冗长的格言。
你还会在准签名中碰到一些由字符构成的图形。除非亲眼所见，否则你很难去描述它们。不过一旦你遇到了，立刻会发现它们其实一目了然。和格言一样，字符图形也应该是你个性的投影。
对于“准签名”，无论是格言还是字符图形，抑或两者兼有，我建议总行数不要超过4行。
附件
以前拨号上网的时候，我建议所有附件不要超过1MB。随着带宽的不断扩大，情况亦不可同日而语。
对于拨号上网的用户，1MB的上限仍然管用。至于宽带或直接相连的用户，我会把上限提高到5MB。不过这种说法并非一成不变。即使是使用宽带或直连的用户，也无法保证他（她）们的邮箱有足够的容量来处理这些附件。对于一个小邮箱，你也清楚一个5MB的附件会很快地把它撑爆，并导致其它邮件的丢失（注：现在的邮箱动辄上G，所以“撑爆”的情况实属罕见）。
一般来说，仅当我清楚对方确实需要的时候，才会发送5MB的附件。
v卡简直就是outlook用户（我正是其中之一）的恶梦。它使每一封电子邮件看起来都像带有附件。尽管它和附件有某些类似，却不是你心目中真正的附件，比如文档、电子表格等。因此我不推荐使用它们。
线索
一旦你发送第一封邮件，便可能收到回复。如果你想回复对方的回复，该怎么办？错误的做法是创建一封新邮件。因为它打断了原始邮件和回复邮件之间的关联（所谓的“线索”）。一旦失去关联，双方就难以跟踪邮件的次序，尤其是经过多次收发的邮件。当你处理新闻组（更新更频繁）的时候，这个问题会更加突出。因为某些新闻组用户不仅回复，还想跟踪已交流的信息的线索。正确的做法是使用“回复”功能，它本质上相当于创建新邮件，却维护了邮件之间的线索。
引用
恐怕没什么比下面这件事更劳神费力：在邮件末尾码上几只字：“同意”，“好的”或“嗯（ditto）”，却硬是把原始邮件完封不动地复制过来。
正确的做法是引用，下面这个例子就是最好的解释：
>请问您同意聘请罗丝夫人来处理我们的法律事务吗？
是的，请适当安排。
句子前面的“>”符号告诉收信人，这些引用的内容来自于他（她）的上一封邮件。第二句则是你针对引用内容的回复。引用的关键是引用适量的内容使对方心领神会。设想你收到一封长达几百行的邮件，而真正需要回答的问题却在最后一行。那么你有什么理由要把整封邮件都引用进来（而不是单单引用那个需要回答的问题）？否则，就算对方只对你的回答感兴趣，也不得不从头到尾把整封邮件翻一遍。
引用可以嵌套使用，如下：
>>请问您同意聘请罗丝夫人来处理我们的法律事务吗？
>是的，请适当安排。安排好了。我们的第一次会议将安排在明天早上。
在这个例子中，我们看到了两层引用（>>）和一层引用（>）。两层引用">>"表示发信人正在引用你上次引用的内容，">"正是其中的一部分。
不要在引用上纠缠不清。过多的引用层级只会喧宾夺主，从而淹没了真正的意思。
保护树木
我有时候觉得最好的事就是能让人们远离打印机。为什么？因为每次我给别人发邮件，三分之一的人读都没读就把邮件打印出来，另外三分之一阅读后还是会打印，只有最后的三分之一读完直接把邮件干掉。
使用电子邮件的目的之一就是根除（或大量减少）纸张的滥用。如果大部分人都把收到的邮件拿去打印，这岂不是违背了初衷？我不是说所有邮件都不能打印，而是太多的邮件被不明不白地打印（相当一部分被打印之后，就再也没离开过打印机）。
除非你使用非常原始的邮件系统，否则它都会提供一个功能（通常叫“文件夹”）来永久保存邮件，方便日后随时查看。常常打印邮件的人如果能在电脑中建立和现实文档组织结构相同的文件夹（来保存邮件），不仅达到了同样的目的，还节省了大量的纸张（和树木）。
个人隐私，开玩笑么？
打住吧，留点脑细胞好好想想下面这句话：电子邮件没有任何隐私可言。我不管别人怎么说，怎么证明，怎么发誓还是怎样怎样，反正电子邮件就是没有隐私。理由？继续读下去吧。
对于某些电子邮件系统，管理员可以阅读其中的所有电子邮件。如果碰到这种情况，你最好求上帝保佑你的管理员是一个诚实可靠的人。
某些公司会监管员工的电子邮件（我觉得这种审查再糟糕不过）。这种令人瞠目结舌的做法的借口更是花样百出，无论是管理层想确保员工没有在不必要的邮件上浪费精力，还是确保不能通过非官方渠道泄露公司机密。
和所有软件一样，电子邮件也会偶尔出错。一旦故障发生了，你可能会收到原本属于别人的邮件，或者你的邮件发错给别人。无论是收错还是发错，你所以为的隐私都不复存在。
在地球上某个角落存在着这样一种人（通常称为“黑客”），只要他（她）们足够努力（破解邮件系统），就能够阅读你的邮件。当然，“足够努力”很必要，阅读他人的邮件通常没那么简单。此外，电子邮件系统通常采用一些安全措施来防止类似的入侵，然而百分之百“黑客免疫”的安全措施并不存在。在前面两个句子中，我使用了“通常”这个字眼，因为我假定安装或管理电子邮件系统的人都会采取一些必要的预防措施。当然，同样的安全也必须在邮件的另一方得到保证。
总结一下：首先，让我重申最初的说法：电子邮件没有任何隐私可言，懂么？其次，如果你觉得某件事不能在公司的公告牌上公布出来，那么就不要在邮件中提及它。相反，如果它对于公告牌而言是安全的，则邮件亦然。如果你还在争论到底个人隐私可不可以通过电子邮件发送，我想还是亲手交给对方或者使用普通邮政系统来得安全。
从公司送出的邮件，代表的就是公司
不管内容是什么，从公司送出的个人邮件都被认为是公司的官方消息。这也许会给你和你的公司惹上一些不必要的麻烦。嘿，没吓着吧？怒火
“怒火”是什么东东，或者再具体点，什么叫“惹火上身”？“惹火上身”的意思是：你发送了邮件给某人，却导致对方恶言相向。基本上这算是一种电子型的言语攻击。我想提供一些例子，由于无法确定读者的年龄，为免日后“惹火上身”，我想想还是算了。
有时“起火”的原因显而易见（读下去），有时却让你摸不着头脑。例如，你给10个人发送了一封自以为无害的邮件。9个人语气平和反应正常，不料第10位却狠狠地烧了你一把。谨记“一千个人眼中有一千个哈姆雷特”。或许你是个幸运儿，一直以来都和前面的9个人打交道，不过我敢打赌你迟早会撞上第10个。
如何应付“怒火”？这个问题颇为棘手。最好的回应就是无视它们，像其它讲逻辑讲道理的人一样继续过你的日子。如果这不是你的第一反应，估计是你已经被烧得“体无完肤”，忍无可忍了。可是，你会发现任何回应都是徒劳。记住，古人云：你只能满足部分人……
如果真的选择了回击，你最终可能会卷入所谓的“flame war（骂战）”。谩骂的双方或者多方会在这里没完没了地“驳火”，常见的招数不外乎“问候对方的母亲”，“质疑对方的智商”等。某种情况下，交战的各方最终都忘记了争吵的初衷，变回正常的人类。
从来没有惹火上身？好吧，如果你真的很想试试，我倒有下面几个建议：· 发送一封只有大写字母的邮件。大写字母相当于对准别人的耳朵大喊大叫。它仅用于强调（注：原文是“ONLY use upper-case words when trying to make a point (such as I just did)”，作者巧妙地演示了大写字母的用法，可惜中文无法体现出来）。即便如此，你也要谨慎对待交流邮件的另一方。
· 对（他人邮件的）语法或标点的用法指手画脚。这就像是和八年级（注：美国童鞋的八年级相当于我们的初三）的英语老师交流邮件一样，没人会感兴趣。
· 群发大量广告。这是“不要这样做”排行榜中的头把交椅，它惹的麻烦比魔鬼还要多。想想邮局每天给你“倒”了多少垃圾信件。即便有一百个不愿意，你也不得不从头到尾一封接一封地大海捞针，因为月度的水费单往往就夹杂在那一大堆不请自来的广告和废纸之中。电子邮件也是这个道理。你想在塞满广告的邮箱中翻箱倒柜，仅仅为了找到来自老板的非常重要的邮件吗？
· 寻求电脑技术支持却不提供详细的系统信息。举个例子，假设我提交一封电子邮件说“我有一个关于Word软件的问题……”。那好，究竟这是Word97，Word2000，XP的Word还是2003的Word？如果你安装的软件有版本之分，则告诉对方版本号。记住，电脑的世界（还有其用户）是由你想象得到的各种各样的电脑所组成的，从个人电脑到苹果电脑，再到Linux工作站，甚至还有你的邻居在车库里组装而成的电脑。正确的做法是先列出所有详细的系统信息，再说明故障或问题。举个例子，如果家中电脑的Microsquish Word发生了故障，我正在寻求其解决方法。那么我应该这样列清单：Windows 2000 SP5，Office 2000 SR3，惠普Kawack，酷睿奔腾2，512MB内存，4GB的SCSI硬盘，再详细地描述问题。
比“蜗牛”邮政“牛”
你可能会这么想：既然电子邮件是“电子的”而且电子信息是以光速传播，那么电子邮件应该会在发出的几秒后到达目的地。如果收信人是你隔离的同事，它有可能这么快。不过大多数情况下，电子邮件可能会花费从几分钟（正常情况）到几天（非正常情况）的时间。
不妨这样想。发送本地的电子邮件和亲手把信交给对方一样容易。这样的话，如果你想把信亲手交给远在天涯海角的另一方，难道不应该多花点时间吗？
（收发电子邮件）花费更长的时间的原因是：邮件从A点传到B点，在到达终点之前可能会通过1个、2个，甚至数不清的不同的电子邮件系统。还记得我以前说过的话吗？不是所有的电脑（和电子邮件系统）都是一样的。
无论多远，我保证电子邮件一定比“蜗牛”邮政要“牛”（注：“蜗牛”邮政是电子邮件用户调侃传统邮政的说法）。此外，它还帮你省了邮票钱。福祸相倚
电子邮件是一种不要求即时回复（比如电话）的对话。如果某人打你电话，你拿起电话，然后开始对话（除非你有自动答录机、语音邮件或者你本来就是一个“大老粗”）。这叫做交互式的对话。
在电子邮件中，你发送邮件然后等待回复。对方的回复可能在五分钟后，也可能是五天后。无论如何，这都不是交互式的对话。
如果有100个人在同一天内给你发邮件，你会怎样？你没必要100人都回复。考虑一下忽略“你好”，“再见”和其它可有可无的闲聊。使用电子邮件，你可以自主安排时间处理重要的消息（忽略“你好”，“再见”等）。这就是电子邮件的好处。
现在说说坏处。
太多的用户都断定对方一旦收到邮件就会立刻打开阅读。这种“想当然”非常糟糕。
如果你正在安排一个1小时后举行的会议，并给每个出席者发送了邮件。所有人都在1小时内阅读你的邮件的概率非常小。另一方面，如果会议安排在明天，那么机率会大多得。记住，电子邮件的设计初衷不是即时沟通（这是电话的“地盘”），而是方便沟通。
某些（不是全部）电子邮件系统提供了一些功能来弥补这个问题（即时沟通）。这些功能（通常叫“通知”）会在对方收到或阅读邮件时通知你（事实上它只能把“打开邮件”假设为阅读邮件——它无法确定收信人是否逐字逐句地阅读了邮件）。结合上一段的例子，你可以在会议开始之前检查谁看了邮件，然后直接给没看的人打电话。
Nick Young
Nick
近来有朋友抱怨SHLUG邮件列表里的OT讨论越来越多。
虽然我们没有精确的对于OT数量的统计，但每月目前近2000贴里OT比例的确有愈演愈烈的趋势。
邮件列表是一个公开讨论，畅所欲言的地方。我们几位管理成员与大家一样也不希望对OT讨论完全噤声，只在这里单纯的讨论技术话题。
但SHLUG毕竟是一个技术性的社区，技术讨论是我们的主旨。
所以特此我们向大家征求意见，对于OT内容的讨论我们现在在思考以下的举措：
1. 维持现状，大家自觉不要太严重以及太多的OT
2. 在SHLUG的网站上开一个web论坛供OT帖子讨论专用，SHLUG的邮件列表保持较为单纯的技术话题讨论
3. 新开启一个邮件列表供OT帖子讨论用，本邮件列表保持较为单纯的技术话题讨论
注：OT贴子的判定标准由群体讨论产生，凡在该范围内以外的主题都请在OT列表中讨论。
欢迎大家讨论，在一周之内（截止时间为9月13日）提出自己的观点与想法，我们将根据大家的意见采取相应的举措，谢谢。
SHLUG Coreteam
小马xiaoma
我一直在用Buzz, 觉得那就是谷歌出的微薄，只是集成在了Gmail里而已。
Thomas Iverson
> OT的话题发在邮件列表里有成百上千用户可以看到，但是发表在自己的Buzz上，没几个人看到。如果要达到同样的效果，等于是邮件列表里的每个人，都要去关注邮件列表的其他所有人。
>
> 我一直在用Buzz, 觉得那就是谷歌出的微薄，只是集成在了Gmail里而已。
buzz我不用，感觉洪水泛滥... 在gmail里禁用了
S‘LeX
姚毅捷
Qingsu Chen
> 拥护OT
>
喜欢OT的欢迎到各类IRC channel吹水。
表明拥护OT的，建议直接BAN掉。
不过，我对发展出中国特色的mail list文化，是没有意见，也是无能为力的。
只能表明一下态度。
Sami Zhan
Shen Chenjun
wang lei
Sami Zhan activity is the only road to knowledge 于 09/15/2010 07:55 PM 写道:
> 同意，OT去IRC比较合适
