致歉声明

[GoogleCodeExporter]

我是一名大四的学生，去年10-11月间写了一片关于OJ的论文，�
��不久发表于某期刊。

文章中所述的绝大部分研究和idea均是基于HUSTOJ和FPS的，论文�
��稿中提到了这个，但是由于存在某些私心（便于论文发表）
，在某次修改时删去了这些文字。另外，原文中有致谢部分��
�提到了HUSTOJ的初创者Sempr和现任主要开发者zhblue，但一方面��
�于该期刊以往似乎没有致谢部分的习惯，一方面因为篇幅，�
��者国内也很少有那种语气强烈且包含一大串人网名的致谢文
字，该部分也没有出现在发表的版面中。

虽然之前我和zhblue在HUSTOJ主页里和通过email有过很多较深层次
的交流，有些主意比如采用成熟的SIM做代码抄袭检测、pending�
��存临时表的增设、ShareCode、通过mono支持.net等，可能是我较�
��提出，但是最终也是最早真正把它们实现在OJ中的毫无疑问�
��zhblue，我最多也就是手工做了几个验证性实验而已。而有句
话是A man has never done it has no say in 
it，所以zhblue毫无疑问享有这些技术实现的所有权利（特别是
FPS以XML格式的数据描述题目）。

我在此声明，HUSTOJ和FPS代码的原创性毫无置疑，即我的论文��
�基于HUSTOJ源码的，而不是hustoj项目使用了我在论文中的设计�
��希望大家如果看到此文，不要再产生任何质疑。

另外，感谢zhblue对我的过失既往不咎，同时也提醒其他开发��
�和研究者，不仅要注意开源社区的一些规则比如GPL，同时也�
��注意研究成果声明和归属的一些规则和惯例。建议大家在基
于HUSTOJ和FPS的所有源码中都要保留其标识、链接和GPL授权协��
�，并将改进后的代码依相同协议完全公开；所有基于HUSTOJ的�
��究成果也要注明。

Original issue reported on code.google.com by cn-...@china.com.cn on 12 Sep 2011 at 1:12

[GoogleCodeExporter]

注意：
原文中的队列模型可用，但CPU核亲和性绑定确实没有必要，��
�个设计本来是保证测量精确性的，但实际上这样虽然能让各C
PU（核）中的寄存器和部分Cache并行工作，但在SMP中，OJ中的��
�存行为的交叉是不可避免的，实验测试的结果也说明这一点�
��即用亲和性精确性没什么提升，反倒增加了系统的复杂性，
使系统极易崩溃。
（作为作者之一，我承认而且提醒：亲和性的描述只是paper的
需要，在实际OJ系统中并不实用）

Original comment by cn-...@china.com.cn on 12 Sep 2011 at 1:47

[GoogleCodeExporter]

Original comment by newsc...@gmail.com on 14 Sep 2011 at 3:48

• Changed state: Accepted