このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ESはjndiなURLに対してクエリを投げるとこまではしてしまうのでした。 https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/pages/ElasticSearch.md ただし実行まではされない。
@kyuizu 送る側でデジタル的にボリューム制御すればいいと思います。送る側の環境が分からないとそれ以上の事は言えません。
#SubwayTooter の gradlew.bat dependencies には log4jは含まれてません。
まあOS自体はmasterで2.5になってるから脆弱性あればGoogleがなんかアクションとるやろ。問題はサードアプリが好き勝手に追加したライブラリの依存関係の奥底にあるlog4j。こんなんアプリ開発者が依存関係チェックするしかない
Android Code search でApache HarmonyのJNDI関連のパッケージあるかと検索してみた https://cs.android.com/search?q=org.apache.harmony.jndi&sq=
が、ないっぽいなあ
というか、Androidに入ってるのはJVMではなく、Dex中間コードを変換するARTランタイムなので既存の.classファイルなんか読めない。Java EEでもないのでJNDI自体使え無さそう。
手元の端末に入れてたSTの通知既読管理テーブルの内容が、表示済み最新IDと(オープン/スワイプ)済み最新IDの大小がおかしくなってた。とりあえずテーブルからロードした時に大小関係を保証するようにしたが、通知既読管理のリセット操作を追加しても良いかもしれないな…
某おばけはlast_status_atまで規格外なのかよ… API文書の例だと "2019-11-17T00:02:23.693Z" とかだろ…。
うげ、#SubwayTooter が時刻の横に表示するアイコンでsuspendedとDMの未読が同じ図柄だった。直さなきゃ…。 suspendedだとゴミ箱の図柄とかかな…? 禁止マークもエラーマークも別の意味で使われてるし困った
Victor HA-FW10000が点検修理から戻ってきた。ケーブル接触不良は点検時には再現できなかったが、見込みで交換しておいたとのこと。たまに起きる接触不良だと妥当な対応かな。
Pi4の発熱、発売当初と比べてかなり下がってるんですよ
https://www.raspberrypi.org/blog/thermal-testing-raspberry-pi-4/
環境少女グレタは中国共産党の工作員だった http://www.thutmosev.com/archives/81694338.html
Playストアから「install_referrer intent broadcast への依存をMarch 1, 2020までに取り除け」というメールが来て、merged AndroidManifest.xml や gradle dependencies を見たら firebase-core → com.google.firebase:firebase-analytics → play-services-measurement-base という依存関係でブロードキャストレシーバが定義されてた。 https://firebase.google.com/support/release-notes/android を見ると No longer add the Android library firebase-core.
This SDK included the Firebase SDK for Google Analytics. という警告が出てた。 firebase-coreを明示的に使用する必要はもうないらしく、依存関係から外すことにした。
https://pc.watch.impress.co.jp/docs/news/1223528.html 「AMDグラフィックスドライバで過去最高の安定性」らしい。他社にはまだ並んでないと受け取ればよいのか…?
sidekiqからMediaCleanupSchedulerが呼ばれてstatus_idと紐ついてないMediaAttachmentがdestroyされるとき、添付ファイルは削除されるんだろうか…?
@basictomonokai もう一つ、ロード処理を行うスレッド数に制限があるので、カラムに「loading?」と表示されるのはロード処理を開始したがまだスレッドが割り当てられれていない状態を示しています。これも主にサーバ負荷の関係で、無闇にスレッド数を増やすことはできません。
@basictomonokai カラムの作り方によっては簡単にサーバに負荷をかけられてしまうからです。なのでプロセス起動直後はカラムが画面内に表示されるまではロードを行わないよう制限してあります。制限を外せるようにすると鯖缶たちにおこられかねないやつです。
@basictomonokai カラムの作り方によっては簡単にサーバに負荷をかけられてしまうからです。なのでプロセス起動直後はカラムが画面内に表示されるまではロードを行わないよう制限してあります。制限を外せるようにすると鯖缶たちにおこられかねないやつです。
別にSWAPしまくってるわけではないのでクエリを止めて2時間まつだけだが、これだと大規模なDBメンテナンスは面倒だな…
@noellabo 会話ツリー中一部だけメンションされたとしても、ローカルユーザはその会話ツリー全体を見たいですよね。それを妨げるのは私はナシだと思います
@noellabo メンションや返信について、会話ツリー全体をみないと「ローカルと無関係」とは言いきれないんですよ。けっこう大変なので今回のクエリではメンションを含む投稿や返信や被返信は対象外にしてます。レスが付く=重要性が高いという見方もできるので、フィルタ的には割と良い感じです
@noellabo 蓄積される投稿と違ってユーザ情報は現在の状態なので、「古いものを削る」という判定ができないんですよね…。
https://gist.github.com/tateisu/3d98290f2b72d12ba5f1b977a0d5743c ブーストに影響が出ないようにした
テスト鯖なので1時間より古い使われてないトゥートを削除してみた。それなりに動いてる模様。メンションがあればローカル住人と無関係でも残すとか、pinned投稿なら残すとかあるので、思ったよりは他タンスの投稿が残る。添付メディアはstatusとの関連が切れるだけなので別途tootctl media remove_remote する必要がある
とりあえず、リレー参加中のテスト鯖 https://mastodon2.juggler.jp/ でdelete クエリをかけてみる。
リレーを使うようになると使われてない古い投稿がタンスのDBに溜まっていくと思うんですが、どうにかいい感じに削除してディスク容量を空けられないものか…? と思ってこんなクエリを考えてみたけど、どんなもんだろうか https://gist.github.com/tateisu/3d98290f2b72d12ba5f1b977a0d5743c
前に使ったLGV32ではpm hide しまくってからアップデートしてたので、使えなくなったことに気が付かなかったのだ
獺祭「お願いです。高く買わないで」 人気すぎる日本酒メーカー(旭酒造)が呼びかけた理由
http://asahi.5ch.net/test/read.cgi/newsplus/1512975273/
高い値段でも買っちゃう客がいるから転売屋がのさばる、という構図は供給が追い付かない商品だとありがちすな
しかしフルサイズのボディがあればそっちに装着した方がセンサー性能でSS稼げるから、あくまでもネタ装備なんですよ…。フルサイズの一眼レフよりは軽くできるけど、画質と使い勝手は劣る感じw
このフォーカルリデューサーに50mmF1.4をつけると、AFはそのまま使えて、画角は55mm相当、露出はF1.0相当、ボケはF1.5相当、ただし収差は増える。ネタ装備的には面白い
個人的にはあるべき姿は「投稿者が細かく制御できる」だと思う。4段階の公開範囲で十分な時代はもう終わってる
unlistedで意見が分かれるのは、どの公開TLに見せたいかを選択する手段が現状これしかないから。見せるか見せないかじゃなくて、「どの」公開TLに見せたいか。
例えば今後公開TLの種類が増えるとして(APのコレクションとかね)、その度に同じような議論を繰り返すのだろうか
unlistedとタグTLの話、根本的には投稿者が選択できてしかるべきかなあ。開発者やタンス管理者が一律に決めるべきだという理由が特にない。いままでそうだったからというだけ
アカウントTLはアカウントに注目しないと見えないし、ハッシュタグはタグに注目しないと見えないし、パブリック度合いはほぼ変わらないように感じる。ならunlistedでも良いじゃないの…
ハッシュタグTLも完全にパブリックではない何かだ、という定義にすれば、unlistedなトゥートを含めても何の齟齬もなくなるんでは…?
このアカウントは、notestockで公開設定になっていません。
実際のところunlistedは全くプライベートではないのに、タグTLまわりではなぜかプライベートの一種ってことにされてる
未収載はLTL/FTLに載らないだけで十分に公開されてると思う。publicという言葉に惑わされてるのだ
app/lib/feed_manager.rb の trim(type, account_id) ってリストに対しても使われてるのかな
マストドン連動の質問箱サイトができたらしい。 登録だけしておいた https://quesdon.rinsuki.tk/@tateisu@mastodon.juggler.jp #quesdon
今のマストドンの「リストを編集」が使いにくい。ユーザプロフの画面からリスト操作できず、いちいち検索しないといけない。
理由A: 非同期操作の闇「フォロー操作直後のユーザに対してリスト操作を行うことができない」を隠すために「既にフォロー済みだと確実にわかるユーザだけがあのダイアログの検索結果に出てくる仕組み」になってる。本来あるべき方向は「未フォローのユーザでもリストに追加する動線を設ける。未フォローならフォロー操作を促す。フォロー処理中ならそれとわかるエラーメッセージを出す。」だと思う。(STではこの方向で頑張ってみた)
理由B:「あるユーザをどのリスト(複数)に追加したか」を一目で把握する方法がない。(添付画像)みたいな表示が欲しい。
https://mastodon.juggler.jp/media/o6-piNvm6LYOpN3SSdw
専用APIなしでこれを表示しようとすると、リストAPI呼び出しの回数がひどいことになってRate Limitにひっかかりかねない。
Issue は建ててみたけどどうなるやら
https://github.com/tootsuite/mastodon/issues/5953