@dawn009 说实话这个理由太扯了 要是这个理由好用 大家就不用商业竞争了 邮政可以去搞顺丰 出租车可以拿着这个去告滴滴 卖 POS 机的去告支付宝我觉得都 OK

1. 对象存储只是一个协议或者概念 至于你底层用什么其实根本不关心的 底下是你的 fs 也好 是你的 NFS 也好 其实对对象存储来说都可以 具体看你自己的实现了 一般架构上都会有一个 gateway 存在来处理你的请求 至于 gateway 要如何帮你把文件落盘存储那就是你自己的实现了

你现在这么以为只是你以 Minio 做例子罢了 如果是 Ceph 的话其实 Index 和 Data 是在不同的 Pool 上面的 而这个 Pool 又建立在 RADOS 上面 RADOS 自己是直接使用 Bluestore 去管理裸设备的 跟你的 Minio 实现并不一样 现在新的一个叫 ozone 如果你去看 ozone 的话 ozone 的管理模式又变了 虽说是基于你自己的 fs 但是人家是通过 Container 实现了对不同的 Block 的管理 然后利用 Ratis 去管理 Replication 在此之上人家实现了 S3 Protocol 或者是 o3fs 甚至是一个兼容 HDFS 的文件系统

2. 对象存储的重点不在性能上 需要性能的话请选择 NVMeOF 你要区分不同存储的特点 对象存储的好处是可以存储海量数目的文件 并且可以横向扩展 对于一些传统的存储来说 横向扩展还是有很多限制的 而且在存储海量文件的时候也会有管理上的麻烦 就像你自己举例的那样 Minio 就是你说的那么做的

各个存储类型都有自己使用的范围 建议多看看不同的文件系统之间实现的差别和局限性再来讨论这个问题 另外就是要结合你自己的需求来选择合适的存储

@dingwen07 说实话 我真觉得 Slack 做得比他好多了 虽说面向的市场不同 但是你说的这几个方面 Slack 应该做在了 Telegram 前面了吧？

今天更新了 看起来是一个 bug

```
[Other] ERR_HTTP2_PROTOCOL_ERROR on some websites #1374
This week Chrome 87 was released, which has a compatibility problem with AdGuard when using the HTTP/2 filtering protocol - some sites may experience regular hangs and download errors. In this update we have improved HTTP/2 filtering compatibility with Chrome 87, it is recommended to upgrade to the new stable version as soon as possible. :)

[Fixed] BigSur: AdGuard can't start protection in Network Extension filtering mode because of codeSignatureInvalid error
Also in this update, issue which many Big Sur users encountered was fixed. AdGuard network extension couldn't pass the authenticity verification of the developer's signature. Because of that, it was impossible to turn the Network Extension mode on and to enable AdGuard protection.
```

@tsui 主要是自动驾驶要连接网络这个事情就不太靠谱 你要是用来 OTA 那没问题 但是如果涉及到跟自动驾驶相关的说实话我觉得还是算了 就算天顶星科技你也不可能把具体的流程转移到云端额

@SorryChen 然而也基本差不多 5G 覆盖不到位你去哪用 uRLLC 而且 uRLLC 应该是 SA 的特性 SA 估计等 6G 出来了也只有小部分市区能用 外加现在运营商晚上还得给基站断电省电费 那 AutoPilot 要不要晚上就不能用了？ 怎么想这种事情都不靠谱

而且这个想法也是老的了 至少 30 年前我教授读博士的时候就有讨论过类似的想法了 再往前的想法是马路下面埋传感器来辅助定位 听着是不是很有年代感

@SorryChen 那还是等 Tesla 自己去布网吧 就现在这个覆盖率 开一会儿到了信号不好的地方那还用不用了……

@Goldilocks 谁说 Apple 用的 ARM 就是大家知道的那个 ARM……

@nobody123123 https://www.docker.com/blog/apple-silicon-m1-chips-and-docker/?utm_campaign=IT+Pro&utm_content=1605547520&utm_medium=social&utm_source=Organic

@nonduality 然而这个风险有多大呢 就像你提到的发送时必定有时间、IP 、地点 但是实际上数据里面并没有地点 时间这些东西也都是属性自带的 通过这些来判断是某个用户装了什么的可行性有多少？ 你技术上要如何实现这些？

至于使用困扰那是应该去解决的 但是如果说泄露隐私的话还是担心下 ISP 比较好 相对于其他更大的问题 说实话我不觉得这个是个什么严重的问题 你自己去拦截一下这些请求 能从中复原出什么信息呢？

我只是觉得大家把一个看起来很简单的问题变得很严重化 反而对真正严重的问题视而不见 如果你对 OCSP 觉得这么严重的话 name 你对 TLS1.3 以前的协议中 SNI 没有加密的问题怎么看 相对于这么费劲的才能知道你装了什么 app 这个可是会直接泄露你访问了什么网站而且 ISP 直接就能拦截到的 那是不是我们都不要用 TLS 了？

@nonduality 请阅读 Apple 的差分隐私技术的白皮书 https://www.apple.com/privacy/docs/Differential_Privacy_Overview.pdf

@bethebetter 而且 Chrome 的实现看起来也没那么好吧 毕竟时效性不如 OCSP 如果你那么在意这个的话你在意不在意 Chrome CRList 更新的慢可能带来的风险？

要是一个简单的 OCSP 就能暴露这么多隐私 我觉得大家还是别上网了 浏览器也别用了 毕竟通过 Canvas 以及 WebGL 也能追踪到你的浏览器不是？

Apple 有完整的隐私相关的介绍 大家都不去看
https://www.apple.com.cn/privacy/features/

蹲一个 有了记得 @我

@Cielsky 这个也跟屏蔽反屏蔽手段厉不厉害没关系

核心观点其实应该是用户 厂商以及 publishers 之间权利的问题的 商业利益有没有受到侵犯不应高于用户权利 否则的话像 iOS 越狱 各种独占的软件和游戏之类的行为 都可以用类似我的损害了我的商业利益来状告对方了

@Cielsky 那得优酷拿出证据来说啊 而且准确来说给优酷造成损失的不是浏览器厂商 而是选择去用屏蔽广告浏览器的用户 我看楼上有人说屏蔽了广告后优酷就不允许播放了

其实这个更根本的问题是用户有没有权利去屏蔽广告？浏览器厂商有没有权利去满足用户的需求？照着优酷的这个逻辑 所有的做广告个性化投放的厂商都可以去起诉浏览器厂商了 毕竟现在主流浏览器都有反追踪的功能

说实话优酷这样有点变相侵犯用户权利了

@Cielsky 屏蔽开启了广告屏蔽插件的用户是优酷的选择 那没问题 既然优酷已经拒绝为这部分用户提供服务了 那又何来浏览器添加了广告屏蔽服务而给优酷带来了损失？ 因为这部分用户根本就没享受到优酷的服务

@sillydaddy 感觉很多人观点很奇怪 觉得影响商业利益就可以去告 而不是从用户权利和视频网站权利出发

德国的判决其实说的很清楚 用户有权利去屏蔽广告 同时 publishers 也有权利去屏蔽屏蔽了广告的用户 而且优酷也已经把不看广告的用户都屏蔽了 所以如果用户有权利去屏蔽广告 同时各种厂商去满足用户一个合法的需求又有什么违法的地方 如果优酷认为广告属于版权的一部分 那么优酷可以并且已经通过屏蔽这部分用来拒绝展示内容

如果优酷觉得屏蔽广告是违法的 那么是不是有侵犯了用户所拥有的屏蔽广告的权力 但是从商业利益受损出发肯定是有问题的 考虑到之前美国也已经判决 iOS 越狱是合法的 出发点也是为了平衡版权和用户权利之间的关系 并且支持了用户有权利去越狱自己的设备

@laravel Google 不该去告 AdBlock 么？ Chrome 不该下架 AdBlock 插件么？断人财路 呵呵