V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  adoal  ›  全部回复第 1 页 / 共 24 页
回复总数  467
1  2  3  4  5  6  7  8  9  10 ... 24  
3 小时 59 分钟前
回复了 Sliverburger 创建的主题 问与答 如何更好地兼容 Python 2 和 Python 3
2022 年了,不用考虑兼容 2 了。如果真的还有必须用 2 的遗留环境,那就不用考虑什么优雅不优雅了,反正已经是屎山。
先把工作网络和顾客网络分开再谈限速
19 小时 7 分钟前
回复了 willx12123 创建的主题 程序员 如何使用 Windows 愉快的编程?
用 Windows 要愉快编程……老老实实选微软御用技术栈呗。
3 天前
回复了 zhuwd 创建的主题 程序员 定制化需求三天一变,累死技术部
新需求到手不要马上改,先厚着脸皮拖三天进度……反正三天后又变了
6 天前
回复了 Aliberter 创建的主题 程序员 公正评价,这代码什么水平
团队有 coding style 就拿出来怼他。没有……说个捷豹。
@coderluan 这位把话题递归扯到元异议,就变成一个没法继续下去的哲学话题了……
已故乔帮主说跟聪明人合作最大的好处是不需要顾忌对方的自尊心……
6 天前
回复了 huyangq 创建的主题 Linux 关于 Linux 下面的 包管理器的 疑惑
RPM 系和 DEB 系主流发行版里打包好的包都是按 FHS 来。

而单位自用业务系统里的业务功能部分,不论是搞外包的传统行业的信息化还是自养开发团队的互联网,普遍倾向于按业务领域划分,everything-under-business-prefix……
6 天前
回复了 huyangq 创建的主题 Linux 关于 Linux 下面的 包管理器的 疑惑
把文件按作用分类到不同目录,而不是按业务领域,有些可能的好处。因为通常文件在文件系统里的权限、性能、易变性是按作用而不是按业务领域来划分的。

比如[/usr]/[bin|sbin]下的可执行程序、[/usr]/lib 下的动态链接库,/usr/share 下的静态数据,通常不需要普通用户有写入权限;/var/lib 下的数据库、/var/log 下的日志通常需要各自的 uid 有写入权限;/etc 下的配置通常在程序和数据做小版本升级时不需要改动,但管理员可能要单独修改;/run 下的 pid 、socket 最好在系统重启后就没了,以免判断错误。等等。
再比如,在资源受限的环境(比如路由器),可执行程序和不可变数据可以做成只读的压缩文件系统,启动后部分解到内存或者按需解开;配置文件需要改变后持久化到闪存;日志通常不需要持久保留。

按 FHS 划分就很容易为不同业务功能但相同作用的文件设置统一的存储策略。而按业务领域划分,从这个角度看反而是散乱的。
6 天前
回复了 huyangq 创建的主题 Linux 关于 Linux 下面的 包管理器的 疑惑
我见过很多不做运维的纯开发人员都对 FHS 困惑和反感😄

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
6 天前
回复了 autoxbc 创建的主题 CSS CSS 的缩进写法没有普及令我感到诧异
CSS 是没有层级的,有层级的是 DOM
8 天前
回复了 awanganddong 创建的主题 MySQL mysql 表查询语句优化
把这些浮点和三角函数预先计算出来存成列试试?
这些也算软技能吗?明明都是硬梆梆的。
OO 大沙文主义终于在 JS 程序员圈也取得了胜利😄
建议你说服领导,把公司的操作系统环境统一,至少生产环境要统一,开发环境谁不愿意跟着走的要自己负责由此导致的兼容性问题。
就是说,你改好软件功能,测试通过了,要打包了,假设你公司的生产和开发环境使用以下发行版+版本,那……
拉起一个 centos 8 (或者 alma 8 、rocky 8 、龙蜥 8 )的 docker ,在里面打出 -el8 的 rpm 包;
拉起一个 centos 7 的 docker ,在里面打出 -el7 的 rpm 包;
拉起一个 debian 11 的 docker ,在里面打出 -bullseys 的 deb 包;
拉起一个 ubuntu 20.04 的 docker ,在里面打出 -focal 的 deb 包。
把这 4 次拉起 docker 写成一个批处理脚本自动跑完就好。
@liuguangxuan 不清楚用 cmake 如何自动识别发行版再打包……但正常的做法是,当软件出新版之后,用批处理流程为支持的每个发行版+版本组合自动起相应的 docker ,在 docker 里面打包。可以参考有个开源 API 网关叫 APISIX 的 build 系统 apisix-build-tools ,使用时可以通过参数指定包格式、发行版、版本号,只要自己写一个脚本来批量多次调用打包工具就行了。
@liuguangxuan Linux 的软件安装是个很复杂的生态。可以不管发行版,自己从上游软件的源代码开始编译安装,也可以不用管 File System Hierachy 规定的什么文件放在什么目录……实际上大部分上游软件编译之前的 configure 或类似阶段的默认值就是不遵循 FSH 的。但有发行版在,对于普通用户节省了挑选上游软件具体版本测试其搭配的兼容性的精力。

同时,发行版会在自己编译开源软件时做一些风格上的适配,比如约定不同类别的文件放在什么路径、后台服务程序用什么机制启动、配置文件如何细分到各种**.d 里以便把插件的配置和主配置分开方便自动修改、日志文件如何定时切分,等等。

rpm 和 deb 是两大主流发行版 RH 系和 Debian 系的“御用”格式,发行版本身包含的组件(比如 Debian 当前版本里有 8 万多个软件)是用这两种格式来打包的。通常比起上游来经过了一系列统一风格的改造。理论上是可以跨越发行版混装的,但实际上有很多问题,有些能装成功有些则不行。所以正常的做法是,写好 spec/rules 然后针对用到的特定目标发行版和目标版本来做自动打包,当然 spec/rules 是有兼容性问题的,也要好好适配同一发行版的不同版本。你厂 IT 基建环境基本为 0 的话而你又要兼作基建的话,那强烈建议现阶段尽量减少发行版 /版本的数量。比如都统一到 Debian 或者 CentOS 的一两个版本上。暂时统一不上去的,以后逐步改版替换。操作系统版本迭代导致的屎山,等以后再去想办法治理,现阶段既然是 0 ,还是尽量简化。

还有很多开源软件(有的闭源软件也是),是发行版不会包含或者还没收录的,上游作者有时候也会打包成 rpm 或者 deb ,让用户能以使用发行版的相同操作风格来管理。甚至有些体积很大的,比如 GitLab ,比如 Elastic Search 。

但是打包 rpm 或 deb 往往是个吃力不讨好的事,因为很多人(尤其是纯开发角色的)其实不太在乎运维方面的讲究,他们更喜欢一个 tar.gz 原地解压后的 everything-under-prefix 方式,认为这样更方便和自由,而 rpm 或 deb 里遵循 FHS 等规范的生产环境打包方式对开发来说太麻烦了,比如要考虑各种路径的权限、执行时的用户身份等,而且“散落”在不同的地方,开发过程中查找起来麻烦,等等。在企业里,基建团队打包 rpm/deb 是不产生直接的业务绩效的,开发团队对这些玩意的认可度也不高。所以往往会有企业根据自己踩过的各种坑自己搞得各种“最佳实践”。其实长线下来 rpm/deb 的学习成本未必高,但是起点高,要学一大堆不能马上产生绩效的“乱七八糟”的东西,而且很可能不讨大部分开发人员喜欢。所以大部分厂的业务型软件都不太用发行版包的方式来发布。

所以,虽然我自己(一个甲方的综合信息化人员)比较喜欢按发行版打包、按 FHS 布局的行为,但在这贴里还是建议你慎重考虑。因为精力投入会比较大,不产生业务绩效,而且不太容易被其他人接受。看看这贴里的很多回复就知道了。当然,如果你觉得值得,自己能 hold 住,说不定会成为业界尤其是国内业界与众不同的一股清流( or 泥石流)。


另外,还有值得一提的是,发行版的打包方式,其实是很传统的了。在云原生时代,很多软件对于外部依赖组件所采取的 vendoring 策略跟发行版打包是矛盾的。Debian packaging team 曾经尝试把 K8S 给 deb 化,但 K8S 特定版本和 Debian 特定版本的第三方依赖锁定版本冲突,始终没办法很好解决,最后终于放弃。LWN 上还曾经专门有一篇讨论。最后的结论是,三观不同没法强融。
1  2  3  4  5  6  7  8  9  10 ... 24  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1142 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 44ms · UTC 20:18 · PVG 04:18 · LAX 13:18 · JFK 16:18
Developed with CodeLauncher
♥ Do have faith in what you're doing.