">作者：Linus (翻译：Roman[AKA]) HuIfbaiducukNY6来自：AKA
HuIfbaiducukNY6
HuIfbaiducukNY6译者序：关于LINUX内核
开发
我觉得这些观点都是正确
观点都表达了不同使用者喜好
这些喜好都是需求对于不同使用者他们会更具自己喜好去使用不同环境这些都体现了LINUX灵活性和可开发改造性这些特点是别系统所没有这就是我喜欢LINUX
个原因 HuIfbaiducukNY6
HuIfbaiducukNY6关于不同
开发环境个人有自己喜爱和偏好而各种环境都有自己特点我想这样争论应该保持下去这样争论会促进LINUX发展能开发出各种各样优秀工具而这些工具生存不在于两个人而是广大LINUX 用户去决定 HuIfbaiducukNY6
HuIfbaiducukNY6我想不同
观点将出现不同风格但是我不想LINUX各种版本变非常大而且他们相互都不互相融合我认为Linus观点是完全正确保证LINUX内核统性和完整性这样就保证了各种不同版本LINUX起发展 HuIfbaiducukNY6
HuIfbaiducukNY6***************************************************************************
HuIfbaiducukNY6
HuIfbaiducukNY6我不喜欢调试器
从来不大概永远不会喜欢我只使用GDB而且我总是并不把它作为调试器来使用只是将其作为个可以用来分析
分解器来使用 HuIfbaiducukNY6
HuIfbaiducukNY6任何关于内核调试器
意见、争论都没有触动我哪怕是丝毫相信我这么多年来我收到很多这方面建议到最后他们都只能归结为很基础（东西）：—— 开发应该变得更容易我们能够更快加入许多新东西 HuIfbaiducukNY6
HuIfbaiducukNY6坦白地说
我并不在意（这个问题）我认为对内核开发不会是很容易事我不赞成那种通过个个代码逐步去寻找
做法我认为系统额外可见度并不是件必要好事 HuIfbaiducukNY6
HuIfbaiducukNY6很明显
如果你在没有使用个内核调试器情况下就附和这种观点： HuIfbaiducukNY6
HuIfbaiducukNY6—— 你会遇到
系列问题：旦出错系统就会崩溃你会失败； HuIfbaiducukNY6
HuIfbaiducukNY6—— Linux 内核编程太难太费时
人们会对其失去信心； HuIfbaiducukNY6
HuIfbaiducukNY6—— 创出新
特色需要段很长时间 HuIfbaiducukNY6
HuIfbaiducukNY6没有
个人能向我解释这些问题对我来说这不是个问题这是它特点这不仅是已经有证明文件证明而且这是好事因此很明显这不是个问题 HuIfbaiducukNY6
HuIfbaiducukNY6“创出新
特色需要段很长时间”——这点在调试器方面尤为不是个强有力论据对Linux来说缺少特色或新代码不是个问题事实上这对整个软件产业来说都是如此相反我主要工作就是对那些新特色/特征说“不”而不是去寻找它们 HuIfbaiducukNY6
HuIfbaiducukNY6
确当（系统）崩溃你甚至不能获得丝线索只有失败那么只能得到两种结果：你要么小心翼翼重新开始；要么开始对内核调试器不断抱怨 HuIfbaiducukNY6
HuIfbaiducukNY6坦白
说如果（工程进程中）出现粗心大意情况我宁愿摈弃那些在开始时就没有小心谨慎人这听上去很无情就算是上帝听上去也会感觉无情但这并不是人们所认为那种“如果你不能承受压力那就干脆离开”情况这里（所包含意义）要更深些我宁可不和那些粗心大意人起工作这就是软件发展进化论 HuIfbaiducukNY6
HuIfbaiducukNY6这样把人分成两种是
个冷酷、无情观点我宁愿选择第种人忍受他们 HuIfbaiducukNY6
HuIfbaiducukNY6我是
个比较自私人我完全不知道人们为什么要从不同方面进行考虑但是他们确实是（那么做）人们认为我是个好人但事实上我是个诡计多端自私鬼只要最终能得到我所认为更好系统那么我对任何感情伤害或工作时间损失都不在乎 HuIfbaiducukNY6
HuIfbaiducukNY6我并不只是（在口头上）说说而已
我真不是个很好人我能面无表情地说“我不在乎”而且我确实不在乎 HuIfbaiducukNY6
HuIfbaiducukNY6我相信不使用内核调试器会迫使人们在
个不同层次上考虑问题我认为如果你不使用调试器你就不能得知他如何运转以及你如何处理你就试图从别角度去考虑问题你会想在不同层次上理解事情 HuIfbaiducukNY6
HuIfbaiducukNY6在
定程度上更多是“源代码对二进制”（问题）你不必不得不去查看源代码（当然你可以去查看任何优良调试器使其轻而易举）你必须在源代码之上层次进行查看就是说不使用内核调试器话你将不得不去理解在做什么而不仅仅是特定（代码）行 HuIfbaiducukNY6
HuIfbaiducukNY6坦白
说对于许多实际问题（这和截然不同那些愚蠢是那么多）来说调试器并没有多大作用这些实际问题正是我所担心剩下就是些细节了他们最终都会被确定下来 HuIfbaiducukNY6
HuIfbaiducukNY6我能理解那些与我不
致意见我不是你们母亲如果你愿意话你可以使用内核调试器我不会你自己“毁誉”而轻视你但是我不会去协助你使用他我真诚希望人们不要高频率地使用内核调试器因此我不会将其作为评定标准如果现有调试器没有被人们很好了解我不会去（刻意）糟蹋贬低他我是个比较自私人但是我以此为荣！ HuIfbaiducukNY6
HuIfbaiducukNY6原文（英语）来自LINUX 内核邮件发送清单见下页
HuIfbaiducukNY6Sep 7, 2000, 14 :26 UTC (23 Talkback[s]) (3973 reads)
HuIfbaiducukNY6
HuIfbaiducukNY62000 年9 月7 日
14：26联合技术公司（23 对讲系统）（3973 读本） HuIfbaiducukNY6
HuIfbaiducukNY6From the Linux Kernel Mailing List:
HuIfbaiducukNY6
HuIfbaiducukNY6Date: Wed, 6 Sep 2000 12:52:29 -0700 (PDT)
HuIfbaiducukNY6
HuIfbaiducukNY6From: Linus Torvalds
HuIfbaiducukNY6
HuIfbaiducukNY6Subject: Re: Availability of kdb
HuIfbaiducukNY6
HuIfbaiducukNY6On Wed, 6 Sep 2000, Tigran Aivazian wrote:
HuIfbaiducukNY6
HuIfbaiducukNY6Very nice monologue, thanks. It would be great to know Linus' opinion. I mean, I k
Linus' opinion HuIfbaiducukNY6
HuIfbaiducukNY6of some years' ago but perhaps it changed? He is a living being and not some
of rules written in HuIfbaiducukNY6
HuIfbaiducukNY6stone so perhaps current stability/highquality of kdb suggests to Linus that it may be (just maybe)
HuIfbaiducukNY6
HuIfbaiducukNY6acceptable
o official tree? HuIfbaiducukNY6
HuIfbaiducukNY6I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a
HuIfbaiducukNY6
HuIfbaiducukNY6debugger, but as a disassembler on steroids that you can program.
HuIfbaiducukNY6
HuIfbaiducukNY6None of the arguments for a kernel debugger has touched me in the least. And trust me, over the years I've
HuIfbaiducukNY6
HuIfbaiducukNY6heard quite a lot of them. In the end, they tend to boil down to basically:
HuIfbaiducukNY6
HuIfbaiducukNY6-- It would be so much easier to do development, and we'd be able to add
things faster. HuIfbaiducukNY6
HuIfbaiducukNY6And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone singlestepping
HuIfbaiducukNY6
HuIfbaiducukNY6through code to find the bug. I do not think that extra visibility
o the system is necessarily a HuIfbaiducukNY6
HuIfbaiducukNY6good thing.
HuIfbaiducukNY6
HuIfbaiducukNY6Apparently,
you follow the arguments, not having a kernel debugger leads to various maladies: HuIfbaiducukNY6
HuIfbaiducukNY6- you crash when something goes wrong, and you fsck and it takes forever and you get frustrated.
HuIfbaiducukNY6
HuIfbaiducukNY6- people have given up on Linux kernel programming because it's too hard and too time-consuming
HuIfbaiducukNY6
HuIfbaiducukNY6- - it takes longer to create
features. HuIfbaiducukNY6
HuIfbaiducukNY6And nobody has explained to me why these are bad things.
HuIfbaiducukNY6
HuIfbaiducukNY6To me, it's not a bug, it's a feature. Not only is it document.d, but it's good, so it obviously cannot be a bug.
HuIfbaiducukNY6
HuIfbaiducukNY6"Takes longer to create
features" - this one in particular is not a very strong argument for having a HuIfbaiducukNY6
HuIfbaiducukNY6debugger. It's not as
lack of features or code would be a problem for Linux, or, in fact, for the HuIfbaiducukNY6
HuIfbaiducukNY6software industry as a whole. Quite the reverse. My biggest job is to say "no" to
features, not trying to HuIfbaiducukNY6
HuIfbaiducukNY6find them.
HuIfbaiducukNY6
HuIfbaiducukNY6Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you
HuIfbaiducukNY6
HuIfbaiducukNY6get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining
HuIfbaiducukNY6
HuIfbaiducukNY6about a kernel debugger.
HuIfbaiducukNY6
HuIfbaiducukNY6Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds
HuIfbaiducukNY6
HuIfbaiducukNY6callous, and by God, it is callous. But it's not the kind of "
you can't stand the heat, get out the the kitchen" HuIfbaiducukNY6
HuIfbaiducukNY6kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with
HuIfbaiducukNY6
HuIfbaiducukNY6people who aren't careful. It's darwinism in software development.
HuIfbaiducukNY6
HuIfbaiducukNY6It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the
HuIfbaiducukNY6
HuIfbaiducukNY6second kind. Live with it.
HuIfbaiducukNY6
HuIfbaiducukNY6I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm
HuIfbaiducukNY6
HuIfbaiducukNY6a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or
HuIfbaiducukNY6
HuIfbaiducukNY6lost hours of work
it just results in what I consider to be a better system. HuIfbaiducukNY6
HuIfbaiducukNY6And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face,
HuIfbaiducukNY6
HuIfbaiducukNY6and really mean it.
HuIfbaiducukNY6
HuIfbaiducukNY6I happen to believe that not having a kernel debugger forces people to think about their problem on a
HuIfbaiducukNY6
HuIfbaiducukNY6d
ferent level than with a debugger. I think that without a debugger, you don't get o that mind where HuIfbaiducukNY6
HuIfbaiducukNY6you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about
HuIfbaiducukNY6
HuIfbaiducukNY6problems another way. You want to understand things on a d
ferent level. HuIfbaiducukNY6
HuIfbaiducukNY6It's partly "source vs binary", but it's more than that. It's not that you have to look at the sources (of course
HuIfbaiducukNY6
HuIfbaiducukNY6you have to - and any good debugger will make that easy). It's that you have to look at the level above
HuIfbaiducukNY6
HuIfbaiducukNY6sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand
HuIfbaiducukNY6
HuIfbaiducukNY6what the program does. Not just that particular line.
HuIfbaiducukNY6
HuIfbaiducukNY6And quite frankly, for most of the real problems (as opposed to the stupid bugs - of which there are many,
HuIfbaiducukNY6
HuIfbaiducukNY6as the latest crap with "truncate
" has shown us) a debugger doesn't much help. And the real problems are HuIfbaiducukNY6
HuIfbaiducukNY6what I worry about. The rest is just details. It will get fixed eventually.
HuIfbaiducukNY6
HuIfbaiducukNY6I do realize that others disagree. And I'm not your Mom. You can use a kernel debugger
you want to, and HuIfbaiducukNY6
HuIfbaiducukNY6I won't give you the cold shoulder because you have "sullied" yourself. But I'm not going to help you use
HuIfbaiducukNY6
HuIfbaiducukNY6one, and I would frankly prefer people not to use kernel debuggers that much. So I don't make it part of the
HuIfbaiducukNY6
HuIfbaiducukNY6standard distribution, and
the existing debuggers aren't very well known I won't shed a tear over it. HuIfbaiducukNY6
最新评论