| レス数が950を超えています。1000を超えると表示できなくなるよ。 |
2ch閉鎖の危機なんだと(Part3.1)
[689:Perler ◆GSi39OA6 (01/08/28 12:42 ID:0ST40Qqw)]
>>684
私としては、現在自体が逼迫しているので、根本的なシステムの改変
というのは、現状打破の解決策としては難しいと思います。
もちろん、現状打破後(その場しのぎ後)の先行きを見通すために
根本的なシステム改変の案を練っていく作業も必要だと思いますが。
とりあえず、現在2ch.netは心臓自体が止まりそうなので、心臓マッサージの
ような応急的延命措置を続ける作業と、
一方で、一命を取り留めた後どういった手術をして事態の再発を
防ぐのかを検討する作業、をはっきりさせた方が良いと思います。
個人的には、
・read.cgiのHTTPによるミラー化
・mod_gzip
・HTMLの削減
などは前者、
・NFSやSCSI、SQLサーバーなどによるデータ共有
・NNTP化
・GnutellaのようなP2Pクライアント作成
などは後者だと思っています。
特に、read.cgiが非効率なのは確かにそうなのですが、現状で
CPUの効率化のコーディングは、現状打破として全くメリットはないわけですし、
現状で変なバグを埋め込んでしまうと致命的になると思われます。
(「1つバグを潰すと新しいのが3つできるの法則」なんてのもありますし)
現在稼動しているものに、CPUの効率化ルーチンを適用するのは
これ以上は止めて、別に作業を進めて2chが安定したのちに適用する
方が良いのではないかと思います。
[690:名無しさん@お腹いっぱい。 (01/08/28 13:24 ID:qse3iNBo)]
>>689
そうですな。しかし、P2Pクライアントの作成したときのメリットってあるんですかねえ?
NNTPとかならともかく、P2P化しちゃうと、かなり問題が出てきそうなんですが。
[691:7$\ (01/08/28 16:58 ID:tLykoEfs)]
うに板で対応された方、興味あったらカキコよろしくです。
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=998984911
[692:にはん ◆/gWayilU (01/08/28 19:01 ID:rXhYdVC.)]
684です。(↑バイク板のコテハン)
>>689
これ以上UNIX板では「延命処置」に関してやることはないと思うな。
PG板の人達ががんばってるみたいだし。コーディングに興味のある人が
あっちに出張って参加してる状況なんだよね?
眺める限り、やはりPG板はPGが集まっているのだなあ、と思った。開発の発想や
プロジェクトの進行の感じが。
UNIX板にもし使命があるとするなら(そんな大仰なものは2chのどこにも存在しないかも
しれないし、そう思っている人が大半だろう)、長期的展望のもとに根本的な構成の見直し
とかの選定をすべきなんだと思うな。PG板がPGや「初級SE」なら、UNIX板はマネジリアルSE
やPL、といった感じで。
>>690
俺はデメリットのほうが大きい気がするなあ。技術的な面「以外の」部分で。
今PG板で語られているP2P-cacheの構成は、基本的にユーザの善意に依存してる。
(delegationまで含めた)専用クライアントを配布する形態では、基本的に来るものは拒まず
であるWWWの仕組みとも2chの今までのポリシーとも相反するものだと思う。
2chがここまで大きなコミュニティになったのは「縛りがゆるい」からだ。
たとえば、昔の「パソコン通信」では、アカウント取得が無料で、ユーザ情報は一切記録して
いないような草の根ネットがあっても、そのユーザID取得手続き自体が億劫でなかなか
気軽に覗いたり書いたりはしなかった(した人もいるだろうけど)。
専用クライアントが必要になったら、ID制と同じようなことになると思うな。
[693:名無しさん@お腹いっぱい。 (01/08/28 19:10 ID:l7CNGdzg)]
んー、PG板とUNIX板、どっちも見てるのは俺だけですか?
>>690
同意。ていうか明らかに初心者とか上級者とか関係なく首を突っ込みにくくなるとおもう。
IRCですら使わない人が多いのに。
# 比較対象として間違ってるかな?
[694:名無しさん@お腹いっぱい。 (01/08/28 19:35 ID:/foo1b.s)]
>>692
それは web な frontend を作れば解消するのでは?
>>693
PG 板と UNIX 板とで作業スレがいったり来たりしているだけで、
住人は基本的に同じです。
[695:旅人プログラマ (01/08/28 19:59 ID:gfPqQmnc)]
>>664
平均的なmtuはって聞かれると、
「私の周りではデフォルトを変えていませんので1500です。」
としか答えられませんが…(汗
周りに影響を与えない様にmtuを大きくすれば、
1アクセスの転送量が多いシステムなので、
tcpヘッダの数が少なくなってと安直に思っていたのですが…
[696:にはん ◆/gWayilU (01/08/28 20:07 ID:rXhYdVC.)]
>>694
DNSラウンドロビンな(別に下にVLAN切ってあるL4SWでもいいが高いし)キャッシュサーバを
林立させておくということ?
クライアント側が、用意されたP2P-chaceクライアントを使わないことを前提に話しているのだけど。
[697:名無しさん@お腹いっぱい。 (01/08/28 21:23 ID:/foo1b.s)]
>>696
ん? P2P-cache client の web gateway を用意しておいて、そこに
各 web browser が access すればいいでしょ。P2P じゃなくなるし、
gateway が多数あってうまいこと負荷分散してくれないと辛いけど、
cache の効率は上がるという利点もある。
[698:にはん ◆/gWayilU (01/08/28 21:28 ID:rXhYdVC.)]
>>697
それだと、既にP2P-cacheでトラフィック減って話じゃなくて、サーバがわでの負荷分散の話に
なってしまってるでしょ。
俺も鯖側での負荷分散にはなんのフリクションもなく移行出来ると思うよ、実現可能な
土壌があるならね。
read.cgi ver5.26+ (01/10/21-)