Ubuntu 15.04の大きな変更点は、起動およびシステムサービスの起動を管理するためのデフォルトとして、upstartからsystemdへの切り替えです。
技術に詳しくないユーザーに、これが私たちにどのような影響を与えるのか、またどのように影響するのか、誰でも適切に説明できますか？そして、なぜそれが重要なのでしょうか？
Ubuntu 15.04の大きな変更点は、起動およびシステムサービスの起動を管理するためのデフォルトとして、upstartからsystemdへの切り替えです。
技術に詳しくないユーザーに、これが私たちにどのような影響を与えるのか、またどのように影響するのか、誰でも適切に説明できますか？そして、なぜそれが重要なのでしょうか？
回答:
レイマンユーザーは、設計上、変更に気付かないはずです。これは初期化システムであり、ユーザーが伝統的にやり取りするものではありません。Upstartが提供する機能を完全に置き換える必要があります（さらにいくつかの追加操作を行う必要があります）が、技術に詳しくないユーザーに表示されるのは、問題が発生したときだけです。
Upstartを積極的に使用および開発してきたユーザー、システム管理者、および開発者は、物事に取り組む必要がある人々です。Ubuntu Wikiには、開発者が初期化スクリプトを変換するのに役立つ移行ドキュメントがありますが、ユーザーとsysopは14.04（2019年までサポートされます）を維持することでUpstartの使用を継続できます。
変更の理由と理由は、Ubuntu側からではありませんでした。CanonicalはUpstart（プロジェクト）に十分満足していましたが、多くのDebianユーザーは、ブート時の同時実行性とすべてのサービスの監視機能を向上させるために、最新のinitエンジンに移行したいと考えました。
それは、さまざまな選択肢（理論的根拠）間の戦いを意味し、 systemdは最終的に勝ちました。
CanonicalはDebianと一緒に行きました。これはDebianが最も簡単で、おそらく最高だからです。彼らはプロジェクトをドロップし、上流で戦っていません。また、systemdに移行している他のディストリビューション（Red Hat、Fedoraなど）とも一致します。より集中し、労力の重複を減らします。
tl; dr技術者でない人にとっては、これはあなたにまったく影響を与えるべきではありません。Ubuntuの場合、作業量が少なくなり、初期化システムが改善されます。
技術に詳しくないユーザーに、これが私たちにどのような影響を与えるのか、またどのように影響するのか、誰でも適切に説明できますか？
理論的には、これは、システムが実際にどのように機能するかという核心に関与しない非技術的なエンドユーザーに影響を与えるべきではありません。実際には、あなたが目にする多くのものがあります。
不完全なリストは次のとおりです。
init+ から来る他のLinuxオペレーティングシステムユーザーrcsystemdがSystem 5との後方互換性しかないという事実に噛まれrcます。新興企業や他のほとんどのシステムと同様に、System 5 initおよびその構成ファイルとの後方互換性はありません/etc/inittab。したがって、「まあ、これを編集して/etc/inittab…」とアドバイスする30年の人々からのアドバイスに従った人々、またはそのアドバイスに従ったソフトウェアを使用する人々は、今ではブートストラップで開始しないソフトウェアを持っています。例：https : //unix.stackexchange.com/a/196197/5132
shutdownshutdownshutdown nowsystemctl rescue--userオプションを使用してコマンドを実行することについて人々が話しているのを見るでしょうsystemctl。Ubuntuには適用されません（まだ）。upstartとsystemdはこの分野で大きく異なり、Ubuntuバージョン15 では、systemd のユーザーごとのインスタンスではなく、upstart のセッションごとの初期化が引き続き使用されます。だからhttps://superuser.com/a/860598/38062例えば、適用されません。☺すでに他の人がここで指摘しているように、理論的には、これは非技術的なエンドユーザーに影響を与えるべきではありません。
ここに投稿されたものには、いくつかの説明が必要だと思います。
これは初期化システムであり、ユーザーが伝統的にやり取りするものではありません。
SysV initとUpstartの場合はそうでしたが、systemdの場合はそうではありません。それはありません多くのユーザー伝統的相互作用を持つもののを：
Upstartが提供する機能を完全に置き換える必要があり、さらにいくつかの追加処理を行う必要があります。
明確にする2つのこと-最初にUpstartを完全に置き換えることについて：
systemdに関して人々が抱える問題の1つは、SysV initスクリプトを実行しないことです。そのため、Upstartが提供する機能を完全に置き換えない例が1つあります。
これは30年以上も頼ることができたもので、伝統的にSysV initスクリプトを書いて、同じスクリプトの複数のバージョンを書くことで自分自身を繰り返すことなく、移植性を最大限に高めました。
公式リポジトリのパッケージのみを使用する場合、これは問題になりません。おそらく、SysV initまたはUpstartスクリプトを使用していたすべてのパッケージは、パッケージ化する前にスクリプトを書き換える必要があるためです。
これは、SysV initまたはUpstartのいずれかのためにinitスクリプトが記述されたサードパーティまたはカスタムソフトウェアを使用する人にとってのみ問題になり、systemdを使用してシステムにアップグレードする前にinitスクリプトを書き換える必要があります（またはget オプションであるupstartをインストールするか、systemdを使用しないシステムに移行します）。
SysV initスクリプトをsystemdスクリプトに自動的に変換することになっているsystemd-sysv-generatorがありますが、いくつかのバグと明示的な非互換性の長いリストがあります。
次に、2番目の説明-これらのいくつかの余分なものについて：
systemdがカバーする「いくつかの余分なもの」-systemdの展望- 達成されたもの、および 2014年のGNOME.asiaでのLennart Poetteringによるプレゼンテーションは、次のとおりです。
「これは初期化システムであり、ユーザーが伝統的にやり取りするものではありません。」-initシステムはそのリストの1つのアイテムにすぎないことを指摘する必要があります。
そして最後に、私が最後にコメントしたいこと：
[T]技術者でないユーザーがこれを見るのは、それがうまくいかないときだけです。
ああ、なんて安心。:)
（スクリプト自体を除く）エンドユーザーにとって最も注目すべき変更は、サービスの開始と停止、および次のようなコマンドの使用です。
期待どおりに動作しなくなりました。たとえばnohup、セッションからログアウトした後にプロセスが実行し続けることを確認するPOSIXコマンドです。それはもはや機能していないにsystemdに。また、のようなプログラムscreenとtmux特別な方法で呼び出されるか、そうでなければ必要性あなたも一緒に実行することをプロセスが殺されます（殺されたそれらのプロセスを取得していない間は、通常、最初の場所での画面やtmuxのを実行しているの主な理由です）。
これはバグではなく、設計上の選択であるため、将来修正される可能性は低いです。これが、レナート・ポエタリングがこの問題について言ったことです。
私の見解では、ログアウト後にデフォルトで任意のユーザーコードが制限されないままでいるということは、実際にはUNIXではかなり奇妙でした。これは多くのOSの人々の間で長い間議論されてきましたが、これは可能ですが、確かにデフォルトではありませんが、これまでスイッチを切り替えてデフォルトからオプションに切り替えることを誰も敢えてしませんでした。ログアウト後にユーザーセッションをクリーンアップしないことは、見苦しくてややハッキングされているだけでなく、セキュリティ上の問題でもあります。 systemd 230は最終的にスイッチを切り替え、最終的にユーザーがログアウトするとすべてが正しくクリーンアップされるようになりました。
詳細については、以下を参照してください。
screenscreensystemd-run --user --scope screen（注：上記の「upstart」の動作は、実際にはsystemd以外のものであり、これはupstart固有ではありません）
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status（この質問の範囲外の詳細については、Upstartとsystemdの賛否両論についての私の答えをご覧ください。）
Unixの伝統に反して、systemdのログはカスタム形式のバイナリファイルに格納されるため、ログの処理にも大きな違いがあります。
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
ログにアクセスするには特別なコマンドを使用する必要があります。
sudo journalctl -u foo
sudo journalctl -u foo -f
systemdを最初にDebianに導入し、後にUbuntuに導入したことには、以下の記事のいずれかを書いた人なら誰でも知っているように、論争や大きな反対がなかったわけではありません。
systemdに対するDebianの公式の立場とその結果としての論争は、2014年の出エジプト宣言につながり、Ian Jacksonの辞任で終わりました。
Init Freedom、 Without-Systemd.orgおよび Systemd-Free.orgイニシアチブが生まれ、 Hacker Newsに関する多くの議論が行われました。