マイクロソフト、無駄な抵抗を辞めてWSLに本物のLinuxカーネルを同梱する
Announcing WSL 2 | Windows Command Line Tools For Developers 「自分らはLinuxカーネルだ。防衛を解除して投降せよ。自分らの技術上の差異は自分らのものとする。自分らの文化は自分らの益とする。抵抗は無意味だ。」 マイクロソフトはWSL 2で本物のLinuxカーネルを同梱して利用すると発表した。 最初のWSLは、マイクロソフトによるLinuxカーネルのシステムコールの互換実装であった。これは様々な互換性とパフォーマンスの問題を抱えていた。互換性は果てしなく低く、パフォーマンスは主にファイルシステム周りがとてつもなく遅かった。 新しい実装であるWSL 2では、本物のLinuxカーネルを使い、完全なシステムコール互換性を実現する。このLinuxカーネルはマイクロソフトによってビルドされている。最初のバージョンはLinux 4.19となる
本の虫: GCCのgit移行が難航中
GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。 GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。 ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。 Resource page for reposurgeon 3.44 しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。 ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。 GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix ESRの所有する64GBのメモリ
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明 npmが一見無意味に思えるfsというパッケージをSPAMとみなして削除したところ、1000件ほどのパッケージが依存するパッケージだったので、削除を取り消した。 npm, Inc. Status - "fs" unpublished and restored 今日、数分ほど、"fs"というパッケージが、ユーザーからSPAMであるという報告を受けて、レジストリから非公開にされた。これは現在復旧されている。これは私(@seldo)による人為的なミスである。私は非公開が安全であるかを確認する内部のガイドラインに従っていなかった。ビルドが阻害されたユーザーに謝罪する。 詳細："fs"というパッケージは、無意味なパッケージである。これは単に"I am fs"をログに残して終了する。このパッケージが何
Linuxにleftpad()というシステムコールを入れる提案
LKML: Richard Weinberger: New syscall: leftpad() Linuxカーネルに興味深い日付でleftpad()というシステムコールが提案されている。 最近のnode.js業界の事件を振り返るに、leftpadのような基本的なアルゴリズムの依存はソフトウェアを脆弱にすることが判明した。ledpad[原文ママ]を提供するnode.jsパッケージが消失し、多くのソフトウェアが動かなくなった。 この事件に注目すると、node.jsベースのソフトウェアがLinuxの「ユーザースペースは壊さない」原則に将来的に頼ることができるので、このような機能を提供するのはカーネルの役目であるという結論に至った。 glibcとAndoid[原文ママ]のbionicは、早急にこの新しいシステムコールのラッパー関数を提供してくれることを望む。 leftpadをカーネルに入れたのは
npmからkikとその他諸々が消されたまとめ
npmとは、node.jsにおけるパッケージシステムのことだ。npmを使えば、他人の書いたnode.jsベースのプログラムとライブラリの入手と利用がとても簡単になる。 そのnpm界隈が混乱している。発端は以下のURLだ。 I’ve Just Liberated My Modules — Medium Azer Koçuluはkikという名前のnpmパッケージを公開していた。このkikというソフトウェアの中身についてはここでは関係がない。 さて、それとは別に、kik.comというスマフォ用のチャットアプリを出しているKik Interactive社がいて、kikという名前のパッケージをnpmで出したいので、名前を明け渡すように要求した。 Azerはこの要求を拒否した。すると、Kik Interactive社はnpmの管理者に片っ端からメールを投げまくり、そのうちの一人が反応して、Azerの意
cpで大量のファイルをコピーした（4億3200万件、39TB）
GNUのcpを使って大量のファイルをコピーしたところ、cpの設計上の問題で、極めてコピーが遅かったというお話。 My experience with using cp to copy a lot of files (432 millions, 39 TB) よう。俺は最近、大量のファイルをコピーする必要があったんだが、UNIXは20年もやってきた俺の経験からも、cpの挙動には驚かされたし、俺の意見はコミュニティに共有されるべきだと思う。 環境：古いDellのサーバー（2コア、初期メモリ2GB、追加して10GB、Ubuntu Trusty）と、新しいDellのストレージ格納機(MD 1200)にある、12個の4TBディスクでRAID 6が設定してあって、全体で40TBの要領を持ち、二つのドライブが同時に失敗しても問題ない環境。サーバーは遠隔地バックアップに使われていて、ディスクへの書き込みし
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
ループカウンタを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
Linus Torvalds、 GCC 4.9.0のコード生成にブチ切れる
Phoronixで知ったが、Linus TorvaldsがGCC 4.9.0のコード生成にブチ切れている。 問題はLinuxカーネルのload_balance()がランダムにパニックを起こすというもので、その原因は、報告者の使っているコンパイラーであるGCC 4.9.0のコード生成がおかしかったという話だ。 Linus様は御自ら生成されたコードを読み給い、平生と変わらぬ調子で物事の道理を示された。 Linux-Kernel Archive: Re: Random panic in load_balance() with 3.16-rc From: Linus Torvalds Date: Thu Jul 24 2014 - 14:47:25 EST On Wed, Jul 23, 2014 at 6:43 PM, Michel DÃnzer <michel@xxxxxxxxxxx> wro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
