Dockerじゃないsystemd-nspawn＋machinectlが非常に良い
前回、 自作FRPライブラリTimeEngineをブラッシュアップして http://timeengine.github.io/ を公開しました。 次回は、その日本語訳、 Reactの応用技術、あるいはReact再入門についての記事をUPしますのでお楽しみに！ と書いていたのですが、Dockerじゃないsystemd-nspawn＋machinectlが非常に良い、ので予定を変更して、こちらを先にエントリします。いろいろ印象を忘れないうちに。TimeEngineに関してはとりあえず自分がすでに英文で書いたものを和訳してどこかにUPしておいたほうが、何か別展開や国内のためになるかな程度のことなのでお急ぎの方は上記リンクから英文読んでください。そちらも全部仕上がっているとは言えないですし、行き届いていないところをセルフチェックするために和訳もしておこうという感じです。 実用的で枯れた技術「コン
なぜsystemdなのか？ | POSTD
このブログ記事は2014年5月21日に行った私の講演の内容に基づいています。 ここ数年、GNU/LinuxのディストリビューションはSysV initを避ける傾向にあり、代わりに多種多様な新しいinitシステムへと移行が進んでいます。SysV initに満足しているユーザにとっては、これは予想外の流れでしょう。問題なく使えるのに、なぜ多くのディストリビューションはSysV initに背を向けているのでしょうか。 この記事ではSysV initの問題点と、それに対してsystemdがどんな解決法を提供しているのか説明してみようと思います。 私は特にsystemdの大ファンだというわけではなく、ただ広く使われているツールだという認識以上の思い入れは無いことだけお断りしておきます。 initシステムの役割とは何か？ コンピュータが起動する時には、ビルトインされたファームウェア（コンピュータの場合
Systemd入門(1) - Unitの概念を理解する - めもめも
Linuxの起動処理は、これまでinit/upstartと呼ばれる仕組みで行われていました。Red Hat Enterprise Linux 7 (RHEL7)では、これが、systemdと呼ばれるまったく新しい仕組みに置き換わります。Fedoraでは、すでに先行してsystemdが採用されていますが、この連載（？）では、Fedora 17での実装をベースとして、systemdの考え方や仕組み、利用方法を説明していきます。今回は、systemdの動作の基礎となる「Unit」の概念を理解します。 systemdを採用したFedoraでLinuxの基礎を学びなそう！という方には、「「独習Linux専科」サーバ構築/運用/管理――あなたに伝えたい技と知恵と鉄則」がお勧めです。(^^/ systemdの考え方 参考資料 ・Rethinking PID 1：systemdの開発者であるLennart
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hello, systemd
