我看那个fellow气坏了。我捋了一下时间线 2020/12/20 -- UMN教授发声明clarify他的‘hypocrite commit“ work 2021/04初 -- UMN教授的新学生Aditya又提交nonsensical code 2021/04/20 -- Linux foundation分析这些代码后得出以下结论 If you look at the code, this is impossible to have happen. Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way. This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university... ------------------------- ”> They introduce kernel bugs on purpose. Yesterday, I took a look on 4> accepted patches from Aditya and 3 of them added various severity security> "holes". 2020/04/21 -- Aditya 指控Linux Foundation诽谤他，基本意思就是您们组织什么烂态度，恶心，以后再也不提交patches了 2020/04/21 -- Greg决定ban 来自 @UMN后缀的code 以下是Grey对于Aditya的回复 On Wed, Apr 21, 2021 at 02:56:27AM -0500, Aditya Pakki wrote: > Greg, > > I respectfully ask you to cease and desist from making wild accusations > that are bordering on slander. > > These patches were sent as part of a new static analyzer that I wrote and > it''s sensitivity is obviously not great. I sent patches on the hopes to get > feedback. We are not experts in the linux kernel and repeatedly making > these statements is disgusting to hear. > > Obviously, it is a wrong step but your preconceived biases are so strong > that you make allegations without merit nor give us any benefit of doubt. > > I will not be sending any more patches due to the attitude that is not only > unwelcome but also intimidating to newbies and non experts. You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? When submitting patches created by a tool, everyone who does so submits them with wording like "found by tool XXX, we are not sure if this is correct or not, please advise." which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect. A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid "fix" is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create. Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way. Our community does not appreciate being experimented on, and being "tested" by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems. *plonk* greg k-h
我看那个fellow气坏了。我捋了一下时间线 2020/12/20 -- UMN教授发声明clarify他的‘hypocrite commit“ work 2021/04初 -- UMN教授的新学生Aditya又提交nonsensical code 2021/04/20 -- Linux foundation分析这些代码后得出以下结论 If you look at the code, this is impossible to have happen. Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way. This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university... ------------------------- ”> They introduce kernel bugs on purpose. Yesterday, I took a look on 4> accepted patches from Aditya and 3 of them added various severity security> "holes". 2020/04/21 -- Aditya 指控Linux Foundation诽谤他，基本意思就是您们组织什么烂态度，恶心，以后再也不提交patches了 2020/04/21 -- Greg决定ban 来自 @UMN后缀的code 以下是Grey对于Aditya的回复 On Wed, Apr 21, 2021 at 02:56:27AM -0500, Aditya Pakki wrote: > Greg, > > I respectfully ask you to cease and desist from making wild accusations > that are bordering on slander. > > These patches were sent as part of a new static analyzer that I wrote and > it''s sensitivity is obviously not great. I sent patches on the hopes to get > feedback. We are not experts in the linux kernel and repeatedly making > these statements is disgusting to hear. > > Obviously, it is a wrong step but your preconceived biases are so strong > that you make allegations without merit nor give us any benefit of doubt. > > I will not be sending any more patches due to the attitude that is not only > unwelcome but also intimidating to newbies and non experts. You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? When submitting patches created by a tool, everyone who does so submits them with wording like "found by tool XXX, we are not sure if this is correct or not, please advise." which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect. A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid "fix" is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create. Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way. Our community does not appreciate being experimented on, and being "tested" by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems. *plonk* greg k-h urthur 发表于 2021-04-21 20:26
我感觉linux foundation一开始就是一群比较理想主义的技术nerds在一起做的项目，算是CS界的一种慈善吧。所以管理上相对简单，毕竟没那么多花花肠子，平常都靠大家自觉。但现在参与的人多了，也杂了，不知道他们会不会做些改变应对。Really takes a crook to find all the loopholes in the system lol
我感觉linux foundation一开始就是一群比较理想主义的技术nerds在一起做的项目，算是CS界的一种慈善吧。所以管理上相对简单，毕竟没那么多花花肠子，平常都靠大家自觉。但现在参与的人多了，也杂了，不知道他们会不会做些改变应对。Really takes a crook to find all the loopholes in the system lol urthur 发表于 2021-04-21 20:41
比如就这样随手删一段，也不写注释 diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 807bc9465add..542f2428014c 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -869,11 +869,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev, info_size = sizeof(info); if (copy_from_user(&info, useraddr, info_size)) return -EFAULT; - /* Since malicious users may modify the original data, - * we need to check whether FLOW_RSS is still requested. - */ - if (!(info.flow_type & FLOW_RSS)) - return -EINVAL; } if (info.cmd == ETHTOOL_GRXCLSRLALL) { --
比如就这样随手删一段，也不写注释 diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 807bc9465add..542f2428014c 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -869,11 +869,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev, info_size = sizeof(info); if (copy_from_user(&info, useraddr, info_size)) return -EFAULT; - /* Since malicious users may modify the original data, - * we need to check whether FLOW_RSS is still requested. - */ - if (!(info.flow_type & FLOW_RSS)) - return -EINVAL; } if (info.cmd == ETHTOOL_GRXCLSRLALL) { --
比如就这样随手删一段，也不写注释 diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 807bc9465add..542f2428014c 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -869,11 +869,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev, info_size = sizeof(info); if (copy_from_user(&info, useraddr, info_size)) return -EFAULT; - /* Since malicious users may modify the original data, - * we need to check whether FLOW_RSS is still requested. - */ - if (!(info.flow_type & FLOW_RSS)) - return -EINVAL; } if (info.cmd == ETHTOOL_GRXCLSRLALL) { --
UMN的回应 Statement from CS&E on Linux Kernel research - April 21, 2021 Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical. Sincerely, Mats Heimdahl, Department Head Loren Terveen, Associate Department Head 主楼第三个链接里的讨论解释的比较清楚。这个研究项目并没有事先跟IRB提交申请，事后没有如实跟IRB解释他们研究项目的内容，更没有拿到linux dev的consent，没有披露risk。确实是bad faith。如果他们多点尊敬和诚意，也许他们的研究可以获得别人的合作和认可
UMN的回应 Statement from CS&E on Linux Kernel research - April 21, 2021 Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical. Sincerely, Mats Heimdahl, Department Head Loren Terveen, Associate Department Head 主楼第三个链接里的讨论解释的比较清楚。这个研究项目并没有事先跟IPB提交申请，事后没有如实跟IPB解释他们研究项目的内容，更没有拿到linux dev的consent，没有披露risk。确实是bad faith。如果他们多点尊敬和诚意，也许他们的研究可以获得别人的合作和认可 urthur 发表于 2021-04-21 23:48
你这是胡说八道了。都要看有没有IRB approved或者作者要在paper里写IRB Approved的。 可悲的是reviewer都没有熟悉Linux的。要不然肯定知道这research不会被Linux同意。industrial reviewer都是摆设吗。 miaka 发表于 2021-04-22 00:05
这是教授自己说的 Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned—Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form. We would like to thank the people who suggested us to talk to IRB after seeing the paper abstract. 我的解读是第一次他们就没有事先获得approval。 4月份这次导火索，他们应该同样没有走正常渠道，否则linux kernel maintainer不会那么生气，认为这个教授的实验室在恶意sabotage
这是教授自己说的 Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned—Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form. We would like to thank the people who suggested us to talk to IRB after seeing the paper abstract. 我的解读是第一次他们就没有事先获得approval。 4月份这次导火索，他们应该同样没有走正常渠道，否则linux kernel maintainer不会那么生气，认为这个教授的实验室在恶意sabotage
我看那个fellow气坏了。我捋了一下时间线
2020/12/20 -- UMN教授发声明clarify他的‘hypocrite commit“ work 2021/04初 -- UMN教授的新学生Aditya又提交nonsensical code 2021/04/20 -- Linux foundation分析这些代码后得出以下结论
If you look at the code, this is impossible to have happen.
Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way.
This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university...
-------------------------
”> They introduce kernel bugs on purpose. Yesterday, I took a look on 4 > accepted patches from Aditya and 3 of them added various severity security > "holes".
2020/04/21 -- Aditya 指控Linux Foundation诽谤他，基本意思就是您们组织什么烂态度，恶心，以后再也不提交patches了 2020/04/21 -- Greg决定ban 来自 @UMN后缀的code
以下是Grey对于Aditya的回复
On Wed, Apr 21, 2021 at 02:56:27AM -0500, Aditya Pakki wrote: > Greg, > > I respectfully ask you to cease and desist from making wild accusations > that are bordering on slander. > > These patches were sent as part of a new static analyzer that I wrote and > it''s sensitivity is obviously not great. I sent patches on the hopes to get > feedback. We are not experts in the linux kernel and repeatedly making > these statements is disgusting to hear. > > Obviously, it is a wrong step but your preconceived biases are so strong > that you make allegations without merit nor give us any benefit of doubt. > > I will not be sending any more patches due to the attitude that is not only > unwelcome but also intimidating to newbies and non experts.
You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work.
Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing?
They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches?
When submitting patches created by a tool, everyone who does so submits them with wording like "found by tool XXX, we are not sure if this is correct or not, please advise." which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect.
A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid "fix" is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create.
Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way.
Our community does not appreciate being experimented on, and being "tested" by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.
Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems.
*plonk*
greg k-h
要点脸行吗？这是在评选骗子第一名吗？别人吃屎你也吃？什么逻辑？
是的，我刚刚去看了一下code，差点吐血了，早知道就吃了晚饭再看，还有东西可吐。
这么烂吗？那我吃完晚饭再看吧
我感觉linux foundation一开始就是一群比较理想主义的技术nerds在一起做的项目，算是CS界的一种慈善吧。所以管理上相对简单，毕竟没那么多花花肠子，平常都靠大家自觉。但现在参与的人多了，也杂了，不知道他们会不会做些改变应对。Really takes a crook to find all the loopholes in the system lol
这个Ap是不害死国人不罢休的感觉。
确实不是评选骗子第一名。碰到pwwq同学这种喜欢张嘴就骂两句中国的人，楼上的反驳的确不应该从这个角度入手。
应该把他的贴子顶起来，这样众位喜欢骂中国的人可以互相鼓励，大家一起骂，使劲的一起认定中国吃屎，而自己不吃，那才显得自个儿高明嘛，您说是不是？
中国人弄虚作假方面确实道德水准低于平均水平，这是事实。不能说所有中国人都弄虚作假，但中国人里比例就是比别国高这也是事实。当然了，你不会承认这是事实。
哈哈哈， 啥意思？ 太烂了？
比例是不是比别人高，我没统计过，您也没拿谁的数据出来说事。您一个猜想，我也拿不准您猜对没有，更没啥承认不承认的。
至于这贴子里那几位骂中国的，人家也没用您这种方式（讲讲比例问题）说话，而且我也没说他们不能骂嘛。我只是指出他们在骂，那么想和他们一起骂的可以一起骂，想骂他们的可以骂他们，我看热闹（相看热闹的也可以和我一起看），不行么？
code review是怕你万一自己没有意识到自己的code有bug。 一般开源项目负责finalize master branch的人只有一个，个个都这么瞎搞是要折腾死leader的。这是一个trust base的系统，很多参与项目时间够久的dev甚至可以直接提交code。
那简直是肯定的，老婆孩子一起上阵要钱，一次次提高额度，微信群里一个个逼问捐款，然后回国高光
我骂得的是那些为了赚钱毫无底线的中国人， 假奶粉， 假药 假酒， 假疫苗， 赶着新冠肺炎 做生理盐水假疫苗，
每当这个时候总有若干ID跑出来， 给我扣上毒云轮的帽子， 或者某个掰扯精也跑出来， 揪着我抨击， 说我攻击所有中国人，
嗯， 问题来了， 我骂得是这些为了钱毫无底线， 干缺德事情的垃圾，
你们这几个ID 为什么这么激动呢？
我百思不得其解啊！
值得深思
没有正面作用，因为他们主要目的是为了灌paper, 而不是改进linux kernel, 或者linux 管理。
他们组，甚至学校半年前已经被linux foundation告知不欢迎这种行为，结果继续上传有漏洞的代码，还辱骂linux foundation态度恶劣， 所以linux foundation 这次炸了。
改基因造病毒搞网络防火墙 以上这些美国没有？
这些人就是那位判不是你撞的你为什么要扶老人的法官，从根本上颠覆一个社区的ethics，至恶
真来捐款也会有人捐的，楼里几个挺他的应该会捐吧。这些被抓的不道德教授太多了，没几天就出来一个，他们捐得估计心里也挺烦的。
哈哈哈哈，
一点也不奇怪，
如果真的这么做了
我觉得没啥正面意义，他们之前已经发表过paper了，就算是有那么一点微小的意义也已经足够了，但是他们还不收手，还在继续提交这种恶意测试，浪费这世界上好多真正聪明的人的时间。
您说的是中国社会，我说您说中国，这没歪曲您的话吧？至于“说我攻击所有中国人”，那就是您自个儿瞎编出来的了，别扣我头上哦。。。
你嘴一张就是事实了，平均水平怎么定量的，什么叫高，什么叫低，
用什么依据来计算平均水平？ 比如为了防止病毒传播，即使自己年轻力壮, 不怕感染，也愿意带口罩，愿意牺牲一点个人自由的的平均人数么？
还是随时随地可以 理直气壮0元购的人数比例，而且主流媒体还为其撑腰的现象的频繁程度？
你的根据呢，数据呢？ 还事实，本来就是你的臆造，还好意思要别人承认
我是泛指若干个ID， 我并没有说 VMC 说的，我攻击所有中国人吧？ 所以我并没有遍什么， 你会掰扯， 我也会，
我说的中国社会里这种毫无底线 为了钱，傻缺德事情都干的那种垃圾人口，
我下次一定会准确说明，
你要是觉得我在攻击你的话，
哈哈哈，
我向你道歉哦，
不要代入感这么强，
除非你是？
比如就这样随手删一段，也不写注释
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 807bc9465add..542f2428014c 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -869,11 +869,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev, info_size = sizeof(info); if (copy_from_user(&info, useraddr, info_size)) return -EFAULT; - /* Since malicious users may modify the original data, - * we need to check whether FLOW_RSS is still requested. - */ - if (!(info.flow_type & FLOW_RSS)) - return -EINVAL; } if (info.cmd == ETHTOOL_GRXCLSRLALL) { --
我不是coding背景
不太懂，
这得你们专业人来评论
呵呵
你是说他 comment out 不加注释？
那位法官应该是个转折点，但在此之前国内已经有一定的风气了(基础)。我小时候就听家里老人讲扶人反被讹的事例，只不过社交媒体不发达，没大范围传开而已。
所以类似于这位教授的行为应该被谴责，一旦大家习以为常就很难扭转了
对啊，把code里原本有的删了，搞不好是前面的人刚fix的bug呢
南京 法官
那件事情？
几个pinkie真是不要脸啊，最近20年中国大陆食品安全问题还少了？这还不算无数毒疫苗，假疫苗，豆腐渣工程。。。。。
https://zh.wikipedia.org/wiki/中国大陆食品安全事件列表
如果人家不是台湾人你全家死光？
粉毛看到觉得厌恶共产党的id，就立刻歇斯底里说别人是台湾人，
粉毛纯属自欺欺人，就是不敢肯承认你的共产党老鼠过街人人喊打的事实
Stupid！
跟什么人用有什么关系？做坏事就是做坏事！
是那个ap和他的学生，还写了一片paper。what an a*hole
不论是不是，你全家先死光光吧，你这么喜欢你全家死。
他这么干，让我想起以前一个记者要揭医院黑幕，用茶水当尿送检。结果当然是一堆不合格要进一步检查。然后他就说这个太黑了连不是尿样都看不出来。。。
基本信任都没有故意Abuse 系统的人，真的无底线。
linux内核连本地改动一下都需要数字签名。
你跟我说这么一套套的review commiter机制是“基于信任的潜规则”？你这是开的什么国际玩笑？
这个事情的本质很简单。
教授和他发表的安全顶会，打了linux 评审机制的脸
linux的反击方式是开脱自己的体制问题(我们就没想过应对恶意push），一边先下手上纲上线。用手头那点权利先把事情闹大。事情一闹大，现有体制总是占上风的那边，因为谁也不像得罪当权派。
linux那边的行为恰恰证明了他们这套机制更大的问题，就是掌权的小圈子关心自己的主导权，远远超过他们对代码质量和社区利益的关心
你真是不要脸
你真是个自恨狂
这种事情如果是以色列人干的，不知有多少大妈会满眼星星，，看人家犹太人就是有创造力
以色列的几个安全公司常年往linux kernel里放0day bug，这都是半公开的事情了。
人家不止水了一篇文章。而且都是超级top的文章。很多人一辈子都发表不了一篇的。想想真是可悲，top会议review的时候就没人质疑ethical issue吗？不这样玩就发不了top会。这次要不是惹恼了redhat，这lab还不知道要继续多久。撑死胆大的，哪行都一样。我就想知道那些top会什么时候withdraw他们的paper。
醒醒吧。你是以色列人吗？不是就老老实实做人做学问。
Statement from CS&E on Linux Kernel research - April 21, 2021 Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.
We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical.
Sincerely, Mats Heimdahl, Department Head Loren Terveen, Associate Department Head
主楼第三个链接里的讨论解释的比较清楚。这个研究项目并没有事先跟IRB提交申请，事后没有如实跟IRB解释他们研究项目的内容，更没有拿到linux dev的consent，没有披露risk。确实是bad faith。如果他们多点尊敬和诚意，也许他们的研究可以获得别人的合作和认可
我就想问以Linux作为研究对象要不要Linux知情同意。
IPB是什么鬼。
typo, IRB
楼主大妈屁都不懂，上来就带节奏。
这个研究能绿灯，能发表，本质上代表会议committee和UMN committee认为这是一个技术问题，可以用技术的方式解决
linux fiundation 疯狂造势给自己甩锅。说不是一个技术问题，而是一个政治问题，伦理问题。合着他们只有权力没有义务。foundation那么多经费养着这些committee成员，不是让他们建设架构，而是让他们居高临下给大家诛心来着
华人大妈一看，什么？伦理问题？这个我懂。“中国人就是贱！”
绝大部分做eecs相关的都的用吧。和族裔有毛关系。
研究的不是linux委员会的人，而是linux内核的review机制。所以UMN的伦理委员会认为不属于human research。
稍微google一下，你这些问题都有答案。
跟华人大妈没关系。。。基本上一面倒说这个教授unethical，就算研究方向有点意思。。。 如果像你这么信誓旦旦，这事就闹不起来。
总之和“主流”、“正统” （redhat/open source community)算结了大梁子了。你也别给你好朋友洗地了。没得洗。让他赶紧和学校legal office赶紧想办法认错吧。
显然UMN 判断错了。
我觉得技术学刊审稿的时候不见得认为有ethical issue, 首先paper可能不会讲到这些细节，其次审稿人会认为对方已经走过officlal 流程，取得permission/consent
他要如实汇报，apply IRB怎么可能IRB会判错？竟然怪IRB office的大妈不认真工作？你以为IRB office是好糊弄的吗？当然那些大妈不懂他要干什么，只能听他忽悠。
师夷长技以制夷
前面應該加個
偷
偷师夷长技以制夷
你这是胡说八道了。都要看有没有IRB approved或者作者要在paper里写IRB Approved的。 可悲的是reviewer都没有熟悉Linux的。要不然肯定知道这research不会被Linux同意。industrial reviewer都是摆设吗。
这是教授自己说的
Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned—Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form. We would like to thank the people who suggested us to talk to IRB after seeing the paper abstract.
我的解读是第一次他们就没有事先获得approval。 4月份这次导火索，他们应该同样没有走正常渠道，否则linux kernel maintainer不会那么生气，认为这个教授的实验室在恶意sabotage
所以IRB office不背锅。这是最新消息吗？之前为什么说他apply了IRB？ 难道是想坑学校IRB大妈？
AP 應該是拿不到 tenure 了
真要有人告上
校方賠不起
出自这个教授自己的申辩（2020/12底），第二页 ''is this human research‘。
https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf
很多人认为这种研究明显有ethical violation，教授承认事先没有联络IRB，而既然事后能获得IRB的approval，应该是教授没有跟IRB 如实告知研究范围和内容。 教授则认为得到了IRB的免死金牌，理直气壮继续他的研究，结果被linux foundation黑名单了
其實
刁 稱帝 也是 台灣人出的主意
“不要你以为要我以为”晓明哥的至理名言送给他们
原來搞搞軟體也能捅這麼大的樓子啊
政治化了 就沒有對錯了 那 美國大學為了避免將來
出了錯 還被政治會 會不會把 錯誤掐死在源頭 比如說 從此不雇用 Q X 發音的AP
畢竟
正體漢字造晶片 簡體漢字塞bug
这什么情况？这属实吗？没有经过IRB批准根本不能开始research。如果开始了也不能发表。我还第一次听说这种也能补票的。
戰狼科研
永遠沒有錯
对啊 没有IRB批准是不可能开始研究的，批准了都会从IRB那里得到一个号码。
这个分析主要是网络一些academia 的人根据教授的免责声明做出的推测。
最后还是要看umn 的"官方" 调查结果吧。目前该实验已经被叫停了
你孤陋寡闻了吧。他们team说不定都被FBI盯上了。
所以我總覺得
幹啥 系主任 院長 的
總得替別人背鍋洗鍋 挺辛苦的
你想多了，不是所有系主任/院长都舍己为人的。
记住了，
都是跟台湾人学的！
都是跟台湾人学的！
都是跟台湾人学的！
默读三遍，
一切洗白！
好好的反歧视就是被你们
怎麼不學學做
晶片 啊
这真是他们上传的patch？
UMN IRB先是给了豁免，也就是根本不认为这项研究需要审查。然后在研究团队主动要求之后，还是提供了批准。
反倒linux foundation的那个greg，看起来压根就不知道和他对骂的这个阿三学生不是论文成员，也没有参加论文研究项目。greg因为论文发表以后被公开打脸的恼火，一股脑把UMN邮箱之前提供的200多个patch全部都revert了。而这200多个patch，1大部分不是这个团队提交的，2没有一个是这项研究的产物。
至于大家讨论焦点的这篇论文，里面提到的三个提交，都是用随机的gmail邮箱，通过了评审以后有主动撤回的。并没有进到Linux内核里头去。如果他们真的有任何恶意，以他们的技术水平可以干出很多事情。根本就不可能被这个笑话一般的oss流程发现
你觉得谁一边倒？从各种事实来看，UMN大学， Lu 团队和IEEE S&P会议，拥有压倒性的有力证据。linux foundation的行为除了恼羞成怒，没有别的解释。
之前IRB直接给了豁免，认为这根本不涉及human research.
也就是說 UMN 提供的兩百多個 patch 存在 不是這個研究的產物 但是由這個團隊提交的 patch
以這個團隊的能力是可以造成更大的傷害
那麼 更大的傷害 會不會就在 這些 patch 之中呢
是該封
太危險了