サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
umezawa.dyndns.info
家鯖の HDD を交換して大きくなったわけですが、作業をさぼっていて上に載ってるファイルシステムはそのままなので空き容量は特に増えてませんでした。ここらでえいやっとファイルシステムを拡張します。RAID パーティション(md デバイス)は既に拡張してあるので、resize2fs するだけです。Linux 2.6 以降なら ext2/ext3 はオンラインで(= マウントしたまま)ファイルシステムを拡張できます(他にもオンラインで拡張できるファイルシステムはいっぱいあるけど特に調べてない)。マシンを止めたくないので、もちろんオンラインで拡張します。 [root@nyx umezawa]# resize2fs /dev/md1 resize2fs 1.39 (29-May-2006) Filesystem at /dev/md1 is mounted on /; on-line resizin
いやドキュメントとか読めばちゃんと書いてあるんですが。 check_ntp_peer チェック対象ホストと、チェック対象ホストが参照している NTP サーバとの時間のずれを監視する。NTP 的なジッタや stratum も監視できる。普通はこっちを使えばいいはずである。 check_ntp_time チェック対象ホストと、チェック元ホスト(check_ntp_time を実行するホスト)との時間のずれを監視する。そのため、チェック元ホストの時計が正確であることが必要である。チェック対象ホストの時刻を取得する方法が NTP だというだけであって、それ以外の点は check_time (こちらは time プロトコルを使う)と同じである。 check_ntp (deprecated:非推奨) チェック対象ホストと、チェック元ホストとの時間のずれを監視する(これは check_ntp_time
表を見ると分かる通り、ほぼ SOCK_STREAM と同じです。「SOCK_STREAM のデータグラム版」と考えておくのがいいでしょう。 AF_LOCAL (AF_UNIX) での実装 仕様は上のとおりなのですが、実装となるといろいろと細かい話が出てきます。(なお、ここでは AF_LOCAL の話だけします) 多くの POSIX 実装において、(AF_LOCAL では)SOCK_DGRAM は順序性も信頼性も持つ。というか、そうでない実装は見たことがない。つまり、上の表における SOCK_SEQPACKET と SOCK_DGRAM との差異はコネクション指向かどうかという点だけになる。 SOCK_SEQPACKET は実装されていない環境があり、古めの OS だと使えないことがある。NetBSD なんかは現時点の stable である 5.0 ですら使えず、6.0-beta でようやく
x86/x64 最適化勉強会 #6 で聞いてきましたが、AVX-512 なるものがアナウンスされてました。名前から予想される通り、SIMD レジスタが 512bit になります。SIMD レジスタが 512bit というと Xeon Phi は最初からそうなっているのですが、これが普通の Xeon に降りてくるイメージです。 AVX が「単なる legacy SSE の 256bit 版」ではないのと同様、AVX-512 も「単なる AVX の 512bit 版」ではありません。 SIMD レジスタが zmm という名前で 512bit になる。下位 256bit は ymm としてアクセスできる(xmm に対する ymm と同じ) 64bit モードの場合、SIMD レジスタが 32本使える。これは、zmm だけでなく ymm や xmm でも同様である。32bit モードでは8本のまま
Linux Kernel 3.9 には SO_REUSEPORT が追加されているそうです。SO_REUSEPORT でググると日本語のページの中で一番上に出てくる当blog(2013-06-02現在)としては調査しないわけにはいきません :-) Linux の SO_REUSEPORT は「TCP ソケットを完全重複 bind し、受け付けたコネクションをそれぞれのソケットに適当に割り振る」という機能のようです。これは、BSD の SO_REUSEPORT より機能が「強い」ということです(参考)。SO_REUSEADDR の時もそうですが、同じ名前で違う機能にするのやめてくれないかなぁ… 実験 SO_REUSEPORT が追加されたのは3月10日ごろのようなのですが、既に3か月たっていて Fedora 18 が Kernel 3.9 ベースになっており、試すためにソースコードからビルド
が、わたくしかなりピキピキしております。 付与されない経緯を書いた後、クリ奨担当の中の人(ホンモノであることは koizuka さんから聞いたので間違いない)から Twitter で連絡があって(実際には前後しているのですがまあそれはそれ)、以下のことを聞きました。 見送りになったのは「本人かどうかの判断が付きかねた」から。 異議申し立ては届いていない。 ん? 前者は、当時は静画の説明文にダウンロード先とか書いてなかったからだと思われるのですが、アカウントのプロフィール見たらblogのURLは書いてあるんだしその辺見てくれよ思うんですが、まあこっちはいい。こっちは。 後者は…んなアホな。ちゃんと送信ボタン押したぞ。なのでもちろん信用していませんが。 で、さらにやり合い(こう書くと喧嘩腰のようだけどやりとり自体はそういうわけではない)、再度異議申し立てをするよう言われたのでそうしました(今度
Ut Video Codec Suite にニコニコ動画のクリエイター奨励スコアが付与されない理由について教えて、って話が連続してきたので、せっかくだからまとめておきます。 まず、2011年12月13日からクリエイター奨励プログラムが始まりました。これは面白そうだ、ということで、サクッとインストーラのスクリーンショットを取ってニコニコ静画に投稿し、クリエイター奨励プログラムに登録しました。このときの静画 ID は im1642183 なのですが、後述の理由により削除してあります。 子作品が増えていくのをニヤニヤしながら眺めていたのですが、2012年03月24日に、「クリエイター奨励スコア付与見送りのお知らせ」というタイトルのメールが ニコニ・コモンズ事務局 から届きました。どう見ても定型メールなので貼っておきます。(今気づいたんですけどメールに誤植がありますね…) いつもニコニ・コモンズを
Q77 Express チップセット搭載マザーボードである DQ77MK に Ivy Bridge な Core i5-3570T を載せて VMware ESXi 5.1 を動かして VT-d を活用しようとした過程で得た情報のメモ VT-d を利用するには CPU とチップセットの両方が対応していないといけないことになっている。チップセットにぶら下がっているデバイスだけを DirectPath I/O の対象にする場合でも CPU の対応が必要だというのは良くわからないが、ともかくそういうものらしい。 デスクトップ向け Intel 7 シリーズチップセットで VT-d をサポートしているのは Q77 だけ。X79 もサポートしているが、これがデスクトップ向けと呼べるかというと微妙なところ。ノート向けだと QM77 と QS77 の2つ。正確には 7 シリーズではないが、サーバ向けチップ
POSIX 環境で非同期的なタイマを使うには setitimer() を使いますが、これだとタイマが 1 個しか使えません。(正確には SIGALRM, SIGVALRM, SIGPROF という性質の違うタイマをそれぞれ 1 個ずつ) さすがにこれでは厳しいということで、POSIX.1b には timer_create() という関数が定義されていて、これだと好きなだけタイマを作ることができます。さらに、setitimer() と違い、タイマごとに好きなシグナルを発生させることができますし、シグナルを発生させる代わりにスレッドを起動して通知関数を呼び出させることもできます。 #include <inttypes.h> #include <pthread.h> #include <signal.h> #include <stdint.h> #include <stdio.h> #inclu
機能追加 QuickTime for Mac 用コンポーネントを追加した。RGB24/ARGB32 へのデコードのみ。とても遅い。 その他 入出力フォーマットのチェックがより正確になった(はず)。 readme 日本語 英語 / バイナリ Windows x86 (msi) Windows x64 (msi) Mac OS X (zip) / ソース ようやく Mac 版ができました。本バージョンの Mac 版には実装と検証の進捗の関係上、以下の制限があります。(Windows 版には特に制限はありません) デコードしかできない。 RGB (k24RGBPixelFormat) と ARGB (k32ARGBPixelFormat) での出力しかできない。 とても遅い。とにかく遅い。フル C++ 実装でシングルスレッドの上、かなり余計な処理をしているはず。 インストーラがない。/Libra
最初にことわっておくと、Linux には SO_REUSEPORT はない(追記: Kernel 3.9 で追加された)。Windows (Winsock) にもないし、Linux に近い環境を構成する Cygwin にもない。(Solaris はどうだったかな…) 今現在簡単に入手できる OS のうち SO_REUSEPORT があるのは、大まかに BSD に分類される OS、つまり {Free,Open,Net}BSD の系統と Mac OS X だけである。 BSD の場合 BSD においては、AF_INET / AF_INET6 なソケットに対する SO_REUSEADDR と SO_REUSEPORT は以下の意味になる。(AF_UNIX などその他のアドレスファミリに関しては割愛) SO_REUSEADDR connected socket が残っている状態で、そのソケットの
最大文字数:動画タイトルは 99 バイトまで、動画説明文は 999 バイトまで。UTF-8 でカウント。(2008/09/02 現在) 省略制限:動画タイトルは 24 カウントまで、動画説明文は 48 カウントまで。カウント規則は一部不明。(2008/10/05 現在) 入力エリア 動画タイトル 0 バイト 0 カウント 動画説明文 0 バイト 0 カウント 折りたたまれている場合 全部表示する場合 注意点 プレミアム会員で使える XHTML タグの修正(たとえば <br> を <br /> に変換するとか <font> で一部を除いて属性を削除するとか)は実装していません。 プレビュー領域で sm 番号等リンクになる文字列を太字で表示する機能も実装していません。 省略表示の計算をするときに、一部の文字を使っていると誤差が生じるかもしれません。JIS で定義される範囲の文字であれば、おおむ
この程度の情報、どこかに載っていても良さそうなものなのだけど、ググり方が悪いのか見つからなかったので、SMILEVIDEO の挙動を実験的に調べてみた。 結果 タイトル 99バイト 説明文 999バイト ただし、UTF-8 でエンコードされるので、 いわゆる半角英数記号文字 1バイト いわゆる半角カナ 3バイト いわゆる全角文字 3バイト IE7 (XP) から投稿した場合の改行 2バイト で計算する。カナは半角でも全角でも1文字あたり 3 バイトで同じであることに注意(シフトJISなどとは異なる) なお、改行について、UNIX-like OS など改行が 1 バイトである環境では、そのように計算されるかもしれない(未調査)。要するに、ブラウザが送ってきた UTF-8 文字列を(改行変換せずに)そのまま保存しているかもしれない、という話。 また、プレミア会員だと数種類のタグを使えるが、(昔
前の記事で、Alder Lake のEコアである Gracemont では SHLD 命令がものすごく遅いせいで ULxx のエンコードが遅いという話をしました。 じゃあってんで SHLD 命令を等価な命令にバラして書いて計測してみたところ、YV24 -> ULY4 の predict left が 13.5fps から 32.4fps に高速化しました。これはこれでいいんですが、Pコアで実行した場合は逆に 56.2fps から 48.7fps に悪化します。遅くなるのは Golden Cove に限った話ではなく、他の Core 系 MA でも 10-15% の低速化になります。 まだいろいろ考えることがあるようです。
RTA in Japan Winter 2023 で見かけたので、 shapez (シェイプズと発音するのか…?)という工場建築系ゲームを始めてみました。 Read the rest of this entry
このページを最初にブックマークしてみませんか?
『UMEZAWA Takeshi's Site』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く