親子におすすめの新型プラネタリウムとは?

μITRONでの開発経験しかない者です。
Linuxについては見たことも触ったこともない、
全くのど素人ですが、どうぞ宜しくお願い致します。

かなりざっくりとした質問になるかと思いますが、
出来れば具体的なケースなど用いて細かくご回答
頂けると助かります。

(1)Linux上で動くアプリを作った場合、そのアプリは開示義務が
あると言えるのでしょうか?

(2)Linux上で動くアプリを作った場合、何をしたら開示義務が
適用されますか?

(3)この家電はこういうやり方で開示義務を免れているという
ような例があればお願い致します。


ちなみにGPLとLGPLなるものが存在することは承知しております。

このQ&Aに関連する最新のQ&A

A 回答 (4件)

一応理解の範囲内で回答します。



(1)
質問が「必ずあるのか」という意味ならNo。

(2)
GPLのソースコードを流用などした場合、そのアプリ全体をGPLとして扱わなければなりません。
LGPLのライブラリを静的にリンクした場合、そのアプリはソースコードかオブジェクトの開示が義務付けられます。(動的リンクに制約はなし)

(3)
Cで開発する場合、おそらくGCCを利用するでしょうがglibcはLGPLです。
ですから、これをスタティックリンクしない形ですべてのコードを自前で作成すれば、アプリ部分の公開義務はありません。

たとえばBuffaloのNAS(LinkStation等)ではシステム部分(MontaVista Linux)自体のコードは公開していますが、制御部分は自社で作成していてそのコードは非公開です。

特に「うっかりGPLコードを流用した奴がいて炎上」って話が危険なので、非公開アプリを作りたいならコード管理は厳密にやらないと危険です。

この回答への補足

イーサのドライバなどもGPLなのでしょうか?

 アプリ→TCP/IPスタック→イーサドライバ(GPL?)
上記の流れのようにアプリからTCP/IPの送信APIをコールしイーサの
処理に入るような場合、アプリは公開対象にはならないでしょうか?

何か勘違いしているかもしれませんが、宜しくお願い致します。

補足日時:2009/12/05 14:02
    • good
    • 0

えーと、誤解を恐れずにざっくりぶったぎると、要は「コードをアプリに取り込まなければ問題ない」ってことです。



> アプリ→TCP/IPスタック→イーサドライバ(GPL?)

この例であれば、アプリはドライバのコードを含まないのでOK、ということになります。
まぁ#3でも言われているように「法務に聞いた方が確実」ではあるかと思いますが。
    • good
    • 0
この回答へのお礼

以前よりクリアになってきました。
ありがとうございました。

お礼日時:2009/12/17 17:54

> (1)Linux上で動くアプリを作った場合、そのアプリは開示義務が


> あると言えるのでしょうか?

> (2)Linux上で動くアプリを作った場合、何をしたら開示義務が
> 適用されますか?

No.アプリを作るだけではソースコードの開示義務は発生しません。
以下の条件の★両方★を満たしている場合に発生する可能性があります。

- 自作したアプリの中にGPL でライセンスされたソースコードのすべてま
たは一部が含まれているまたはリンクされている。
- 自作したアプリを外部に公開しようとしている。

※動的リンクの場合は組み込まれていると解釈しないケースもあるのでグレーです。
(ただし、FSF の見解としてはブラックです)
※glibc は LGPL ですので、リンク可能ですし、gcc は例外条項があるため、
gcc でコンパイルされたアプリまでに gcc の GPL が及ぶことはありません。

> (3)この家電はこういうやり方で開示義務を免れているという
> ような例があればお願い致します。

- GPL でライセンスされたアプリと連携しない。
- ソースコードを公開する。

あと、会社であれば法務担当に相談されるのがよろしいかと思います。
    • good
    • 0
この回答へのお礼

ありがとうございました。

お礼日時:2009/12/17 17:52

既存のソースを利用した場合には、そのソース元のライセンスやライブラリだと静的リンクや動的リンクの場合など、また、ライブラリも同時配布なのかという点もあるので、作り方それぞれです。



BSDライセンスと呼ばれるものは、比較的ゆるく商用利用とかしても、オリジナルのライセンス文や作成元を明記するだけでも良いものから、商用の場合は別途ライセンスフィーがかかるもの、ソース公開も必須と様々です。

家電系では、Linuxを使っているところであれば、基本は開示しているはずなので、開示義務があれば、それを逃れることはできません。
結局、既存のものを使って安く仕上げるから、プロプリエンタリーでコストをかけて守るかのどっちかですかね。
    • good
    • 0
この回答へのお礼

ありがとうございました。

お礼日時:2009/12/17 17:51

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QLinux上で動作するアプリケーションの公開義務

私はLINUXを組み込みで使おうとしている会社員です。
LINUXはGPLが適用されておりOS本体の改造など行なった場合、
公開の義務があるらしいのですが次のケースは公開義務が発生するのでしょうか?
御存知の方、是非御教授の程、宜しく御願いします。

・Linux上で作成した流用母体の無いアプリケーション
・サイトからダウンロードしたサンプルプログラムを一部流用した
 アプリケーション
・Linux上で作成した流用母体の無いドライバ

Aベストアンサー

「公開義務」って言葉があやふやですねえ。

GPL にのっとれば「複製、及び配布(copy and distribute)」です。
後、あなたが言う「公開義務」に含まれそうなのは、

・あなた以外の第三者による利用を制限できない
・ソースを添付するか、第三者への提供の義務がある

ですね。

少なくとも、

> ・サイトからダウンロードしたサンプルプログラムを一部流用したアプリケーション

が、ひっかかりそうですね。そのサンプルプログラムが GPL であれば、の話ですが。


それ以外は、別に GPL に従わなければいけない、ということは無いです。
現実に GPL 以外のライセンスにしたがって、作られたプログラムが linux 上で
動いています(*)から。


まずは、きちんと GPL を読みましょう(→参考URL)。

# GPL って解釈が結構難しいので、この回答にも法的な責任は負いかねます m(_ _)m

参考URL:http://www.gnu.org/copyleft/gpl.html,http://www.gnu.org/copyleft/copyleft.ja.html

「公開義務」って言葉があやふやですねえ。

GPL にのっとれば「複製、及び配布(copy and distribute)」です。
後、あなたが言う「公開義務」に含まれそうなのは、

・あなた以外の第三者による利用を制限できない
・ソースを添付するか、第三者への提供の義務がある

ですね。

少なくとも、

> ・サイトからダウンロードしたサンプルプログラムを一部流用したアプリケーション

が、ひっかかりそうですね。そのサンプルプログラムが GPL であれば、の話ですが。


それ以外は、別に GPL に従...続きを読む

QGPLによるソース公開の回避方法

GPLライセンスの下で頒布されているソフトウェアライブラリなどをリンクして作成したプログラムを頒布する再には、当該プログラムのソースコード入手経路を確保しなければならないことになっていますが、これを回避するための方法はありますか?

Aベストアンサー

別のプロセスに分離する。GPLをリンクしたプロセスだけは公開する必要あり。
この分離についても実のところはグレイゾーン。あと動的リンクもグレイゾーンとされている。判例は今のところありません。

QLinuxでスレッド優先度って変えられますか?[pthread C/C++]

はじめまして。

Suse Linux 10を使用して、
C++でスレッド(pthread)を用いたプログラムを作ってあるのですが、
更にスレッド優先度を設定する必要があります。

ですが、一般ユーザではスレッド優先度が効かないようです。
super userでログインした場合には効果あるようです。

一般ユーザとsuper userで異なる理由は何なのでしょうか?
サンプルプログラムはありません。申し訳ありません。
コードレベルでないと分からない部分もあるかもしれませんが、
一般論として、そもそも一般ユーザでもスレッドの優先度は変えられるか!?

どなたか詳しい方がおりましたらご教授ください!
宜しくお願いします。

Aベストアンサー

> ただ、シンプルにスレッド作成時に優先度設定できればいいんですがね。。。

スレッド作成時に指定したければpthread_attr_setschedparamを使えば良いですが、本質的には同じことです。内部ではsched_setscheduler(2)を使うでしょうから権限による制限は同じです。
# http://www.linux.or.jp/JM/html/glibc-linuxthreads/man3/pthread_attr_setschedparam.3.html

参考URL:http://www.linux.or.jp/JM/html/glibc-linuxthreads/man3/pthread_attr_setschedparam.3.html

QGPLライセンスのライブラリを利用=ソース公開しなきゃだめ?

GPLライセンスについて調べています。
考え方がまちがっていたらご指摘いただきたいです。

1.GPLライセンスのライブラリを用いたシステム開発を行った場合
  ソースの開示を求められたら、開示しなければいけない?

たとえば、Javaで開発したシステムの場合、ここでいうソースコードとはjavaファイル郡になるのでしょうか?
jarファイルとかwarファイルだけでは駄目 ということですよね?

2.GPLライセンスのライブラリを用いたソフトを作って売る場合も
  同様で、ソースの開示を求められたら、開示しなければいけない?

つまりは、Javaで開発したソフトをパッケージ販売したいなら、
ソースコードをお客に開示するつもりでいなければならない ということでいいですか?

また、ソースコードを開示する先 は、お客だけでいいのでしょうか?
まったく関係のない人から開示を求められた場合も、ソースコードを渡さなきゃいけないのでしょうか?

以上です。
よろしくおねがいします。

Aベストアンサー

僕もあまり詳しくはないですが、
GPLで配布について求められていることは、
バイナリを直接配布する場合、そのバイナリを入手するのと
同じ手順でソースコードも入手できるようにすることだったと思います。

つまり、サイト経由でバイナリを配布するならば同じページでソースコードを配布しないとだめだし、CDで配るのなら、同じCDの同じディレクトリに同梱しないといけません。

ちなみに、GPLには、LGPLというライブラリ用の劣化したGPLがあります。
この場合、動的リンクをする場合にはGPL汚染はしなかったと思います。
利用しようとしているライブラリのライセンスを確認して、実際に利用している人に聞いてみるのがよいかと。。

参考URL:http://www.opensource.jp/lesser/lgpl.ja.html

QGPLの派生物の範囲が分かりません

GPL v2 における派生物についてのご意見を頂戴したく思います。

以下のような状況において OS のカーネルは派生物に該当するかどうか
ご意見を頂ければ嬉しく思います。

カーネル(非 GPL)
ドライバ(GPL)

組み込み機器で使用するソフトなので,ソフトウェアの形態としては
最終的には1つの実行ファイルになります。ただ,これは組み込み機器
への搭載に際して不可避なことであり,単に1つの実行ファイルである
からといって,即派生物になるという認識は一般的でないと考えています。

さて,本論に入ります。

GPL カーネルを 非 GPL のドライバがファンクションコールする場合,
当該ドライバがカーネルの一般に公開されている I/F のみを用いるの
であれば,当該ドライバは派生物とは見なされないのが一般的であ
ると認識しています。これはソフトウェア情報センターによる報告
(2004.10)に基づいています。

本件は,これを逆に解釈し,非 GPL カーネルが GPL ドライバの
一般に公開されている I/F のみを使用する場合も,カーネルが
派生物と見なされないという余地があるかについての質問です。

通常は linux のカーネル(GPL)が例に多く出されるので,本件の
ような事例は調査しところ見つけることができませんでした。
ご意見お待ちしております。

GPL v2 における派生物についてのご意見を頂戴したく思います。

以下のような状況において OS のカーネルは派生物に該当するかどうか
ご意見を頂ければ嬉しく思います。

カーネル(非 GPL)
ドライバ(GPL)

組み込み機器で使用するソフトなので,ソフトウェアの形態としては
最終的には1つの実行ファイルになります。ただ,これは組み込み機器
への搭載に際して不可避なことであり,単に1つの実行ファイルである
からといって,即派生物になるという認識は一般的でないと考えています。

さて...続きを読む

Aベストアンサー

今回のご質問の場合、FAQの次の項目が当てはまるのではないでしょうか?

http://www.gnu.org/licenses/gpl-faq.ja.html#GPLPluginsInNF
フリーではないプログラム向けのプラグインにGPLを適用することはできますか?
もしプログラムがforkやexecでプラグインを呼び出すならば、プラグインは別のプログラムですから、メインプログラムのライセンスは何の条件も課しません。ですからあなたはプラグインにGPLを適用できますし、特別な要件はありません。

プログラムがプラグインと動的にリンクされ、お互いにファンクションコールを使ってデータ構造を共有している場合、それらは単一のプログラムを形成していると見なされますので、プラグインはメインプログラムの拡張部分として扱われなければなりません。このことは、GPLで保護されたプラグインをメインプログラムとリンクするのはGPL違反となることを意味しています。しかし、あなたはこの法的問題を、あなたのプログラムのライセンスにフリーではないメインプログラムとのリンクを許可する例外を加えることで解決できます。

より詳しくは、「フリーではないライブラリを利用するフリーソフトウェアを書いています」という項目で始まる既出の質問をご覧ください。

---
ドライバとカーネルも、fork&exec かそれに類する手段で呼ばれる
関係ではないですから、ドライバとカーネルは単一のプログラムを形成する考えられ、
したがって全体がGPLによる縛りを受けるものと判断すべきだと思います。

最終的には(裁判所で)法的に判断してもらうしかないですし、
GPLの縛りを嫌うのであれば、徹底的に避けるべきだと思います。

今回のご質問の場合、FAQの次の項目が当てはまるのではないでしょうか?

http://www.gnu.org/licenses/gpl-faq.ja.html#GPLPluginsInNF
フリーではないプログラム向けのプラグインにGPLを適用することはできますか?
もしプログラムがforkやexecでプラグインを呼び出すならば、プラグインは別のプログラムですから、メインプログラムのライセンスは何の条件も課しません。ですからあなたはプラグインにGPLを適用できますし、特別な要件はありません。

プログラムがプラグインと動的にリンクされ、お...続きを読む

Q英文Eメールで「私は田中です」と名乗る場合。

いつもお世話になっております。
英文で、先日問い合わせた田中です。と書きたいのですが、This is Tanaka, I asked you the other day.
と、電話のようにThis is~でよいのでしょうか?
アドバイスお願いいたします。

Aベストアンサー

こんにちは。6/14のご質問ではご丁寧なお返事を有難うございました。

1.初対面の自己紹介ではないので、My name is~、I'm~といった表現にする必要はありません。

2.一度コンタクトをとった相手ですので、「こちら~です」といった、ご質問文にあるThis isで問題ありません。

3.「先日問い合わせた」という修飾部分は、関係代名詞を使うより、2文に分けた方が相手に伝わり易いでしょう。

4.また、私(主体)にポイントを置くより、相手(客体)にポイントを合わせた表現の方が、相手もピンときて思い出しやすくなります。

つまり、「私が問い合わせをした」ではなく、「あなたが問い合わせを受けた」と、主語を転換させるのです。

4.以上を踏まえて訳例は、

Hello, this is Tanaka.
I hope you received my e-mail a few days ago.
「こんにちは。田中と申します。
数日前私の問い合わせを受けられたと思いますが。」
となります。

以上ご参考までに。

こんにちは。6/14のご質問ではご丁寧なお返事を有難うございました。

1.初対面の自己紹介ではないので、My name is~、I'm~といった表現にする必要はありません。

2.一度コンタクトをとった相手ですので、「こちら~です」といった、ご質問文にあるThis isで問題ありません。

3.「先日問い合わせた」という修飾部分は、関係代名詞を使うより、2文に分けた方が相手に伝わり易いでしょう。

4.また、私(主体)にポイントを置くより、相手(客体)にポイントを合わせた表現の方が、相手もピン...続きを読む

Qx86とARMの性能の違い

x86とARMの性能の違いについて教えていただきたいです。
それぞれの設計に基いたご説明をいただけるとなおありがたいです。
また、性能の違いの結果として、
それぞれどのような場面でよく使われるのかも知りたいです。

よろしくお願いいたします。

Aベストアンサー

まず違いを知るなら以下を読むべきかと、有志が書いているとはいえ、日本サイトのただの年表とは段違いに情報があるはずです。
http://en.wikipedia.org/wiki/ARM_architecture
http://en.wikipedia.org/wiki/X86

といって、読める人なら、質問しないのでしょうけど。
概略的に説明すると、ARMは reduced instruction set computing(RISC)プロセッサです。 それに対して、x86はベーシックに言えば、complex instruction set computer(CISC)プロセッサとなります。まあ、世間では既に差はあまりないのですけど、思想としてはCISCとRISCでは演算の基点が違います。

x86と呼ばれるプロセッサは、i8086を始まりとして(86を冠した世代が4世代目まで続いたことから)現在のCore i7プロセッサに至るまでの製品を指します。ただし、64bitモードであるx64(AMD64/Intel64)は、このx86を開発したIntelではなく、AMDが先に実装しています。このx86/64系のプロセッサは、高度で複雑な演算を行うために開発されたプロセッサであり、現在においてHPC用のプロセッサを除けば、世界最速を誇るプロセッサとなります。尚、x86/64系は処理速度を高めるために、スカラユニットの採用と分岐予測、パイプラインによる高速動作などを実現しているため、消費電力が大きなパーソナルコンピュータ、ワークステーション、サーバー分野においてこれまでは使われてきました。価格的にも高性能故にそこそこの値段であり、インテルとAMD以外のメーカーでは、VIAなど一部が進出するのみで、Intelの市場での強さもあり、他のメーカーが力をもつことはありませんでした。


ARMは、元々組み込み向けとしての素質を持つプロセッサで、コンパクトで指向性の高い命令を、速やかに処理することに長けたプロセッサとして登場しています。要は、何でも処理するというよりは、命令の方向性をある程度定め、その範囲内で処理をこなすことがARMの特徴となっていました。その代わり、消費電力はミリワット単位から数ワットまでと劇的に小さな電力/パッケージングに収まるものが主流でした。しかも、それ故に製造単価や開発単価も安く、そもそもARM.LTDは製品のライセンスビジネスで利益を出しており、インテルのように開発製造販売などを一手に手がける垂直型ではないことから、多くのメーカーが使ってきたのです。


本来この2つの製品が能力的に接近することはないと思われるほど性能差がありました。しかし、携帯電話の普及によって、ARMプロセッサは急速に進化を遂げ、スマートフォン時代に、市場規模ではインテルとAMDが開発してきたx86/64系のプロセッサに匹敵するか、それを超える市場規模になる可能性が出てきたのです。(金額ベースでは、インテルプロセッサにはまだ及びません)

ARMが急速に性能を伸ばすことになったのは、スマートフォンが登場したことが大きな理由です。当初は搭載していなかったSIMDの実装や、高機能レジスタの搭載によって、たった5年ほどで多くのラインナップが登場し、多くのメーカーがARM.Ltdとライセンス契約し新しい技術の搭載を進めたのです。
結果的に、現在ようやくインテル社が持つx86に迫る程度に性能が向上しました。ただ、性能面で上回るほどになるかというと・・・。今の段階ではまだ難しいでしょう。


尚、性能の違いの結果という点は今の段階では、高性能なx86、安価で省電力なARMです。
ただ、今後もそうである保障はありません。

単価やブランドイメージの違い、販売における製造ラインの確保の問題などもありますからね。
ただ、ARMの場合は、ライセンスさえ取得すれば、製造はある程度できますから、需要があれば数は伸びる傾向があります。ただ、単価が安いため、数が大量に出ているから、売上げが凄いわけではないのです。そのかわり、一定以上の販売が伸びれば、ソフト開発も活況を呈するため、ハードの性能も総じて向上します。
そうすると、性能が上がることで単価があがるというラインに今さしかかっています。

それに対して、x86/64は元々ブランドとして一定の地位を持っている高性能汎用プロセッサです。アプリケーション資産は既にPC市場において過半数を占めており、現在はゲーム機市場でもWiiUを除けば、PS4とX-BOX Oneに採用されています。1つのプロセッサあたりの単価もそこそこ高くなります。
高性能故にダイサイズもARMとは比べものにならないほど大きなものが主流です。最近になって、そこから性能を抑えて、ARMに対抗できる製品や、ARMより少し大きくとも消費電力が低く、性能は高い製品を出すようになりました。

尚、x86とARMでは、処理方法に違いがあり、実行できるマイクロコードの記述方法にも差異があります。そのため、x86の性能が高いからといって、ARMから簡単に移植したり、その逆にARMが普及しているからといってx86の資産を簡単に移せるわけではありません。まあ、アプリケーションはOSさえ対応し、アプリケーションの開発環境に準じた実行APIを備えてくれれば良いですけど、それを支えるAPIやOSは、ハードに最適化したプログラミングをしないと、そのハードが備えるピーク性能を発揮することはできません。

といったところでしょうか?

最後に、プロセッサには他にもMIPS(MIPS)、SPARC(SPARC/旧Sun Microsystems)、Power(IBM)、SX(NEC)、IA-64(Intel/HP)などなどのアーキテクチャが存在します。性能の違いだけで見るなら、これらの製品の方が、競争する市場が似ているものもありおもしろい製品が多いですけど。MIPSなどは、最近は少し弱いですが、MIPS-III世代では、ソニーのプレイステーション2のCPUであるEmotion EngineがこのMIPSアーキテクチャでした。SPARCはスーパーコンピューター京、Power系は、そのクライアント版(PowerPC)が、Intel Macになる前にMacintoshに使われていました。
SXは、地球シミュレーターです。IA-64は・・・。不運なプロセッサ。

設計で考えるなら、プロセッサ全体を見渡すのも大事です。そして何より、重要なのは開発されるOSやアプリケーションがどういうものかを見るのが妥当です。特にそれを如実に示すのは、SXとその他のプロセッサの違いでしょう。

まず違いを知るなら以下を読むべきかと、有志が書いているとはいえ、日本サイトのただの年表とは段違いに情報があるはずです。
http://en.wikipedia.org/wiki/ARM_architecture
http://en.wikipedia.org/wiki/X86

といって、読める人なら、質問しないのでしょうけど。
概略的に説明すると、ARMは reduced instruction set computing(RISC)プロセッサです。 それに対して、x86はベーシックに言えば、complex instruction set computer(CISC)プロセッサとなります。まあ、世間では既に差はあまりないのですけど、...続きを読む

QSD書き換え回数制限について

SD書き換え回数制限について
書き換え回数 10万回と記載の仕様は
存在するデータを消さずに ひたすら単純にOPEN→ WRITE→ CLOSEで
10万回書き込みだけを実施した場合でも制限になるのでしょうか。

フラッフメモリなので書き込み寿命があると記載されています。
ROMにデータを書く時のように、ハード的に 消して書く事に制限があるとの認識もあるのですが、
ファイル管理をする見えないエリアで問題になるのでしょうか。
詳しい方 ご教示頂けると助かります。

よろしくお願いいたします。

Aベストアンサー

SDメモリカードの書き換え回数についてですよね。
http://ja.wikipedia.org/wiki/SD%E3%83%A1%E3%83%A2%E3%83%AA%E3%83%BC%E3%82%AB%E3%83%BC%E3%83%89

恐らく、約10万回の書き換え回数というのは、SLC(Single Level Cell )タイプのフラッシュメモリを使ったSDメモリカードの場合だと思います。SLCタイプのSDメモリカードは現在少なく、現在は殆どがMLC(Multiple Level Cell)タイプだと思います。

MLCは、約1万回の書き換え回数です。他に、TLC(Triple Level Cell)タイプのフラッシュメモリもあり、約3000回の書き換え回数です。SDメモリカードにもTLCタイプがあるようです。安価で小型・大容量には向いています。

フラッシュメモリの特性を見てもらえば判りますが、同一セルを書き換えを寿命回数まで行うと、セル自体が劣化してやがて電子を保持できなくなり、データの保持ができなくなります。書き換え寿命は、ぴったりしたものではなく、大雑把な値でができなくなってわかる場合が多いです。
http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%83%A1%E3%83%A2%E3%83%AA

SSDと同じようにSDメモリカードでもウェアレベリングが行われています。恐らく小容量の時代(MBの頃)にはなかったでしょうが、現在のようにGBがあたり前の現在では、書き換え回数を抑えるために空き領域を交互に使って書いて行きます。

自分の記憶では、SDメモリカードやUSBフラッシュメモリなどは、容量一杯まで書いて削除する方法で使っていました。こうやって、なるべく書き換えを行わないようにしていましたね。全削除してから、また書き込みを始めていました。今は、気にせず書き換えを行っています。

という訳で、現在はSDメモリカードではあまり気にする必要はないでしょう。SSDのようにOSレベルで使う場合は、書き換え回数が遥かに多いので問題になりますが、時折書き換える程度の使い方をするSDメモリカードの場合は、気にすることもないでしょう。
http://freesoft.tvbok.com/tips/pc_windows/usb_sd_memory_life.html

書き換えの回数計算が載っています。参考にして下さい。これにあるように、定期的に書き換えを行う場合は、計算が必要ですね。
http://q.hatena.ne.jp/1302950619

SDメモリカードの書き換え回数についてですよね。
http://ja.wikipedia.org/wiki/SD%E3%83%A1%E3%83%A2%E3%83%AA%E3%83%BC%E3%82%AB%E3%83%BC%E3%83%89

恐らく、約10万回の書き換え回数というのは、SLC(Single Level Cell )タイプのフラッシュメモリを使ったSDメモリカードの場合だと思います。SLCタイプのSDメモリカードは現在少なく、現在は殆どがMLC(Multiple Level Cell)タイプだと思います。

MLCは、約1万回の書き換え回数です。他に、TLC(Triple Level Cell)タイプのフラッシュメモリもあり、約3000...続きを読む


人気Q&Aランキング