FreeBSDを語れ Part38

**名無しさん＠お腹いっぱい。** · 2014/07/14(月) 05:03:19.63

さぁ語れ

The FreeBSD Project
http://www.freebsd.org/ja/

前スレ
FreeBSDを語れ Part37
http://peace.2ch.net/test/read.cgi/unix/1390323139/

関連スレ
初心者もOK! FreeBSD質問スレッドその118
http://peace.2ch.net/test/read.cgi/unix/1397057895/

**104** · 2014/08/06(水) 11:17:26.57

>>189
＞pkgngって欠陥品では・・・

pkgng はまぁ良いとしても、デフォルトで latest なのがマズイと思う。
latest はローリングリリースで数が減ったりするから、タイミングによって欲しいモノがない。
デフォルトはタグの付いたリポにしとくべきだ。
最低でも、そう変更する方法の説明があるべきだけど、それもない。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 13:22:33.96

>>191
>本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
>入れるか。
ばーか。お前は今までの話を理解してないんだな。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 13:31:10.23

>>191
もう一度問題の原因を読んで考えなおせ

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 14:58:18.55

なるほど。FreeBSDのパイプの実装がまずいわけですね。

**191** · 2014/08/06(水) 15:45:43.49

>>193,>>194
すまない、確かに自分がわかっていなかったようだ。
「gsに対するパイプへのreadをちゃんとせずにwriteするからお互いにwriteしようと
してデッドロックする」ということであっているだろうか。

これに対する修正なら確かにFreeBSD固有ではないな。ツッコミ感謝。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 15:50:41.55

read/writeのデッドロックじゃなくて、
パイプからの1回のreadで全サイズ読めないとエラー扱いにしてしまうソフトの問題かと。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 16:39:03.33

LOがらみ：
サイズに関する進展。

まず、壁は4KBじゃなく、8KB。しかも8192byteちょうどならフリーズ。8191byteならOK。
あと、これは予想されたことだが、showpage\n がファイル末尾ならどんなサイズでもOK。1文字でも余計に続くとフリーズ。

で、だ。これが不可解なんだが、write(2) で一発でパイプに書くんじゃなく、
1バイトずつ、1024バイトずつ、4096バイトずつ、小分けに書くとフリーズしない。
もちろんこの間 read(2) していない。

なぜだ？誰か名推理してくれ。あるいは次に調べること提案してくれ。
どうも FreeBSD 固有の pipe の実装にぶちあたってきた気がしてならない。

あと蛇足だが衝撃の事実。gs は標準入力を1バイトずつ read(2) してる。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 17:24:26.66

読まずに書いてしまったが、>>193と>>194はこの現象をどう思う？
>>197はどこからそう判断してるの？

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 18:28:48.13

いい感じに盛り上がってるね。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 20:46:12.80

追加情報：
EPSにはshowpageがあるのと、showpageがないか無効化されてるのがあり、
後者はgsが入力の最後までちゃんと読むので、write(2) が完了し、
サイズによらずフリーズしない。

linux (Fedora 20) で LibreOffice 4.1.3.2 を使ってフリーズさせることに成功。
ただ条件がかなり狭い。
sinx.epsみたいなのに何MBも冗長な行を追加してもフリーズしない。
write(2) は何MBも一気にパイプに書いたが、なぜ可能か不明。
画像をpnmtopsしただけの1MB超EPSに数十KB冗長な行を追加するとフリーズした。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 21:54:11.92

>>198
・showpageが途中に来る(gsc入力終了前に出力が始まる)
・8KB以上の入力
・4KB以下を一括でwrite
の三条件で発生して、
・止まるときは4KB以上のwriteがブロックしたまま停止する
ってことか。showpageの情報と分割writeの情報で一気に予測が進むね。
4KB以上のwriteではwriteから抜ける条件が全データreadされること、なのかもね。
4KB超えたらパイプバッファが足りないからreadを待って続きをwriteってのありそう。
4KB以下なら大丈夫なのは、showpageの後ろが4KB以下だからバッファへwriteして抜けれるとか。
なら多分BMPサイズが4KB以下のもセーフかも。

FreeBSDのソース読んでみようかな。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 02:47:40.62

https://svnweb.freebsd.org/base/release/9.3.0/sys/kern/sys_pipe.c?revision=268523&;view=markup
うげぇ・・・K&Rスタイルの引数指定かよ・・・
・・・よし、なんとなく把握した。202時点で想像した形と案外近かった、かな。

FreeBSDのパイプにはdirect I/Oってモード(pipe_build_write_buffer)があって、
これはカーネルにマップしたwrite側プロセスのメモリをパイプバッファとして使う。
一度にマップする量はpipe_buffer.size以下で、マップする前にバッファが空になるのを待つ。
マップするから当然、マップしたデータを全部readしてもらうまでwriteはブロックしたまま。
writeの時に残りのread待ちデータがバッファサイズ以下でもブロックするのは不味いねぇ…。

ってわけで対策考えてまとめてみた。間違ってたらごめんなさい。
・LOで出来る対策(根本治療)→横着しないでreadとwriteを並列に動かす(大事)。
・GSで出来る対策(根本治療)→showpageしても、readとwriteを並列に動かす(大事)。
・BSD User側対策(根本治療)→gscをシェルスクリプトとかで差し替え(>>144)。
・LOで出来る対策(対処療法)→writeを刻んだりシェルスクリプトを経由させたり(>>144 >>198)。

↓100%対策じゃないけど、フールプルーフになる。
・BSD User側対策(対処療法)→PIPE_MINDIRECTを上げたりPIPE_NODIRECT有効でカーネル再構築。
・BSD Kernel改良(対処療法)→direct I/Oモードを使う場合も、バッファを活用する。
　・バッファサイズを超えたwriteを抜ける時はバッファが満タンになるように、
　　pipe_build_write_bufferではpipe_buffer.size以下を全部マップせず、
　　writeの最後でuio->uio_residがPIPE_MINDIRECTかpipe_buffer.sizeになるよう制限する。
　・uio.uio_residがwpipe->pipe_buffer.size以下ならpipe_direct_writeのmsleepは
　　無限待ちせずタイムアウトからのpipe_clone_write_bufferで抜ける。
　　所詮フールプルーフだからできるだけdirect I/Oで稼ぐ為タイムアウト。

■DEFINE設定値
PIPE_SIZE：pipe_buffer.sizeの最大値。デフォ16384。
PIPE_MINDIRECT：direct I/O自動選択の条件、PIPE_SIZEより小さい。デフォ8192。
PIPE_NODIRECT：pipe_direct_writeを使わせないフラグ。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 02:48:15.69

sys_pipe.cの頭とかヘッダにも色々書いてあるけど、英語苦手なんでコード中心に当てずっぽう

sys_pipe.c(970)■pipe_write(パイプへの通常書き込み)
PIPE_NODIRECTが未指定で、io要求のバッファがユーザ空間であり、
io要求のバッファサイズがPIPE_MINDIRECT以上であり、
パイプ自身の現在のバッファサイズがPIPE_MINDIRECT以上であり、
パイプのFNONBLOCKビットが0である場合pipe_direct_writeを使うよ。

■sys_pipe.c(871)■pipe_direct_write(パイプへの直接書き込みまたは特定の通常書き込み)
/* This implements the pipe buffer write mechanism. Note that only
 * a direct write OR a normal pipe write can be pending at any given time.
 * If there are any characters in the pipe buffer, the direct write will
 * be deferred until the receiving process grabs all of the bytes from
 * the pipe buffer. Then the direct mapping write is set-up. */
■訳：パイプへのdirect I/Oまたは通常の書き込みがブロックされる可能性に注意。
パイプバッファに文字が残っていると、読み側が全部読むまでブロックするよ。
pipe_direct_writeはそれが終わったらこの書き込みの処理をするよ。
■追記：あと、これ使って書いたデータが全部readされるまでブロックするよ。
(シグナルとか？)エラーが出たらpipe_clone_write_bufferで通常バッファ戻すよ。
pipe_direct_writeの大半ははdirect I/Oの完了待機部分で、コイツが呼んでる
pipe_build_write_bufferがどっちかといえばpipe_direct_writeの本体ぽい感じ。

sys_pipe.c(770)■pipe_build_write_buffer(直接書き込みのバッファ作成)
/* Map the sending processes' buffer into kernel space and wire it.
 * This is similar to a physical write operation. */
■訳：カーネル空間に送信バッファをマップします。物理書き込みと同等です。
■追記：名前は普通パイプバッファを作る関数だけど、実際はdirect I/Oのマップ作業
write要求量がpipe_buffer.size以上ならpipe_buffer.size分だけマップする。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 04:02:36.68

す、凄い。原因究明して、かつ、複数の対策まで。恐れ入ります。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 05:23:37.04

調査乙です。バグというより互換性問題なのか。

しかしこの理由だとするとFreeBSDでしか起きない現象なのかな。本当はLOを直すのが
よさそうだけど、FreeBSD固有の問題だとLO本家が直してくれるかどうか怪しいかも。

**202-204** · 2014/08/07(木) 05:33:49.01

>>206
・gsがshowpageした後writeが終わるまでreadしない
・LOがwriteし終わるまでreadしない
のが原因だからLinuxでも再現するはず。
FreeBSDだとdirect I/Oになるとバッファサイズによらずreadが終わるまでwriteが
終わらない(実質バッファサイズが0のような挙動になる)から発症率が高いけれど、
出力画像とshowpageの後ろのゴミが両方パイプバッファサイズ以上ならOS問わず固まると思う。

**202-204** · 2014/08/07(木) 05:41:05.83

>>205-206
凄いのはパイプの挙動やshowpageやepsファイルサイズが再現性に影響する事を見つけた人だと思う。
デバッグには再現性に関わる部分に詳しいバグ報告が大事ってのをよく表すんだなぁと198みて思った。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 06:28:00.10

きちんとバグ報告までしない限り、実質的に何もしてないのと同じなので別に凄くない

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 08:07:25.31

なるほどねぇ。
刻むとフリーズしない理由も見事に説明できてる。
linuxでもフリーズする事例はできてるんだから、
LO側の対策も受け入れてもらえるでしょ。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 08:21:49.33

追記
ブロッキングなwrite(2)がブロックしやすいパイプ実装をしてしまっただけの
FreeBSDには何の落ち度もないね。
どう見ても、双方向なパイプを逐次処理で実装したLOが悪い。
GSにshowpage後に入力をclose(2)させるのは、epsだけならそうだけど、
ふつうのpsと区別できるとは思えないので困難と思われる。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 08:42:30.10

一番凄い>>209がバグ報告してくれる。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 09:42:05.70

>>212
www

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 09:48:19.24

>>212
2chはこういう他力本願のクズが多いね本当に

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 09:52:28.08

作業に絡めなかった>>209がなんか言ってる

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 10:39:53.70

>>215
絡みたくてもcもc++も読めなくて悔しかったのかもな

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 10:48:17.16

実際LibreOfficeが直らなきゃ解析した意味がないということで、>>209の書くことも一理ある

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 11:16:59.25

バグの場所わかったからってすぐバグレポート書けるわけないのを知らないの？

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 11:30:54.34

>>209ほどの人ならすぐ書けるだろ。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 12:32:42.92

調べたのを褒めてもらいたかったのにけなされて切れてる人がいる風味

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 13:01:12.27

で、調べた人叩いて何か意味があるの？けなさないと気がすまない症候群？

**202-204** · 2014/08/07(木) 22:50:32.72

>>209
わざわざそういう言い方する必要はないと思うけど、まぁそうだね。報告も超大事。
英語苦手なんでしばらく様子見するけど、FreeBSDのpipeの挙動は
進展が無い様だったらそのうち報告をBugzillaにでも投げてみるよ。
LOの方はユーザじゃない(Xすら入れてない)ので特に触る気はない。
GSの方はどうすっかなぁ…GS側はある程度仕方ない面も有りそう、
というかLOが酷すぎるから知ったことじゃない、で終わる気もするし。

>>220
誰が誰に貶されて切れてるって？

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 23:10:11.45

あんなひどいコーディングしてるのにFreeBSDにバグ報告されたら迷惑です。

**名無しさん＠お腹いっぱい。** · 2014/08/07(木) 23:32:10.06

1ヶ月たっても誰も何のアクションもしなかったとしたら何だかなあと思うけど、
今の時点で言うこっちゃない。

**名無しさん＠お腹いっぱい。** · 2014/08/08(金) 06:11:38.87

２ちゃんなんかでやっちゃったせいで報告すべきところへ報告できなくなる奴とかいるよなｗ

**名無しさん＠お腹いっぱい。** · 2014/08/08(金) 15:33:10.87

https://github.com/freebsd/pkg/issues/912

pkgコマンドで-fオプションが効かなくなった

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 01:19:55.57

linux-f10はもう終わりか
でも現状でxorg-libsとかはどうすればいいんだろう？？

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 13:54:16.96

え？ pkg search しても、f10 しかないけど。

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 16:40:35.98

脆弱性何年も放置してるから終わりだって言ってんじゃないの

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 17:56:39.15

https://wiki.freebsd.org/201407DevSummit/LinuxEmulation

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 18:13:33.64

>・BSD User側対策(根本治療)→gscをシェルスクリプトとかで差し替え(>>144)。

こっちは残念ながら gv に影響が出ました。

>・BSD User側対策(対処療法)→PIPE_MINDIRECTを上げたりPIPE_NODIRECT有効でカーネル再構築。

こっちを試してみます。 NO にすると他のソフトが遅くなる可能性がありますか？

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 19:35:22.27

あれ、今後、FreeBSD では acroread は使えないのかな？これも困るな。

===> ja-acroread9-9.4.2_1 is forbidden: No longer maintained upstream since 2013-06-26.

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 20:36:12.97

あまり使ってる人いないんだろうけど、最近clispもportsから外れてた。

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 22:33:07.35

こう言ういきなり勝手にforbiddenにするバカは氏ねって思う

**名無しさん＠お腹いっぱい。** · 2014/08/09(土) 22:57:32.58

地道に修正報告するなりしてメンテナシップ乗っ取るしかないな

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 00:50:13.67

>>233
まじか
人手不足なのかな

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 04:27:13.03

>>230
いくらfedora10でしか動かんものがあったとしても、それはさすがにもうあきらめるしかないんでないの？とオモタ
そもそもからして変化（サポート切れ）のスピードがはげしいfedoraをデフォルトに採用したのが筋が悪かったんでないかなあ？
これからなら、linux_baseが既にあるcentosに移行が現実的でないかと。Ubuntu LTSもよさそうだけど。

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 06:31:14.84

GPL3がクソなのはわかるが、GPLというだけでportsから外す動きがあるように見える。

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 13:13:36.61

GPLならportsから外すのは当然だと思うけど？

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 14:29:58.12

でもなんだかんだいって、新しめのGCCは永遠にportsから外せないような気がする
ベースシステムのツール群とかはどうにかなると思うけど

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 15:39:04.69

>>232
>===> ja-acroread9-9.4.2_1 is forbidden: No longer maintained upstream since 2013-06-26.

FreshPorts を見ると、６日前に forbidden になってる。余計なことするなよ。

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 17:24:38.28

ports なんて入れる入れないはユーザーの自由。
セキュリティとかライセンスとか気にする奴はバカ。

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 21:15:06.80

金もらってシステム構築する場合の面倒を考えると、バカって言う奴がバカって言いたくなるな。

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 21:25:52.02

イヤンバカン

**名無しさん＠お腹いっぱい。** · 2014/08/10(日) 22:20:28.05

>>242
あまりにも自分だけの都合で物事を考えすぎ

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 04:21:27.94

ports/pkg は入れない自由もあるんだから、消す必要はないだろ。

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 14:27:59.20

そうまで言うならメンテナになれば？

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 15:48:32.05

GTKは消してもいいと思うよｗ

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 16:13:20.91

消さなくてもいいと思う。

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 16:20:07.93

>>249
お前がそう思ってても消す理由なんていくらでもあるからな？

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 16:25:33.51

>>250
たとえば?

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 16:35:40.41

特にありません。

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 20:08:09.99

>>251
俺が消してもいいと思ったから

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 21:12:46.68

↓バカの極み

Since Adobe has issued multiple security advisories for newer versions of the
product, after support for the old version was discontinued, we must assume
that the old versions are also vulnerable. Hence forbid installation.

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 21:45:50.93

くやしいのうｗ

**名無しさん＠お腹いっぱい。** · 2014/08/11(月) 23:33:59.29

こういうのがあるともう普段の環境には使えないな

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:12:23.26

同感。
ここらがサヨナラする潮時なのかな。
PC-9801RAで始めてからかれこれ結構長く使ってきたな。
本は「入門キット」と言う名前だったような。２０年くらいになるのかな。
Linux はディストリが多くて何を基準に選べば良いのか分からん。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:16:20.37

debian/kfreebsdでfreebsdを使い続けよう

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:20:47.33

acroreadが無いだけで困るって

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:23:43.12

pdf閲覧なら他にも選択肢があるし、adobeもlinux版は力入れてないみたいだから、
acroreadはもう仕方ないかなと思う。でも他の多くの実用的なlinuxアプリケーションも
portsから入れられない状態が続くのはマズイような。いまのうちにパッケージ確保しとくかなあ。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:28:32.94

ほかのFreeBSDユーザーはX用ソフトは仮想環境のlinuxで使ってるのかな、と最近思う。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:39:27.57

acroreadはバグだらけだし
セキュリティホール直す技術もないし

どう考えても入れては駄目なソフトウェア筆頭だろ。
失くなったところで、一切影響ないんだが。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:43:25.93

GNOMEのEvinceかMATEのAtrilでいいじゃん

. · 2014/08/12(火) 00:45:11.91

閲覧用途ならそれで十分だね。
パスワード付きも閲覧できるし。

Firefoxも標準で閲覧できるし。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 00:54:10.91

evince はスナップショットがないのが玉に瑕。
okular の GTK 版があればなぁ。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 02:55:11.90

LinuxのwineではFoxitが余裕で動くでゲスよ

. · 2014/08/12(火) 06:47:37.15

Foxitをわざわざ使う必要性がない

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 07:12:28.81

acroreadがないだけでFreeBSD見限れるなら見限ればいいだけの話。
必要なのはPDFを読める環境なのであってFreeBSD自体でないんだから。

それをもったいつけて「サヨナラする潮時なのかな」って、お前どんだけFreeBSDに
とって重要なユーザなつもりなんだよｗ

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 08:07:40.71

日本語で頼む。

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 10:46:12.01

MacOS XからFreeBSDサーバーに入るのが一番な生活になってはや10年ぐらいかな

. · 2014/08/12(火) 11:01:22.92

OSX糞杉。
FreeBSDの方がマシだわ。

会社で仕方なく使っているけど

**名無しさん＠お腹いっぱい。** · 2014/08/12(火) 23:45:42.59

「acroreadが無いだけ」なんて言った覚えは全然ないんだけどな

「こういうのがあるともう普段の環境には使えないな」
全然違うだろ

必要なもので自分で何とかする気になるものだったら自力で何
とかするからいいんだよ。微妙すぎて自分でやる気にならんものが
地味に痛い。そういうのが増えると特にね

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 02:42:01.25

>>272
257だけど、268 は俺に言ったんだよ。
彼の言う通りだし、俺は移る準備を始めるよ。
寂しいけど、ちょっと前からそんな予感がしてたんだ。

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 03:12:37.82

FreeBSDからLinuxに移行するとするとして
最も敷居が低いLinuxディストリはどれになるんかな

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 04:52:58.70

Debianじゃないかな。
Ubuntuとかはノイズが多い

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 04:54:04.69

敷居は知らんがFedora使っとくのが標準。

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 05:58:07.72

今はさすがにFedoraはない。
ユーザ置き去りにしてアップデートしすぎだありゃ。

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 06:09:38.88

Fedoraに着いて行けないような老害にはなりたくないのです

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 06:52:27.88

RHELの公開アルファテスターですね、わかります

**名無し** · 2014/08/13(水) 09:16:48.58

ArchがBSDユーザーには使いやすいと思うよ

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 09:27:57.71

ソースをビルドしてシステムを構築するという文化的側面を鑑みると、Gentoo Linuxが最も近しいと言えよう。

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 09:35:40.33

うぶんちゅにしてUnityの素晴らしさに震えろ

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 10:20:33.61

unixを日本語込みのメインデスクトップ環境として使うなんて
暇が有り余ってる学生と窓際にだけ可能なことだよ

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 10:39:16.62

誰が無職だ！

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 11:24:56.97

MacBookにfreebsdをいれてる人いますか？

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 11:27:30.31

社史編纂室ではunixを日本語込みのメインデスクトップ環境として使えます。

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 13:09:21.36

Arch LinuxやGentoo LinuxがBSDに似てるといっても
業務でBSDを使う会社はあってもArchやGentooを業務で使うなんてことはまず無いだろうから覚えても無駄になるのでは？
おとなしくCentOSかRedhatかUbuntuかFedoraを使った方がいいのでは？

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 15:02:42.94

そこでUbuntuだすなら、arch,gentooでもいいだろ。

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 15:07:13.64

Linux ってディストリごとに見たら、FreeBSD よりユーザー少なかったりしない？

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 15:09:57.53

CentOSは最近 7が出たので、それにするか6.5にするか非常に悩ましい所

**名無しさん＠お腹いっぱい。** · 2014/08/13(水) 16:35:50.42

>>288
Ubuntuも一部で業務に使われてるし
jujuっていうサーバーオーケストレーションツールもあるし
http://gihyo.jp/admin/serial/01/ubuntu-recipe/0288