ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    悪魔の証明=無理難題を吹っかけてくる人

    このエントリーを含むはてなブックマーク はてなブックマーク - 悪魔の証明=無理難題を吹っかけてくる人 あとで読む
    ときどき、無茶な要求をしてくる人がいる。
    一体、どのような思考回路を形成しているのであろうか?

    悪魔の証明 - Google 検索

    (参考)
    悪魔の証明 - Wikipedia

    悪魔の証明(ラテン語:probatio diabolica、英語:devil's proof)とは、中世ヨーロッパの法学者によるローマ法解釈において、所有権帰属の証明の困難性を比喩的に表現した言葉である。

    消極的事実の証明
    消極的事実の証明(ないことの証明、Evidence of absence)を、「悪魔の証明」とする使われ方もある。
    また、証明が困難でないことを「悪魔の証明」には当たらないと反論で使うこともある。



    悪魔の証明とは - はてなキーワード

    悪魔の証明とは、「ある事実・現象が『全くない(なかった)』」というような、それを証明することが非常に困難な命題を証明すること。
    例えば「アイルランドに蛇はいる」ということを証明するとしたら、アイルランドで蛇を一匹捕まえて来ればよいが、「アイルランドに蛇はいない」ということの証明はアイルランド全土を探査しなくてはならないので非常に困難、事実上不可能であるというような場合、これを悪魔の証明という。

    新約聖書にあるサタンがイエスを試した逸話から来ている。
    ある論争に際して、そもそも挙証が困難な命題の証明を相手に迫ることもひとつのディベートのテクニックではあるが、それを悪魔の証明だ、と相手が指摘することが挙証責任を転嫁する際の決めぜりふであるということには必ずしもならない。

    注意点
    「『全くない』ことを証明するのは不可能に近い」のであって、「『全くない』のは確実である」という意味ではない。

    また、「ある一連の事実が『全て本当にあった』」ことを証明することも、言い換えれば「その一連の事実に『嘘は全くない』」ことを証明することであり、同様に不可能に近い。
    (補注:すなわち「ある事実・現象の有り無しを『100%』確定するのは不可能に近い」ということである)

    犯罪を犯した証拠はないが、犯罪を犯していないという証拠もないので無罪ではない、などという事例には適用できない。



    他人に責任転嫁する論法には、様々なパターンがある。
    無理な要求に対しては、アサーティブなコミュニケーションによって、断るようにしたい。

    図解 自分の気持ちをきちんと「伝える」技術―人間関係がラクになる自己カウンセリングのすすめ
    平木 典子
    PHP研究所
    2007-05-01
    ¥ 1296

    Linuxのディレクトリー数とファイル数の上限

    このエントリーを含むはてなブックマーク はてなブックマーク - Linuxのディレクトリー数とファイル数の上限 あとで読む
    Linuxのファイルシステムで、1つのディレクトリーにどれくらいファイルやディレクトリーを配置できるのだろうか?
    理論上は無限だったとしても、多くなればなるほどアクセス速度が遅くなって、実用性が失われるだろう。

    Linux ファイルシステム ディレクトリ 階層 深さ アクセス 速度 - Google 検索

    (参考)
    pxt | OS依存:ファイルシステムの文字数の上限について
    ファイル数・ディレクトリ数

    昔、Linux 上で 1つのディレクトリの直下に 30000個 強のディレクトリを作ったら落ちるという現象に遭遇したことがある。
    こちらによると、一つのディレクトリに 32768 のサブディレクトリの上限があり、一つのディレクトリ内のファイル数は、実運用上約 10000~15000 個が上限 とある。
    システム全体の数は i-node によると書かれている。



    Linuxは1ディレクトリに大体ファイル数を 1万ファイル位(まあ大… - 人力検索はてな

    1ディレクトリ内のディレクトリ数の制限はあるのでしょうか?

    ここに情報があります。
    https://jp.linux.com/JF/JFdocs/kernel-docs-2.4/filesystems/ext2.txt.html
    > 一つのディレクトリに 32768 のサブディレクトリの上限があります。
    > 現行の単方向リンクのリストによるディレクトリの実装で、一つのディレクトリ内のファイル数は、実運用上約 10-15k 個が上限になります。
    > この制限はこのような大きなディレクトリ内のファイルを作成および削除 (さらに検索) する時のパフォーマンスの問題のためです。

    実用上、15000 までは OK との見解ですね。



    サブディレクトリ―の数やファイル数は、10000個~15000個程度にしておくのが無難、という情報がヒットしました。
    (やや古い情報だったので、最新の情報は分かりません。)

    ファイルシステムの改良によって上限は増えていくでしょうが、一つの目安として、実用上はこの程度だと覚えておくと良いのかもしれませんね?


    ゼロからはじめるLinuxサーバー構築・運用ガイド 動かしながら学ぶWebサーバーの作り方
    中島 能和
    翔泳社
    2016-07-06
    ¥ 2894

    UNIXの哲学

    このエントリーを含むはてなブックマーク はてなブックマーク - UNIXの哲学 あとで読む
    ここ最近、関数型プログラミング言語について学んでいる。
    Lisp、Haskell、OCaml、Elixirなど。

    どうせ、計算機で動かすのは同じだから、プログラミング・パラダイムが命令型でも宣言型でも、本質的には大差ない。
    (計算可能性理論では、チューリング完全であれば十分)
    しかしながら、その設計思想には違いがある。

    関数型言語は、文字通り「関数」を作る。
    関数の合成が、計算機で計算する手順となる。

    で、この関数の作り方なんだけど、「シンプルイズベスト」で、簡潔であればあるほど分かりやすくなる。
    Elixirの本を読んで、関数型言語はUNIX哲学と同じだと分かった。

    プログラミングElixir
    Dave Thomas
    オーム社
    2016-08-19
    ¥ 3024


    UNIXという考え方―その設計思想と哲学
    Mike Gancarz
    オーム社
    2001-02-01
    ¥ 1728


    UNIX哲学 - Wikipedia

    UNIX哲学とは、ソフトウェア開発に関する文化的な規範と哲学的アプローチのまとまりであり、UNIX OSの先駆的な開発者たちの経験に基づいている。
    パイプの発明者でありUNIX創始者の一人でもあるマキルロイは、この哲学を以下のように要約した。

    一つのことを行い、またそれをうまくやるプログラムを書け。
    協調して動くプログラムを書け。


    この哲学はしばしば、「一つのことを、うまくやれ」とさらに厳格に要約される。



    小さな関数を積み合わせて、大きな関数を作る。
    小さなプログラムを組み合わせて、大きなシステムを作る。

    1つ1つがしっかりしたプログラムでなければ、砂上の楼閣になってしまうのだ。
    だから、1つ1つの小さなプログラムが大事になってくる。
    小さなプログラムを大切にできない者には、大きなプログラムを作ることはできない。
    (もしも無理矢理作ったとしても、バグフィックスが不十分となり、最終的にはシステムが崩壊するだろう。=徒労で終わる。)

    当ブログでは、
    「夢を形に ~サービス開発メモ~ 小さなプログラムを日々作り、組合わせたら、新たなシステムを生み出すコストもどんどん減るね!」
    というキャッチコピーを掲げているが、自分の正しさがまた1つ証明された。

    日々、自分のやっていることに確信が持てるように、確認の作業を怠らないようにしたい。
    それ以外に、天才になる道はない?
    (他にあったら教えてw)

    FC2Ad