GPU Killは、NVIDIA、AMD、Intel、Apple Siliconシステム間でGPUを管理するためのコマンドラインツールです。GPUインフラストラクチャの監視、制御、保護を容易に行えます。リアルタイムでのGPU使用状況の監視、スタックしたプロセスの強制終了、クリプトマイナーと疑わしいアクティビティの検出、リソースの不正使用を防ぐためのポリシーの適用、クラスタ監視のためのWebダッシュボード、複数のサーバー間でのGPUのリモート管理、AIアシスタントとの統合などの機能があります。Linux、macOS、Windowsをサポートしています。シンプルなコマンドラインインターフェースとWebダッシュボードにより、ユーザーフレンドリーな管理を実現します。
わずか約150行のC99コードで書かれた、最小限のJSONパーサーライブラリが登場！メモリ効率のためにゼロアロケーションを採用し、状態も簡素化されています。エラーメッセージには正確な行番号と列番号が含まれています。数値と文字列の解析はユーザー自身で行う必要があり、`strtod`や`atoi`などの関数を使用できます。簡単な例として、JSON文字列から矩形構造体`Rect`への読み込み方法を示しています。このプロジェクトは、パブリックドメインで公開されているフリーで無制限のソフトウェアです。
arXivLabsは、共同作業者がarXivの新しい機能を直接サイト上で開発・共有できるフレームワークです。arXivLabsと協力する個人や組織は、オープン性、コミュニティ、卓越性、ユーザーデータのプライバシーという私たちの価値観を共有しています。arXivはこれらの価値観にコミットしており、これらの価値観を共有するパートナーのみと協力しています。arXivコミュニティに価値をもたらすプロジェクトのアイデアをお持ちですか？arXivLabsの詳細をご覧ください。
Space Station 14をARM64 Windowsに移植する際に、開発者は奇妙なクラッシュに遭遇しました。デバッグの結果、問題はウィンドウモードゲームのためのMicrosoft DXGIの最適化に起因することが判明しました。この最適化は「flip」モードを強制的に有効にするため、特定の状況下（ゲームの実行ファイル名がSS14.Loader.exeの場合）でGetDC()関数に関連する不正な命令例外が発生します。これは、MicrosoftのARM64 DXGI最適化のバグであり、特定のゲーム名でのみ有効化されることがわかりました。Space Station 14はこのリストに含まれていました。開発者は、ネイティブARM64 Windowsゲームの数が少ないため、このバグは見過ごされていたと推測しています。この問題はMicrosoftに報告されており、バグが修正されるまで、ARM64 Windowsのサポートは一時的に延期されます。
Vecは、C言語向けの汎用的で高速、メモリリークのない動的配列です。連続メモリを使用し、幾何級数的に（×2）サイズを拡大することで、償却O(1)のpushを実現し、メソッドスタイルのAPIを提供します。オーバーフローガード、境界チェック付きアクセサ、空/縮小/破棄時の明確な動作定義など、安全性を重視した設計となっています。パフォーマンスと安全性を両立させ、クリーンで効率的なインターフェースを提供します。
1974年のHoneywell Multicsシステムのセキュリティレビューで「バックドア」への懸念が指摘されて以来、2024年のDebianシステムを標的としたXZ攻撃に至るまで、オープンソースソフトウェアサプライチェーンセキュリティは持続的な問題となっています。この記事では、この問題の複雑さを探求し、単純な依存関係グラフを超えて、ソフトウェアのビルドと配布のあらゆる段階、そして人的要因を含んでいます。ソフトウェアの認証、再現可能なビルド、脆弱性の迅速な検出と修正、より安全なプログラミング言語の使用など、さまざまな解決策を提案しています。特に、資金不足によりプロジェクトが悪意のある乗っ取りを受けやすくなるため、オープンソース開発の資金調達を重視しています。XZ攻撃は、一見無害な「無料の助け」が大きなリスクを隠していることを示す明確な警告となっています。
同僚が関数型プログラミングのスタイルを批判したため、プログラマはマネージャーから関数型プログラミングの使用を禁止された。職を維持するため、彼は渋々、同僚をリストする単純な関数を命令型プログラミングで書き直す。しかし、関数型パラダイムを避ける努力にもかかわらず、完全に遵守することは難しく、コードレビューで新たな課題に直面し、最終的にはマネージャーに助言を求める羽目になる。このユーモラスな逸話は、職場における恣意的な技術的決定の不条理を浮き彫りにしている。
9ヶ月間の開発を経て、Bluefin LTS（長期サポート版）とBluefin GDX（AIワークステーション版）が一般公開されました。CentOS Stream 10をベースとしたBluefin LTSは、安定したGNOME 48デスクトップと長期サポートを提供し、新しいカーネルのためのオプションのハードウェア有効化ブランチ（lts-hwe）も用意されています。Bluefin GDXはAI/MLのプロフェッショナルをターゲットとし、NvidiaドライバとCUDAを統合し、Red Hatと協力してオープンソースのAI/MLツールを開発しています。どちらのバージョンも、改善されたインストール体験とセキュアブートのサポートを備え、安定性と効率性の高いデスクトップエクスペリエンスを目指しています。
PostgreSQL 18ベータ版がリリースされました。最も期待されている機能の1つは、UUIDv7のネイティブサポートです。タイムスタンプベースのUUIDバリアントであるUUIDv7は、データベースの主キーとして使用される従来のUUIDに固有のソートとインデックスの局所性の問題を解決します。グローバルに一意の識別子と時間的順序付けの説得力のある組み合わせを提供し、高性能とスケーラビリティを必要とする分散データベースに最適です。PostgreSQL 18のその他の性能向上には、非同期I/Oとインデックスの最適化が含まれます。
macOS Monterey 12.0.1のディスクユーティリティは、APFSディスクの修復時にボリュームまたはコンテナをアンマウントできないという長年のバグに引き続き悩まされています。この記事では、リカバリモードでディスクユーティリティを使用するか、コマンドラインツール`fsck_apfs`を直接使用してAPFSボリュームとコンテナをチェックおよび修復するなどの回避策を提供します。この記事では、`fsck_apfs`の使い方、チェックと修復のオプション、暗号化されたボリュームの処理方法について詳しく説明します。
この記事では、モデルキャリブレーションにおける一般的な問題点について論じています。それは、キャリブレーションデータセットが元のトレーニングデータセットよりもはるかに小さいため、等尺性回帰によって確率分布が過度に単純化され、モデルの細かい違いが失われるという問題です。この記事では、この「データの希薄性によって引き起こされる平坦化」現象を分析し、ノイズによる正当な単純化とデータの制限による過剰な単純化を区別するためのいくつかの診断方法を提案しています。最後に、等尺性制約を緩和したり、滑らかな単調モデルを使用したりすることで、キャリブレーション精度を維持しながら、元のモデルの識別能力を可能な限り維持するCalibreパッケージを紹介しています。
AIのコーディングにおける役割は、プログラマーを完全に置き換えることからは程遠く、むしろベテラン開発者の効率向上ツールとして機能しています。AIは定型コード、反復作業の自動化、迅速なイテレーションに優れていますが、コードレビュー、アーキテクチャ設計、コード品質、セキュリティ面では不足しています。そのため、現状では「ベテラン開発者＋AI」の組み合わせが、「若手開発者＋AI」よりも効果的です。AIの最適な活用例は、迅速なプロトタイピング、ルーチン作業の自動化、異分野の連携、単純な機能テストです。AIはコーディング分野に大きな可能性を秘めていますが、生成されたコードの人間による精査は不可欠であり、期待値は現実と整合性が取れているべきです。
AI支援コーディングの普及により、大きな課題が生じています。「vibe coding」による混乱です。AIは効率的にコードを生成しますが、多くの場合、アーキテクチャの堅牢性、セキュリティ上の考慮事項、システムコンテキストの理解が不足しており、大規模なコードのリファクタリングが必要となります。新たな職業が登場しました—AIコードクリーナーです。彼らは低品質のAI生成コードの修正を専門とし、高額な料金を請求します。市場調査によると、2028年までに企業ソフトウェアエンジニアの大半がAIコードアシスタントを使用するようになり、AIコードクリーンアップ市場の巨大な成長機会を示唆しています。ソフトウェア開発の未来は、AIが初期の実装を処理し、人間がアーキテクチャ、テスト、クリーンアップを処理するようになるでしょう。AIコードクリーンアップに精通したエンジニアは、非常に需要が高まるでしょう。
このブログ投稿は、カリフォルニア工科大学CS179：GPUプログラミングコースの最終プロジェクトの詳細を説明しており、Feng et al.の論文「Were RNNs All We Needed？」の主張を検証しています。このプロジェクトでは、簡略化されたminGRUとminLSTMモデル、およびカスタムCUDA並列スキャンアルゴリズムを実装しました。結果は、長いシーケンスに対してGPUによる大幅な高速化を示し、RNNの再帰を並列化できるという論文の中心的な発見を検証しています。しかし、短いシーケンスでは、CUDAカーネルの起動オーバーヘッドがパフォーマンスの向上の一部を打ち消しました。GPUカーネルのプロファイリングにより、最終的な射影層が主なボトルネックであることが明らかになり、単一のcuBLAS GEMM呼び出しによるさらなる最適化を示唆しています。
静的型付けゲームスクリプト言語を開発中に、著者はヘテロジニアスデータの処理に課題に直面しました。この記事では、null、バリアント型、タグなしユニオン、サム型、サブタイピングなど、様々なプログラミング言語で用いられる解決策を探求しています。最終的に、著者はPascalのバリアントレコードに似たアプローチを選択し、簡潔な構文と実行時型チェックのバランスを取っています。これにより、フロータイピングの複雑さを回避し、より理解しやすく使いやすい言語となっています。これは、静的型付けの安全性と使いやすさを両立させた巧妙な設計であり、ゲーム開発にとってより便利なスクリプト言語ソリューションを提供します。
この記事では、npmエコシステムにおける過剰設計されたライブラリの増加について考察しています。多くのライブラリは稀なエッジケースの処理を優先しており、結果として過度に細分化された依存関係ツリーが生じています。著者は、`is-number`ライブラリを例に挙げています。このライブラリは様々な数値のような入力を処理しますが、実際には多くのアプリケーションでは`number`型のみを処理すれば十分です。提案されている解決策は、ライブラリが一般的なユースケースに焦点を当て、入力タイプの妥当な仮定を行い、エッジケースの処理を必要とするプロジェクトに任せることです。これにより、コードが簡素化され、パフォーマンスが向上し、不要な依存関係が削減されます。
新しい言語を効率的に学習するには、語彙を迅速に拡大する必要があります。この記事では、語彙学習の効率を最大化するための本の選択問題について探求しています。単一の本を選択することは比較的簡単ですが、より多くの語彙を網羅するために複数冊の本を選択することは、NP困難問題になります。つまり、正確な解を求めるための計算時間は、本の数に応じて指数関数的に増加します。幸いなことに、この問題は劣モジュラ問題に分類されるため、近似アルゴリズムを使用して、特定の精度内でほぼ最適な解を見つけることができます。この記事では、貪欲アルゴリズムとその改良点を紹介し、効率的なPythonライブラリsubmodlibを推奨しています。
2009年、若いマイクロソフトのBitLocker開発者は、BitLockerのエラーメッセージを改善するために、.mcファイル内でC++定数値を参照する方法を探しました。社内メーリングリストに問い合わせたところ、レイモンド・チェンから簡潔ながらも効果的な回答が得られました。プリプロセッサを使うというものです。しかし、複雑なWindowsビルドシステムを壊すことを恐れて、開発者は最終的にこの方法を諦めました。数年後、彼はこの経験を振り返り、マイクロソフトの内部ツールの欠点と、複雑なビルドシステムを避ける自分の傾向を指摘しています。
この記事では、Bazelキャッシュ、リモート実行、そして異なる環境でのglibcバージョンの違いが相互作用して本番環境でクラッシュが発生した事例について説明します。開発者はローカルで変更をビルドしてテストし、CIはキャッシュを利用してリリースビルドを作成しますが、本番環境へのデプロイは 'GLIBC_2.28' バージョンがないために失敗します。この記事では、glibcバージョンの不一致がどのようにビルドの再現性を損なうかを分析し、いくつかの解決策を提示します。簡単な回避策としては、ローカルとリモートのglibcバージョンを取得し、C++ツールチェーンに高い方のバージョンを使用する方法があります。より堅牢な解決策としては、アクションキャッシュへの書き込みを制限し、ビルドをリモートエグゼキュータで強制的に実行する方法があります。究極の解決策は、sysrootsを使用し、すべての環境に複数のglibcバージョンをインストールし、使用するバージョンを明示的に指定する方法です。この記事では、再現可能なビルドの重要性を強調し、状況に応じて適切な解決策を選択することを推奨しています。
1984年の初代Macは、8MHzのMotorola 68000プロセッサを搭載しており、一度に1つのアプリしか実行できませんでした。しかし今日のMacは、複数の大きなアプリを同時に快適に実行し、Time Machineバックアップやその他のバックグラウンドタスクも実行できます。この記事では、シングルタスクの初期から、SwitcherやMultiFinderの導入、Mac OS Xにおけるプリエンプティブなマルチタスクとマルチスレッディングの導入、そしてGrand Central Dispatch (GCD)によるパフォーマンス最適化までの進化をたどります。そして、最大32個のCPUコアを効率的に管理するに至るまで、AppleのmacOSパフォーマンス向上への絶え間ない努力が示されています。
著者は25個の同一の木製ピースからなる複雑な3Dパズルを受け取り、手作業で解くことに苦労した後、Haskellプログラミング言語の力を利用することに決めました。これは、問題のモデリングに焦点を当てた2部構成シリーズの最初の部分です。著者は空間を3Dグリッドとしてモデル化し、ベクトルを使用して位置を表し、単一のピースとその空間における配置のためのデータ構造を定義します。この記事では、線形代数とHaskellの機能を使用してピースの回転と並進を表し、可能な配置の候補リストを生成する方法を詳細に説明しています。この記事は、候補の中から正しい配置を見つける解決策をパート2に残して、スリリングな結末を迎えます。
スレッドアプリケーションのパフォーマンス向上を目指したLinuxカーネルの再起動可能なシーケンス機能は、新しいカーネル機能と共に使用が増加しています。しかし、これによりいくつかの問題が明らかになりました。開発者のThomas Gleixnerは最近、コードを改善し、パフォーマンスのボトルネックと歴史的な問題に対処しました。これらの変更により効率性が大幅に向上しますが、ユーザー空間でABIの変更が必要になる可能性があり、互換性を確保するために徹底的なテストが必要です。
AzureのLLMと音声モデルを使って製品開発を行っている開発者が、懸念すべき傾向を発見しました。同じモデルが時間の経過とともに徐々に性能が悪化しているのです。同一のシステムプロンプトとメッセージを使用しても、GPT-4o-miniとGPT-5-mini/nanoの両方のレスポンスの精度が著しく低下しました。GPT-5は当初は優れていると期待されていましたが、古いGPT-4o-miniよりも遅く、精度も低いことが判明しました。開発者は、Microsoftが古いモデルを意図的に劣化させ、ユーザーをより新しく、信頼性の低いバージョンに誘導していると疑っています。このやり方はユーザーエクスペリエンスを損ない、開発者が他のプラットフォームを探す原因となる可能性があります。
%20(1).png)
多くのnpmパッケージがnpmレジストリから削除され、React、Angular、NativeScriptなどの様々なフレームワークのコンポーネントやツールに影響が出ています。影響を受けたパッケージは、完全に削除されたものから、バージョンが修正されたものまで様々です。この出来事は、開発者にとって、依存関係の保守とセキュリティに対する注意喚起となります。プロジェクトの依存関係を確認し、必要な措置を講じて中断を回避することが不可欠です。削除の理由は、セキュリティ上の脆弱性、保守の問題、その他の要因が考えられます。
この記事は、Microsoftが所有するプラットフォームであるGitHubを使用することの問題点を明らかにしています。ユーザーコントロールの制限、中央集権化されたモデル、テレメトリーデータによる追跡、GitHub ActionsやCopilotなどの機能によるベンダーロックインといった問題点を指摘しています。さらに重要なことに、ICEへのクラウドサービス提供やイスラエル国防軍へのAI技術提供など、米国政府やイスラエル軍との物議を醸すパートナーシップの詳細が記述されており、社内従業員の抗議につながっています。著者は、オープンソースの精神と独立性を維持するために、ForgejoやSourcehutなどの自己ホスティングソリューションへの移行を推奨しています。
C++標準化委員会は、メモリ安全性に関する懸念が続くなか、厳格に安全な言語サブセットを作成するための詳細な提案を却下しました。提案の共同執筆者であるSean Baxter氏は、委員会でRustの安全モデルが不人気であること、代わりに「Profiles」アプローチを優先していることを挙げています。ProfilesアプローチはBjarne Stroustrup氏などから支持されていますが、その実現可能性は疑問視されており、C++26への収録も見込みがない可能性があります。この決定は論争を招き、開発者の中には、RustやGoogleの実験的な「C++の後継」Carbonプロジェクトなどの、より安全な言語への移行がより良い解決策だと示唆する者もいます。
Linuxシステム管理者にとってよくある問題として、デーモンが通常のシステム設定では起動に失敗するが、root権限で手動実行すると正常に動作するというものがあります。従来の原因としては、環境変数$PATHの設定が不完全であること、SELinux、AppArmorなどが挙げられます。近年では、systemdサービスユニットの制限（systemd.execに記載）が原因となるケースが増えています。ProtectHomeやPrivateTmpなどのディレクティブにより、「アクセス拒否」や「ファイルが見つかりません」といった分かりにくいエラーが発生したり、DNSクエリがブロックされるといった間接的な障害が発生したりします。デーモンの.serviceファイルから制限を削除することで問題の診断に役立ちますが、将来のデーモンはこれらの制限に依存する可能性があり、トラブルシューティングが複雑になる可能性があります。
この記事では、Linuxシステムコールのパフォーマンスオーバーヘッドを深く掘り下げ、それが単なるカーネル関数呼び出し以上のものだと明らかにします。システムコールは、命令パイプラインや分岐予測などのCPUのマイクロアーキテクチャの最適化を妨げ、ソースコードからは明らかでないパフォーマンスの損失につながります。この記事では、カーネルコードを分析し、さまざまなソフトウェアとハードウェアの軽減策のパフォーマンスへの影響を説明し、vDSOの使用、値のキャッシング、I/Oの最適化、バッチ処理、カーネルへの作業のプッシュなど、システムコールの頻度を削減し、ソフトウェアのパフォーマンスを向上させるための最適化戦略を提案します。
この記事では、三次ベジェ曲線をイージング関数として直接表現することでアニメーションのパフォーマンスを向上させる、シングルヘッダーのC++20ライブラリを紹介します。`EasingCubicBezier`テンプレートクラスを使用して実装されており、PRECISE（高精度）とFAST（高性能）の2つのモードを提供しています。ベンチマークテストでは、このアプローチがBlenderのアルゴリズムやニュートン・ラフソン法に基づく数値解法よりも高速で安定性が高いことが示されており、特にリアルタイムアニメーションシステムにおいて大きなメリットがあります。これは、実行時に三次多項式方程式を解くオーバーヘッドを回避するためです。
GitHub Actionsは、2026年4月にNode.js 20のサポートを終了することを発表しました。2025年秋にはすべてのActionsをNode.js 24に移行する予定です。最新のGitHub runnerは既にNode.js 24をサポートしており、環境変数を設定することで事前にテストできます。2026年3月4日からはNode.js 24がデフォルトになります。環境変数を設定することでNode.js 20を一時的に使い続けることができますが、夏には完全に削除されます。Node.js 24はmacOS 13.4以前のバージョンとは互換性がなく、ARM32アーキテクチャのセルフホスト型ランナーもサポートされません。