著者アーカイブ takahashi

takahashi 著者:takahashi

Ubuntu 16.04 LTS にPHP16.04をインストールする方法

高橋です。

僕は自宅でサーバーを動かしているのですが、OSにUbuntu12.04を使用しています。
このUbuntu12.04はLTS版のため、リリースから5年間サポートされるのですが、今年の4月でちょうど5年となり、サポート期限切れとなります。
https://www.ubuntulinux.jp/ubuntu

UbuntuにはOSアップグレード機能があるので、Ubuntu14.04を経由すれば16.04にすることは可能といえば可能なのですが、システムにかかわる部分のパッケージがごっそりアップグレードされる上に、それを2バージョン分連続で行わないといけないので正直正常に動作するかはかなり不安…
また、現行で動いてるシステムも、自鯖入門してすぐに、勉強しながら作った環境なので、使い勝手もイマイチな感じでした。
そこで、今回は思い切ってサーバー環境を、Ubuntu16.04上で綺麗に再構築してやろうということで進めています。

さて、LTS版2バージョンも離れていると、Ubuntuもかなり仕様が変化しています。
その変化の一つとして、Ubuntu16.04では公式で提供されるPHPモジュールのバージョンがPHP7になっています。
PHP7はPHP5.Xに比べて、セキュリティの強化や高速化など、多くの改良がされているとのこと。

しかし、PHP5系でしか動作しないシステムもまだまだあるかと思います。
Ubuntu 16.04LTS以降ではそのままではPHP5系のパッケージは入れられませんが、下記の方法を行うとインストールできるようになります。

php5のパッケージが無くなっていて、Ubuntu 16.04 にPHPをインストールできない -Stack Overflow

以下のコマンドを一行ずつ入れていきます。

php5.6をインストールすると、依存関係で以下のパッケージも同時にインストールされるようです。

libapache2-mod-php5.6も一緒にインストールされるので、Apacheを使っている場合は別途モジュールを用意する必要はありません。

これでUbuntu16.04にPHP5.6を入れることができました!

できればPHP7メインで使っていきたいところではありますが、まだまだ未対応で動作しないプログラムが多いのも事実。
そんなこんなでUbuntu16.04でPHP5.6が必要な方は是非お試しください。

——————————————————————————————
参考元:
php5のパッケージが無くなっていて、Ubuntu 16.04 にPHPをインストールできない -Stack Overflow

PHPフレームワークのPHP7対応状況 – Qiita

Topic: pandora fms with php 7.0 (Read 524 times) – PandoraFMS

Repository – なんなんなん行く?

※この記事は以前自分が書いたものを一部修正して投稿しています。
takahashi 著者:takahashi

Java系 IDE用の日本語化ライブラリ “Pleiades” でAndroidStudioを日本語化

高橋です。
皆さんはPleiadesをご存知でしょうか?

Pleiadesとは、”Eclipse” “Intellij IDEA(Android Studio)” などのJava製IDEのUIを日本語にしてくれる、日本語化プラグインです。
特にEclipseは毎バージョンごとに組み込み済みのバージョンがPleiadesの公式サイトから配信されています。

ただ、今までは、Eclipseの日本語化がメインな印象で、ほかのツールにも翻訳をあてることはできていたものの不完全でした。

ところが、先日久々に公式サイトを確認したら、Pleiades自体のバージョンがかなり進んでいまして、

なんとAndroidアプリの開発に必須のツール、”Android Studio”の完全日本語化に対応していました!
従来のPleiadesでも日本語化はできたのですが、一部のみ翻訳されるだけでほとんど英語のままでした。

Android Studioはちょっと難解な部分もあるので非常にありがたいですねw

早速適用してみました!

まず、サイトからPleiadesの最新版を入手します。

Zipファイルが入手できるので、解凍すると中に”setup.exe”というファイルがあるので実行します。

下のような画面が表示されます。

“選択”をクリックします。

ファイル選択画面が開くので、Android Studioのexeファイルを選択します。

情報が出てきたのを確認して “日本語化する”をクリックします。
これで日本語化は完了です。
実際に表示を確認してみます。

ダイアログからメインの画面、プルダウンメニューに至るまでバッチリ日本語化されていました。

Android開発入門したいけど、英語のUIが原因でなかなか手が出せなかった…という方は是非試してみてはいかがでしょうか…?

 


※この記事は以前自分が書いたものを一部修正して投稿しています。
takahashi 著者:takahashi

ハッカー力(りょく)を試すならここ! Hackmeでセキュリティを学ぶ

高橋です。

Webプログラミングをしていて必ず付いてまわってくるのがセキュリティ対策。
Webはプログラムが動作する環境そのものを外部に直接公開することになるので、脆弱性については特に気を付けないといけません。

しかし実際にどういうことに気を付ければいいのか…なかなか理解するのは難しいと思います。

そこで、一番手っ取り早い方法をお教えします。
自分自身が攻撃者としてサイトをアタックしてみればいいのです。

勿論、本当に誰かのサイトをハックするのは犯罪になってしまうので言うまでもなくダメです。
ただ、自分で(外部に影響のないような)練習用の仮環境を用意して、実際に攻撃者が行う手口を体験してみるのは大丈夫です。
むしろ、実際にどのように攻撃が行われているのかを知ることで、守る側に立った時も、どうすれば防御できるのか作戦を立てることができるようになります。習うより慣れろ、というわけですね。

ただ、自分でその練習用の環境を作るとなると、サーバーを用意して、サイトを用意して…となると結構大変です。

実は、そんなセキュリティを学びたい方のために、こんなサイトがあります。

Hackme“というサイトです。

このサイトでは、実際によく使われるハッキングの手口をつかってサイトの認証の突破にチャレンジすることができます。
ちょっとおバカなミスをついたものから、SQLインジェクションを用いた技術的なものなど、Webプログラムをしていて犯しがちな脆弱性を実際に突きながら、Webプログラムをする際にどういったことに気を付ければいいのか勉強することができる非常に面白いサイトです。

興味のある方は是非挑戦してみてはいかがでしょうか。

ちなみに、一口にハッカーとは言っても、必ずしも悪意のある人を指すわけではありません。
もともとハッカーという言葉は、”コンピューターに詳しい人”を指し、攻撃者だけを指す言葉ではありませんでした。

ハッカー – Wikipedia

そういった事情から、不正アクセスを行う人々を”ハッカー”と十把一絡げに読んてしまうと、あまりいい顔をしない人もいるようです。

この場合、悪意をもった攻撃を行う人のことを”クラッカー”と呼び、明確に区別することがあります。
最近では”ブラックハッカー”という呼び方もよく見かけます。

これに対し、”ホワイトハッカー”という人々もいます。
この人たちは、”ブラックハッカー”が行ってくる高度なクラッキング行為を防御する技術をもった人のことを呼びます。
所謂、セキュリティ技術者のことです。

コンピューターセキュリティの救世主 「ホワイトハッカー」の素顔に迫る – 日々タス

ホワイトハッカーを目指して勉強してみるのも面白いかもしれませんね。

takahashi 著者:takahashi

【これはスゴイ】MSがARM版Windows10を発表。win32アプリケーションも動くぞ!

今朝ふとSNSを見ていたら、何気なく凄いニュースが出ていました。

明らかになってきたArm版Windows 10の課題とそのメリット – PC Watch

以前から登場が噂されていたARM版Windows10が、Snapdragonの大手開発元の一つであるQualcommのイベントで発表されたとのこと。これだけ聞くと、ユーザーが増えず、失敗に終わったといわれるARM専用の “WindowsRT” の二の舞感がありますが、今回は一味違うようです。


Windows RTは機能制限版で、x86命令のWin32のデスクトップアプリケーションは使うことができず、利用できるのはWindows Store経由で提供されるストアアプリケーション(現在UWPと呼ばれているアプリケーションの前身)のみだった。しかし、Arm版Windows 10では、前述のとおり、x86命令(32bit)をArm v8命令(64bit)に変換して実行できるため、32bitのデスクトップアプリケーションをそのままで実行できる。

また、OSのSKUも、今回の2製品にプリインストールされていたのはWindows 10 Sだったが、Windows 10 Home、Windows 10 Proも用意されており、ユーザーはMicrosoft StoreでWindows 10 Proへのアップグレード権を購入して、OSをWindows 10 Proにアップグレードして利用することができ、その場合は任意のWin32のデスクトップアプリケーション(たとえばAdobeのCreative Cloudなど)を実行できるようになる。


なんと、ARMのCPU上でもintel向けにビルドされた従来のWindowsアプリケーション(win32アプリケーション)が動作できるらしい!!
今までデスクトップ向けでARM上で動作するOS自体は出ていました。

特に、カーネルや周辺パッケージのソースが公開されているLinux系OSでは、ARM系のCPUが出始めたころから対応しているディストリビュージョンも複数出ていました。
ところが、Linuxではアーキテクチャ間の互換機能はなく、ARMでアプリを動作させるにはARM向けにビルドする必要がありました。(実はLinuxの場合、同じintel系向けでも、32bit用、64bit用それぞれ向けにビルドされたものでないと動作しない場合がほとんどです。)

Windowsでは今までにも64bitのintel系CPUでも32bitアプリが動作するような仕組みを導入していたり、最近では、LinuxそのものをWindows上で動かしてLinuxアプリを実行させる環境を提供するwindows subsystem for linuxなど、他のシステム向けのものをWindows上で簡単に動作できるようにいろいろ工夫してきていました。

まさかそれが完全にアーキテクチャの壁も超えて行われるとは想像してもいなかったですが、これならARMでも安心して使えるようになるかもしれませんね。
なお、動作できるのはintel 32bitCPU向けにビルドされたアプリのみで、64bit向けのアプリは残念ながら非対応とのことです。

同ニュースによると、動作した感じは

OEMメーカーの関係者によれば、OEMメーカーで一般的に言われているのは、Cherry Trailよりは速いが、Coreプロセッサよりは遅い、そのあたりの性能だと認識されている点。実際筆者もさわって、Officeの起動などを行なってみたが、Cherry Trailよりは速いかなという印象だった。実際、手持ちの第7世代Core i7と比べてみたが、Officeの起動は俄然Coreプロセッサのほうが速かった。

とのこと。
重い処理は依然としてx86系CPUの方が優れていますが、モバイルPCとしてなら非常に優れたガジェットになるかもしれませんね。

ARM版Windows10の発売が楽しみです。

※ Windows は米国 Microsoft Corporation の米国およびその他の国における登録商標です。
takahashi 著者:takahashi

mac OSのchromeで、アプリモードでWebサイトを開く方法

高橋です。

僕は普段からブラウザにGoogleChromeを利用しています。
GoogleChromeはWindowsでもMacでも動作するので、どちらのOSを使うときもChromeをメインで使っているのですが、PCではWebアプリを使う機会が多いので、Chromeのアプリモードを愛用していました。

ところが…

Windows版にはあるこのメニューが

Mac版だとありません…
Chromeのアプリ一覧画面にもショートカットを作成するメニューが無いので、Mac版がてっきり非対応なのだと思っていたのですが、最近いろいろ調べていたらたまたま情報を発見しました。

Google Chrome のアプリモードでウェブページを開く – mattintosh note

例えばターミナルで

open -n -a 'Google Chrome' --args '--app=http://example.com'

のようにすればアプリモードで起動できました。

ただ、ショートカットの作成は行ってくれないので

MacのGoogleChromeをDockから起動オプション付きで開く方法- karakaram-blog

上記サイトで掲載されているAutomaterを使用すればapp化もできます。

MacでWebアプリを愛用している皆さん、ぜひお試しあれ!

takahashi 著者:takahashi

モバイル版Chrome/SafariでWebページをWebアプリケーション表示させる方法

高橋です。

モバイル版のChromeやSafariには、特定のページのショートカットを作る機能がついています。

使ったことがある方もいらっしゃるのではないでしょうか?
僕もキャリアが提供するWebメールなどで、画面をすぐに開けるようにするためによく使っています。

さて、このショートカットを作る機能ですが、サイトによって動作が異なることはご存知でしょうか?
例えば、ショートカット化したAmazonのショッピング画面を開くと、

こんな感じで通常のブラウザ画面で表示されます。
一方、Softbank のS!メールどこでもアクセス をショートカット化すると…

開いたときにスプラッシュ画面が!

ブラウザのアドレスバーの表示も消え、まるでアプリのような見た目になりました。

この表示の違いは、対象のページのheadタグに次のようなmetaタグが入っていると起こります。

<head>
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="apple-mobile-web-app-title" content="サイト名">
</head>

この2行を入れておくと、モバイル版のSafari、Chromeで作成したショートカットから起動すると、URLバーが消え、アプリのような表示になるというわけです。
もし、スマホ・タブレット向けに作っているページがあり、Webアプリとして使ってほしい、URLバーを消した状態で使ってほしい、というときに便利です。

一方で、ブラウザ側でこの切替を行う設定は今のところないようなので、ユーザー側ではコントロールを行うことができません。
この点は注意が必要そうです。

モバイル用のWebアプリを作成している方は、一度試してみてはいかがでしょうか。

takahashi 著者:takahashi

オープンソースでも有料ソフト並み 現像ソフト”RAW Thrapee”

高橋です。

皆さんは写真編集をされる際、普段どんなツールをお使いでしょうか?
以前まで、僕はWindows10に付属の”フォト”アプリを使って編集していました。


写真について知識がなくても簡単に触ることができますし、標準でありながら非常に使いやすい完成度の高いアプリとなっていて、ずっと愛用していました。
ところが、最近になって写真を大量に編集する機会が出てきまして、写真を一枚一枚開いて編集するのが大変な場面が徐々に出てきました。

そんななか、知人から無料でありながら超高性能な写真編集ツールを教えてもらいました。

RAWTherapeeです。
RAWTherapeeはオープンソースで開発が進められている現像、つまり写真編集に特化したソフトウェアです。

Windows標準の写真調整ツールとの大きな違いは、写真編集機能に加えて、ファイル管理機能が搭載されていること。
編集済み/未編集の管理や削除、保存の操作をすべてソフト上から一括で行うことができます。勿論、単体での保存も可能です。

左上にヒストグラムも搭載されています。

他にも、明るさや露出の調整や、色の濃さの調整など、Windows フォトアプリよりもさらに細かい調整が可能です。
比較として、有料の現像ソフト”Adobe Lightroom”とよく比較されますが、基本的にはほぼ同等の機能を持つといわれているようです。

僕みたいな初心者でも直感的に触れますし、機能的にも充実しているので、非常に優秀なアプリだと思います。

写真編集にお悩みの皆さん、是非一度試してみてはいかがでしょうか?

——————————————
RAW Therapee Blog(公式サイト)
http://rawtherapee.com/

フリーのRAW現像ソフト RawTherapee(RAWセラピー) – ぼくんちのTV別館
https://freesoft.tvbok.com/freesoft/image/rawtherapee.html

takahashi 著者:takahashi

【現在は解決済】mac OS High Sierraに深刻な脆弱性が発覚 root権限への昇格がだれても可能に

高橋です。
先週、macOS High Sierraのバージョン10.13.1で、とんでもない脆弱性が発覚しました。

今回問題になったのは、macでアプリのインストールや設定変更の際にパスワードを求めるこの画面。
管理者権限へ昇格する際の認証の画面なのですが、ここでidをrootとし、パスワードを何も入力せずに”ログイン”を連打するとログインできてしまうという状態だったとのこと。

macOSはUNIX系のOSなので、rootでかんたんに不正ログインできてしまうというのはかなりまずい事態です。
幸いなことにログインできてしまうのはこの認証画面に限られるので、外部からrootアカウントで直接侵入される…という心配はなかったようですが、セキュリティに厳しいイメージのあるAppleの製品からこの不具合が出たことに、かなり驚いた方も多かったのではないでしょうか。

不具合発覚後、Appleは緊急でセキュリティアップデートを発行し、合わせて謝罪のコメントを出しています。

現在は自動アップデート機能により何もしなくても適用されている状態とのことですが、アップデート配信後にmacOSを10.13.1へアップグレードした方はセキュリティアップデートが適用されていない可能性があるので、アップグレード後に再起動を行ってほしいとのことです。

Apple公式サイトによると、アップデートが適用されているかどうかは下記の方法で確認できるとのことです。


お使いの Mac にセキュリティアップデート 2017-001 が適用されているか確認するには、以下の手順を実行してください。
1.ターミナル App を開きます (「アプリケーション」フォルダの「ユーティリティ」フォルダにあります)。
2.「what /usr/libexec/opendirectoryd」と入力して「return」キーを押します。
3.セキュリティアップデート 2017-001 が正常にインストールされている場合は、以下のいずれかのプロジェクトバージョン番号が表示されます。
opendirectoryd-483.1.5 on macOS High Sierra 10.13
opendirectoryd-483.20.7 on macOS High Sierra 10.13.1
Mac でルートユーザアカウントが必要な場合は、このアップデートを適用した後で、ルートユーザを有効にし直して、ルートユーザのパスワードを変更する必要があります。


参考サイト:
http://www.itmedia.co.jp/enterprise/articles/1711/30/news065.html
http://jp.techcrunch.com/2017/11/30/2017-11-29-apple-releases-a-macos-security-update-to-fix-huge-login-security-flaw/
https://support.apple.com/ja-jp/HT208315
takahashi 著者:takahashi

nginxでSSL設定をするときに気を付けたいこと

高橋です。

以前家で趣味でnginxを使ってサーバーを建てたときの話。
Nginxを後ろに控えているWebサーバー(Apache)のリバースプロキシとして構築していました。

構成としてはサブドメインを割り当てたバーチャルホストが複数稼働している環境だったため、nginx側もバーチャルホストに対応すべく下のような設定にしていました。

 #省略...
 server {
  server_name  .example.com;

  listen          80;
  listen          443 ssl;

  ssl on;
  ssl_certificate      /ssl/to/path/example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
   server {
  server_name  .a.example.com;

  listen          80;
  listen          443 ssl;

  ssl on;
  ssl_certificate      /ssl/to/path/a.example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/a.example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
#省略...&lt;span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"&gt;&lt;/span&gt;

すると..

Bad Requestのエラーが発生。
いろいろ試してもエラーが解消されず頭を抱えていたのですが、調べていたら以下のサイトを発見。

nginx連載6回目: nginxの設定、その4 – TLS/SSLの設定 – インフラエンジニア way
https://heartbeats.jp/hbblog/2012/06/nginx06.html

>sslディレクティブをonに設定すると、SSLが有効になります。ただし、listenディレクティブでsslパラメータを指定したときには不要です。

>ssl on;

>listenディレクティブにsslパラメータを付けると、そのポートでSSLを有効にして待ち受けるようになります。そのポートに関して後述するsslディレクティブをonにしたのと同じ動作になるため、sslディレクティブの記述は不要になります。

>listen 443 ssl;

なるほど、
ssl on;
の記述をしてしまうと
server{}
内で定義されている全ポートにsslが有効になるので、80番ポートでアクセスしてもssl通信と解釈されてしまい、エラーが出ていたようです。
443ポートだけsslにしたい場合は

listen 443 ssl;

とだけ指定しておけば443ポートだけsslを有効にできるようです。
てっきり

“ssl on;”

を入れないとsslが有効にならないものと勘違いしていました(汗

さっきの設定を修正すると以下のようになりました。

 #省略...
 server {
  server_name  .example.com;

  listen          80;
  listen          443 ssl; #これは残しておく

  #ssl on; コメントアウト
  ssl_certificate      /ssl/to/path/example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
   server {
  server_name  .a.example.com;

  listen          80;
  listen          443 ssl; #これは残しておく

  #ssl on; #コメントアウト
  ssl_certificate      /ssl/to/path/a.example.com/fullchain.pem;
  ssl_certificate_key /ssl/to/path/a.example.com/privkey.pem;

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名。クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://xxx.xxx.xxx.xxx;
  }

}
#省略...

これでnginxを再起動したところ、無事80番ポートの平文通信と443ポートのSSL通信両方ともできるようになりました。

Nginxは非常に細かい設定ができるのが人気の理由の一つですが、その分設定の仕方を理解しておかないとハマってしまうことも…

もっと勉強が必要だなぁ、と感じた瞬間でした…

takahashi 著者:takahashi

【使わないと3か月でデータが消える!?】SSDの意外な弱点

高橋です。


引用元:Gigazine

最近安価になりつつあることで普及し始めたSSDですが、以前からHDDと比較して様々な弱点があるといわれていました。
その中でも、一時期特に話題になっていたのが書き換え可能回数の問題。
フラッシュメモリが出てきたときにもよく言われていましたが、NAND型メモリには一定の回数書き換えを行ってしまうと、データが記憶できなくなるという特性があります。
メーカーやものによって耐久度は違ってきますが、同じNAND型メモリを使うSSDもまた、例に漏れずこの制限が存在しています。
ただ最近は、この寿命を伸ばす技術が発達してきていて実用上で心配をしなくても大丈夫になってきたようです。

SSDにデータを書込みまくり再起不能に追い込む耐久試験で分かった信頼性に関する真実とは? – Gigazine
> 余力を十分残しつつもエラー発生の可能性を検知すると、ストップをかけて最も早く脱落したIntel 335でさえ、毎日10GBのデータ書き換えを行っても7万日つまり約190年もつという計算になるため、SSDの書き換え寿命を心配する必要はほとんどないことは確実です。

これでSSDの弱点は目立つところは”HDDと比べて高い”という部分だけになったと考えていたのですが、先日ある事実を知りました。

先にも書いたように、SSDにはNAND型メモリがよく使われているのですが、この前ふと気になってNAND型メモリについてWikipediaで調べていたら、気になる記述を発見しました。

NAND型フラッシュメモリ – Wikipedia
>浮遊ゲート内の電子は、浮遊ゲートを覆う絶縁体により保持されるため、電源を供給することなくデータを数年間程度保持することができる。

お分かりいただけただろうか…

それってつまり、逆に言ってしまうと、”非通電状態では数年間しかデータを保持できない可能性がある。”
ということではないのか…?

気になったのでさらにいろいろ調べてみました。
すると、下記のような説明をしているサイトを発見。

SSDの基礎知識でパソコン購入をガイド – パソ兄さん
> トンネル酸化膜の絶縁によって電子の放出を防いでいますが、長期間書き換え作業が行われないと自然放電が起き、データ化けの原因になります。

と説明されていました。
SSDは電子を放出させないようにすることでデータを保持していますが、長期間通電を行わないとこの電子が放出されてしまい、データが消失してしまうようです。

どれぐらいの期間放置するとデータが消失してしまうのかは議論が分かれるところですが、最小(最も保管条件が悪かった場合など)で”3か月”しかデータが保持できない可能性もあるという話があります。
『中古SSD 無通電時間が長いとデータが消えますか?』 – 価格.com

僕はSSDにこのような特性があったことを恥ずかしながら今回初めて知ったのですが、僕以外にも”SSDは使っていなければ半永久的にデータが保存できる”と、それとなく思っていた方は少なくないのではないかな、と思います。

OSをインストールして使うような使い方であれば、3か月も電源を入れないということは少ないとは思うのですが、データ保存用となるとあり得ない話ではないな…と思いました。
ただ、データ保管用に…と使わないときはSSDを外して保管している方も、中にはいらっしゃるかもしれません。

それ故に、
「大事なデータをバックアップしておいたはずが…なんてこった…」
なんてことになる可能性もゼロではないかもしれませんね。

SSDはあくまで”一時保管用”という意識を頭の片隅に置いておいて、大事なデータは光学ディスクなどのより長持ちするメディアに退避しておくのが一番のようです。
どのメディアにも適材適所があり、用途に合わせて使い分けないといけないんだな、と改めて感じました。

今後SSDを購入予定の方はお気を付けください。

 

※この記事は、以前私が書いたものを一部修正したものです。