This account is not set to public on notestock.
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
This account is not set to public on notestock.
This account is not set to public on notestock.
i3 使ってるけどデスクトップ上でのデーモン管理は systemd にやらせている
This account is not set to public on notestock.
This account is not set to public on notestock.
Steam：LAMUNATION! -international-
https://store.steampowered.com/app/1025140/LAMUNATION_international/?beta=0
おや
ラムネーション、愉快そうではあったけどシナリオにあまり良い評判を聞かなかったのでスルーしたもの
ｽｯﾁﾑでﾎﾟﾁｰできるならハードルも下がるやもしれぬ
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.
私も「鯖」の右下が青でない字体を見てなんじゃこりゃとなったことがあり、教養の NASA はこわいねという感想
This account is not set to public on notestock.
This account is not set to public on notestock.
milli と Mega みたいなやつだ、良いと思う
This account is not set to public on notestock.
Rust向け字句解析器生成器「rflex」を公開しました | Preferred Research https://research.preferred.jp/2019/04/rflex-release/
This account is not set to public on notestock.
This account is not set to public on notestock.
ておくれ銀行、 SLA 39.39% くらいありそう (?)
これは行きたいな | 京都大学図書館機構 - 【図書館機構】2019年度京都大学図書館機構講演会「オープン・サイテーションと機関リポジトリの展開」 https://www.kulib.kyoto-u.ac.jp/bulletin/1381711
「オープン・サイテーションとは、論文等の学術出版物に記載された引用データ（参考文献リスト）をオープンアクセス化することです。引用データは、研究評価、研究プロセスの理解、図書館の蔵書形成など様々な場面で活用される重要な要素ですが、従来は複雑なライセンスにより保護され自由なアクセスが難しい状況でした。この状況を打開するために、2017年4月に、学術機関と出版社によって、I4OC（Initiative for Open Citations：引用データのオープン化を推進するイニシアティブ）が設立され、短期間で目覚しい成果をあげています」
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.
「あなたにクロールの権利はない。ここは日本だ」
This account is not set to public on notestock.
This account is not set to public on notestock.
https://twitter.com/nunnu_zero/status/1115564194898690048
ちんちんの安全な取り外し……溜まっていた dirty page をバッファからフラッシュ……接続部から流れ込む電子……なるほどね
This account is not set to public on notestock.
Common Problems – Gentoo Development Guide
https://devmanual.gentoo.org/appendices/common-problems/index.html
> In this case, the file in question is `/big-fat-red-error`.
big fat red error 、「shita big red」みたいだなと思った
Add app-portage/kerenl-config-check-20180811 · lo48576/lo48576-portage-overlay@a049a02
https://github.com/lo48576/lo48576-portage-overlay/commit/a049a02f7f030cc2e313b8d715e16b67a31be69b
kernel-config-check.py の ebuild を書いた
疲れるほど就活してない……というのは客観的な評価で、私からしてみれば就活のことを考えるだけで疲れるし、疲れるほどのことをしていればもはや就活も同然なので、実質常時就活状態なんだよなぁ
ちなみに今のところ2社ｴﾝﾄﾘｰして1社落とされてて残りが名前を知らない人はいない企業 (つまり絶望的) なので、もう少し真面目にｶﾂﾄﾞｰしないと大変にまずい状況
M1の3月にｼｭｰﾝ開始した勢としてもな……
This account is not set to public on notestock.
Living StandardをReferenceに入れるの、「HTML [HTML] に規定されているように〜」（そう規定されてない）（Wikipediaがしているように閲覧日時を記録する流儀は十分浸透していないので著者がどの版を参照したのかも謎）というのが起こりうるという点は少し気になる
結局タグとしてのバージョンを打たないにせよ、特定の版を識別するためのバージョンは欲しいじゃんという気持ちがあり、 Living Standard はその辺りがよくわからん (ちゃんと番号付いてるのだろうか……？)
spec の git repo が公開されていてその hash を見てねなどのアレがあるのなら、まあそれはそれで個人的には許容範囲なんだけど
「朝型夜型得点」とかいう高いと朝なのか夜なのかよくわからない頭悪い命名の点数判定で遊んでいる人が急に増えてきたな
高いのが朝型なら「朝型得点」でいいと思うんだけど、あえて「朝型夜型」にして評価軸の不明瞭な名前にした理由を聞いてみたい
https://twitter.com/yoh2_sdj/status/1115610560215769089
あるいは「正答率」で済むところを「正当誤答指数」と呼んでるみたいな (高いのがどちらなのか不明瞭)
そもそも(なんらかの時間的かつ分野的な範囲での)一貫性が無いものを規格と言っちゃ駄目だよね感＞＜
hogehoge規格準拠にするにはhogehoge規格が将来にわたってある時点の記述と矛盾するような変化をそれ以降持ってはいけない＞＜ 一貫性＞＜
一億歩譲って、誰にでも間違いがあるので、間違いを悔い改める時に土下座しながら過去と矛盾する改変を行う事を認めるのであれば、hogehoge規格第2版とかリビジョンをつける事によって、一貫性の範囲をそのリビジョンの範囲に狭める事が出来る＞＜
そもそも一貫性が無い規格？＞＜ 準拠していると言いようがないものを規格と呼ぶ意味あるの？＞＜
「きっちり定義されてさえいれば規格としてみなせる」という寛容な考え方も可能そう (将来に渡っての互換性は必ずしも要件ではない)
互換性は同じ名前で規格を維持する場合にどうするかという話なので
クソ規格を捨てて別の良い規格に乗り替えることと、時代遅れになった規格が互換性を捨てて綺麗になることの間には、本質的にそこまで大きな差がないかもしれない
なので、一貫性が無くなったら別の規格にしなければならない＞＜(混乱しないように少なくとも規格の名前が完全に同じであってはいけない)
HTML 4 と HTML 5 を連続した規格と見做すか別物にシリーズ名を付けただけかは名前の問題に過ぎないのでどうでもいいといえばどうでもよくて、しかし HTML Living Standard という共通の名前で特定の固定された文書を参照できないのは完全にアカン感じがある
Tissue試しに登録してみたらトップページで自分の絵がお出迎えとか笑うしかないでしょこんなん🔞
キーボードが死んでいるので sudo のパスワードが突破できない（入力できた文字数がわからないので）
-S (--stdin) を使うと stdin からパスワード流せるので、 echo からパスワードを流してどうにかするなどの手があります (シェルの履歴は残さないなり後で消すなりすれば良い)
$ echo password | sudo -S echo
$ sudo hoge
などすれば良い
暗黙に全てがターミナル上で進行するものと思っていた (agetty みたいな)
まあそれでもログインさえできれば tmux のコピペ機能とか使えばどうとでもなるけど
Windows から GUI の ssh クライアント使うとか、 GNOME Terminal 使うとかって生き方をしてきたので tmux みたいなの、覚えるコストをかける気にならない件
ふむ、 tmux の話をしましょう
普通にシェルを使うと、シェルはターミナルにぶら下がって存在することになるわけですが、ウィンドウというのは本来表示単位なのであって、これがセッション (作業の意味単位やプロジェクト単位) として機能したりその寿命として機能したりするのは不自然というか、「 window が必要以上に意味を持ちすぎ」となるわけです (既に同意してもらえなそう)
で、表示領域と意味単位や寿命を分離してやろうぞという話になるわけですね。
tmux の管理単位としては、まずサーバプロセスがあり、サーバプロセスが複数のセッションを管理し、セッションに複数の window があり、 window に複数の pane があります。
サーバプロセスは普通ひとつで、必要なとき自動的に立ち上がり、不要になれば自動で消えます。
セッションはユーザが作るもので、同じ目的でまとめたいプロセス群を突っ込むものです。プロジェクト単位とか。
window は「表に出ている画面」で、言ってみればタブ型の仮想ターミナルのタブ相当。
で、 pane は window を分割した単位で、単一の window 内に複数の pane を同時に表示したり、ひとつの pane を一時的に全画面にしたりできます。
pane や window は同じセッション内なら移動したりレイアウトを変更できます。
Tiling WM に喩えるなら、ターミナルがモニタ、 window が workspace 、 pane がウィンドウに相当します
で、何かというと、 window manager 的な「ウィンドウ」は、 tmux サーバ上の (切り替え可能な) セッションに接続してひとつの (切り替え可能な) window を表示するクライアントとして機能していて、単純に「覗き窓」なんですね。つまり、覗き窓の寿命とセッション (やそれに属するプロセス群) の寿命は切り離されている
すると、たとえば複数プロジェクトを同時に弄っていて複数セッション用意してあったとして、「今はこっちのセッション要らないから非表示にしとこう」などと思ったとき、 tmux を使っていればデタッチするだけでいいわけです。
ここで tmux でなくターミナルのタブを使っていると、ウィンドウを最小化したり別ワークスペースに避難させたりするけど、消してしまうことはできない
detach できるってだけなら nohup で SIGHUP を止めるだけでもいいんだよな別に
nohup って attach できます？
screen/tmux/byobu の利点は，shell が動く環境なら OS や DE に限らず複数のターミナルをタブみたいに起動したりペインで起動できるところですよね。
個人的な感覚で言ってしまうなら「シェルやプロセスを適切な構造で階層化して管理できる」ことと「レイアウトを割と柔軟に管理できる」ところが tmux の良さで、 つまりデスクトップにウィンドウが散乱しているのを気持ち悪く感じる人ほど tmux の有り難みを感じられるのではと思っているんだけど、これは個人の感想なので事実がどうかは知らん
This account is not set to public on notestock.
私は
* 番号で履歴参照しない
* 履歴は incremental search する
* 空白で開始したコマンドラインは履歴に追加しない
* その他条件に合致したコマンドラインは履歴に追加しない (git hoge や vim hoge、引数なしのコマンド、などなど)
によって快適なシェルライフを送っています
background process になってもプロセス番号はわかるしその FD も procfs から取れるわけで，実はゴニョれば再度拾いなおせたりする
ゴニョりたくない (stdin と stdout の fd を持ってきて継ぎ換えるとかリダイレクトする的なことすればいいのかな)
ググっても「GUI がないのでショートカットキーかぁ難しいなぁ。『コルタナさん、例のセッション見せて』で切り替えられないかなぁ」みたいな気持ちになった
ショートカットキー、まあハイという感じですね (変更できるし私はしている)
C-← と C-→ で前後ウィンドウを表示するようにしたの、結構便利
まあ prefix-n と prefix-p も普通に使うんですが、連打するなら C-矢印が楽
tmux のショートカットで一番の問題は、デフォルトのプレフィックスキー (tmux コマンドのほとんどに付ける最初のキー) が皆バラバラなことですかね……
C-t 派 (なんだろう) と C-b 派 (デフォルト) と C-a 派 (GNU screen 由来？) などが多い
C-b は vim での C-b と競合して嫌なので (C-b C-b とすれば vim 側に C-b が届くけど)、私は C-t 派です
tmux でペインを横に分割するのよくやる（watch コマンドと何かを起動して何らかの情報をモニタリングしてるのを横に出しつつ，書いたプログラムを実行するとか，w3m とかで言語のリファレンスを横に出しつつ何かを書くとか）
あと、 git commit を叩いてから画面を分割して、もう一方で git diff --cached するなどの運用もよくやる。変更の diff を見ながらコミットメッセージを書けるので便利
journalctl -f -u foo.service とかを横で出しつつ何かデーモン走らせるとかな
私キーバインドのカスタマイズ死ぬほど面倒がる人だからだいたいキーバインドはデフォルトでしか使わない
emacs bind と vim bind くらいは選びたい (まあ慣れなんだろうけど)
まあ結局両方使ってるんだけど (大抵のツールは vim タイプにしてるけど、 fuzzy finder は C-p と C-n で行移動できてほしいとか、 GTK のテキストボックスでは C-a / C-e / C-u などのアレをよく使っている)
まあ真面目に答えるなら、 tmux の window 作成にフックして「新規ウィンドウの下部にヘルプ表示した pane が生えてくる」みたいなことはできそう
This account is not set to public on notestock.
つまりヘルプのショートカットキーだけは絶対覚えないといけないんですね（vim が起動して help とか ? とか入力したけどヘルプにたどり着けなかった人間（正解は :help））
Ed, man! !man ed- GNU Project - Free Software Foundation (FSF)
https://www.gnu.org/fun/jokes/ed-msg.html
Let's look at a typical novice's session with the mighty ed:
golem$ ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
なぜパソコンイキリオタクたちがショートカットキーをカスタマイズして覚えていられるのか不思議で仕方ない
カスタマイズして覚えるんじゃなくて、覚えやすいものを設定して押し付けていくんですよ
その点個人的には vim のコマンドは覚えやすくて良い、 vim のキーバインドはほとんど上書きしていない
