アホが暴れない SNS の要件、「承認欲求を満たせない」というのが必要な気がしてきたな
アホが暴れない SNS の要件、「承認欲求を満たせない」というのが必要な気がしてきたな
たとえば直接のフォロワー/フォロイー以外からの RT / fav を認識できないとか
コミュニケーションと承認は一致しないので、承認欲求を満たせない SNS というのが本質的矛盾を抱えているとは思わないです
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.
This account is not set to public on notestock.
vendor c/psgo@v1.3.2 by vrothberg · Pull Request #4197 · containers/libpod
https://github.com/containers/libpod/pull/4197
libpod やっと cgroups v2 対応か……
This account is not set to public on notestock.
This account is not set to public on notestock.
シンプルに「クソッタレのために割いてやるコストはねえし、構ってほしけりゃ金払え」くらいの気持ちでいる
物分かりの悪い連中には「オメーには苦痛を受けてまで関わる価値はない」とはっきり言ってやるべきなんだけど、はっきり言ってやる価値もないので静かにブロックするわな
インターネットに何十億人いると思ってるんだろう、アホどもをブロックしても世界に有益な人間はまだいくらでもいるわ
あと「反対意見をブロックし続けるとエコーチェンバーになる」とかもアホな話だよなぁと思う。反対意見なら何でも不愉快でブロックしたがったり “改心” させたくなるお前らと一緒にしないでほしいわ
というか「分散」という言葉も微妙な気がしていて、本来「サービスに関する権利を個々のユーザの手に取り戻す」というものなのよね
本来ひとつだったものが「分散」するというよりも、「委託を余儀なくされていた権利をユーザに返す」というのが私の感覚です #distsns
多数決でブロックするユーザー決めるの?>< ツイッターレディースならぬマストドンレディース(?)大活躍かも><
分散は「自分の意思で『特定の人間がブロックしたがった人』を同様にブロックする」という個人の意思決定と矛盾するものではないと考えますが
「本人の意思による」というのはよーするに「拒否による不都合が発生しない状況で、本人の理解と同意のもとで機能を利用するか」という話なのであって、ブロックリストが必ずしも分散により取り戻した権利を再び失うことを意味するわけではない
(実際そうならない機構も考えられる)
こういうときだいたい最初に検討すべきなのは Web of Trust をベースとした信用・信頼の伝播と減衰のモデルなのよね (割と適合する)
ツイッターだって結局『声が大きいユーザー』の大多数に従ってるだけでしょ?><
本丸はツイッターの会社ではない><
本丸があるかどうかは関係なくて、「『声が大きいユーザー』の大多数に従」うことをオプトアウトできるかどうかというのが本質。 twitter でそれはできないし分散 SNS ではそれを可能にできる
twitter で強いられていたあらゆることを廃止すればより自由になるというのは違って、自由であるというのは何らかのメリット・デメリットを取るか捨てるか選択できるということ
ここ最近の特筆すべき絶望、「お絵描きできないので 3D モデルを作ろうとしたけど、三面図がないとまともな造形にできそうにない」ということに気付かされてしまった瞬間などがあります
まあいろいろ調べて三面図なくてもいけそうなメソッドを見付けたので試すだけ試してみたりはしてるけど、根本的に完成図のビジョンというかバランス感覚がないので険しい道程になりそう
他の人の言葉を借りるなら、あるひとつのブロックリストが『セレブ』のようにならないと、どう考えたら考えられるの?><
セレブのようになったブロックリストを継続利用するかどうかはユーザに委ねられているし、むしろその愚かな選択をできることこそ自由でもあると思いますね。
システムで人間の愚行を抑えるにも限度があるし、そんな不毛なことが「愚劣でない人間がデメリットを飲み込む覚悟とともに危険な機能を利用できる」ことよりも大切だとは思いません
言葉を借りずにいうなら、あるひとつのブロックリストにユーザーが極端に大きくなることはないと言える?><
オレンジ的には間違いなくひとつかふたつ程度のブロックリストを、ブロックリストを利用するようなユーザーの半数以上が利用する事になるだろうと予想するかも><
その (おそらく想定では) 不適切に巨大なブロックリストを実際に利用するかは個々人の選択なのであって、それを阻止することが自由に貢献するとは思わない。
それが気になるならソフトウェアのプロジェクトみたいに fork してメンテするみたいな仕組みを用意することもできるだろうし、あるいはそもそもそういうことができない別のブロックリスト共有の仕組みを選択することもできるかもしれない。
むしろ「○○は愚行に使われるから人々に提供すべきでない」は人々から自由を奪う考え方ではないかとも思えるんですが
私の求めるものはあくまで「意思決定とそれに基く行動がともに阻害されない」という状況であって、人々を愚行から救うことではないです
フォークしたってフォークした先のリストに移る人何てそんなにいないでしょ?><
で、そのうち初心者向け記事で「安全の為にブロックリストを購読しましょう。人気があるリストはこれとこれです」って書かれて「そうなんだ!」ってその通りに購読して、大半の人はブロックリストを購読したことを翌日には忘れてるよたぶん><
人々が檻の中に入っていくことを防ぐのは、技術的な阻止手段ではなく教育、キャンペーン、そういったものでやっていくべき。
この問題について技術レイヤーですべきなのは、その檻にある日突然鍵がかかったとき人々を中から逃げられるようにすることだと考えます
IT界隈の人も含めて、圧倒的多数の人がそういう人でしょ?><
普及してるものや普及しているやり方を疑う人がどれだけいる?><
私は大衆の行動を技術でコントロールしようとは考えていません (たとえそれが良い方向へであっても)
私は人々に「ナイフで手首を切ると痛いし病気のリスクもあるからやめた方がいいよ」と言うかもしれないけど、いざ本当に手首を切ろうとしている人に「やめろやめろ!!」と喚いたりはしないし、あるいは「手首を切ろうとしている人が手首を切れないナイフ」を開発しようとも思わない
手首を切ろうとする人が手首を切れないナイフを開発するよりも、「自分の手首を切ることを躊躇できるような思想を持ってもらう」方が正道だろうと思うわけです
@keizou TL; DR: そうあるべきではないかもしれないが、ユーザ設定が無視されたとしても問題であるとまでは言えないと考えます。
そもそも LTL や FTL は「誰の意思で誰のために用意されているのか」が極めて曖昧です。
たとえば「個々人の意思を一切仲介させず、あるがままのデータを機械的に見せる」ものかもしれないし、「鯖缶の親切心で、全ユーザに一律に特定の情報を見せる」ものかもしれない。あるいは、「個々のユーザが、自分で閲覧するためにサーバに情報をまとめるよう指示している」というモデルもありえます。
最初のモデルでいけば、一切のフィルタリングが機能しないことは正当であるといえます。
2つめのモデルでは、ユーザが要求していないドメインブロックなどの追加フィルタが最初から導入されていることが正当化できます。
最後のモデルを想定すれば、ユーザがフィルタを自由に設定・適用できるべきだという論拠になるでしょう。
その辺りの「誰の意思で誰のために」が曖昧である以上、どのような実装であってもおかしいとまでは言えないし、逆にお互いに別のモデルを想定して「ここは FTL の意義に合っていない」と主張することもできてしまうだろうとも思います。
そもそもブロックリストが檻にならない または檻になったら気づけると思ってること自体が、檻の中に立って檻の外に居ると思ってる発想かも><
中身を『具体的に』確認しないリストをどうやってその正確性を判断するのか?><
インターネットからの排除の問題も、排除されてしまったものが排除されるべきであったのか?という情報自体も排除されてしまうので、公正に機能しているかどうかを確認する術がないという問題がある><
それに近い状態を「見れない」のではなく「見ない」事でわざわざ実現するとは、なんて愚かなこと><
公正であるかどうかを判断する権利自体をドブに捨てるようなものかも><
https://mstdn.nere9.help/@orange_in_space/103012713964850428
これは「ソースコードを全部読んでないのにどうしてソフトウェアを使う気になるのか」と同じような話に思える。
一般に信頼の構築は必ずしもデータそのもののみによらないし、たとえば「誰が作った」「その誰かが今まで何をしてきた」で信頼の初期値を決めるのは極めて妥当に思われる。
問題の兆候があったとき、その中身を精査できるということが大事なのであって、「利用するあらゆるものを完全に精査する」というのはコストがかかりすぎるので、問題の兆候がないときこれを省略しようと考えるのは当然よね
GUI っていうのは使い方を覚えるものではなく、そこにあるものを押せるものなんだよという強い気持ちを持っているので、本当にジェスチャーが嫌い
小学生頃、ブラウザのマウスジェスチャに飛び付いたりしてた時期があって、結局全然使いこなせなかったんだけど、たまにそのことを思い出してあの頃は若かったなぁみたいな気持ちになる
思考が硬直しはじめた今となってはタブレット端末でのジェスチャも忌避してしまうやもしれず、まあ恐ろしいことではある (使いこなせるかはまた別の話)
「誰が作った」だけでは信頼するには足りないと考えるとき、「誰と誰が信用していて、私らその人々をレビュアーとしてどの程度信用している」みたいな間接的な信用を利用したアルゴリズムが輝いてきて、これこそ Web of Trust なわけです
参考までに cargo-crev というプロジェクトが WoT を利用したソースコードレビューシステムで、とても良いものだと思うので概要だけでも把握する価値はある。
今は Rust のみの対応だけど、根本のシステムは言語非依存なのでそのうち js 版とか他言語への対応もしたいそうで
ソースコードと大きく違う所は、ブロックリストは『読まない対象』のリスト、つまり『中身を確認しないためのリスト』になる事かも><
必ず1アカウント1アカウント過去の発言を遡って読んで判断するのであれば別だけど、そういうものを利用したいような人がそんなことしないでしょ?><
べつに「ブロックしている」ことは「ブロックしたユーザをどう頑張っても調べられない」ということではないし、そんなに気になるならブロックリストを上書きするホワイトリストを用意するとか、ブロックリスト一時無効化みたいなものを用意するとか他にやりようはあると思うけど
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.
本の虫: 2018 Jacksonville会議でC++のドラフト入りが決定した機能
https://cpplover.blogspot.com/2018/03/2018-jacksonvillec.html
基底クラスじゃなくてもサイズ0にできるようになったのか。継承より合成で実装を引き継ぐときのメモリロスをなくせるわけだ
C++ 、型システムがあまり豊かでないせいもあるんだろうけど、任意の問題を attribute で解決しようとしている印象を受ける (偏見気味)
あくまで「最適化のため」なんだなぁという印象が強い (まあスタンスが一貫しているといえばそうかも)
twitter に kb10uy 氏がいたので見る TL 間違えたかと思って脳が混乱した
2019 Roadmap Progress? - internals - Rust Internals
https://internals.rust-lang.org/t/2019-roadmap-progress/10862/7
わくわくするなぁ
std::get (std::variant)
https://en.cppreference.com/w/cpp/utility/variant/get
これ std::get<42>(v) と std::get<float>(v) どっちも使えるんか……ヤベえな
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.
ALL CULTURES MATTER BUT I DONT WANT TO SEE ALL CAPITAL ENGLISH WHEN IM TRYING TO SCROLL THE MASTODON
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.
必要なのは「Not Safe For Work」フラグではなく「I Am Working」オプションだった説を提唱したい(適当)
いや冗談ばかりでもなくて、「嫌なら見るな」の受信者側フィルタを充実させるべき
とにかくいろいろなところで言えるんだけど、情報は受信者側の機能や設定を充実させる方向にしてほしい
原則として不快防止は受信者側でやるべきだと思ってるので、連投ポストを畳むとか(リアルタイムでは)表示しないとか、そっち系で受信者側でフィルタしてほしさがある
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.
送信者側でフィルタしろというの、つまるところ「他人を自分の都合の良いように操りたい」欲の発露だからなぁ
これは pawoo や jp に限らないけど、寄合所帯インスタンスはアカン奴がある程度いると、たとえまともな人が多くてもフィルタリングがインスタンス単位になったりして、まともな人を巻き込んだ対処になりやすいのでよろしくない
こいつらと一緒にすんなと思うような人と同じインスタンスに所属しないでほしい。独立して♡
???「 で凍結されて居場所がなくなったので来た」 みたいな。Fediverseの仕組みがわかってない人は結構いそう
RE: https://oransns.com/users/Nadja_tirol/statuses/103015525401596464
素朴な疑問なんだけど、連合の仕組み分かってない人間はなんのためにFediverse来てるんだろ…?
This account is not set to public on notestock.
This account is not set to public on notestock.
「流行」は「何もわかってない人がファッションの一環として入ってきて、文句言うだけ言って去っていく」のエイリアスみたいなものなので
これも何度も言ったことあるけど、分散 SNS はやたら多数の人々がいないと利益取って成立できないような中央集権商業 SNS とは根本的に違って、ユーザが少なくても成り立つものなんだから、何もわかってなくてこれからもわかるつもりのない人々を twitter 気分で呼び込んでもお互い得るものが少ないよ
思想を啓蒙していこうな……(もう手遅れな気がしないでもないけど)
思想を大事にする人なので啓蒙していこうな!と連呼している
思想から入る人ってごくごく一部なんでしょうけど、そこで妥協してると状況がどんどんよくない方向に転がりかねないのでうーんという感じ
別に連合の仕組みわかってない状態でFediverseに来ても良くない……???みんな初めから全てわかってはじめてないでしょ…………
私自身は思想から GNU Social に入った人間なので……
まあマイノリティなんだろうとは思います。残念なことに。
たとえば極端な想定として「少数の根強いコアユーザが存在する」としたとき、商業だとこれは潰れるだろうけど、分散 SNS でこれが「衰退」することに何か問題があるのだろうか?人が増えなくなった slack チャンネルや discord サーバ並には有用だと思うけど
まあソフトウェアのメンテナンスとかはコストかかるので純粋にユーザ数だけ考えてもしょうがないんだけど。
This account is not set to public on notestock.
であれば「流行しない」ことは「ユーザがいなくなること」と一致しないのでおしまいという感じですね
たとえば特定クラスタの人間が皆去っていったとして、他のクラスタでは普及していたとする、このとき fediverse は「衰退」しているのか?
いつぞやの Mastodon ブーム以前から、 GNU Social に定住していた人々は存在するわけで、そのくらいの規模で fediverse に価値がなかっただろうかといえば私はそうは思わないし、「流行させる」以外にも人を呼ぶ方法はあるだろうから、そっちを考えたいわねという気持ちがあります
分散 SNS は良いものです、権利をユーザに取り戻します、それでいいじゃないですか。
敢えて「ポスト twitter」などと twitter ユーザを煽って無知な人々を無知なまま誘導してくるような余計なお節介があまり素敵に思えないというくらいの話と捉えてください
「必要としている人々が参加できる」くらいのレベルで応援したい感があり、押し売りをする気力はないしその結果として荒れるのも嫌
そもそもこいつがいるのはアメリカンネトウヨ用のインスタンスなので何言っても無駄だったwwwwwwwwwww
そうなんだけど、ツッコミがいがあるおもちゃというかなんというかこう><;
firefox とか thunderbird はいつになったら Python 3 でビルドできるようになるんですか
Firefox/Python 3 Migration - MozillaWiki
https://wiki.mozilla.org/index.php?title=Firefox/Python_3_Migration
もしポリコレな感じの人であればその人がオレンジのような考えに改めさせてオレンジ2号にしたり、それが不可能っぽい感じな方向の人物なら逆に「排外主義者で結構!」って開き直る所まで追い込むとか、そういうのがしたい><
気持ちはわかるけど私はあまり人間に興味ないのでそうなっていないだけで、モノに対してならまあわかる
https://mstdn.maud.io/@pakutoma/103016591498264492
たしか CUE + flac 使うと、曲の間のギャップ情報まで保存できるというのがメリットだった気がする。
あとはジャケットファイルがトラック間で重複しないので若干容量削減できるとか
私は基本的にトラック毎に flac だし、 flac で表現できないレベルのハイレゾは wavpack 使ってます
昔は flac + cue + jpg in mka なんてのも試してたことあったなぁ
最近のプレイヤーはトラックごとに別ファイルでもなんか頑張ってギャップレス再生してくれるからあんまどうでもよくなってそう
ジャケットがかぶらない、たしかにメリットだ(複数環境でそれなりにきれいに表示させようとするとそれなりに高画質な画像を埋めこむので)
全員が個人インスタンスなら、たとえば DM とかも当事者間のみでの通信になるのでプライバシー確保できるんだけど、少なくとも一方が寄合所帯インスタンスだとそっちの鯖缶が DM 覗き見権限持ってるからなぁ
This account is not set to public on notestock.
Firefox 70登場 - 高速JavaScriptエンジン搭載 | マイナビニュース https://news.mynavi.jp/article/20191023-913301/
タイトルを見てSpiderMonkeyの改良に重点を置いて解説しているのかなと思ったけれど公式のアナウンスと同じでETP重点だった
The Baseline Interpreter: a faster JS interpreter in Firefox 70 - Mozilla Hacks - the Web developer blog https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/
ちなみにJavaScriptの性能について説明しているのはこの記事で、インラインキャッシュを搭載したバイトコードインタプリタを昔ながらのバイトコードインタプリタとベースラインコンパイラの間に置くことで、大量のコードをJITCに流し込むことなくプロファイリングできるようになってロード時間やメモリ使用量に少し良い影響が出たという話
典型的なJITコンパイラ(JITC)はまずバイトコードインタプリタ上で実行して(直接ターゲットの機械語を出力していた昔のV8は典型的なJITCではないものとする)これはコンパイルしようと判断した一部を改めてコンパイルするようになっていて、最近ではそこそこのコードを出力するベースラインコンパイラと最適化をガッツリ施すコンパイラの二段構成(直接機械語を出力していた頃のV8もこうなっていた)が主要JavaScript処理系では主流になりつつあるのですが、ベースラインコンパイラでコンパイルするのもタダではないのでインタプリタが賢くなるとうれしい
Rust and C++ on Floating-point Intensive Code - Math, Numerics, and Software
https://www.reidatcheson.com/hpc/architecture/performance/rust/c++/2019/10/19/measure-cache.html
Linux Kernel | Energy Aware Scheduling (EAS) – Arm Developer
https://developer.arm.com/tools-and-software/open-source-software/linux-kernel/energy-aware-scheduling
This account is not set to public on notestock.