今流行りの投機実行脆弱性の影響を一切受けないDOOM実装が公開される
https://github.com/xoreaxeaxeax/movfuscator/tree/master/validation/doom このDOOMは条件分岐を一切使用していない。したがって今流行りの投機実行の脆弱性であるMeltdownやSpectreによる脆弱性は存在しない。 ちなみに、現代の性能のコンピューターで、1フレームの描画に7時間ほどかかるので、このDOOMで遊ぶには若干の忍耐力を要求される。しかし、脆弱性の完全な排除のためには若干のパフォーマンスの低下はやむを得ないところだろう。 このDOOM実装はオリジナルのDOOMのCコードに若干の変更を施して、M/o/Vfuscatorでコンパイルしたものだ。 https://github.com/xoreaxeaxeax/movfuscator M/o/Vfuscatorとは、IntelのMMUがチューリング完全であることを
なぜLispやMLは分裂するのか
How were some language communities (eg, Ruby and Python) able to prevent fragmentation while others (eg, Lisp or ML) were not? - Programmers - Stack Exchange stackexchange.comで、面白い話題が議論されていた。LispやMLというのは、いわば、Lisp風言語、ML風言語の総称である。実際には、Common LispやらSchemeやらArcやらと、多数の互換性のない言語が存在している。一方、RubyやPythonには、特に大きな分裂は起きていない。CPythonに対してPyPyのような、異なる実装は出ているが、言語は分裂していない。なぜなのか。一体、RubyやPythonは、分裂を防ぐために何をしているのか。 色々と議論
Twitterを憂ふ
TwitterというWebサービスに関しては、今さら説明するまでもない。ただ、私はこのサービスが本質的に、Webの将来に禍根を遺すであろうことを危惧している。以下にその理由を述べる。 私がTwitterをとみに意識し始めたのは、去年からである。私がGoogle Readerを経由して読んでいる、いくつかのブログの更新が、急に鈍化しだしたのである。甚だしきに至っては、全然更新されないブログまで出てきた。そのブログに共通している事がひとつ。曰く、「Twitter始めました」と。 彼らはTwitterを使い始め、二度とブログに戻ってこないのである。私には、Twitterの何が、そこまで人を引きつけるのか、理解できなかった。 凡そTwitterは使いにくいこと極まりない。一回の投稿に文字数制限があること、後から読み返しにくいこと、検索しにくいこと、極めて閉鎖的であること等等。followだの何だの
GDBがeBPFのデバッグをサポートした
GDBがeBPFのデバッグをサポートした。 GNU Debugger Adding eBPF Debugging Support - Phoronix eBPFというのはLinuxカーネル内の仮想マシンだ。 もともと、BPF(Barkley Packet Filter)という仮想マシンがあった。これはネットワークのパケットフィルタリングをするための仮想マシンで、レジスターベースのRISCプロセッサーを模した命令セットになっている。 カーネル内で安全にユーザーコードを実行するというのは需要があるので、BPFをより汎用的に使いたいという声は多かったのだが、何分BPFは設計が古い。レジスタは2個で32bit、命令セットはatomic compare exchangeのようなモダンなプロセッサーに搭載されている命令がない。 そのためeBPF(extended BPF)が設計された。レジスタは10個
Twitterでつぶやかれている絵文字のリアルタイムなトラッカー
emojitracker: realtime emoji use on twitter Twitterでつぶやかれている絵文字のリアルタイムなトラッカーがある。 このサービスは近々、Twitterの歴史的に認められていた上限なしAPIアクセスの廃止に伴い、終わる見込みだそうだ。 U+1F647 PERSON BOWING DEEPLY 🙇 — Medium 面白いし参考になるので、今のうちに眺めておこう。 ちなみに、この絵文字トラッカーはユニコードコンソーシアムにおいて絵文字の実際の利用需要の参考に引用されたこともある。 Twitterがまだおおらかな頃、このような面白いサービスを作るために、APIへの上限なしアクセス権を気軽にホイホイ発行していたのだが、Twitterからのメールでの連絡で、近々そのような上限なしアクセスを廃止するので、商用アクセスAPIであるGnipに移行するか諦めろ
AMDのZen 2でRDRANDが-1を返すので最近のGNU/Linuxがブートできない問題
AMDのZen 2アーキテクチャの新製品が発売されて沸き立っているが悲しいお知らせがある。最近のGNU/Linuxディストロはブートしない。例えばUbuntu 19.04はブートしない。 理由は、ハードウェア乱数を返す命令、RDRANDに不具合があり、常に-1を返すのだという。このため、rdrandを直接使っているsystemdが失敗し、結果としてブートできなくなる。 AMDによればこの問題はBIOSアップデートで修正可能であるという。しかしこれはとても怪しい陰謀論を考えたくなる。なぜRDRANDが常に-1を返すような不具合が未然に発覚せずに製品リリースまでこぎつけてしまったのか。なぜファームウェアのアップデートで修正可能なのか。まさかバックドアなのではないか。 陰謀論はともかくとして、もう一つの問題は、なぜsystemdはRDRANDを直接使っているのかということだ。Linuxカーネルの
本の虫: 邪悪なC形式のキャストにしかできないこと
注意：邪悪で汚らわしいC形式のキャストは、いやしくもC++プログラマたる者は、使うべからず C++では、玉虫色のC形式のキャストの機能を、三つに分割した。static_cast、reinterpret_cast、const_castである。しかし、この三種のキャストでは、C形式のキャストを完全に代替できないという声をよく聞く。曰く、「どうしても書けないキャストがある」と。 それはよく聞く話だが、では実際にどのようなキャストなのかということは、誰も審らかにしない。誰も知らないキャストであれば、特に使えなくても問題ないはずだ。ただし、「C形式のキャストならばできるキャストが、新しいキャストを組み合わせてもできない。どんなキャストかは知らないが、とにかくできないと聞いている。故に新しいキャストはクソだ」などという論調で、C++の改良されたキャストを使わぬC畑の外道がしゃしゃり出てくるのも困る。そ
autoの意外な使い方
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
VS CodeがDOMによるターミナル実装のパフォーマンスを改善できなかったためCanvasに変更
Integrated Terminal Performance Improvements Electronという史上まれに見るそびえ立つクソのようなGUIプラットフォーム上で実装されているVS Codeが、ターミナルの実装をDOMによるものからCanvasによるものに変更したそうだ。これは、DOMによる実装ではパフォーマンスの改善が十分にできなかったからだという。 DOMでターミナルを実装する際の問題ごととして、テキスト選択、テキストアライメント、GC、パフォーマンスを上げている。 テキスト選択：ターミナルのテキスト選択を実現するためにDOMのテキスト選択の挙動をだいぶ上書きしなければならない。 テキストアライメント：一部の文字はモノスペースになってくれず、workaroundとして一文字ごとに固定長のspanで包む必要があるが、これはパフォーマンス上よろしくない。 GC：DOMでターミナ
AWSのアクセスキーをハニートークンとして使うアイディア
Early Warning Detectors Using AWS Access Keys as Honeytokens この発想はなかった。 AWSのアクセスキーはハニートークンとして使える。 ハニートークンとは、普段使用しないものが使用されたことを検知して、意図しない利用を検知するトリックである。例えば、通常ならば使われないメールアドレスをパスワードとともに、自分しかアクセスできないストレージに格納しておく。その状態で、もしメールサーバーにログインされた場合は、自分しかアクセスできないはずのストレージに他人がアクセスして、マヌケにもメールアドレスとパスワードをストレージ上に保存しているのを発見して、利用を試みたということになる。つまり、侵入を検知できる。 AWSのアクセスキーは、ハニートークンに使うことができる。AWSに権限を持たないユーザーを追加して、そのユーザーでアクセスキーを発行
Emscriptenがpthreadを実験的にサポート
Emscripten gains experimental pthreads support! - Google Groups Emscrptenがpthreadを実験的にサポートしたそうだ。 JavaScript上でスレッドを実装する上で障害になるのは、スレッドに相当する方法が存在しないということだ。Web Workerは実行媒体ごとに隔離されて、メッセージパッシングで他の実行媒体と通信をする仕組みになっている。これは同じメモリに複数の実行媒体からアクセスするというスレッドとは異なり、プロセスに近い。 現在、JavaScript上で共有メモリを扱えるようにしようというドラフト規格、SharedArrayBufferが議論中であり、Firefox Nightlyが実験的実装を進めている。この機能を用いて、Emscriptenでpthreadを実験的に実装したそうだ。
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳
10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか？ トーバルズ：俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた（データベースは別だが）。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B
ループカウンタを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
Multipath TCPについて
Multipath TCPとは、複数の経路を扱うためのTCP拡張である。実は、以前、本の虫: MultiPath TCPのLinuxカーネル実装という記事で、その実装デモを紹介している。 従来のTCPは、IPとの分離ができない。TCPヘッダーの中には、ひとつのIPアドレスとポートがある。経路ごとにIPアドレスが割り振られるので、経路を変えるには、別のTCPコネクションを貼り直さなければならない。 しかし、複数の通信経路を持つという環境は、もはや珍しいものでも何でもなくなっている。たとえば、多くのラップトップにはEthernetとWiFiの二つの経路があるし、スマートフォンにも、WiFiと3G/4Gという複数の経路がある。特にスマートフォンの場合、経路が使えるかどうかが頻繁に切り替わる。 過去に、TCPで複数のIPアドレスを扱う拡張はいくつも出されたが、いずれも、IPアドレスを隠すという点で
ドワンゴに入社した
そう。タイトル通りだ。筆者、江添亮はドワンゴに雇用された。一体、どのような経緯でドワンゴに入社するに至ったのか。また、どんな仕事をしているのか。それを説明するには、時系列を追って書いたほうがいいだろう。 2013年8月21日 ふとみると、以下のようなサブジェクトのメールが届いていた。 【ご相談】ドワンゴ主催の C++11, 14 に関する勉強会にスピーカーとしてご参加頂けないでしょうか C++11？ C++14？ なんと、日本にC++14などという単語を知っている企業があったのか。しかし・・・ドワンゴ？ SPAMだろうか。いや、こんなにピンポイントなSPAMがあるわけがない。 それにしても解せないメールだ。ドワンゴといえば、もちろん、あの有名なニコニコ動画の企業だ。ニコニコ動画と言えばWebサイトだ。ニコニコ動画やその関連サービスの開発にC++を使っているのだろうか。いやまて、たしか子会社
Debianの新しいinitにsystemdが採決された
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
OpenBSDが資金難で開発停止の危機
'Re: Request for Funding our Electricity' - MARC OpenBSDが、資金枯渇で電気代が払えず、開発停止の危機が目前に迫っているようだ。 List: openbsd-misc Subject: Re: Request for Funding our Electricity From: Bob Beck <beck () openbsdfoundation ! org> Date: 2014-01-14 20:03:37 Message-ID: CAComcpM_hcqQuLnb=otudLjYjwaA5wMU14EyxLCdJWEXOJoLNQ () mail ! gmail ! com この問題に注目を集めるために取り上げる。 資金減少により、プロジェクトの経費を払うことができる資金元が必要だ。OpenBSD財団がプロジェクトの電気代を支払う
プログラミングを学ぶ環境について
昨日、今日と吉田寮にいて、数人集まって、それぞれ自分勝手にコードを書いていたわけだが、思うに、このような環境はプログラミングの学習環境としてかなりいいのではないかと思う。 結局、プログラミングというのは、講師が前の黒板に90分間板書したものを読んで学べるものではないのだ。自分で調べて、コードを書いて、動かして学ばなければならないのだ。 ただし、「自分で調べて」というのが、大抵の場合、非効率的になる。例えば、テンプレートメタプログラミングに詳しくないものが、CRTPのようなテクニックを必要とする場面に出くわしたり、ある型がPODであるかどうかを調べる方法(std::is_pod)について、自力で調べるとすると、無駄に時間がかかる。まずどこを調べればいいのかわからない。ドキュメントがどこにあるのかもわからない。 しかし、CRTPやstd::is_podのようなものは、理解しているものが教えれば
C++1yに提案されている不透明エイリアス(opaque alias)
[PDF注意] N3741では、C++1yに向けて、不透明エイリアス(opaque alias)が提案されている。 不透明エイリアスとは、Strong typedefなどとも呼ばれてきた機能で、typedefに似ているが、別の型として認識される別名の宣言機能だ。 C++には、Cから受け継いだtypedef指定子という機能がある。また、最近はもう少しまともな文法の、エイリアス宣言がある。どちらも機能も、「typedef名」という型に対する別名を宣言する。 typedef int Integer ; // typedef指定子 using Number = int ; // エイリアス宣言 typedef名は、ソースコード中に、型名で意味を記述させることができる。例えば、年齢とかお金とか身長とかだ。 using Age = int ; using JPY = int ; using Heigh
LLVM/Clangがぜってーサポートしねーと宣言しているLinuxカーネルに多用されているGCC拡張
[Phoronix] LLVM/Clang 3.3 Should Be Close To Building Linux Kernel LLVMLinux Bug 9254 – clang can't build iptables in Linux kernel: error: fields must have a constant size: 'variable length array in structure' extension will never be supported ClangでLinuxカーネルをビルドできる状況は、多くの勢力に望まれてきた。理由は様々だ。Clangはビルド時間が短い。静的解析による警告も優れている。ソースコードも綺麗だ。複数の独立した実装でコンパイルできるコードは、誤りを静的に発見しやすい移植性にも優れる。より優れたコピーレフトなライセンスであるGPLv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
