このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

日常動作で左の上腕三頭筋が攣った

いや〜今日はよく運動したなぁ (白目)

痛いが

歩くだけで腕が攣るの、人生カウントダウン最終盤が見えてきたな

このアカウントは、notestockで公開設定になっていません。

PrintScreen 引っこ抜くといざというときの Magic SysRq が使えなくてヤバいので Scroll Lock くらいで容赦してあげてほしい (?)

唐突に電卓を作りたくなってきたので、そのうち作るかもしれない。もちろん標準ロジックで。

論理回路の設計はやるだけなんだけど、ブレッドボードへの配線がまーじで面倒、前もそれで CPU (というか ALU) の素子数を最適化したところまでで実機組まずにやめた

電卓、等価な挙動をする実物が市販されていて入手性も高く、部品も素朴で済み、状態を持ち、日常における実用性が多少あり、動作の検証も容易という、雑に作ってみる教材としては最高なんだよな

論理回路の教科書に順序回路のサンプルとして載りがちな自販機とかよりもよほど現実的で面白いでしょ

#らりおメモTODO

こういうことを考えると論理回路シミュレータ作りたくなってくるんだよな、本当に良くない癖だと思うんだけど

アナログ的な性質を全無視して素子の遅延をどうにかする程度なら書くだけの作業だろうけど、一番の問題は回路図の編集とか配置の自動化とかそういう UI 面なので地獄

でもやっぱり動いてる様子可視化したいじゃん？

べつに SPICE みたいなのが必要なことをしたいわけじゃないんですよ。雑に論理回路作るだけなら1と0とハイインピーダンスがわかれば十分なわけで。

永眠谷のなかまたち

12時からミーティングです
#今すぐ寝ることで救える命があります

Your code displays Japanese wrong | Your Code Displays Japanese Wrong
https://heistak.github.io/your-code-displays-japanese-wrong/

> In short, from a native Japanese eye, yѳur ҭєxҭ lѳѳks κιnd ѳf lικє ҭЋιs.

これ良すぎるな、副題にしてもいいくらいだ

メールサーバ (メモリ 1GB) の available メモリが 9.5% になったぞと警告メールが飛んできた

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

そういえば Firefox が旧時代の NPAPI を捨てて WebExtensions に移行した (Electrolysis) ときもかなりのユーザが Firefox を “見捨てた” けど、この移行を敢行しなければいずれエコシステム全体が web から取り残されて朽ちていただろうし、今振り返ってもやっぱりあれは正しかった

ソフトウェアやエコシステムに対して「俺と共に朽ちて死ね」と言い放つような人々をどう相手にするかというのは商業だとかなり厄介な問題なんだろうなぁ

実際顧客は自分が生きている間、もっと言えば自分がそれを使っている間さえ良ければその後どんなツケがあろうがどうでもいいわけで

このアカウントは、notestockで公開設定になっていません。

そもそもの話をするなら、アプリケーションが最新の API 等に追随していかないところに問題があるのであって、開発元が何もしないのであればユーザが代わりにそれをするという選択肢のある自由ソフトウェアこそが救いなんですな。 MS ではなくアプリケーションに求めるべきことだってある。 (適当)

このアカウントは、notestockで公開設定になっていません。

NVIDIA 495.44 Linux Driver Released With GBM Support - Phoronix
https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver

GBM サポートが stable ドライバに降ってきたからね

Remove --my-next-gpu-wont-be-nvidia by emersion · Pull Request #6615 · swaywm/sway
https://github.com/swaywm/sway/pull/6615

> Note, proprietary Nvidia drivers are still unsupported by the Sway
project (just like all other proprietary drivers).

まあ、ね……

iFixit：Appleのメンテナンス用布「ポリッシングクロス」を分解、修理可能性評価で10点満点中0点を獲得 | アクセサリ | Macお宝鑑定団 blog（羅針盤）
http://www.macotakara.jp/blog/accessories/entry-41978.html

しょーもなくて草

このアカウントは、notestockで公開設定になっていません。

そもそも情報技術は情報を扱うものであるからして、意味論と構文の変換はその中核にある概念なのであって、たとえどんなに普及していようが意味論がカスならばそれはいずれ置き換えられるべき

「ユーザがいるから」と破壊的更新をやめるのは完全に「動けばよし、動くかどうか以外での観点では評価しない」というスタンスであって、開発側がそういうこと言い始めたらもうオワりですよ (まあ実際そうなったら開発側が見捨てられるだけだろうけど)

このあたり機械や物理的な産業との根本的な違いで、機械におけるモジュール化や規格化によるメンテナンス性とかは本質的には「構文」の部分であって、物理的現象で「意味論」をうまいこと表現する試みってのはそもそもないと思うのよね

極論言えば、あらゆる物理的機構は「動けばよし」をその本質としているのであって、その物理機構におけるアナロジーを情報技術の世界に持ってくるのはそもそも哲学が違いすぎて不適当だと思います

たとえばアクセシビリティを考えるとき、紙面や画面での表示だけを考えるのであれば色とか配置とか大きさとかをメインで考えることになるわけだけど、情報技術が目指すべき地点はそういうところではなくて、人間を仲介しない機械同士のやりとりにおいて「この部分はこういう意味を持っている」という解釈が表明・保存されるという、ひとつメタな階層での情報を扱えないといけない

HTML 4 や 5 が必要になったのも、そういう「見た目 (物理的要素) だけ制御できればよし」という旧来の虚無意味論を脱するためのものでもあるわけで、そういう意味ではそもそも「人間にわかればよし」「人間が使えればよし」みたいな基準を第一とするような考え方自体していない

少なくとも “UI” とかについて語るとき大抵は構文 (物理的な性質) の方を語っているわけで、現行の UI がクソであることを以て意味論を操作しようとするフレームワークを語るのは的確とは言い難い

それは HTML の問題ではなく JS の問題なので。まあそもそも私はああいう動的文書が嫌いなので XML に傾倒していたりするわけだが

まあ HTML 側が JS 依存の考え方をしだしていることは否定しないけど、それは <article> や <nav> 要素が導入された功績などとは別で語られるべき

意味がわかりませんね、 HTML 4 の時代からそれは顕著だったし 5 が原因だとは思いません

少なくとも全てを <div> で表現していた HTML 4 の時代が「見た目だけ合ってればおｋ！」でなかったとは絶対に思わないですね

マルチカラムレイアウトとかがまともに機械可読に書かれるようになったのだって HTML 5 + CSS 3 のおかげで、それ以前の惨状といったら

Web Components はそもそも文書のためのものではない (と私は思いたい) し、「アプリケーションの UI 記述言語としての HTML」という面が強く出てきているとは思うけど、だからといって静的な文書の記述の状況が悪化したとは思いません

「アプリケーションのつもりで文書を書いてる連中が多くて辟易する」だったら私も同意しますが、それは HTML 5 かどうかは全く関係なくずっと昔からそうだったので

まあ「UI 記述言語と文書記述を分けろ」みたいな話はあるし私もそう思うけど、そもそも構造と見た目の分離が CSS 3 で正しく行われていないと思う人は当然 XSLT と XSF-FO のことは知っていると思う……

まあ AJAX で全てを破壊しはじめた元凶がｺﾞｯｺﾞﾖだと言いたいならお気持ちとしてはそれはわかる

お気持ちとしてはわかるが、じゃあ逆に「文書記述言語で済んでいたところを UI 記述向けにしなかった未来」がどうなっているかと考えると、 “互換性” を壊さないような規格更新では当然、 UI 記述には不適格な意味論を持つような要素を駆使して UI が記述される未来が待ち受けているわけで、それは氏の主張と自己矛盾しているのでは？

UI 記述のために <div> が無限に駆使される世界のどこが「『動けばよし』ではない」のか、わかりかねます

HTML 5 が二兎を追っているにせよ、現実に既に存在している用法について適切に意味論を表現できるようにすることで機械による解釈がより適切になるようにした、という点で HTML 4 のまま闇の技術がどんどん発明されるよりもずっと健全な未来になっていると思います

XUL は息絶え絶え、 XSLT は 1.1 を最後にオープンな実装がほとんどなく、 XSL-FO も CSS に取って代わられ……

まあ現実なんてそんなもんよね。「動けばよし」の人々が力を持った未来がこれだと思ってます

えらい棒なしなら 1GB でギリギリ動く

リーダーモードでナビゲーションバーとかを除外して本編だけを抜き出せているのなんて、機械可読性の恩恵の典型例でしょうね

このアカウントは、notestockで公開設定になっていません。

XSL-FO 、私の知っている用法だとやっぱり PDF 生成なんだけど、最近ブラウザのレンダリングを使って PDF 化みたいなのが流行という印象もあり

XSL-FO ちゃんと使ってるの、アンテナ某の製品か AsciiDoc から PDF 生成するときのツールチェインくらいしか知らない

ちゃんと……？ (AsciiDoc の方はちゃんと調べてないのでもしかするとかなり雑にやってるか)

このアカウントは、notestockで公開設定になっていません。

ｳｪｯﾋﾞページを SVG へと印刷したいと何度思ったかわからない

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

BanDrive されそう (?)

このアカウントは、notestockで公開設定になっていません。

近年のなんたらスタックに通じるところがあるな (なんだっけ)

JAM stack だ

そういえば書き忘れてたけど、商業的な (ﾋﾞｽﾞｨﾈｽの) 動機ではむしろ機械可読性は落とす方向に向きがちで、つまり「我々の意図した見た目を寸分違わずユーザに見せたいのであって、ユーザが勝手に弄るのなんて認めねえぞ」というわけですね。
だから近年のサイトの機械可読性が落ちていると思うのなら、それは技術的劣化というより金銭的な動機が強まっている可能性もあると思います。

典型的には広告と本文の区別をつきづらくしたり、広告隠しを禁止したり、スクリプト実行禁止ではページを閲覧できないようにしたりなどです

このアカウントは、notestockで公開設定になっていません。

まあ実際これで、その帰結が <https://mastodon.cardina1.red/@lo48576/107179277131385486> これなのかなと思うところもあり、若干の諦めはあります

私は意味論に執着しがちなオタクなので XML から XSLT 使ってﾌﾞﾖｸﾞを生成していたりしますが、まあイマドキみんな markdown で「見えればよし」になっているのでそういうことですよね……

そう、 markdown 、あれこそ意味論軽視の典型的な例よね。なんなら HTML 4 より悪化してるのでは

まあ「何か書きたいと思ったとき HTML の意味論なんかいちいち把握してられんわ」というのも気持ちはわかるけど、つまりそれが「見えればよし」なんですよね……

そしてメタデータの欠如に困った人たちが次に言い出すのは、「ｴｰｱｲでメタデータを付けてやろう！」というわけです。
白黒写真に勝手に色を付けるようにね。

だもんで、一人の意味論のオタクとしてはせめてもの抵抗として、意味を精確に記述しそれを必要に応じて表現に変換するというプロセスは何としても死守したい

コンテンツを作る前にその意味的な構造を考える、そういうオタクでありたいわね

たとえばの話だけど「対訳」をうまいこと表現できる意味論って既存の文書形式にはほとんどない気がしているのよね。だったら自分で考えて実装するしかない。

HTML が表示寄りの形式だなと強く思うのは、 footnote をネイティブに書けないところかなぁ。

まあそうする理由もわかるんですよ、脚注が本文の横にあることもあればページの最後にあることもあれば章の最後にあることもあるので。
(まあ XSLT みたいな技術を使えばそのあたりのコントロールもきっと実現できるはずなんだけど……)

このアカウントは、notestockで公開設定になっていません。

FILCO、カナダTruly Ergonomic製キーボードを発売 - PC Watch
https://pc.watch.impress.co.jp/docs/news/1361811.html

やっぱり columnar でも右手のキーはちょっと多いくらいが嬉しいよなぁ (手元の Moonlander を見ながら)

このアカウントは、notestockで公開設定になっていません。

あともうひとつ思い出したけど、 HTML 4 やそれ以前の時代は JS (あるいはその標準) が貧弱だったせいで Flash などが横行していたのでした

そりゃ Mozilla が原理主義に走ればそれはそれで面白いだろうけど、結果として置きることはかつてのブラウザ戦争で、その結果ユーザが被った被害の悲惨さは今更言うまでもないので、その歴史と教訓を無視して「Google や金儲けに与している」と言うのはフェアじゃないですよね

政府として同じ方向を向けないなら国を割れと言うだけなら簡単だけど、その結果悲惨な目に遭うのは市民ですからね

s/置きる/起きる/

漫然漢字変換！！！！

そもそもそれは逆で、言ってみれば「ユーザが『動けばよし』で黒魔術を発展させ続けるから仕方なく標準化している」という面は大きいと思っていて、ブラウザベンダーが絶対権力として標準を支配しているという考え自体がちょっと違うのでは

情報技術系はそういうところあるけど、基本的に「ユーザ」が完全に受け身の消費者ではなく、同時にその技術で何かを生み出す生産者であることが多いので

このアカウントは、notestockで公開設定になっていません。

Living Standard は本当に愚行

でも結局 W3C ではなく WHATWG が支持されたわけで、そういうことなんですよね……

意味なんて誰も気にしていない、 markdown を書かせれば admonition のつもりで blockquote を書く、啓蒙されてない人類ってのはそういうものなんですよね

自分が何を書いているのかわからなければ、どんなに適切な機構があろうとそれを使おうとはしないし、結局のところそこは教育の問題になってしまうと思う

lint を動かそうにもその linter が文書片の意味を解釈するために本来メタデータが必要なのにそれが欠けていたり誤っているわけであって……
結局そこは技術の責任ではなく人間の責任なんですよ

このアカウントは、notestockで公開設定になっていません。

行頭空白は blockquote ではなく preformatted text では

そういえば preformatted text block と code block も特に混同されやすいやつだわ

HTML の <pre><code> はどうにかならんのかと思うことはしょっちゅうあるけど、じゃあどうするかというと……
今の HTML って block element と inline element みたいな区別じゃないから

？

それは思想のある Mozilla とかが頑張っただけで、 Google は「人々に反感を持たれないよう都合の良い広告機構を用意したい」くらいしか考えてなさそうじゃないですか？
むしろその結果にこそ Google を支持しなかった人々の意志が反映されている気がしますが

あと黒魔術の排除を喜ぶのがどうなのかという話については、そもそも旧規格の力不足な標準に耐え切れず人々がブラウザベンダー拡張を使い始めれば「規格を更新しないことによる互換性維持」なんて方針は簡単に崩壊することは容易に想像できますね

なぜブラウザ戦争後の時代にあってなお -webkit- prefix やら何やらが問題になっていたのかという話です。あるがままの標準を形だけ守り続けていたって意味ないですよ

こういうこと書くとまた機械工業を引き合いに出して web 系のリテラシーが何たらとか言われそうですが、そもそもの話 web 環境はハードもソフトも性能が向上し続けているわけで、重力定数や光速度や気体定数が変化しない現実の物理と対比して教訓を得ようとするのが既に筋違いです

計算素子や伝送路の進歩が完全に止まったら、そのときは機械工業と表面的にも同じような成熟が期待されるんじゃないですか。何十年後のことかわかりませんが。

https://mastodon.cardina1.red/@lo48576/106765585480760850

IE の話してます？

それが内紛に繋がり最終的に web 開発者も完全に受け身な利用者も被害を被るとわかっているから、そうしないよう協働しているんじゃないんですか

まあ原理主義者が争いを起こすことを望むのは勝手なんですが。

セキュリティのことを考えても同じこと言えます？

ハードウェアとオンライン環境の最も違う点は攻撃手法の進化ですよ

まあべつに現実のたとえば錠前破りだって手法は進化しているわけだけど。

なんでもウェブにやらせることに反対する人が足を引っ張ろうが世界は関係なく進んでいく、そういう話をしてるんですよね。だからこそブレーキをかけるだけでなく進んでしまうことを前提に舵取りをしないといけない

お手元だけ綺麗になっていればいいという話ではない

あなたのお手元だけ理想的な環境になっていることは、世界中の端末が緩く結合する web においてクソほどの価値もないです。というか自分から web との接続を切っているだけ。

だから全ての欠陥が事前にわかるというのが思い上がりだという話ですが……
サイドチャネルアタックとか暗号開発とかの歴史の話したほうがいいですか？ (面倒なのでしません)

あと実装に多様性のある状況だと、ある実装が新機能を提供しないことは他の実装が稚拙ながら先に行くことを妨げることはできないし、結果としてその稚拙な実装が標準になってしまうことを許容することにもなるわけですよね

まあその辺はｵｯﾍﾟﾝｿｯｽ開発の歴史でも調べればいいんじゃないですかね (適当)

ワイも正直商用 UNIX とか NCSA Mosaic 時代のブラウザとかの話にはあまり詳しくないもので。

よーするに RHEL とか Debian でやってるみたいなポリシーを要求してるんですかね。
それならそれで個人の勝手なんですが、なぜ人々が Debian より Ubuntu を好んでいるのかに目を向けた方がいいと思います

あと古代の単純な技術は安全だったというのは大いに幻想だと思うので、複雑になったことこそが現代のソフトウェア環境が脆弱である原因であるというのはどうなんでしょうね (一因であることは否定しませんが)

それこそ IP なり TCP なりもっと下のレイヤーでも、昔のプロトコルは “牧歌的” だったわけで、牧歌的であることをやめるために必然的に複雑性が増したのであれば、むしろソフトウェアの複雑さの一部は「本来求められているセキュリティ水準に近付くための必要経費である」という捉え方をすべきですよね

認証・認可系やセキュリティの技術、ローカルリモート問わずだいたい複雑なので。 policykit とか logind (consolekit) とか SELinux とか OAuth とか OpenID とか SSL/TLS とか TPM とか……

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索
https://forza.cocolog-nifty.com/blog/2017/05/post-3793.html

思い出したけど、これ至言よね

リーマンの法則～ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索
https://forza.cocolog-nifty.com/blog/2012/08/post-9619.html

> リーマンの第1法則
> 　使われるシステムは変化する。
> リーマンの第2法則
> 　進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
> リーマンの第3法則
> 　システムの進化はフィードバックプロセスによって決まる。

https://mastodon.cardina1.red/@lo48576/107179637950671494

で、「複雑性を減らす取り組み」というのは要するに outdated になったと判断されたユースケースを除外していくことに他ならないわけですが、それは互換性の破壊なわけですよね。
この “法則” を認めるなら、互換性と単純性と「使われること」の3つは同時には両立させられないということじゃないですか？

あるいは、ユーザ自身が開発者となって自分の側で必要なロジックを実装することにすれば、共有されるツールについての単純さは保てるわけですが。
それって結局「ユーザ自身による開発まで含めてやっとシステムとして成立する」ということであって、受け身なだけのエンドユーザはお呼びでないですよということになります。私はそういうロックなシステムも好きなんですけどね。

互換性があくまで自分だけの過去資産についての問題であるならば、いつそれを切り捨てるかの問題も完全にユーザ自身が制御できる。

でも共有される web 資産にそれは通用しません

氏にとって必要十分である範囲が市場の要求 (あるいは “善良” な人々の要求) と一致していることについて自信がないので、何が「必要」の範囲で何がそうでないように見えているのかについては説明できかねますが

少なくとも「単純にすればするほど人々に使われない (つまり今まで使っていた人々にとっては破壊に見える) ことになる」とか「機能の追加や整理を避ければ避けるほど、ユーザの増加は鈍化して別の (追加や整理に積極的な) システムのユーザが増加していく」くらいの雑な推論はできるんじゃないですかね

そうだなぁ

たとえば HTTP 接続を HTTPS にリダイレクトする仕組みはクライアントに要求する複雑度を異様に上昇させるうえ互換性を破壊するわけだけど、これは許容できますか……みたいなことはたまに考えるね

なお、これを許容しない場合ユーザは中間者攻撃のリスクに晒されるうえ安全な認証も極めて困難になります (そこを安全にしようとするなら最初から TLS 使った方がいい)

とはいえ、たとえば盗聴を許容するのであれば真正性の検証を外付けの電子署名にすることでどうにかする手はあって、たとえば Linux の distro のパッケージマネージャがアーカイブをダウンロードしてくる仕組みとかはそういう感じにできるようになっているのが一般的。
もちろんこれは事前に安全なハッシュや署名鍵が共有されているという前提での話だけど。

たとえばそういう "SafeWeb" を作ったとして、人々がいつまでそれを使い続けるのかという話です

使われないシステムをセキュアに保つことに何の意味があるんです？

もちろんローカルの特定目的での文書の保存とかには使えるかもしれませんが、それは "web" ではないので。
(CHM とかはそんな感じか)

"SafeWeb" で満足できなくなった人が "AdvancedWeb" を作り始めて人々がそっちに移行するだけですよ。
ついでに "AdvancedWeb" のクライアントが "SafeWeb" のデータも読めるようにしてしまえばおしまい。

そうですね、たとえば2021年に Gopher プロトコルを使っている人を私は見たことがないです

だからその「機械産業を想定した倫理観」がそもそも現実と乖離しているという話を私はですね……

https://mastodon.cardina1.red/@lo48576/106104920469021576
https://mastodon.cardina1.red/@lo48576/106000988781561095

このへんですね。
責任が「消費者から製造者に移動されるか否か」というのは自明のルールではなく、あくまで現実とコストを照らし合わせての判断にすぎないわけですよね。
物理機械で製造者にあらゆる責任を押し付けられるからといってソフトウェアで同様のことをすべきかというのは全く非自明だし、私は少なくとも賛同はできない

プロプライエタリな技術についてその利用における責任をある程度開発者や頒布者に押し付けるというのは、まあまあ筋の通った話だと思いますが。
それはソフトウェア一般に適用可能な話ではないでしょう

そうなったら誰も web 相当の技術を使えなくなってオワりですね。

もっと良い話としては、その辺りの法規制の緩い国で技術が発展し、標準化能力を握られ、これはいかんと後追いする日本は永遠に後塵を拝するみたいな未来が待っています

このアカウントは、notestockで公開設定になっていません。

はい。
その無保証であるがままが提供されることの倫理的な裏付けとして「そんなに心配なら、その心配の強さに応じたコストでお前自身が検証することができるだろう」という自由ソフトウェアの在り方があると思っているので

少なくとも金属や複雑な材料で構成された機械が頑丈であることを確認するために必要な諸々のコスト (主に機材の金銭面) を考えると、自由ソフトウェアのソースコードを読むのに必要な金銭的コストは圧倒的に低いですよね。
そのうえで知識面でのコストが支払えなくて、かつリスクを許容できないと思うのなら、そもそも使わなければよろしい。

実際「オープンソースなんか信用できるか！」つって自前で開発してるところも沢山あるんじゃないですか。