  |
はてなキーワード: ディレクトリとは
nginx、PHP-FPM、Laravelという構成なのですが、failed (13: Permission denied)というエラーが表示されて動きません。どうしたらよいと思いますか。
「failed (13: Permission denied)」というエラーは、通常、Nginxがアクセスしようとしているファイルやディレクトリに対して必要なパーミッションがない場合に表示されます。このエラーを解決するためには、以下の手順を試してみることができます。
Nginxがアクセスしようとしているファイルやディレクトリのパーミッションを確認します。ファイルやディレクトリが適切なパーミッションであることを確認し、Nginxが読み取りや書き込みを行えるようにします。
Nginxがアクセスしようとしているファイルやディレクトリの所有者とグループを確認します。Nginxの実行ユーザー（通常はwww-dataやnginxなど）がファイルやディレクトリの所有者やグループと一致するか確認し、必要に応じて所有者やグループを変更します。
サーバーがSELinuxを実行している場合、SELinuxのセキュリティポリシーがNginxのアクセスを制限している可能性があります。SELinuxを無効化するか、適切なセキュリティポリシーを設定することで問題を解決できる場合があります。
Laravelプロジェクトなどの場合、アプリケーションの一部ファイルが壊れている可能性があります。再度アプリケーションをデプロイしたり、必要なファイルを再生成することで問題を解決できるかもしれません。
上記の手順を順番に試してみてください。また、エラーが特定のファイルやディレクトリに関連している場合、具体的なパーミッションや所有者情報を提供していただければ、より具体的なアドバイスをすることができます。
LOAD DATA INFILEでCSVを分割して読み込むことは可能なのでしょうか。そのときautoincrementのidがあった場合はどうしたらよろしいでしょうか。
はい、LOAD DATA INFILEステートメントを使用してCSVファイルを分割して読み込むことは可能です。CSVファイルを分割するには、LOAD DATA INFILEステートメントのファイル名の部分にワイルドカードを使用することができます。
以下は、例としてMySQLデータベースでのLOAD DATA INFILEステートメントの使用方法です。
LOAD DATA INFILE 'path/to/files/file*.csv' INTO TABLE your_table FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' (col1, col2, col3); -- 列のリスト
上記の例では、path/to/files/ディレクトリ内のfile*.csvというパターンに一致するすべてのCSVファイルが読み込まれます。また、FIELDS TERMINATED BY句とLINES TERMINATED BY句を使用して、フィールドと行の区切り文字を指定しています。さらに、col1, col2, col3のように列のリストを指定することで、CSVファイルの対応する列とテーブルの列をマッピングします。
autoincrementのidがある場合、LOAD DATA INFILEステートメントでは自動的に次の値を生成することはできません。そのため、CSVファイル内に明示的にid列が存在する場合は、id列を指定して読み込む必要があります。id列がCSVファイルに存在しない場合は、テーブルの定義でid列をautoincrementに設定しておく必要があります。その場合、データベースが自動的に新しい値を生成します。
CREATE TABLE your_table ( id INT AUTO_INCREMENT PRIMARY KEY, col1 VARCHAR(50), col2 VARCHAR(50), col3 VARCHAR(50) );
この場合、LOAD DATA INFILEステートメントでid列を省略することで、自動的に新しい値が生成されます。
LOAD DATA INFILE 'path/to/files/file*.csv' INTO TABLE your_table FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' (col1, col2, col3);
このようにして、CSVファイルのデータを分割して読み込むことができます。ただし、autoincrementのid列は明示的に指定するか、データベースによって自動的に生成されるようにテーブルを設定する必要があります。
SETしないと動かない。
分割するとauto incrementの値が飛ぶ。
スタックトレースを読んだらrbsのリポジトリに書かれている定義を読んでいることがわかったんだけど、このディレクトリにopen-uriがないのよね。
https://github.com/ruby/rbs/tree/master/stdlib
---
結論、以下のメソッド定義が公式で提供しているのかと思ったのだけど、用意されていない!!
```
[error] Type `singleton(::URI)` does not have method `open`
│ Diagnostic ID: Ruby::NoMethod
│
└ response = URI.open 'https://api.github.com/XXXX'
```
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
「猿でも分かるプロンプト活用術」というタイトルでの電子書籍について、以下に簡単な目次と章ごとの概要を示します。実際の書籍を作成するには、これらの各セクションを詳細に説明し、例や図を追加する必要があります。
目次:
1. はじめに
2. コマンドプロンプトとは何か
8. まとめ
9. はじめに
・グラフィカルユーザーインターフェイス(GUI)との違い
・コマンドプロンプトの開き方
・基本的なコマンドの使い方（例：help、cls、exit）
...
はじめに
コンピュータの世界は日々進化し続けており、我々が日常的に使用するデバイスやソフトウェアは常に更新され、より使いやすく、効率的になっています。しかしながら、コンピュータの基本的な操作や理解には、依然として古くから存在するコマンドプロンプトという強力なツールがあります。このツールは、多くのユーザーにとって未知の存在であり、その力を十分に発揮できていないかもしれません。
本書「猿でも分かるプロンプト活用術」は、コマンドプロンプトをこれまで使ったことがない方や、基本的な操作しか知らない方を対象に、この強力なツールを効果的に利用する方法をわかりやすく解説します。また、既にコマンドプロンプトを使用している中級者にも、さらなる活用方法を学んでいただける内容となっています。
コマンドプロンプトは、グラフィカルユーザーインターフェイス（GUI）に慣れ親しんだ現代のユーザーにとっては、最初は少し難しく感じるかもしれません。しかし、本書を通じて、コマンドプロンプトの基本操作から高度な活用法までを習得し、日々の業務やパソコン操作に役立てることができるようになります。
各章では、具体的なコマンドの例やスクリーンショットを用いて、わかりやすく説明を行います。また、章ごとに練習問題やチャレンジを設けていますので、学んだ知識をすぐに実践して確認することができます。
この本を通して、コマンドプロンプトの力を最大限に引き出し、あなたのコンピュータスキルを向上させることができることを願っています。それでは、さっそく「猿でも分かるプロンプト活用術」の世界に飛び込んでみましょう！
langってディレクトリに言語ごとのphpが入っててjaディレクトリには日本語の文言書かれたファイルはあるのになぁ。
手動でインストール(https://www.linuxyogi.com/rocky-linux/how-to-install-snipe-it-on-rockylinux-9/)
install.shでインストール(どこに書かれているんだ？git cloneした中にあるinstall.sh叩くと全部入れてくれる)
両方とも変わらず。
docker(https://qiita.com/radiance1104/items/258ef6b693eebf0f4a18)
当時はGoogleよりYahooのディレクトリ検索のほうが主流だった。
確か何かしらの機能が使えなかったので、生年月日をごまかして登録していた。
それから20年ずっとメインのメールアドレスとして使い続けてきた。
確かに過去の自分が悪かったけど、あれから20年立って今更ログイン認証だけじゃなくて生年月日が必要と出てきた。
そして、これは変更不可能。20年前にどう入力していたかなんて覚えているわけがない。
ヤフオクでも色々買っていたり、色んな思い出のメールも見れない。
もちろんこのメールアドレスを登録してるWebサービスも山程ある。
メールアドレスに確認コードを送るタイプのWebサイトだともうログインできなくなってしまったし、今使っているサブスクの解約すらも出来なくなってしまった。
最近、はてな内でインターネット老人会やおい腐女子部の方が過去を振り返っていたので、それに関連して無断リンク禁止からリンクフリーへ至った足跡を記憶を振り返りながら記そうと思う。
ただし、当該エントリのリアクションでも触れられている通り、まだまだ規模が小さかったとは言え個人視点で見れば広大なインターネットの全てを捕捉するのは難しく微妙に個人間で差異があるものと思われる。
違いがあれば私はこうだったと教えてもらえると更におもしろくなるかも知れない。
さて、若者の皆さんはインターネットのオンラインコミュニティではその当初「実名文化」であったことをご存知だろうか？
実名文化となった要因は様々あると考えられるけど、大きく影響を示した要因の1つは「JUNET」であると言われれば、まぁ納得はするのではないだろうか。少なくとも影響ゼロではないだろうなと。
JUNETは学術系ネットワークで、その主要コンテンツは今日における電子掲示板群と非常に似通ったものがあり、つまりは話題カテゴリごとに整理されたページが存在したのだ。
建前上、JUNETはごく真面目な学術系ネットワークだったので書き込みの責任は個々人にあり、書き込みへ責任持ってもらうため実名制が取られていたとされる。
電子掲示板群で「である」調の文体もJUNETで使われていた文体であり、由来は論文に使われていた文体なのだ。
まぁ実名であっても責任？なにそれ？みたいな感じで至るところへ噛み付いたり、唐突にまったく脈絡なく関係のない話をはじめ、それを指摘され叱られたら逆ギレして大暴れする抜き身のナイフみたいな方が居たんだが・・・そのことについては別の機会に。
えっソイツどうなったかって？今でもTwitterで元気に至るところへ噛み付いてレスバしてるけど？
私の年甲斐もなく落ち着かない性分はなかなかだと自覚してるが彼女には負ける。私はそろそろ落ち着かないとと思ってるがキミはそのままで良いと思うよ。
まぁそんなこんなで日本のインターネットはその当初実名文化であり、TCP/IPやWWWがデファクトスタンダードとなりWindows 95が社会現象になるほど売れた時代、ホームページ開設ブームなんてものがあった。
まぁブームと言っても現在に比べればまだまだ小規模のものではあったが、個人が自宅からウェブへアクセスし、何ならウェブサイトを公開するというのは中々に特別感があったのだ。
そのホームページ開設ブーム期のホームページは実名文化の影響下にあり、住所から氏名、電話番号、家族構成、勤め先などなどを載せているホームページが数多く存在した。現代の個人情報保護の感覚からすると実におおらかと言える。
言ってみれば、その当時のホームページは後の時代に登場する「前略プロフィール」みたいなものだったのである。
書いてある内容も個人の日記帳、しかも実像へかなり近い個人の日記帳のようなものであった。実名で交友関係がわかったし、ホームページの管理者が学生であれば甘酸っぱい恋の悩みとかを隠すこともなく実名で書いていた。
この当時のホームページはあまりにもリアルすぎる個人情報の塊であり「ホームページの管理者が広く公開していないURLを無断で他所に転載することはネチケットに反していた」という古の文言を現代で記すこととなる。
現代の感覚からしてみると「広く公開していないURLって何なんだよ」と言いたくなるし、情報技術者から見れば「ローカルにDNSサーバでも立てたのかな？プライベートIPアドレスならば個人利用だと事実上無限みたいなもんだ」と広く公開していないプライベートなURLの可能性を探り始めるが、当時の人の感覚からするとインターネットなんてドマイナーなのでインターネットを使ってる時点で隠しているつもりだったのだ。
実にバカバカしいと現代人は感じるかも知れないが当時の大半のインターネットユーザは至って真面目に本気でそう考えていた。
例えば過去の時代、NTTはハローページという個人の電話番号を膨大に載せていた冊子を発行していた。
この個人情報は公開情報であるが、電話番号所有者に無断で何ら関係しない他所へ公開した場合、倫理的に問題ないか？と言われれば現代人でも問題と感じるはずだ。現代では特殊詐欺とかあるしね。
じゃあ何でNTTはそんなもん発行していたのか？と言えば、当時の電話番号を取得するには加入権というものが必要であり、加入権は金融商品としての側面を持っていたことから、ハローページへ記載されているということはNTTがその個人の信用をある意味で担保しているという判定が得られることがあったのだ。
まぁつまり電話番号すら持ってないヤツは信用ならんから取引しないという考え方がマジで存在したんだ。
現代の、それこそ若者の感覚からするとNVNOで気軽に電話番号を入手できてしまう今では考えられない価値観だ。
ちなみに加入権の反動からか約20年前に契約書すら必要のないプリペイド携帯電話で詐欺が横行するっていう失敗があったので約20年前が最も電話番号の価値は低かった。
まぁそんなこんなで、URLは公開情報であっても勝手に使うのはダメなんだ、URL無断転載禁止なんだ、無断リンク禁止なんだという価値観の時代は存在したが、それが急速に失われて「リンクフリー」が台頭する時代が来る。
リンクフリーが何故一気に広まったのか？と言えば「Yahoo!」が日本国内で営業開始したからであった。
当時のYahoo!はディレクトリ型と呼ばれるウェブ検索エンジン方式で、これはハローページなどと同様に人力でURL情報を収集して掲載するという形のウェブ検索エンジンだった。
掲載されるには審査が必要で、Yahoo!に掲載されるということはウェブサイトへ一定の価値と信用を与えてくれるものだった。まるで本当にハローページみたいだ。
この価値が失われるのは「Google」がロボット型と呼ばれるウェブ検索エンジンを開発したからであったが、リンクフリーはGoogleが登場する前から使われ始めている。
リンクフリーはYahoo!が登場したからだけでは実は説明しきれず、Yahoo!が人気サイトをランキング形式で掲載するようになったからというのが実際の答えである。
人気ランキングが存在するようになると競争が生まれる、当時のウェブサイトにおいてはアクセス数(≠ユニークユーザ数)こそが人気の指標であり、URL無断転載禁止・無断リンク禁止のスローガンはこの人気争いの中で邪魔になっていった。
そして同時にインターネット芸人みたいな人たちも続々と登場するようになり、個人の赤裸々な情報が詰まった日記帳のようなホームページは段々と廃れていき、匿名のインターネット芸人が笑い話やお涙話で人気を集めるようになった。
そうつまり「テキストサイトブーム」の到来である。
テキストサイトの思い出についてはこのエントリを読むインターネットユニークユーザ諸氏の方が詳しいしバラエイティに富んでいると思われるので任せた。
ディレクトリ型ウェブ検索Yahoo!の登場は別にテキストサイトだけへ影響を及ぼしたわけでなく、２ちゃんねるの元になった電子掲示板群「あめぞう」の前身である「あめぞうリンク」は「リンクサイト」と呼ばれる種別のウェブサイトであった。
そのほか後年にはリンクサイトの発展型である「ランキングサイト」も登場しており、ここまで来るともはや牧歌的なインターネットなど想像も付かないような喧騒が起きるようになり、更に現代では当時を喧騒と表現しても良いのか迷う程度に現代インターネットは闘争本能が強すぎる人たちが多く生息している。
アーマードコアの新作発表されたしそっちでやれよ。
URL無断転載禁止・無断リンク禁止派の最後の抵抗はやはりGoogleによるクローリングだろう。
前述したロボット型と呼ばれるウェブ検索エンジンはウェブページからウェブページへのページリンクを自動的に収集するというもので、人力で登録していたYahoo!よりも収集効率が物凄く高かった。
しかし自動で収集するからこそウェブサイト管理者からすると謎のアクセスが急激に増え、何なら当時「Google」という単語など知る由もなかったので特にリンクを多く持っていたウェブサイト管理者からするとDDoSアタックか？と疑念を抱かせる程度には迷惑千万だった。
もちろん静かに仲間内だけで楽しんでいるようなウェブサイト管理者としても急にアクセスが増えることは不快感でしかなく、Googleの人気が増えていくに連れてリンクされない権利を求めるユーザもまた増えていったのだ。
この件であまりにも叩かれすぎたGoogleはウェブ検索エンジンの検索結果に記載されない「noindex」という施策を取ることとなり現代でも運用されている。
ただしこのnoindex、性善説で運用されておりウェブクローリングする側がnoindexを無視すりゃ普通にクローリングできるので完璧な解決手段ではない。
まぁこんな感じでテキストサイトあたりから日本のインターネットは匿名文化へ傾倒するようになりリンクフリーが一般的になっていったのだ。何ならリンクフリーって言葉すら見なくなる程度にはリンクフリーが当たり前の価値観であるインターネットになった。
そう言えば、はてなブックマークでも無断リンク禁止、勝手にウェブブックマークするなという意見が取り沙汰されたこともあったが、その辺の思い出話はブクマカのほうがよく記憶しているだろうし任せた。
結構多くのWEBサーバのアクセス制限で.co.jp .ne.jp .jpがdeny設定されていたって話である。
https://b.hatena.ne.jp/entry/s/twitter.com/kanose/status/1601270223386324992
個人のネット利用で大きな転換点は2005年くらいで、例えばブログのはしりのはてなダイアリーサービス開始は2003年でアルファブロガー選考開始は2004年、youtubeサービスインが2005年だが、これらの特徴は「アカウントをとって企業のWEBサービスを利用する」という、今では当たり前の方法だ。
だがこの以前にはそういう方式のものは少なく、ISPや借りたレンタルサーバに自分でコンテンツをアップロードして構築するというのが主流だった。
これは内部的にはLINUXサーバ制限アカウントを貰ってユーザーディレクトリの/WWWにファイルを置くという事やね。
だから最初のうちは個人サイトのURLは「ｈttp://www.yourisp.co.jp/~aybabtu」って感じだった。~はUNIXのユーザーホームディレクトリを示すのね。やがてバーチャルドメインに対応するサーバ会社が増えてｈttp://www.aybabtu.rentarusabaa.comみたいな今では当たり前のURLになったんだが、最初はバーチャルドメイン設定は有料だった。
MS Officeには「パブリッシュ」ボタンがあってそれを押すと編集してるファイル群の構造のまま指定したサーバにFTPでファイル送るみたいな機能もあった。（だがこれはShift-JISでUpするというクソ仕様で後に読めなくなるのだった）
httpの頭のHTはハイパーテキストで、参照箇所にはリンクが設定できて参照元にジャンプ（これも死語だ）できる電子文書なわけで、まさに公開はパブシュッシュ＝出版なわけだ。今もサブスクリプション＝新聞雑誌の定期購読というのはこの建付けが残ってるからだ。
ISPやWEBレンサバにはユーザー権限の多寡で違いがあって、ユーザに実行権限も付与してperlなどのインタープリタを構築しておくと、テキストであってもファイル先頭にインタープリタへのパスを書いておくとそれが実行され、標準出力をhttpで返す。これがCGIで、ISP供与で多いHTMLファイルの公開だけの権限制限されたサーバに不満な層は「CGI実行可」のレンサバ屋に移っていった。
但しプログラムであるから、いい加減に書いてループ参照とか起こすとサーバのCPUやメモリを喰いつくしてサーバダウンを惹き起こす。だからISP供与のでは実行権限を与えなかったわけだ。逆に言えばISPが必ずホームページ公開スぺースを供与するのに個人向けレンサバが成り立ったのは何故？と言えばCGIの実行が出来たからだ。
故にWindowsしか使わない人には難しい上級者向けだったのだが、これを優しいチュートリアルで簡単設定出来るようにしてユーザーを増やして会社を大きくしたのがpaperboy＆co.の家入一真氏なわけだ。はてな創業者の近藤淳也氏と並ぶ個性的なアントレプレナーと謂われた。その後堀江などと共にインターネッ党を作って都知事選に出て箸にも棒にもな結果になったのは黒歴史なので触れないで上げてください。特に堀江は野菜でいじられるよりも傷つくので偉そうに政治の話してる時に「インターネッ党」とボソっというのは残酷な事なので止めてあげて欲しい。お願いします。
また、CGIでの使用言語はperlが圧倒的で、perlで書いた掲示板スクリプトを配布するサイト、趣味プログラマが星の数ほどいた。
こういう訳で初期のWEBで動的ページ＝perlであってJcode.pmを開発した小飼弾氏は魔術師扱いされて崇拝されており、ブログブームが来ると圧倒的な人気を誇った。
今では多言語が普通に扱えるのが当たり前だが、マルチバイト文字の扱いというのは難しく、文字コードがそれぞれ違うのがそれに輪をかけていた。例えば今でも日本語Windows上でフランス語や中国語のファイル名は作れないだろう。また、最初期からかなりの期間、Twitterでは日本語の検索が出来なかった。youtubeでも日本語で投稿できなかった期間は長い。
子飼氏はperlで日本語を使用できるようにするライブラリをUNICODE対応にしてWEBで普遍的に日本語が使えるようにしたものだ。
ただ、HTLMと実行文を混ぜ書きできるPHPがver.4になるとデータベース連携が強化されていてデフォルトでSQL文発行関数が実装されており、perlCGIは廃れていってしまう。
またISPより高い自由度を求めて自宅にサーバを立ててそれを公開するという者も現れた。
はてなはサーバをデータセンターに置いてはいたものの、筐体は町工場に設計図を持ち込んでステンレスの1U筐体を自前で作っていたし、Pixivはギガバイトのシステムボードを使って自作した多数のサーバをエレクター上に置いてむき出し運用してしていたので、自宅サーバ組の延長にあったのだな、実は。
こういう中で画像を公開する、動画を公開するというのはなかなか大変だった。
仲間内で見るという分にはファイルを置けばいいだけだが、問題になったのが「2ch晒し」であった。これは悪意を持って2chにURLを貼るのだけじゃなくて、単にURLを書くというのも含まれた。
というのも2chにURLが書かれるとアクセスが集中して大抵はサーバダウンしてしまう。すると他の契約者のサイトもページも見れなくなってしまう。
例えばヒーロー戦記主題歌みたいな社歌でbuzzった日本ブレイク工業のサイトは重すぎて何週間も閲覧出来なくなった。社歌の動画ファイルを置いていたためだ。
こういうサーバダウンは契約者の責任ではないがホスティング会社も許してはくれない。契約解除、つまり出ていけか、法人契約への変更かを迫られる。転送量制限なしと言っていても実際に転送過多になると干すティングになるわけだ。
だから2chは悪意の塊の他にサーバーダウンとサーバからの追い出しを惹き起こすので蛇蝎のように嫌われていた。2ch晒し→その時点でサイトを閉じてしまう人も多く居た。
するとこれを逆手に取ってアップローダ（あぷろだ）を自作サーバで運用してアフィリエイトで収入を上げる者が現れてくる。
ただこれは著作権違反のファイルが上げられて訴えられる事もあるからそのリスク低減のためと転送量制限の為にファイル容量に制限が設けられていた。
すると大きなファイルを共有したい連中はこれでは満足できない。
そこで目を付けたのが海外でアップローダを運用しているサーバだ。運用動機は日本のアップローダと変わらない。だがファイルの大きさの制限が緩かった。
そこでそういう海外のアップローダが違法性が高いファイルの共有に使われるようになった。やってたのは2chのダウンロード板と半角板がメインだ。
だがこれは運営には迷惑な話で、日本人は英語の広告なんてクリックしない。しかも商品の販路が無いので日本からのアクセスに報酬は支払われない。つまり金を落とさず転送量だけ上がるのだ。しかも海外では転送量従量課金は多かった。
更に問題なのがロリ画像がアップロードされることだ。2次元ロリでも規制があるのに実写ロリは完全アウトだ。実写ロリが発覚した場合、サーバ管理者は必ず逮捕される。マグショットが新聞に掲載されTVで晒され、釈放後も幼児が被害者の性犯罪者なのでGPSロガ装着が義務付けられ住所は共有される。二度と部屋を借りる事は出来ずに一生トレーラーハウスかキャンピングカーを買って橋の下で生活となる。
こんな実写ロリ画像や動画をアップロードする奴が居たのである。
そこで管理者としては日本からのアクセスが増えたのを確認した時点で遮断するしかない。一生を棒に振る可能性を回避するためだ。
圧倒的によく使われるWEBサーバのapacheでは.htaccessというシステムファイルに記述してアクセス制限を掛ける事が出来る。ここで国別IPアドレス指定するのはちょっと難しいのでdeny from co.jp deny from ne.jpという風に書くとドメインがco.jp、ne.jpからのアクセスを全部弾くことができる。
この時にディレクトリ指定を「/」にするとそのサーバの全てが弾かれて403エラーが出てしまう。しかもバーチャルドメインも同じなので思わぬところで403エラーが出る事もある。
そういう訳であちこちの海外サーバで日本からのアクセスが拒否されていた。全て2chダウンロード板と半角板のやつらのせいである。
自分はアメリカの田舎の新聞社のトップページで403を食らったことがあるから嫌われ方は相当なものだと思う。「やるべき.htaccessの基本設定」みたいなのに書かれて共有されたのかも知れない。
因みにダウンロード板と半角板は2ch名物の厨房板だったのに、今見たら無くなってるのな。諸行無常だ。
2005年にサービスインしたYoutubeだが、翌年にGoogleに買収されたもので最初は元paypal社員らが作ったベンチャーだった。
だが最初は著作権違反コンテンツばかりであって、自作ビデオというのは少なかった。
特に酷かったのがまた日本人で、最初は10分制限がなかったのをいいことにアニメの全話丸上げみたいなのが大量にされており、当事者のアニオタ達も「ここまでやったら閉鎖されるだろ！」と諫めるほどだった。
そんな中で2006年6月にYoutubeが数日間の大メンテナンスに突入し、画面には「All your video are belong to us」というブロークン英語が書かれていて騒ぎになった事があった。
これの元ネタは「All your base are belong to us」で、古いセガのゲームの英語版で出てきたセリフだ。深刻な場面で突然めちゃくちゃな英語をいう。このおかしさでFLASHが作られたりとミーム化していたものだ。
しかも日本産ゲームは結構あちこちでバカ英語を作ってて、engrishとかjanglishとか言われてネタにされていた。日本で言えばアヤシイ中国製品の日本語を愛でるような感じだ。
そこでYoutubeがあんなメッセージを出したので、日本のネット民は身に覚えがありすぎて「アニオタのせいだろ！また排除されるだろ」と責任のなすり合いと相なったのだった。
因みにその後も日本人の利用が制限とかは無かったので誤解だったのだが、海外アップローダ見つけては403の焼き畑とかロリ画像問題とかがあって、その後のアニメフル全話という流れだったので過剰反応をしたのであった。
-
...
正解は下のURLのページに当該のツイートが複製されるでした～～
-
...
正解は下のURLのページに当該のツイートが複製されるでした～～
みんなはわかったかな？
-
そう、今日現在のTwitterの機能上、RTといいねは他人のツイートを複製拡散するという部分でほぼ同じ挙動をするんだ！
ディレクトリがトップページだろうが1個下の階層だろうが法的には区別されないぞ！
保管目的ならブックマーク機能を使えば良いのでお気に入りが云々は的外れもいいとこなのだ
引用も公式に引用RTという機能が追加されたので、これをあえて使わない事情は斟酌されにくいのだ
せっかく課金したのにユーザが増えまくっているのか滅茶苦茶重くなっていて最悪。
だから流出したモデルを使ってローカルでNAIの環境を構築する。
ネットには情報もだいぶ転がってるけど陳腐化した情報があまりに多いため増田にまとめることにした。
もしかしたらこの記事もすでに陳腐化しているかもしれないが…単純に間違ってたらトラバで教えてほしい。
もちろん自己責任。この記事を見て導入した結果何かあっても増田は何も保証しない。
英語がわかる人はこっちを見た方が早いと思う。今は導入RTAができるくらい導入は楽になっている。
https://rentry.org/nai-speedrun
VRAMが2GB以上あるNVIDIA製のグラフィックボードがあればローカル環境を構築できる。
GPUの世代はGTX700シリーズ以降。なので一昔前のミドル級ボードでも動作するらしい。
IntelのオンボードGPUでも実行する方法があるらしい(stable_diffusion.openvino)が今回は割愛する。自分で探してね。
その他の推奨環境は以下の通り。
対応OS：Windows7以上(と言うがM1Macでも動作する方法があるとかなんとか)
メインメモリ：16GB以上(VRAMもたくさん必要だが起動時にメインメモリも大量に食う。WebUI起動時にタスクマネージャを見ているとよくわかる)
スマホしか持ってないような人やこういうのがよくわからない人はNovelAIを使った方が良いと思う。
今は重いけど、きっとそのうちみんな飽きてサーバも軽くなるかもしれないし。
(追記)NovelAIがリソースを確保してサーバが軽くなったからリスクを背負ってまで導入しなくても良いかも
(追記)Pythonは当然3系。最新の奴を入れれば問題無い。
導入方法はいちいち書かないけど、「python --version」や「git -v」で
正常にバージョン情報が出る(パスがきちんと通っている)ことはちゃんと確認しよう。
Stable Diffusion web UIはStable Diffusionやそれをベースとした画像生成AIを利用するためのフロントエンド。
その中でも特に開発が活発でデファクトスタンダードとなっているのがAUTOMATIC1111版だ。
導入したい適当なディレクトリに対してPowerShellなどで
「git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git」
なお、AUTOMATIC1111版は数時間単位でコミットが行われるから
定期的に「git pull origin master」で更新しよう。
クライアントはqBitTorrentが一番楽だと思う。
ここにはさすがにmagnetリンクは書かないから各自ググって欲しい。
結構誤解されがちなことだが流出データ50GBを全部ダウンロードする必要は無い。
必要なファイルはanimefull-final-prunedディレクトリの中身とanimevae.ptだから5GBちょっとくらいなんじゃないかな。
もし余裕があるならmoduleディレクトリの中身もダウンロードすればいいけど、ぶっちゃけ必要無いんじゃないか？
まずはanimefull-final-prunedの中身のファイルをリネーム。
「model.ckpt」を「animefinal-full-pruned.ckpt」のようなわかりやすい名前にして、
「animevae.pt」を例えば「animefinal-full-pruned.vae.pt」のような拡張子以外は同じファイル名にする。
WebUI起動フォルダ配下の\models\Stable-diffusionにリネームしたファイルを移動させれば配置はOK。
ちなみにmoduleディレクトリの中身は\models\hypernetworksに移動させて使う。
それらのファイルを設定で適用させると画風が結構変わるがNovelAI再現とは関係無いみたいだ。
(追記)moduleディレクトリの中身の.ptファイルはhypernetworksという技術によって画風などを学習したものらしい。
すでに複数のイラストレーターの画風を学習したptファイルが作成されており議論を呼んでいる。
自分のグラボのVRAMが4GB未満の場合は「set COMMANDLINE_ARGS=」の後に
4GB未満の場合は「--medvram」、2GB未満の場合は「--lowvram」とパラメータを追加しておこう。
自分の持ってるグラボのVRAMがわからないときはGPU-Zなどで調べよう。
またGTX1600系固有のバグ(単色の画像が出力される)があるらしいので
その場合は「--no-half-vae」もしくは「--no-half」や「--precision full」とパラメータを追加。
ちなみにパラメータに「--xformers」を追加してxformersを導入・使用すると
消費VRAMが減って画像生成処理時間も短縮されるので是非導入しよう。
画像からdanbooruのタグをAIで調査するdeepdanbooruを利用する場合は「--deepdanbooru」を追加。
のようになる。
ターミナルやPowerShellなどでwebui-user.batを起動しwebUIの初期導入と起動を行う。
過去には手動でCUDA等を導入する必要があったが、現在はこの初期導入でだいたいの導入が行われる。
ずいぶん楽にはなったがその分初期導入の時間は結構長い。10分～20分くらいかかるかもしれない。
途中で導入処理がエラーで止まってしまった場合は管理者権限で実行するなどして対応して欲しい。
起動ができたらSettingで以下の設定を変更してNovelAIに近づける。
Stop At last layers of CLIP modelを2に、
Eta noise seed deltaを31337にする。
これで設定は完了！
設定を合わせて完全にNovelAIと同じ内容になったのかを確認するテストがある。
出力結果から海外じゃHallo Asuka Testなんて呼ばれている。
これは初期SEEDをはじめとする設定内容が完全に一致していれば同じ出力結果を得られる仕組みを利用している。
プロンプトの内容：masterpiece, best quality, masterpiece, asuka langley sitting cross legged on a chair
ネガティブプロンプトの内容：lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts,signature, watermark, username, blurry, artist name
https://i.imgur.com/Bfl5qJB.jpg
なお、このテストはAUTOMATIC1111のバージョンやxformersの適用状態によっては微妙に違う画像が出力されることがあるらしい。
xformersを適用させている増田の環境だと確かに二つ並べると間違い探しレベルの違いがあった。
「Booru tag autocompletion for A1111」を導入すればNovelAIのように自動でdanbooruのタグを保管してくれる。
画像生成AIモデルはStable DiffusionがOSSのため派生が結構多い。
自前で追加学習もできるため自前で学習した追加AIモデルを4chanのような掲示板などで共有する人もいるらしい。
しかしそのようなモデルの中にウィルスのような悪意のある動作を行うものもあるらしい。
FBIがペドフィリアを一網打尽にするためにIPアドレスなどの個人情報を抜き出す動作を行うロリ特化AIモデルを掲示板で配布していて
しかもそれには本物の児童ポルノが教師データとして使われている…などという都市伝説的な話が今界隈を賑わせている。
知らん人は以下を参考に。
https://suan.tokyo/affiliaters_branding/
ここでされているのはいわゆる「サイト貸し」や「ディレクトリ貸し」と呼ばれる手法である。これは数年前から話題になっていて、SEO業界で有名な辻氏も警鈴を鳴らしていた。
welq問題のときにされていたのは「コンテンツが重要なので、やたらと充実した長文を書くのがいい」という手法だ。しかし、これでキュレーションブームが激しくなり、検索の品質が下がってしまったため「ドメインごとランクを落とす」という手法でGoogleが対応をした。
明らかに手動としてか思えない、当時、ドメインへのペナルティが行われていた。1位だったのが、30位以下になる、といった形だ。2chまとめもこの手法で落とされている。
その後「信頼できる大手サイトか、大手サイトからのリンクを重視する」というアルゴリズムらしきものがGoogleで採用される。ぽっと出てきたばかりのメディアよりも、toyota.comやasahi.comのほうが信頼がある、といった具合だ。
これをハックしたのが、mybestである。「mybestで紹介されました」などで検索をすればわかると思うが、やたらとmybestで紹介されたことをサイトに載せている企業が見つかる。
文章やタイトルの傾向からみて、あくまで推測ではあるが、mybest側から「紹介したのでプレスリリースやサイト内に掲載してください。売上が伸びますよ」的な営業をしているのではないだろうか。
これにより、mybestは信頼できる企業からの大量のリンクを集めることができランクをあげている。穿った見方をすれば「ランクに載せたことを掲載してくれる企業の商品は上位にあげやすい」というのが起こりうるとも言えるが、そこは編集の独立を信じよう。
mybestのこのやり方は、非常に賢い戦略だと思うが、それでもリスクは残る。先程書いた「ドメインごと下げられる」だ。
mybestがあまりに検索上位に来ることが問題になれば、こういった対応も考えられるだろう。mybestは専門家も入れた上で、記事を作っているので、スパム扱いされることはないだろうが、「明らかに企業からのリンクを意図的に増やしている」となると、そのプラス分を0にされることは可能性としてあり得る。
そして、株式会社アルゴリズムのやっている「サイトを間借りする」の手法だ。
これは、病院や士業の事務所、大手企業などのディレクトリを借りてアフィリエイトサイトをやることである。
信頼できるサイトしか上位にでないなら、その信用できるサイトの中にアフィリエイトサイトを作ってしまえ、という発想だが、これは事業としてやるのはメリットしかない。
それもそのはず、もしもGoogleからスパム扱いされて、そのサイトのドメインランクが落とされたとしても、別のサイトを見つけて移し替えればいいからだ。ディレクトリ貸しをしたサイトは二度と検索上位には戻らず、下手すれば100位にも入らなくなるが、アフィリエイトサイト側からしてみれば無傷である。
サイトを間貸ししている事業社は当然こんなことは知らずに貸していると思うが、株式会社アルゴリズム側からしてみれば「Googleの検索アルゴリズムはブラックボックスなんでわからない」という逃げ道がある以上、責任を問うことはできない。
Googleが対策をする可能性は十分に考えられるが、それまでに儲けきって、かつ事業を売却してしまえばとんでもない額の売上が入る。
たとえば、SEOが強かったmoto株式会社という、個人がやっていたアフィリエイトサイトをログリー社が7億円で買収したが、のれん4.9億円を減損している。上位でほぼ見かけることはほぼなくなったので、収益が相当減少したと思われる。
https://docs.sakai-sc.co.jp/article/m-and-a/moto.html
ある意味、moto氏は抜群のタイミングで売り抜けたわけであり、ビジネスセンスを感じさせる。
知らん人は以下を参考に。
https://suan.tokyo/affiliaters_branding/
ここでされているのはいわゆる「サイト貸し」や「ディレクトリ貸し」と呼ばれる手法である。これは数年前から話題になっていて、SEO業界で有名な辻氏も警鈴を鳴らしていた。
welq問題のときにされていたのは「コンテンツが重要なので、やたらと充実した長文を書くのがいい」という手法だ。しかし、これでキュレーションブームが激しくなり、検索の品質が下がってしまったため「ドメインごとランクを落とす」という手法でGoogleが対応をした。
明らかに手動としてか思えない、当時、ドメインへのペナルティが行われていた。1位だったのが、30位以下になる、といった形だ。2chまとめもこの手法で落とされている。
その後「信頼できる大手サイトか、大手サイトからのリンクを重視する」というアルゴリズムらしきものがGoogleで採用される。ぽっと出てきたばかりのメディアよりも、toyota.comやasahi.comのほうが信頼がある、といった具合だ。
これをハックしたのが、mybestである。「mybestで紹介されました」などで検索をすればわかると思うが、やたらとmybestで紹介されたことをサイトに載せている企業が見つかる。
文章やタイトルの傾向からみて、あくまで推測ではあるが、mybest側から「紹介したのでプレスリリースやサイト内に掲載してください。売上が伸びますよ」的な営業をしているのではないだろうか。
これにより、mybestは信頼できる企業からの大量のリンクを集めることができランクをあげている。穿った見方をすれば「ランクに載せたことを掲載してくれる企業の商品は上位にあげやすい」というのが起こりうるとも言えるが、そこは編集の独立を信じよう。
mybestのこのやり方は、非常に賢い戦略だと思うが、それでもリスクは残る。先程書いた「ドメインごと下げられる」だ。
mybestがあまりに検索上位に来ることが問題になれば、こういった対応も考えられるだろう。mybestは専門家も入れた上で、記事を作っているので、スパム扱いされることはないだろうが、「明らかに企業からのリンクを意図的に増やしている」となると、そのプラス分を0にされることは可能性としてあり得る。
そして、株式会社アルゴリズムのやっている「サイトを間借りする」の手法だ。
これは、病院や士業の事務所、大手企業などのディレクトリを借りてアフィリエイトサイトをやることである。
信頼できるサイトしか上位にでないなら、その信用できるサイトの中にアフィリエイトサイトを作ってしまえ、という発想だが、これは事業としてやるのはメリットしかない。
それもそのはず、もしもGoogleからスパム扱いされて、そのサイトのドメインランクが落とされたとしても、別のサイトを見つけて移し替えればいいからだ。ディレクトリ貸しをしたサイトは二度と検索上位には戻らず、下手すれば100位にも入らなくなるが、アフィリエイトサイト側からしてみれば無傷である。
サイトを間貸ししている事業社は当然こんなことは知らずに貸していると思うが、株式会社アルゴリズム側からしてみれば「Googleの検索アルゴリズムはブラックボックスなんでわからない」という逃げ道がある以上、責任を問うことはできない。
Googleが対策をする可能性は十分に考えられるが、それまでに儲けきって、かつ事業を売却してしまえばとんでもない額の売上が入る。
たとえば、SEOが強かったmoto株式会社という、個人がやっていたアフィリエイトサイトをログリー社が7億円で買収したが、のれん4.9億円を減損している。上位でほぼ見かけることはほぼなくなったので、収益が相当減少したと思われる。
https://docs.sakai-sc.co.jp/article/m-and-a/moto.html
ある意味、moto氏は抜群のタイミングで売り抜けたわけであり、ビジネスセンスを感じさせる。
動けばいいというだけでも、本番サーバのどのディレクトリにPHPのソースをアップしてとか、場合によってはサーバにリモートログインも必要だし、簡単ではないと思うんだよな。
↑を書いた元増田ですが、VBの話から派生した話で、やたらコマンドライン(以下CLI)を使った開発に否定的な人間がいて閉口した件。
そりゃ一口に開発と言っても色々なので、本当に統合開発環境(以下IDE)だけで開発するケースもあるのは、こっちも知ってるんだよ。
だから学習者の中で「何をやりたいか」が既に決まっているなら、CLIを全く触らずプログラミングを学ぶケースもアリということなのだろう。
1つ目は、そもそも「プログラムって何？」というレベルの人が「何をやりたいか」なんて決まっているわけがないので、最初から「何をやるか」を決めてかかるのはナンセンスという話。
むしろどういう開発に進んでもいいように、「等号は代入を意味する」辺りから始まって、どんなプログラミングでも基礎の基礎になる、データ構造とアルゴリズムを意識させることに集中させたい。
そのためには難易度低めで比較的潰しが効く言語を、できるだけシンプルな手順で作業できる開発環境で学べる方がいい。
そしたらPythonの実行環境とそこそこ以上の機能を持つテキストエディタを入れて、コマンドプロンプトとかPowerShellとかのCLIから"Helllo, world"が取っ掛かりだと思うわけ。
もしLinuxの環境が用意できるなら同じことをLinuxでも試してもらって、プラットフォームに依存しない開発の入り口くらいを知っておければベター。
いずれにせよ何かを実行する方法が1つではないという重要な知見は、できれば基礎のうちに知ってもらいたいことの1つだし、それはWindowsとLinuxとかCLIとIDEという対比がうってつけかなーと。
ちなみにIDEは、Pythonによる手続き型プログラミングに慣れた後のタイミングで学べばいいと思う。
そこまで行ったら変数の型や、クラスとオブジェクトとかの難しい話をGo言語で学んでおくことで、現場で使われているJava、C#、swiftへの移行もスムーズになりそうだし。
ちなみに「初心者コース」の最後、もし可能ならRustでポインタとメモリの話の触りくらいを体験してもらえると、組み込みに進む際のハードルが少しは下がるんじゃないかな。
もう1つは、いくら現場によってはIDEだけで開発する現実があっても、CLIを使った開発がどういうものかくらい、プログラマにとっては知ってて当たり前じゃねーの？という話。
もちろん「プログラマが何を知ってて当たり前なのか」は、時代の移り変わりとともにどんどん変わる。
大昔ならおそらく機械語とかが必須だっただろうけど、今なら機械語よりはHTMLを読めるほうが遥かに重要なわけで。
あと、UNIX系OSをパーティションごとに主要なディレクトリを分割してインストールしていた時代であれば、edエディタの使い方は必須だったと聞く。
(/binに入るエディタがedのみだったため、もし使えないとシステムクラッシュして/以外マウントできなくなったときに詰む)
でも今やそんなの完全に過去の話どころか、viとemacsの論争ですら多分古い方の問題になるだろう。
そういう過去の諸々も踏まえるとCLIが未来永劫、プログラマにとって常識的なナレッジだとは自分も思っていない。
でも今はまだ、プログラマを名乗るならCLIからコンパイルだ実行だくらいの基礎は知ってて当然だと思うんだが。
Git（ギット[2][3][4]）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。
Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
自動で安価をつけて返信するプログラムでもこんなに長く複雑になる(一部抜粋)
/**************************************
以下のCSV_DIR, FILE_PATHS, SETTINGSを書き換えてね。 <h3>o- *************************************/</h3>
//CSVファイルが置かれてるディレクトリのパス。投稿前にエラー出たら大体ここの設定ミス。 例："C:\\Users\\sakuraimasahiro\\Documents\\iMacros\\Macros\\rentou\\";
'C:\\Users\\USER\\Desktop\\iMacros\\Macros\\rentou\\';
//ファイルのパス。CSVは絶対パスで、拡張子も必要。iimは相対パスでよく、拡張子不要。
const FILE_PATHS = {
textCsv: CSV_DIR + 'textNoAnker.csv',
//レス用投稿文が書かれたCSV。通常とレス用で分けないなら同じファイルを使えばいい。
replyTextCsv: CSV_DIR + 'textReply.csv',
};
baseWaitTime: 5,
//baseWaitTime+0～waitTimeRange（ランダム）だけ待つ
waitTimeRange: 5,
//連投しすぎだと忠告された場合に処理を一時停止させる時間(秒)
waitTimeForAvoidingPunishment: 60 * 30,
//メール
mail: 'sage',
//名前設定
name: '',
//以下、偽装ワッチョイ設定。浪人でワッチョイを非表示にしてるときだけtrueにしてね。
//妙なニックネーム（ﾜｯﾁｮｲ、ｱｳｱｳｳｰなど）をランダムで決めて付加するかどうか。true=付加する。false=付加しない。
//妙なニックネームの後に付く8桁の文字列をランダムで決めて付加するかどうか。
},
//アンカー無し投稿をするならtrue。しないならfalse。noAnkerPostかreplyPostのどちらかはtrueにすること（両方trueでもOK）。
//アンカー付き投稿（返信）をするならtrue。しないならfalse。もしnoAnkerPostとreplyPostの両方がtrueの場合、投稿は返信が優先され、返信対象が見つからなくなったらアンカー無し投稿をする。
//最初に取得するアンカー無し投稿文CSVファイルの行番号。もし返信用と同じCSVファイルを使うなら-1と入力。
noAnkerPostTextCsvStartRow: 1,
//最初に取得する返信用投稿文CSVファイルの行番号。もしアンカー無しと同じCSVファイルを使うなら-1と入力。
//テキストCSV/返信用テキストCSVの取得行が最終行に達したら最初の行まで戻るかどうか。true=戻る。false=マクロ終了。
//返信する場合、これより小さなレス番には返信しない。返信を投稿すると、この数値は前回の返信先のレス番に更新される。
minAnker: 895,
//返信する場合、名前に以下の文字列を含む投稿にアンカーをつけて返信する(ﾜｯﾁｮｲやIPなど名前フィールドにあるものならなんでも可)。配列で複数指定可能。指定無しなら空配列（[]）。filterNamesとfilterNamesNotIncluded共に無指定ならレス番1から順に返信していく（minAnkerが設定されてればそこから順に）。以下のfilter系は全て併用可能。
//↑とは逆に、名前に以下の文字列を含まない投稿にアンカーをつけて返信する。↑と併用も可能。
//返信する場合、本文に以下の文字列を含む投稿にアンカーをつけて返信する。
filterText: ['自演かな', '自演わらわら', 'スクリプト使うの', '安価ガバ', '>>660', '自演で擁護', '最後' ,'あいうえお', 'かきくけこ', 'さしすせそ', 'なにぬねの', 'はひふへほ', 'まみむめも', 'やいゆえよ', 'やゆよ', 'らりるれろ', 'わいうえを', 'わをん', 'わいうえをん'],
},
//自分のIPアドレスの確認。VPNとかでIPを変更してマクロを動かしてるとき、突然VPNが作動しなくなってIPが元に戻ったときにマクロを止めるためのもの。
//以下の文字列が自分の現在のIPアドレスに含まれている場合、マクロを一時停止する。基本的に自分の本当のIPアドレスを入力。
},
//浪人設定。最後に動作を確認したのは5年くらい前で、今も同じように動作するかは、浪人を持ってないから確認できずわからない。
//浪人にログインしてるかどうかをチェックするかどうか。trueならする。falseならしない。trueにしていてもし浪人にログインしていないことを確認したらログインしにいく。
password: '1234',
},
};
/**************************************
設定箇所終わり。
https://info.5ch.net/index.php/%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%82%81%E3%81%AA%E3%81%84%E6%99%82%E3%81%AE%E6%97%A9%E8%A6%8B%E8%A1%A8 <h3>o- *************************************/</h3>
/**************************************
・NULL演算子(??)は使えない。論理積(&&)は使える。
・オブジェクトの分割代入はできない。
・importはできない。 <h3>o- *************************************/</h3>
/**************************************
関数 <h3>o- *************************************/</h3>
/**
* ここから始まる。
*/
checkSettings();
var _TextCsvCursors = new TextCsvCursors(
SETTINGS.postSettings.noAnkerPostTextCsvStartRow > 0
? SETTINGS.postSettings.noAnkerPostTextCsvStartRow - 1
: SETTINGS.postSettings.noAnkerPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
SETTINGS.postSettings.replyPostTextCsvStartRow > 0
? SETTINGS.postSettings.replyPostTextCsvStartRow - 1
: SETTINGS.postSettings.replyPostTextCsvStartRow,
SETTINGS.postSettings.textCsvLoop,
),
);
var _LoopStatuses = new LoopStatuses(0, SETTINGS.postSettings.minAnker);
const _MyPosterName = new MyPosterName({
name: SETTINGS.nameSettings.name,
});
const _ThreadUrl = openPromptThreadUrl();
//ループ
while (true) {
SETTINGS.ipSettings.checkIp && checkCurrentIpNotTheIp();
//スレを開く
openUrl(_ThreadUrl.fullUrlHttps());
//浪人にログインする設定なら、浪人にログインしているかどうかを確認し、していなければログインしにいく。
if (SETTINGS.roninSettings.checkLogin) {
}
}
if (SETTINGS.postSettings.replyPost) {
const targetAnkerNumber = createPostDOMList()
.filterPostnumberHigher(_LoopStatuses.currentMinAnker())
.filterByPostername(SETTINGS.postSettings.filterNames)
.filterByPosternameNotIncluded(
SETTINGS.postSettings.filterNamesNotIncluded,
)
.filterByText(SETTINGS.postSettings.filterText)
if (targetAnkerNumber !== null) {
const r = _TextCsvCursors.takeNextRowTextAsReply(targetAnkerNumber);
messageDisplay(`返信対象有り。アンカー先: ${targetAnkerNumber}`);
return {
...r,
updatedLoopStatuses:
_LoopStatuses.updateMinAnker(targetAnkerNumber),
};
}
}
if (SETTINGS.postSettings.noAnkerPost) {
//返信対象無し、或いは返信しない設定の場合。アンカー無し投稿文を作る。
const r = _TextCsvCursors.takeNextRowTextAsNoAnker();
messageDisplay('返信対象無し。アンカー無し投稿。');
return {
...r,
updatedLoopStatuses: _LoopStatuses,
};
}
return null;
})();
if (p) {
//投稿。
nickname: SETTINGS.nameSettings.nickname,
korokoro: SETTINGS.nameSettings.korokoro,
area: SETTINGS.nameSettings.area,
}),
SETTINGS.mail,
p.text,
);
//_TextCsvCursorsと_LoopStatusesを更新。
_TextCsvCursors = p.updatedTextCsvCursors;
_LoopStatuses = p.updatedLoopStatuses.incrementPostCount();
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
} else {
`返信対象が現われるのを待機中...。`,
`投稿回数: ${_LoopStatuses.currentPostCount()}`,
`minAnker: ${_LoopStatuses.currentMinAnker()}`,
`今回アンカー無し投稿取得行: ${_TextCsvCursors.currentRows().noAnker}`,
`今回アンカー有り投稿取得行: ${_TextCsvCursors.currentRows().reply}`,
]);
}
wait(SETTINGS.baseWaitTime + randomRange(0, SETTINGS.waitTimeRange));
}
}
/**
* 投稿処理と投稿結果を見てリトライしたりマクロ終了したり。
* @param {string} serverName サーバー名
* @param {MyPosterName} _MyPosterName
* @param {string} postMail メール
*/
serverName,
postMail,
_MyText,
retryTimes = 0,
) {
const r =
retryTimes === 0
? new ValuesOfPost(serverName, _MyPosterName, postMail, _MyText).post(
postTo5chTread,
)
serverName,
postMail,
_MyText,
).postSubstring(retryTimes, postTo5chTread, postConfirm);
if (r) {
back();
return;
}
wait(7);
const error = createPostErrorMessage().analyze();
messageDisplay(error.message);
if (error.order === 'KILL') {
kill();
} else if (error.order === 'SKIP') {
return;
} else if (error.order === 'TRUNCATE') {
back();
serverName,
postMail,
_MyText,
retryTimes + 1,
);
} else if (error.order === 'WAIT') {
wait(SETTINGS.waitTimeForAvoidingPunishment);
serverName,
postMail,
_MyText,
retryTimes,
);
} else if (error.order === 'LOGIN') {
serverName,
postMail,
_MyText,
retryTimes,
);
}
return;
}
/**
* 現在のIPアドレスに、SETTINGS.ipSettings.avoidTheIpの値が含まれていないことを確認する。含まれていたらマクロを一時停止。
* @returns
*/
function checkCurrentIpNotTheIp() {
openUrl('https://www.cman.jp/network/support/go_access.cgi');
const _IpAdress = createIpAdressFromCMan();
if (_IpAdress.includes(SETTINGS.ipSettings.avoidTheIp)) {
pause('現在のIPに指定した値が含まれていることを確認。');
}
return;
}
/**
* @returns
*/
if (
SETTINGS.postSettings.noAnkerPost === false &&
SETTINGS.postSettings.replyPost === false
) {
return kill('設定エラー。noAnkerPostとreplyPost両方ともfalseになってる。');
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow < 0 &&
SETTINGS.postSettings.replyPostTextCsvStartRow < 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRowとreplyPostTextCsvStartRow両方とも-1になってる。',
);
}
if (
SETTINGS.postSettings.noAnkerPostTextCsvStartRow === 0 ||
SETTINGS.postSettings.replyPostTextCsvStartRow === 0
) {
return kill(
'設定エラー。noAnkerPostTextCsvStartRow/replyPostTextCsvStartRowの初期値は-1或いは1以上で。',
);
}
}
/**
* 入力フォームを表示して入力されたスレのURLを受け取る。
*/
function openPromptThreadUrl() {
const url = prompt('スレURLを入力');
}
/**
* 開いてるスレのレス全て読み取ってPostListインスタンスを作って返す。
* 重すぎるので使うのやめ。どうやらインスタンスの大量生成が原因な模様。
*/
const posts = window.document.getElementsByClassName('post');
return new PostList(Array.from(posts).map((e) => new Post(e)));
}
/**
* 開いてるスレのレス全て取得してPostDOMListに格納して返す。
* @returns
*/
function createPostDOMList() {
const posts = window.document.getElementsByClassName('post');
for (let index = 0; index < posts.length; index++) {
//HTMLCollectionからElementを1つずつ抽出して配列に。
arrPostDOMList.push(posts.item(index));
}
return new PostDOMList(arrPostDOMList);
}
/**
* 開いてる投稿結果画面に表示されてるエラーを読み取ってPostErrorMessageインスタンスを作って返す。
*/
function createPostErrorMessage() {
window.document
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
この記事はよく調べてあるなぁと思う反面，事実関係の間違いも多く当時の空気感など欠けていると思う部分がいくつかある。事実関係に関しては追い切れないので参考文献を挙げるにとどめておくが，空気感のほうはいくつか書いておく。なお当該記事の「当時と今では状況が全然違うんだから，安易に『UNIX 哲学』とかいうな」という主旨には大賛成である。
初期の UNIX の歴史について興味がある向きには次の書籍をお薦めする。
Peter H. Salus『A Quarter Century of UNIX』(1994, Addison-Wesley Publishing)
和訳の『UNIXの1/4世紀』(Peter H. Salus, QUIPU LLC 訳, 2000, アスキー) は絶版のうえ訳も微妙なので薦めづらいが，原書は The Unix Heritage Society (tuhs) で PDF が無償公開されているので，英語が苦にならないのなら読んでみるといい。
また同じく tuhs で無償公開されている Don Libes and Sandy Ressler『Life with UNIX』（1989, Prentice Hall）を読めば80年代終りの UNIX の状況（XENIX についてもしっかり言及されている）や利用者目線での雰囲気もある程度判るだろう。
元記事で一番気になるのが「哲学」という語の捉え方。この言葉の強さに引きずられているように読める。でもこれ，当時は設計の基本的な考え方くらいの意味でわりとよく使われていた言葉なんだよね。たとえば米 BYTE 誌のアーカイブを “philosophy” で全文検索するとこんな感じ。
https://archive.org/details/byte-magazine?query=philosophy&sin=TXT&sort=date
ほぼ毎号のように出現していたのが判るだろう。
もっとも猫も杓子も「哲学」を振りかざしていたわけではないし，UNIX の開発者たちが「哲学」の語を好んで使っていたのも間違いないように思う。傍証の一つが AT＆T の定期刊行物『The Bell System Technical Journal』の1978年7, 8月号だ。元記事で言及されているマキルロイの Forword の初出がこれで，ネットのアーカイブから PDF が入手できる。
この号は二部構成になっていて第一部が Atlanta Fiber System に関する論文12本（全172ページ），第二部が UNIX に関する（Preface や Foreword を含む）論文22本（全416ページ）となっている。さて前述の PDF は OCR されているので “philosophy” で全文検索してみると8箇所見つかる。これが見事に全部 UNIX の論文なのだ。もちろん論文の性質もページ数も違うからこれだけで確定的なことはいえないが「日常的に使っていたんだろうなぁ」という推測は成り立つだろう。じつはマキルロイの哲学とされている部分は “Style” であり “philosophy” の語は一切使われていないというのもちょっと面白い。UNIX の開発者たちがなぜ「哲学」という語を好んだか正確なところは判らないが，それまでにない新しい考え方に基づいた OS を開発しているという意識があれば，そういう言葉を選ぶのが自然な時代だったことは間違いない。
UNIX が認知され拡がっていく過程で「哲学」も知られるようになっていった。自分が好むものの良さを他人にも識ってもらいたい，あわよくば他人もそれを好むようになって欲しいという布教活動は今も昔を変らないわけで「哲学」はその便利なツールとなったわけだ。元記事ではガンカースの著作を「外部の人間が後から打ち立てた哲学」と表現しているが，そんなたいしたものではない。マキルロイの論文に影響を受けた布教のためのああいう説教は到るところにあった。たとえば前掲の『Life with UNIX』にもしっかり Philosophy の項がある。また日本で最初期の UNIX 解説本のひとつである，村井純・井上尚司・砂原秀樹『プロフェッショナル UNIX』（1986，アスキー）には冒頭次のような一節がある。
オペレーティング・システムは，コンピュータを使うものにとっての環境を形成する基盤であるから，そのうえで生活する者の個性を尊重し，より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェアでなければならない。この主張こそが，UNIX のオペレーティング・システムとしての個性ではないだろうか。
「より良い環境へと作り上げて行く課程を支援するような素材を提供するソフトウェア」とはテキストを入出力フォーマットとする単機能のコマンド群のことで，これらをパイプでつなげたりシェルスクリプトでまとめたりすることで「そのうえで生活する者の個性を尊重し」た「より良い環境へと作り上げて行く」ということだ。こういった説教はありふれたものであった。たんにそれを「哲学」の語を用いて書籍にまとめたのが，たまたまガンカースだったというだけのことである。
そしてじつは UNIX の場合，布教活動とはべつに「哲学」を広めなければならない切実な理由があった。これを説明するのは非常に面倒くさい。当時と今ではあまりにも環境が違うのだが，その違いが判らないと切実さが伝わらないからだ。マア頑張ってみよう。
UNIX は PDP というミニコンピュータ（ミニコン）上に開発された。このミニコンを使うためには専用の部屋に行く必要がある。その部屋は，もちろん場所によって違うわけだが，マアおおよそ学校の教室くらいの大きさだ。長机が何列か並んでおり，そのうえにはブラウン管ディスプレイとキーボードを備えた機器が等間隔に置かれている。壁際にはプリンタが何台かあるだろう。通っていた学校にコンピュータ室などと呼ばれる部屋があったならそれを思い浮かべればだいたい合ってる。ただし置かれている機器はコンピュータではなくコンピュータに接続するための端末装置（ターミナル）だ。端末装置のキーボードで打った文字がコンピュータに送られコンピュータが表示した文字がそのディスプレイに表示される。現在 Unix 系 OS で CLI を使うときターミナルとか xterm という名のアプリケーションを用いるがこれらは端末装置のエミュレータで，もともとは実体のある装置だったわけだ。
さてコンピュータ室にたいていは隣接するかたちでマシンルームなどと呼ばれる六畳くらいの部屋がある。窓ガラスで仕切られたこの部屋には箪笥や洗濯機くらいの大きさの装置が何台か置かれている。これがコンピュータ本体だ。もっともコンピュータが何台もあるわけではない。この箪笥が CPU でそっちの洗濯機がハードディスク，あの机に置かれているタイプライタが管理用コンソールといった具合に何台かある装置全部で一台のコンピュータになる。どこが〝ミニ〟だと突っ込みたくなるかもしれないが「六畳で収まるなんて，なんてミニ！」という時代のお話だ。
端末装置それぞれから（USB のご先祖様の）RS-232 という規格のアオダイショウみたいなケーブルが伸び，マシンルームに置かれたターミナルマルチプレクサと呼ばれるスーツケースに台数分のアオダイショウが刺さってコンピュータとの通信を行う。コンピュータと多数の端末装置を含めたこれら全体をサイトと呼び，root 権限を持って管理業務を行う人をシステム管理者あるいはスーパーユーザと呼んだ。
結構上手に説明できたと思うのだが雰囲気は伝わっただろうか。ここで重要なのは一台のコンピュータを数十人が一斉に使っていたという事実だ。洗濯機とかアオダイショウとかは，マアどうでもいい。
当時の UNIX の評価を一言で表すと〝自由で不安定な OS〟となる。メーカお仕着せではなく自分好みの「より良い環境」を作りあげる自由。さらに他のメインフレームやミニコン用 OS に比べると一般ユーザ権限でできることが圧倒的に多かった。そしてその代償が不安定さ。今では考えられないが UNIX のその不安定さゆえにプロ用 OS ではないと考える向きは多かったし「でも UNIX ってすぐ落ちるじゃん」というのは UNIX アンチ定番のディスりだった。UNIX の落とし方，みたいな情報がなんとなく廻ってきたものだ。
こういった雰囲気を鮮やかに伝えてくれるのが，高野豊『root から / へのメッセージ』（1991，アスキー）だ。当時アスキーが発行していた雑誌『UNIX MAGAZINE』に連載されていた氏のエッセイの1986年11月号から1988年10月号掲載分までをまとめた書籍である。著者の高野氏は勤務先の松下電器で1980年ごろから UNIX サイトのスーパーユーザを務めており，日本では最古参の一人である。この本の中で高野氏は繰返し UNIX の自由さと不安定さに言及している。すこし長くなるが，その中の一つを引用しよう。
CPU は，システムにとって重要な共有資源であるが，この CPU を実質的に停めてしまうことが UNIX ではいとも簡単にできる。たとえば，cc コマンドを10個くらい同時に走らせてみたらよい。VAX-11/780 といえども，同時に実行できるコンパイルはせいぜい3つか4つである。それ以上実行することも当然可能ではあるが，他に与える影響が無視できなくなる。つまり，てきめんに vi のカーソルが動かなくなる。あるいは，すこし大きめなディレクトリ上での ls コマンドの出力が表示されるまでに煙草を1本吸い終えてしまったり，タイムアウトでログインが撥ねつけられたりといったバカげた現象が起きだすのである。こういった状態になると，UNIX は破壊されたに等しい。真夜中，独りで VAX を占有して使っているのなら何をやろうとかまわない。しかし，20人30人と多数の人間が使っているときに勝手をやられると非常に困るのである。当人の仕事が遅れるのは自業自得だとしても，そのとばっちりで他のエディタまで止まってしまうと，もはやどの仕事も進行しなくなる。
ディスクについても同様なことがいえる。UNIX では，ファイルシステムを使いはたすまで大きなファイルを自由に作ることができる。したがって，自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュアが使うと悲惨なことになる。ディスクを使いはたすと，コンソール・タイプライターにエラー・メッセージが出力されるが，夜中にそれが発生して，コンソール・タイプライターが一晩中エラー・メッセージを打ち続け，朝マシンルームに行ってみると紙を一箱打ち尽くしてしまい，ピーピーと悲しげな声を上げて人を呼んでいた光景を私は何度も見てきた。こうなると，それをしでかした本人のプロセスは当然のこととしても，同じディスクで走っている他のプロセスも先に進めなくなってしまう。すこしでも負荷を夜間にまわそうとする善意は逆転してしまい，わずかでも仕事を先に進めようとする意図も完璧に打ち砕かれてしまうのである。
そして，こうした不安定さが「哲学」を必要としたのだ。自分が利用しているサイトに「cc コマンドを10個くらい同時に走らせ」たり「自分のプロセスがいったいどのくらいの容量のファイルを作り出すのか見当もつけられないようなアマチュア」がいるとその累は自分にも及んでしまう。だからサイトの利用者全員に UNIX の設計の基本的な考え方を理解してもらうことが，自分のために必要だった。UNIX の伝道がより苛烈だった理由のひとつがここにあるのだ。
ミニコン上で誕生した UNIX は 4.3BSD（1986）で最高潮を迎える。注意したいのはミニコン時代の UNIX は Research UNIX と CSRG BSD みたいな区別をせずにまとめて UNIX として扱われていたことだ。実際『プロフェッショナル UNIX』も『root から〜』も UNIX と記述されてはいるが実際には BSD を扱っている。べつに当時の人が無知だったわけではない。なにしろ BSD を利用するためにはまず AT＆T から UNIX のライセンスを購入し，そのうえでカリフォルニア大学バークレー校（UCB）から BSD を入手しなければならなかったからその関係は当然広く知られていた。ベル研で発明された UNIX を外部の人たちも含めみんなで改良し，それら全体が UNIX であるという考え方が自然だっただけである。『Life with UNIX』のような英語の文献によく登場する “Berkeley UNIX” という言い回しが当時の気分をよく表している。UNIX vs BSD みたいな捉え方は法廷闘争を経た90年代以降の感覚だ。
もっともそういう70年代風味の牧歌的風景はミニコン世界限定の話であった。BSD そのものはミニコン用のものしかなかったが，そのコードを受け継いだ BSD 系 Unix や AT＆T が推し進める System V などがワークステーション市場を舞台に80年代中盤から激しく覇権を争うようになる。いわゆる Unix 戦争で，PC 用 Unix であるマイクロソフトの XENIX も当然参戦した。ミニコン世界が牧歌的だったのは，ぶっちゃけていえば先のない技術だったからだ。ただ Unix 戦争はあくまでも標準という聖杯を争う戦いであり，AT＆T と BSD 系 Unix の Sun Microsystems が共同で System V Release 4.0 (SVR4) を作りあげたように後の法廷闘争とは趣が違う。
こうしたミニコン UNIX からワークステーション Unix への転変は Unix そのものや文化にも変化をもたらした。まず激しい競争は Unix の高機能化を加速した。商品として判りやすい惹句が「あれもできます，これもできます」なのは誰もが知っている。もちろん安定性を増すために quota のような利用者の自由を制限する機能も含まれていた。またワークステーション Unix は現在の Unix 系 OS と同様同時に一人が使うものであり前述の布教の必要性は大幅に減じた。達人たちのみの楽園から万人に開かれた道具に変ったのだ。こういった変化を体感したければ『root から〜』と水越賢治『スーパーユーザの日々』（1993，オーム社）を読み比べてみるといい。『スーパーユーザの日々』はワークステーション Unix のシステム管理の入門書だ。この本ではたんに知識を羅列するかわりに架空のソフトウェアハウス（開発会社）を舞台に新卒社員が先輩社員からシステム管理を学ぶという体裁をとっており，そのおかげで架空の話とはいえ90年代前半の雰囲気が堪能できる。出版年でいえば『root から〜』と二年しか違わない『スーパーユーザの日々』の落差は “dog year” と称された当時の激烈な変化まで体感できるだろう。
当時はよくいわれたのに今やほとんど聞かれなくなったものがある。マキルロイの論文の結論部分に書かれたそれは，1973年に出版されたイギリスの経済学者エルンスト・シューマッハーの著作の題名で，中学生の英語力があれば十分に理解できる平明な一文だ。
Small is beautiful.
マキルロイは『人月の神話』を引いて一定の留保をつけてはいるものの，これが UNIX 哲学の背骨であることに違いはない。機能をありったけ詰め込もうとして失敗した “kitchen-in-a-sink” な MULTI•cs のアンチテーゼである UNI•x にとって，これ以上のスローガンがあるだろうか？
ひるがえって現在の Unix 系 OS をみれば，ブクブクと肥え太ったシステムコール，全容を俯瞰するだけでも一苦労するライブラリインターフェイス，一生使うことのないオプションスイッチまみれのコマンド群。UNIX が仮想敵とした OS そのものだ。そのことについてとくになにも思わない。ハードウェアは長足の進歩を遂げ，コンピュータの応用範囲は途方もなく拡がった。UNIX が変らなければたんに打ち棄てられ，歴史書を飾る一項目になっただけだ。ただ現在「UNIX 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。
