ストールマン:GNU/Hurdの完成は来年に 55
ストーリー by Oliver
もうちょっと延びても 部門より
もうちょっと延びても 部門より
torus 曰く、 "
IDG の記事(11月7日)によると、『Linuxカーネルの代わりに独自カーネル「Hurd」を採用したGNUオペレーティング・システム(OS)の実稼働バージョンのリリースは、来年にずれ込む公算が高くなった』とのこと。ストールマン氏自身がインタビューで語ったそうです。
個人的には、今年できる予定だったということも知らなくて忘れかけてましたが、残っている問題もはっきりしているようなので、もうすぐ完成かと期待もつのります。"
大きなディスクと高速シリアルI/Oへの対応がボトルネックになっているとか。また、IPv6対応のためにネットワーク担当のデーモン達の大幅な再設計も進行中という情報がIPv6関連のMLにあった。Hurdはマイクロカーネルなのでインタフェースの変更さえなければサブシステムの取り換えが簡単とはいえ、リリース間近に... なにはともあれ、開発者およびコアな人達はすでに日常的にメインマシンとして使っているらしいので、完成といえる臨界点はたしかに近付いてそうだ。
期待はあるのですが・・・ (スコア:1)
見えるのでしょうか。
自分はUnix素人の癖に(しかも「ぱすかりゃー」)
なぜかHurdを使いたくて堪らないという問題人間
なのですが、現状pascalが動くOSというとUnix系
ではLinux系しか無い状況ですので、Linux系の
アプリが動くのか気にはなります。
#最悪プリプロセッサを作る、という手はアリ。
#GNU-Cって関数のネストを許すからほぼ1対1で
#C++pascalは変換可能なはずなんだよな・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
> ではLinux系しか無い状況ですので
そーなんですか?
Free Pascal Compiler
http://www.freepascal.org/
には、Linux, FreeBSD, DOS, Win32, OS/2, BeOS, SunOS (Solaris), QNX and Classic Amigaで動くとありますが。
Re:期待はあるのですが・・・ (スコア:2, 参考になる)
1.0.4からサポートをはじめて1.1で正式対応という話ですから・・・・(今は1.0.6・・・でしたよね?)
ぜんぜん関係ないですが、FreePascalは同名で引数の違う手続(関数)の宣言を許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります。他に選択肢は事実上ないんですが(大笑い)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
まあ、そういうことが出来ないのは、元祖(だよね)Pascalのほうの「落ち度」ですからねえ(^^;
#Delphiしてると、宣言の順序とかinterface節の存在そのものとかにも、結構むかついてきます。
#ああいうガチガチコンパイル系の言語は、Javaみたいに順序依存性を極力廃するのが、いらん気遣いが不要になって楽だと思う。
Re:期待はあるのですが・・・ (スコア:1)
>
>まあ、そういうことが出来ないのは、元祖(だよね)Pascalのほうの「落ち度」ですからねえ(^^;
「落ち度」ですか…
それをいうならシンボル名の長さに制限のあった当時のリンカ等の落ち度(というか限界)だと思うのですが。
過去の技術の限界に配慮しろとは思いませんが、こう簡単に「落ち度」なんて決め付けてしまうと「わかってんのかコイツ」みたいな印象を持ってしまいます。
うじゃうじゃ
Re:期待はあるのですが・・・ (スコア:2, 参考になる)
>みたいな印象を持ってしまいます。
劣った技術は、優れた代替技術が出てくれば、さっさと捨てるが吉でしょう。
つまり、
>許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります
過去はさておき今は、納得しましょう、むしろ積極的に肯定しましょう、と言いたいのです。
それとも逆に引数Overloadの弊害について語りたかったのでしょうか?
それならOKですが、でもそういう雰囲気ではないですよね。
>それをいうならシンボル名の長さに制限のあった当時のリンカ等の落ち度(というか限界)だと思うのですが。
ところでリンカに話を持っていくのは微妙に違うと思いますよ。
コンパイラが、名前のマッピングをすればいいんですから。
たとえば作成された関数に1番から順に通し番号でも振ればいい。
でも、限界といっても、8bit時代でも「いろいろな」長さ限界を持つ幾つか(も)のコンパイラ/リンカが
たしかありましたよね。つまり限界といってもそれはべつに原理的にドコに限界があるというはっきりしたものが
あるわけではなく、「たまたまその実装が」という感じですよね。
ということは少なくとも、一等賞の奴(^^;以外は、もっと良く実装することは可能だったはずなのに、ということになります。
#そんなこと言い出したら、俺だって8bit時代のCにOOPもどきをやらせたかったです。ええ(T_T)
…マッピング? (スコア:1)
でも新しいのが出てきたからと尊敬の念も捨てるのは吉ではありませんよ。
> ところでリンカに話を持っていくのは微妙に違うと思いますよ。
> コンパイラが、名前のマッピングをすればいいんですから。
> たとえば作成された関数に1番から順に通し番号でも振ればいい。
これってマッピングって言うんですか? それにどうやってすべての環境で発番を管理するんですか。
シグニチャ(関数名と引数の形)をハッシュコードにしちゃえばいいかもしれませんけど、かぶらないとも限りませんよね。
ところで私は Pascal も Delphi もちょいちょいと使っていただけなのであまりよく知らなかったんですけど、Pascal って同じ名前の関数を作れるんですね。Cよりもいいとこがあるじゃないですか。
どんな言語もたどる道 (スコア:1)
>つまり、
>>許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります
>過去はさておき今は、納得しましょう、むしろ積極的に肯定しましょう、と言いたいのです。
その点については否定した覚えは無いし、否定するつもりもありません。
とはいっても安易に過去の資産の継承を否定してしまうと、オープンソースのような考え方も否定してしまうことになってしまいますが。
少なくとも、同じ名前の手続きを持てることが悪いといってるわけじゃありません。
使いつづけられ資産を蓄積したプログラム言語が、それゆえに古臭くなり限界が見えてくるのはPascalに限らずどんな言語でも避けられないようなことなのにPascalであることが落ち度であるような表現は不当じゃないかと書いたのです。
JavaやC#だっていつかは同じ道をたどるのだろうし。(すでにたどってる?)
古い処理系を捨ててしまえば済む問題なら
>>許すところが(しょーがないとはいえ)少々納得のいかないpascalさんではあります
なんて話は出てくる必要はないですよね。
こういう嘆きが出てきたということはAverageさんにとってはまだ過去のPascalを捨てきれない事情があるということなのではないでしょうか。
>ところでリンカに話を持っていくのは微妙に違うと思いますよ。
>コンパイラが、名前のマッピングをすればいいんですから。
>たとえば作成された関数に1番から順に通し番号でも振ればいい。
本来の古典的なPascalならP-codeインタプリンタという閉じた環境の話なのでそういう方向性もあったでしょうが、現実にはCなどとの連携を考慮して一般的な命名規則を採用するという当時としてはより実用的な実装を採用しただけの話です。
>つまり限界といってもそれはべつに原理的にドコに限界があるというはっきりしたものが
>あるわけではなく、「たまたまその実装が」という感じですよね。
んでもPascalの場合はある程度環境(ハードウェア)を選ばずに動作することも目指していたわけで、実装がいまよりもずっとハードに依存していたことを考えるとそういう妥協は現実的選択だと思うのですが。
うじゃうじゃ
Re:…マッピング? (スコア:1)
尊敬の念とやらについては今回俺は言及も思考もしておりませんのでご了承を。
てゆーか、「落ち度」と書いたから「(非)尊敬」、ですか?
そういう感情論はアッチ(ってドコだ?)でお願いしたいものですが…
対象はあくまで技術的なものなのですから、"博物館に行ってくださいね"、という種類の敬意なら
払う事にしばしば意味がありますが、それだけのことですね。現場に残って欲しくはないです。
改良すればまだまだ現役という美辞もありますが、屋上屋を架すという諺も意識する必要があります。
捨てる勇気とも言いますね。きちんとした代替物が有る「なら」以前の劣ったものはおおいに無理なく捨てられるわけです。
#今日もまた過去のソースへの敬意(違)に逆らえなくて辛かったのでG7
>これってマッピングって言うんですか?それにどうやってすべての環境で発番を管理するんですか。
「全ての」環境は不要かと。そんなMSみたいな(GUIDだっけ?)贅沢は申しません。
「自分の」環境を記録したファイルかなんかを後生大事に持ち歩けばいいかな、と思っています。 #嫌だろうな(^^;
意味付けは違いますが、なんとなくSmalltalkのImageファイルのノリを連想してます。
>ところで私は Pascal も Delphi もちょいちょいと使っていただけなのであまりよく知らなかったんですけど、Pascal って
>同じ名前の関数を作れるんですね。Cよりもいいとこがあるじゃないですか。
ん。てゆーか、あれはDelphi(しかもver4あたり以降)の言語仕様だったような。
でFreePascalはたしかDelphi似が売り文句でしたよね。
余談:
個人的には、引数Overloadが絶対必要か?と詰め寄られたら、ちょっと目をそらすかも知れません(笑)。
どっちかってーと、SmalltalkでいうKeywordMessageみたいなもののほうが、ずっと重要かつ有用じゃないかと思っています。
名前つき引数とかと違って静的に処理できるんで、然るべきParserを作れば済むし、#名前つきだって静的に処理できないわけじゃないが、記号にあんまり多義性を持たせたくないですし…
読みやすさは引数をカンマでしか区切れない言語より数段マシだと思いますし。#書きやすさは…どうだべか?
Re:どんな言語もたどる道 (スコア:1)
記述フォーマット(この場合は言語)の陳腐化、というのは、
ソースを持つという考え方に対して「常に」ネックになりますね。
逆にいえば、そのネックとは上手に付き合っていかざるを得ないわけです。
あくまでネックなので、いつまでもいつまでも同じソース(&それの継承物)を引きずるのは
段段メリットよりデメリットのほうが多くなるでしょうね。
#これは、言語について言えば「言語の発達」というものが終わってしまわない限り、続く事でしょうね。
どこかで捨てる勇気が必要になるでしょうね。
勿論蛮勇では駄目で、代替物を準備してから捨てるべきなのですが、
逆にいえば代替物を用意しようと努力することもまた重要だし。
結局、どこからならば「安易」といえるのか?という程度問題になるのでしょうね。
また、単にあるソフトのある版の(^^;ソースが自由配布されるだけじゃなくて、
それが「新陳代謝」していくこともまたOpenSourceの醍醐味&メリットだと思います。
で、その変化がたまたまある時点で大きくなる…所謂乗り換え…という事が起きる(ことを肯定する)のは
別にOpenSourceと相反する考え方では、ないでしょうね。
過去の版が有る状況での話ではないですが、Squeakの思い出話(?)に
我々の誰もがCでVMを書きたいとは思わなかった [dti.ne.jp]というのが有りました。
あーゆーノリ、じゃないかな。
>使いつづけられ資産を蓄積したプログラム言語が、それゆえに古臭くなり限界が見えてくるのはPascalに限らずどんな
>言語でも避けられないようなことなのにPascalであることが落ち度であるような表現は不当じゃないかと書いたのです
「Pascalはその落ち度を持っている」と言ったツモリであり、
「その落ち度を持っているのはその言語がPascalだからだ」という差別論を展開したツモリは無いのですけど?
>JavaやC#だっていつかは同じ道をたどるのだろうし。(すでにたどってる?)
PascalにはPascalの、JavaにはJavaの、「落ち度」が有ります。
そしてそれらは、大抵「別々です」。あんまり重なりません。(重なるのも有るけど。)
俺(や任意の誰か)が、それぞれの言語についてそれぞれの時点でそれぞれ「落ち度」に気付いてそれぞれ語れば
それで良いだけのことです。
>こういう嘆きが出てきたということはAverageさんにとってはまだ過去のPascalを捨てきれない事情があるということ
「捨てきれない事情が有るから捨てられません」という話があることを論拠として
「捨てたいよね。捨てようよ。」という話を不当と呼ぶ、
のも不当なのではないですか?(^^;
事情のことを言い出したら、きりが無いのですけどね。地球上には無数の事情があるんですから。
>んでもPascalの場合はある程度環境(ハードウェア)を選ばずに動作することも目指していたわけで、実装がいまよりも
>ずっとハードに依存していたことを考えるとそういう妥協は現実的選択だと思うのですが。
まああの時点ではそんなもんかもですね。
逆にいえば後世までそれを引きずった実装は許し難いものが有りますが。
例えば今でも思い出すたびムカツク(笑)のですが、Delphi ver1のString型は、最大長さが256byteでした。
Win3.1時代でのあの制限はマヂ辛かったです。16bit時代なら文字列だってせめて65534byteにしてくれよ(T_T)。
Re:どんな言語もたどる道 (スコア:1)
>「Pascalはその落ち度を持っている」と言ったツモリであり、
>「その落ち度を持っているのはその言語がPascalだからだ」という差別論を展開したツモリは無いのですけど?
了解。「落ち度」という言葉に過剰反応してしまいました。
>「捨てきれない事情が有るから捨てられません」という話があることを論拠として
>「捨てたいよね。捨てようよ。」という話を不当と呼ぶ、
>のも不当なのではないですか?(^^;
そうですね。それには気付いてなかったです。
>今でも思い出すたびムカツク(笑)のですが、Delphi ver1のString型は、最大長さが256byteでした。
うああああっ。
いつのバージョンか忘れましたが、VBの配列サイズ制限でむかついた記憶が。(笑)
うじゃうじゃ
Re:期待はあるのですが・・・ (スコア:1)
これ、ワタシ逆に気持ち悪くてダメですね(大笑い)。
それに順序依存性がないのも気持ち悪いです(さらに倍)。
便利だし、絶対使っちゃうんですけど、自分は極力forwordっぽい宣言ってのが生理的に気持ち悪いです。
だから、今のObjectPascalよりOberonの方が気持ち良かったりします。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
あ。そういうことですか。ならば(俺も同じ意見かどうかはさておき(^^;)ナットクです。
>それに順序依存性がないのも気持ち悪いです(さらに倍)。
とりあえず俺が思うに、「OOP言語で」依存性が有ると、めちゃ辛いです。
(rubyみたいに一見宣言なものも実は実行である、という言語なら話は別ですが、
あれは逆にシンボルの評価(ってゆーか)がLazyに行われるんで、そもそも困りません。)
一般に手続き同士の「相互(循環)呼出」を、これといった対策なしに使うと、えらいことになりますが、
一般にObject同士の「相互(循環)参照」はなんぼでも有りです。やりまくりです。
この辺の違いが、「OOP言語では」順序の概念を捨てたくなる理由なんじゃないかと思います。
本質的に順序というものとの相性が宜しくない。
単に便利のためだけじゃなくて、必然としてそうある(べき)なんだと思います。
なので、純粋Pascalに対しては、あんまり文句はありませんが、
OOPを導入したタイプの奴には、不満を感じてしまいます。ちなみにC++も全く同じ。
>便利だし、絶対使っちゃうんですけど、自分は極力forwordっぽい宣言ってのが生理的に気持ち悪いです。
「宣言の」順序依存性が無くなれば、そもそもforward宣言は不要になるはず、ですよね。
1passで終わらないのは不愉快だという面もあります(^^;が、まあ重要な利益との引き換えなので…
#逆に、1passに拘って、言語として使い難くなっちゃうほうが、辛いなあ。
>だから、今のObjectPascalよりOberonの方が気持ち良かったりします。
なんか面白い言語らしいですね>Oberon
Re:期待はあるのですが・・・ (スコア:1)
ソレはオブジェクト指向だから、つーよりも、むしろ作法モードが順序依存無しモードに入るからじゃないですか?つまり使っている人間のせいじゃないですか?
私は(好みの性で)極力、forwardっぽい宣言をしないように作ってしまいます。ObjectPascalでもね。<この態度はどうか。
それと、現在はスコープと継承を同時にクラスにしょわせていますけど、本来OOPで重要なのは継承で、スコープ制御はまた別のメカニズムで行う方が自分としては好ましい気がしてます。だもんで、デリゲーション的なメカニズムの方が未来があるようなきがしますねー。(例の「オブジェクト指向は間違っていた!」のアレです)
それはそれとして、Oberonがいいなーと思うのは、pascalってwhile - doは文を囲むのにbegin-endがいるのに、repeat untilはイラン、とか仕様的に凸凹が見えるところが軒並み修正されてますので。
言語仕様的にはCLUとかOberonとかの方が好みにあいますねー。特にCLUはなかなか変態的で楽しい言語です。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:1)
・・・冗談はさて置き、GNU-Cのネスト可能な関数というのは
独自拡張ですか?
C++なら関数オブジェクトにすれば、独自拡張に頼らずに
ネストした関数が作れますよ。
Re:期待はあるのですが・・・ (スコア:1)
今、Javaの中間コードに落とすアプリがあるんですよねー。
JITが効くから使うならこっちかなー。
>・・・冗談はさて置き、GNU-Cのネスト可能な関数というのは独自拡張ですか?
でしょう。
pascalコンパイラをサポートするのに必要だから、入れといたヨ、というハナシです。C派には微妙に迷惑な気も・・・
>C++なら関数オブジェクトにすれば、独自拡張に頼らずに
ネストした関数が作れますよ。
使っている用語がパスカリャーなんで微妙にずれているかもですが、ソレだとpascalのオブジェクトと同じなので微妙に使いたい所と違うです。関数のネスティングって手続きがめったやたらに長くなって、でも括りだして外に書くと引数が長くなるー、という時に手続きの中で関数を定義したりするです。このばーい、親の関数で定義した変数にもアクセス出来るんで・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:期待はあるのですが・・・ (スコア:0)
OS そのものの違いはよくわからないでありますっ!
Re:期待はあるのですが・・・ (スコア:0)
細かいことを言えば、Linux と Hurd はいずれも GNU libc を使う (ことが多い) ので、似てるのかなあ、と。
どのアプリが動くか、ということは、カーネルとは あまり関係ないような気がします。
Re:期待はあるのですが・・・ (スコア:0)
debianは? (スコア:1)
もはや捨てるに捨てられないところまで来てると思うので、GNU/LinuxバージョンとGNU/Hurdバージョンとで並行して進んで行くとは思うのですが。
Re:debianは? (スコア:3, 参考になる)
たとえば、
- マイナーなハードなのでカーネルはNetBSD
- マイクロカーネルが欲しいのでカーネルはHurd
- {Linux, FreeBSD}が好きなのでカーネルは{Linux, FreeBSD}
(- ハード的な制約からカーネルはSolaris、Sunのアプリは嫌い)
(- 上から命令されているのでカーネルは Win32 APIなやつ、あのUIは非生産的)
で、標準インストールされるアプリとその設定は共通。使えるアプリも一緒で、fooアプリが使いたければどのカーネルを使っていようともapt-get install foo一発でOK。こういうのを目指してます。
たとえば、現状ではLiloみたいにLinux固有のアプリじゃないのに、作者がLinux決め打ちで作った為にHurdでコンパイルできなければ、それは致命的なバグとして扱われます。fdiskみたいにアーキテクチャ依存なツールじゃないのに、32bit/64bitを考慮してない為にIA-64/Linuxでコンパイルできなくても致命的なバグ。
Re:debianは? (スコア:1, 参考になる)
Re:debianは? (スコア:1)
まあ、ほんとに故意の FUD なら、訂正に応じてはくれないでしょうが。
Re:debianは? (スコア:1)
debianはカーネルに依存しない、"Linuxディストリビューションだ"と言い切られる事に違和感を感じる、そいういう印象だけは持っていました。この印象の正体はこういうことだったんですね。一安心です。
さて、置き換えるというのをどこで見たかですが、もう2年近く前の記憶なので定かではありません。debian.orgかdebian.or.jpの和訳された文書だったような記憶があるのですが、確認しても見付けられませんでした。当時の誤読だったのかもしれません。
Re:debianは? (スコア:0)
これで (スコア:0)
Re:これで (スコア:0)
「だ~か~ら~、Gnu/Hurdって呼んでくれってば~」
いやいや (スコア:0)
「Richux vs Linux」なんて記事をzdnetあたりに書かれてしまって広まってしまって、
「ちがーう、我々のシステムはGnu/Hurdなのだー」と公式声明を発表する、と。
Re:いやいや (スコア:1)
アレゲつーかナニな人たちが食いついてくれるかも。
# どのみち[GNU]は略される運命だろーなー(涙
高速シリアルI/Oを実現したいなら (スコア:0)
Re:高速シリアルI/Oを実現したいなら (スコア:2, 参考になる)
Hurdどころかそこらの16bitな組み込みですら、ふつーCでアセンブラを使うのはMPUを 初期化したり、MPUを叩かないとダメな固有の機能(キャッシュのsyncとか)叩く時だけ だって位、最近のコンパイラは頭が良くなっていると言うのに…
本当にクリティカルな所以外はアセンブラは使わないようにするのが、多くのプラット ホームで動かしたりコードを使い回したりする時の基本だと思うのですが…
Re:高速シリアルI/Oを実現したいなら (スコア:3, 参考になる)
そういうレベルの話じゃないと思うのですが。
多階層のコンテキストスイッチが避けられないマイクロカーネルじゃ、猛烈な周期で上がってくる割り込みに、堪え切れないって所かな?バッファリングしようにも、APIがバイト単位処理前提になってて、バイト単位のコンテキストスイッチが避けきれないとか。
ちなみに、コンテキストスイッチのオーバヘッドは、状況によってはとてつもなく重くのしかかります。OSにもよるけど、大抵、一回にμsオーダーの時間が掛りますから。
あと、元々シリアル関係のAPI/アプリは、速度が遅い時代に設計されているから、ハードだけが高速になっても、アプリ含めた周辺が対応して無くて、全然パフォーマンスが出ないってのも、結構ありがちです。例えば、1msのイベント契機に最大50バイトしか送信しない設計のアプリじゃ、他がどう頑張っても、400kbps以上出る訳無いですよね?
-- Buy It When You Found It --
Re:高速シリアルI/Oを実現したいなら (スコア:0)
元発言はそんなこと重々承知のことだと思うのだが。たぶん昔のLinuxのことを暗に示唆しているんじゃないの。つまり、理想を追い求めるのも良いけど、実際に「使える」ものにするには、現実に即したダーティさも必要だってこと。それから、Linuxが発展した裏には、みんながすぐに突っ
Re:高速シリアルI/Oを実現したいなら (スコア:0)
>「ここ変じゃない?」なんて、気軽に言える雰囲気じゃない。
DJB教に通じるニュアンスが見て取れますが気のせいですか?
Re:高速シリアルI/Oを実現したいなら (スコア:0)
そこまで読み取れない気がするのは俺だけ?
いまモデレータなんだけど「買いかぶり」のタイミングは
今なのか?
Re:高速シリアルI/Oを実現したいなら (スコア:0)
普及するだろうか? (スコア:0)
ドライバの提供をかなり渋りそうな気がするんだけど・・・
Linuxでさえ、無線系のカードのドライバが出せない状況になって
いるそうだし・・・
そして、マイクロソフトの一人勝ち・・・いーやぁーだぁー
Re:普及するだろうか? (スコア:1, 参考になる)
#転職先を探してる段階なのでAC
どういう理由なんでしょうね (スコア:1)
対応の窓口を用意して社員を張り付かせなければならないからでしょうか。これもやっぱり素人考えにはテキトーにやっておけばいいよう思うんですけどねえ。あ、対応する社員が会社の顔の一つになっちゃうからですかね。
魅力? (スコア:0)
今はFreeBSD的な生活をしていますが、乗換えてしまうだけの
魅力ってどういうものがあるんでしょうか。
GNUなtoolsには大変お世話になっているので、ここは一気に
浸かってしまうのもいいかもしれないですね。
# たぶん、様子ながら移行するであろう軟弱者なので AC
リアルタイムタスク (スコア:0)
Re:海を臨んでどうする。 (スコア:1)
Re:海を臨んでどうする。 (スコア:1)
(これまでも結構気付いていたのだけど、他の人に任せてた)、
こう言う時って晒しコメントにするよりメイルか何かの方が
良いんでしょうか。
こう言うのでコメントツリー浪費するのもなんなので。
ついでに聞いてみました。
Re:海を臨んでどうする。 (スコア:1)
Re:海を臨んでどうする。 (スコア:1)
これも良し悪しで、コメントツリーの頭だけがしきい値以下に沈むと、
「なんだこりゃ」なコメントツリーが出来上がってしまうのですよね。
もっと多くのM1erがいればコメントツリーごとスコア-1にしてしまえるんでしょうが、
現状では解決策になっていません。
Re:海を臨んでどうする。 (スコア:1)
その上で必要以上のコメントを付けてきたら(荒らし -1)とか。
結局M1erに頼ってしまう事になりますが、それら誤字/脱字の指摘等は本来記事の内容とは関係のないものですから、やはりモデレータに-1してもらうのがいいのではないかと。読みたい人だけ読めばいいってことで。
カルマの問題は残りますが、減るのがイヤならACで指摘すればいいんですよねACさん [srad.jp]?
Re:海を臨んでどうする。 (スコア:1)
Re:海を臨んでどうする。 (スコア:0)
ACで書く必要がありそうですね :)
もっとサブジェクト(タイトル)を活用しようよ。 (スコア:1, 参考になる)
それを見た運営者側は「修正しました」というタイトルで返信を書く
ようにすれば良いんじゃないでしょうか?
別に無理して(-1)してなくても,タイトルを見て読み飛ばせば良い
でしょうから。
もちろん,slashcodeを大幅に改良して対処するのが一番良いでしょう
けどね。…とりあえず,現実的に今すぐ出来る方法を提案してみました。
Re:海を臨んでどうする。 (スコア:0, おもしろおかしい)