@ 2015.11.03 , 20:30
84

乱动Linux内核代码会发生什么

[-]

Linus Torvalds是一名传奇性的软件工程师和Linux内核的创造者,他对烂代码也不能忍,所以,坐好,拿出爆米花,欣赏吧。

对于赫然出现在Linux 4.3版本中的一些新代码,Torvalds贴出了这条回应,帖子很技术化,但即使你看不懂其中的精妙,每个人都能欣赏那娴熟的吐槽:


天哪,这伙人,这就是一坨翔

我得到这个冲突是因为愚蠢的新gcc头文件垃圾,但让我烦躁的是这货的存在理由完全不成立。

这是net/ipv6/ip6_output.c里的旧代码:

mtu -= hlen + sizeof(struct frag_hdr);

而这是新的“改进”代码,使用了需要魔法般内置编译器支持的花哨货色,而且当支持不存在时还带有傻冒的包装器函数:

if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||

mtu <= 7)

goto fail_toobig;

任何人要是认为以上代码(a)易读 (b)高效(甚至在有魔法般编译器支持时) (c)尤其是安全的,都是无能的神经病。

以上代码就是一坨翔,而且它生成的代码也是翔一样的,它看上去就烂,没有任何理由存在。

该代码本可以用仅仅一个容易理解的条件来轻易实现,而且编译器实际上本可以生成更好的代码,而且这个代码会更好看、更容易理解,为什么不写成

if (mtu < hlen + sizeof(struct frag_hdr) + 8)

goto fail_toobig;

mtu -= hlen + sizeof(struct frag_hdr);

这个行数是一样的,不使用没人知道它们在干什么的疯狂的辅助函数,它实际上做什么也更加明显,我保证第二个更明显的版本更容易阅读和理解,有任何人真的想争辩这个吗?

真的,给我一个理由它为什么要用两个不同的条件写成这么白痴的方式,还有一个簇新的非标准函数,要求特定的编译器支持来生成半吊子代码?一个我们在其它任何地方从来不曾需要过的崭新函数,这简直就是编译器自慰。

对,如果整个“hlen + xyz”表达式溢出了,你还是会有溢出问题,但很坦率地说, “overflow_usub()”代码也一样,所以如果你操心这个,那么你一开始根本就没做对。

所以我真的看不出这种完全白痴的垃圾有任何理由。

告诉我为什么,因为我不带这种生成rc7时冲突的完全疯掉的东西,而且看来绝对没有理由有这种愚蠢的不可读的一团糟。

这个代码看来是被设计成来使用那坨新的“overflow_usub()”代码,看上去就是个使用这个函数的借口。

真是个[哔~]了狗的脑子坏掉的烂借口。

对不起,但是我们不为那样的白痴新代码增加这样的白痴新接口。

对,对,如果这货呆在网络层里,我本来从不会注意到它,但既然我已经注意到了,我真的不想要这货,事实上,我要让每一个人都清楚,这样的代码是完全不能接受的。任何人如果认为这样的代码因为使用了花哨的溢出检测函数,就是“安全”(原文为safe,不出错)和“安全”(原文为secure,不被黑)的,都是神志不清到根本就不搞笑的地步。所有这些垃圾所做的就是用神经正常的人永远不会真正理解它在干什么的代码把代码变成没法读的一团糟。

给我把它干掉,我再也不想再看到这坨翔。

Linus


教训就是:不要乱搞Linus的代码。

本文译自 Gizmodo,由译者 王丢兜 基于创作共用协议(BY-NC)发布。


给这篇稿打赏,让译者更有动力
支付宝打赏 [x]
您的大名: 打赏金额:

4.6
赞一个 (38)

TOTAL COMMENTS: 84+1

[2] 1 »
  1. 2977920

    楼底有我,加油小编。

  2. 苦瓜
    @2 years ago
    2976449

    我擦,他竟然才45岁

  3. 苦瓜
    @2 years ago
    2976443

    linus还没退休?

  4. 2976228

    麻烦编辑将23楼回复翻译成英文,看看能有别的效果吗

  5. 2976142

    @神之疯神: 这个倒真没必要喷…他说的是对的。
    goto不是完全不能用,但是问题是正确使用并不容易做到,很容易被滥用。可是硬是完全不用的话又确实有些特定的问题很难处理。怎么办呢?方法之一是针对那些“正确的使用goto”的场景单独设计一个新的机制/语法结构,让大家去用这个新的专用工具,不要直接用goto。
    这样出来的产物里,exception机制是最常见的一个。而从根源上来说,还真的就是goto的一种包装,相当于先弄出来个 :exception_handle ,这部分其实就是catch的部分;然后所有出问题的地方用goto :exception_handle,就等价于throw。

  6. 2976136

    @杨二姐: 好吧,记错>_<。 多谢指正。

  7. 神之疯神
    @2 years ago
    2976110

    @xiaohu: 按你这么说的话黑盒子也就是个录音机,被包装了一下而已

  8. 巨蜥拉卡
    @2 years ago
    2976102

    其实sein老大也挺难的,小编被大家吐槽了,他再不向着小编,碰到玻璃心的估计又得跑一个。招一群不明真相的读者容易,招一个愿意把爱好当工作来付出的小编很难——纵然很多蛋友也是翻译达人,作为纯爱好翻个一两篇还行,一直翻下去并不容易,甚至说很难做到。比如幻想了很多结果好几年只往煎蛋投过两三篇稿子的我,没错,我在装逼

    当然小编既然被喷了,喷得在理的部分也要虚心接受,很多人其实并不喜欢 @伟大的安妮 那一套(包括我),错了就是错了,努力改改看下次评价,然后继续改下去咯。

    既然选择做一个大厨为我们带来一些精神食粮,那么味道不好就是要改的啊,不能说因为你没有大厨的底子只是凭爱好努力学做饭就可以随便做出黑暗料理让我们强行吃下去是不是- –

  9. 杨二姐
    @2 years ago
    2976095

    @abc: “信、达、雅”是严复提出来的。 @王丢兜: 翻译是一种再创造,译文是给读者看的,读者们接受认可那么这个翻译才能算是完成了它的基本目的,传递信息。

  10. needupapoit
    @2 years ago
    2976092

    @ark12211: 冲突,是系统工程学界经常用的专业化术语,表示系统当中有些局部结构的运行动作,发生了影响整体功效的矛盾,造成互相干扰、阻滞、打压禁断等等不利于完成工作任务的不良结果,不能算是不接本地日常生活用语习惯的错词,全球各地的日常生活用语几乎都不涉足有关的意义空间。
    翻译成 冲突,是木有哪嘎瘩好置疑的,问题只在要不要加挂话外音辞典,或者让围观蛋友自己去查是神马玩惹,此无定论可依,吵吧您,卖瓜子起。

  11. 2976089

    @ggarlic: 不要看到人家不懂goto就喷啦~ 这种知识对于年轻的程序员几乎就没有地方获得,因为看起来就是所有人都喷goto,而没有几个人知道goto应该怎么用。

  12. 2976056

    《自high吐槽系列》……

  13. 2976032

    @abc: 我往这个方向尝试一段时间,非常感谢指点。

  14. yellow
    @2 years ago
    2976013

    @额呵呵: 煎饼销量好吗?

  15. 2975968

    @王丢兜: 侯捷先生曾经对翻译相关技能的重要性有个排序,个人认为非常到位的:
    最重要的是中文表达能力。
    其次是对原文所表达内容相关领域的了解。
    最后才是英文水平。
    翻译一事,另有胡适的“信、达、雅”之说,“雅”之一字无需多言,指的是表达方式。而“信、达”二字,是需要有个基础的——“信”于什么,表达出什么才算“达”?文字本身只是一种工具,是作者用来向读者传递信息、表达思想的工具。翻译,实际上是译者用另外一种语言工具来重新实现这个目标。所以文字本身并不重要,文字背后的内容才是核心。拘泥于英文本身的字面、语感之类的东西,是很难有好的翻译结果的。

  16. 百得
    @2 years ago
    2975945

    简洁的代码是很值得的,应该推崇。约束和检查不应该泛滥。例外处理最好能纳入常规处理。

  17. rosses
    @2 years ago
    2975939

    @冯·卡布伦: 就是出自那一次。处于对N卡公司在linux双显切换驱动的爱理不理以及及其官僚的办事作风。叼了一顿之后好了一点,可以支持手动切换的,但还是无法自动切换。用双显本本的linux用户还是要再等等。

  18. 2975931

    @王丢兜: “连合同工都是”:应更正为“连合同工都不是”

  19. 2975928

    @Simla: @abc: @abc: @abc: 你们说的很对,特别感谢在这种时候还认真写了那么多,每一条都说得很在理,非常感谢。

    前面说过的话不重复了,长期以来我一直理解是读者在上,我在下,这里也不是我讨论自己想法的地方(毕竟我只是一个作者,连合同工都是,其实不应该就翻译问题在这里发表言论),这段时间讨论升温其实我是忘了这个前提,以对待peer的对等姿态开始来回互动,我错了,对不起。

    我的翻译能力的确非常差,学生时代初学英语就是在纯英文环境,从来没有中英对照地学过英语,第一本字典就是《朗文英英》,没拥有过英汉字典。所以对我来说,英语是第二母语,翻译还真有点像外国人学中文的感觉,这就会造成问题。而我主观上也想尽量把英语里的各种修辞和幽默感翻译过来,结果不令读者满意,我也非常沮丧。加深我情绪的,还有另一点,因为我经常还推荐文章稿源给其他作者翻译,我也读他们的成果,每次我都感觉,怎么这个词漏了,那个表达方式变了,原文的各种棱角怎么都磨平不见了,因此我自己翻译的时候,会更加注意贴近原文的语感,结果还是不好。

    所以,前几天我已经决定放弃坚持己见,并且尝试改变风格,不再努力贴近原文的语气,结果评论的反馈有所改善,对此我不知该是喜是悲。but again,煎蛋 is too important for me to tinker with,我个人的任何追求都本不应该对煎蛋造成这么大的影响,非常抱歉,对不起。

    最后再一次地,非常感谢各位的意见,over and out.

  20. xiaohu
    @2 years ago
    2975925

    @ACDC: 你看c#就有goto,说真的,goto不难用,没goto少了很多创造力

  21. xiaohu
    @2 years ago
    2975916

    @Air: 说白了 try catch就是一种goto,只是被包装了一下而已

  22. moonsun
    @2 years ago
    2975909

    以上是玩笑….

    认真来说,我工作10多年,看过的烂代码实在太多了.多到我都懒得去叫别人修改了.主帖里面大神说的事情其实是写程序的人知识面太窄,很多东西不知道怎么实现.于是就用变通的方法去实现,然后嘛,这个重新发明的轮子还是方的不好用.于是就被喷了.这样的事情其实是种懒惰的表现.很多程序员写东西的时候都懒得把帮助和函数示例看全了.很多明显有用最基本函数可以简单实现的东西,非要自己写个漏洞百出的复杂容错函数来解决.

  23. moonsun
    @2 years ago
    2975907

    每一个程序员在他的职业生涯中某一天都会突然获得开示,这种开示在通常某一个夜晚悄然降临,有时是以图灵本人托梦的形式出现。这一开示的主要内容如下:程序员是真正理解思维和逻辑真谛的人。非程序员是被蒙蔽的无知者。每一个程序员对于世界上其他程序员有着不可推卸的责任。每一个程序员都必须尽力维护程序员这一高贵种族的延续,并保证世界的命运控制在程序员手中,既不被无知者淹没,也不被机器智能取代。完成这一使命的唯一方式,是保证稳定地出产低质量,难以理解,修改和维护的代码。每一个负责任的程序员,他每一年的产出,必须为另外三个程序员制造一年的就业机会。唯此,程序员一族可生生不息,整个IT行业欣欣向荣。图灵大神在冥冥中微笑,他的纸带机将嗒嗒作响,直至永恒。

  24. 冯·卡布伦
    @2 years ago
    2975905

    这张题图可能出自Linus痛骂Nvidia那次。不太确定,因为他骂人的时候实在是太多了。

  25. 2975896

    @ark12211: 这句我当时也斟酌了好一会,现在你这么问,也许翻译成“我这里编译结果里跳出这个冲突,是因为……”会更加明确一些。当时还是想贴近原文的口气,的确结果在中文角度上不好看。

  26. diberium
    @2 years ago
    2975844

    直到有一天你们想吐槽翻译也没人翻译了……

  27. 幫肆
    @2 years ago
    2975832

    果然我就知道,这种文章会引起大乱

  28. ark12211
    @2 years ago
    2975827

    呃,如果认为翻译没问题的话能给我解释一下“我得到这个冲突是因为……”是天朝大地上的语言吗

  29. Lalalol6
    @2 years ago
    2975817

    读文知小编

  30. 2975809

    @王丢兜:
    其实类似的事情在煎蛋已经发生过好几次了,印象深刻的一次闹得比较大的是oioi的诺基亚手机文章,在翻译质量上则是@寿司猫 有过和@王丢兜 非常类似的局面。此类事件大致上的发展进程如下:
    1 小编弄出了点问题(内容弄错了、翻译不好等)
    2 读者批评(可能诚恳可能尖刻,但绝不是无中生有)
    3 小编方面给出了不太合理的应对,共同特点是“事实上不愿意承认问题”(“这个不重要啦”,“小编也是兼职要求那么高干什么 ”,”煎蛋是免费的,不满意你别看啊”,”小编已经很辛苦了”,“我翻译的时候是这么这么个思路”……)
    4 读者怒了,矛盾激化,问题升级。
    问题就在第3部分里。所有这些回应都是顾左右而言他,没有触及问题本身。纵有千般理由万般无奈,翻译质量不好就是不好,内容弄错了就是弄错了。读者提出来这个问题,无非就是提醒一下小编,希望改进。
    本来并不复杂的事情。内容错了那就核实下,如果确实错了就改掉文章;翻译不好那就努力提高,读者如果给出了更好的翻译也不妨采纳。这些事情都做好,再来谈思路说想法——谈思路说想法的目的应当是通过这种深层次的剖析交流来提高,而不是拿这些做为论据希望论证“我没错”。
    可是每次闹出问题来的时候,都是小编放着问题本身不去解决(提醒了哪里有错不改,给出了更好的翻译不用),反而有大把时间精力来和读者打口水仗,各种理由各种说明各种辩论……
    这样你说你态度没问题是我们鸡蛋里挑骨头,说的过去么?

    [12] XX [0] 回复 [0]
  31. 2975808

    @王丢兜: 简单的说,你“自认为自己很诚恳”就认为“客观上自己真的很诚恳”,从而觉得别人对你的负面意见是有问题的。<- 这就是你的态度问题所在。
    你做事的主观意愿是否是好的(是不是认真翻译了、是不是诚恳接受意见),并不能直接决定客观结果是否是好的(是不是真的翻译得很,是不是真的正确接收意见)。好心办坏事、能力不足没办法弄好、个人有偏见(以上各种解释是从好到坏的揣测)都可能导致结果很不好。

    你的翻译质量不高,既然有这么多人都有这个感觉(ps.我也这么觉的),那么这个事情本身争辩的意义就很小。好的态度应该是关注这个结果,努力去解决,去提高(以大众的眼光和评判标准来看的)翻译质量。而不是去聚焦于过程,反复说一些“你说得对,但我要说一下我为什么要这么翻”这样的话。你自认为这种解释是很诚恳的,但是客观上,这就是一种抵赖——“你有不同意见?我是对的,是你们不懂欣赏”。

    [10] XX [0] 回复 [0]
  32. 2975774

    @: 献丑:

    这是 net/ipv6/ip6_output.c 中的老代码:

    mtu -= hlen + sizeof(struct frag_hdr);

    下面呢,是“改进过的”新代码, 用了些要求编译器有神奇的内置支持的时髦玩意,为了处理编译器不支持的情况,还弄了个傻到家的包装函数:

    if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||

    mtu <= 7)

    goto fail_toobig;

  33. 2975773

    @ggarlic: Java学习者表示很惶恐,goto只见过,从来没用过

  34. ekansrm
    @2 years ago
    2975764

    最近一些事的处理方式, 例如d.i.a.n c.h.i事件, 段子区洗版, sein的个人言论, 等等让我对@sein: 越来越反感了

[2] 1 »

发表评论


24H最赞