Author Archives: admin

期权交易心得

之前因为造就了上市公司美团、以及在大肠腾讯上班的缘故,手里是有不少员工股的。但是那时候不开窍,对难以引入内地的资产也一直不算太在乎。2024秋季,NVDA突发暴跌到90几美元。当时恰好在旅游,心情不错就买了一点。但这笔操作是以美团为抵押,找券商融资而得的。2025年4月特朗普股灾,美港双跌,我的美团股票被强制平仓,我自己把剩余部分也清了,避免了进一步损失。 灾后重建阶段,我开始学习期权的知识,并尝试使用covered call加速手里剩下的NVDA股票的回升,但因为目光短浅,终止在155左右,没吃到155到180这段涨幅。 不过这段经历倒是重塑了我对证券市场的认知,从此开始,我很少交易股票,转向交易期权,并略有心得。 Long or short 如果对后面的趋势有清晰坚定的看法,可以作为买方。在AMD和OpenAI宣布合作的那天,盘前AMD暴涨。我考虑到之前已经有好几家上市公司利用和OpenAI的合作来炒作“市值管理”,觉得开盘之后应该会跌回去。虽然我错了,但是我买的PUT还是在市场情绪波动的半小时内给我带来了(扣除费用之后)3976美元的利润。 但在平常,没有什么八卦消息的时候,我只是一个卖低价PUT、卖宽跨式的卖方而已。 Call or put 除了常见的“买方风险有限、卖方风险无限”之外,期权本身的方向也是影响风险的因素。 买期权如果买反了,权利金报废是最大风险。但是还有一种情况就是方向正确,但你没能力行权而且还忘记提前平仓,冤死。我不知道这种情况会不会真的发生,希望只是停留在我的恐怖幻想中吧。在小红书上看到有人遇到了,下边评价说在最后几个小时,券商会试算行权,如果发现买方没能力行权,会强制卖出平仓,算是为买方回收一点残值吧? 卖put,要准备好被指派,自己被迫买下股票,所以提前就得做好思想建设,要选择自己喜欢的股票和能捏着鼻子忍了的价格。在期权价格上升(股票从高价跌向行权价)过程中,券商会提高保证金要求。如果补不足,可能会被强制平仓。这种交易的极端风险是股价不但跌破期权的行权价,甚至跌到0,最后你花了行权价的钱买了一堆废纸回来,虽然也挺惨,但毕竟不是无限。 卖call,我在卖宽跨式的时候遇到过涨超范围的情况。想象一下,股价有可能涨上天,而对手还是按原来约定的行权价来找你行权,这个风险理论上是无限的。 Strike price 我喜欢选择at the money附近,偏向out的那边一点点。 作为买方,我不想花钱买内在价值。如果一开始花钱买了,我没把握将来卖掉的时候这个内在价值还依然存在。换个角度,即使还存在,这部分花费也白白占用我的资金那么长时间,也不好。 作为卖方,卖出in the money的期权,无异于刀尖舔血,这说明从一开始你就处于被对方指派的价格区间了,你卖得的这部分内在价值,其实只是借来的,很可能还要还回去。 Expiration date 因为日常卖PUT,我喜欢一个月之内的,就当每月发工资。短线操作,我一般是作为买方,可以选更短期的,提高资金使用效率。 买方真的会行权吗? 之前卖PUT的日常,其实见过挺多次跌破行权价的情况。不过我大都选择死扛了,也有8月底美团财报这种极少数割肉平仓的情况。 换位思考:如果自己是买方,距离到期日还很远的情况下,提前行权虽然可以拿到内在价值,但是需要花费行权成本,且浪费了剩余的外在(时间+波动)价值,倒不如直接卖掉,我只吃差价就好了。如果临近到期,期权的流动性比较差,这时候还愿意花钱买的估计只有卖方忍痛买回去平仓了,买方可以选择卖回,也可以选择行权吧。 到底什么人会买二手期权呢?有看法相同、但是进场比上一手更晚的人;有意见相左的人;还有卖方买回去平仓的情况。 我的日常配置 所有资金全都买券商自动申赎的货币基金,赚每天几十块钱的生存费。另外卖低价PUT,依靠卖方的高胜率搏一个中等收入。有八卦新闻时,猜方向,买期权爽一把。

Posted in 默认分类 | Tagged , , | Leave a comment

在Python里抑制requests库的日志消息

我自己经常在自己的脚本开头使用logging.basicConfig(level=logging.DEBUG)初始化logging库,但是随之而来的就是requests会输出大量日志,甚至盖过了我自己的内容。所以我打算抑制requests的日志。 综合搜索的资料,和探索源代码,我发现: 所以只需要在basicConfig后面加一句 logging.getLogger(“urllib3”).setLevel(logging.WARNING) 就可以抑制这部分日志了。 另外,logging.Logger.manager.loggerDict是个好东西,可以检查当前到底存在哪些logger。通过检查loggerDict[‘urllib3.connectionpool’].propagate发现其为True,其上层也是True,因此,虽然这两层logger一个没handler,一个NullHandler,但是该logger记录的日志消息仍会逐层上传,最终被basicConfig的root logger处理。

Posted in 默认分类 | Tagged , , | Leave a comment

Tencent tlinux的$releasever比Redhat原版更反动

前几年我写过一篇批判$releasever的博客之后,现在工作中又用到了tlinux,而且发现它的$releasevar居然是2.2,是带小数的。但是看了看tlinux-release的主版本号确实是2,不带小数;它provide的centos-release的主版本号也是7,也不带小数。 折腾了一番,发现yum的config.py里,class VersionGroupConf下边的_read_yumvars(yumvars, root) 函数,直接提供了用 /etc/yum/vars/ 下边的文件来设置release属性的方法。

Posted in 默认分类 | Leave a comment

supervisor泄漏进程案例分析

起因 前几天使用 salt ‘*’ test.ping 的时候发现响应内容中有一些“某某minion was already deleted from tracker, probably a duplicate key“的提示信息。刚开始误以为是salt-key管理有问题,尝试删除再重新accept,但是依然会出错。到该minion上检查,发现上面运行了两套salt-minion*三层进程树,一共6个进程,其中一套的PPID为1,另一套的Parent是supervisord。 然后就开始研究这种情况是怎么产生的,发现有两种可能: 第一种可能 supervisor本身不被systemd监管,被SIGKILL信号杀死时,因为SIGKILL由内核直接处理,所以并没有机会关闭下属的进程,导致下属salt-minion进程树泄漏。而且不但salt-minion进程树泄漏,连同样被supervisor监管的另一个服务也一并泄漏,二者的PPID都变成了1号。 不过,如果supervisor本身被systemd监管,在其主进程被杀死时,systemd会给整个service slice cgroup里所有进程补刀,所以并不会泄漏进程;如果supervisor是被SIGTERM信号杀死,它也会给下属子进程发信号,一般也不会泄漏进程。 第二种可能 supervisor没有受到影响,正常运行;supervisor监管的salt-minion三层进程树的其中最高层进程(也就是supervisord的直属子进程)被SIGKILL信号杀死,随即,第二层进程exit(1) (不明原因,可能需要看一下salt-minion源码),导致第三层进程变成孤儿。经检查源代码的_spawn_as_child()函数,supervisor针对其监管下的每一个服务,都是采用 fork() + setpgid() +execve() 的方式来启动的,在调用setpgid()改变了process group id之后,第三层进程的孤儿收养关系就不再归属于supervisord进程,而是归属于1号进程。 随后supervisor会重启salt-minion服务,产生新的3个进程,加上之前剩下的,一共4个。 结论 考虑到观察到6个进程而不是4个,实际发生的大概是前一种情况 supervisor虽然有“能力”处理进程退出之后马上重启的工作,但是因为使用了setpgid()把下属服务与自己隔离,没使用cgroup机制把下属服务单独圈起来,又不具备1号的神圣地位,其实它并不知道到底下属了多少、哪些进程,从机制原理上就根本无法保证所有下属的孤儿进程都被其reap。还是建议不要在严肃场合使用 1号进程神圣,所有的服务进程监管工作都应该交给1号进程来处理

Posted in 默认分类 | Tagged , , | Leave a comment

Reproducible builds 果然是很重要的

去年10月17日公司出了个事故,“幸好有我“,力挽狂澜。我觉得还是把具体内容脱敏,记录一下吧,免得将来忘了。 早晨test环境某个自研产品组件build成功,但是运行时错误日志里一堆“Broker hostname updated”等等,仿佛孔乙己说的话,让人听不懂。我刚开始没把这个当回事,请Kafka管理员去检查,几个小时都没查出原因来。 到了午后,各自研组件纷纷开始更新Live环境的版本,发布的都是前几天在Test环境已经测试定稿的版本,居然也出现了类似的问题。更狠的是,回滚居然也无效! 最终查实,有不少自研产品的build脚本里,使用wget下载master版本的librdkafka然后编译使用。而librdkafka恰在前一天(10月16日)被提交了很多修改。当时紧急解决的方法是使用librdkafka的上一个被明确标记了tag的v1.2.1版本代替master版本。 事后复盘处理过程,觉得当时的处理过程也有问题:所谓回滚其实并非直接使用旧版本编译出来的docker image,而是重新build了旧版本,而且编译时指定的是branch名字,而不是精确的commit id,这样的问题是无论外部代码(master版本的librdkafka)还是自研代码(注意branch有可能move forward哦),都不一定是原来的版本,这个行为其实并不能称作回滚,而是带有主观回滚意向的一次重新构建。 在这种情况下,讨论自研代码和外部库的质量,都是缺乏讨论基础的。这种讨论应该基于确定的版本。 说实话,我以前对于传说中的“Google把自研代码、外部库和工具链”全都纳入版本化管理,是有点嗤之以鼻的。当时我觉得这种做法,在处理多个自研软件的外部依赖相互冲突时,会带来额外的行政成本,在国内企业的KPI风格下,会导致相互推诿。经过这次力挽狂澜之后,觉得相互推诿其实是KPI至上主义导致的,而不是把所有代码都管起来导致的;不过是否真的要管这么大范围,尚有待商榷。

Posted in 默认分类 | Tagged , | Leave a comment

广东电信IPTV 华为EC6108v9c 的使用经验

前天(3月9日)终于拨乱反正把还剩下近一个月但网络“几乎能通”的垃圾天威视讯给弃用了,换了正经运营商中国电信广东深圳公司的上网服务,并且开通了IPTV。因为今年租的房子是正经居民房,就遭遇到了经典的“弱电箱距离电视机太远”的问题。 本来IPTV盒子可以支持Wi-Fi的,但它很快就强制自动升级,把本来支持的Wi-Fi联网方式给去掉了。 网上找到一个固件,保留了“粤TV”app,并且重新开启了Wi-Fi功能,且开放安装外来安卓软件。刷新说明里写着放在FAT32的U盘里,文件名叫update.zip,开盒子之后在bootloader过程中按左右键进入recovery,然后apply update from external storage即可。但我照做的时候,recovery提示没有找到升级包。 再搜,发现还有一个所谓按待机键进入recovery的,但我按不出来。妄want图to 拆盒子短接跳线,还从盒子里掉出一个虫子尸体,算是给祖师爷致敬了。 我想了想,可能这俩方法是不同时期的。于是我在当前recovery里apply update from backup刷回旧版了,(中间还操作了一步wipe dalvik cache,清除新版的升级包,避免旧版开机之强制刷新新版)然后再按待机键进入旧版recovery,刷了这个update.zip进去。 再说网络。官版固件有线网接入,目前是IPoE(其实就是特殊的DHCP)或者PPPoE认证的;直接DHCP无法获得IP地址。我改了一下光猫,把原来的VLAN 45上联业务,从PPPoE桥接模式(即:客户端自己PPPoE)改为PPPoE路由模式,并开放下行DHCP服务,再关联到SSID1上,用IPTV盒子去连这个Wi-Fi即可。理想情况下应该开多个SSID,但我这个光猫似乎不支持多个,所以这个2.4G only的Wi-Fi就给IPTV用,而自家其他通用设备使用的Wi-Fi,用了额外一个5GHz路由器从有线网口转出来。

Posted in 默认分类 | Tagged , | 1 Comment

经典错误——使用/etc/security/limits.conf配置文件 和 ulimit -n命令

很多以讹传讹的半桶水文章,都教人修改/etc/security/limits.conf配置文件来放宽“打开的文件数量”限制,如果可以再多一滴水的话,还会加一句“重启后生效”。 其实,使用这个配置文件,和使用ulimit -n命令一样,属于很经典的错误。 设置或放宽“打开的文件数量“限制,其本质是调用了setrlimit()函数,设置了RLIMIT_NOFILE资源。在有特权的程序中调用这个函数,可以提高上限(放宽限制),而普通权限的程序只能自己勒死自己和新生的子进程。 而/etc/security/limits.conf这个配置文件是怎么生效的呢?其实用dpkg -S或rpm -qf查一下就很容易知道,这个文件是pam_limits.so的配置文件,而pam_limits.so是在/etc/pam.d/中被login和sshd等多个配置文件声明将要被调用的。 系统开机的时候,1号进程init“自然而然”是root身份运行,其下属的getty/login和sshd进程,也都是root身份。这些程序都可以随意调用setrlimit。当身份认证(部分工作由PAM来做,所以可以读shadow文件)完成之后,login和sshd的子进程会为用户准备好session(网络登录调用pam_mkhomdir建设HOME目录、pam_limits模块设置rlimit、pam_env模块读取/etc/environment设置环境变量,甚至显示motd这种功能也是PAM模块实现的)并将自己降级到登录的用户身份,再启动一个shell给用户使用。 /etc/security/limits.conf 只对“调用过pam_limits.so“的登录过程有效。但并不是所有场景都经过这个过程的。而ulimit命令呢,它本身只是shell是一个内部命令而已,只对“该shell进程”及随后新产生的子进程有效。 但是需要放宽rlimit的程序,往往不是在shell中由用户手工运行的程序,而是提供大规模网络服务的后台进程。它们所需的rlimit,要在init脚本、service unit文件中设置;支持从root身份启动的服务,一般都有自行设置rlimit的能力。 如果不理解上面的内容,就容易引发一些莫名其妙的故障。比如之前我在FreeWheel工作的时候,前辈为后台服务写的的init脚本里没有调用ulimit -n命令,而在root用户的~/.bash_profile里有这个命令。造成的后果,就是开机自动启动该服务的时候,启动的是一个打开文件数量受限,以至于无法保持很多socket的网络服务,而当运维人员登录进去手工重启服务之后,又莫名其妙变好了,以至于没法检查这个故障到底是怎么发生的。

Posted in 默认分类 | Tagged , | Leave a comment

从神州租车更改手机号,看数据库关系设计

我搬来深圳之后,就换了手机号。为了应对一些出行需求,我就打算从神州租车租辆车来用。用新手机号注册之后提交身份证,结果提示该身份证已经被占用。联系客服,说是一个135的北京手机号占住了,还提示我以前在嘉峪关租过车,客服可以帮忙把这个135的登录手机号改成我的新手机号。我检查了一下通讯录,认识,跟他打了招呼之后就同意了客服的做法。 但其实,这个事情暴露了神州租车方面的数据库强关系设计,与实际业务冲突的问题。我和这位朋友之前两次一起租车,因为他当时还不会开车,所以登记了我的证件,但后续他仍有使用此注册名租车的业务需求啊。身份信息应该关联在“一次租车行为”而不是关联在“一个注册用户”身上,也就是每次发生租车行为的时候,把身份信息从注册信息复制过来,或者由门店人工录入身份信息到“一次租车行为”的数据库记录里。 这不是关系范式之间来回迁移,而是正确与错误的区别。 联想到以前在美团我们自制的一个用作软件版本发布的小系统,旧的设计并没有把“发布功能相关设置”关联到“一次发布行为”,而是关联到“要发布的应用”,以至于检查每一次发布行为到底为啥不正确的时候,根本不敢确定设置页面里看到的设置就是当时生效的设置。 这个错误在后面重构中被推翻了。

Posted in 默认分类 | 1 Comment

在嵌入式开发板上使用蓝牙耳机

简单记录一下: 安装 bluez pulseaudio-module-bluetooth 软件包 pulseaudio是用户级后台服务,视情况可能需要手工-D启动之 bluetoothctl命令进入交互式界面,先scan on 等看到蓝牙耳机之后,pair和connect到蓝牙耳机的MAC地址,看到连接成功之后scan off并退出bluetoothctl pactl list sinks查看设备,看看它支持哪些profile,有可能需要通过pactl set-card-profile将其切换到a2dp aplay -Dpulse 指定pulse虚拟设备播放文件 还没搞定录音。看起来话务耳机在handfree等模式似乎需要特殊步骤激活录音模式?

Posted in 默认分类 | Tagged , | Comments Off on 在嵌入式开发板上使用蓝牙耳机

placeholder 2016年10月欧洲之行

6月办签证,因为英国当时在闹脱欧,签证审批速度大大降低,耽误了办理申根,连瑞航机票都耽误了。所以决定10月辞职后再去。 临辞职,拿了在职证明去办法国申根,但忘记提前买好英法之间欧洲之星国际列车的票,后来多花了好多钱 走之前没查时区,10天行程调了5次时区,痛不欲生 不喜欢法国的繁复建筑物,但很爱她的博物馆们;塞纳河左岸下午照不到太阳,是酸臭文人吹捧起来的地方。 英国很有沉淀感 国际标准时间曾经是巴黎天文台,但英国人解决精度问题之后,标准时间变成了“比我巴黎时间晚9分9秒的‘那个时间’”

Posted in 默认分类 | Tagged , , | Leave a comment