linuxbrew でツールの依存で Qt 入ってきた結果、chromium のビルドが始まって辛い
linuxbrew でツールの依存で Qt 入ってきた結果、chromium のビルドが始まって辛い
Qt、webengine のため chromium を内包しとるんか
pawoo.net に対する連合機能の一時停止について
いつもMisskey.ioをご利用いただき、ありがとうございます。
この度、pawoo.net において不適切なコンテンツ(児童ポルノ)の投稿が急増している事象を受け、ユーザーの皆様の安全を最優先に考え、同インスタンスとの連合機能を一時的に停止させていただくこととなりました。
皆様にはご不便をおかけしますが、安全な利用環境の確保に向けての措置であることをご理解いただきますよう、お願い申し上げます。
今後ともよろしくお願いいたします。
SysCallFilter で制限した方がいい syscall リスト一覧ってどっかにないのか?
@mitarashi_dango https://nogithub.codeberg.page/
> Is this a legal document?
> No, it isn’t. If the project is under an open source license, it means that everyone can share a copy – even on GitHub – of the licensed material under certain conditions.
あくまで開発者を尊重して守る人は守ろうという感じですね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@balloon @kaori ブラウザに限らず発生するはず。日本語だけなら、雑に直す変更入れてもらった
https://git.joinfirefish.org/firefish/firefish/-/merge_requests/10527
次バージョンで日本語だけは治るはず
とりあえず、systemd 側で syscall filter は入れてみているが、process fork してるので privileged とかつけないといけないんだよな。結構 filter 書くのがめんどい
個人的には Firefish が機能的に一番良さそうなんだが、No GitHub がちょっときついんだよなあ
自分でフォークするなら GitHub に置けないのは結構きついし、security advisory 出す人は結構 GitHub ユーザの割合が高いのでセキュリティスキャンの機会も減るのも微妙なのよな
個人的な Firefish vs Misskey vs Mastodon は、
Mastodon:
👍 アプリが充実している
👍 グローバルにユーザが多く、比較的安定している
👎 動かすのに Ruby / Node 両方が必要で管理コストが高く、消費リソースも大きい
Misskey:
👍 機能が豊富
👍 misskey.io という実績あるインスタンスで使われている
👎 アプリが少ない
👎 リソース消費が激しく、メモリリークもする
Firefish:
👍 Mastodon / Misskey 互換な部分が多く両方のエコシステムに乗れる
👍 Mastodon / Misskey に比べ軽い
👎 バグが多く、またユーザ数も少ないためあまり安定していない
👎 No GitHub なので、GitHub にフォークできない
ハッシュタグはグローバルでしか機能しないので、グローバル
【個人サーバーのみなさんへ】
普段の投稿範囲どうしてる?
理由がある人はメリット・デメリットなど教えてください!
(これ以外の人も……)よろしくお願いします
【アンケート】
Misskey 使ったことないから分からんけど。なお、develop だと 128 文字になってた
このアカウントは、notestockで公開設定になっていません。
@balloon 後は、普通に Misskey の場合リクエストに生パスワードは載り、悪意がなくてもアクセスログにリクエスト body とか載せててそれが漏れたりするとアウトな場合はあるので、まあパスワードそれぞれ設定する分にはそっちの方がいいと思いますね。まあこれも全てのサービスに言えることですが
TODO 多めだが、コードはここにあるぞ
https://github.com/mizunashi-mana/sample-alloc
メモリ上の生存は Linux が動的に確認してくれるのでヨシ!
73/98 functions で unsafe がついてるらしい。これが僕の Rust や!
ほーん、型上で assert が書けるようになるってこと?
このアカウントは、notestockで公開設定になっていません。
ももいろテクノロジー、人生で一番お世話になってるブログです
@elpinal ありがとうございます。ちょうどその方法は試してました。macro 定義の中だと補完が効かないのがちょっと難点ですが、基本これで良さそうです。ありがとうございます!
@elpinal なるほど、ありがとうございます。結構使用範囲が長い時は scope 区切ってやったり、関数として括り出せるものは括り出したりしてやってるんですが、わりと f / g / f / g みたいな交互の呼び出しが連続する系だと辛いなあって感じでした
@elpinal それはそうなんですが、let y の binding でやりたいことは borrowing ではなく単に borrowing の記述数を減らすための binding というか、記述の alias を作りたいって感じです。
f(&mut x.b, x.a);
g(&mut x, 3);
f(&mut x.b, x.b.c + x.a);
の x.b の部分がちょっと長くて一々コピペで書きたくないという感じなんですよね。投稿の方のコードは例コードで、実際には g は A 全体を mutable に操作する何かって感じなので、g の方を弄るみたいな解決はできないって感じです
やっぱりなんも分からん。いつか Rust 分かるようになりたいな〜。今回は諦め
borrowing しない場合の書き換えは融通利かしてくれてるってこと?
でも、
let y = &mut x.b;
x.a = 1;
は書けるが、
let y = &mut x.b;
(&mut x).a = 1;
は書けないのか。それってどういう原理なんだ (別の疑問が生まれてしまった...)
つまり例が良くなかったらしい
struct A { a: usize, b: B }
struct B { c: usize }
fn f(y: &mut B, v: usize) {
y.c = v;
}
fn g(x: &mut A, v: usize) {
x.a = v;
}
let mut x = A { a: 1, b: B { c: 2 } }
let y = &mut x.b;
f(y, x.a);
g(&mut x, 3);
f(y, y.c + x.a);
みたいなんが書きたい
読んでもよく分からん
x.a = 1;
と
(&mut x).a = 1;
が違う意味論を持ってるのか
#[derive(Debug)]
struct A { a: usize, b: [B; 5] }
#[derive(Debug)]
struct B { c: usize }
fn main() {
let mut x = A { a: 5, b: std::array::from_fn(|_| B { c: 2 }) };
let y = &mut x.b[0];
y.c = x.a;
func(&mut x);
y.c = y.c + x.a;
println!("{:?}", x);
}
fn func(x: &mut A) {
x.a = 10;
}
cannot borrow `x` as mutable more than once at a time
@elpinal なるほど、&mut よく分かってなかったんですが、これってこの時点では借用しないんですね。これっぽいです。ありがとうございます!
いや、まあ、*mut () as usize とかが必要なコード書いてるので、unsafe function がたくさんあるのはしかないんだけど
unsafe 警察が求められるな。Copilot、unsafe 使わない書き方教えてくれ
コンパイラに怒られるから一所懸命
struct A { a: usize, b: B }
struct B { c: usize }
let mut x = A { a: 1, b: B { c: 2 } }
x.b.c = x.a;
x.a = 1;
x.b.c = x.b.c + x.a;
って書いてるけど、x.b.c の部分がもうちょっと長いと辛い
struct A { a: usize, b: B }
struct B { c: usize }
let mut x = A { a: 1, b: B { c: 2 } }
let mut y = x.b
y.c = x.a;
x.a = 1;
y.c = y.c + x.a;
みたいなんが書きたい時ってどう書くの?
Rust の所有権ってやつがよく分かんなくって、let bind できない人になってる
Rust でたくさん unsafe fn 書くやつやってる
全ての dynamic library は backward compatible でプラットフォーム依存じゃない serialize 形式で繋がれてどうぞ
libc & openssl の根絶は人類の夢でしょ。なんで C 使わんのに C 標準ライブラリが必要になんねん
@1inguini 知らなかったですが、面白そうな RPC system ですね。ただ、encoding / decoding の速さより、サポートの方が求められる状況はある気がしますね (多少 encoding / decoding にリソース割かれていい)
FFI 高級にしてもどうせ言語能力に差が出てくるので、最悪バイナリだけ渡せるようにしてシリアライズは工夫してもらおうの方が色々都合が良くないっていう
このアカウントは、notestockで公開設定になっていません。
Protobuf なり Thrift なり JSON なりで foreign interface 作るの、割と良くやる手法だと思ってたがそうでもないのか
Web デザイン周り全然なので、一回 Figma で画面作ってそれをちゃんとコードの落とし込みつつ、それなりの規模のフロントエンド作るはやってみたいんだよな
インスタンス単位ならリレーを作ればいいわけだけど、別にリレーしたいわけじゃなくてフィルターしたいんだよな
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
一期は陳腐な発端からの stand-alone complex が好きなんだけど、2nd GIG は人間ドラマって感じで個人的な琴線には触れなかったんだよな。タチコマ可愛いのはそう
攻殻機動隊 2nd GIG、おもろいんやけど、standalone complex としてはやっぱ笑い男事件の方が好きだなという感じ分かる?
Twitter こんなにたくさん話題になって、MAU 鰻登りやろなあ()
このアカウントは、notestockで公開設定になっていません。
どうせなら dist upgrade は clean install でやるか
Firefish & Debian bookworm 移行への道のり
1. Mastodon の account moved & suspend の時の WebFinger / Actor の内容を調べる
2. Mastodon post -> notestock full URL の mapping 作る
3. WebFinger / Actor / Activity の static file 化と、notestock へのルーティング作る
4. https://github.com/mizunashi-mana/firefish-dist-pkg の起動テスト作る
5. 手元で試験運用
6. Mastodon / Firefish 並走させ、お引越しして Mastodon 閉じる & static 化
7. Debian dist upgrade
このアカウントは、notestockで公開設定になっていません。
Mastodon、最初何すればいいか普通に分からんよ。情報もめっちゃ分散しとるし
Mastodon / Misskey に興味を示さないが、タイッツーやスレッズに腰が軽いというより、昔 Mastodon / Misskey 試してあまり経験が良くなかった人がいるという話なら観測してるな
@osapon お、なるほど、一応 activity id から note の full URL 検索 API あるんですね。それならマッピング簡単に作れそうですね。ありがとうございます!
このアカウントは、notestockで公開設定になっていません。
@osapon ありがとうございます。そうすると、やっぱりリダイレクトは結構厳しそうですね... 全投稿 activity id -> notestock id 変換マップ作るみたいなことすればできなくはないですけど
@osapon このインスタンス閉じた時に投稿のリンクの飛ばし先を作りたくて、activity id から簡単にリンクしたいなという感じでした
https://mstdn.mizunashi.work/@mizunashi_mana/110763900296214895
notestock 側の permal link の note id って、activity id とは別に notestock 側で振られた独自 id って感じですよね?
Hostdonで自分専用のサーバーを建てた話
https://note.com/crossdon_note/n/n22923c017ea1
noteで公開しました。
ホスティングサービス(Hostdon)利用の初歩の初歩な内容ですが、自身の備忘録も兼ねて記しておきます。長いぜ!
後リモートアカウントインポート時って nodeinfo とかも見てるんだろうか? WebFinger さえおいとけばなんとかなる?
inbox は POST 410 で閉鎖できるし、アカウントフォローも POST 410 で閉鎖できるはずか。そもそも actor が movedTo になってる場合何が起きるんだ?他のマストドン鯖はそれ捕捉してなんかしてくれるんか?
マストドン鯖閉鎖時に
* WebFinger account resource static 化
* Person Actor suspended & moved 宣言して static 化
* GitHub pages にポストを移してそこにリダイレクト飛ばす
* POST は全部 410 返す、他の GET は 404 返す
以外にしといた方がいいことってあるんか?
notestock が post ID とかでりんくできないっぽいので、post のリモートリンクは残念ながら諦めるしかなさそうだが。まあ、そこも static に作るの頑張ってみてもいいが
手元で試しにやってみるか。放棄鯖の static 化、GET で Person actor と web finger だけ static に作りつつ、後は 410 / 302 返せばいいようにするだけならなんとかなりそうだな
suspended かつ moved な Person actor とかって作れるんか?
AP の actor の方では movedTo ってのがついてるのか。GET でこれ返すようにしとけばいいのか?
WebFinger には引越し済みみたいな情報は載らないのか
Firefish install script でも、CREATE USER で不要な CREATEDB 権限とかつけてたりして微妙に気になる
静的サイトでもドメイン共有してる何かがあるなら XSS は気をつけといた方がいいぞ (Cookie / Local Storage が漏れる)
狼と香辛料、まじで俺は何を見せられてるんだ。こんなん子供の頃読んどったんか?
後、一人開発なら圧倒的にコピペ -> 後から共通化の方がよい共通化もできるし生産性も高いけど、複数人開発だと知らない間にコピペ増えるので最初から共通化しといた方がコスト安い場合もあるっていうのも
最初から共通化して書くより、コピペして後から共通化考えた方が生産高いの分かる。ただし、共通化コストが案外高く後回しにして結局やらないと、後で高くつく場合もあるのが悩ましい
このアカウントは、notestockで公開設定になっていません。
Twitter の最近を知らないけど、著名なトレンドはなんか分かるマンになってる
これはそう。何事もバランスが大事。ただ、変革が速すぎると失業者が出たり倫理上の問題はどちらにしろ出てくるので、そこのケアは必要だと思う
このアカウントは、notestockで公開設定になっていません。
@sublimer ところがそうすると今度は断言しないのは責任回避だと批判されたりするという...
stack にすると next だけで良いが、途中の要素抜き出したり、順番入れ替えたりするだけで double linked にする必要が生まれるの中々厳しい
ヒープレイアウト決まったし、allocator 書いてくか
@lithium03 ああ、AP 的にどう付き合ってくべきかというより、チラシに AI 絵使うべきではなくない?みたいな話が発端でした
ま、法律という具体的に人の権利縛ってくるやつが、実際に訴訟してみんと解釈わからんとかいうとんでも運用されてるのが悪いという話はあるが...
似たような画風の絵を描かれて学習元の絵者がどう思うかを考えるべき、AI 絵は細部が変になりがちなので品質を問題にするところで使うのはどうなのか考えるべきというのはそうだがそれは倫理上の問題でありそれはそれで議論されるべきだが、そこに著作権的にグレーゾーンとかいうほぼとんでも法解釈使った脅しだよね?みたいな文言入れてくるのはあまり誠実的ではないと思う
法律が全てじゃないので、創作者というか当事者が自身の権利を侵害されている、別に良いのではみたいなお気持ちを表明するのは聞く価値があるし、倫理的にもうちょっと考えるべきではという批判は分かる。ただ、現行法でどう解釈されるかの批判は切り分けて、ちゃんと法解釈に載った形でやって欲しい。じゃないとどこが問題でどこが問題じゃないのか、どう進むべきかを曖昧にするだけ
これなんだよなあ。解像度が低いという批判での著作権に対する言及が解像度低すぎるとちょっともにょる
このアカウントは、notestockで公開設定になっていません。
世の中善意を前提にしすぎてるので、奉仕を行わないと批判されるっていう。別に善意に溢れること自体は素晴らしいことだが、善意前提にして善意がない場合に批判が始まったら終わりだよな