突然想起来自己有了一个儿子，虽然每天都是惹我生气，但是今天喝酒了，突然看到我儿子才意识到我有一个儿子，而且是个健康的儿子，心情很复杂，不知道各位有没有同样的心情？顺便说一句结婚的男人不如狗（有点夸张）但是有了孩子的男人确实是需要牺牲很多。 第一 次发有照片的帖子，如果不显示请各位指教

大家天天开心啊

1 、封禁时间都差不多，都是 10 月 22 号 6 点多,肯定不是人工封的。

2 、之前就听说，贴吧的删帖封号机制，很多时候都是乱来。

很多被删帖、被封号，根本就不知道为什么被删被封。

3 、被永久封号的，范围非常广泛，包括：吧主、吧务、高级号、签到号、三无号、绿蓝黄牌普通用户。

4 、这次封禁的好多都是十年以上的用户，看来老用户已经成为阻碍百度发展的最大因素了，要不百度干嘛下手这么狠。

有没有人讲解一下这到底是咋回事？

第一次见这种随机“枪毙”自己互联网交流平台的重要用户的！

• 网站地址： https://blog.qiyuor2.me
• RSS： https://blog.qiyuor2.me/rss.xml

机器：三星 Fold 7

喜欢的：

1. 后退键/手势，如同一个系统级的 undo stack ，非常实用。每次完成一件事情后省了切选 app 的心智负担，效率有提升。
2. 浏览器。Chrome 和 Firefox 都比 Safari 好用多了，尤其是用上插件后。
3. AI 与系统结合度高，不管是 Chrome 还是三星的 circle to search 都能直接 trigger AI 浮窗去选择文字或截图。默认不是 Chatgpt 但 Gemini 也算能打。
4. 看书软件 Moon 比 iBooks 好用，手势配置茫茫多，配得很舒服。

不喜欢的：

1. 代理：目前用 Singbox ，比 Surge 难用一点，尤其是监控和流量分析上。不过功能齐全，除了 snell ，能想到的都支持。
2. 国内软件有点卡，目前下过抖音和高德导航都这样。不知道是不是因为美版手机而水土不服。
3. 滑动的 animation 没有苹果舒服。

总结： 用户体验略降，自由度和功能性提升。

我们不妨先从结论开始，不使用 gRPC-Go 来构建 OTLP/gRPC 的 gRPC Server ，可以让：

• 二进制包的体积：降低 25%
• CPU 使用率：降低 36%

背景

OpenTelemetry 协议（ OTLP ）是 “有 OpenTelemetry 插装的应用” 与 “OpenTelemetry （兼容的） Collector/后端” 之间进行数据传输所用的协议。

现在假设你就有这样一个应用，想要传输数据到 Collector ，那么你可以配置通过以下 Exporter 完成：

• OTLP/gRPC Exporter
• OTLP/HTTP Exporter, 其中 Protobuf 的 Payloads 可以编码成：
  • - binary 格式
  • - JSON 格式

出于一些原因，VictoriaTraces 仅暴露了一个 HTTP 接口，通过 OTLP/HTTP 接收 binary 或者 JSON 格式的数据。然而，有很多的应用只支持通过 OTLP/gRPC Exporter 输出数据，kube-apiserver 就是其中的一个典型例子。所以，完善对 OTLP/gRPC 的支持是当前的刚需。

目标

我们的目标是实现一个 gRPC Server，它作为 TraceService 服务提供 Export 方法给远程调用方进行调用，这些信息是定义在 OpenTelemetry Proto 中的。

// Service that can be used to push spans between one Application instrumented with
// OpenTelemetry and a collector, or between a collector and a central collector (in this
// case spans are sent/received to/from multiple Applications).
service TraceService {
  rpc Export(ExportTraceServiceRequest) returns (ExportTraceServiceResponse) {}
}

那么，是什么原因让我们考虑弃用 gRPC-Go ，或者更准确地说，弃用整套 protoc 工具链呢？

原因 1: Protoc 工具链不好用

以 Go 为例，最常见的构建 gRPC Server 的方式就是：

• 用 protoc 和 protoc-gen-go 生成 .proto 中定义的 Message 对应的结构体。
• 用 protoc 和 protoc-gen-go-grpc 生成 .proto 中定义的服务 Interface 并实现它。

说起来简单，不妨先试想一下这些步骤具体是怎么做的。假设我（对 Protobuf 熟悉程度一般）现在 git clone 了一个项目，然后想往其中的 .proto 添加几个新的 Message 和方法：

1. 首先想起来 protoc 并不是 Ubuntu/MacOS 自带的；
2. 从 Release 页下载最新版本的 protoc；
3. 诶，光靠 protoc 不能生成 Go 代码，所以还需要 go install protoc-gen-go 和 go install protoc-gen-go-grpc；
4. 都准备好了，生成代码的命令是什么来着？ Google 一下 “gRPC 如何编译 Go 代码”；
5. 终于，抄到了命令在本地运行，回车。Boom ！弹了个依赖 Error ，因为 .proto 里面有一些 import，还要将这些引用的内容的目录在命令中指定清楚；
6. 整理好所有目录和命令，重新运行，终于成功生成出了代码。

不过，别高兴得太早，protoc 可能还有惊喜在等你。

“为什么这些新生成的代码看起来和老代码好像不太一样？”

新代码：

type TracesData struct {
state protoimpl.MessageState `protogen:"open.v1"`

ResourceSpans []*ResourceSpans `protobuf:"bytes,1,rep,name=resource_spans,json=resourceSpans,proto3" json:"resource_spans,omitempty"`
unknownFields protoimpl.UnknownFields
sizeCache     protoimpl.SizeCache
}

老代码：

type TracesData struct {
    ResourceSpans        []*ResourceSpans `protobuf:"bytes,1,opt,name=resource_spans,proto3" json:"resource_spans,omitempty"`
    XXX_NoUnkeyedLiteral struct{}         `json:"-"`
    XXX_unrecognized     []byte           `json:"-"`
    XXX_sizecache        int32            `json:"-"`
}

7.Google 对应原因，行，然后用不同版本的 protoc 工具链重新走了遍步骤 2-6 。（甚至有时候还要 git log 找之前的作者问用的是哪个版本。）

幸好，这些步骤只是个玩笑，在 VictoriaMetrics 里面我们不这么干。这只是想说明，编译 Protobuf 相关的内容并不是那么直来直去的，不像写个 HTTP JSON 接口那么简单。

当然，它可以变得简单一点：

1. 把所有的命令都写到 Makefile。
2. 或者使用 Buf CLI，把代码生成完全在线化。

不过仍然有很多工程师就是喜欢 HTTP JSON 。

尽管麻烦不断，但是这些仍不足以说服我们弃用 protoc 工具链。还有别的理由 （借口） 吗？

写在原因 2 之前

原因 2 或许能给你新的启发，不过需要声明，因为 VictoriaTraces 中存在一些历史包袱，它才能在该项目中作为一个 “原因”。也就是说，这个 “原因” 并不是每个项目都该纳入考虑的。

原因 2: easyproto 已经代替了 golang/protobuf

在 VictoriaMetrics ，VictoriaLogs 和 VictoriaTraces 中，对于 Protobuf 的内容，我们是用 easyproto 来进行 Marshal 和 Unmarshal 操作的，而非常见的 golang/protobuf 包。原因在 easyproto 的 README 中写得很清楚：

• easyproto 不需要 protoc 或者 go generate。
• easyproto 不会像传统的 protoc 那样让编译的二进制包的体积增大。
• easyproto 正确使用的话可以达成零内存分配。

不过，如果真的要实现 OTLP/gRPC 支持，我们得考虑：

1. 如果用了 protoc 生成 gRPC Server ，那编译的二进制包会大多少？
2. 有可能将 easyproto 和 gRPC 结合起来用吗？protoc 只需要生成 gRPC 服务的代码，而 Protobuf Message 的结构体还是用 easyproto 处理。
   • 注意这仍然需要引入 gRPC 相关的包，这会弱化使用 easyproto 的第二个理由（减小二进制包体积）。
3. 还有其他办法可以复用现有的 easyproto，而不用引入任何新的包吗？

邪门歪道: 用 HTTP/2 Server 代替 gRPC Server

按理来说

gRPC 是个实现在 HTTP/2 上的协议，所以按理来说，实现一个 HTTP/2 Server 来处理对应接口的请求就可以了。

gRPC 也可以实现在 HTTP/3 (QUIC) 或者 HTTP/1.1 之上，不过这已经超过了这篇博客讨论的范围，我们把它留给读者探索。

根据 gRPC over HTTP2，Data Frame 的格式是这样的：

// +------------+---------------------------------------------+
// |   1 byte   |                 4 bytes                     |
// +------------+---------------------------------------------+
// | Compressed |               Message Length                |
// |   Flag     |                 (uint32)                    |
// +------------+---------------------------------------------+
// |                                                          |
// |                   Message Data                           |
// |                 (variable length)                        |
// |                                                          |
// +----------------------------------------------------------+

同时很容易知道，TraceService 服务的 Export 方法对应的 HTTP 接口是 /opentelemetry.proto.collector.trace.v1.TraceService/Export。

下面这段代码简单展示了如何用 HTTP/2 Server 处理 gRPC 请求：

// Init 启动一个 HTTP Server 。
func Init() {
logger.Infof("starting OTLP gPRC server at :4317...")
go httpserver.Serve(
[]string{":4317"},
OTLPGRPCRequestHandler,
httpserver.ServeOptions{UseProxyProtocol: nil, DisableBuiltinRoutes: true, EnableHTTP2: true},
)
}

// OTLPGRPCRequestHandler 管理 gRPC 请求的路由。
func OTLPGRPCRequestHandler(r *http.Request, w http.ResponseWriter) bool {
switch r.URL.Path {
case `/opentelemetry.proto.collector.trace.v1.TraceService/Export`:
otlpExportTracesHandler(r, w)
default:
grpc.WriteErrorGrpcResponse(w, grpc.StatusCodeUnimplemented, fmt.Sprintf("gRPC method not found: %s", r.URL.Path))
}
return true
}

// otlpExportTracesHandler 处理 OTLP Export 请求。
func otlpExportTracesHandler(r *http.Request, w http.ResponseWriter) {
// gzip 解压缩
...

// 解析前 5 bytes ，用 easyproto unmarshalling 剩余 []bytes
...

// 写数据等操作
...

writeExportTraceServiceResponse()
}

完整的代码可以查看 VictoriaTraces #59。

代价是什么？

这个实现看起来简单直接，那作为交换，一定有什么代价吧？

到目前为止这个实现只在 Unary RPC 中测试过，而对于 Streaming RPC ，我们没有场景和动力去做相关的测试，所以暂且认为它是只能处理 Unary RPC 请求的。

不过这样的实现足以覆盖我们在 OTLP/gRPC 上的需求，它可能在其他场景不适用，如果你知道具体是哪些场景，非常欢迎在评论中发表看法！

对比测试

我们做了一轮测试来对比 VictoriaTraces 中不同 OTLP/gRPC 实现方案的二进制包的体积和资源使用率，这些方案包括：

1. 用原生 HTTP/2 Server 处理请求，用 easyproto 来处理 Protobuf Message 。
2. 用 protoc 生成 gRPC Server 代码，用 gRPC 原生的 Encoder 和 Decoder 来处理 Protobuf Message 。

另外，生成的 gRPC Server 也支持通过以下代码自定义 Encoder 和 Decoder ，所以我们也用将 easyproto 设为 Encoder 和 Decoder 作为另一组对比。

import (
"google.golang.org/grpc/encoding"
)

func init() {
encoding.RegisterCodec(&easyProtoCodec{})
}

结果如下：

编译二进制包体积:

• Release 的所有二进制包总体积 (tar.gz):

  • HTTP/2 + easyproto: 87M
  • gRPC + easyproto: 113M (+29%)
  • gRPC: 113M (+29%)

• 单个 linux-amd64 包体积:

  • 参考基准 (v0.4.0): 21M
  • HTTP/2 + easyproto: 21M (+0%)
  • gRPC + easyproto: 28M (+33%)
  • gRPC: 28M (+33%)

请求处理的资源使用率（ CPU 使用率, no-op: 对每个请求仅进行 Decompression 和 Unmarshalling):

• HTTP/2 + easyproto: 31.3%
• gRPC + easyproto: 45.6% (+45%)
• gRPC: 49.1% (+56%)

• 资源监控 Snapshot 可以查看这里。

• CPU 和内存的 Profiles 可以在这里下载。

从这些结果可以看出，HTTP/2 + easyproto 确实更占优一些。

总结

这篇博客分享的是“为什么 VictoriaTraces 用 HTTP/2 + easyproto 来实现 OTLP/gRPC 所需的 gRPC Server”。它的关键实现是由 JayiceZ 完成的，而最初的想法来自于 @makasim。

这个实现的背后有很多特定的原因，我们并不是想说服你也这样做，但是我们在测试中确实看到了这种方案的潜力和价值。

VictoriaStack 的亮点是高性能和资源优化，所以每一分 CPU 、内存和网络流量都很重要。当然，这同样也适用于二进制包、Docker 镜像的体积等等，就如这些要素也曾在 Aliaksandr Valialkin（ VictoriaMetrics 的作者）写的这篇博客中被提到，一直以来它们都没变过。

求大佬给个 iyuu 或者其他支持 mp 的站点

AUTH_SITE 认证站点支持：iyuu/hhclub/audiences/hddolby/zmpt/freefarm/hdfans/wintersakura/leaves/ptba /icc2022/xingtan/ptvicomo/agsvpt/hdkyl/qingwa/discfan/haidan/rousi/sunny

邮箱: wangyu19970819@gmail.com

设备群晖 32 个 T 一直开机不会死 求

请看下图，google 时，已经被翻译成中文的 reddit 帖子标题，直接出现在搜索结果里：

点进去 也是翻译好的 reddit 帖子（关键翻译的质量真的好高）

所以，真的对我这种英语不好的人很友好，我一般 google 直接搜中文的，可以直接搜到 reddit 的帖子，不会漏掉英文的高质量回答，点开也是中文的已经翻译好的 reddit 帖子。

但我点进去 reddit 首页或者其他帖子的时候，又瞬间变成英文的界面了，好奇是不是有什么设置，可以让我浏览 reddit 站的时候，通篇全部都是翻译好的 中文界面呢？？

当然你说，可以开网页翻译然后浏览呗，但是 1 我觉得 reddit 自带的翻译质量特别高 2 我也想在手机的 reddit app 上也可以这样

拼车网站： https://ipinpin.store 优惠码：9999 减 9 元 质保一年，自动发货

https://github.com/nullbyte-lab/wechat-multi-open

原理: 复制微信应用并修改 Bundle ID ，系统会识别为不同的应用，从而实现数据隔离和多开。

Xcode: 不需要安装完整的 Xcode ，只需要 Xcode Command Line Tools （约 500MB ），脚本会自动检查，缺失时会提示安装

成功了别忘记 回帖+Star

有大佬打赏就更好了，最近跌的心态差

原理已经说明，微信若发疯了要封，我免责 反正我自己在用

Features

• 交互式菜单 - 傻瓜式操作，无需记忆命令
• 智能检测 - 自动扫描已有副本，避免重复创建
• 增量创建 - 只创建缺失的实例，节省时间
• 选择启动 - 指定启动哪些实例，支持多选和 all
• 灵活删除 - 可删除指定副本或全部清理
• 彩色输出 - 清晰易读的彩色交互界面
• 安全保护 - 二次确认、错误处理、权限隔离

Installation

Quick Install

# 下载脚本
curl -fsSL https://raw.githubusercontent.com/nullbyte-lab/wechat-multi-open/main/wechat-multi-open.sh -o ~/wechat-multi.sh

# 添加执行权限
chmod +x ~/wechat-multi.sh

# 运行
~/wechat-multi.sh

Manual Install

# 克隆仓库
git clone https://github.com/nullbyte-lab/wechat-multi-open.git

# 进入目录
cd wechat-multi-open

# 运行脚本
./wechat-multi-open.sh

纯兴趣学习，本人在武汉，寻找下兴趣相投的伙计，还处于基础的摸索阶段

一直显示无法访问此网络

已知我的代理软件没问题，在手机上使用流量可以上，连接 Wi-Fi 就不行。

有什么办法吗？

codex 用不了很难受哇

轮盘游戏。固定的角度录制有 10 万次结果。 根据这些完整数据，能预测出白球是落在左边还是右边吗？ 我查阅了一些资料 国外有很多人做过这些研究。理论上是可行的。

相关资料 使用 OpenCV 二进制掩码检测轮盘和球速 https://www.linkedin.com/pulse/roulette-wheel-ball-speed-detection-opencv-binary-mask-muhammad-anas-nqy4f

https://www.youtube.com/watch?v=bpy933SQ6Q0 https://www.youtube.com/watch?v=kibZDD_I9HY https://www.youtube.com/watch?v=HaMlKvNqCVs https://www.spinsight.ai/

java 单元测试，求教。 或者有其他更好的适用于 java 单测的数据库推荐吗