就从目前整个应用体验来说 sysvinit 强过 systemd
其一 内存占用，MGC2.6 占用内存不超过 300M，MGC3 占用 500M 左右。其二Option "metamodes" 效果不佳，每次重启后就出现屏幕超出显示，需要重新设置
其三 KDE 经常无法重启或关闭，组件的变动都可能要重新编译 systemd 来缓解 KDE 重启或关闭问题。
其四 udev 对 kvm 的强行绑定，使得本来很优秀的默认显示驱动得不到应用
其五 fstab 如果出现任何挂载错误或者 mtab 出现某些错误将不能进入 X 服务，容错能力非常低下。
其六 兼容性一般，并且编译依赖不透明，并不是所有版本的 systemd 适合你目前的系统环境。
还有很多说不清的东西。。。 很多不接受systemd的人，就质疑它这个东西的不透明，很多时间弄不清他怎么启动的。
不过整体来看，sysvinit肯定会被systemd替代的。 sysvinit 确实不符合当前的形势了。
不过 systemd 太追求于大而全了。
我觉得 systemd 最好还是把他的功能拆开，做成插件化的比较合适。systemd 的核心尽可能小，插件就可以按需选择了。
其实我觉得最终的解决办法，应该还是内核直接接管 init 过程，这样很多服务或者响应，直接就是内核级的调用，性能和功能都更好。 原帖由 sejishikong 于 2014-6-7 20:43 发表 http://forum.linuxfans.org/images/common/back.gif
很多不接受systemd的人，就质疑它这个东西的不透明，很多时间弄不清他怎么启动的。
不过整体来看，sysvinit肯定会被systemd替代的。
我觉得 sysvinit 近期是不会被淘汰的，最新版本的内核仍然保持对 sysvinit 启动方式的支持，反倒是 systemd 需要变革，目前没有即稳定又快速的启动方式。因为 systemd 和 pulseaudio 是同一作者，而被广泛采用的这两组件又是最恶心最有争议最不稳定的东西，再加之据说 linus 对 systemd 开发者成员之一乱改其内核源码表示愤怒，所以我对这两个项目真的没有好感，它带给我的麻烦比方便还要多。
另外 systemd 编译出错时根本没有地方能有效找到出错原因。
早前红旗的社区 CJACKER 做过加快启动速度的创新，可惜都没有成气候就丢弃了。 原帖由 haulm 于 2014-6-7 23:20 发表 http://forum.linuxfans.org/images/common/back.gif
我觉得 sysvinit 近期是不会被淘汰的，最新版本的内核仍然保持对 sysvinit 启动方式的支持，反倒是 systemd 需要变革，目前没有即稳定又快速的启动方式。因为 systemd 和 pulseaudio 是同一作者，而被广泛采用的这两组件又 ...
那个其实类似于现在windows上的服务延迟启动，和systemd的想法不一样的。
systemd的主要想法在并行上。 我已经在上传 MGC 2.6.6 了，升级了 Qt-4.8.6 kernel-3.14.5 python-2.7.7，重编译了依赖部份。
目前从应用上来说 32 位才是需求，对应整个 Linux 共享软件应用生态是这样的，PPStream for Linux 还能用哈。
没有对 MGC 2.6.6 更换启动方式，因为 MGC3 的 systemd 应用虽然没有问题了，但一些没有搞定的问题:
比如有机率 KDE 无法重启或关闭，这个 BUG 安同系统也是有的。MGC3 如果我们没有力量开发自己的启动程序或修改 systemd，那么 systemd 的动画也将要去掉，因为 X 到终端卡在动画需要快捷切换，而重启不了可能也是动画的原因。
MGC 2.6.6 仍然对下载的一些 KDE 窗口风格应用会无法进入 KDE，这个问题挺麻烦，我是有准备出一个 2.6.7 升级一下
各应用组件，底层的一些系统组件就算了。 systemd214克服了好多问题，关机变得很稳定正常。
页:
[1]