HTML がガバ文法を受け入れる方向に進んだのもそうなんだけど、ある意味では「vaidator や linter を前提とする」という方向に舵を切れなかった時点で将来を読み違えており衰退への第一歩を力強く踏み出してしまっていた、みたいな感じがあるのかなぁという気持ちです >XML / HTML

ポステル則はプロトコルについては確かにその通りなんだけど、 HTML とか XML とかはもっと長期保存されるデータとしての側面も持っていたわけで、そこで validity を重視できなかったのはやっぱり決断の誤りだったのかなぁという後知恵

@skoji スキーマ言語も XML Schema とか RelaxNG どっちがデファクトスタンダードなのかはっきりせず、 post schema validation infoset についてのスタンスも統一できておらず、その辺りで validation するにしてもいい感じに「これを使っとけば安心」というひとつの標準がなかったのも良くなかったのかなぁという感じがあります

DTD はさすがに死滅したと思いたいけど、 XML Schema と RelaxNG は結局どうなんだというアレはある

あとこれはとても個人的な感想なんだけど、 XML Schema みたいなの、型システムとしては大層パワフルで、処理系の実装がさぞ大変だろうなぁという感想があり、これもまた validation しづらさ (ツールの作りづらさ) に拍車をかけていたのかもしれないみたいな感想もある
(が、実情がどうだったかは知らない)

正確なスキーマをロジック (実行可能コード) ではなくデータで表現するなら、処理系が複雑になるのは当然の帰結であって、そこで「これを使えば安心の標準」を打ち出せなかったのは良くなかったのではないかなぁという無責任な想像をしている

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

MathML とか SVG とかは？

The MathML RelaxNG Schema
https://www.w3.org/Math/RelaxNG/
RelaxNG schemas for SVG 1.2
https://www.w3.org/Graphics/SVG/1.2/rng/

MathML も SVG も w3c から RelaxNG スキーマ出てますね

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

うなブリッジ……？？？

Unabridged Pentium 4, The: IA32 Processor Genealogy (PC System Architecture Series) | Tom Mindshare Inc. Shanley | Microprocessor Design
https://www.amazon.co.jp/dp/032124656X/

ぴけ氏のイラストが待たれる (???)

#575

@eniehack https://mastodon.cardina1.red/@lo48576/102618872380403607

RelaxNG 、直接の子でない子孫についての除外指定が若干書きづらかった気がしているんだけど、最近書いてないので記憶が曖昧

たとえば「a タグの子孫に a タグが現れてはいけない」みたいなの面倒そう？ (よく覚えてない)

Re: [relax-ng] A mechanism for handling inclusion/exclusion
https://lists.oasis-open.org/archives/relax-ng/200401/msg00000.html

DocBook NG: The “Absinthe” Release
https://norman.walsh.name/2004/01/01/absinthe#exclusions

SchematronによるXML検証 | Netsphere Laboratories
http://www.nslabs.jp/xml-schematron-with-relaxng.rhtml

Schematron 割と私好みのアプローチだなぁ

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

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

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

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

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

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

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

PermitRootLogin no
と
PasswordAuthentication no
は絶対必須よね

私の場合、たとえば自宅鯖は Port 60022 などしているんだけど、それでも結構ログイン試行のログが残っているので、ポート変えて安心する程度の知識しかない人ならそもそも SSH 使わない方がいいよ

まあ .*022 系のポートは自動化攻撃されやすいんだろうけど

「効果が微妙な対策 **のみ** で素人がセキュリティ万全と勘違いしてしまうリスク」との向き合い方はな……

だいたいわかってる人は勝手にポート変えるなり別のところに注力するなりするだろうから、

* port 22 を変えるのは (雑攻撃を避ける意味では) 有効
* 「port 22 を変えるといいよ」という言葉を発しても、わかってる人には得るものがないし、わかってない人には勘違いリスクがある

という感じなので結局 port 22 を変えることに言及するのあまりメリットないかなぁと

無論、何もわからず SSH サーバ立ててる人もいるはずなので、そういう人にはまあ焼け石に水程度の効果を期待して啓蒙するのもひとつの選択ではあるだろうけど……

そもそも Rust は安全で確実なコードを書くための言語であって、狂プロみたいなのとは目的が合ってないのではという感想がある

狂プロer じゃないので知らんけど

テスト通ったら終了でもう知らんということなら LL の方が圧倒的に向いてるんじゃねえのと思わなくもないんだけど、 LL だと TLE したりする話をよく聞くし、制約のバランスが妙なのではという感想が

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

私が通っていた高校のコンピュータ室では、「緊急停止ボタン」みたいな名前の赤くて大きいボタンがあり、たぶんアレを押すと部屋の全コンピュータの回線が切れるか電源が落ちるかするんだろうなと (押したことはない)

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

木でも用途によっては結構苦労するからなぁ >Rust

だいたいそういう系の本質的に危険な操作は単独の crate にして、安全性はそちらで独立に検査して提供しろという方向なんだと思う

メンテナンスが前提のコードを書かないと Rust のありがたみは感じられないよ

unsafe とかは典型的な例で、その場限りで動いておしまいのコードなら全編 unsafe にしてしまえばいいんですよ。まあ C++ なんだけど

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

「オメーがやれ」は原則だし、一方で「共通のコンポーネントに注力した方が得るものが大きい」もひとつの真理なんだよなぁ

Rust はいいぞ

そういえば大学夏祭りで展示する成果物ちょっと弄るか悩んでるんだよなぁ

FBX viewer なんだけど、明らかに実装できそうなんだけどやる気がなくなって手を付けてない部分があり

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

これよね

まあ Rust の型システムの強力さだけでも有り難いといえば有り難いので、マジで全体を unsafe block にしたうえで型システムの恩恵だけ受けるというのは考えられそうではある

unsafe は safe Rust における safety guard が全て外れるわけではなくて、型システムや参照の lifetime などのいくつかの重要な制約は付いたままになる。単にそういった制約を迂回する機能が有効化されるだけで、 unsafe ブロックの中でも外と同様にコンパイラにいろいろ検査させることはできる

今のところ overload 機能が stable じゃないのでたぶん二重にバッファリングされると思う (というか overload できたところでこれが解決できるかは微妙だけど)

や、解決できるか

ふぃぎゅ＠メイト、くっそ懐かしくて泣いた (懐かしいといってもプレイしたことがあるという意味ではない)

わかものなので、ふぃぎゅ＠メイトとか Nursery Rhyme とかが何年代のゲームなのかさえ把握していない

@KAZU34 https://mstdn.maud.io/@r8_gre/99025734275213983

おっぱいって乳首が極なのでは (適当)

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

ムスコの手術……いったい何をするつもりなんだ……

一皮剥けて帰ってきそう (適当)

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