トップページ⇒unix
983コメント245KB

FreeBSDを語れ Part38

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。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/
01681042014/08/02(土) 11:31:00.15
>>167
了解です。私の 9.3R amd64 pkg とは amd64 だけ共通ですね。
shell は何でしょうか？ 私は tcsh です。
0169名無しさん＠お腹いっぱい。2014/08/02(土) 11:34:26.73
すげえ、Linuxのpipeって、64kB超えても一気に read(2) できるわ。確認した。
01701642014/08/02(土) 11:37:41.82
>>168
ログインシェルはtcshにしています
0171名無しさん＠お腹いっぱい。2014/08/02(土) 12:03:15.56
職場の新しいプロジェクトでC#を使うことになったんだけど、
いざ FreeBSD の pkg を見てみると mono や monodevelop 等の環境が充実していることに驚いた。
0172名無しさん＠お腹いっぱい。2014/08/02(土) 16:23:26.66
BSD#プロジェクトってほとんど一人でやってるんだぜ・・・頭下がるわ
0173名無しさん＠お腹いっぱい。2014/08/02(土) 16:35:29.21
俺はいつもほとんど一人でしごいてるんだぜ・・・頭がハゲるわ
01741042014/08/02(土) 17:04:28.53
>>170
二人とも tcsh ですね... これが関係しているのですかね？
>>162 さんが shell に触れているので気になりました。
0175名無しさん＠お腹いっぱい。2014/08/02(土) 17:34:26.31
#!/bin/sh って書いたスクリプト実行させるのにログインシェルとか関係ないからｗ
0176名無しさん＠お腹いっぱい。2014/08/02(土) 18:10:26.08
>>128
へえ、最近はそんなにでかいんだ
01771622014/08/02(土) 18:20:02.16
シェルスクリプト介す場合はシェルを何にしてるかも影響しそうだけど、
シェルスクリプト介さずプロセス作った時のトラブルに影響するのかな？
>>175
#!/bin/shが実際どんなシェルにリンクしてるかは一応環境依存だけど、
そもそもエラー再現するときがgsc直で呼んでる時だからやっぱ関係ない系
0178名無しさん＠お腹いっぱい。2014/08/03(日) 09:01:53.51
ざっとソースを読んでみた感じでは、
sal/osl/unx/process.cxx
の中の
osl_executeProcess_WithRedirectedIO　の処理を修正すれば良いんでしょうかね。
ちょっと追っかけてみます。
0179名無しさん＠お腹いっぱい。2014/08/04(月) 02:46:56.10
>>178 お疲れさまです。

http://code.woboq.org/libreoffice/libreoffice/sal/osl/unx/process.cxx.html#461

最終的には osl_psz_executeProcess の中の osl_waitCondition とかに行くのですかね...
複雑過ぎです...
0180名無しさん＠お腹いっぱい。2014/08/04(月) 21:24:21.44
LOがらみ：
再現性について進展。
pstoeditがインストールされていると、
RenderAsEMF()が成功するのでRenderAsBMP()を呼ばず、フリーズしない。
pstoeditがインストールされていないと、フリーズする。
0181名無しさん＠お腹いっぱい。2014/08/05(火) 11:49:53.00
マスターのportがあって、そのスレーブのport個々でPORTREVISIONをバンプした後で
マスターのPORTVERSIONが上がったとき、そのバンプを元に戻すのは
やっぱ忘れやすいよなｗ
0182名無しさん＠お腹いっぱい。2014/08/05(火) 12:14:30.80
>>180
お疲れさまです。
なるほど。FreeBSDでもフリーズする人しない人が居る理由が判りました。
判ってよかったです。
0183名無しさん＠お腹いっぱい。2014/08/05(火) 16:36:43.00
>>180
RenderAsEMF も osl_executeProcess_WithRedirectedIO を使っているんですね。
このときは FreeBSD でも問題ないのは、gsc の問題を意味するのでしょうか？

>>164 にもあるようにフリーズ中は gsc が残っていて、これを kill するとフリーズは解けるのですが、
画像が正しく表示はされる事はないです。例えば、外枠だけ表示されて中が真っ黒となります。
gsc の処理が途中で止まっている様に見えます。
0184名無しさん＠お腹いっぱい。2014/08/05(火) 18:16:19.76
>>183
>このときは FreeBSD でも問題ないのは、gsc の問題を意味するのでしょうか？

いいえ。pstoeditの出力は標準出力ではなく指定したファイルに行うようになっているので該当しません。
どうせ読むならもっと正確にコードを読んで判断してください。
0185名無しさん＠お腹いっぱい。2014/08/05(火) 19:03:53.23
で、>>143はどうなった？
pstoedit入れずにLinuxで巨大EPSのテストもな。1MBはいるな。
01861432014/08/05(火) 19:50:25.25
>>184
分かりました。

>>185
linux は手元にないです。Window はテストしました。
440KB の EPS で正常に動作しました。
0187名無しさん＠お腹いっぱい。2014/08/05(火) 22:24:50.35
LibreOfficeのバグであることは明白なんだから、いいかげんバグ報告すりゃいいのに。
ここでやるのはもうだいぶスレ違い。
0188名無しさん＠お腹いっぱい。2014/08/05(火) 22:31:23.20
わかっている範囲FreeBSDでしか発生していないバグをそのまま報告しても「わからん」
言われて終わる可能性は高いからなあ。スレ違いとまでは言えないと思うが。

SolarisとかでLibreOffice動くんだろうか。わざわざ試す気にはなれないけど。
0189名無しさん＠お腹いっぱい。2014/08/06(水) 02:12:13.47
pkgngって欠陥品では・・・
0190名無しさん＠お腹いっぱい。2014/08/06(水) 05:59:35.22
>>188
ではFreeBSDのパイプの実装を直すべきって言うかね？
0191名無しさん＠お腹いっぱい。2014/08/06(水) 08:05:06.58
本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
入れるか。
どっちにしろ「FreeBSDの話題」だよね?
01921042014/08/06(水) 11:17:26.57
>>189
＞pkgngって欠陥品では・・・

pkgng はまぁ良いとしても、デフォルトで latest なのがマズイと思う。
latest はローリングリリースで数が減ったりするから、タイミングによって欲しいモノがない。
デフォルトはタグの付いたリポにしとくべきだ。
最低でも、そう変更する方法の説明があるべきだけど、それもない。
0193名無しさん＠お腹いっぱい。2014/08/06(水) 13:22:33.96
>>191
>本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
>入れるか。
ばーか。お前は今までの話を理解してないんだな。
0194名無しさん＠お腹いっぱい。2014/08/06(水) 13:31:10.23
>>191
もう一度問題の原因を読んで考えなおせ
0195名無しさん＠お腹いっぱい。2014/08/06(水) 14:58:18.55
なるほど。FreeBSDのパイプの実装がまずいわけですね。
01961912014/08/06(水) 15:45:43.49
>>193,>>194
すまない、確かに自分がわかっていなかったようだ。
「gsに対するパイプへのreadをちゃんとせずにwriteするからお互いにwriteしようと
してデッドロックする」ということであっているだろうか。

これに対する修正なら確かにFreeBSD固有ではないな。ツッコミ感謝。
0197名無しさん＠お腹いっぱい。2014/08/06(水) 15:50:41.55
read/writeのデッドロックじゃなくて、
パイプからの1回のreadで全サイズ読めないとエラー扱いにしてしまうソフトの問題かと。
0198名無しさん＠お腹いっぱい。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) してる。
0199名無しさん＠お腹いっぱい。2014/08/06(水) 17:24:26.66
読まずに書いてしまったが、>>193と>>194はこの現象をどう思う？
>>197はどこからそう判断してるの？
0200名無しさん＠お腹いっぱい。2014/08/06(水) 18:28:48.13
いい感じに盛り上がってるね。
0201名無しさん＠お腹いっぱい。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冗長な行を追加するとフリーズした。
0202名無しさん＠お腹いっぱい。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のソース読んでみようかな。
0203名無しさん＠お腹いっぱい。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を使わせないフラグ。
0204名無しさん＠お腹いっぱい。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分だけマップする。
0205名無しさん＠お腹いっぱい。2014/08/07(木) 04:02:36.68
す、凄い。原因究明して、かつ、複数の対策まで。恐れ入ります。
0206名無しさん＠お腹いっぱい。2014/08/07(木) 05:23:37.04
調査乙です。バグというより互換性問題なのか。

しかしこの理由だとするとFreeBSDでしか起きない現象なのかな。本当はLOを直すのが
よさそうだけど、FreeBSD固有の問題だとLO本家が直してくれるかどうか怪しいかも。
0207202-2042014/08/07(木) 05:33:49.01
>>206
・gsがshowpageした後writeが終わるまでreadしない
・LOがwriteし終わるまでreadしない
のが原因だからLinuxでも再現するはず。
FreeBSDだとdirect I/Oになるとバッファサイズによらずreadが終わるまでwriteが
終わらない(実質バッファサイズが0のような挙動になる)から発症率が高いけれど、
出力画像とshowpageの後ろのゴミが両方パイプバッファサイズ以上ならOS問わず固まると思う。
0208202-2042014/08/07(木) 05:41:05.83
>>205-206
凄いのはパイプの挙動やshowpageやepsファイルサイズが再現性に影響する事を見つけた人だと思う。
デバッグには再現性に関わる部分に詳しいバグ報告が大事ってのをよく表すんだなぁと198みて思った。
0209名無しさん＠お腹いっぱい。2014/08/07(木) 06:28:00.10
きちんとバグ報告までしない限り、実質的に何もしてないのと同じなので別に凄くない
0210名無しさん＠お腹いっぱい。2014/08/07(木) 08:07:25.31
なるほどねぇ。
刻むとフリーズしない理由も見事に説明できてる。
linuxでもフリーズする事例はできてるんだから、
LO側の対策も受け入れてもらえるでしょ。
0211名無しさん＠お腹いっぱい。2014/08/07(木) 08:21:49.33
追記
ブロッキングなwrite(2)がブロックしやすいパイプ実装をしてしまっただけの
FreeBSDには何の落ち度もないね。
どう見ても、双方向なパイプを逐次処理で実装したLOが悪い。
GSにshowpage後に入力をclose(2)させるのは、epsだけならそうだけど、
ふつうのpsと区別できるとは思えないので困難と思われる。
0212名無しさん＠お腹いっぱい。2014/08/07(木) 08:42:30.10
一番凄い>>209がバグ報告してくれる。
0213名無しさん＠お腹いっぱい。2014/08/07(木) 09:42:05.70
>>212
www
0214名無しさん＠お腹いっぱい。2014/08/07(木) 09:48:19.24
>>212
2chはこういう他力本願のクズが多いね本当に
0215名無しさん＠お腹いっぱい。2014/08/07(木) 09:52:28.08
作業に絡めなかった>>209がなんか言ってる
0216名無しさん＠お腹いっぱい。2014/08/07(木) 10:39:53.70
>>215
絡みたくてもcもc++も読めなくて悔しかったのかもな
0217名無しさん＠お腹いっぱい。2014/08/07(木) 10:48:17.16
実際LibreOfficeが直らなきゃ解析した意味がないということで、>>209の書くことも一理ある
0218名無しさん＠お腹いっぱい。2014/08/07(木) 11:16:59.25
バグの場所わかったからってすぐバグレポート書けるわけないのを知らないの？
0219名無しさん＠お腹いっぱい。2014/08/07(木) 11:30:54.34
>>209ほどの人ならすぐ書けるだろ。
0220名無しさん＠お腹いっぱい。2014/08/07(木) 12:32:42.92
調べたのを褒めてもらいたかったのにけなされて切れてる人がいる風味
0221名無しさん＠お腹いっぱい。2014/08/07(木) 13:01:12.27
で、調べた人叩いて何か意味があるの？けなさないと気がすまない症候群？
0222202-2042014/08/07(木) 22:50:32.72
>>209
わざわざそういう言い方する必要はないと思うけど、まぁそうだね。報告も超大事。
英語苦手なんでしばらく様子見するけど、FreeBSDのpipeの挙動は
進展が無い様だったらそのうち報告をBugzillaにでも投げてみるよ。
LOの方はユーザじゃない(Xすら入れてない)ので特に触る気はない。
GSの方はどうすっかなぁ…GS側はある程度仕方ない面も有りそう、
というかLOが酷すぎるから知ったことじゃない、で終わる気もするし。

>>220
誰が誰に貶されて切れてるって？
0223名無しさん＠お腹いっぱい。2014/08/07(木) 23:10:11.45
あんなひどいコーディングしてるのにFreeBSDにバグ報告されたら迷惑です。
0224名無しさん＠お腹いっぱい。2014/08/07(木) 23:32:10.06
1ヶ月たっても誰も何のアクションもしなかったとしたら何だかなあと思うけど、
今の時点で言うこっちゃない。
0225名無しさん＠お腹いっぱい。2014/08/08(金) 06:11:38.87
２ちゃんなんかでやっちゃったせいで報告すべきところへ報告できなくなる奴とかいるよなｗ
0226名無しさん＠お腹いっぱい。2014/08/08(金) 15:33:10.87
https://github.com/freebsd/pkg/issues/912

pkgコマンドで-fオプションが効かなくなった
0227名無しさん＠お腹いっぱい。2014/08/09(土) 01:19:55.57
linux-f10はもう終わりか
でも現状でxorg-libsとかはどうすればいいんだろう？？
0228名無しさん＠お腹いっぱい。2014/08/09(土) 13:54:16.96
え？ pkg search しても、f10 しかないけど。
0229名無しさん＠お腹いっぱい。2014/08/09(土) 16:40:35.98
脆弱性何年も放置してるから終わりだって言ってんじゃないの
0230名無しさん＠お腹いっぱい。2014/08/09(土) 17:56:39.15
https://wiki.freebsd.org/201407DevSummit/LinuxEmulation
0231名無しさん＠お腹いっぱい。2014/08/09(土) 18:13:33.64
>・BSD User側対策(根本治療)→gscをシェルスクリプトとかで差し替え(>>144)。

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

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

こっちを試してみます。 NO にすると他のソフトが遅くなる可能性がありますか？
0232名無しさん＠お腹いっぱい。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.
0233名無しさん＠お腹いっぱい。2014/08/09(土) 20:36:12.97
あまり使ってる人いないんだろうけど、最近clispもportsから外れてた。
0234名無しさん＠お腹いっぱい。2014/08/09(土) 22:33:07.35
こう言ういきなり勝手にforbiddenにするバカは氏ねって思う
0235名無しさん＠お腹いっぱい。2014/08/09(土) 22:57:32.58
地道に修正報告するなりしてメンテナシップ乗っ取るしかないな
0236名無しさん＠お腹いっぱい。2014/08/10(日) 00:50:13.67
>>233
まじか
人手不足なのかな
0237名無しさん＠お腹いっぱい。2014/08/10(日) 04:27:13.03
>>230
いくらfedora10でしか動かんものがあったとしても、それはさすがにもうあきらめるしかないんでないの？とオモタ
そもそもからして変化（サポート切れ）のスピードがはげしいfedoraをデフォルトに採用したのが筋が悪かったんでないかなあ？
これからなら、linux_baseが既にあるcentosに移行が現実的でないかと。Ubuntu LTSもよさそうだけど。
0238名無しさん＠お腹いっぱい。2014/08/10(日) 06:31:14.84
GPL3がクソなのはわかるが、GPLというだけでportsから外す動きがあるように見える。
0239名無しさん＠お腹いっぱい。2014/08/10(日) 13:13:36.61
GPLならportsから外すのは当然だと思うけど？
0240名無しさん＠お腹いっぱい。2014/08/10(日) 14:29:58.12
でもなんだかんだいって、新しめのGCCは永遠にportsから外せないような気がする
ベースシステムのツール群とかはどうにかなると思うけど
0241名無しさん＠お腹いっぱい。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 になってる。余計なことするなよ。
0242名無しさん＠お腹いっぱい。2014/08/10(日) 17:24:38.28
ports なんて入れる入れないはユーザーの自由。
セキュリティとかライセンスとか気にする奴はバカ。
0243名無しさん＠お腹いっぱい。2014/08/10(日) 21:15:06.80
金もらってシステム構築する場合の面倒を考えると、バカって言う奴がバカって言いたくなるな。
0244名無しさん＠お腹いっぱい。2014/08/10(日) 21:25:52.02
イヤンバカン
0245名無しさん＠お腹いっぱい。2014/08/10(日) 22:20:28.05
>>242
あまりにも自分だけの都合で物事を考えすぎ
0246名無しさん＠お腹いっぱい。2014/08/11(月) 04:21:27.94
ports/pkg は入れない自由もあるんだから、消す必要はないだろ。
0247名無しさん＠お腹いっぱい。2014/08/11(月) 14:27:59.20
そうまで言うならメンテナになれば？
0248名無しさん＠お腹いっぱい。2014/08/11(月) 15:48:32.05
GTKは消してもいいと思うよｗ
0249名無しさん＠お腹いっぱい。2014/08/11(月) 16:13:20.91
消さなくてもいいと思う。
0250名無しさん＠お腹いっぱい。2014/08/11(月) 16:20:07.93
>>249
お前がそう思ってても消す理由なんていくらでもあるからな？
0251名無しさん＠お腹いっぱい。2014/08/11(月) 16:25:33.51
>>250
たとえば?
0252名無しさん＠お腹いっぱい。2014/08/11(月) 16:35:40.41
特にありません。
0253名無しさん＠お腹いっぱい。2014/08/11(月) 20:08:09.99
>>251
俺が消してもいいと思ったから
0254名無しさん＠お腹いっぱい。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.
0255名無しさん＠お腹いっぱい。2014/08/11(月) 21:45:50.93
くやしいのうｗ
0256名無しさん＠お腹いっぱい。2014/08/11(月) 23:33:59.29
こういうのがあるともう普段の環境には使えないな
0257名無しさん＠お腹いっぱい。2014/08/12(火) 00:12:23.26
同感。
ここらがサヨナラする潮時なのかな。
PC-9801RAで始めてからかれこれ結構長く使ってきたな。
本は「入門キット」と言う名前だったような。２０年くらいになるのかな。
Linux はディストリが多くて何を基準に選べば良いのか分からん。
0258名無しさん＠お腹いっぱい。2014/08/12(火) 00:16:20.37
debian/kfreebsdでfreebsdを使い続けよう
0259名無しさん＠お腹いっぱい。2014/08/12(火) 00:20:47.33
acroreadが無いだけで困るって
0260名無しさん＠お腹いっぱい。2014/08/12(火) 00:23:43.12
pdf閲覧なら他にも選択肢があるし、adobeもlinux版は力入れてないみたいだから、
acroreadはもう仕方ないかなと思う。でも他の多くの実用的なlinuxアプリケーションも
portsから入れられない状態が続くのはマズイような。いまのうちにパッケージ確保しとくかなあ。
0261名無しさん＠お腹いっぱい。2014/08/12(火) 00:28:32.94
ほかのFreeBSDユーザーはX用ソフトは仮想環境のlinuxで使ってるのかな、と最近思う。
0262名無しさん＠お腹いっぱい。2014/08/12(火) 00:39:27.57
acroreadはバグだらけだし
セキュリティホール直す技術もないし

どう考えても入れては駄目なソフトウェア筆頭だろ。
失くなったところで、一切影響ないんだが。
0263名無しさん＠お腹いっぱい。2014/08/12(火) 00:43:25.93
GNOMEのEvinceかMATEのAtrilでいいじゃん
0264.2014/08/12(火) 00:45:11.91
閲覧用途ならそれで十分だね。
パスワード付きも閲覧できるし。

Firefoxも標準で閲覧できるし。
0265名無しさん＠お腹いっぱい。2014/08/12(火) 00:54:10.91
evince はスナップショットがないのが玉に瑕。
okular の GTK 版があればなぁ。
0266名無しさん＠お腹いっぱい。2014/08/12(火) 02:55:11.90
LinuxのwineではFoxitが余裕で動くでゲスよ
0267.2014/08/12(火) 06:47:37.15
Foxitをわざわざ使う必要性がない
■ このスレッドは過去ログ倉庫に格納されています