电影,其实是一件非常私人的东西

看电影,就像其他一切需要调动内心体验的行为,都是非常私人化的,这是无数次教训得出的宝贵经验。它告诉我,自己的看法,不要指望其他任何人能认同。

很多次沮丧的发现,自己给身边的人倾心推荐的电影,他们看完都表示没有什么感觉。有一个经验是,如果电影看到一半,对方萌萌的抬起头,弱弱的问道,这个电影到底是讲什么的啊?这个时候最聪明的做法是赶紧换别的活动,不要抱有任何也许后面的剧情会让他/她大为震撼的幻想。

刚开始的时候是心情是很不愉快的,明明这个电影我已经看了三遍了,恨不得次次都有泪点,为啥在您这就一无是处呢?后来,我逐渐领悟到,问题在我,而不在别人。

只要不是太糟糕的电影,无论什么类型,基本上我都能集中注意力去看的。因为电影于我,是一种精神体验,当你的精神投入到一定程度,有时会觉得自己把别人的人生也经历了一遍。人的一生只有一次,但通过电影,让人生在某种程度上得到了延伸。

所以,看电影的确是一种非常私人的东西。能陪朋友一起看的,只能是那些“爆米花电影”。

所以,下次有跟别人一起看电影的欲望时,及时打住。

两只金鱼

最近家里来了两个客人:两只金鱼,一只白色的,一只红色的,我给他们分别取了个名字,小红与小白。于是每天早上出门前,给他们喂点食料,晚上回来后趴在鱼缸前跟他们说两声Hello成了我的一大乐趣。

几天之后,我发现,当我凑近鱼缸跟他们say Hello的时候,他们会慢慢的游到水面,露头吐出两个泡泡然后迅速沉入水底,仿佛一脸娇羞。一脸娇羞,说明我是一个喜欢歪歪的人,放佛,有说明我并没有歪歪的那么放肆。

想起小时候貌似看过一个少数民族的传说,一个小伙子家里有条鱼,每天当小伙子出门干活后,那条鱼就跳出鱼缸,变成一个美丽的姑娘,把家里的活都干好。不知道是不是古人和我一样看到了鱼儿冒泡时"一脸娇羞"的样子,才歪歪出这么个故事的。

RPM中的%config和%config(noreplace)

打开一个rpm spec文件,在 %files段有一个指令很常见:%config(noreplace),这个指定到底是干什么用的呢?

答案是,该指令决定如果一个文件被管理员修改过后,下次更新该文件所在的rpm包时,该文件的存在状态。例如,一般升级软件时,配置文件是不会变化的,而主程序则一般需要被升级(替换)。

对于spec文件中在%files段的某一个文件,我们要讨论三种情况:

  1. 没有带%config指令。例如:%{_sbindir}/redis-server
  2. 带了%congfig指令。例如:%config %{_sysconfdir}/redis/redis.conf
  3. 带了%config(noreplace)指令。例如:%config(noreplace) %{_sysconfdir}/redis/redis.conf

- 阅读剩余部分 -

春哥关于Nginx踩坑记(一)的回复

对于Nginx踩坑记(一),在openresty的google group上提了个问题:ngx.exec是如何处理上层定义的变量的

春哥的回复摘录如下:

你这里使用了 rewrite 配置指令来发起内部跳转。其实 rewrite 指令发起的内部跳转非常特殊:它不会从
server-rewrite 阶段重新开始运行,而是从 find-config 阶段开始执行,所以你上例中写在server {}
块中的“set $hello hello”并不会在跳转后重新运行一遍,因为 server-rewrite 阶段在跳转后被直接跳过。

注意,rewrite 配置指令的特殊行为也可以通过下面这一行 ngx_lua 配置来复现:

 rewrite_by_lua 'ngx.req.set_uri("/test2", true)'; 

而ngx.exec() 调用(以及其他接口,比如 echo_exec 配置指令)发起的内部跳转的标准行为是从 server-rewrite
阶段重新开始执行,所以你的“set $hello hello”会被重新执行一遍,从而改写掉 $hello 变量原先的取值(即"bye")。

我或许应该在教程里强调一下这个重要细节 :)

Nginx踩坑记(一)

1. 预备知识

Nginx有两种定义变量的方法,一种是在模块中定义,从而成为内建变量;另一种是在配置文件中通过set指令来定义。

配置过Nginx的童鞋可能都知道这样一个事实:一个请求在其处理过程中,即使经历多个不同的 location 配置块,它使用的还是同一套 Nginx 变量的副本。

例如,如果有如下的配置:

location /test1 {
        set $hello hello;
        rewrite /test1 /test2 last;

}

location /test2 {
        echo $hello;
}

虽然变量是定义在location /test1中,但Nginx 变量一旦创建,其变量名的可见范围就是整个 Nginx 配置,所以在/test2中直接使用该变量是不会报错的。另一方面,由于变量的生命周期是与请求相关的,所以如果直接访问/test2,得到的变量$hello是一个空值,而访问/test1,则会内部跳转到/test2,将/test1中赋值的hello打印出来。

- 阅读剩余部分 -