アカウント名:
パスワード:
その理屈でいくと、オープンソースじゃないOSを使えばこんな発言 [srad.jp]やあんな発言 [srad.jp]は出てこない、ということになりませんか？
あくまでリンクは参照ないし関連づけであって，リンク文字列はリンク先の内容を簡潔に表しておくべきだ，とされています。
例えば，本で「こんな事実（P.45）もありましたよね。」などと書かれていたら不愉快ではありませんか？ 「『こんな』じゃなくて何か書いてくれたら思い出すかもしれないのに」と思いませんか？
「あれ」とか「こんな○○」といったアンカーは閲覧者側に，本来不要であったかもしれない通信を強いることになり，よろしくないのです。ナローバンド環境では「クリックする楽しみ」が「クリックする苦しみ」であるかもしれません（そもそもリンク先に移動する操作が「クリック」であるかどうかは不定ですが）。あるいは，今回のような参照の場合，別ウィンドウを開いて見るのは自然でしょうが，新しくウィンドウを開くにはリソースが足りなくてヤバいという場合もあるかもしれません。実際，私の場合，/.Jは開くまでにやや時間がかかり（ISDNですので），移動回数はなるべく少なくしたいというのが正直なところです。
先ほどの本の例でも同じように，「『こんな』じゃなくて何か書いてくれ」と考えるのは自然なことだと思います。
俺は逆に、クリックすれば簡単にRemoteを手繰って読めるものをいちいちLocalにも書くのは、ダサいと思っています。
私は、上に述べたような理由により、リンク文字列をきちんと記述することが洗練されていると考えます。少なくとも，「クリックする楽しみ」という考え方はwebには馴染まないと思います。
# オプトピックな上に不毛な議論＋長文で申し訳ない。
しつこいと思われるかもしれませんが，突っ込みどころが散見され，放置できなかったもので…。
なぜ「不毛な議論」と言ったか
このような議論の場合，たいていはこちらの主張を受け入れてもらえず，説得することが不可能であるからです。
「簡潔に要約」に関して
大抵の文書にはタイトルが付いてるでしょうから，それを流用すればほとんどの場合は問題になりません。また，そのリンク文字列が言葉足らずだとしても，全くないよりはましでしょう。
あと，「要約」というのはいささか不適切な表現であると思われます。数字～十数字程度で文書の内容を言い表すのですから，タイトル付けといったところでしょう（要約と言うと文章というイメージを受けます）。
本の例えに関して
本を持ち出したのは，本でもwebでも「他のページをいちいち見に行く手間が面倒だ」と言いたかったのです。ですので「一度見に行けば覚えられるから大丈夫だ」というのはやや的はずれで，その「一度見に行く手間」を省けるようにしよう，と言いたかったのです。この辺の主張はこちらがやや言葉足らずだったかもしれません。申し訳ない。
ちなみに，TeXは元々組み版のために作られたソフトウェアですので，脚注があるのはごくごく当たり前の話です。
洗練されてる，されてない
そもそも，webのユーザビリティの概念は誰にでもアクセスしやすいようにしようという考え方ですので，環境が整ってない奴は我慢しろという考えは根本的にありません。誰にでもアクセシブルにすることでみんなでハッピーになろうということです。
「別ウィンドウを開くのは…」の話に関して
この話を挙げたのは，結局は「世の中には色々な環境の人がいるんだよ」ということを言いたかったためです。webは，何もPC上のブラウザだけから利用される訳ではありません。携帯電話やPDAからでも見ることができますし，もっと言えば検索エンジンの巡回ロボットなどもwebを利用していると言えます。どんな環境でも快適に閲覧（ないし利用）できるようにすればみんなハッピーになるだろうという訳です。
あと，ここで「リソース」という言葉を使ってしまったのは私のミスです。うっかりWindows環境のみを想定した物言いをしてしまいました。申し訳ありません。
長文申し訳ありません。これで説得できなかったら諦めます。
そこまで面倒見られる業者なんか、ほんの一部だと思うんだが？
20年前の常識なんぞ持ち込んで欲しくないね。
現在の常識も20年前とそれ程かわっていないとおもわれ
あと、責任については発注金額が高い分メーカーがOSに手を入れてくれるぐらいしてくれる。まあ責任をお金でかっているだけですけど。昔から。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
Everybody's Business is Nobody's Business (スコア:2, 興味深い)
バグが発見されて、パッチが公開されたとして、そのパッチをあてる責任は誰になるのでしょう。
パッチが公開されたと言っても、例えばLinuxであれば、そのディストリビューションのサイトでパッチが公開されていない場合、管理者にパッチをあてる責任はあるのでしょうか？
権威のないサイトから取ってきたパッチに信用性はあるのでしょうか？
権威のあるサイトが書き変えられてはいないでしょうか？
パッチの内容を検証をする責任は誰が負うのでしょうか？
パッチが未公開の場合、作成する義務があるのでしょうか？
そういう責任を明確化しなければ、そうとう危険な気がします。
しかし、UNIXであれば、スーパーユーザーを持つ「管理者」に相当大きな負担がかかりそうです。
責任を明確化すると誰もやりたがらなくなるかもしれません。
うち大学でも、未だに重大なセキュリティホールのあるapacheやsshなどを使って、安全そうな顔をして平気でいます。
管理者がぼーっとしていて、踏台に使われることもしばしばあるようです。
それでも責任はちっとも明確化されていません。
もちろんこれはオープンソースのソフトウェアに限った問題ではありません。
安全性が高いから、とかコストが安いから、とか言う前に、責任の所在をはっきりしてほしいものです。
と言っても、縦割りの官僚社会の中では理系はとにかく責任を負いたくないし、文系は責任を負わせようにも、中身のことがわからんから何も言えんのやろうけど。
やれやれ
------------------------- Excess and Obsolete
ほほぅ (スコア:4, すばらしい洞察)
その理屈でいくと、オープンソースじゃないOSを使えばこんな発言 [srad.jp]やあんな発言 [srad.jp]は出てこない、ということになりませんか？
Re:ほほぅ (スコア:0)
リンクをクリックすればいいのはもちろんわかるのですが、
「こんな発言」「あんな発言」だけではなくて、もう少し
わかりやすくして頂けると嬉しいです。
(webユーザビリティ的にもアレかと)
Re:ほほぅ (スコア:1)
私の言いたかったことは、zymaseさんがおっしゃった「みんながハッピー」に集約されてます。
ただ、G7さんのおっしゃってる内容もわかります。
要約を書く書かないのどちらが正しいかなんて私にはわかりませんが、基準というか論点をどこに置くかで答えが変わってしまうのかもしれません。
私は、どっちが人にやさしいかという基準で、要約があったほうがいいなと思った次第です。
Re:ほほぅ (スコア:3, すばらしい洞察)
あくまでリンクは参照ないし関連づけであって，リンク文字列はリンク先の内容を簡潔に表しておくべきだ，とされています。
例えば，本で「こんな事実（P.45）もありましたよね。」などと書かれていたら不愉快ではありませんか？ 「『こんな』じゃなくて何か書いてくれたら思い出すかもしれないのに」と思いませんか？
「あれ」とか「こんな○○」といったアンカーは閲覧者側に，本来不要であったかもしれない通信を強いることになり，よろしくないのです。ナローバンド環境では「クリックする楽しみ」が「クリックする苦しみ」であるかもしれません（そもそもリンク先に移動する操作が「クリック」であるかどうかは不定ですが）。あるいは，今回のような参照の場合，別ウィンドウを開いて見るのは自然でしょうが，新しくウィンドウを開くにはリソースが足りなくてヤバいという場合もあるかもしれません。実際，私の場合，/.Jは開くまでにやや時間がかかり（ISDNですので），移動回数はなるべく少なくしたいというのが正直なところです。
先ほどの本の例でも同じように，「『こんな』じゃなくて何か書いてくれ」と考えるのは自然なことだと思います。
私は、上に述べたような理由により、リンク文字列をきちんと記述することが洗練されていると考えます。少なくとも，「クリックする楽しみ」という考え方はwebには馴染まないと思います。
# オプトピックな上に不毛な議論＋長文で申し訳ない。
Re:ほほぅ (スコア:1)
「楽しみ」は冗談だとしても(笑)、実際、そこに書かれた簡潔な要約って奴はかなりの頻度で
「不十分な要約」でしかなかったり、更にいえば「主観も入っていて不正確な(=過不足の有る)要約」
だったり、という問題に悩まされます。
そんなもんに悩まされるくらいなら、いっそそれらを捨てるほうが「洗練されてる」と、俺は思います。
>私は、上に述べたような理由により、リンク文字列をきちんと記述することが洗練されていると考えます。少なくとも，「クリックする楽しみ」という考え方はwebには馴染まないと思います。
また、通信環境にお互い苦労させられる(俺もAirH"ですし)のも、つまりは「洗練されてない」ことの一端なわけでして、
迂回策を我々が実践するのは「洗練されてない」といえます。
なので逆に「洗練「されるまでは」待って(=旧来方式でやって)くれ」というなら、まだ判りますけど。
># オプトピックな上に不毛な議論＋長文で申し訳ない。
「不毛」たぁなんですか？(苦笑)
>例えば，本で「こんな事実（P.45）もありましたよね。」などと書かれていたら不愉快ではありませんか？
電子化されてない本は一緒にならん、と思います。
電子ブックにでもなったら話は「がらっと」変わると思います。
尤も、電子ブック全盛の暁になっても旧態依然としたスタイルを大衆は継承してしまう恐れは十分有りますが。
そういう意味では、TeXとか(RDとか?)に脚注機能なんかが有るのは、
「あぁ、紙(の都合と文化)に合わせるための退化だな」と感じています。
別んとこに飛ばしてくれたほうが「美しい」のに、それが出来ない(やると不便になる)のは
紙の限界のせいであって、計算機や人間のせいではない。
つまり、そういう機能をなくしてくれるほうが良いなぁと思うのね(笑)。てゆーかペーパーレス。
あっちへ飛べば読めるものを、わざわざこっちにも書くのは、本質的にお洒落じゃないと思いますよ。
限界を克服して、そういうお洒落が出来るようになる未来が、早く来て欲しいものです。
>「『こんな』じゃなくて何か書いてくれたら思い出すかもしれないのに」と思いませんか？
ご安心ください。本ってのは、直接の文字列以外の情報をも以って、人に記憶をせしめるものでございます。
手垢の位置とかでも覚えちゃうんだよね、どこに何があったかを。
逆にいえば、初回ならばP123と書いてあったらP123を見に行くのが一番確実ですし、
次回からはP123を「見るまでもなく」その内容を「思い出す」ことでしょう。
それを、いちいち毎度要約されて字数稼がれてるの(笑)は、時として不愉快です。
紙じゃなく電子データについては上に書いたので略します。
ま、もっと見易いDisplayと、「ユーザの(書籍へと同様な)書き込み」がしやすいソフト環境と、の整備が急務だとは思いますけど。
>新しくウィンドウを開くにはリソースが足りなくてヤバいという場合
そこまで気にする状況だと、もう他の作業は出来ませんね。
エディタを開く余地も無いほどの状況でWebを読む(何か興味深いことがあったら
それをメモったりコメント書いたりするためにエディタ上げますんで)のは、そもそもナニです。
ちなみに、リソース…これも色々な意味が有る語で厄介ですが、ここではWinで言う意味のを採りましょう…を
消費するとは限らないですね。それはブラウザの実装次第。
単一の窓を内容だけ切り替えて使うようにすりゃ「リソース」は消費しないわけで。
もちろん「リソース」の意味が何か別のものになったとしても、大抵は相変わらず
「リソースを使いまわして節約する」術が有るものです。
で、最後のリソース(^^;であるところのDiskすら不足してる状況では、ブラウズなんて…
（スコア:-2, オフトピック+しつこい） (スコア:1)
しつこいと思われるかもしれませんが，突っ込みどころが散見され，放置できなかったもので…。
なぜ「不毛な議論」と言ったか
このような議論の場合，たいていはこちらの主張を受け入れてもらえず，説得することが不可能であるからです。
「簡潔に要約」に関して
大抵の文書にはタイトルが付いてるでしょうから，それを流用すればほとんどの場合は問題になりません。また，そのリンク文字列が言葉足らずだとしても，全くないよりはましでしょう。
あと，「要約」というのはいささか不適切な表現であると思われます。数字～十数字程度で文書の内容を言い表すのですから，タイトル付けといったところでしょう（要約と言うと文章というイメージを受けます）。
本の例えに関して
本を持ち出したのは，本でもwebでも「他のページをいちいち見に行く手間が面倒だ」と言いたかったのです。ですので「一度見に行けば覚えられるから大丈夫だ」というのはやや的はずれで，その「一度見に行く手間」を省けるようにしよう，と言いたかったのです。この辺の主張はこちらがやや言葉足らずだったかもしれません。申し訳ない。
ちなみに，TeXは元々組み版のために作られたソフトウェアですので，脚注があるのはごくごく当たり前の話です。
洗練されてる，されてない
そもそも，webのユーザビリティの概念は誰にでもアクセスしやすいようにしようという考え方ですので，環境が整ってない奴は我慢しろという考えは根本的にありません。誰にでもアクセシブルにすることでみんなでハッピーになろうということです。
「別ウィンドウを開くのは…」の話に関して
この話を挙げたのは，結局は「世の中には色々な環境の人がいるんだよ」ということを言いたかったためです。webは，何もPC上のブラウザだけから利用される訳ではありません。携帯電話やPDAからでも見ることができますし，もっと言えば検索エンジンの巡回ロボットなどもwebを利用していると言えます。どんな環境でも快適に閲覧（ないし利用）できるようにすればみんなハッピーになるだろうという訳です。
あと，ここで「リソース」という言葉を使ってしまったのは私のミスです。うっかりWindows環境のみを想定した物言いをしてしまいました。申し訳ありません。
長文申し訳ありません。これで説得できなかったら諦めます。
Re:ほほぅ (スコア:0)
Re:ほほぅ (スコア:0)
Re:（スコア:-2, オフトピック+しつこい） (スコア:1)
「(目の前の俺の)説得」なんかが目的だったんですか？随分短気でらっしゃいますね…。
俺のほうは、こいつはもっと息の長い問題だと思っているんですけど。
人々の考えを改めさせる(ぉ)のには時間はかかるでしょうから。
>そのリンク文字列が言葉足らずだとしても，全くないよりはましでしょう。
それは幻想です。
まあそれに比べれば「タイトルがあれば流用すればいい」はまだしもマシですね。自分の判断が入る余地が無い分だけ。
>ちなみに，TeXは元々組み版のために作られたソフトウェアですので，脚注があるのはごくごく当たり前の話です。
もちろん。「組み版」というもの自体に隠居して頂くのが将来的な理想だ、という話です。
>・ 洗練されてる，されてない
>そもそも，webのユーザビリティの概念は誰にでもアクセスしやすいようにしようという考え方ですので，環境が整ってない奴
>は我慢しろという考えは根本的にありません。誰にでもアクセシブルにすることでみんなでハッピーになろうということです。
その発想をこの話題に適用すると、そもそもLinkというコストの高い仕組みがWebに有ること自体が
アンハッピーの種だ、という話になってしまうんで…
「それにも関わらず」Linkというものを持ち込んでしまった、のがWebの素晴らしい点なわけです。
そうでなきゃmailとftpで事足りてたんです(藁
>どんな環境でも快適に閲覧（ないし利用）できるようにすればみんなハッピーになるだろうという訳です。
ほぉ？では、貴方のいうやり方が「どんな環境でも」快適をもたらすものだ、と言い切れるんですね？
俺は我慢しろなどと言った覚えはありません。
タイトルだかなんだかを取り出したとしても、そもそも情報の本体は結局はLink先に有るんでしょうから、
我慢もへったくれもなくそっちは最終的(あるいは最初)にアクセスせざるを得ないのは同じことです。
その情報を見るつもりがそもそもあるならば、ですが。#ないならばこういう議論とは無関係。
ちょろっと書かれたタイトルだけで「判ったつもり」になられるのが、却って怖い(うざい)、という面が結構有りましてね。
アクセシビリティといえば聞こえがいいですが、サブセット情報が半可通を生む現実を思うと、ちょっとどうかと…
すらっしゅこんまじゃぽん (スコア:2, おもしろおかしい)
すらっしゅこんまじゃぽん
アレゲなニュースと雑談サイト
今日はメタモデレート してますか?
こんな内容
Woliver による 200x年xx月xx日 xx時xx分 の投稿
こんな内容[xxxxxx.co.jp]
( もっと読む… | 5 コメント )
そんな内容
Woliver による 200x年xx月xx日 xx時xx分 の投稿
そんな内容[xxxxxx.org]
( もっと読む… | 29 コメント )
あんな内容
yourDog による 200x年xx月xx日 xx時xx分 の投稿
あんな内容[xxxxxx.go.jp]
( もっと読む… | 11 コメント )
～～～～～～～～～～
どんな内容？
Re:すらっしゅこんまじゃぽん (スコア:1)
>yourDog による 200x年xx月xx日 xx時xx分の投稿
>
> あんな内容[xxxxxx.go.jp]
>
>( もっと読む… | 11 コメント )
>
>
>～～～～～～～～～～
>
>どんな内容？
ん？これは何をどう評価して欲しいのだろう？
「内容」が1行しかなくしかも本文も事実上無い、という点を評価して欲しいんだろうか？
それともそういうものにコメントやモデ点数をつけたりする際の指標を欲しいんだろうか？
それとも内容そのものが何であるかを俺に問いたがってるんだろうか？
俺の答えは決まってます。「好きにしてください」「好きに考えてください」。
#そんなこと(どれであるにせよ)も、いちいち人に問わずに居られないのですか？
Re:すらっしゅこんまじゃぽん (スコア:0)
しかし、めんどくさいなぁ。
このコメント自体もも別のところに置いて、リンクするわけですか？（ｗ
Re:すらっしゅこんまじゃぽん (スコア:1)
「既に別の頁に存在するもの」はLinkするのが一番自然＆スマートでしょ、と言ってるだけだけど？
わざわざ別出しにしろ、とは言ってないっすよ？
----
引用とLinkは別。おわかり？
URLが、既存頁の「任意の部分の切り出したもの」を指すことが出来る仕様になっていたら、話はまたちょっと違ってきたんだけど、
まぁ現実はそうなってないので。
ここ (スコア:1)
たとえばあるトピックへのコメントとして、「ここ」と書かれたリンクだけがあったら、あなたはクリックしますか? こんなコメントがあったら、たとえリンク先の情報がとても有用だったとしても萎え萎えです。
Re:ほほぅ (スコア:0)
>いちいちLocalにも書くのは、ダサいと思っています。
寒い
システムを受註したメーカーの責任 (スコア:4, 参考になる)
政府がシステムを導入する場合、OS、DB、アプリケーションサーバーを
コンポーネントで買ってきて自分で組み立てて使うなんてはずはなく、
システムインテグレータを呼んできて入札するわけですよね。
そのとき「OS はオープンソースのものでも OK よ～ん」という条項が
つくって話でしょう。
元もと、納入したシステムにバグが出たとしたら、そのバグの原因が
コンポーネントの一部にあるとしても、顧客に対する責任は納入した
業者にあるでしょう。これは MS-Windows を使おうが、Linux を使お
うが同じ話で、顧客にすぎない官僚には責任はないでしょう。
バグフィックスやアップデートも、サポート契約を結んで納入した業者
にやらせるのものでしょうし、やらせるべきです。
コンタミは発見の母
ベンダーの機会 (スコア:3, すばらしい洞察)
ただ納品した製品で使われているOSやミドルウェアのほとんどに自社で手を入れられるとしても、実際に手をかけられるのは、IBMやNECのような大企業のみかもしれません。
BSD系やGNUなどのソフト採用の機会を増やすなら、中小ベンダーや個人などにもチャンスが広がるような手だてを尽くしてほしいです。
あ、私はこの場合、ユーザーの側にたつ人間です。(^_^;)
ただ今までの公共投資って、おいしいところが地元の人たちにわたってないような感じがします。今後、投資が伸びると思われるIT関連では、政府や自治体の公共投資のできるだけ多くを直接、働いている人に渡るような方針で行うべきだと思います。
Re:ベンダーの機会 (スコア:0)
んで、公共投資が地域の企業にうまく配分されるためには、
まず、政治を地方自治へ分散化するのが先決だとも思います。
運用上の穴は誰の責任？ (スコア:1)
で、運用は業者が全てやるとは限らんのだよな
そこまで面倒見られる業者なんか、ほんの一部だと思うんだが？
(_ _)ZZZZzzzzz...... I'm sleepy
Re:運用上の穴は誰の責任？ (スコア:0)
契約してて面倒見てないんなら契約違反です。
Re:運用上の穴は誰の責任？ (スコア:1)
普通はせいぜい、運用要員を他の会社から雇うのが精一杯ではないかと？
つか、国の施設もアウトソーシングで済まそうなんて、普通は無理だろうけどねぃ
(_ _)ZZZZzzzzz...... I'm sleepy
Re:Everybody's Business is Nobody's Business (スコア:2, すばらしい洞察)
> 相当大きな負担がかかりそうです。
「UNIXだから大変」とか「UNIXじゃないから楽」ということは無いでしょう。
まともに管理しようとすれば、OSが何であろうとそれなりの手間がかかるのは
当たり前では?
Re:Everybody's Business is Nobody's Business (スコア:1)
だから、中間管理職である「システム管理者」はシステム管理よりは、システム運用とかで負担かかるかと…
まぁ、それが大変な事になりそうだから、お役所なら地域毎に管理者グループが協議会みたいなもの作って、
御互いの(責任者への愚痴の捌け口とか)管理技術とか勉強の場になるんだったら、その組織もオープンに
すべきかなと。
/* Kachou Utumi
I'm Not Rich... */
Re:Everybody's Business is Nobody's Business (スコア:1)
言いたいんだと思うんだけど、違うのかな。
そうだとすると、 UNIX かどうかはあまり関係無いというのは変わらないけど、 Plan9 [aichi-u.ac.jp]だと
チョット変わったりする。
Re:Everybody's Business is Nobody's Business (スコア:2, すばらしい洞察)
導入した側でバグが発覚した責任を問うのはおかしく無いですか？
追求するならば「バグを突かれて被害が出た時の責任」ではないでしょうか？
バグが見つかったということはそれを塞げば被害を事前に防げる可能性があるわけですから。
オープンソースではバグを見つけた人がそれを直す確立は高くないですか？
(この場合の「バグを見つける」は「バグの現象に出くわした」とは違います)
「バグだバグだ、誰だこんなの導入したのは、誰の責任だ、誰だ、誰だ！」
などとやっている暇あったらもう一歩引いて全体を見渡したほうがいいでしょう。
そんなに近くちゃ世界中のハッカーが動き回ってるのが見えませんよ？
繰り返される議論（dy's Business is Nobody's Busine (スコア:1, 参考になる)
負わない。 大概のライセンスにそう書いてある。
ふつーどこが責任を負って対処するかというとそのソリュー
ションを提供した業者（もちろん契約内容に拠るが）
そうなるとオープンソースであろうがなかろうが関係ないのだな。
業者を介さず自分達で導入したものであれば明らかに自分達の
責任ですよ。これもまたオープンソースであろうがなかろうが
関係なくね。
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
＞ションを提供した業者（もちろん契約内容に拠るが）
＞そうなるとオープンソースであろうがなかろうが関係ないのだな。
理屈では当然そうなのだが、「契約内容を無視して」自分達で責任を負えない契約主をなんとかしてくだ
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
オープンソース化でその常識に戻るだけと思われ。
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
20年前の常識なんぞ持ち込んで欲しくないね。
時代が時代だからなぁ。
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:3, すばらしい洞察)
この場合、是非を評価されるべき点は「現場プログラミングが常識として認められる」ことで、「常識の新旧」ではないだろう。
新しいものは何でも古いものより必ず優れているのか？
二言目には「時代が違う」と言う人がいるが、「新しい時代」を生きる人間は「古い時代」を生きた人間よりそんなに賢いのか？
「新時代の最先端を行ってる」気分になりたいだけでは無いのか？
本当に重要なのは時代や業界に関係なく、先人の良い点・悪い点を謙虚に咀嚼・吟味・評価して、その経験を活かす事だろう。
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:1, 興味深い)
その結果として、古いものより優れている新しいものを作る・使う・広めるというのが重要でしょう。
#201379のコメントはちょっと哀しい。
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:1)
逆の話をしているのでは？と、ふと思いました。
つまり、もしかして過去より今のほうが「劣って」いるのでは？という。
確かに「明日」のために今日、新しくて優れているものを頑張って作って用意するのは、重要なことです。
が、それと、「今日」使われているものが既に優れているかどうか、は別のことです。
明日のものを作るために参考にするのに相応しいものが、実は今日のものではなく過去のものである、
ということはありえると思います。
そして、それはこの話題については、案外当てはまっているのでは…という不安は、あります。
#なんで不安かというと、俺もその「今日」に生きているからであって、G7
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
それでも… (スコア:0)
激しく同意。
ただ、それでも現場プログラミングは広まらない罠。
＃プログラムが組めなくても、
＃サーバの管理はできる。
＃その逆もまた同じ。
現場プログラミングやってません? (Re:それでも…) (スコア:0)
ユーザ側の立場で言うと，うちの会社(製造業)ではUNIX系のシステムでも普通に現場プログラムを要求してます． もちろん規模と重要度によりますし，呼ぶのもテスト～立ち上げの時期のことが普通ですが．
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
現在の常識も20年前とそれ程かわっていないとおもわれ
あと、責任については発注金額が高い分メーカーがOSに手を入れてくれるぐらいしてくれる。まあ責任をお金でかっているだけですけど。昔から。
Re:繰り返される議論（dy's Business is Nobody's Bus (スコア:0)
http://www.amy.hi-ho.ne.jp/~lepton/program/p2/prog245.html
Re:Everybody's Business is Nobody's Business (スコア:1)
セキュリティ対策費みたいな項目を予算化しやすくなるのではないかと。
予算さえつけば、本来契約外なのに業者に押しつけるとか、外に出せないで
現場の人が泣くとかの可能性が少しは減るのでは。
予算化されてれば、発注側と受注側の責任範囲も明確にしやすいでしょう。
もっとも、官僚組織というのは責任の所在を不明確にするためのものだったり...。
Re:Everybody's Business is Nobody's Business (スコア:0)
Re:Everybody's Business is Nobody's Business (スコア:1)
もちろん、「オープンソースにしろ！」って命令した役人さんたちが。
// Give me chocolates!
Re:Everybody's Business is Nobody's Business (スコア:1)
残念(?)ながら、そういうシーンは今のところあんまり見た記憶が無いような。
#責任神話が、アレですなあ。
M$やSunに文句を言えばどうにかしてくれると? (スコア:0)
問題が起きた時のオープンソース/クローズの違いは文句の捌け口
があるかないかでしかないです。
いずれにしても、誰かがやってくれるわけじゃないです。
結局は導入した自分達の責任です。
Re:M$やSunに文句を言えばどうにかしてくれると? (スコア:4, 参考になる)
Solarisにはapacheが付いています。
自分でup-to-dateなものをインストールしたりせずに
OS付属のものを使えば、Sunはそのapacheを
サポート対象としてくれます。
ここでいうサポートというのは、バグに対してSun内部の
バグIDを振って管理してくれるということです。
客: 「なんかapacheが変な挙動するんですけど」
Sun:「ああ、バグ登録されています。今patch作ってます」
そして出てきたpatchをあててみると、apacheのバージョンが
上がっている、と。もちろん、そのapacheもサポート対象ですが。
Re:M$やSunに文句を言えばどうにかしてくれると? (スコア:1)
責任問題に関してオープンなのとクローズドなのとどちらがいいかといったら、こういうことになるんだと思います。
// Give me chocolates!
Re:M$やSunに文句を言えばどうにかしてくれると? (スコア:0)
ま、結局は業者に全ての責任を負わせるんだけどね、
つまり、何を使っても一緒。
彼らに大事なのは「やってますと言う”ポーズ”」のみ。
そこから生まれるものなんて興味ゼロ。
それが官僚。
泣くのは業者。
この構図は未来永劫変わらない。
Re:国が金かけてやるんだから (スコア:0)
公務員ハッカー…かっこよくない？