twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ

ブログ

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

 

新着記事



知的生産の技術、梅棹忠夫著、読了、濫読日記風 2018、その18

知的生産の技術 (岩波新書)を読んだ。 大昔に読んだのだが、妙に記憶に残っている部分もあった。 約50年前(PCもインターネットもない時代だ)の知的生産の技術なので、現代にそぐわない点もあるが「学校では知識は教えるけれど知識の獲得のしかたはあまり教えてくれない」という問題設定はいまだに有効な気がする。 この50年で「知的生産」に関わる人口も増えた。かつては教員や専門職など限られた人たちだけだったが、今や、会社員はほぼ皆なんらかの形で「知的生産」に関わっていると言っても過言ではない。 仕事で文書を書く必要のある人はほぼ全て「知的生産」をしている。 本書で扱うことは広い意味での勉強であり情報生産である。 その基本的なツールとして、B6サイズのカードを紹介しているが、流石にカードを利用した情報の整理というのは流行らないだろう。ただ、手帳の使い方や、ノートやカードの使い方などは参考にはなる。情報を規格化するというのは検索可能性(情報の再利用性)をますので重要である。 読書について、創造的読書の項で、「読書においてだいじなのは、著者の思想を正確に理解するとともに、それによって自分の思想を開発し、育成することなのだ」(127ページ)としている。著者とはまったくべつの、「あらぬこと」を考えんながらよむ(126ページ)というのはまったくその通りだなあと思った。 7章で「ペンからタイプライターへ」は日本語とかな文字タイプライターなどについての記述があるが、PC時代になって、陳腐化した記述である。たった10数年で日本語入力は手書きからPCを利用したものになった(1960年代後半から1980年代前半)。 9章で「日記」について記している。ブログ時代になって、個人の記録を電子的に残せるようになった。自分という他人との文通として日記の形式で記録を残しておくことは価値がある。経験の記録をどのように記すかということはもう少し議論されてもいい。科学者は実験ログを残す。それと同様なことを、記憶せずに記録する。(189ページ) 「技術の開発の発展のためには、成果よりも、それに至るまでの経過の記録と、その分析がたいせつである。ところが、そのほうは、信じられないくらいおそまつなのである」(193ページ) 10章「原稿」、11章「文章」が紹介されている。この章は、のちに理科系の作文技術...
続きを読む...
 

禅と日本文化、鈴木大拙著、読了、濫読日記風 2018、その17

岩波書店の広報誌「図書」の臨時増刊「はじめての新書」(岩波新書創刊80年記念)は各界の著名人が自分にとっての「はじめての新書」を薦めている。そのリストを眺めるだけで楽しいし、こんな人がこんな新書を薦めているということを読むだけでも興味深い。自分が読んだことがある新書の薦め方というのも自分とは違った観点から本を薦めるという点からも興味深い。 若手気鋭の研究者落合陽一さん(メディアアーティスト)のオススメの禅と日本文化 (岩波新書)を読んだ。 本書は鈴木大拙が英米で行った講演をもとにして英文で著されたものである。1940年翻訳刊行いらい今日まで読みつがれている古典的名著である。 今回はじめて大拙の著を読んでみたのだが、自分は禅も詫び(わび)も寂(さび)も全くもって知らぬ門外漢で、その意味で日本文化について全く前提知識を持たない欧米人という想定読者に近いものだと言える。 のっけから剣道の達人が弟子に武道を教えるというエピソードが出て来てのけぞるのだが、(こんな漫画みたいなことは流石にありえないだろうとツッコミを入れながら読んだのだけど)、『禅のモットーは「言葉に頼るな」(不立文字)というのである』(7ページ)という記述にドキッとする。 禅は身をもって体験するという身体性を何よりも重視する。ここに言語化できぬものには価値がないという立場と鋭く対立する何かを見出す。理論化というものは「野球をやるときや、工場を建てるときや、各種工業英品を製造するときなどには、結構なことであるかもしれぬが、人間の魂の直接の表現である芸術品を創ったり、そういう技術に熟達したりする場合、また正しく生きる術をえんとする場合には、そういう訳にはゆかぬ」(7ページ) 禅は体験的であり、科学は非体験的であるという。 言葉は禅の妨げとなる。言葉は代表するものであって、実体そのものでない、実体こそ、禅において最も高く評価されるものなのである。(8ページ) 大拙は、禅の予備知識からはじめて、禅と美術、禅と武士、禅と剣道、禅と儒教、禅と茶道、禅と俳句を論じている。 正直言って大拙の主張を十分理解できたかとは言い難い。自分にはまだ十分な読解力(リテラシー)がない。大拙の別の著作や茶の本などを読んでみたいと思った。お薦めです。...
続きを読む...
 

自動車の社会的費用(岩波新書)、宇沢弘文著、濫読日記風 2018、その16

20世紀が大量生産、大量消費の世紀だったことを私たちは知っている。自動車がそのシンボルである。 自動車の社会的費用 (岩波新書 青版 B-47)を読んだ。 自動車の普及ほど、戦後日本の高度経済成長の特徴を端的に表しているものはないであろう。(2ページ) 本書は1974年に発行された古典的名著だ。いまなをその輝きを失ってはいない。 自分は自動車の利便性を否定するものではない。自分の意思でいつでも自由に何処へでも移動できる。その利便性を得るために自動車を所有することは各自の自由である。ことさら取り立てて議論するつもりもない。 その一方で自動車によって引き起こされる様々な問題についても知っている。自動車による事故、環境破壊など直接的なものから道路建設にまつわる様々な問題が発生することも理解している。 本書は1974年という段階で自動車の社会的費用という概念を提唱した画期的なものとなっている。 自動車の利用においては利用者は一見直接的な費用を負担しているように見えるが、道路交通網の建設費用など各種社会インフラの費用、事故による経済的損失、環境破壊など外部不経済が発生している。このうち発生者が負担していない部分を何らかの方法で計測して、集計した額を社会的費用と呼んでいる。(80ページ)...
続きを読む...
 

おてつたびでお手伝い

「おてつたび」というサービスがある。学生とお手伝いを必要とする地域とを結ぶマッチングサービスだ。若い人が少なくて困っている地域に学生をお手伝いする人として送り込む。その地域までの交通費とお手伝い中の食事と宿泊費用はお手伝いをされる方が負担する。学生は行ったことがない地域へ行けるし、地域の人は若いお手伝いをしてくれる人を得られて、双方一両得だ。 https://otetsutabi.com楽天の社会起業家を支援するプログラム、楽天ソーシャルアクセラレーターに採択されたプロジェクトの一つだ。*1 *2 *3 縁あって「おてつたび」をお手伝いしている。 楽天ソーシャルアクセラレーターは楽天社員の自主的な運営で実施されていて、活動しているメンバーは本業とは別にボランティアとして行っている。 私も楽天時代にそれに参加して、定年退職後もボランティアとしてお手伝いをしている。 地域の課題として後継者不足、労働人口の減少など、様々なものがあるが、その土地にゆかりのない学生が行くことによって、その地域のことをもっと知るきっかけになる。最初はちょっとしたお手伝いだとしても、実際に体験してみて、様々な気づきをえる。それが価値である。 地域の人も日頃接する機会の少ない若い学生と接することによって地域の価値を再発見したり、思いもよらない解決策を若い人たちから貰ったりする。 自分は楽天時代に縁のあった飛騨市の皆さん(市役所や観光協会の皆さんや楽天社員)とおてつたび代表の永岡さんをご紹介したきっかけでおてつたびをお手伝いしている。...
続きを読む...
 

#東京大学生物語 その1

9月末に60歳定年退職して、東京大学大学院情報理工学系研究科電子情報学専攻博士課程に入学した。*1 9月末より現役の東京大学生である。博士課程の大学生がどんな生活をしているのか、日記を認めることにどのような意味があるのかという疑問を持たなくもないが、定年退職後のおじさん学生の日記も多くないので自分の経験がだれかの役に立つかもしれないと思い記すことにする。 授業のことなど 9/21に入学式があって、その次の週から授業だが、自分が履修する授業は、10/1の週から開始だった。 輪講(必修)が金曜日午前中にあるので、9/28にいそいそと学校に行ったら、次週から開始ということで、いきなり空振りになってしまった。 図書館で時間を潰していたら、研究室の修士1年生のSさんが声をかけてくれたので、二人で生協食堂で昼飯を食いに行った。初ランチである。(緩募。ランチ友達) その足で会社に行って最終出社日の各種手続きをバタバタとして、満足なご挨拶もできず、失礼しました。授業の休講の告知などは事務室の掲示板に貼られるので、学校に行って確認しないといけない。ネットの情報はあることはあるのだけど基本は掲示板とのことである。学内の掲示板には様々なイベントのポスターなどが貼ってあって、告知の手段としてのポスターというのが未だに健在というのが面白い。*2月曜日に4コマ固めて履修した。1コマ105分で13回授業がある。昔は1コマ90分で13回だったのが、文科省の指導で15回になり、その後、15回だといろいろと大変なので、105分を13回になったらしい。*3 ちなみに月曜日に履修する授業のタイトルは、情報視覚化、コンピュータシステム、計算言語学、並列プログラミングである。流石に4コマ取るとお腹いっぱいになる。6限目の授業は履修していないが、社会人でも会社帰りに取れそうな時間帯だ。 授業は修士課程、博士課程共通だ。分野の話題を体系的に学べる。当たり前の話なのだけど、ウェブにある玉石混合の断片的な情報を自分で取捨選択するのとは違って専門家によるレビューを経た良質のコンテンツを一気に学べるので極めて効率が良い。密度も高い。 その分野に明るくない場合、ウェブにある情報の質を評価するのことは難しい。自学自習の限界点はどうしてもそこにある。大学教育の場合は、その質が担保されていて、最新の動向にも触れられて効率もいいし、疑問点は質問もできる。自分の娘が大学に入って親として授業料を払うときは、授業料高くて大変だなーと感じたものだが、自分の意志で大学院に入って、自前で授業料を払う立場になると、大学院の教育費というのは大変お得だなあと思う。例えば、今期は講義が4コマ、輪講が1コマを履修しているので、半期で(4+1)x13=65コマ分の講義を受けることになる。博士課程の授業料は年間520,800円(半期で260,400円)だ。1コマあたり、260,400/65=4006円。*4 もちろん、授業料だけで大学院で学ぶ価値を評価するのは愚の骨頂であるが、学びたい意欲を持っている人にとっては、それが大きな障壁になるとは言えない。むしろ社会人にとっての障壁は、学ぶ時間の確保などになる。 幾つ授業を取っても授業料は固定なので、取れば取るほどお得だ。取りすぎて研究がおろそかにならないように注意しないといけないけれど(てへ どの授業を履修するかはもちろん学生の自由である。 履修届けはウェブで行う。 本郷の学生生活 自分は学部、修士とも慶應だったので、本郷も駒場も全然土地勘がない。食堂も図書館も教室も生協書籍部もどこに何があるかよくわからない。...
続きを読む...
 

9月末で60歳定年退職しました

当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。その中で、日本ディジタルイクイップメント(DEC)研究開発センタという外資系の知名度のない小さい企業に新卒で入るというのは異例といえば異例かもしれない。本人はそんなことは全然思っていなかったのだが、世間ではそのようなことを思っていたかもしれない。実際、両親はDECのことを知らなかった。*1 DECでは日本語版COBOLプリプロセッサを作るのが最初の仕事だった。実用的なプログラムを作ったことがない新卒のプログラマにとってはちょうど良いサイズのプロジェクトだったと、いまだからこそ思う。 言語プロセッサを作るということは、言語仕様は明確に決まっているので、典型的なウォータフォールモデルになる。仕様が与えられ、それに基づいて設計し、実装する。実装するというのはコードを1行1行書くという地味な作業なのだが、新卒の頭でっかちなプログラマは、もっとカッコいい仕事があるに違いないと思い違いをしている。第二次人工知能のブームなので、そんなところで仕事があるといいなあと思っているんのだが、もちろんない。 最初にやったことは見よう見まねでコマンドスクリプトを駆使してビルド環境を作ることだった。生まれて初めてmakefileを書いた。makefileというのは、どのようにプログラムをコンパイルしてビルドをするかというルールを記したファイルなんだけれど、知っている人には冗長な記述だし、知らない人には、これでは説明にならない。 夜中の0時に、そのスクリプトが動き出すようなスクリプトを書いて、毎日夜中の0時からビルドプロセスが動くようにした。そのビルドプロセスは、当日変更のあったファイルを取り出してコンパイルするだけではなくて、ビルドしたのちに、テストツールを起動して、全テストを流すというものだった。 今でこそ、CI (Continuous Integration)すなわち継続的インテグレーションという名前で知られている、毎日毎日変更のあった部分をビルドしテストをするというプロセスだ。当時は夜中のビルドあるいはデイリービルドと呼んでいた。 夜中のビルドで、毎日毎日全てのテストを流す。プログラムの変更によって時としてテストで不具合を見つけることもある。既存のテストの場合、前日までOKだったのが、その日NGになった場合、当日行った変更が何らかの原因である場合が多い。今まで顕在化していなかったバグがその変更で顕在化する場合もあるし、純粋に新しいバグを埋め込んだということもある。 あるいは新規のテストを追加した場合、元のプログラムに変更がなかったとしても、そのプログラムに含まれていた不都合を新たに発見することもある。 さらには、まだ実装されていない部分のテストを書いている場合はNGが出るのだけど、実装がテストを追い越してしまう場合もある。 TDD(Test Driven Development)などという言葉がない時代のソフトウェア開発でも同様なことは行われていたのである。 ソフトウェア開発を機械力を使って加速する。ソフトウェア開発チームにはプロのプログラマーしかいない。プログラマは、プログラムを書くだけでなく開発環境の整備やテストプログラムも書く。 このCI環境での開発は言語プロセッサ開発でもデータベース管理システムの開発でもOSの開発でもそのプロセスは一緒だ。 DEC時代に学んだこと ソフトウェア開発のイロハを学んだ。プログラムを書いたらコード管理システムにチェックインする。そしてテストを書きテストをする。当たり前のことを当たり前にする。それの大切さを学んだ。 バグを発見したら、それを記録した。その記録が貴重な学びの場になった。どうやってバグを発見したかを記録する。テストで発見したり、たまたま発見したり、製品の場合は顧客が発見する場合もある。そのバグの原因は何かを記録する。いつバグを埋め込んだか。どのように修正したかを記録する。 自分たちが作っているソフトウェアなのに、自分たちがどのようにバグを作り込んでいるか、驚くほど知らないことに唖然とする。どのようにバグを発見しているかの知見も乏しい。 バグデータベースを作るだけでも学びの速度は加速する。最近のソフトウェア開発プロジェクトでは忘れられたプラクティスかもしれない。自ら学びの場を放棄しているようで勿体無いと思うが、実際はどうなのだろうか(実はよく知らない) Gitのようなコード管理システム、jenkinsのようなCI環境などがDECの開発現場にあった。 ソフトウェアの国際化 外資系コンピュータベンダにいると日本語版の開発というのは避けて通れない。本社で作られたソフトウェアが日本のことどころか、英語前提ガチガチで作られていたりして、米国以外では使うこともままならなかったりする。 ASCII7ビット前提とした作りになっていて、当時のUnixもひどかったし、C言語もひどかった。各国向けにソフトウェアを作り変えることをローカライズするとか言っていた。それをより一般化して、ソフトウェアの国際化という概念にしていくのが、1980年代から90年代である。 当時はUnicodeなどというものもなくて、AppleやXeroxの人たちが中心となって、1988年ごろにUnicodeの原型となるものが提案されたが、それはどう考えても使い物になるものではなく、各社のエンジニア達が様々な議論を経て、ISO 10646という形にまとめていく。 他社のエンジニア達と腹を割って議論するという経験を文字コードやソフトウェアの国際化を通じて行えたのは僥倖だった。 Oracle DECはコンピュータ業界を支配していたIBMに対する破壊的イノベーターでだった。70年代から80年代にかけてIBMのローエンド市場をPDP-11ないしVAX 11という16ビットないし32ビットコンピュータで徹底的に破壊していった。アメリカのコンピュータサイエンスの先端にはDECのコンピュータがあった。 IBMへ果敢に挑戦しているもう一つのグループが日本のコンピュータベンダー、日立や富士通だった。彼らはIBMメインフレーム互換マシンを製造していた。80年代のことだ。 IBMのようにハードウェア、OS、ミドルウェア、アプリケーションなど全てを一社で提供するベンダーを垂直統合型ベンダーという。時代は80年代に大きく変わった。PCの登場だ。 PCハードウェア、OS、ミドルウェア、アプリケーション、それぞれを提供するトップベンダーが登場した。それがIntelであり、Microsoftであり、Oracleなどである。 垂直統合型から水平分散型へビジネスモデルが大きく転換していったのだ。 自分はDECという垂直統合型の最後のコンピュータベンダにいた。IBMを破壊的イノベータとして破壊する立場の会社にいたのだが、自分の所属している会社がその波に飲み込まれるとは理解していなかった。 PCはおもちゃだと思っていた。Unix WorkstationはスケーラビリティーがないのでVAXの敵ではないと思っていた。OracleはDEC Rdbほどの性能もなければ機能もない、DEC Rdbは世界で1番のRDBMSだと思っていた。 そして、そのどれも間違いだったと90年代に気がつく。気がついたときにはDECの経営が傾いていた。 「イノベーションのジレンマ (―技術革新が巨大企業を滅ぼすとき (Harvard business school press))」という教科書に載っている通りである。 優秀な経営者が合理的な経営をすればするほど隘路にハマって行く。そして一度その隘路にはまり込んでしまうと二度とそこからは抜け出せない。イノベーターのジレンマである。 プログラマとしてDECで十分経験も積んだ。ソフトウェア国際化についての知見も少なからずある。文字コードについてもJIS(日本工業規格)の標準化委員会にも参加していた。SQL...
続きを読む...
 

GCC 7以前のAArch64ターゲットでlibgccをビルドする時に-fomit-frame-pointerを付けるとC++例外が正しく動かなくなる問題

タイトルが本記事の内容のほぼ全てです。自分で libgcc をビルドするという奇特(誤用)な人以外には関係無い話ですが(※)、まあこんなこともあるんだなと。 おそらく Linux (aarch64-linux-gnu) ターゲット等でも共通だと思うのですが、現象を確認したのはベアメタル (aarch64-elf) ターゲットで、GCC 5.1/6.3...
続きを読む...
 

clangのarm-eabiターゲットはenumが固定長

ARM の AAPCS の仕様では、enum のサイズは可変長と固定長の 2 パターン許されています。 異なるバイナリをリンクすると当然、正常動作は期待できないため、これは重要な違いとなります。 続きを読む...
続きを読む...
 

ゲーデル、エッシャー、バッハ、第20章、六声のリチェルカーレ、訳者あとがき、訳者紹介まで読了、ダグラスRホフスタッター著、濫読日記風 2018、その15

ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版を読了した。 ゆるゆるとゲーデル、エッシャー、バッハを読む会(ゆるげぶ)で読書会をしていたゲーデル、エッシャー、バッハ(GEB)を読了をした。第20章の次の「六声のリチェルカーレ」も熟読した。 GEBは章番号が付いている本編(?)と章番号がついていない亀やアキレスや蟹が出てくる部分との図と地が織りなす二重らせんの構造をしている。まるでエッシャーの絵のようだ。無限に音階が上昇していくカノンのようだ。 地の部分があるから図が際立ち、図がなければ地の存在は意味がない。 難しい本を読んでいて、理解できないところを無意識にスルーしている自分に気がついた。同じ本をみんなで読むタイプの読書会では、それぞれの人の感想を聞けるので、自分と随分違う読み方をしている、あるいはそのような読み方があるのかという発見にいとまがない。さらに担当を決めて、その章の説明を順番でするというタイプの読書会だと、ゆるげぶはまさにそのような読書会だ、自分なりに咀嚼して理解していないと説明できないので、深い理解が得られる。というか自分の浅い理解に気が付ける。 意識していなかったのだけど、よくわからないところはうわべだけを読んでスルーしていた。説明しようとして、ハタと、あれコレってどーゆーことだと理解していないということに気がついた。理解していないことに気がつくというのは意外とありそうでない経験だ。 シェパード・トーンという無限にオクターブが上がっていくように聞こえる音律(707ページ)というのを知った。そして、映画の効果音にそれが使われるとなんとも言いようのない緊張感を醸し出すということも知った。 知らないということは簡単にわかる。知らないから。だけど理解していないということに気がつくというのはありそうでない。理解しているということは誰かに説明できれば間違っていたとしても理解はしていると言えるので意識できるが、理解していないということを知ることは難しい。 理解度テストなんていうのは日常生活では、ほとんどない。説明を誤解しているなんていうことはむしろ日常茶飯事である。しかし、自分が誤解しているということに気がつくことはほとんどない。そう考えると怖い。 なんていうことを読みながら思った次第である。...
続きを読む...
 

なぜアメリカ大陸横断を列車でしたのか

いろいろな人になぜアメリカ大陸を横断したのかと聞かれる。簡単に自分なりの答えを記しておく。 今回は鉄道(Amtrak)で横断したわけだが、最終的にはクルマで横断したいと思っている。 なんでそんな酔狂なことをするのか?したいからしたいとしか言いようがないのだけど、もうちょっと言葉を重ねてみる。小田実は「何でもみてやろう」で「ニューヨークの摩天楼とミシシッピ河とテキサスの原野を見たくてアメリカに行った」と記している。当時の日本は焼け野原で「摩天楼」は無かったし、ミシシッピ河もテキサスの原野も日本にはない。だからこそ小田実はそれを自分の目で見たかったのだと思う。*1 今回、ミシシッピ河も見たし大平原のトウモロコシ畑も見た。もちろんニューヨークの摩天楼も見た。小田実の聖地巡礼をしたかったわけではない。 大陸横断するときの時間感覚をざっくり理解したかったのである。例えば、行っても行ってもトウモロコシ畑、行っても行っても山岳地帯、走ったら走ったで国内に時差があるので、時計を調整しないといけない。東部夏時間(EDT)から中部夏時間(CDT)に調整する。同様に山岳部夏時間(MDT)、太平洋夏時間(PDT)へそれぞれ進んでいく。 行っても行ってもトウモロコシ畑だ。 そんな規模感を身体性を持って理解したかった。そしてそれはクルマで大陸横断をするための予行演習に他ならない。 行っても行っても山岳地帯。 自分の知っているアメリカは仕事を通じて知っているアメリカだ。新卒で入ったDECは東海岸の大企業(コンピュータハードウェアの製造販売会社)だし、その後転職したOracleは西海岸の大企業(ソフトウェア製造販売会社)だ。東海岸に住んだこともあるし、西海岸(シリコンバレー)にも住んだことがある。アパートの契約をして、クルマを買って、銀行口座を作って小切手でアパート代を払った経験もある。その意味で一般的な日本人よりはアメリカを知っているつもりになっている。 しかし、自分は肌感覚として、都会のIT産業というフィルターを通したアメリカしか知らないということを理解している。いまの大統領を支持し投票した人々を自分は知らない。...
続きを読む...
 
3 / 92 ページ
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ

  1. Today's Linux 2018/12/03 2018年 12月 02日
  2. Today's Linux 2018/12/04 2018年 12月 03日
  3. Today's Linux 2018/12/06 2018年 12月 05日
  4. Today's Linux 2018/12/07 2018年 12月 06日
  5. Today's Linux 2018/12/10 2018年 12月 09日

Linux Foundationについて

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

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

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

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

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

乞うご期待!