V2EX › Jirajine 的所有回复 › 第 115 页 / 共 213 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 111 112 113 114 115 116 117 118 119 120 ... 213

❮

❯

2021 年 1 月 27 日

回复了 yodhcn 创建的主题 › 程序员 › 请教下，怎么用 ffprobe 查看音频文件的 "位深" ？ bits_per_raw_sample = N/A; bits_per_sample = 0 是啥情况？

你可以理解为瓶子里装水，参数越高代表瓶子越大，“能够”装下更多地水。但实际装的水有多少，没有任何参数能够直接反映出。

2021 年 1 月 27 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@ryd994 不是所有项目都有一套“内部库”，开发者选择简单、省事、现有的低效实现是很常见的状况。
不否认你说的的 C 的所有优点，简单、直接、可控。理论上的效能 C 也确实拥有最高的上限。但语言的标准、库、生态实实在在地影响实际上的软件性能。比如 ripgrep 和 fd 的性能明显的好于 GNU 的 grep 和 find 。

2021 年 1 月 27 日

回复了 maplerecall 创建的主题 › Chrome › Google 将禁止第三方基于 Chromium 的浏览器同步 Chrome 数据

这很好，干嘛要主动把自己的隐私送给 Google 呢。
如果致使其他人开发出可自建的替代后端就更好了。

2021 年 1 月 27 日

回复了 forcecharlie 创建的主题 › Windows › baulk 极简的 Windows 包管理器 2.0 发布，使用 C++20 编写了新的 tar/zip 解压缩功能

你这个包管理的理念，有点太“绿色”了。
不过你源里的自制的 wsudo 好像不错，看起来能当个轻量的 sanbox 用。

2021 年 1 月 27 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@wms #108 你这样做就把原字符串 mutate 了，其他语言(fat pointer 实现)可以直接取 slice 。

2021 年 1 月 27 日

回复了 huangmingyou 创建的主题 › 云计算 › 私人照片备份的选择

加密后上 s3/oss

2021 年 1 月 27 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@ryd994 难用就会导致你实际中写出的程序变慢。c 最快应该说是理论上最快，实际中影响因素很多。就像我上面说的那个字符串的例子，确实理论上可以自己实现，但因为没有统一的标准，你和其他库交互时还是得转回来，一来一去还是快不起来。

2021 年 1 月 26 日

回复了 orannge 创建的主题 › Windows › 二进制管道， PowerShell 竟还不如 CMD

慢可能是因为二进制数据先被解析成 string 了，并且对无效字符可能进行替换。你会发现最终产生出来的文件已经面目全非。

2021 年 1 月 26 日

回复了 weifan 创建的主题 › Windows › win10 如何重置 powershell

敲个 gal 或 Get-Alias 你就明白了。

2021 年 1 月 26 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@wms 取子串需要添加 null byte，取后缀需要先 count 。
语言的标准实现、库、生态当然会影响你写出程序的性能。就算你强行替换成最优实现，也只是理论上可行。比如标准的 null terminated 字符串性能慢，你改成 fat pointer 的实现，那你调用别人的库 /别人调用你的库都需要额外转换，性能还是不行。

2021 年 1 月 26 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@wms 取子串、取后缀。
再就是由于其糟糕的依赖管理，某些算法 /数据类型在其他语言你可以轻易导入其他人很好的实现，在 c 里你可能就懒得用了。
当然我不是说 c 不行，我只是说 c 并不是**永远**最快的（尤其是 real world c programs ）。

2021 年 1 月 26 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@wms 你这样说就过于绝对了，且不说工程上的复杂度导致 c 难以一直使用最优化的实现。一个最简单的例子，c 的 null terminated 字符串。

2021 年 1 月 26 日

回复了 Rwing 创建的主题 › Debian › 来自 debian 团队的各大语言性能测试数据

@Mohanson #21 理论上来说全都应该使用语言内置基础类型、最简实现才能实际地体现出各语言的性能。

2021 年 1 月 26 日

回复了 lengrongec 创建的主题 › DNS › ROS 做 ipv6 内网劫持 dns 查询

ros 不清楚，按理说应该支持。一般的 linux 路由 nat4 和 nat6 装上对应的内核模块都是一样使用的。

2021 年 1 月 26 日

回复了 alexkuang 创建的主题 › JavaScript › pnpm 没法 unlink 的问题

开 verbose 看看问题出在哪一步，然后排查代码。

@love #1 试试 pnpm install --shamefully-hoist
pnpm 最大的坑是很多脚手架(create-xx-app)不支持，还是会调用 npm/yarn，除此以外基本没问题。

2021 年 1 月 26 日

回复了 smallyu 创建的主题 › 问与答 › Linux 有比 deepin 更好用的桌面系统吗？

gnome/kde

2021 年 1 月 26 日

回复了 downstairs 创建的主题 › 问与答 › go 适合写操作系统吗？

go 且不说 gc 导致的效率问题。
安全性和可靠性也不行，从 c 那里继承太多糟粕。

2021 年 1 月 26 日

回复了 imzhazha 创建的主题 › 投资 › 为什么不建议大家投资虚拟货币

第一点，不止我们中国打压，全世界 zf 机构都在打压。只不过我们有制度优势，封杀的更彻底，而西方的审查.封锁力不从心。
第二点，虚拟币确实没有任何物质上的价值，就像我们的 d 和 zf 也不创造任何物质上的价值一样。zf 金融机构通过印币发币制造通胀实现剥削，通过中心化的监控实现控制，虚拟币可以一定程度上进行对抗。相比起基于国家信用的法币，通过数学原理像金银一样保证信用，允许不受 zf 机构控制的自由流通，就是虚拟币最大的价值所在。

1 ... 111 112 113 114 115 116 117 118 119 120 ... 213

❮

❯