今天发现 edge 新加的视频增强其实超级吃 GPU ，一个 1080p 的超分能把 RX6600 干爆。
不是甜点游戏卡的试下关掉这个功能。

专利实质审查实际上跟论文查重差不多，if 你只是要授权的话。
所以主要注意的是用词严谨，术语稳定之类的，专利代理可能会有指导。

遇到跟 OP 一样的问题，由于别的原因要用光猫拨号，ISP 下发/60 前缀但作为二级路由的 openwrt(23.06.2)拿到的是/64 前缀，不过因为我没有设三级路由的需要所以就没管这点了。
我这边遇到的问题是隔一段时间二级路由下面就没了 GUA 前缀，所有 GUA 地址 deprecated ，查 ifstatus lan 得知前缀 preferred=0 但 valid>0 ，重启 wan6 接口可恢复，不知道怎么解决。

光猫上的 IPv6 信息：
IPv6: 2XXX:XXXX:603:b625:56ce:82ff:feXX:XXXX
前缀: 2XXX:XXXX:63b:c340::/60
前缀来源: PrefixDelegation
下发方式：RA/DHCPv6
首选/有效时间: 3600/1209600

Openwrt 二级路由的信息：
wan6:
IPv6: 2XXX:XXXX:63b:c340:1e40:e8ff:feXX:XXXX/128
IPv6-PD: 2XXX:XXXX:63b:c341::/64
lan:
IPv6: 2XXX:XXXX:63b:c341::1/64
IPv6: fd26:aa84:c3c8:1::1/64 （实测有没有 ULA 并无影响）

其实不叫收藏，只是单纯没坏就没扔。
那些只能 5v 的拿去给各种小电器用就不用再买充电头了。手机附赠的通常情况都比山寨小厂的靠谱。

旁路由是你没法动主路由才会考虑的。
因为大部分人对 openwrt 的需求都太简单了，所以才想着拿硬路由一机多用而不是搞两台设备。

小的做系统盘，大的做数据盘。
现在的游戏只要不是立项时就 console only 的，应该不会用高性能 ssd 当性能基准。
可能你玩星空才能感受出一点差距吧。
DirectStorage 没想象中影响那么大。

@JinTianYi456
LibChecker 的"元数据"来自 AndroidManifest.xml,因为编辑麻烦，通常不会在这里放渠道信息。但 Play App Signing 会在这里填写 source stamp ，所以 LibChecker 会根据这个在标题显示 Play 商店图标。

使用 play app signing 的有明确特征，app bundles 几乎 100%使用 play app signing ，但 google 允许开发者在控制台下载由 google 代签的 apk 在其他渠道分发(小开发者常用)，所以通常算是能识别来源的。

由于 google 新规要求新应用和超过 150M 的旧应用必须使用 app bundles,所以以上方法靠谱程度很高。

可以在 play 下载 LibChecker 可以查到很多打包相关的信息，非常好用。

其他渠道没有统一的识别方法，app 厂商通常都会自己插入渠道标识。

pascal 和 gen9.5 差不多是同代的，差别好像是不大的。
我怎么感觉拿这个核显机当播放机用没什么问题啊。

都到 2024 年的怎么还有等等党等这个的。
但凡看点行业新闻都知道 23 下半年上游库存都清得差不多。
不会真有人觉得 23 年的低价是理所当然的吧？

按照“检测到 360 就主动禁用 shell 推广功能”来看算是比较合理的解释。

以微软过去十多年给各种第三方软件擦屁股的习惯来看，这样反向适配也不算什么大问题，特别还是杀毒软件这类野路子操作当饭吃的软件，随便改点啥都很容易被系统搞崩，没深度沟通渠道需要反向适配很正常。

原 UP 不懂这些可以理解，我感觉认识 Raymond Chen 的人才能理解下微软的这种选择。

有没有可能，这是做防蹭网/MAC 黑白名单/DHCP 静态分配设置界面要用的信息。
作为网关，掌握这些信息很合理啊。

据说可以用苹果的 magic trackpad ，搭配第三方开发的 windows precision 驱动使用
集成的话主要要求够大。

@0o0O0o0O0o
HTTP3 大致就是 HTTP2 over QUIC ，不过将这俩深度集成在一起了，主要是直接打包了前面所提的 session ticket/0rtt 等改进，并支持连接迁移（客户端换网络不需要重新握手）。如果就是打算在里面跑 http 的可以直接上 http3 （跳过 Alt-Svc 升级）。
省流量其实不算是 HTTP3 的改进目标，出发点是减少握手的话按上面恰当配置 TLS1.3 应该也差不多，而且应该不会比用 PSK 密码套件(毕竟这玩意的安全性太差)的 TLS 省流量。

而且我是不明白，不在意安全性你为啥要整 TLS,图啥？

前三个是 TLS1.3 定义的套件，第四个是 TLS1.0+可用的套件，最后一个是防降级攻击定义的套件。
所以少了第四个会导致不支持 1.3 的服务器握手失败。

还有如果是想省流量，缩减 clienthello 属于思路错了，你应该考虑的是跳过握手和缩减服务器证书链，包括 TLS1.3 PSK(也就是 session ticket 扩展)、0rtt early data(有重放风险，只能用在幂等请求)，或者直接上 http3(要考虑 udp 联通性问题)。低安全要求又没可靠时钟的可以考虑用 PSK 套件。

以上优化是建立在专用客户端/服务器上，没有向前兼容的情况。

建议换 server2022,以及不装显卡驱动试试。