パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

低価格PC向けにWindows XPの販売を延長」記事へのコメント

  • by Anonymous Coward
    まぁ最近はLinux方面のデスクトップ環境も結構重くなってるけどさ
    それでもWindowsには最新ハードを活かせる最新OSに全力を尽くして廉価PCは無視してもらいたい
    というかXPのサポートに割くリソースをVista安定化やWindows7へ回せ
    • Re: (スコア:2, すばらしい洞察)

      by Anonymous Coward
      >というかXPのサポートに割くリソースをVista安定化やWindows7へ回せ
      いやいや、VistaなんかやめてXPのサポートに。
      XPでまだまだやるべき事があるはず。

      VistaをXPの後継に位置づけるのは無理かもしれません。
      95/98系とNT系が共存していたように、NT系とVista系を共存させれば良いのでは。
      • Re: (スコア:2, 興味深い)

        by Anonymous Coward
        HDDではなくフラッシュメモリ、とたれこみにもありますが、今のXPじゃHDDへ最適化してあるのでフラッシュメモリの実力を引き出せない、というか欠点を露呈することになるんですよね。XPのSSDへの最適化もやってるらしい [microsoft.com]ですけど、これをサービスパックの形で取り込むのか、別OSとして出すのか。どっちにしろ市場に追いつけてませんね
        • by Anonymous Coward
          で、MacやLinuxで用いられるファイルシステムはSSD向けの最適化ができるのですか?
          • by Anonymous Coward on 2008年04月04日 22時22分 (#1325049)
            >ファイルシステムはSSD向けの最適化ができるのですか?

            (あえて変なところで切らせてもらうけど)
            その言い方は実は微妙に罠です。

            というのは、Linuxでは「ファイルシステムを」最適化するんじゃなく、
            より最適なアーキテクチャのファイルシステム「に交換」することで
            目的を果たせる(恐らく)からです。
            HDDで使うならHDDに向いたFS。
            FlashならFlashに向いたFS。
            色々組み合わせれる。
            既存実装も色々有る(し、もちろん新しいアイデアが出れば作ればいい)

            対して、個人的に不思議でならないのが、
            Windows系OSが「対応」するFilesystemの種類の少なさ。
            乱暴にいってFAT系とNTFS系だけかよ、という。
            しかも両者は内部構造だけじゃなく対外的Interfaceも全然違うから、
            交換可能ですらない。

            なんでそんな経営(?)判断をしちゃったのか?を想像するのは又の機会として、
            いずれにせよMSから見れば、
            LinuxとかのFSの選択肢の多さ(最適化のしやすさ)は、
            ちょっとした脅威に映ってるんじゃないか?と思います。

            「ファイルシステムはxxx最適化ができる」という言い方は、
            ヤリカタはそれしかないかのように人々を誘導する言い回しに
            なってしまう恐れがあります。
            実際はLinuxではもっとエレガントな回答、
            つまり「その」FSを最適化するんじゃなく、別なのに交換する、
            をしてるのに、それが視界から外れてしまう。

            MS的にはそこを狙ってるんじゃないのかなあ?
            親コメント
            • by Anonymous Coward
              >Windows系OSが「対応」するFilesystemの種類の少なさ。
              >乱暴にいってFAT系とNTFS系だけかよ、という。

               光メディア系も入れてあげてください。
               ISO9660とかUDF。

               あと、Windowsは殿様なので、サードパーティが対応するドライバを書いてくれる。
               逆にMicrosoftが標準搭載すると独占禁止法やらでうるさい(かつ需要は少ない)のでスルーしているのだろう。
              • by Anonymous Coward on 2008年04月05日 10時56分 (#1325217)
                >光メディア系

                それは他のOSからもアクセスできるし、そもそも外様。

                そういえばext[234…]をWindowsからアクセスするドライバって
                有りましたっけ??
                …あ。今は有るのか。
                http://itpro.nikkeibp.co.jp/article/COLUMN/20070130/260017/ [nikkeibp.co.jp]

                >サードパーティが対応するドライバを書いてくれる。

                ドライバ(振る舞い)のほうはどうでもいいんです。
                問題はファイルシステム(データ構造)です。

                同一のデータ構造に対して複数のドライバ実装は有り得ます。
                (しかもFREEの実装だって有り得ます。ライセンス的に縛られてなければですが)

                しかしドライバに対して複数のデータ構造が存在できるわけではないです。

                結局、周囲に恩恵が広がりやすいのはファイルシステムのほう(が存在すること)。

                そしてプロプラかフリーかという問題がある。
                特定一社が提供してて「その顧客しか使ってない」ようなファイルシステムなんて、
                存在してても世間の大多数の人々には無縁でしょう。
                (すみません。ワタシもそもそも見たことが無いもんで…)

                ここで比較に出してるLinuxの各種FSは、
                契約や金という面での導入障壁が基本的に無いし、
                導入作業を肩代わりしてくれる人々(=Distroおよびオンラインインストールシステム)
                が既に幾つも有るので、
                恩恵の広さという意味では段違いです。

                >逆にMicrosoftが標準搭載すると独占禁止法やらでうるさい

                自由ソフトウェア万歳。
                本家マージどころか、使いやすいパッケージ管理システムで入れるも外すも自由自在なのは、結局はソフト(の大多数)が自由ソフトウェアであるおかげですね。「自由」は現実の利便性をもたらしてるわけだ。

                (逆に、自由ソフトに独禁法みたいな枠が科せられるという未来を想像してゾっとしてしまった)

                それに、独禁法だとしても、
                事実上1種類(NTFS)しか対応FSが用意されてないのは
                幾らなんでも奇異に感じます。
                特に昨今のFlash系媒体の伸びに対して、
                フォロー(をできるFS)が全く無いってのは奇異。
                今は外部媒体はFAT系で食い繋いでますが、
                おかげで容量の壁がアレなことになってます。
                しかも業界全体を巻き込んで。
                親コメント
              • by Anonymous Coward
                > 特に昨今のFlash系媒体の伸びに対して、
                > フォロー(をできるFS)が全く無いってのは奇異。

                参考までに、FAT/NTFSしかファイルシステムの選択肢が無いことによる、ユーザに対する
                具体的な弊害を教えていただけますでしょうか(特にNTFS)。


                上のほうで書いてある
                > 特定一社が提供してて「その顧客しか使ってない」ようなファイルシステムなんて、
                > 存在してても世間の大多数の人々には無縁でしょう。

                という事情は、逆に
                「大多数を占めるWindowsで(標準機能では)使えないようなファイルシステムなんて
                存在していても大多数の人々には無縁」
                というのが実情で
              • by Anonymous Coward
                >前回と違うところに書き込もう

                確かにそうなんですが、
                その層「も」頑張る一方で、
                他の層「も」頑張っても良いんですよ。

                そういえば、PocketBSDで、
                それこそFlashを持たせるため+省電力のために、
                ファイルへのアクセス時刻(書き込み時刻じゃなくてね)を
                記録しない、という設定をしとくといいぞという話があった。

                書き込むべきもの自体を減らしてしまえってことです。
                当然ですが、Flashドライバ「だけ」が頑張るよりは、
                両方が頑張るほうが効果は増します。

                これは簡単な設定の話でしかないけど、
                もうちょっと大げさなチューニングになると、
                ソースからForkするほうが良い場合もあるでしょう。

                そして、
                「どの層でも」そういうチューニングをおこなうことが出来て、
                しかも実際にチューニング済みなものの選択肢も(現実に)多いのが、
                自由OSの現状です。
              • by Anonymous Coward
                ファイルシステムの設計構造に詳しくないのであまり的確な回答はできませんし、元ACでもありませんが、

                参考までに、FAT/NTFSしかファイルシステムの選択肢が無いことによる、ユーザに対する 具体的な弊害を教えていただけますでしょうか(特にNTFS)。

                Windowsのシステム自体がNTFSに特化しているため、Windows上で使用する限りは「具体的な弊害」がありません。むしろ具体的な弊害が出たらMS自身がNTFSの仕様自体を変更しています(NT4→2000)
                最も大きな問題は、全く特性の違うデバイス(SSD)に対応するのに、HDDの特性に最適化されたファイルシステムでは最適化に無理がある

              • by Anonymous Coward
                全くオフトピなんですが、Windows上でNTFSをリードオンリーでマウントする方法って無いもんですかね。
                それこそ Linuxなら楽勝なわけですが、EFSを読まねばならないのでどーにも…。

                個人的に Windows が NTFS/FAT/UDF のみ対応で不満は無いんですが、
                マウントするともれなく書き込みがついてくるというのは不便で仕方が無いです。
              • by Anonymous Coward
                (#1325329)と(#1325339)のお二方、丁寧に教えていただきありがとうございます。

                Flashメモリの場合、セルの劣化を防ぐための工夫だけでなく、書き込みの頻度低減や
                書き込みの特性を意識した制御のために、上位層のファイルシステムにも工夫を施したい
                のですね。勉強になりました。

                この辺りの工夫がされて、特にWindowsの起動Diskへのアクセスが速くなると、
                個人的にはうれしいです。
                仕事では主にNotePCを使っているので特に。

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

処理中...