2015年のPC業界を個人的に振り返る。

 さて、書いていたらまたしてもあまり面白くない感じになってしまったのが本人をしてイマイチなのだが、取り敢えず今年のPC周りを振り返ってみましょ。

 1◇Windows10の提供開始とゴタゴタ。

 今年のPC業界全体を見ると、落ち目のMicrosoftに振り回されて業界全体が更に弱った、というのが個人的印象。

 トップが変わってから色々頑張っているのは分かるのだが、多少頑張った程度でMS品質がどうにかなるワケもなく。
 しかも何故か当初予定より前倒しで展開した挙句、相変わらずのポンコツ状態で「正式」登場したWindows10。

 ♯もう少し品質を上げておけばもっとスタートダッシュが効いたと思うのだが、ここまで前倒しにした理由が個人的には全く思いつかないんよ。

 そして先日配信されたNovember Update=事実上のSP1でもバグ修正と仕様変更を一気出し、しかも配信できちんとトラブルを起こす、という相変わらずの展開。
 とはいえ漸く「SP1並」の品質になってきたので、EarlyBirdがぼちぼち移行し始めているといったところ、というのが2015年末ってトコですかね。
 次の大型アップデート=Redstoneではまた色々手を入れるという話もあるので、取り敢えずここで一旦、という人も居るのでは。

 とまぁここまでの展開が約半年。
 ユーザもPC業界もそろそろ学習しましたね。Windowsは未来永劫安定することはない、と。
 そしてトップが変わろうがアグレッシブになろうが、やはりMicrosoftは品質とタチが悪いと。

 変化することと安定しないことは違う筈なのだが、Microsoftにこの2つを区別出来るだけの能力があるワケもなく。
 Micfosoftが目指すと公言したモノと、現実とのギャップが激し過ぎて、でも業界としてはそれに付いていくしかない。

 しかも一蓮托生だと思っていたら、自社製ハードウェアのラインナップ拡張で競合範囲を広げてきたし。
 更にTH2の出来云々よりも強引なアップデート誘導という面で個人ユーザとベンダの余計な混乱と反発と顰蹙を現在進行形でかっているし。

 そんな姿勢そのものがPC業界を弱らせているということに、MSは気付いていなのでしょう、きっと。

 ちなみにWindows10 Mobileは・・・あ~そいやそんなのありましたね的な。
 個人的にはこのまま永遠の弱小勢力で終わる確率が非常に高いと思っています。
 OS提供も遅れ、Windows Bridgeも全然進んでいない、その間にもAndroidとiOSは拡大中、もうこの差はは取り返せないだろ、と。

 確かに最近のAndroidは肥大化というか品質低下が目立っているし、その辺りWindows10 Mobileと並べるとという話もあるが、OSとしてのプラットフォームが一度広まってしまったらソレがどれだけ強いかということは、Microsoft自身のWindowsが証明してきたトコなのでね。

 ♯ネタ商品的にはアリだと思う。

 2◇OneDriveを巡るゴタゴタ。

 Microsoftネタ連発だが、これも今年のデカい話として外せないと思うので。

 ミクロで見ればいつものMicrosoftというだけ。「新生」Microsoftは存在しなかった、ということを一番分かり易く知らしめたということで。
 マクロ的視点だと、クラウドサービスってこういうモノだよ、ということを広く再認識させた効能があったかと。
 一般PCユーザの視点で見てみると、Microsoft離れを加速させたとしか。

 個人的な意見だが、古臭いPCユーザといわゆるスマホネイティブユーザの大きな違いの一つに、サービスに対する忠誠度があると思っている。
 これはPC万能時代の「移行の面倒臭さ」の記憶と裏返しであり、一つのアプリなりサービスなりに腰を据えて使い続けるのがPCユーザの習性。良く言えばロイヤリティが高い。
 一方、スマホネイティブユーザはアプリを選んで入れて捨てて御仕舞が当たり前。大多数がコンテンツ消費者なので移行するデータも無く、データ移行作業なんて基本存在しないので、アプリを入れ替えても特に困らない。
 サービス提供側から見た場合、どちらを掴んでおいた方が幸せか、ということですよ。

 そんな時代に、コンテンツ消費者がPCを買ってくれるという幻想はもう通用しない。
 PCが掴んでおくべき顧客はひと昔前「プロシューマ」と呼ばれていたコンテンツ作成側のユーザであり、これは即ち古臭いPCユーザであり、取りも直さずWindowsユーザであり、Microsoft製品ユーザなのですよ。
 そんな彼らに「やっぱMicrosoftは信用ならんわ」と知らしめた今回のイベントは、確実にMSのコンシューマ向け戦略に未来永劫影響を与えると思うんですわ。Windows Mobileの展開も含めてね。

 3◇メインストリーム向けNVMe離陸開始。

 さて、いい加減MSネタばかりだと飽きるので、きちんとハードウェアの話しましょ。

 今年のハードウェア的トピックの中では、個人的にはNVMeがいよいよコンシューマ向けに来たことかと。
 OS側は実はWindows 8.1からフルサポートになっていたが、チップセット側の正式サポートが100シリーズからとなったので、DDR4移行と同時のタイミングで離陸開始と。

 そんなNVMeの価値は、世間で良く言われている「ベンチマーク値がSATAの理論速度超え」ではなく、プロトコル上のオーバーヘッドが少なくSATAよりレイテンシが低いこと。
 今は未だ出始めということでコストも拡張性も全くこなれていないが、現状CPUの足を引っ張りまくっている大容量記録装置周りが漸く一歩前進したワケで。

 個人的には是非早期の値崩れを期待したいところだが、同時にIntelにPCIeバス本数拡大も期待したいところ。
 NVMeだとPCIe x4を使ってしまうので、現行CPUのPCIe x16では拡張性が足りないよね、と。

 4◇HBMが実製品に。

 次に、今年HBM搭載製品が(ハイエンドとはいえ)一般向けに出回り始めたのは、あまり世間では話題になっていないが個人的にはポイントだと思うのですよ。

 着目点ととしてはNVMeと一緒で「高速な演算装置と、追い付いて来ない周辺回路」というPCの中の構図を一歩改善する為に、非常に広帯域なメモリが採用されたということ。
 勿論現時点では価格その他問題も色々あるが、AMDはAPUでもメモリ帯域不足で頭を抱えているということ、GPU ComputingにはPCI-Expressも相対的に低速でボトルネックとなっていること、その他諸々を考えると、まずは将来に向けての一歩を踏み出した、と言えるのでは。

 5◇HDDもSSDも揃って停滞中。

 続けて大容量記憶装置の方を見てみると、今年は正直停滞の年でした、と。

 まずSSDは順調に値下がりし、年初比で3割~4割安くなったが、正直それだけ。
 低価格品ではTLCの採用が拡大。TLC故の書込の遅さはキャッシュで誤魔化すしかなくその取り回し方法で多少個性が出るものの、基本的にはコントローラが一緒なら挙動も一緒という、正に「コモデティ」と化してきたというところ。

 HDDの方を見てみると、コンシューマ向けには年初に8TB品が出回り始め、年内で大体3割程値下がりしたものの、10TB品は未だに影も形も見えず。
 アキバの店頭では地味に4TB・5TBが下がったものの、今年1年ずっと3TBが主役のままで、このラインに至っては値動きもほぼ無し。

 以上、要するに全く面白くなかったですな。

 ちなみに、現時点でPMRの最高密度品は東芝の2.5′ 3TB HDDの750GBプラッタ。
 製品発表は年初、その時は5月出荷予定とアナウンスされ、アキバには9月に流れ始めましたな。これが最高密度。
 3.5’ではHGSTの10TB製品で、コレは1.43TBプラッタという密度。SMRでは去年この密度になっていたのだが、今年にはPMRでこの密度になりました、と。

 あとペーパーではSMRではSamsungが2.5’で1TBプラッタを開発したとPRを出ているが、現物はちっとも出てこないですな。

 6◇IntelがSkylakeでDDR4に移行開始。

 最後にIntelからSkylake登場、DDR4に移行を開始しました、と。
 ある意味定例アップデートで面白くもなんともないし、消費電力は減ってきているものの実処理性能ではあまり伸びてもいない。
 これは取りも直さず「アップデートのメリットが少ない」=「コストばかりかかる」=「コスパが悪い」ということで、こういう商法を続ければどうなるか・・・は自明の筈なんだがなぁ。

 但しプラットフォーム入れ替えというのはパーツ屋にとっては一大イベントで、これがあったからPCパーツ屋は今年が乗り切れたなんて話もあったり無かったり。

 ♯「DDR3が使えるSkylakeマザーが動かない(売れない)」なんて台詞をどっかで聞いたが、当然でしょうよ。

 ◇

 以上、今年のPC市場は自分から見たらこんな感じでした。
 今年のblog更新はこれで終了です。

 それでは皆様、良いお年を。

Share

Win10のKB3124200、病気持ちにつき注意。

 昨日辺りからWindows Updateに乗ってきたKB3124200だが、適用された環境でコントロールパネルを含む一部アプリが起動出来なくなる不具合が発生中。
 このテの症状はレジストリが壊れたりシステム必須ファイルが壊れたりしても発生するのだが、該当KBを明示的にUninstallすると全ての症状が消えることから、このKBが病気持ちなことはほぼ確定。

 対策は該当KBをUninstallすること。繰り返しになるが、それで問題は解決する。

 ◇

 コレでS.KazがWindows10のWindows Update絡みで喰らったトラブルは2回目。 
 1回目はTH2で出たDigiOn製品の不具合で、前回書いた通り。
 2回目がコレ。

 さて・・・3回目は何時来ますかね。

Share

やっちまった。

 TH2が公開されたので取り敢えず公開β程度の完成度にはなったのではないかという期待を持ってしまい、うっかりメインPCをWindows10にアップグレードしてしまいました。
 方法は・・・思いっきり手抜きの「アップグレード」。大体2時間弱ぐらいかかりましたかね。

 とはいっても「TH2で動かなくなった」ソフトもちらほら出ているので、万人にはお勧めしません。
 そういう自分も取り敢えず上げてはみたものの、普段使いのソフトが一つ使えなくなってしまい、さてどうしたものかという真っ最中なので。

 #最悪パーティションイメージから元に戻せる状態にはしてありますよ。

 ・・・つか、こういう互換性に関わる部分の重大な変更を告知無しで強行するなんて、Windows As A Serviceってそういう意味なんかね。
 そんなことするようじゃ、そもそもWindowsなんて・・・っととと、
 閑話休題、このネタは長くなりそうなので別エントリにします。

 #仕様変更でなくバグだよねきっと。まぁそれだって(以下略

 ということで、以下はあくまで参考情報ということで。
 実際にWin7からWin10へアップデートしてみたので、自分が一番ハマった点をメモっておきます。
 といいましてもネタとしては実に古典的な、定番の、使い古されたシロモノですが。

 ◇

 それでは、今回自分が痛い目を見た原因を。

 「カーネルに近い動作をするアプリはかなり危険、基本抜いておけ」
 「ドライバは7と8.1以降対応両対応のものがあれば最新版に、それが無ければ思い切って抜いておけ」

 ほら、よくある話でしょ?
 更に、TH2以降にする(なる)場合には、以下の項目も大事。

 「DigiOn製のDTCP-IPに関連するソフトはTH2でBSODの原因になるので確実に抜いておけ」

 これからIn-place Updateをしようという皆様、本当にコレ重要ですよ。

 当方のように、ランダムに頻発するBSODに脅されながら、一生懸命ドライバのUpdateしたり、疑わしいアプリのUninstallしたりするという、非常に非生産的且つ被虐的な時間を過ごしたくなければ。

 ♯以前ちょっと書いたように、当方メインPCでは結構色々な常駐モノ・組込モノを動かしていてのも原因の一つと思われる。

 特に当方のようにWindows7からの移行だと、Win8からの移行だと恐らく問題無いのだろうがWin7からの移行だとヤバい、という代物が結構ある模様。
 この原因はほぼ100%、ドライバのお作法がWin8から変わっていることなのですよ。
 Win8.1で動くドライバがWin10でコケる確率は高くないが、Win7となるとコケない確率の方が高くない。

 こういうブツが日和見BSOD(というか)の最大の原因なのだが。
 おっかないのは、この日和見BSODを起こす原因の中に、USBやGPU等の必須ドライバも(当然)含まれること。

 ♯前述したDigiOn製DTCP-IP関連ソフトもこの類。
  インストールするとDTCP用ドライバが裏で自動的に動き始めるのだが、こいつがCRITICAL_STRUCTURE_CORRUPTIONを日和見で吐いてくれる。
  ドライバの問題なので上物のアプリを起動しなくともインストールしてあるだけでBSODになるし、大体1時間も持たない。

 だったらそのテのドライバぐらいインストーラが事前に検出して警告してくれれば良いのに、とは思うのだが、そんなことに気を使ってくれないのはMSのいつものことなので。
 実際、当方では検証用環境をWin8.1から10に上げた方では特にBSODなんて発生しなかっのに、本番機のWin7からの(なんの事前準備もしていない)アップデートだとまぁBSODの嵐となったワケですよ。

 しかも、USB3.0等の「そもそもWindows10ではベンダドライバ不要」なんてブツでも、Win7用のドライバが存在すると、何故かこの古いドライバとWindows10用ドライバが衝突して、BSODだけでなくデバイス自体も正常に動かないなんて羽目に。

 なので、こういう困ったドライバ対策として、オススメなのは「一度全部抜いて、MS純正ドライバが当たっている状態にしてしまえ」ということ。
 この状態だと確実にUpdateプロセス中で更新されるので。

 そしてこの「事前準備」は確実にUpdate前に行うこと。
 Update後にはUninstallが正常に出来ないモノが・・・まだコレはまし。
 レジストリやらを直接修正するハメに・・・これでもまだマシ、起動出来ているんだから。

 最悪なのは、そのドライバのせいで自動修復すら起動出来なくなって、要するに「環境が死んで」しまうこと。
 起動時に必須ドライバとして読み込まれるブツにNGドライバが混ざっていると、最悪こういうことになるんですわ。
 ぁぅぁぅ。

 ♯なのでもう、開発系は出来るだけ触らずに一旦大掃除することにしました、はい。

 ◇

 とまぁこんな感じで、取り敢えず上げた時の雑感ということで。

 ・QuickLaunchは以前と同じ方法で復活可能。個人的にはコレ超重要。

 ・CtrlとCaps他、キーレイアウトのレジストリでの入替もそのまま使える(Updateの時消えるので要再導入)。個人的にコレも超重要。

 ・当方のように単色背景を使う人間にとっては、以下の2つのコマンドラインは必須。
  というかコレなんでGUIから削ったん。

  control /name Microsoft.Personalization /page pageWallpaper
  control /name Microsoft.Personalization /page pageColorization

 ・BSODを発生させないにしても、一度Uninstallした後再Installしないと正常動作しないアプリも少なくない。
  修復ではダメ、アレ?と思ったら取り敢えずUninstall&再Install。

 ・正常にUninstall&再Install出来ればアプリもドライバも意外と古いモノでも普通に動く模様。この辺りはさすがMSといったところか。

  但し「普通に動く」ことを確認するまではものすごく大変。
  ドライバ類だと前述した「日和見BSOD」起こすブツが正直言って少なくないし、アプリでもウィンドウやボタンが妙にズレて肝心なトコが押せなかったりなんてパターンも。

 ◇

 以上、S.KazのWindows10 In-place Updateドタバタ騒動記、若しくは「常駐モノや組込モノが多い人は御注意あれ」というお話でしたとさ。

 今回はこの辺りで。

Share

リモート デスクトップ サービスは別にビジーではありません。

 今回のネタは、時々「あ~やっちまった」となるお話。

 Windows Serverでログインしたまま(そして大抵は何かアプリを動かしたまま)のセッションに再接続しようとすると、たまにこんなエラーが出て接続させてくれないことがある。

 「リモート デスクトップ サービスが現在ビジー状態のため、実行しようとしている操作を完了できません。しばらくたってからもう一度試してください。他のユーザーはログオンできます。」

 ちなみに英語版のエラーメッセージはコレ。

 「The task you are trying to do can’t be completed because Remote Desktop Services is currently busy. Please try again in a few minutes. Other users should still be able to log on.」

 この問題が出てしまった時の対処法は、

 「Adminユーザーでログインして該当ユーザーを強制ログアウト」

 これが一番。というか、実質的にはコレしかない。

 え、保存していないデータ?セッション切る前に保存していなかった方が悪い。
 だってWindowsよ?いつ落ちてもおかしくないでしょ?それぐらい覚悟してるよね?

 ・・・え、鬼畜過ぎるって?
 でもこんな風に割り切りでもしないとどうにもならないのも事実なワケで。
 さくっと強制ログアウトしてしまいましょ。

 ◇

 さて、頻度は低いとはいえ一度ブチ当たってしまうと状況次第では(精神的、或いは時間的)ダメージが結構大きいこのトラブル。
 一番アレなところは、エラーメッセージが実態を全く正しく表していないことなのではないかと。

 というのは、殆どの場合、問題なのはTermSvcs(Remote Desktop Services)ではなく、その上のセッションで動いているCsrss.exeがセッション接続要求に応えなかったからなんですな。

 そもそもcsrss.exeって何かと言われると、カーネルとアプリケーション間のやりとり(システムコール等)を仲立ちするシステムサービス。Windows起動と共に開始され、サービス開始に失敗する(或いはユーザが間違って停止させる)とBSODで即落ちする、Windowsの基幹部品の一つ。
 なので、アプリが起動する際には必ずこのcsrss.exeとのプロセス間通信が発生しているし、ユーザーがログイン・ログアウトする際、セッションが接続・解放される際にも然り、と。

 ところが、デスクトップ用に作られてあまりセッション切断のことを考慮していないアプリがあると、セッションが切断された際にアプリとcsrss.exeの間でデッドロックが発生してしまうそうな。状況的には、カーネル側に対してはセッション切断を完了しているが、アプリ側のセッション切断完了は待ち続けているという。
 仮にcsrss.exeがアプリにセッション切断を強制したらアプリが即ハングする可能性もあるので、さすがにそういう仕様にはなっていない。

 この状態でもシステムコール等は正常に出来るし、アプリ自体は特に問題無く動き続けるが、csrss.exeの方は「セッション完了待ち」ステータスで居続ける為、新しいセッション接続要求に対して対応することが出来なくなってしまう。

 #ちなみにWindowsServer2008/R2にはこのデッドロックが頻発する不具合(バグ?)があり、修正パッチが出ているものの、これも根本解決ではなくタイミング調整等でデッドロック頻度を下げているだけ、の模様。

 ◇

 それじゃコレ、正しくお行儀良くセッション切断するアプリなら問題無いか、というとそう簡単な話でもないようで。
 何しろ「純正」MS製のOffice等でもこのデッドロック状態が発生することがある、という話はぼろぼろ出てきているので。

 不具合発生頻度が結構高くよくネタとして出てくるのはOutlookで、デカいメールボックスを抱えているようなユーザー。
 Outlookのプログラム自体はこのセッション切断を考慮していないワケではないようなのだが、メールボックスに対して検索等の操作中だったり、裏でインデックシングが動いているような状況で切断すると、アプリ側のセッション切断がシステム側の要求に対して間に合わず、デッドロック状態に陥ることがある模様。

 他にも、たまたまIO要求が高い状態でセッション切断すると、通常なら一瞬で終わる筈の処理がIOに引っ張られて待ち行列に入ってしまい、結果的にタイムアウトしてデッドロック状態になるというハメに陥ることも。

 ◇

 ということで、元々「シングルセッション」「全権限制約無し」「起動中にセッション切断・再接続なんて考慮外」という世界で動いていたWindowsのデスクトップアプリを、Server上で動かすってのは意外とリスキーである、というお話でしたとさ。

 まぁ自分の場合は「あっちゃーまたかよ」で済むので特に対策もせず使い続けているが、そういうのが許されない状況だったら、悪いことは言いません。
 Server上でデスクトップアプリを動かすなんてことはやめといた方がいいです、はい。
 そしてどうしてもデスクトップアプリを起動しなくてはいけなくなったら、終了するまでセッションはそのままで。

 P.S.
 個人的には出来はそんなに悪くないと思っているNT6.3カーネルなのだが、その中でも恐らく手癖として最悪なのがコレ

 「IOのプライオリティが高い割に、IOと要求スレッドの並列化が十分になされていない」

 ではないかと。
 結果として、該当スレッドの処理内容とは関係無い筈のIOの待ちでスレッドが何故か一時停止したり、平行稼働出来る筈のIOが何故か順次稼働になってしまったり。
 プライオリティを上げないとIO性能が頭打ちになるのは目に見えていたのでこの変更自体は正解だと思っているが(これからコンシューマーでもNVMe等が普通になっていくだろうし)、伴ってもう少し改善すべき箇所もある気がするのよね。

Share

UEFI bootでディスクのSerial Noを変えて起動しなくなったら。

 検証用に大量の物理・仮想マシンを並べたりする時によく使われる、クローニングという手法。
 仮想マシンだと特に簡単にコピー出来るので、さくっと出来て嬉しいことが多い反面、気をつけなくてはいけないこともあるワケで。
 そんな中には、従来のBIOS環境だと気にする必要が無かった、UEFI環境ならではのネタもあるワケです。

 そんな中で今回ネタにするのは、割とありがちな「ディスクのシリアルID書き換えたら起動しなくなった」という話。
 自分も初めてやらかした時は「あちゃ~」という感じだったので。

 ◇

 まず、前提。

 状況:

 UEFIで起動する環境でブートドライブのシリアル番号を変更すると起動しなくなる。

 解決策:

 Step1:bcdbootで修理する。
 Step2:それで駄目なら、bootrecで修理する。

 当方が色々やらかした範囲では、ブートドライブのシリアル変更のみならbcdbootの自動修復で100%回復している。
 何も考えずに直してくれるのでこれが一番ラク。
 但し万が一これがコケた時に備えて、後で本来正当なbootrecのやり方もメモっておく。

 ◇

 以下、まずはbcdbootでやる方法。

 1:
 起動がコケてるマシンをWindows Install DVD(またはUSBメモリ等)で起動し、コマンドプロンプトを開く。

 システムによってはInstall DVDよりも起動優先度が高いデバイスが存在する為、必要ならばBIOS(UEFI)画面に入って起動優先度を変更する。
 DVDから起動したらインストールオプションから左下「コンピューターを修復する」を選択し、「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト」。

 2:
 diskpartでWindows SystemのあるボリュームにC:を割り当てる。

 select disk 0
 → list volume
 → 一覧からWindows本体が入っているパーティションの番号をチェックし、select volume 番号
   (例えばselect volume 3)
   大抵の場合Infoに「ブート」と入っている
 → assign letter=C:
 → exit

 3:
 bcdbootでC:から起動するエントリを作成する。

 bcdboot C:¥Windows /l ja-JP

 4:
 DVDを抜いてシステムを再起動する。

 以上。
 実はこのうち3.のC:を割り当てる作業をせず、4.でオプション無のままでbcdbootコマンドを打つだけでも、結構な確率で起動する状態に戻せる。
 とはいえ時々コケることもあるので、ドライブレターを振っておいた方が幸せな模様。

 ◇

 それでは次に、bootrecコマンドを使う場合。
 以下の例は修復フルセット。

 1:
 起動がコケてるマシンをWindows Install DVD(またはUSBメモリ等)で起動し、コマンドプロンプトを開く。

 2:
 diskpartでWindows SystemのあるボリュームにC:を割り当てる。

 3:
 diskpartでBoot PartitionにF:を割り当てる。

 select disk 0
 → list volume
 → 一覧からBootパーティションの番号をチェックし、select volume 番号
   (例えばselect volume 0)
   大抵の場合Labelは「システムで予約済み」、Infoに「システム」と入っている
 → assign letter=F:
 → exit

 4:
 Bootフォルダに入ってbootrecコマンドで再構築する

 F:
 → 環境依存で以下のうちどれか、dir等でBootフォルダを探す
   cd ¥EFI¥Microsoft¥Boot
   cd ¥ESD¥Windows¥EFI¥Microsoft¥Boot
   cd ¥Boot
 → bootrec /fixboot
 → bootrec /fixmbr
 → bootrec /rebuildbcd

 5:
 DVDを抜いてシステムを再起動する。

 ◇

 以上、こんな感じでほぼ何とかなる筈。

 ちなみにマルチブート構成ではrebuildbcdで複数のWindowsが認識され自動でエントリに追加される筈だが、時々取りこぼしも出る模様。
 所詮自動修復なので、その辺りは手修正しましょうということで。

 あと、シリアル書換でなくトラブル対応でも良く出てくるbootrec /fixbootだが、そういう場合はWindows Systemの入っているボリューム(上の例だとC:)がActiveにマークされていることを確認することをお忘れ無く。Systemの入っているボリュームがActiveになっていないとこのコマンドはエラーになってくれるので。

Share