DebianFork 将发布没有 systemd 的 Debian 分支

Debian 8 Jessie的 init 系统默认使用 systemd,这一选择在社区引发了大量争议,导致了技术委员会的多名成员辞职。现在,“老兵 Unix 管理员”宣布要创建一个新的不使用 sytemd 的  Debian 分支。这群 Unix 哲学拥护者们请求外界 捐赠 支持他们的新使命。

以下内容来自 debianfork.org 的相关内容:

我们是谁?!

我们是老兵 Unix 管理员(Veteran Unix Admins),我们非常关注 Debian GNU/Linux 在 systemd 上的分歧,并且决定分支(fork)Debian 项目。

为什么我们要这样做?

我们中的一些人是上游开发者,一些人是专业的系统管理员:我们每天都要和 Debian 打各种交道。

我们不想被强迫使用 systemd 来替代传统的 UNIX sysvinit 初始化系统,因为 systemd 背离了 UNIX 哲学。

我们考虑采用贴近 sysvinit 的架构,而不是那种破坏了“做一件事,把它做好”的原则、带着数十个紧密耦合的二进制文件和不透明的日志的东西。

有比创建分支更好的解决方案么?

不幸的是,目前没有!

在下一代的 Debian v.8 "Jessie" 发行版中,默认的初始化系统将是 systemd,它将挟裹着一堆紧密纠缠的东西来到。

我们需要分离这些依赖的牵扯,从所有受到影响的软件包中清除这些,并提供相应的替代品。我们所要创建的分支的稳定性是目前阶段所要考虑的首要重点。

你觉得为什么会走到了这一步?

现在的 Debian 项目的领导者受到了 GNOME 开发者太多的影响,而且在项目中考虑了太多的桌面需求的因素,而 Debian 用户却大多数是精通技术的系统管理员。

而且,今天 Debian 正逐渐背离自己最初愿景,也是开源软件的基石:用户至上。这到底是怎么了?所谓的“do-ocracy”开发者和包维护者正在给用户强加他们的选择。

你可以说一下你对 systemd 的意见吗?

套用一下 Eric S. Raymond 在这个问题上的看法,我们认为 systemd 很容易就会发生嬗变,进而臃肿不堪、最后变成了那种讨厌的纠结在一起的毛球。

我们希望能够用可以阅读的 shell 脚本来控制系统的启动,因为可读性能够给我们这些有能力的人更多的控制和洞悉。我们认为,在一个守护进程中集中控制服务、socket、设备、挂载等等,是对传统的 UNIX 哲学的一记响亮耳光。

某些支持 systemd 的人对此的快速回应可以在 forkfedora.org (已经关闭,需要FQ才能看历史归档)上看到。这个页面突出了两者之间的根本不同:systemd 也许对于配置 init 来说很简单,但是它增加了 init 过程中的不透明度。在 systemd 中很明确是这样的:可以通过更少的变量来调整,而通过远超 sysvinit 大小的程序将大部分细节隐藏在一个巨大的二进制程序里面。

ls -lH /sbin/init
  sysvinit: -rwxr-xr-x 1 root root 36992 Jul 14  2013 /sbin/init
  systemd: -rwxr-xr-x 1 root root 1317632 Sep  1 14:41 /sbin/init
# 你也许认为我不够强大,但是你也太胖了!

可以说 systemd 的安全模式更多的依赖于开发者和包维护者,而不怎么指望系统管理员。作为 Debian 用户,我们只是希望不要被强迫必须如此,看看 CTTE 关于这个问题的投票就会知道 ,我们相信这样下去会越来越多的听到用户要求: 放开那个 Init !不要和 systemd 和它的那堆零碎纠缠在一起。

你们能坚持多久?

这不是比谁的胡子更长,放心,毛茸茸的不总是绵羊!

概括一下计划?

“放开那个 Init”( Init Freedom),这是我们的承诺,我们会建立一个 Debian 项目的分支,创建一个新的基础发行版。

这需要一些时间,我们会一步步来。

首先我们会配合 Debian 8 "Jessie" 的发布,给当前的 Debian 用户平滑升级提供一个完整的解决方案。

如果你也需要这个,请帮助我们: 捐赠 或者参与进来。

我们需要谈谈。

当然,您可以写电子邮件给 [email protected] 。

我们也有一些人聚集在 IRC , Freenode 频道号是 #debianfork ,欢迎加入。

可以订阅邮件列表 。喜欢的话来发布意见吧,不管是什么。

只有你们这些家伙吗?

不是,有很多用户都对 systemd 有意见。

有一篇文章是对这个问题的很好的介绍: Systemd: Linux 世界末日的预兆 。

有个 boycott systemd 网站也有一些相关的资料。那里有个叫做   uselessd 的 “systemd 分支”,有些不错的地方和许多笑点(lulz)。

还有人提出了一个 当世界 systemd 了 之后的撤退战略。

在维基百科的 systemd reception 章节也有一些对其提出的批评意见。

谢谢你做的这些,我怎么帮助你们?

老兵 Unix 管理员(Veteran Unix Admins)的一个小型的核心小组正在积极建设分支的相关框架和一些用于开发的基础设施。

这时的捐赠有助于我们确定可以在基础架构上投入多少以及人们的对我们的预期。

如果你会捐赠,那么 来吧 。

如我们现在做的,我们会在此一直更新我们的项目进展。

对于你做的这些,人们是怎么看的?

下面是我们收到的一些邮件(略,请参照 原链接 ),我们会匿名发表这些信息,除非你申明不用。

我们会保密你的邮件地址,并会通知你我们的下一步进展。

时间: 2024-11-02 23:23:56

DebianFork 将发布没有 systemd 的 Debian 分支的相关文章

Debian 7.x 安装教程、网络配置、软件源配置、磁盘分区、LVM、U盘安装、网络安装

目录 一.准备安装Debian系统      1.1Debian简介          1.1.1介绍Debian版本          1.1.2Debian的正式发音          1.1.3Debian软件包管理          1.1.4Debian分支          1.1.5官方网站与文档          1.1.6介绍  Debian 7.1  1.2获得Debian发行版          1.2.1从镜像站点上下载ISO的镜像文件          1.2.2将IS

php 通过exec 创建git分支失败

今天给我们自己的发布系统增加一个新建分支的功能,操作比较简单,但是使用php执行shell命令的时候总是无法push分支到远程,但是登陆服务器执行却是可以的 新建分支命令如下 git fetch --all git checkout -b pmt_20160624_v10.7.4 origin/master  git push origin pmt_20160624_v10.7.4:pmt_20160624_v10.7.4 php大概代码如下,执行这个php文件是定时执行的 <?php $cmd

Git分支管理策略(转)

如果你严肃对待编程,就必定会使用"版本管理系统"(Version Control System). 眼下最流行的"版本管理系统",非Git莫属. 相比同类软件,Git有很多优点.其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便.有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用. 但是,太方便了也会产生副作用.如果你不加注意,很可能

GIt分支管理策略

大纲: 1.前言 2.创建分支 3.切换分支 4.合并分支(快速合并) 5.删除分支 6.分支合并冲突 7.合并分支(普通合并) 8.分支管理策略 9.团队多人开发协作 10.总结 注,测试机 CentOS 5.5 x86_64,Git 服务器版本:git version 1.8.2.1,客户端版本:git version 1.9.2.msysgit.0.所有软件请到这里下载:http://msysgit.github.io/. 1.前言 在上一篇博客中我们主要讲解了Git 远程仓库,相信大家对

持续集成之“分支策略”?

现代版本控制系统(SCM)的作用已不仅仅是保存历史版本,它还是各软件开发组织利用其分支功能实现多人并行开发,提高生产效率的一种工具.对于稍有历史的软件产品来说,一般都会有代码分支的出现,也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入"无尽维护"的泥潭.分支的目的是希望"分而治之",而持续集成的目的是"频繁集成",这二者之间又有哪些联系呢? 在<测试三角形与分段构建策略原则>一文中,咱们说到:由于自动化测试时间

git-【六】分支的创建与合并

在版本回填退里,已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支.截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支.HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支. 一.创建 1.创建分支,合并 首先,我们来创建dev分支,然后切换到dev分支上.如下操作: git checkout 命令加上 –b参数表示创建并切换,相当于如下2条命令 git branch dev git ch

GIT分支管理是一门艺术(转)

英文原文:http://www.nvie.com/posts/a-successful-git-branching-model/ 原文作者:Vincent Driessen 本文经Linux大棚博主总结精简而成. 1 GIT,在技术层面上,绝对是一个无中心的分布式版本控制系统,但在管理层面上,我建议你保持一个中心版本库. 2 我建议,一个中心版本库(我们叫它origin)至少包括两个分支,即“主分支(master)”和“开发分支(develop)” 3 要确保:团队成员从主分支(master)获

Git分支管理策略(转)

如果你严肃对待编程,就必定会使用"版本管理系统"(Version Control System). 眼下最流行的"版本管理系统",非Git莫属. 相比同类软件,Git有很多优点.其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便.有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用. 但是,太方便了也会产生副作用.如果你不加注意,很可能

Git分支合并选择

用Git进行多人协作开发时,必然会合并代码,解决冲突.然而合并代码也是需要点技巧的,如果对一些关键命令没有理解去使用的话,git的版本演进路线就会变得很乱,从而造成了日后维护的一些麻烦. Git上合并代码有git merge 以及 git rebase 两种方式.下面将深入两者的用法以及对两者的适用场景作个总结. 前置知识点 Master分支:首先,代码库应该有一个.且仅有一个主分支.所有提供给用户使用的正式版本,都在这个主分支上发布.这个分支被称为Master分支: Develop分支:主分支