目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには 2025 年入試から大学入試共通テストでも出題されるようになり、教科「情報」の重要性が高まっています。 これで 2030年に79万人不足すると言われる IT 人材 の問題が解決！…と言いたいところですが、先日も『課題感ある教科1位「情報」』という調査結果が

パソコンユーザーのためのDRAM入門 目次 Part 1 : パソコンにおけるDRAM、DRAMの構造 Part 2 : 制御、パッケージ Part 3 : GHzへの挑戦、PCB Part 4(準備中) : マルチチャンネル、規格、未来 Part 2 おさらい Part 2の肥大化を抑えるために、Part 2ではDRAMチップの制御方法の大枠と、DRAMダイのパッケージングについてのみ触れた。そろそろ肉眼スケールの話に移りたいと飽き飽きする頃だろう。 そして、ついにPart 3で私達人間が日常的に触れられる物理スケールの話に移っていく。いよいよDIMMのご登場だ。ついにcmオーダーの話に突入だ。だが、ここには悪魔が潜んでいる…いや、もはや神と言っていいだろう。そう、電磁気のお時間が始まります。どんなにデジタルな数字を扱おうとも、その根源には物理法則があることを叩きつけてくる、それが現実の

パソコンユーザーのためのDRAM入門 目次 Part 1 : パソコンにおけるDRAM、DRAMの構造 Part 2(本記事) : 制御、パッケージ Part 3 : GHzへの挑戦、PCB Part 4(準備中) : マルチチャンネル、規格、未来 Part 2があまりに肥大化したため、Part 2とPart 3に分割した。そのせいで若干Part 2が寂しい感じになってしまったが許せ。 Part 1 おさらい まず、多くの人にPart 1を読んでいただいたことを感謝したい。Qiitaはソフトウェアの話題が多い中で、このようなゴリゴリのハードウェア、しかも半導体レベルの話題に興味を持っていただけたことは大変嬉しい。勢いで書いた拙い文章であるが、DRAMの話題を通して身近な半導体にさらに興味を持っていただけたらなと思う。(前半のバスの話が長すぎて、大事な後半読まれてない説が若干あるが(汗))と

はじめに 本ドキュメントでは、Kubernetes v1.21 にAlphaとして登場予定のContainer Object Storage Interface(COSI)について紹介します。 なお、本内容は2020/10/20にマージされたKEPの内容をベースにしており、Kubernetes v1.21 or later向けには大きく変更される可能性があります。 KubernetesコミュニティのSIG-StorageのCo-Chairの発表ではCOSIを「コーズィー」と発音していました。 COSIの概要 これまでKubernetesではブロックストレージとファイルストレージをターゲットにCSIが提供されてきました。 これに加え Kubernetes v1.21 からはAlphaとしてオブジェクトストレージをターゲットにしたCOSIが登場する予定です。 ブロックストレージ・ファイルストレ

序 : プロセッサへの嫉妬 DRAMさん「最近みんなCPUやGPUにばかりうつつを抜かしやがって…。みんながやれRyz○nだの、FinFET ○nmだの盛り上がって、みんなが次世代プロセッサを楽しみにしている。新しいアーキテクチャやISAが出てきて話題も絶えない。」 DRAMさん「たしかによ…CPUはパソコンの花形だし、GPUの性能上げればゲームのグラフィックスがきれいになるよ。それに比べると俺は目立たない。」 DRAMさん「挙句の果てに、Memory wallだなんて言われて、CPUやGPUの足を引っ張る存在だと疎まれている。」 DRAMさん「だけど…だけど…俺がいなかったらパソコンは動かない…！それに、俺だって頑張ってる！お腹にviaを貫通させたりして、CPUやGPUの足を引っ張らないようにしている！」 DRAMさん「だから…だから…俺を…DRAMを…見てくれ…！！！」 対象読者 DR

Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important 優れた概念であり、Mozillaにとっても重要である。 worth prototyping 優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。 non-harmful 有害ではないが、良いアプローチではなく、取り組む価値

はじめに Linuxでファイルのreadaheadがどのように動いているのかを読み解くという趣旨の雑記です。kernelへの理解の助けにはなると思いますが、何かしらの結論めいた記事というには程遠いです。 なお、Linux-4.16くらいを見ています。 readaheadの役割 例えば、とあるファイルを先頭から4KB分readしようとしたとする。要求に応じ、Linux kernelは該当ファイルのinodeの中身の位置を特定し、少なくとも中身の先頭から4KB分をreadして返さないといけない。 ただ、先頭から4KBをreadするようなユースケースの場合、続けて次の4KBもreadするような処理へ続く可能性が一般的に高い。このため、先に4KBをreadするときに、kernelが勝手に4KBではなくて8KBやら16KBやらreadしてページキャッシュに載せておくと、続きの要求を出すときにすでにr

タイトルは「Linuxの「かな漢字変換」」です。ひらがなの文字列を普通の漢字かな混じり文にするソフトウェアの話です。 はじめに この記事ではLinuxの日本語入力を歴史の中で特にかな漢字変換の部分の歴史についての概要です。その時代に広く使われていたと筆者が独断で思う物のみに触れます(触れてない物の中には筆者の友人知人の作品も含まれていて心苦しい点もありますが…)。 Linux以前 - 国産ワークステーションの時代 80年代後半から90年代前半にかけて国内の複数の会社がワークステーションを製造販売していました。各社ではそれぞれのアーキテクチャにUnix系OSを移植し、何社かはそこに搭載する日本語入力のシステムを自社で開発し、さらに素晴らしい事にほぼオープンソースな条件でソースコードを公開していました(NECのCanna, オムロンのWnn, SONYのSj3)。 その中ではCannaやWnn

はじめに 世の中には Ceph 等、汎用サーバを束ねてスケーラビリティの高いストレージを作るための Open Source ソフトウェアが沢山あります。しかしながら、スケーラビリティを高めるためのトレードオフとして、コンポーネントが大規模化して運用管理のハードルがやや高めになってしまいます。 とはいえ、(Linstor コントローラを含まない)DRBD のような、シンプルな構成だけでは沢山の Volume を管理するのが辛くなってしまいます。 この問題は Public Cloud を使う人にとっては今まで問題にはならなかった内容ですが、Kubernetes (k8s) が広く普及してきたことで、次のような形で問題が顕在化しました。 k8s 単体でも簡単に Pod が抱えるデータを永続化する方法として、Statefulset や Persistent Volume が利用できるようになった

Rust を勉強し始めたので冬休みの間に Linux の boot protocol を喋る x86ブートローダー（自称:Krabs）を作ってみました。この記事では、開発に至った動機や、作成した Krabs の特徴とか仕組み、開発中におきた嬉しかったことなどについて書きたいと思います。 Krabs とは Krabs は、Rustで書かれた x86/x86_64(Legacy BIOS) 向けの４段ロケット構成のチェインローダーです。 bzip2 で圧縮された ELF 形式のカーネルを起動できます。bzip2 圧縮されたイメージを解凍して、次に展開してでてきた ELF イメージを再配置してからの、カーネルの起動となります。 内部では libbzip2 の C ライブラリを利用していますが、それ以外は全て Rust で記述されています。 GitHub - o8vm/krabs: An x86

はじめに （この記事はFujitsu Advent Calendar 2019 24日目の記事です。なお、記事は個人の見解であり、組織を代表するものではありません。） というわけで、今年もNVDIMMこと不揮発メモリの話を書くことにしました。補足編となっているのは、今年はすでに12月の講演で最新状況をほとんど話してしまっていて、その講演の時間内に収められなかった小ネタを補足としてするつもりだからです。 正直言うと、2019年は業務の都合上NVDIMMのお仕事はほとんど何もやっていなかったんです。しかし、過去3回にわたってひたすらNVDIMMの話を書いているせいか、最近はすっかりNVDIMMの人として見られるようになっている気がします。そのおかげで過去の記事をご覧になった大学の先生などから講演のお声がかかるようになってきたというわけです。ありがたいことです。 Outputを外に出すとそれが自

はじめに 本記事はChainerMNを用いて分散学習を行ってみようという記事です。内容としては分散学習について、データパラレル分散学習、モデルパラレル分散学習の順番になっています。 以下のスライドの拡張版です。 分散学習のあれこれ～データパラレルからモデルパラレルまで～ Chainerは素晴らしいフレームワークだったのですが、ついにメンテナンスフェーズへと移行してしまい、その役割を終えてPyTorchへと吸収されました。 分散学習をする際にChainerはとても明解であり、スムーズに研究を進められました。最後に恩返しの気持ちを込めて分散学習についてのあれこれを書いていきます。 最後にポエミーなことも書きますが、もしよかったら最後まで見ていってください。Chainerへの最後のクリスマスプレゼントとなれば幸いです。それでは見ていきましょう。 コードは後程Githubで公開します。 分散学習と

Rook とは Rookは，Cloud Native環境向けのストレージとして2018年1月にCNCFに加わりました． Rookの現在のバージョン(v0.7)では，Software Defined Storage(SDS)のCephをコンテナ化し,Kubernetes上にPodとして実行しています．これにより，Cephがもともと備えるブロックストレージ，ファイルストレージ，オブジェクトストレージの3つのタイプのストレージを提供しています．また，データの格納場所については，KubernetesのFlexVolumeを使っています． Rook の主な特徴 RookはCloud Nativeなストレージとして次のような特徴をもっています． KubernetesのSelf-healingにより，Rook自身もSelf-managing serviceを実現 Rookはアプリケーションと合わせてスケ

はじめに これはLinux Advent Calendar 2015 3日目の記事を2016/2/2に編集したものです。 Linuxにおいてシステムの物理メモリが枯渇したOut-Of-Memory(OOM)という状態になった際の挙動について説明しています。OOMに関連が深いsysctlパラメタを紹介するとともに、カーネルの内部論理についても触れました。 本記事に記載されているファイル名は、とくに断りが無ければカーネルソースのトップディレクトリからの相対パス名です。調査に使用したカーネルバージョンは4.3です。 本書は話を単純化するために、細かい動作論理については説明を省いていることをご承知おきください。また、本書の中に誤りを見つけたかた、および、私が追いきれなかったソースについての詳細をご存知のかたは、指摘していただけると助かります。 Out-Of-Memory(OOM)とOOM-kill

はじめに 「クラウドを支えるこれからの暗号技術」のデジタル署名の説明へのツッコミtweetをしたところ、著者の方との遣り取りが始まったのですが…。 ※togetterまとめ「電子署名=『秘密鍵で暗号化』」という良くある誤解の話に経緯があります 認識の齟齬についてtwitterでどうこうするのは難しいですし、批判ばかりなのも建設的ではないので、「自分ならこう書くだろう」という文面の形でまとめてみました。 ※なお、電子署名を含めた公開鍵暗号全般に対する私の説明を2つの公開鍵暗号(公開鍵暗号の基礎知識)にまとめています。 署名の説明案 前提 「クラウドを支えるこれからの暗号技術」Web公開されているPDF、2018/3/11時点(最終更新2017/11/11の4.6節デジタル署名(p.50)を、書き換えるとしたら、という前提で文面を作っています。 ※そのため既存の文面の流用や、他の節を参照する記

高速化をしようと思ったら、まず、プロファイルを取って遅い原因を探るということをするかと思います。 このため、前回、Chainer/ChainerMNのプロファイルの取り方等を紹介する記事を書きました。 https://qiita.com/shu65/items/42914bd2ad01d1e323da しかし、学習速度がでない原因の中にはプロファイルでは見つけにくいものがあります。 この記事では、このプロファイルでは判断しにくい上に、私が頻繁に遭遇する速度低下原因のChainer/ChainerMNのCPUリソース不足による速度低下についての紹介と、その解決方法、この原因が起きているかどうかの見極め方について紹介します。 CPUリソース不足による速度低下が起きる理由とプロファイラで見つけにくい理由 そもそもなぜCPUリソースの不足が起きるか？ CPUリソースが不足する原因はいくつかあるかと

自分への備忘録的な意味も込めて最近まとめたので、私が実践しているChainer/ChainerMNのプロファイルの取り方とプロファイル結果の見方を紹介します。 この記事で使うプロファイラは、Chainerのプロファイルを取る際まず取るべきと思われるcProfileとnvprofの二つです。 環境 Python: 3.6 Chainer: 5.2 CuPy: 5.2 CUDA: 9.0 MPI:　OpenMPI 1.10.7 参考コード この記事ではChainerMNのmnistのサンプルをベースに改造したコードで説明を行っています。 mnistのオリジナルのコードはこちら。 https://github.com/chainer/chainer/blob/v5/examples/chainermn/mnist/train_mnist.py 改良後のコードはここに上げてあります。 https:

この記事は武蔵野アドベントカレンダー19日目の記事です。 物理のステートメントはだいぶ雑ですが、計算のステートメントには一応正確さに気を使って書いているつもりです。何か誤りがあった場合は、@iKodackまでご連絡いただけると幸いです。 (2018/12/22に「宇宙破壊コンピュータはセールスマン巡回問題の最適化問題を解けるか？ 」「時間遡行コンピュータで無限ループすると何が起きるか？」を記事末尾に追加しました。) (2018/12/28に「宇宙破壊コンピュータは答えが無い場合に全ての宇宙を破壊する？」について記事末尾に追加しました。) 前書き より速い計算機が欲しい、という欲求は全ソフトウェアエンジニア共通であることが知られています。 最近、業務において500GBのSSDや16GBのメモリを最低水準にするべきではないか、という議論がネットで活発になされていますが、生産性を限界まで高める限

概要 そろそろApache Hadoopは終わったのでは? という話がありそうなので、ここ最近の状況を書きます。結論を言うとまだまだ終わってないですが、クラウド事業者が提供するマネージドサービスが充実してきたことにより、直接 Hadoopクラスタ上でジョブを実行したり、Hadoopクラスタを運用したりする人々は特定の企業に集中していくのかなと考えています。 Apache Hadoopとは Hadoopは、大きく分けてHDFS(Hadoop Distributed FileSystem), Hadoop MapReduce, Hadoop YARN(Yet Another Resource Negotiator)の3つのコンポーネントから構成されており、Hadoopについての発言を見たときには、それらのうち何について語られているか注意が必要です。主語がでかいのはよくないです。 Hadoop

自然言語処理とニューラルネット ここ数年で、自然言語処理の分野でもニューラルネットが非常に頻繁に使われるようになってきました。 自然言語処理で主に解析対象となるのは単語の配列や構文木などで、これらの内包する情報を表現するためにrecurrent neural network1やrecursive neural network1などに基づくモデルが頻繁に使われます。これらの最大の特徴はニューラルネットがある種のデータ構造を持っているという点で、1レイヤあたりのノードはそれほど多くない代わりにネットワークの接続が複雑で、しかも入力されるデータごとにネットワークそのものの形状が変化するという特徴があります。このため、伝統的なfeedforward neural networkを前提としたツールキットでは構築が難しいという問題がありました。 Chainerは、そのような問題を概ね解決してしまう強力