Shell's Home

Apr 18, 2012 - 1 minute read - Comments

值返回和指针返回简说

好吧,这是常识,我说快点。 C * c = get_c(); 这是指针返回。 C c = get_c(): 这是值返回。 指针返回的缺点是,你必须检测返回指针的有效性,也就是NULL。并且,你需要手工管理指针释放。而优点则是避免了值拷贝,还有可以返回空值,即通过返回NULL表示没有值的情况。 而引用返回最大的优势在于,变量的生存周期和作用域相同,你无需管理释放问题。然而缺陷就是庞大的拷贝开销。 在get_c返回的时候,会return一个对象。这个对象是子函数作用域对象(sub function scope),会随着子函数退出而失效。因此,在返回值的时候会引发拷贝。这种拷贝有两种可能。 拷贝构造 当返回值被用于某个对象的声明时,会触发拷贝构造函数。被返回的对象会作为拷贝构造参数传递(引用传递),而拷贝出的对象就是被生成对象。 赋值算子 即operator =。当对某个已经声明对象进行赋值时,会发生这种现象。 当然,近代编译器对于“在返回时进行构造用于返回后的构造”这种情况做了优化,通称RVO优化。例如上文,如果get_c中使用return C(a, b);进行返回,实际上只有C::C(a, b)的调用,而没有C::C(const C & c)的调用。

Apr 17, 2012 - 1 minute read - Comments

vps上应当装什么

假定你有一台debian vps,上面需要装一些东西来——你懂。你应该装一些什么呢? 基础部分 ssh 没啥好多说,没有ssh,你甚至无法管理机器。不过注意,安全的ssh方式应当只允许使用key登录,禁止一切密码登录。而且对于没必要登录的某些用户,需要在/etc/passwd中将shell改为/bin/false。至于端口改不改,这个不重要,看你心情。 vim debian默认装的是vim-tiny,很不好用。建议改为vim,改配置的时候让自己舒服点。 安全部分 iptables-persistent 这是debian内用于iptables规则持久化的工具,你可以编辑/etc/iptables/rules.v4来修改防火墙规则。注意,目前debian stable(squeeze)中的版本还没有4/6区分,你可以弄一个testing(wheezy)中的来装。 一般来说,你的规则中至少要包含以下内容: -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i tun+ -j ACCEPT -A INPUT -i ppp+ -j ACCEPT -A INPUT -p tcp -m multiport --dport 22,xxx,xxx,xxx -j ACCEPT -A INPUT -p udp -m multiport --dport xxx,xxx,xxx -j ACCEPT 而且强烈建议,先保存一个没问题的iptables,然后直接修改iptables,再保存。这样的好处是,当你脑残改错了导致你自己都无法管理的时候,只要重启就可以恢复vps工作,而不用更麻烦的动作。 denyhosts 这是ssh的连接防御进程,用python编写。如果有人试图尝试你的ssh密码,这个程序就会踢掉他的ip。 如果你已经用了我说的,通过key的连接方式,你可以一次就直接踢掉对方ip。 管理部分 ifstat ifstat是用于网络流量管理的工具,可以告诉你网络目标的流量是多少。 dnsutils dnsutils里面包含了不少用于管理dns的工具,包括我们常用的nslookup,还有相对少用的dig。 mtr-tiny mtr是一个traceroute工具,比后者好用很多。这个工具可以快速跟踪路由。

Apr 13, 2012 - 1 minute read - Comments

mirrors.geekbone.org软件仓库镜像站将于4月中旬下线

原文在此我用了5年多的cn99和geekbone两大镜像终于全部下线。 需要通告的一点关键问题即是, 由于tux下线早于新一个版本的debian发行, 因此目前mirrors.geekbone.org还是已经发行的debian安装盘的官方源之一. 请大家在安装debian6的时候不要再选择geekbone, 并请通告其他debian用户. 在09年加入shlug之初,就知道当年用了很久的geekbone服务器是shlug管理维护的。当时就很惊讶,以捐助方式运作一台镜像服务器,这个是相当不容易的。包括募集,管理,账目,在中国要做整套过程需要相当心力。而且geekbone还是在debian有注册的镜像站之一。可以看Debian 全球鏡像站。 大约在11年,中科大的ustc服务器上线后。在一次和lightning的闲聊中,lightning就谈到了tux服务器的问题。当时tux的服务器硬盘已经不足,最多在数月后就会满额。lightning删除了部分上面的无用数据,让服务器可以稍稍多工作一些时日。我当时就建议不要全面镜像所有的debian镜像,毕竟当时中国已经有anheng和ustc两个全面源,其中ustc还在申请大陆一级源(他们的资源投入确实不错,镜像速度相当快)。tux毕竟是老服务器,可以转做i386和amd64两个主要镜像。国内大部分人用的都是这两个arch,sohu的部分镜像也是针对这部分的。lightning表示看看再说。 今天,看到了shlug通告,tux服务器准备下线。想想也的却是,tux已经在超期服役,而国内已经有了ustc, anheng, sohu, bjtu四个镜像. 再进行一次募捐让tux恢复服役看来是没什么必要了. 在此, 感谢一下shlug服务器维护团队, 谢谢你们的努力让我五年来得以享用快速的源服务. 祝tux一路走好, 愿电脑诸神与它同在, enter. 另外, 提一点我们和欧美的工业水准差距. 我曾经撰文说过, 中国要追赶美国还有很长的路要走. 当时列举的证据就是dd和debian mirror lists. 当时我们也是4个源, 目前加入了bjtu, tux退出, 还是4个源. 相比美国那个深不见底, 鼠标滚轮滚好几下都没看到头的列表, 实在是太差距了. 这个差距不仅体现在源少, 更体现在用户少. 用户少就是源少的原因. 如果用户增长一个数量级, 目前这些源肯定会发生不足, 然后吵着让各个大学再开一两个镜像出来. 我倒是觉得这样不错, 至少sjtu有机会露个脸. 其实sjtu也是有自己的源的](http://ftp.sjtu.edu.cn/debian/)%E7%9A%84), 只是没有对普通网络用户开放, 访问速度缓慢而已.

Apr 12, 2012 - 1 minute read - Comments

segment的核心数据结构空间和时间效率估量

首先我们简述核心词典的目标。词典最主要的目标是,给定一句句子S,匹配出所有和句子开始拥有完整匹配的词语。所谓完整匹配,就是句子开始的一定长度的连续序列和词语相等。例如,中华,中华人民,中华人民共和国,都是句子:中华人民共和国今天成立了,的完整匹配。 要解决这个问题,直观方式是使用tied tree。但是中文的tied tree非常不好实现。英文的tied tree在一个节点上最多拥有不超过26个子节点,而中文的在根上面会拥有6000个以上的子节点,使用同样的结构在子节点上会浪费大量内存。 我们先跳过tied树本身的细节,来讨论如何使用python内置数据结构高效简洁的完成这一工作。作为一个读比写高频很多的结构,无疑hash table是一个非常适合的结构。我在hash table的性能分析中说过,hash table的查询性能是O(1)量级的。无疑,可以使用hash tree来高速完成查找。同时注意一点,词语的最小长度是2,因此不存在只有一级的结构。所以,hash tree的第一级结构可以从2开始,而不是1。 实现效果如何?我们正式给出的词典拥有127K的词汇量,平均第二级宽度为6.8,因此大致可以推算出,第一级的词典含有元素19K个左右。python源码解析中说过,当表项小于50000个时,扩张大小为当前活跃表项的4倍,最高填充率不超过2/3,即填充率最低25%,最高66%。平均来说,填充率应当在45%上下波动,我们以0.5计算,实际上一级词典的Entry个数应当是40K个上下。在源码Include/dictobject.h:50有给出Entry的结构,这应当是三个平台相关的数据结构,以贝壳的64位系统而言,长度应当是24字节。忽略掉辅助结构,一级词典的大小应当是960K,即约1M。而词典指向的数据,即2字长的str对象本身头部长度24字节,辅助数据长度12字节,数据长度4字节(utf-16编码的两个unicode),null term1字节,共计41字节。由于python对象是8字节对齐,因此实际占用48字节。19K个数据总计占用912K。 二级表项平均长度6.8,这个长度很难估量。因为5的话总表项刚好是8,而6就会增长到24,我们取中间数20做一个估量值(因为6.8毕竟大大偏离了5),一个词典的大小应当是480字节,加上头部大约是512字节(算的粗糙点吧),19K个词典就是8.5M左右。指向的对象长度更加难估量,我们粗糙点按照96字节一个对象(别忘记了,unicode对象不但成员多,而且超出了BOM,一个字占4字节),127K个对象大约是12M内存。而float内部使用C的double类型,一个对象占据32字节,127K个对象占据4M内存。 以上总计,初级词典本身占用1M,关键字占1M。二级索引占据10M,关键字占12M,频率数据占4M。总计28M内存,基本上一个12.7W词的词典,大小2.5M,占据30M内存,这就是dict核心词典的空间效率估量。 时间复杂度估量更加复杂,不过我们可以简化来说。初级索引需要多少时间?O(1)量级,毋庸置疑。问题是二级词典的复杂度,异常难算。凑合一下,按照比较6.8次计算(因为必须通过遍历才能知道全部的匹配)索引出一个句子所有的完整匹配的时间复杂度O应当为O(n),其中n是平均二级索引宽度。目前而言,实际测量结果,平均6.8。当词汇量大于一定值后,随着词典的加大,这个值基本是线性增加的,我们粗略的可以认为O(n)即是正比于词典大小。 而后我们顺便给出分词核心算法在处理一句话时的效率估量吧,证明太长,这里写不下。假定句子长度S,词典大小N,匹配数目M,分词算法的时间复杂度量级为O(N*M*S),有兴趣的可以帮我复核一下,这个证明颇为困难,不知道有没有证错。在实际运行的时候,匹配数目会跟着词典的增长而增长,而句子长度则相对固定。当然,明眼人一眼就可以看出,所谓匹配数据随着词典增长而增长,其中并不是正比的。而是O(1)<O<O(n)。因此我们可以看作时间复杂度为O(N)<O<O(N\^2),具体是什么,做不出来。 然后是纯粹的tied tree的性能估量。讲到tied tree,我们就必须要提到如何实现一个有效的tied tree。实际上纯粹用区域哈希映射太浪费内存了,而顺序查找太浪费时间。比较折衷的办法还是只有——dynamic hash table。 不过这次我们就可以控制一下哈希表的大小了。对于大小不超过6W的哈希,我建议采用crc32,虽然离散度并不高,但是作为一个近似填满的hash table的hash key足矣(这点需要实际考察一下)。如果是自己实现,表项直接存字符串,连指针都不需要,采用开链法。总计大小1M即可以保存所有的一级数据。 二级数据就无法这么偷懒了,因为二级结构中字符串长度不定。但是以数据展开大小只有2.4M来看,无论这一级别如何扩张,字符串本身大小不应当超过3M。开链法一个节点24字节,平均填充率0.5计算,14个表项一个词典(这个也可以自行控制了),336个字节一个词典,乘以19K个dict。大约6.23M。127K个频率数据1M,这是常规占用。 以上总计,初级词典本身占用1M,二级结构本身占用10M,不超过20M应当就可以构建起一个高效的核心数据结构。由于实现类似,时间复杂度也类似,就不详细推论了。 以上还有一点可改进之处,dict作为二级存储的绝对劣势在于,必须要对比全部词典才能确定完全匹配数量,于是时间复杂度正比于词典大小。严格的tied树只需要沿着顺序进行几次索引即可,复杂度取决于词语长度——基本来说和词典大小无关。按照这个推论,实现一个紧凑的,高效的二级小结构,可能比较有利于减小总体大小,增加工作速度。

Apr 11, 2012 - 1 minute read - Comments

赞一下京东

昨天觉得背不舒服,买了个按摩器,200。 10点下单,下午两点就送到了,效率不错。 但是用了20分钟,不动了。照说明冷却了一阵,还是不动,遂报换货。 下午四点打电话,10分钟后就来电确认了,五点来了个人,把东西拿走了。 我要求换货,目前页面写的是退货,不知道会不会把新品送来。 不过效率很不错呢。

Apr 10, 2012 - 1 minute read - Comments

如何用tabbar插件做emacs的tab定位切换

说明一下,定位切换的意思,是像chromium那样,用Atl-1-9直接切换tab。而不是用上一个下一个慢慢换。另外,是切换buffer,不是切换frame。 以下是实现部分: ;; 全部的buffer都分一组,否则这个修改是没任何意思的 (setq tabbar-buffer-groups-function (lambda () (list "All Buffers"))) ;; 去掉emacs自带的几个buffer (setq tabbar-buffer-list-function (lambda () (remove-if (lambda(buffer) (find (aref (buffer-name buffer) 0) " *")) (buffer-list)))) ;; 切换到第N个buffer,1为第一个,负数表示从后数,注意0会出错,这里就不处理了 (defun switch-tabbar (num) (let* ((tabs (tabbar-tabs (tabbar-get-tabset "All Buffers"))) (tab (nth (if (> num 0) (- num 1) (+ (length tabs) num)) tabs))) (if tab (switch-to-buffer (car tab))))) ;; 不说废话,绑热键 (global-set-key [(meta 1)] (lambda () (interactive) (switch-tabbar 1))) (global-set-key [(meta 2)] (lambda () (interactive) (switch-tabbar 2))) (global-set-key [(meta 3)] (lambda () (interactive) (switch-tabbar 3))) (global-set-key [(meta 4)] (lambda () (interactive) (switch-tabbar 4))) (global-set-key [(meta 5)] (lambda () (interactive) (switch-tabbar 5))) (global-set-key [(meta 6)] (lambda () (interactive) (switch-tabbar 6))) (global-set-key [(meta 7)] (lambda () (interactive) (switch-tabbar 7))) (global-set-key [(meta 8)] (lambda () (interactive) (switch-tabbar 8))) (global-set-key [(meta 9)] (lambda () (interactive) (switch-tabbar 9))) (global-set-key [(meta )] (lambda () (interactive) (switch-tabbar -1)))

Apr 9, 2012 - 1 minute read - Comments

empathy的无聊问题——记一次排错

废话不说,debian testing,装了empathy后没法用account,等于废物。 先看bug report,开reportbug,看empathy的bug,有一个“Accounts window does not open”,估计就是我要的。 在浏览器中打开,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594945&archived=False&mbox=no,里面说了大致情况,和我这里非常类似。 第一个意见,killall -9 empathy-account,无效。 第二个意见,需要装CM。 跑去看看,一个都没装。跟着看说明,应该在recommand里面的。OK,我这里有这个配置。 shell-deb:\~\# cat /etc/apt/apt.conf.d/20norecommanded APT { Install-Recommends 0; }; 这是对付很多无聊包把recommand当作suggest用的,结果这次中标。其实这次的recommand应当放入dep里面的。 OK,完事。 PS.虽说如此,记得把telepathy重启一下,否则jabber协议看的到但是无效。

Apr 1, 2012 - 1 minute read - Comments

无线网络问题的诊断

今天看到ZQ在坛子里面说无线网络卡,想想这对很多人是个问题。现在越来越多设备采用无线网络,本来看似够用的无线网络应该也会逐渐变的不怎么够用。这篇文章的大部分内容在blog中都有说,但是没有集结成文。今天集结一下,为大家提供便利。 关于无线网络卡这个问题,有多种可能,我们逐个分析原因/诊断方法/解决方案。 有终端连不上,即使这个终端就在路由器附近 这个主要是因为无线网络负载的设备达到极限所致的。这个极限,我见过最差的路由器是8个,普通路由器(包括dir-825刷openwrt)大概是50上下,苹果的要超过100。一个/24子网的最大负荷是253个IP地址,如果不另行设定,大多数的默认配置都无法超过这个极限。 解决方案很简单,加路由器,或者换一个更好的路由器。加路由器具体参考这篇。换路由器的意见是,不要用fastnet,推荐tplink或者dlink的设备,buffalo的也不错。如果你已经用了这些路由器,但是终端超过50个(好像通常只有公司会碰到吧),可以考虑苹果的,或者多扔两个路由器,辐射小信号好。 有终端离开一点距离后就连不上,或者离开一定距离后速度变慢 这是典型的信号衰减。作为不严谨的测试,你可以在android上安装wifi测试仪,然后走到各个角落。如果你的信号质量不足80dbm,那么就属于比较差的情况。大概能连接,但是经常断线,或者速度很慢。如果不足90dbm,基本就不可用了。 解决方案也很简单,同上一个。总之优化到家里的每个点信号质量都可以就好了。 明明信号很好,速度就是上不去 有可能是因为周围的channel干扰,也可能是因为你的路由器CPU不足。你可以用wifi测试仪,看看你周围当时有多少人在用你路由器的channel。两个channel相隔5以上才不互相干扰。所以,如果你使用channel6,那么channel2-channel10都会对你的信道造成一定干扰,相隔越远干扰越小。而如果你隔壁有一堆和你同channel的AP,实际带宽是均分给你们所有channel的。如果对方用的比较多,也会对你造成干扰。 这是非常难解决的问题,你总不能跑到隔壁说,你们改个信道吧。一方面,如果有条件,你可以对墙壁,门缝做信号屏蔽。这样能减小一点隔壁的信号干扰。另一方面,建议你采用5G频段。这个频段的信道更多,更不容易串扰。但是目前支持5G频段的设备少,而且5G的穿透能力比2.4G更差。 CPU不足呢 CPU不足最典型的确诊就是关掉加密,你的无线网速就会突然暴增。或者你保持无线空载,用有线狂用网络,无线的ping值从10变化到上千。 碰到这种情况,扔掉垃圾路由器重新买一个。 明明有些设备一点问题都没有,有些设备就是连AP都找不到 看看你的channel是否设定到了11以上,例如12/13/14之类的。各个国家对channel的许可范围不一,欧洲日本美国的许可比中国宽一些,因此有12等信道,中国最高到11。因此你用水货手机连外贸版本的路由器的时候,channel12没问题,而用中国许可的设备的时候就连AP都找不到。 解决方法很简单,换个中国许可的channel。 无线速度跟不上外网速度 自从20M以上光纤出现以来,这个问题就逐渐变成主要问题。11g的标准速度号称54Mbps,但是实际上通常只有18Mbps。而外网速度从常见的1/2/4Mbps骤然升到了10/20/30Mbps,就出现了严重的外网速度反超内网速度。 这个一点办法都没有,只能把11g的设备都淘汰光。只要有11g的设备在,11n就无法发挥极限速度,导致你的无线只能在18Mbps上晃。而换用11n的设备后,速度一般可以达到30-40Mbps以上,基本够用。 路由器被打爆 由于速度加快,导致现在有更多的小包可能被传输。虽然传输速率要求不高,但是由于路由器对每个包都需要做同样处理,所以大量小包的资源消耗和同样数量的大包是同一个量级的。我们做一个简单的计算。如果一个包是1500字节,128KB/s的网络可以每秒传输90个包。而如果每个包是64字节,就可以传输2000个包。而当速度升级到2.5MB/s(20Mbps光纤),如果是1500字节,每秒1700个,而64字节的就是40000个。如果路由器的处理能力是每秒10000个包,升级到光纤一跑小包就挂了。很多人在ADSL的时代没问题,升级到光纤反而频繁出问题就是这个原因。 现象比较多,如果是交换机挂掉,往往是一个机器链路OK但是就是有TX没有RX。怎么整也没用,但是过一会,这台机器突然就OK了,换下一台出同样问题。而如果是整个路由器挂掉,可能是路由器突然重启,或者ppp0断线重新拨号。还有的机器是死在那里没任何反应,必须拔掉电源线重新插才有效。

Mar 30, 2012 - 1 minute read - Comments

redis的rdb和aof模式性能对比

由于是同一台机器,进行相对对比,我就不列配置了。系统是debian testing,kernel 3.2 686。redis 2.4.8。 测试方法是用python写的脚本对redis数据库进行写入,看写入速度。 100000/300000/1000000是数据量,插入的都是string。第一个数据是最小时间,第二个是平均,第三个是数据大小。 100000: dbmode: 4.8, 5.1, 1477792 aofmode: 9.1, 9.3, 3677803 300000: dbmode: 16.5, 17.6, 4877792 aofmode: 21.1, 21.4, 11477803 1000000: dbmode: 61, 65, 16777792 aofmode: 77, 85, 38777849 从简单分析来看,aof比rdb慢25-80%,但是大规模数据都比较支持慢25%这端。估计在低数据量下,rdb模式更加占优势。数据规模增长时,速率比接近于4:5。aof的数据比rdb数据大150%(2.5倍上下),这点随着数据增长基本不变。 从读性能分析来看,两者差异不大。同样,数据分别是最小时间和平均时间。 dbmode: 55, 60 aofmode: 62, 63 差异在10%以内,甚至比最小-平均差异还弱。基本可以视为一致。

Mar 27, 2012 - 1 minute read - Comments

假如生命可以重来——致80后的家长

假如我们的生命可以重来——好吧,这个听起来像七老八十的老头说的话,不过,确实,人过到而立之年,会发现很多遗憾,很多很多的已经太晚。假如人生可以重来,我们也许就能弥补其中一些。 假如生命可以重来,我首先要干的第一件事情是在中学和大学多去旅行几次。这不是说我中学没有旅行过,而是都太“安全”了。苏州?杭州?拜托,这些地方在工作后都有的是机会去。如果回到初中,也许我会跟父母申请,在中学的时候就跑去黑龙江,看看松花江上的雾凇,索菲亚大教堂。高中跑去敦煌看看莫高窟,看看大漠风光。跑去云南看玉龙雪山,看西双版纳。大学跑去喀那斯,纳木错。 现在?我现在哪里都能去了,都可以去了,都有钱去了,可惜没时间去。我毕竟有一个家要养活,不能任性的丢下工作,突然和老板说,我要去西藏一个月,您看着办。 也许初中去听起来不是很安全。可是想想,现在去,比初中生安全到了哪里去?旅行中的安全,来自出门的阅历。我们都是在不断的出门中学习到,什么是安全,怎么样才安全。也许,在初中学到这些东西,会比毕业后学到更加有用。 假如生命可以重来,我要做的第二件事情是学个乐器,当然,也可能是画画。这也不是说我没学过乐器,小学的时候我学过电子琴,大学学过吉他。从哪个角度看,都和“没学过乐器”沾不上边。不过我要说的是,并不是说“会使用一种乐器”就算“学过一种乐器”的。 小学的时候,当时好像流行让小孩学各种班。当时我对音乐挺感兴趣的,所以就老妈做主,买了个很贵的电子琴。那时候才刚刚脱离36块工资,一户人家一个月也没多少钱,一把YAMAHA的电子琴要价1600。既然买了这么贵的电子琴,总不能让孩子瞎玩对吧?于是老爹老妈就给我报了一个班,每周接送去学两个小时,家长就在门口等着,到时间了再接回来。 于是,音乐对我的意义就从好听的歌曲变成了跳跃的五线谱,琶音,休止符,三拍子,每天一个小时的练习。我顿时就觉得不好玩了,每天哭闹不止。三个月不到,父母的音乐家梦想破灭了,电子琴现在还在家里不知道哪个角落扔着。 高中的时候,有个同学吉他弹的不错,经常跑出去一起练琴什么的。我就跑去听他们玩各种各样的声音,唱歌。高考结束,我有点自己的时间,才开始又学起了吉他。如果让我重新选择,也许我那个时候不会去弄那么贵的电子琴,而是弄一个小孩子玩的乐器,找朋友玩玩看。那是一种乐趣,一段人生,哪怕其实我们的歌不忍猝听。 假如人生可以重来,我要做的第三件事情是多谈几个女朋友。首先要发表的一点声明是,这不代表我对老婆有任何不满,也不代表我很花,打算——咳咳,你们懂。 我曾经有一条推,被广为转发,大概意思是。父母在初中高中甚至大学的时候,以学业为名,尽力不让我们恋爱。等大学一毕业,又逼着我们赶快找一个好的老公/老婆出来。怎么可能做的到,你当恋爱不需要学习么? 也许我们在初中时候谈的女友,十个中有九个走不到最后。我翻阅开心上高中同学的结婚记录时发现,基本所有的高中恋人,哪怕当时看起来多么金童玉女,基本都很少有走到最后的。唯一的一对例外可以说是相当的有决心和坚持,据我所知,男女双方一起报同一所学校的不罕见,可是男方没考上就硬是复读重考,女方还肯等的,就非常罕见了。这里恭喜一下杨亮刘莹,很遗憾没参加你们的婚礼。 但是,无论如何,在小时候谈的恋爱,会成为长大后的青涩回忆。当你越长越大,论及婚嫁,恋爱也就越来越不单纯。你不会简单的评判你是否喜欢拉着他的手,带你在街上走。而且还会考虑当你需要用车的时候,他是否买的起。你希望你的青春回忆中,充满了酸甜的爱恋,还是父母和老师的斥骂?或者更糟糕的,根本就是彻底的一片空白? 更何况恋爱中的失败,会成为你下一次不会轻易犯下的错误。在中学,我们很可能不会上床,也没有孩子。如果有什么错误,我们还来得及修正。而如果到了需要结婚的时候再开始积累经验,一个不留神就会碰上一个看似合适的陷阱。结果必然是悲剧。不是在痛苦中挣扎一生,就是带着伤心,争斗财产/孩子之类的问题。 好吧,上面一堆,和80后的家长有什么关系? 我们的人生有很多遗憾,有不少遗憾,是因为我们承载了家长的梦想,受到家长的管束。家长认为他们没有接受过正规的音乐教育,所以他尽力让我们接受正规的音乐教育。家长认为初中生旅行是不安全的,却没有想过他们十几岁就离开家乡去了大城市闯荡。他们没有接受过高等教育,所以认为我们需要高等教育,所以不能谈恋爱。但是这一切的一切,却并没有使得我们的人生完美。 所以,当你决定你孩子的人生的时候,不妨想想。假如我的人生可以重来,我想要的是什么?