Not only is the Internet dead, it's starting to smell really bad.:2018年10月分

2018/10/07(Sun)

[インターネット] GDPR(EU一般データ保護規則)

faviconみたいにサイトのどっか定位置にCookieに関するポリシーをテキストで転がしておけば、勝手に同意するかの後藤伊藤(Got It)ダイアログ出すようにしてくれませんかね>主要ブラウザ開発者、クソくだらねぇプッシュ通知やらブラウザに実装する暇はあるんだからさ。

2018/10/10(Wed)

[Windows] PowerShell Core 6.1

これまでWindows 7で使えるPowerShellは Windows Management Framework (WMF) 5.1に入ってる5.1が最新だと思ってたんだが、知らん間に6系が 出てたのね。

つーかCoreってだけあってPowerShell ISEはついてこないんだけど、今後は Visual Studio Codeを使えってことなんか、めんどくせぇなぁ…

以前ならCygwinあるいはWindows Scripting Host(JScript)使って書いてたバッチスクリプト的なものはなるべくPowerShell使って書くようにしてるんだけど、何年経っても慣れないし覚えられないし書いてて気持ち悪いし困ったもんだよなこれ。

いっそJScriptをNode.jsと統合してくれればいいのにな…

2018/10/11(Thu)

[やきう] 公式戦日程終了

去る由伸そして金本か、どうせならラミレスも以下略

巨人原はアレとして、阪神は和田監督が7(奈々)そして金本監督が8(鉢)やし次の監督は9(苦)るしみそうですね…

すっかり中日森繁忘れてたけど、与田新監督ってこらまた肩幅で遠近感の壊れる人選ですなぁ…

2018/10/12(Fri)

[写真] VueScan crop size shows wrong pixel

うーんまた新しいバグ見つけた、前提条件として

とした状態で実際に切抜き範囲を指定すると以下の現象が起きるな

手元で発生するのはEPSON GT-X750のフラットベッド機、Nikon COOLSCAN LS-50では発生しないっぽい。他に複合機でCanon MP960とMG6530があるけどそっちは未検証。

まーた一銭にもならんバグレポか…せめてコード読めるならバグ解析の面白味もあるんだけどな。

他にもスキャン結果をファイルに保存する時にファイル名に例えば

scan0001+.jpg

と指定すると「0001+」の部分は4桁の数字で1からの連番をつけるという意味なんだけど、これがJPEGで保存する場合とRAW(Tiff or DNG)で保存する場合で微妙に挙動が違うバグ(おそらく境界値判定のOff-By-One)にも気づいてるんだけど、めんどくせーし放置してたのと合わせて報告しますかね。

そもそもVueScanは古いスキャナーで最新のOSだとドライバが無いなんて場合には便利だけど、ソフトウェアの品質自体は微妙だなぁという感じ。

とはいえ他の候補であるSilverfastは元々の価格が高めの上、スキャナ買い換えたり複数台持ってたりすると機種ごとにライセンスも新たに購入(アップグレードライセンス)が必要というのがアレ。

2018/10/14(Sun)

[やきう] CS 1st stage

昨日は裏の中日×阪神とロッテ×楽天が「暗いマックスシリーズ ワーストステージ」呼ばわりされた上にどちらも塩試合で盛り上がりましたね…

そして今日は巨人菅野が完全試合は逃すものの圧巻のノーノー達成、みんな空気を読まない大松を代打にだせといってて大草原、なお戦力外。 それにしても直近数試合がすべて完封ノーノーの投手が、コンディション不良を理由に日米野球の侍JAPAN召集辞退は草、横浜も去年の今永の二の舞いにならんよう東は辞退させてくれルーキーやぞ。

それにしてもシーズン中もだったけどエイオキ居ないと去年の96敗ヤクルトに逆戻りやな、負けても差し支えない試合で負傷退場したのがターニングポイントやったな。 そもそもあの試合は対戦相手の横浜に勝たせて3位に滑り込ませておいた方がCS有利やったのにな、今年の対戦成績は巨人相手にはボロ負けでパと横浜に勝ち越したことでの2位だったわけで。 井野マスクで小川と原樹里投げさせてソトだけ敬遠しときゃあと全部雑魚やしファースト勝ち抜け余裕だったはず。

2018/10/15(Mon)

[チラシの裏] HTML5

古い日記ツールもまだしばらく使うので、ナウでヤングなHTML5吐くようにテンプレやら弄ってるのだが、HTML5で導入された構造化タグとかいうやつ、いにしえのSGMLという亡霊の怨念がいまだに成仏せず黄泉の国から這い出そうとしてて草不可避、なんで機械の為に人間がいちいちタグ付けせにゃあかんのかって20年前くらいに学習済みなはずなんだけどな…

2018/10/17(Wed)

[MobilePhone] 防災情報アプリ

昨日の夕方頃に強盗殺人未遂事件(犯人逃走中)があったようで、昨晩に自治会が自主的に戸締りの呼びかけをして回ってたんだが、そこは流石の神奈川県警のとても迅速な働きっぷりで記者会見での情報提供は丸一日以上たってからで、今ようやく防災情報アプリにアラートが飛んできたところ。

つまりは神奈川県に住む限りは近所を殺人犯がナイフ持ってウロウロしてようが、アラートなぞ飛んでこないので警戒することもままならんてことですな、さすがは治安がデトロイトな8mileの向こう側やで…

まぁ頭の上を事実上のミサイルとかなんとかが通過した後からJアラート流れる国だから警察なんかもっと役に立たんわけやけど、こんなんじゃ防災情報アプリに位置情報くれてやる方がプライバシーのリスクですわな。

つーかAndroidも8.1以降なら地震津波以外のJアラートあるいは自治体からの水害地滑り情報のETWSも受信できるんやね、Nexus5にも一応8.1のカスROMあるわけで、アンインストールしてもええかもしれんな。

もちろん地元の警察がまともならこの手のアプリのETWSで配信されない警察発表の不審者情報なんかは役に立つかも知れんのだが、そこは神奈川県警自体が天災みたいなもんだからしゃーない。

2018/10/20(Sat)

[写真] Nikon COOLSCAN V(LS-50)/SA-21(ストリップフィルムアダプタ) + VueScanで正常にフィルムが読み込めないバグ

表題の組み合わせでフィルムをスキャンしてると、フィルムを差込んでローディングするところまでは正常なんだけど、プレビューやスキャンを実行するとフロントランプが点滅してフィルムを吐き出してしまう、あるいはスキャナがハングアップして電源を入れ直さないとフィルムを取り出せなくなる現象がたまに発生するのよね。

おそらくSA-21あるいはSA-30(ロールフイルムアダプタ)を使うCOOLSCAN IVおよびV(LS-40/4000およびLS-50/5000)だけの問題ではなく、旧型のSA-20を使うCOOLSCAN III(LS-30/2000)も同じ問題が発生すると思う(同機種手元にあるけど動かすのめんどくさいので未検証)。

まぁFH-2(ストリップフィルムホルダー)とMA-21(スライドマウントアダプタ)の組み合わせで、COOLSCAN II以前と同じ手順でスキャンすることで回避可能ではあるんだけど、COOLSCAN IV以降の機種にはこれ標準添付されてなかった上にもはや入手困難で中古でも結構なお値段するし、そもそもフィルムが抜けなくなったりすると貴重な機械と大切なフィルムを壊してしまいそうでアレよね。

でだ、読み込めるフィルムと読み込めないフィルムをしばし見比べて原因がわかってしまった、これフィルムのパーフォレーション(コマ送り用のギアが噛む小さい穴の列)に

というイレギュラーがある場合をVueScanは考慮してなくてバグってるんですわこれ。

ということで回避方法としては

とする、ですな。

Nikon純正ソフトの Nikon Scan 4では問題なく読み込めてるようなので、VueScanにも対策して欲しいところだよなーこれ、またバグレポ書きますかね…

2018/10/23(Tue)

[自宅システム管理者] HP Microserver N54LでLink Aggregation(検討段階)

この10年で写真や動画が高画質化したことで肥大したファイルのサイズがネットワーク帯域を圧迫し、そのクソ遅さにそろそろ忍耐の限界なんだが最近安くなってきたとはいえ家庭内を10GbE化するには支払能力の限界というのもあってだな、アンマネージドスイッチに5万台は無理ですわ。 10/100MbEから1GbEが普及するまではあっという間だったのにボトルネックってレベルじゃねぇぞ、2.5/5Gでもいいからはやくしてくれないかな。

つーことで10GbEなカードとかスイッチが諭吉でお釣りがくるくらいになるまでの姑息的解決策を考える、いちばんイライラする事の多いのがファイルサーバ相手のファイル転送なんだけどこれを複数のNICを束ねるLink Aggregation(LAG)で高速化ってのがまず最初に思い浮かびますな。 とはいえLAGは耐障害性でなく帯域増強を目的とするならそもそもLACP対応スイッチでないと効果は限定的だし、価格を調べるとさっきの10GbEアンマネージドスイッチ買える程度のお値段でな…

まぁそこは1GbEの歴史の長さ、企業でお払い箱になったスイッチも安いの探せばあるやろという気はする、なお消費電力とか騒音以下略。

問題はそれ以外にもある、ファイルサーバのHP Microserver N54Lの拡張スロットはすでにリモートアクセスカードとSmart Array P410で埋まってしまってる。 どっちか抜かねばならないんだけどどっち抜いても悲しみが大きい。

まぁリモートアクセスカード抜いてもWindows標準のリモートデスクトップで99%用事は足りるし、残り1%の例外的なケースもリモート機能つきのKVM持ってるのでそっちから操作するようにすれば100%だ。 しかしこのカードの役割はむしろIPMI経由でのステータス監視の方なので、それができなくなるのは悲しみが深い。

逆にSmart Array P410を抜いてオンボのSATAを使ってソフトウェアRAIDという選択、これはキャッシュ無くなると速度低下するしバッテリ保護ないとRAID5書き込みホールが恐ろしくて論値。

ハードウェアRAIDを信奉してるとどこからともなくZFSはいいぞおじさん現れて「ZFSはいいぞ」といいだすんだけど、ZFSでRAID-ZはそもそもSolaris以外でも安定して使えるのかよく判らんよね。 趣味でFreeNAS(=FreeBSD)とかOpenMediaVault(=Linux)とかでヒトバシラーするのはいいけど、オペミス以外の理由でテラバイト級のバックアップ書き戻しとか大いなる人生における時間の浪費でしかない。ハードウェアRAIDは壊れたらどうのというけどebayで中古3000円程度で潤沢にタマが存在するP410だし問題は無い、すでに予備も確保してるしな。

それと5inchベイのスペースにディスク2台追加してP410は6ポートまですでに使用済なのもネック、これをオンボSATAに戻すとなると光学ドライブ用のSATAポートの速度制限を解除する野良BIOS適用してさらにeSATAポートの内部引き込み改造とかせんとならん。

つーことでステータス監視をIPMI以外で実現することにしてPCI-E x1スロット空けるかという気分なんだけど、今度はHP純正品のNICはほとんど選択肢は無いという問題にぶちあたる。 そもそもサーバにシングルアダプタ刺す意味ってあまり無いのでデュアルあるいはクアッドポートな製品ばかりだからインタフェースがPCI-E x4とかで物理的に刺さらないのよね。

ざっと調べた限り、HP純正品かつPCI-E x1という条件に合致するのは以下の2種類しか選択肢がないもよう。

そして需要が無いということは中古品の流量も極端に低くて入手性も悪いということ、うーんこの。

まぁHP純正にこだわらなければx1でロープロファイルの1GbE NICはいくらでもあるんだけど、あいにくWindows Server 2008 R2にはOS標準でLink Aggregationを設定することができないので、各ベンダが提供しているツールのインストールが必要になる。

ツールの選択肢はだいたい以下の通り

ただしHP NCU以外のツールを使ってLAGを設定するとHyper-VのVLANが機能しなくなるという制限があったりする。

まぁHyper-VでVLAN使うことも無いんだが気分的な問題でNCUをインストールして設定することにしたんだけど、こいつについては制限事項どころかそもそもHP純正品以外のNICを認識するかすらよく判らんのよね。 もはやNICはオンボが当たり前の時代となってしまったので手元に一枚も無いんだよな、PCI/PCI-Xとかならジャンク箱にいくらでもあるんすけどね…

ちなみにPROSetやBACSでは異なるベンダ間でLAG組むのは可能(Multi-Vendor Teamingとかでググれ)みたいなんだが、TCP/IPオフロード機能をオフにしたりする必要があるようで、AMD Turion II Neo N54Lという非力なCPUだと厳しいかもしれんね。NCUも多分事情は同じで、オンボのNC107iがBroadcomなら増設もNC320Tの方がやっぱり良さそうね。

しかし困ったことにNC320Tにはロープロファイルブラケットモデルがなぜか存在しない。 いちおう同等品でロープロファイルなのはあるようなので、サイズ的に元々対応してないってことは無さそうなんだが、ブラケットだけどっかから調達して交換せんとならんのがネックやのう。

そもそもHP純正といってもOEM品なんだから同等品でも動きそうなもんだけど、ドライバのINF読んでみると

%E704AHPSA.DeviceDesc%          = E107D,       PCI\VEN_8086&DEV_10B9&SUBSYS_704A103C
%NC320T%    =  NC320T_LHinst.NTamd64.6.0,    PCI\VEN_14e4&DEV_1659&SUBSYS_7031103c

としっかりSUBSYSにOEM先の PCI Vendor ID(103C=HP)が割り当てられてるので、NCUがその値見てチェックしてたらダメやろという予測。

これだけの苦労を払ってLAG組んで結果は誤差程度の性能向上だったらちょっと悲しいものがあるので、実行に移すかどうかはちょっと要検討ですなぁ。

HP Microserver N54LのBroadcom 1GbEドライバとNCUのバージョン組み合わせ問題

書き忘れたので追加エントリ、 HPE ProLiant MicroServer G7 ServerからダウンロードできるNCUのバージョン10.80.0.0とNC107iのドライバ同15.4.0.19(B)の組み合わせだとエラーがでる、やはりHPからHPEになって増えたEはエラーのEなんやな。

まぁHPの品質の高いソフトウェアやサポート(皮肉)についてはネットワーク屋時代にいろいろあった( その1)( その2)のでこの程度なら耐性はあるので問題ない、記事にはしなかったかSmart Array P410の古いファームが引き起こす障害の数々によってシステムが何度止まってワイ針の筵に座らされたことやら(怒)。

この問題については改定履歴追いながら試行錯誤した結果、NCUは 10.90.0.0(B)にNC107iのドライバは 16.8.0.4までバージョンアップしてもOKということがわかった、世界で3人くらいには有益な情報かもしれない。

2018/10/24(Wed)

[自宅システム管理者] LACP対応の中古スイッチを探す

昨日の続きでLACP対応の1GbEスイッチ中古探してるんですがあまりそっち方面は詳しく無くてな…

昔仕事で使って操作に慣れてるHP Procurve製品から選ぶなら 2510なら2kくらいから出品あるのだけど、消費電力が家庭用にしては大き過ぎるのが困る。

オフィス向けで8ポートモデルがある消費電力の小さい 1810前にも書いたとおり窓から投げ捨てろシリーズ殿堂入りのバグがあるしな、v2というバージョンアップ出てるけど直ってるんだろうか…

ここで唐突にこのスイッチにまつわる過去の恐怖体験を思い出したので、ひとつSIer怪談話をして涼んでおこう。

実はこのHP Procurve 2510というシリーズは10/100/1000をサポートする2510「G」と、10/100までの2510「無印」という二種類がラインナップされてて紛らわしいことこの上ないのよね。 中古で安いと思って入札すると実は無印だったという事故があるのでよく注意しましょう、操作性は一緒なので勉強用と割り切れるなら安い無印でもいいんだけどね。

そんで怪談本題、ワイがプログラマだったのになぜかネットワーク屋の仕事させられとった某所なんだけど、設計書によればサーバラックに鎮座してるはずの 2510-24G(J9279A)のネームプレート、これがよーく目を凝らすとそれは前任者の発注ミスによって 2510-24無印(J9019B)だったんですね怖いですね、百物語ならぬ100MbE物語ってやつですかねポートに一本ずつケーブルを刺していき帯域がサチるとシステムごと死ぬってやつ、あるいは帯域足りな~いという番町スイッチ屋敷。

新品の定価は12万に対して7万くらいだったはずなので大企業さまが導入に躊躇して下位を選ぶ価格差ではないよね、後者はファンレスだといってもオフィスに置くわけでもなくデータセンターに置くんだからいくら爆音発したってOKなわけやし。 ちなみに気づいた瞬間のワイは、サーバラックの中からジャック・ニコルソンが斧で扉を叩き割って狂気の微笑をみせる幻覚をみた。

そんなんすぐ発覚するやろーと思われるでしょうが、しっかり発注ミスが発覚しないようスループット重要なサーバ間だけ余りモノのNETGEARとかPlanexの安物ギガハブで繋ぐ工作を施されておった。 よって無事にババはワイに引き継がれたもよう、最初なんでこのスイッチはメインのはずなのにスカスカなんやろと不思議に思ったんだよな…

そのまま放置してもよかったんだけど、タイミング見計らって今後サーバ増強する時に即対応できるように48ポートにリプレース必要ですねーと偉い人を適当にいいくるめて予算確保し、後継の 2530-48Gを導入した上で後任に引き渡しましたよ、ババ引いたらババは自分で処理しろ他人に引かせるなという俺のジャスティス。 まぁワイも継続性でProcurve選んだけども、まさかその数年後にHPがAbura Networkを買収したことでProcurve自体がオワコンになるのまでは予見できなかったけどな!

そんで今気づいた、2530-48Gの設定についてあまり深く考えずに前任者が2510-24に施した設定をほぼそのまま踏襲したんだが、Link Aggregation組んでるポートにLACP設定するの忘れとりましたわ。 まぁワイの後任がまともなネットワーク屋ならどっかのタイミングで気づいて直してワイの事をバカだ無能だと吹聴してくれとる事やろう(希望的観測)。

[自宅システム管理者] HP NC332T

もう少し調べたらHP純正のNICでBroadcomチップかつPCI-E x1に刺さるNICには NC332Tというデュアルポートなやつもあるのね、こっちは純正でロープロファイルも用意されてるのでNC320Tよりこっち探した方が良さそうね。 まぁNC320Tより更に中古のタマ数少なそうやけどね…そらそうよデュアルポートなら帯域考えてふつーにPCI-E x4のやつ買うし。

あとNC320Tはジャンボフレーム非対応なんだけどNC332Tは対応してるのな、まぁオンボのNC107iの方が非対応だからLAG組むなら使えないので以下略。

2018/10/25(Thu)

[プログラミング幻語C] intmax_tはいうほどクソか?

open-std.orgのintmax_tの話、そもそもintN_tと混同してABI安全な型だと勘違いしてたのが間違いに気づいて逆ギレして騒いでるだけなんじゃねかなこれ。 ちゃんとlibcの実装に関わったことのある開発者ならいまさらこんなこといいだすはずがないと思いたいんですけどねぇ…

そもそもこれってtime_tを32→64bitに変更するような部類のものでlibcのsoname変更は当然という認識がlibc開発者には元よりあったはず、無いならちょっと不勉強すぎてだな… つかABI破壊なんてlibc開発者にはチャメシインシデントで、OpenBSDなんかリリース出るたびにABI破壊しとったぞ、Nとかglibcは__RENAMEとかsymverで可能な限り回避はしておるけど。

この話って元々はint128_tを追加したい→intnmax_tのABI変わるで→ワーワーギャーギャーという流れなんだろうけど、そもそもgccの__int128とか使ってる人いるんですかねアレ、SSEなら自前の__m128あるしな。 焼いたクッキーの枚数を数えるのに欲しいとかならJavaのBigIntegerみたいなもの実装するほうがいいだろうし。

そんでこの話はABI壊れるなんて話よりintN_tはそもそもプリミティブ型ではないのでそれぞれ対応するプリミティブ型のtypedefとして実装する必要があるってところの方が重要よな。

まず最初に思いつくであろうアイデアとしてはlong long intを128bit化してしまえなんだけど、生憎IPL32な環境においてはlong intは32bitだからlong long intを64→128bitに変更するとint64_tに対応するプリミティブ型がシステム上に存在しなくなってしまう。 そこを無理矢理にIPL32環境はレガシーと切り捨てて(無理やろうけどな)、LP64環境だけでええんや!と主張したとしても今度はsizeof(long long int)が4から8になることでABIが崩れるだけでなくマナーの悪いソースが動かなくなる。

となると新たにlong long long int型 *1を追加するしかない、まぁstrtolll/llldiv/lllabsといった新規関数の追加とprintfのフォーマット指定子に"lll"を追加せんとならんけど、intmax_t関連以外にABIへの影響は無いしソース互換はバッチリなのよな。

ただここでひとつ問題があって、C99あたりからの傾向だけども型は追加するのはOKだけど、その型を扱うためのAPIを増やすのは嫌がられるという傾向があるのよね。 なのでintN_tの導入時にstrtoiN/iNdiv/iNabsは実装されなかったし *2、char16/32_t導入時に至っては本来はwchar_tの為のAPI(isw*とか)を乗っ取ろうとするムーブまであった。

とはいえ必要になるならしゃーないので戦力の逐次投入は負け戦だし一気にドーンと

typedef long long long int				int128_t;
typedef long long long long int				int256_t;
typedef long long long long long int			int512_t;
typedef long long long long long long int		int1024_t;
typedef long long long long long long long int		int2048_t;
typedef long long long long long long long long int	int4096_t;

くらいは追加しておけばいいんじゃないですかね(マジキチスマイル)、strto*/*abs/*divについてはC99 tgmath.hの尻拭いに導入されたC11の_Generic(Generic Selection)みたいな紛い物ではない、本物のジェネリックプログラミングをCに導入をだな…

ネタはおいといて、いっそのことintN_tの方をプリミティブ型にしてint/long int/long long int/の方をtypedefにしてしまう方がいろいろスッキリするのだけども、そうするとこいつらの実装が難しい36bitワードみたいな変態アーキテクチャ(今となっては)の立場が無いのよな。 おいおいNですら諦めたPDP-10みたいな過去の亡霊どうでもええやろ…とお思いでしょうが、UNISYS社の現役メインフレームの Cコンパイラのマニュアルの4-11ページの4.5. Size and Range of C VariablesにあるTable 4-6. Summary of the Size and Range of Data Typesの表をみると、まだ36bitワード現役なのですわ。 やはり UTF-9/UTF-18は決してエイプリルフールのジョークではない(マジキチスマイル)。

*1:電磁ナイフのドグ「3回もlongって言いやがった!」
*2:そもそもstrtoiすら無いので未だにatoiが使われてしまうのもアレだよな…