V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  secondwtq  ›  全部回复第 7 页 / 共 120 页
回复总数  2394
1 ... 3  4  5  6  7  8  9  10  11  12 ... 120  
2023-02-01 21:23:24 +08:00
回复了 enchilada2020 创建的主题 问与答 有没有综合体验能跟 MBA M1 差不多的 Linux 笔记本
楼主你这个需求,究竟是先跑个非 Linux 的虚拟机 host ,上面再跑 Linux/WSL ,还是直接跑 bare metal 的 Linux ?
前者的话就按照优秀 Windows 本的标准来挑基本就行,毕竟这里 Linux 没有硬件的直接控制。
后者的话,by definition 没有,软件和生态 integration 现在是 Mac “综合体验”的重要部分,Linux 比起来差异太大了,根本做不到“差不多”。
2023-02-01 21:17:51 +08:00
回复了 enchilada2020 创建的主题 问与答 有没有综合体验能跟 MBA M1 差不多的 Linux 笔记本
@agagega
> 买得起电脑还差这点电费吗
这个在 Mac Studio 的上下文里还真没啥问题。很多拿 Mac Studio 干活的人,换成一个 hypothetical 的配置类似的 ITX 或 MATX 的机器估计问题也不大,毕竟十年前整的垃圾桶那种活都能用。

这里的问题我觉得主要还是无论哪个生态圈,现在都是一套芯片通吃的。这就造成 PC 在笔记本及更小的 form factor 表现不理想,至于 Steam Deck 啥的更是只能凑合用的德行(哪怕 Steam Deck 已经是半定制芯片+系统了)。而另一方面 Mac 在更大的 form factor 的功耗上有优势,但是我也不得不好奇如果苹果以更高的功耗目标重新设计个桌面芯片的话性能和功能还有多少空间。这个模式不变只能是要么是过度偏向其中的一个极端,要不就是两边都不讨好。

PC 某些方面的趋势确实不太好,但是非要全线压到 M 系级别的功耗我觉得没必要——毕竟 Mac 最高端产品才能提供的扩展性,随便一个低端 PC 就能搞个猴版,在这种形态上体积明显是有下限的,没必要像苹果做得那么极限。
但另一方面 PC 的问题又是实际存在的,这个我觉得还是得通过加强不同 segment 芯片的差异化来解决。并且 PC 也不是完全没有降低功耗的动力——比如服务器堆核就是个很现实的问题。
2023-01-28 22:49:37 +08:00
回复了 levelworm 创建的主题 分享发现 和一位 art director 聊了一下,感觉目前的 AI 已经很可怕了
我的想法跟楼主很相似,就是未来的某个阶段,内容创作者可以更多地做高层的工作,而把底层的工作更多地 offload 给工具。
这个“高层”和“底层”的定义并不是固定的,比如对于一个画手而言,“高层”就是构图和氛围,“底层”就是作品中细节的形状透视光影。而对于一个游戏主创而言,“高层”则是 core gameplay ,世界观和剧情梗概,整体艺术风格,单个的图片和声音素材则变成了“底层”。

有些人总觉得用 AI 之类的东西来做很 low effort ,我觉得是这个技术刚起步不成熟,尤其不能把眼光局限在“给一个 prompt 然后给出一个最终结果”这种“端到端”的形态上,ChatGPT 等流行产品目前起到的最大作用是展示了未来的潜力,之后工具的形态可能很不一样(并且可能也需要和现在类似的专业知识来操作)——比如上面有人提到的“低代码平台”,其实就是另一条路,但是最终目的是一样的。不过无论是走哪条路,这个就是我,可能也是一部分从业者比较理想的方向。

我使用“内容创作者”而不是“艺术创造”这个词,是因为我发现和“艺术”沾边的东西很多给我一种不太现实的印象。比如“码农”和“工程师”两个词,“工程师”这个词看上去很牛逼,但是不同的“工程师”的工作状况完全不同,有的可以跻身顶尖科学家,有的还不如“码农”,所以我更喜欢比较中性的“程序员”这个词。
有些“艺术家”或“艺术评论家”还有一种偏执,就是什么东西一定要是手搓的才好,机器的都是垃圾,在这一派人看来 AI 更是彻底的异端。但是从人类社会诞生起这个追求本来就是不现实的——你的音乐是实录的,但是你的乐器全是手搓的?不是手搓的又如何做到对音色的完全掌控?而特别是在工业时代之后,“手搓”变得越来越不现实,比如一部电影会把很多工作外包给不同的公司,那不就相当于交给了高级的“AI”么。当然人家的逻辑是自洽的,艺术嘛就是浪漫的 ... 但是如果我们在谈工具,谈量产的工作成果,那么就必须谈现实的一方面。

用个比喻来说就像外部库:有了这些东西,程序员才不用手动造轮子了。现在的内容创作其实早就有很多类似的东西,比如笔刷、音源、Kitbash 、Stock Photo 。但是可能缺一个类似于“编译器”的东西,把手动写汇编、做优化的过程省掉。不必期待它是完美的——编译器这个已经广泛使用了几十年,已经成为经典理论,完全可解释的东西用起来还有各种问题,未来的内容创造大概率不会更简单。
2023-01-28 21:59:35 +08:00
回复了 520discuz 创建的主题 分享发现 其实固态硬盘真的没必要买太好的
是这样的,我之前用的最便宜的原厂 SATA ,现在用 905P ,确实没有明显区别 ... 除去极个别情况之外日常使用绝对不值这个钱
我觉得有个更有意思的问题是,操作系统的 page cache (以及 prefetch 等机制)起了多大作用,把花在高档 SSD 的钱花在扩容内存上是不是更好(毕竟现在这俩都白菜价)
2023-01-28 21:52:42 +08:00
回复了 LaGeNanRen 创建的主题 问与答 请问在英语职场的交流中, block 更多的含义是什么
#5 正解
用于人时本来是没有归因于“能力”“态度”的意思的,就是表达一个事实。靠谱的外企在发现问题之后偏向于改进 process 和项目管理,而不是 blame 个人。(当然有可能在 yygq 你)
当然也可以用于任务或者 Issue 之间。
2023-01-28 21:45:58 +08:00
回复了 abc0123xyz 创建的主题 问与答 求教 qbittorrent 内存问题
你这个好的,我现在占了 17.6GB ...
两条和四条主要是超频的问题,内存条数越多超频上限越低。不超频基本随便。
混插没试过 ... Frankly 你插单条 32GB 上去唯一的好处是以后能在此基础上扩展到最高 128GB ,而全插 16GB 最多只能 64GB 。
另外我的华硕主板内存槽标注是 A1A2 B1B2 ,AB 区分 IMC 的两个通道,12 是每个通道上两个 DIMM 。
要是能进系统的话找点软件看看能不能侦测出插的条子,或者直接 UEFI 里面看。
2023-01-23 00:38:42 +08:00
回复了 a1knla 创建的主题 前端开发 为什么 Electron 不推出公共运行时?
其实这个是个政治问题不是技术问题
Electron 的好处之一,就是它提供了一个较为确定的虚拟机,并且它是 Electron 应用开发者完全可控的,应用开发者只需要绑定一份 Electron ,就可以确定应用在最终用户系统上的行为是基本一致的。开发者还可能对 Electron 进行一些定制来满足一些特殊的需求。说白了就是:我既要跨平台,我又要稳定,还要低成本,最后要可控,Electron 提供这么一个方案。但是你知道这是计算机,那么古尔丹,代价是什么?就是你每个应用都得带一份,把成本转嫁到用户上。
采用公共运行时的形式,就意味着应用开发者失去了对虚拟机这一层的控制。这自然会削弱 Electron 的优势。

楼主说的“公共运行时”的形态并不是完全不行,比如我现在用的 Arch Linux ,就把 Electron 单独打了一个包,然后 VSCode 依赖这个包。虽然因为我只装了 VSCode 一个 Electron 应用所以这个形式在我这聊胜于无,但是应该很接近楼主想要的状态了。这个包还分为 17-22 等不同版本,颇有 .NET 风范。可以说 Arch Linux 已经“一国建成社会主义”了。
当然上一个“一国建成社会主义”的现在已经凉了,Arch Linux 的实际状况也并非上面说的这么好。比如 VTune 也用了 Electron ,作为一个闭源软件,很难确定是不是能用包里提供的 Electron 替换上去(而且最丧心病狂的是这货似乎把 Electron 的文件打包进了 executable 里面),网易云音乐和 Steam 用的是 CEF ,这东西“本质上”跟 Electron 差不多,但是你也没办法把它搞出来做成公共运行时,同时装这俩最后还是两份 CEF 。
类似地你会发现,比如 Qt 也是个很适合做成公共运行时的东西,但是很多 Qt 软件就喜欢在发布时带上一份 Qt ,这里 Qt 扮演了和 Electron 十分类似的角色。而出现这种现象的绝大多数都是闭源软件,闭源软件追求绝对的稳定和收入,是绝对不会放过任何一个“增强稳定性”的机会的,如果不是在 Windows 上微软强制 .NET 必须通过系统级的方式安装,他们绝对会自己把 .NET 的所有文件带上来分发的。对于开源软件而言,社区本来就是它的一部分,所以如何更好地融入用户系统也是开源软件开发的重要考量。

然后考虑楼主的比如“把 JS 解释器抠出来”之类的提案,这里要考虑的历史背景是 Electron/CEF 等都是基于 Chromium 项目的,Google 开发 Chromium 项目的初衷是做 Chrome 浏览器,Chromium 项目本身和 V8 引擎是深度绑定的,对于 Google 来说,不存在把 Chromium 和 V8 解绑的动机——人家一开始做这个就是为了不受 WebKit 制约,能自己乱搞,而不是要做得多模块化,这个和 Electron 开发者用 Electron 的原因倒是很像。就算有人做好了给 Google 端上来可能人家都懒得 merge 。

最后,开源软件就真的完美了么?还是作为一个 Arch Linux 用户,我现在机器里有 OpenSSL ,GnuTLS ,Mbed TLS ,wolfSSL 至少四个 TLS 库,Expat ,libXML2 ,TinyXML ,pugixml 至少四个 XML 库,json-c ,jsoncpp ,Jansson ,RapidJSON 至少四个 JSON 库,至于浏览器引擎,除了上面提到的 Electron 和 CEF ,还有 Firefox 自己的一份,Chromium 自己的一份,WebKitGTK ,QtWebKit ,QtWebEngine ... 上面这所有的软件,除了两个浏览器之外我没有主动安装它们,它们都是不同的包依赖的。
我觉得楼主问题的根本逻辑可以简要地概括成:不同软件中的“重复”能否完全消除?答案我觉得上面已经很明显了 ... 这远远不是 Electron 自己的问题。

最后一个有趣的现象:对桌面 Linux 有点了解的应该知道目前 NVIDIA 官方的用户驱动是闭源的,这背后不仅仅是 NVIDIA 的开源战略问题——目前 Linux/FreeBSD 上几乎所有的开源 GPU 驱动,都是基于 Mesa 3D 这一套框架做的,这个意思是,不同 GPU 的驱动只需要写和硬件直接相关的部分,而处理 API 和 Shader 编译前端之类的硬件无关部分由 Mesa 框架负责,这个架构可以做到在 *不同公司、不同硬件、同一系统* 上驱动代码的复用。类似的东西在 Windows 上也有,叫 WDDM 。
这个是开源社区的角度,而 GPU 厂商,比如 NVIDIA 的角度可能是不一样的,先不考虑是否开源的问题,它们需要解决的,是需要实现一个跨平台的驱动,也就是 *同一公司、不同硬件、不同系统* 上驱动代码的复用。这样可以推断 NVIDIA 内部可能有另一个框架,它将操作系统和一部分 API 的差异抽象出来,后面主要处理不同代硬件之间的差异。
也就是说 Windows 上 N 卡的 OpenGL/Vulkan 驱动可能和 Linux 上的专有驱动,甚至可能还有之前 Mac 上的驱动共享了很大部分代码——但是不会是 Mesa 的。NVIDIA 不会使用 Mesa 这套东西,一方面是它主要面向部分平台( Mesa 并不是不能在 Windows 上跑,不过主要还是做 Linux 和 BSD 的),另一个是它是社区的东西不可控,可能也不是完全适合它的硬件。
当然作为一个闭源的东西,我做的只是推断。不过一个旁证是目前 NVIDIA 放出的所有与硬件相关的开源信息,其表述的动机都是“供开源开发者参考来开发另一套开源驱动”,包括前段时间的开源内核驱动在内,NVIDIA 从来没有表达过把它自己的这一套东西和开源社区原有的项目在代码层面直接融合的想法。类似地 AMD 可能也有这么一套东西(虽然大家都说 AMD 在 Linux 下的开源驱动做得好,不过人家自己也有一个 Linux 闭源驱动的),Mali ,Adreno 之类的可能也有。Intel 在 Linux 下只有官方开发的基于 Mesa 的开源驱动,所以可能 Windows 驱动是完全独立的。
4k 日常使用比 2k 要舒服太多,你买 4k 显示器日常 2k 分辨率我是真没看懂 ...
2023-01-22 22:18:41 +08:00
回复了 pocarisweat 创建的主题 Intel 12/13 代 i7/i9 CPU 大概会比 M1 Pro 强多少?
你这个最简单的方案是弄个 5950X 换上啊 ... Zen 3 和 GLC 比性能差一点但是绝对算不上落后,能耗比也很好
2023-01-22 22:12:17 +08:00
回复了 dearroy 创建的主题 问与答 ChatGPT Pro 版在小规模内测了,你会为此付费吗?
之前 OpenAI 的 GPT-3 之类的模型,他们都提供 API 按量收费的,所以可能不一定非要订阅。
想起之前这个主题 /t/907460
2023-01-22 22:04:32 +08:00
回复了 gowl 创建的主题 奇思妙想 提高网站速度的第二种思路
这些东西算是前端优化的基础知识吧,我之前找工作背的八股文里面还有 sprite 呢,资源打包、压缩、分块也都是老套路
技术层级的东西确实对博客最有用,但是到生产项目上,我感觉最有用的是需求管理和项目管理。同一个页面塞太多乱七八糟的需求,天天只糊屎不埋屎,再优化也白瞎。
2023-01-22 21:50:26 +08:00
回复了 basncy 创建的主题 Linux 你在 Linux 下用什么 office 套件
Google Docs ,我觉得比 365 网页版好用
缺点是依赖于 Google 账户,占内存高
你这题超纲了,苹果做电脑就没想过让你跑 Android 模拟器 ...
这题我会。如果只是这些需求的话感觉用 container 或许也可以。这里面可能需要解决一下 GUI 的一些问题,大概不如虚拟机简单直接,但是开销更小,玩熟之后也更灵活。

我没用 container 跑过 GUI ,但是我做过一个大概更加脱裤子放屁的事情。因为我现在用的是 Wayland 环境,然后我发现 Steam 的 Remote Play 大概对这玩意支持不是很好( github.com/ValveSoftware/steam-for-linux/issues/6148 )因为 Steam 是闭源的所以不怎么方便折腾。为了能用 Remote Play ,就又做了个 QEMU 虚拟机,上面跑 Openbox ,只装必要的包和 Steam ,然后插了张空闲的显卡 passthrough 过去(中间手动 hack 了新版 kernel 引入的一个 bug lore.kernel.org/lkml/[email protected]/T 不然 tty 就没法用了,然而我又时不时会改下 Wayland Compositor ...),写了个脚本启动和关闭。注意这上面是会跑 Proton 的,也就是为了解决一个 Linux 自己的兼容性问题跑了个虚拟机,然后上面又跑了解决 Linux 和 Windows 兼容性问题的 Emulator ...

刚才有几个明显的坑已经说了,还有几个:
* 我尝试过用 virtio-gl 代替 GPU Passthrough ,这个是 QEMU-KVM 这个栈给出的开源 GPU Paravirtualization 方案。说实话,纯 OpenGL 程序跑得还可以。但是 Proton 现在主要方向是 DXVK ,是需要 Vulkan 支持的,而 virtio-gl 现在是只给 OpenGL API 做虚拟化的。有人在利用 virtio-gl 的基础做一个 Vulkan 的 Paravirtualization 叫 Venus ,这个看样子已经基本可用了,但是不在目前 Mesa 和 QEMU 的稳定版里面(当时我测试的时候已经进 Mesa 的 testing 包了,但是 QEMU 的 patch 好像很久都没合进去),还好是 Arch ,折腾一阵编译好了,但是不能用,折腾到最后发现应该是 N 卡闭源驱动栈提供的一些内核对象不支持 mmap 操作,无法在两个系统之间共享内存,恰好这个闭源驱动栈的新硬件的内核部分有开源的,所以可能折腾一下能行,不过我一时半会不清楚该怎么改 ...
这个 Paravirtualization 的性能损耗会比 GPU Passthrough 要高,intel 驱动应该不会有这些问题,但是如果是核显的话本身性能也低。我去试的基础是本身主 GPU 性能足够损失一截也无所谓。这也是为啥要折腾 Vulkan 支持,更新的实现和开销更小的 API 也有助于降低 Paravirtualization 的损耗。但是 anyway Vulkan 支持现在还不成熟,虽然现在普通桌面一般还都是 CPU 渲染或 OpenGL ,但是需要游戏或者 Vulkan 编程的时候就成了问题。另外这玩意现在应该只是处理通用 API ,需要 GPGPU 等 GPU 特定 API 的时候不知道会怎么处理 ...
* 我尝试在虚拟机和主机之间共享游戏文件夹,这个 QEMU 也提供了 virtiofs 的解决方案。但是可能是因为我叠的 debuff 太多了(我还是在 ZFS 上用的),偶尔会出现不稳定。其实还有一些其他的方案,但是到底都是两个内核访问同一个文件系统,本身就是很奇怪的一个事情,使用 container 的话直接共享就行。
* 以前我都是虚拟 Windows ,我本来以为 Linux 内核会直接支持在 Linux 上虚拟 Linux 时,虚拟机没有使用的内存就不占用宿主机内存,这样我可以很低开销让虚拟机一直跑在后面。但是查了一下发现这个东西貌似挺麻烦的,不过折腾折腾估计还是可以的。
* 键鼠如何虚拟化解决方案也不唯一,现在我主要用的是 evdev passthrough ,相当于把所有事件转发给虚拟机,这样在虚拟机里用快捷键不会被宿主机拦截。但是在目前的设置下我还是需要手动处理虚拟机运行过程中热插拔键鼠的情况,并且偶尔会有不稳定。

非常凑巧的是大概同时间我还对硬盘分区进行了调整——先是换了一块更大的系统盘,这个过程很简单,就是插一个 Arch 安装盘启动,给新盘分区格式化,然后 rsync 原来的系统盘到新盘里,最后修改一下 fstab 里面的 UUID 和 bootloader 里面的系统盘分区标签(如果你用的是一样的标签就可以不做 ...),就可以直接从新盘启动。然后还把系统分区和 Home 分区分离了,这个更简单,就是分好区之后挪一下 Home 目录,fstab 加一条。我的意思是在直接备份很简单的情况下,只为了备份需求跑虚拟机实在有点大炮打蚊子的感觉。如果你只用包管理器装软件的话,桌面 Linux 大半的自定义其实都在 Home 里面,除了 Home 之外备份个 /etc 和 /boot 就差不多了(最多还有你的包列表)。所有这些都是可以通过直接拷贝文件解决的问题。虚拟机对我来说代价太重了,而且最重要的是不知道什么时候会出问题,比如我在主机可以用 turbostat 看 CPU 功耗和频率,虚拟机就跑不了(有可能是我设置问题)。

另外 Arch 属于在软件选择上没有偏向性的系统,基本只有 pacman ,glibc ,systemd 几个给你框下来了(内核可以改,因为内核的 userspace API 相对稳定反倒问题不大),剩下的基本都是你自己发挥。所以不存在“Arch 对虚拟机支持怎样”的说法。另外如果只是使用一个系统的话,没必要两个系统都装完整的 GUI 。可以向我一样只装最小化的 GUI ,或者干脆不装 GUI 直接 passthrough GPU 。
用星战的梗来说,楼主的说法是正确的,"from a certain point of view"

黄仁宇有个说法,把中国帝国史分为三个阶段,从秦到南朝陈为第一帝国,从北魏到南宋为第二帝国,从辽到清为第三帝国。按这个说法,从元成到南北朝结束,就是持续半个多千年漫长的旧秩序崩塌,新秩序建立的过程。
上面有人提到的新朝,它就是在危机第一次开始显现时试图通过较为和平的方式解决它的一个尝试。所以你会看到王莽有很多很 naive 的做法,因为他就是个大儒生,也是儒家势力推他上去的,他就按照当时比较原始的儒家学说来搞,当然完全是不切实际的。这背后反应的其实就是这个时代是比较 naive 的,后来就再也整不出这么大的活了。
就不说后面全都有很重的周边群体色彩了,按照楼主的说法,二三帝国是没有合法性的。这个结合带清的事情来看的话就更河里了——旧事物自身是缺少更新的动力和能力的,必须强行武德注入。我觉得我们看最近两百年的很多想法可能也能移植到当时经历转变的人上面。

当然,这套理论不是所有人都认,因为它只是"a certain point of view"。就像楼主认为“生产力”和“科技水平”是唯二重要的东西一样,我也可以说,自从智人走出非洲以来,每一年都是平行世界的关系——毕竟公元前 3022 年是智人的历史,公元 3022 年也是智人的历史,调换一下顺序,感觉也能对得上。因为每个朝代都吃大米,所以是平行独立的关系,调换一下顺序,感觉也能对得上——嘛,并不是,北方有一半的时间都是吃小米的,汉朝人不会发面,唐朝人不会炒菜,穿越到明朝之前的四川会感觉很不对劲,因为没有辣椒。唐朝也看不着三国演义。

不过我个人嘛,我个人坚定地认为 Rust 1.0 的发布是人类历史上最重要的转折点,从此人类便有了光明,希望,和抛瓦! UNLIMITED POWAAAAA!!!!111
unix.stackexchange.com/questions/269098/silent-disk-errors-and-reliability-of-linux-swap Silent disk errors and reliability of Linux swap - Unix & Linux Stack Exchange 不知道是不是你想要的
2023-01-11 00:21:33 +08:00
回复了 amiwrong123 创建的主题 程序员 x86 汇编 CPU 是如何使用 loop 指令的操作数的?
1. 不要完全用软件的思路揣测硬件实现,硬件可以定制任意位数的加法器的 ...
2. 不止 LOOP ,JMP 就很常用这样的模式
3. 由于各种原因,LOOP 这条指令基本早就不用了,编译器也不会生成。
我觉得比较合适的是强制使用“符合某些条件”的开放标准,而不是钦定一个特定的标准。
反正苹果只要自己能躺是不在乎恶心了谁的,也别怪别人天天恶心你
1 ... 3  4  5  6  7  8  9  10  11  12 ... 120  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3624 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 50ms · UTC 04:34 · PVG 12:34 · LAX 21:34 · JFK 00:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.