V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  vonfry  ›  全部回复第 1 页 / 共 1 页
回复总数  10
x11 有 ssh x forward ,可以把远端的 xorg client 在本地渲染。wayland 有一个 waypipe 也是做这个事情的。
如果你不需要完整的桌面控制,只是需要跑一些远程的图形界面,那么这个方案就足够了。任务脚本反正 ssh 过去就行。
在我看来反正大部分情况是不需要一个完整远程桌面的。
4 天前
回复了 zisen 创建的主题 职场话题 2026 年从物理学转码是不是 49 年入国军
我之前有一份工作是 EDA 的。公司内有很多物理出身做算法的(比如 FDTD 、有限元),就业你可以找找这一类。小公司是需要你能写代码(甚至是高性能的),直接优化掉程序岗的那种。小公司可能还需要你会一些数学相关的知识,再优化掉数学岗,比如像特征值求解算法这类。大企业不知道,但从职能结构上来说应该是分离的。
但这个行业很卷,至少我面过的公司都一个样子,几套话术来回说。

AI 的部分,因为你是从业外转入的,所以等于你在用工具快速做你不熟悉的领域,可能你做出来的东西只是能工作,它里面可能存在很多你不知道的问题。“不知道”就是这里最大的问题。
我的观点是干活可以用,但业余不要过度依赖,知识储备一定是得要的。早期入门时还是手写好一点,基础打好很重要。
至于你所谓的老员工不用,可能是活太多了,根本没时间去玩;也可能只是工作而已,干完活就行了,怎么干是另外的事,反正工资是按天算的,又不是按你干活多少算的。当然也可能是尝试过,发现不好用,或者工具链不适用,或者太贵了用不起,或者就是没尝试。反正理由很多。而且对这个领域,LLM 可能并不能特别好的处理很多事情。它很强,但没宣传的那么强。
2025 年 12 月 31 日
回复了 idblife 创建的主题 宽带症候群 奶昔订阅更新失败是啥情况?
五分钟自毁,之前我特意发邮件问过。说是防 ddos
2025 年 12 月 22 日
回复了 chman 创建的主题 程序员 大家在实现 AI Agent 的时候都用什么框架呢?
核心不是框架,是你的业务逻辑如何拆解成逐步执行的逻辑与分发。另外现在大部分框架都是做简单原型还行,但复杂需求都要东改西改,不如手搓方便。
2025 年 12 月 2 日
回复了 powersee 创建的主题 程序员 自定义 tree-sitter 的 grammar 真难
tree sitter 的语法不是基于 generalized LR 做的么?已经比 LR(1) 这种规则宽很多了。
如果觉得难,可能是不太理解 BNF 表达和 FSM 解析流程。可以先拿 yacc 这种写个简单的 parser 开始。或者阅读一下龙书(
2025 年 12 月 1 日
回复了 aqtata 创建的主题 C++ 少用 auto
@litmxs 有的,朋友,有的。serena 这个 mcp 就是干这个的(其实还能代替 code agent )。

@Trustzone 现在 lsp 基本都比较成熟了,静态语言的类型基本都能推断。
2025 年 11 月 5 日
回复了 BigChengzi 创建的主题 Rust 如何看待 Rust?
@BigChengzi #44 我的观点是:你没拿 C/C++ 这种写过多线程并发、处理临界资源访问、内存分配管理的经验,直接上手学 rust 过不了编译很正常。但如果有相关经验其实就基本是无门槛了。

所以也是相对的,如果没有类似的需求用不用 rust 差别不会太大。

我个人而言,rust 是主流语言里,即有完善生态、有又较好的语法(糖)、又吸收了各类其它语言的优点(特别是一些函数式设计),写起来其实会很舒服。

不过现在 rust 其实也有一些问题,比如没有 C++ 的原地构造,想要做只能依靠编译器帮你优化,或者拿 unsafe 。
2025 年 10 月 19 日
回复了 unbinilium 创建的主题 程序员 记因 API 第一次挨同事骂
你有 leader ,也提了前身兼容这种要求。那么你应该和 leader 多沟通,确认技术细节。
另外开会说的东西遗忘还蛮正常的,毕竟那么多内容,一般都主要关心自己的部分。这种会后开工前要对接的,提供沟通会比较合适。
2025 年 10 月 19 日
回复了 unbinilium 创建的主题 程序员 记因 API 第一次挨同事骂
> 前端页面下一个子组件对应到一个 endpoint ,不再分级,组件全部信息放在一个相同的 JSON schema 里就好
> 根据请求类型,后端自动去 request payload 里找需要的字段用或选择性更新 response body 里的部分字段

听起来很像 graphql 的想法,如果要用 json 也有类似的框架。简单来说就是后端不把功能拆得非常细,而是由前端来控制数据的获取,这样其实对迭代会比较简单,后续维护很多需求可能都不用过后端。不过就是初期开发会有点成本,用框架的话会好一点。

> 一年前上司曾批评过我过度设计,效率低

我觉得得看人和项目。对很多企业来说,产品能跑就行,根本不关心内部质量。以技术角度来说我个人认为不可取,企业内,你自己想明白就行。我觉得满足自己最重要,再严重也就是丢份工作而已。

> 他自称写过很多爬虫,也写过前端(他本职做 AI 算法的,211 硕)
> 前端原型里部分组件 anti-pattern 的迹象很明显,一个模块里揉合状态信息、配置信息和控制指令,我倾向做 decomposition 拆到该 endpoint 的子路径里做(我很难接受前端把这种模式通过 API 扩散给后端)

和学历无关,身边统计学。国内前端、AI 出身的大部分不关注代码质量。另外做过什么并不能说明代码能力。何况爬虫这种又是调库为主的;并不是去维护了爬虫库,做了很复杂的反爬,或是有很好的性能调优或者架构。说明不了什么。
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2981 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 14:15 · PVG 22:15 · LAX 06:15 · JFK 09:15
♥ Do have faith in what you're doing.