rdesktop の tips - daily dayflower
Linux から Windows のリモートデスクトップ（もしくはターミナルサービス）に RDP で接続するのには rdesktop というコマンドがあります。これコマンドラインインタフェースから使うので敬遠する人も多いかも。GUI のフロントエンドとして，たとえば GNOME のターミナルサーバクライアント（tsclient）があるので，こちらを使うと使いやすい*1んですが，rdesktop のポテンシャルを 100% 生かしきれない*2ので結局 rdesktop コマンドを直接いじるのが吉です。 $ rdesktop -5 \ -g 1024x768 \ -a 24 \ -N \ -x lan \ -z \ -P \ -r disk:home=/home/dayflower \ -r sound:local \ -r clipboard \ -u dayflower \ -d WORK
KVM で PXE ブートしようとしたら難儀した - daily dayflower
KVM の場合，virt-install コマンドに --pxe オプションをつければ PXE ブートさせることができる。Xen と違って完全仮想化だから。ばんざい。 # virt-install --name=hogehoge --accelerate --os-variant=rhel5.4 \ --ram=384 --vcpus=1 \ --file=hogehoge.img \ --network=bridge:br0 --pxe \ --vnc --noautoconsoleあるいは qemu-kvm コマンドを直接叩いて network option rom を指定するという方法もあるようだ (参考, qemu-kvm の直接起動は Stray Penguin - Linux Memo (KVM-2) 参照)。 これで普通に DHCP サーバと TFTP サーバを構成していれば
Mercurial MQ について - daily dayflower
巷では git の大ブームだけど，ひさしぶりに Mercurial について書きます。 Mercurial について言及されたブログとか読んでいるとき，たまに MQ という言葉を目にして気になっていた。ながらく気にはとめつつ全然調べていなかったんだけど，ちょっと利用しようかなというケースがあり，ちょこっと触ってみた。 自分の理解では，MQ (Mercurial Queues) とは，誤解を恐れずにいえば Mercurial の changeset と独立して構成される修正履歴（パッチ）のスタックのようなものだ。 （なので今後 MQ の patch queues を Queues という名称と裏腹に「パッチスタック」「パッチ群」などと勝手に呼び称します） 「誤解を恐れずにいえば」と書いたけれど，この直感的な印象は MQ を使っていくうちに――大筋では変わらないものの――ちょっと変わった。それ
噂の SeamlessRDP を動かしてみた - daily dayflower
環境は クライアント: rdesktop 1.5.0 （ディストリビューション付属） on Fedora 8 サーバ: Windows XP Pro SP2 on VMware Server 1.0.3 on CentOS 5.1 です。 で，元記事（SeamlessRDPでXPとLinuxをシームレスに統合 (1/3) - ITmedia エンタープライズ）のとおりにやってみたんですが…… 2008年02月08日 kunumi 仮想化, linux, windows, vmware fedoraのパッケージ持ってきてやっているんだが、普通にリモートの画面が開くだけで解説の様にはできないorz。 http://b.hatena.ne.jp/kunumi/20080208#bookmark-7408374 あるある〜。最初同じようにはまりました。 で，どうも調べたところ，SeamlessRD
Capistrano で rsync - daily dayflower
Capistrano によるファイル転送手段で標準で用意されてる方法は upload や put でファイルをアップロードする（scp / sftp 経由） Git や Subversion などの SCM からファイルをチェックアウトする であり，rsync はない（と思う）。 なので，Capistrano で rsync しようと思った（あ，でも rails とか用の標準 deploy レシピで使う方法とかじゃないです; 単に task に rsync を書くだけ）。 Capfile は実際 ruby のコードなのでなんとでもやりようはある。 task :rsync_task do source_path = "/source/path/" target_path = "target_host:/target/path/" `rsync -avz #{source_path} #{ta
4096 バイトセクタの HDD と Linux - daily dayflower
先日 1TB クラスのハードディスクを買いに秋葉原へいってきました。ずいぶん安くなったものだなぁと感激しながら物色してたんですが、なぜかキャッシュ 64MB のほうが 32MB のものより安かったのでこりゃお得だろうと思いそちらを考えなしに買いました。 帰ってきて調べてみたら、買ったやつは 4096 バイトセクタのものでした。なんか Windows XP だとそのまま使うとパフォーマンスがでないとか聞いていた気はしていたんですが、まさかそれを買ってしまうとは。どうりでバッファ容量が大きいほう（つまり 4K セクタ）がどの店でも安いわけだ。 たしか Linux の場合だと大丈夫だよねと思いながら検索してみると、Linux でもパフォーマンスが落ちるという話が。うわーどうしようと思い、4096 バイトセクタ HDD と Linux についていろいろ調べてみました。 ただ、机上の調査であり実地検
CentOS で aufs (another unionfs) を使う - daily dayflower
フラッシュメモリデバイスなディスクに Linux をインストールしたい ⇒ 書き換え限度回数が心配だよ ⇒ CDROM bootable な OS にすればいいよ ⇒ システムの変更やアップデートのときが面倒だよ ⇒ read only filesystem の上にかぶせることができる UnionFS を使えばいいよ ⇒ UnionFS より aufs のほうがおすすめだよ ということで，CentOS 5.2 に aufs をいれてみました。ちなみに「やってみた」レベルのお話です。 aufs とは aufs とは，スタッカブルな「単一化」ファイルシステムです。まぁーつまり，単一ファイルツリーに複数の「ブランチ」を透過的に重ね合わせることができます。 KNOPPIX 5.1 以降で使われています。 ビルドする 残念ながら RPM パッケージは用意されてないので，CVS で最新版をダウンロード
split はデフォルトで後続する空フィールドを削除する - daily dayflower
昔々はまったことあるけど，久々に Perl 使ったらはまったので記念*1に。 sub show { print join q{, }, @_; print "\n"; } # デフォルトでは後続する空フィールドは削除される show split(/:/, 'a:b:c:::'); ### => a, b, c # 第3引数を正数で指定すると，「最大で」そのフィールド数までしか分割しない show split(/:/, 'a:b:c:::', 2); ### => a, b:c::: # 「最大で」なので，存在するフィールド数以上を指定しても空で埋めたりはしない show split(/:/, 'a:b:c:::', 8); ### => a, b, c, , , # 負数を指定すると空フィールド含めて最大限分割してくれる show split(/:/, 'a:b:c:::', -1); #
overload の rebless バグについて - daily dayflower
きちんと追いきれなかったので結構ぐだぐだです。 そもそも bless の挙動とは #!/usr/bin/perl use strict; use warnings; package FooBar; package main; my $a = { }; my $b = $a; print $a, "\n"; # HASH(0xb8002a0) print $b, "\n"; # HASH(0xb8002a0) bless $a, 'FooBar'; print $a, "\n"; # FooBar=HASH(0xb8002a0) print $b, "\n"; # FooBar=HASH(0xb8002a0) 前半はまぁいいでしょう。同じ無名ハッシュリファレンスをさしているので同じ内容が出力されます。 おもしろいのは後半です。 $a を bless しただけなのに，$b も bless され
base (< 2.14) が $SIG{__DIE__} を破壊するのではまった - daily dayflower
たとえば， #!/usr/bin/perl use strict; use warnings; local $SIG{__DIE__} = sub { warn "signal handled"; die $_[0]; }; require Foo; die "foo"; こんなスクリプトがあったとして，実行すると， signal handled at test.pl line 7. foo at test.pl line 12.みたいになる（それなりの package Foo があったとして）。 ところが，その package Foo の中身が package Foo; use strict; use warnings; use base qw( URI ); # なんでもよい のようになっていた場合。つまり，（パッケージ指定の）use base を使っているときに，実行すると， foo
Exporter を使ったモジュールの継承 - daily dayflower
おまえは何を言っているんだみたいな話だったらすみません。 たとえば，foo() という関数を export している ModA というモジュールがあるとします。 package ModA; use strict; use warnings; use base qw( Exporter ); our @EXPORT = qw( foo ); sub foo { warn sprintf '%s::foo called', __PACKAGE__; } 1; こいつをたとえば #!/usr/bin/perl use strict; use warnings; use ModA; foo(); のように使うと， ModA::foo called at ModA.pm line 12.のように出ます。 ここまでは当たり前。 use ModB したら ModA::foo() を呼び出せるようにしたい
UNIVERSAL::isa($hoge, 'Huga') を使うべきではない - daily dayflower
ことの理由と出典をいつも忘れてしまうので，メモメモ。 if ($obj->isa('Huga')) { ...... } みたいなコードはよく使うんですが，$obj が bless されたオブジェクト（か，クラス名の文字列スカラー）じゃないとエラーを吐くので，一時期，以下のように書いてました。 if (UNIVERSAL::isa($obj, 'Huga')) { ...... } でもそれはイカーン，とどこかで読んだような気がして探してたら，「続・初めてのPerl 改訂版」の「14.2 オブジェクトの動作に関するテスト（pp.186-188）」に書いてありました。 しかし，これではオブジェクト指向メカニズムを否定することになり，それはそれで問題を起こします（→脚注）。 脚注 特に，Animal がカスタムの isa メソッドを持つ場合（中略），UNIVERSAL::isa を呼び出してし
PL_check hack - daily dayflower
（あとでかく） XS くらいいじれないと Shibuya.pm に加入できないらしいので，とりあえず書きましたー。今回は実践編なので，あまりわかりやすい内容＆たいした内容ではないです。わっふるさせてごめんなさい。 ゴール #!/usr/bin/perl eval 'print "Hello ' . $ARGV[0] . '!\n"'; とか危険ですよねー*1。こんな機能があるなんてけしからん。ですので，eval の実行を抑制するモジュールを書いてみました。 というのは冗談で，eval の実行主体となる OPCODEが，システム内で「完結」してます（んーうまく表現できない）。なのでサンプルとしていじりやすく，この題材をとりあげました。 評価型 eval はどのような OPCODE に変換されるのか まずは単純なコードを書いて，OPCODE がどのようになるのかたしかめてみます。 use st
ファイルハンドルをめぐる冒険（ただしマニア向け） - daily dayflower
以下は Perl 5.8.8 のソースを元に記述しました。Perl 5.10 でもそう変わってはいないと思いますが，結構内部が変更されているので違うかもしれません。大まかには同じだと思います。 イントロダクション Perl でのファイルハンドルは内部的には [http://search.cpan.org/perldoc?IO::Handle:title=IO::Handle] オブジェクトとして保持されています。そのような記述は perl5004delta くらいでしか見つかりませんでした。ラクダ本にもなかったような。 Internal change: FileHandle class based on IO::* classes File handles are now stored internally as type IO::Handle. The FileHandle module
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
