6/21/2018

海底ケーブルは海底の地震検知に利用できる

Slashdotより

サイエンス誌に掲載された論文で、イギリス国立物理学研究所(NPL)のジュセッペ・マラ氏は、まったく異なる目的のために建設されたインフラを取り入れることによって、海洋に小さな光をあてることを提案している。レポートより:
マラ博士らは、大陸から大陸(地図参照)のインターネットを巨大な海底センサーとして扱い、海底の光ファイバーケーブルの地球の100万キロメートルのネットワークを使用することを望んでいる。マラ博士は特に地震に興味がある。地球のドライビットは、地震計で十分に蓄えられている。海洋は、それほどうまくカバーされておらず、海底の永続的なセンサーはほんの一握りしかない。これは、多くの小さな地震は、それらが引き起こす揺れが遠い陸上のセンサーによって拾われるにはあまりにも軽度であるため、記録されていないことを意味する。このアイデアは、ある科学分野における進歩が他の明らかに無関係な分野における新たな発展につながる方法の良い例である。

IPv6採用へのブロッカー

RIPE NCCより

David Holder

最近、イギリスから米国へのフライトで、グローバル企業のITディレクターの隣に座りました。彼は私が旅行している理由を尋ねました。私は、米国政府が開催したIPv6カンファレンスで基調講演をするためだと答えました。躊躇なく、彼は「IPv6は私の片隅にもありません」と答えました。

多くの企業にとって、IPv6はまだToDoリストに載るには程遠いところにあります。多くの人は、それを採用するためにいくつかのブロッカーを挙げています。私が20年以上IPv6サービスを提供してきた中で見た3つの最も大きなブロッカーは次のとおりです。

ブロッカー1: どうして壊れていないものを修正しなければならないのですか?

企業はIPv6を今日のものとまったく同じものを与える技術として認識しています。インターネットはコストとリスクが増大しています。 彼らは、「なぜ壊れていないものを修正しなければならないのですか」と尋ねます。企業は、IPv4に基づくインターネットとIPv6に基づくインターネットとの間に差異はないと考えています。

IPv6コミュニティの一部のリーダーでさえ、それに同意しているようです。2017年に開催された北米IPv6タスクフォースで、ARINの社長兼CEOは、基調講演でIPv4とIPv6インターネット間に大きな違いはないと言いました。彼の正しい答えは、IPv6をより安全にすることで、IPv4よりもIPv6を魅力的にすることでした。 私はこれが間違っていると思います。

ブロッカー2: 私たちにはIPv6の予算がありません

私はこれを繰り返し聞きます。最近の別の会議では、講演者は組織のIPv6予算不足を嘆いていました。彼らはIPv6を導入したいとは思っていましたが、資金不足のために進めることはできませんでした。多くの組織では、IPv6を導入するための初期コストとIPv6と並行してIPv4を管理するための継続的なコストが非常に高く、その結果、プロセスのために予算が割り当てられていません。

ブロッカー3: 私たちはNAT44の利点を失います。

企業はしばしば、ネットワークのエッジでNAT44を使用しますが、セキュリティのためではなく、ロードバランシングとレジリエンスのために使用されます。これは、複数のインターネットプロバイダに接続し、BGPを実行し、独自のプロバイダ独立(PI)アドレス空間を持たない中小企業に特に当てはまります。大企業であっても、複数のプロバイダの利用を容易にするためにNAT44を使用することがあります。

PI空間を取得してBGPを実行することを望まない中小企業にとって、IPv6は大きな問題を提示します。現在、これらのタイプのマルチホームシナリオには、標準化されたIPv6ソリューションはありません。

ブロッカーの克服

時として、IPv6導入へのブロッカーを克服するのは簡単な場合があります。今日、一定の現実の問題を解決するために組織がIPv6に動かされるシナリオが数多くあります。ここでは、IPv6採用のためのこれらの原動力のいくつかを繰り返し説明する価値があります:

  • RFC1918のアドレス空間を使い果たした組織
  • 割り当てられたパブリックIPv4空間を使い果たした組織
  • AppleのApp Store向けアプリケーションを開発しているアプリケーション・プロバイダ
  • 特定のピアツーピア要件を持つ組織
  • デュアルスタックを考慮しなければならないサイバーセキュリティー組織
  • モノのインターネット(IoT)を導入している人たち
  • IPv4アドレスの在庫が不足している新しいISPやサービスプロバイダ
  • キャリアグレードNAT(CGN)の導入問題に直面した事業者

ここ数ヶ月、上記の理由のそれぞれについてIPv6を導入したクライアントと私は話をしました。

ブロッカーの克服: どうして壊れていないものを修正しなければならないのですか?

これは根本的な前提を受け入れる時かつその時に限り有効な質問です。IPv6インターネットがIPv4インターネットと同一であること。個人的には、私はこれには同意しません。さらに重要なことに、私は2つのインターネット間の違いが、企業がIPv6を採用する最も強力な理由の1つであると考えています。

ほとんどの人は、IPv6には想像もつかないほど大きなアドレス空間があり、IPv4アドレス空間は非常に小さく、完全に使い尽くされていることを理解しています。 IPv4アドレスの枯渇は、企業の一部に直接影響するだけです。 しかし、枯渇の間接的な影響は、すべての組織に影響します。この影響の規模は、組織がインターネットをどのように使用し、ビジネスにとってどれほど重要であるかによって様々です。

IPv6よりもIPv4を悪化させる企業にとって重要ないくつかの分野があります。これらには:

  • パフォーマンス。私たちの経験では、IPv6ネットワークではネットワークの待ち時間が少なくなることがよくあります。これはユーザー体験だけでなく、検索エンジン・ランキングなどの要因にも影響します。IPv6のパフォーマンスに関する調査では、大量のサンプルを同時に多数のコンテンツプロバイダに対して測定することはできません。従って、最終的な措置を取ることは困難です。しかし、IPv4のルーティング・テーブルのサイズやCGNに起因する遅延などの要因が、我々の観測をいくらか説明可能にするかも知れません。

  • 信頼性。一部のアプリケーションでは、IPv4ネットワーク上で断続的に障害が発生します。サイトあるいはアプリケーションと顧客あるいはエンドユーザーとの間のCGNによって、一部のアプリケーションが障害を引き起こす可能性があります。あなたは、どの顧客あるいはエンドユーザがCGNの後ろにいるのかをコントロールできない可能性があります。イギリスの情報通信庁であるOfcomがCGNに関する調査を行っている中で、私たちは多くの例を見つけました。私たちは、NAT44で動作するように設計されたアプリケーションでさえ、CGNで失敗する可能性があることが分かりました。モバイルネットワークでは、実際にCGNによって引き起こされた間欠障害がモバイルネットワークに起因すると考えられていると疑っています。イギリスの携帯電話事業者向けのサポートフォーラムを調べ、よく知られているメッセージ・アプリケーションと断続的な障害を探しました。私たちは、同じ電話機、ネットワーク、および同じ場所でこのアプリケーションを使用して断続的な障害が発生したという報告が多数あることを発見しました。私たちは、これがCGNによるものと推測しましたが、証明はできませんでした。CGNにログインする難しさは、オペレータとアプリケーションプロバイダがこれを証明することを不可能にしています。興味深いことに、アプリケーションのサポートフォーラムに同じ症状を議論する特別なスレッドがありました。

  • 分析。Web分析は、あらゆる規模の組織にとって非常に重要です。ここでも、エンドユーザからの経路にあるCGNは、アドレスによるユーザの追跡を不可能にします。エンドユーザー、パートナー、あるいは潜在的なクライアントがインターネットに接続する方法をコントロールできないため、これをコントロールできません。

  • ガバナンス、セキュリティ、フォレンジック、合法的傍受。IPv4インターネットにおけるIPアドレスとエンドユーザとの関係は、よりダイナミックで信頼性に欠けます。これは、CGNが経路上にあるためです。この場合もやはり、CGNが経路上にいる時、あなたはコントロールできません。従って、フォレンジックや合法的傍受はより困難になります。これにより、ベルギー政府はCGNの圧縮率を16:1に制限する命令を出しました。これは、ベルギーでのIPv6の採用における主要な要因の1つと広く見られています。つい最近、ユーロポールはCGNの禁止を提唱しました。 CGNがなければ、IPv4の機能を維持し続けることは不可能です。詳細については、https://tools.ietf.org/html/draft-daveor-cgn-logging-04https://www.europol.europa.eu/activities-services/main-reports/internet-organised-crime-threat-assessment-iocta-2016https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online、この記事の後半に参照している私のCGNのプレゼンテーションとレポートを見て下さい。

  • 重要な機能の不具合。例えば、IPv4インターネットのIPv4アドレスの広範囲な共有は、ジオロケーションの有用性が劣化し、意味がなくなる場合があります。これは、ジオロケーションを使用するWebサイト、分析、フォレンジック、アプリケーションに影響を与えます。この場合もやはり、企業はジオロケーションが劣化しているかどうかのコントロールや知識がありません。

企業マネージャーは、CGNのようなIPv4の不完全な技術的な詳細には関心がありませんが、ビジネスへの意味合いで非常に関心があります。

顧客がCGNの背後にいるかどうかを企業がコントロールできないことを繰り返し強調することは重要です。さらに悪いことに、彼らは通常CGNの背後にいることを検出することさえできません。

これらの問題や他の問題の一時的に止まる性質は、企業がこれらの問題が存在することを認識することが困難であることを意味します。彼らがそれを検出できたとしても、それがIPv4インターネットの劣化に結びついていると考えることは不可能であることも意味します。従って、IPv4インターネットの悪化を企業が理解できるよう教育する必要があります。

このトピックの詳細については、昨年の北米IPv6タスクフォース(NAv6TF)のミーティング(https://youtu.be/fbk4H6EmZzI)の私のプレゼンテーションあるいは、イギリスの情報通信庁OfcomのCGNレポート(http://stakeholders.ofcom.org.uk/binaries/research/technology-research/2013/cgnat.pdf)を見ることを推奨します。

簡単な補足 - 私は、より厳格なセキュリティを通じてIPv6をより良くすることはうまくいくとは思いません。Microsoft Windows Vistaを覚えていますか? それはより安全でした。企業はこれを歓迎すべきですが、むしろ、セキュリティが邪魔になったため、ユーザーはVistaを広く嫌いました。私たちは、IPv6をWindows Vistaと同じようなネットワークにすることは望みません。

IPv6でのみ可能な望ましい機能が見つかった場合、これはIPv6導入に寄与する役立つインセンティブです。MicrosoftのDirectAccessの導入や、Apple App Storeのすべてのアプリケーションに対してIPv6のみのサポートを義務づけたことなど、こうした種類の理由でIPv6を導入したクライアントがいます。

私たちは、20年以上にわたってIPv6のキラーアプリを探し求めてきました。それはまだ分かりにくいままです。問題は、キラーアプリがインターネット自体であり、IPv4とIPv6の両方がこれを提供しているように見えるということです。

代わりに、私たちは、どの程度IPv4インターネットが悪化しているかに焦点を当てるべきです。そして、IPv4とはかなり異なり、IPv6はIPv4の問題につながるすべての事柄を克服します。

ブロッカーの克服: 私たちにはIPv6の予算がありません

IPv6を導入するには、かなりの予算が必要となる可能性があります。しかし、これは必ずしも当てはまりません。実はむしろ、先見の明があれば、全体としてIPv6予算の多くの要素を排除することが可能です。

不要な費用を避けることはビジネスにおいて賢明です。IPv6を導入する場合、いくつかの単純なポリシーでIPv6の導入を容易にし、必要な予算を大幅に削減できます。ここではいくつかの例を示します。

購入

購入するすべてのネットワークハードウェア、ソフトウェア、サービスが「IPv6対応」でなければならないという購買ポリシーを実装します。これを行わないと、IPv6の導入時に交換する必要がある購入する危険を冒してはいけません。「IPv6対応」が何であるかを定義して伝えることは難しいことです。しかし、企業にとって、この定義だけで、追加の予算を必要とせずに、IPv6導入環境を構築するのに大いに役立つでしょう。

RIPEやその他の団体は、IPv6購入に関する有益な指針を作成していることに注意してください。

ITトレーニング

IPネットワーキングへの参照を有するすべてのITトレーニングに、従来のIPv4と一緒にIPv6を含める必要性があることを義務付けます。新しいITスタッフを募集する際には、IPv6を要件として含めることを忘れないでください。

ステルス導入のための機会

私は無許可でIPv6を導入することを主張しているのではなく、むしろ、企業が他のITプロジェクトを使ってIPv6を導入する方法を考えておくことを推奨しています。例えば、オフィスの移転は、新しいネットワークをIPv6対応、IPv6利用可能、またはIPv6専用にする機会になるかもしれません。新しいネットワークをIPv6専用として導入する特定のIPv6予算を持たないクライアントがいます。これにはIPv6導入コストはないだけでなく、デュアルスタック環境を運用するための追加コストもかかりません。

上記のすべての例の共通点は、これを行うには組織がIPv6を考えなければならないということです。IPv6は未来であり、それを導入する機会を求める意志の強い努力であることを受け入れる必要があります。さもなければ、IPv6の導入は、予算を正当化するのが困難なプロジェクトのままでしょう。

ブロッカーの克服: 私たちはNAT44の利点を失う

現在、マルチホーミングにNAT44を使用する企業のサブグループに対する優れたIPv6ソリューションはありません。PI空間を取得し、BGPを実行するか、ISPが自分のためにPI空間を広告することによって、この問題を解決する人もいます。他の人は、ネットワークアドレス・プレフィックス変換(NPTv6)などの望ましくない解決法に頼っています。

将来、プロビジョニング・ドメイン(draft-ietf-intarea-provisioning-domains-02)、PAアドレスを使ったエンタープライズ・マルチホーム(draft-ietf-rtgwg-enterprise-pa-multihoming-07)、あるいはソースアドレス依存ルーティング(draft-ietf-rtgwg-dst-src-routing-06)などの新しい標準ベースのソリューションを使用できるでしょう。それまでは、NPTv6を使用することによって対処される可能性が最も高い問題のままです。

最後のコメント

この投稿のすべてを下から支えるには、思考の変化が必要です。今日の世界は、IPv4がインターネットプロトコルの現行バージョンであると考えています。IPv6は、あまり重要ではない第二のプロトコルとして追加可能な付加機能です。IPv6導入の動きが起こるためには、思考の変更が必要です。私たちと他の人々は、IPv6がインターネットプロトコルの最新バージョンで、IPv4はレガシープロトコルであり、劣悪で壊れて悪化していると思う必要があります。

Hacker News

6/20/2018

OpenBSDは、セキュリティ上の問題でインテルのハイパースレッドを無効化

Slashdotより

OpenBSDプロジェクトは更なる「Spectre級のバグ」の理論上の脅威に関するセキュリティ上の懸念から、インテル製CPUのハイパースレッディングのサポートを無効化する計画だと発表した。Bleeping Computerがレポートする:

ハイパースレッディング(HT)は、プロセッサが同じマルチコアCPUの異なるコア上で並列動作を実行できるようにするテクノロジーである同時マルチスレッディング(SMT)のIntel独自の実装である。この機能は、2002年以降にリリースされたすべてのインテル製CPUに付加され、インテルではその主な理由としてパフォーマンスの向上が挙げられ、デフォルトで有効になっている。

しかし本日、OpenBSDプロジェクトのMark Kettenisは、OpenBSDチームがインテルHTのサポートを取りやめると述べている。設計上、これはこの技術がより多くのタイミング攻撃の扉を開いているためである。タイミング攻撃は、第三者のオブザーバが暗号アルゴリズムの実行に要した時間を記録して分析することによって、暗号化されたデータの内容を推測することができる暗号攻撃の類である。OpenBSDチームは現在、「多くの最新のマシンで、BIOSのセットアップでハイパースレッディングを無効にする機能が提供されなくなった」ため、HTサポートを無効にする新しい設定を提供することに取り掛かっている。

6/19/2018

AppleのHyperCardは、ビル・アトキンソンがラリって思い付いた!!

BoingBoingより

AppleのHyperCardは、LSDによる幻覚でインスピレーションを受けた

先駆的なエンジニアであるビル・アトキンソンは、Apple Lisaのグラフィカル・ユーザー・インターフェース、MacPaintとQuickDrawの作成者、そしてApple Macintoshを開発したオリジナルチームのトップ・デザイナー/開発者だった。1985年、アトキンソンはLSDをやって、最初のウェブブラウザの先駆けであった画期的なマルチメディア・オーサリング・プログラムであるHyperCardを思い付いた。アトキンソンは最近Leo Laporteに、この信じられないLSDが原因の発見の瞬間を語った。Mondo 2000より:

宇宙が活気付く過程にあるように私には思えました。意識は、宇宙に移住するために発展し、伝播して、地球上の生命は、意識の宇宙の誕生において、多くの明るい点の一つです....

街灯は私に知識の塊、発見と理解の宝石を気付かせましたが、遠く離れた異なる言語でお互いは離れ離れになっていました。詩人、アーティスト、ミュージシャン、物理学者、化学者、生物学者、数学者、エコノミストはすべて個別の知識を持っていますが、深いつながりを共有して見つけるのを妨げています...

知識、それは私には情報の断片の間を「どのように」つながり、原因と結果の関係から成り立っているように思えました。この行動はどのようにその結果をもたらすのでしょうか? 科学は、「どのように」つながりを発見するかの体系的な試みです。知恵は、それは私には、さらに一歩進んで削除され、知識の断片の間を「なぜ」のつながりの大きな視点にあるように私には思えました。なぜ、倫理的で審美的な理由から、私たちは将来にわたって一つの未来を選択すべきですか?

いろいろな知識分野でアイデアを分かち合うことができれば、より大きなイメージが出現し、最終的にはもっと知恵が発達するかもしれないと私は考えました。知恵につながる知識につながる情報のトリクルアップ理論の一種です。

これは、プログラマでない人がHyperCardスタックと呼ばれる新しいインタラクティブ・メディアを使用してアイデアを共有できるようにするマルチメディア・オーサリング環境であるHyperCardの根底にある発想でした。

6/18/2018

パンゲア上の自宅を見付ける方法

The Vergeより

大陸が存在する前、超大陸パンゲアが存在しました。2億年前、巨大な大陸が分裂し始め、私たちはその後ずっと分断されてきました。しかし、マップツールは、ある町が超大陸のどこにあったのかを知るのに役立ちます。

この古代のアース・ツールは、さまざまな時点で世界を回転させて見るものです。時代を選択することができます(「7億5,000万年前の地球はどうでしたか?」)、または「最初の多細胞生物(first multicellular life)」や「最初の昆虫(first insects)」などのイベントで検索することができます。あなたがパンゲア上に住んでいる場所を把握するには、住所を入力し、右端のオプションから「パンゲア超大陸(Pangea supercontinent)」を選択してください。

カリフォルニアの私の故郷は、なんとまだ海岸でした。しかし、ニューヨークの私の現在の場所は、一方が(明らかに)北東アメリカ、他方がモロッコであった土地にありました。

時間だけでは足りない場合は、Antipodesマップを使って場所を入力し、地球上の正確な他の場所を見つけることができます。ニューヨークの私の所在地の正反対の位置にある場所(対蹠地)はオーストラリアの近くの海ですが、私の故郷の対蹠地は... アフリカの南端近くの海です。しかし、中国中部で私が生まれた病院の対蹠地はアルゼンチン北部の場所です。そうこなくっちゃ。

6/17/2018

Rustプログラミング言語の第一印象

Jakobのブログより

Cはほぼ50年近く、C++はほぼ40年近いです。年数は通常、経験を下に何十年もの最適化を伴う成熟した実装を表していますが、言語の機能セットはプログラミング言語のデザインにおける最新の進歩がほとんど持っていないことも意味します。そのため、最新の言語に移行するには、PDP-11のようなプラットフォームの限界の中で仕事をするのではなく、最新のプラットフォームを考慮して設計されています。新しい言語の中にはZig、Myrddin、Go、Nim、D、Rustなどがあります。仮想マシン上で動作するJavaやElixirのような言語でさえ、事前コンパイルされたCとC++の代替として時折提案されます。

私はこれらの新しいプログラミング言語を区別する特性を調べ、それらを学び、ブログ投稿の形式で私の最初の印象をドキュメント化する計画を立てました。この投稿はその冒険の始まりです: 私の最初の印象はRustです。 私はいくつかの理由で前述の他の候補の1つではなく、まずRustを評価することにしました。一例としては、Mozillaのようないくつかのビッグネームに支持されているので、独自に開発したものよりも洗練されたドキュメントが用意されていることを期待しています。そうしないと、私たちは、コンパイラのソースコードを読む必要なしに、学ぶことができる言語を踏み外すかも知れません。また、私の意見が友人と一致していたため、以前のRustにはかなり批判的でしたが、わざわざ新しいプログラミング言語を学ぶ努力をすることにしました。 私は自分の批判が根拠がないかどうかを確認する機会としてこれを使います。

これらの新しいプログラミング言語を学ぶことは、確かに仕事になるでしょう。私が初めて紹介したのはPythonとCだったので、私はしっかりと精を出して、学び、その時にやっていた全てのものにそれを適用することができました。私が後で他の言語を勉強しようとした時、私が進歩しているかどうかを判断するのに苦労しました。私は、これは学んでいたものに積極的に関わりを持っていなかったからだと思います。私が学んでいた言語を使った些細なプログラムを書いていて、本物のプロジェクトに取り組む必要がある時はいつでも、CやPythonにデフォルト設定していました。私の目標は、これらの新しい言語を意味のある評価ができる範囲で学ぶことです。そのため、私は過去の試みを振り返り、重要なものを開発するためにそれらを使用する必要があるか、いくつかの記事で提案されているように、その言語で書かれたフリーソフトウェアプロジェクトに貢献することです。 この投稿について言えば、私は実際にはRustがKen SilvermanのBUILDエンジンを再実装するのに十分使えるようになったので、前者になります。

とんでもないこのシリーズのためのイントロで、Rustの私の最初の印象に踏み入れることができます。最初のステップはそれを学ぶためにマニュアルに飛び込むことで、そこから始めるのが理にかなっていると思います。簡単に言えば、Rustの質の高い学習教材が不足しているわけではありません。RustにとってのTCPLに相当する "Rust Programming Language"は、驚くほどよく書かれています。あなたがCのようなシステムプログラミング言語に精通していても、始めから最後まで読むことをお勧めします。私は最初に "Rust for C++ Programmers"とRustのチュートリアル"Learn X in Y Minutes"から始めましたが、TRPLを読むまでは意味がありませんでした。標準ライブラリを使用するようになった時のことを完全に忘れていました。この本は、親しみやすく、奨励されており、標準ライブラリとさまざまなサードパーティ製クレートの共通パターンを概説する優れた例が満載です。TRPLの唯一の不満は、アナロジーのいくつかがモナドチュートリアルの領域に足を踏み入れることです。いくつかの例外的な例は、リファレンスカウンターポインタを居間のテレビと比較したり、参照をレストランのテーブルと比較します。それらはすべて悪いわけではありません。川に渡すメッセージの並行性の比較のように、実際には本当に楽しいものがいくつかありますが、そのほとんどは現実世界の何かにコンセプトを関連づけるのが難しく、役に立たなくなってしまいます。幸いなことに、この本はGitHubにあり、プルリクエストを受け付けるので、いくつかの選択肢の代替案を送る予定です。

素晴らしい文書があるにもかかわらず、私はほとんどの人がまだRustを学ぶのに苦労すると予測しています。それはあなたが以前に見たことのないいくつかの概念をもたらします。私が知る限り、これはコンパイル時のメモリ管理を提供する最初のプログラミング言語です。(C++は間違いなく同じようなスマートポインタを持っていますが、それらのルールは実行時に強制されます。Rustは、オーナーシップとライフタイムのコンセプトをコンパイラと密接に統合しています。) TRPLはコンパイル時のメモリ管理のコンセプトを紹介するのはうまく行っていますが、実際にはほんの少しかじっただけだと感じています。その理由から、私はRustを学ぶ人に、メモリモデルの素晴らしい補足的なリソース、つまり「Learning Rust With Entirely Too Many Linked Lists」を指摘したいと思います。これは実践的なもので、TRPLと同じくらい手近なものです。この投稿は、一般的な概念を理解するのに問題がある場合にも役立ちます。

TRPLはコンパイル時のメモリ管理のコンセプトの取り入れることをうまくこなしていますが、実際にはやらなければならないことがまだまだあると感じています。その理由から、私はRustを学ぶ人に、メモリモデルの素晴らしい補足的なリソース、つまり「Learning Rust With Entirely Too Many Linked Lists」を指摘したいと思います。これは実践的なもので、TRPLと同じくらい取っ付きやすいものです。この投稿は、一般的な概念を理解するのに問題がある場合にも役立ちます。

それは私に別のポイントをもたらします。Rustがテーブルにもたらす機能は学ぶのが難しいかもしれませんが、それらを使用することを学ぶことは最後には報われます。コンパイル時メモリ管理は、あまり使い慣れていない方法でプログラムを設計する必要がありますが、手動のメモリ管理あるいは、ランタイムにガベージコレクションを任せるより間違いなく優れています。

例えば、Cのメモリモデルは手動で管理されます。ヒープ割り当てはmalloc(3)とcalloc(3)によって実行され、free(3)が呼び出されるまでこれらの割り当てが存在します。文字列を含むヒープ割り当てを行うための、この平凡なコードを取ってみましょう:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv) {
    char *buf;

    // 14バイトのヒープ割り当てを行う
    buf = calloc(14, 1);

    // calloc(3)がnullポインタを返す可能性がある
    if (buf == NULL) {
        return 1;
    }

    // 割り当てられたバッファを文字列で埋め、出力する
    strcpy(buf, "Hello, world!");
    puts(buf);

    // 終わったら、ヒープ割り当てを解放する
    // これは必ずしも関数の終わりにあるとは限らないが、通常はある
    free(buf);

    return 0;
}

このモデルは、あなたが作成した割り当てを追跡し続け、不要になった時に解放されることを保証する必要があります。私たちはfree(3)への呼び出しを簡単に忘れてしまいがちです。非常に簡単な例では、プロセスが終了し、オペレーティングシステムがヒープページを再利用するため、問題はありませんが、プログラムがその文字列を出力した後に動作し続けた場合、メモリリークが発生します。とにかく、Cの手動メモリ管理は、これがコンパイルするものを多かれ少なかれ予測できるほど十分に明確です。GCC 6.4.0は、amd64コードに続いて出ています:

              # 前置き
55             pushq %rbp
4889e5         movq %rsp, %rbp
4883ec20       subq $0x20, %rsp
897dec         movl %edi, -0x14(%rbp)
488975e0       movq %rsi, -0x20(%rbp)

              # calloc(14, 1), スタック上にポインタを格納する
be01000000     movl $1, %esi
bf0e000000     movl $0xe, %edi
e892feffff     callq sym.imp.calloc
488945f8       movq %rax, -8(%rbp)

              # nullポインタをチェック
48837df800     cmpq $0, -8(%rbp)
7507           jne 0x750
b801000000     movl $1, %eax
eb3b           jmp 0x78b

              # (最適化された)strcpyを呼び出す
488b45f8       movq -8(%rbp), %rax
48ba48656c6c.  movabsq $0x77202c6f6c6c6548, %rdx
488910         movq %rdx, 0(%rax)
c740086f726c.  movl $0x646c726f, 8(%rax)
66c7400c2100   movw $0x21, 0xc(%rax)

              # puts(buf)
488b45f8       movq -8(%rbp), %rax
4889c7         movq %rax, %rdi
e846feffff     callq sym.imp.puts

              # free(buf)
488b45f8       movq -8(%rbp), %rax
4889c7         movq %rax, %rdi
e82afeffff     callq sym.imp.free

              # 解体
b800000000     movl $0, %eax
c9             leave
c3             retq
0f1f00         nopl 0(%rax)

Rustに相当するものはよく似ていますが、見て分かるように、ヒープ割り当てを明示的に解放する必要はありません。

use std::io;
use std::io::Write;

fn main() {
    let buf = Box::new(b"Hello, world!\n");
    io::stdout().write(*buf);
}

rustc 1.25はこれを以下のamd64コードにコンパイルします:

              # 前置き
4883ec48       subq $0x48, %rsp

              # 'std::boxed::Box'スマートポインタで作られたヒープ割り当て
b808000000     movl $8, %eax
89c1           movl %eax, %ecx
4889cf         movq %rcx, %rdi
4889ce         movq %rcx, %rsi
e8caedffff     callq sym.alloc::heap::exchange_malloc::h42fa40019bea1ed3

              # 個々のバイトをボックスにコピーするのではなく、実際にバイト文字列への
              # 参照を格納することになる。
              # それにもかかわらず、これはヒープ割り当てをかなりうまく説明している筈
              # だと思う。私はこの例をいくらかシンプルにして、それをロールバックする。
488d0de3e705.  leaq str.Hello__world, %rcx
4889c6         movq %rax, %rsi
488908         movq %rcx, 0(%rax)
4889742410     movq %rsi, 0x10(%rsp)

              # stdoutへのハンドルを得る
e855590000     callq sym.std::io::stdio::stdout::h537f6f9874379378
4889442408     movq %rax, 8(%rsp)
488b442408     movq 8(%rsp), %rax
4889442430     movq %rax, 0x30(%rsp)

              # stdout.write(*buf);
488b4c2410     movq 0x10(%rsp), %rcx
488b11         movq 0(%rcx), %rdx
be0e000000     movl $0xe, %esi
89f1           movl %esi, %ecx
488d7c2418     leaq 0x18(%rsp), %rdi
488d742430     leaq 0x30(%rsp), %rsi
e8965a0000     callq sym._std::io::stdio::Stdout_as_std::io::Write_::write::h12094683b11bc5a8

              # 'write'によって返却された'std::io::Result'を解放
              # 悪いフォームと見なされるそれをチェックしなかったが、これは単なる例に過ぎない。
488d7c2418     leaq 0x18(%rsp), %rdi
e8fef4ffff     callq sym.core::ptr::drop_in_place::h72bdea260ebb17c9

              # stdoutハンドルを解放
488d7c2430     leaq 0x30(%rsp), %rdi
e8a6f4ffff     callq sym.core::ptr::drop_in_place::h55479d5b85e18c56

              # 最終的に我々が作ったヒープ割り当てを解放
488d7c2410     leaq 0x10(%rsp), %rdi
e8faf5ffff     callq sym.core::ptr::drop_in_place::ha5ac9a364139ad29

              # 解体
4883c448       addq $0x48, %rsp
c3             retq

stdoutとやりとりするためのハンドルを割り当てる必要がある以外に、rustcが出すアセンブリ言語は、GCCのものとほぼ同じことを行います。バッファを割り当て、いっぱいにしてから使い終わったら解放します。Rustは、このプロセスをより扱いやすい抽象化で装っているだけです。

私が本当に楽しめるようになったもう一つの特徴は、NULLポインターがなくなったことです。それらはHaskellの厳密な型システムに置き換えられました。上記のCの例では、glibcが十分なメモリを確保できない場合にcalloc(3)がNULLを返すことが分かりました。私たちは、それがNULLでないことを確認するチェックを入れるのを簡単に忘れてしまう可能性があります。その場合、セグメンテーション違反が発生します。このようなことを防ぐことは、人々が「メモリの安全性」と言うときに話していることです。セグメンテーション違反の場合、オペレーティングシステムは、私たちはすべきではない何か、例えばNULLポインタを逆参照をしているため、ジャンプしなければなりません。ヒープ割り当てを2回解放する、さらに悪いことに、バッファの範囲外に書き込むように、Cではできることはたくさんあります。Rustは、オペレーティングシステムに任せたり、緩和システムを悪用したりするよりも、むしろ何かばかげたことをする時に、コンパイラの介入することを目指しています。NULL可能な参照のにこれを行うためには、Rustは何か、あるいは何もないのどちらも表現することができる"Option”型(そして "Result”型)を提供します。標準ライブラリで広く使用されています。文字列中の部分文字列のインデックスを見つけるためのメソッドstd:string:Stringの'find'メソッドを考えてみましょう。文字列に部分文字列が存在する可能性があります。その場合、そのインデックスを返すだけですが、存在しない場合はどうなりますか? Cの場合、'-1'のようなばかげた値を返すかもしれませんが、RustではUsize値を返すか、何も返さないOption<usize>を返します。そして、コンパイラは、このことの意味を理解します。

fn main() {
    let to_search = String::from("I may contain foo.");
    let index = to_search.find("foo");
    println!("index - 5: {}", index - 5);
}

これはかなりばかげた例ですが、どうか我慢して下さい。これをコンパイルしようとすると、何も保証されていない変数を扱うため、rustcはエラーを出力します。

error[E0369]: binary operation `-` cannot be applied to type `std::option::Option<usize>`
 --> test.rs:4:31
   |
 4 |     println!("index - 5: {}", index - 5);
   |                               ^^^^^^^^^
   |
   = note: an implementation of `std::ops::Sub` might be missing for `std::option::Option<usize>`

これはOptionを検査して、何もないのではなく、何かであることを保証することで修正されます。これは代数的なデータ型なので、もしも’find’が何かを返すと、それを構造化してインデックスで処理できます。

fn main() {
    let to_search = String::from("I may contain foo.");
    if let Some(index) = to_search.find("foo") {
        println!("index - 5: {}", index - 5);
    }
}

“if let”は、私が他の言語にはないと思う構文構造なので、おそらく簡単な説明をするべきでしょう。ブロックが実行されるのは、'find'が'None'ではなく'Some'だった 'Option'のインスタンスを返した場合のみです。'Some'のインスタンスが返された場合、そのインデックスにはインデックスが含まれているので、それを構造化してその値を変数indexに設定することができます。

あなたは、この厳密性が不満を招くと思われるかもしれませんが、コンパイラは単に専門家でない人がそれらを理解できるだけのエラーを出し、問題のコードを修正するための提案をしばしば行います。上記は素晴らしい例ではありませんが、ここにより良い例があります:

fn tabulate_slice(slice: &[u8]) {
    for elem in slice.iter() {
        println!("{}", elem);
    }
}

fn main() {
    let vec = vec![1, 2, 3];
    tabulate_slice(vec);
}
error[E0308]: mismatched types
 --> test.rs:9:20
   |
 9 |     tabulate_slice(vec);
   |                    ^^^
   |                    |
   |                    expected &[u8], found struct `std::vec::Vec`
   |                    help: consider borrowing here: `&vec`

Rustには、コンパイルされた言語であるにもかかわらず、典型的な高水準のRubyやPythonと同じように感じる豊富な機能があります。そして、私が上で説明したものに限定されません - ここに私が本当に感心した他の機能のいくつかがあります:

条件文と式

let var = if true {
    1
} else {
    2
};

if/while/forの式部分に括弧はない

私はあなたがすでにそれを十分に見ていると思います。

無限ループの動作

loop {
    break;
}

未使用の変数/パラメータの動作

for _ in 0..5 {
    println!("I'm printed 5 times!");
}

範囲表記法、型推論、イテレータ

もう一度、あなたはすでにこれを見てきました。

タプル、デストラクチャリング、matchとif let式を使ったパターンマッチング

match to_search.find("foo") {
    Some(index) => println!("Foo at {}", index),
    None => println!("No foo :("),
}

// Or, more idiomatically:

if let Some(index) = to_search.find("foo") {
    println!("Foo at {}", index);
} else {
    println!("No foo :(");
}

自動化されたテストはビルドシステムに統合されている

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}

これは、cargo testの呼び出し時に実行されます。

安全でないコードの分離

安全でないコードを扱うことの意味が適切に含まれていることを保証するための一連のルールがありますが、その主な目的は、安全でないコードがスコープシステムによって分離されることです。ほとんど、安全でないコードで作業することができて、私はうれしいです。

fn main() {
    unsafe {
        asm!("INT3");
    }
}

これは言語設計の面に関する私の意見ですが、コミュニティとエコシステムも同様に重要です。Rustコミュニティでの私の経験は限られていますが、コミュニティの人々は友好的で合理的です。私はほとんど見たことはありません。私はrust-imapにいくつかの問題を提出し、迅速で有益な回答を受けました。また、私は自信を持って、Rustのエコシステムと一緒に仕事をするのは喜ばしいと言うことができます。明らかに他の言語のエコシステムほど成熟していませんが、プロジェクトに「crate」依存関係を追加することは、「Cargo.toml」に行を追加するのと同じくらい簡単です。 自分で作成したcrateのコードとドキュメントを公開することも同様に簡単です。私は、WildMIDIとやり取りするためのライブラリを一緒に投げました。そして、私からの介入なしにdocs.rsページがポップアップしました。簡単です。

これらのcratesを実行可能ファイルにリンクするプロセスは、比較的原始的であり、その点でいくつかの不満があります。これは主に静的なリンクです。その議論は「あなたのコンピュータ上のいくつかのライブラリの古いコピーを取得します」というようなものです。しかし、代わりにダイナミックリンクのメリットは、この記事で取り上げたくない議論です。今、私はRustのバイナリサイズに無頓着で、ダイナミックリンクに関するいくつかの不満があるかもしれませんが、 「現在の実装ではオプションではありませんし、それは欠陥です」として、放ってあります。

全体的に、私はRustにとても満足しています。Cの可能な代替として、まだ「そこに」存在していないかもしれませんが、有望であり、時間とともに、GNU/Linuxエコシステムにうまく収まると感じています。


1: 前のバージョンのこの記事では、コンパイラによって生成されたアセンブリ言語すべてが含まれていましたが、このリビジョンでは、私が実際に示しているコンセプトを損なうと思ったので、Rustのエラー/パニックコードを削除することを選択しました。


Hacker News

どのようにAppleは3D Touchを修正できるか?

Mediumより。確かに!

はっきりした点から始めますね。3D Touchは壊れています! ユーザー体験はちっとも素晴らしくありません。Appleは、3D Touchと新しい関連する相互作用のPeekとPopを2014年に導入しました。最初の導入から約4年が経過していますが、みんな3D Touchを知らないか、使用していません。なぜでしょう? ハイテクに精通したユーザーでも、3D Touchのボタンが分かりません。言うまでもなく通常のユーザーなら尚更です。

すべてのリンクを通常のテキストと同じ色とスタイルにすることにしたらどうなります? みんなは何をクリックすればいいのか分からなくなるでしょう? では、なぜ3D Touchは違いがないですか? 私たちは、他の何よりも先に作動可能性を決定するために視覚に頼っています。3D Touch可能なボタンとそうでないボタンを区別できないなら、どうやってボタンを押すことができるでしょう? このスクリーンショットを見て、どのボタンが3D Touchできるかを見て下さい。

これらのボタンはすべてが3D Touchできません。どうしたら、どちらがどちらか分かるでしょう? 唯一の可能なのは、3D Touchを試してそれを覚えていることです。更に悪いことに、3D Touchはもはやギミックではありません。「個人用ホットスポット」あるいは「AirDrop」トグルにアクセスするには、「4ボタンコントロール」を強く押さなければならないのです。

それでは、問題が何であるかを理解したので、私の解決策を披露します。何年も前にウェブ上でリンクテキストを使ったように、3D Touch可能なボタンを視覚的に区別する必要があります。この同じ画面を見て、どのタッチが3D Touchに対応するかを知ることができるかを見て下さい。

私の解決策は3D Touchできるものの右下に線を追加することです。Force Decorators(Force Touchを参照)と呼ばせて下さい。

3D Touchは、主流となる最も明白なものを欠いています。それは、視覚の合図です。私はこれが答えだと思います。

あなたはどう思いますか?

ジョン・グルーバーは次のように書いている

これに関して、私も全面的に合意します。3D Touchできるものを視覚的に示さないことで当惑させています。

トランプは、金正恩に直通番号を教えたのか?

WIREDより。ホワイトハウスは機能しているのか?

ドナルド・トランプ大統領がシンガポールで独裁者の金正恩と会った後、大統領は二人の指導者の関係の強さを強く宣伝した。彼は金曜日にホワイトハウスで記者団に次のように語った。「私は彼にすぐに電話できる。彼に直通の番号を教えた。彼は何か問題があれば私に電話することができる。私たちは通信手段を持っている。」

米国と北朝鮮は非常に複雑で厄介な外交関係にある。トランプは核攻撃でよく考えませず脅しはしなかった。そして、両国間の親密さの言動は、それを助長した。しかし、セキュリティ専門家はトランプ氏の主張を憂慮し、大統領が実際に金正恩に個人の電話番号を渡したなら、その過程で重大な国家の安全保障上のリスクを生み出すであろうと指摘した。

携帯電話ネットワークの攻撃を研究しているドイツのSecurity Research Labsのチーフ・サイエンティストKarsten Nohl氏は、「おっしゃる通り、それが問題なのです。」と言う。ハッカーは、携帯電話ネットワークの相互運用性の欠陥を悪用して、重要人物の電話を傍受し、テキストメッセージを傍受し、その自分つの位置を追跡することができる。もし、トランプが用心深くなければ、金正恩に米国政府のトップを狙うための簡単で発展性のあるツールを与えたかも知れない。ホワイトハウスにコメントを求めたが、返事はなかった。

「彼が分別があり、そのアドバイスを聞いていれば、彼の電話のSIMカードから実際に離れた電話番号に対して、彼はおそらく自分の電話番号に転送するランダムな電話番号を教えただろう。」とNohl氏は言う。「米国の大統領として、彼はおそらく彼の電話につながる1000の電話番号のリストを持つことができるだろう。」

それが、物事はうまくいくきっかけである。 しかし、トランプは、ホワイトハウス内でサイバー衛生を維持するための実績がありません。彼は、初めて大統領職を始めたときに、個人のAndroid携帯を持って来て、検査や交換するためのホワイトハウスのIT部門に対し、政府発行のスマートフォンを変えることに抵抗を示した

「誰もがトランプのスマートフォンにマルウェアを仕掛けようとしていても驚きはしません。」とNSAの元研究者で現在ペネトレーション・テスト会社のImmunityを経営するDave Aitelは言う。

さらに、4月下旬のCNNの報道によると、トランプは最近、共和党議員との会話を含む、個人的なスマートフォンの使用を増やし、一部はホワイトハウスの交換台を迂回しようとしている。

そんなこんなで、米国大統領が安全でない可能性のあるスマートフォンを使用している状況、少なくともハッキングが大好きな敵対的な外国人の指導者にそのスマートフォンの番号を渡している可能性がある。「もちろん、これは完璧なシナリオではありません。」とNohl氏は言う。

北朝鮮の情報局がマルウェアを通じてトランプの携帯電話をまだ追跡していないなら、直通の電話番号がそれらの手段を与える可能性がある。SS7攻撃と呼ばれる既知の携帯電話ネットワーク攻撃の主な種類は、位置データは言うまでもなく電話やテキストに比較的簡単にアクセスできる機会をハッカーに与える。FCCは脆弱性の広範な修正に取り組んでおり、その脅威は決して仮説上のものではない。国土安全保障省は、ハッカーたちが米国の携帯電話ユーザーに対してSS7攻撃を行った可能性があることを5月末に認めた

SS7攻撃には、さまざまな携帯電話ネットワーク間の接続のコントロールが含まれており、通信事業者はこれらの接続の記録を保持しているため、特にトランプと同様に高い価値を持った番号に対応できる。これは、ハッカーが攻撃を戦略的に1〜2回の攻撃にしか利用できないことを意味するわけではない。Nohl氏は、トランプが海外へ旅行中にデバイスのローミングを許可しているなら、彼がスマートフォンを持ち出して外国のキャリアを使った際に、SS7攻撃の兆候を監視するのはかなり難しいと指摘する。

北朝鮮は、金融やインテリジェンスのために世界中のシステムをハックしてコントロールする敵対者であることを証明した - それは2014年のソニーへの破壊的なハッキングと昨年のWannaCryのランサムウェアのメルトダウンの両方に責任があり、SS7のハッキングも例外ではない。しかも、グローバル・コミュニティは、北朝鮮のハッカーが特に厚かましくなってから、彼らを扱うのに苦労している。もし、米国がトランプの携帯電話で北朝鮮のスパイ行為を捕まえたとしても、適切な抑止反応を選択することは難しいだろう。

ホワイトハウスにはもちろん安全な通話のための装置がある。願わくはトランプが金正恩との深夜のおしゃべりがセキュアライン上で起こり、友情と楽しみに集中できるよう望む。しかし、トランプが引きこもりがちな独裁者に彼が主張するようにアクセスを与えたなら、その無謀な行為は問題になる可能性がある。

6/14/2018

研究者たちは、IQが1970年代から落ちていることを発見

Medical Pressより。魚を食べよう!

ノルウェーのRagnar Frisch Centre for Economic Researchの研究者たちは、IQテストのスコアが過去数十年間で徐々に低下していることを発見した。Bernt BratsbergとOle Rogebergは、Proceedings of the National Academy of Sciencesに掲載された論文で、彼らの研究と発見した結果について説明しています。彼らはまた、発見にいくつかの可能な説明を提供している。

以前の研究では、知性指数で測定されるように、前世紀初めよりも人々が賢く成長したことが示されている。これはフリン効果と呼ばれる傾向である。良い栄養、健康管理、教育など人間の精神の明白な明るさを説明するために、さまざまな理論が提案されている。しかし、今、ノルウェーの研究者によると、その傾向は終わった。賢くなるのではなく、人は愚かになってきている。

チームによる調査は、1970年から2009年の間にノルウェーの徴兵制(義務的な軍務)に入る青少年のIQテスト結果を分析することから成っている。全部で730,000件のテスト結果で説明された。このデータを研究するにあたり、研究者らは、1世代あたり平均7ポイントのスコア低下が見られ、テスト結果の明確な逆転は約70年前に遡る。

しかし、すべてが悪いニュースばかりではない。研究者らはまた、家族集団の間にいくつかの違いがあることを見出し、その減少のいくつかは環境要因に起因する可能性があることを示唆している。しかし、彼らはまた、生活様式の変化が、教育制度や子供の読書量の減少、そしてビデオゲームで遊ぶ時間の増加などで、減少の一部を説明することも示唆している。悲しいことに、他の研究者も同様の結果を見出した。英国のチームは、第2次世界大戦のほぼ終わり頃からIQスコアの結果が10年ごとに2.5ポイントから4.3ポイント低下することを最近発見した。そして、今年12月、米国の別のグループは、魚をたくさん食べて育った子どもたちのIQは高くなる傾向があることを発見した。また、良い睡眠をとることも、成人の知能レベルに関わるもう一つの要因である。とりわけ、現代の多くの国の子供たちは魚をほとんど食べていない。

Hacker News

ビデオ・コーディングの終焉?

Slashdotより

匿名の読者が伝える:

Netflixのエンジニアリングチームは、業界がビデオコーディングをどのように扱っているかを調査し、それらの方法論の違い、そして新しい人たちが直面する課題と洞察力に富んだ記事を掲載している。私たちがどこに向かうかをまとめた抜粋:

MPEG-2、VC1、H.263、H.264/AVC、H.265/HEVC、VP9、AV1 -- これらすべての規格は、ブロックベースのハイブリッド・ビデオコーディング構造の上に構築された。この従来のモデルから向きを変えようとする試みは成功していない。いくつかの場合(例えば、分散ビデオコーディング)、普及したユースケースにとって技術が実用的でなかったためである。しかし、ほとんどの場合、成熟を可能にさせるのに十分なリソースが新技術に投資されていない可能性が高い。

残念ながら、新しい技術は最先端のコーデックに対して評価され、コーディング・ツールは何十年もの投資から精緻化されている。それでは、新しい技術を「額面通りではない」と落としてしまうのは簡単である。新しいツールを成熟させないことで、私たちは、より優れた効果的な技術を見逃してしまうか? 私たちが単純に舗装された道に留まり、同じエンコーディングツールを反復するだけなら、どのくらいの冗長ビットを捻り出すことができるだろうか?

Hacker News