アカウント名:
パスワード:
Gnome標準にするってのはわからなくもないわけですよ。Gnome周りのコンポーネントに依存してるアプリが多いのも事実だしね。ただこのさまざまな条件を検討した結果 [debian.org]ってのは、一体なんなんです?
tasksel task qualityからしておかしいよね。まあ100歩譲って、GnomeのXfceが+1なのは許すよ。だけどkdeが0ってのは何なの? mateやcinnamonに至っては-1って何なんです?そんなに優位な差がどこにあるの? どう見ても50歩100歩にしか見えんのだけど。
accessibilityも何を評価してんだか分からんよね。xfceやlxdeを差し置いて、kdeは-1ですもんね。kdeがlxde以下の評価とかびびるわー。
systemd integrationに至ってはもう、iPhoneクオリティのネタ画像を彷彿とさせるよね。なにこのレンガで殴っても壊れません的な無意味な評価項目?そのリストに入ってる中で、「systemdじゃなきゃ動きません」ってのがGnomeだけの話だろ?どうしてその欠点が評価されてんの? 「systemdでも動くけど、別にそれ以外でも動きますよ。」ってのがどうしてマイナス評価なの?
そもそも、皆は辟易してるんじゃないのかな? 下らない標準争いにさぁ。ESounDが標準とかのたまってたかと思えば、gstreamerでALSA直がどうとかのたまって、結局そのgstreamerさえグダグダになってきてPhononかまして利用してるとか。DCOPこそ至高とかほざいてた癖に、気がついたら後継のdbusに移行してねとか始まって、挙句の果てにはsystemdに融合するからとかやりだしたり。そういう下らない標準争いに、皆辟易してるんだと思うよ。Gnome以外のsystemd integrationが低いのはそういうこと。皆こう思ってるんだよ、どうせまたすぐ変わるだろうって。おれおれ標準詐欺に右往左往させられるのはGnomeだけで良いってさ。
# まあ何が一番おかしいって、accessibilityがマイナス評価な分、kdeがlxde以下の評価ってことだよね。# どこの盲に評価させたらそんな結果になるの?
リンク先のページの中身をマトモに読んだ上でそーゆー発言になってるの?
tasksel task qualityってのは何か各言語へのローカライゼーションとかに関連するものみたいなんだけど、(つか自分はこんなものの存在を今初めて知ったので、どーゆーものなのかはあんまりわかってない)それのクオリティを総合的に判断した上でそんな評価してるの?
# 自分はKDE日本語化に結構苦労した記憶があるけど、# task-japanese-kde-desktopをいれてたら一瞬で終わったのだろうか…orz
ちなみにmateやcinnamonのtaskについてはまだ新しすぎるからテストをきちんとしたわけじゃない、でも明らかな問題もあるし、とりあえず評価を低くしておくよ、と一応理由も書いてあるよ。それを読んだ上でそのコメントなの?
systemdについては標準に採用されるんだから、是非はともかくとして、そりゃデスクトップ環境側も問題発生させちゃダメだから、評価基準に挙げられてもしょうがないでしょう。そして、Gnomeのsystemd対応は申し分なかったから+1でXfceはその時に問題あったから-1(もう直ってるっぽい)、Mateはその時マイナーな問題があったから、0になってるということな気がする。
この評価が妥当かどうかは別にして、少なくとも明示的に書いてある理由は読むべきじゃない?そして、この項目についてKDE他の評価が空なのはデスクトップ環境のメンテナもsystemdのメンテナも両方とも回答をしてないから。
んで、accessibilityの評価について何か不満があるならもっと具体的に書けば?そのaccessibilityってのがどーゆー観点での評価なのかを明示的に書いた上で。あと検討項目が不適切だと思うんなら、代わりにどういう項目が妥当であるかでも書いてみたら?
> だけどkdeが0ってのは何なの?
KDEはC++が(主要な)開発言語だから。C++はちゃんと勉強しないと罠が多い言語でOSSのプロジェクトで使うには不向きだと思われる。
Cでやると標準ライブラリで可変長バッファをサポートしないわ、ランタイムに生のポインタを渡しまくるわ、例外処理機構がないので無数のIF文が増殖するわでセキリティと堅牢性の問題が出やすい。
ユーザーランドでC言語を使うのは時間と労力を浪費してる。
それはC++に対する反論なのか?多分、CとC++の両方だろうけど。
> Cでやると標準ライブラリで可変長バッファをサポートしないわ、realloc()は可変長バッファとは言わないの?まぁ、標準ライブラリは貧弱だから、GTK+で作る時はベースになってるglibを使うし、滅茶苦茶便利だよ。一度glibのリファレンスを見てみるといいよ。
> ランタイムに生のポインタを渡しまくるわ、生のポインタを渡すこと自体はなんの問題もない。問題は解放済みのポインタを使っちゃう事だけど、それは開発中に簡単に検出出来るよ。
> 例外処理機構がないので無数のIF文が増殖するわで例外機構は必須じゃないよ。コンシューマーゲームってC++で作られるのがほとんどだけど、ほぼ100%例外処理は使われてないけど特に問題ないよ。
> セキリティと堅牢性の問題が出やすい。これは確かに問題が出やすいけど、やっぱりチェックする方法はある。
他にもメモリリークの検出とかも出来るし、徹底的にチェックしようと思えばむしろスクリプト言語より徹底的にチェック出来る。まぁ、そういう技法はあまり知られてないのかな?
OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。
つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。それなのに理由が「KDEはC++が(主要な)開発言語だから」って論理が飛躍しすぎ。
> OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。OSSプロジェクト全体で見ると実際少ないと思うよ。特にソースはないけど…(ほとんどのプロジェクトはC言語な事がソースとも言える)その3つのプロジェクトははっきり言って少数のフルタイム開発者が主要な部分を開発してるから、問題が無いと思われる。
> つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。そこまでは把握できてなかった。それだと確かに開発環境とは関係ないと思う。
> ほとんどのプロジェクトはC言語な事がソースとも言える
ダウト。プロジェクト、っていうか、ライブラリ系は移植性の問題があるからC言語が圧倒的に多い。だから、普通の開発者はCで書けるならちょっとくらい不便でも(利用者のために)Cで書こうとする。しかし、ある程度複雑になってくるとそうも言ってられないから、製品はC++で、ってパターンが多い。プロジェクトから「ライブラリのみのプロジェクト」を除いて集計すると、C++の圧勝じゃないかな。
まあ変だよね。評価結果。で、それ見て俺的にはああこれがDebianだよなという評価しちまった内側で殴り合ってユーザーがどうなのかは蚊帳の外の連中のイメージ好きでやってるのだろうから、やりたいことやればいいとは思うけど俺は使わない、使わなくてよかったと改めて思ったページだったよ
accessibilityって言葉の意味を知らないのかな?KDE Accessibility Projectは死体も同然。
https://docs.kde.org/stable/en/kdeaccessibility/ [kde.org]
だって、APIがクソだからね。この点ではATKが断然先行している。KDEはATKに追従すべきじゃないかな。
>tasksel task qualityからしておかしいよね。>まあ100歩譲って、GnomeのXfceが+1なのは許すよ。>だけどkdeが0ってのは何なの? mateやcinnamonに至っては-1って何なんです?>そんなに優位な差がどこにあるの? どう見ても50歩100歩にしか見えんのだけど。tasksel(使用目的に応じて、アプリケーションをまとめてインストールするためのアプリ)に対応してどの程度メンテナンスできているか?っていう質問なんじゃないの?要は、メンテナがどの程度がんばっているかとか、メンテしやすいかとかでしょ?
どれかのアプリを採用して、それをメンテナンスするようにみんなが頑張る。っていう方向じゃなくて、現時点でdebianにおいてきちんとメンテナンスされている&これからもメンテナンスされそう、っていうのが評価基準なんだろうから、使い勝手は関係ないでしょ。
ネタなのか本気なのか、どちらなんだ
bot説
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
検討結果が作為的すぎる (スコア:5, 参考になる)
Gnome標準にするってのはわからなくもないわけですよ。
Gnome周りのコンポーネントに依存してるアプリが多いのも事実だしね。
ただこのさまざまな条件を検討した結果 [debian.org]ってのは、一体なんなんです?
tasksel task qualityからしておかしいよね。
まあ100歩譲って、GnomeのXfceが+1なのは許すよ。
だけどkdeが0ってのは何なの? mateやcinnamonに至っては-1って何なんです?
そんなに優位な差がどこにあるの? どう見ても50歩100歩にしか見えんのだけど。
accessibilityも何を評価してんだか分からんよね。
xfceやlxdeを差し置いて、kdeは-1ですもんね。
kdeがlxde以下の評価とかびびるわー。
systemd integrationに至ってはもう、iPhoneクオリティのネタ画像を彷彿とさせるよね。
なにこのレンガで殴っても壊れません的な無意味な評価項目?
そのリストに入ってる中で、「systemdじゃなきゃ動きません」ってのがGnomeだけの話だろ?
どうしてその欠点が評価されてんの? 「systemdでも動くけど、別にそれ以外でも動きますよ。」ってのがどうしてマイナス評価なの?
そもそも、皆は辟易してるんじゃないのかな? 下らない標準争いにさぁ。
ESounDが標準とかのたまってたかと思えば、gstreamerでALSA直がどうとかのたまって、結局そのgstreamerさえグダグダになってきてPhononかまして利用してるとか。
DCOPこそ至高とかほざいてた癖に、気がついたら後継のdbusに移行してねとか始まって、挙句の果てにはsystemdに融合するからとかやりだしたり。
そういう下らない標準争いに、皆辟易してるんだと思うよ。
Gnome以外のsystemd integrationが低いのはそういうこと。
皆こう思ってるんだよ、どうせまたすぐ変わるだろうって。
おれおれ標準詐欺に右往左往させられるのはGnomeだけで良いってさ。
# まあ何が一番おかしいって、accessibilityがマイナス評価な分、kdeがlxde以下の評価ってことだよね。
# どこの盲に評価させたらそんな結果になるの?
Re:検討結果が作為的すぎる (スコア:5, 参考になる)
リンク先のページの中身をマトモに読んだ上でそーゆー発言になってるの?
tasksel task qualityってのは何か各言語へのローカライゼーションとかに関連するもの
みたいなんだけど、(つか自分はこんなものの存在を今初めて知ったので、どーゆーもの
なのかはあんまりわかってない)それのクオリティを総合的に判断した上でそんな評価してるの?
# 自分はKDE日本語化に結構苦労した記憶があるけど、
# task-japanese-kde-desktopをいれてたら一瞬で終わったのだろうか…orz
ちなみにmateやcinnamonのtaskについてはまだ新しすぎるからテストをきちんとしたわけ
じゃない、でも明らかな問題もあるし、とりあえず評価を低くしておくよ、と一応理由も
書いてあるよ。それを読んだ上でそのコメントなの?
systemdについては標準に採用されるんだから、是非はともかくとして、そりゃデスクトップ
環境側も問題発生させちゃダメだから、評価基準に挙げられてもしょうがないでしょう。
そして、Gnomeのsystemd対応は申し分なかったから+1でXfceはその時に問題あったから
-1(もう直ってるっぽい)、Mateはその時マイナーな問題があったから、0になってるという
ことな気がする。
この評価が妥当かどうかは別にして、少なくとも明示的に書いてある理由は読むべきじゃない?
そして、この項目についてKDE他の評価が空なのはデスクトップ環境のメンテナもsystemdの
メンテナも両方とも回答をしてないから。
んで、accessibilityの評価について何か不満があるならもっと具体的に書けば?
そのaccessibilityってのがどーゆー観点での評価なのかを明示的に書いた上で。
あと検討項目が不適切だと思うんなら、代わりにどういう項目が妥当であるかでも書いてみたら?
Re:検討結果が作為的すぎる (スコア:2)
> だけどkdeが0ってのは何なの?
KDEはC++が(主要な)開発言語だから。
C++はちゃんと勉強しないと罠が多い言語でOSSのプロジェクトで使うには不向きだと思われる。
Re: (スコア:0)
Cでやると標準ライブラリで可変長バッファをサポートしないわ、
ランタイムに生のポインタを渡しまくるわ、
例外処理機構がないので無数のIF文が増殖するわで
セキリティと堅牢性の問題が出やすい。
ユーザーランドでC言語を使うのは時間と労力を浪費してる。
Re:検討結果が作為的すぎる (スコア:2)
それはC++に対する反論なのか?多分、CとC++の両方だろうけど。
> Cでやると標準ライブラリで可変長バッファをサポートしないわ、
realloc()は可変長バッファとは言わないの?
まぁ、標準ライブラリは貧弱だから、GTK+で作る時はベースになってるglibを使うし、滅茶苦茶便利だよ。
一度glibのリファレンスを見てみるといいよ。
> ランタイムに生のポインタを渡しまくるわ、
生のポインタを渡すこと自体はなんの問題もない。
問題は解放済みのポインタを使っちゃう事だけど、それは開発中に簡単に検出出来るよ。
> 例外処理機構がないので無数のIF文が増殖するわで
例外機構は必須じゃないよ。
コンシューマーゲームってC++で作られるのがほとんどだけど、ほぼ100%例外処理は使われてないけど特に問題ないよ。
> セキリティと堅牢性の問題が出やすい。
これは確かに問題が出やすいけど、やっぱりチェックする方法はある。
他にもメモリリークの検出とかも出来るし、徹底的にチェックしようと思えばむしろスクリプト言語より
徹底的にチェック出来る。
まぁ、そういう技法はあまり知られてないのかな?
Re: (スコア:0)
OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。
つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。それなのに理由が「KDEはC++が(主要な)開発言語だから」って論理が飛躍しすぎ。
Re:検討結果が作為的すぎる (スコア:2)
> OSSのプロジェクトに絡んでいる人はC++をちゃんと学んでいる人が少ないと言いたいのかな?WebkitとかGeckoとかMySQLとか怖くて使えないね。
OSSプロジェクト全体で見ると実際少ないと思うよ。特にソースはないけど…(ほとんどのプロジェクトはC言語な事がソースとも言える)
その3つのプロジェクトははっきり言って少数のフルタイム開発者が主要な部分を開発してるから、問題が無いと思われる。
> つうか、そもそもtasksel task qualityはtaskselのメンテナがしっかり仕事をしているかを評価したものに過ぎず、開発環境について評価したものではない。
そこまでは把握できてなかった。それだと確かに開発環境とは関係ないと思う。
Re: (スコア:0)
> ほとんどのプロジェクトはC言語な事がソースとも言える
ダウト。
プロジェクト、っていうか、ライブラリ系は移植性の問題があるからC言語が圧倒的に多い。だから、普通の開発者はCで書けるならちょっとくらい不便でも(利用者のために)Cで書こうとする。しかし、ある程度複雑になってくるとそうも言ってられないから、製品はC++で、ってパターンが多い。プロジェクトから「ライブラリのみのプロジェクト」を除いて集計すると、C++の圧勝じゃないかな。
Re: (スコア:0)
まあ変だよね。評価結果。
で、それ見て俺的にはああこれがDebianだよなという評価しちまった
内側で殴り合ってユーザーがどうなのかは蚊帳の外の連中のイメージ
好きでやってるのだろうから、やりたいことやればいいとは思うけど
俺は使わない、使わなくてよかったと改めて思ったページだったよ
Re: (スコア:0)
accessibilityって言葉の意味を知らないのかな?KDE Accessibility Projectは死体も同然。
https://docs.kde.org/stable/en/kdeaccessibility/ [kde.org]
だって、APIがクソだからね。この点ではATKが断然先行している。KDEはATKに追従すべきじゃないかな。
Re: (スコア:0)
>tasksel task qualityからしておかしいよね。
>まあ100歩譲って、GnomeのXfceが+1なのは許すよ。
>だけどkdeが0ってのは何なの? mateやcinnamonに至っては-1って何なんです?
>そんなに優位な差がどこにあるの? どう見ても50歩100歩にしか見えんのだけど。
tasksel(使用目的に応じて、アプリケーションをまとめてインストールするためのアプリ)に対応してどの程度メンテナンスできているか?
っていう質問なんじゃないの?
要は、メンテナがどの程度がんばっているかとか、メンテしやすいかとかでしょ?
どれかのアプリを採用して、それをメンテナンスするようにみんなが頑張る。っていう方向じゃなくて、現時点でdebianにおいてきちんとメンテナンスされている&これからもメンテナンスされそう、っていうのが評価基準なんだろうから、使い勝手は関係ないでしょ。
Re:Gnome周りのコンポーネントに依存してるアプリが多いのも事実だしね (スコア:3)
ネタなのか本気なのか、どちらなんだ
Re: (スコア:0)
bot説