Linuxはｶｰﾈﾙからﾄﾞﾗｲﾊﾞを完全分離する時が来たね

1 ：12/03/12 〜 最終レス ：12/05/04

遅すぎるぐらいだが。

2 ：

分離って、なんのこと言ってるのかな？
バイナリーとしては切り離せるようになってるけど、昔から

3 ：

http://slashdot.jp/story/11/06/22/0911201/Linus-Torvalds%E6%B0%8F%E3%80%81ARM%E7%94%A8%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AB%E5%99%9B%E3%81%BF%E4%BB%98%E3%81%8F
3月31日、LinusはLinuxカーネルのメーリングリストに宛てたメッセージで
「つまり私が言いたいのは、ARMデバイス用のドライバを闇雲にLinuxカーネルに
加えるべきでないということだ」「なぜなら、それは動かないからだ。長期的に見れば、
これらの変更はメンテナンスできないゴミだ。」「カーネル内に組み込むべきではない」と述べており、
4月18日には「無意味なプラットフォームのコードが果てしない程あるというのは
問題だってことに皆気がつかなくてはならないし、唯一私にできることといったら
『直す努力を怠るようなら、お前達から離れるぞ』と言うことだけだ。最終的にはそうすることになるだろうが」と
強気な姿勢を崩していない。
ARM用Linuxカーネルを開発するLinaroのDavid Rusling氏によれば、新カーネルに対して
およそ70,000ものARMコードが追加されるのに対し、x86コードはたったの5,000程
しか追加されていないとのこと。Torvalds氏の苛立ちはもっともであると思われる。

4 ：

>>2
カーネルモジュールはカーネルとファイルは分かれていても、その特定のカーネルのバージョンに密接に依存しすぎていて
カーネルとドライバが分離しているとは言いがたい。
ファイルが分かれているだけで密接に癒着している。
カーネルのバージョンがわずかに上がっただけでもカーネルモジュールはエラーを出して読み込まない。
強制的に読み込ますオプションはあるが動く保証はないし実際に動かないことも多い。
Linuxのドライバにはカーネルのバージョンに格バージョンに対してのバイナリ互換が全く無いということだ。
おまけにソース互換すらあまりない。

5 ：

armの命令体型だと汎用的な作り込みがし難いって言ってるだけでしょ
下位互換性が無いようにしてるのは、わざとじゃないの

6 ：

カーネル空間以外からハードウェア制御なんかできたら欠陥構造だろ

7 ：

鶏肉と人形が支配するカーネル空間

8 ：

新ディストリ完全分離Linuxはまだか？

9 ：

>>6
カーネルを構成しているファイルが１つとカーネル空間で１塊は
また意味が違うと思うが。プラットホームごとに明らかに無駄な
部分がリンクされないカーネルが自動で作れればいいんじゃね？
起動時にメモリ上に読み込まれなければHDDの中にあったところで
そんなに問題じゃないと思うけどな。

10 ：

マイクロカーネル化しろとは言わんが、少しずつ分離はしていかんとな

11 ：

>>4
ドライバーのいろいろな構造体（テーブル）をカーネルのバージョンが上がるたびに
変更するんだもの、そのたびにドライバーのソースの変更が必要になる。
Windowsは嫌いだがこういう点はWindowsを見習って欲しいね。
FreeBSD系はカーネルのバージョンがちょっと上がったくらいでドライバーのソース
の変更が発生することはめったにないと思うのだが…

12 ：

互換性もったら、使い捨てになる奴が増えるんじゃないの？
そういう状態が嬉しい側？

13 ：

メンテ放棄で使い捨てになるドライバは所詮ゴミ
カーネルソースに入れる必要はないと思うけど

14 ：

ちゃんと動けばなんでもいいよ

15 ：

>>14
ちゃんと動かすためにいつまでも古いカーネルを使い続けてもいいの?
そのためにいつまでも古いパソコンを使うことにもなる。

16 ：

メンテしたくないなら、patch提供して取り込んでもらえばいいのに
見られたくない事でもしてるのかね？

17 ：

多分、自作PC板ARM搭載PCスレの延長なんだろうけど
今でも十分柔軟性があるとは思うけどね
プロプライエタリなドライバが少ないのは実装よりシェアの問題だし

18 ：

利用者が少なくメンテもされないドライバに対して
メンテ嫌ならパッチ提供って何のことだ？
ニーズのないドライバでもマージしたらカーネル維持の仕事がムダに増える
そんなアホな作業が増えたらやってられんって話だと思ったが

19 ：

その程度で、verupがどうとか言ってるのかよ

20 ：

おかしいのは、普通は一度作ってバグのないデバイスドライバにメンテは要らないだろう。
カーネルのバージョンアップと共にソースを書き直してコンパイルし直すというメンテを必要としているLinuxカーネル側の設計ミスだろうこれは。
メンテ、メンテって言っているやつバカ?
バグがないのならメンテの必要ないシステムを考えるべきだ。

21 ：

Linuxのデバイスドライバインターフェースがグダグダなのは今更だし
それとどうでもいいドライバのマージや保守は別の話だろ

22 ：

グダグダな部分を示してくれや

23 ：

LinuxってWindowsでいうフィルタドライバみたいな機能がないでしょ？
ドライバとドライバの間に入れて、別のドライバを拡張したりする奴。
OSとドライバのインターフェースがきっちり決まってるからこそ、
このように間に割り込ませる汎用の方法ができるんだよね。
Linuxだとドライバに特定の機能を追加しようとしたら
ソースコードにパッチを当てて修正という作業になる。

24 ：

>>16
> メンテしたくないなら、patch提供して取り込んでもらえばいいのに
> 見られたくない事でもしてるのかね？
だから、そのpatchを誰がメンテするんだってこと？
ドライバに関しては、カーネルのバージョンが上がるたびに
メンテしないといけない状況になる。
取り込んで終わりというわけにはいかない。
たとえ不具合がなくとも、メンテが必要。
こんなんじゃニッチなドライバはLinuxでは使えなくなっていくよね。
そもそも、>>20がいうように、メンテが必要なのがおかしい。
しっかりドライバのインターフェースを定めておけば、
カーネルがメジャーアップデートでもしない限り互換性が保てるはず。
そうなればメンテする必要も少なくなってメンテナがつかれることも減るだろう。

25 ：

カーネルのバージョンが上がってなにかドライバーに新しい機能が使えるようになったのなら
積極的にドライバーのソースを直して新機能に対応させるのだが、そうでなくただ構造体が変更に
なっただけでドライバー自体は安定動作しているのにソースコードを修正する作業が発生するのは
メンテナーにはちっともありがたくない。

26 ：

>>24
＞しっかりドライバのインターフェースを定めておけば、
＞カーネルがメジャーアップデートでもしない限り互換性が保てるはず。
なんかしらんがカーネルのバージョンがちょっと上がっただけで
ころころテーブルフォーマットを変更するんだよな。
なんか意味があって改良になっているんだろうがよくわかんない。

27 ：

もうそろそろバイナリ互換というものを
真剣に考えるときがきているのだろうな。

28 ：

この手のスレは必ずバイナリ互換という言葉が現れるな
それはいいとして
こんな所にスレ立ててまで主張したいことがあるんなら
コミュニティーとかに飛び込めばいいのに

29 ：

コミュニティって狂信者しかいないイメージ

30 ：

だからモノリシックは駄目だと言ったのに… by 20年以上前のAST教授
モノリシックでも、せめてNetBSDみたいにMI/MDを分離すべきだったな。
単なるゴチャ混ぜ、gdgdなだけのLinux kernel...
Linusも20年前と言ってることが正反対だしぃ。

31 ：

>>29
この板に張り付いて書き込んでる人達にも同じ臭いを感じるぜ

32 ：

Linusは責任とって、Linux　Foundatin出資でも、合弁会社でも何でもいいから
正式なLinuxカーネル開発会社を起業すべき。
そんで、企業サポートの名のもとに、まともなABIと完全なバイナリ互換を補償しろや。

33 ：

ていうか、UNIXから適当にパクっただけだから、そもそも設計とかして無いだろ。
あめぞうからパクった2chみたいに。

34 ：

何か開発するのに、いちいち気持ち悪い野良犬コミュニティと「延々と」付きわなきゃいけない。

35 ：

ハードウェアのほうをさ、ドライバーをいらない作りにしたらいいんじゃないの？
そしたらハードウェアメーカーもビジネスチャンス増えるでしょ。
それか、Linuxのほうが、Windowsのドライバをそのまま使える仕組みを入れればいいんじゃないの？

36 ：

どうやって動かすんだよ・・・

37 ：

>>24
はあ、いい加減なドライバー作りましたって言ってるのか？
一時、ドライバ作ります的な流れがあったんだけど、kernel方面

38 ：

>>36
ハードの方をどうにかしようとしたら、例えばアナログラジオみたいに
プロセッサなんて使いませんというくらいのものにしなきゃいけない
だろうから無理だろうけど、ドライバの無い状況を想像するのは可能。
要するにアプリが直接ハードを叩く。Xサーバーがグラフィックカードを
音楽再生アプリがサウンドカードを、ライティングソフトがドライブを
直接制御するようなことを考えれば想像し易い。
ただしアプリが占有すると困るものも多々あるので、各ハードウェア毎に
専用の制御プロセスがメーカー等から提供されて、それらがプロセス間
通信でやりとりしながら協調動作する形に落ち着く。
それなんてマイクロ（ry

39 ：

インターフェイス固定したらメーカーがバイナリでドライバ配布したり
カーネル開発スタッフのヒエラルキーも崩れてしまうんではないの？

40 ：

別にバイナリでドライバ配布悪いことじゃないだろ

41 ：

それ言うと、ライセンスどうたらの流れになるような

42 ：

>>38
＞要するにアプリが直接ハードを叩く。Xサーバーがグラフィックカードを
＞音楽再生アプリがサウンドカードを、ライティングソフトがドライブを
＞直接制御するようなことを考えれば想像し易い。
それをしたくないからドライバーあるんじゃないの。
たとえばサウンドカードなんて無数にあるのにアプリが全部対応できるわけない。

43 ：

>>40
Windowsがそれやってるな

44 ：

なんか>>1とその取り巻き？か自演が壮大な勘違いしているスレに見えるけど・・・
kernel.orgで行われていた議論の論点と、滅茶苦茶ずれてる。
というか、ほとんど関係のない、勘違い話してる。

45 ：

>>44
おいおい、kernel.orgの議論なんて知ったこっちゃないさ。当たり前だろ
それ程面白くないしタイトル見て分かる通りこのスレはネタスレだから

46 ：

まともな議論できるような人はこっちに来ないよね。

47 ：

すまん、先週の2回前のカーネルアップデートから
(なんかワイヤレスLANがらみに手が入ったようなんだが)
うちのPCのRHINE2(NIC)がIRQエラー吐きつづけている。
これってやっぱカーネルにドライバがはっているせい?
RHINE2のドライバのソースは2003年製で
そのあと更新されている形跡がないのだが。
もはやコンパイルが通らない。
どうしたものか…
まぁ、使ってないからいいんだけど
syslogがうざくて。
[ 19.627065] via-rhine 0000:00:12.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 19.627408] via-rhine 0000:00:12.0: eth1: VIA Rhine II at 0x*******, xx:xx:xx:xx:xx:xx, IRQ 23
...
[ 5683.476022] Polling IRQ 23
[ 5684.476020] Reenabling IRQ 23
...
Message from syslogd@localhost at Mar 16 16:38:01 ...
kernel:[ 5743.020899] Disabling IRQ 23

48 ：

>>47
日本語でおけ

49 ：

>>47
ここ質問スレじゃないよ。

50 ：

>>47
今まで使えているデバイスドライバを使い続けたければ
カーネルは更新してはいけない。
こういうトラブルが嫌な人のために有料のLinuxの高機能ディス鳥であるWindowsが存在する。

51 ：

>>47
解決と言うか、オンボNICならBIOS等でDisableにしちゃうとか。

52 ：

>>51
それだっ!!。なんで気づかなかったんだろ。
つーかこのマザボは、もともとカーネル更新の度に
NICのドライバをコンパイル・インスコするのが面倒で
普通に認識されるの別の1000円蟹NIC差してたんだった。
忘れてたよ。
でもここ数年は知らんうちに両方のNICが動くようになってて
カーネルに取り込まれたのかねぇとか思っていたんだけど。
ありがとね。
まぁ、近々マザボ交換する予定なんだけどね。
さて、今度は(チップセット)ドライバのおかげでマザボの交換だけするか
OSの再インストールにするか悩みどころだよ
カーネルとドライバの分離ってありかもしれんね。

53 ：

kABIも知らんのか

54 ：

>>53
それ、RH厨しかしらない専門用語

55 ：

要するに、誰もメンテしなくなるようなドライバを
Linuxカーネルに入れるなってことだろ？
昔のGPUドライバ。今メンテされてないよね。
GPUドライバもカーネルに入れるべきではないんじゃね？

56 ：

例えばUSB4.0なんてものができて
いち早くそれに対応した、無名のメーカーがある。
将来このメーカーはUSB4.0で大きくなるかもしれないが、
Linuxは大きくなるまで、サポートしないわけだよね。
だって他のメーカーが製品作って、すぐ誰も
メンテナンスしなくなるかもしれないじゃん。
リーナスの考えは、Linuxは新しいデバイスに対応しないって
悪い流れを更に推し進めるものになるよ。
Linuxは新しいのも古いのもメジャーなもの以外は対応しない

57 ：

デブ専のステマか

58 ：

>>55
>>3の話？
ぜんぜん違うよ。
これは元の報道自体が説明不足でミスリーディングしてんだけど、
Linusが問題にしていたのは、ARMの組み込み用のSoCがたくさんあって、
そのSoC専用の、主にペリル用の、コード群を、抽象化して共通化せずに、
SoC毎に別のドライバとして提供されたのを、マージしようとしていたこと。
組み込みCPU作った奴らのコードが場当たり的で、抽象化が甘いから起きた問題。
Linuxカーネル構造の固有の問題じゃないし、kernel.orgの体制の不備でもない。
指針ドキュメントが不足していたということは言えると思う。
Linusはトサカにくると言葉が荒くなって説明が下手になるのも祭りになる原因の一つだが。

59 ：

>>58
えっと、ARMで抽象化は無理だよ。
ARMってのは、基本はあれど、それに対して
無限にあるいろんな拡張を施して製品にする。
だから製品毎に全く違うものが出来上がる。
http://pc.watch.impress.co.jp/docs/2009/0312/hot601.htm
　逆にARMのビジネスは、差別化の戦略にある。同じARMコアを採用していても、
A社の最終製品とB社の最終製品は互換性を持たない。ライセンシーごと
、あるいはプラットフォームごとに差異化された世界だ。
たとえばTIのOMAP用に書かれたソフトウェアが、NVIDIAのTegraでそのまま動いたりはしない。
もちろんプロセッサコアが同じアーキテクチャだから、注意深くプログラミングすれば、
他社のプラットフォームで動作するソフトウェアを制作することは不可能ではないが、
それはSoCに集積されたDSPやその他のI/O機能を利用しない、非効率なものになってしまう。

60 ：

よくわからないけど
その細かい差異を吸収して互換性を高めるためにOSを載せるんじゃないの？
同アーキテクチャ内の製品ごと柔軟に対応するためになるべく象徴化するわけで
もしも組込み等で独自の機能を使いたければソフトウェアの提供側でソースを修正するか、
それこそ独自のファームウェアでもいい

61 ：

>>60
PCってのはPC互換機とも言われるように、
ハードウェアレベルで細かい差異を吸収している。
ARMではそれがない。
だから、PCとCPUが同じだけどアーキテクチャが
違うものとして、昔NECのPC-98シリーズってのがあったけど、
ARMはそれと同じで、A社製ARM、B社製ARMといくつも
違うものが存在する。
それを単一のOSでサポートするならば、A社製アーキテクチャ、
B社製アーキテクチャって、アーキテクチャごとに対応しないといけない。
互換性がないのだから、ARMというくくりで一つにはできない。

62 ：

ドライバーはそもそも互換性なんてない。
周辺機器ごとに違う。

63 ：

>>59
コード見ればわかるけど、そういうレベルじゃないんだよ。
出来る抽象化が行われてないコードがマージされようとしていた。
ドライバにすべき部分がもっとコアの部分のパッチになっていたり。

64 ：

>>61
MicrosoftのSoCは固定してサポートする方針だけど、
>>61で言うようなレベルじゃないコードがマージされようとしていた。

65 ：

具体的に言えば？

66 ：

そのためのデバイスマッパーへの対応だろ？armはplatform device をから切り替えようとしている

67 ：

をからってなんですねん

68 ：

機械じゃないんならそれくらい読んでやれよ
日本語って難しいですね

69 ：

おからの煮物はおいしい

70 ：

だからカーネル開発会社作って、責任持ってバイナリ互換と企業サポートをやれよ。
コミュニティはグダグタ、ソースはごちゃまぜ。　誰も根本的な設計ミスを認めようとしない。
そこらのゴミかき集めてもゴミの山にしまならない。
臭いから、一から作りなおせよ。

71 ：

適当にパクるだけで、マトモに設計しないのがGNUなのか？
リリース前にDRぐらいしてんだろうな？

72 ：

ボットのつぶやき : A fool and your money are soon partners.

73 ：

お受験の幼稚園児みたいなのが騒いでるな

74 ：

リーナスが標準の書き方と
サンプルを用意しないからコいうことになる。
いい加減その場のノリで修正するのではなく
修正が入らないような設計に変更しろ。
ドライバは、どのバージョンのどのディストリの
Linuxでも共通に使える。が原則だ。

75 ：

ソース読めません状態がなんか言ってるな？

76 ：

一生懸命、LINUXを悪く言おうと必死なのが哀れみを誘う。
職を奪われたプロプラ系元開発者か、簿給でコキ使われているネガキャン要員か

77 ：

根本的な部分は十分標準化されてるでしょ

78 ：

カーネル更新するたびに
毎度毎度修正がはいって
互換性がなくなるようなものの
どこが標準化されてるって？ｗ

79 ：

>互換性がなくなるようなものの
?

80 ：

なんでLinuxは毎度毎度再コンパイルが必要なんだろうねｗ

81 ：

脳内linuxでも使ってるのか？

82 ：

>>80
> なんでLinuxは毎度毎度再コンパイルが必要なんだろうねｗ
え？

83 ：

Linuxカーネルのモジュールは後述する互換性の問題から、
カーネルがリリースされる度にリビルドする必要がある。
モジュールのビルドはカーネルソースコードに含まれる
デバイスドライバに対するものとカーネルソースコードに
含まれない外部のカーネルモジュールに対するものの2通りあるが、
いずれもカーネルビルドのインフラを利用している。
通常、カーネルソースコードに含まれる一部のデバイスドライバは
カーネルコンフィグレーション(Kconfig)にてカーネルに直接静的リンクするか、
もしくはモジュールとして構築するかのいずれかを選ぶことができる。
モジュールとして構築することを選択した場合、カーネルソースのMakefileには
modulesというターゲットが存在し、予めこのディレクトリでカーネル
（に直接関係し、カーネルイメージの生成前段階のファイルvmlinux）を作成した後、
このmodulesターゲットを実行する事でモジュールのビルドと依存関係の解決用ファイルが生成される。
そして、make installを実行すると、システムにカーネルとモジュールを同時にインストールする。

84 ：

LinuxがLKMに提供しているAPIやABIは安定したものではない。
すなわち、カーネルのバージョンが異なれば内部のデータ構造や機能に差異があり、
非互換問題を発生する可能性がある。
Solaris、WindowsといったOSでは、カーネルのAPIとABIは
比較的安定に保たれており、このような問題を回避している。

85 ：

同じソースを利用できる時点で十分標準化されてるじゃん
堅牢性を求められるからこのような規約があるわけで
君がバイナリレベルでの互換を望むならWindowsでも使ってればいいんじゃないの？

86 ：

ID:1Swu4Na5、どっかから引用している文章は引用元書けよ。

87 ：

LinuxはAPIやABIが安定してないからな。
だからドライバのメンテナンスって作業が必要になる。
それが嫌だからカーネルに含めようとするんだろう。
一旦カーネルに含まれてしまえば、自分でメンテナンスル必要なくなるからな。
しかし根本的な問題は、ドライバのメンテナンスが必要とされる頻度が
高いってことだ。APIやABIが安定してないからね。
安定させれば、ドライバのメンテナンスを必要とせずに長期間使えるが、
そうすると今度はクローズドなドライバが増えるだろう。
Linuxはこのジレンマから抜けださないといけない。
おすすめはクローズドなドライバを認めて多数採用するってことだが。

88 ：

そもそもパッチじゃないとできないことが多すぎるんだろうな。
Windowsなんか、クローズドだから故に
パッチというものはまず存在しない。
だからパッチじゃなくてもドライバだけで実現可能なように
OS自体が柔軟な拡張性を持って設計されている。
Linuxがこのレベルに到達できるのはいつだろうね。

89 ：

>おすすめはクローズドなドライバを認めて多数採用するってことだが。
なんだ、これが言いたいだけだったのか、、、
”ドライバが不安定””しばしば書き換えなければいけない”といった文言が出てるけど
具体例は一度も書き込まれず。　ネガキャンにしても読む意義の少ないレスだな

90 ：

>>88
> Linuxがこのレベルに到達できるのはいつだろうね。
難しいんじゃないか？Windowsのクローズドな所があるが故に
いくらでも誤魔化せた。Win98とNT,2kは別物なのにAPIを
極力共通化し、カーネルだけさっと入れ替えた。
さらにドライバのインタフェースまで作って、ドライバ周りの作業を
カーネルの開発の作業から外へ追い出した。これはOSSには無理。
始めから設計しておかないといけない。
もしやるなら、ドライバインタフェースのレイヤを設けて、そこで
標準化する必要がある。コミュニティにそこまでリソースを掛けられるかどうか。

91 ：

マイクロソフトはそのクローズドなドライバにすらドライバーのスケルトン
を提供してソースの一部（無償）を共有させることで全体のバランスを
保っていたと思うよ。
ハードウエアの特徴を個々に追加するのではなく、最初から拡張可能な
ゆとりがある設計は性能には繋がらない面があるがマイクロソフトは
その辺が非常に上手じゃないかとおもう。
ＮＴのビデオシステムは当初、ユーザーモードで動くサブシステムで
非常に遅かったから次期でカーネルに組み込んだ。その後もカーネルだけで
は速度が遅いのを改良するためにＤｉｒｅｃｔハードウエア関係の
拡張を繰り返してきた。
ハードウエアの抽象化とアプリケーションレベルでのハードウエア末端
の利用を同時にするのって間違った働きを完璧に検閲できないと無理
なんだろう。ドライバーを作った人がドライバーのＢＵＧ利用をさせない
為のコードを書き、パラメータの組み合わせ全てで動作を保証する
動作テストプログラムなどを同時に設計するのは金と時間がかかるんだろうね。

92 ：

WindowsマンセーをLinux板でやるところがコンプレックス丸出しなんだよ。

93 ：

マンセー・・・？

94 ：

こんなのがマンセーに見えるとか

95 ：

*BSDでできてることが、Linuxでできないんだから
OSSか企業かの問題じゃないと思うよ。
コミュニティのやる気の問題。
パクリしかできないハッカーばっかりだから、設計とかしたことないだろ

96 ：

GPLは甘え

97 ：

ほら、やっぱり。
「GPLなんてヤダ！　GNUなんてなくなっちゃえ！！」　いいたいだけなんだよ。
もうプロプラの流れには戻らんし、BSDじゃ企業間のソース共有に不公平を生む
から現在のような競合他社が切磋琢磨しながらも、互いの成果を土台にして
ともに上を目指すような流れは起きにくい。
iPad向けのミニゲーム、便利アプリ開発するにはいいんじゃない？　プロプラもBSDも

98 ：

>>95
> *BSDでできてることが、Linuxでできないんだから
> OSSか企業かの問題じゃないと思うよ。
BSDには元々そういう設計思想が入っているじゃないの？
だからマイクロカーネルのMachはBSDサーバが標準になっていた。
後から作り直そうとすると、マイクロソフトみたいな誤魔化しを
やらなければならなくなる。
まず、マイクロカーネルのバージョン（Windows NTにあたる）を開発する。
とりあえずカーネルモード、ユーザモードに処理を振り分けて、
極力ユーザモードで処理してしまうようにする。
次にカーネルとドライバとHAL（ハードウェアを抽象化する層）を
カーネルから分離した状態にして切り分ける。
最終的にドライバのインタフェースを標準化して、正式なドライバのみを
認定していく。
この作業を今からOSSでやるとすると、どれくらいのリソースが
掛かるのか？という話なんだが？

99 ：

そもそも設計とか仕様調整とか統一規格の策定とかできる奴が、
「俺が、俺が」ばっかりのOSS界隈に居るのか疑問。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Linuxで親指シフトキーボードを使う！ (201)
CCさくらヲタ用Linux (326)
chumby 3匹目 (185)
３年後のLinux情勢を妄想しよう (809)
Linux上でのフォント総合スレ 5 (270)
Linuxってなんであんなにｲﾝｽﾄｰﾙに時間がかかるの？ (101)
--log9.info------------------
小林ゆう　その44 (460)
林原めぐみファンスレ105 (928)
【アゴ】宮野真守アンチスレ7【アゴ】 (754)
岩田光央Part2 (548)
折笠愛Part11 (934)
野川さくらpart56 (350)
水瀬いのり (114)
【ﾌｧﾝﾌﾞﾛｸﾞ監視】諏訪部順一アンチスレ19【ｲｪｱ!】 (406)
沼倉愛美 part28 (776)
南條愛乃 part13 (163)
篠崎愛 (915)
幼馴染は気弱な看板娘〜川澄綾子58〜 (531)
長谷優里奈(元 落合祐里香)306 音楽業界にいる私 (276)
寿美菜子 part38 (1001)
杉田智和アンチスレ11 (424)
沢城みゆきスレ63 (134)
--log55.com------------------
BLANCA の新井ニーニャ （本スレ 9）
FABLED NUMBER Part.2
HAWAIIAN6 part28
Survive Said The Prophet Part.4
【アップルトラック】アマイワナ１
【害虫軍団】養護三銃士【ひとり】
東京初期衝動 アンチ3
【 害虫女の 】新井ニーニャ 【ダニ女】