２ちゃんねる開発統合スレッド

DATからの直読みがuser-agentを要求するのは明らかにナンセンスな仕様だと思われ。
これならGETなどで適当なパラメータを送るように仕様が変われば
read.cgiの負荷なんて簡単に下げられると思うのだが。

その前にCGIやめろ
CGIだから負荷問題がでてくる
おわかりかな？

>316
本質的に315と同じだな

クライアント依存のプログラミングには俺も賛成。
自前で全部やるから疲れるんだ

どうせならｄａｔをファイルじゃなくてメモリ常駐の変数にしてしまえば驚くほど
早くなるかも。最初のクライアントサイドプログラムだけＨＤＤから送ってやるようにして。

素人ひっこめ。

>>319はアホだ。
しかし>>318は素人発想だな。許せる。

俺は２ちゃんねるが軽くなることに何のメリットも感じないのだが、
軽くするアイデアなんてみんな持ってるんじゃないのか？
俺と同じくメリットがないから出していないだけだと思われ。

>>318
これが近いな
http://loche.tripod.co.jp/
ローカルプロキシじゃなくてローカルの2chサーバにしてしまっても面白いかもしれん。
319は……アホだな

>>322
クライアントをインストールして貰う、というのが最大の難点かと。
それをクリアする必要があるのに、DATを直読みするときに
クライアントが絶対必要なuser-agentを必須にしているのが
ナンセンスすぎて泣けてきます。

この制限さえなかったら、かなり選択肢の幅が広がるはず。
少なくとも俺はいくつかの解決策を提示できます。

もっとも、この制限に燃えてハッカーチックでトリッキーなことをするのが
この板や２ｃｈに求められる人材なんだろうけれど、
こちらは暇ではないし、ここでの名誉もいらないのでそんなことはしないです。

で、たぶん俺と同じく大多数の人がそうなんじゃないかなと思ってみた、と。

＞クライアントをインストールして貰う、というのが最大の難点かと。
じゃあどないせーちゅーんじゃ

>>323
何を言いたいのかサッパリ分からないんだが。
論点を明確にしてもう一度どうぞ。

>>324
ブラウザ上でクライアントウェアを実装するとかね。たとえばJavaScript。

>>325
user-agent制限をはずせば、色々な人が軽量化アイデアを出すだろう、ということ。

　　_, ._
（　ﾟ Дﾟ)　　・・・

柔軟に考えようぜ

ＩＥプラグインにできないのか？
俺にはそんなスキルないけど

メモリ２ＧＢ実装しても容量足らないのか?

>>329
ナンセンスかと思う。

理由１：IEのみに対応は普通に反感を買う
理由２：普通のユーザはプラグインをインストールしない。しかも2ch発なんて怪しすぎる

需要はあるだろうが、やはりインストールしてもらう、というのがどうしてもいけないね。
たぶん今の問題を根底から解決は出来ないだろう。

>>330
その説は悪いけどもう捨ててください。

ＵＮＩＸならメモリもファイルの一つとしてマウントできそうな気もするんだが。
てか負荷の原因ってハード的な部分も大きいと思うんだが

>>333
何もわからないのに書き込まないでください

>>332
>>334
どしてそんなに偉そうなんだ

335=333に１００ペリカ。

>>335=333
read.cgiを実際にプロファイリングしてみればわかると思うけれど、
プログラミングをそこそこかじった人間ならば、
ディスクアクセス時に発生するコストとHTMLに変換する際のコストと
どちらがクリティカルかを直感的に理解している。
どうしても自分が正しいのだと言うならば、証拠を出してくれ。
＃もし本当にやってくれたら結構感謝するかも。俺もデータ自体は知りたい

後、２ちゃんねるのデータが２Ｇごときで足りるとは思わないのだが
サーバスペック自体で１００Ｇは超えていたはず。

他にも、メモリにおいた場合データの消失にはどうやって対応するんだとか、
もうそりゃ考慮するまでもない馬鹿な話だったので否定している。
偉そうなのではなくて、アイデアが相対的に果てしなく馬鹿なだけ

>>335
偉そうに思われてすまないです。だいたい336氏と同じです。
ボトルネックはハードとは関係の無いところで起こっているはずで、
だからこそ運営側は２ちゃんビュアーを使えと言っているんだと思います

そうそう、仮にuser-agentの規制をはずして貰っても、JavaScriptを使う場合
セキュリティの問題から、必ず*.2ch.netにスクリプトを置かなければ
いけなくなるので、すぐにローカル環境からテストは出来ないです。

だからアイデアを２ちゃんねる運営側の協力なしに実装するには、
他のサーバにて自前でテスト環境を整えなければいけなくなるけれど、面倒すぎる……。

>>333
それを言うならファイルをメモリにマップする（マップトファイル）と思われ。
頭だいじょうぶか？

ちなみに夜勤さんによるとディスクI/Oが最大の問題だそうだ。
gzipで圧縮転送するのに、ディスクにテンポラリファイルを作る
らしいんだが、その負荷がバカにならんらしい。

>>336
＞後、２ちゃんねるのデータが２Ｇごときで足りるとは思わないのだが
＞サーバスペック自体で１００Ｇは超えていたはず。

おまいはメモリとディスクの区別ぐらいつくようになってからこい。
ド素人丸出し。

>>340は勘違いらしい。すまんかったので逝ってくる。

>>339
なるほど知らなかった。
ん、まてよ、DAT直接読むときもgzipで圧縮かけていなかったっけ？
monazillaにそんな記述があったような気がするけれど、もしそうなら
２ちゃんビュアー使ったところでＩＯの問題は必ず残るのかな？

結局、CPU能力が充分あったとしても、
ネットワーク速度＞IO速度
なら、IO問題は残ってしまうと思うが。

ところで、ここで何かを発表して、それが運営側に伝わるのかな？

>>336
333ではないが・・・。
100ペリカ頂く。

>>どうしても自分が正しいのだと言うならば、証拠を出してくれ。
いつ正しいと言った？
書き込むなとか、考えを捨てろとか、この辺が偉そうだっていっただけ。

>>342
read.cgi ＋ 圧縮I/O負荷
圧縮I/O負荷のみ

どっちが負荷高いかはわかるでしょ。

既存の圧縮形式ってリアルタイム性に特化してるわけじゃないからｇｚｉｐより
単語の符号化が一番いいと思うが。専用ブラウザは全部クアイアントで処理
出来るようにしてｒｅａｄ．ｃｇｉはとりあえず２ｃｈでがんばる。ＩＥとネスケだけでも
プラグインが使えればかなり軽減されると思うが。転送量も３０％異常の軽減
が望める。

>>346
read.cgiの転送量＝直読みの転送量、とした場合ならば

１：夜勤はディスクI/Oが最大の問題と言っている
２：read.cgiでもDAT直読みでもI/Oのコストは同じ
３：２ちゃんビュアーを使っても「最大の問題」の解決にはならない

となるわけです。

しかし現実問題、read.cgiの転送量はDATに比べてだいぶん大きそうなので、
上記の２番目の項目が嘘になり、ある程度問題を解決できるって事ですかね？

>>347
・gzipを使っているのは、ブラウザで広く普及しているため。他に選択肢はないです
・プラグインをインストールする人の層と２ちゃんビュアーをインストールする人の層はかぶるだろうから、
　仮にプラグインを作ったとしても今以上の幅広い導入は期待できない。３０％はまず無理かと。

符号化する単語の数で決まると思うよ。ｐｅｒｌなら簡単なんだがＣで文字列置きかえって
どうやるの？

本７は沢村よりタチが悪いと思った。

相手にするからいけなかったのかな。

俺の意見としては
・クライアントをインストールさせずにサーバのI/O負荷を減らす方法
の解として、
・JavaScriptでクライアントを作ればよい
を提案しますが、そのためには
・user_agentによる制限をなくす
必要があります。

とりあえず以上で。今日はもう筋トレして寝ます。

ＩＥユーザの多くがＪＡＶＡを切ってる罠

http://homepage.mac.com/hitomi18/

・・・JavaとJSの区別をつけられないほど初心者だったのか・・・

>>338
> 頭だいじょうぶか？

お前の方が心配だよ｡
マップドファイルとメモリーファイルシステムは全然違うもんだよ。

unixって各入出力も全てファイルとして扱っていると読んだ事があるから言って
みたんだが違うの？Ｘ６８０００の仮想ディスクみたいにできたら糞速くなるとおも
うが

メモリマップト（マップド？）ファイルは、
あたかもメモリアクセ（略

本７に向けて説明してもわかるわけないか

>>358
というかスレ違いだろ、質問スレでやってくれ

>>352
発想はいいが、各ブラウザに対応してスクリプトを書く労力はちょっとなぁ…
それに、JavaScriptでDATを取ってくることなんて出来る？

バカはもう寝ろ

・プロキシやオンラインストレージ、HDDのリプレース（オンメモリ、シリコンディスク）
これらは金がかかる。
無料サービスを利用した草の根的な展開はすでに実施されているが大規模にするわけにはいかない。（組織的にやったらｺﾞﾙｧされると思われ）
ただしそれらの草の根活動を支援する仕組み（HOWTOや支援ツール）を用意することは有効だと思われる。

・クライアントソフト
いかに普及させるかが課題。
慣れ、見た目などの問題もあるがただ単に職場はソフトのインストール禁止だからという人も多い。

というところでしょうか
専用ブラウザをいかに普及させるかがキーになると思われますが
IE（JScriptやJAVAなど）で実行できる通常の２ちゃんねるとあまり見た目が変わらない専用ブラウザで
多少の+αがあればライトユーザーにも勧めやすいと思います

DAT直読みよりread.cgiを使った差分読み込みが今回の主眼となるのではないでしょうか
（DATは差分読めたっけ？）
CPUが問題になってないのであればDAT一括読みは避けたほうがいいと思います（特にJSはローカルに残せるわけでもないし）
まずはIEのリロードを死滅させるのが先決だと思います

実況みたいな小数のスレを多数で見るのならP2Pでリレーさせればいいじゃん

本７は馬鹿なので以下放置してください

おっぱいｽﾚが板違いてどういう事だ？出て来い管理人
http://qb.2ch.net/test/read.cgi/sakud/1044021102/

JavaScriptでクライアントソフトか。考えもしなかった。
それだと、IE5／NN6／OPERA7以上限定になるだろうけれど、
見た目を全く変えずに作ることが出来そうだな

ｽﾝﾏｿﾝ
あまりよく理解していないんだけど、dat→HTML変換をJavaScriptで
行うことで鯖の負荷を減らせるんじゃないかってことデスカ？

>>366
そういう事だと思います。

>>360

普通に考えれば、サーブレットなどにしてしまえば
プロセスの起動コスト等が短くなっていいんじゃないかと思うが、
それはあまり問題じゃないの？

>>347
現在は read.cgi での圧縮はしていません。おそらくhttpdレベルかと。

>>348
ディスクI/Oも問題だけど、他にも解決すべき問題はあるわけですよ。
２ちゃんビューアを使うとIEを使うより（目に見えるほど）負荷が下がる
のはすでに実証済みですが（特にCPU負荷）。

>>349
HTTP1.1をサポートするブラウザ（大きいとこでIEとNN）はgzip以外に
defrateも実装しています。他のブラウザも多分そうだろうけど。で、
gzipよりdefrateのほうが負荷が低い（圧縮用テンポラリファイルを作ら
ない）ということらしいですが、うまく運用できてないらしい。

>>352
JavaScriptでクライアントを作るって軽く言ってくれるけど、あれって
結構重たいですよん（スクリプト言語だから当然重いわけで）。
そんなことするならJavaAppletのほうがまだ現実的かと。Appletを
使う前提ならホストに直接HTTP GETを発行する前提でＯＫだから、
User-Agentは何ら問題ないわけですが。

>>353
あなたは頭悪すぎ。現実はほとんどのユーザがデフォルトのまま。

deflateﾀﾞﾛｶﾞ

>>370
＞JavaScriptが重い
そんなことは無い。
少なくともdat->html変換程度ならば
目に見える負荷は無い。実験してみそ。

それよりappletというのは良くない考えだね。
appletは（仕方がないのだが）起動が重いし、
appletで作ったインターフェースは、
ユーザーの今までのブラウジングの直感に反するので
従来のページも使えるとすればほとんどそちらに流れると思う。

JavaScriptの方が断然メリットがある。ただ、各種ブラウザに
きちんと対応して開発しなければいけないという面倒はあるけれど。

>>372
＞少なくともdat->html変換程度ならば
datはどこから持ってくるの？

>>373
どういうこと？ただ知らないだけの質問なら、
http://pc2.2ch.net/tech/dat/998908559/
たとえばここから。
いわゆるdat落ちで言われるdatではないよ。

それとももっと深い質問だったんだろうか

http://pc2.2ch.net/tech/dat/998908559.dat
だな、須磨粗。どちらにしてもブラウザからは
user-agentの制限で読めないはず。

え、JavaScriptってば、GET発行できたん？

>>372
うーん、なんというか、たとえば800レス300KBのスレを
全部表示させたりなんかすると、JavaScriptでやるには
ちょっとつらくないすかねぇ、ってことですよ。もちろん、
ガタガタに遅くはないだろうけど、モタつく程度いは体感
できるはず。あとdatの取得をJavaScriptでやる方法は
漏れもわかりません。

＞appletは（仕方がないのだが）起動が重いし、

いつの時代の話？Netscape7.02＋PentiumII 500MHz
の環境（かなり貧弱）だけど２秒で起動したよ。一度目
が起動してしまえばあとはブラウザを終了しない限り
起動時間はかかりません。

＞ユーザーの今までのブラウジングの直感に反するので

もう少しJavaのGUI 部品を勉強しましょう。WEBブラウザ
に似せることなんていくらでもできますよ。

>>377
２秒は遅いだろ

話が進んでいますね……

>>370
JavaScriptは遅いですね。とはいえ、たとえば300KBのレスを
全部表示させるとどの程度の重さになるのかはちょっとわからない。
直感だと１秒はかからないと考えているのですがどうでしょうか。

>>370
deflateしらなかった、調べてみます。
「うまく運用できてないらしい。」というのは
運営側が導入に失敗しているということかな？

>>377
JavaAppletはありですね。
でも俺も、アプレットを使ったページは忌避しますが……
＞もう少しJavaのGUI 部品を勉強しましょう。
＞WEBブラウザに似せることなんていくらでもできますよ。
たとえばどんなところがありますか？

>>376
＞え、JavaScriptってば、GET発行できたん？
iframeにonloadを使えば出来ます。
operaで出来ないですが、それでも似たような方法はあるかも。

それよりいっそ、DATファイルをHTMLにしてしまうのはどうなんだろう……

一度目
が起動してしまえばあとはブラウザを終了しない限り
起動時間はかかりません。
↑
重要なのはコレ。２秒は純粋に起動コストだから、以後は
スイスイです。ていうかたかが２秒も待てないの？鯖負荷
でHTML取得に待たされるほうがよほど重いと思うけど。

>>380
appletってだけで最悪

>>379
deflateがうまく動いてないというのは、どうやらApacheとかhttpdの
設定の問題らしい。どうもrootがないといろいろ面倒 = gzipでいく
しかなさそう？という流れになってきているようですね。

＞でも俺も、アプレットを使ったページは忌避しますが……

SunのJRE1.4.1_02を入れて、以下のページをいろいろめぐってみて
ください。初回起動時に一瞬待たされる以外はさくさく動くはずです。

http://sariel.miyako.co.jp/~uni/

＞たとえばどんなところがありますか？

JEditorPaneでHTMLをそのまま表示してやれば、あとはread.cgiの
やってることをアプレットでやるだけかと。Appletはローカル資源に
アクセスできないのと、ダウンロード元ホストとしか通信できないの
を除けば、HTTPリクエストも発行できるしGUI 部品も使えるので、
便利は便利ですが、ホスト側にAppletを置く必要がありますね。

＞それよりいっそ、DATファイルをHTMLにしてしまうのはどうなんだろう……

ひろゆき管理人が実験するとかしないとかいってましたよ。やるなら
sports2サーバ？と思ったら、 http://bg3.2ch.net/rdt/ こんな板が
ありますね。いろいろ実験はしてるようです。

>>374
datファイルの位置じゃなくて、>>375-376で言われてることを言いたかった。

＞それよりいっそ、DATファイルをHTMLにしてしまうのはどうなんだろう……
結局 http://pc2.2ch.net/test/read.cgi/tech/998908559/5-10 みたいな指定をされたらCGIを動かすしかないわけで……

>>382
とりあえずフォント設定、コピペ、などを含めて
いままでと同じ環境が用意できるので、
その点でJavaScriptが有利ですね。

アプレットは開発が楽なのが何よりのメリットなので、
ぜひ誰かに作ってもらえばいいと思います。

>>384
そんなことは無いと思います。
たとえば今までと同じDATファイルなんだけれど、最初の１行だけ
<HTML><HEAD><SCRIPT lang..="javascript" src="ext.js" /></HEAD><BODY><PRE>
を付け加えたとして、
ext.jsの中で現在の自分のURLを取得し、それを自分で解析すれば可能です。

でも何度も言うように、JavaScriptで開発って面倒すぎて、無償では誰もやらないと思うのですが。

iframeで読み込んだら、dat全読みになって転送量に響くと
思うのだがどうか。

>>386
２ちゃんブラウザってみんなdat全読みじゃないの？

p2 使えよ。

最初の一発だけはね。
JavaScriptでは、ローカルキャッシュが存在しないとおもうけど、、

>>389
ブラウザ閉じるまでなら自分でキャッシュしておけばいいのだろうけれど
転送量は微妙なところだな

JavaScriptってば、キャッシュしたうえに差分転送できるの？

Flashでやる猛者はおらんか

確かにJavaScriptにしろJavaAppletにしろdatの部分指定を
されるとdat全読みになる罠（レス番号に対応するオフセット
がわかるなら別だが）。
２ちゃんねるブラウザはローカルにdatを保存するから差分
読みとローカルキャッシュの表示で対応できるわけで。

>>393
オフセットがわかっても無理ぽ
JavaScriptならば転送量を増やす危険性があるなぁ

ならばレス番指定の時のみread.cgi等、うまく割り振ってやればどうだろう

>>394
いや、Appletだったら、HTTPでRange: 500-1000とか投げれば
バイト指定で部分取得できるかと思って。

IEで見てたらたまにブラクラ表示するようにしたら
２ｃｈブラウザ使うようになるんでない？

datの構造改革とか。1レスずつは無理でも100レスずつバラバラにするとか。
とりあえずアイデアだけ。実現性は後の人よろしく

で、平均5個あるスレのdatから、最新のdatを検出するのはどうするんだい？

>>398
すかさずindexファイルを用意か？

いっそのことRDBに

>>370
圧縮方式としてはgzipもdeflateも同じです(ヘッダが微妙に違うだけ)
メモリI/Oを使うとか使わないというのはサーバ側のモジュールの
実装の話。

> http://bg3.2ch.net/rdt/
念願のレス番を飛び飛びに指定できるread.cgiが入ってますね。
http://bg3.2ch.net/test/read.cgi/rdt/1051009961/1,5,7

やっぱり read.cgi の最適化か、スレッドのdatとhtmlを同時に作るか（html化の
手間はなくなるけどhtml化まで２重データ保持するのが無駄）そこらへんしか
うまい手はないような気がするなぁ。
IEライクな２ちゃんねるブラウザを作るか（●対応で）またはローカルプロキシ
タイプのWEBブラウザサポートツール（●対応）を作るか、あたりが現実的な
ところだろうか。

素直にサーブレット＋ＤＢなどのソリューションはなぜダメなのだろうか？

>>403
前者はacty、後者は322かな。（●対応してないみたいだけど）

>>404
誰が保守・運用するんですか？

>>406
夜勤にスキルが無いなら公募すればいい。削除人みたく

ボランティアでやるやついるかなぁ(^_^;
権限の問題とか面倒なことになる予感

#include <stdio.h>
#include <string.h>

int main(void);
int substr( char *ukeru, char *kaesu , int a, int b );
char replace(char a[204]);

int main(void){

char sti[200];
char vt[200];
strcpy(sti,"@00@@01@で@02@で@03@@04@。\r\n");

printf(sti);

strcpy(vt,replace(sti));
printf(vt);

return 0;

}

char replace(char a[204]){

char s[4][10];
char x[200];
char y[200];
char z[220];

char b[220];
int i;
int l;
strcpy(s[0],"漏れは");
strcpy(s[1],"アフォ");
strcpy(s[2],"ヴァカ");
strcpy(s[3],"基地害");
strcpy(s[4],"です");
l = strlen(a);
substr(b,a,i,4);
for(i=0;i<l;i++){
if (strcmp(&b,"@[0-9][0-9]@")){
substr(b&a,0,i);
strcpy(x,b);
substr(b,a,i+4,l-i);
strcpy(y,b);
strcat(z,x);
strcat(z,s[i]);

strcat(z,y);

}

}

return *z;
}

int substr( char *ukeru, char *kaesu , int a, int b )
{
intk, n ;
n = strlen(ukeru) ;

if(( 0<a && a<=n) && (0<b && b<=n) && (a+b-1<=n)) {
for (k=a; k<a+b; k++)
kaesu[k-a] = ukeru[k-1] ;
kaesu[b] = '\0' ;
}
else
kaesu[0] = '\0' ;
return 0;
}

バグが残ったままだけどこんな感じの符号化エンジンとデコードエンジン作って
転送量そのものの軽減、クライアント側でのデコードにするのはどうでしょう？

どー考えても、gzipに圧縮率、信頼度で勝てないナ

http://www5e.biglobe.ne.jp/~ae86gtv/dat_test.zip

もしかしたらデータが途中で切れるかも知れへんけどＪＡＶＡのテスト用に
便利なブラウザ用意しました。

私は難しいことに挑戦していますが、
必ず、人気サイトにさせます。クーポン屋は
日本一のクーポン屋を目指しています。
http://www.c-gmf.com/index3.htm
http://www.c-gmf.com/index2.htm

>413-414
広告屋逝ってよし

>本７ ◆HON7/awDa.
荒らすな。ウゼぇ。

>本７ ◆HON7/awDa.

話の理解力もスキルも無いくせに二度と書き込むな、クズが

>>415
ﾜﾗﾀ。同じ扱いか(藁

半角の厨がまじってるな

>>419とかな

例えば>>413-414のような広告厨をローカルあぼーんする場合、
2ch専用ブラウザを使わないで非表示にするにはどういう仕様がいいだろうか？

俺はラウンジなんだが。

削除投票システムなんてどうよ？

削除人待ちではなくこれは消すべきだと思ったら誰でも投票できる
それを元にフィルタリング
つまりあぼーんリストの共有ってことです

少数派を切り捨てるやり方は賛同できない

>>423
つまり、田代砲の改造品の餌食になるためのシステムを作るわけですね?

何故賛同者がでないのか、考えたことはあるのかな

誤爆。失礼しました

>>425
あくまでフィルタなのでそれを適用するかどうか、どのコミュニティのフィルタを適用するかは
使用者に委ねられます
マスターに手を加えるわけではありません

>>428
ＪＡＶＡスクリプトかなんかで直読みスクリプト書いたついでに組み込めば？

>>428
だったら普通にローカルフィルタでいいと思う｡

>>430
一々新手の広告に対応する手間が低減される
また、荒らし行為にも強くなる

>>431
そのフィルタの情報が正しいことを誰が保証するんだ ?
全発言に対するフィルタを投票する奴が必ず出てくるよ｡

>>432
二通りあります
1.トリップなど電子署名にあたるものを導入
2.いくつかのグループに細分化しそれぞれがそれぞれのポリシーに基づいて管理

削除人との相違点は管理する人（グループ）の利害のみでフィルタを作成することができることです

http://love.2ch.net/test/read.cgi/gender/1051273875/

bbs.cgi にDenyListみたいなのを読ませて、特定のURL（広告とか）が
含まれていたら投稿拒否みたいのはどうかな。このスレのネタではない
ような気もするけど。

>>433
悪いけど、そのグループ員はどうやって決めるの ?
全てのグループに参加して邪魔することだってできるんだろ ?

(もちろん匿名性をある程度犠牲にすりゃそういうのを排除できるだろうけど、ある面 2ch の特性を殺すことになるからな｡)

P2PBBSスレでも出てたな＞あぼーん投票
組織票をどうするかが問題になったが

>>435
TOMATO＋αって感じですな

>>423
そんなあなたに、
http://pc2.2ch.net/test/read.cgi/tech/1043275721/l50

>>433
参考までに。
新しい掲示板の仕様を考える
http://pc2.2ch.net/test/read.cgi/php/995359658/

>>423
あぼーんリストを有志が作成してWEBで配布
自動ダウンローダーで常に最新の状態に保つ
ダウンロード元は複数を指定できる

これならあぼーん機能に対応しているほとんどの専用ブラウザで利用できる
欠点は専用ブラウザが必要

専用ブラウザの補助ツールの話題はスレ違いかな
この手のツールはゲ製板並に荒らされないとあまり意味がないけど

スレ違いかもしれないけど、ひろゆきが最近
「あぼーんでログが詰まるのはツールの問題であって、２ｃｈの問題ではない」
的なニュアンスの発言をしてたのを見ましてレスを。。。
昔より確実に削除の頻度が増えて、今後は ログつまり → 再取得の頻度が増える
のが、昨今の削除板を見ていて痛感しているのですが、
削除を前提として考えてスレッドの仕様を作る　という視点の改良は可能なのでしょうか。

いいんでないの。
……インデックスでもつけるかい？

結局RDBにせよ、という事で

JavaScript案面白かったけど実現無理っぽいな〜

RDBにすれば何で速くなるん？

>>445
俺のつたない知識からいくと、
・データにアクセスするために必要な、ディスクアクセス等さまざまな部分で
　　彼らの長年にわたる知識を詰め合わせた最高の最適化を行っているため
　　read.cgiなどに比べデータ読み出しの効率が非常に良くなることが予想できる
・データベースを利用するためのプロセスが常時一つ立ち上がりっぱなしになることが予想され
　　（具体的にはjavaサーブレットとか）、プロセス起動＆終了の手間（コスト）が
　　かからなくなるので高速化される
・部分的に読み出したい場合なども適切なデータ構造を取っていればコスト無く可能

などでしょーか

>>429　本当に馬鹿だったんだな
http://pc2.2ch.net/test/read.cgi/php/1050607994/

>>447
どうせ、役立たずのﾗｳﾝｺ

>>447
放置で

あぼーんの位置さえわかれば全再取得しなくて済むんだけどな

つーか、負荷を減らしたいならマジでRDBにすればいいんじゃねーの？

たぶんデーモン動かす権限すらないよ。
かりもんのサーバだし。

>>404-408

インプリメントされているものは増やせない、減らせない、ルートも握れない、
という条件がほぼ確定なわけだから、その前提で考えないとね。

前回もその縛りだったからな
新機能もいいがすでにある機能をこれからread.cgi 5.26+に
再実装していくはずだからもう少しマシにできないものか
http://www.example.com/#.2ch.net/
こんなのとか

read.cgi を read.phpにすると・・・・どんなもんかね。
現状のリクエストごとにプロセスを起動するのと、
スクリプト処理ながらphpモジュール内でスレッド処理するのと
どっちが軽いんだろう。

JavaScript、案は面白いな。
一時的にテストで入れてみて、転送量が増えるかどうか試してみたらどうだろう？

テストするまでもなく転送量は増えるだろ……

>>456
それなら apache モジュール mod_2ch.c にした方が良くないか?

<script defer=defer><!--//
document.getElementsByTagName("BODY")[0].innerHTML=
document.getElementsByTagName("BODY")[0].innerHTML.replace(/デフォルトの名無しさん/g, "<br>hogehoge");
//--></script>
<body>
デフォルトの名無しさん<>sage<>01/09/10 19:21<> テストするまでもなく転送量は増えるだろ…… <>
デフォルトの名無しさん<>sage<>01/09/10 19:30<> >>456 <br> それなら apache モジュール mod_2ch.c にした方が良くないか? <>
</body>
どう考えても無謀だろ

dat→HTML変換処理を書いたJavaScript込みのHTMLを別に置いて、
それ経由で参照しに行くわけじゃないの？
datの1リクエスト毎にScript込みで送ってたら転送量増えるのは当然。

>>461
別の場所に置いても結局転送することに変わりはないんじゃない?
最新の書き込みが反映されなくなっちゃうし、差分読み込みはできないでしょ。

データ解凍と自動リンクとかをクライアント側でやらせて
鯖はただデータを送るだけっていう発想か

>>463
発想自体はmonazilla系ツールが既に実践していることだけど、特別なクライアント
ソフトをインストールさせることなく実現できないかと言う議論かと。
で、出てきた意見がブラウザ上でJavaScriptにやらせればってことだけど、まあ俺
にはいまいち方法が解ってないわけだが(w

結論はJavaScriptではdatを保存しておくことができないので
毎回すべて読みに行くことになるから転送量激増

転送量≠負荷なわけで

負荷も転送量も両方問題なのよ。単に現状負荷の優先度が
高いというだけでね。転送量が限界超えたらまた同時多発で
板閉鎖になるよ。2001年８月ショックみたいに。

>>461の案だけど、生のdatをread.cgi が直接送りつけて、表示変換だけ
JavaScriptでやるという手もなくはないかな。ただ、JavaScript切ってると
わけがわからないけどね。

google バーみたいに ActiveX のコンポーネントをインストールさせちゃえば？

>>469
それってIEプラグイン（ActiveX）の２ちゃんブラウザ作るってことだよね。

そやね。
Flash でも面白いかも。
ローカルのファイルにアクセスできるかどうか知らないけど。

>>470
monazillaにあった気がするな

>>468
なぜ生datをわざわざread.cgi通すんだ？

クライアントインストールでは本質的な解決じゃないと思うのだが……
というのも、たいていのユーザーはクライアントなんてインストールしない。

そうするとread.cgiを改良するか、JavaScript／JavaApplet／Flashによる
htmlの強制クライアント化が望ましいのだろうけれど、
JavaScriptは転送量の増大を生む。
AppletとFlashはインターフェース的に不評を買う可能性が高いし、
（知らずに）オフにしている人間は、一般ユーザーには結構多い。

とりあえず誰かが作ってくれるといいなぁ。Appletなら楽そう？

read.cgiの抜本的改良案もあるのかな？
実際に負荷のネックになっている部分がどこなのか、
サーバのCPU単位のプロファイリングをして貰いたいけれど無理だよね。

上のレスを参考にすると、gzipのテンポラリファイル作成時の負荷と、
read.cgiを呼び出しているときプロセス起動・終了の負荷が重いのかな。

何とかそれを根本的に解決できるアイデアはないものか。

>>468のアイデアは悪くないと思います。
>>473が「なぜ生datをわざわざread.cgi通すんだ？」と言っているけれど、

たとえばread.cgiが先頭に
<SCRIPT LANGUAGE="text/javascript(だっけ？)" src="http://www.2ch.net/read.js">
</SCRIPT>
みたいな出力をしましょう。そして本文はdatをちょっと手直しして、
JavaScriptで処理しやすい形で出力する。たとえば、
<div id="name_1">デフォルトの名無しさん</div><div id="mail_1">sage</div><div>...
みたいな形で。（divにはstyle="display:none"を入れておく必要があるね）

そして全部読み込まれたら、先頭で読み込んだJavaScriptがいつもの見慣れた形に整形して表示する。
この方法のメリットは、
・read.cgi自身の負荷は今より若干減る
・htmlの作成はクライアントで行うので、タグやリンクなどの転送量が激減
今概算で出してみたところ、現状のdatを利用するだけでも２５％の転送量軽減を望める模様
（このスレの１〜１００を使用、HTML62,243bytes、DAT45,561bytes）

現実的な軽量化ではありますね。

ちょっと>>476の整理を。
・read.cgiの出力をさらにJavaScriptにかけることで、HTML生成をクライアントに任せる
・read.cgiは整形HTMLを出力する必要が無くなり、転送量が２５％程度減る可能性がある
・またgzipによって生じるコストも、転送量と比例して２５％程度減る事が予想される
・HTML整形を行う外部JavaScriptは、ブラウザのキャッシュに入るので頻繁に転送されない
・JavaScriptを使用すれば、理論上は９９％以上のブラウザで見た目を変えずに提供できる
・デメリットとしては、クライアントが少し重くなる事と、JavaScriptを切っていたら使えない事

しかもJavaScriptを頑張って作れば、下のサイトみたいなのをデフォルトに出来るね
http://members.tripod.co.jp/moe_story/test/t-4fzrxdrx4i.html

＃例が悪くてすまん、俺は妹属性なので

あ。転送量の計算は、さらにgzipにかける必要があるな。
ノーマルzipでテストの結果、HTML13367byte、DAT11635byte。

１２％の転送量削減。やる価値はあるかも。

ということで、みなさんの検討お願いします

>475
だから、根本的解決を図るには、サービスにするしかないのさ。
サービス(要は常駐して内部/外部からのリクエストに応える)にすると
最終的に負荷を一桁以上減らすことも可能だろ。

まず、fork/execのCGIプロセス関係の負荷を減らし、
.datの内容をキャッシュしてDiskI/Oの負荷を減らし、
圧縮した結果もキャッシュすることでCPUの負荷を減らし、
さらにはread.cgiのrawモードのように
専用ブラウザ用のインターフェースも内蔵すれば
こっちにもキャッシュする効果が出てくる。

ここまで(インターフェースを確定)して、専用ブラウザに普及すば、
.datファイルを公開せず、隠すことができる。
つまり、内部がservlet+DBでも全然かまわない、完全に自由になるわけさ。

サービスっつったって、何もhttpdを作れってわけじゃない。
apacheモジュールでも、mod_perlを利用したperlモジュールでも、
或いは他のモジュールを利用してもいい。
「リクエストの度に起動しない」「状態を保持し続ける」
この２点を満たせるならばどんな方法でもいい。

ただ、開発は力を合わせれば充分可能だけど、導入の方が難しい。
rootも無いし、成果物を好き勝手にいじれる事も求められるみたいだからね。

>476
read.cgiのソース覗いたことある？
read.cgiが出力を細工する負荷なんて微々たるものだ。
何度も繰り返されているが、負荷は
・プロセス
・I/O
・圧縮
この３点。

.datの内容をcgiで出力するなんて、現状は全く意味がない。
そもそも、read.cgiのrawモードが
「負荷が高くなりすぎる」という理由で非推奨となっている。

誰か夜勤とかひろゆきとか呼んできてよ

>>480
最後の２行がそれまでの全部を否定しているような？

>>481
476は負荷の話ではなくて、転送量の話。転送量も下がるに越したことはないでしょ？

負荷はどなたか頼みます。

>>481
転送料では意味あるだろ？

とりあえずageよう。

転送量じゃなくて転送料（金ね）の問題だったら●でなんとか
賄える気がするから減らすべきは負荷なのかな。
今は負荷分散のために●の売り上げで鯖が増えてるけど。

だから

負荷をあげて転送量をさげるために、２年前の８月、当時の全monazillaツールは
read.cgiのrawモードを利用してdatを取得する機能を取り入れた
(これなら圧縮も出来る)

今は使われていない

なぜか？

「負荷が上がりすぎるから使わないで欲しい」と言われたから

>>488
なんかはずれたことを言っていないか？

どうして？

read.cgiを使って転送量を減らそうとする限り
転送料と負荷はトレードオフの関係にあるでしょ。

いま最重要なのは負荷でしょ？
まさか人大杉って言葉聞いたことないとか言わないよね？

あ、ごめん、わかってなかったみたい。
説明すると

　　たとえ転送量を多少減らすことが出来るとしても
　　それに伴って負荷があがってしまうのであれば
　　負荷が最重要である間は、採用される見込みは全く無い。

だから無意味なのさ。

>>490
違いますよ。よく476を読んでみて。
負荷を、読む人のクライアントマシンに（JavaScriptで）かけることにより
サーバの負荷と転送量両方とも減らす、という事です

どうしてもやってみたければ、既にある機能
http://pc2.2ch.net/test/read.cgi/tech/998908559/l10?raw=0
を使って試してみたら？
read.cgiを改変する必要があるとは思えないし。

493は勘違いしたまま？
468==476==>>477のアイデア、問題ないなら導入してもいいんじゃないか？
転送量１２％オフってでかそう。

>492
わかってるよ。

JavaScriptでどうやって差分読み込みするか結論は出てるの？

差分でなければ全取得しかない
↓
だったらCGIで差分を転送させたら？

って流れだったから無駄と言ってるの。

それと、同一部分が多いHTMLは、圧縮すると.datと大きな差は出ないの。
これも昔に検証されてるよ。
もちろん、FORMやらの部分は違うけどね。

それと、負荷は1%も差が付くとは思えないけど。


俺が言いたいのは
最も重要なのは負荷で
負荷をかけている最大の要因がread.cgiなのだから
「read.cgiを使ってどうするか」ではなく
「できるだけread.cgiを使わないように」する事を考えるべけ
ってこと。

>>495
＞それと、同一部分が多いHTMLは、圧縮すると.datと大きな差は出ないの。
>>479

>>495
負荷の話は同意です。これはもっと画期的なアイデアが必要そう。

圧縮は私が試したところ、>>479で書いたとおり１２％の差が出る結論になりました。
転送量に１２％の差が出るなら、やってもいいんじゃないかと思ったんですが。

うん。やってみる価値はあるとは思う。
無駄って言ったのは訂正する。ごめん。

圧縮後のサイズ比も、AAや長文の多いスレと一行レスの多い雑談系では違うし
>1と>>1の差も大きい(いくつ入ってるかで全然違う)。
負荷も、read.cgiは>>1の書き換え等でごちゃごちゃやってたりもするんで
数％程度は違うかも。

ただ、俺は>>480に書いたような根本的な対策が必要な時期に来ていると思ってるし
それが出来ないなら今まで通り●の金で延命を図る程度しかないかなと。

まあ、新しく設計から始める方が楽しいし
同じ時間を使うならそっち(導入手段を含め)を議論すべきだと思ってたんでね。
要は(俺が)やる気になれなかっただけってことで。
ほんとごめん。

read.cgi使う使わないの話なんだけどさ。
read.cgi止めてる場合は、TOPからのリンクを
htmlディレクトリ内のhtmlファイルにリンクするよう改造してくれ。

>>481
＞・プロセス
read.cgi を使う限りつきまとう問題。主なCPU負荷。リクエストごとにプロセスの
生成・消滅が伴い、コストが高い。

＞I/O
＞圧縮
gzipが圧縮用のテンポラリファイルをディスクに作りに行くのでI/O負荷が高い。
圧縮はWEBサーバレベルでやっているので（もうread.cgi は圧縮してない）圧縮
に関する負荷はこれ以上どうにもならなそう。deflateも設定の関係か動かない
らしいので、ここらへんはどうにもならない？

ということで read.php を試してみる、が一番現実的っぽい。現状のCGI の代わ
りに、サーバにインストールされているPHP用のスクリプトを作るだけなんで。
ただ、ほんとに軽くなるのか？

とりあえず現実的な改良案として、

方法：read.cgiでデータを書き出し→JavaScriptで展開
効果：転送量を１０％前後減らすことが出来る
欠点：ブラウザが少々重くなる＆JavaScriptがオフなら動かない

が挙がりましたね

phpがもし駄目な場合、mod_perlじゃダメなのか？
mod_gzip使ってるんならmod_perlも入れてもらえそうだが。
そうすればプロセスのコストは気にしなくてすむぞ。

ところでさ、read.cgiでgzip圧縮をやってしまえば
テンポラリファイルを作るＩ／Ｏが無くなるんじゃないの？

>>498
気にされずに。労力を考えると無駄かもしれないし、
出来ることなら抜本的な構造改革（どこかで聞いたな）が必要でしょう。

そこで>>501でまた面白いアイデアが出てるし。
gzipの圧縮を、mod_gzipを通さずに自前でやるのは、かなりＯＫなのでは？
問題はテンポラリを作らずに圧縮することが可能かどうか、すなわち
（多少圧縮率を落としても）ある程度のバッファリングでgzip規格にのっとった圧縮が可能なのかどうか。

もしこれが出来ればDisk I/Oの問題の大部分は解決しますね。
興味のある人はgzipについて調べてみてください。お願いします。私は寝ます（笑

phpは一度試してみるべきだと思う。
ただし、ひろゆきと夜勤★を説得する必要あり。
夜勤★(とマァブ)あたりは「Cで書いたネイティブコードが最軽」と
思っている節がある。

・mod_perl
apache2鯖には入っている。
１年前の負荷問題の時に導入を勧めた(perlモジュールの可能性を含め)が
夜勤★の「誰がメンテするの？わたしはいやですよ」により拒否された。
また、ひろゆきがメモリリークを疑って躊躇している。
こちらはわしづかみくんスレ参照。

・read.cgiによる圧縮
個人的な意見だが
read.cgiによる圧縮部に不具合があるような気がする。
負荷問題時に入れたら、鯖落ちが頻発するようになった。
メモリの問題かもしれない。
そもそも、圧縮部がかなり無駄(無駄にコピーしてたりする)なので直したいのだが
夜勤★がread.cgiをclosedにして手許で変更しているので、手が出せない。

最大の問題は、こういった実際の開発作業をする人たちに
なんら報酬が支払われないシステムなのではないだろうか。

>>503
ROM ってたのですが、わしづかみくんスレ なるもののリンク先を
教えてもらえないでしょうか？

別に金なんていらないさ。今までよりもっと快適に遊べれば。

>505 全部HTML化待ちだった
http://pc.2ch.net/test/read.cgi/unix/1044204340/
http://pc.2ch.net/test/read.cgi/unix/1044210109/
http://pc.2ch.net/test/read.cgi/unix/1044371176/

ちなみにこれね。
http://pc.2ch.net/test/read.cgi/unix/1044371176/704

704 名前：ひろゆき ◆3SHRUNYAXA 投稿日：2003/2/12(水) 16:54
tcpserverだと、>690さんのような問題もあるわけで、、
tcpserverのようなことをするphpスクリプトormod_perlスクリプトを噛ませるってのは
どうなんでしょう？
ただ、mod_perlは、高負荷になるとメモリにゴミが溜まるようなので、
apacheを再起動しまくったりしなきゃいけないので、
あんまり採用したくなかったりします。
machibbsはmod_perlで動いてますが、早朝に再起動してます。

>>502
read.cgiのgzip圧縮機能はテンポラリファイルを生成しない。
もちろんmod_deflateも。
生成するのは単なるmod_gzipの都合。

>>507-508
すんません。うたた寝してました。

HTML化待ちでしたか。でも、どうもありがとうございます。
クライアントが取得する 2ch の実データはリダイレクトして
どっか別のところにないと、根本的にはサーバの負荷も
データ転送量もイタチゴッコのような気もしたのが現在の所感です。

|-`).｡oO(……。)ﾁﾗ

read.cgiって、自前でmod_gzip通しているの？？

あ、意味不明だった。read.cgiって、gzipの処理を自前でやってるの？
それともapacheのモジュールを利用しているの？

zlibを静的にリンクしてる

>>514
そいつがテンポラリファイルを作っているのかな？
ならその部分をテンポラリファイル作らない形に書き換えれば
確かにずいぶんと変わる気はするな。可能ならだが

ファイルは作ってない。
詳しくは>>611ﾀﾝの http://2ch.nekoruri.jp/ からソースをどうぞ。

>>511だった。まあどうでもいいが。

じゃ、なんでmod_gzipがテンポラリファイルを作ることが
負荷になっているんだろう？？

read.cgiのその部分は現在有効にされておらず
mod_gzip任せだから。
つーか少しは過去ログ嫁よ

過去ログ読んだんだけど、読解力が足りなかった。スマソ。
ってことは、自前でmod_gzipを作ればいいだけの話なんだな。
tech板の住民なら楽勝だろうけれど、ただでは絶対にやらないな

read.cgi で圧縮させるよりmod_gzipに任せたほうが軽くなるから
現状に落ち着いたんだと思うんだけど、認識間違ってる？

>>521
いや正しいです。

ただ、mod_gzipはテンポラリファイルを作成するらしく、
そのテンポラリファイルを作る際のI/Oコストが馬鹿にならないらしいです。

なので、テンポラリファイルを作らず負荷のかからない圧縮ルーチンを
自前で作成してしまえば（おそらくトレードオフとして圧縮率か負荷が必要でしょう）
I/Oの問題は解決します。

で、I/Oの問題が最重要なのであれば、そこで負荷を下げてはどうか…という話でした。

>>522
それじゃ、mod_gzipを改良して、
テンポラリファイルではなくメモリ上でgzip圧縮結果を保存するようにしてください。
おそらく、mod_deflateが参考になるのではないかと。
もちろん、そのモジュールを鯖に入れることができるかという問題が別にあります。

ところで、負荷: mod_gzip < read.cgi/zlib のソースをどなたか教えてください。
gzipを呼び出してる大昔の版が遅いのは確かですが、
どうせキャッシュの効かないread.cgiの結果の場合、
apache moduleであるアドバンテージはそんなに無いように感じるのですが……。

>>523
だからおまえがやれって。なんでわざわざ無償で・・・

無償とか訳わかんないこと言ってる香具師はこのｽﾚに(・∀・)ｸﾙﾅ!!

>>525
無償とか言ってる奴はどうせ有償でもろくなもんは書けない奴だからスルーしとけ｡

無償じゃやらないって言ってる奴って、
頭悪そうだし、仕組みについて全然理解してなさそうに見えるんだけど。
なんちゃってSEとかかな。

>523の後半
俺も、「mod_gzipが軽い」は「何となくそう思う」以外ないと思う。
少なくともheに頼んでmod_gzipを入れてもらう前は
index.html圧縮のトラブル防止が待たれていたってことと
read.cgi圧縮がmod_gzipに任せる前提になってたのが大きいかと。

ソース見てないけど、zlibのgzxxxx系がファイル読み書きしかできないから
mod_gzipがgzxxxxを使っているなら負荷がかかるのは当然かも。
一時期read.cgiによる圧縮を有効(最低圧縮率)にした頃の
動作報告スレや重い重いスレ等を見ると
実際に負荷は下がったっぽい。圧縮率の影響だけかもしれないけど。

何故read.cgiによる圧縮をやめたかは理由は不明。
鯖落ちとの因果関係も不明(cgiでapacheが落とせるのか？)だし、
bugがあってcoreを吐いてるのかもしれない。

>>528
read.cgi以外のindexとかsubbackとかのために
mod_gzipがやっぱり必要だから入れて貰った。
だからそのままread.cgiもmod_gzipにやってもらうようになった。

……という流れしか覚えてないんだけど、
もしかして、read.cgiはmod_gzip経由しないようにして
zlib圧縮を復活させればすむ問題だったりして。

もちろんindex.html等のGETにはmod_gzipのオーバヘッドが依然残るんだけど。

> index.html等のGETにはmod_gzipのオーバヘッド
ここの部分はちょっと違う。
index.htmlはbbs.cgi内部でindex.html.gzを作成している。
mod_gzipはindex.html.gzがある時はindex.htmlを全く探さずに
index.html.gzを返してくるようなので、オーバーヘッドは少ないと思う。

subback.htmlは当初更新毎に作ってたけど
今は.gzを作成してないかもしれない。subject.txt.gzも。鯖にもよるかな？
また、.dat(Rangeなし)は、mod_gzip導入直後は圧縮する設定になってたけど
負荷の問題で圧縮しないようになったはず(apache2鯖の設定は知らない)。
この辺は圧縮回数(bbs.cgi呼び出し回数)とGET回数とのバランスなので。

でも、結局、何がボトルネックなのか「〜らしい」って噂だけで
実際に数字が出てない(調査してない)から
どうするのが一番効果があるか、わかんないんだよね。

>>530
おっと、index.htmlは.gz作ってるのか。それは知らなんだ。

あと大きなパラメータはdatの圧縮をいつ行うかだとすれば、
やはりbbs.cgiやread.cgiの呼び出し回数に依存するし、
鯖毎に収容する板によっても割合が変わってくるかな。

さて、ここいらで巣に移動しますか？

２ちゃんねるのプログラムなどを書く人たちのモチベーションって何なの？
オープンソースは世の中に広く使われて、情報的インフラのような側面があるので
使命感などもかなり大きいと思うけれど、そんなのはないよね。

>>532
面白いから、かな。

read.cgi なんか 一日に何千万回も呼び出されるわけだし。
そんなコードに関われると考えただけで、駆り立てられる物がある。

あと、私は 2ch.net が好きだから。
使命感? そんな大きいモンじゃないよ。

少なくとも、今までに何かやってきた人にとって
金や名声でないことは確かだね。

>>533
参考になりますた。ありがとう。

俺は日曜プログラマだけど、なんとなく想像できなくもないかな。
アパッチのオープンソースなんかも同じく楽しそうだけど、
やっぱり日本語じゃなきゃ参加しづらいですよね。

自分が欲しいもんを作ってるだけだろ
少なくともオレはそうだ

apache2鯖に関してはmod_deflateを使うと言うことで解決に向かってる感じ。

■　新しいサーバで read.cgi が正しく動かない問題。
http://qb.2ch.net/test/read.cgi/operate/1047840578/

たしかにそんな事言ってる。
http://jbbs.shitaraba.com/computer/bbs/read.cgi?BBS=2095&KEY=1051177958

（´-`）.｡oO(保守……。)

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

 wea eawwr

・・・JavaとJSの区別をつけられないほど初心者だったのか・・・

>>542
マァヴのことか？

日付/時間指定で新しいスレ一覧を取得できるように四手ほしい。
N速＋とか見てるとどれが新しいスレなのかよくわからん

>>544
dat名でソートすれば

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

保守

もう、保守要らないのかな？

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

８月騒動以来の長寿スレッドだから、保守してあげてください

（結局の所、８月騒動は管理側＆サーバ屋の自作自演だったのかな）

夜勤の自作自演というのが定説です

保守

懐かしい事件を思い出した。
あの時ははらはらしたな。

　他のスレッドなどへのリンクの表記を
>>みたいにできないかな　>@とか･･･
@>http://pc2.2ch.net/test/read.cgi/tech/998908559/555
のように書きこんで、
@>555　のように表記されるような｡
　>>と、前スレの続き、他スレで見た、
などを指すリンクの調和の幅｡

保守☆

手伝ってくれる方キボンヌ
http://program.dot.thebbs.jp/1071486463.html

手伝ってくれる方キボンヌ
http://program.dot.thebbs.jp/1071486463.html

bbs.cgi再開発プロジェクト２
http://qb3.2ch.net/test/read.cgi/operate/1069144193/

いろいろ発注もあり。

akiさんまだ見てます？
見てたら
http://qb3.2ch.net/test/read.cgi/operate/1068017802/796-820
をお願いしたいんですけど・・・

つくろー。

ひろゆき氏 ｂｌｏｇ

元祖しゃちょう日記
http://blog.livedoor.jp/hirox1492/

防犯・詐欺対策＠2ch掲示板
http://that2.2ch.net/bouhan/

#▼ロックファイル
sub lock {
$symlink_check = (eval { symlink("",""); }, $@ eq "");
if (!$symlink_check) {
$c = 0;
while(-f "$LOC") {
$c++;
if ($c >= 3) { &error("■ロック中"); }
sleep(2);
}
open(LOCK,">$LOC");
close(LOCK);
}
else {
local($retry) = 3;
while (!symlink(".", $LOC)) {
if (--$retry <= 0) { &error("■ロック中"); }
sleep(2);
}
}
}

sub error {
if (-e "$LOC") { unlink($LOC); }
print "Content-type: text/html\n\n";
print "<html><head><title>$TITLE</title></head>\n";
print "<body>\n";
print "■エラー<hr>\n";
print "$_[0]\n";
print "</body></html>\n";
exit;
}

↑このロックファイルで定義したところ、
必ず「ロック中」になっちゃうんです…
何が原因なんでしょうか？
定義が間違っているのでしょうか？

read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/

保全

秒表示記念

#5X:~$14H

保守

ほ

死

ゅ

？

このスレでいくら議論しても、
ひろゆきがそれをフィードバックさせなきゃなんの意味もない。

皇紀

お遊びは忘れないのな・・・