各国政府がLinuxを採用/米マイクロソフトを敬遠 75
ストーリー by wakatono
さて、日本はどうする? 部門より
さて、日本はどうする? 部門より
hatochan 曰く、 "電波新聞(2001年12月5日朝刊3面)によると、世界各国の政府機関で、Linuxの採用が広がっているという。ソフトウェア市場で首位の米Microsoftの製品では、Linuxよりウィルスやハッカー(原文のまま)の標的になりやすい上、一米企業の製品を多用することへの不快感、米政府のスパイ行為への根強い懸念が消えないためとしている。
さて、日本政府はどう対応していくのでしょうか。TRONのリベンジなるか。これからの動きに注目です。"
公のシステムに、ソフトウェアについて上から下まで1社の製品というのはどうかと思う…
なぜに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? (スコア: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? (スコア: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 も使いますし、それぞれ長所短所を持ちます。
セキュリティがらみの話ならどんなプラットフォームでもセキュリティホールがあるわけですし、そのプラットフォームでどれだけセキュリティに気を使って運用するかの方が大事だと思うのですが。
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)
なぜにKylix? (スコア:1)
Re:なぜにKylix? (スコア:2)
Delphi も、Linux との互換性を重視した 6 以降は、VCL ではなく CLX (VCLX) を用います。VCL が Win32 上に直接実装されていたのとは違い、CLX は、Linux 版も Windows 版も共に Qt を用いて実装されているようで、互換性は高いらしい。
Re:なぜにKylix? (スコア:1)
確かに、最適化の効率ではベンダ供給とか、スクラッチから起こした処理系の方が有利な場合が多いです。
しかし、gccの最大の利点は、エンディアン処理とかインラインアセンブラとかの一部の例外を除いてどんなMPUでも同じコードで通るし、最適化の処理内容も読めると言うあたり=移植性の高さにあります。
これは、一度gccでクロスプラットホーム開発をすると非常にありがたい事です。
その他のプラットホーム独自の処理系で開発をやると、最適化で何やるかわからないとか、不穏な(genericでない)コードを書いてしまった時に、コンパイルで通ってもアセンブラレベルの処理で変なコード吐いてタコ壷ってしまうと言う困難に直面する事が結構ありますので…
コンパイラのバグとかが多いのもOpenではない、独自の処理系の難点だと思いますので…この辺りはベンダ提供の物に多いですが。
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?:客がわかるだろうか? (スコア:2)
> <客自身が知らない>からで
なぜ客自身が知らないかというと、
Linuxだからですね。
思うにLinuxには客に知られようという素振が見受けられない。
というか、それが本質なのかもですけど。
Re:なぜにLinux?:客がわかるだろうか? (スコア:1)
Win95 を「GUIだから」ダメ、というのであれば
賛同できませんねえ。(そうじゃないと思いますが)
とりあえず、キーボードを使わずマウスで操作できるものを
GUI と呼んでみてるだけであって。
他のシステムで、もっとまともな GUI がいっぱいありますからね。
[udon]
Re:なぜにLinux? (スコア:1)
「そんなもの危なっかしくて使ってられないじゃないか。だれも責任とらないんだから」
Re:なぜにLinux? (スコア:1)
Oracle や DB2 の存在は大きいと思ふ。
Re:なぜにLinux? (スコア:1)
ソフトの種類によるリスクを避けようと思えば
超マイナーなOSも含めてシステム構成を頻繁にコロコロ替えるべし
でもそうすると自爆ミスによるリスクのほうが大きくなる
そのへんまで来るとあとは費用対効果の問題
とりあえず技術者にできることは
そんなもの何に使うんだというような非実用的な製品も
侮らずに日頃から戯れておくことです
(なんてことをうそぶきながら今日もおもちゃと戯れる)
世界各国って具体的に? (スコア:2)
それぞれ事情が違うから、どのくらい拡大しているのか知りたい。
対MS(アメリカ)という意味ならヨーロッパ・中国・ロシアまでは解釈できるけれど、それ以上まで広がっているなら別のポイントがありそうだ。
-- wanna be the biggest dreamer
Re:世界各国って具体的に? (スコア:3, 興味深い)
#URL失念
各国語の対応はどうなんでしょ。 (スコア:1, すばらしい洞察)
言語対応がどこまで各国政府のOSの選択に影響しているものなんでしょう?
オープンソース採用法 (スコア:1)
http://www.zdnet.co.jp/news/0109/04/e_open_m.html
元記事を読んでないので外してるかもしれませんが... (スコア:1)
OS は特定企業のを避けるけど、その上で使うワープロは format も公開されていない特定企業のソフトだというのでは悲しいじょ... 結局その為に OS を自由に選択出来なくなるような気もするし。
TRON? (スコア:1)
コレ意味不明なんですけど。なぜここでTRONが出てくるんでしょうか?
投稿氏の意図がわかりませんが。
幻の標準OS(Re:TRON?) (スコア:3, 参考になる)
状況によっては、日本の標準OSはTRONになっていた可能性もあったんですね~(遠い目)。
Re:幻の標準OS(Re:TRON?) (スコア:1)
TRONはきっと良いんだろうと思う(知らないので失礼)んだが、
OSに国境を設けかねない上記のような意見は、ちょっと心配をしてしまうです。
いや、もちろんTRONに落度があるわけじゃないんだけど、
unix(そしてその子分(笑)のwin)とあそこまで違うOSがunixと同時に存在すると、
データ流通の互換性をとりにくくてしょーがないっすよね。
データというものの考えかたが根本から違うんだから。
世界中がunixになるとか、逆に世界中がTRONになるとか(^^;を考えるならまだしも、
一国一OS(アーキテクチャ)なんてな考えかたは、甚大な不便をもたらしかねないのでは…
ところで話飛ぶけど、なんか(B)TRONって開発環境弱くないっすか?(T_T)
Programだってメタコンテンツ(?)なんだから、それを作るのも
コンテンツを作るのと同じくらい快楽でないと駄目だと思うのだが。
Re:データの互換性 (スコア:2)
ええ? そうですか??
わたしは基本的に非互換なものはないと思ってましたが。
#今のコンピュータシステムのデータ形式として、
#binary表現を使うという観点で、ですが。
だって、そうとでも考えないと、アーキテクチャもendianも
違ったCPUのOS間でデータのやり取りが出来る現状をどう説明つけるので?
あ、ちなみに、アプリケーションが扱うデータ構造の非互換については、
アプリケーションの移植の問題なのでわたしは考慮しておりません(笑)。
#フォーマット変換プログラムを作ったりすりゃ扱えるのであれば、
#それは「扱える手段がない」だけで、即「非互換」というわけじゃないでしょ?
#「現時点で非互換に見える」だけ。
>そもそもunixにtextファイル以上のレベルでの互換性のある
>データの規格が無いような気がする
それも、アプリケーションのデータ構造に過ぎませんよねぇ。
そもそもunixから出てきた規格じゃないし。
---- redbrick
失礼、勘違い(汗) (スコア:2)
>>本来的にはデータの規格ってOS非依存ですよね。
>
>ええ? そうですか??
>わたしは基本的に非互換なものはないと思ってましたが。
ここ、「非依存」を「非互換」と読んで疑ってませんでした(汗)。
申し訳ありませんでした。
OSに依存するデータ形式がないというのは同意です。
#「データ形式が依存する」というのは、わたしは基礎部分の表現形式が
#現在のアーキテクチャの理論に依存するだけ、と思ってます。
---- redbrick
Re:TRON? (スコア:2, すばらしい洞察)
昔、某国の圧力によって潰されたからでしょうな、きっと。
逆に、MSを排除することでその某国をギャフンと言わせたい、と思っている人が少なからずいるだろう、ということなのだろう。
確かに某国の圧力は理不尽なことがあるよな。
Re:Distribution統一? (スコア:2)
気がするのはわたしだけなのでしょうか(汗)?
#スタッフ間での知識の伝達はしないの? ノウハウ伝達が面倒でないですか?
#それとも個人で全部のサーバ、Distributionを世話する形態での運用なのかな?
#でも、多数のDistributionを世話してて、全てのセキュリティ情報やパッチを追いかける
#余裕ってあるのでしょうか・・・(汗)。
>先日、某サイトでの侵入を調べたとき、RedHat系でなくてよかったー、と思う事例が
>多数あったから、侵入者対策としては、あれこれのDistributionがあったほうがいいと思う。
ちなみに、RedHattでどういった侵入経路で、どのようなセキュリティホールを
つつかれたのでしょうか?
差し支えなければ、概要でいいので、教えていただけませんか?
---- redbrick
Re:Distribution統一? (スコア:2)
一国家がその気になれば、distro メーカーに頼らずともサポートくらいできます(国家規模にもよるが)。きっとみんな「MS 対 Red Hat」みたいな視点で、ディストリビュータをかいかぶりすぎです。
Re:Distribution統一? (スコア:2, すばらしい洞察)
> 侵入者対策としては、あれこれのDistributionがあったほうがいいと思う
のであれば、Windowsや商用UNIX、BSDなども含めて、適材適所で構成する方がよりよいと思います。Microsoftダメ、BSDダメとか言っていたら、ディストリビューションを統一するのと同じです。大きなシステムを多様な技術で構成させるという時代だからこそ、技術はオープンであることが重要になってきます。だから、Linux以外はダメだ、なんて閉鎖的なことは言わないで、もっとオープンであって欲しいと思うわけです。
Re:Distribution統一? (乱丁により書き直し) (スコア:3, 参考になる)
失礼、何故かタグが全滅してしまったので書き直し(プレビューではうまくいってたのに...)。
私の仕事場がまさにそんな感じです(ごった煮の間違いかも知れないが)。OSの違いをどう定義するかにもよりますが、/usr/localの区別で考えると...
と、8種類が同居しています(これにBSD/OSを加える話まであった)。これだけあるといろいろなことができます。例えば...
こういうコツをいろいろため込んでいけば、管理の手間を抑えながらOSを多様化させることができます。
Re:Distribution統一? (スコア:2)