filezillaのエディター設定をコンソールのvimを呼び出すラッパースクリプトにする。
ここまではググって楽勝。
#!/usr/bin/zsh tilix -e "vim $1"
これでやると制御文字がナマで中出しされるので、こうしないとだめっぽい。
#!/usr/bin/zsh tilix -e "tmux new-window vim $1"
あれやこれや入れ子にしまくると、いつも制御文字系に引っかかる。便利は不便w
Electron and xfce4-notifyd or other notify daemon don’t get along.
Chromium stops short time, when we viewing pornHub and other some cool sites.
How to fix this.
sudo mv /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications_service
Rename file and reboot.
add your i3config this.
exec --no-startup-id dunst
notice: dunstrc on ubuntu
/usr/share/doc/dunst/dunstrc.gz
Have fun!
1000枚程度の画像ファイルをconvertで適当な処理をやる工程をpython3のsubprocessで
単純にforで回して
for file in files: subprocess.Popen([convertへのコマンド], cwd=dir)
みたいな感じをOSXでやると、メモリいっぱいまで食いつぶして気持ちいい爆速処理ができます。仮想8コア100%。CPU稼動率はっぴゃくぱーせんと！ なんだか楽しくなってきます。
そんなに入らないぃぃぃ状態まで食わせるので、当然他の操作は出来ません。ファンがめったにない高速回転になるのが気持ちいい。回転数が下がったら処理が終わりみたいな感じ。
投げっぱなしなので、適当な手段で次の逐次処理に追い越されないようにしないといけませんが、OSXでは処理前ファイルと処理後ファイルの数を比較して、合わなかったら寝てろで止められます。書き出し中のファイルはカウントしないようです。
これをLinuxでやると予定通り、oom_killerに殺されてシステム自体が動作不能になります。
どこでも動く制限付きのマルチスレッドに変更せねば…。
ということで、
「フォルダ1」にtiffファイルが入っていて、処理済みのファイルを「フォルダ2」に書き出す処理。
def hage(x):
subprocess.check_output(['convert'---x[n]を適当に当てはめてコマンドを形成--], cwd='./'--カレントディレクトリで走らせる決め打ち)
def main():
todo_list = []
for file in files:
todo_list.append(フォーループで回すのに使うはずだった変数一覧）
# ここで読み込みファイルのフルパスと書き出しファイル名のリストを作るので順不同に処理されても問題なし
p = Pool(いい塩梅なプロセス制限の数値）
p.map(hage, todo_list)
check_outputのsubprocessがPool()個づつ回ります。
ここで、またPopenを使ってしまうと、戻りがないので、ひたすらぶっこまれて最初に戻るになります。
6.2MBのTiffファイルを200枚の処理で、単純にcheck_outputに投げると、1ファイルずつの処理になるので約280秒。Pool(8)ちゃんに回してもらうと、約60秒。
単純にPopenに投げたときより少しだけ速かったので、ちょっとびっくり。
食いつぶされても死なないようにOSXがなんかしてるオーバーヘッド的な何かがなくなり、論理コア数分（うちのは4コア。論理8コア）のプロセスしか使わないのでお気楽になるのだと思われます。
I.O DATA HDL-GT2.0 余裕の長寿命かと思ってたら、崩壊…。ほうかいwwww
一人で使ってるので、使用時以外は電源を切っていて、使うときに起動する感じで使ってました。
昨晩起動したら、なんかデグレちゃって、ああ、デグレか。今度こそ予備ディスクを使う日がやってきたか。と思いきや、前回デグレのときと同じく、いきなりリビルドを始めやがりました。
進行中のファイルは入ってないので、適当にリビルドしてくれ。前回のようにwと思って、帰ってきたら、赤ランプ全点灯。警告音鳴りっぱなし。
ずっといた人に聞いたら、出掛けてすぐくらいから鳴り続けていたということなので、リビルドを始めてから爆速で崩壊したようです。ほーかいwwww
smartを見てもこれと言って問題があるわけでもなく、なんか知らんけど、何かの拍子になんか起きてデグレードして、何かの拍子にリビルド開始、何かの拍子に崩壊。
何かが何かはまるでわかりません。
普段遣いのファイルや進行中のファイルは入れていないので、流用データが無くなって滅多にこないものは新規で作ることになる感じで済みます。
どうせ、そういう用途で、概ね半分くらいしか使ってないし、極端に古いものは捨ててるので、思い切ってこのままraid5からraid10に変更して、機械が完全に死ぬまでいじめ抜いて差し上げることにしました。
こんくらいの規模のraid5で割と売れたものなので専門業者さんは定番の復旧策があるようで、概ね妥当と思われる御値段で復旧可能ですが、なくなったものは諦めてまた作ればいいというイワオ方式で行くことにしました。
今更役に立つかどうかわかりませんが、
電源を切る。
最上段のHDDだけ残して、あとは全部抜く。
起動。
途中で赤ランプ点灯。警告音。ここで、statusボタンを押して警告音を殺して暫し待つ。
崩壊モードで起動しているので、192.168.0.200（←ココ重要）がアクセス先になります。
崩壊モードの管理画面に入れず。invalid なんたらエラーが出たら、最上段に残したHDDがハズレです。他のに入れ替えてやり直し。
崩壊モードで入れたら、諸諸設定してHDDを全部入れてraid再設定。
ここでOKすると、正常位に戻ってしまう（←ココ重要）ので、平時に設定したIPアドレスでアクセスします。
あとは、買ったときの新鮮な気持ちで全部やり直し。
※崩壊モードは最上段HDDに当たり外れがある（理由はわからん）。
※崩壊モードはアクセス先が平時とは変わる。
※崩壊モードを抜けると平時のアクセス先に戻る。
以上です。
