读《UNIX编程艺术》随记

 

 

2012-07-07

《UNIX编程艺术》这本书是人介绍的，

一看到这书的厚度，我有想打退堂鼓的冲动。好厚的说。

不过，听到可以不用细也可以，就硬着头接下这本书了。

 

先看它的书皮，一位师傅与一个徒弟先入眼球，

再看“艺术”这二字，似乎是一位师傅在传授而徒弟在聆听。

最后就纠结，我该从哪里看这本书。

 

出于习惯的原因，我从书后面开始阅。。。

 

 我先看附录D上的内容。先总结再细说。

看这附录上的内容，没有unix的知识及历史做背景真的很难看懂。

而且看了也不知道是不是自己所想的意思。

现在摘一个自己能看得懂的。

 

无名师与脚本狂

    无名师和学生吃早饭时，从黑客大陆来了人陌生访客。

    “I hear y00 are very 133t, ”他说，“Pl33z teach m3 all y00 know. ”（我听说你很牛请把你会的都教给我。）

    无名师的学生面面相觑，都没听懂这类粗鄙言语。无名师微笑道：“你想弄懂Unix？”

    “I want to b3 a wizard hax0r, ”陌生人回答，“and 0wn ever3one's b0xen. ”（我想当个顶尖黑客，能掌握所有人的机器。）

    “我不教这个”，无名师答道。

    陌生人很激动。“D00d, y00r nothing but a p0ser”，他说，“If y00 n00 anything, y00 wud t33ch m3. ”（哥们们，敢情你没真本事啊，你要知道点儿东西就教给我了。）

    “有条路，”无名师说，“可以将你带入真知。”他在纸上写了个IP地址。“黑掉这台机器，这对你来说应该不费什么力气，它的管理员不称职。回来后告诉我你发现了什么。”

    陌生人鞠了一躬就离开了。无名师把他的早饭吃完。

    几天过去了，几个月过去了。没人再想起陌生人。

    数年过去了，黑客大陆来的陌生人回来了。

    “你混蛋！”他说，“我黑掉了那台机器，你说的没错，太容易了。但是我被FBI抓起来扔进监狱了。”

    “好”，无名师说，“你可以继续下一课了。”他在另一张纸上写了个IP地址交给陌生人。

    “你疯了？”陌生人喊道。“经过这事，我再也不黑别人的机器了。”

    无名师脸现微笑。“这里就是”，他说，“真知的开始。”

    听到此，陌生人眼中一亮。

故事到这里为止了。

 

说这故事是讲黑客的呢，还是讲学习的真道呢？

可是这故事的题目是“无名师与脚本狂”，“脚本狂”这一词又怎么解释呢？

看完这个故事，头脑想着，它想说点什么呢？

 

看了《UNIX编程艺术》一个小时多一点就看不下去，于是找一些其它的内容来丰富一下自己。

上网搜索了一些内容，忘了搜索的主题是什么了。。

Hacker 和 Backer

不知道指的是谁，大概意思说，

黑客不是“黑”他人的机器就成功，而在于他能否找出系统漏洞并完善它。（对开源的说。）

原文找不到了，以上的说法是自己回忆+总结的，有不对的，请指出。

未完。

 

 

 

 

2012-07-11

 

读这本书第一章，我感兴趣的是UNIX的生成原则。

生成原则：避免手工hack，尽量编写程序去生成程序。

以前从来没有想过，代码也可以自动生成。

 一直想着代码是人写的，而现在有了新的观点，代码由机器生成更值得信赖。

 引用书上的话语：

 

“程序中的任何手工hacking老师滋生错误和延误的温床。程序规格越简单越抽象，设计者就越容易做对。由程序生成代码几乎（在各个层次）总是比手写代码廉价并且更值得信赖。

 当代码生成器能够提升抽象度时——即当生成器的说明性语句要比生成码简单时，使用代码生成器会很合算，而生成代码后就根本无需再费力地去手工处理了。

 而第一章让我印象深刻的，则是它的“KISS”原则。

K.I.S.S： Keep It Simple, Stupid!

 呃，这个，有点难以理解。

 只知道，UNIX提供了一个应用KISS原则的良好环境。

  

第一章只是简单的说了UNIX的相关哲学内容，并没有深入。

 慢慢来，越看越有感觉。 

接着，这本书讲UNIX的发展历史了。

历史，说真的，不喜欢。 

但是，能从中体会了当时的元老的思想也是一样不错的收获。 

近期才慢慢接触UNIX领域，不说从技术上跟随先， 

而我则是从思想上崇拜它而学习它。（以下是个人体会，可能有不对的请提出。） 

浸泡在UNIX的思潮中，有技术有能力的人站在前方，而这些人却不会高高在上。 

他们不断地吸收各种精华并融入到UNIX系统中。 

当然他们也会毫不犹豫地把降低整体性能的代码delete了。 

引用Ken Thompson的一句话： 

我最有成效的一天就是扔掉了1000行代码。

 

呵呵，看到这里就着实吓到了，原来UNIX的优化原则还有这一说法的。 

说到这里，再看第一章，第一章与第二章的思想上是相连的。 

到了第二章的最后，有一小节引人深思。 

UNIX的历史教训

 在UNIX历史中，最大的规律就是：距开源越近就越繁荣。任何将UNIX专有化的企图，只能陷入停滞和衰败。

 虽然我们在软件设计这个重要但狭窄的领域比其他人聪明，但这不能使我们摆脱对技术与经济相互作用影响的茫然，而这些就发生在我们的眼皮底下。即使UNIX社区中最具洞察力、最具远见卓识的思想家，他们的眼光终究有限。对今后的教训就是：过度依赖任何一种技术或者商业模式都是错误的——相反，保持软件及其设计传统的灵活性才是长存之道。

 另一个教训是：别和低价而灵活的方案较劲。或者，换句话说，低档的硬件中要数量足够，就能爬上性能曲线而最终获胜。

 真正的专业和奉献精神，正是我们在屈服于世俗观念的“合理商业做法”之前的所作所为。

 这里的教训二，看不明白。

 

 

 

 

2012-07-21

前一段时间，想在这本书找一找makefile的一些小链接，看能不能从中找到信息让自己更能体会MAKEFILE。。。

没有发现MAKEFILE的一些信息，只有MAKE的一些操作介绍。

这本书介绍MAKE时也插入一些MAKEFILE的信息，这让我头晕了。

通用生成目标
很多常用的典型makefile中根本没有文件依赖关系。它们是将某些开发者想要自动化的小过程捆绑在一起的方法。

接下来，书上引用了Stuatr Feldman的话：

生成目标非文件，这早已有之。“make all” 和“clean”是早些日子我自己的习惯。有一个老Unix笑话，输入“make love”，输出是“Don't know how to make love”。 

 其实make与makefile有什么区别呢。？？

求解。。。

~！~！~！~！

 

待完。