The color table is based on that of X11 RGB file, usually located in /usr/lib/X11/rgb.txt.
前フリ プログラマのみなさんならキーボードにこだわりを持ってなおかつタイピング速度を0.01秒でも稼ぐために日夜キーバインドを研究されていることと思います。 そんな私は Windows では AutoHotKey、Linux では Xmodmap、Mac では KeyRemap4Mac を愛用しております。 新しい環境や新しいキーボードが手に入ったりするとまずはキーボードの設定から、という方も多いのではないでしょうか。 私は HHK を長年愛用しており、新しいコンピュータを購入したら何はともあれコイツをつないで、キーバインドの設定からはじめます。 PFU Happy Hacking Keyboard Professional2 墨 英語配列 静電容量無接点 USBキーボード Nキーロールオーバー UNIX配列 WINDOWS/MAC両対応 ブラック PD-KB400B 出版社/メーカー:
コマンドライン形式の文字列を受け取って解析し、要素の集まりを得る処理を行いたい場面が存在するが、手動で行うのは面倒で、正確でない場合もありうる。 ここでは、Pythonの標準機能とGLibライブラリのそれぞれにおいてこの処理を行ってくれる関数についてを扱う。 元の記事は2010年1月に書かれたが、大幅に内容を書き直しており、GLibについての解説と例を追加している。 PythonGLibC言語での使用例Vala言語での使用例Python文字列オブジェクトのメンバ関数split()はスペースやクォートを含んだコマンドライン文字列を意図した通り(クォート内をひとまとめにしてその中のスペースでは区切らない)に区切ってくれない。 そこで、shlex.split()関数を用いて文字列を渡すことでスペースやクォートがうまく処理され、リスト型の戻り値として要素の集まりを得ることができる。以前試したときに
Ubuntu 12.04を利用している時、キーバインドの変更(例えばCaps LockとCtrlの入れ替えなど)は、.Xmodmapファイルをホームディレクトリに配置するだけで対応できてきた。 で、最近インストールしたUbuntu 14.04では、この方法では変更できなかった。 で、いろいろ調べていくと、Xmodmapは事実上の廃止状態で、Ubuntu 13.10以降ではxkbを利用するのが正攻法ってことらしい。ので、xkbでキーバインドを変更する方法を色々調べてみた。 xkbで設定を行えば、X window上で動作しているすべてのアプリに設定が反映されるので。 Caps LockとCtrlの入れ替え程度であれば、xkb以外にも方法があるのだが、xkbを使う方法では、「;キー」にenterキーを割り当てるなど変則的な対応もできるのが魅力。 変更は次のように行う。 xkbでキーバインドを変更
IBus MozcとFcitx Mozcの開発状況 インプットメソッドをIBusからFcitxに切り替えることにした。GNOMEと相性がいいことからIBusを使い続けてきたが、MozcのFcitx版(fcitx-mozc)がArch Linuxの公式リポジトリに登録されて久しいことや、以前の記事にも書いたが、ibus-mozcがそのうち廃止になるっぽいこと [1] 、Ubuntu 15.10でもデフォルトのIMがFcitxに切り替わったこと [2] 、とかを考えると、そろそろFcitxに切り替えようという気になった。こんな状況になっては、IBusを使っているのが悪あがきに思えてきた。 以前、Fcitxを使ってみたことはあるが、結局IBusにもどしてしまった。今回は、もうIBusに戻さないことに決めて、IBusとibus-mozcのアンインストール、及びFcitxとfcitx-mozcのイン
2018/7/18 追記 3.10.0-862.9.1.el7 で fix されました hiboma.hatenadiary.jp 2018/7/4 追記 最新の情報はこちらにまとめています hiboma.hatenadiary.jp 2018/6/16 追記 CentOS Plus の kernel-plus では修正が入っています. 詳しくはこちらをご覧ください hiboma.hatenadiary.jp エントリの概要 CentOS7.5 の fsnotify() がレースコンディションを起こすバグを、 nginx + td-agent (fluentd) + in_tail プラグインで踏んだ際の調査内容を記していきます. イントロダクション このエントリを書いた時点では、CentOS 7.5.1804 以降でリリースされているカーネルは 3つありますが、カーネルの fsnotif
はい、釣りタイトルです。 はじめに自分はあくまで生粋のUbuntu(≒Unity)のファンであることを断っておきます。 Ubuntuを常用するようになってから3年以上経った先日、 Canonicalからデスクトップ環境がUnityからGNOMEに変更になるアナウンスがあり、 未だに立ち直れていないので気持ちの整理をするためにも、 感じていることを書き連ねます。 これは失恋に近しい感情だった。 まずは自分とUbuntuとの出会いから振り返ってみよう。。。 Ubuntuとの出会い Unityの素晴らしい点をあげてみる LIM(Locally Integrated Menus) MATEのファイルマネージャー Ubuntuのファイルマネージャー(nemoに変更) MATEのfirefox Unityのfirefox MATEのGedit UnityのGedit 画面左に配置されたランチャー なぜ
Linuxサーバの障害対応で社内で伝統的に使われているテクニック。I/Oで完全にブロックしているポイントを特定するノウハウ。 問題対応のため、怪しいプロセスをstraceしてみる read(2)やwrite(2)でブロックしていることを発見する read(2)やwrite(2)、connect(2)の引数にはファイルディスクリプタ番号がみえる プロセスIDとファイルディスクリプタ番号を使って、/proc//fd/ の中身をみると、ソケットI/Oで刺さっている場合はソケット番号を発見できる netstat からソケット番号でgrepして接続先を発見する [y_uuki@hogehoge ~]$ sudo strace -p 10471 Process 10471 attached - interrupt to quit read(58, <unfinished ...> Process 10
最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon この本はLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる本。この本を読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの?ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ
κeenです。雰囲気でシェルを使ってる人が多いとのことだったので少しばかり込み入った知識を。 あと一応POSIX準拠かどうかも気にしながらやっていきます。 基礎知識編 シェルの種類 まず、POSIXにシェルが定義されています。 これに最低限の機能で準拠しているものをPOSIXシェルと呼ぶことにします。いわゆる/bin/shです。具体的な実装はbsh、ash、dashあたりでしょうか。 最低限の機能以上に色々拡張されているシェルを拡張POSIXシェルと呼ぶことにします。具体的な実装はbash、zsh、kshなどでしょうか。 ここでは触れませんがPOSIX準拠でないシェルも存在してcshやtcshなどのシェルがあります。あと確か最近話題のfishも違ったような。 さて、1つ問題になるのは普段使いのコマンドラインはおおむね拡張POSIXシェルでしょうが、サーバで使うシェルやデプロイスクリプトで呼
0. はじめに 本記事は、Linuxを対象としたカーネルエクスプロイトの入門記事です。 カーネルエクスプロイトというのは、Linuxや*BSD、Windowsを始めとするカーネル自身の脆弱性を突くエクスプロイトです。 基本的にカーネルはシステム内で最高権限を持つ特権モードで動作しているので、ここを悪用されるとシステムの大部分(ほぼ全て)を掌握されてしまいます。 エクスプロイトと言うと、普通はユーザー空間で動作しているアプリケーションのバグをつく物が多いですが、これだと限られたレベルの権限しか奪えません。 SELinuxやjailを始めとする、OSレベルでの保護機構に阻まれるとたちまち効力を失ったりします。 しかし、カーネル自体の脆弱性をつくカーネルエクスプロイトを利用すると最高権限での任意コード実行が可能なため、大抵の保護機構はものともしません。 このカーネルエクスプロイトが特に効力を発揮
前回も軽く触れたけれども、automake/autoconfでビルド環境を作るのは少し面倒な印象があった。 ところが、autoreconfを使うと途中の面倒な作業を大幅に軽減できることがわかったので、メモがてら一連の流れについて書くことにする。 手順 ソースコードを用意する Makefile.amを用意する configure.acを用意する autoreconfを実行 あとは./configure && make && make install 1. ソースコードを用意する 今回は、以下のような簡単なソースコード(hello.c)からhelloという実行バイナリを作成するプロジェクトを作成する。 #include <stdio.h> int main(int argc, char* argv[]) { printf("Hello, world!\n"); return 0; } 2. M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く