中央hogehoge駅名、群馬の中央前橋駅もある＞＜
このアカウントは、notestockで公開設定になっていません。
○○中央って名前は多いように感じる（千里中央、日生中央、和泉中央、高井田中央、etc）けど、中央なんとかって、中央林間と中央フリーウェイしか知らない。
フェアユースの話とアメリカ公民権運動の話をセットですればわかりやすいかも？＞＜
わかりやすいかは別として反論はしづらいかも？＞＜；
著作権の (倫理的に正しい) 保護と国内外の著作権法の遵守や思想は必ずしも一致していないという話なのに、それらの区別がしづらいんだよなぁ
あと、トレーラー慣れでヤバイなと思ったの、トレーラーの後ろが折れ曲がってくれるのになれた状態でFS19でトレーラーじゃない林業用トラックで走ったら車体の後ろを対向車にぶつけた＞＜；
現実でトレーラーじゃない大型トラック運転してる人は、ATSとかでトレーラーの感覚になっちゃうの危険なのかも？＞＜；
ATSでずっと走ったりアメリカのトラック車載実況見まくってると、トレーラー牽いてない車載動画でもミラーでトレーラー確認しようとして「あ＞＜；」ってなる変な癖ついておもしろいよ＞＜；
そのせいでこんな珍車が・・・＞＜
オーテック・ザガートステルビオ - Wikipedia https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%BC%E3%83%86%E3%83%83%E3%82%AF%E3%83%BB%E3%82%B6%E3%82%AC%E3%83%BC%E3%83%88%E3%82%B9%E3%83%86%E3%83%AB%E3%83%93%E3%82%AA
これの関係で一時期日本じゃ「フェンダーミラーじゃないとダメ！」ってルールになってなかったっけ？
フェンダミラー付きのクルマに乗ってる人は「めちゃくちゃ見やすい」って言ってたね
（教習車のことは覚えてない）
ていうか、日本のクルマでもサイドミラーって見づらそう＞＜(免許なしのアメリカントラック好きの意見＞＜；)
(前に免許ある人にバックミラーの話したら「乗用車は後ろそんな頻繁に見ないよ！」的なこと言われた＞＜；)
アメリカのトラックでわりと重要なのは、ボンネット上のミラーが上に十分に大きく突き出てる事(低いとシートポジションをあげなければならず、上げると今度は屋根が近くて上が見づらくなっちゃう＞＜；)と、
サイドミラーが十分に前に出てる事(前に出てないと大きいミラーでトラクターの状態を見る時に毎回大きく横を向かないといけない)が結構重要なのかもって気がしてる＞＜；
視界が結構重要感＞＜；
ATSで走って初めてわかったけど、クラシックスタイルのトラックって横の円筒形のでっかいエアクリーナーが視界を遮ってるのがかなり邪魔＞＜；(それでほとんど乗らなくなった＞＜；)
【ヤフオク】ピータービルト379トラクターヘッドコンボイトレーラー激レア！ http://racingcar.ready.jp/?p=10566
日本でもたまにこんなのがナンバーつけて走ってるんだよなぁ……
自分のトゥートをアーカイブするサイトを教えた貰ったのにブックマークしておらず、さらにサイトURLを忘れるという無能ムーブをかましてる
トラクタはある程度長い方が走りやすいけど、長すぎると今度はどうやっても入りきらない問題もあるので日本ではこのくらいがちょうど限界かも的な＞＜；
トラクタが3軸じゃなく2軸で短くてなおかつボンネットで、トレーラーもそこそこ短めなので運転しやすそうに見えるかも＞＜
MEU KENWORTH ケンワースのタンクローリー 24ｋｌ仕様 過去の写真no.43
http://fd830.blog121.fc2.com/blog-entry-109.html?sp
これこれ
エクソンモービルジャパンが一時期タンクローリーにケンワース使ってたよね
あれ運用するの大変なのでは？と思ったり
ただし、トレーラー含めフルサイズの スリーパーつきのトラクタ＋53ft箱車 の組み合わせが日本では道交法的に走れないので、それがどうなるのか謎＞＜；
ETS2で40ftコンテナ牽いてフランスを走ったときには狭い道でも全長が長い（慣れてる）アメリカのトラックの方が楽だったけど、究極に狭い所の対応では全長が長いのは最終的に不利だろうし、もっと狭い日本ではどうなるんだろうって＞＜；
極稀にだけど、日本にアメリカのトラック輸入して乗ってる人いるよね
※宇部興産は除く
欧州のトラックとアメリカのトラック比較スクリーンショット＞＜
第五輪（カプラ）とキャビンの位置関係がアメリカと欧州で規格が違うから、アメリカのトラックで欧州のトレーラーの一部（特に箱車）を牽引しようとすると、キャビンにぶつかっちゃう＞＜
ホイールベースも全然違う＞＜
でも、後輪基準でのドライバーの位置は高さも含めてほぼ同じっぽい＞＜
ETS2で走りにくく感じるの、マップのせいなのかトラックのせいなのか絞り込む為に、試しにETS2でATSのトラックが使えるMOD使ってみたら超走りやすかった！＞＜；
だいたいトラックの違いのせいっぽい＞＜；
オレンジはETS2は持ってる事は持ってるけどDLCちょっとしか持ってないし、お金ないし、走りたいのはアメリカなのであんまり遊ばないのに大金つぎ込むのはアレかも感が＞＜；
（逆にATSはマップDLCもトレーラー追加系DLCも全部持ってるので、ATS版のProject Japan出て欲しい＞＜；）
ついでにATSも買って、ATSのトラックをETS2で走らせる事ができるMODと組み合わせて日本でアメリカのトラックを走らせるとどんな感じになるか試してみて欲しい＞＜；
ETS2を久々にやりたくなってきたな
DLC全部買ってProject Japan導入してみようかしら？
ASTRO-H喪失事故も、ヒューマンセンタードデザイン軽視で運用でカバー頼みのおもしろ事故事例の代表かも＞＜
X線天文衛星「ひとみ」はなぜ失敗したか(2) 引き継ぎ不足が招いた運用ミス | sorae 宇宙へのポータルサイト https://sorae.info/column/2016_06_26_astro-h.html
＞＜
https://mstdn.nere9.help/@orange_in_space/102214177327526396
https://mstdn.nere9.help/@orange_in_space/102214197300437921
https://mstdn.nere9.help/@orange_in_space/102214219526070066
プリウス事件みたいになってるのすごくムカつく＞＜
（togetterでプリウスの暴走に関する議論でヒューマンセンタードデザインの話したら無視された上に飛行機の話したら「飛行機は関係ない」って言われた事件＞＜）
https://mstdn.nere9.help/@orange_in_space/102214375973446706
https://mstdn.nere9.help/@orange_in_space/102214446591092509
あと、お約束の「使うのはプロだから」って逃げも、そもそも認知工学はプロというか資格を持っている者が操作するような分野を中心に実用されてきた分野だという事を忘れちゃ駄目かも＞＜
認知工学は航空機のコクピットやクルマの運転や医者が使う機械等に限定した学問じゃなく、あらゆるマンマシンインタフェース等を対象とした学問だし、計算機のUIって真正面から対象とされてる分野だよ＞＜
人間側の都合と機械の側の都合が直接的に接触しないようにクッションを作るのも・・・あれだよ？＞＜（？）
OSのシェルってマンマシンインタフェースだってこと忘れてない？＞＜（UNIXの開発者はそれを完全に忘れてるっぽいので駄目だという話＞＜）
このアカウントは、notestockで公開設定になっていません。
気付いてるかわかんないけど、
https://mstdn.nere9.help/@orange_in_space/105818724333638095
この本の著者って
https://mstdn.nere9.help/@orange_in_space/105819153676939832
の人だよ＞＜
オレンジもわりと最近まで（ツイッターのログによると2016年01月03日辺りまで）は、「UNIXってよくわかんないけど優れたものかもたぶん＞＜（けどちょっとだけ引っ掛る点はあるかも？＞＜）」って思ってて、そこから古典色々読んで問題を知って「駄目じゃん！＞＜」になったって経緯があってあれかも＞＜
＞＜
Criticism -- Unix philosophy - Wikipedia https://en.wikipedia.org/wiki/Unix_philosophy#Criticism
このアカウントは、notestockで公開設定になっていません。
737MAXの話は、オレンジがスラドにコメントかいてたらもっと詳しくかかれてショックを受けたコメント読むとわかりやすいかもたぶん＞＜
Re:エアバスが通った道をやっとか…。 (#.3581695) | 墜落事故を起こしたボーイング737MAX8と737MAX9に対し米当局も全機運航停止命令を出す | スラド https://srad.jp/comment/3581695
Re:エアバスが通った道をやっとか…。 (#.3581742) | 墜落事故を起こしたボーイング737MAX8と737MAX9に対し米当局も全機運航停止命令を出す | スラド https://srad.jp/comment/3581742
イカの耳（比喩表現）で将来性をの話、
エアバス機の操縦特性の隠蔽ってプロテクションを追加する余地を持っていて、実際最初から大量のプロテクションがあるだけじゃなく、そこそこ近年滑走路オーバーラン防止のプロテクションがオプションで追加されたりしてる＞＜
AIRBUS and NAVBLUE : ROPS & Landing Surveillance - YouTube https://www.youtube.com/watch?v=F5nw2Mt3I1I
ボーイング好きは「こんなの必要ある？？？」とかいう＞＜ ；（月刊エアライン許さない＞＜；）
意味がわからない＞＜（ゲーム機は複数の企業が出していたし、それらに拡張バススロットがある事は多々あったし、日本の高速道路よりは参入しやすいと思うけど＞＜
それとも道路の事例をだせばってこと？＞＜；）
ゲームでも、マインクラフトでもギチギチ建築する人と、拡張の余地のために階段に踊り場っぽく余裕作るのもあるし、Factorioでも分岐合流用スペースを作っておいたりして混流ライン化できるようにしておくとか＞＜
（色々スクショ見るとあんまり混流ライン使う人っていないように見えるからあれだけど＞＜；）
オレンジが例に出してるゲーム機の拡張バススロットも実例になるかも＞＜
逆にコスト削減であえて省略してしまった悲劇の例
PCエンジンシャトル - Wikipedia https://ja.wikipedia.org/wiki/PC%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3%E3%82%B7%E3%83%A3%E3%83%88%E3%83%AB
このアカウントは、notestockで公開設定になっていません。
こういう場面で本読めっていうのなんか嫌だけど、オレンジの話が単なる思い付きかなんかだけだと思ってるならばこの本読んだら？＞＜（この本の内容全てに同意しているというわけでは無い＞＜）
誰のためのデザイン？ 増補・改訂版 - 新曜社 本から広がる世界の魅力と、その可能性を求めて https://www.shin-yo-sha.co.jp/book/b455574.html
ただひとつに定まるかどうか別として安全に関する研究が多々あるんだから、それベースでデザインすればいいじゃん？＞＜
それこそ航空機のコクピットみたいに＞＜
安全に関する研究が何のためにあると思ってるの？＞＜
ていうか、専門職であっても知らなきゃいけない情報って絞られるでしょ＞＜
隠蔽できるものは隠蔽していかないと、仕様が下のレイヤに引きずられるし、操作が安全でもなくなる＞＜
エアバス機は「普通飛行機はほうっておいてもまっすぐは飛ばない」という特性とかを隠蔽して勝手にまっすぐ飛んでいくよ＞＜
この仕様だけでもボーイングが採用してたら737MAXがもうちょっとマシな実装になってた可能性があるよ＞＜
航空機は航空機の持つ本質的な複雑さを全く隠蔽していないんですか？ それは嘘でしょ
私が HDD にファイルを書き込むとき HDD の回転速度を知らなければいけなかったことなんて一度たりともないですが……
rm はファイルシステムからの path→ファイル実体 のエントリの抹消であって、それ以上でもそれ以下でもないし、 SSD だろうが HDD だろうが FDD だろうがオンメモリだろうがネットワーク越しだろうが操作は変わらん
もっと言うととにかく上昇したいのであれば、どのくらいの上昇率で上昇するかも知る必要すらないよ＞＜（「スティックを最大に引く」はその機体が現在の状態で性能限界の上昇を行う指令として解釈するので＞＜（ボーイング機777とかの場合は同じ事すると空中分解する＞＜））
エアバスサイドスティック機の壊れてない時のモードで、スティックを引く時にどれくらいの上昇率でどんな感じの上昇をするかは想定する必要はあるけど、具体的に昇降舵が何度動くかは全く知る必要はないよ＞＜
結局「自分が何をやっているか知れ」という話でしかないし、飛行機の操縦で飛行機について知る必要があるなら、なぜ PC の操作で同様に PC について知る必要があるとしないのか
オレンジは対象のファイルがHDD上にあるかSSD上にあるかRAMドライブ上にあるかとか、そのHDDがシーゲート製かWD製かどうかとかで操作は変わってほしくは無いけど＞＜
そんで「自分が何をしているか」を正確に把握するには実装のシンプルさが欲しくないですか？
根本的に「自分が何をしているかわからないようなコマンドを無責任に叩くな」という話はありませんか？
ファイルシステムによるけど特別な名前に変更する事で『消したことにして再利用可能な領域として開放する』って処理の場合も多々あると思うし、誰も直接ディスク上のデータを消してないと思うんだけど＞＜
「ファイルを削除してください」と指示したのにファイルが削除されず不可視で特別な名前のディレクトリに移動される、これが本当に “ユーザの意志を反映している” といえるのか？
それこそUAVの技術を基にした空飛ぶタクシーかなんかの操作の話ならエンドユーザに限った話になるかもだけどそうじゃないんだよ？＞＜
旅客機をそこらの一般人が操縦してると思ってる？＞＜
無知なエンドユーザだけじゃないよ？＞＜
ITのプヨな方々も含めたほぼ全員だよ？＞＜
エアバスA320って乗客が操縦する飛行機じゃなくてとんでもない時間の訓練をつんだ限られた人のみが操縦できる飛行機だよ？＞＜
UNIX コマンドが無知なエンドユーザ向けでないことは UNIX コマンドがクソであることを意味しないんだから
だったら最初からそう言えばいいじゃないですか、それなら言いたいことはわかる
逆から言うと「UNIXコマンドを誰かに使わせるのはやめよう＞＜」かも＞＜
https://mstdn.nere9.help/@orange_in_space/105818517897636494
orange 氏が UNIX をこきおろすとき、「航空機のインターフェースというエンドユーザ向け上位層のデザインを例に挙げて」「OS や distro レベルの下位層のデザインがエンドユーザ向けでないという話をしている」のがフェアではないし批評として的確といえない、という話をしています
あと話が微妙飛ぶし かえってややこしくなるかもだけど、オレンジは「GUIが無いものは未完成！＞＜」ってよく書いてる＞＜
オレンジもそういってる（UNIXのシンプルは実装のシンプルであってユーザーから見たシンプルでは無い＞＜）し、何の話なのかよくわからない・・・＞＜
https://mstdn.nere9.help/@orange_in_space/105818505286980459
「コクピットにあるランディングギアの形をした、手で下げられるレバー」は上位レイヤーであって、その「ユーザーから見たシンプルさ」は「ランディングギアを駆動する機械的な構造」という下位レイヤーの「実装のシンプルさ」と混同されるべきでないという話です
たとえがよくわからないけど、エアバスがハイテク機を作るずっと前から、航空機でランディングギアを出す操作は「コクピットにあるランディングギアの形をしたレバーを手で下げる事」になってるかも＞＜（FAAの基準とかでもそうなってたはず＞＜）
ランディングギアを人間が手で掴んで引っ張り出すしやすくするようなことを考えるべきではないのでは？
https://mstdn.nere9.help/@orange_in_space/105818482496354459
そもそもの話、低レイヤーは機械と他プログラムの仲介のために実装されるものであって、そこにおける「正しさ」とは「プログラムから扱いやすいか否か」であって「人間から扱いやすいか否か」ではないのでは。
user-centric が必ずしも human-centric を意味するとは限らないよね
"POSIX コマンド群より上のレイヤーとして重ねて実装"でいいけど、同時に「POSIX コマンド群は純粋に互換性維持のために残してあるだけなので基本的には使うな」ってするのならオレンジが言ってる事に近いかも＞＜
だから、そういう「ヒューマンセンタード」なレイヤーは POSIX コマンド群より上のレイヤーとして重ねて実装するのではいけないのかという話ですね……
実装から見たシンプルなデザインが、正しさを優勢したデザインと比べて大幅身寿命が短い事を示した事例であり、なおかつヒューマンセンタードデザインの黎明期に起きた事としてもアレかも＞＜
（同時期にエアバスはエアバスで生みの苦しみで実装がうまくいかず事故って叩かれまくってたけど＞＜；）
1980年代のコクピットデザインの話で言うと、ライバルであるボーイングは767(1981年初飛行)でとても保守的で『シンプルな』デザインにした結果、747-400(1988年初飛行)でもう大幅に違う操縦方法に変えなければならなくなった＞＜
通用したのはたった7年ともいえなくも無さそう＞＜
ちゃんと将来性を見据えて、ヒューマンセンタードデザインの研究成果とかを元に作れば実際に長期的に使えるデザインになるという事を示した事例がエアバスサイドスティック機の30年以上使われてるデザインかも＞＜
なので、UNIX関連の議論のシンプルと正しさの衝突の別分野での事例として、エアバスとボーイングの哲学の違いってちょうどいい題材で、737MAXの事故が起こるまではエアバスがアレだという話でアレもあったけど、737MAXでついに危惧されていた通りそのままの事故を起こしてわかりやすくしてくれたので・・・あれかも＞＜
エアバスの場合アホじゃないモードでは飛行機側の事情が隠蔽されている（エミュレートしやすいようにデザインされた架空の航空機をエミュレーションしているともいえる）ので、1980年代の機体から最新の機体まで機種をまたいでも同じ操縦方法である程度同じ操縦感覚（乗員互換性）で操縦する事ができる＞＜
ボーイング737は操縦感覚の隠蔽は行われていないので、737MAXで大幅に特性が異なる機体に変わった時に、無理やり古い737（物理的な機体の特性が剥きだし）の操縦感覚に合わせようとした結果、ギャグみたいな実装にしておもしろい連続事故を起こした＞＜
意味がわからないけど、FBWな操縦システムはレイヤが多重化されていて、トラブルが起きるとだんだんアホになって行って最終的に舵を直接操作する駄目で元々なモードまで落ちるようになってたりする＞＜
航空機の操縦インターフェースはそもそもレイヤーを重ねられないのでソフトウェアの管理についての喩えとして明らかに不適切
航空機の世界で、実装のシンプルを優先すると将来何が起こるかはボーイングが737MAXでわかりやすく証明してくれたかも＞＜
オレンジは古けりゃ何でもいいなんて全然言ってなくて、例えばUNIXのコマンド体系を批判してる＞＜
エアバスとボーイングの違いでわかりやすいところは、一見画期的すぎるようなデザインをしてもそれが長期的互換性を考えて作られたものであれば1987年から最新の製品に至っても互換性を保ててる＞＜
一方で妙に保守的すぎたボーイングは、クラシック機を引きずったデザインである767、747-400、777って行き当たりばったに少しずつ変更してきたので、古い767のデザインのままにするのは危険なので互換性が何度も断ち切れてきた＞＜
787ではやっと、過去ほどの断ち切りは無く777との差を最小限にする努力をしてる＞＜
正しく作る事と長期的一貫性の話は結構頻繁にエアバスを例に書いてるかも＞＜
https://mstdn.nere9.help/@orange_in_space/104396819450085966
システムとしてはこういう規格だけどシェル側では扱えませんなんてことがまかり通る事を一貫性があるとは言わない＞＜
オレンジは、実装としてのシンプルと、ユーザーから見たシンプルは全く違うって主張していて、ユーザーから見てシンプルになる方のデザインの方を正しいデザインと言ってる＞＜（これはUNIXに関する議論でよく出てくる「シンプルと正しさの衝突」の話の用語とほぼ同じかも＞＜）
それで言う所の正しい方にそろえて一貫性を持たせろって言ってる＞＜
それで「当時は『正しい』と思われていた設計が結局よろしくないことがわかった」ときにはまた全てを捨て去れということですかね。
私好みの考えではあるけど、 orange 氏の日頃の主張と一貫してないような気もする (ちゃんと考えてないので実際どうかは知らん)
こうすれば、レガシーなコマンド/ツール群では特殊文字を含んだファイル名も扱うようにして、新しい方のツール群では特殊文字を含んだファイル名を弾くようにすればいい＞＜
たぶん一番伝わって無い部分が伝わるかもしれない刺々しい書き方すると、
オレンジは「ユーザーフレンドリーでは無い『全く正しくない』UNIXコマンド群は、1970年代から現在までの間に滅ぶべきだった」と言ってる＞＜
もちろん互換性の為にレガシーコマンドは(滅ぶべきとはいえ)残すべきかも＞＜ ゴミでも一度つくってしまったのだから＞＜
レガシーコマンドを捨てれば2重にはならないで済むね＞＜
運用で禁止って話にするならこうすべきだったかも＞＜
https://mstdn.nere9.help/@orange_in_space/102475383658421359
何が起こるかはマストドンの特殊ユーザー名の話（2018年に書いた物）の引用で示したじゃん・・・＞＜
このアカウントは、notestockで公開設定になっていません。
エレベーターガール - Wikipedia https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%AC%E3%83%99%E3%83%BC%E3%82%BF%E3%83%BC%E3%82%AC%E3%83%BC%E3%83%AB
"...「発祥の地」である松坂屋上野店でも、2006年4月に常駐ではなくなり、2007年をもって完全に廃止された[3]。日本橋髙島屋には未だに配置されている[4]が、これは日本橋高島屋のエレベーターには手動運転式の機種が残っているためで、必須の要員になっている。"
いま突然気づいたけど、
「上へまいります」って言葉がエレベーターに関する言葉である事って、今の子供はわからないかも？＞＜
エレベーターガールの実物はもちろんフィクションでももう見る機会ほぼ無いんでは感＞＜
ここまで引用すればどういう意図で「UNIXってやっぱ馬鹿が作ったんだな感＞＜」って書いたか通じるかも？＞＜
ていうかゲーム機の拡張バススロットも「イカの耳」ってオレンジは言ってる＞＜(めちゃくちゃ便利な言葉だと思うからもっと特に広義のエンジニア界隈で普及して欲しい言葉かも＞＜(設計手法の説明とかにも使えそうだし＞＜(「イカの耳を作っておく事を忘れるな」とか＞＜)))
イカの耳、転じてオレンジはプログラミングとかでもゲーム(例えばマインクラフトとかFactorioとか)でなんか作る時にも、将来拡張用に備えた設備とか仕様をイカの耳って言ってる＞＜(わりと浸透してない単語の可能性＞＜；)
ちゃんとイカの耳を作っておくとか、きれいに分割するとか＞＜
参考＞＜
幻の路線の名残!? 首都高に潜む巨大な「イカの耳」
ドライブ WITH トリビア＞2018.03 幻の路線の名残｜首都高NEWS
https://www.shutoko.jp/ss/shutokonews/archive/trivia/201803.html
機能拡張の面で言うと、将来その鯖のマストドンの鯖のバージョンを上げた時にその鯖のユーザーは名前衝突されたら困るのでという面の
一方で、予約文字列による特殊なユーザー名のユーザーも、ActivityPubなりOStatusは喋れなければならないんだから、マストドン以外から見て特殊に見えなくても問題ないというか、問題ないように実装しなければプロトコル無視ってことになって大問題かも＞＜
＞＜
https://mstdn.maud.io/@unarist/100557388714324356
https://mstdn.nere9.help/@orange_in_space/100557420010292398
私の理解では ActivityPub 自体はアカウントの識別に IRI を使っているから、たとえば mastodon であれば https:// domain/@ user 以外のあらゆる IRI は事実上 “ユーザ ID としては予約済” であると認識しているんだけど
なんでこれをセットでboostしなかったの？＞＜
https://mstdn.nere9.help/@orange_in_space/105810315610245159
議論した日のnotestock上のログ＞＜
2018年8月16日 - orange_in_space@mstdn.nere9.helpの投稿 - notestock https://notestock.osa-p.net/@orange_in_space@mstdn.nere9.help/20180816/view
例えば(あくまで問題の例示として)さっきの公開LTLトランスポンダをマストドンの新しいバージョンに公式につけるとして、アカウント名を例えばltlって名前にしたら、そのアカウント名を使ってたltlさんが困る＞＜
例えば例えば規格上"_sys"で終わるアカウント名は予約文字列なのでユーザー用には用いてはいけないと規格上定義しておけば、ltl_sysであれば安全に使える＞＜
デフォルトでどうとか設定で追加できるって話じゃなく規格上の予約アカウント名を用意すべきだったかもって言いたい・・・＞＜ example.comみたいに、その目的で使用しても将来的にも過去の互換性的にも問題無いと規格上保証される予約文字列＞＜
通報どうすんだ問題の時もそうだけど、マストドンでシステム用の予約アカウント文字列を用意しなかったの、ものすごく先見の明が無くてすごくアレ＞＜
あとでなにか拡張する為の文字を予め予約しておかないのは全く賢くないよ＞＜
このアカウントは、notestockで公開設定になっていません。
なんでこれをセットでboostしなかったの？＞＜
https://mstdn.nere9.help/@orange_in_space/105810315610245159
mgd？＞＜
"...The only universally prohibited character in a UNIX filename is the forward slash (/). ..."
Parallel shells with xargs: Utilize all your cpu cores on UNIX and Windows | Linux Journal https://www.linuxjournal.com/content/parallel-shells-xargs-utilize-all-your-cpu-cores-unix-and-windows