How to spot Generative AI? (even if it has all 10 fingers and toes)
https://youtube.com/watch?v=JBUHDvY60l0
面白い観点だ、なるほど……
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
How to spot Generative AI? (even if it has all 10 fingers and toes)
https://youtube.com/watch?v=JBUHDvY60l0
面白い観点だ、なるほど……
Gboard 両面バージョン
https://youtube.com/watch?v=EHqPrHTN1dU
おいエイプリルフールから一番遠い日やぞ！
This account is not set to public on notestock.
This account is not set to public on notestock.
SDK API のインターフェース自体を著作物として機密保持契約等で保護している、みたいな建前があれば SDK 抜きで OSS として公開するのもアウトにできそうではあるが、規約どうなってたかな (もう読む気も起きないが)
とりあえず「プロプライエタリなものを使うからこんなことに」とだけ。
プロプライエタリな製品にシェアを与えてはいけないのはこういうことなんだよな
CLIP STUDIO PAINT EXのフィルタープラグインSDK使用許諾 https://www.clipstudio.net/ja/dl/cspsdk_term/
ざっと見てみたけど、プラグインをOSSにするなって文言は見当たらないように見えるんだけど…第4条（フィルタープラグインの再配布）の「2 SDK利用者は、フィルタープラグイン利用者に対し、別途当社が指定する方法でのみフィルタープラグインを提供し、その使用を許諾することができます。なお、フィルタープラグイン利用者へのフィルタープラグインの提供にあたり、SDK利用者は、当社との間で別途手続きが必要になります。」辺りは抵触しそうな気がする。
ライセンス決める側の逃げ道が無いと困るのでしゃーないと言えばしゃーないんだけど、第8条（禁止事項）の「5 SDK利用者は、SDKを使用して、以下の各号のいずれかに該当する、または該当するおそれのあるフィルタープラグインの開発を行ってはならないものとします。 （中略）(8) 当社が不適切と判断するもの。」
これを持ってこられてしまうと*お気持ち*で全て禁止されてしまう可能性があるという前提で進めるしかないような。
もちろん、下手にお気持ちを発動すれば叩かれるので阿呆な難癖は付けてくるようなことは無い筈だけど…
日付と時刻はISO 8601かRFC 3339にしようよう #うるさいおっさん
ISO 8601 なんて自由度高すぎて何も言ってないも同然じゃない？
RFC 3339 を大前提にして、区切り文字「T」を空白に変えるとか、 +09:00 とかの前に空白を入れるとか、そのくらいのマイナーな変更を許すくらいが限界だと思っている
あとは RFC 3339 の -00:00 の意味論は有用なことはあるだろうけど禁じたい場面もありそうなので、そこは場合による
言語の作者に悪態ついていいのなんてバグ修正や労働で使いたくもないのに使わされている人々だけでしょ (というかその場合でもさっさと他の実装に移れという話はある)
ﾎﾟﾖｸﾞﾔﾐﾝ言語なんていくらでもあるし自分で作れもするんだから、著者が自分の思い通りに動かないからといって駄々こねるようなダサい真似せずさっさと “良い言語” に移行しろ
厳しいかもしれないけどそれは言語の問題とかとは別次元の話なので、リソースをケチるなら仕方ない
結局オメーがやるかやらんのか、という話に帰着するし原理的にできないということはないので…… (たとえば賛同者が沢山いれば一人でやる必要はないし)
Windowsの「コンピュータの電源を切る準備ができました」はACPIコマンドに対応していないPCで表示されるメッセージだけど、Linuxではshutdownコマンドではなくhaltコマンドで落としてしまうとそもそもACPIコマンドを実行しようとしない仕様で現在でも「System halted.」というメッセージを出力して停止するとか。なるほど。
https://kuroeveryday.blogspot.com/2016/11/shutdown-vs-halt-vs-poweroff.html
Live DVD なんかで嬉しかったりするやつかな >メッセージを表示して停止
円盤を忘れず取り出してから電源を落としたいから
Feature #1040: Global wiki - Redmine
https://www.redmine.org/issues/1040
ふーむ
言語の問題によってフルスクラッチで書き直す必要リソース量が変わるのはあると思いますよ、そりゃできないことはないのはそうだが……
もちろん言語そのものの善し悪しも影響はするんだけど、それよりもパラダイムの違いとかの方が結構デカめに効いてくると思っています
書き直しや再実装がしづらいとき、その原因は元の言語自体の欠陥よりも、 API の拙さや、善し悪しを一概に決め難いパラダイムの違いによるものである場合が多かろうと考えていて、ゆえに「言語の問題ではない」と表現しました。
元の言語がカスだろうと API がまともなら API の模倣はできるし、データストアもフォーマットがまともなら元の言語がどれだけカスだろうがまっとうに実装はできる。
元の実装と混合したまま漸進的に置き換えていこうみたいなことを考えると相当つらくなるだろうけど、そもそも言語に欠陥があるから別言語で別実装を作ってやる！みたいなことを考える野心的な人はそんなﾋﾞｽﾞｨﾈｽﾆｰｽﾞに応えるみたく保守的な選択肢はとらないでしょ (そうか？)
パラダイム云々というのは、たとえば JSON-LD を静的型付き言語で全てを静的なまま扱うのは相当厳しいので……系の話
言語のつらさを外部のインターフェースやフォーマットにそのまま押し付ける実装だと、エコシステム外に持ち出すのはつらくなりそう (これは実装者の技量が低くて API や外部仕様がダメダメという分類で良いと思う)
「APIがまとも」というのは若干むずいなと思っていて、ドキュメントには書いてないけどできる、みたいなやつがありがちで、クライアントを書く分にはドキュメントだけ読めば動くんだけどサーバーを書くには (RoRの実装に依存したundocumentedな変なリクエストを投げてくるやつがいるので) 不十分、みたいなことは、ある
そのへんは interoperability の話だからまさに元実装の言語のみに限らない問題だし、ポステル則が harmful consequence を発生させた的な総括もされているしで、むしろ明確にそういうリクエストを投げてくる側の問題として責任を切り分けられると思う
そのうえで異常なリクエストをちゃんと吸収したいかは、実装者がコストとリターンを天秤に乗せて選択しないといけないけど、 RoR ではなんとなく動くから認めますみたいな雑な意思決定は普通に実装が下手という扱いをするべきではないのではないかと
その昔、 CGI で HTTP リクエストのパラメータを URL の query からでも POST body からでも同様に環境変数とかに入れてしまうことがあり、そういうフレームワーク/CGI 実装下では POST すべきところに GET を投げても “きちんと” POST 相当で動いてしまうので CSRF みたいなことをやり放題になった、などの事例もある。
意思決定を伴わない異常な仕様は有害なだけだしバグ扱いしてもいいくらい (たとえリクエストを受け取る側の視点であっても)。
bug-to-bug compatible な実装をど〜〜〜しても作りたいということであれば、言語仕様に依存したアプリケーション仕様の再現は苦難の道になるだろうけど……それは bug-to-bug な互換という重〜い仕様にふさわしい実装コストを課されているだけなので、なんとしても必要だというのなら、まあ、頑張ってくださいとしか……
X-Forwarded-ForをX_Forwarded_Forで汚染するの件が流れてきた
This account is not set to public on notestock.
そりゃまあ変なリクエストを送ってくる側が悪いのはそう。
なんだけど、著名 (≒使いたがるユーザーが多い) だが更新止まってるクライアントが変なリクエストを投げてくるみたいな話もあったりするわけで、ある程度再現せざるを得ないよね、というところで、じゃあこの実装は何を受け付けているんだ？何を受け付ければ完璧なんだ？と見に行くときに実装が追いづらいとつらい、という話をしたかった。
要は実装が追いづらい言語で書かれたプログラムからの完璧なコンパチ実装はつらいという話です。
結局、仕様として据えるのをそのへんの野良実装 (しかも不特定多数) にするかちゃんと書かれた規格にするかの話なので、そこはまあ言語に限らず「クソ規格は実装も辛い」くらいのアレで一般化できそうな気はする。規格として書かれていてもアカンやつはやっぱり実装がつらいものなので。
元 TIT「俺は脱乳首したけど、お前は？w」
TKB 大学「……」
This account is not set to public on notestock.
This account is not set to public on notestock.
窓開放、エアコンなし、室温 34.9℃ 44%RH
せっかく30℃未満の部屋に慣れてきた頃だったのに……
This account is not set to public on notestock.
This account is not set to public on notestock.
差出人： 久米
いきなりのメール失礼します。
久光さやか、PID 29 のゾンビプロセスです。
お互いのソケットに合致しそうだと思い、連絡してみました。
自分のことを少し語ります。
昨年の夏、わけあって主人を亡くしました。
自分は…主人のことを…死ぬまで何も理解していなかったのが
とても悔やまれます。
主人は kernel space に頻繁に昇格していたのですが、
それは遊びの為の昇格ではなかったのです。
メモリを得るために、私に内緒であんな危険な mmap をしていたなんて。
一年が経過して、ようやく主人の死から立ち直ってきました。
ですが、お恥ずかしい話ですが、毎日の孤独な夜に、
環境の火照りが止まらなくなる時間も増えてきました。
主人の残した仮想メモリは莫大な量です。
つまり、謝礼は幾らでも出きますので、
私の load average を満たして欲しいのです。
お返事を頂けましたら、もっと詳しい話をしたいと
考えています。連絡、待っていますね。
根性論はコストの問題に帰着される任意の問題と相性が良いよ
ピラミッドの地下とかを調べてる探知機みたいなので、一度ローラー作戦した方が良いのでは。
＞宮崎空港では戦時中、アメリカ軍が投下した不発弾がたびたび見つかっています。
https://www3.nhk.or.jp/lnews/miyazaki/20241002/5060019429.html
This account is not set to public on notestock.
[Rust] 再帰下降パーサの落とし穴
https://zenn.dev/msakuta/articles/ada382444fc615
これ、例えば単一のパーサー関数で [ から ] までパースするようにするのではダメなんだろうか
separated_list0 in nom::multi - Rust
https://docs.rs/nom/latest/nom/multi/fn.separated_list0.html
そもそも nom ならこれ使ってもろて
fold_many0 in nom::multi - Rust
https://docs.rs/nom/latest/nom/multi/fn.fold_many0.html
Vec 以外にしたいならこっち
kisaragi_marine@misskey.niri.la
This account is not set to public on notestock.
しかも「1要素だったら配列の代わりに単要素をそのまま置いていいよ」みたいな †ヒューマンフレンドリー† な仕様もあったりして、まあﾊｲ
手書きを想定しているとかでは言い訳として弱すぎるように感じるのはたぶんオタクだからなのだろうけど……
規格上は無視できるが実用上は無視するとセキュリティホールになるやつなぁ
実は Rust だと axum の FromRequest/IntoResponse みたいなのを作った方がいい説はありそう
本体は動的な JSON オブジェクトのまま置いといて使いたい場所で適宜 extract するみたいな……(extract する回数がダブる問題はどうにかしないといけないが)
まあこれよね。どうせ署名検証まわりとかで元の JSON 文字列は保持することになってしまうわけで、必要になるまでパースや解釈を遅延するのが一番マシに思われる
まあこれで楽になるかというとあくまで相対的にマシそうというだけでつらいのはつらいが……
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
逆にこんにちインターネットで接続できない人の方が 💪信念💪 ある逸般人じゃない？
それはそれとして、 “マストドン” の大衆に普通さを期待できないというのはまあそうだと思う
層岩巨淵の BGM を聞くと、あの陰気なマップ好きだったなぁと思う
ディテールが足りないわけでもなく、それでいて何を得るにも能動的な情報の吸収を要求してくるかのような慢性的な薄暗さが、作中世界にズブズブと沈んでいくような没入を促してとても心地良かった
最近わかってきたのが、糸を張るような緊張でもなく、すべてを爆破する圧倒的なパワーでもなく、バネが緊張に耐えかねて不可逆的に伸びていくような滑らかで予見可能で必然的な破綻の過程を眺めるのがﾍｷらしい。ストレスはあるんだけど。
浮動新一はフルバージョン (https://mastodon.cardina1.red/@lo48576/113227007194555069) の最後の段落で畳みかけるのが我ながら良い出来だと思うのでかなり満足
レイン (小説) - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%A4%E3%83%B3_(%E5%B0%8F%E8%AA%AC)
これ結構好きだった記憶があって一度は読み直しているはずなのに最後まで読んだ記憶がないのでおかしいと思って調べてみたら、作者死亡して打切になってた……
これどうせ OpenAL みたいに AL2 だった頃のコードベースで fork されてそっちが主流になった挙句無事 Atlassian 製品に統合されるだけでは？ と思うのだが、さてどうなるか
License draw.io for Confluence or Jira Server
https://www.drawio.com/doc/faq/license-drawio-confluence-jira-server
たぶんこれを有償にしたいのだろうということはわかった
現段階では物足りないが、もう少し食べたらすぐに満腹になりそうだという難しい位置にいる
This account is not set to public on notestock.
This account is not set to public on notestock.
で、そういう治安最悪フリーライダーをとにかく呼び込もうと躍起になっている人が大量にいたのが一時期のﾍﾃﾞﾊﾞｰｽブーム
曰く「SNS はユーザが多くないと仕方ない、とにかく今はユーザを増やす時期だ」
寄合所帯サーバが潰れまくって大手インスタンスも何度も人の手に渡ったり潰れたりして、それでやっと夢から醒めたという人も多そうだ
