w568w 最近的时间轴更新 w568w 最近的时间轴更新
ONLINE
88 
61 
w568w
| 上海联通，这种情况是被 gank 了吗 宽带症候群 • w568w • 44 天前 • 最后回复来自 SelFree | 14 |
| 尝试润了下几十块的薄膜键盘，体验不错 机械键盘 • w568w • 53 天前 |
| Python 3.14 已发布
1 Python • w568w • 58 天前 • 最后回复来自 w568w
|
35 |
| 有什么比较好的制作 EPUB 的工具？ 问与答 • w568w • 62 天前 • 最后回复来自 callmesmc | 9 |
| 微信 for Linux 终于更新了 微信 • w568w • 52 天前 • 最后回复来自 invzhi | 9 |
| 需要向应用下发一些小体积数据（应用公告等），用什么解决方案比较好？ 问与答 • w568w • 73 天前 • 最后回复来自 w568w | 2 |
| 丝之歌初玩评价 游戏 • w568w • 90 天前 • 最后回复来自 stinkytofux | 13 |
| 硬核探索式推理类游戏推荐 游戏 • w568w • 116 天前 • 最后回复来自 dxgfalcongbit | 13 |
| 再开一个浏览器扩展推荐贴 浏览器 • w568w • 113 天前 • 最后回复来自 shengchen11 | 42 |
| 各编程语言新生项目数量排行 Top30 程序员 • w568w • 143 天前 • 最后回复来自 w568w | 38 |
w568w 最近回复了
6 天前 回复了 einsdisp 创建的主题 › 输入法 › AI 时代了， Linux 下有好用的开源的中文输入法了吗 |
@PrinceofInj 哈哈，我也差不多。之前对 rime 的印象一直就是手摇拖拉机，干啥都行等于干啥都不行，事事都要自己写代码配置，配来配去折腾一两个礼拜还不如 Windows 上微软输入法开箱即用的体验。Fcitx5 Pinyin 就更简陋了，而且不知为何从输入到显示候选总是慢一拍。
后面直接用了万象，第一次感觉 Rime 还能这么简单好用。
> 感觉万象主要还是在调整词库，ngram 的语法库似乎并没有感觉有太明显的作用
确实。不过总体来说万象的输入舒适感虽然和搜狗输入法这种依赖云端的还不能比，但肯定是本地输入法里最强的一档了。
后面直接用了万象，第一次感觉 Rime 还能这么简单好用。
> 感觉万象主要还是在调整词库，ngram 的语法库似乎并没有感觉有太明显的作用
确实。不过总体来说万象的输入舒适感虽然和搜狗输入法这种依赖云端的还不能比，但肯定是本地输入法里最强的一档了。
7 天前 回复了 einsdisp 创建的主题 › 服务器 › 基于 KVM 的虚拟化（PVE/unraid/oVirt/Openstack），现在能实现 Win 虚拟机下的 3D 加速吗？ |
大厂的方案我不清楚，但确实见过一个开源实现 mvisor： https://github.com/tenclass/mvisor-win-vgpu-driver
7 天前 回复了 einsdisp 创建的主题 › 输入法 › AI 时代了， Linux 下有好用的开源的中文输入法了吗 |
AI 训练，开源，拼音，我看标题都以为这是 万象拼音 的推广贴了
不过万象拼音确实不错，可以看看： https://github.com/amzxyz/rime_wanxiang/
它本身是在语料库上训练了 ngram 预测器，算是有 AI 加成。实际输入的体验也不错。我自己已经用了几个月了，对长难句的支持很好
（注：非广，也不认识作者，甚至都没加官方群）
不过万象拼音确实不错，可以看看： https://github.com/amzxyz/rime_wanxiang/
它本身是在语料库上训练了 ngram 预测器，算是有 AI 加成。实际输入的体验也不错。我自己已经用了几个月了，对长难句的支持很好
（注：非广，也不认识作者，甚至都没加官方群）
7 天前 回复了 doushini 创建的主题 › Windows › 非常怀念 windows XP，界面简洁， 300MB 的 ISO 镜像 |
怀念的不是当时的系统，而是当时的软硬件生态。随便拉出几个当年的软件和今天的软件一对比，就看出差别来了
12 天前 回复了 WithoutSugarMiao 创建的主题 › 游戏 › [年度游戏投票] 今年的年度游戏是 33 吗？ |
好奇《天国：拯救 2 》为啥一直不温不火？因为是续作？名字起得太小众？游戏节奏太慢热？
我自己没空玩但我看朋友玩了，不管是游戏自由度、世界观和文案文本量、配音工作量，还是开放世界建模和渲染水平，应该都是业界顶尖的水平。
我今年玩了《丝之歌》和《双影奇境》，云了《 33 号远征队》。说实话我大力支持《丝之歌》拿最佳独立游戏，《 33 号远征队》玩法创意不错，但前面这几部的制作水平应该还没法和《天国：拯救 2 》扳手腕……
我自己没空玩但我看朋友玩了，不管是游戏自由度、世界观和文案文本量、配音工作量，还是开放世界建模和渲染水平，应该都是业界顶尖的水平。
我今年玩了《丝之歌》和《双影奇境》，云了《 33 号远征队》。说实话我大力支持《丝之歌》拿最佳独立游戏，《 33 号远征队》玩法创意不错，但前面这几部的制作水平应该还没法和《天国：拯救 2 》扳手腕……
12 天前 回复了 lihua 创建的主题 › 分享发现 › 安卓千元机让人刮目相看 |
不错，我今年也给家里人（包括我自己）换成 iQOO 全家桶了，顺便开了 vivo 家庭会员，可以共享云盘空间。体验很不错
13 天前 回复了 shenhualv7 创建的主题 › 分享发现 › 拿着一万预算想买个稍微护眼的手机，研究了整整一天买了个一千的 g100 |
一直觉得手机护眼是个伪需求。
看了一下 OP 之前的帖子，主要是要阅读吧。为什么不直接买墨水屏的电纸书或手机呢？
看了一下 OP 之前的帖子，主要是要阅读吧。为什么不直接买墨水屏的电纸书或手机呢？
14 天前 回复了 zcion 创建的主题 › C++ › [求助] Linux 有什么好的引入 c++ 第三方库的方案 |
（我主要写 C ，没写过 C++，所以下面一部分说法可能不准确。）
这个问题其实有系统级和语言级的两层，一是 Linux 对 C/C++ 依赖的管理没有明确的定义，各个发行版自立山头；二是 C/C++ 的包管理本身确实很乱。
1. 对于前者，可以认为在依赖管理这件事上，Linux 没有规定什么做法是标准的，所以「每个系的发行版都是完全独立的体系」，不应该像 Windows 7/8/10/11 那样当成同一血脉的系统来看待。
尽管大家可以找出一些最大公约数（比如大多遵循 FHS 、使用 pkg-config 和 gcc ），但在实现上会有非常多细微的差别。大部分差别在开发过程中可以消解掉（例如使用 CMake 的 find_library/package 过程）但不是全部，而在打包和分发过程中则完全需要各个区别对待（比如 Debian 系、Gentoo 系和 Redhat 系，在分割软件包的粒度和指定依赖的方式上，做法都完全不同）。
此外，Linux 本身又是极度依赖 source-driven 的，需要时刻考虑用户利用现有环境进行开发的可能性。这就是为什么 Linux 下很难有 vcpkg 这样一个独立的、和系统无关的 C/C++ 包管理器。或者说即使有了，也不会好用，因为你最终还是要为每个发行版、编译器和依赖组合付出额外的成本去适配。
2. 对于后者，你的例子其实就是很好的典型。「通过 pacman 下载的 boost 似乎没有提供 .pc 文件」，是因为 boost 这个库本身只提供了 CMake 模块。你用 pacman -Ql boost 就能看到，boost 提供的是 /usr/lib/cmake/Boost-xxx/BoostConfig.cmake 配置文件，而不是 pkg-config 文件。
这种四世同堂的局面很多，不是每个包都会提供 pkg-config 来兜底（从功能性上来说，CMake Modules 无疑是更先进的）。这其实也是生态碎片化的体现：开发中的选择一旦多起来，开源作者都会习惯性选择自己最习惯的，而不是兼容性最好的。你问「有没有办法用统一的方式导入」，其实就和前端问「有没有办法在我的 React 项目里导入其他 UI 框架的控件」是一样的。当然这边的问题至少理论上是 solvable 的。
----
所以我能给的建议是什么呢？
1. 如果你专为某个发行版开发程序：完全本土化。使用那个发行版和系统包管理器，完全遵循那个发行版的逻辑。系统提供什么就使用什么方式引入；
2. 如果你为所有发行版开发程序：防御性编程，减少假设。同上，但是尽可能不要依赖某些假设（例如「一定有 pkg-config 」）。CMake 的 https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html 介绍了通用的建议，主要是 尽可能使用 find_package 来引入依赖、使用 FetchContent 来从源码编译依赖 及 不要使用 FindPkgConfig 。
这个问题其实有系统级和语言级的两层，一是 Linux 对 C/C++ 依赖的管理没有明确的定义，各个发行版自立山头；二是 C/C++ 的包管理本身确实很乱。
1. 对于前者，可以认为在依赖管理这件事上，Linux 没有规定什么做法是标准的，所以「每个系的发行版都是完全独立的体系」，不应该像 Windows 7/8/10/11 那样当成同一血脉的系统来看待。
尽管大家可以找出一些最大公约数（比如大多遵循 FHS 、使用 pkg-config 和 gcc ），但在实现上会有非常多细微的差别。大部分差别在开发过程中可以消解掉（例如使用 CMake 的 find_library/package 过程）但不是全部，而在打包和分发过程中则完全需要各个区别对待（比如 Debian 系、Gentoo 系和 Redhat 系，在分割软件包的粒度和指定依赖的方式上，做法都完全不同）。
此外，Linux 本身又是极度依赖 source-driven 的，需要时刻考虑用户利用现有环境进行开发的可能性。这就是为什么 Linux 下很难有 vcpkg 这样一个独立的、和系统无关的 C/C++ 包管理器。或者说即使有了，也不会好用，因为你最终还是要为每个发行版、编译器和依赖组合付出额外的成本去适配。
2. 对于后者，你的例子其实就是很好的典型。「通过 pacman 下载的 boost 似乎没有提供 .pc 文件」，是因为 boost 这个库本身只提供了 CMake 模块。你用 pacman -Ql boost 就能看到，boost 提供的是 /usr/lib/cmake/Boost-xxx/BoostConfig.cmake 配置文件，而不是 pkg-config 文件。
这种四世同堂的局面很多，不是每个包都会提供 pkg-config 来兜底（从功能性上来说，CMake Modules 无疑是更先进的）。这其实也是生态碎片化的体现：开发中的选择一旦多起来，开源作者都会习惯性选择自己最习惯的，而不是兼容性最好的。你问「有没有办法用统一的方式导入」，其实就和前端问「有没有办法在我的 React 项目里导入其他 UI 框架的控件」是一样的。当然这边的问题至少理论上是 solvable 的。
----
所以我能给的建议是什么呢？
1. 如果你专为某个发行版开发程序：完全本土化。使用那个发行版和系统包管理器，完全遵循那个发行版的逻辑。系统提供什么就使用什么方式引入；
2. 如果你为所有发行版开发程序：防御性编程，减少假设。同上，但是尽可能不要依赖某些假设（例如「一定有 pkg-config 」）。CMake 的 https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html 介绍了通用的建议，主要是 尽可能使用 find_package 来引入依赖、使用 FetchContent 来从源码编译依赖 及 不要使用 FindPkgConfig 。
15 天前 回复了 DarkCat123 创建的主题 › 宽带症候群 › 如何利用国外便利架设内网或科学上网？ |
纯境内或境外的部分，你怎么折腾都可以。关键是从境内到境外这一步。你用 OpenVPN 、Tailscale 这些常规的、不专为反审查设计的协议，多半是秒封禁的。
目前反审查能力比较强的协议主要是
1. VLESS （内层代理协议）+ REALITY （将 TLS 握手特征伪装成可信网站）+ Vision-XTLS （消除 TLS-in-TLS 特征）
2. VLESS + REALITY + XHTTP （传输协议，将流量上下行分离，包装成 HTTP 上传下载请求）
3. NaïveProxy （直接使用 Chromium 的网络栈来消除指纹特征）
我自己一直用的是 VLESS + REALITY + Vision-XTLS ，没有任何中转，直通境外。已经两年了，依然没有受到封禁或审查。
不过这几种协议都比较小众，目前只有 sing-box 、mihomo 以及各自的自家代理客户端支持。我没用过 Surge 不是很清楚是否能用。除此之外还有一个备选项 Trojan ，大概相当于以上协议的简化版，抗审查能力弱一些，但客户端兼容性更强
目前反审查能力比较强的协议主要是
1. VLESS （内层代理协议）+ REALITY （将 TLS 握手特征伪装成可信网站）+ Vision-XTLS （消除 TLS-in-TLS 特征）
2. VLESS + REALITY + XHTTP （传输协议，将流量上下行分离，包装成 HTTP 上传下载请求）
3. NaïveProxy （直接使用 Chromium 的网络栈来消除指纹特征）
我自己一直用的是 VLESS + REALITY + Vision-XTLS ，没有任何中转，直通境外。已经两年了，依然没有受到封禁或审查。
不过这几种协议都比较小众，目前只有 sing-box 、mihomo 以及各自的自家代理客户端支持。我没用过 Surge 不是很清楚是否能用。除此之外还有一个备选项 Trojan ，大概相当于以上协议的简化版，抗审查能力弱一些，但客户端兼容性更强
Select Language