暫定措置の終わり

明日の午後から夏休みの旅行に入るから準備しないと。

まぁ夏休み前でいろいろバタバタ調整してるけど、1週間消えても多分大丈夫な気がする。

いや、もともとうちの職場の人は代わりにやってくれるか、1週間ごまかしてくれるけど。


もうだいぶ前だけど、在宅勤務者が増えすぎたときに暫定措置として、

メールサーバー・テレビ会議などに社外からインターネットで直接アクセス出来る仕組みが導入された。

社外からもアクセス出来るようにした

実はこれ会社所有PCだけでなく、個人所有PCでも使えたのだが、

いろいろ状況も改善してきたので、会社所有PC限定になることになったようだ。


理由はセキュリティ強化のため。確かに暫定措置ということで、利用者の善意に頼るところはけっこうあった。

会社所有PCでは継続されるため、会社所有PCを自宅に持ち帰りさえすれば問題ないし、そっちのほうが利益が大きい。

確かにこの機能を個人所有PCで使ってはいたのだが、メールが届いたのを読んで、

特に添付ファイルがある場合など、会社所有PCを立ち上げて作業するということはザラだった。

それなら最初から会社所有PC使っとけよというのは一見すればごもっともな話である。


しかし、それをやらないことには理由もあって、それは会社所有PCがノートPCであることで

長時間にわたりノートPCで仕事してはそれはどう考えても疲れるわけである。

そこで、この暫定措置を使って、個人所有PCを使うことが多かったわけですね。

ただ、一方で個人所有PCでそういうことができなくなるというわけでもない。

従来やっていたように画面転送で仕事をすることはできるからである。

しかも、これも去年春にだいぶ強化されたので、そんなにリソース不足に悩まされることもなくなった。

実際、標準的なソフトウェアで足りる作業で、ある程度の時間、画面と向き合う仕事ならこっちを使っている。


でも、これでテレビ会議ってできるのかな?

確かに昔は画面転送経由でテレビ会議に参加してた覚えもあるけど、どうだったっけ。

まぁ結局は会社所有PCでの参加になるんかなぁ。実はここが一番微妙ですね。


これとは別の話だけど、最近はノートPCが供給難らしい。

勤務先でも新規の用立てが難しいというような話がこの通知に付けてあった。

一方で、うちの職場でデスクトップPCを社外(自宅)に持ち出してる人もいるらしい。

えっ!? って思ったけどね。デスクトップPCをVPNでつないでるんだろうか。

まぁVPNの利用範囲が大きく拡大されたので可能なのかも知れない。(cf. 在宅勤務でVPNが使える)


というわけで、暫定措置をやめる理由も理解できる部分は多いので、仕方ないなと思うのだが、

多少仕事のしにくさというのは出てきそうな気はする。

基本は会社所有PCで、それで長時間やっては耐えられないときは個人所有PCに画面転送ですかね。

しかし、個人所有PCでテレビ会議するために取り付けたマイクの出番は激減しそうだな。

USBマイクは安くてもよい

まぁこれ会社に買ってもらったわけではなく、単に自分の趣味で付けただけだし、そもそも安いもんだし。

別になんとも思わないです。ただ、テレビ会議ぐらいなら……という思いもあるのは本音ですがね。

電子書籍用microSDカード

例によって7月に入ると早々に夏休みなのだが、

実は準備が全然できてなくて、やっとこさ予定を組み始めた。

いろいろ考えたけど、ほぼ1週間、関西を転々とすることになりそうですね。


先週末、タブレットPC用のmicroSDカードを買った。

もともとあったのだが、容量が16GBと少なかった。

microSDカードで保管するデータ量はもともと少ない想定ではあったのはあって、

音楽データを格納するスマートフォンに比べては少なめだった。


このmicroSDカード購入の大きな理由は、本体のストレージ不足だった。

タブレットPCの主な目的は電子書籍を読むことがあるのだが、

ダウンロードした各種の電子書籍が本体ストレージを圧迫していたのだ。

一部はアプリの設定でmicroSDへの保存を選んでいたが、それでも間に合わない状況だった。

容量が圧迫されれば、消去すればよく、消去してもダウンロードし直せばよいので、

その点ではなんとでもなると言えるが、容量不足→消去を繰り返す頻度が増えていて、これは困ったなぁと思っていた。


でも、よくよく考えればmicroSDなんて今は大容量のものが安く買えるんだからケチる必要ないよねと。

先週末に東京に行った時に秋葉原界隈に寄り道して、128GBのものが安かったので買ってきた。

その上でファイルをコピーして、各種の電子書籍アプリのファイルを消して、保存先をmicroSDに変更した。

これで本体のストレージの空きもある程度確保できるようになった。

それでも32GBの本体ストレージの8割以上を使ってるんですけどね。


手元には8GBと16GBの未使用のmicroSDカードがあるが、これといった使い道はない。

本来はこれだけ入ればいろいろあるだろうと思うけど、

スマートフォン・タブレットに取り付けられるmicroSDは1枚だけだから。

わざわざ8GBなんて選ぶ必要があったのかと今は言われそうだけどね。

その当時、8GBは一番安い部類だった覚えはあるが、8GBと16GBには明確な価格差があったんだよな。

多分、これは以前使ってたタブレットPCに付けてたんだと思うけど。


今は64GBまでならほとんど値段は変わらないぐらいに見えましたね。

迷ったら64GBでいいかなと思った。もちろん機器が対応していることが前提ですが。

どうも調べたら2018年ごろから急激に価格が下がったらしく、

その原因というのがCPU・GPUの供給不足だったらしく、頭脳がなければ記憶媒体のニーズもないということらしい。

フラッシュメモリがそんなことあるか? と思わなくもないが、他のPCパーツの動向と見比べるにそういうことらしい。

まぁ電子書籍を楽しむ分にはありがたいことだけど、なかなかこの業界も大変ね。

ブロック大臣ってワクチン大臣か

昨日、VRSの接種記録をもとにワクチンの配分を決めるという話を紹介した。

VRSへの登録が遅れると困る

この件に付いてはいろいろな意見があるところで、Twitterでパラパラ見ていたら、

「ブロック大臣」がうんぬんと書かれていて、なんだ? と調べたところこういうことらしい。

「自分のファンばかりに囲まれて…」河野太郎氏のTwitterは本当に「暇つぶし」なのか? (BuzzFeed)

河野太郎さんのことだった。役職は何度か変わってるが、かれこれ4年以上は何らかの国務大臣をやっている。

現在はワクチン大臣(正式名称は違うけど)で知られている。

Twitterへの投稿が多いことで知られているが、ブロックしてるユーザーも半端ではないとのこと。


河野さんがTwitterのユーザーをブロックする理由は自らまとめていた。

河野太郎大臣Updates / ブロックに関する批判について (note)

基本的には誹謗中傷が目に余る人をブロックしていると言うことらしいが、

一方でReplyなどこれといったやりとりもないのに先回りしてブロックされているという事例もあるそう。

河野太郎防衛相のツイッターを見ようとしたら、ブロックされていた。驚いた。(略) 私は河野氏にコメントしたことはなく、自分のツイートで言動を批判しただけ。河野氏は批判的な利用者をわざわざ検索で見つけ出し、情報を遮断している。自衛ではなく、敵地を先制攻撃するような使い方だ

([大弦小弦]ブロックされていた (沖縄タイムス))

この時点でどうかと思うのだが。


ただ、河野さんのような立場の人にとってブロック機能を使う意義は限られるんじゃないかと思う。

TwitterでAさんがBさんをブロックすると、下記のことができなくなる。

  1. AさんはBさんの投稿するTweetを閲覧することがなくなる
  2. BさんはAさんの投稿するTweetを閲覧することができなくなる
  3. BさんはAさんをFollowできなくなる(Followしていても解除される)
  4. BさんはAさんにReplyを送ることが出来なくなる
  5. BさんはAさんのTweetを引用できなくなる (2.により引用先のTweetを見られないため)

しかしながら、河野さんのように公開アカウントの場合は、ログアウトすればTweetを閲覧することはできる。

ログインしていないユーザーでも閲覧できるということはそういうことである。

閲覧を困難にする可能性はあるが、閲覧を不可能にするわけではない。

しかし、自分のTweetでブロックされたユーザーに対して言及することはできなくなる。

Tweetを投稿するためにはログインしなければならず、そこでは例え公開アカウントだとしても閲覧できないためである。


かつては1.の目的でブロックする人もいたというが、現在は一般的ではない。

それはTwitterにミュート機能が導入されたためである。(2014年導入だからそれ以前のTwitterを知らない人も多いかも知れないが)

実は僕もミュート機能はけっこう使っていて、ここには2つのパターンがある。

1つは検索の邪魔になる大量投稿をするアカウントを除外するため。スパムに近いものから、そこそこ意義があるものまでいろいろだが。

もう1つは「Retweetのみミュート」で、投稿内容自体は読みたいが、Retweetの量が多すぎるとか内容が偏っているとか、

かつてはそういう状況を我慢するか、Followを解除するかどちらかだが、Retweetのみの除外ができればだいぶ助かるので使っている。

このタイプはタイムラインにRetweetが流れなくなるだけで、各ユーザーのページではRetweetが確認出来るので念のため。


むしろ、つきまとい行為をするような人にブロックは逆効果という話もある。

これはブロックされたことが認識できるからである。これにより相手を激昂させることがしばしばあるという。

この点においてミュートであれば、無関心を貫いているだけのことで、さすがにこれはどうしょうもない。

非公開アカウントの場合は、ブロックすると、相手からのFollowが解除されることで、本当にTweetを見られなくなる。

この目的ではブロックは積極的に活用するべきである。(閲覧できるユーザーを管理することが非公開アカウントの目的なわけですから)

しかし、公開アカウントの場合はブロックしてもログアウトすればTweetを見ること自体は可能である。

この点ではTweetを閲覧できなくなるという目的はブロックしても達成されないのだから、やるだけ無駄ということである。


ブロックの効力として示した5つの事項のうち、1はミュートでOK、2~3は公開アカウントである以上は本質的に閲覧可能、

実効的な効力があるのは4~5だが、5.については引用方法の問題とも言える。

というのも、ブロックとは無関係にスクリーンショットを使った引用というのが一部において活用されているためである。

これはいくつかの目的があって、1つには引用先のTweetの削除に備えた「魚拓」という一面、

1つには相手側から引用されたことを察知できなくするという目的。

(現在はTweetのURLを引用すると、その旨が通知され、引用元のTweetに「○件の引用ツイート」として記録される)

どっちもなかなか陰湿な使い方だと思うが、公開アカウントである以上はログアウトすれば閲覧が可能で、

その内容を引用する方法は必ずしもTwitterの公式機能を使う必要はないわけだから。


そんな中で実効的な効力として残ると思われたのがReplyをできなくするという効力である。

しかしながら、ミュートをすればReplyの通知を受け取ることもなくなるわけだし、

なにより大量のReplyが寄せられるようなアカウントであれば、全てのReplyの通知を受け取るのは不都合と考えられ、

例えば自分がFollowしていないアカウントからのReplyは通知されないようにする、そういう設定は可能である。

ゆえにReplyによるつきまといを回避するという観点でも、ブロックを使う必要性は必ずしもない。

ブロックにより相手を激昂させる可能性があるならなおさら回避するべきである。


しかし、現在のTwitterではReplyはまた異なる意味を持つようになっている。

というのもある時期から特定のTweetに対するReply(特にMentionと呼ばれることがある)がTweetの下に見えるようになったからだ。

あれ導入されたのいつだったんだっけ? と調べたら2014年頃には導入されてたみたいですね。

最近だと思ってたけど全然そんなことないですね。

この機能により「クソリプ」が問題視されるようになってきた。

会話に関係ない投稿、あるいは会話を妨害することを目的とした投稿が同一ページ中に挟まることになるからである。

会話に関係ない投稿が見えることについては、Tweetの質が吟味されるような仕組みを導入することで緩和を図ってきた。

しかし、投稿者にとって好ましくない投稿が同一ページに挟まるという根本的な問題の解決にはならない。


対策の1つとしては2020年8月にReplyできるユーザーを制限する機能が導入された。

ついにTwitterが「リプライ制限機能」を実装、クソリプ根絶に一歩前進 (GIGAZINE)

FollowしていないユーザーがReplyすることを防ぐようなことはできるようになったのだが、

そうするといかにも門前払いしているのが見えてしまうのが問題の1つである。

なお、このような場合でも引用Tweetは可能である。


もう1つの解決方法としては、特定のReplyを非表示にするという方法である。

Twitterが「返信を非表示」をグローバル公開、ブロックも選択可能に (TechCrunch)

しかし、この機能を使うと、非表示にしたReplyがあることがマークから判別可能であり、

またそのマークをクリックすることで非表示にしたReplyを確認することが出来る。

Replyをモデレートする機能をどのように使っているかということが問われる機能であり、使い方次第では危険である。

あと、ちょっと実験してみたんだけど、自分がミュートしているユーザーのReplyは非表示にすることができない。

しかし、例え自分がミュートにしていても、Replyを指定して非表示にしない限りはReplyはTweetの下に表示される。

すなわち、ミュート機能との相性が悪いとみられる。そんなこともあってあまり使っている例は思い当たらない。


このことからTweetに対するReplyのモデレートを目的としてブロック機能を使うことには合理性はあるかもしれない。

Replyできるユーザーを制限すると、制限されている事実を知ることは出来る。

また、その制限を回避するために引用Tweetが使えることは一般に知られてるので、

どのような反応が気になって引用Tweetを開くことは真の反応を知ることができるので制限の効果は微妙という話がある。

特定のReplyを非表示にすることも同じである。何を非表示にしたかはバレてしまう。また引用Tweetの削除はできない。

しかし、ブロックであれば他人からはブロックにより排除されているユーザーがいることはわからないし、

また、公式機能により引用することもできないので、引用Tweetの一覧に並べることもできない。

この点ではブロックは最強のReplyのモデレート方法であると言える。


でも、本当にそういう意図があってブロックしているのかなと言うのは疑問がある話である。

先回りしてブロックしたところで、そのユーザーがReplyや引用を使うことを未然に防ぐ価値はあるのかということである。

その可能性に乏しい人をブロックすると、先の記者のように何もしてないのにブロックされたという不信感だけが募るわけである。

なんやかんや言っても興味を持ってTweetを読んでいるユーザーをあえて敵対視する意味はあるのかということである。

実際に何らかの害を為す可能性があれば対応を考えるべきだが、予防目的でやるには割に合わないと思う。


SNSにおけるユーザーをFollowするシステムについては、偏った意見を集めてしまいがちである。

このような現象を「サイバーカスケード」と呼ぶことがあるらしい。

ただ、Twitterについては公開ユーザーが多く、多くにおいては自由にReplyや引用ができる。

このため、この意見は正しくないなどという意見にたどりつくことは比較的容易とも言える。

一方でFacebookでは、よりクローズドなコミュニティが形成される傾向があり、

それがゆえに現在は陰謀論の巣窟になっているらしいという話を聞くが実態は知らない。


いずれにせよ、Twitterにおいては、議員とか大臣とも立場の人が投稿をすれば、

それに対しては賞賛も非難も受けるのは当然であり、その中には粗暴な表現もあるかもしれない。

正当な批判の範囲と受け止めるべきとしても、心理的に負担が重いことはあるかもしれない。

一方でTwitterではミュート機能や通知を制限する機能があり、これを適切に使うことで緩和が可能である。

どうしてもブロック機能でないと得られないものは、Replyと引用の制限だが、

これは特定の意見を排除するということにつながるものだから、議員とか大臣が使うのは慎重であろうと思う。

誰にとっても明らかに有害なアカウントであればブロックによる対策には妥当性があると思うが、

でも、果たして河野さんがブロックで排除したアカウントというのは、それほど問題のあるアカウントなのだろうか?


というわけで、河野さんのような立場の人がブロックを多用するのはどうかと思いますよという話。

他にも、都道府県知事などでブロックを使っているような人はいるようである。

ただ、ニュースになるほどにブロック数が多いという点で河野さんは特殊である。

Twitterの特徴を考慮した上でブロック機能も利用しているという解釈もできるが、

ミュート機能導入以降はブロック機能を使うデメリットも意識されるようになってきたと思っていた。

そんな中でこんな人がいるとは正直驚いている。ちょっとデメリットに対する考慮が不足してるよねと。

OCRもそれはそれでよいが……

今日はPayPayフリマでたくさん売ってたくさん買った日だった。

PayPayボーナスもいい感じに消化できてよかったんじゃないですかね。

よく売る人はよく買うという話もありますが、新品・中古問わずいろいろ買ってますね。

もうちょっと売れてくれないと本の収納場所が……


今日はGoogle Playカードを購入した。

キャンペーン目当てでの購入ですね。

Google Playカードを購入して登録するのだが、これがだいぶ楽になっていた。

まずはスクラッチ部を削る……のではなくシール状になっているのをはがしてコードを出す。

削る方法でもよいのだが、はがす方法の方が圧倒的に楽である。

その状態でGoogle Playアプリを起動して、ギフトコードを登録するのだけど、

ここでカメラを使って自動的に読み取ることができる。

ついでにこの後にキャンペーン申込みをするのに、購入時のバーコードの一部が必要なので、

これもバーコードリーダーアプリでスキャンして切り出した。


以前はコインで削って、アルファベット・数字交じりの文字列を打ち込んで……

とけっこうめんどくさかったGoogle Playカードの登録だが、いろいろな工夫で楽になりましたね。

まぁクレジットカード決済の方が楽だろと言われればそれはそうなんですけど。


ところでカメラでコードを読み取るというのはOCRで文字認識をしてるということですね。

書体がOCR-Bであることを考えれば文字認識は比較的容易だとは思うが、

そうはいっても読み取り条件によっては誤読はあるものである。

認識の容易性だけ言えばバーコードなりQRコードの方が……

とは思うけど、スクラッチカードには向かないのかなとも。


そんな中、ちょっとニュースで話題になっていたのですが。

ワクチン接種券読み取りに不具合 政府配布タブレット (日本経済新聞)

現在、新型コロナウイルスのワクチン接種にはVRSという記録システムが使われている。

一般的な定期予防接種では市町村が予診票を発行して、それを医療機関に持参して接種を受け、

医療機関が予診票を回収して市町村に提出して……というようなフローを取るのだが、

今回、広域接種も想定されていたからか、突貫工事で作られたのがVRSというシステムだと聞いている。

全国共通フォーマットの接種券・予診票を市町村が配布して、これを接種会場でVRSに登録するということである。


で、このVRSでは接種者の情報を読み取るのにOCRを使っていて平均2~3秒で読み取れる!

ということだったのだが、実際にはそれ以上の時間を要したり、誤認識が起きることがあって問題になっているようである。

ところで、この記事で読み取り画面の写真が掲載されているが、バーコードがあるように見える。

バーコードじゃなくてOCRなの? と思ったかも知れないが、実はバーコードはOCRで読み取る文字情報の一部しか入ってないらしい。

現場の工夫により足りない文字列を付け足すバーコードと連続して読み取ることでこの問題を回避しているケースもあるようだが、

どうして現場でOCRを使うことにしたのか? というのはよくわからない話である。

OCRの性能が高いからそれで問題ないと思ったのかも知れないが……イマイチである。


OCRといえば、以前は本の流通で使うことが想定されていて、

そのためにISBNなどの情報を印字する書体(OCR-B)・文字サイズが厳密に規定されていたら。

しかし、ISBN13桁化のときに、それはバーコードでやるだろということで、この規定を大きく緩和し、

それ以後は従来よりも小さめの字で一般的なゴシック体で記載されることが多くなっている。

そういえばそうだなと思った人もいるかもしれない。


事情は色々なのでなんとも言えないのですが……

カメラで読み取るならQRコードはQuick Responseの言葉の通り素早いですよね。

PayPayが導入されたときにユーザースキャン方式とかどう考えても遅いだろと思ったけど、

意外に速いのは、QRコードの読み取りの早さのおかげというのはあるだろう。

QRコードはそれはそれでデザイン性の問題があるというような話もあるんですが。

確かにGoogle Playカードに登録用QRコードを印字するとなれば、なかなか置きにくいとは思う。

一方で、接種券にそういうスペースを作ることはそんなに難しくなかったのでは? という気はする。

やり方次第ではないか。

iOSではスクリーンショットできるんですか

Twitterで集英社の電子書籍アプリでアカウントが凍結されたと言っている人がいて、

話によればスクリーンショットの撮影を繰り返したためだという。

結局は手続きを踏んでアカウント凍結は解除されたようだけど、

そもそもなんでこういうことになってるんだろうと。


というのもちょっと前にこのBlogでとある電子書籍アプリでスクリーンショットが封じられてた話を紹介した。

スクリーンショット禁止っていうけど

これ詳しく書かなかったけど集英社直営ストアの話なんですよね。

同じアプリではなさそうだったが、集英社なら基本的な考えは同じだろうと。

確かにそうらしい。

ただ、1つ違いがあって、それはその人はiOSを使っているということ。


実はiOSでは直接的にスクリーンショットを禁止することはできないらしい。

ただ、スクリーンショットが行われたということを検出することはできる。

そこで、このアプリはスクリーンショットが行われたことを検出して、

まず警告を表示する。ここでアカウント凍結の可能性もあると警告されるわけである。

2回以上スクリーンショットを撮らなければ、おそらくはおとがめなしである。

しかし、それを無視して繰り返すと、今度はそれを元にアカウント自体を凍結させてしまうと。

このようにして間接的にスクリーンショットを抑止しようとしているようだ。


AndroidではHDCPを強制してまで、スクリーンショット制限を実効的にしようとしている。

実際にはAndroidエミュレータ、BlueStacksで外側からスクリーンショットが撮影できてしまうけど。

WindowsではHDCP強制していないから、外側からキャプチャすることはできるが、

HDCP強制でないといってもそうそう容易な話ではないだろう。

そんな中ではiOSは禁止できないという点では相当にゆるいが、

反復的にスクリーンショットを行うことを困難にしてなんとかということらしい。


まぁ仕方ないと言えばそうなんだろうけど、今どきそんなのなのかと。

もっともiOSもDRMで保護されている動画についてはスクリーンショットをすると真っ黒になったり、

あるいは動画でキャプチャする場合はそれを検出して画面を消すような処理は可能だという。

すなわちスクリーンショットだけが穴となっているわけで、静止画については軽視しているだけとも言える。

まぁそれは仕方ないのかなとも思うが、電子書籍だと静止画が全てなんだよなぁと。

もちろんその性質によって制限の必要性は判断されるべきですが、時間限定のコンテンツなどは制限する妥当性はあるんじゃないか。

集英社もそういう意図だと思うが。

何をマイニングしてるんだろう?

マイニング需要でグラフィックボードが品薄なんて話はよく聞くけど、

一体何の暗号資産(仮想通貨とも)をマイニングしてるんだろ?


結論から言えば、多くにおいてはEthereumとみられる。

暗号資産の先駆けともいえるBitcoinではSHA256のハッシュ計算を効率よく行うために専用のICを作ることが行われた。

これをASICマイニングと呼んでいるが、こうなってくると参入障壁が非常に高い。

ASICマイニングにはCPU・GPUを使っては太刀打ちできないのが一般的で、専用のICは一般には買えませんから。

というわけで、Bitcoinのマイニング目的でグラフィックボードが品薄になるのは現実的ではない。


一方で後発の暗号資産では、ASICマイニングを困難にするようなアルゴリズムが取り入れられることが多くなっている。

というのも、暗号資産は多くの参加者の合意を得ることで改ざんを困難にしているわけだが、

Proof of Workを使っている暗号資産では過半数の計算能力を悪意を持った人が占有すると、台帳の改ざんができてしまう。

これを「51%攻撃」などと呼んでいて、実際そういう被害が出た通貨もいくつかあるようだ。

この問題を回避するためには特定の人が計算能力を独占できないように、汎用的なコンピュータでマイニングに参入できるようにするべきだと。

これが後発の暗号資産では一般的な考えだという。


さて、人々が暗号資産のマイニングをするにあたって、マイニングプールに参加することが一般的である。

というのも、大抵においてマイニングというのは、特定の条件を満たすハッシュ値を算出した人が報酬を総取りする。

なのでPC数台とかいう単位でマイニングをやっても報酬が得られる可能性は低い。

そのため、よっぽど大規模でない限りは、みんなで計算能力を持ちよって、獲得した報酬を分け合う仕組みが一般的で、それをマイニングプールと呼んでいる。


そんなマイニングプールの中でも特に参加者が多いらしいのが「NiceHash」というサービスである。

これは数あるマイニングプールの中でもかなり独特なものである。

NiceHashでは多数のアルゴリズムが選択可能で、それぞれの環境でもっとも多くの報酬が得られるものが自動的に選ばれるのが通常。

しかし、どのアルゴリズムでマイニングしても報酬はBitcoinで与えられる。

なんで? と思うところだが、実はNiceHashは計算能力の売買の仲介をするサービスで、

Bitcoinを払って、NiceHashの計算能力を買って、それで暗号資産のマイニングをする人もいるわけだ。


Algorithms (NiceHash)

これがNiceHashで取引されているアルゴリズムなのだが、日当たりの取引高の大きいアルゴリズムはこんなところ。

  1. Ethash(DaggerHashimoto) : 81BTC/日 (53万台)
    →Ethereum, Ethereum Clasic, TRON など
  2. SHA256(SHA256AsicBoostと合算) : 9.6BTC/日 (8万台)
    →Bitcoin, Bitcoin Cash, Bitcoin SV
  3. Scrypt : 6.4BTC/日 (4万台)
    →Dogecoin, Litecoin
  4. KAWPOW : 2.0BTC/日 (5万台)
    → Ravencoin
  5. Equihash(パラメータ違いのZhashと合算) : 1.7BTC/日 (3万台)
    → Zcash, Bitcoin Gold(こちらで使うEquihashをZhashと通称しているらしい)
  6. RandomX : 0.84BTC/日 (15万台)
    → Monero

()内にminerの数を書いておいた。時間帯に変動はあるかもしれないのでなんとも言えませんが。

というわけで取引金額・miner数のどちらを見ても圧倒的にEthashで、Ethash=Ethereumと考えて差し支えない。

実際、マイニングしてるPCの画面のスクリーンショットでも「DaggerHashimoto」という表示を見ることは多い。

(NiceHashでなぜDaggerHashimotoと表記されているのかというと歴史的経緯があるらしい)


SHA256もなんやかんやいってけっこうあるが、これはASICなんですかね。

取引額の半分以上はSHA256AsicBoostという露骨にASICっぽいアルゴリズム名だし。(根本的には同じだと思うが)

ScryptはASICマイニングを回避するアルゴリズムにしたつもりが、結局はASICマイニングされてしまったというものらしい。

miner1台あたりの売却額とみると、Ethashが0.15mBTC/日、SHA256が0.12mBTC/日、Scryptが0.16mBTC/日と似たようなもんだが、

その次、KAWPOWは0.04mBTC/日、Equihashが0.06mBTC/日とやや少なく、RandomXは0.006mBTC/日とかなり少ない。

(参考までに現在の相場で1mBTC=約6000円であるから、Ethashだと1台平均900円/日、KAWPOWだと1台平均250円/日とかそれぐらい)

KAWPOWやEquihashは比較的非力なGPUでのマイニングで選択される傾向があるらしく、

実験的にAMD APU搭載のこのPCでGPUマイニングをしたら、唯一動いたのがZhash(Equihash)だった。


そしてRandomXについては、これは専らCPUマイニングに適用されるアルゴリズムである。

RandomXはMoneroという暗号資産のアルゴリズムなのだが、CPU以外でのマイニングを非常に困難にするという方針なんですね。

これは他のアルゴリズムと明確に異なるため、CPUマイニング=RandomXということらしい。

もっともMoneroという暗号資産は流通量の割に取引所での取扱が少なく(日本国内には取扱業者がいないとか)、

これはMoneroの方針で非常に匿名性が高く、犯罪に利用される恐れがあると、業者も手を出したくない存在らしい。

NiceHashならRandomXの計算能力にもBitcoinが支払われるから、漫然と動かすのは容易だけど、

大した金額にもならないので、非常に軽視されているというのが実情である。


時価総額ではBitcoinが筆頭で、次がEthereumで、この2つが飛び抜けてますから、

BitcoinはASICマイニングで支えられ、EthereumはGPUマイニングで支えられているということであろう。

(EthereumもASICマイニングはあるが、アルゴリズム設計上、効果が薄いらしい)

その上で昨今の経済情勢により行き場の失った金がBitcoinやEthereumに流入してるということで、

そんなところでこれらの暗号資産、あるいはそれ以外の暗号資産のマイニングで得られる報酬が増えていると。

そうするとマイニングのためのハードウェア投資をしても見合うということですね。


NiceHashを使ってると、マイニングしてる人も、自分で何の暗号資産をマイニングしてるのか知らないということはありそう。

特にDaggerHashimotoなんて、何を表してるのはさっぱり意味がわかりませんからね。

もちろんEthashを計算して、直接的にEthereumを受け取るマイニングプール(Nanopoolなど)とかもありますから、

こういう場合はEthereumを掘っているということは意識しているはずだけど。

自動更新されて困ったWordPress

週末にこのBlogシステム、WordPressからメールが届いた。

サイト (http://hdmr.org/d) を WordPress 5.7.1 へ自動更新しました。
何もする必要はありません。 バージョン 5.7.1 について詳しくは「WordPress について」画面をご覧ください。

なんだこれ? と思ったんだが、どうもWordPressには自動更新機能があるらしいですね。

基本的には互換性の問題はないということらしいのだが……

セキュリティ的に強固な状態を維持するのに役立つということのようである。


確かにこれは一理あるし、本来は大きな問題とならないはずなのだが、

実は更新前後でこのBlogの動きが変わっていたのである。

原因はwp-include/functions.phpに追加していたカスタムコードが消えていたから。

WordPressのカスタマイズをするためにfunctions.phpにコードを追加しろというのはよく見るので、

それに従ったのだが、このファイルが更新で変更されることはないのかな? というのは心配になっていた。

やっぱりあるんですね。


もともとこういうことはあるだろうと予期していて……といってもまさか自動更新されるとは思ってなかったんだが。

カスタマイズのコードの正味部分は別ファイルにしてincludeしていた。

なんでこれのincludeを再度書き加えれば戻るだろうとは思ったのだが、

自動更新のたびに手動対応が必要なのは困った話である。

そこで調べたところ「Code Snippets」というカスタムコードを追加するプラグインがあったので、

これをインストールして、下記のコードを自動追加させるようにした。

include('/var/www/wp/wp-includes/00_custom.php');

これによりfunctions.phpを直接いじってないので、自動更新の影響を受けることはなくなったはず。


自動更新が当然有効になっているのはWordPressの開発者があるべき姿を考えた結果なのだと思うが、

やはり本番のシステムをいきなり更新されてしまっては困るという声の方が多いようだ。

確かにプライベートの重要度の低いBlogだから自動更新されてもまだなんとかなったけど、

自動更新~修正までの間に投稿した記事はslugが漢字になってたり(後に記事のslugについては修正済)、

URLが書き換わってたり、いろいろ問題が起きてしまったわけである。

影響度が小さいはずと考えた更新プログラムも、環境によっては思わぬ影響を及ぼしてしまうことはあることだ。

そこで更新するにしてもテスト環境でテストしてから本番環境へというステップを踏みたいということで、

自動更新を切るための方法がいろいろ紹介されているが、設定画面で簡単に設定できる話ではないらしい。

この辺はWordPressの開発者と運用に関わる技術者の考え方の乖離がかなり大きいところである。


ちなみに00_custom.php(00で始まってるのは検索しやすくするためで深い意味は無い)の内容は下記の通り。

  • slugの付け直し(タイトルから漢字になってしまうところを wp-6085 などに強制付替)
  • パーマリンクのURL変更 (内部的なslugが blogn-4732 ならば /?e=4737 のように旧形式にURLに変換する)
  • RSS URLの自動変換(/rssを内部的にはindex.php?feed=rdfに変換している)
  • 上記自動変換によってURLの書換が起こらないようにする(なにもしないと /feed/rdf にURL変換されてしまう)
  • フィードリンクを強制的に/rssに変換
  • 検索結果の表示順序を日付順に固定(標準ではタイトルで検索結果ヒットの日付順→本文で検索結果ヒットの日付順)

といったところで、けっこういろいろあるんですね。

URL関係はApacheの設定でやってる部分もあるので、WordPressの更新だけで即ダメになるわけでもないのだが、

やはりいろいろおかしな挙動になっていたので、そこで気づいたというのが実情ですね。


やっぱり今まで化石みたいなBlogシステムを使ってたのがWordPressに変わるといろいろありますね。

よくメンテナンスされてるのは安全・安心とは言えるし、カスタマイズ性も高いけど、やっぱり難しいわ。

唯一の選択肢だろうと選んだWordPressですからうまく付き合っていくしかないね。

プロセスが多くてはメモリ浪費がひどい

朝にBlogにアクセスすると異常に重くて、状況を確認しようとするとSSHアクセスも重い。

MySQLなど一時停止して、再起動すると立て直せたが、いろいろ重くて、

始業前にいろいろ対策をしていた。


これまでBlogではデータベースシステムを使ってなかったんだな。

ところがWordPressを使うのは不可避だとMySQLを導入したら、これがリソースを食ってた。

ただ、MySQLについては負荷軽減のための対策はこれといってなく、

対策をしたのはそれ以外の部分である。


結論から言えば、メモリの消費がひどかったんだよね。

# free

RAMはほぼ全部を食い潰し(メモリの余裕はavailableの数字をみるとよい)、スワップすら半分以上使ってた。

このVPSの契約がメモリ1GBというケチな契約なのがそもそも悪いのだが、

簡単に増量できなさそうだし、少ないメモリ消費でもパフォーマンスを維持できる仕組みを考えることに。

まずは現状分析のためにプロセス毎のリソース消費量を調べた。

# ps aux --sort=-%mem

これでメモリ消費量順に並ぶのだけど、筆頭はmysqldでしたね。

でもmysqldは1つだけなんですよ。

複数のプロセスに分断されてるものを合計して考えると一番ひどかったのはphp-fpmだったんですよね。

あと使ってないのに消費してたという点ではsssdというのがあって、認証関係のデーモンらしいが使ってないのは確実なので無効化した。


php-fpmとはなにかという話だが、これはPHPを使ったことあるひとでもなじみがない人は多いかも。

このサーバーでは以前よりPHPをfastcgiを使って動かしてきた。

FastCGIは本当に速いけど…それだけ?

それがいつしかphp-fpmというもので管理されるのが標準になったらしい。

なんとなく旧来のApacheプラグインとして動くPHPと似てきた気もするけど、あくまでも違うものなのかな。

とはいえ、これが一番良さそうなのは確かなのでphp-fpmを採用している。

ユーザーディレクトリに限ってはこのとき書いたのと同じFCGIWrapperを使う方法にしてるけど。


で、php-fpmは標準設定だと最大50個までプロセスを動的に増やせるらしく、多すぎるプロセスにメモリが食い潰されていたらしい。

というわけで適度な個数に制限することで、メモリの浪費を防ぎパフォーマンスを保てるわけである。

/etc/php-fpm.d/www.conf にて、下記の通り設定した。

pm = static
pm.max_children = 4

これが一番効いたかな。


他にもこういうものはある。ApacheもDovecotもそうである。

Apacheだとこんな感じで

StartServers 2
MaxClients 2
MaxRequestsPerChild 128

プロセス数2は少なすぎるかなぁ。

Dovecotについては、imap-loginが標準設定ではログイン要求毎に作られるのが問題で、

これは多くのログイン要求(総当たり攻撃も含む)でプロセス数が際限なく増えてしまうということである。

ただし、imap-loginをログイン用要求毎にプロセスを作るのはセキュリティ強化のための方法らしく、

下記の設定はパフォーマンス重視の設定であることに注意が必要である。

/etc/dovecot/conf.d/10-master.confにて、

service imap-login {
  (略)
  service_count = 0

これでもimapプロセスは接続毎にできるけど、これは実際使われている分なので仕方ないということで。


こんな対策でとりあえずメモリの空きは確保できるようになった。

ただ、やっぱりきついですね。RAM 1GBのVPSは無謀だったかなぁ。

いろいろあるかもしれないけど、パフォーマンスは犠牲にしても、

なにかあっても身動きが取れなくなるほど悪化することは避けられるようにカスタマイズしていきたい。


あとSSHのログインが遅い件については、こういうカスタマイズもした。

ログイン時の処理で使っていないもの、あまり意味のないものを切ったという話。

UseDNS no
GSSAPIAuthentication no

もちろんGSSAPIを使っている人は有効にしないといけませんが。

プッシュ通知が使えてなかったのは設定ミス

今さらなんですけど、AndroidタブレットでIMAPのプッシュ通知が有効にできた。

Androidのメーラーとしては「K-9 Mail」を使っている。

おそらくAndroidでは唯一のSSL/TLS証明書認証を使えるメーラーで、

これがあるから証明書認証を使えているというところはある。

マイナーな認証方式ではある

まぁそれ抜きにしてもAndroidでIMAPのメーラーといえばこれだと思いますが。


で、今までもIMAPのプッシュ通知は有効にしていて、スマートフォンの方はそれで即時通知が来ていたのだが、

タブレットの方はプッシュ通知は飛ばないし、数分に1回の自動更新も期待通りに動かない。

どうなってんだと思ってたら、電池の設定のせいだったらしい。

電池→アプリ起動で、K-9 Mailの「自動的に管理」を無効にすれば、メールが届いた瞬間にプッシュ通知が届くようになった。

実はスマートフォンでは同じ設定をちゃんとやっていたというだけの話で、

とはいえ、なぜそのことをあまり意識してなかったのかというと、

こちらでは同設定はアプリの権限設定などと並んであるので、非常に気づきやすかったんですね。

MediaPad M5を使うようになって2年間、このことに気づいてなかったのがアホらしい。


もう今どき、メールサーバーを設定して……なんてE-mailの使い方をする人も減っただろうなぁ。

スマートフォン・タブレットならGmailアプリなど入れて、PCならWebメーラーを使ってと。

IMAPというプロトコルも、これを意識して使う人はそう多くないかも。

ただ、内部的にはIMAPを使っているようなメールアプリもありそうな気はしますが。(Yahoo!メールとかそんな感じがするけど)

IMAPの特色として、基本的にはメールサーバーにメールを置きっぱなしにして使う(POP3だと受信後に削除するのが通常だった)、

なんていうのはよく言われる話だけど、その次ぐらいの特色がプッシュ通知ではないかと思う。

IMAP IDLEという機能らしいのだけど、コネクションを維持しておくと、

メールボックスにメールが届いたらサーバーから教えてもらえるわけですね。

これにより、ポーリング間隔を数分と長めにとっても、メールが届いたら即時に通知が入るというわけである。

短い間隔でポーリングを繰り返されるよりもメールサーバーの負荷軽減にもつながるとされている。


今どき、そこを意識してE-mailを使う人は減ったと想うけど、うちは自分でメールサーバー動かしてるからね。

どうしてもここら辺の設定は意識して使うことになる。

ただ、IMAPとしてはこの機能があって、アプリが対応していても、

それがAndroidの電池マネージメントでつぶされるというのは難しいね。

K-9 Mailはこれ切っても大した電池消費はしないけど、アプリによってはこういう対策は必要なんですよね。

マジックコード、ただしバイト順が逆

今日は出勤して作業していた。

作業自体はわりと短時間で終わる話だが、実機を使うとなると出勤してやらないとね。

無事に完了して、作業完了後にハードウェアを他の担当者に引き渡して、

なんともなければこれでいけるはず。


今回はプログラムに簡単なチェック機能を組み込むものである。

コマンドを送ると、チェックして、判定結果を格納するというもの。

判定結果は0と1でもいいのかもしれないが、偶然OKに見えてしまうと嫌だなと思い、

OKの場合は0x900DDA7Aという値を格納することにした。

“gOOD DATA”ってことですね。Tはちょっと無理がある気がするけど。

NGの場合は明確に別の値を格納するし、チェック結果の格納前に読んでしまっても偶然OKになる確率は極めて低い。

(手順を守ってやればそんなこともないはずだけど、視覚的にわかりやすいのはよいことである)


それで実行したら、なんか変な値が格納されていて、初期化ミスでもしたか?

と思って、よく結果を見たら “7A DA 0D 90” というデータ列で、

これリトルエンディアンで見れば 0x900DDA7A ってちゃんと格納できてるなと。

そうだ、マイコンは4byteのところにリトルエンディアンで代入しているけど、

判定する側はビックエンディアンで見ている(他の部分も大半そうなっている)から、こうなるのか。


というわけで、これ自体はわりとあるあるなので、バイト順を入れ換える処理を追加しようかと思ったのだが、

よく考えたら代入する値は定数なんだから、

0x900DDA7Aのバイト順を入れ換えて代入する処理を書くのも、0x7ADA0D90という値を代入するのも意味は変わらない。

というわけで代入する定数の定義を 0x7ADA0D90 に書き換えて、

「ビックエンディアンでの0x900DDA7A」というような注釈を入れておいた。

こうして期待値通りの結果が得られるようになってめでたしめでたし。


しかし、本来は視覚的にわかりやすいという理由でこういうマジックコードを使っているのに、

そのマジックコードのバイト順を入れ換えた、一見よくわからない値を代入するのはちょっと納得感のないところはある。

そういうもんなんですかね?


というわけで実にしょうもない話でしたとさ。

チェック処理も過去に作った処理の転用で非常にシンプル。

ただ、これを作り込むことで製造上のメリットがあるということでやることにした。

姑息というのはこのことだが、製造時にしか使わない機能なので姑息でもいいかなと。