@ZhLTE 我没打过针 不知道 但是我四个月减了 20 多斤（ 106kg 到 94kg ）

@anson264556364 有的 我是朋友给我发的一个香港的…但是国内也获批了

之前的讨论在这里，可以看相关回复
https://www.v2ex.com/t/1015678

我现在是停药了的，肯定是反弹了，懒得称了 😂

停药是因为太贵了，香港黑市进来的，30 片 2700 块一个月，加上春节期间口服药是被获批了的，我一直在等上市……可是现在都还买不到🤦
我吃的是印度走私来的（应该是吧），毕竟药盒上写了印度卢比的价格，贵了好几倍…虽然承受得起但实在不划算。
所以打算等国内能买到的时候，再从头吃

感兴趣的也可以去美团上下单，它会在线给你出诊、出处方单……也可能会搜到“日本的片剂”（这个不需要处方单），日本的我没吃过不知道是不是真的。

我是片剂，每天一颗

可乐什么的随便喝，照样减重

副作用是打乱了饮食规律，正常饭点儿不会饿，然后又会在半夜饿…吃了不少烧烤…🤦

女性论坛：重庆购物狂 cqmmgo

感受到了 LZ 的着急，摸摸头。。。但有时候生活就 tmd 是这个样子…

我有个朋友，腾讯的，老早前的事儿了：
可能是她 iPhone 上装了 TestFlight ，被微信扫出来了，微信就提示安装 beta 版微信
她么也是好心，想帮着测一测，抓抓 bug 啥的…

结果刚装上就闪退，怎么折腾都闪退。也是没备份过，结果就是十几年的微信聊天记录直接全没了…

Software has bugs, always create your own backups, 这样你的生活才不会 sucks.

云上的环境吗？试试开 VPC Flow Log 流日志

阿里云的： https://www.alibabacloud.com/help/zh/vpc/user-guide/overview-13
AWS 的： https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-traffic-flows/

@povsister 然后你又打错了…p 后面漏了个 l

高性能模式可以，但要求 Apple Silicon ，以及只有在内网用才行。。。

需要带宽够，以及发起端的 UDP 5900~5902 是通的

可以了解一下逆向、破解，巩固下底层基础

HHKB 用了 13 年了，本来也无欲无求……
但前两周看到了 Keyball 61/44/39 ，直接种草下单了…

分别买了 61 和 44 ，组装好了，把玩一下。。。

手写过，但不是定时检查，而是通过 gitlab cicd pipeline ，最后部署阶段的时候做：

两组服务，A&B 交替启动：

新版本来了的时候判断一下，比如当前 B 在运行中，就修改 A 的 tag ，准备启动 A 。
A 启动成功了去修改 nginx proxy_pass 的配置，test OK 后 nginx reload ，再等待 B 的端口没有连接后杀掉它。

其实 qwerty 键盘的背后的赞助商是 PornHub

因为「空姐」的单词 stewardesses 可以单独用左手在 qwerty 键盘上打出来（你也可以试试），这样你在 PornHub 上，左手打字、右手就可以开始干活儿了

看你想干啥……本地开发随便写写，线上这么写有问题。。。

★ Allow-Origin 赋值成 $http_origin ，就等价于 allow *
　 origin 是请求时携带的网页 URL ，现在这么配，是来者不拒的意思，或者像 #12 那样提前判断下。

★ 应该仅在必要的 Method & URL 上加 header 字段，而不是直接写在 server {…} 或 location / {…} 这样粗暴。
　我们为了减少静态资源的 overhead 流量会给 CDN 单独买个域名，就是为了在请求和响应期间减少 header 所携带的内容。CORS 这种功能性的 header 应该仅在必要时出现。

★ 后端框架也需要注意的一点
　我遇到过一个网站，虽然有 CORS 策略阻止我干坏事儿，但是他们 jsonp 是开着的。我觉得是后端框架的锅，默认开启了 jsonp 的特性，URL 追加个 ?callback=jsonp_xxxx 还是能从前端跨域拿到对方的数据…

我自己剃头，有款推子用得很舒服，前两个月发现京东买不到了，天猫也没有，但淘宝有卖的，但是是英规插头。想必以后是买不到了吧…然后我就买了俩

刚刚看了一眼，我买的店铺也给下架了

@privil @kinkin666 我并没有表述 AWS 的服务器没有用 ECC 内存

可能是我们的机器实在是太多了，所以遇到了非常极端的小概率问题的可能性也是有的吧…

因为在这个事儿之前，我刚读过 Dropbox 关于它客户端 bitflip 相关问题的文章，因为 Dropbox 的用户体量就非常巨大，他们的客户端上的 bitflip 很常见…（文章里是这么说的）

----
当然我们遇到的这个问题并没有定论，而且 AWS 的服务器不可能不用 ECC 内存，毕竟那么大的体量，出了问题他们担待不起。

我对于问题原因的判断单纯因为两端的日志比对，字符 3 （ 0x33 ） 变成了字符 #（ 0x23 ），就一个 bit 之差…

Surge 有机制，可以通过匹配热点名字 SSID ，然后用直连 Direct 的规则就行了。具体自己看下文档

我们 AWS 生产环境遇到过一次（疑似），而且是灾难级别的

程序端打印的日志跟 slow query 里的语句差了一个 bit ，这个翻转了的 bit 把 where 给注释掉了，然后这条 update 语句更新了全表…

送个金子做的小蛋糕：宝宝零岁纪念