はてなキーワード: メモリとは
皆様こんにちわ。
このまま親のすねかじりではいけないと思い自分で稼げるようエロまとめサイトを作りました。
就職はできたもののついた上司が異常なほど暴力上司だったことにより
仕事をやめ実家でエロサイトサーフィンしてるとき、自分のエロサイトを急に立てたくなり
メモリ:4G
HD: 500G
wordpressのテーマは2年のにわか知識と人のテーマを見ながら作成
2年そこらの仕事でのノウハウを生かし自宅にサーバを立ててwordpressで早速開設。
ひどい時は0人…
相互リンクをするとよいと聞きいろいろなサイトに打診メールをするが返信がなく泣きべそ。
とりあえず生きるには金を稼がなきゃいけない
2,3年おきに1回行くか、いかないかという感じで90年台の半ばから。
今回行ったのは、ノートのメモリを緊急で必要になってしまったからだった。
さて、色々メディアで聞く限りだと秋葉原はビジュアルメディアのオタクの街(にかわってしまった)という話だったので、ふーんと思っていたのだ。(なぜなら2,3年前の時点もうそんな感じだったから。
でも今回行って見て思ったのは、もうそのレベルでさえ通り過ぎた感じになっていた。
メイン通りは中国人の観光客しかいないし、著名な電気店も顧客はほとんどいないようでビックリした。
なんと形容していいのか分からないのだけど、外国人が来るようなある意味「ダサい」観光地に成り下がっているのかもと思ってちょっと寂しかった。
ちなみにメモリは飛び込みで入った、ツクモさんで買ってその場で、店員にドライバー変えて換装とテストまで、できたので満足だった。
http://pha.hateblo.jp/entry/2015/12/03/225533 を見てふと。
当方文筆業。外で書き物するときとか、家の中でもデスクトップじゃ作業する気になれないとき用に動作の軽いラップトップが欲しいと思っていた。
値段がお安くて動作も軽いという噂のChromebookを検討したんだけど、基本的にブラウザ上で完結させないといけないと聞いて二の足を踏んだ。
ちょうどその時、古いノートPCをChromebookとして復活させてくれるアプリ『CloudReady』という記事がはてブに上がってたので試してみる気になったんだけど「Chrome OS入れるぐらいならLinux入れるわハゲ」というコメントがあって、そっちの方がいいのかとやってみた。
当方が持ってた古いノートPCは、2007年ごろに買った糞Vista搭載のレッツノート(CF-Y5)。当時の型落ち機だったので、買った当初からVistaは若干重く、とにかく嫌な記憶しか残ってない。CPUは2コアの1.6GHz、メモリは512+1024MBぐらい。クリーンインストールもしたんだけどやっぱり重く、ブラウジングですらコマ落ちする有様。これにLinuxの軽量ディストリビューションをいくつか入れてみて、けっきょくLinuxBean+Firefoxの組み合わせに落ち着いた。
あれ……、これだけか。
など。Windowsのように使おうとすると確実にLinuxの洗礼に見舞われると思う。ただそれを乗り越えてでも使いたいほど軽くなったので、頑張ることができた(デメリットというより単にLinuxに慣れろって話かもしれない)。
まとめると、糞VistaノートにLinuxを入れて手に入れたものは、「軽快さ」であり、Chromebookじゃなくて良かったなと思えるのは「Windowsアプリが動く」ことだ。Linuxに慣れてないことによって面倒だと感じることはあるが、用途を決めればそれに合致する環境を手に入れるチャンスではあると思う。
このエントリが、Chromebookを検討しつつ糞Vistaノートを死蔵させてるひとに対し、ひとつの選択肢を提示できたなら嬉しく思う。
原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題:Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日:2015年11月12日(午後にタイトルを日本語にしました)
----
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。)を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア(通信相手)とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注:blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント:
正直すげぇムカついている。
方法は単純。
買ったものを返品して、戻ってきたポイントで私物を購入してたってわけ。
yahooやrakutenのポイントくらいなら目をつぶってたけど、さすがにこれはネーわ。
たまたまHDDがいかれて、数台購入したばかりの領収書が目についたから余ってたらよこせって聞きに行ったら変に言いよどんだから追求したら発覚した。
アカウントの履歴見たらここ一年でHddとかメモリとかで月2~3万くらいずつの返品があった。
そんなに額も大きくないし月末の領収書チェックじゃ全然気づかなかった。
社内共有アカウント使わせなかった自分が悪いってのはあるけども、購入レポートを指定アドレスに定期的に配信させたりとかできないものかね。
iPhone6sにしてから1週間弱が経過したので、そろそろ3DTouchの感想を語らせていただく。結論から言ってしまうと「ものすごく人を選ぶ」機能であった。
まず、思っていたよりも力強く「グッ」と押し込まなければならず、お手軽とは言いにくい点を指摘しなくてはらない。感度設定は可能であるが、たったの3段階である。1番弱い設定にしても、かなり意識的に「グッ」と押し込まなければならない。フリックやスワイプにはそんな思考は必要なく、無意識に操作できる。しかし、3DTouchではそれができないのだ。マウスの右クリックの方がはるかに直感的である。(慣れの問題かもしれない)
そして、「グッしよう」と思考してから「グッ」したにもかかわらず、アップルの標準アプリですら、機能しないアプリが多すぎる。更に悪いことに、実際に「グッ」してみるまで、「グッ」が機能するのかどうか、全くわからない。スワイプやフリックの場合、アプリのUIで対応しているのか、直感的にわかる。その期待を裏切るアプリはほとんど存在しない。しかし「グッ」は期待を裏切るアプリが大半で、しかも一瞬の思考が必要な操作だけに、裏切られたときのがっかり感もそれなりにある。今では「グッ」できると覚えている画面以外では全く「グッ」しなくなってしまった。
更に問題をややこしくしているのは、「グッ」と「グググググッ」を使い分けなければならないという現実である。例外もあるが、多くの場合、「グッ」すると詳細がプレビューされ、「グググググッ」すると実際に画面が切りかわる。つまりプレビューでとどめておきたければ「グググググッ」と判定されるまでに指を離さなければならない。「グッ」と「グググググッ」の違いは感覚的に覚えねばならず、もはやアクションゲームの操作に近い。
「グググググッ」もマウスのダブルクリックよりも非直感的である。(慣れの問題かもしれない)ダブルクリックは、その人のペースで2回押しさえすれば反応するので、速い人も遅い人も問題ない。しかし「グググググッ」は「あらかじめアップルが設定した時間だけ押し続ける」必要がある。速い人からすればじれったいし、遅い人からすれば早すぎて使いにくいのである。
勘違いしてはいけないのは「グッ」するのが速い操作ではないことである。「グッ」するメリットは「グググググッ」しなければキャンセルできる、点に集約されている。写真アプリなら、「グッ」して写真をプレビューして、「グググググッ」して切り替える、はナンセンスの極みである。普通にタップすればすぐに切り替わるのであるから。タップの方がはるかに速くて簡単で直感的で確実。それでも「グッ」するのは、実は見たくない写真だった場合、「グググググッ」する前に指を離せばキャンセルされて元に戻る。そのため、指を画面左上まで移動して戻るを押さなくて済む、のが「グッ」及び「グググググッ」の最大のメリットである。
まとめると「「グッ」できる画面と「グググググッ」できる画面を記憶でき、今用意されている感度がジャストフィットし、アクションゲームに近い操作を無意識にできる人」にとっては3DTouchは神機能だと思う。でも、そうでない人にとっては無理に使うとかえってストレスがたまる機能である。フリックやスワイプは、操作にアナログ感があり、動かすのが速ければ速く、遅ければ遅く反応するが、どちらでも操作に問題はない。しかし3DTouchは、速ければ失敗し、遅ければ失敗する、デジタル的な操作である。慣れるまでは苦痛で、ずっと慣れられない人もいるであろう。
3DTouchは個人に合わせたチューニングが絶対に必要である。3段階ではその人にピッタリの感覚には絶対にならない。「グッ」と「グググググッ」の両方が無断階で調整できるようになるべきである。更に「「グッ」と「グググググッ」の両方の調整アプリ」を用意して、初起動時に調整させるようにするべきである。更に「グッ」は有効だが「グググググッ」は無効になる設定もできるようにするべきである。純粋にプレビュー専用の機能になるので、「グググググッ」になる前にキャンセルするのが苦手な人でも扱いやすくなる。
念のために補足しておく。iPhone6sはすばらしい端末であった。iPhone5sからの買い替えであるが、大きさにはすぐに慣れた。もう以前のサイズには戻れないね。何をするのもとても速く、特にアプリの起動と切り替えが快適。メモリ2 GBが効いていると思う。iPhone6sで注目するべきは4K撮影じゃなくて3DTouch、という記事をたくさん見かけるが、4K撮影なんて誰も気にしていない。注目するべきは間違いなくメモリ2 GBである。実際に使えば、3DTouchなんかよりも2 GBに有り難みを感じる。
「子供はまだいいや」とか思っている人。
「将来的には欲しい」と。かすかにでも思っているのであれば、早い段階で各種検査だけはしておくべき。
何故か。
いざ作ろうとしたタイミングで不妊の要因が見つかり、不妊治療といわれるような対処が必要になると、結構な時間がかかる場合が少なくない。
なんだかんだやっていると、気が付いたら2年経つ、ということも珍しくないのだ。
体の周期に合わせてのことなので、なんらか治療や検査など、一回のトライが最低でも一か月単位になると思っていい。
人工授精や体外受精になると、一回のトライが2~4か月単位になることも普通にある。
そもそもこの『不妊治療』に踏み込む前の段階で、半年~1年くらいかかったりする。
そうこうしていると、特に女性の体には年齢という重い壁が迫ってくる。
年齢が上がると成功率は下がり、体の負担などからも一回のトライやインターバルに時間が必要になる。
そこで。
私としては、子供を作ろうとする前に、事前にある程度の準備は終わらせておくこととお勧めしたい。
以下は20代の早い段階からでもやっておくことを強くお勧めしたい。
なんだかんだ基礎体温の把握は基本になる。
最近の婦人体温計はメモリ機能があるのは当たり前、PCやスマホと連動するものもある。
基礎体温計を付けて不審な点があればそれも婦人科で相談してみるといいと思う。
生理不順や生理痛がひどい場合は、何等かホルモンや卵巣などに問題がある可能性がある。
日常生活に差支えばなくても妊娠という面では障害になることがある。
もし検査で経度の子宮の病気等が見つかった場合、もちろん医師との相談の上ではあるが早めに対処を考えてほしい。
例えば通常は医者も「気にすることはない」という軽度の子宮の変形でも、不妊治療に何度も失敗すると「着床しない原因」の可能性を疑い手術することはある。
もちろん不妊治療中にそういった外科治療をすると次の不妊治療まで大きくインターバルが空くことは言うまでもない。
何が言いたいかというと、
ということ。そして
ということ。そのため
くどいようだが。
子供が欲しいと思ってから「トライ→検査→自然妊娠トライ→人工授精→体外受精』と一通りやってみるだけでも、すんなりいって2年はゆうに経つと思っていい。
時間との戦いを制するには事前にできることをやっておくに越したことはない。。
妊娠・出産だけでなく、むしろそれ以上に、不妊治療には肉体的も精神的にも女性に負担がかかる。
ぜひ支えになって上げてください。
仮に自分が今は子供が欲しくなくても、パートナーが検査や治療を行うことに嫌な顔はしないでほしい。
基礎体温について。
病院や医師によって差異はあるかもしれないが、診断の最初のデータとして利用されるケースが少なくない。
そのため基礎体温を全くとってない状態で婦人科にかかかっても「とりあえず1周期分基礎体温記録してきて」となり初回診断は何もできずに終わることもありうる。
所詮は素人が採取するデータ、精度にバラつきが出ることはあるがそれは医者も織り込み済みである。
最も負担が軽く取得できるデータでもあるので、よほど事情があるのでなければとることをお勧めしたい。
将来的に子供が欲しい男性も可能であれば精子の検査を行っておくにこしたことはないだろう。
とはいえ男性の不妊の場合、1年などの短期間で根本原因を取り除くような治療よりも、何らかの方法で精子を採取・選別して人工授精や体外受精となるケースが多いと聞いている。
(EDによる性交渉障害や精子の質と量に問題がある場合など、治療や手術等でそれ回復を図るよりも確実だからだろか。)
そういった意味では、"事前に検査や治療が 後々の自分の体やパートナーにかける負担の軽減にどれくらい有効に働くか"という度合では女性のそれと比べてインパクトが低いと私は考えている。
(重ねてになるが、やらなくて良いとは思っていないしケースバイケースではあろう)
スプラトゥーンの話題に乗って、せっかくなので用語を学んでおきたい。
タイムラグのことで、反応までに間があることを指す応用範囲の広い言葉である。
ラグってる、で、データが遅くておかしくなってる、くらいの意味。
カモンって聞いて、WiiUゲームパッドを見て、それから動く人。
(カモンに対して、即座に移動できる人は、ラグ無し)
ネットワーク周りを知っている人からすると奇妙に思えるネット語(ジャーゴン)である。
元々はネットワークが繋がってるか調べるPingと言うちっちゃなプログラムが発祥である。
行って帰ってきた時間(ラウンドトリップタイム:RTT)を出力するので、そこからの造語だろう。
リスポン地点から味方までスーパージャンプして、即座にリスポン地点に戻ってくる。
行きに4秒、戻りに4秒かかるのであれば、ラウンドトリップタイム(Ping値)は8秒である。
(往復レイテンシ=ラウンドトリップタイムなので、Ping値と同じだね)
リスポン地点からガチエリアまで駆けつける速度が、片道レイテンシ。
1秒間に送れるデータ量、とかって使われることが多い。
30Mbpsなら、1秒間に3000万個のビットを送るってことで、1秒に3.75Mバイトのデータを送れる。
リスポン地点からガチエリアまで駆けつける間に塗れる1秒あたりの面積。
しかも、だいたい大きなデータを全部ゲットできるまでの時間を割り算する。
例えば、3Mバイトのデータを3秒でゲットできれば、ダウンロード8Mbpsになる。
1秒あたりドレダケの面積を塗れるか、という値で会話をしてるが、
ガチエリアまでドレダケの速度で駆けつけられるか、という速度が重要という話。
パブロで塗りながらガチエリアまで来るイカリングでは、大きな差がある。
つまり、さっさとガチエリアまで来い、と怒っているわけである。
RTTだが、有線LANは0.5ms程度、無線LANは5ms程度が多いようだ。
環境にもよるが、(単位時間あたりの通信量ではなく)一回あたりの通信速度が10倍違う。
SIMでのテザリングはばらつきが大きいが、50ms程度のようだ。
スプラトゥーンの対戦時フレームレートは60fps(1秒間60枚描画)なので、0.017秒=17msに1枚だ。
つまり、有線LANなら、描画間に30回、無線LANでも次の描画までに3回は通信できるが、
SIMでテザリングしてると、1回通信する間に、3枚も描画が終わってしまっている。
無線LAN組が60fpsで快適に遊べているなら、テザリング組は20fps以下になってる。
個人的には任天堂がWiiUで出して有線LAN必須にしていない以上、
父親には言う。母親には言わない。
まず500万くらいで奨学金を完済する。
iMacも新しいのにしたい。メモリとかHDDは増やさなくてもいいかな。
欲しかったの何本か買うだけかな。
そんなに食べなくてもいいかな。
あとなにしようかなー