【 在 [email protected] (补洞大作站 QQ) 的大作中提到: 】 : ※ 引述《[email protected] (痛苦的星期一 -_-)》之铭言： : 又 如果 贵站的功能全都是自己写的或是旧的水球系统也是自行研发的 那只能说这 : 一切实在是很巧 我并没有认为参考有何不对 事实上 Open Source bsded 的 BBS : Code 放出来後 本来就是欢迎互利共荣 但是取用的手法就是问题 我这边现在在用的水球是用 WD 的主架构和 FB 原来的功能整合起来的 因为 FB 的旧的系统是每按一下回讯就读一次硬碟去读发讯者的 pid 人多的话实在很操 HD 讯息记录也很肥 之前的硬体不够力常常因此出现 open too many files 就挂点 才会想说要来改改, 不然用得好好的东西我干麻动它 @_@ M3 的 BMW 功力不够, 看到 ** 两个星星 pointer to pointer 看也没看就先投降了 最後就拿了 WD 来改 : 前文我仅就参考来源与程式码部份请你於 发布时/程式码内部 补充说明 否则你一向 : 在 FB 群组出没 我本来就没有必要跑到那边去质问这个问题 早在你在贵站提出水球 : 的 patch 时我就很好奇了 没想到居然有人和我一样会用读档去处理传讯回顾 (光是 : 这种很烂的处理方式 我们真该握握手 :p) 这个就很奇怪了, 那个水球系统我好像没发布过吧, 就只是放着自己边用边抓虫 虫太多了还没抓完(因为太懒了想说能用就好), 又还有一个很重点的问题没解决 我那敢把这种半成品发布出来 @@ 至於程式码内部我如果从那边参考那边改来的都会写在里面啊 (也是因为懒, 刻程式刻到现在从没写过 CHANGE 之类的东西) 如果是整个档案拿来修的, 像水球和看板连署机, 我连最上面的一堆注解都留着哩 有需要的话整个档案寄给你看看也没问题啊 至於用读档去处理传讯回顾...呃...硬体不够力人又多的话还是不要试的好 不然大概会看到一堆文章的第一行出现 open too many files : 参照人家的 程式码 实作参考 到 概念参照 稍微提一下总是好 也是种习惯 何解 ? : 我改个函式名 叙述处理方式不同就可以说我是自创的 但别人不见得信 为了避免对 : 岸的类似问题发生 发布 patch 多点说明 可以少掉许多问题 : 至於我要声明一下 如果我因为抄这个字造成你的误会 那我必需在此在次澄清 参照 : Code 并无不好 porting 也是一种常途 我所强调的只是习惯性的知会一下你所得知 : 的来源作者 或是 公告一下前因後果 对於发布时的立场环境 会好很多 我自认我如果是拿别人的 code 来改的, 发布出来前一定都有注明出处 但上面那个推文就真的是运气好慢慢刻出来的, 要怎麽注明出处？ 至於水球系统我还在测试只是自己用跟本没放出来过, 又何来注明？ 最後像这种, 借引用一下你上面的文章 ! char filename[FNLEN-1]; /* M.109876543210.A */ + /* Dopin: idea by [email protected] */ + uschar goodpost; idea by 连这个都要写我就自认没办法了 我推文这边就是这样处理的, 当时很直觉就这样写了 可能也是之前架过 WD 有看过这段 code 吧 但总不可能边写 code 然後边去翻旧文章还是其他站的 source 去刻那个注解吧 看过一些文章和一些程式码, 可以用的, 写得好的, 都已经印象深刻, 想到就直接用了.. 当初会想碰 bbs 是想说可以练习写 C 还有学到一些程式技巧 新学校第一届刚好有机会试试看, 才会来做这种, 说真的, 没钱又吃力不讨好的工作 改 code 占用自己的时间是还好 自己有兴趣, 又有机器可以给你随便恶搞, 所以还玩得满高兴的 处理 user 一些奇奇怪怪的问题才真的让人头大 回个白目点的 user 的文章一篇就要一两个小时, 比刻程式还累 想不到现在一个五个多月前丢出来的东西也能被批成这样, 真是令人心寒 我还是回去专心去刻我专题的 MFC 算了 说真的, 也给你一个建议, 下次要批评前麻烦先问清楚情形再批 有怀疑寄个信来就是了, 我好像还没资格让您这样的大人物偷偷注意这麽久吧 不需要好像把每个人都当小人的样子, 这样是会浇熄很多人的热情的, 谢谢！ -- 只是叹息 只是叹息 很乾净 很乾净 很乾净........乾净 <叹息瓶> -- ※ 来源：高大原野星辰 bbs.nuk.edu.tw．From：h188.n219-68-241.adsl.giga.net