4K/8K無料放送は「録画禁止」に？ NexTV-F発表の規定が大きな波紋 - Phile-web
4K/8K放送が今後本格化することをご存じの方は多いだろう。リオ五輪が開かれる今年2016年にはBSを使った4K/8K放送が開始。2018年にはBS/110度CSで実用放送を開始するロードマップが総務省から公表されている。 その次世代放送の早期実現のため、技術仕様の検討や検証、実用化のための試行や開発を行うのが、一般社団法人 次世代放送推進フォーラム（NexTV-F）。そのNexTV-Fが昨年末、12月25日に公開した技術資料が波紋を呼んでいる。 話題となっているのは「高度広帯域衛星デジタル放送運用規定」という資料で、NexTV-FのサイトにPDFで公開されている。 この資料は、前述の4K/8Kロードマップに示されたBS/CS放送に関して、放送の運用ルールや受信機の仕様などを定めたものだ。全部で1,137ページもある資料なので、一般の方がすべてに目を通すのは難しい。 ■無料放送も「録画禁止
Fabricでサーバー管理をDRYにしよう
7. $ ssh <web/ap server> $ sudo yum update ... $ exit $ ssh <db server> $ sudo yum update • ssh serverA ... $ exit • sudo yum update $ ssh <scm server> $ sudo yum update ... $ exit • お茶を飲んで待つ $ ssh <pm server> $ sudo yum update ... • exit $ exit $ ssh <ci server> • 以下5回繰り返し $ sudo yum update ... $ exit ... 8. $ scp foo.pub <web/ap server>:. $ ssh <web/ap server> $ sudo mv foo.pub /etc/ssh/keys/ $
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Treasure Dataプラットフォームの管理画面を作る - mikedaの日記
前置きです。 IT界隈の人とHadoopの話をするとこういうギャップを感じます。 Hadoop使ってみたいところ >>> 実際に使っているところ みんな どう使って、どう収益に結びつけるか 設計、サーバ購入、構築、運用などなどの技術的コスト とか考え始めて止まっちゃいます。たぶん考えるよりTreasureData使ってみたほうが早いです。 そんなの使ってみないとよくわからんからです。 Hadoopガッツリ使ってました！なんて人そうそういないのです。 というわけで問答無用で構築して（そのあたりは前記事）、簡単な管理画面を作ってサービスチームに公開しています。 無料のトライアル版でもけっこう使えますし、気合入れればきっと数日で構築出来ます。 以下はその管理画面についてです。 ポイントはとにかく、『テキトウに作ってさっさと使ってみる』です。 （ちゃんとしたものはそのうちだれかが作ってくれるでしょ
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
Munin 2.0(stable)登場☆新機能はとってもうれしいなって（第1回） | Pocketstudio.jp log3
◆ Munin 2.0 (stable) が遂にリリース！ “リソース推移のモニタリング” ただ、それだけに特化した、監視ツール Munin 。設計思想は、シンプルかつパワフルに。 Munin は、サーバの「リソース推移」を見るためのツール。簡単なセットアップで、ブラウザを通して、サーバの中の様々な状況を、グラフとして見ることができる。例えば、CPUの使用状況や、メモリ、ディスク等々。障害通知の機能は最低限。あくまでリソース推移を簡単に見ることに特化。 単純に数値を見るだけなら、sysstat(sar)や各種のログを見る事でも目的は達成できる。しかし、障害発生の現場においては、複数のサーバから、複数の指標を取得＆比較し、迅速な対応と判断が求められる。そこでは、ログの追跡は時間や人手がかかる。一方、グラフで障害発生ポイントを、視覚的に、迅速に把握できるようになる事は、原因切り分け時間の短縮
Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用
Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用 急速に人気が急上昇するWebサービスでは、どのようにスケールするアーキテクチャを構築し運用していくのかはサービスの成否を分けるほど重要です。Pinterestのように急成長してきたサービスのソフトウェア構成やリソース構成はどうなっているのでしょうか、Web上でいくつか情報が公開されているのでまとめてみました。 Pythonで開発し、Amazonクラウドで運用 1年ほど前なので少し古い情報ではあるのですが、Q&AサイトのQuoraにPinterestのco-founder Paul Sciarra氏が書き込んだソフトウェア構成の説明があります。 PinterestはPythonで開発されており、MemcachedやNginxなど高速なレスポンスに配慮した構成になっている様子がうかがえま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://dl.dropbox.com/u/224433/fluentd_casual_1/index.html