7月12日のtweetsに関するおはなし (お金と矜持)

私は2019-07-12に次のようなツイートをした。

夜中だから激しいことを言うぜ。

お金だけが何より大事、それこそ全てだって人は商売を学べばいいよ。手段を問わなきゃ2,3000万くらいなら普通に行くから。 商売ってそういうもんだし、商人ってそういうもんだし。

でもさ、現実にはクソみたいな商人であふれてはないじゃない? そういうのがいっぱいいるにしたってさ、そこらへんにいる人に声かけたら、今の仕事や状況に不満はわんさとあったって、やることは現実維持、商売の話なんか興味ない人に当たる可能性のほうかずっと高いわけだ

つまり、金が全てとは思ってないわけよ。そういう人は、家族の命だろうが、長年の友情だろうが逡巡もなく換金するわけ。労力も払えば犯罪もするわけよ。 でも、そんな人であふれてはないでしょ。労力を払いたくない、努力したくないなんてクズい理由かもしれないけど、金を拒否する理由はもってる

だからなんだかんだ言っても基本的には、今の立ち位置って、自分にとって許せる、自分を納得させられるラインの中で選んだものなのよ。 収入が少ないとか、その他たくさんの不満はあれど、自分が選んだことには胸を張ろうぜ。

それほど反応はなかったが、割と多くの人が見てくれたようだ。

それで私としては流していたのだが、7月28日に人気tweeterの4.5Pさんが次のようなツイートをした。

同じことに言及している。後に同氏はNoteにまとめている

それで話題になっているので、ちょっと私の発言についてちゃんと説明しておこうと思う。

なお、この記事はいずれ新しいサイトに移される。

発言の経緯

同氏はtweet、あるいはNHKの番組をきっかけにしたとあるが、私はそうではない。当該tweetよりも私は前に発言しているし、テレビも持っていない。 私が当該tweetを行った理由は、そのときtimelineに「もっとお金がほしい」「給料を上げてほしい」といったtweetが溢れていたからだ。

それらのtweetに「言うほどその望みを強く抱いているわけではない」と感じたのだ。

最初は「行動するべきなのではないか」といった主旨で発言しようかと思ったのだが、そうではないなと感じ、前述の発言に至る。

発言の意図と説明

正義と倫理

「お金至上主義の行動」というのはどちらかといえば4.5P氏の記事のほうを読むほうが早いだろう。 ちなみに、timelineで見たところによれば

罪悪感がある一方で、良い経験ができたな、ラッキーだな、と思う自分もいる。半グレの仕事で培ったコミュニケーション能力をいかして、一流企業で働きたい

という発言をした人物は、交際相手を風俗で働かせ、そのお金をだまし取っていたのだそうな。

お金を得るための手段そのものは、実のところ幅広い。捕まらなければいいという考え、あるいは捕まっても構わないという考えならばなおさらである。

実のところ、私にはいくつかの突出した能力があり、犯罪に転用しやすい能力も割と多い。そのため私は恐らく一般の人よりも犯罪に誘われる頻度が高い。 そして、内容を聞く限りだと、その還元を私に行う意思はない。つまり、私を騙すことで希望する犯罪を成立させ、お金を得ようと考えているわけである。

この場合、そう言っている当人はリスクがあまり高くない。「人に犯罪をさせることで自分が富を得る」はその人にとっての倫理であり正義なのだ。

さて、あなたにとってはどうだろう? 「人に犯罪をさせることで自分が富を得る」、は「可能ならそうしたい」だろうか?

実のところ、これは完全に人によって分かれる。共通の見解を持とうとすること自体が不可能といって過言ではないだろう。 それを共通の見解としたものが法律なのではないか、という見方もあるだろうが、実際のところ「法を文面で理解するか、意図で理解するか、逮捕で理解するか」の差に加え、そもそもそれを遵守すべきか否かというレベルで著しい差がある。もしも法が遵守される前提が成り立つのであれば、ブラック企業など稀な存在であるはずだ。

お金は実利的だから、「ほしくない」(もってなくて良いという意味で)という人はかなり少ないだろう。 実際、私も極貧生活をしていた期間は長くて、そのために大事なものを失ったりもしている以上、その重要性はとても感じている。

ちなみに、日本の自殺対策では、「人はお金を理由に自殺したりしない、必ず精神が病んでいる」とされているのだが、私は実際はそうではないことを知っている。例え暮らしていける程度だとしても、貧することはとても苦しいのだ。 経験したことのない人にはわからないかもしれないが、生きていることに凄まじい苦痛を伴う。 苦痛はあまりその別による違いというのはないのだ。

だが、それでも私はお金を得るとき、他者に貢献することを望む。そしてそうでなければならないと考える。 もちろんお金は欲しいが、それが満たされないとき、そのチャンスがあったとしても望まない。

その基準は人によって全く違うわけだが、結局のところ「お金が欲しい」という気持ちよりもネガティブな気持ちが強ければ人は動かない。 というよりも、大幅に欲求が上回らなければ動かない。 人には慣性というものがあるため、「変更する」というのは釣り合うだけでは不十分なのだ。

理由はなんでもいいのだが、倫理にそぐわないものであれ、労力にそぐわないのであれ、あるいは面倒なのであれ、 結局のところ「嫌だ」と思う理由が十分にあればそうしない。

そして、同一の事柄に対して誰もがその理由を持つわけではない。 労力を払うのが嫌だと思う人もいれば平気だと思う人もいる。他者を傷つけることが嫌だと思う人もいれば平気だと思う人もいる。 そういうことだ。

「選択」というものに対して、「変更」を前提に捉える人は多いが、 例え意識しなかったとしても選択はなされており、さらにいえば「認識した時点で形而上で選択している」のだ。

儲け話を聞いて、拒否するのも一笑に付すのも、結局自分の価値観に照らし合わせて「否」という結論に達してそうしている。 儲け話に乗らず、他者を搾取して金を得ることをせず、文句を言いながらも会社勤めをしている人は、自身の価値観における選択の上でそのようにしているのである。

だから、「半グレの儲け理論」で金だけでマウントをとって「馬鹿だ」「負け組だ」と言われようが、胸を張って「俺の選んだ生き方だ」と言ってやればいいのだ。

言葉の前提

この話は賃金が少ない、というtweetsを元にしている。 素直に受け取るのであれば、私は(自分もしない多くのものも含めて)お金を得る方法をある程度知っているわけで、そのようなコメントをするのが適格であろう。

が、それを思いとどまったのはこの件に限らずもっと根本的なことだ。

人は発言するとき、その思考を全て話すわけではない。 だから、言葉にはその人の価値観に基づく様々な葛藤が詰まっている。

例えば人が「死にたい」と言ったとき、別に必ずしも死を至上としているわけではない。 それは、「現実性によらず願いを全て叶えられるとしてもなお死にたいか」という観点で考えればわかりやすい。 表出したのがたった4文字の言葉であったとしても、そこには様々な前提があり、その前提の元に発言されている。 表出したものだけを取って述べるのは、適切とは言えないだろう。

この話題も同根で、「こんな安い賃金で働くなんてやってられない」という言葉の裏には、様々な事情や思慮や葛藤がある。 そして、選べる中で選んでいるがそれに不満、ということなのだ。 だからその人に必要なのは儲け話ではなく、めぐりあいなり、社会的是正なり、とにかく自分の選択したものが良いものへと変わっていくことなのだろう。 もちろん、同じ言葉の下は自分の知らない儲け話を教えてほしいという人だっているだろうが。

具体的な内実は基本的には他者にはわかりえない。よほど親しければ可能性はあるが。 だから、単独の言葉からその意味するところを見出すことは、まぁできないだろう。

人は結局、選択しうるときには、自分の許せる範疇から選んでいる。 許せないものは、結局どうあれ選択しえないのだ。それは「できない」という言葉でなにも間違いではない。

その言葉には、その人の「あり方」が詰まっている。

最小限の環境を作る「フォントえらび」

私は基本、4台のコンピュータを運用している。これはまんま「3部屋+携行」なのだが、それぞれの最終システムインストール日を見ると

  • ThinStation P720 (2019-01)
  • FM2A88X (2017-12)
  • Z400 Workstation (2019-07)
  • ThinkPad X1 Carbon 5thGen (2018-06)

である。ちなみに、これはjournalctlすれば分かる。

システムセットアップ時に悩ましいのがフォントだ。 ここではManjaroを前提にして語るが、日本語フォント関連のパッケージは“font japanese”で検索すると62ほどあり、うち公式パッケージは源ノ角ゴシック、源ノ明朝、IPAフォント、花園明朝、さざなみフォントである。

フォント関連のAURパッケージはあまりメンテナンスされないことが多く、多くのフォントを維持するのはかなり厳しい。インストール時間もかかるので入れるのもしんどい。 ひとつにまとめて、それを/usr/local/share/fontsなどに入れて運用する方法もあるのだが、商用フォントの除外という手間もあるし、OS側(/usr/share/fonts)との兼ね合いもディストリビューションが違ったりすると特に発生しがちなので割と難しい。

なにより、「フォントの数」と「画面の総ピクセル数」は ものすっごく 反応速度に影響するのだ。遅い遅いと思っていたマシンをまっさらにして1366*768なディスプレイをつないだら爆速になったりしている。 だから、メインマシン(もしくはフォントを使うようなアートワーク作業をするマシン)だけにフォントを積んで、他はessentialに運用したい。

ここでは私の経験に基づいてよいと判断したessentialを紹介するが、好みによることはご了承いただきたい。

先に結論

% trizen -S adobe-source-han-sans-jp-fonts adobe-source-han-serif-jp-fonts ttf-cica ttf-ume
  • 商用フォント顔負けのクオリティで出せる源ノ角ゴシック、源ノ明朝
  • zsh-theme-powerlevel9kpowerlineを入れた場合に必要になるpowerlineシンボルなどまでカバーし、日本語コーディングフォントを必要する場合に有用なCica
  • MS日本語フォントにメトリック互換の梅フォント

という構成である。

好みのちょい足し

もう少し意味を補強すると、IPAフォントがあるとLibreofficeで文書をやりとりするようなケースでは有効である。 IPAフォントは公式パッケージなのでインストールしてもいいかもしれない。

さらにいえば、コーディングフォントは日本語フォントである必要はなかったりする。 私が様々なコーディングフォントで様々なコードや文章を書いた経験で言えば、長時間使っていて快適性が高かったコーディングフォントは

  • Hermit
  • Input Mono
  • Fira Mono
  • Meslo
  • Camingo Code
  • Roboto Mono

だった。

あと、私は個人的にMiguも好きなので、

% trizen -S otf-ipafont ttf-migu otf-hermit

好みのちょい盛り

ひょっとしたらスタイリッシュな欧文フォントがないことが不満かもしれない。 定番としてはSenとかだったと思うのだけれど、今SenはGoogle Fontsから外れてしまった。 Overlockも定番。これは個人的には静凛さんのチャット欄がOverlockなので馴染みがある。

ManjaroのロゴフォントであるComfortaaは最近のManjaroはデフォルトで入っていたりする。

あと、Joseffin Sansも好き。

かっこいいSerifフォントが欲しい、とかいうと特に定番はないので、GoogleでSerifカテゴリを選択して探していただくのがよかろう。 Serifフォントに関しては私は商用のHumanist Slab 712を使っていたりするし。 どうしてもお勧めというのであれば、MartelとかCormorant Garamondとか、Abhaya Libreとかだろうか。

そして個人的には源ノ角ゴシックも良いが、やっぱりモトヤフォントが好きだ。 それにこのラインナップでは丸ゴシックがない。

そこで小杉ゴシック小杉丸ゴシックだ。 小杉ゴシックは元「モトヤ Lシーダ W3等幅」、小杉丸ゴシックは「モトヤ Lマルベリ W3等幅」のリネームである。 これらはApache Lisence 2.0でAndroidに載っていたフォントだ。

好みの盛り盛り

ドキュメントを書く上で使いやすいフォントに欠けるので、源暎フォントを追加している。 ただし、これはドキュメント生成、つまりPandocを使う端末のみ。

あと、本文フォントは「源暎ラテミン」よりも「元陽逆アンチック」のほうが人気があるので、それも入れておく

セットアップ

言葉はいらないよな?

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
        <its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
    </its:rules>

    <description>Re-define sans-serif, serif and monospace.</description>
    <match target="pattern">
        <test qual="any" name="family">
            <string>sans-serif</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Joseffin Sans</string>
            <string>MotoyaLCedar</string>
            <string>Source Han Sans JP</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>serif</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Overlock</string>
            <string>GenEi Koburi Mincho</string>
            <string>Source Han Serif JP</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>monospace</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Hermit</string>
            <string>Cica</string>
            <string>Migu 1M</string>
        </edit>
        -->
    </match>
</fontconfig>
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
        <its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
    </its:rules>

    <description>Substitude popular Japanese fonts</description>

    <match target="pattern">
        <test qual="any" name="family">
            <string>MS Pゴシック</string>
        </test>
        <test qual="any" name="family">
            <string>MS PGothic</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume P Gothic S5</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>MS P明朝</string>
        </test>
        <test qual="any" name="family">
            <string>MS PMincho</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume P Mincho</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>MS明朝</string>
        </test>
        <test qual="any" name="family">
            <string>MS Mincho</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume Mincho</string>
        </edit>
    </match>
</fontconfig>

Inflatonにおけるサーバープロビジョニングのおはなし

Inflatonにおけるサーバープロビジョニングに関する質問があったので、記事にしようと思う。

基本的にはこの部分は、私の(=Inflatonの)基本的方針を踏襲したものになっている。 つまり、

  • 一般的である、あるいは流行であるということにはとらわれず
  • Unixの流儀に従い
  • 堅牢で確実なツールと手法で
  • 全ての理解が容易であるように

している。

前提

Inflatonにおいては、一般的ではない前提が成り立っている。

まず、「私が前提になっているということ」である。

つまり、私に属人化することは基本的に問題視されない。 それよりも私の能力が発揮できることが優先されるのでやり方は好きに選べる。

もうひとつは、会社自体が少数精鋭になっているということだ。

これを前提に一般的な手法を避けたりもしていて、「IT業界の人間」が直ちに即戦力になるような状況にない。 戦力になるまで、1年くらいは育てて使う方針になっている。

その間賃金が低いとしても、300万円くらいは利益を出さない人のために使うということである。 しかも、まっさらな状態から1年でちゃんとやれるようになるとしたら、つきっきりで教えなくてはならない。 私だとえらいことになってしまうし、全てを教えられるレベルのエンジニアだと年俸600万円は下らないだろう。

これは「1人増えるのが一大イベント」であるからこそできることで、新卒採用があるような会社ではここまでの方法はとれない。

ここまでの前提を以て、他とは違うInflaton styleを可能にしている。

正しい方法

ConoHaの場合、「スタートアップスクリプト」という機能があり、サーバー構成時にスクリプトを実行させることができる。 cloud-config形式とシェルスクリプト形式をサポートしているという。

ConoHaに限らなければ、Chefなどのツールを使うのが一般的である。

もちろん、これらの方法はInflatonでは採用していない。

我々の方法

基本的に

  • ドキュメントを書く
  • シェルスクリプトを書く

の2点である。

ドキュメントは手順書と言っていいのかはわからないが、基本的に最低限コマンドが打てればこれだけ読んで構築できるレベルの内容になっている。 開発も実務も忙しいのに事業かけもちでドキュメントもちゃんと書いていることについては是非とも褒めまくっていただきたい。

シェルスクリプトのほうは、より正確に表現するならZshバッチになっている。 正直なところ、ドキュメントを読むよりもこちらを読むほうがわかりやすいだろう。

何のために、といったことに関しては、そのサービスを構成するものに関する、内部向け外部向けのドキュメントが存在するため、それを見れば確認できる。

それぞれちゃんとした理由がある。

まず、ドキュメントが揃っている最大の理由は、しばらく触ってないソフトウェアやサービスに関して、私が覚えていられないことと、説明する時間が割けないことだ。

弊社取締役はMimir Yokohamaの生徒さんでもあり、私が書くレベルのドキュメントがあればだいたいは理解できる。 このため、ちゃんとドキュメントがあるだけでも私の負担は確実に減る。そして、ドキュメントがなければ私は開発に戻ってくるのが大変になる。

そして、システム構成に関してはあまり固定化されていない。そもそもコンポーネントの変更をしやすいように設計してあり、サーバー面での変更というのは相当カジュアルに行われている。

もちろん、理由は私が管理しているからであるが、もうひとつの理由としてArch Linuxだからというのもある。 Arch Linuxは普通にバージョンも上がれば、役割を担うソフトウェアが変更されることもある。だから、構築から運用を固定化したところで、固定化したものが自動的に通用しなくなって困るだけなのだ。

ドキュメントに関しては単純に都度アップデートしている形だが、実はシェルスクリプトとドキュメントの2段構成にしている大きな理由として、「サーバー構築手順が次のサーバーで成立する可能性はかなり低い」というのがある。 一番躓くのがパッケージ名の変更である。Archは非常にカジュアルにパッケージ名を変更するので、インストールするパッケージ名の指定がコケる原因になる場合が多い。 加えていえば、サーバーソフトウェアの設定ファイルの項目も、意外と頻繁に変わる。

そこで

  1. ドキュメントで手順を確認
  2. そのパートのバッチスクリプトを実行、あるいはドキュメント記載のコマンドをコピペしながら実行
  3. 躓いた場合は原因を確認し、ドキュメントとスクリプトをアップデート

という形でstep by stepで進めていくと構築できるようになっている。 Inflatonとしてはサーバーを増やすのは年に数えるほどでしかないため、完全自動化するのはメリットよりデメリットのほうが大きい。

サーバーインスタンス増加による増強よりは、新しいことをやるために構成の異なるサーバーを立てる頻度のほうが高い。 だから作業においてコアになることが確定している部分…例えばzsh, grml-zsh-config, zsh-theme-powerlevel9k, screenのインストールと、/etc/zshrc.localの設定などはそれでひとつのスクリプトにまとめられている。 なので、このスクリプトは使い回しが効く。

Inflatonでサーバーを立てるということは、最近始まったばかりなので稀な話だが、「システムの構築」そのものは数え切れないくらいやっている。 今でも何らかの理由でシステムを作ることは年に10回くらいはあるし、15年とか前だと週イチなんてペースだったので、知識と経験があるし、効率化も進んでいる。 結局のところ「最適解を追い求めている以上、ゴージャスな方法で固定するよりは変更しやすい方法のほうがいい」というのが教訓なのだ。

ここには私の信念、及び流儀も絡む。 私は「完璧たりうる」と思っているし、かつ「完璧と動的である」と思っている。だからこそ、「完璧を追い求めることにこそ意味がある」と信じている。 そのためには「動いた状態」で固定することには意味がないし、「動的な最善」であるArch Linuxなのである。

一例としては、現在Plutoのサーバーではsshd_config(5)のCiphers

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

である。この設定の主たるところはchacha20-poly1305@openssh.comが外されていることで、外している理由はSSHの処理が比較的重いサービス特性上、サーバー側でAES-NIを使いたいからである。

余談だが、AMDプロセッサはBulldozer以降でAES-NIをサポートしており、IntelはIvy Bridgeまではi3においてAES-NIがサポートされていなかった。 こうしたことを含め、性能の低いデバイスにおいてはAES-NIがなく、計算量の多いAESは重いということになるのだが、コネクションが1本であるクライアントにとっては大した話ではなく、多数のコネクションをさばくサーバー側で軽くすることが優先である。

しかし、この設定ではaes128-ctrが最初に来ており、今後10年で変更されることを意味している。

つまり常に動的に構成され、動的に変更されるのである。 構成時はむしろ構成変更タイミングでもあると言っていい。

手順スクリプトは

pacman -S grml-zsh-config tmux zsh-completions zsh-syntax-highlighting zsh-theme-powerlevel9k zsh-history-substring-search vim vim-plugins rsync
cat > /etc/zshrc.local <<EOF
setopt vi

autoload -U history-search
#zle -N history-beginning-search-backward-end history-search
#zle -N history-beginning-search-forward-end history-search
bindkey "^P" history-beginning-search-backward
bindkey "^N" history-beginning-search-forward
bindkey "\e[5~" history-beginning-search-backward
bindkey "\e[6~" history-beginning-search-forward
bindkey -M viins "\e[5~" history-beginning-search-backward
bindkey -M viins "\e[6~" history-beginning-search-forward
bindkey -M vicmd "\e[5~" history-beginning-search-backward
bindkey -M vicmd "\e[6~" history-beginning-search-forward
...
EOF

みたいな感じで、普通にコマンドラインの手順のバッチと、catを使ったファイル生成から成り立っているのだが、ステップ中で躓いた場合、Vimでd:2してそのステップからやり直すようにすれば良い。 dggでない理由は、「失敗時にそのステップを終了する」ため、先頭で

TRAPZERR() { exit 48 }

としているからだ。

付して述べるなら、「理解していなくても使える」というのはInflatonとしては嬉しいことではなくて、「理解する前提で育てる」方向だから、 「知悉しやすい、教材としても優れたものにしておく」という考え方になってもいる。

プロビジョニングツールを使うことでディストリビューション間の差異を吸収しやすくなるという面はあるが、 ディストリビューション変更をするような場合は、パッケージに含まれるファイルの詳細を把握しなければ潜在的に危険であると考えているので、そのような吸収をしてもらう必要はない。

同様にプロビジョニングツールを使うことで構成することそのものを容易にする面もあるが、そもそも構成が普通でないので、これも全く役に立たない。 例えば私は個人としては2017年までサーバーにDeleGateを使っていたが、DeleGateを構成することなど誰も考えていないし、そこまで極端ではなくとも常に普通にはない構成になっている。 こうしたことから、定番の構成を容易にする機能というのは助けにならず、こうした機能を理由にツールを選択することもない。

サーバーに依存したツールを使うことも、「サーバーの変更」という選択を難しくさせるので、望ましいとは思えない。

Sharhiveって何か

Sharchiveの話をしたら、「それなに」という方がいたので、「あぁ、そうか。思いっきり昔話だもんなぁ」というわけでちょっとSharchiveの話をしよう。

概要

Sharchive (Shell Archive)はアーカイブファイルフォーマットである。filename suffixは.sharで、コマンド名もshar

アーカイブが7bit ASCIIで書かれたshスクリプトになることが特長。展開時はシェルスクリプトとして実行することで展開できる。

「危険ではないのか」という意見に関して答えると、非常に危険である。 純粋なシェルスクリプトであるため、Windowsの自己解凍形式なんかよりはるかに危険である。

背景

Sharは1995年頃まで使われていた。 tarがアーカイブファイルとしてはまだ一般的でない頃に使われていたのだが、アーカイブファイルフォーマットとして主流だったことはない。間違いなくやや特殊なアーカイブだった。

Unixプラットフォーム上ではshがあることは期待できたので、そうした互換性問題を回避するという面はあった。 だが、Sharが使われていた頃であってもtarがないということはそれほどなかった。

Sharが使われた最大の理由はネットニューズである。

ネットニューズを知らない人は多いだろうが、だいたいやりとりの感覚としてはメーリングリストに近い。 そして、当時はMIMEが制定される前で添付ファイルというものはなかった。つまり、データはメール内に書くしかなかった。 なおかつ、まだ8bit目がチェックディジットに使われている時であり、7bit ASCIIでしかメールが書けなかった。

もちろん、この頃でもtarでアーカイブを作り、uuencodeする、という選択肢はあった(Base64という選択肢はまだなかった)。 だが、これだとネットニューズで見ただけでは、それがどのようなソフトウェアなのかということを推定することができない。 Sharchiveであれば、特にスクリプトファイルやソースコードの場合、ネットニューズ上で確認するだけで内容を把握することができる。 メールと違い、uuencodeされたソースを展開するには取り込んでから保存してソースを取り出すという手間があるし、今と違ってX window system前提というわけでもなかったのでコピペが簡単にできたわけでもない。

こうしたことから使われていたのだが、バイナリサイズが大きくなってくると目視は困難だし、効率も悪く、なにより目視確認できないSharchiveは危険極まりない。 これによって、MIME制定以降Sharchiveは使われなくなっていき、やがて全く使われなくなった。

現在

Manjaroの場合sharutilsというパッケージがextraに存在する。

FreeBSD/DragonflyBSDのtarはlibarchiveを使っており、Sharに対応している。--formatオプションやaオプションで作成可能。

もちろん、展開はshでできる。そのため、展開そのものは今も苦労なくできる。

もはや使っている人はいないレベルだと思うのだが、Mimir YokohamaやInflatonでは使う場合がある。 その理由は、コマンドラインツールの利便性や説明の統一を狙って、Git for Windowsをインストールし、Git Bashを使う、という手順で説明することがあるからだ。

サーバー側はLinuxだし、zipでは返しづらい部分もある。こうした理由から手順が統一できるsharを使う…ということをしていたのだが、 現在は「Git for Windowsにtarが入っている」ことに気づいたのでこれも廃止した。