はてなブックマーク

はじめに この記事は、Linux Advent Calendar 2019 - Qiitaの8日目です。 この記事では、今使っているLinux Kernelがどんなkernelなのか、どんな設定で動いているのかを確認する方法を紹介します。 Linux Kernelは様々な用途に使われています。 そのため、ひとくちにLinux Kernelと言っても、動作はシステムによって全然違います。 現状を把握する手段を知ることで、効率的にKernelのコードリーディングやより良い設定を探す一助になれば幸いです。 また、コメント大歓迎ですので、なんでもお気づきのことがありましたらぜひお気軽にお願いします。 この記事で書くこと Linux Kernelの素性を確認する方法 Linux Kernelの設定値を確認する方法 この記事で書かないこと 各プロセスや各ユーザなどに対する設定（ulimitやniceや

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

$ fdisk GentooAarch64_20171114.img Welcome to fdisk (util-linux 2.27.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0x1218c51a. コマンド (m でヘルプ): o Created a new DOS disklabel with disk identifier 0x8c0219cc. コマンド (m でヘルプ): n Partit

HTMLのどこでJavaScriptを記述するか、選択肢が多すぎて迷ったので、まとめてみた。 head tag defer/asyncなし HTMLのレンダリング前に同期的にロード・実行 HTMLのレンダリング前に実行する必要があり、他のJavaScriptと依存関係がある場合のみ使う HTMLのレンダリング・他のコンテンツのロードが遅れるのでできるだけ少なくするべし deferあり HTMLのレンダリングと並行して非同期でロード HTMLのレンダリング後に同期的に実行 HTMLのレンダリング後に実行する必要があり、他のJavaScriptと依存関係がない場合 本来はJavaScriptの実行順序は保証されるという仕様だが、保証されないブラウザも存在するらしいので、他のJavaScriptと依存関係がある場合は使えない asyncあり HTMLのレンダリングと並行して非同期でロード HTM

シンボリックリンクの向き先を変えたいときって結構あるけど、単純にln -s TARGET LINK_NAMEってしたら怒られる（"ln: target: File exists"）。 そこで泣く泣くrm -f LINK_NAME && ln -s TARGET LINK_NAMEってしてたけど、便利な上書きオプション-fがあった。 あぁわかりやすくて便利、ln -fs TARGET LINK_NAME。 （なんで今まであると思わなかったんだろう。。。） [追記] TARGETがディレクトリの時は、-nオプションも必要。 ln -fs TARGET LINK_NAMEだけだと、TARGETがディレクトリの時に意図通りにならない。 $ ls -l TARGET1/ TARGET2/ $ ln -fs TARGET1 LINK_NAME # 1回目は大丈夫 $ ls -l LINK_NAME -

（最初に修正を導入したリポジトリ内で） git remote add TO_FIX_REPO {これから修正を導入したいリポジトリのURL} git fetch TO_FIX_REPO git checkout -b TO_FIX_REPO-master TO_FIX_REPO/master git cherry-pick {master上の修正コミットのSHA1} git push TO_FIX_REPO TO_FIX_REPO-master:master （上記を修正を導入したいリポジトリの数だけ繰り返す） これならかなり機械的に処理できるから、だいぶ楽になるんじゃないだろうか。まぁだからといってコピペが横行して良いというわけではないが。 ちなみにgit push TO_FIX_REPO TO_FIX_REPO-master:masterってのも結構ポイント。ローカルのブランチ名とリモ

gitでバイナリファイルの差分を出力したいときはgit diff --binaryを使いましょうって話。 「コミットすればいいじゃん」ってゆうツッコミは置いといて。 他の人と一時的な差分を共有するとき、git diff > hoge.diffとかやってパッチを渡すことがある。 そんなとき、バイナリファイルに差分があったらどうするか。 「このパッチをあてて、このバイナリファイルをここに置いて、それからこうやってビルドしてください。」ってのはちょっと残念。 git diffはデフォルトでバイナリ差分を省略するので、--binaryオプションの出番。 ちなみにテキストファイルの差分もちゃんと一緒に出力してくれる。このオプションは例えばgit showなどでも使える。 適用するときは特にオプションは不要でgit applyでバイナリも変更してくれる。 ただ一点注意。もしパッチを渡す相手が昔ながらの

「○日のソフトだったら動いていたのに。。。」ということはよくある。 そんなときgitリポジトリではどうやって環境を再現するべきなのだろう。 結論を先に書いておくと、「きちんと運用をしておかないと機械的に厳密に再現することはできない」 ＃良い方法があったら教えてください。 真っ先に思いつくのはgit log -1 --until=2013-01-23などでその日付以前の最後のコミットを抽出し、checkoutするという方法。 だがこの方法には落とし穴がある。指定した日付以降にmergeした修正（当時まだ導入していない修正）を、checkoutしてしまう可能性があるのだ。 例えば下記の操作をした場合、2013/01/23リリースのソフトといえばcommit1までをcheckoutしたいが、実際にはcommit2までをcheckoutしてしまう。 [2013-01-22] git checkou

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?