{見過ごしてしまった}{内部処理}{`loading.html`}{気付きかけた}{後方互換模動}{`<iframe>`}{`<!DOCTYPE html>`}{希哲16年1月21日7歩}{希哲16年1月21日の進捗時限}{希哲16年1月21日の進捗}...=}(57)

{希哲16年1月21日10歩 K#F85E/A-E74C-38B2}

進捗時限記録中略

領下手定め環境での開発者通類梱装がすっきりしたところで,<!DOCTYPE html> がなくて後方互換模動になっているという警告が出ていることに気付き,調査

結局FirefoxAutoPagerize AdvancedChromeAutoPagerize<iframe> 要素内に表示する HTMLDOCTYPE 宣言 が無いことによる問題だった。よく読めば拡張機能から出ている警告であることは分かるが,勘違い重なり気付くのに時間がかかった

まず,デライト出力するソースを見ると,以下のように不自然出力になっている。これは特に問題ではなかったが,ここでデライト出力に何か混入しているのかという勘違い発生した。

<!DOCTYPE html><html lang="ja-JP">

<head ...

ただ,試しにここを修正しても警告は消えないし,全知検索検索結果によって警告が出たり出なかったりする。ここで AutoPagerize Advanced問題かと気付きかけたところで,Chrome でも同じ警告が出ていることを確認。これで「拡張機能問題」という考えんでしまった。だいぶ前に Chrome にも AutoPagerize引装していたことを忘れていた

小一時間悩んだ挙句Firefox警告表示されている loading.htmlクリックしてみて正体分かった。これも一見内部処理関連っぽい名前なので見過ごしてしまった

何はともあれ,デライト問題がなくて安心した

=}
{デライト}{外部スクリプト}{角括弧}{読み込む}{描画}{混乱}{記法}{検証}{検知}{修正}...=}(19)

{数式の描画について K#F85E/A-E74C-D7A6}

報告検証ありがとうございます。ご指摘を受けて調査してみたところ,単に角括弧を使った記法への対応が抜けていたことによる不具合のようです。

デライトでは,外部スクリプトが必要な記法検知すると外部スクリプト読み込むように HTML出力します。したがって,ページのどこかで数式検知されている(「標本: 数式表示」の場合は丸括弧による数式)と,単体では検知されていない数式も正しく描画されることになります。

出来るだけ早く修正いたします。混乱させてしまっているようでしたので取り急ぎご報告まで。

{ネット環境整備}{上がった}{急ぐこと}{使えていない}{一連の}{時間はかからなかった}{簡単な}{もう数日}{当たった}{手頃な}...=}(54)

{希哲15年10月26日の整清 K#F85E/A-E74C-B2DE}

ネット環境整備仕上げなど。

無線 LAN 子機Archer T2U Nano から Archer T4U Plus換装し,USB 配線整理

T4U Plusドライバrtl88x2bu簡単な引装インストールのみで認識され,その他設定引き継げたので,動かすまでに時間はかからなかったUSB 配線整理USB 3.0 ポート認識不良についての調査未解決時間がかかった

iw で見る限り信号強度若干改善に留まったものの,たまに不安定化することもなくなり,平均的通信速度上がったのか,以前の光回線有線 LAN と比べても遜色ない体感速度になった。T2U Nano不安定化アンテナ性能問題という見立て当たったようだ。

もう数日様子を見たいが,すっきり身軽になり,これだけの通信品質確保出来たのだから,一連のネット環境整備は今のところ大成功と言ってよさそうだ。

あと気になるのは各機器耐久性と,まだ USB 3.0 ポート使えていないことくらいで,特に急ぐことはない。

T2U Nano手頃な予備として保管しておく。

{Slackware 時代}{ネット環境整備}{希哲15年10月26日の開発}{希哲15年10月26日の整清}{内部配線}{試していない}{良い復習}{弄っていなかった}{変わらなかった}{核脳再構築}...=}(70)

{希哲15年10月26日9歩 K#F85E/A-E74C-A67B}

ネット環境整備配線整理過程SLFS における USB 3.0 ポート認識不良についての調査始めたものの,未解決保留

主力機には筐体前面背面にそれぞれ2つずつ USB 3.0 ポートがあるが,Linux では Slackware 時代からいまいち使えた試しがない。それもそのはずで,どうも USB 3.0 ホストコントローラー認識されていない最初から Windows仮想機でしか入れていないので,Linux 固有問題かもしれない。

lspci では Etron TechnologyEJ168 が見えるがドライバ表示がなく lsusb では表示されない。

怪しいのは UEFI核脳構配起動応付あたりだが,今のところよく分かっていない。UEFI 設定見直した明らかおかしい所は見つからなかった

核脳構配では,そもそも USB 3.0有効にしていなかったので CONFIG_USB_XHCI_HCD=yCONFIG_USB_XHCI_PCI=y加えて核脳再構築をしたが,相変わらず。更に CONFIG_USB_XHCI_PLATFORM=y を加えても変わらなかった

これまで使っていた Linux 核脳 vmlinuz-4.9.9-slfs-t2希哲11年6月28日備立したもので,しばらく弄っていなかったので,良い復習にはなった。今回の備立は一応 vmlinuz-4.9.9-slfs-t3 としておいた。今後何かと調整しやすくなるだろう。

起動応付変更はまだ試していないが,急ぐことでもないので今日はこの辺でやめておいた。

内部配線問題もありそうな気がしてきたので,今度の主力機清掃時に確認してみる。

{握接}{デライト}{39回}{収まった}{21時台}{13時台}{受け流していた}{忘れ去られている}{希哲15年10月23日の開発}{https://mn.kitetu.com}...=}(53)

{希哲15年10月23日10歩 K#F85E/A-E74C-8B02}

Mastodon 対策終了

になってデライト頻繁停止再起動しているのが気になり,調査したところ,キット*メーネ運用していた https://mn.kitetu.com をいまだに Mastodon 捌き認識して /inboxPOST してくる捌き手が複数あることに気付いた

閉鎖して 410 Gone を返すようにしたのが昨年3月24日のことだったので,もう流石に忘れ去られているだろうと思っていたが,放置していた Mastodon 専用の捌き手はずっとこれを受け流していたらしい。

deln.confhttps://mn.kitetu.com への握接一律 410 Gone を返すようにして同現象は収まった

デルン出力録を見ると,DNS 設定整理でいったん全てのウェブ捌きsss-2集約した13時台から対策を施した21時台までに再起動多発しているのが分かる(およそ8時間39回にかけて頻度が高くなっているのは投稿活発になってきたからだろう。

=}
{調査}
{}