pidstat --human -r -p
间隔20秒种,输出指定进程ID的CPU 内存使用情况,重复执行128次
非常简易的检测进程内容使用情况的命令
发现了一个Go小工具的内存泄漏.
有人听过 老歌 《十不该》吗？
这首歌其实是一首别样的情歌，
“最不该 我还深深把你来爱
爱情路上有苦啊 也有甜呐
盼望你早日回到我 身边来”
一个“最”字，就把前面所有的不该的份量都压过去了，于无声处听惊雷，不太经意间表达出来的深爱
前面懊悔的不该，都是已经发生过的事情，但最后这一项，确实等下我还爱着你，虽然也许从外部的压力，世俗的价值观，或者不能在一起的客观条件上 我不应该再爱你了，但我还是“深深把你来爱”，还盼望你回来，这也否定了前面所说的“绝路“，还有希望回到身边来，有爱，就不是绝路。
小时候听不懂，长大后听懂了才知道是一首别样的“撒狗粮”的歌，难怪当年传唱一时
写于上班路上的电车时间
见自己 认识人类 之 对味道的记忆
昨天晚上去吃了人形町麻辣烫，加了羊肉，到后来往汤里加胡椒粉调料之后，一入口一下子想起来了之前在深圳时吃过的 贵州 虾子镇羊肉粉，应该是味道比较像吧。
离开广东之后，几乎没有再想起来过这种美食和这个地名，但却在不经意间吃到类似味道的食物之后回忆起来了，科技园的那家店：布局，招牌，一次典型午餐的流程……
其实虾子镇这个地名也是招牌中的店名我已经想不起来了，还好生活在移动互联网时代，查一下之后就确认了……
其实协议中也是有删除功能的，只不过分布式的特性天然难以做到安全 可靠 完整的删除。
就像传统的产品中，用户也可以通过截屏，复制粘贴等方式来 “反删除”，只不过截屏和复制粘贴后的内容没有技术上的证据来证实来源，nostr则因为有签名而不可否认。 （泄露私钥的情况除外）
现在还不太可能，主要是普通电脑没有外部可以轻松访问的公网IP地址，后续随着生态的繁荣和软件的发展，结合其他网络工具是可以的，不过优势和优先级都不是很大。
docker run --rm -it -v $PWD/migrations:/code/migrations -v $PWD/knexfile.js:/code/knexfile.js node:18-alpine3.16 sh
修改nostream的db配置,使之连接到aws rds, 使用环境变量 NODE_TLS_REJECT_UNAUTHORIZED=0 使之连接成功. 推测rds使用了自签名证书
现在这个各个社交平台互不连通的模型下, 如果一个人想把自己的内容发布给更多用户,就只能在各个平台上注册账号,发布内容,运营成本上就增加了不少: 各个平台分别发布内容.
各个社交平台如果都是用同一套user id,也就是nostr这样的公钥, 然后遵守同一个开放协议,内容上也可以尽可能多地共有,比如发一条短文动态,可以同时发布到推特 微博 朋友圈.
这是我对于社交软件未来的一个期待 nostr:note1as3nvmfm7lz4kwpkxd8cnle4zwtdv9kppvug0gh32xukvtxdy6aq45l5s4
随着生态的持续繁荣，人们可以在 #nostr #诺斯特 上面做的事情也越来越多，
人群的多样性丰富性也越来越高：
基于兴趣爱好的小圈子社区
熟人朋友的封闭半封闭社区
推特微博红迪贴吧开放广场
可以通过第三方机构实名认证，身份，满足大v或者政府，大企业的可信权威身份认证
可以轻松创建极其难以追踪真实身份的匿名小号（nostr天然就有的特性，前置VPN和tor后可以做到除了内容和内容元信息（发帖时间，间隔……）之外没有任何线索可以最终到真实身份）
用户可以自由选择一个身份穿梭在不同类型的社区和应用，
也可以自由选择一个“马甲”一个社区/应用 nostr:note1yw9psqsyzw7d7vr9mpgvwp9zxc7ajzmlzrq6gtj404yv4cfyts0qv46y2f
nostr狂想曲 #nostr
将来的某一天，基于nostr协议，人们开发了类似 天涯论坛，百度贴吧，知乎问答社区，新浪微博，小红书图文社区，视频直播社区……
与上面报菜名般的应用不同的是，在上述所有产品中，所有的用户身份和关系还有数据，都是可以互通的，没有一家公司或者开源组织拥有这些产品或用户数据，但可以有提供各种优质服务的商业服务提供商，比如存储，内容分析与推荐，社区商业内容营销，付费高质量客户端……
用户的身份和数据永远属于自己，由开放协议和用密码学算法来保护，没有软件开发商运营服务商锁定，
没有一个唯一的权威中心来审查用户内容，但可以由自下而上的自发秩序来规范社区的内容
……
很有意思, 可以翻译成多种语言, #grownostr 让大家都知道 nostr:note1rl5ewewu2fnvgk3xpg9tjzg8e68lvy2xuc78wuka2xwzcjaj05csn9lsv2
nostr 客户端有哪些方面可以增强的?
我觉得中继(relay)管理也可以算作一个:
当前许多客户端都是指定一组relay去连接使用,而实际上nostr协议中许多位置都带有relay地址, 客户端如果合理使用这些relay信息,也能通过动态检测到的relay发现更多的用户和内容.
发布策略上也可以更灵活,而不只是发布到固定的几个relay,这样还能增加对屏蔽和relay失效的抵抗.
客户端还可以增加 自家的event管理功能, 把自己的所有内容从relay备份到本地,发布到另外的一组relay,这些功能客户端可以完善好,便于用户使用.
还有多媒体文件托管功能,这块也有很多优化空间.
备选链接放到tags,防止content中的URL失效;
增加hash字段,可以识别出链接中的内容是否被篡改…
ec2 手动运维日志:
服务器突然不可访问,登陆aws后台发现status check 1/2 failed, 重启后开始手动恢复服务.
发现/data盘还没有自动挂载,编辑了/etc/fstab, 启动静态文件托管,和relay服务.
中间顺便还升级了一下系统,检查磁盘空间...
配置了s3的静态网站托管.
小结:
1. 只提供http服务. 如果使用https,还需要再配合CloudFront使用
2. 需要打开bucket的public access
3. 加上自定义的dns cname,就是一个简单的网站了
#nostr #relaytotwitter
广场上看到有人说“剧荒”, 竟有一种悲意从心中升起: 不同的人的生活怎么就差别这么大呢?
有人可以“剧荒”, 我却极少能闲下来看剧, 上一次看剧还是21年的《山河令》了, 想一想自己,长期以来的心境都是: 很忙,没时间,以后有时间了做什么什么… 原因在哪里?我的时间都去哪了?我的人生是谁在主宰? 感觉好像不是我… Via #freefrom
早上碎片时间看了一点 https://youtu.be/aA-jiiepOrE ，想到了一个问题：
当前nostr text note中的图片 视频链接会被client解析，但如果图片链接失效，或者被 #gfw等原因限制访问，图片视频等附加的多媒体内容就不可访问了
我想到了一个提议：
协议和client可以在tags中添加media的备用链接，这样支持的client可以从多个来源尝试加载media附件
不知这条是否已有人讨论过，是否可以提交到nip中
#relaytotwitter 测试to twitter的bot thanks @pleblira
#nostr 社区和生态, 在3个月后,1年后,3年后... 会是什么样的?
用户群增长到多少?