VS CodeがDOMによるターミナル実装のパフォーマンスを改善できなかったためCanvasに変更
Integrated Terminal Performance Improvements Electronという史上まれに見るそびえ立つクソのようなGUIプラットフォーム上で実装されているVS Codeが、ターミナルの実装をDOMによるものからCanvasによるものに変更したそうだ。これは、DOMによる実装ではパフォーマンスの改善が十分にできなかったからだという。 DOMでターミナルを実装する際の問題ごととして、テキスト選択、テキストアライメント、GC、パフォーマンスを上げている。 テキスト選択：ターミナルのテキスト選択を実現するためにDOMのテキスト選択の挙動をだいぶ上書きしなければならない。 テキストアライメント：一部の文字はモノスペースになってくれず、workaroundとして一文字ごとに固定長のspanで包む必要があるが、これはパフォーマンス上よろしくない。 GC：DOMでターミナ
そろそろマストドンについて語っておくか
世間ではマストドンが流行っている。結論から言うとマストドンは思想的にも設計的にも失敗しているのでお祭りのように一時の話題になった後、急速に忘れ去られる運命にある。 マストドンを語るには、まずマストドンが実装しているプロトコルであるOStatusについて説明する必要がある。これはもともと、StatusNetというソフトウェアが提唱したプロトコルで、Twitterようなマイクロブログの更新通知のためのプロトコルだ。StatusNetは今は名前を変えてGNU Socialとして自由ソフトウェア財団の傘下になっている。 マストドンはいうなればGNU Socialの互換実装だ。その基本的な思想や設計はGNU Socialと同じだ。どちらも現在の大手ソーシャルネットワークサービスに共通の問題に対処しようとしている。 問題とは何か。権力の一極集中である。TwitterにしろFacebookにしろGoog
ドワンゴにおける業務外Slackチャンネルのまとめ
はてな社内Slackでウォッチしている非業務チャンネル6選 - 平常運転 ドワンゴ社内Slackの非業務チャンネルを紹介 - ゆっくりしてない ドワンゴ社内チャットにおける各言語別チャンネルの参加者数をグラフで表してみた:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴグループのエンジニア) - ニコニコチャンネル:生活 すでにまとめられているので三番煎じだが、ドワンゴにおけるSlackの業務外チャンネルをまとめてみた。 ドワンゴには今、1000人ぐらいの被雇用者がいるはずであるが、現時点でチャンネル数は1534ある。ゆっくりがまとめた19日より、わずか2日間で7個増えている。 #4gamer チャンネルの由来は4Gamer.netだろうか。ビデオゲームについて話すチャンネル。 #boardgame ボードゲームのチャンネル #kusoge クソゲの雑談をするチャン
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
超会議2015
ニコニコ超会議2015が25, 26日に開催される。 今回のドワンゴの企画ブースにおけるアナログゲームは、 おばけキャッチ ワードバスケット ワンナイト人狼 ごきぶりポーカー エセ芸術家ニューヨークへ行く 6ニムト 麻雀 花札 ポーカー 他にも、囲碁将棋のブースがある。 今回は闘会議と違い、重たいゲームがほとんどない。 ちなみに、超会議2015では、私はゲームエリアには割り当てられていない。ゲームエリアでボドゲのインストをしたかったので希望を出したのだが、なぜか丸投げ広場に割り当てられた。今回の丸投げ広場は、幕張メッセの9-11ホールなので、いつもの場所とは離れている。その分、去年より面積が広く確保できているようだ。 私は何をするのかというと、おそらく馬車の先導役なのではないかと思われる。ドワンゴ社員の中でも変わり者が割り当てられたと見える。私のほかに割り当てられたもう一人のドワンゴ社員で
Linus Torvalds、HFS+に激怒
CVE-2014-9390 aka "Git on case-insensitive filesystems" I did not give the… gitが影響を受けた、HFS+で、一部の文字を区別しなかったり無視したりする問題に対して、Linusが吠えている。 マジで、HFS+はたぶん最悪のファイルシステムだな。クソすぎるぜ。NTFSもutf8の正規化で似たような問題（/の非正規化された表現を使用）があったが、まあ、今は修正されたんだろうよ。OS Xの問題は根本的すぎる。 そりゃ、古いさ。そりゃ、データ保護がクソすぎるってのはあるさ。だが、そういうのは、単に「すげーファイルシステムじゃない」って問題だ。「自分のケツすら拭けないマヌケによって設計された信じがたいクソ」ってわけじゃない。 HFS+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
ファイルシステムの破損？、付記using宣言とusingディレクティブの違い
ここ最近、筆者の使っているコンピューターは不可解な挙動に見舞われてきた。再現性なく機能停止に陥るのだ。 機能停止、というのはなんとも大雑把な言葉だが、そうとしか表現しようのない状態になる。 何の前触れもなく、急に画面が真っ暗、あるいは単色になり、そのまま止まってしまう。ターミナルに切り替えることもできず、SysRqすらきかない。 しかし、Ubuntuのバグ報告をみても、それらしき現象はない。こんなにも頻繁に遭遇しているのに何故だろうか。ハードウェアの故障であろうか。 ところで、今日、不思議な現象に出くわした。bashのglob上からみると存在するはずのファイルが、なぜか実際には存在していないという現象である。つまり、echo *とlsで表示されるファイルが異なる。globからしか見えないファイルがある。不思議だ。例に再起動してみたが、やはりglobでしか見えないファイルがある。 はて・・・
ループカウンタを64bitにしたり、 バッファのサイズを定数にしたらパフォーマンス激落ちなんだけど何で？
ループカウンタを64bitにしたり、 バッファのサイズを定数にしたらパフォーマンス激落ちなんだけど何で？ c++ - Replacing 32bit loop count variable with 64bit introduces crazy performance deviations - Stack Overflow stackoverflowで、興味深い質問が行われている。 簡単にまとめるとこうだ。std::uint64_t型の配列の各要素にx86-64のpopcnt(1になっているビット数を数える命令)を適用したい。 コードの肝心の部分を書くと、以下のようになる。 for (unsigned i=0;i<size/8;i+=4) { count+=_mm_popcnt_u64(buffer[i]); count+=_mm_popcnt_u64(buffer[i+1]); coun
JavaScriptの自動セミコロン挿入
JavaScriptでは、多くの文は、セミコロンという終端記号を明示的に記述して、文の終わりを示す。 var i = 0 ; ++i ; --i ; しかし、JavaScriptでは、一部の文脈で、セミコロンの省略が許されている。あたかも、セミコロンが自動的に挿入されたかのように振る舞う。これを、自動セミコロン挿入(Automatic Semicolon Insertion) ECMA-262 Edition 5.1 §7.9が規定する、自動セミコロン挿入の定義を、本記事では解説する。 まず、三つの基本的なルールがある。 プログラムを左から右にパースした時に、文法上許されないトークン(反則トークン, offending token)があった場合、以下の二つの条件のうちどちらかひとつ、もしくは両方を満たせば、セミコロンが自動的に挿入される。 反則トークンと前のトークンが、ひとつ以上の行終端子
2014-01-pre-Issaquah mailingのレビュー: N3880-N3889
[なかなか悪くないHTML] N3880: Improving the Verification of C++ Programs ようやく、C++論文で許せるマークアップのHTMLを読んだ気がする。 この論文は、C++にプログラムの検証を支援するための機能の必要性を提案している。 プロジェクトを始めるにあたって、どのプログラミング言語を選ぶかということは重要である。プログラミング言語ごとに利点や欠点があるので、考慮される。考慮に上がる対象に、検証可能性は重い。標準規格に、検証のための標準の規格がないのは、C++の利用を妨げる要因となっている。 この論文は、検証を標準規格でサポートするための必要性を提起するものであり、具体的な新機能の提案は含まれていない。ただし、現在のC++で改良できる分野として、いくつかの点を上げている。 たとえば、static_assertのメッセージを改良するだとか、
ClangがC++14の機能完全に到達！ 繰り返す！ C++14の機能完全に到達！
[llvm-project] Revision 194194 Clang - C++98, C++11, and C++14 Status とうとう、ClangがC++14の機能を完全に実装し終えたそうだ。もちろん、まだ既知、あるいは未知のバグがあるだろうが、とにかくC++14の機能的には完全にそろった。 これは素晴らしい。 ちなみに、Hacker Newsでは、このSVNコミットのリヴィジョン番号が、194194であることに着目して、狙ったのかと言われている。 それに対して、100100から194194までの数字には、194個もの同じ3数字二つの組み合わせがあり、別に特別な数字ではない、また、123321のような、他の意味で興味深い数字まで含めると、実に多くの「面白い」数字があると反論されている。 また、Interesting number paradox（興味深い数字のパラドックス）を
KDE、あやうくレポジトリを失いかける
Too Perfect A Mirror - Me, my blog, and my Johnson 追記：上記記事の全訳 本の虫: KDEレポジトリ消失問題の記事の全訳：完璧過ぎるミラー 追記：この記事は上記のブログ記事にざっと目を通して素早く書いたものであり、詳細を欠く。上記の記事は全訳しているので、より正確で詳細な内容のために、目を通すべきである。 2013-3-22に、git.kde.orgをホストしている仮想マシンをセキュリティアップデートのために一旦落とした。アップデート後に復帰させてみると、ファイルシステムが壊れていたらしく、KDEの1500以上ものレポジトリが消えていた。 問題は、この問題が気づかれぬまま復帰したので、ミラーサーバーが誤りをそのままコピーしてしまったことだ。 ミラーは正しいバックアップではない。 とてつもなく幸運なことに、この問題が起こる一日前、ミラーサーバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
