V2EX › feather12315 的所有回复 › 第 25 页 / 共 118 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 ... 21 22 23 24 25 26 27 28 29 30 ... 118

❮

❯

2023-07-11 14:23:26 +08:00

回复了 woniuppp 创建的主题 › 职场话题 › 有没有英国或者欧洲的程序员交流群呀

哥们，要不要建个群

2023-07-11 13:37:04 +08:00

回复了 hering 创建的主题 › 酷工作 › [德企][全国][在家办公] SUSE 招聘 Linux 操作系统开发工程师

manager 还是 Roger 吗

2023-07-06 00:35:19 +08:00

回复了 ahill 创建的主题 › 程序员 › 资深程序员的晋升瓶颈

有了 ChatGPT ，junior 5 天的也可以一天完成。

除非资深干的是烧脑子的工作（比如 case by case 分析的问题），或者是讲故事，不然使用了 chatgpt 后，junior 跟资深没有区别。

2023-07-02 11:03:56 +08:00

回复了 kuma42710 创建的主题 › 职场话题 › 核电工作前景怎么样？

求稳定的话可以去，这地方是贼稳定，就是规矩多。

2023-06-27 12:49:12 +08:00

回复了 ethan1i 创建的主题 › 教育 › 弟弟高考选不选安徽大学中外合作的数字媒体技术专业

适合看看张雪峰

2023-06-25 11:47:48 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #67

那请问你：你的代码是 hw 相关的，你怎么做能减少 hw 相关的代码，从而做到无需其他团队 /个人 /第三方配合，就可以做到一套代码跑在不同的硬件上

2023-06-24 18:17:12 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #60 所以场景是不一样的。
你说的场景是云上的，用 vm 。Linux 内核怎么换都行，只要不出问题。但是 host 上的物理机系统就不一样了。

所以这就是两个市场：云上是 Ubuntu 占比高，host 上是 RHEL 。

2023-06-23 21:19:35 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #50 你是从 vm 的角度来看的：统一的 virtio 硬件，不需要第三方的 ko 参与。

实际上与物理机关联，但凡 system 级别的开发，绕不过第三方提供的硬件与驱动。
high level 的代码可以做抽象，可以做 portable ，可问题是使用的硬件，虽然功能相同，不同公司的甚至不同版本的，驱动、so 都有差别。没法做 portable

2023-06-23 21:17:22 +08:00

回复了 amiwrong123 创建的主题 › 程序员 › 保存 Caller saved 寄存器的动作，是硬件行为，还是软件行为？

@amiwrong123 #8 right 准确地来讲这是被优化后的代码，如果禁止优化的话 O0 应该就不这样了（没测试，可以看看）

@amiwrong123 #10 是的。这个要查手册页才能确定，而且贼琐碎。

2023-06-23 19:53:47 +08:00

回复了 amiwrong123 创建的主题 › 程序员 › 保存 Caller saved 寄存器的动作，是硬件行为，还是软件行为？

arm 的话，返回地址是 r13 还是 r12 。
这个要查手册页了，programming manual 有详细的介绍（ arm 的手册很多，要仔细找找，有个 guide 简述了上述过程

2023-06-23 19:52:25 +08:00

回复了 amiwrong123 创建的主题 › 程序员 › 保存 Caller saved 寄存器的动作，是硬件行为，还是软件行为？

一部分硬件，一部分软件。

准确地说：
通用寄存是是软件行为，特定的寄存器是硬件行为。
比如函数调用是软件行为，中断异常的寄存器保存（ amd64 下的 rip 、返回地址）是硬件行为

2023-06-23 19:46:56 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #44
bug 种类多了去了，只有想不到没有它做不到。

不是强制指定系统，是第三方内核模块厂商编译成二进制打包后，在商业 Linux 操作系统提供商指定的版本下（商业 Linux 操作系统会明确表示在特定的一系列版本上兼容什么，不兼容什么）进行一系列测试，测试完成后会表示对此版本进行兼容。

客户要的就是这种兼容性保证。

那么如果商业 Linux 操作系统提供商表示用了 A 版本与 B 版本是兼容的，该内核模块在 A 版本上没有问题但是在 B 版本上出现了问题，那就是操作系统提供商的 bug ，否则就是内核模块提供商。
这种二进制发型的机制明确了责任归属。

2023-06-23 19:40:19 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #44
使用商业版本的 Linux 操作系统不就是买服务吗

2023-06-23 18:44:48 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

#36
国产 Linux 系统不是重新 build 一遍，只要自己维护内核，那么保证 kabi 兼容性、cve 补丁回合就是最重要的任务。
难度不高，就是繁琐。

2023-06-23 18:42:25 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #36
那你看 NVIDIA 的 dkms 模块能得到 NVIDIA 的商业支持吗？
就是 ko 出了任何问题都能找 NVIDIA 来 support 。

很多芯片厂商代码都是两套：一套是开源的，随便用；一套是给商业公司的。
给商业公司的代码，不少是二进制交付（而不是源码交付，看需求）。二进制交付的话，这个模块除了任何问题，都可以找厂家。

一个大型系统（比如存储系统），上下游团队很多，每个团队有自己的 release 。
以二进制交付的话，kabi 变更，任何一环变更了 kabi 导致的模块重新编译，都是不可承受的。
不以二进制交付，那就是源码交付。团队：我都源码交付了，模块遇到问题当然被交付方先处理了。被交付方愿意吗？

2023-06-23 09:24:04 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@yyws2012 #16
内核不一样，你可以拉下来 kernel 的代码看看有没有结构体预留字段。

2023-06-23 09:19:03 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

@james122333 #20
做成 dkms 也可以呀。可是用的结构体字段或者函数变更了，需要修改 dkms 代码才行。
第三方厂商愿意为你一个厂家适配吗？

但是第三方厂家愿意为 RedHat 、SuSE 、Ubuntu 企业版适配：因为他们签约合作协议。

为什么不做成 dkms ？因为要保证二进制一致性。这是 dkms 不具备的。
有时候编译器的改动都可能带来潜在的 bug ，以及：签名。dkms 编译的可不具备来自 server 厂商的签名：这需要用 server 厂商的构建系统构建。

2023-06-23 01:34:27 +08:00

回复了 lvii 创建的主题 › Linux › Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

kernel 只是一方面，还有 glibc 、systemd 之类的各种基础软件的兼容性：
发行版每个版本兼容性都稍微有点区别，企业版会给出 changelog ，社区版就不一定了。

1 ... 21 22 23 24 25 26 27 28 29 30 ... 118

❮

❯