| レス数が950を超えています。1000を超えると表示できなくなるよ。 |
2ch閉鎖の危機なんだと（Part3.1）
[680:名無しさん＠お腹いっぱい。 (01/08/28 07:43 ID:yCOO7A16)]
>>679
この際しょうがないと思われ
[681:名無しさん＠お腹いっぱい。 (01/08/28 07:52 ID:Hx/9lOYg)]
>>679
ネスケは大丈夫じゃなかったっけ？
[682:名無しさん＠お腹いっぱい。 (01/08/28 08:04 ID:j8nWGmlo)]
>>680
ついでに携帯端末も切り捨て…ってこっちはイイか、別に。
[683:名無しさん＠お腹いっぱい。 (01/08/28 08:21 ID:w54poCSc)]
>>633
外圧から完全に自由になると言う意味で、究極2ch向きなのはP2Pなんですけどね。
近々それに類する物が出てくる香りは各所でしていますが・・・
[684:名無しさん＠お腹いっぱい。 (01/08/28 09:09 ID:2eseTliQ)]
DNSラウンドロビンで表側を複数台に分けたとして、裏側の、実際に記事データをいちいち
ミラーリングする手法だと、各リーフノード間のトラフィック増による時差が馬鹿にならないと
思うんだけど、どうだろう。この時差を許容するなら、NNTP/NNRP を捨てる意味がよくわからない。
（いや、だいぶそのタイムラグは違うのはわかっているのだけど、そのミラーリングに）
これを、各表サーバ1つごとに1台づつマシンを増やしてソフトウェアRAIDなりででかくて速い
記事置き場にしておいてNFSマウントとか、NFSだとトラフィック的に無理があるなら
RAIDコントローラに使えるようなSCSIドライバを書いて直接SCSIで物理的につなげる、
つまり現行のハードウェアRAIDを自作してしまう、ってのはどうかなあ。
# イニシャルでコストが結構かかるけど、月に何百万とか払うよりましな気がする
[685:名無しさん＠お腹いっぱい。 (01/08/28 09:11 ID:2eseTliQ)]
>684
ああ、なんか日本語になってないな。寝る。
[686:名無しさん＠お腹いっぱい。 (01/08/28 11:04 ID:qse3iNBo)]
最新のread.cgiおいてあるとこってどこなの？
あちこち乱立しててわけわからん
[687:VC++まだ箱のなか厨房(w (01/08/28 12:30 ID:BD3EkxyY)]
http://star.endless.ne.jp/users/forcount/4countbbs/scriptmaker/index.html
こちらで、
開発は主にプログラム板の
プログラマが2chを救う！？２
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998845501
で行われています。
概要は
http://www.gedoh.org/aki/2ch/tiki/
[688:名無しさん＠お腹いっぱい。 (01/08/28 12:37 ID:qse3iNBo)]
おお、これはサンクス.私もがんばってみますか。
[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が安定したのちに適用する
方が良いのではないかと思います。
read.cgi ver5.26+ (01/10/21-)