1.5時間？ #知らぬ間に椅子の上で気絶部
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
1.5時間？ #知らぬ間に椅子の上で気絶部
クレデンシャル管理の話で keepass 派の話をなかなか聞かないんだよな (サーバ不要だから？)
本当におすすめです、特に Nextcloud サーバを既に自前で持っていたりするようなオタクは満足できるのではと
https://mastodon.cardina1.red/@lo48576/111126880776372544
🈟NAS のホスト名をまだ考えていないので、そろそろ決めないと起動もできやしない
14 TB ×2 だと思っていたが、どうやら再確認してみたら 12 TB （10.91 TiB) ×2 しか余ってない……
pool の used が 10.02 TiB なので、これはまず間違いなく足りない。 HDD の買い足しは不可避のようだ
https://mastodon.cardina1.red/@lo48576/108505666951247882
オタクなのでホスト名は美少女ゲームのキャラから取っています
ｴﾖｹﾞのキャラクター名、枯渇しないし PC 関係の用語と衝突しづらいし画像や声でのイメージが紐付くから思い出しやすいし、なんなら色とかを対応させようと思っても割と簡単にできてしまうし、良いことずくめやで
別に俺は良いもの使ってるぜイエイイエイってイキりたいわけじゃないんだけど、良い体験を提供するものを作るには、普段から良い体験を提供するものに触れている必要があるので、選べるならそこにコストをかけているものを選ぶべきという信念がある
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.
GPG にやらせたくないので ssh-agent 使ってる
ただでさえ GnuPG はカオスなのだから、「ひとつのことをうまくやる」を徹底してくれという感じ
This account is not set to public on notestock.
This account is not set to public on notestock.
ssh-agent、デフォルトがパスワード省略になるのが微妙な気がするので使うなら常にパスワード要求するように設定したい
ssh-agent ってデフォルトだと一回解除したらあとは鍵のパスフレーズ入力スキップしてログインできるようになりませんか
そもそも ssh-agent はそういう役割のものだと思っていたので考えたことなかった (agent 使わなければ passphrase 毎回入力することになった気がするし)
ForwardAgent yes では駄目なのか
ssh-agent からロード済のキーのキャッシュを消すには ssh-add -D でやれるはず
個別の削除は ssh-add -d [file...]
A を踏み台にして B にログインするとき、authorized_keys さえそれぞれに設定しとけば ssh agent とかなくても ssh -J A B で手元にある鍵だけでログインできるから agent forward のはなしはそれでよくない？という気がしてこないでもない
SSH 鍵をパスワードマネージャに突っ込みたい需要、あまりわからん (理屈のうえではありうるのはわかるんだけど)
特にプライベートな用途では、基本的にクライアントごとに鍵を生成しといてサーバ側にそれを突っ込むという感じになるし、だったら ansible とかで authorized_keys をまとめて管理できてればそれでおわりじゃない？ という
べつに ansible とか高度なこと言わずとも ssh 接続して上書きコピーするだけでも十分だし
複数クライアントで SSH private key を共有する必要がある状況って、「公開鍵を自由に登録・削除できないサーバがある」という場合だけだし、これってかなり稀だと思うので……
その場合普通に private key を .ssh/ にコピーしてくるんでは駄目なんか？ という感じ。
鍵側に設定する passphrase を管理したくないから password manager で……というのはまあわからんでもないけど
ホスト A と B が鍵 x を authorized_keys に持ってて、ローカル→A→B でアクセスするなら、ローカルに秘密鍵 x を持っていれば ssh-agent で貫通してパスフレーズ入力は1回で済む
ちょっと自信なくなってきたので手元で試してみている
いけた。 ローカル→A でのアクセスで ssh -A として agent の forwarding をする必要があるのと、 A の sshd_config で AllowAgentForwarding yes してある必要があるけど (弊環境ではデフォルトで yes だった)
ただ ~/.ssh/config にあるホスト名のエイリアスとかは引き継がれなそうなので、ポートとユーザ名と IP アドレスを指定してやる必要があった (ssh-agent はあくまで鍵の管理であってオプションまで面倒見てくれないらしい？)
おっかしいなぁ、 ForwardAgent yes してるはずなのに自動で -A 相当の挙動になってくれてない
.ssh/config は Include foo などすると .ssh/foo を読んでくれるのでこれが地味に便利
自宅の物理サーバだけで7台ある (仮想サーバ含めるともっと多い) ので、いいかげん認証を SSO か何かでまとめたい気持ちが強くなってきた。
……が、可用性の担保やるのがダルすぎる (軽率にブレーカーを落としたり LAN ケーブルを引っこ抜いたりするので)
あとオーバーキルソリューションの沼に沈みたくないというのがあり、 LDAP とか Kerberos は視野に入れつつもかなり警戒している
ssh-agent の挙動見て POSIX 非互換シェルの痛いところを突かれた顔になった
eval するやつなぁ。
まあ構文的には単純なのでラッパー噛まして割とどうにかなるし、ソケットのパスを固定させてしまうのもひとつの手。
私はソケットのパスを固定したうえで systemd で ssh-agent デーモンの管理させてます
いろいろなデーモンが systemd user session で管理されている
systemd の environment からシェルに引っ張ってくるのは、こういうスクリプトを用意してシェル起動時にロードしてる
これがないと、セッション作成後に変更された environment がリロードされなくて、セッション作成直後の値がずっと使われるということになってしまうので。
普通はその挙動でも困らないんだけど (たとえば HOME とか XDG_DATA_DIRS とかがログイン中にコロコロ変わるようなことはありえないし危なすぎる)、私はもうちょっとカジュアルにセッション内で環境を共有するのに使おうと思って。
スクリプトとして見ると POSIX sh 系よりはかなりまともな構文と制御構造を持ってる
POSIX sh と比べたらなんだってマシだし Pascal だって女神に見えちゃうでしょ……
べつに non-POSIX sh に抵抗があるわけではないんだけど、「ちょっとスクリプト書こう」からの「これサーバで動かしたろ」みたいなことをしたくなることは多くて、だったら (interactive shell の UI はさておき) スクリプト言語の処理系としては (bash ですらない) POSIX sh を日頃から使うようにしておかないと筋肉が衰えてしまう、という動機で #!/bin/sh してる
interactive shell 前提のことなら zsh 固有の機能はまあまあ積極的に使っている
https://mastodon.cardina1.red/@lo48576/111133071995230123
たとえばこれ、 ~/.config が ~conf になっているのお気付きでしょうか (cd ~conf とか vi ~conf/nvim/init.lua などやってもちゃんと動く)
さすがに日頃から busybox を使うほどの筋トレ趣味はないので、 alpine Linux のインスタンスとかで ip コマンドの挙動が微妙だったときとかはﾋｨｺﾗ言いながら sed 叩いてますが
fish 使うまえちらとこれ思ったこともあったけど、Dockerfile だとか GitHub Actions workflow とか Makefile とか嫌でも POSIX sh 書くことも常にあるから何も問題なんてないのだと了解した
CI: 使ってない
Makefile: 使ってない
Dockerfile: 書いてない
なるほどね
ローカルマシンにひきこもるのをやめろということか……
や、 Jenkins とかはそのうち立てるつもりなんですが (まだ woodpecker と迷っている)、どちらにせよシェルとしては相当浅いところの部分しか触らない気がしているのでどうかな
if なら ok とか || の前なら ok とか、なんかあったよな…… (おぼえてない)
KWARC/rust-libxslt: Rust wrapper for libxslt
https://github.com/KWARC/rust-libxslt
結局メンテされなくなってるなぁ。いつかそうなるかもとは思っていたが……
KWARC/rust-libxml: Rust wrapper for libxml2
https://github.com/KWARC/rust-libxml
こっちは流石にまだ使われているようだ
Haskell の HXT というやつなど面白そうとは思っていて、まあ要するに XML to XML の変換を気持ち良く書ければ何でも良いのだが、やっぱりその用途では XSLT が圧倒的に “自然” かつそれなりにポータブルなんだよな……
べつに Rust から逃げることは当面ないだろうし portability については気にしないといえば気にしないんだけど
フォローリクエストに対して UI 的には
* accept
* reject
* mute
* block
* reject forever (reject future requests automatically)
* ignore forever (don't show follow request notification anymore)
くらいの選択肢があるのが妥当な気がしてきた
人間ユーザの文脈でのフォローリクエストの処理って、本質的にはリクエストそのものの処理というよりは対象アカウントの審査であるように思われるので、審査の結果どう扱うかという選択肢を提示することを考えると mute / block は入るべきと割と素朴に思えてきた
accept and follow back もあっていいのかも
bash を使うスクリプトは #!/bin/bash するべきなので、デフォルトのシェルは小さいに越したことはないと思っている (エラーが起きないと不正な #!/bin/sh 記述には気付けない人も多いだろうし)
むしろ dash にも bash 拡張みたいなのが若干漏れ出してたりするんじゃないかというところの方が不安がある。 dash で動くから安心してたら ash で動きませんでした、みたいなのがあると嫌だし……
いや dash なら大丈夫なのか。 bash の sh モードが一番安心できない
Debian系以外のメジャーな非Bash /bin/sh LinuxシステムとしてBusyboxを使うものがある
そういえば busybox あったな……
Debian、merged-/usr を延期 | スラド Linux
https://linux.srad.jp/story/23/05/20/0430248/
日本語不正オンライン薬局のセーフヘイヴン、GMOインターネットの対応について | LegitScript
https://web.archive.org/web/20210728074807/https://www.legitscript.com/ja/blog/2016/08/%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%B8%8D%E6%AD%A3%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E8%96%AC%E5%B1%80%E3%81%AE%E3%82%BB%E3%83%BC%E3%83%95%E3%83%98%E3%82%A4%E3%83%B4%E3%83%B3%E3%80%81gmo/
やってんねぇ…… (そしてこのページが消されているのがまた……)
LegitScript Helps Stop 6,149 Rogue Online Pharmacies in 2019
https://www.legitscript.com/2020/01/23/shuts-down-rogue-pharmacies/
> Although ICANN guidelines are clear, some registrars are slow to respond or outright refuse to take action in response to LegitScript's notifications of abuse. (snip.) Outside of the US, Japan-based GMO Internet, Inc. and India-based Ednit Software Private Limited sponsor rogue pharmacies that mostly target Japan,
This account is not set to public on notestock.
ハッシュタグさえ付いていれば何でもいいよ (ハッシュタグがないせいでミュートできない猫写真に腹を立てている顔)
まあそんなもんよね。ワイも美少女ゲームのキャプチャとか無頓着に貼ったりするし
つまりそれが文化圏ってやつなんでしょう
正直、猫に限らず実在人間の写真とかもかなり見たくないものの部類に入るのだが、人間の写真に # 人間 のようなハッシュタグが付いている光景は流石に見たことがない
主にフィルタリング用途を想定して、ハッシュタグ以外のもう少し implicit というか not appealing な属性付けの仕組みがあるべきなのではないかと思うことはある。完全に不可視にしてしまうと、それはそれで望ましくないハックが横行しそうだが……
一貫していてフィルタとして使い物になれば何でも良いと思うし、なんならそれを理由にブロックされても良いというレベルであればフィルタ可能にする必要もないと思う (とはいえ好き好んでアカウント全体をミュート/ブロックしたいとは限らないので選択可能であってはほしいが)
実写アイコンの眼力が強すぎて受け付けないという理由でアカウントをミュートしたことがあるマンなので、もうどうとでもなれという投げやりな感覚もなくはない
いわゆる「実況」(放送番組に時間同期してコメントを投稿する行為) などはタグ付ける人も付けない人も両方とも多いのだが、作品名ではなく実況を弾くのに使えるようなタグを付けてくれる人はそう多くなかったし、そういうアカウントはやむを得ずアンフォローしたこともある
実況自体を弾くのに使えるタグ、たとえばテレビ局名のハッシュタグとかです (まあそれもそれで局自体に言及する用法まで引っかかってしまうけど……)
まあそういったわけで、「使いやすい属性として与えられた属性タグ」でないと精度高い活用は難しくて、そして「アピールするためのハッシュタグ」と「アピールしないためのタグ」はおそらく別物として作られないと駄目だよな、というぼんやりとした直観があるというわけ > https://mastodon.cardina1.red/@lo48576/111134018416169707
属性タグで思い出したけど、ブログ記事とかに与える「タグ」も本当は質の違うものが複数あるはずなんだけど、区別されているのはあまり見たことがない
ちょうどメモがあったのでそのまま投げるか
「関係する話題」と「そのものの話題」は区別できてほしい。コミケに行ってついでに飯を食った日記とコミケそのものについて論じる話は区別できてほしいし、AMD の製品に関する話題と AMD という企業そのものに関する話題も区別されてほしい。
implied tags は基本的に「関係する話題」側。
* is-a タグ: 記事そのものの性質を記すタグ。この場合、「日記」タグや「トラブルシューティング」タグなどは記事そのものが日記やトラブルシューティング記録であることを示す。
* describes タグ: 記事が論じる対象を示すタグ。この場合、「日記」タグや「トラブルシューティング」タグなどは、記事が日記についてやトラブルシューティングについて論じていたり説明していることを示す。
* relates タグ: 記事に関係があることを漠然と示すタグ。この場合、タグは記事に関して「関係がある」以上の情報を与えない。たとえば、「日記」タグや「トラブルシューティング」タグは他人の日記を読んだりトラブルシューティングを眺めた感想の記事に付けることができる。
以上でメモ引用おわり。
implied tags というのは、「Ubuntu」タグをユーザが与えたらシステムが半自動的に「Linux」タグも付けてくれるようなシステムを想定したときの、「Linux」タグ側のこと
https://mastodon.cardina1.red/@lo48576/111134116902336629
この概念の包含というかタグの implication 関係は、真っ当に整備していくとそのまま ontology になる気がしていて、 semantic web を再発明しているなぁという気持ちになったりする
タグの包含関係の実装例です (この例では Rust タグと advent calendar だけがユーザによって付与されていて、 programming は Rust タグから、 computer は programming タグから自動で (間接的に) 付与されている)
これも本当は is-a:advent calendar と describes:dendron と relates:Rust (または describes:Rust) の組み合わせなんだけど、まだタグそのものの種類はモデルを固められるほどちゃんと考えてないので実装もしてない
苦痛耐性の話は「殴られたときに備えて殴られておく」みたいな本末転倒を誘発しがちなのでかなり厳しく批判的な目で見がちなところがある
「社会はもっと厳しいぞ」という言い訳のもとに行われる学校でのパワハラとか。
耐性パラメータを上げるための苦行が楽しいのは遊びの中だけよ
はてブのタグが、これら(＋個人的メモや個人的ジョーク)がごちゃまぜで、使い物にならなくなってるの、ムカつく＞＜
タグで大喜利したり謳い文句っぽくしたりするの、たぶんニコ動あたりの文化なのかなと思うけど、小説投稿サイトとかにも流入していてタグの質が悪い
なんというか、シンプルにビジュアルの表現が洗練されていないせいでハックされているのと、モデル化が雑なせいであらゆる用法や異質なものが混合してオワってるのと、ちゃんとやったところでユーザ側での世界の解像度が低すぎてまともに運用されないのが目に見えているのと、いろいろ複合的な要因があって地獄が生まれているのかなという感じがする。能力の認定なしに不特定多数を受け入れるプラットフォームではどうしようもない。
「多人数」を意識するようになったらオワ、というぼんやりとした感覚がある
見せる内容ではなく見せる行為そのものに主眼が移ってしまうというか
「俺にはこれが良い」ではなく「これを “みんなに” 見てほしい」になったらもうおしまい
これを自己顕示欲という概念で説明しようとする言説はよく見たものだし一理あるとは思うけど、それだけではないというか別の原理によってつまらなくなっている側面もあると思う
This account is not set to public on notestock.
そもそも「面白い」と「気持ち良い」の混同から諸々の複雑さが始まっているのではという気持ちもある
面白いものごとを求めてフォローする人と気持ちよさを求めてフォローする人というのがあるのでは (これも大概雑な分類だが、ひとまずシンプルなモデルとしてこれでいく)
たとえば私は私の言うことに気持ちよく賛同してくれるアカウントとかいう存在があったとして心底どうでもよく感じるわけですが、むしろそれが大事という人も少なからずいるはず (どちらが多数派かは知らん)
べつに SNS に限らずリアルでもそうか。
結局のところ、フィルターバブルとかエコーチェンバーとかいうやつもリアルでそういうの作ろうとする度合いの傾向がそのまま出てくるだけなのでは？ という仮説も立ってしまう
直接依存として指定してないコンポーネントにアクセスできてしまうモジュール管理システム、 C/C++ のヘッダの混乱から何も学んでいない
「あとで読む」タグに関してはシステムで最初からパブリックには表示しないタグ扱いにしておけばいいのにって思う＞＜
Amazonの質問コーナーみたいなのに「わかりません」だけの答えが除外されずにあちこちで表示されまくるのと同じように間抜けなシステムかも＞＜
べつにこれは特定のシステムを批判するわけではないんだけど、「とりあえず最低限動くし使い物になる」というレベル (いわゆるMVP？) で運用開始してハックや低品質利用が横行しつつもそのままデータ蓄積しちゃって……みたいなパターンをあらゆるところで見るので、マジで人々って情報や概念のモデルに興味ないんだなと思う
ユーザによる全体可視なタグ付け (tagsonomy やそれを真似たシステム) もそうだし、星の数によるレビューシステムもこれに該当する
This account is not set to public on notestock.
その結果、不愉快なものにざまぁするコンテンツで喜ぶ姿や、犯罪のニュースを見るたびに犯人に向かって悪態をつく姿、そういうものを見せつけられて辟易する人もいるってわけ
まあ人間の醜さを知っておくのは大事かもしれないッスね〜
そもそも「偏りがない」という判断の基準自体が真っ当に規定できないだろうし、不可能で未定義なことを都合よく決めつけてバランス取ろうと考えるのはあまり健全でないとさえ思う
思想的な偏りのなさ、たとえば人口で加重平均をとるのか、それとも少数派も大切にすべく多数派を相対的に軽視するのか、これだけでも一方を選択して一貫した判断を保つのは極めて難しい。まず間違いなく場面次第で都合のよい選択が発生する
たとえば乱雑に (選別なしに) 数を増やして結果に満足がいくなら、それは入力の偏りのなさゆえのことではなく、単にマジョリティとの相性が良い (あるいはマジョリティそのものである) というだけの話かもしれない
あとは「情報に触れて判断することそのものを趣味としている」という可能性も結構ある
そういう趣味の人はたまにいて、多趣味判定をされたりしていることもあるけど、個人的にはメタな趣味なだけではという感じがする。そういう人々のスタイルにうっかり合わせようとするとえらい目に遭いますよ
https://mastodon.cardina1.red/@lo48576/109187928718753987
フォローを検討するとき最初に判定するのがコレなので、まずここで引っかかるアカウントが多くてフォローを増やしづらい
SNS でのﾋｮﾛｰをキメるとき、(学術とも自分の守備範囲とも限らないが) それなりに専門的だったり詳細な話をよくしていることと、マジで興味なさすぎるし笑えもしない日常の投稿が十分に少ないことがおおよその基準になっていて、私はこれを「S/N比 (専門/日常比) が高い」と呼んでいる
技術的にめちゃくちゃ面白い話しまくってるアカウントでも興味なさすぎる日常の投稿が多かったりするとﾋｮﾛｰしないことが多々あり、勿体無いとは思いつつマジで他人の生活とかどうでもいいので仕方ない
このアカウントからのﾌｮﾖｰを少しずつ増やしていきたいところなんだけど、 S/N 比 (https://mastodon.cardina1.red/@lo48576/109187928718753987) が結構低いアカウントが多くてなぁ……
TL の S/N 比が下がることは私にとって明確に体験の低下なので、おもしろい情報の絶対量が増えればそれで良しという感じではないんだよな……
アイス調子に乗ってたくさん買ったため冷凍庫にたんまりあるので、アイスどころでない室温が当たり前になる前にある程度処理しておかないといけない……
興味ある投稿が稀によくある( https://dic.nicovideo.jp/a/%E7%A8%80%E3%81%AB%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B )アカウント、フォローしなくても同じクラスタ内の共有で流れてくるので問題ない、みたいなところある。
これは実際あるんだけど、フォローが俺の TL を作る！ 善意の RT に頼りきりになるな！ という鋼の意志をもってフォロー検討をしに行きます (まあ大抵は忘れててスルーしてる)
たまに思い出したように確認してみたら未ﾎｮﾖｰだったので今更ﾋｮﾛｰ、みたいなことはままある
TL 確認しに行って S/N 比が低すぎてﾛｮﾖｰを諦めるということも結構ある
尾がないのに交尾……と言おうとしたけど「“前しっぽ” を使ってるじゃん」との脳内ツッコミが入ったため発言案は棄却された
This account is not set to public on notestock.
This account is not set to public on notestock.
むしろ、潰しが効かないプログラミング言語が少なくなってきていると思う。そもそも鋳潰す必要がないというべきか。コンパイラやインタプリタのソースコードが公開されているので、コンパイラの会社が倒産して何もかも終わりだよもうというリスクがかなり低くなった。
今潰しが効く効かないを気にするレイヤーは、たとえば web frontend framework とかそういうレイヤーになっているのではないだろうか (知らんのでテキトー言ってる)
あれもなんだかんだで †アウフヘーベン† している気はするので後継や後発への移行で持ち越せる知識量はそれなりに多そうではあるが (知らんのでテキトー言ってる)
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.
X540-T2 って、爆熱と名高いアレじゃん
安いからといって準備なしにとびつくと苦労しそう
This account is not set to public on notestock.
This account is not set to public on notestock.
プログラミングにおける言語の選択は、そうだな……工作をするときに、3Dプリンタを使うか、木材とネジや釘を使うか、金属と溶接を使うか、LEGOを使うか、既存の製品をバラして使い回すか……くらいにはデカくて影響のある選択です
べつに何使っても個人で短期間使い物になるものはできるかもしれないけど、 “ちゃんとした” ものを作ろうとするならそれなりに方法論や特性やコストが違うし、区別しないのは単なる無知か怠惰
そもそも安泰を求めてやるようなものじゃないのでは、職業ﾌﾟﾖｸﾞﾔﾏ
This account is not set to public on notestock.
どうだろ、ﾎﾟﾖｸﾞﾔﾐﾝというかｱｲﾃｰは分野を跨いで適用できることが多くてその点では潰しはきくのかなという感想はある (ポストが多いかは別問題)
慣習とかはそれなりに違うだろうけど、培った技能や直観がが死ぬことはそうそうなさそう (マルチパラダイムでやってるなら特に)
まあどこ行ってもやっていけるような人はそもそも勉強を苦にしてないだろうから潰しの効く言語とか考えないだろうけど。
コア言語だけでも鎚なのかグラインダなのかチェーンソーなのかの違いがあるからどれでもいいってことはまずないけれど、それだけでなくツールチェーンやエコシステムまで含めると大規模な工務店で働くのか一人親方なのかぐらいの差も出てくるのだなあ
原爆の俺、アメリカから追放されたので深海のヌシになります 〜軍に帰ってきてくれと言われてももう遅い〜
北朝鮮 軍事境界線を越え北朝鮮側に入った米兵 “追放”を決定 | NHK | 北朝鮮情勢
https://www3.nhk.or.jp/news/html/20230927/k10014208641000.html
これかぁwww
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.
This account is not set to public on notestock.
自分用 PixelFed をさっさと立てるべきっぽい
くぉ〜‼ ぶつかる〜‼ ここで予算全開、ニホン人を西に！
This account is not set to public on notestock.
This account is not set to public on notestock.
戦闘機の操縦桿は股の間から屹立しており、これを喜びの棒に見立ててジョイスティックと呼び……
これ3つめの投稿見て自分の心が汚れているのを実感してしまった
ジョイスティック(原義)の頭に付けるゴムとジョイスティック(隠語)の頭に着けるゴム両方あるのが悪い
エイムリングみたいなのはゴミたまって逆効果らしいけどハット部分に被せるキャップみたいなのはまあ大丈夫でしょうというのと、デフォの感触がちょっとしっとりしててもうちょっとカリっとしてるのにしたい
prime@mstdn.poyo.me
This account is not set to public on notestock.
This account is not set to public on notestock.
？？？「ほーら、 libc のアドレスをランダムに決めちゃうよ〜 (ささやき声)」
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.
This account is not set to public on notestock.
キーボードは多ければ多いほど良い
