タグ

2016年12月27日のブックマーク (8件)

  • 録画サーバ構築の前準備(Ubuntu・Debian編)、Chinachu・epgrec UNA対応 | 自分に負けないラボラトリー

    この記事で紹介するのは、Ubuntu・Debian向けの録画サーバ構築のための前準備です。Chinachuとepgrec UNAインストール前の共通作業をまとめたものになります。OS環境、サービス設定(NTP、Samba)、開発環境構築、録画機能設定(arib25ライブラリ、recpt1等)を順を追って説明します。 記事が対象とするOSはUbuntu 14.04LTS以降(2018年8月時点の長期サポート版は18.04LTS)、Debian 8 Jessie以降(2018年8月時点の最新版はDebian 9 stretch)です。 記事で取り扱うTVチューナーボードはPT3 Rev.Aです。 なお、実行ユーザーを区別するため、シェルのコマンド表記は以下の様にしています。 [user@centos]$ 一般ユーザーとして実行 [root@centos]# rootとして実行 スポンサーリ

    録画サーバ構築の前準備(Ubuntu・Debian編)、Chinachu・epgrec UNA対応 | 自分に負けないラボラトリー
  • これから録画サーバを作りたい人向けの省電力対応おすすめハードウェア構成 | 自分に負けないラボラトリー

    録画サーバ向けのおすすめのハードウェア構成を紹介します。24時間稼働を前提としているので、省電力対応で消費電力を低めに抑えることを前提としました。 おすすめパーツに関しては「これから録画サーバを作りたい人向けのおすすめパーツ」の記事をご覧ください。 2016年6月19日追記)記事の情報も古くなってしまったため、「省電力PC向けおすすめハードウェア構成」と「今から始める録画サーバの運用方法とおすすめパーツ」の2つの記事にまとめなおしました。どちらの記事も情報が古くならないように随時更新中です。 スポンサーリンク CPUPCの消費電力の関係 ハードウェア構成の説明に入る前にPCの消費電力に関して説明します。 最終的にPCを組み立てた時の消費電力は搭載されているCPUと相関関係にあります。そこで、省電力なCPUを中心に完成品のPCの消費電力を調べてみました。消費電力の少ないほうから順に並べる

    これから録画サーバを作りたい人向けの省電力対応おすすめハードウェア構成 | 自分に負けないラボラトリー
  • HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに

    By Bill Dickinson オンラインストレージサービスBackblazeが、自社のサービスに使用してきた200種類、合計約3万5000台の運用データから算出した、「HDDの信頼性データ」の2014年9月最新版を発表しました。以前からメーカーやモデルによって壊れやすさの偏りは明らかでしたが、その傾向はあまり改善されていないようです。 Backblaze Blog » Hard Drive Reliability Update – Sep 2014 https://www.backblaze.com/blog/hard-drive-reliability-update-september-2014/ どこのメーカーのHDDが信頼性が高いのかが一発で分かるグラフがこれ。灰色の棒グラフは2013年通年での故障・エラー発生率、色の付いた棒グラフは2014年6月までに生じたエラー発生率を示し

    HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに
  • Goについて思うこと 2016

    あんまりこういう内容のポエム的なものは広まってほしくないなあ・・と思うのでこっちにひっそり書くことにする。 今年は僕にとってはGoの存在がとても大きい年だった。 5年前、僕が書くのはWebアプリケーションが中心で、PHPをメインで触っていた。それが気がつけばエンジニアリングのレイヤが広がったなあという所感があって、ここ最近Goがそれを加速してくれた。第二の言語としてのGoはとても良くできていて、小回りが聴くし、ミドルウェアをちょろっと書くにも心地よい。やっぱり最近の言語ならではの良さがある。たとえば、 * テストが標準ライブラリに組み込まれている * net/httpがとても良くできている。フレームワークを必要としない場面も多い。 * concurrencyを堅牢に扱える(うまい言葉が見当たらない) * そしてそれなりに速い というのがあげられる。特にgo toolの充実はすごい。Race

  • 技術採択のときにやるべきこと - まるまるこふこふ

    初めに 新規プロジェクト/既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客=ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという

    技術採択のときにやるべきこと - まるまるこふこふ
  • Azure Backup で VMware 仮想マシンのクラウドバックアップ構築手順 (1) - 仮想化でプリセールスしてるSEの一日

    今回の記事は「vExperts Advent Calendar 2016」と連動しています。 せっかくクリスマスイブを陣取りましたので、私の得意とする二分野「Microsoft × VMware」の最新技術について書きたいと思います。 この2社、以前は真正面からのライバルでしたが、最近は少しベクトルがズレてきているのはご承知のとおり。Microsoft は自社の Azure クラウドサービスを重視していますし、VMware はオンプレ重視、クラウドについてはマルチクラウド戦略です。ここで、両社がコンフリクトしない 1 つのソリューションがあります。 「クラウドバックアップ」 です。 2016 年 11 月より Azure Backup Server に対応 正確というと、この VMware to Azure Backup は 今夏から実現できていました。 ではなぜ先月からかというと、Sys

    Azure Backup で VMware 仮想マシンのクラウドバックアップ構築手順 (1) - 仮想化でプリセールスしてるSEの一日
  • Make an IT infrastructure engineer great again

    今冬人気のドラマでこんなセリフがありました。 この前か後か忘れましたが「インフラエンジニアはいないと困るでしょう」というセリフもあったような気がします。たしかリストラの話の流れだったと思います。 この部分について、自分の思うところを書いてみようと思います。 確かにインフラエンジニアはいないと困るのですが、しかし「今までみたいなインフラエンジニア」はそのうちいなくても誰も困らなくなる、ってのが実際のところだと思います。 インフラエンジニアの置かれた状況は業種業態によって異なりますが、多くの環境ではインフラエンジニアの価値は下がり続けていると私は考えているからです。 ITインフラの優劣がビジネスに直結・大きな影響を与える通信キャリアや大規模なWEBやコンテンツサービスプロバイダーなどの例外も存在していますが、大多数を占める旧態然としたいわゆる企業の情シスに所属するインフラエンジニアSIer

    Make an IT infrastructure engineer great again
  • インフラ野郎Azureチーム Night

    True to its name, Ananta provides cloud scale load balancing. It addresses limitations of traditional load balancers by supporting 100Gbps per VIP, rapid failover of thousands of VIPs, and tenant isolation to prevent overloads in one tenant from impacting others. Ananta implements load balancing across three tiers - packet-level in routers, connection-level in servers, and stateful NAT - to achiev

    インフラ野郎Azureチーム Night