アカウント名:
パスワード:
しかし、バージョンが固定で指定されているため、バグ修正でバージョンがどんどん上がっていくような某オープンソースソフトは、修正がされないままで放置です。もちろん管理者としては危険を放置できませんから、
何でもかんでもオープンソースが良くて、問題もないと思ったら大間違いです。
管理者なら、バグ修正後の新バージョンと現行バージョンとの差分から、｢バージョン固定のままの修正パッチ｣を作れますよね、オープンソースなんだから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
残念だが学校では使われなさそう (スコア:1, 興味深い)
しかし、彼ら以外の教師が…となるとはなはだギモンだ。
OpenOffice.org を紹介したが、 MS-Office を購入するし、 Acrobat を購入するし。
ちなみに埼玉県の学校はとある方法で Starsuite が無償で入手できる仕組みがあるらしいが、使っているのを見たこともないし、そもそも導入さえしていないようだ。
教育委員会の先生に、そういったことを話したことがあるが、全然乗ってこない。
正直なところ自分が知っている学校の先生にはほとんどそういったことは期待できない。
だから、生徒にも使わせようとする先生は多分ほとんどいない。
そして、他の選択肢があるということを知る子供もほとんどでない、と思う。
先生は忙しいとか出来ない理由はイッパイあるけどね、言い訳は言い訳だから。
Re:残念だが学校では使われなさそう (スコア:1, 興味深い)
他の人はそうは思っていないことが多いわけですし、いろいろ
複合的な検討をした結果、OOoは却下するなんて選択もあるわけで。
セキュリティの問題やサポート体制のことを考えると、他人に
MS-OfficeをやめてOOoを使えなんて私は思えませんけど、
押し付けがましく「OOoを使えといってるのにMSOfficeを買いやがった。
あいつらは忙しいというのを言い訳にして面倒を避けてるか、
バカなんだ」という意見をみることがあると、普通の人は引いちゃう。
実際存在する公共団体で、とあるオープンソースソフトを公式ツール
として組織全体で採用してるところがありますが、そのソフトのバグで
問題が多発し続けてます。
しかし、バージョンが固定で指定されているため、バグ修正でバージョンが
どんどん上がっていくような某オープンソースソフトは、修正がされない
ままで放置です。
もちろん管理者としては危険を放置できませんから、強固なFirewallや
フィルタリングサーバを導入するなどをして、別のところで余計に
コストがかかってるんです。
何でもかんでもオープンソースが良くて、問題もないと思ったら
大間違いです。
Re:残念だが学校では使われなさそう (スコア:1, すばらしい洞察)
Re:残念だが学校では使われなさそう (スコア:2, すばらしい洞察)
OSにしろミドルウェアにしろアプリにしろ、動作確認がとれてないバージョンへの更新なんて、責任とれん。
動作確認にどれだけのコストがかかるかを考えたら、安易にバージョンをあげられることがどれだけ“迷惑”なことか知れるというもの。
セキュリティ修正パッチですら限定的な範囲での動作確認が要るのに…
Re:残念だが学校では使われなさそう (スコア:0)
検証確認と導入作業をやらなくてはならないとなると、よけいにOOoなどの
オープンソースソフトは導入できないんじゃないでしょうか？
それだけで大事業になりますよ。
深刻な脆弱性が発覚して、すぐに対応してくれるのはいいのですが、
その修正が不完全、またはすぐに別の脆弱性が発覚して、次の週には
また修正が施されてバージョンが上がったりする、あのソフトなんて
とてもじゃないが公式採用できませんよ。検証が追い付きません。
何のソフトかは書きません。
書いたら、どうせ熱狂的な支持者の多いスラドでは批判されるだけですから。
それよりは一太郎やMS-Officeのように、ビルドバージョンは上がっても
指定されているメジャーバージョンは変わらない、メーカーが*ある程度*の
検証と保証とサポートを行っているプロプライエタリな製品が都合がいいんです。
Re:残念だが学校では使われなさそう (スコア:0)
批判されるのを嫌がるあたり。
修行が足りませんね。（と批判してみる）
Re:残念だが学校では使われなさそう (スコア:1, すばらしい洞察)
Re:残念だが学校では使われなさそう (スコア:0)
#1204901なんぞその典型。
Re:残念だが学校では使われなさそう (スコア:1)
# こういうところでソフト名（しかもプロプラならともかくオープンソースで）を伏せる理由がさっぱりわからん。
# 誰かわかるなら教えてくれ。
Re:残念だが学校では使われなさそう (スコア:0)
ただなんとなく思いついただけですけど。
タダより高い物は無い？（Re:残念だが学校では使われなさそう） (スコア:1)
でなければ、新しいメジャーヴァージョンのOSに移行するための準備とか考えないで予算やシステム要件を決めたので、セキュリティサポート打ちきられた後も使う羽目になっているとか…
# っつーか、この手の文句に関しては、RHELのような有償系でサポート体制きちんと組んである会社のOS(高いですが ^^;）
# 導入するか、さもなくば実験部署作って、次期リリースがβからrcになったあたりで幾つかの環境を移行した上で事業所ごとに
# リポジトリのミラー立てておくとかくらいのコストまではケチったらイカンでしょうよ┐(´ー`)┌とか思いますけどね。
## まぁ、入札の時にとことん安くしたSIerに頼んで、後のサポート代でふっかけられた。とかそういう類の話の様にも思えてきた
でなければ、日本医師会のレセコンシステム [med.or.jp]みたいに、OSのメジャーヴァージョンが上がってから公式な対応の為の作業を始めてしまって [med.or.jp](実際にはかなり前からetch対応作業は始まっているのですが…あくまでも人柱向けの供給状況で…)、更に現状のベースのOSのセキュリティサポートが来年４月頭で終わる予定 [debian.org]と言うかなーりタイトな開発スケジュールのシステムなのか…(;´Д`)
なんか、職員が自力でアップグレードするのを禁止すると言うのもなぁ、せめて業務時間外にバッチでアップグレードするようにスケジュール組んでやれよ…そこいらあたりの為の経費までケチるならFOSSに手を出すべきでは無いんじゃないかと思うんですけどね。
Re:残念だが学校では使われなさそう (スコア:0)
#でも/.Jで叩かれるという観点からみたら正しいかなと
Re:残念だが学校では使われなさそう (スコア:0, すばらしい洞察)
管理者なら、バグ修正後の新バージョンと現行バージョンとの差分から、｢バージョン固定のままの修正パッチ｣を作れますよね、オープンソースなんだから。
何でもかんでもオープンソースが良うとは思いませんが、あなたのおっしゃる運用ではオープンソースの一番の利点を全然活用してないですよね。
Re:残念だが学校では使われなさそう (スコア:4, すばらしい洞察)
Re:残念だが学校では使われなさそう (スコア:1)
たかだか”管理者”にそこまで求めるのですから…。
時間を割いて「バージョン固定のままの修正パッチ｣を作ったとしても、
”その動作の責任”と”そんなものを配布した責任”の行き先を考えれば、
”いらん事に時間を割いていないで仕事しろ”と理不尽な事になります。
それならば、費用がかかっても修正と検証・問題発生時の受け皿のある製品を選びますよ。
あるいは、専門のサポートを含んだオープンソース発の製品を。
オープンソースなんだから自分で変更できる。
しかし、それは”管理者も知ってはいるが、現実として取れる手段ではない”という事を
知らないか理解できない立場の方の言葉です。
他の方も書かれていますが、だからこそ”管理者が取れる手段で何とかしようとする”のです。
制度を変えるなどは時間がかかりますから、なるべく現実的で即効性のある方法で。
＃オープンソース物でも、そこらへんなんとかならんかしらん？え？会社変えればだって？
Re:残念だが学校では使われなさそう (スコア:0)
ごめん､元ＡＣなんだけど、どうやら私がやっている「管理者」と君の言う”管理者”は違う仕事のようだね。
> 時間を割いて「バージョン固定のままの修正パッチ｣を作ったとしても、
> ”その動作の責任”と”そんなものを配布した責任”の行き先を考えれば、
> ”いらん事に時間を割いていないで仕事しろ”と理不尽な事になります。
私が担当なら、パッチを作る､FireWallを強化する、など数点の対策を想定して、お客さん、サポート業者と打ち合わせをして、責任なり費用なりを明確にするのが当然だと思います。勝手
Re:残念だが学校では使われなさそう (スコア:1)
（労働時間も当然含めて）費用のかかる話ですし、提案するのは当たり前の事です。
いくつかの松竹梅パターンも、どこでもやられている事だと思います。
お客さんの決定後に、即進められる様、事前準備できるものはすることも。
しかし、（システム毎・お客さん毎に違うことですが）その当然が通じないところがあります。
セキュリティにかかわる提案自体を「無駄」とするところも。
いざトラブルが発生して、提案を破棄したことも忘れて文句をいわれたり、打ち合わせで決まった以上の責任を負わせられる事は”理不尽”だと思っています。
>> オープンソースなんだから自分で変更できる。
>> しかし、それは”管理者も知ってはいるが、現実として取れる手段ではない”
>> という事を知らないか理解できない立場の方の言葉です。
>そこまで書くと、君が楽したいから「バージョン固定な運用」したいだけとちゃうんかと。責任が、とかいうなら、たとえば公式にバージョン固定での修正パッチが出てもパッチ当てるつもりないんじゃないの。もともと無保証なんだし。
「バージョン固定な運用」が楽かどうかは、ものによりますが、
定期的な更新をする方が楽な場合が多いです。パターン化で３桁のマシンでも省力化できてますし。
現状では、話がついているお客さんの環境では、逐次手続きの上で作業しています。
>「…していないで仕事しろ」と上からしかられる「たかだか”管理者”」程度の人に「という事を知らないか理解できない立場の方の言葉です」だなんていわれたくはないね。最終手段だから使えなくていいってことでしょ、君の論法では。それでその仕事やってて怖くないのかね。万が一代替手段がない事象に遭遇したらとか考えたことないの？
考えたことだけではないから、こうなりました。
怖いのは、（無保証なものに限らず）安く上がるからと管理面を考慮せずを導入し、あとは管理部門に”よろしく！”とかいって去る輩と
”管理者なんだからなんでもできるでしょ？””●●なんだから、●●すればできるでしょ？”
”やらないのは、面倒だからでしょ？”と、契約内容や制限事項も知らず、”他のユーザーやお客さんにまぎれて煽るユーザー”や、”煽られた（状況を知らない）上の方”です。
お客さんとは当然話をし、多くは費用の部分で”やるかやらないか”決まっています。
お客さんがリスクをわかった上で”やらない”と決めたのなら、それまでです。
それを勝手にやれば当然「理不尽」な目にあいます。
「仕事しろ（無駄なことをやるな）」と言うのは、（当然わかっているからこそ）上司でも言います。
>> たかだか”管理者”にそこまで求めるのですから…。
>ごめん､元ＡＣなんだけど、どうやら私がやっている「管理者」と君の言う”管理者”は違う仕事のようだね。
あなたのおっしゃる”管理者”は”睡眠時間が要らない機械”か”なんでもできるスーパーマン”に見えて、憧れます。
＃隣の芝生は青く見えるもので、いいなぁと。しかし、どうせどこでも一緒。
完全にオフトピックですな…。