2016更新
这里的大多数答案都已经有5年了，所以是时候进行一些更新了。
Ubuntu以前默认使用upstart，但去年却放弃了它，转而使用systemd-请参阅：
因此，在Ubuntu Wiki上有一篇不错的文章《针对Upstart用户的Systemd》 -非常详细地比较了upstart和systemd，以及从upstart到systemd的过渡指南。
（请注意，根据Ubuntu Wiki，您仍然可以通过安装upstart-sysv和运行默认情况下在默认版本的Ubuntu上运行upstart，sudo update-initramfs -u但考虑到systemd项目的范围，我不知道它在实践中如何工作，或者systemd是否在可以卸载。）
下面的“命令和脚本”部分中的大多数信息都是根据该文章中使用的一些示例改编而成的（就像在Creative Commons Attribution-ShareAlike 3.0许可下的Stack Exchange用户贡献一样，已被方便地许可）。
这是常见命令和简单脚本的快速比较，请参阅以下各节以获取详细说明。该答案是将问题中要求的基于Upstart的系统的旧行为与基于systemd的系统的新行为进行比较，但是请注意，标记为“ Upstart”的命令不一定是特定于Upstart的-它们通常是每个非系统Linux和Unix系统都通用。
指令
运行su：
- 暴发户：
su
- systemd：
machinectl shell
（请参阅下面的“ su命令替换”部分）
运行画面：
- 暴发户：
screen
- systemd：
systemd-run --user --scope screen
（请参阅下面的“意外终止后台进程”部分）
运行tmux：
- 暴发户：
tmux
- systemd：
systemd-run --user --scope tmux
（请参阅下面的“意外终止后台进程”部分）
开始工作foo：
- 暴发户：
start foo
- systemd：
systemctl start foo
停止作业foo：
- 暴发户：
stop foo
- systemd：
systemctl stop foo
重新启动作业foo：
- 暴发户：
restart foo
- systemd：
systemctl restart foo
列出工作：
- 暴发户：
initctl list
- systemd：
systemctl status
检查作业foo的配置：
- 暴发户：
init-checkconf /etc/init/foo.conf
- systemd：
systemd-analyze verify /lib/systemd/system/foo.service
列出作业的环境变量：
- 暴发户：
initctl list-env
- systemd：
systemctl show-environment
设置作业的环境变量：
- 暴发户：
initctl set-env foo=bar
- systemd：
systemctl set-environment foo=bar
删除作业的环境变量：
- 暴发户：
initctl unset-env foo
- systemd：
systemctl unset-environment foo
日志
在upstart中，日志是/ var / log / upstart目录中的普通文本文件，因此您可以照常进行处理：
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
在systemd中，日志以内部二进制格式（而不是文本文件）存储，因此您需要使用journalctl命令来访问它们：
sudo journalctl -u foo
sudo journalctl -u foo -f
剧本
用编写的示例新贵脚本/etc/init/foo.conf：
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
用以下脚本编写的示例systemd脚本/lib/systemd/system/foo.service：
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
su命令替换
一个su命令替换被合并到拉请求＃1022 systemd：
因为根据Lennart Poettering的说法，“ su确实是一个破碎的概念”。
他解释说：“您可以像以前一样使用su和sudo，但是不要指望它会完全起作用 ”。
现在，实现类似su行为的官方方法是：
machinectl shell
Lennart Poettering
在发布问题＃825的讨论中作了进一步
解释：
“嗯，对此进行了长时间的讨论，但是问题在于，su应该做的事情还很不清楚。 ，也可以使用它，但它不是完整的登录名，不应将其误认为一个登录名。” -Lennart Poettering
也可以看看：
意外杀死后台进程
像这样的命令：
不再按预期工作。例如，nohup是POSIX命令，用于确保从会话注销后该进程继续运行。它不再适用于systemd。诸如此类的程序screen以及tmux需要以特殊方式调用的程序，否则与它们一起运行的进程将被杀死（而未杀死这些进程通常通常首先是运行screen或tmux的主要原因）。
这不是一个错误，这是一个经过深思熟虑的决定，因此将来不太可能解决。这就是伦纳特·珀特林说这个问题：
在我看来，对于UNIX来说实际上是很奇怪的，它默认情况下允许任意用户代码在注销后保持不受限制的状态。许多操作系统人士已经讨论了很长时间了，这应该是可能的，但肯定不是默认值，但是到目前为止，没有人敢将开关从默认设置转换为选项。注销后不清理用户会话不仅丑陋而且有些骇人听闻，而且还是安全问题。 现在，systemd 230最终翻转了开关，并最终默认情况下在用户注销时正确清理了所有内容。
有关更多信息，请参见：
高级启动概念
以某种方式systemd向后工作-在新贵的工作中尽快开始，而在systemd的工作中必须尽快开始。归根结底，两个系统都可以以几乎相同的顺序启动相同的作业，但是您可以从相反的方向来看。
这是Systemd for Upstart用户的解释方式：
Upstart用于启动流程（作业）的模型是“基于贪婪事件的”，即，发生启动事件的所有可用作业都应尽早启动。在启动过程中，新贵将一些启动事件（例如启动或rcS）作为“树根”进行合成，早期服务在这些事件上启动，后来服务在前者运行时启动。一个新作业只需要将其配置文件安装到/ etc / init /中即可生效。
systemd用于启动过程（单元）的模型是“基于懒惰的依赖关系”的，即，仅当某个其他启动单元依赖于该单元时，该单元才会启动。在引导过程中，systemd启动一个“根单元”（default.target，可以在grub中覆盖），然后可传递地扩展并启动其依赖项。一个新的单元需要添加自身作为引导序列（通常是multi-user.target）的一个单元的依赖关系，以便激活。
发行版中的用法
现在根据维基百科的一些最新数据：
默认情况下使用新贵的发行版：
默认情况下使用systemd进行分发：
（有关最新信息，请参阅维基百科）
既不使用Upstart也不使用systemd的发行版：
争议
在过去，有人提出了Debian的fork来避免systemd。该Devuan GNU + Linux的创建- Debian的无systemd叉子（感谢fpmurphy1指点出来的评论）。
有关此争议的更多信息，请参见：
你们中许多人可能已经知道，伊恩·杰克逊（Ian Jackson）提倡的Init GR Debian投票对于保护Debian的遗产及其用户免受系统性的雪崩袭击并没有帮助。
这种情况预示着系统依赖的锁定，这实际上威胁着发展自由，并对Debian，其上游和下游产生严重后果。
CTTE设法通过依赖于sysvinit的微妙安装systemd来交换依赖关系并为我们赢得了时间，但是即使这个过程也很累并且充满了戏剧性。最终，一周前，伊恩·杰克逊（Ian Jackson）辞职。[...]
我将从技术委员会辞职，立即生效。
虽然重要的是应继续在我的技术委员会中代表与我同意的项目的30-40％的意见，但我本人现在显然太有争议了，不能这样做。我应该退后一步，以减少有关项目治理的对话的个性化程度。[...]
Devuan诞生于关于将其用作Debian的默认初始化系统的争议。Debian在systemd上的官方立场充斥着其他人揭穿的主张。有兴趣的读者可以在“系统性争议”中继续讨论这个热门话题。但是，我们鼓励您保持冷静，保持声音平和。在Devuan，我们对错误的编程比回头更感兴趣。[...]
已经创建了一些有关systemd争议的网站和文章：
有很多 Hacker News上有趣的讨论的：
在其他发行版中也可以观察到类似的趋势：
哲学
暴发户遵循DOTADIW的Unix哲学-“做一件事情，做好事”。它替代了传统的init守护程序。除了启动和停止服务之外，它没有任何其他作用。其他任务则委托给其他专门的子系统。
systemd的功能远不止于此。除了启动和停止服务之外，它还管理密码，登录名，终端，电源管理，工厂重置，日志处理，文件系统挂载点，网络连接以及更多功能- 有关某些功能，请参阅NEWS文件。
扩张计划
根据一种systemd的角度看，已经实现了，而什么样的未来由伦纳特·珀特林在2014年GNOME.asia介绍，这里是systemd的主要目标，即已经覆盖和那些仍在取得进展的领域：
系统目标：
我们的目标
已经涵盖的领域：
我们已经介绍的内容：
初始化系统，日志记录，登录管理，设备管理，临时和易失性文件管理，二进制格式注册，背光保存/还原，rfkill保存/还原，引导图，预读，加密存储设置，EFI / GPT分区发现，虚拟机/容器注册，最小容器管理，主机名管理，语言环境管理，时间管理，随机种子管理，sysctl变量管理，控制台管理等。。。
工作正在进行中：
我们正在从事的工作：
- 网络管理
- 系统联网
- 本地DNS缓存，mDNS响应器，LLMNR响应器，DNSSEC验证
- 内核中的IPC
- kdbus，sd-bus
- 与NTP时间同步
- 系统时间同步
- 与容器的更多集成
- 服务沙箱
- 应用程序沙箱
- 操作系统映像格式
- 容器图片格式
- 应用图片格式
- 具有自动发现功能的GPT
- 无状态系统，可实例化系统，出厂重置
- / usr是操作系统
- / etc是（可选）配置
- / var是（可选）状态
- 原子节点初始化和更新
- 与云整合
- 跨节点的服务管理
- 可验证的操作系统映像
- 一直到固件
- 引导加载
该答案的范围
正如fpmurphy1在评论中指出的那样，“应该指出，多年来systemd的工作范围已远远超出了系统启动的范围。”
我试图在这里包括大多数相关信息。在这里，我将按照问题中的要求比较Upstart和systemd用作初始化系统时的常见功能，我只提到systemd的功能超出了初始化系统的范围，因为这些功能无法与Startup进行比较，但是它们的存在很重要了解这两个项目之间的区别。应该检查相关文档以获取更多信息。
更多信息
可以在以下位置找到更多信息：
附加功能
该LinOxide团队创造了一个Systemd VS SysV初始化的Linux的cheatsheet。