プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

hugepageのコアダンプとれる機能を提案してみた このエントリーをはてなブックマークに追加

会社的には優先度高いらしいが、僕は最近連発でごり押しをしているので、はてさてうまくいくかどうか

関連記事
スポンサーサイト
linux | 【2008-08-28(Thu) 14:40:13】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - integrity このエントリーをはてなブックマークに追加

SCSIのセクタって実は512バイトじゃなくて520バイトなんて8バイト余分があるんだぜい。でもってそこは昔はRAIDコントローラが使ってたんだけど今は誰も使ってない。
だからそこにCRCいれたら信頼性あがるじゃーーん。というパッチ

Oracleのことしか考えてないので、アプリケーション側でCRC計算してwrite時に埋め込むことになっているので、ちょっと手間隙がたいへん。



関連記事
linux | 【2008-08-27(Wed) 05:34:21】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - CRED このエントリーをはてなブックマークに追加

カーネル内部に散在しているアクセス権チェックをまとめたフレームワークを作ろうというパッチ

- {,e,s,fs}{u,g}id
- 補助グループ
- capabilities
- secure bits

など。
FS-Cache/CacheFiles の実装に特に有効らしい。

なかなかよさそうであるが、パッチを読む時間がなかったので(ぉぃ)没に

関連記事
linux | 【2008-08-27(Wed) 04:24:39】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - Btrfs v0.16 released このエントリーをはてなブックマークに追加

Andrew Morton期待の星のbtrfsだが、ほとんどまともに動かないバージョンのリリース文だけだと記事にしようがないので没

関連記事
linux | 【2008-08-27(Wed) 04:16:21】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - mdb このエントリーをはてなブックマークに追加

なんか、kgdb対抗っぽいデバッガがポストされてたけど、 patch descriptionがオレ様がデバッガをつくったぜーーレベルで全然説明不足なので、まともな議論にもなってないし、紹介しようがない。
よって没

とゆーか、おいおい今日は4/1じゃないんだぜBoy. って誰かがコメントしててすごく印象に残っているのだが、今探したら見つからなかった。むーん


関連記事
linux | 【2008-08-27(Wed) 03:07:47】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - includeディレクトリ大変更 このエントリーをはてなブックマークに追加

今月、なぜかソースディレクトリの機種依存部のインクルードファイルがinclude/asm-$(arch)/ から
$(arch)/include/へ大移動中。
いちおう関連スレッドみたけど、正直まっとうな理由はほぼ0としか思えない。

で、理由はないけど移動しました。だけだと記事の文字数が規定値に達しないので没。

正直、ディストリのkernel-headerパッケージメンテナの心労を増やすだけで誰にとっても意味がない変更だったと思う



関連記事
linux | 【2008-08-27(Wed) 02:58:30】 | Trackback:(0) | Comments:(0)

Quicklist表示パッチ このエントリーをはてなブックマークに追加

ページテーブルキャッシュ量を/proc/meminfoで表示させるパッチがもうすぐ入りそう。Andrew Mortonは-mmで温めずにmainlineとstableに直接送るといっているので、結構すぐに使えるようになりそう。

だいたい、1GB以上平気でメモリ喰う機能が使用量見る方法がないほうがおかしかった。

関連記事
linux | 【2008-08-26(Tue) 22:20:53】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - TALPA このエントリーをはてなブックマークに追加

今月はLKMLでノートンみたいなmalware対策ソフト用インターフェースの追加をめぐって大フレームが発生していたのだが、あまりに話が発散しすぎていて論点をまとめきれずスルー

てきとうにならべると

・SELinuxは完璧だから新しいIFは不要
・ユーザー空間のマルウェア対策ソフトにバグがあると、カーネルが不安定になる設計である。
 これは設計がおかしい事を示している
・そもそもLinux用マルウェアなんて現実にはみかけないじゃん。ありもしない脅威の対策ソフトってこっけいだぜ
・Sambaのアドオンでやったらええやん
・それFUSEで出来るよ
・LD_PRELOADもお忘れなく
・なに全てのセキュリティは銃で脅すだけで解除できますよ



関連記事
linux | 【2008-08-26(Tue) 09:45:40】 | Trackback:(0) | Comments:(0)

kernel watch没ネタ集 - LVM Snapshot Merging このエントリーをはてなブックマークに追加

http://kerneltrap.org/Linux/LVM_Snapshot_Merging

LVM snapshotをオリジナルデバイスに再びマージするアレゲパッチがマージされたようだ。
アレゲさはピカイチなんだけど、LVM単位でrollbackしたい状況が一つも思いつかずに記事に出来ず。



関連記事
linux | 【2008-08-26(Tue) 09:40:36】 | Trackback:(0) | Comments:(0)

Filesystem Freeze機能 このエントリーをはてなブックマークに追加

そういえばNECさんのFS Freeze機能は結局今月号に入れられなかったな。
まあ、まだマージされてないみたいだから来月でも手遅れにはならんやろ

関連記事
linux | 【2008-08-26(Tue) 09:38:31】 | Trackback:(0) | Comments:(0)

うむ このエントリーをはてなブックマークに追加

SLUBがhackbenchで、くそメモリ喰うバグのFixがたったいまPekkaから2.6.27-rc4向けにGIT pull リクエストがとんだ。
これでSLUBがだいぶ使いやすくなったぞ

関連記事
linux | 【2008-08-25(Mon) 16:34:49】 | Trackback:(0) | Comments:(0)

kernel watchかけた このエントリーをはてなブックマークに追加

今月はやたら疲れた。。
いくつか漏れた記事があるんだけど、blogにアップするほどまとまっていないので、このまま捨てることにする

関連記事
雑談 | 【2008-08-23(Sat) 21:43:55】 | Trackback:(0) | Comments:(0)

メガネが必要です このエントリーをはてなブックマークに追加

というCMらしいのですが、眼鏡っこ属性に訴求せずにこういうCMをもってくるあたりがドイツ的か

http://jp.youtube.com/watch?v=0cbCOQAWGWg





関連記事
ねた | 【2008-08-23(Sat) 17:31:18】 | Trackback:(0) | Comments:(0)

ニューテクノロジーは伊達じゃない このエントリーをはてなブックマークに追加

http://anond.hatelabo.jp/20080821120653

こういうバカネタ最高

グーグル「行け、グーグルカー」

グーグルカー「カシャ、カシャ、カシャ」

シャア「その技術が犯罪に利用されるだけだと言う事が何故わからん?」

グーグル「お前ほど急いでいなければ人類に絶望もしちゃいない」

シャア「ならば今すぐ全人類にオプトアウトできる英知を授けて見せろ」

高木「ああグーグル、中庭が見える」



後はコレで訴訟をする人がいれば

グーグル「○○は訴訟をするような人ではなかった」

とか言えたんだけど。

あまり話を追っていないし、思い浮かばなかったので後は頼んだ。



関連記事
ねた | 【2008-08-22(Fri) 00:00:21】 | Trackback:(0) | Comments:(0)

NILFS このエントリーをはてなブックマークに追加

-mm に入りましたな。

関連記事
linux | 【2008-08-20(Wed) 22:04:29】 | Trackback:(0) | Comments:(0)

mlock() fix return values このエントリーをはてなブックマークに追加

先日Linusツリーに入れた、不正アドレスを渡したときの、mlock()の戻り値が2.6.18とheadで変わってしまっていたのを直すパッチがGregKHのstable tree用パッチ候補としてレビュー依頼メール飛んでる。
Signed-off-by ついてない+誰一人Ackしていない状態で、Andrew MortonからStableツリーに送っといたよメールが来たときはビビったが、なんとかなるもんだねー



関連記事
linux | 【2008-08-18(Mon) 09:12:01】 | Trackback:(0) | Comments:(0)

Reviewing Linux-next このエントリーをはてなブックマークに追加

ちょっと遅いけど。リンク

http://kerneltrap.org/node/16466

linux-nextの運用をめぐる議論。
現在の-nextはビルドエラー検知にしか実質使われていないのだけど quality control もするようにしていきたいよねーとかそういう話。
そうは言っても-mmですらほとんどテストされておらず rcXX に入ってからギャッと叫んでいるのにベキ論語ってもしょうがない気がする。

それか企業さんの参入待ちなんかもしれん。

関連記事
linux | 【2008-08-18(Mon) 03:31:47】 | Trackback:(0) | Comments:(1)

おまえら本当にNOPが好きだなぁ このエントリーをはてなブックマークに追加

Efficient x86 and x86_64 NOP microbenchmarks というスレッドでLinusはx86のprefix命令は遅いとか言ってるけど、ちがうよ、全然違うよ。5バイトNOP (0x66 0x66 0x66 0x66 0x90)最強だよ。
とか議論してる。

おまいら、本当にNOPが好きだなー


* Steven Rostedt (rostedt@goodmis.org) wrote:
>
> On Fri, 8 Aug 2008, Linus Torvalds wrote:
> >
> >
> > On Fri, 8 Aug 2008, Jeremy Fitzhardinge wrote:
> > >
> > > Steven Rostedt wrote:
> > > > I wish we had a true 5 byte nop.
> > >
> > > 0x66 0x66 0x66 0x66 0x90
> >
> > I don't think so. Multiple redundant prefixes can be really expensive on
> > some uarchs.
> >
> > A no-op that isn't cheap isn't a no-op at all, it's a slow-op.
>
>
> A quick meaningless benchmark showed a slight perfomance hit.
>

Hi Steven,

I also did some microbenchmarks on my Intel Xeon 64 bits, AMD64 and
Intel Pentium 4 boxes to compare a baseline (function doing a bit of
memory read and arithmetic operations) to cases where nops are used.
Here are the results. The kernel module used for the benchmarks is
below, feel free to run it on your own architectures.

Xeon :

NR_TESTS 10000000
test empty cycles : 165472020
test 2-bytes jump cycles : 166666806
test 5-bytes jump cycles : 166978164
test 3/2 nops cycles : 169259406
test 5-bytes nop with long prefix cycles : 160000140
test 5-bytes P6 nop cycles : 163333458


AMD64 :

NR_TESTS 10000000
test empty cycles : 145142367
test 2-bytes jump cycles : 150000178
test 5-bytes jump cycles : 150000171
test 3/2 nops cycles : 159999994
test 5-bytes nop with long prefix cycles : 150000156
test 5-bytes P6 nop cycles : 150000148


Intel Pentium 4 :

NR_TESTS 10000000
test empty cycles : 290001045
test 2-bytes jump cycles : 310000568
test 5-bytes jump cycles : 310000478
test 3/2 nops cycles : 290000565
test 5-bytes nop with long prefix cycles : 311085510
test 5-bytes P6 nop cycles : 300000517
test Generic 1/4 5-bytes nops cycles : 310000553
test K7 1/4 5-bytes nops cycles : 300000533


These numbers show that both on Xeon and AMD64, the

.byte 0x66,0x66,0x66,0x66,0x90

(osp osp osp osp nop, which is not currently used in nops.h)

is the fastest nop on both architectures.

The currently used 3/2 nops looks like a _very_ bad choice for AMD64
cycle-wise.

The currently used 5-bytes P6 nop used on Xeon seems to be a bit slower
than the 0x66,0x66,0x66,0x66,0x90 nop too.

For the Intel Pentium 4, the best atomic choice seems to be the current
one (5-bytes P6 nop : .byte 0x0f,0x1f,0x44,0x00,0), although we can see
that the 3/2 nop used for K8 would be a bit faster. It is probably due
to the fact that P4 handles long instruction prefixes slowly.

Is there any reason why not to use these atomic nops and kill our
instruction atomicity problems altogether ?

(various cpuinfo can be found below)

Mathieu


/* test-nop-speed.c
*
*/

#include
#include
#include
#include
#include
#include

#define NR_TESTS 10000000

int var, var2;

struct proc_dir_entry *pentry = NULL;

void empty(void)
{
asm volatile ("");
var += 50;
var /= 10;
var *= var2;
}

void twobytesjump(void)
{
asm volatile ("jmp 1f\n\t"
".byte 0x00, 0x00, 0x00\n\t"
"1:\n\t");
var += 50;
var /= 10;
var *= var2;
}

void fivebytesjump(void)
{
asm volatile (".byte 0xe9, 0x00, 0x00, 0x00, 0x00\n\t");
var += 50;
var /= 10;
var *= var2;
}

void threetwonops(void)
{
asm volatile (".byte 0x66,0x66,0x90,0x66,0x90\n\t");
var += 50;
var /= 10;
var *= var2;
}

void fivebytesnop(void)
{
asm volatile (".byte 0x66,0x66,0x66,0x66,0x90\n\t");
var += 50;
var /= 10;
var *= var2;
}

void fivebytespsixnop(void)
{
asm volatile (".byte 0x0f,0x1f,0x44,0x00,0\n\t");
var += 50;
var /= 10;
var *= var2;
}

/*
* GENERIC_NOP1 GENERIC_NOP4,
* 1: nop
* _not_ nops in 64-bit mode.
* 4: leal 0x00(,%esi,1),%esi
*/
void genericfivebytesonefournops(void)
{
asm volatile (".byte 0x90,0x8d,0x74,0x26,0x00\n\t");
var += 50;
var /= 10;
var *= var2;
}

/*
* K7_NOP4 ASM_NOP1
* 1: nop
* assumed _not_ to be nops in 64-bit mode.
* leal 0x00(,%eax,1),%eax
*/
void k7fivebytesonefournops(void)
{
asm volatile (".byte 0x90,0x8d,0x44,0x20,0x00\n\t");
var += 50;
var /= 10;
var *= var2;
}

void perform_test(const char *name, void (*callback)(void))
{
unsigned int i;
cycles_t cycles1, cycles2;
unsigned long flags;

local_irq_save(flags);
rdtsc_barrier();
cycles1 = get_cycles();
rdtsc_barrier();
for(i=0; i callback();
}
rdtsc_barrier();
cycles2 = get_cycles();
rdtsc_barrier();
local_irq_restore(flags);
printk("test %s cycles : %llu\n", name, cycles2-cycles1);
}

static int my_open(struct inode *inode, struct file *file)
{
printk("NR_TESTS %d\n", NR_TESTS);

perform_test("empty", empty);
perform_test("2-bytes jump", twobytesjump);
perform_test("5-bytes jump", fivebytesjump);
perform_test("3/2 nops", threetwonops);
perform_test("5-bytes nop with long prefix", fivebytesnop);
perform_test("5-bytes P6 nop", fivebytespsixnop);
#ifdef CONFIG_X86_32
perform_test("Generic 1/4 5-bytes nops", genericfivebytesonefournops);
perform_test("K7 1/4 5-bytes nops", k7fivebytesonefournops);
#endif

return -EPERM;
}


static struct file_operations my_operations = {
.open = my_open,
};

int init_module(void)
{
pentry = create_proc_entry("testnops", 0444, NULL);
if (pentry)
pentry->proc_fops = &my_operations;

return 0;
}

void cleanup_module(void)
{
remove_proc_entry("testnops", NULL);
}

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mathieu Desnoyers");
MODULE_DESCRIPTION("NOP Test");


Xeon cpuinfo :

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
stepping : 6
cpu MHz : 2000.126
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx tm2 ssse3 cx16 xtpr dca sse4_1 lahf_lm
bogomips : 4000.25
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

AMD64 cpuinfo :

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm)64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 2009.139
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
bogomips : 4022.42
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Pentium 4 :


processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 1
cpu MHz : 3000.138
cache size : 1024 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc up pebs bts pni monitor ds_cpl cid xtpr
bogomips : 6005.70
clflush size : 64
power management:



> Here's 10 runs of "hackbench 50" using the two part 5 byte nop:
>
> run 1
> Time: 4.501
> run 2
> Time: 4.855
> run 3
> Time: 4.198
> run 4
> Time: 4.587
> run 5
> Time: 5.016
> run 6
> Time: 4.757
> run 7
> Time: 4.477
> run 8
> Time: 4.693
> run 9
> Time: 4.710
> run 10
> Time: 4.715
> avg = 4.6509
>
>
> And 10 runs using the above 5 byte nop:
>
> run 1
> Time: 4.832
> run 2
> Time: 5.319
> run 3
> Time: 5.213
> run 4
> Time: 4.830
> run 5
> Time: 4.363
> run 6
> Time: 4.391
> run 7
> Time: 4.772
> run 8
> Time: 4.992
> run 9
> Time: 4.727
> run 10
> Time: 4.825
> avg = 4.8264
>
> # cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 65
> model name : Dual-Core AMD Opteron(tm) Processor 2220
> stepping : 3
> cpu MHz : 2799.992
> cache size : 1024 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> apicid : 0
> initial apicid : 0
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic
> cr8_legacy
> bogomips : 5599.98
> clflush size : 64
> power management: ts fid vid ttp tm stc
>
> There's 4 of these.
>
> Just to make sure, I ran the above nop test again:
>
> [ this is reverse from the above runs ]
>
> run 1
> Time: 4.723
> run 2
> Time: 5.080
> run 3
> Time: 4.521
> run 4
> Time: 4.841
> run 5
> Time: 4.696
> run 6
> Time: 4.946
> run 7
> Time: 4.754
> run 8
> Time: 4.717
> run 9
> Time: 4.905
> run 10
> Time: 4.814
> avg = 4.7997
>
> And again the two part nop:
>
> run 1
> Time: 4.434
> run 2
> Time: 4.496
> run 3
> Time: 4.801
> run 4
> Time: 4.714
> run 5
> Time: 4.631
> run 6
> Time: 5.178
> run 7
> Time: 4.728
> run 8
> Time: 4.920
> run 9
> Time: 4.898
> run 10
> Time: 4.770
> avg = 4.757
>
>
> This time it was close, but still seems to have some difference.
>
> heh, perhaps it's just noise.
>
> -- Steve
>


関連記事
linux | 【2008-08-14(Thu) 04:32:57】 | Trackback:(0) | Comments:(2)

SLUBが遅い原因がだいたい分かったような このエントリーをはてなブックマークに追加

2.6.23からデフォルトアロケータとなったSLUBであるかTPC-Cなど、いくつかのベンチで従来のSLABより遅いことが知られていた。
で、個人的には自分がhackbenchを多用することもあり、SLUBがhackbenchでしばしばSLABの10倍以上遅いのは気になっていた。
んで、LKMLで議論していたのだが、だいたい原因がわかったような気がする。

以下はhackbenchを実行した直後のmeminfoの抜粋。
SLUBのほうが1G以上余計にメモリを使っていることが分かる。メモリ消費量が大きいってのは、余計なスワップを誘発する可能性があるわけで、パフォーマンスを落とす原因になりうる


MemTotal: 7701376 kB
Slab: 123840 kB
SReclaimable: 30272 kB
SUnreclaim: 93568 kB


MemTotal: 7701376 kB
Slab: 1591680 kB
SReclaimable: 12608 kB
SUnreclaim: 1579072 kB

んで、なんでそうなるかというとslabinfoコマンドから分かって

% slabinfo
Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg
:t-0000128 28739 128 1.3G 20984/20984/8 512 0 99 0 *

128byte object用slabが28739 objectしかないのに、20984 slabつくっている。
つまりほとんど1 obj につき1slab.

これは直接的には以下のコードが原因

static inline
int lock_and_freeze_slab(struct kmem_cache_node *n, struct page *page)
{
if (slab_trylock(page)) {
list_del(&page->lru);
n->nr_partial--;
__SetPageSlubFrozen(page);
return 1;
}
return 0;
}


glibcもそうなんだけど、slubもアロケートにいくつか順序があって
1.CPU毎のオレ専用 free listを探す。これはロック不要なので超速い
2.ダメなら途中まで使っているslabを使おうとtrylock
3.全部ロックがとれなかったら新しいslabを作る

となっているんだけど、hackbenchだと競合が激しすぎてtrylockが失敗しまくり、レアイベントの予定だった3が頻発しちゃったわけだね。

なので、解決としては2と3の間にもうワンクッション、メモリを新しく確保せずになんとかがんばるメソッドを挿入できればよい。となる。
2を直接かえちゃうと、うまくいってたケースで遅くなっちゃうからね。

間違ってるかもしれないので、もうちょっとCristoph Lameterあたりと議論が必要だが、前には進んでいるのでRHEL6までには解決できるんではなかろうか。

関連記事
linux | 【2008-08-14(Thu) 00:13:50】 | Trackback:(0) | Comments:(1)

Alan Coxがあいかわらず漢らしい件について このエントリーをはてなブックマークに追加

[TALPA] Intro to a linux interface for on access scanning
というスレッドでマルウェアを検知するインターフェースをつくろーぜーという提案にたいして
セキュリティ議論になったところで出てきた一言


マシンガン持ってあなたのオフィスに押し入り、パスワードを尋ねるだけであなたのセキュリティシステムは陥落するだろうね

> Sure, but what's the point of partial security? It seems to me you're
> not secure until you're fully secure, so why bother with almost?
>
> Every bug caught with the debuggers is one caught, yay :-)
>
> Every virus let through is a pawned system, aww :-(

Every bug missed is a crash. Security is not an absolute. If I burst into
your office with a machine gun and ask you for the password your security
system probably fails ...

Security is a risk/reward model.

Alan



関連記事
linux | 【2008-08-12(Tue) 15:51:55】 | Trackback:(0) | Comments:(0)

ところで このエントリーをはてなブックマークに追加

いまどき、Web雑誌媒体で簡単に記事投稿できるのってどこなんだろうねぇ?
求めている条件は

・内容は某なんとかWatchで紹介したLinuxのnew featureの解説を深堀したような
 使い方とか、コツとかが書いてあるような記事
・当然不定期になる
・僕の低い日本語能力を考えると、校正システムがあるとなおベター
(wiki チックに読者が直せるシステムでも全然問題ない)

なのだけれど。

関連記事
雑談 | 【2008-08-09(Sat) 23:43:40】 | Trackback:(0) | Comments:(4)

完全に夏ばて このエントリーをはてなブックマークに追加

もうだめー

関連記事
雑談 | 【2008-08-09(Sat) 23:40:14】 | Trackback:(0) | Comments:(0)

聖☆おにいさん このエントリーをはてなブックマークに追加

http://d.hatena.ne.jp/m-hiyama/20080807/1218066481

檜山正幸のキマイラ飼育記 の 仏陀 vs キリスト というエントリを見ていて思い出したのだが


最近、聖☆おにいさんという漫画が超おもしろいです
まあ、ブッダとキリストが まったりとーく するだけの話なんですが。

子供にもオススメですよ・・・たぶん


関連記事
雑談 | 【2008-08-07(Thu) 17:42:40】 | Trackback:(0) | Comments:(3)

Remove the deprecated cli() sti() functions このエントリーをはてなブックマークに追加

とうとうcliとstiがカーネルツリーから削除されましたね。
まあ、さすがにイマドキ誰も使っていないと信じたい。

http://kerneltrap.org/mailarchive/git-commits-head/2008/8/6/2830514

関連記事
linux | 【2008-08-07(Thu) 17:35:07】 | Trackback:(0) | Comments:(0)

mlock の戻り値 このエントリーをはてなブックマークに追加

ある人のバグ報告がきっかけでmlockの戻り値を見直してるんだけど、Linuxのmlock周りって根本から狂ってるというか間違ってるというか何も考えていないというか。。
まあいいや。また作り直しましたパッチでキューを長くしよう。

関連記事
linux | 【2008-08-05(Tue) 01:55:43】 | Trackback:(0) | Comments:(0)

なんか業務効率が悪いと思ったら このエントリーをはてなブックマークに追加

いつのまにか部署内で係りを3つ、企画会議のとりまとめ1つで4つも割り込みが入っていた。
それぞれだいたい月イチで割り込みが掛かるから週に2日ぐらいは仕事してない計算になる。
んなバカな。

関連記事
雑談 | 【2008-08-01(Fri) 18:49:01】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。