はてなブックマーク

Do Not Use Go for 32bit Development 私は今、大量のGoのコードをCに書き換える作業をしている。時間は金で買えない。主たる開発者として、金はここで止まってしまう。わたしは顧客と話し、責任を負った訳だ。私の過ちは、Goを信頼したことだ。私は自分のモットーを思い出すべきだったのだ。Nullius in verba（政治信教の言を入るべからず） Goは1.0がリリースされたが、もし、32bitサポートが必須であれば、Goを選んではいけない。 32bit Goには多くのバグがあるが、特に問題なのがひとつある。 実行開始の初期化時に、Goは512MBの仮想アドレス空間を予約しようとする。予約できなければ、クラッシュする。Goは、ガベージコレクションのためにこの空間を必要とする、おそらく、すべてのGC言語、いや、すべての言語は、メモリ管理に対して、似たような手法を用い

江添亮 自由ソフトウェア主義者 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

Why does holding the Ctrl key when selecting New Task from Task Manager open a command prompt? - The Old New Thing - Site Home - MSDN Blogs Adam SはなぜCtrlキーを押しながらタスクマネージャの新しいタスクを選択するとコマンドプロンプトが開くのか質問した。 隠し機能さ。 Windows XPはビジュアルスタイルを導入した。ビジュアルスタイルをデバッグする際に問題になることは、もしビジュアルスタイルエンジンが暴走した場合、まともに見えなくなるということだ。ビジュアルスタイルの開発者がしばしば直面した問題に、実行ダイアログが動かなくなるというものがあった。実行ダイアログがなければ、問題を検証するためにデバッガーを起動することすらできなくなる。 解決方

Larry Osterman's WebLog : What’s up with the Beep driver in Windows 7? 今朝早く、ある人が僕に、「なんで64bit版のWindowsは、PCの内部beepスピーカーをサポートしてないんだい」と訊ねてきた。その答えは、すこしばかり複雑なんだ。また、PCを取り巻く環境とも関係していて、なかなか面白い問題だ。 まず、当時[1]のbeepハードウェアが、どのように機能しているかということについて説明するね。元々、IBM PCは、Intel 8254 プログラマブル・インターバル・タイマー・チップを搭載して、システムクロックを作り出していたんだ。IBMのエンジニアは当時、PCは音を鳴らす必要がある（高音質とまではいかないけれど）と考えたから、8254を、矩形波生成器として使うことにした。このために、エンジニア達は、チップの第三タイ

Coding Horror: Speed Hashing xkcd: Password Strength GPGPUが一般的になった現代では、従来のハッシュアルゴリズムは十分な強度ではないというお話。一般人が五百ドル程度で購入できるハイエンドグラフィックカードは、現在のハイエンドCPUより150倍も高速にハッシュ計算ができる。しかも、GPGPUで高速に計算できるということは、並列性が高いということを意味する。つまり、GPUを増やせば容易にスケールするので、さらに危ない。 もはや、MD5やSHA-1、SHA-2の時代は終わった。これからの開発者は、GPGPUに対しても十分な強度を持つ、容易に並列化できないハッシュアルゴリズムを採用しなければならない。 ユーザーは、長いパスワードを使わなければならない。現時点でのJeff Atwoodのおすすめは、12文字以上である。1(xY%08などという、

Diego Novillo - Switching to C++ by default in 4.8 GCC開発者の一人でGooglerのDiego Novilloは、今月の3日にMLで、GCC 4.8のビルドをデフォルトでC++にしようと提案している。これは、GCC自体をビルドする際のデフォルトの言語をC++にするという意味である。GCCがコードをデフォルトでC++としてコンパイルするのではない。現在のGCCビルドシステムの言語モードをC++に切り替えるのは非常に簡単で、必要なのはテストだけだという。 2011年、GCCの実装で、C++を使用可能にする採択が受け入られている。GCC自体のコンパイルをデフォルトでC++にすることは、GCC実装におけるC++の利用を更に加速するだろう。 GCCにおけるC++利用のコーディング規約は、目下作成中である。コーディング規約が完成する前に、GCCのビ

GNU/Linuxに移行してより、あらゆることが新鮮で充実した日々を送っている。急に身長が伸びたりはしないし、彼女もできないし、宝くじにも当たらないが、幸せだ。 ただ、どうも、道を誤った感がある。 ここ数年というもの、C++の参考書の執筆に専念してきた。規格書の読解、日本語による説明、ひとつの機能だけを使った完結なサンプルコード、そんなことを考えて日々を送っていた。その結果、C++の規格の知識は大幅に増えたが、その他の技術からは遠ざかってしまった。向上したのは、英語の読み書き能力とドキュメントを読む力だけだ。一部の能力だけに特化した結果、汎用的なプログラマーとしての力は、むしろ衰えてしまった。 新しい環境で新鮮な気持ちになり、久しぶりに色々とコードが書きたくなった。驚いたのは、ドキュメントを読む力が格段に上がっていて、全く馴染みのない環境やライブラリでも、楽に学べるようになっていることだ。

思うに、私が最初のOSに不自由なWindowsを選んだのは正解だったかもしれない。すくなくとも、Win32 APIはPOSIXよりはるかに使いやすい。 問題はiconvだ。一体どこの糞が何をキメながら設計したらこうなったんだ。狂っているにも程がある。 size_t iconv (iconv_t cd, const char ** inbuf, size_t * inbytesleft, char ** outbuf, size_t * outbytesleft) ; ポインターのポインターであるには理由がある。iconvは、すべて書き換えるからだ。ポインターを書き換えるのでポインターへのポインターを要求する。当然だ。当然であって欲しくないが当然だ。 なんでそんなに馬鹿げた副作用を持ち込むんだ。それでは必ずlvalueを渡さなければならないし、大抵の場合、もとの値を保持しておきたいから、オブ

今や、GNU/Linuxの方が不自由なWindowsより日本語サポートが優れている。これは純然たる事実である。 私は、UIが日本語化の質を論じているのではない。私はUIの言語を英語にしているので、UIの日本語の質についてはわからない。ただ、2012年となった今では、GNU/Linux/Xの環境の方が、圧倒的に日本語を扱う環境が優れていると考えているのだ。 まず、現行のまともなディストリは、文字エンコードをデフォルトでUTF-8にしている。このため、不自由なWindowsにおける、カオスな大量のマルチバイト文字コード混在環境の問題は存在しない。確かに、不自由なWindowsのネイティブの文字エンコードはUTF-16だが、下位互換性を保証するために、既存のマルチバイト文字をすべて継続してサポートしているために、未だにカオスな状況になっている。多くのプログラムは、嘆かわしいことに、いまだにANS

WindowsからGNU/Linuxに改宗した身として、WindowsとGNU/LinuxではBoostに対する感覚が違うことに気がついた。ここで問題にするのは、threadとかfilesystemとかの環境に依存した低級なライブラリの話である。regexなどの環境にあまり依存しない高級なライブラリは除く。 Windowsユーザーから見ると、BoostはWin32 APIの極めて限定的なサブセットをC++でラップしたライブラリである。WindowsでC++が必要な本物のプログラムが書きたければ、やはりWin32 APIを使わなければならない。どうせWin32 APIを直接使うなら、なぜ機能が削減されたBoostなど使う必要があるのか疑問だ。そのため、Windowsユーザーだった私は、Boostの低級なライブラリには興味を示せないでいた。移植性はあるだろうが、それ以外には魅力がない。STLに

Win32 APIに慣れた身としては、POSIXが使えなさ過ぎて困る。 まず、あまりにも機能が少ない。もちろん、POSIXは環境が用意するべき最低限の保証なのだから、こういうものなのかもしれないが、低機能は低機能だ。さらに、低級だ。 そもそも、APIの設計からしてひどい。まず、関数名が暗号のように短い。Windowsのやり方DoSomethingOrOtherExW(多数の引数)が最適とは言わないが、すくなくとも、Win32 APIの方が、どういう意味なのかはわかりやすい。関数名が十分に長いので検索もしやすい。さらに統一されたドキュメントもある。今の時代、関数名が長すぎて困るということはないのだ。当時のCコンパイラーが認識する識別子の長さに関係していたのか、あるいは単にUNIX文化が略語を好むのか。 POSIXのドキュメントと格闘した挙句、結局、ほとんどの場合、Boostにもっとマシなライ

Willus.com's 2011 Win32/64 C Compiler Benchmarks これはすごい。Windows上で動くCコンパイラーを様々な面から比較している。ベンチマークに使ったソースコードは、すべて純粋なC言語である。アセンブリやインラインアセンブリは無効にしてある。これは純粋なCコンパイラーの性能を図るためだからだ。 まず、コンパイラー自体の問題がある。Intelのコンパイラーは、デブすぎるにもほどがある。Intelのパッケージだけで1.6GiBもあるのに、これにさらにVisual Studioを別途インストールしなければ使えない。さらに、Intelのインストーラーは40個以上もの別個のソフトウェアをインストールする。それぞれ、バッチスクリプト用にPATHを追加するので、PATH環境変数に何十個も追加されることになる。Windows 7では、インストール済みのソフトウ

btrfsという、現在開発中のファイルシステムがある。これは、既存のextの系譜に変わるべく開発されているファイルシステムである。ext系列のファイルシステムはすでに十分な実績があるが、いかんせん土台とする技術が古い。これは、extのオリジナル作者であるTheodore Ts'oも認めている事実である。つまり、抜本的な革新のためには、全く新しいファイルシステムを開発する必要がある。 そこでbtrfsだ。btrfsは、近代的な技術を使った新しいファイルシステムである。内部の実装はさておくとしても、ユーザーにとっても便利な近代的な機能を多数提供している。スナップショットやサブボリュームのサポート、ファイルシステムによるRAIDや圧縮のサポート、オンラインデフラグ、オンライン動的ディスクの追加と削除、さらには、将来的には暗号化などもサポートする予定である。 これらの機能は、従来、ファイルシステム

自由なソフトウェアの力は素晴らしい。とすれば、自由の威力はドキュメントにも及ぶはずだ。現在、ほとんどの紙書籍は不自由である。Web上にホストされている検索可能なドキュメントの多くは、後述する通り、複製や公衆送信や翻案を暗黙に許しているわけだが、たいてい、明示的な許諾が与えられていない。そのため、Web上のドキュメントは真に自由なのではなく、ある程度は自由のように振る舞うことを黙認されているだけである。この現状は不自由である。 いかに現行法が実情にそぐわないものであったとしても、今を生きる我々は現行法に従わねばならぬ。コピーレフトなライセンスは、著作権法を利用した賢いハックである。著作権法は、著作物の利用の独占を許している。本来、独占は禁止されているが、著作権法や特許法や商標法などは、独占を実現することが目的なので、独占を禁止する法律の適用外である。独占者たる著作者は、著作物の利用許諾を与え

そろそろ食費にすら事欠くようになったのでバイトをすることにした。一日数時間の掃除だ。おそらく、C++本の執筆にはさほど影響しないだろう。 結局、結果からいえば、当初の目論見であった、貯金の続くうちに、全力でC++本を完成させるというのは、無理だったわけだ。やれやれ、最初から働きつつ執筆すべきだったのか。 C++本は、ようやくオーバーロード演算子まで進んだ。といっても、途中のBasic Conceptsに当たる部分は飛ばしたし、コピーとムーブも飛ばした。コピーとムーブはどう書けばわかりやすくなるのか分からない。純粋なコア言語機能だけ説明してもわかりにくいし、かといって、プログラミングテクニックまで説明するのは本書の範疇ではないように思う。コア言語に絞ってさえこの分量なのだから、最初の壮大な野望通り、標準ライブラリまで手を広げようと思ったら、いつまでかかるか分からない。 そもそも、一冊のまとま

[Phoronix] Qualcomm Calls To "Kill All Proprietary Drivers For Good" [Phoronix] Qualcomm Calls To "Kill All Proprietary Drivers For Good" Let's Kill All Proprietary Drivers For Good 来週開かれる6th annual Linux Foundation Collaboration Summitで、Qualcommのプレゼンする内容は、「善のため、プロプライエタリなドライバを根絶せよ」というものだ。あの悪名高いQualcommが、ここまで姿勢を変えたというのは、なかなか感慨深いものがある。 なぜ一部のドライバーはクローズドソースなのか。これには、色々と複雑な事情がある。特に、ソフトウェア特許の問題がある。連中は、既存

PulseAudioについては、悪い話しか聞かない。まだ私が不自由なOSであるWindowsを使っていた頃から、PulseAudioは酷評されていた記憶がある。 これが不思議だ。そもそも、PulseAudioというのは、低レベルAPIをラップする高レベルAPIである。PulseAudioによって、すべてのプログラムが、あたかもサウンドデバイスを独占的に使用できているかのような環境をエミュレートしている。その実装の質はともかく、思想は至って普通だ。モダンなOSなら、当然ハードウェアなどは通常のプログラムから意識させないようにするべきである。いまや、OSはサウンドデバイスの制限のあるミキシングに頼らないのだ。CPUは十分に速くなった。ソフトウェアでのミキシングは、現代のCPUならパフォーマンス上、なんの問題もない。いまや、完全なソフトウェアによるリアルタイムのミキシングやリサンプリングは当たり

GNU/Linuxでは、fontconfigによりフォントの優先順位を設定している。この設定によって、フォントに存在しないグリフでも補完して表示できる。この機能は、モダンなOSなら大抵備えている機能である。しかし、もし、日本語と文字を共有している他言語のフォント、例えば簡体字や繁体字のフォントの優先順位が、日本語フォントより高い場合、そのフォントが日本語フォントより優先されてしまう。 どうも、この問題に対して、場当たり的に対処している人間が多いようだ。たとえば、該当の日本語以外のフォントを削除するという選択だ。PulseAudioの件と同じ場当たり的な対応である。なぜ問題の本質を探ろうとしないのか。そもそも、多言語環境を本当に実現したければ、重複数複数のフォントがあっても問題ないようにすべきである。問題を本当に解決するためには、フォントの優先順位の変更が必要だ。 日本人ならば、日本語フォン

江添亮 自由ソフトウェア主義者 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

Adobe Flash Player Premium Features for Gaming | Adobe Developer Connection Got a Profitable Flash-Based Video Game? Adobe Wants a Cut | Webmonkey | Wired.com Adobeの不自由なソフトウェアであるFlash Playerのプレミアムな機能を使っていて、$50000以上の売上のあるFlashで作られたゲームは、売上の9%をAdobeに差し出すこと。 この利用料を回避する方法は、プレミアムな機能を使わないか、売上を下げるか、今年の8月までにFlashゲームの公開を取り下げることである。 もちろん、我々が皆同意するように、不自由なソフトウェアであるFlashを使わないという選択肢が最も優れている。だから早く不自由なFlashの利用をやめる

このブログのライセンスを、今日より、CC-3.0-BY-SAからGFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Textsに変更することにした。 これは以前からGFDLとCCを比較して考えていたことである。 変更の理由は、Creative Commonsという名称のややこしさである。Creative Commonsは一枚岩ではなく、派生物を認めるかどうか、派生物は認めるがShare-Alikeかどうか、Non Commercialかどうかなど、それぞれ細部が異なるライセンスの集合である。お互いに互換性はない。だから、単にCreative Commonsといった際、非常に紛らわしいのだ。 また、Non Commercialという概念の定義も曖昧である。何

もはや、不自由なソフトウェアの時代は終わった。単純に終わったのだ。もうこれ以上、不自由なソフトウェアの未来はない。金銭的な価値はともかく、ソフトウェアの質は自由な方が圧倒的に高い。だからWindowsとかiOSとかAndoridが手元にあるならば、窓から投げ捨てるべきである。 こう言ったからとて、私は何も、フリーソフトウェア原理主義に改宗したのではない。今や、自由なソフトウェアの方が質が高くなっているからという至極単純な理由から言っているのである。私は質を優先する。不自由なソフトウェアの方が優れているのならば、いくら金を払っても構わないし、ソースコードが公開されていなくても構わない。しかし、事実として、今や、不自由でクローズドソースなソフトウェアは劣っている。自由か、最低でもオープンソースなソフトウェアの方が優れている。わざわざ不自由でクローズドソースなソフトウェアを使う必要はない。まして

グリーは一体どこから道を間違え始めたのかという知られざる歴史まとめ - GIGAZINE これはなかなか面白い。利益を追求する方向に進んでいったら、今の形になったというわけか。 それにしても、なぜ利益を追求しようとすると、ああいう不自由な形になってしまうのだろう。なぜ独占的で排他的な囲い込みに走ってしまうのか。Appleしかり、Microsoftしかり、Sonyしかり。事実として、利益が出ているのだから、認めるしかないが、それにしてもなぜこうなるのか。なぜ自由と利益は両立できぬのか。 ともかく、不自由なOSの使用をやめた身からすると、不思議でならない。今の私は、グラフィックドライバー以外は自由もしくはオープンソースなソフトウェアを使っているが、不自由なソフトウェアを使っていた時よりも、よほど快適だ。もっと早く移行するべきだったと後悔している。 ただし、私は今の自由なソフトウェアの環境を手に