  |
はてなキーワード: viとは
MS OfficeやPhotoshopからデファクトを奪うレベルのオープンソースソフトが未だに出てこないのはどういうこと？
LibreOfficeにしろGIMPにしろ、いつまで経っても業務でまともに使えるレベルにならないし。
あとGUIも、オープンソースにおける決定版がこれまた待てど暮らせど出てこない。
てかOSSって、便利である以上に複雑怪奇なUIで、ユーザを苦しめるソフトばっかり作るよね。
(Perl、sendmail、bind、TeX、gnuplotなどなど挙げてったらキリがない)
なんでユーザの使い勝手というか、そこら辺のデザインがこうも蔑ろにされるのか意味がわからん。
結局、viとemacsどっちがいいかという、傍から見たらきのこたけのこ未満のしょーもないレベルで使い勝手を言い争っていた頃から、OSS界隈は何も変わっちゃいないと。
プログラミングだったら今やWindowsやmacでも、超快適な環境を超簡単にセットアップできる。
昔ながらのviやemacsが、現代的な開発環境より使い勝手に優れるとか絶対にありえないし。
それにLinuxなんてプログラミングどうこう以前に、MSOfficeもPhotoshopも使えないじゃん。
こっちが問題にしているのはあくまでMSOfficeやPhotoshopが使えないことなので、完成度低すぎな「なんちゃって代替ソフト」があっても全く解決にならない。
あと、Linuxがオープンソースというのは確かに特徴っちゃ特徴だけど、果たしてデスクトップLinuxのユーザに、OSがオープンソースかプロプライエタリかが問題になるレベルで使っている人間がどれほどいるのかっていう。
そうなると結局、デスクトップLinuxユーザというのは今も昔も
あるいは
アーマード・コアシリーズの新作、ARMORED CORE VI FIRES OF RUBICON が発表された。
この10年近くずっと新作を待ち続けていたので本当に楽しみだし、たくさん売れて評価されて、今後も新作が出続けてほしい。
そこで、アーマード・コアをよく知らないけど少し興味がある、という人に向けてシリーズの紹介をしたいと思う。すでに同じような記事が出ているけど、こういうのはいくつもあって良いだろう。
3人称視点の3Dアクションゲームで、プレイヤーはアーマード・コア（AC）と呼ばれるメカ（ロボット）を操縦して戦う。公式にはジャンルは「3D戦闘メカアクション」とされている。
（ゲームとしてのアーマード・コアとゲームに出てくるメカとしてのアーマード・コアを区別するために、以下ではメカの方をACと書くことにする）
ACはコアと呼ばれる胴体を中心に、頭、腕、足（人型以外にも色々な種類がある）や武器、動力源のジェネレーター、高速移動用のブースターなど様々なパーツを組み合わせて完成する。完成済の機体の中から選んで操縦するのではなくて、たくさんあるパーツの中から自分で選んで組み上げた（アセンブルした）機体を操って戦う、というところがこのシリーズの大きな特徴。
主人公（プレイヤーの分身。名前も自分で決める）は金銭を対価に依頼を受けて戦う傭兵で、色々なミッションをこなして金を稼ぎ、稼いだ金でパーツを購入して機体を強化し、また次のミッションに向かう…というのがゲームの基本的な流れ。ミッションの他に、AC同士の一対一の対戦で賞金を得られるアリーナがある作品も多い。
先日公開された IGN のインタビュー （https://jp.ign.com/armored-core-6/64541/interview/armored-core-vi） から宮崎氏の言葉を引用する。
『ARMORED CORE VI』の開発がどういう形で始まって、どういう狙いがあったかというと、まずは「ARMORED CORE」シリーズ従来のコアコンセプトである、自分の機体を自由にカスタマイズできるアセンブルと、それを自由に動かせることになります。
アーマード・コアの核となる部分はまさにここなんだけど、これだけだと未経験者はイメージできないと思うので、もう少し詳しく説明する。
前提として、ACのパーツには「これを選んでおけば最強」というものは基本的にない。どのパーツにも個性があって、選んだパーツやパーツの組み合わせによって機体の動きの特性や得意な戦い方が大きく変わってくる。
防御力の高い機体で真正面から敵と撃ち合っても良いし、動きの速い機体で敵を翻弄しながら戦ってもいい。遠くから狙撃するスタイルの機体を組んでもいいし、近接武器メインの機体で敵を切り刻んでもいい。
ミッション一つ一つにも機体の向き不向きがあるので、攻略するために状況に合わせて最適なアセンブルを考えていくことも必要になってくる。もちろん、自分の考えた最強の機体で最初から最後まで戦い抜いても良い。プレイヤーごとに様々なスタイルがあり得るし、様々な遊び方がある。
また、ACのアセンブルではただパーツを選ぶだけでなく、機体を好きな色に塗装したり、エンブレムを貼り付けたり、名前を付けたりと、機体の性能に関わらない部分まで細かくカスタマイズすることができる。そうやって隅々までこだわって完成したACは自分だけの唯一無二の機体で、そしてそれを自由に操って戦場を駆け回ることができる。これがとても楽しく充実感があって、他のゲームでは代えがたい魅力だと思う。
シナリオクリア後には全てのミッションを再度プレイできるようになるので、最初はガチガチの攻略用機体でさっさとクリアして後から好きな機体で趣味に走ってもいいし、クリア後はひたすら他のプレイヤーとの対戦に没頭しても良い。
一周クリアしたからもう遊び尽くした、おしまい、とはならないのもこのシリーズの特徴だ。
こういう戦法で戦いたい、好きな武器を撃ちまくりたい、見た目がかっこいい機体で戦いたい、他作品に出てくる好きなロボットに似た機体を作りたい、操縦が難しい機体を上手く乗りこなしたい、あえて自分で制限を加えて縛りプレイを楽しみたい、他プレイヤーとの対戦に勝ちたい、などなど、色々な遊び方にアーマード・コアシリーズは応えてくれる。そこが本当に面白くて楽しい。
これに関してはすでに IGN のインタビューでも語られているが、大前提としてソウルシリーズはアクションRPGで、アーマード・コアシリーズは戦闘メカアクションだ。
基本的な操作方法から世界観に至るまで全然違う。飛び交うのは矢や魔法ではなく銃弾やレーザーだ。とはいえ、同じフロム・ソフトウェアが作っているのでフロムゲーに共通する要素は見られるし、ゲームシステムにも似通った部分はある。
例えば、ACのアセンブルはソウルシリーズのキャラメイクと似ていると言えるかもしれない。
キャラクターが装備する防具のようにACにはフレームパーツ（頭、コア、腕、足）があるし、剣や弓、魔法や祈祷はACでは武器パーツになる。ソウルシリーズでキャラビルドを突き詰めるのが好きな人はきっとACのアセンブルも楽しめるだろう。
キャラメイクの際に外見にこだわり抜いた経験がある人はACのカラーリングやエンブレム作成にハマるかもしれない。
もちろん異なる点もあって、例えばアーマード・コアシリーズにはレベルアップの概念がない。同じアセンブルの機体は常に同じ性能で、レベルアップするのは操縦するプレイヤーの腕前だけだ。
この他にもシビアな世界観や多くを語らないストーリーテリングといったフロムゲーによく見られる特徴があるが、挙げていくときりがないのでこのくらいに。
そんなことは全くないので安心してほしい。シリーズが長く続く中で世界観やゲームシステムが何度かリニューアルされていて、分類すると以下のようになる。
系列が異なる作品にストーリー上のつながりは無いので、例えば3系だけプレイしても十分に楽しめる。（初代系と2系のように一部世界観がつながっているものはあるが、ストーリーを追いかける上では知らなくても問題ない）
なお、ここに挙げたのは据え置きゲーム機のタイトルのみで、他に PSP や携帯電話（スマホ以前のガラケー）向けのタイトルも存在する。
新作のACVIでは世界観からゲームシステムまですべて一新されることが（今出ている情報だけからでも）分かっているので、シリーズ経験者もVIからのプレイヤーもスタートラインは横並びになる。VIから始めても全く問題ないはずだ。
とはいえシリーズ全般に通用する基礎知識というものはある程度存在するし、過去作も面白いので気になったらぜひプレイしてみてほしい。
ぜひプレイしてみてほしいと書いたものの、残念ながらどの作品も動作するハードが旧世代機になってしまっているので、2022年現在だとそもそも過去作をプレイする環境を用意するのが難しくなってしまっている。
手元にある（あるいは手元に用意できる）ゲーム機で遊べるタイトルがおすすめ。機種別だと、最初にシリーズに触れる作品としては
が個人的におすすめ。これに限らず気になった作品から手を付けても大丈夫だけど、同じ系列の中で後発の作品は前の作品をプレイしていることを前提に難易度調整されていたり、前の作品とストーリー上のつながりがあるものがある。
そのため、3を飛ばして3SLから始めたり、NXを飛ばしてLRから始めるのはあまりおすすめしない。（ストーリーに関しては作品ごとに単体で完結するので、その点は安心してほしい。ただ、同じ系列の中であれば前作をやっておいた方が後の作品をより楽しめる）
ちなみに、PlayStation の初代アーマード・コアは古い作品なので今遊んでも面白くないかというと、全くそんなことはない。
アーマード・コアというゲームの基本はシステムの面でも、世界観の面でもほぼ全てこの1作目の時点で完成しているので、古いゲーム故のグラフィックの粗さが問題ない人はぜひ触れてみてほしい。
M1 pro Macにて。ここ参照：https://github.com/magnusviri/stable-diffusion/tree/apple-silicon-mps-support
git clone https://github.com/magnusviri/stable-diffusion.git
cd stable-diffusion
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
conda activate ldm
mkdir -p models/ldm/stable-diffusion-v1/
https://huggingface.co/CompVis/stable-diffusion-v-1-4-original から`sd-v1-4.ckpt`をダウンロードして、
ln ~/Downloads/sd-v1-4.ckpt models/ldm/stable-diffusion-v1/model.ckpt
以下のパッケージを追加した。https://twitter.com/hevohevo/status/1562364961481162754?s=20&t=KxNXNB9fz99fbosZ8TfnvQ を参考に。
conda install onnx
pip install invisible-watermark
それで実行
python scripts/txt2img.py --prompt "a photograph of an astronaut riding a horse" --plms
するとエラーになる。https://qiita.com/hevo2/items/e646148a05118074fecf に従い、下記ファイルの2511行目を書き換え。
vi /opt/homebrew/Caskroom//miniforge/base/envs/ldm/lib/python3.10/site-packages/torch/nn/functional.py
オープンソースソフトウェア(OSS)は、ソフトウェア開発でも長い歴史を持ち、なおかつかなり個性的な特徴がある。
ざっと挙げるなら
こうしたコミュニティから生まれてきたソフトを最も多用しているのは、他ならぬWeb系だろう。
サーバサイドプログラミングが中心になることから、Linuxを触る機会も他の開発系に比べて格段に多いだろうし。
結果、「UNIXの哲学」とかGNUの歴史とか全く意識せずとも、こうした活動を通じていつの間にかOSSのエッセンスを身に着けた人が、Web系には少なからずいそう。
その意味では、OSSがどういうわけか今のWeb系の礎になってしまったという意味で、タイトルに書いた通りになっているのかなーと。
↑を書いた元増田ですが、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からコンパイルだ実行だくらいの基礎は知ってて当然だと思うんだが。
名著「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 哲学」を語るならそうした背景は理解していなければならないし，どれだけ繊細な注意を払ったところで〝つまみ食い〟になってしまうことは自覚すべきだ。
わたくしどもの教会はこれまで個々に伝道され教えを実践してまいりましたが、2009年にSaint I-gnu-cius(聖イグヌチウス)様がわたくしどもの前に顕現を果たしたことを切っ掛けとして共に教えを一帯となって伝道していこうと心新たにしChurch of Emacs(Emacs教会)が同年に成立いたしました。
ここでは反カルトを説く皆様方へSaint I-gnu-cius(聖イグヌチウス)様のお伝えの一部を紹介することで、わたくしどもの心が皆様と共にあるということを示したいと思います。
「我こそはSaint I-gnu-cius(聖イグヌチウス)である。Church of Emacs(Emacs教会)より派遣さる。」
(中略)
「汝ら純潔を守るべき事あり。汝ら、もし、邪悪な制限された論理(Software)を受任(Install)されたる利器(Computer)を所有して支配下に置きし時、かかる利器に、神聖にして完全なる自由な基幹倫理(Operating System)を受任し、その上に自由なる論理のみを受任すべし。この誓いを守りて貫き通したれば、いずれ汝ら聖人となり、その頭に光背を頂くに至らん。」
わたくしどもは個人が自己決定権を持つべきだと誓いをたてており、これらの誓いを貫徹することによってわたくしどもの魂もまた聖人に近付くのだという教えを持っています。
またそれは、わたくしどもと心が近くあるが道を違える者たちにも自由はあるべきだとSaint I-gnu-cius(聖イグヌチウス)様はお伝えになっているのです。
たとえ教会にカルトという烙印を捺されようとも、わたくしどもはそのカルト教信者に自由があるのならば、カルト教会信者は贖罪されるべきだと考えているのです。
断罪だけでは何も解決しないのです。わたくしども1人1人がその罪を贖罪する心を持ち、不自由に囚われているカルト教信者の方々を自由の愛の手で包み込み、そして自由の愛の手を繋げていくことが重要なのではないでしょうか。
これらの教えはわたくしどもChurch of Emacs(Emacs教会)の有志によってWeb上にこのような動画としてアップロードされていますし、先日わたくしどもと同じ教会に属しているであろう者の投稿があったようなので皆様方にも認知していただいている方がいらっしゃるのではないかと存じます。
更にわたくしどもを冷静によく評価している投稿も見付けましたのでこちらも合わせてご紹介したいと思います。
CoreKeeper側で apt に依存しているっぽいので、Ubuntu でやった方が楽だと思います。
Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。
dpkg --add-architecture i386 add-apt-repository multiverse apt-get update apt-get dist-upgrade reboot
useradd -m steam passwd steam gpasswd -a steam sudo
sudo -u steam -s cd sudo apt install steamcmd ln -s /usr/games/steamcmd steamcmd ./steamcmd +login anonymous +app_update 1007 +app_update 1963720 +quit
cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ ./_launch.sh
Press Ctrl + C for Stop Core Keeper Dedicated Server
mkmir -p -m 775 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds chown steam:steam /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old world file (0.world.gzip) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old setting file (*.json) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/
chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/*.json
vi /etc/cron.hourly/corekeeper_backup #!/bin/bash cp -a /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip /home/steam/worldbackup/0.world.gzip.`date '+%Y%m%d%H%M%S'` cp -a /home/steam/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt /home/steam/worldbackup/CoreKeeperServerLog.txt.`date '+%Y%m%d%H%M%S'` chmod 777 /etc/cron.hourly/corekeeper_backup sudo -u steam -s cd mkdir worldbackup
sudo -u steam -s cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ nohup ./_launch.sh tail -f ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt
利用者の問題か、サーバーの問題かわかりませんが人数が10人超えると CPU4コア/メモリ4G/100Mbps で結構ラグかったです。
今は CPU6コア/メモリ8G/1000Mbps で動かしています。
６-８人以上で２-３時間サーバー動かしてると、Unityのライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます。
ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思います。タイミングによってはアイテムロストしてしまうので。
viと、そのベースになっているラインエディタedは、通信回線が非常に遅くても、コマンドを投げてしまえばある程度思ったとおりの挙動をしてくれるようにできている
使えるようになっておいて損はない
viエディタと同様、キーボードのみで操作されることを前提としていたため、キーボードのみですべての操作が可能になっている。その基本的な操作方法はviと同じで、状況に応じてモードを使い分けることでテキストを編集していき、小さなコマンドの組み合わせをその場で作ることによって多種多様な機能を実現する。
他のエディタとは操作方法がまるで異なるため、一通りのテキスト編集作業ができるようになるまで慣れが必要となる。しかしながら、一旦慣れてしまえば軽快なテキスト編集ができるため、数多くのVim愛好家が存在する。Vimの他の機能と併せて、プログラムコードやシステム設定ファイルを編集するのに特化しているため、特にプログラマーやシステム管理者に利用者が多い。
なるほど。
そうでなければ少数の職人芸になって、老人の自己満足になってしまう。
vi/vimがほかのエディタよりユーザーが多いのかは知らないけど。
あとは、viはメモリが数十KBの時代に、軽く動くことを想定して作られたってことがキーポイントかもね。
今時軽いからといってWindows2000使う人いないでしょ。
個人的には、慣れてるから使う、古くからあるから使う、ってのは、思考停止のアホに見える。
そういうのはITじゃなくて土方行ったほうがいい。
