谈谈父子关系

去年创业之初,和另外两个合伙人聊到关于中国人的父子关系,特意问了一个与我同样来自于北方农村的合伙人,发觉中国农村父子间,大抵难有较多的精神交流,因为看过较多美国电影,对里面父子甚至家庭之见常见的we need talk这样的对白,以及随之而来的谈心,一直比较看重这样的做法,如今我初为人父,看着逐渐有一定意识的孩子,对于父子关系,我的确需要提前准备一些思考。

父亲算是村里为数不多的读了师范当了老师的人,然而既便是在这样的情况下,我与父亲的交流,基本上随着我上大学之后,印象中十二年我从华为离职,父母去北京陪我暂住过春节,走后我偶尔发现父亲留给我一封信(父亲之前应该在我高中时退学事件发生时还给我写过一封信),信件如今我已经遗失(或可能在老家旧屋中),粗略记得父亲大抵指责我停止了学习,他应该是挺期望我读研究生这样的路线,可惜我早早地工作了,他或又觉得我从华为这样的大企业离职,去往苏州这样的二线或三线城市,一如他当年从县城回村里教书那样的不明智,然而这些大抵是我凭印象的推测,可能也不一定代表他真实的想法;然而也就是从那之后,父亲与我,逐渐疏离了,加之因为观念的不同,无论是回村里,还是他来苏州的家里,我都与他有过一些比较激烈的争吵,从而使得我们基本上除了亲人间的嘘寒问暖,以及因我儿子这个纽带的关联产生的生活交流,基本上已经很难有过多的交流了,所以我所期望的美国式的交流,大抵很难发生在我与父亲之间,我似乎也很难主动再去改变这个事实。

回忆过往,自从从父亲教书的村小学毕业后,父亲基本上已经很少像小学那样修理我了,加之父亲或许对于兄弟姐妹的关注,母亲陆续代为养育了姑妈家的表弟、四叔家的儿子,我在家庭似乎觉得有人分享了父母对我的关爱,虽然如今我已经释然,但当时我还过于年轻,很难对这样的事情有所理解,因而或许隔阂从这些事情间逐渐产生,父亲那些年对我并不管教,我倒也足够自律,在父母提供的上学支持情况下,较为节省的读完了高中、大学,我自然非常感谢父母为我的付出,只是觉得如今这种隔阂,似乎不是最好的结局。

总结起来,对于我与父亲的关系,对我最大的影响可能有几点,一是性格上我继承了父亲不太好的脾气,而这一点,在我成家后的生活中逐渐磨平;二是父亲不善及不愿社交的态度,亦影响了我,使得我并不太乐意过于发展社会关系;三是较为松散的教育和管理,给予了我足够的自由;四则是而他对于好口碑以及安贫乐道的生活态度,使得我形成较好的善恶观,可能这使得难以有大的发展或者成就,但亦能自得其乐。

与父亲的关系多少有些遗憾,故而我期望这种隔阂,不至于在我与儿子之间传递下去,所以我最近常想,针对儿子未来的生活,我到底应当要扮演一个什么样的角色,这些年我读了一些育儿以及关于亲子关系的书籍,借夜深时静下心来写些感触的当下,写一些指导原则,供自己来日查验思考吧。

其一,我自己亦在努力扩大与别人的交流,一方面为了工作,一方面则是期望与别人的交流中,能够学习到更多不同的思维方式与新的知识,能够识别自己的不足,期望我的儿子亦能更加从容的参与到社会交往中;然而亦要注意避免让孩子产生攀比的心理,要能够以合适的心态去面对别人取得的成就,即不因之而自卑,亦不因之而不屑,知道山外有山,人外有人的道理。

其二,避免当孩子面的争吵,让孩子能够有一个比较温暖的家庭环境,体会被家人所爱,并学会爱家人;既便没控制住自已,亦要像国外电影里那样,与妻子分别与孩子谈心,谈谈父母产生争执的原因,让孩子能够理解矛盾,不至于让其胡思乱想。

其三,以身作则,对于生活要充满热爱,不将自己未完成的想法或未达成的目标,施加给孩子,比如自己热爱读书,方能让孩子有机会喜欢上读书;相信孩子在良好的自我意识的培养过程中,能够形成自己的一套判断,尊重理解他的想法。

其四,让孩子关注普世价值观的构建,避免受到社会流弊的影响,尽可能形成其自己独立的思考与判断,自己亦能多与其就某些观点进行讨论,亦便于培养父子双方的沟通习惯,从而避免我与父亲类似的结果。

此外,关于教育特别是学区房这点,我目前是不太愿意因为折腾学区房,给自己更多的压力,这与我所理解的父子关系有关,我更相信价值观以及孩子自主性的培养,同时亦相信我与孩子都是独立的个体,因而我并没有义务牺牲太多我与妻子的生活,因此,孩子的教育上来看,我会像我父亲那样,提供我力所能及的支持,而不一定要有超出我能力外,或者我需要背付很大压力的情况下支持他的情况的发生;除外,对于未来孩子的买房成家,我想我亦只会提供力所能及的支持,父子一场,我更相信前半段彼此相伴是上天给予我养育孩子的报答,至于后半场他的人生,交给他吧。

最后,这里的一些思考,在孩子大的时候,我期望和孩子重读,希望他能理解我并不认为我过于自私;当然,如果到时我与孩子难以坐下来重读这篇,亦说明我对突破我与父亲的隔阂的努力,亦算是失败了,那大抵是一种命运吧,我亦认之了。

写在第一个孩子到来之后

18年3月14日晚,在产房外听到了儿子的第一声啼哭,使我成为父亲成了实实在在的感觉,待医护人员为妻子处理完伤口之后,我得以见到安静的躺在小床里的小家伙,不禁让我感叹,这是多么神奇的一个小家伙啊。

我与妻子相识已经近10年,期间总觉得心绪未定下来,也一直想给孩子有一个较好的环境,待房子、车子安顿之后,想要孩子,却发现比想象中的困难许多,然而我觉得命运还是再一次眷顾了我,在备孕一年后,妻子成功在去年怀上孩子,于是在谨小慎微中,托妻子身体素质的福,孩子一直在母亲腹中赖到41周,在医院催产,我终于顺利见到我这稍显调皮的儿子。

打从故乡起,因为村里上高中、大学的同龄人稀少,我放假回家往往只能同孩子们玩耍,因而虽则我上面觉得未准备好,内心其实一直很期望着孩子的到来,期望能够有一个人,能够在我的看护下长大,他亦将最天真可爱的时光赐与我,如今终于成为现实,着实令我欢喜。

孩子出生至今已有八天,昨天为孩子办理了出生证明,并录入了户口,这几天一直沉浸在初为人父的喜悦之中,也体会到父母所谓一把屎一把尿的说法的真切实意,因而迟至今日,坐下来记录下这个孩子到来之后我的心情。

妻子孕晚期母亲从老家赶来照顾我们,而我工作的状态使得我有足够的时间在这期间同母亲一起生活,从妻子那里听来说母亲经常觉得我改变了,不再对故乡亲近,不再听她的话,使她多少有些伤心;孩子的出生,使得母亲变得兴奋起来,而老家人多少有些重男轻女,因而儿子使得她更为激动,每天都要同家乡的亲友们聊上很多话;孩子的出生让我有些体谅母亲,开始能够承受他一直的念叨我们的做法不对(尽管我们仍不一定会按照她的意思行事),也能默默听完她从二姨讲到姑妈家的二孩子而不打断;对于我自己的儿子,我希望自己在未来能够放手的让他去享受自己的生活,要提前准备好面对他将来找到自己爱的人,并组建自己家庭,对我们逐渐远离的必然。

对于儿子的命名,我的家庭人脾气往往较为急躁,我父亲如是,我叔叔如是,我自己亦如是,多年的教育与工作,使我脾气逐渐收敛了许多,也有了很多沉重的教训,因而我为儿子了命名为克柔,克,一义为能,克柔即为能够相对柔和的处事,不至于冲动盲目;一义为克服,克柔即为在当果断而需果断,把握机会;当然,名字只是一个寓义而已,孩子往往不能按我们预期去生活,倒不如目前就已经释然,仅作期望作能于将来理解我给他名字的意义,在遇事情时能够稍作思考。

感谢儿子的到来,今生相逢一场,我将尽自己的努力,使我们在长长时光里能够快乐的度过。

思维方式的反思

考虑到育儿、父母身体以及与朋友出来独立做点事情的需要,短暂的一年工作也接近了尾声,迟迟想动笔写点东西,直到情人节的次晚终于静得下心来, 重点谈一下自己针对思维方式的思考,以作为对这一年工作的总结,也算对杭州进思这部分做一个收尾。

我大概属于感性大于理性的人,所以这些年在工作上,尽管也能解决一些疑难的复杂问题,但仔细想来,往往灵机一动的成份居多,似乎很难形成一套行之有效的方法论,我也曾幻想过读个中文、当个作家什么的,然而计划永远追不上变化,我终究成了工程师或者码农,或者这也印证了我本身就不是很会做计划的人,因此系统的反思一下自己的思维方式,也算对三十多年的作法换一种角度去看待。

当然,触发我思考思维方式这个相对形而上的问题的由头,近期的诱因是对于佛经的研究,当月的诱因则是《降临》这部剧的观看与思考,这部剧讲了一个人借助于外星人的语言从而诱变思维方式逐渐了解到未来已经确定从而最终想通如何度过这已确定的一生的故事,抛开科幻的思路,我思考了死这个问题,死应当是我们生而为人所无法避免也即确定的事情,因而我们既便刻意忽略,或者不了知如何而死,但我们却可以想到如何在这终极必然之前,怎样回答自己所面临的问题;而佛经则更进一步,它讲轮回,讲波罗蜜,讲涅槃,而如果有轮回,怎么我们无法知道前世的记忆,我在思考这个问题时,突然明了也许修佛至涅槃的意义就在于我们解脱于轮回,届时我们以涅槃的视角回看自己各世的轮回,或许真会觉得可笑。

当然佛经出世讲的多,但我们仍入于世,涅槃不易,我们仍需面临这世上种种,那么如何用更好的思维方式,减少自己所需承受的苦痛,是很有必要的;前言我觉得自己过于感性,因而往往容易念头迁变,受其他事情的影响,因此我认为自己目前的思维方式不像决定论那样,往往很难给出一个远期的清晰的目标,而这目标由于模糊,自己又不没有练习制作计划的习惯,因而最终各种事情往往只能随意而安,不能顺势而为。

之前微博兴起时,妻子曾经在微博上得到出版社赠送的一本日本稻盛和夫的《活法》,其中提到的一个内容便是如果自己想做一件事,就会持续性的在心中构想其最终的相状,直到其越来越清晰,他认为这样就最终能将事情做成,如今回头来看,似乎他并没有直接指出当你清晰了,你就容易制定计划,配合良好的执行力,就会使得事情容易完成,而我曾经有过很多构思,工作中也负责过若干项目,却罕有能够绞尽脑汁地去将其最终状态思考清楚,这也是难怪我总觉得在困惑中一件事情就结束了,好坏也有预期,往往只能靠运气了。

因而我想,在今后与朋友一同做事的时光里,我应当首先仔细思维目标,逐渐使之清晰化,之后细心制作具体的执行计划,并关注计划的执行情况,认真对待自己的每一个想法,在死之必然到来前,努力创造一些自己能所触发的必然:)

考虑到我仍会回看自己所写的文字,因而我想当我每次看到这文字时,都去检查一下自己以当时所在的点展开,是否以清晰的计划完成了事情,并针对于未来做了清晰的计划。

再见杭州,这个提前的告别依然不同于计划。

主流公有云外网IP实现调研

因工作需要, 尝试分析主流公有云外网IP是否具有较好的隔离性,以下记录下分析结果。

主流厂商方案调研

aws

aws的实例可获得一个动态的public ip(重启后会变)以及不变的elastic ip,这两种ip官方文档上明确给出是属于1:1 NAT,在vm内部仍只能看到私有网地址,使vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性。

aws的私有网(即EC2-VPC)做了较多的限制,在FAQ中明确给出不支持组播及广播,在网络上也看到有其他基于第三方软件规避此问题的方案。

aws的网络实现经由了EC2-Classic到EC2-VPC的转变,目前主推EC2-VPC,提供虚拟子网功能。

相关资料:

microsoft azure

azure具有两种创建虚拟机模式,注册了试用账号,并结合文档,总结外网在不同模式下实现如下:

  1. Azure Resource Manager(v2版本,以资源方式管理一组vm): 默认动态外网ip,可配置成静态外网ip(需关机重开机) ;此种模式下无法动态或静态ip,在内部只能看到一个内网ip的接口。
  2. Azure Service Management(v1版本,称为classic deployment,以服务方式管理一组vm):默认无外网ip,需通过service的vip对外呈现,需要手工打开vip端口,并关联后端vm dip端口;可设置实例级别的外网ip,称为ilpip,vip本身在vm内部无网卡,ilpip也同样无网卡。

也即无论是v1/v2版本的部署模式,无论是共享的vip还是独立的public ip或ilpip,在vm内部均不可见,类似于floating ip技术,即vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性。

而对于私有网,二层做了大量的限制,比如收方向收不到不是到自己地址的报文(含L2/L3过滤),对ARP及DHCP进行了速率限制且做了spoofing处理,组网、广播、udp组播明确表明不支持(详见下附资料)。

相关资料:

google cloud engine

从GCE的官方文档来看,其实例的external public ip基于NAT实现,即vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性。

其子网仅支持IPv4单播,不支持IPv4组播及广播,而其资料上提到子网内ARP通过代理予以回复,综合来看,二层组播及广播显然不支持,且在其网络中,也不会存在未知单播的情况。

GCE的网络实现与AWS类似,经由了legacy network到subnet network的变化。

相关资料:

aliyun

根据资料及试用结果,aliyun classical network中云主机具有两个接口,外网接口(/22)直接暴露给用户,通过tcpdump可以监听到来自于其他节点及网关的ARP请求,说明未做了隔离,而VPC网络则进行了改进,云主机只有一个接口,外网采用1:1 NAT实现,在vm内部仍只能看到私有网地址,使vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性

aliyun同样经过了classic network到VPC网络的改进。

相关资料:

ucloud

根据上次在为上海客户基于ucloud临时搭建的操作经历,以及Ucloud所公开的设计细节,其EIP同样采用1:1 NAT实现,在vm内部仍只能看到私有网地址,使vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性。

相关资料:

tencent cloud

根据在腾讯云主机的实际验证,linux云主机内部仅有一个接口,具有一个/18子网的内网地址(10.X.X.X),且根据其资料所示,腾读云方外网IP同样采用1:1实现,使vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性。

腾讯云EIP 15年底发布,之前与aliyun一样,仍是实例级的额外接口配置公网IP,相当于经过了优化。

相关资料:

qingcloud

青云经历了网络1.0到网络2.0的演进,2.0支持实例直接绑公网IP,不依赖于路由器做端口转发了,网络2.0支持EIP,根据验证及资料,外网IP同样采用1:1实现,使vm只能访问内网及外网,不能向同外网子网的机器注入广播报文,具有较好的隔离安全性。

相关资料:

云服务商外网IP实现汇总

总体上前述所有公有云厂商均最终采用了EIP这样的分离方案,具有较好的隔离安全性。

应对信息泛滥

罗素以前说过有的人二十多岁就死去了,此后只不过重复以往的生活,八十岁才死去,从三十岁的角度来看,似乎我也开始走入这么一种怪圈,成为以前自己或许不会喜欢的无趣的人;而究其原因,我想信息泛滥导致失焦,而自己思考出利他度已或者以佛法来说的布施
这样的人生目标的时间还较短,也就容易被如今泛滥的信息所迷失,别人玩微博时我自己也玩微博,别人刷朋友圈时我自己也刷,今日头条好时我自己也用今日头条,但似乎除了不断地被动接受新的咨讯外,一种空虚感也随之而来;我想,是时候理一理头绪,对信息
进行一定的管控了。

从利他度已或布施的角度来看,前提是自己需要有一定的有,我想这些泛滥的信息中,的确有精华在,但如果少了有针对性的过滤,那么必然将疲于应付,最终沉淀的不多,因而能汇聚起来的有就少,这样将如何帮助他人或者布施呢?

结合自己近年来的兴趣与需求,我想除开技术上大的上我需要在如下两块信息上进行筛选,其他的信息基本上要做到忽略,以形成下意识过滤的习惯。

首先则是财经类的信息,这方面应当包括基础的知识,如宏观、微观经济的一些基础知识,国家与党的相关政策,我们生活在经济社会中,了解经济社会的运转规律,对于投资或者机会的把握,都会有很大的作用。

其次则是生特医疗类的信息,从投资上来看,我个人比较倾向于生活医疗类的公司,目前看基因新兴技术、医药新兴技术相比之前有了很大规模的发展,甚至一些癌症都可以得到有效的发展,因此,结合自己年幼时曾想学习生物的愿望,在今后的时光里,再投入一些精力去
学习,也不失为一件美好的事情。

当然,我也需要对于自己的主业技术进行一定的信息筛选,仍将关注点放在网络技术相关的深化,以及对于新兴网络技术的理解与把握中,以便指导自己将来与同道的相关朋友,做出一摊事业来。

定目标相对简单,更重要的则是执行,有时候我会想起自己在初中时早上四点超床晚上十点准时入睡的时光,那时的精力似乎是无穷尽的,且我给自己定了严格的学习计划,现在回忆起来,在信息泛滥失焦的状态下,基本上每天都是随信息漂流而活,我想,这很难使得自己
上述的目标得到执行,从佛法的角度来看,也即几无精进;因此,后续我需要针对上述的筛选出的信息类别,将对每周的时间进行初步的划分,合理的分配工作、家庭、学习的时间,以期让三十岁到四十岁这样的十年,自己在知识层面,能够得到更大的提升。

相信自己。

linux max open files限制过小导致openvswitch工作异常

上篇分析了linux内核的netdev_max_backlog默认设置导致了openvswitch在大量virtual port转发异常的问题,本篇再额外记录一处与大量virtual port相关的调优点。

自openvswitch 2.x版本开始,ovs引入了多线程的支持,在非dpdk即传统的ovs应用模式下,多线程主要用于处理内核fastpath lookup miss的流表,此过程称为upcall;并对这些流表进行统计、老化处理,此过程称为revalidate。

upcall和revalidate的线程数量计算,以openvswitch 2.3.x为例,代码中的判断是将物理核数约3/4分配给upcall,而revalidate则占1/4,这个分配直观上是合理的,毕竟upcall处理转发,要尽可能的快,处理能力也要更强。

而我们知道openvswitch datapath对用户态的每个virtual port都会在linux内核datapath中创建一个vport,内核datapath通过netlink发送消息给upcall,为了更快的处理每个vport的upcall请求,openvswitch将会为每个virtual port分配等同upcall线程数量的netlink socket,内核datapath根据flow hash将同一vport的upcall分发给不同的netlink socket,实现不同upcall线程间的并发处理,提升upcall性能。

从这里可以看出,openvswitch在优化性能方面确实做足了功夫,但这里确存在一个值得考虑的地方,我们知道linux process存在一个max open files的限制,当限制达到后,新的fd将无法被分配,导致建立文件、创建socket等需要用到fd资源的操作无法执行。

那么我们可以估计一个24 physical core的系统上,如果有2000个virtual port,openvswitch将会有多少个netlink socket,243/42000即36000,也即单音用于处理vport的netlink socket就占用了36000个fd,如果对openvswitch的max open files限制过小,很容易导致在大量virtual port下,出现各种工作异常。

对于此问题主要的优化思路如下:

  • 调整ovs-vswitchd进程的max open files limit上限,可按照前述算法估量
  • openvswitch提供了一个n-handler-threads的配置,可通过ovs-vsctl持久化配置,根据性能需求适当的减少upcall线程数量

linux内核netdev_max_backlog设置在极端情况下导致openvswitch转发不通

近期在调试问题时,遇到了一个从配置上看openvswitch无任何问题,但却导致转发不通的问题,特此记录下说,说明在openvswitch在大规模部署时,仍需要有较多调优之处。

设想如下openstack场景,大量tenant router通过linux namespace即仿真vrouter访问外网,此namespace中通过openvswitch internal port(或veth,如果不追求转发性能)连接到另一公网namespace,此时如果公网namespace中接口数量过多,比如说2000个(比如openstack中的qg-*接口),将有可能面临转发不通的情况。

从openvswitch的角度,我们知道openvswitch在内核态存在一个datapath,负责生成内核流表,实现高性能转发,对于一个拥有上千个port的ovs bridge来说,比如对应于上面的公网namespace,收到一个arp请求报文,由于是广播,报文通守openvswitch在userspace命中默认的normal流表后将推送广播至其他所有成员端口的内核流表,此后arp报文广播复制逻辑将在内核datapath模块处执行,最终命中以下内核代码:

:::c
/*
* enqueue_to_backlog is called to queue an skb to a per CPU backlog
* queue (may be a remote CPU queue).
*/
static int enqueue_to_backlog(struct sk_buff *skb, int cpu, unsigned int *qtail)
{
    struct softnet_data *sd;
    unsigned long flags;

    sd = &per_cpu(softnet_data, cpu);

    local_irq_save(flags);

    rps_lock(sd);
    if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) {
        if (skb_queue_len(&sd->input_pkt_queue)) {
enqueue:
	        __skb_queue_tail(&sd->input_pkt_queue, skb);
		     input_queue_tail_incr_save(sd, qtail);
             rps_unlock(sd);
             local_irq_restore(flags);
             return NET_RX_SUCCESS;
		 }

         /* Schedule NAPI for backlog device
          * We can use non atomic operation since we own the queue lock
          */
         if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
             if (!rps_ipi_queued(sd))
                 ____napi_schedule(sd, &sd->backlog);
         }
         goto enqueue;
    }

    sd->dropped++;
    rps_unlock(sd);

    local_irq_restore(flags);

    atomic_long_inc(&skb->dev->rx_dropped);
    kfree_skb(skb);
    return NET_RX_DROP;
}

可以注意到在上面的代码中有一个对sd->input_pkt_queue的检查过程,而sd是每个cpu核心net rx soft irq用于维护待处理报文的队列,netdev_max_backlog则是内核所提供的一个配置选项,默认为1000。

在ovs datapath复制报文的过程中,将对上千个port进行遍历处理,这个处理过程中不会进行cpu释放的操作,也即将持续调用enqueue_to_backlog(openvswitch datapath最初调用的是netif_rx,但最终调到enqueue_to_backlog),那么默认的1000限制将很快达到,假如上述的qg-*所公用的外网网关碰巧位于1000个以后,那么很显然,某个vrouter namespace发过来的ARP请求则无法被发送给公网外网网关接口,导致vrouter所对应的内网无法访问外网,如果是在生产环境中,势必影响客户业务。

对于此问题的修改,有如下两种思路:

  • 直接提高netdev_max_backlog数量,根据可能存在的接口数量合理设置
  • 通过sdn控制器配置arp或动态回复arp请求

由于目前项目中所采用的方案,我们通过方案1进行了改造,较好的解决了此问题。

观音莲与心经

佛教里讲无常与缘起,近来反复背诵心经,走路时背诵,健身时背诵,之前难以坚持的事情,因着背诵,也能坚持起来,冥冥中遇上佛经,也算缘份的例子了。

晚上与同事外出就餐,顺便想去超市买个杯子,而路上遇到售卖绿植的,心想回来路上再遇到,就买一小盆回家,装点一下自己在这陌生城市小屋的一角,然而超市里因为活动人头攒动,而也无适合的杯子,于是出来折返,所幸卖绿植的老人还在,看中一株只卖十元的看似莲花的小绿植,欣然买来,回家查阅后,原来名为“观音莲”,而心经中开首句即为“观自在菩萨”,也再算缘份的另一个例子了。

附上心经原文,此后仍将信心持诵,以期远离颠倒梦想,心无挂碍。

般若波罗蜜多心经

观自在菩萨行深般若波罗蜜多时

照见五蕴皆空度一切苦厄

舍利子

色不异空空不异色

色即是空空即是色

受想行识亦复如是

舍利子

是诸法空相不生不灭

不垢不净不增不减

是故空中无色无受想行识

无眼耳鼻舌身意无色声香味触法

无眼界乃至无意识界

无无明亦无无明尽

乃至无老死亦无老死尽

无苦集灭道无智亦无得 以无所得故

菩提萨陲依般若波罗蜜多故

心无挂碍无挂碍故 无有恐怖

远离颠倒梦想究竟涅盘

三世诸佛依般若波罗蜜多故

得阿耨多罗三藐三菩提

故知般若波罗蜜多

是大神咒是大明咒 是无上咒

是无等等咒能除一切苦 真实不虚

故说般若波罗蜜多咒

即说咒曰揭谛揭谛 波罗揭谛

波罗僧揭谛菩提娑婆诃

emacs与konsole不对付的那点事

作为Linux重度用户,折腾过各式各样的WM/DE,最终还是觉得KDE PLASMA的易用性和美观程度是最佳的,考虑到不折腾的缘故,一直使用KDE至今,虽则时有crash,但总体上不优点大于缺点,瑕不掩瑜。

在linux上,存在较多的终端仿真器,即terminal emulator,所谓的仿真器就是把图形系统即X窗口上的键盘输入,转化成virtual terminal的输入,传送给那些将标准输入关联在/dev/pts这些伪终端设备上的控制台程序,使得这些控制台程序能够像在文本模式下那样工作。

这些仿真器中就包括KDE自带的konsole。

但konsole有一个问题就是,如果我们在终端仿真器里进行emacs -nw即文本模式的emacs(图形模式下不存在下面所述问题),则ctrl+2/ctrl+2这个emacs默认用来激活mark的命令大概率不能用,当然ctrl+space也可以用,但对于中文用户而言,ctrl+space大多绑定到输入法中英文切换,相应的键不能用,还是带来了诸多不便。

由于konsole可以通过手工设置key binding,因此可以手工将ctrl+2这个键绑定到发送\0这个控制序列给终端程序,来解决此问题,但对于适应了ctrl+@这个相似功能的键位的用户来说,目前key binding无法设置,仍是非常不便。

https://bugs.kde.org/show_bug.cgi?id=341157 KDE社区有人提了类似的bug,且已经解决,但似乎只解决了西语用户所关注的ctrl+space问题,但ctrl+@这个仍未解决,我已经提供了相关的反馈,期待进一步的进展。

:::console
fortitude@fortitude:~$ konsole -version
QCoreApplication::arguments: Please instantiate the QApplication object first
Qt: 5.5.1
KDE Frameworks: 5.19.0ppp
Konsole: 15.12.2

由于C++代码不够熟悉,自己也没有过我的精力去钻研这里,就先写在这里,供遇到相似问题的朋友参考关注。

当下与将来

近来在读关于正念的一书中,因正念源自《大念处经》,其中正念的一个首要的修行法门即所谓的“四念处”,其中一处即观心无常,简单说就是要知道心念潮起潮落,因此正念的核心就是通过了知心念变幻,因此也将心所控制住,停留在某事某物,也即住于当下。

对我而言,这点让我思考了许久,近年来,生活上发生很多的变化,因此也接触到更多人与事,烦恼也随之而来,尽管我不常怀旧甚至之前提到有些担心怀旧,但对于将来的思量,无法是憧憬或者担忧,总让我似乎难以住于当下,每每做事时,往往容易心念起伏,因此当下种种,往往难以深入体味并了解,不是我过生活,而是被生活所过。

刚过去的春节里,因为妻子需要上班的缘故,我在陪伴她之余,罕见的花了时间读了一些书籍,这些与佛教多少有关的书籍带给我了一种全新的视角,相比之前看过诸多活在当下的书籍,或许是我的心绪变化,抑或是年纪增长的原因,突然觉得如今算是少有所悟的感觉,因此我也愿自己能够在此刻,以及以后的每天,能够更踏实的度过每分每秒,与生活紧密的融合。