河豚的 Yggdrasil 公共节点上线了

tcp://ygg.puffer.blog:1883
tls://ygg.puffer.blog:1884

https://publicpeers.neilalexander.dev/#:~:text=japan

虽然在这儿说也没啥用吧，但其实90%的河南村镇银行小储户根本没必要去河南维权，就在当地银保监信访登记一下，拿到受理回执等消息就行，金额小十来万这种的话，等当地银保监给河南发个函问题就解决了
特别着急用钱的话还可以找当地银保监协商，当地银保监给你的解决方案一般是会给你发放一笔与存款等值的贷款，先让你过渡一下
但是你如果不在当地，而是远赴河南维权的话那是100%不会成功的，因为河南不可能给你单独开这个口子，因为一旦给你发了钱，那现在滞留河南的大量维权储户就全都得解决才行，这是根本不现实的
总结一下就是，虽然在天朝这个魔幻的地方，按流程维权不一定能解决问题，但是完全不按流程维权那更不可能解决问题

两高、公安部、移民管理局6月29日印发《关于依法惩治妨害国（边）境管理违法犯罪的意见》规定：
组织他人通过虚构事实隐瞒真相等方式掩盖非法出入境目的、骗取核准出入境者，组织依法限定在边境地区停留活动的人员非法进入非边境地区者，认定为组织他人偷越国境罪。
明知他人实施骗取出境证件犯罪，提供虚假证明、邀请函件以及面签培训等帮助者，以骗取出境证件罪的共同犯罪论处。
（国家移民管理局）

回国限制在放松（14+7隔离变成7+3，回国航班数量增加）
出国限制在收紧（恶意出境追究刑责，出入境证件从严审批，海关盘问劝返）

深夜吐槽一下，Steam绑定手机号居然不支持香港新的号段，真是服了

看了眼上海公安泄露数据放出来的sample，其中快递，外卖数据全都收录并且自动关联用户身份了，
所以我这个电报身份估计应该也已经进公安数据库了，当然这一切都源于之前某个傻逼网友发快递的时候居然姓名填了我的电报用户名，wdnmd

【Telegram 魔法】给信息自定义预览
https://telegra.ph/Telegram-%E9%AD%94%E6%B3%95%E7%BB%99%E4%BF%A1%E6%81%AF%E8%87%AA%E5%AE%9A%E4%B9%89%E9%A2%84%E8%A7%88-10-14

Tor Long-Lived ports

21, 22, 706, 1863, 5050, 5190, 5222, 5223, 6523, 6667, 6697, 8300

https://2019.www.torproject.org/docs/tor-manual.html.en#LongLivedPorts

焯，沈逸老师也是老二刺螈了

【[新v]乐子人速进，元气(沙雕)歌杂(吃小孩)大小姐-bilibili直播】https://live.bilibili.com/10801407

看起来B站直播里的弹幕游戏分区是真的赚钱
想搭建一个玩玩了

Win7又续了三年命，现在延长支持到2026年了，成功熬死所有消费者版Win10

https://news.1rj.ru/str/winaero/6058

“更好日子还在后头呢”

河豚的一些 docker-compose.yml 常用配置

version: "2.4"
# 是的，3.X版本docker-compose其实是阉割版，功能比2.X少了一大堆
# Docker为了让你用他的集群服务真的是不择手段

restart: always
# 容器自动启动

network_mode: bridge
# 停止自动新建网桥，使用Docker的默认网桥

mem_limit: 64M
memswap_limit: 64M
# 限制容器内存使用量

read_only: true
# 容器根目录只读挂载，增加安全性

tmpfs:
- /tmp
# 适用于在根目录只读挂载后，解决非持久化数据的读写需求

ipc: none
# 不自动挂载 /dev/shm，增加安全性

logging:
driver: "none"
# 停止记录日志，提升容器I/O性能

今日老黄历：
宜：清理微信好友
忌：炒股

国内普通人买纸黄金的最后一丝希望，工商银行，也倒下了，从此之后普通人再也没有合规购买纸黄金的渠道了

##Orz 十周年纪念日（不）快乐。

今日小发现，Python 的 strftime() 支持61秒

%S        Second as a decimal number [00,61].

https://docs.python.org/3/library/time.html#time.strftime

下面的注释就很有意思 for historical reasons

The range really is 0 to 61; value 60 is valid in timestamps representing leap seconds and value 61 is supported for historical reasons.

虽然是错了，但是也不是啥大问题就先不改了

然后就在issue里翻出了这个历史原因，开发者开始甩锅：“是97版的Posix标准先写错的，Python只是受害者！”

https://bugs.python.org/issue2568

The 'double leap second' issue has been around a long time and is part
of the Posix standard (for some background see
http://www.ucolick.org/~sla/leapsecs/onlinebib.html, specifically the
section named 'Unix system time and the POSIX standard').

接着Posix标准说冤枉啊，是C89标准先写错的，我也是受害者啊：

之后直接开喷了

The "double leap second" is complete nonsense. It never existed outside the 
ANSI C standard and never will. It was introduced by the ANSI C 89 committee 
to document its problems understanding UTC issues. Someone heard that there 
are two prefered dates for leap seconds per year and this got munched up to 
the false rumour that UTC days can be up to 86402 seconds long. The 
definition of UTC, which requires that |UTC-UT1| < 0.9 s all the time, 
obviously makes double leap seconds mathematically impossible.

最后，其实新的C99标准和04版Posix标准中都已经把时间范围从[0,61]修正为了[0,60]，
但是这些被坑的编程语言却没有跟着修正，只能作为historical reasons保留了