タグ

2015年1月15日のブックマーク (8件)

  • Google Sites: Sign-in

    Not your computer? Use a private browsing window to sign in. Learn more

  • BLOGOS サービス終了のお知らせ

    平素は株式会社ライブドアのサービスを ご利用いただきありがとうございます。 提言型ニュースサイト「BLOGOS」は、 2022年5月31日をもちまして、 サービスの提供を終了いたしました。 一部のオリジナル記事につきましては、 livedoorニュース内の 「BLOGOSの記事一覧」からご覧いただけます。 長らくご利用いただき、ありがとうございました。 サービス終了に関するお問い合わせは、 下記までお願いいたします。 お問い合わせ ※カテゴリは、「その他のお問い合わせ」を選択して下さい。

    BLOGOS サービス終了のお知らせ
  • 第17回 LXCの構築・活用 [4] ― 一般ユーザによるLXCコンテナの利用 | gihyo.jp

    root権限の場合のパスは各ディストリビューションのコンパイル時のオプションに依存します。一方で一般ユーザの場合は、システム設定ファイルでデフォルト値を変更しない限りは、どのディストリビューションでも図のようになるはずです。 テンプレートファイルに関しては、root権限用、一般ユーザ用という区別はなく同じテンプレートを使用しますので、一般ユーザ用のテンプレート置き場は存在しません。 一般ユーザでコンテナを利用する場合のLXCの設定 ネットワークインターフェースの設定 第16回で説明したように、一般ユーザでコンテナを扱うためにユーザ名前空間を作成すると、名前空間内でネットワークインターフェースを作成するといった特権が必要な操作は名前空間内のrootユーザで行えます。 現時点では一般ユーザ権限で起動したコンテナと外部の通信をする際は第6回で説明したvethインターフェースを使う必要があります。

    第17回 LXCの構築・活用 [4] ― 一般ユーザによるLXCコンテナの利用 | gihyo.jp
  • [メモ] TCP上(もしくはHTTP)にリトライ可能なアプリケーションプロトコルを実現する方法

    HTTP/1.1の持続的接続においては、サーバがリクエストを受け取ったあとに異常終了したのか、リクエストを受け取らずに接続を閉じたのか判別することができない。このため、べき等性の保証がないアプリケーションにおいて、リトライを行うべきか否か自動的に判断できなくなる場合がしばしば発生する注。 リトライ可能か否か(ピアがメッセージの処理を開始した否か)を判別するには、より細かな情報交換を行う別種のプロトコルを採用しても良いが、複雑なプトロコルはパフォーマンスに悪影響を及ぼす可能性が高いので避けたいところである。 というわけで、以下題。 pipeliningを行わないHTTP/1.1のような単純なリクエスト/レスポンス型プロトコルをそのままに、アプリケーションレイヤへのリクエスト到達可否を判定する手軽な方法としては、SO_LINGERを用いる方法がある。具体的には、以下のような形式でサーバを実装

  • CRIT - CRIU

    defiant
    defiant 2015/01/15
  • OpenStackはどのようにテストしているのか?

    OpenStackはどのようにテストしているのか?:OpenStack最前線~ユーザ会メンバーが持ち回りで語る「OpenStackのリアル」~(4) 特集記事と同時に、日OpenStackユーザ会メンバーが超ホットでディープな最新情報をコラムスタイルで紹介していく@IT特集「OpenStack超入門」。コラム第4回は「Tempest」コアデベロッパーの井川征幸氏がOpenStackの品質を担保する「テストの仕組み」を紹介する。 皆さま初めまして。日OpenStackユーザ会の井川と申します。OpenStackの開発コミュニティで「Tempest」のコアデベロッパーとして活動しています。 TempestはOpenStackにおける「テスト」を担当するプロジェクトです。「Nova」の仮想マシンや、「Neutron」の仮想ネットワークのように直接ユーザーが利用する機能と違い、Tempestを

    OpenStackはどのようにテストしているのか?
  • 開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD

    “なぜ納期を守れなかったのだろうか?” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は当に開発者の仕事が遅いせいでしょうか? Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと(S、M、L、XL)、また種類ごと(ストーリー、テスト、バグ)に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目:開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目:変動があるのは、ほとんどがチケットが開始される前(SomedayからBacklogまで)の段階です。これは、関係者が仕様を理解して作業の優先順位

    開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD
  • GitHub - adityakali/linux at cgroupns_v3