莫非上半部分是《linux系统编程》读书笔记？

hadoop用hdfs和kfs 哪个效果更好？

Hadoop HDFS VS KFS KFS采用C++实现.HDFS采用Java,与Hadoop整个生态系统结合紧密. 从效率上来讲, KFS要略胜一筹. 这个你测试过吗？hadoop用kfs和hdfs，哪个效率更好？

好东西，谢谢分享

AvatarNode实现NameNode HA 更加可行！ FACEBOOK就是用这个的，不过只能用与HADOOP 0.20版本的，暂时不能用于0.21 他的切换时间可以在1分钟内实现

@liangzhimy 当然，hadoop 是从nucth中剥离出来的，nucth是一个基于lucene的搜索引擎，所以，你要了解hadoop与lucene你可以看看nucth源码，呵呵,lucene,nutch,hadoop都是大牛Doug Cutting的作品

[quote]jhorne：--引用-------------------------------------------------- <br/>123we: 可以使用buffer来解决socket_send的问题，不用阻塞，只是send的buffer写满后，再检查EPOLLOUT，然后继续写剩余的buffer <br/>-------------------------------------------------------- <br/>这话是什么意思呢？ 非阻塞socket 调用一次send 然后等待EPOLLOUT事件 <br/>等到了即是发送完毕了 是这样吗 <br/> <br/>[/quote] 对于LT，应该是调用send后，如果buffer已满（即此次send失败），这才等待EPOLLOUT事件。 否则，EPOLLOUT会一直就绪，那就会死循环了。 while(1) { epoll_wait(); // 空闲时，这个地方不会阻塞 if(EPOLLOUT) ... }

if($timestamp - $get['time'] > 3600) { exit('Authracation has expiried'); } 有这段代码啊，一个小时候以后就失效了。

@Jack Niu 严格意义上，这是个漏洞,只不过是一个事后漏洞, 1. ucenter本身的设计不合理，因为他没有提供鉴权api. 2. uchome对账户的鉴权机制不完备,只简单判断uid存在性. 所以,只要用户帐号被盗过之后,用户就算追溯回并修改密码，日后仍然可被侵入. 严格的鉴权一定要落到ucenter进行才有意义.单凭加密凭据是不够安全的. 本人曾从事过大规模SSO系统的设计，客观上来说，ucenter/uchome不是一个非常"可靠"的系统. ucenter不够"中心化".

不过，UC相对来说，还算是比较不错的系统了 --[url=http://jack-fx.com]Jack[/url]

@onlyxp 看这么多回复，你还认为是UC的漏洞？？？？ 按照你的说法，第二条如果成立算是UC的漏洞 但是你那个假设前提？？？ 搞笑！ 你这个标题误导人，建议改一下！

只能说dz的做法能满足大部分网站的应用. 如果说什么暴力破解,还是比较难的.

@cnblogs装B成风 上述分析都是根据实际代码分析和测试得来的结论。 勿须过于挑衅。如有疑问或困惑，请通过实践来验证。 或友善诚挚抛出问题来探讨。

@onlyxp 难道你的代码又让人给任意改了？如果代码可以改，那安全就没有任何意义了。

@感觉没了 uchome中也有个uc_member表.里面只是简单存放uid, username, password等信息. 实际上每次在uchome中登录时，都会去ucenter同步账户信息到uchome的member表中.(具体代码在source/do_login.php的synlogin方法中)

@canbeing 你只要看下ucenter里面的authcode方法, 就知道是怎么个encode原理了. 至于timeout, 这个值是可以任意设置的. 在uchome的api/uc.php中只简单判断 timestamp - $get('time') > 3600 即认为超时.

@kezonet 已经实践验证过了!

额，希望博主自己验证清楚。

把UC_KEY给别人，这是傻子干的。 而且登录的加密字符串是带时间的，默认超过60分钟，验证就不会成功。 请博主研究清楚，再发此类文章。

这不算是uc的安全漏洞。 你说的那个算是uchome的安全漏洞？不过我真没测试过。 据我所知，uchome没自己的用户库，完全用的是uc的用户表。 ucenter和uchome不是一个东西，你上边的概念貌似有所问题？ 如果要开始uc自定义的应用，只要自定义应用端再做一次安全验证 是不会出现你说的情况的，跟uc本身无关，uc只提供一个登录的接口 而是否要进行登录这个动作，完全是接收登录操作的相应应用决定的。 [quote]或者如果你知道了某个uchome应用的UC_KEY, 那么你就可以构造伪造请求来模拟任意用户登录了.[/quote] 这个没什么好说的，你这个如果.....让人觉得搞笑 人家本来就是开放接口的，知道了密钥当然可以随便操作了， 别说登录了，注册用户，删除用户都没问题。

想法是绝对正确的，我上周发现了我们网站的一个漏洞，也是cookie认证的。 只对ID进行验证，而没有进行密码认证，也没有密钥，就是一个MD5加密ID和域的认证，并且是一个固定cookie的key 这样，攻击者可以利用脚本漏洞，尝试常用的加密算法，根据其他用户的ID生成密码，重写cookie。达到登陆其他账户。。 我和程序员争有问题，他说他已经加密了。不会有问题，实际上呢，哈哈？

看标题来的，只想问问博主试过了吗？ uchome在执行每一个页面的时候，先decode cookie中保存的密码，然后检测uid和password来判断是否登录的吧。 所以，在api/uc.php中可以不检查密码，直接通过存为cookie。 当你进入uchome的时候，因为你的cookie里有登录信息，所以它会尝试登录，如果密码错误就会把这个信息从cookie中删除。 由于我也好久没碰uchome了，所以想问问试过了吗

@侯伯薇 是的，只是表象而已，炒下概念先。 真正的wave需要融入协作的机制，实现方面还需要很多的工作量。 后续有时间也打算基于其协议慢慢过渡。

使用google日历提醒那图标也贼大了

点击编辑信息就是空白页面

有一个开源的wave，python开发的 http://code.google.com/p/pygowave-server/

似乎和wave之间只是表面上有一点儿类似，功能上还是传统的公告板形式，呵呵。wave可不是个简单的东东…………

能分享一下开发过程吗？

wave还是好看些！

Sorry, we didn't find your requested resouce: http://xiaoyuan-huodong.appspot.com/admin/deleteactivity?activity_id=2038 on server. 呵呵，对于非管理员的请求，那个”删除“链接最好别显示出来，还有就是如1楼所说的，”挤“了点

MVC?

唯一的感觉 界面好拥挤

希望以后多多指教，向您学习！

受益匪浅！ 有两个问题： 1. Pig在哪些特定场景下性能较好？ 2. 在基于bookeeper进行NameNode HA时，是否已有成功案例证实可行？复杂性高在哪里？

如何能够一次登录就能无刷切换到LoggedInTemplate?你的下回分解还没有面世阿?

是的.至少在当前的版本中,如果某台机器磁盘满或者只读, 很可能一个task会多次分配到同一个tt, 而导致整个job失败. 在hadoop0.21版本中在JobTracker上对故障问题作了一些改进: 比如提供了一个health check 服务, 在tt上周期性调用一个由mapred.healthChecker.script.path属性指定的脚本来检测当前节点的状况是否正常,收集的信息会在下一个heartbeat中上报给jt, jt根据信息决定是否把此机器列入blacklist.这样,我们就可以在此自定义脚本中检测磁盘满,磁盘只读等问题.

@彭帅 谢谢你的回复 如果没理解错的话，一旦某一个tt出现rofs，并向jt请求task，那么整个job几乎会100%失败，因为失败的tt会不断重复向jt请求task，并且非常有可能是同一个task 还是说在tt或jt上有一种黑名单机制，对于已失败的task不会重复分配给同一个tt？

@zhwang task失效有网络层面，软件层面的，也有硬件层面的. 1. 网络层面,偶尔可能发生拥塞. 2. 应用层面，比如某个处理较慢(特殊的正则表达式, mapred任务中依赖的第三方服务缓慢)，导致10分钟都没有和jt心跳，任务就会超时失败. 3. 硬件层面. 比如磁盘满，磁盘只读，盘符丢失,都会导致任务失败. 对于网络异常，磁盘满，可能只是偶发现象。网络恢复，磁盘空间释放后再跑任务也就没有问题了。 对于磁盘坏的情况，任务失败就是必然的。 如果发生磁盘坏这种不可恢复性的错误，尽量要做到及时发现并屏蔽故障，并尽快更换设备。 当然，有个好的外围failover系统来实现一些机械式故障处理的自动化也是很有帮助的。

好的，支持一下帅哥！

你好，你提出的模型很值得参考，有这样几个问题 1. 实际运行中task失效是否大多数都是硬件失效？ 2. 硬件失效，尤其是磁盘失效，往往都是永久失效，会造成“坏节点”的情况，这个问题如何处理？ 3. 你在作业调度的那篇文章中提到过ROFS会造成整个Job阻死，这里提到一个JobTracker黑名单，没具体看这个机制，想请问一下这个黑名单的策略是什么？

收藏！

@yuanlin 我的理解：1.FairScheduler:每个用户拥有一个pool，向其中提交job，这些job公平地享受有pool的计算资源，pool可以设置priority，优先级越高，拥有的资源越多; 2.CapacityScheduler:多个用户把job提交到一个queue中，queue内按优先级和提交时间分配资源数量; 最终每个queue享有相同capacity的资源，进行过程中会随着reclaim resource而发生资源拥有量的变化。

@彭帅 @彭帅 你好，我想请教一下：作业的优先级怎么设定？该看哪部分的代码？谢谢了 谢谢~[quote]彭帅：如果是用默认的fifo queue, 那么直接调用JobConf.setPriority(..).来设置优先级.[/quote] 谢谢回复。 您在文中提到了四种调度器，包括hadoop默认的。这部分内容在网上资料比较少，我看了一下官网上的英文指南，还是搞不清楚这四种调度器，您认为它们各自有哪些优缺点，适用哪类任务呢 ？谢谢

如果是用默认的fifo queue, 那么直接调用JobConf.setPriority(..).来设置优先级.

@happyyuanlin 可以先设置fairscheduler. 然后定义pools.xml文件.在里面建立几个pool.通过weight参数来设置pool的优先级.

你好，我想请教一下：作业的优先级怎么设定？该看哪部分的代码？谢谢了

不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认（这句话不理解）。 ----------------- 这句话的意思是在TCP协议中，这个ET模式的运行效率还需要更多的测试~~

很久以前的文章了. 天涯狂人 说的没错. 对于EPOLLOUT事件的处理策略就是先尝试直接发送.如果发送不完整，就buffer住等下一轮再发.

不错的收集，很全面:)

期待...
:-)