世界を変える方法は山川の教科書に書いてある (1/2)
「世界を変えたい」とか「日本の教育行政を変えると日本を再生できる」とか、土日に最近の話題をざっと追いかけていてとても違和感があった。日本の義務教育（実態として義務化している高校も含めて）では世界を変える方法をきちんと教えているのだから、変えなければいけないのは教育行政ではなく、教科書に書かれていることを「自分事化」する教え方ではないのか、と思うのだ。 商品・サービスの設計方法 商品・サービスの設計方法は、3つしかない。ひとつは新しいニーズをいち早くつかみ、これまでにない商品・サービスを「発明」することだ。竪穴式住居の普及で一箇所に留まる時間が長くなり、食料を貯蔵するニーズから縄文土器が生まれたように、大量の音楽がデータ化されPCで楽しむようになった後、ハードディスクやフラッシュメモリーに音楽データを入れて携帯する「携帯型デジタル音楽プレイヤー」が生まれた。 ふたつめの方法は「改善」すること
CPU黒歴史 夢の5GHz CPUは燃費最悪 Prescott～Tejas (1/4)
CPU黒歴史第5弾は、インテルの90nm世代の話である。「Willamette」に始まり、「Northwood」でそれなりに性能と消費電力のバランスも取れて、しかも動作周波数を上げやすいということで比較的好評だった「Pentium 4」シリーズ。これに大ブレーキをかけたのが「Prescott」世代である。連載61回でも一度説明したが、まずはこのPrescottの話から始めよう。 大幅な機能拡張と高速化の工夫を 凝らしたPrescott NorthwoodからPrescottへの改良点として、当初インテルから挙げられたのは以下のような内容であった(関連記事)。 90nmプロセスを利用し、さらに「歪みシリコン」を利用することで高速化を図る。 内部配置を大幅に見直すことでクリティカルパスを大幅に短縮し、より高速動作を可能にした。 1MBの2次キャッシュを搭載。 「PNI」(Prescott Ne
5分弱の“玉音放送”を現代語訳してみた
「ちきりんの“社会派”で行こう！」とは？ はてなダイアリーの片隅でさまざまな話題をちょっと違った視点から扱う匿名ブロガー“ちきりん”さん。政治や経済から、社会、芸能まで鋭い分析眼で読み解く“ちきりんワールド”をご堪能ください。 ※本記事は、「Chikirinの日記」において、2008年8月15日に掲載されたエントリーを再構成したコラムです。 今日8月15日は太平洋戦争の終戦の日。そこで8月15日正午にラジオで放送された5分弱の「終戦の詔勅」、いわゆる“玉音放送”を現代語に訳してみました（原文はこちら）。太字が原文（カナは追記）、その後が“ちきりん現代語訳”です。 玉音放送を現代語訳してみた 原文 朕深く世界の大勢と帝國の現状とに鑑み非常の措置を以て時局を収拾せむと欲し茲（ここ）に忠良なる爾（なんぢ）臣民に告く 世界の情勢と日本の現状をよくよく検討した結果、ありえないと思われる方法をあえてと
DNSの歴史（第5回「DNSサーバーの誕生」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 前回，DNSのアーキテクチャや仕様が決まるまでをお話しました。実際にネット上でDNSを利用するには，DNSを実装したサーバー，つまりDNSサーバーが必要です。「DNSの歴史」最終回である5回目は，DNSサーバーについて解説します。 RFCに基づくDNSが最初に実装されたサーバー，すなわち，最初のDNSサーバーは，RFCを書いたPaul Mockapetris氏自身による「JEEVES」です。JEEVESはその後，UNIX系OSの一種である「4.3 BSD」のために開発された「BIND（Berkeley Internet Name Domain）」に置き換えられて，現在に至ります。 BINDは，カリフォルニア大学バークレー校「Computer Systems Research Group（CSRG）」により，開発されました。CSRGに在籍
DNSの歴史（第4回 普及までの道のり）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 HOSTS.TXTに代わる，新たな名前解決の方法である「DNS」。開発の中心人物は，Jon Postel氏，南カリフォルニア大学情報科学研究所(SIS)に所属していたPaul Mockapetris氏，そして，Craig Partridge氏を中核とした，Information Sciences Institute（ISI）のあるグループでした。 1983年11月，Jon Postel氏が開発スケジュールをまとめ，RFC881 *1 として発表しました。DNSの基本概念と実装や仕様については，RFC882 *2とRFC883 *3 として，Paul Mockapetris氏が発表しました。なお，基本概念については，1982年にもRFCが発行されています *4。 *1 RFC881 The Domain Names Plan and Sc
DNSの歴史（第3回「DNSに必要な条件」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 「HOSTS.TXTの破綻」を教訓に，ARPAnetは，「新たな名前解決の方法」として以下の条件を満たすシステムを開発しようとしました。それが現在のDomain Name System (DNS) です。 （1）分散管理できること 「HOSTS.TXT」の二の舞を演じないためには，不可欠の条件でした。HOSTS.TXTのように，1カ所に管理を集中すると，そのホストは過負荷状態になってしまい，いとも簡単にダウンしてしまうことは実証済みでした。 （2）階層的にホスト名（名前空間）を管理できること 現在のドメイン名などを見ると「.」で区切られて，階層化されていることが分かります。階層的な名前空間を使用することにより，ホスト名が重複するのを避けようとしたのです。これも，HOSTS.TXTの失敗に学んだ条件です。階層化という発想自体は，UNIXの
DNSの歴史（第2回「HOSTSファイルからDNSへ」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 当初，「HOSTS.TXT」ファイルで名前解決を図っていたARPAnetですが，ホスト数の増大により，様々な問題が発生しました。そのため，ARPAnetは危機に陥りました。ネットワークが正常に機能しなくなりつつあったのです。 具体的には，次のような問題が発生しました。 （1）SRI-NIC *1 の負担増大 ARPAnet上に存在する，すべてのホスト情報を記載したHOSTS.TXTファイルの容量は，大変大きくなっていました。1ホストにつき1行増えるので，ファイルは何万行にもなりました。また，当時は現在とは比較にならないほど，接続回線は細いものでした。複数のユーザーが大容量のファイルを転送しようとすると，回線はすぐに一杯になってしまいました。 そのため，管理の手間もさることながら，そのファイルを保存しておくためのサーバー・リソースや，その
DNSの歴史（第1回 「HOSTSファイルの崩壊」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 インターネットやイントラネットといった，TCP/IPネットワークの利用には不可欠なDNS（Domain Name System：ドメイン・ネーム・システム）。ホスト名を問い合わせると，そのホストのIPアドレスを返してくれます（これを「名前解決」といいます）。また，その逆も可能です。 そのため，数字の羅列であるIPアドレス（例えば，“211.2.246.25”）を覚えていなくても，意味がある文字列で構成されるホスト名（例えば，“itpro.nikkeibp.co.jp”）を覚えていれば，そのホストへアクセスできます。 今や当たり前のように利用しているDNSですが，TCP/IPネットワークが構築されたときから，存在するわけではありません。DNSが現在のように利用可能になるまでには，紆余曲折（うよきょくせつ）がありました。このコラムでは，5回
Page not found – GNU/Linux Distribution Timeline
Deprecated: Optional parameter $content declared before required parameter $post is implicitly treated as a required parameter in /home/kd89114/futurist.se/gldt/wp-includes/functions.php on line 840 Deprecated: Return type of WP_Theme::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to t
返信メールの“Re”の意味と由来 - 言語郎−B級「高等遊民」の妄言
（第189号、通巻209号） Ｅメールを受け取った後、発信者に返事を出そうとパソコンのメールソフトの「返信」ボタンをクリックする。画面の宛先欄に相手のアドレスが打ち込まれており、「件名」の欄には相手が書いてきた用件の冒頭に“Re:”が自動的に付記される。“Re:”は返信であることを示す接頭辞、言わば目印になっている。 日ごろ何気なく使っている “Re:”について、多くの人は英語の“reply”（返信）か“response”（応答、返答）あるいは“return”（返却）の略、と漠然と思っているに違いない。私自身、数年前までなんの疑いもなくそう解釈していた。ところが、実際には“reply”にしろ“response”にしろ“Re:”の語源としては俗説のようだ。 では、本当の語源はなにか。いくつかのウエブサイトやパソコン関係の本、辞書にあたってみたところでは、二つの説に帰結する。まず一つは英語の“
なぜ，/var や /etc が /etc や /cfg というディレクトリ名ではないのか？ - NO!と言えるようになりたい
Unixを使っていると，/usr が全然ユーザー用じゃなくどう見てもシステムのための物だったり，/etc が事実上設定ファイル置き場となっていたり，/var がログファイル置き場となっていたりと，名が体を現していなくて奇妙な感覚を覚える．もっと分かりやすい名前の付け方があったんじゃないかと，Unixユーザーならば誰もが思うはずだが，これに対する解答がredditに投稿されており，その内容が非常に面白かったので，軽く翻訳してみた． Anyone know why /var and /etc weren't named something like /etc and /cfg? http://ja.reddit.com/r/linux/comments/cpisy/anyone_know_why_var_and_etc_werent_named/c0ua3mo 昔々，システム7が使われていてU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブの歴史がひと目でわかる！ GoogleがHTML5で作成したページ“ウェブの進化”を公開!! - 週刊アスキー
「コミックマーケットの源流」展のために、コミケ会場の変遷図をつくってみたら... on Twitpic