アカウント名:
パスワード:
512が主流になったのは(昔の)UNIXが512決め打ちだったからじゃなかったかなぁ。
セクター長を1024に変えて容量を増やすのは、常套手段でしたが、そのためには、/etc/disktab を手で書かなくてはいけないので、ちょっと面倒でした。この話題、まだ検索にひっかかりますね。
http://www.nextcube.org/board/bbs.php3?board=doc&line=subject&... [nextcube.org]
ひょっとしたら当時生まれていなかった人も読んでいるでしょうから蛇足を加えると、NeXTstepは、現在の MacOS X の源流の Unix系 OS です。今の Mac ではセクタ長を選べるのでしょうか？
思わずPC-9801のMS-DOS FDフォーマットを思い出しました。
MS-DOSで使われていた5インチ2HDのフロッピーディスクは、PC-9801: 1024バイト/セクタ×8セクタ/トラック×77トラック/面×両面=1232KiBPC互換系: 512バイト/セクタ×15セクタ/トラック×80トラック/面×両面=1200KiB(通称2HC)の2種類があったのでした。
1024バイトセクタを採用することで、512バイトセクタと比べて、1トラックあたりの容量が7.5KiB→8KiBと約7%増えています。
(そのかわり、PC-9801で使われていた方は、8インチ2D規格を5.25インチに持ち込んだため77トラックしかないのに対し、PC互換機系の方は、それまでの5.25インチ規格と同じ80トラックを採用したため、結果的に容量はほとんど同じになっちゃってますけど…)
で、当時からPC互換機系のMS-DOSはセクタサイズが512バイト決めうちになっていたため、そのままではPC-9801の2HDフロッピーは読み書きすることができなかったので、データ交換が面倒だったのですが、PC-9801用の2HDを読み書きできるAT互換機DOS用ドライバが出てきて世界が一変したのでした。
そのドライバは、内部で1024バイトセクタと512バイトセクタの変換処理を行うため、DOSからは512バイトセクタのメディアに見えるようになっていたのですが、DOSから見て奇数セクタ数の書き込みを行った場合、メディア上では1024バイトセクタの半分だけ書き込む必要があります。そういう場合は、一端1セクタ1024バイトを読み込んでから、半分の512バイトを書き換えたデータを作って、書き込みを行う、という処理の流れになるため、かなりパフォーマンスが落ちたのでした…
…というオサーンほいほいな思い出話ですが、というわけで、OSがネイティブに対応していないと、パフォーマンス的に悲しいことになるんじゃないかと心配してしまいます。まあ、最近はドライブ内部にキャッシュがあるから、それほどひどいことにはならないと思いますが…
ていうか、ドライブが内部で変換してくれればいいじゃん、とか思ってしまいますね。
#MacOSXやUN*X系OSの対応はどうなんだろう?
> 思わずPC-9801のMS-DOS FDフォーマットを思い出しました。
TRS-80 Model I [trs-80.org] に CP/M を移植したときに、そういうオレサマフォーマットして悦に入っていたことを思い出しちまったよ。詳細は忘れちまったけどね。
＃あのころは、たかが 512 byte が、なんて貴重だったんだろう。＃いや、128 byte と 256 byte だったかもしれない。
全部じゃないけど元記事にある程度の解説が、、、
>互換性を維持するためにAdvanced Format Technologyでは、ドラ>イブインターフェイスにおいて4,096バイトの物理セクタを512バ>イトの論理セクタに組み立てるエミュレーションを行う。
>Advanced Formatは、Windows 7/ Vista、Mac OS X Tiger/ Leopa>rd/ Snow Leopardなど、新しい世代のOSの機能にHDDを最適化さ>せる技術である
この辺を読んでいると垂直磁気記録方式はDTRやBPMと言った技術と組み合わせることでまだ当分イケそうですね。【PC Watch】 DISKCON JAPAN 2009レポート ～HDDの記録密度向上ペースを鈍らせないために [impress.co.jp]日本HDD協会2008年10月セミナーレポート [impress.co.jp]東芝：プレスリリース (2007.09.06) [toshiba.co.jp]
意外でしたよね。半導体メモリはあと2～3回しか密度倍加できないんでしたっけ。
当時ドライバを書いていましたが、DOS では 2048 セクタのメディアは、512 セクタに見えるように変換していましたね。
Windows NT では認識しませんでしたが、Windows 2000 からは、こっそり対応してました。
当時の Linux は 2048 メディアを差し込むと、ハングアップしてましたね。
ずいぶん懐かしい話ですが、今頃こんな話がでてくるとは・・・
Linux 2.0.38あたりを使っていたときに2048バイト/セクタパッチ当ててMO使ってましたなぁ…。
NTも一応認識はします。ただ、起動時にMOをドライブに刺してたり、540MB以下と640MB以上を混在したり、640MBだとエクスプローラーからフォーマットできなかったりとか。# 使えないのとほぼ同義なのでSCSIカードやMO等に付属のドライバを組み込むのですけどね。
それとは別にNTFSフォーマットしたりするとディスクを抜けなくなる等の事象が発生したりします。こちらはポリシーで設定可能。とはいえ普通はFATでしょうけど。# GigaMOドライブを高速MOとして繋ぐこともあるけど今やUSBスティックの方が全てにおいて便利よね。メディア自体の耐久性以外は。
こんなこともあろうかと！Vistaから512Byte超のセクタサイズに対応できるようにしておいた・・・のかと思ったら、リンク先読むと、予定されていたことだったみたいですね。
基本的に最近のMSは「こんなこともあろうかと」で対応はしません。下手な「対応」はセキュリティホールの温床になるだけですから。フラッシュメモリの大幅な値下がりでUSBメモリが一気に普及したけど「こんなこともあろうかと」CD/DVD以外からのオートランにも対応してたらConflicker大流行でござるの巻とか。
512bytes以上4096bytes以下のサイズ差が問題になるエロ画像なんて存在するの？
画像ファイルなんて今時なら数MBytesなんて当り前なのかと想像してました。いつの世もリソースを一番食うのはエロだよね。
もともとOSは8セクタ=1クラスタで管理してたので、違いは出ません。
「8セクタ=1クラスタ」(=4096bytes)はNTFSでの規定値ですね。(厳密には16TB以下のストレージでの規定値ですが)FAT32だと1クラスタが64セクタ(=32KiB)なんてこともザラでした。http://support.microsoft.com/kb/140365/ja [microsoft.com]
どちらにしろ，大半のHDDは4096bytesの倍数が最小の管理単位でフォーマットされますから，1セクタが512bytesから4096bytesになっても，容量の無駄は無い筈です。
NTFSの場合小さいファイルはMFTに配置されるから大丈夫ではないかとその閾値は調べてないですが
http://lwn.net/Articles/322777/ [lwn.net]
Linux は patch があるみたい(2ch でリンクされてた)http://pc11.2ch.net/test/read.cgi/jisaku/1259989662/541 [2ch.net]
FreeBSD に関しては IDEMA とか BigSector で site:FreeBSD.org 探しても引っかからない
Linux は patch があるみたい(2ch でリンクされてた) http://pc11.2ch.net/test/read.cgi/jisaku/1259989662/541 [2ch.net]
DAT落ちしてたので転載。
541：Socket774 ：sage：2009/12/11(金) 11:07:57 ID: J5AFwax/ (1)これをWDが初めて導入したってことでok？HDD業界団体が標準セクター・サイズを4Kバイトに拡大，「Windows Vista」は対応予定 http://itpro.nikkeibp.co.jp/article/USNEWS/20060324/233190/ [nikkeibp.co.jp] Slashdot | Long Block Data Standard Finalized http://hardware.slashdot.org/article.pl?sid=07/05/01/2021244 [slashdot.org] Hard Disk Drive Long Data Sector White Paper http:/ [idema.gr.jp]
541：Socket774 ：sage：2009/12/11(金) 11:07:57 ID: J5AFwax/ (1)これをWDが初めて導入したってことでok？
HDD業界団体が標準セクター・サイズを4Kバイトに拡大，「Windows Vista」は対応予定 http://itpro.nikkeibp.co.jp/article/USNEWS/20060324/233190/ [nikkeibp.co.jp] Slashdot | Long Block Data Standard Finalized http://hardware.slashdot.org/article.pl?sid=07/05/01/2021244 [slashdot.org] Hard Disk Drive Long Data Sector White Paper http:/ [idema.gr.jp]
自社のRAID装置は、データ512byteにend-to-endでデータの同一性を保証するためのトレーラ情報8byteを足して1セクタ520byteでフォーマットし直してるなぁ…
データ経路上全てで520byte単位で処理しているので、HDDだけBigSectorに対応しても全く恩恵にあずかれなかったり。そろそろRaidEngineを全部作り直ししないとなぁ。
>２HDの容量は基本2MB
シーケンシャルに使えばね・・・って事でその昔、98用でそんな独自フォーマットを使うバックアップソフトがあったとさ。当然ながらランダムアクセスは出来ないんだけど、ディスク枚数と時間を節約できるんで結構便利でした。(FATが無い、ギャップが無いから実効転送速度が上がる、回転待ちをトラック変えた時しかしない等での高速化)
#なんでもっと早くに物理セクタでかくしなかったんだろう。どうせクラスタサイズが肥大化してるのに。#そういえば3Mのフロッピーが(略
普通の人は現状で容量に困ってないから。容量的に困っているのは動画を扱う人のみだし。
Windows7については、既に問題は少ないと思う。そもそもVistaSP2だと思えば問題ないし。
アプリ的にはVistaの段階で移行しているから問題は無い。というか、ヘンにVista選ぶより良い。今の段階でVista対応すら考えていない会社だと顧客に捨てられるよ。
Vista対応というか、UAC対応をする=アクセス権限をきちんと管理する=アプリケーションがクラックされた時の被害減少というのもあるので真面目にVista対応してほしいです。w2kのターミナルサーバー対応アプリケーションのガイドラインを満たせば良いのだからさ。
x86のセグメントサイズ4Kもいやだなx86はやく無くならないかしら...
見た目の容量が、7-11%拡大されるブラですか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
昔話 (スコア:5, 興味深い)
512が主流になったのは(昔の)UNIXが512決め打ちだったからじゃなかったかなぁ。
NeXTstepでは (スコア:2, 興味深い)
セクター長を1024に変えて容量を増やすのは、常套手段でしたが、そのためには、/etc/disktab を手で書かなくてはいけないので、ちょっと面倒でした。この話題、まだ検索にひっかかりますね。
http://www.nextcube.org/board/bbs.php3?board=doc&line=subject&... [nextcube.org]
ひょっとしたら当時生まれていなかった人も読んでいるでしょうから蛇足を加えると、NeXTstepは、現在の MacOS X の源流の Unix系 OS です。今の Mac ではセクタ長を選べるのでしょうか？
Re:昔話 (スコア:1, 興味深い)
ソフトセクタ式HDDでセクタサイズ変更後に容量が結構増えていたと記憶しています。
PC-9801時代のFDフォーマット (スコア:5, 興味深い)
思わずPC-9801のMS-DOS FDフォーマットを思い出しました。
MS-DOSで使われていた5インチ2HDのフロッピーディスクは、
PC-9801: 1024バイト/セクタ×8セクタ/トラック×77トラック/面×両面=1232KiB
PC互換系: 512バイト/セクタ×15セクタ/トラック×80トラック/面×両面=1200KiB(通称2HC)
の2種類があったのでした。
1024バイトセクタを採用することで、512バイトセクタと比べて、1トラックあたりの容量が7.5KiB→8KiBと約7%増えています。
(そのかわり、PC-9801で使われていた方は、8インチ2D規格を5.25インチに持ち込んだため77トラックしかないのに対し、
PC互換機系の方は、それまでの5.25インチ規格と同じ80トラックを採用したため、結果的に容量はほとんど同じになっちゃってますけど…)
で、当時からPC互換機系のMS-DOSはセクタサイズが512バイト決めうちになっていたため、
そのままではPC-9801の2HDフロッピーは読み書きすることができなかったので、データ交換が面倒だったのですが、
PC-9801用の2HDを読み書きできるAT互換機DOS用ドライバが出てきて世界が一変したのでした。
そのドライバは、内部で1024バイトセクタと512バイトセクタの変換処理を行うため、DOSからは512バイトセクタのメディアに見えるようになっていたのですが、
DOSから見て奇数セクタ数の書き込みを行った場合、メディア上では1024バイトセクタの半分だけ書き込む必要があります。
そういう場合は、一端1セクタ1024バイトを読み込んでから、半分の512バイトを書き換えたデータを作って、書き込みを行う、という処理の流れになるため、かなりパフォーマンスが落ちたのでした…
…というオサーンほいほいな思い出話ですが、
というわけで、OSがネイティブに対応していないと、パフォーマンス的に悲しいことになるんじゃないかと心配してしまいます。
まあ、最近はドライブ内部にキャッシュがあるから、それほどひどいことにはならないと思いますが…
ていうか、ドライブが内部で変換してくれればいいじゃん、とか思ってしまいますね。
#MacOSXやUN*X系OSの対応はどうなんだろう?
Re:PC-9801時代のFDフォーマット (スコア:2)
> 思わずPC-9801のMS-DOS FDフォーマットを思い出しました。
TRS-80 Model I [trs-80.org] に CP/M を移植したときに、そういうオレサマフォーマットして悦に入っていたことを思い出しちまったよ。詳細は忘れちまったけどね。
＃あのころは、たかが 512 byte が、なんて貴重だったんだろう。
＃いや、128 byte と 256 byte だったかもしれない。
Re: (スコア:0)
CP/M86になっても同様で、MS-DOSのほうがディスクは圧倒的に高速でした。(DOSのほうがファイルシステム全般的に優れていましたが)
Re: (スコア:0)
全部じゃないけど元記事にある程度の解説が、、、
>互換性を維持するためにAdvanced Format Technologyでは、ドラ
>イブインターフェイスにおいて4,096バイトの物理セクタを512バ
>イトの論理セクタに組み立てるエミュレーションを行う。
>Advanced Formatは、Windows 7/ Vista、Mac OS X Tiger/ Leopa
>rd/ Snow Leopardなど、新しい世代のOSの機能にHDDを最適化さ
>せる技術である
Re: (スコア:0)
1024バイト * 5セクタ + 256バイト * 2セクタ = 5.5kB
なんてのもありました。
PC88は標準256バイト * 16 = 4kBだったから、137.5%。
これに続くのはDTRとBPMなんでしょうかね (スコア:3, 興味深い)
この辺を読んでいると垂直磁気記録方式はDTRやBPMと言った技術と組み合わせることでまだ当分イケそうですね。
【PC Watch】 DISKCON JAPAN 2009レポート ～HDDの記録密度向上ペースを鈍らせないために [impress.co.jp]
日本HDD協会2008年10月セミナーレポート [impress.co.jp]
東芝：プレスリリース (2007.09.06) [toshiba.co.jp]
屍体メモ [windy.cx]
Re: (スコア:0)
SSDがHDDを抜いて主役になる日は来ないんでしょうね。
Re: (スコア:0)
意外でしたよね。
半導体メモリはあと2～3回しか密度倍加できないんでしたっけ。
MOでもあったよ (スコア:3, 興味深い)
540MB と 640MB ディスクは記録密度がほぼ同一で、
セクターサイズの 512B/2048B の違いでこれだけの容量差を
稼いでました。
（CD に対抗するためにどうしても 640MB にしたかったらしい）
セクターマークそのものや、セクターマークを「読んで」から
データ「書き込み」に切り替えるなどの時間を稼ぐための
マージンとしてのギャップや、再生信号と同期をとるための
ヘッダーパターンを書き込む領域は 1/4 に節約できますね。
ECCデータ長はエラー訂正力を同一にするためにセクターサイズに
比例して増えるし、回転ムラを吸収するためのギャップ長は
セクター長が長くなるので相対的に変わらなかったと思います。
Re:MOでもあったよ (スコア:2)
>それにしても、いままでもMOは2048bytesセクタを使っていたような気がするのだが、どう対応していたのだろう。
と言及しておいたのですが、なぜか採用されるときに消されました。
そんなにMOはマイナーなのか。
Re: (スコア:0)
win95(98/Me) は何故かそのまま使えた。ただし OS 起動時にメディアが
すでにあると そのセクターサイズがどこかに残り、異なるセクター
サイズのメディアに差し替えると問題を起こした。
winNT は忘れた。win2000 は普通に使えたように思う。
FreeBSD などは日本の有志が対応していたように思う。
1GB の iPodShuffle を買ったときに調べたらこれは 2048b/sect だった。ブートメディアに使えないじゃん！とがっかりした。
それから後の最近の事情はよくわかりません。
Re:MOでもあったよ (スコア:2, 興味深い)
当時ドライバを書いていましたが、
DOS では 2048 セクタのメディアは、
512 セクタに見えるように変換していましたね。
Windows NT では認識しませんでしたが、
Windows 2000 からは、こっそり対応してました。
当時の Linux は 2048 メディアを差し込むと、
ハングアップしてましたね。
ずいぶん懐かしい話ですが、今頃こんな話がでてくるとは・・・
Re:MOでもあったよ (スコア:1)
Linux 2.0.38あたりを使っていたときに
2048バイト/セクタパッチ当ててMO使ってましたなぁ…。
Re:MOでもあったよ (スコア:1)
NTも一応認識はします。
ただ、起動時にMOをドライブに刺してたり、540MB以下と640MB以上を混在したり、640MBだとエクスプローラーからフォーマットできなかったりとか。
# 使えないのとほぼ同義なのでSCSIカードやMO等に付属のドライバを組み込むのですけどね。
それとは別にNTFSフォーマットしたりするとディスクを抜けなくなる等の事象が発生したりします。
こちらはポリシーで設定可能。とはいえ普通はFATでしょうけど。
# GigaMOドライブを高速MOとして繋ぐこともあるけど今やUSBスティックの方が全てにおいて便利よね。メディア自体の耐久性以外は。
こんなこともあろうかと！ (スコア:2)
こんなこともあろうかと！
Vistaから512Byte超のセクタサイズに対応できるようにしておいた・・・のかと思ったら、
リンク先読むと、予定されていたことだったみたいですね。
Re: (スコア:0)
基本的に最近のMSは「こんなこともあろうかと」で対応はしません。下手な「対応」はセキュリティホールの温床になるだけですから。フラッシュメモリの大幅な値下がりでUSBメモリが一気に普及したけど「こんなこともあろうかと」CD/DVD以外からのオートランにも対応してたらConflicker大流行でござるの巻とか。
無知で申し訳ないのですが (スコア:2)
セクタ/クラスタ端数領域の無駄が増えて結局損してたりしませんかね。
細かいエロ画像とかエロ画像とかエロ画像とかたくさん持ってる人とか。
あと不良セクタのダメージが増えたり。
#そんなの誤差だとは思いますが、7-11%増える程度も誤差のような、
#と言いたくなる昨今のHDD価格にビックリ。
Re:無知で申し訳ないのですが (スコア:2)
512bytes以上4096bytes以下のサイズ差が問題になるエロ画像なんて存在するの？
画像ファイルなんて今時なら数MBytesなんて当り前なのかと想像してました。
いつの世もリソースを一番食うのはエロだよね。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
もともとOSは8セクタ=1クラスタで管理してたので、違いは出ません。
Re: (スコア:0)
「8セクタ=1クラスタ」(=4096bytes)はNTFSでの規定値ですね。
(厳密には16TB以下のストレージでの規定値ですが)
FAT32だと1クラスタが64セクタ(=32KiB)なんてこともザラでした。
http://support.microsoft.com/kb/140365/ja [microsoft.com]
どちらにしろ，大半のHDDは4096bytesの倍数が最小の管理単位でフォーマットされますから，
1セクタが512bytesから4096bytesになっても，容量の無駄は無い筈です。
Re: (スコア:0)
Re: (スコア:0)
NTFSの場合小さいファイルはMFTに配置されるから大丈夫ではないかと
その閾値は調べてないですが
続きまして某教祖様によります (スコア:1, 興味深い)
Vista/7以外の対応状況は？ (スコア:1, 興味深い)
Linuxはどうなってるんだ？とちょっと調べたんですが、やっぱり63セクタで決め打ちになってるようで・・・そのままじゃ無理ぽい。EFIならできるのかもしれないけど、そうするとXPなど古いOSとのマルチブート環境で辛いことになりそう。
うちはTrueCryptでWindowsシステム暗号化してるんで、さらに厄介なことに。
今後の主流になるかわかりませんが、その他ソフトの対応に期待したい。
Re:Vista/7以外の対応状況は？ (スコア:1, 参考になる)
http://lwn.net/Articles/322777/ [lwn.net]
Linux は patch があるみたい(2ch でリンクされてた)
http://pc11.2ch.net/test/read.cgi/jisaku/1259989662/541 [2ch.net]
FreeBSD に関しては IDEMA とか BigSector で site:FreeBSD.org 探しても引っかからない
Re: (スコア:0)
DAT落ちしてたので転載。
1024^3/1000^3≒1.07 (スコア:1)
512バイトだったのか… (スコア:1)
1Kバイト=1000バイト
1Mバイト=1000Kバイト
（以下略
として扱っているけど、てっきり1セクタ=1000バイトだからそのようにしてるのかと思ってた。
セクタサイズ520byte (スコア:0)
自社のRAID装置は、データ512byteにend-to-endでデータの同一性を保証するためのトレーラ情報8byteを足して1セクタ520byteでフォーマットし直してるなぁ…
データ経路上全てで520byte単位で処理しているので、HDDだけBigSectorに対応しても全く恩恵にあずかれなかったり。
そろそろRaidEngineを全部作り直ししないとなぁ。
Re: (スコア:0)
物理フォーマットしなおしてサーバに突っ込んでたことも
あったなぁ。
アクセスランプがアクセス時に消灯だったりするので
区別しつつ。
# 特定されそうなのでAC
X68000 (スコア:0)
DOSでフォーマットしちゃうと1.2MB程度になっちゃうけど、某フリーのフォーマッタでフォーマットすると
2MBフルに使えるディスクになっちゃうのあったよね？
あんな感じのを誰か開発してくれないかな。ブートは出来なくていいから。
1.5TB買っても使えるのは1.27TBって・・・
どういうことやねん。
Re:X68000 (スコア:1)
>２HDの容量は基本2MB
シーケンシャルに使えばね・・・
って事でその昔、98用でそんな独自フォーマットを使うバックアップソフトがあったとさ。
当然ながらランダムアクセスは出来ないんだけど、ディスク枚数と時間を節約できるんで結構便利でした。
(FATが無い、ギャップが無いから実効転送速度が上がる、回転待ちをトラック変えた時しかしない等での高速化)
#なんでもっと早くに物理セクタでかくしなかったんだろう。どうせクラスタサイズが肥大化してるのに。
#そういえば3Mのフロッピーが(略
凛々しく、あほらしく。
オーシャノグラフィー (スコア:2)
当時(1986年)業務で20MのHDDを利用していて、1プロジェクトが300kb～10MB程度の
プロジェクトのバックアップに利用していました。
たしか、圧縮した後オーシャノを立ち上げる、そんなバッチを作っていました。
とにかくデータ転送が早く、ふつうにコピーしたら2～3分かかる作業が、
ソフトの立ち上げ時間を入れても30秒程度で済んでいたと思います。
まず、HDDが100Mになり(ミドリ電子だったと思う)、
Zipドライブにバックアップを変えてから、オーシャノの出番は無くなりました。
Re: (スコア:0)
オーシャノグラフィ2だったと思います。フォーマット形式は不明ですが、たしか超大サイズのセクターを作ってデータを詰め込む形式だったはず。
しかしそんなローカルマシンを例に挙げなくても、マイクロソフトがWindows 95のインストールメディアで採用したDMF(Distribution Media Format: 1.68MB)や、IBMがPC-DOS7.0やOS/2 Warpで使ったXDF(eXtended Density Format: 1.86MB)なんかの方が有名ですね。
前者は書き換える必要が無いインストールメディアという性
Re:X68000 (スコア:1, すばらしい洞察)
それは 1000vs1024 と filesystem の仕様のせい
なのではなくて？
... | dd of=/dev/rsd2c すればぁ？
ちなみに FDD にはエラー訂正という概念は入ってません。
"読めませんエラー"が検出されて終わりです。
普及が遅れている・しないのはしょうがないだろう (スコア:0)
いまだに売れている・普及しているのがＸＰなんだもの。
７だってまだ企業などの組織体はまだ様子見・・・・評価するために多少製品を買っているだけだろう。
少なくともＳＰ１が出るまでは本格普及は先だろう。
そういう意味で今から約1年くらいは、ベンダー側がＷｉｎ７に対応したり、トラブル情報を収集したり
とノウハウをためている時期かと・・・ＳＰ１が出て2年目以降からようやくお客様への提案書に書くよう
になり、予算執行はその次の年じゃないかね？
かといって、ベンダーもお客もＶｉｓｔａにはＯＳそのものにノーを突きつけたから、
結局提案書に書くことはなかったがね。
個人向けはＷｉｎ７しかないから泣く泣く買っているにすぎない。
ＸＰがあったら、ＸＰを買う人のほうがまだまだ多いと思う。
今買っている人は正直新しいものが好きなＰＣ好きであり、一般ユーザーが
手を出しているのはまだまだごく少数（ＰＣが壊れて仕方なく買い替えとか）。
私の場合、評価および開発ソフトのテストで仕方なく使ったけど、メインはまだまだＸＰだから・・・
Ｗｉｎ７に本格的な移行はまだまだ先だと思う。
皆さんはどうでしょう？
お客様への本格導入で今既にWin7を前提の案書を既に今書けてますか？
Re: (スコア:0)
Vistaと違い、Windows 7はそれなりに話題になりましたからわざわざWindows 7を指名買いする人もそれなりに居るような印象があります。
今までの例を見ると、OSが切り替わるタイミングって「世の中に普通に売っている(なにか)が、古いOSでは使えなくなったとき」というのが多いような気がします。たとえば、Windows 95と98は、外見上ほとんど違わないOSだったけど、USB機器が使えなかったり、4GB以上のHDDが使えなかったりといった理由で「95にしがみつく人」はそれほど多くはなかった。
一方でWindows 2000→XPなんていうのは、××が使えない、というのがそれほど多くなかったので、今でもまたWindows 2000を使い続けている例も多い。今回に関しては、2TB超のHDDがそれにあたるかもしれません。すでに世の中には2TB容量のHDDも普通に出回り始めており、2TBオーバーも最早時間の問題。そうなったとき、2TBオーバーのドライブが使えないXPがどうなるか、てところでしょうか?
それ以前に (スコア:0)
普通の人は現状で容量に困ってないから。
容量的に困っているのは動画を扱う人のみだし。
Windows7については、既に問題は少ないと思う。
そもそもVistaSP2だと思えば問題ないし。
アプリ的にはVistaの段階で移行しているから問題は無い。
というか、ヘンにVista選ぶより良い。
今の段階でVista対応すら考えていない会社だと顧客に捨てられるよ。
Re: (スコア:0)
Vista対応というか、UAC対応をする=アクセス権限をきちんと管理する=アプリケーションがクラックされた時の被害減少というのもあるので真面目にVista対応してほしいです。
w2kのターミナルサーバー対応アプリケーションのガイドラインを満たせば良いのだからさ。
メモリも (スコア:0)
x86のセグメントサイズ4Kもいやだな
x86はやく無くならないかしら...
Re:メモリも (スコア:2)
(リアルモードでアセンブラプログラミング？)
>x86はやく無くならないかしら...
これには同意(^^;)
Re:メモリも (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
Re:新作プレミアムブラ 今だけ!送料無料 \1,480～(税込) (スコア:1)
見た目の容量が、7-11%拡大されるブラですか？