残念なことに、私はこのテキストのロシア語の翻訳を見つけられませんでしたが、私には非常に...啓発的、または何かに思えました。
サイン1：sudoを使用しません
両方のCAPS LOCKは「タフガイのためのクルーズコントロール」であり、sudoは「疑わしい人のための松葉杖」です。 rootとして何かをする必要がある場合は、sudoのようなゴミではなくsuを使用します。 Unixライクなオペレーティングシステムのいずれかがsudoの使用を強制する場合、最初に行うことはsudo suであり、rootユーザーが将来suを快適に使用できるようにパスワードを設定します。 sudoを絶え間なく使用することは、腹部にゴムの輪を置いて泳ぐことと比較できます-はい、より安全ですが、行動について考える必要はありません。
症状2：emacsではなくviを使用しており、picoまたはnanoを使用していない
emacsは多くのUnix管理者の心に近いものですが、実際にはMicrosoft Word for Unixと同等です。 Vi（特にvim）は、emacsが持っているナンセンスなしで必要なことをすばやく実行する必要がある、厳しいUnixの第一人者の本当のツールです。 Emacsには、やるべきことをするための血まみれのテトリスが組み込まれています。
コードの折り畳みや構文の強調表示など、vimのこれらのホイッスルや偽物はすべて完全なゴミとして認識されますが、脳がすでに弱い場合、viのモーダル編集の概念は非常に役立ちます。 その結果、すべてのプラットフォームのサイズが小さく存在するため、唯一のTrue Editorが作成されます。 ありがとう、ビル、ありがとう、ブラム。
サイン3：正規表現は私たちの武器です
初心者にとっては、無害な正規表現でさえ、キーボードが病気のように見えます。 私たちにとって、これは純粋で真の詩です。 pcreの複雑さに含まれるパワーは、他のツールとは比べ物になりません。 10万行のファイルで3文字ごとに順番に置き換える必要がある場合（4文字目が4文字の場合を除く）、正規表現は単なる優れたツールではなく 、そのようなタスクの唯一のツールです。 そして、正規表現を恥ずかしがる人は、自分自身だけでなく同僚にも害を及ぼすだけです。 厳しいUnix管理者には、正規表現の鑑識家が何人かいます。これらの男たちは、正規表現の例や、解読の涙ぐましい要求を含む大量の電子メールメッセージを絶えず送信しています。
サイン4：私たちは本質的に怠け者です
問題を解決するために多くの反復的なルーチンが必要な場合、それを実行するコードを記述することを常に好みます。 これは通常、近接法よりも時間がかかりませんが、常にではありません。 とにかく、今ここで問題を解決するよりも、後で再利用できるものを作成する可能性が高くなります。 通常、これは数年後、同様の問題に遭遇し、ホームディレクトリの袖から数百行のPerlコードを引き出し、数分で問題を解決してコードの改善に戻るときに便利です。 または、Angry Birdsの未完成の3つ星レベルまで。
特徴5：エレガントなソリューションを好む
問題を解決したり目標を達成する方法がいくつかある場合は、石膏に包まれたサポートを迅速に構築するのではなく、現在の問題を解決するだけでなく、将来起こりうる結果を解決する根本的な解決策により多くの時間を費やすことをお勧めします。 これは、すでに頭の中で「解決済み」とマークされている問題に再び取り組むことを嫌うという事実によるものです。 いくつかの余分なジェスチャーで今すぐ将来の問題を解決すれば、明日はもっと自由な時間があることに気付きました。 そして、通常は正しい。
症状6：質問への答えは質問者に依存していると確信している
一定レベルのUnixの啓発を達成するためには、基礎知識に対する絶対的な自信が必要です。 また、自分で問題を見るまで問題を信じないことも意味します。 Unixの厳しい管理者に、ファイルが「消失」したことを伝えると、見返りに軽empt的なreceive笑を受け取ることになります。 これが本当に起こったことを証明してください-そして、彼は振り返らずに問題の解決策に飛び込み、理由と適切な解決策の適切な意味のある説明を見つけるまで掘り下げます。 多くの人がこれを慢またはrog慢の兆候と考えています。 しかし、それは自分自身を謙虚にしている、私たちはそれに値する。
サイン7：医師よりも病理学者に近い
大きな問題に直面して、私たちは現在の問題を解決するのではなく、何が起こったかを分析するのにより多くの時間を費やすでしょう。 少なくとも1分の時間がある限り、問題の原因となったすべての理由を知る必要があります。 厳しいUnix管理者の仕事には魔法はありません。 各イベントは、追跡可能な特定の論理ポイントから成長する必要があります。 要するに、すべてには理由があり、それを見つけるためにイベントの開発のためのすべてのオプションを考え出します。
プロセスを再起動したり、ファイルまたはディレクトリに777権限を発行したりするのは簡単です。 しかし、これは解決策の半分にすぎません。 このプロセスで再起動が必要なのはなぜですか？ 通常のプロセスを再起動する必要はありません。このルールが実行されない理由を知る必要があります。
症状8：表示する以上にWindowsについて知っている
Windowsがマシンにインストールされておらず、Windowsを搭載したサーバーについて少し心配することはありませんが、通常はWindowsの問題の診断と修正が得意です。 これは、これらの問題が私たちの責任範囲に浸透したときにこれらの問題に遭遇したためです。 しかし、ほとんどの場合、WindowsはUnixの深く論理的な原則を共有していないため、これを好まないため、これを認めたくありません。 上記の症状5および6も参照してください。
症状9：再起動は私たちの方法ではありません
Unixコンピュータを再起動する必要はありません。 再起動せずに問題を修正する可能性が少なくとも少しでもある限り、それを試みます。 カーネルまたはハードウェアが変更された場合にのみ再起動が必要であり、再起動の問題に対する解決策は一時的なものです。 問題が一度発生し、再起動によって「解決」された場合、再び表示されます。 再起動するよりも問題の解決策を見つけて、それが再発することを期待します。
これらの原則の一部が単なる人間の観点から非社会的または理解しにくいと思われる場合、それはまさにそうであるためです。 他の人が聞き取れない、あまりにも複雑な方法を見る場合、私たちは長年の訓練、経験、そして最も重要なこととして論理から生まれた啓発を見る。