自分がDebianとNetBSDのユーザなので無理矢理話をBSDに変換してしまうと、「FreeBSDがあるんだからNetBSDやOpenBSDなんかいらない」とは絶対思わないってことです。かつてFreeBSDを使っていて、newconfig vs new-bus の醜い争い(当事者たちはどう思ってたか知らないが、傍目からは実に醜かった)を見てFreeBSDを捨てた時、NetBSDという選択肢があったことを実にありがたいと思ったものです。
日本だとどうしても「kernel屋 == デバドラ屋 or ネットワーク屋」となってしまい、4.4BSD本(今となっては古すぎる)を参考にすれば十分とか、穴埋め式で書いていけばkernelなんて簡単に作れると思い込んでいる人達が目についてしまいます。穴埋めが効かない、問題の定式化から手作りで始めなければならない、しかもOSなんて100や200もあるわけではなく、参考にできるものが少ないところにOS作りの本当の難しさがあります(wfjが386BSD本で述べたことは21世紀になった今でも通じている)。ネットワーク屋さんはある程度意識しているかも知れませんが、デバドラ屋になるといまだにあの赤い本を振り回す人がいて、そんなものが使いものにならない私からすればむなしく見えてしまいます。
なぜにLinux? (スコア:2, 興味深い)
BSDなOSを使ったほうが良いのでは? 確か、日本のある公共団体
の施設では、上記の理由でオールBSDで運用していたぞ。
やはり、あまりにもマイナー路線なのも話題不足で駄目なのだろうか…
Re:なぜにLinux? (スコア:2)
FreeBSDが駄目だと思ったらOpenBSDというわけにはちょっといかないですよね。そりゃWindowsよりはずっと移行は楽だと思いますが。
後は・・・高性能なJava VMが存在するのも押さえておきたいポイントだと思います。
いずれにしても、砂上の楼閣アンチパターンにみんなようやく気づきだしたと言うところですか。
Re:なぜにLinux? (スコア:2)
素朴な疑問ですが、世の中の多くの人に、トラブルがkernelにあるのか、それともuserlandにあるのか判断する能力があるのでしょうか? また、Unixではほぼすべてのapplicationについてin-kernelの性能が影響を及ぼすことがどれくらい周知されているのでしょうか? これらがわからないので、distroが選択できるといわれても有り難みが感じられません(あるとしても一時的、限定的なもの)。
逆にいえば、その判断基準を身に付ければ、たとえSolarisのようにsourceからの構築が難しい、あるいはfreeなOSとの差異が大きいものでも使いこなすことはできますけどね。GiantさえとれてしまえばFreeBSDはSolaris8と十分張れる、7以前に対してはより高い性能を出せる可能性すらあるとか(Solaris7およびそれ以前ではslab allocatorがSMPの足かせになっている、8ではDynixっぽくしたらしい)。
Re:なぜにLinux? (スコア:0)
>有り難みが感じられません(あるとしても一時的、限定的なもの)。
ありがたみを激しく感じてる者のひとりです. Debian がなかったら
Linux は使ってません.
Debian が ほげほげBSDで動くんなら, そっちに移行するかも
しれないです.
# 所詮私は寄生虫
Re:なぜにLinux? (スコア:1)
>ありがたみを激しく感じてる者のひとりです. Debian
>がなかったら Linux は使ってません.
いや, ですからここでの話の流れではDebianで良ければRedHatやSUSEはいらないでしょう? じゃあRedHatやSUSEの存在価値は? ってことです.
Re:なぜにLinux? (スコア:2)
なぜ? 選択肢があることはいいことだと思いますけど? Debian のリリーススケジュールのルーズさや、主要ソフトウェアのdeb化がワンテンポ遅れる傾向があることを嫌う人だっているはず。
自分がDebianとNetBSDのユーザなので無理矢理話をBSDに変換してしまうと、「FreeBSDがあるんだからNetBSDやOpenBSDなんかいらない」とは絶対思わないってことです。かつてFreeBSDを使っていて、newconfig vs new-bus の醜い争い(当事者たちはどう思ってたか知らないが、傍目からは実に醜かった)を見てFreeBSDを捨てた時、NetBSDという選択肢があったことを実にありがたいと思ったものです。
そうやって選択肢を残しつつお互いのいいところを取り入れ合ってみんながどんどんよくなっていくのが理想でしょう。感情的なものもあるから、なかなかそうはいかないのも確かだけど。
技術交換は実は難しい (スコア:2)
選択肢が多いことと、それらの間で技術交換ができることが私の頭の中では結びつきません。例えばFreeBSDのSMPngはBSD/OS 5.0を参考にしていますが、実際に手を動かしてみると(私だけでなく、関わっている人の多くの結果に共通して)BSD/OSとはまるで違ったものができ上がってしまいます。私が関わっているprocess groupやsessionについても、全くもってFreeBSD独自の実装をせざるを得ませんでした(御存知ないでしょうが、BSD/OSのsession managementはSVR4-basedです。BSD-basedな方法ではありません!)。
日本だとどうしても「kernel屋 == デバドラ屋 or ネットワーク屋」となってしまい、4.4BSD本(今となっては古すぎる)を参考にすれば十分とか、穴埋め式で書いていけばkernelなんて簡単に作れると思い込んでいる人達が目についてしまいます。穴埋めが効かない、問題の定式化から手作りで始めなければならない、しかもOSなんて100や200もあるわけではなく、参考にできるものが少ないところにOS作りの本当の難しさがあります(wfjが386BSD本で述べたことは21世紀になった今でも通じている)。ネットワーク屋さんはある程度意識しているかも知れませんが、デバドラ屋になるといまだにあの赤い本を振り回す人がいて、そんなものが使いものにならない私からすればむなしく見えてしまいます。
Re:技術交換は実は難しい (スコア:2)
そりゃ結びつかないんだから当然でしょう。例えば、ApacheとIISはいずれもHTTPサーバの選択肢ではありますが、これらの間でサーバサイドスクリプトの技術交換ができるかといえば、一部できないこともないけど、そんなことハナっから期待なんかしないでしょ。だからこそ、選択肢を換える時には移植だ何だが必要になるわけで。
もちろん、選択肢間で同じ技術を使える場合だってありますが、「場合だってある」というだけのことです。
ところで、後段がこのスレッドとどうからむのかが残念ながらわかりませんでした(前段も引用した1文を除いてはわからない)。どうからむんです?
Re:技術交換は実は難しい (スコア:2)
長々と書いたのは、「技術交換が理想である」とあまりに簡単に片付けているので、それが決して簡単にできるものではないという実例として出しました。case studyにはすぎませんが、実際に使える事物や方法論を抜きにしては「○○ができる」「場合がある」といっても実感が沸かないんです。
Re:技術交換は実は難しい (スコア:2)
「技術交換が理想である」と書いたつもりはないんだが、ひょっとして「選択肢を残しつつお互いのいいところを取り入れ合ってみんながどんどんよくなっていくのが理想」と書いたところを捉えてそう言われるのかな。
newconfig vs new-bus 云々を持ち出したのが誤解の遠因になっているのかもしれないけれど、「ドライバを融通しようよ」とか「ほげほげの実装をこっちに持ってきて」という意味を込めたつもりはないです。もちろん、そうできりゃそれこそ理想的だけど、技術的な理由でなかなかそうもいかないのも理解できてるつもり。どちらかといえば、例えばWebサービスのプラットフォームとしてのBSDの選択肢があってよかったね、というところですね。「お互いのいいところを取り入れ合う」という記述の時念頭にあったのは、BSDにおけるOpen Package [openpackages.org]だとか、最近rpmをバックエンドにするaptが出てきたことあたりです。
Re:なぜにLinux? (スコア:2)
>利点だと思えます。
わたしは逆に欠点だと思いますねぇ(汗)。
#Turboの流儀がSlackで通じない、ってね。
#わたしにしてみれば、「同じLinuxなのになんでコマンドが違うんだ?」なんて
#感じますし、「この設定コマンドが」なんて、Distribution指定せずに
#いきなり切り出したりする人もいるし。
#コミュニケーション能力の不足は経験で補うとしても、
#話をするベースの部分での知識にばらつきがあるのではねぇ・・・。
#みんながみんなkernel hackerの知識があるわけではないのだし。
#あと、各Distributorでkernel patchが出るって状況、
#本当にそれでいいんですかね??
>FreeBSDが駄目だと思ったらOpenBSDというわけにはちょっと
>いかないですよね。
何故?
そう「いかない」という根拠を、まず述べるべきでは??
個人的経験談でいいのだけど・・・。
#ちなみに、派生元が同じなので、基本の設定コマンドはほとんど共通です。
#ドライバについては、FreeBSDは数の多い機器から、NetBSD/OpenBSDは
#開発者が興味を持った機器から作られて、お互いにportingしてるような状況です。
#ファイルシステムは、BSD系OSはsolarisのufsやext2すらマウントできるしねぇ。
#お互いのffsくらいは当然、素のkernelでマウントできますよ。
#ただ、ffsのendian independencyはまだ実装中・・・なのかな?
>高性能なJava VMが存在するのも押さえておきたいポイント
クローズドソースに用はない。
ソースがあればBSD系OSでも動くし、セキュリティ考えたら
Java VMの導入はもっと慎重な態度を取るべきでは?
#セキュリティの話してるのにBlackBox入れてどーすんだ??
>いずれにしても、砂上の楼閣アンチパターンにみんなようやく
>気づきだしたと言うところですか。
ここは同感。
---- redbrick
Re:なぜにLinux? (スコア:2)
#そりゃ、その気になればCだって十分書けますが。
アプリケーションの開発が難しい環境を標準に、というのは難しい話だと思います。それに、セキュリティを考えてJavaでアプリケーションを構築する事例だってあります。不用意にプログラミングしてもBuffer overrunのような問題がほとんど発生しないし。
エンタープライズアプリケーションの実行環境として、BSDは残念ながら現状でLinuxに大きく水をあけられていると思いますよ。適材適所でほかの使いどころは十分にありますが。
Re:なぜにLinux? (スコア:2)
>たとえばFreeBSDで使えるデバイスがNetBSD/x86で使えるとは限らないでしょう。
それはkernel verisionの統一を考えていない、各Linux Distributionでも同じですよね?
porting問題はおっしゃるとおり手間が生じる"可能性"がありますが、これはLinuxでも
生じない事ではないですよね?
#kernel versionの差でサポートデバイスは変わる"可能性"はあるし。
だとすると、それで、BSD系の間の場合とLinux Distribution間の場合を区別して
「移行が難しい」と主張する根拠にならないと思いますが。
#・・・間違ってますか? 間違っていましたら、論理的にご指摘いただければ、訂正の上謝罪いたします。
>これは一般人にとって十分な差異と思われますが?
これは、わたしの個人的見解ですが、サポートデバイスを調べないで移行をしようとするヒトは
一般人じゃなくて、うっかり者です(苦笑)。
#そんなの、Windows間だってLinux間だっておんなじ。
#移行しない、という選択肢が他に比べて妥当、ということもありますし。
>>FreeBSDが駄目だと思ったらOpenBSDというわけにはちょっと >いかないですよね。
サーバを前提として考えて、実行環境の移行を想定していたのですが、ディスクなどの
必須デバイスでのサポートの差異は現状ほとんどないはずです。
#RAIDカードのサポートはもしかしたらOpenBSDの方が進んでる?
#あ、SMPのサポートはFreeBSDが進んでる・・・かな?
以下、個人的見解による意見ですが・・・。
ドライバ開発などのサポートが遅れているのはsound等のサーバ業務には必要のない
デバイスや新規のもので、この辺りは必要ないか、portingのスタートが変わらないので
あんまり差がでないと思います。
サーバアプリケーションの用意は、日本語の問題をXで解決すると、BSD間での差異は
ほとんどないはずです。
#そもそもコンソールで日本語を通すにはkon2等の特殊なコンソールドライバがどのBSDだって必要。
#NetBSDはwscons(標準コンソールドライバ)でのm17n化が進んでいる?
で、最後にディスクはどのBSDでも、i386同士ならば問題なく読めます。
ここまで考えて移行が「ちょっと(すぐには)いかない」とおっっしゃるのは不思議に思ったんで、
「個人的経験談でいいのだけど・・・。」
と書いたのですけどね。
#特殊な事情や、移行を妨げる特別な事例があったのかと思いまして。
#でもJAVAが制約になっている、ということなのですよね(詳細は後述します)。
>私は基本的にJava屋なので、Javaが動かないところでソフトウェアの開発は厳しいんですよ。
JAVAの件は、"FreeBSDでは存在しないorLinuxバイナリを動かしてる"といううろおぼえの記憶が
念頭にあったのと、サーバ系でセキュリティ重視という場合で考えていましたので、
開発者の方と見解が異なってしまうのはあると思います(汗)。
こちらで前提を説明せずに論を展開してしまって申し訳ありませんでした。
この点については謝罪いたします。
#でも、BlackBoxなシステムは、個人的意見としてセキュリティ重視のものには使いたくないですが、
#それはわたしの個人の主張ですしね・・・。
ここでの「あなたにとって、他より妥当な選択肢」が、*BSDではない、って事ですよね。
#やるせないことだ・・・。
>エンタープライズアプリケーションの実行環境として、BSDは残念ながら現状でLinuxに
>大きく水をあけられていると思いますよ。適材適所でほかの使いどころは十分にありますが。
この点は同意です。
#わたし自身は、PC-Unix上ではクローズドソースのアプリケーションは使わないポリシーですけど。
#あと、BSD系のi386だとLinuxのi386バイナリを直接実行することも出来ますが、
#結構ライブラリの整合性とかで苦しむor動かないこともあるようで、ちょっと残念です・・・。
---- redbrick
Re:なぜにLinux? (スコア:1)
ふむふむ、実行環境として水をあけられていたのか...俺はてっきりLinuxブームと共に、エンタープライズアプリケーションを作ってる/売ってる連中がLinuxに進出してきただけだと思ってました。で、参考までにお聞きしたいのですが、実行環境として、どういう点でLinuxがBSD一派よりも優れているのでしょうか?あるいはBSD一派に足りないものは何でしょうか?
ちなみにjavaに関しては、FreeBSD本家内 [freebsd.org]に情報があります。(別投稿でACさんも書いていますが)SunはLinux以外のFree UNIXはお嫌いみたいですね。
Re:なぜにLinux? (スコア:2)
Javaについては、別の場所で書きましたがやはり非常に熱望されているのでSunも含めて何とかしてほしいところです。
もし出たら、Linux/FreeBSDのJDK対決を見てみたいな・・・
Re:なぜにLinux? (スコア:0)
> ポイントだと思います。
いやね FreeBSD にも JDK はきちんとあるのですよ。
もちろんネイティブで JDK1.3 相当の。
ちゃんと port されてるにも関わらず Sun が配布 OK 出して
くれないだけ
Re:なぜにLinux? (スコア:2)
それで「高性能」なんでしょうかね?せめてLinuxのJDK1.3.1レベルは実現しておいてほしいところですが。
実はテストにとおっていないとか、そういう理由ではないのですか?一応、 [BugId:4288745]/ [sun.com]はRFEのトップ得票なんですがねえ。ま、Sunにどうにかしてほしいと言うのは同意です。Re:なぜにLinux? (スコア:1)
ええまぁ、いろいろあってですね
法律的な問題を抱えているようで、1.2.2 にしても 1.3 にしても Sun が JCK を通していないそうです。こればっかりはどうしようもない。
サーバーサイドの場合 Java 2 以降の Java 2 SDK は似たり寄ったりな気がしますけど。(注意: 元が Sun ではない実装は別)#それに FreeBSD 上の Java 2 SDK で運用してる商用サイト結構知ってます:-)。
ところで元ネタの話だと、BSD がどうたらと書いてありますが、どっちでもいいんじゃないでしょうか。私は FreeBSD が好みですが、適材適所で Linux も使いますし、それぞれ長所短所を持ちます。
セキュリティがらみの話ならどんなプラットフォームでもセキュリティホールがあるわけですし、そのプラットフォームでどれだけセキュリティに気を使って運用するかの方が大事だと思うのですが。
FreeBSD JDK (スコア:0)
Re:なぜにLinux? (スコア:2)
へぼい奴が使えば Linux だろうが BSD だろうが Secure なサイトになんぞなりません。もはやうんざりするほど言いつくされてきたことなのでは? CGIの危ないやつがひとつ使われてたらアウトですよね。
# 今どきCGIかよ、というのはとりあえず置いとくとして。
もちろん、Secureに保つ上でのコストパフォーマンスの点でIISが弾かれるのは当然とも思いますけど。
Debian GNU/Linux と NetBSD を愛用してるけれど、Secureに保つためのコストという点ではどちらもそう変わらない。差は他の部分にあるわけで、用途によって使い分けてる。それだけ。
Re:なぜにLinux? (スコア:1)
狙われやすいのでわ? ということです。Linux(カーネル云々の話
は抜きにしましょう)に感染するウィルスを作って自己満足する輩
がいてもおかしくはないが、BSDなシステムに対するウィルスで
自己満足する輩は、相当な珍種であろう。
Re:なぜにLinux? (スコア:3, すばらしい洞察)
うーん。確かに、ありきたりな技術を使って手当たり次第にアタックを仕掛けるScripting Kiddieどもからするとそうかもしれませんね。出回っている対UNIX系アタックコードの多くがLinuxを対象にしていますからね。
ただし、
という希望的観測にもたれてサイトを運用するのは相当に危険なことです。例えばつい先日話題になった wu-ftpd の穴にしたところで、巷間ではあたかもLinux固有の問題であるかのように言われていましたが、Exploitコードに多少の違いはあれ、wu-ftpdを使っていればBSDと言えど危険だったはずです。この穴を残したまま運用していて、そのホストをピンポイントで狙われたら、BSDであろうと間違いなくやられる。その点では差はないのでは?
Re:なぜにLinux? (スコア:2)
もう1つ注意しなければならないこととして、cross-compilationがあります。現在およそfreeなOSのほぼすべてがGNU toolchainを利用しているため、それらのOSが動くarchitecture向けにcross-compileを行うことが可能であり、かつ容易になっています(i386でsparc64用のkernelを作ったらあっさり動いたとか)。したがって、たとえ自分が特殊なarchitectureで仕事をしているからといって、安心はできません。
残念ながら、現実に需要があるのでcross-compilationを止めるわけにはいきません。私はこれを厄介な問題であるととらえているのですが、何故かこういう指摘ってなかなか見かけませんね。もしかして世の中の多くの人はi386しか存在しないと考えている?
Re:なぜにLinux? (スコア:2)
・・・残念なことなのでしょうか?
これがないと、NetBSDやOpenBSDの各アーキテクチャのportが新規に作れませんが。
#コンパイラのネイティブなバイナリすらないアーキテクチャに移植することだってあるのだし。
#Debianは他アーキテクチャのサポートに熱心ですから、Debianも困りますよね?
>私はこれを厄介な問題であるととらえているのですが、
何がどういうふうに「厄介なこと」なのですか?
#わたしには具体例が想像できないのですが・・・。
#i386のWindowsが穴だらけでbinary形式のvirusによく引っかかったりするのは、
#Winの対策がなってないせいってだけで、cross-compilationが厄介というのは
#無関係な気がするのですが・・・。
#それとも、その他のことですか? うーん・・・、なんだろう???
サーバが他から持ち込まれたbinaryを自動実行するとしたら、それは設定のミスか
セキュリティホールでしかないので、ここで論じるのはナンセンス、ということで
よろしいでしょうか?
>たとえ自分が特殊なarchitectureで仕事をしているからといって、安心はできません。
セキュリティ維持の観点からすると、そこで安心して思考停止するのがそもそも間違ってますよ。
---- redbrick
問題は問題の存在に気づくか (スコア:2)
問題をすり替えられてるぁ... そういうことじゃなくて、「スクリプトインタプリタを入れてないから大丈夫」「shellを削ってあるから大丈夫」などと考える輩が存在するんですよ(特にscript kiddyという言葉からの連想で)。というわけで、
は正しいのですが、問題はそれではなく、この事実に気が付いていない人が多いことです。ですからやるべきは、問題の正しさを論じることではなく、如何にして問題の存在を周知するかです。
Re:問題は問題の存在に気づくか (スコア:2)
>「shellを削ってあるから大丈夫」などと考える輩が存在するんですよ
>(特にscript kiddyという言葉からの連想で)。
あ、そちらの「厄介なこと」という意味でしたか・・・。
#技術的な問題が、アーキテクチャ非依存であるのかと思ってしまいました(汗)。
そういうことであれば、「厄介」というのはわかるんですが・・・、その場合、
cross-compiling出来ることが厄介なのは結果であって、本質的に厄介なのは、
>この事実に気が付いていない人が多いことです。
ですよね?
それをcross-compiling側で注意するのは、なんか本末転倒で、結論を導き出す流れが
まったく繋がってない気がしますが・・・・(汗)。
#途中の「script kiddyとかの"気が付いていない連中"が危ない」って入らないと、
#読み返してもわからないですよ、これ(汗)。
#なら、それから先に主張した方がいいのではないでしょうか?
刃物がヒトを傷つけるからと言って、刃物を先に世の中から締め出そうとするような
ことじゃないですかねぇ・・・。
ヒトを傷つけるような"危ない人間"については触れないで。
---- redbrick
Re:なぜにLinux? (スコア:1)
Re:なぜにLinux? (スコア:0)
もんなんでしょうね、実際。
これ **だけ** がウリと思ってるんですが > Kylix
なぜにKylix? (スコア:1)
Re:なぜにKylix? (スコア:2)
Delphi も、Linux との互換性を重視した 6 以降は、VCL ではなく CLX (VCLX) を用います。VCL が Win32 上に直接実装されていたのとは違い、CLX は、Linux 版も Windows 版も共に Qt を用いて実装されているようで、互換性は高いらしい。
Re:なぜにKylix? (スコア:1)
まだまだ使い物にならないです。
VCLとの相性もいまいちみたいで同僚が苦労してました。
Re:なぜにKylix? (スコア:1)
確かに、最適化の効率ではベンダ供給とか、スクラッチから起こした処理系の方が有利な場合が多いです。
しかし、gccの最大の利点は、エンディアン処理とかインラインアセンブラとかの一部の例外を除いてどんなMPUでも同じコードで通るし、最適化の処理内容も読めると言うあたり=移植性の高さにあります。
これは、一度gccでクロスプラットホーム開発をすると非常にありがたい事です。
その他のプラットホーム独自の処理系で開発をやると、最適化で何やるかわからないとか、不穏な(genericでない)コードを書いてしまった時に、コンパイルで通ってもアセンブラレベルの処理で変なコード吐いてタコ壷ってしまうと言う困難に直面する事が結構ありますので…
コンパイラのバグとかが多いのもOpenではない、独自の処理系の難点だと思いますので…この辺りはベンダ提供の物に多いですが。
Re:なぜにLinux? (スコア:1)
そ、そーなんですか(^^;;;
俺としては、Delphiみたいな、
ネイティブコンパイル言語である一方でメタ機能も充実
(コンポーネント云々を出来るのもそのおかげ)した言語が
Linuxにもやってきた、のが最大のウリだと思いたいです(^^;
Delphi(Kylix)の言語仕様を知ってしまえば、
C++はもとより、javaだって、時として糞言語に思えてしまいます。
OOP言語を標傍してるくせにクラスメソッドの多態もできない言語なんて!!
#まぁDelphi(Kylix)の言語仕様にも糞な面は色々ありますが…
こういう言語が来てくれたことだし、将来(?)的には、
こういう言語に刺激を受けて更に凄い言語を
作る人がばんばん出てきてほしいですね。
そりゃ凄い言語は既に他に色々あるけど、色々あるからって「それで足りてる」とは限らないんだし。
え?普通のやつらの上?まぁその…
Re:なぜにLinux? (スコア:1)
現に最近ではいくつかの商用ソフトウェアがWindows->Mac->Linuxの順で対応してきています。巷に住むLinux人口もかなりのものだと考えられます。OSはOS自体の質だけでなく、こういったユーザ数なども考慮しなければ採用はしにくいでしょう。
要はネームバリューも含めての行動だと思います。
-- By Grabthar's Hammer!
Re:なぜにLinux? (スコア:1)
サポートか考えるとき、サポートの問題がどうしてもついてまわります。
以前、仕事で社内DATA BASEの構築をしたのですが、Linuxで蹴られた覚えがあります。
結局その時はWindows系ですべて済ませて納品しましたけど...
また、大規模なDATA BASEを構築する場合でも、やはり個人的にはソラリス+オラクルっていう選択をすぐ取っちゃいます。
(これもサポートの問題ですけど)
#担当もそれほど馬鹿じゃないので、Linux関連企業がつぶれたり
#サポートをやめちゃったりするLinuxだとあまり積極的ではない
#事も多々あります。
Re:なぜにLinux? (スコア:0)
だいたい、5年でサポートを終了するようなOSで安心できるのですか
#NT3.5にいたっては影も形も無い
過去のバージョンとの互換性が充分か、ソースが公開されているならとにかく、クローズじゃ手の出し様が無いです
せめてサポート中止したOSはソース公開してくれないかなぁ
逆にLinux等のOSの方が
Re:なぜにLinux? (スコア:0)
>だいたい、5年でサポートを終了するようなOSで安心
Re:なぜにLinux?:客がわかるだろうか? (スコア:0)
<客自身が知らない>からで
わたしが体験した悲惨な例は Win95でスキャナの画像を
読み込み、検索データベースへ取りこむもの。
アクセスは遅いは、手順はすべてGUIでくたびれるは...
データ格納に失敗するは.で、ユーザーなかせ
Re:なぜにLinux?:客がわかるだろうか? (スコア:2)
> <客自身が知らない>からで
なぜ客自身が知らないかというと、
Linuxだからですね。
思うにLinuxには客に知られようという素振が見受けられない。
というか、それが本質なのかもですけど。
Re:なぜにLinux?:客がわかるだろうか? (スコア:1)
Win95 を「GUIだから」ダメ、というのであれば
賛同できませんねえ。(そうじゃないと思いますが)
とりあえず、キーボードを使わずマウスで操作できるものを
GUI と呼んでみてるだけであって。
他のシステムで、もっとまともな GUI がいっぱいありますからね。
[udon]
Re:なぜにLinux? (スコア:0)
営業やセールスエンジニアの立場で「客先要望」に従って選択するのは当然ですけど、Linuxのサポート停止を心配することとは別の話ですよね
# 職業というより立場の方が適当だったかなぁ
また、開発とサポートの違いでも選択肢は変わると思います
フリーという立場も営利を目的とする「企業」
Re:なぜにLinux? (スコア:1)
「そんなもの危なっかしくて使ってられないじゃないか。だれも責任とらないんだから」
Re:なぜにLinux? (スコア:0)
反論その1
MSのOSを選択するような「馬鹿じゃない担当」はそう考えません
客観的事実を評価しているのではなく、担当者がどう判断するかを検討しています
反論その2
日本以外の政府も含め
Re:なぜにLinux? (スコア:0)
そうなんですけど、独自にサポートできない範囲というのも自ずから存在します。例えば、企業ユースだと、24時間x365日サポートしてくれるかどうかが重要だったりしますので。
基幹系の場合には、不具合が発見された場合コールすれば1~2時間以内にエンジニアを派遣できるような体制を整えないといけないですし、それができるのは体力のある企業に限られてきます。
> だいたい、5年でサポートを終了するようなOSで安心できるの
Re:なぜにLinux? (スコア:1)
Oracle や DB2 の存在は大きいと思ふ。
Re:なぜにLinux? (スコア:1)
ソフトの種類によるリスクを避けようと思えば
超マイナーなOSも含めてシステム構成を頻繁にコロコロ替えるべし
でもそうすると自爆ミスによるリスクのほうが大きくなる
そのへんまで来るとあとは費用対効果の問題
とりあえず技術者にできることは
そんなもの何に使うんだというような非実用的な製品も
侮らずに日頃から戯れておくことです
(なんてことをうそぶきながら今日もおもちゃと戯れる)