俺たちはヤクザだった……！？
「「働かないで稼ぐ」という価値観を理想とするヤクザの存在を理解することは、労働と対価という資本主義社会の本質について考えるきっかけとなるかもしれません。」
職業としてのヤクザ 溝口 敦(著/文) - 小学館 | 版元ドットコム https://www.hanmoto.com/bd/isbn/9784098253968
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
俺たちはヤクザだった……！？
「「働かないで稼ぐ」という価値観を理想とするヤクザの存在を理解することは、労働と対価という資本主義社会の本質について考えるきっかけとなるかもしれません。」
職業としてのヤクザ 溝口 敦(著/文) - 小学館 | 版元ドットコム https://www.hanmoto.com/bd/isbn/9784098253968
このアカウントは、notestockで公開設定になっていません。
我々が人間と計算機を対等に考えていないのと同様にヤクザが自分たちとパンピーを対等に考えていないのであれば、我々はヤクザかもしれない
搾取の自覚みたいなのはひとつの考えられる差異なのかなと思ったけど、ヤクザが搾取を自覚しているのかはわからないので何ともいえない
このアカウントは、notestockで公開設定になっていません。
さこつ の投稿
sakots@pokemon.mastportal.info
このアカウントは、notestockで公開設定になっていません。
【復旧】みずほ銀行、システム不具合でATM停止 - Impress Watch
https://www.watch.impress.co.jp/docs/news/1309043.html
このアカウントは、notestockで公開設定になっていません。
この前の物販で買ったときに名刺も入っていたのでそこから幾つかアクセスしてみたけど Twitter とか Instagram とかじゃなくて自前の静的サイト持っておくの大事ですよ，絵描きはみんな持っておいて（願望
<map> と <area> 使ってるのかと思ったら display: absolute; で笑った
<area> - HTML: HyperText Markup Language | MDN
https://developer.mozilla.org/ja/docs/Web/HTML/Element/area
このアカウントは、notestockで公開設定になっていません。
ポータルそろそろ更新せななあと思ってリポジトリ開いたは良いものの、テーマに合わせるのも微妙に面倒だったのでとりあえずラフ書いてたらこれそのまま使ったら良いじゃんとなった
このアカウントは、notestockで公開設定になっていません。
<area> は HTML 4.01 時点で既にあったからな……
Footnotes
https://www.w3.org/MarkUp/html3/footnotes.html
HTML 3 って footnote 用のタグあったんか、知らなかった
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ああいうの、 toml みたいなので書いて自動整形すれば……と思うんだけど、よーするに bibtex ですわ
ところで DocBook の bibliography には2種類あって、完全に構造化された記述と、人間可読な形で部分テキストにタグで意味付けしていく方法がある (前者は bibtex ライク、後者は RDFa や microdata ライク)
巷の SSG のテーマ、だいたいが簡易ブログ的な構成になっててシングルページなポートフォリオで使うにはやや不便だったり巨大すぎたりするんだよなあ
このアカウントは、notestockで公開設定になっていません。
XML を中間的な AST とした相互変換ができればいいんだよな
pandoc とかはちょっとだけ近いんだけど、あれは pandoc AST の表現力が激よわなので駄目
インライン要素の id を維持できないとかお話にならない
これ、この前の機械可読性の話にも繋がるけど、理想で言えばHTMLまたはそれ以上に優れたものによるハイパーテキストの世界の方が素晴らしいことには全面的に同意するけど、
現在のウェブやHTMLに長期的一貫性なんて1ミリもなくて、どこぞの鯖に置かれてるHTMLによる文書をリンク先にしたとしてもその文書はたかだか数年しか永続しないし規格もたかだか数年しか持たない＞＜
結局の所、現時点では論文も『文書を固定化して保存する事』が必要になるので、現時点ではpdfで出版しDOIで管理することが絶対的に避けられないし、HTMLのぶっ壊れ状況がなおるまでpdfと紙に依存するしかないかも＞＜
PDF に未来があると主張するよりは、 HTML ペラ1のページとか WebBundle / WebPackage の方が1048576倍は信用できるので……
だいたい任意の場所にアンカー張ったりとかテキストをコピーしてくることさえ満足にできないフォーマットは……
あと PDF が「固定化」された情報であるとかはちゃんちゃらおかしいので、そこは全く賛同しかねますね。内容の固定化なら HTML でもできるし、単に web で公開するだけなら PDF も上書き更新されうるわけだから「固定化」の度合いは HTML と差異がない (別ファイルになっているスタイルとスクリプトが云々という話ならわからんでもないが)
あともうひとつ、 HTML はたとえ規格自体が煩雑であるとしても、特定の所望の文書を処理するような簡単なフィルタプログラムを書くことは比較的用意。
対照的に、 PDF は HTML よりも規格レベルで複雑であるし、それを処理するプログラムも単純には書けないので、 (HTML が複雑すぎるという点に賛同するとしても) PDF の方が全面的に利用しやすさは劣っている
紙の方が保存性が高いと思うなら HTML も印刷すればいいのでは？ (名推理)
HTML to PDF と PDF to HTML どちらが容易かを考えれば、我々がどちらを信じるべきかなんて考えるまでもないと思っていたけど……
現在のHTMLは全くそんな使い方されてないでしょ＞＜
pdfとDOIでの管理であればそれと比べたら圧倒的に固定化、言い換えると特定の文書に対するリンクとして機能してるでしょ？＞＜
doi にペライチの HTML を使ってもいいわけですよね。 doi の永続性は PDF とは全く無関係では
「持続させたいドキュメントに <script> や <link rel="stylesheet"> による外部リソースのリンクを行うな、できるだけ埋め込め」という主張であれば大いに賛同したいところだけど、「PDF の方がよい」というのは全然わからない
それこそ現代であれば webpackage による dedup であったり static site generator による自動的な埋め込みであったりは可能なわけで、永続化を最初からデザインに含めて考えていれば HTML の外部リンクが fragile であるという弱点は自然な形で十分に克服できる
(まあ webpackage はまだ規格成立してないけど…… 成立するという期待はしてよいので)
まあスクリプト云々の話をするなら、 PDF にも javascript 埋め込んでだいぶあれこれできるようですけどね……
頭おかしいこと思いついたけど(？＞＜；)
現在のHTMLのウェブ空間とは独立したHTMLよりもミニマルな新たな規格とそれ用のブラウザによる百科事典のような静的サイトによるウェブを作るってしたらおもしろそう＞＜
HTMLはHTMLの方でウェブアプリの空間として勝手にやってもらって、書物はこっちに書く的なやつ＞＜
わりと重要な点としてHTMLと互換性がないこ事＞＜(混ぜて使用出来ないように＞＜ 新規格のサイトを閲覧するウェブアプリはありで＞＜)
https://mstdn.nere9.help/@orange_in_space/105782010694877972
これこの前書いてだれも反応しなかったけど、こういう事すればもしかしたらpdfを捨て去る事が出来るかも＞＜
原理的には滅茶苦茶簡単だけど誰もやってないので、それが答えですね……
雑に言えば Wikipedia / MediaWiki なんかで専用ブラウザの利用を強制すればあっというまに氏の言うものは実現できる
なんなら fediverse だって専用プロトコルによる連合だから、 HTML で出力する UI をなくしてしまえば既にそのようなものはできている
まあ本当の意味で “自由な” プラットフォームであれば当然誰かが双方向にゲートウェイを作って終了でしょうけど……
メーリングリストが HTML に変換されて web から閲覧できる様子を見れば、プラットフォームとフォーマットの分離が “世界” の分断の役には立たないことは実例つきで納得できる
あるいは世界には HTML 以外にもバージョン付けされて厳格な文法を持ち検査用のスキーマが充実したフォーマットが多数あるわけで、それを使えば済む話なんですよね。生の XML を web に公開することは可能なんだから。
HTML に不満があれば DocBook なり TEI なり DITA なり好きなものを書けばよい (なんなら reST でも AsciiDoc でもよい)。
私は実際そうしてきた
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ワイの持ってるパナのドラム式洗濯乾燥機は感想完了後にふんわり維持モードみたいなのになるのでそこまでシワにならないけど、完全に電源が切れた後に放置し続けると、中に残った湿気が水分となってぐちゃぐちゃの服に入るのでシワにはなる
現状で一番マトモな選択肢は webpackage の策定プロセスを見守ったり参加したりすることだと思いますね
WARC 形式のアーカイブとかは特定リクエストに対するレスポンスの保存なので、アーカイブとして機能してはいるけど、上流から提供するバンドル形式としてはあまり良いものではない……
そういうことじゃなく、二つの空間に分かれて文書の永続性を考えたハイパーテキストの空間を別に構築することで「そういう永続性が全く無い使い捨てのゴミみたいな事はHTMLの世界の方でやってくれ」って指導が出来る事が大きいかも＞＜
(HTMLによる現状のウェブ空間が論文のプラットホームとしてなぜたえられないのか？も浮き彫りに出来るかも＞＜)
https://mstdn.nere9.help/@orange_in_space/105809899518056512
その「永続性のある方の世界」から、既存のあらゆるリソースが蓄積されてきた dirty な web のリソースを一切参照せず実用性で勝てるのかという話ですよ。
結局「意識高いエリートが集ったものの実利は薄いものができあがる」だけでは。
戦略としては「既存の web 空間に後付けあるいは置換可能な代替形式による永続化機構を与えていくことで、永続性を侵食させていく」というのが向かうべき方向だと思っている
まあ <!doctype html> と Living Standard は愚かだとは思うけど、原理的には <!doctype html> を使っている文書の解釈で互換性破壊が発生しないような変更であればいくらでも HTML LS に詰め込んで問題ないわけですよ。
で、過去の文書を読めなくなる変更を入れたくなったら <!doctype html6> なり <html version="6"> なり <html extension="foo-ext"> なりのような雑な感じで区別できるようにする手だってある (実際どうなるかは知らんが)
【ドラム式洗濯機】 ふんわりキープってなんですか - 洗濯機／衣類乾燥機 - Panasonic
https://jpn.faq.panasonic.com/app/answers/detail/a_id/92/~/%E3%80%90%E3%83%89%E3%83%A9%E3%83%A0%E5%BC%8F%E6%B4%97%E6%BF%AF%E6%A9%9F%E3%80%91%E3%80%80%E3%81%B5%E3%82%93%E3%82%8F%E3%82%8A%E3%82%AD%E3%83%BC%E3%83%97%E3%81%A3%E3%81%A6%E3%81%AA%E3%82%93%E3%81%A7%E3%81%99%E3%81%8B
> ふんわりキープは乾燥終了後、5分ごとに40秒間ドラムが繰り返し回転します。（約2時間）
> 衣類を取り出すまで、ドラムの回転により衣類をほぐします。
> （衣類の取り出し忘れによるシワを低減します）
ある意味それはそうだしΣっぽいもどういだけど、
論文がHTMLでは無くpdfや紙で構築されていて論文同士の参照がDOIやタイトルと著者名と出版年で行われてるのも、新しくはなくむしろ古いけどHTMLのウェブ空間から一歩引いたエリートの世界かも＞＜
もっと根本的な話をしてしまうと、 DOI とかいうデータベースこそ完全に SPOF だと思うので、 web の自然な hyperlink よりも DOI の方が永続性が高いという発想はよくわからない (タイトルと著者と出版年で検索かけろというのはまだわかる)
それこそ DOI などよりも IPFS みたいな content-addressable な分散ストレージで論文公開した方がよっぽど信頼できると思いません？
論文の最終稿を IPFS にｱｯﾋﾟﾛｰﾄﾞしろ、そんで各種研究機関や論文リポジトリが pin して保存を冗長化しろ、という話であれば諸手を挙げて賛同したところですが
結局のところ、 DOI は「永続する『名前』」としては機能するけど、「永続する『(直接的アクセス手段としての) アドレス』」として機能するかは DOI 運営の管理能力と組織寿命と善良さと諸々に依存するので……
まあ DOI も名前空間分かれてるっぽいので、 HTTP を捨てて各アップストリームに問い合わせれば doi.org が死んでもデータへのアクセスはできるかもしれないけど……たとえばそれでも各リポジトリの運営機関の寿命に影響を受けそうなのでやっぱり永続性について十分な安心ができるかは正直微妙では
スクリプト言語とマネージドな VM の上で動いてるならともかく Rust だと 貧相な C FFI を通じてやるしかないんかなあ
本当に動的なプラグイン機構であれば動的リンクは絶望的 (不可能ではないが) なので、まあ RPC か別スクリプト言語 / DSL の利用しかないのでは……
Mattermostとかプロセス間通信してたっしょ、たしか
寝てる間の腹痛が辛すぎて誤魔化したいからか、見た目は普通のナミテントウなのに、部屋の中で捕まえても指の隙間から余裕で抜け出してくるパワーのあるマッチョなテントウムシをどう駆除するかという、意味の分からんミッションが脳内展開されて脳の負荷がヤバい。お腹は常に痛い、耐えられない、起きてきた。
このアカウントは、notestockで公開設定になっていません。
Web Bundles
https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html
でも application/webbundle だし schema でも webbundle なんだよね (<https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#name-top-level-structure>)
google/webbundle: WebBundle library for packing web sites
https://github.com/google/webbundle
ここでも "WebBundle format" とか言ってるので、どこかのタイミングで名前が変わったのではという疑いを持っている (知らんけど)
https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#section-appendix.a-4
> draft-03
> * Retitle to "web bundles".
なので、昔は WebBundle だったのが draft-03 で web bundles になったというのが答えっぽいな
このアカウントは、notestockで公開設定になっていません。
英語圏にありがちな「タイトルで勝手に capitalize するせいで固有名詞の正式な表記がわかりづらい問題」
文脈のせいで勝手に capitalize が発生する言語で固有名詞が case sensitive なの、完全に欠陥仕様
“ＭＳ ゴシック” だか “ＭＳ ゴシック” だか思い出せないんだよなぁ (?)
このアカウントは、notestockで公開設定になっていません。
@cmplstofB OpenPOWER以降でいえば、IBM自身のものでないかぎり大体Powerが正式（Power ISA、Power Architecture）です。
たとえば、歴史的にいえばIBMから寄贈されたPOWER ISAを基に、OpenPOWERのメンバーによってPower ISAの仕様が策定・公開されています。また、IBMのPOWER9プロセッサはPower ISA Version 3.0に準拠しています。
このアカウントは、notestockで公開設定になっていません。
競走馬「プリンニシテヤルノ」をさくっと紹介【プリコネ…？】 - ニコニコ動画
https://www.nicovideo.jp/watch/sm37029651
Linux上で特殊文字を含む名前のファイルの削除方法 - THE BLUE NOWHERE http://y-sumida.hatenablog.com/entry/2017/10/17/213915
ハイフン始まりのファイルは ./ に続けて指定するのが一番楽。シェル補完も効くし
クォート系はシングルクォート以外はすべてシングルクォートで括れば良いし、シングルクォートが来たら一度閉じて \' を入れれば良い。
foo"bar'baz なら 'foo"bar'\'baz みたいな。かんたん
シェルのエスケープ、読むのはアレとしても書くだけなら超単純なので悩むようなことはない
改行入れたいなら foo$'\n'bar みたいにするなどのテクもあるが、まあ素直に "$(echo -e 'foo\nbar')" のようにするのがわかりやすいかもね
あとは搦め手としては、 echo や cat で垂れ流して xargs -0 で行区切りを NUL にしてやると \n が行区切り扱いされなくなるなどの方法もある
可読性を求めるならそもそもシェルスクリプトを使うのが間違ってる。シェルのスクリプトやぞ……
シェルのというか、インタラクティブシェルのスクリプトやぞ……
(なんにしてもバッチファイルよりはマシ説はあるかもしれないけど……)
全ファイル指定で *.* するのとか FAT みがあってウケるよな (真顔)
.htaccess を保存するとき .htaccess. と入力しないといけない環境の話はやめろ！
WSH とか結局今でも VBScript と JScript 両方使えるのかな (興味なし (興味はないが労働でそのうち書くかもしれない (バッチファイルよりはマシかもしれない)))
まあ今から VBS はありえないので手を出すにしても JScript ですね
このアカウントは、notestockで公開設定になっていません。
Can Chrome be made to perform an XSL transform on a local file? - Stack Overflow
https://stackoverflow.com/questions/3828898/can-chrome-be-made-to-perform-an-xsl-transform-on-a-local-file
そんなことになってたのか……
C++ 難しすぎて昼を食いそこねてた (今準備してる)
このアカウントは、notestockで公開設定になっていません。
Times New 傲慢 「タイムズ紙でこのフォント使わないとか、そんなことあるか？？www」
このアカウントは、notestockで公開設定になっていません。
【速報】LINE Payは「PayPay」が吸収へ──Yahoo! JAPAN×LINE経営統合で方針 | DIAMOND SIGNAL
https://signal.diamond.jp/articles/-/599
吸収合Pay…… と言いそうになったけど経営統合だった。残念 (?)
そうか、ここで「クマ娘」とか言って某アニメの画像を出せばいいんだな
Twitter のクマ娘タグ、音声作品が出てきてワロた。なるほどね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://mstdn.maud.io/@giraffe_beer/105814369695058578
既に第1の青函トンネルは存在するわけで、「5000兆円あれば第5000兆1青函トンネルまで作れる」が正しい (適当)
「階段で1階から2階まで上るのに1分かかった。階の高さと階段の構造がすべての階で同じだとして、100階まで上るのにあと何倍の時間が必要か」みたいなのに近い (答えはもちろん100倍でも99倍でもなく、98倍)
このアカウントは、notestockで公開設定になっていません。
スーパーカップの素粒子を食べたときうまさが最大になりそう (超適当)
やりたいことが渋滞を起こして lock contention で何もできなくなってる、最悪すぎる
脳、明らかに非対称デュアルコアでは足りないので対称で32コアくらい欲しいが
このアカウントは、notestockで公開設定になっていません。
本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった - fsubal
https://scrapbox.io/fsubal/%E6%9C%AC%E5%BD%93%E3%81%AB%E5%80%92%E3%81%99%E3%81%B9%E3%81%8D%E3%81%A0%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%AF_jQuery_%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3%E3%81%A0%E3%81%A3%E3%81%9F
このアカウントは、notestockで公開設定になっていません。
読んだらもっと不穏なこと書いてあってゥヮとなってしまった
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
処理系実装者としては XSLT 2.0 以降は地獄みがありますね (実行時にデータとして記述された型と名前が外部からやってきて、それを使って型検査じみたことをすることになりそうなので)
私が XSLT 3.1 を使いたい理由、純粋に sequence まわりのデータ型が使えるからですね (XSLT 1.0 の nodeset は正直表現力が足りない)
あとは演算子も foo/(bar|baz)/qux みたいなのが XSLT 1.0 だと意図したように使えないとか、そういうアレもある
まあスキーマまわりがつらいのは XSLT 2.0 に限らず XML Schema とかでもそうなんだけど (あれほんまつらそう)
lo48576/xslt10-lambda-calculus: Lambda calculus by XSLT 1.0 (and `node-set()` of EXSLT)
https://github.com/lo48576/xslt10-lambda-calculus
あと XSLT 1.0 では result tree fragment まわりの制約がつらいというのがある。 XSLT 1.0 で再帰的スタイル適用をしようとすると EXSLT の node-set() 拡張が必要になる。
XSLT 2.0 からは標準機能のみで同等のことができる
node-set - EXSLT | MDN
https://developer.mozilla.org/ja/docs/Web/EXSLT/exsl/node-set
このアカウントは、notestockで公開設定になっていません。
XProc なぁ、静的サイトジェネレータに使えるじゃん！！！！ となったけど例のごとく処理系が気に入らないのばかりで諦めた
XML、単に構文木にするとかなら良いんたけど拡張の処理とかを考えると Java とか .NET あたりがちょうど良い感じになってそう
これなんだよなぁ
DITA とか見ていると本っ当にそう思うんだけど、動的な処理系の拡張能力があてにされている感じはある
ソースコードレベルでできるようにしたってええやんけ！ と思うんだけど、まあ C と C++ でやりたい人が少ないのは致し方ない
本当に**実行時に**拡張できることを期待しているユースケース、実際そんなになさそう……
このアカウントは、notestockで公開設定になっていません。
JSON-LD はともかくとして JSON とか YAML には外挿されるような意味というのはあまりないことが多いけど XML だと例えば名前空間の検証とかしないといけなくないですか
単に DOM を作りたいだけなのに、 XML Schema が指定されていたらそれを読んで解釈したうえ検証をしつつデフォルト値を突っ込まないといけない、みたいなの……つらい
単に構造化されたデータとしてだけ扱えればよいのなら他と同様に要素名とか内容をあてはめていけばおわりなのですが……
まあ名前空間というのが本質的に「外部的な (未知の可能性がある) スキーマに基くデータの混入の可能性を認める」という話なので、スキーマの固定された json や yaml と比較するのはフェアじゃないよね。フル機能の JSON-LD と比較するのが妥当
このアカウントは、notestockで公開設定になっていません。
contention と race が両方とも「競合」と訳されるの最悪だ
密閉型のヘッドホン、ボイチャに使うと声がデカくなりがちなので、それ用に開放型のヘッドホンを調達しておくべきかなみたいな気持ちもなくはない (まあ普通に考えるとソフトウェア側でループバックした方が賢そうだけど)
このアカウントは、notestockで公開設定になっていません。
どちらかというと hardware-like であるとは「構成が固定である」に近い気がするけど、もっと言うなら「各コンポーネントの連結のトポロジが固定である」ことと「入出力の場所が安定している」ことな気がしていて、これは典型的にはノードを連結してストリームデータを加工するような宣言的なソフトウェアやフィルタが近い気がしている
Web Audio API - Web API | MDN
https://developer.mozilla.org/ja/docs/Web/API/Web_Audio_API
たとえば Web Audio なんかはどうでしょ
実際ノードベースで作られたプログラムはハードウェア実装に喩えることが容易な気はしていて、各コンポーネントがステートレスだったりすると尚更よね
まあハードウェアでもステートフルだったりヒステリシスのあるものはあるので、ステートレスか否かは本質ではないけど。
これはomasanori推薦図書です。
FPGAの原理と構成 | Ohmsha
https://www.ohmsha.co.jp/book/9784274218644/
このアカウントは、notestockで公開設定になっていません。
！！！？＞＜；
"UNIX/Linux において、ファイル名として使用できない禁止文字は以下の 2つのみである。
"/" (スラッシュ。ASCII コード 0x2F)
\0 (ASCII コードのゼロ)
上記以外の文字、例えば空白・タブ・各種記号 (#$%& など)・コントロールコードなどはすべて使用可能である。"
用語集:ファイル制限まとめ: UNIX/Linuxの部屋 http://x68000.q-e-d.net/~68user/unix/pickup?%A5%D5%A5%A1%A5%A4%A5%EB%C0%A9%B8%C2%A4%DE%A4%C8%A4%E1
このアカウントは、notestockで公開設定になっていません。
「NUL」というファイルを作れない MS-DOS は天才が作ったということなのかな (?)
How I Broke Rust's Package Manager for All Windows Users - sasheldon.com
http://sasheldon.com/blog/2017/05/07/how-i-broke-cargo-for-windows/
これいい話なので読んでね
NUL とかはまあわからなくもないけど COMn とか PRTn が予約されているのちょっと信じられないんだよな
インターネット老人たちが思い出すシリーズを思い出し始めているぞ (?)
https://twitter.com/withoutboats/status/858791127750557696
> I thought Rust was supposed to prevent nul errors! ;-)
オチが秀逸 (???)
このアカウントは、notestockで公開設定になっていません。
NTFS and/or Windowsで表現できないファイル名を使うのはウニハラ
Thumbs.db を zip ファイルに突っ込む窓仕草なぁ
@kb10uy CP/M で、/dev/ みたいなの実現したいけれどそもそもディレクトリツリーが作れなくて一階層しかない……そうだ、グローバルな名前空間で豫約したろ！から来てるから……。
このアカウントは、notestockで公開設定になっていません。
zipを生成する時に常にThumbs.dbと.DS_Storeを勝手に突っ込むアーカイバを作ろう
https://social.mikutter.hachune.net/@shibafu528/105815040492917482
未定義動作に対して HDD をフォーマットするコードを生成するコンパイラの類型じゃん (?)
.DS_Store、.DS_Store の隣に ._.DS_Store も生成するからな
このアカウントは、notestockで公開設定になっていません。
そもそも COM ポートって若番から順に採番されるんじゃなくて、よくわからない数字の振られかたするから 3 コ目で COM10 だったりする
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
これはいい話なんですが、 nvidia-drivers の更新でうっかりがあるとターミナルが起動しなくなってつらい (alacritty が OpenGL 使ってるので)
このアカウントは、notestockで公開設定になっていません。
APFS 登場したばかりのモデルの Mac で Adobe が insensitive 前提の作りで無事死んだりしてたはず
まあ Windows の FS API まわりで狂ってると思うのは CON とか NUL とかよりも C:\DOCUME~1 とか C:\PROGRA~2 とかですね。オメー short path まだ残ってんのか。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
あれ良く出来てて長いファイル名に対応してない環境でもただの未対応テーブルエントリとして読み飛ばせる
まあ UNIX の方もそれはそれでアホだなぁと思う設計はあって、たとえば .* (dot files) が hidden 扱いされるようになった経緯とかです
いやこれは UNIX というより単なるアプリケーション側の慣習かもしれないけど
FatFs - Generic FAT Filesystem Module http://elm-chan.org/fsw/ff/00index_e.html
数百byte のワーク領域で FAT 読み書きできるライブラリ
@cmplstofB TFS https://gitlab.redox-os.org/redox-os/tfs なんだと思っていましたが今確認したらまた新しくRedoxFS https://gitlab.redox-os.org/redox-os/redoxfs というのを書いてますね。
Why I'm leaving Open Source · Ticki's blog
http://ticki.github.io/blog/why_im_leaving_open_source/
TFS は書いてた人がやめちゃったので
> I want everything to be perfect, well-documented, and rigidly correct. This is not viable. Truth is, I didn't get enough things done. In the later days, my main project was TFS, but matter of the fact is I never accomplished anything with it. It is vaporware -- possibly among the most well-documented and well-designed pieces of vaporware out there, but it is what it is, vaporware. I wanted perfection and was unwilling to make compromises to produce results, meaning that what is left is just a bunch of very robust libraries. In terms of the project goal itself (being a state of the art file system!), nothing was ever achieved.
読んでて苦しくなってくる
