twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ

ブログ

ブログ別アーカイブ l 未来のいつか l Android/OPhone雑記 l l
l アジアのペンギン l 烏龍の旅 l 第三のペンギン l TOMOYO Linux l

 

新着記事



状況に埋め込まれた学習

われわれは学習というのを学校制度の中のかぎられた活動という風にとらえがちである。もちろんそんなことはない。わたしたちは日々の生活のなかで、あるいは仕事の中でなにがしかを常に学んでいる。学び続けている。 単に形式化され言語化された知識を獲得することが学習なのではない。 徒弟制度のような非熟練者が熟練者のもとで作業に参加することによって技術を習得していく方法について焦点を本書はあてている。 ソフトウェア開発コミュニティへの参加ということが、オープンソースの発展によって、より開かれた形になり、一つの企業に属さなくても自由にできるようになった。ごく限られた範囲でしか見聞き出来なかったソフトウェア開発のベストプラクティスがオープンソースコミュニティによってインターネットを介して自由に流通している。 その事例を間近で見聞きするにつれ状況に埋め込まれた学習の有効性を確認することができる。 本書の訳者あとがきで、本書の立場(正統的周辺参加論、以後LLPと略す)と従来の教育論とのはっきりことなる点を以下に上げている。(1)学習を教育とは独立の営みとしたこと。(2)学習を社会的実践の一部であるとする。(3)学習とは「参加」であるとする。学習によって人は何かに貢献する、行為する、という「する側」にたち、「される側」/「見る側」ではない、ということである。(4)学習はアイデンティティの形成過程であるとする。すべての学習がいわば、「何者かになっていく」という、自分づくりなのであり、全人格的な意味での自分づくりができないならば、それはもともと学習ではなかった、ということである。(5)学習とは、共同体の再生産、変容、変化のサイクルの中にあるとする。(6)学習をコントロールするのは実践へのアクセスであるとする。 LLP的な立場から勉強会やオープンソースのコミュニティの方法論を整理しなおすと、自分の向かおうとしていたことが極めてすっきりと表現されているように感じる。コミュニティには、学習の機会、参加の機会があり、そこに参加することによって自らを成長させていく機能が備わっている。 コミュニティの中に熟練者(マスター)を見出し、そこに弟子入りする。マスターの所作から一つ一つ技量を学んでいく。それはまさに社会的な実践であり、参加であり、アイデンティティの形成であり、コミュニティの再生産、変容、変化のサイクルにある。マスターが初心者を導くのは実践へのアクセスである。本当の現場であり、そこでのリアルな問題をリアルに解いていくことをアクセスさせる、それがマスターの役割である。 われわれが、勉強会やオープンソースのコミュニティに向かうのは、そこには状況に埋め込まれた学習の場があり、自分の成長の機会とアイデンティティの形成の過程があるからなのかもしれない。 ソフトウェア開発の技量を高めたい若者が、勉強会にその道の達人を探しに行き、コミュニティの門を叩くのは、そこが現代の徒弟制度として機能しているからなのではないだろうか。...
続きを読む...
 

LinuxCon Japan ビデオ公開

お久しぶりです。syoshidaです。 先月六本木ヒルズで開催されたLinuxC...
続きを読む...
 

メッセージパッチ投稿準備

伊藤 @ NTT OSS センタです.

LinuxCon Japan 後の懸案だったメッセージ ID パッチの更新ですが,(1) mPediaの経験ある方に,メッセージからソースが探しづらいよい実例を,(2) gcc に詳しい方に,va_list のスキャン中にNULLポインタを踏んでしまう原因追求をお願いしたく,投稿しました.

パッチの現状は,次の通りです.以下を完了しています.

・開発者のメリットをうたった文面の強化

・RAS機能,メッセージ辞書での有用性への言及

まだできていないのが,

・どういうときにメッセージが探しづらいのかを示す実例

・vnsprintfの"%vP"への対応

です.後者は,コードは書いたのですが,可変引数の処理でパニクる原因調査に手こずっています.

---

---->8------>8------>8------>8------>8------>8------>8------>8--

What is it?
-----------

This patch provides an optional enhancement to printk(), configurable
by CONFIG_PRINTK_MSGID, to print crc32 value of format strings with
kernel messages.

TBD: MSGID is a misnomer, because they may not be unique by design.

Rationale
---------

Printk and vprintk in combination with C macros allow kernel
programmers to write kernel messages in flexible ways, while
that flexibily sometimes cause system administrators or even
kernel hackers spend repeated guess works to find an exact
place where a kernel message comes from. For example,

A hash value of format string, if choosen appropriately,
helps narrowing down number of places to look for, and with
modified ctags/etags like facility, allows fast access to
candidate lines from a value. An obvious alternative is
a pair of __FILE__ and __LINE__, which we didn't feel good
enough because we are concerned about additional kernel memory
requirement for each macro expansion, and because __LINE__
changes at nearly every release/RC. Since contents of message
formats less likely to change than their __LINE__ counterpart,
it is more useful in situation where we have to deal with
multiple versions like bisecting.

It can also help enterprise users of Linux by making it
easier for developpers of RAS features to parse kernel
messages and providing a visible key to index a message
catalogue that assists end users in deciding first action
when things go wrong.

Given their enough uniqueness, the hash values might also be
used as compressed strings to store more messages in the dmesg
buffer if vast majority of the format strings occupy much larger
space than their id counterparts, although the current proposal
does not pursue this possibility.

The ultimate solution for all of these would be to make
kernel messages better, one by one, that isn't a very
easy task to say the least. So we propose this patch as
a non-perfect, yet practical work around.

Implementation
--------------

We have decided to implement it in (v)printk, so that it works without
requiring any changes to callers of the function. Previous attempts at
solving similar problems used macros to wrap printk around.  One still
had to rewrite printk or custom-made (v)printk wrappers to make use of
the wrapper. It is easier than rewriting messages themselves, but the
problem is that there are more than 70,000 printk's in the kernel
and it is unpractical to believe that all maintainers is willing
to modify their code for that.

There are a couple of places where we can implement our proposal:
- a configurable macro replacement for (v)printk or its implementation; and
- configurable code section in vprintk a la printk_time.

Macro replacement of (v)printk is the most flexible and allow for
any other substitutions
An if clause in vprintk like printk_time yields the simplest implemention,
and one can expect uniform behaviour from all the invocations of (v)printk.

Hash values are computed at run time.  While compilation-time calculation
would be useful for embedded system where we would be able to substitute
hash values for format strings in kernel binaries, it does not work in
the cases where the format argument to (v)printk is a variable.

To identify a vprintk invocation fairly uniquely, we decide to use
CRC32 value of format string.  With more than 70,000 instance of
printk's in the linux kernel, CRC16 is deemed to cause too small
as a starting point.

Patch
-----

The patch comes in two parts, i.e.
- Calculate and print CRC32 of format string in printk.
- An additional lib function to extract a format string corresponding to %pV.

The second part is a work-in-progress and known to cause
null pointer dereference when it hits a %pV.  I suspect
the culprit would be rescanning of va_list and/or use of va_copy(),
but am still unable to identify the exact nature of the problem.

diff --git a/kernel/printk.c b/kernel/printk.c
index 2531017..067f768 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -39,6 +39,7 @@
 #include
 #include
 #include
+#include
 
 #include
 
@@ -566,6 +567,13 @@ static int printk_time = 0;
 #endif
 module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
 
+#if defined(CONFIG_PRINTK_MSGID)
+static int printk_msgid = 1;
+#else
+static int printk_msgid = 0;
+#endif
+module_param_named(msgid, printk_msgid, bool, S_IRUGO | S_IWUSR);
+
 /* Check if we have any console registered that can be called early in boot. */
 static int have_callable_console(void)
 {
@@ -791,6 +799,30 @@ asmlinkage int vprintk(const char *fmt, va_list args)
                 printed_len += tlen;
             }
 
+            if (printk_msgid) {
+                const char *use_fmt;
+                struct va_format vaf;
+                va_list use_args;
+                u32 crc_fmt = 0;
+                char *tp;
+                char tbuf[16];
+                unsigned tlen;
+
+                /* use format string in va_format in case of %pV */
+                vaf.fmt = fmt;
+                vaf.va = &args;
+                while (vget_format(vaf.fmt, *vaf.va, &vaf))
+                    ;
+
+                /* or, min(strlen(use_fmt), MAX_CRC_LEN) */
+                crc_fmt = crc32(crc_fmt, vaf.fmt,
+                        strlen(vaf.fmt));
+                tlen = sprintf(tbuf, "(%08x): ", crc_fmt);
+                for (tp = tbuf; tp < tbuf + tlen; tp++)
+                    emit_log_char(*tp);
+                printed_len += tlen;
+            }
+
             if (!*p)
                 break;
         }
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 69a3266..3f7e4a3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -9,6 +9,15 @@ config PRINTK_TIME
       operations.  This is useful for identifying long delays
       in kernel startup.
 
+config PRINTK_MSGID
+    bool "Show message id on printks"
+    default n
+    depends on PRINTK
+    select CRC32
+    help
+      Selecting this option causes message id to be
+      included in printk output.
+
 config ENABLE_WARN_DEPRECATED
     bool "Enable __deprecated logic"
     default y

--------(part 2: An additional lib function to extract a format string corresponding to %pV)--------
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index edef168..e208216 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -223,6 +223,9 @@ extern char *kasprintf(gfp_t gfp, const char *fmt, ...)
     __attribute__ ((format (printf, 2, 3)));
 extern char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
 
+extern int vget_format(const char * fmt, va_list args, struct va_format *p)
+    __attribute__ ((format (printf, 1, 0)));
+
 extern int sscanf(const char *, const char *, ...)
     __attribute__ ((format (scanf, 2, 3)));
 extern int vsscanf(const char *, const char *, va_list)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7af9d84..8ef3be6 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1909,6 +1909,127 @@ EXPORT_SYMBOL_GPL(bprintf);
 #endif /* CONFIG_BINARY_PRINTF */
 
 /**
+ * vget_format - Parse a format string and place format string and
+ * its va_list corresponding to %pV in va_format if there's one.
+ * @fmt: The format string to use
+ * @args: Arguments for the format string
+ * @fp: A pointer to va_format to store results
+ *
+ * The format follows C99 vsnprintf, except %n is ignored, and its argument
+ * is skiped.
+ *
+ * The return value is 1 if a recursive format is found, 0 otherwise.
+ */
+int vget_format(const char *fmt, va_list args, struct va_format *fp)
+{
+    struct printf_spec spec = {0};
+    int res = 0;
+    va_list use_args;
+
+    va_copy(use_args, args);
+
+#define consume_arg(type)                        \
+do {                                    \
+    if (sizeof(type) == 8) {                    \
+        unsigned long long value;                \
+        value = va_arg(use_args, unsigned long long);        \
+    } else {                            \
+        unsigned long value;                    \
+        value = va_arg(use_args, int);                \
+    }                                \
+} while (0)
+
+    while (*fmt) {
+        int read = format_decode(fmt, &spec);
+
+        fmt += read;
+
+        switch (spec.type) {
+        case FORMAT_TYPE_NONE:
+        case FORMAT_TYPE_INVALID:
+        case FORMAT_TYPE_PERCENT_CHAR:
+            break;
+
+        case FORMAT_TYPE_WIDTH:
+        case FORMAT_TYPE_PRECISION:
+            consume_arg(int);
+            break;
+
+        case FORMAT_TYPE_CHAR:
+            consume_arg(int);
+            break;
+
+        case FORMAT_TYPE_STR: {
+            const char *skip_arg = va_arg(use_args, char *);
+            break;
+        }
+
+        case FORMAT_TYPE_PTR:
+            /* recursive format */
+            if (fmt[1] == 'V') {
+                struct va_format *vp = va_arg(use_args, void *);
+                fp->fmt = vp->fmt;
+                fp->va = vp->va;
+                res = 1;
+                goto out;
+            } else {
+                consume_arg(void *);
+            }
+            /* skip all alphanumeric pointer suffixes */
+            while (isalnum(*fmt))
+                fmt++;
+            break;
+
+        case FORMAT_TYPE_NRCHARS: {
+            /* skip %n 's argument */
+            u8 qualifier = spec.qualifier;
+            void *skip_arg;
+            if (qualifier == 'l')
+                skip_arg = va_arg(use_args, long *);
+            else if (TOLOWER(qualifier) == 'z')
+                skip_arg = va_arg(use_args, size_t *);
+            else
+                skip_arg = va_arg(use_args, int *);
+            break;
+        }
+
+        default:
+            switch (spec.type) {
+
+            case FORMAT_TYPE_LONG_LONG:
+                consume_arg(long long);
+                break;
+            case FORMAT_TYPE_ULONG:
+            case FORMAT_TYPE_LONG:
+                consume_arg(unsigned long);
+                break;
+            case FORMAT_TYPE_SIZE_T:
+                consume_arg(size_t);
+                break;
+            case FORMAT_TYPE_PTRDIFF:
+                consume_arg(ptrdiff_t);
+                break;
+            case FORMAT_TYPE_UBYTE:
+            case FORMAT_TYPE_BYTE:
+                consume_arg(int);
+                break;
+            case FORMAT_TYPE_USHORT:
+            case FORMAT_TYPE_SHORT:
+                consume_arg(int);
+                break;
+            default:
+                consume_arg(int);
+            }
+        }
+    }
+out:
+    va_end(use_args);
+    return res;
+#undef save_arg
+}
+EXPORT_SYMBOL_GPL(vget_format);
+
+/**
  * vsscanf - Unformat a buffer into a list of arguments
  * @buf:    input buffer
  * @fmt:    format of buffer

 

Ubuntu10.04にてログインIDを表示させない

Panasonic Let's Note CF-Y5の画面表示がたまに崩れてしま...
続きを読む...
 

Twitterの書き込みをきっかけに仕事についてあれやこれや考えてみた

先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件/環境/待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の(1)良いところ(あれやこれや)、(2)悪いところ(あれやこれや)と、仮に転職するとして、その候補となる会社の(3)期待値(あれやこれや)、(4)転職するにあたっての手間暇(あれやこれや)をざっくり天秤にかけて、いまのところにとどまるインセンティブA=1-2、転職のインセンティブB=3-4で、A>Bだったらいまのところに留まるだろうし、A<Bだと転職したいという気持ちにぐぐっとなる。 求人をしている会社としては、3の期待値をどのようにあげるか、そのために、エンジニアが金銭以外で求める条件/環境/待遇などをサーベイして、実現コストが低くて、効果が高いと思われるものを実装して、3の期待値をあげ、結果としてBをあげる。 Aの部分は、それこそ、人それぞれ、会社それぞれなのではあるが、それでも一般論として、重要視したいこと、最低限必要なこと、あったらうれしいことなどいろいろある。 転職は面倒だ 実のところ、転職というのは非常に面倒で、出きることならしないですませたいと多くの人が思う。通常4の手間暇が大きいので、ちょっとやそっとのことでは、なかなか転職には踏み込めない。もちろんそれをどう感じるかは人それぞれなので、1年に一度位の頻度で転職している人もいなくはないが、例外的な人であろう。 引越しみたいなもので、引越しそのものを好きな人は別として、できれば、そんな面倒なことはしたくはないが、生活スタイルが変わったり、結婚、出産したり、あるいは、職場が変わったりして、外的要因で引越しをしたりする人もいる。それと同じで、転職も、できれば、そんな面倒なことをしないですむならしないにこしたことはないが、会社の業績が悪化して、Aが急速に減少したり(給与が下がったり、待遇が悪化したり)、あるいは、自分の興味の持っている業界が急成長して、非常に魅力的に思え、Bが上昇し、AとBのバランスが、A>BからA<Bへ移ったときに決断をしたりする。*1 Twitterの書き込みをみていると、意外と2についてあれやこれや書いている人が多い。それって、結構ブラックだよなあというような書き込みが少なくない。あるいは、1あるいは3についても、本当にささやかな願いだねえ、みたいなものが少なくない。*2 仮にこれらの条件を当たり前条件ということにする。例えば福利厚生が業界水準以上というような条件だ。この当たり前条件で、魅力的な職場を作ることは不可能ではないかもしれないが、大変難しい。 魅力的条件ってなんなんだ 問題は魅力的条件(1ないし3)というのは、一体なんなのだ、ということである。(ここで話が振り出しに戻るわけである) 共通の価値観を持つことは非常に重要で、職場の人々がそれを共有できていて、それに向かって努力しているような職場は働いていて気持ちがいい。 新卒で入社したDEC(Digital Equipment Corporation)という会社について、職場の魅力の点から評価してみよう。その当時、世界最先端の社内ネットワークがあったし、あこがれの達人も社内にはいっぱいいた。仕事を通じて学ぶことも多く、実際、自分が成長している実感もあった。社内には図書室があり、技術書、専門書も普通にあったし、JISやISOの規格書も仕事に必要であれば、購入できた。諸橋の大漢和辞典を図書室に購入してもらったこともある。自分自身は情報処理学会、ACM、IEEE computer societyの会員だったので、それぞれの会誌については自前で購入していたので、社内外の最先端の情報にアクセスすることに不自由はなかった。また、各種セミナーなどにもよっぽどのことがないかぎり自由に参加でき、ミッドナイトプロジェクトと称して、今のプロジェクト以外の作業を行うことを認めていた。(Googleの20%ルールというのは、その当時、普通にあったのである)。 10年もいた会社をなんでやめたかというと、会社の業績が急速に悪化して2が1を上回ったからである。ご承知のとおり、DECはCompaqに買収され、CompaqはHPに買収され、いま、DECという会社は存在しない。DECは今で言うところのTechnology-Centric Cultureを持った会社であった。しかしながらビジネスは下手であった。IBMは生き残ったが、DECは消滅した。 ビジネスでサバイバルできなければ、何の意味もない。その上での、魅力的な職場とは何か。(またまた話は振り出しに戻るわけである) 自分の価値観 わたしは、OSSとか勉強会を奨励する会社に魅力を感じたりして、そのために社内でも微力を投じたりしているのであるが、その向こうにあるのは、自分が成長したいという欲望だと思う。仕事によって成長し、さらに自分のレベルを高めるために、OSSや社外の勉強会に出て切磋琢磨するというイメージである。もちろん、そのようなことに価値観をみい出さない人もいるとは思う。 仕事によって成長するという観点にたてば、どの職場でもその仕事から学ぶことはあるわけで、では、この会社でしか経験できない仕事とは何か、それがいわゆる差別化要因になるのではないかということになる。 ただし、他社がOSSや勉強会に参加することを当たり前に奨励していたとしたら、それは魅力的な条件ではなく、当たり前の条件となる。わたし自身、一エンジニアとして考えると、OSSや勉強会への参加が禁止されるのではなく、奨励される社会の方が、絶対自分にとってもうれしいし、多くのエンジニアにとっても、いいことだと思うので、一企業に留まらず、それがふつーの当たり前の習慣になってほしいと思う。 つまり、よりよい職場環境を望み、それに向かって一人一人がちょっとした努力をして、ちょっとした行動を起こすことが、結果として自分の待遇を良くし、まわりの待遇をよくして、さらに回り回って自分の待遇もよくするということになる。 OSSとか勉強会を禁止する職場になんか転職したくないし。それが当たり前になれば、もっと別のところでエネルギーを使えるしね。 わたしなんかは、そーとー年を食っている(組織の中の相対的年齢分布では)ので、魅力的な職場を作るみたいなことを考えないといけない立場にあるのだけど、上記のTwitterの書き込みなんかをみて、すごい参考になる意見もあれば、これはどーかなという意見もある。 その中で、一連の@yuguiさんの書き込みは非常に参考になり、共感するところも多い。http://twitter.com/#!/yugui/status/26609377333 (次の転職先決定にあたり重視したこと1) 技術的挑戦...
続きを読む...
 

Polycom communicatorをSkype on Ubuntu 9.04で使う

Polycom communicatorは、Skypeのスピーカフォンとしては、...
続きを読む...
 

LinuxCon Japan 2010、第106回カーネル読書会、U-20プログラミングコンテスト、PHP祭りなど

先週は、LinuxCon Japan 2010から始まって、第106回カーネル読書会、U-20プログラミングコンテストの最終審査会、そしてPHP祭り(PHPmatsuri)へ参加とコミュニティ三昧の一週間だった。 英語三昧 コミュニティ三昧ではあったが、英語三昧でもあった。 LinuxCon Japanは日本で開催されるカンファレンスであるが、公用語が英語になっていて、日本人の発表も英語、当然質疑応答も、日本人同士でも英語である。キーノート以外には通訳はつかない。 昨年のLinux Symposium Japan以来の英語でのカンファレンスで、当初は英語の発表で大丈夫かという声もあったが、やってみたら、意外とどーにかなったというのが実状である。日本人にとっては、英語での発表は相当敷居が高いが、Linuxの世界では、避けて通れないのでしょうがない。 海外からカーネルハッカーが来るので、彼らとコミュニケーションをとるためには、英語以外の選択肢はない。 若い人がちらほら参加していて、わたしの希望としては、もっともっと学生の参加が増えればいいなあと思っている。 LinuxConの中日(なかび)に開催したカーネル読書会もカーネルハッカーが多数参加してくれて、昨年の第100回記念の時のように盛り上がった。来年もLinuxConが開催されるのならば、同じように行いたい。会場はGREEに、ビールおつまみはNovellに提供いただいた。GREEのふじもとさんには、会場での細かいことに大変お世話になった。ありがとうございました。 カーネル読書会での前説は昨年同様英語である。参加している学生さんたちには、積極的に海外からのカーネルハッカー達と交流するように背中をおした。英語で自己紹介するんだよー。なんでもいいから一言挨拶するんだよー。 LinuxConの最終日の懇親会で、参加していた学生に、ハッカーと話をしたかと聞いたら、まだだと言うから、Greg KHにところに連れて行って、自己紹介をさせ、カーネルハッカーになるにはどうしたらいいかアドバイスを聞いた。ドキュメントを翻訳するとか、ドキュメントを書くとか、バグを直すとか、メンテナーになるとか、いろいろなアドバイスを彼にしてもらった。英語力の必要性を多分痛感したと思う。そーゆー刺激が何かになればと思う。おせっかいではあるが。 Gregと言えば、LinuxConで、安定版2.6.35.7をリリースするのをライブデモした。リリース名はYokohamaである。前日YLUG(Yokohama Linux Users Group)のカーネル読書会に出たので、それにちなんでYokomahaと名付けた。というか、発表の前にGregがYLUGのマスコット名は何だと聞いてきたので、特にないというと、安定版リリースの名前にYLUGにちなんだ名前をつけるというので、苦し紛れにYokohamaというのは、どーだと答えたところ、Yokohamaになってしまった(笑)。ライブで、デモをしているとき、Yokohamaのスペルはあっているかとかぶつぶつ言いながら安定版をリリースしていた。 LinuxConの前日、ボランティアの皆様とJames Bottomleyを連れてハイキングに行った。英語の練習をしたいからといって、娘もついてきた。北鎌倉から円覚寺、源氏山、長谷の大仏、長谷寺などをまわった。参加した日本人のなかで、娘の英語が一番上手だったのであるが、おとーさんもがんばらなければいけないと思った。 会社の9月のお誕生日会で、若手のエンジニアを話す機会があって、hyoshiokさんは、どーやって英語を覚えたんですかというような話になって、昨年のお誕生日会でも同じ話を同じエンジニアにしたことを思いだし、なんでもいいから使えばいいんだ、というようないい加減な答えを昨年同様にした。 例えば、質問を英語でする。"I have a question. ..."だ。例えば自己紹介をする。"My name...
続きを読む...
 

Linuxニュース

【ニュース】NTTデータが独自開発オープンソース・セキュアOS「TOMOYO Linux」を公開,ポリシーの自動学習機能を備える http://itpro.nikkeibp.co.jp/article/NEWS/20051111/224444/ 【インストール完全ガイド】Ubuntu 10.04 LTS Desktop 日本語 Remix CD...
続きを読む...
 

ZABBIXを産んだAlexei Vladishev氏がやって来た。

今週、ZABBIXの産み親であり、ZABBIX SIAのオーナー社長である、Al...
続きを読む...
 

第106回カーネル読書会のお知らせ〜〜LinuxCon Japan開催記念〜〜

Tweet 毎度お馴染み流浪のカーネル読書会のお知らせです〜 昨年のLinux Kernel Summit記念カーネル読書会と同じ感じで カーネルハッカーを招いてビアバッシュを開催します。 今年は誰が参加してくれるか楽しみです〜 日時:9月28日(火)18:00開場、18:30時ころ開始 お題:あれやこれやご歓談 発表者:みなさん...
続きを読む...
 
95 / 101 ページ
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!