注意：该“开源”代码仅仅是“公开源代码”而不是“开放源代码”，此代码的授权协议包含诸多限制，不是 Open Source Initiative (OSI)认可的“开放源代码协议”。

这个网卡后面那段短的真的不是什么需要配合主板用的特殊引脚吗？ PCIe 本身是能双向兼容的，长卡完全可以插入短槽中，有的主板会给短槽末端开口，完全不需要弄成两段两种长度，这么做也会和市面上的机箱冲突。

“作息不正常”有两种情况，一种是说睡眠时长有问题，另一种是说睡眠时间段有问题。一般来说更需要关注的是睡眠时长，睡眠时间段更多是一种社交、社会性问题，而不是生理性问题。

@delete26 看厂商的。Pixel 一些旧机型 Widevine 不会掉，新机型如何不知道。小米是都不会掉，至少我手头上的 Redmi K40 不会。一加是都会掉(指纹仅微信会掉)。

看厂商的，小米是指纹和 Widevine 都不会掉

推荐看看 https://www.zhihu.com/answer/3055150642

因为市场太小吧，Disney+面向的简体中文人群基本就只有新加坡人以及少数大陆出国的人，市场太小，优先级不高，所以还没完工，完工后应该会补上，也有可能是干脆就没做。

Apache 支持.htaccess ？ WordPress 是支持根据用户配置自动生成一个.htaccess 的，就不需要手动配 nginx.conf 了。

1. 不知道，我猜是
2. 看城市之前有没有管吧，有的话应该都会戴
3. 出门前带上
4. 有，因为可能被车撞
5. 好像有的电动车是有的吧
6. 看城市规定吧

如果摄像头本身不会持久化保存设置的话，拔掉摄像头再插入就恢复了。系统应该是没办法得知摄像头本身的默认值的，没法在系统中恢复。

@documentzhangx66 我开发的根本不是游戏服务器，只是举个例子，你又急于否定了。
而且这个问题只需要加多个进程内 map 进行缓存就能解决，举这个例子就是为了反驳你说的“觉得语言内置 map 性能比 Redis 好”，因为性能真的比只用 redis 好，redis 和 map 不是互斥关系，是互补关系。

@documentzhangx66 所以你仍然是在不了解他人需求、现状的情况下，就急于否定？就举一个简单的例子，游戏客户端高频低延迟和服务端进行通信，服务端每收到一个包都通过 TCP 从 redis 或其他数据库请求客户端信息，难道不会成为性能瓶颈吗？再者，我只是在 redis 的基础上加上了进程内的缓存，就叫“放弃一套成熟系统的其他方面”？

看城市的，像广州和佛山的地铁就是通的。
至于国铁的问题，部分线路是已经地铁化运营的，比如广深城际，可以直接扫乘车码入闸，上任意班次。也有像广珠城际那样有很多站票的。
香港高铁目前已经确认 7 月开始试行买票上任意车次了。至于站票，似乎是跟车速以及车辆内部空间设计有关，可能加不了站票。

@documentzhangx66 我目前就在开发一个支持分布式的服务。客户端会与服务进程通信，服务进程从 redis 获取用户 session 信息，以及上报当前 session 的一些数据到 redis 。还有个管理进程去维护 redis 中的数据，最终数据都是存放在 mysql 中的。
服务进程中有使用 map 进行 redis 数据缓存，曾经实测过每次收到客户端数据时都通过 TCP 连接从 redis 拉取客户端数据，结果是会严重影响性能。而且因为是单 TCP 连接 redis(设计成多连接又会继续增加复杂度)，redis 请求需要类似 HTTP 那样按顺序处理，会导致无法并行处理客户端数据。
所以 map 比 redis 性能好时，为什么还要使用各种类型的数据库呢？因为有别的需求，仅用 map 不能满足这些需求。不能不看需求就认为不能用 map ，而且即使用了 redis ，本地也适合用 map 再增加一层缓存。
比如说上述案例，如果改为全都直接读 SQL 数据库，SQL 数据库没有通知客户端缓存失效的接口。如果管理进程和服务进程通过 RPC 通信来交换数据，那基本等于重新实现了 redis 的功能，又要写很多 RPC 通信的代码，管理进程崩掉也会影响服务进程正常工作，还不如直接使用 redis 。

@documentzhangx66 redis 还要走网络通信，还是基于 TCP 协议的，我认为不会更快。而且许多 redis 客户端库都支持客户端缓存，redis 也支持 value 发生更改时通知客户端清除缓存。

@iorilu PotPlayer 的广告是服务器控制是否显示的，按官方的说法是会根据你的使用频率决定是否显示。

关于 FFmpeg 耻辱柱的问题，Infuse 支持那么多格式，它有没有使用 FFmpeg 呢？如果有的话，它有按照协议开放源代码吗？
就算 Infuse 真的能力超强，所有解码算法都是自己独立开发的，同时还解决了专利问题，它能这么做的底气也是因为 macOS 有完善的软件付费平台，以及用户也有付费的意愿，换到 Windows 平台上，Microsoft Store 很晚才出，之前一直没有很简单方便的付费平台，就算有，绝大多数用户也没有付费意愿，完全没办法支撑开发。

充电是 EC 控制的，不同 Windows 机子上的 EC 差异非常大，要开发的话就得一一适配，成本极高。
而且印象中 Mac 能控制充电也是因为有人发现了 Mac 的 SMC 有隐藏的控制充电的接口，苹果似乎很久都没有使用这个接口，但一直存在，如果没有这个接口的话也是没法控制充电的。

@kaedea 上架过 https://web.archive.org/web/20230506161605/https://play.google.com/store/apps/details?id=com.sankuai.meituan