九维我操你爹
https://aws.amazon.com/cn/blogs/security/simplified-developer-access-to-aws-with-aws-login/
他们终于想起来做这个功能了……每次一听到要在 aws 上干点什么事都想立马打退堂鼓
实在是太绕了。不妨设想一下假设同事把 aws 账号和密码发给你，你能在 5 分钟内登录完 aws-cli 吗？至少我不行（
他们终于想起来做这个功能了……每次一听到要在 aws 上干点什么事都想立马打退堂鼓
实在是太绕了。不妨设想一下假设同事把 aws 账号和密码发给你，你能在 5 分钟内登录完 aws-cli 吗？至少我不行（
Amazon
Simplified developer access to AWS with ‘aws login’ | Amazon Web Services
Getting credentials for local development with AWS is now simpler and more secure. A new AWS Command Line Interface (AWS CLI) command, aws login, lets you start building immediately after signing up for AWS without creating and managing long-term access keys.…
昨晚上在淘宝下单了轻洗到家的洗鞋服务。这个好像要他们客服处理订单以后才能预约上门取件的时间。所以现在单纯只是付了钱，连服务资格都还没生效，然后早上就接到了下面这通电话：
（陌生来电）：你好，轻洗到家的，有需要保洁服务的吗？
：没有没有没有，我没有说想收到营销电话啊
（陌生来电）：……
（机械）：请您对我本次的服务做出评价，非常满意请按1……不满意请按3
：3
（机械）：请您对我本次的服务做出评价，非常满意请按1……不满意请按3
：3
（机械）：请您对我本次的服务做出评价，非常满意请按1……不满意请按3
：3
（电话被挂断了）
这还没开始服务就把好感败光了啊？不仅骚扰用户，简直就是不要脸啊😅
（陌生来电）：你好，轻洗到家的，有需要保洁服务的吗？
：没有没有没有，我没有说想收到营销电话啊
（陌生来电）：……
（机械）：请您对我本次的服务做出评价，非常满意请按1……不满意请按3
：3
（机械）：请您对我本次的服务做出评价，非常满意请按1……不满意请按3
：3
（机械）：请您对我本次的服务做出评价，非常满意请按1……不满意请按3
：3
（电话被挂断了）
这还没开始服务就把好感败光了啊？不仅骚扰用户，简直就是不要脸啊😅
https://fixupx.com/albert_kokinji/status/1990953645119320232
FixupX
hoshiboo (@Albert_kokinji)
日本人は自分達がした事に関しては「非礼」とは考えず、他者が同様の事をして来た時には「非礼だ」と騒ぎ立てる。自分勝手で幼稚。こうはなりたくない。
Quoting nageune31 (@nageune31)
でも、日本だって同じようなことをしてきた。安倍が韓国に対して言いがかりをつけて半導体輸出規制をしたとき。日本に来た韓国側の交渉者を、日本は質素な会議室と服装で応対した。当時、韓国人はニュースを見て怒っていた。今も覚えている。
Quoting nageune31 (@nageune31)
でも、日本だって同じようなことをしてきた。安倍が韓国に対して言いがかりをつけて半導体輸出規制をしたとき。日本に来た韓国側の交渉者を、日本は質素な会議室と服装で応対した。当時、韓国人はニュースを見て怒っていた。今も覚えている。
https://fixupx.com/KNHjyohokyoku/status/1990574940849082736
全く仰る通りです
ここに至るまでの、高市総理の長年のネトウヨ迎合発言、へずま氏のような排外煽動系インフルエンサーによる“中国人観光客への嫌がらせ”や“出ていけ”というヘイト言説への同調、そうした排外的な姿勢の積み重ねが背景にある。
全く仰る通りです
梓瑶在上周分享的 rust x SIGPIPE 的 issue 很有意思： https://t.me/ziyao233channel/3879
issue: https://github.com/rust-lang/rust/issues/62569
这里涉及了命令行软件和服务端软件的一些默认实践，我翻了一下几年前的笔记恢复了记忆。
服务端软件（socket 网络编程）通过 write (writev/sendto/sendmsg/sendmmsg) syscall 发送 tcp 流量，这里有个几乎无法避免的情况是，进程正在 write(sock)，对端的 tcp reset 飞过来了，内核会抛出 SIGPIPE 信号通知进程这个 socket 不可写。
这个行为对于服务端软件是完全有害且多余。
- 说有害是因为 SIGPIPE 信号的默认处理是崩掉进程，然而 socket 收到 tcp reset 本来就是预期之内的情况，所以必须忽视 SIGPIPE。
- 说多余是因为忽视 SIGPIPE 之后，write syscall 返回 EPIPE 错误码，进程不可能错过这个报错，“正在给一个已经收到 tcp reset 的 socket 写数据” 的这个信息量没有得到任何丢失，反而由于同步化的 EPIPE 返回简化了信号处理（否则 pthread_sigmask + sigtimedwait 是有多想不开）
因此写网络程序直接 ignore SIGPIPE 百利无害，此事在 Unix Network Programming 中亦有记载，UNP 还是太权威了[1]
既然如此那为何要设计 SIGPIPE，全部用 EPIPE 错误码不就好了？答：unix 历史遗留 https://stackoverflow.com/questions/8369506/why-does-sigpipe-exist
这里带出了 SIGPIPE 的（几乎唯一？）需要抛出的场景，考虑命令行：
管道下游的 head -1 读到第一个 echo 1 的输出就退出进程了，关闭了 pipe_r，导致 pipe_w 不可写，上游的 echo 2 再 write(pipe_w) 的时候会遭遇 SIGPIPE 中止进程。
古典的 unix 命令行要求此时在 retval 里反映信号，141 == 128 + SIGPIPE(13)。
这个要求导致我们不能无脑 ignore SIGPIPE，否则看起来有点业余。（当然可以在命令行软件里看到 EPIPE 再手动 raise SIGPIPE / return 141
）
所以 rust 目前默认 ignore SIGPIPE 就常常会使 rust 编写的命令行工具在本应该返回 141 return code 时候返回 0（again，这是可以仔细处理好的：在 EPIPE 时 return 141）
如果去看下 go 是怎么处理的，会发现它（貌似）更智慧一点：
https://pkg.go.dev/os/signal#hdr-SIGPIPE
更能照顾到绝大多数场景。
不过在 gdb 调试 go 进程时，由于 SIGPIPE 没有被 ignore，会触发 ptrace 的 signal-delivery-stop，很烦，但都是非常细微的 debugger 细节，正常人类不用管。。。
[1] https://flylib.com/books/en/3.225.1.83/1/
（再不分享点技术内容就要沦陷为飞升为男同
交友频道了）
issue: https://github.com/rust-lang/rust/issues/62569
这里涉及了命令行软件和服务端软件的一些默认实践，我翻了一下几年前的笔记恢复了记忆。
服务端软件（socket 网络编程）通过 write (writev/sendto/sendmsg/sendmmsg) syscall 发送 tcp 流量，这里有个几乎无法避免的情况是，进程正在 write(sock)，对端的 tcp reset 飞过来了，内核会抛出 SIGPIPE 信号通知进程这个 socket 不可写。
这个行为对于服务端软件是完全有害且多余。
- 说有害是因为 SIGPIPE 信号的默认处理是崩掉进程，然而 socket 收到 tcp reset 本来就是预期之内的情况，所以必须忽视 SIGPIPE。
- 说多余是因为忽视 SIGPIPE 之后，write syscall 返回 EPIPE 错误码，进程不可能错过这个报错，“正在给一个已经收到 tcp reset 的 socket 写数据” 的这个信息量没有得到任何丢失，反而由于同步化的 EPIPE 返回简化了信号处理（否则 pthread_sigmask + sigtimedwait 是有多想不开）
因此写网络程序直接 ignore SIGPIPE 百利无害，此事在 Unix Network Programming 中亦有记载，UNP 还是太权威了[1]
既然如此那为何要设计 SIGPIPE，全部用 EPIPE 错误码不就好了？答：unix 历史遗留 https://stackoverflow.com/questions/8369506/why-does-sigpipe-exist
这里带出了 SIGPIPE 的（几乎唯一？）需要抛出的场景，考虑命令行：
$ (echo 1; sleep 1; echo 2) | head -1
1
~ $ echo "${PIPESTATUS[@]}"
141 0管道下游的 head -1 读到第一个 echo 1 的输出就退出进程了，关闭了 pipe_r，导致 pipe_w 不可写，上游的 echo 2 再 write(pipe_w) 的时候会遭遇 SIGPIPE 中止进程。
古典的 unix 命令行要求此时在 retval 里反映信号，141 == 128 + SIGPIPE(13)。
这个要求导致我们不能无脑 ignore SIGPIPE，否则看起来有点业余。（当然可以在命令行软件里看到 EPIPE 再手动 raise SIGPIPE / return 141
）所以 rust 目前默认 ignore SIGPIPE 就常常会使 rust 编写的命令行工具在本应该返回 141 return code 时候返回 0（again，这是可以仔细处理好的：在 EPIPE 时 return 141
）如果去看下 go 是怎么处理的，会发现它（貌似）更智慧一点：
A write to a broken pipe on file descriptors 1 or 2 (standard output or standard error) will cause the program to exit with a SIGPIPE signal. A write to a broken pipe on some other file descriptor will take no action on the SIGPIPE signal, and the write will fail with a syscall.EPIPE error.
https://pkg.go.dev/os/signal#hdr-SIGPIPE
更能照顾到绝大多数场景。
不过在 gdb 调试 go 进程时，由于 SIGPIPE 没有被 ignore，会触发 ptrace 的 signal-delivery-stop，很烦，但都是非常细微的 debugger 细节，正常人类不用管。。。
[1] https://flylib.com/books/en/3.225.1.83/1/
（再不分享点技术内容就要
交友频道了）看到这条消息很难过，不知道之后要怎么才能看到有賀先生的近况了——有賀先生是我曾经日本旅行时住过的一间民宿的主人，尽管我提出了我可以在同行的伙伴和他之间作为翻译，但是老先生还是坚持用手机上的翻译器和我们每个人聊天。
尽管自动翻译有很多的错误，还是需要我来帮忙补充，但老先生即便是语言不通也坚持要自己面对面和每个人沟通的姿态感动了我们所有人。旅行之后我们仍时常挂念着他，有朋友写过明信片寄给他，我也会时不时地访问他的博客来了解他的近况。
有賀先生几乎每天都会写一篇博客，我想他一定有收到平台将要关闭服务的提醒吧，不知道他是否曾经在某一篇博客中说明了未来博客会迁移到什么地方。但作为一名不合格的读者，我错过了他最后的博客，也错过了征得他的同意，并为他的博客存档的机会。
等我知道时，一切已经无法挽回了。互联网上能找到的最后的存档停留在 6 月 18 号，之后整整 5 个月的内容恐怕都已无从恢复。
尽管自动翻译有很多的错误，还是需要我来帮忙补充，但老先生即便是语言不通也坚持要自己面对面和每个人沟通的姿态感动了我们所有人。旅行之后我们仍时常挂念着他，有朋友写过明信片寄给他，我也会时不时地访问他的博客来了解他的近况。
有賀先生几乎每天都会写一篇博客，我想他一定有收到平台将要关闭服务的提醒吧，不知道他是否曾经在某一篇博客中说明了未来博客会迁移到什么地方。但作为一名不合格的读者，我错过了他最后的博客，也错过了征得他的同意，并为他的博客存档的机会。
等我知道时，一切已经无法挽回了。互联网上能找到的最后的存档停留在 6 月 18 号，之后整整 5 个月的内容恐怕都已无从恢复。
