V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  CapNemo  ›  全部回复第 1 页 / 共 5 页
回复总数  99
1  2  3  4  5  
8 天前
回复了 ATKLLL 创建的主题 NVIDIA NVIDIA 对于消费级显卡的虚拟化限制普遍吗?
之前有驱动限制,检测到虚拟机时驱动会报错 42 错误码。二几年取消了,20 系之后的都可以直通给单个虚拟机了。
@darkway 不行
要从携程之类的找向导的话,可以先下单一天,然后见面了再聊后续的行程,能省不少钱
10 天前
回复了 cheemy 创建的主题 投资 大 A 埋人了
这个时候还加风险有些高了,差不多该止盈了
15 天前
回复了 OneLiteCore 创建的主题 NAS 关于 All In Boom 到底是 Boom 在哪里?
还有一个可能性是没有仔细考虑冷启动/恢复时的循环依赖,导致到时候要修好 A 得从 B 里提取备份,要修好 B 得从 A 里提取备份
感觉强制 gpg 签名会更好一些
77 天前
回复了 Kenmin 创建的主题 Android 一加手机投屏需要开启定位权限
简单来说,一切和物理意义上的周围设备进行的交互都能用于确定一台设备的大概位置,因此在进行这样的操作前,需要申请定位权限。
这不是直接拿 2N ?
比较大的开源项目会存在贡献者协议,通常会有给控制项目的组织授予修改项目许可证的权利这样的条款,严格一点的会限制能升级到的协议。反面例子也存在 Linux kernel 就是这样的原因被锁死 GPL2 。但无论如何,一般的开源协议对当前版本代码的授权是不可撤销的。因此单方面修改通常会导致 fork 或重新实现(比如 redis,es)。
121 天前
回复了 Noicdi 创建的主题 C++ CLion 提供非商业免费使用了
对 CLion 的印象主要是比较方便的调试功能和在 ICPC 赛场上崩溃带来的心理阴影。
143 天前
回复了 llsquaer 创建的主题 程序员 请教,关于中后台 API 权限的设计方式?
第二种方案存在将权限和路径绑定的问题。接口需要版本迭代或增加不同参数的版本时容易引发问题。
可以考虑将第二种方案里权限配置改为使用带通配符的路由。不过设计的太复杂又容易因为配置错误导致越权。
如果指 1 楼的情况,那就是一个引用传值,避免反复拷贝一些比较大的 struct 等。如果指 unsafe 里的指针,这个主要是为了方便搞一些强制类型转换和链接 c 语言库。
通过网络连接 USB => 使用 USB/IP 项目 https://usbip.sourceforge.net/
通过网络连接硬盘柜 => 使用 NAS

理论上存在直接在主板上魔改,把网卡到 CPU 之间的连接替换的方案,不过

1. 不知道网卡和 CPU 之间是 PCIE 还是 USB
2. 信号完整性很难保证
172 天前
回复了 San2025 创建的主题 NAS 有必要上 ECC 内存吗?
@yanqiyu 是这样的,如果在内存里就坏了是无可奈何的。我想表达的意思是由于写入占比较低+视频文件对位错误的容忍度,因此 ECC 的必要性会降低一些。
176 天前
回复了 shewhen 创建的主题 分享发现 扩散大模型-Mercury 真的超级快
试了一下,快是确实快,准确性就不太行了
@kxg3030 我记得在 CCPC/ICPC 等算法竞赛中,java 自带的大整数有时候挺有用的
没毛病,魔力即是能源
176 天前
回复了 wysnxzm 创建的主题 程序员 请问这是在说哪一个?
@lesismal 大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。

这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好,而是为了通过语言斗兽棋强行体现自身优越。

内存安全的 rust 是很好,但是如果没有在延迟上有特定的要求,我可能更倾向于支持 GC 的语言。

GO 无脑堆逻辑确实快,但是占一多半的 if err != nil return nil,errr 也确实碍眼。

我赞同你的 curd 是为这个世界服务的观点,在兼具高性能和安全要求的地方推广 rust 无可厚非。

语言的特性是一个事实,没有一个功能或语法就是没有。至于是否属于功能缺失,我觉得判断标准确实要落在是否影响实际工程应用上。
确实是大坑,每个库的 logger 接口都不太一致,需要分别兼容。
177 天前
回复了 wysnxzm 创建的主题 程序员 请问这是在说哪一个?
在我看来,不管是将 GO 的"功能缺失"强行解释为"哲学优越性",还是以内存安全为由在各种项目上强行推广 rust ,这些行为都属于忽略实际条件去强行套用解决方法,本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间,也无助于提高自身水平。
必须认识到,编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知,才能在快速迭代的生态系统中构建可持续的工程能力。
我最多只能说:在我遇到的某个特定场景下,使用某些语言/工具是合适的。但是绝对无法断言,这些语言/工具能满足任意场景的需要。
不过我倒是不反对在工程上的约束较为宽松时(比如不涉及合作开发的项目、性能不关键的项目等等)使用自己最熟悉/最喜欢的工具。
1  2  3  4  5  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2543 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 05:04 · PVG 13:04 · LAX 22:04 · JFK 01:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.