2024-07-13「大吉祥寺.pm」の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。
![Linux コンテナの歴史を追うとコンテナの仕組みがわかる / Dai Kichijoji pm](https://cdn-ak-scissors.b.st-hatena.com/image/square/25fe52a092768437f70ad8aa862b8b9e912a6b74/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F310cddf29ea24ef48a726e553546da82%2Fslide_0.jpg%3F30966131)
最近、ローカルLLMがアツくなっているという話をtwitterでチラホラ見かける。 ローカルLLMって何じゃ?というと、オープンに公開されているモデルのウエイトをDLしてきて手元のPC上で推論させる事である。 オープンなAIモデルとは逆の存在として、モデルがDLできないクローズなAIモデルもある。 OpenAIやAnthropicのような最先端AI企業のクローズなAIモデルに比べて、オープンに公開されているオープンなAIモデルの性能は今でもかなり後れを取っている。 だから去年の間はあくまでAIの本命はChatGPTのようなクローズモデルであって、オープンなAIモデルなんて眼中にありませんみたいな風潮が無くはなかった。だが最近は風向きが少々変わってきている。 GPTのAPI高い問題 & OpenAIがAIベンチャー皆殺しにしてしまう問題 まず「結局GPTのAPIを叩いてサービス運営して成功し
Android Weekly Topics 脱Android、Huaweiが独自OS「HarmonyOS NEXT」を発表 2024年1月19日に、Huaweiが自社製の「HarmonyOS NEXT」を発表しました。 開発者向けにはプレビュー版がリリース済みで、2024年の第4四半期にはリリースが予定されています。 HarmonyOS NEXT Developer Preview | 华为开发者联盟 HarmonyOSと言えば…… 米トランプ政権時代、Huaweiは安全保障上の懸念から米国企業との取引を禁じられました。これにより、GoogleのGMS入りのAndroidが使用できなくなったために、独自に開発したHarmonyOSが登場しました。タブレットは残っているものの、これにより国内ではスマホを見ることがなくなり、Huaweiはウェアラブルデバイス専業メーカの印象が強くなりました
Rustを第二言語として採用してデバイスドライバなどのモジュールをRustで書けるようにする「Rust for Linux」が近々マージされる予定だともLinus氏自身が発言しています。 そんな期待のかかるRust for Linuxですが、提案された当初は期待こそされていたものの、様々な懸念点も指摘されていました。 その1つが標準ライブラリの一部であるallocクレートの設計です。 このクレートはヒープ領域を扱うBox、Vec、StringなどRustではお馴染みの構造体を提供しています。 Rustの標準ライブラリはOSのサポートを前提とした構造体も多くあります。そのため、OSそのものを書くようなベアメタルプログラミングにおいて標準ライブラリをそのまま使うことはできません。 使えるのはcoreと呼ばれる依存関係のない全く無いライブラリがありますが、allocはOSのサポートが必要なヒープ
Steven J. Vaughan-Nichols (Special to ZDNET.com) 翻訳校正: 村上雅章 野崎裕子 2022-03-04 11:33 LinuxカーネルがCで記述されているというのは誰もが知るところだ。ただ、そのCがかなり昔のC、すなわち1989年の規格である「C89」だという事実については知らない人もいるかもしれない。C89は「ANSI X3.159-1989」、あるいは「ANSI C」としても知られている。Linus Torvalds氏は、そろそろC89に別れを告げる時だと判断し、Linuxカーネルの公式な開発言語を2011年規格の「C11」に移行しようとしている。 これは見かけほど大きな変更ではない。C89は現在でもほぼ普遍的にサポートされている。どのようなCコンパイラーでも以前の規格との後方互換性を備えているため、C89で記述されたプログラムのコンパイ
0 fgets <internal>:-1 1 <main> <internal>:-1 0 fgets <internal>:-1 1 <main> <internal>:-1 0 fgets <internal>:-1 1 <main> <internal>:-1 ... 0 time_nanosleep <internal>:-1 1 PhpProfiler\Lib\Loop\LoopMiddleware\NanoSleepMiddleware::invoke /home/sji/work/php-profiler/src/Lib/Loop/LoopMiddleware/NanoSleepMiddleware.php:33 2 PhpProfiler\Lib\Loop\LoopMiddleware\KeyboardCancelMiddleware::invoke /home/sji/
Steven J. Vaughan-Nichols (Special to ZDNET.com) 翻訳校正: 村上雅章 野崎裕子 2021-03-31 07:30 Linuxはプログラミング言語Cの申し子のような存在だ。しかし時は流れ、状況は変わった。RustをLinuxのシステム記述言語として採用しようという動きが少しずつ支持を集めてきている。例を挙げると、Linuxカーネル開発者のための年次カンファレンス「Linux Plumbers Conference(LPC)2020」において、開発者らはLinuxのインラインコード部分でのRustの採用を真剣に議論していた。その議論は現在どうなっているのだろうか?筆者はLinuxの父と目されるLinus Torvalds氏と、Linuxの安定版カーネルのメンテナーであるGreg Kroah-Hartman氏から考えを聞いた。 これはRustに魅
5/27にWindows 10 2004 Updateが正式リリースされて、それに伴いWSL2もWindows Insider Preview版を使用しなくても利用可能となりました しかしWSL2を使用してるとVmmemというプロセスのメモリ使用量が増加し続けて、Windowsホストのメモリが枯渇してしまう問題があります。そしてこの問題は正式リリース後も解消されず残っています。 NOTE: Windowsホストで動いているVmmemプロセスで「WSL2のHypver-V仮想マシン全体が消費&確保しているCPUとメモリ」を確認できるという大雑把な理解でOKです。 microsoft/WSLのIssueは1年近くOpenのままとなっており、Microsoft側も問題を認識して取り組んでいるものの未だに根本対処されていません。 本問題のアップデート情報 (2023/07/04更新) 本問題に関す
現在プレビュー中の20H1のビルド19013から、WSL2(Windows Subsystem for Linux 2)は、一旦確保したメモリでも不要になれば、きちんとWin32に返すようになった。今回はこのあたりを調べてみる。 WSL2におけるメモリ割り当て WSL2は、軽量ユーティリティ仮想マシン(Light Weight Utility Virtual Machine:以下、LWUVM)内で動作している。このため、ホストとなるWindows 10のメモリの一部を利用する。ただし、メモリ割り当ては、Hyper-Vでいう動的メモリ割り当てであり、上限を決めるものの、実際に使っている分のみを確保して、必要になれば上限までメモリを確保しようとする。 この上限は、WSL2側からは「実装メモリ量」のように見える。デフォルトでは、PC側のメモリの75%をWSL2の上限として割り当てているようだ。た
メモリのように書けて永続化される次世代ストレージデバイスNVDIMMの扱い方を解説します これは2019年10月19日に行われる予定だった カーネル/VM探検隊@北陸 5回目(台風の影響で中止) での発表資料です サンプルコード: https://github.com/Fadis/kernelvm_20191019_samples
「C」や「C++」に代わるシステムプログラミング言語として「Rust」が注目を集めている。メモリ安全性が高く、メモリ破壊バグといった脆弱(ぜいじゃく)性を作り込みにくいからだ(関連記事)。 ただし、システムプログラミング言語では、高い処理性能が必須条件であり、これがCやC++が使われ続けている理由となっている。Rustはどの程度「速い」のだろうか。 ドイツのミュンヘン工科大学で博士課程の学生であるポール・エメリク氏は2019年9月9日、Rustで作成したデバイスドライバの性能評価をGitHubで発表した。 同氏のグループはさまざまな言語で同じ機能を備えたデバイスドライバを記述し、性能を比較している。 何が性能低下を引き起こしているのか 性能評価用に作成したのは、Intelのイーサネットコントローラー向けのLinux用デバイスドライバだ(ixgbeタイプ)。 エメリク氏は解説の冒頭で研究に取
どうも、前回の記事が思っていたよりも反響があり、Blogを書くモチベーションが高まり、また記事を書くことにします。 ↑とか書いたんですが、このへんまで書いて50日くらい記事を書くのを放置していたので、ちゃっちゃと書き上げることにします。 今回はx86なCPUに存在するControl Registerのうち、CR0に存在するCache Disableフラグを操作するカーネルモジュールをLinux、FreeBSDのそれぞれ向けに作ったのでそれについて記述します。 それでは、続きからどうぞ。 はじめに、作成したカーネルモジュールのリポジトリへのリンクを掲載します。 Linux版のカーネルモジュール(procfsとして実装) cr0cd FreeBSD版のカーネルモジュール(キャラクタデバイスとして実装)cr0cd_fbsd そもそもこれはなに 一言で言うと、メモリのキャッシュ(L1, L2, L
A History of system-level offensive security researches: How is your system compromised by nation state hacking, APT attack はじめに 企業や個人に対するサイバー攻撃の頻度は年々増加の一途を辿っているが、これらはskiddyによる悪戯程度の物から、企業を標的とした高度な標的型攻撃、あるいは政府による諜報活動に至るまで多岐にわたっている。 特に大規模な組織や政府による綿密に練られたサイバー攻撃は、確実に目的を果たすために高度な手段が講じられる事が多い。 本記事では高度標的型攻撃や政府による諜報活動で用いられる手法の一つとして、"システムソフトウェアに対する攻撃"について紹介する。 これはオペレーティングシステム (OS) や仮想マシン、ファームウェアといった基盤システムを
Rust言語による新しいDockerコンテナランタイム実装「Railcar」、オラクルがオープンソースで公開。なぜRustでコンテナランタイムを実装したのか? Rust言語で実装したコンテナランタイムの「Railcar」を、オラクルがオープンソースとしてGitHubで公開しました。 Railcarはコンテナランタイム標準であるOCI(Open Container Initiative)に準拠してているため、Dockerのバックエンドとしても利用可能と説明されています。 なぜDockerをRust言語で実装するのか Railcarの公開を明らかにしたOracle Developers Blogに投稿された記事「Building a Container Runtime in Rust」によると、Rust言語でコンテナランタイムを実装した理由が次のように説明されています。少し長いのですが、引用し
自分が書いたプログラムのメモリ使用量を測定したいことがある。プログラムがOOM Killerによってお亡くなりになった場合や、ページフォルトをなくして高速化したい場合などだ。定常的に起動するサーバーのプログラムなら、sarや meminfo など(今なら Datadog とかだろうか)を使ってじーっと見つめるわけだ。もっとモダンにやるなら perf や DTrace を使ってもよいかもしれない。しかしこれらのツールは基本的にプロセスIDを渡してサンプリングして外から覗く方法だ。 わたしのユースケースはデーモンプロセスではなく、 main から入って必要な計算をして、それが終わったら main を抜けるバッチジョブ(単にコンソールから実行して終わるまで待つ、いわゆる "Hello world!" 的なやつ)だ。これだと、プログラムが起動して終わるまでそこそこの時間で終わってしまって、外部プロ
私が最近注目しているプログラミング言語がある。Rustだ。Rustとは、錆のことである。何が錆なものか。JJだ。 RustはMozillaが開発しているプログラミング言語である。恥ずかしいことに私はRustの存在をつい最近まで知らなかった。私がRustの存在を知ったのはkernelvmでのことである。発表をustで聴いたあと自分で調べるとなるほどこれは私の望んでいた言語だと思った。そしてそれは、Linuxコミュニティが望んでいた言語でもあったのだ。 昨今、Go言語なるものが流行っている。猫も杓子もDockerの実装言語として採用されているためだ。しかし、Goは私のテイストに合わない。プログラミング言語というのは、異性のようなもので、一目見ただけで良いとか悪いとか感じるものである。これがまさにテイストということであり、言語にこだわりがないなんて人は、「誰でも良い」と言ってるようなものである。
先日 GHOST と呼ばれる glibc の脆弱性が発表された。なんでも、「リモートから任意のコードを実行できる可能性がある」らしいではないか。しかも様々なプログラムで利用されているライブラリ部分の問題とあって、影響範囲がとても広い。なかなか厄介なことである。 はて、しかし一体全体どうやってリモートから任意のコードを実行しようというのだろう? 話を聞くに、たかが数バイトの情報を範囲外のメモリに書き込める可能性があるだけだという。実際それだけのことでサーバーの乗っ取りなどできるものなのだろうか。そんなわけで、その疑問に答えるべく、本記事では以下の URL で解説されている実際の攻撃方法を若干端折って紹介してみようと思う。 http://www.openwall.com/lists/oss-security/2015/01/27/9 なお、本記事はこの脆弱性そのものに対する緊急度などについて言
glibcのgethostbyname系関数に脆弱性の原因となるバグが発見されCVE-2015-0235(GHOST)と命名されたようです。放置した場合は相当多くのアプリケーションがこの脆弱性の影響を受けることが予想されます。 glibcは libcのGNUバージョンです。libcはアプリケーションではなく、事実上全てのアプリケーションが利用しているライブラリです。OSの中ではカーネルに次いで重要な部分と言えます。Linuxシステムでは(ことサーバー用途においては)例外なく glibcが使われています。 この glibcに含まれる gethostbyname系関数の実装に 2000年頃から存在したバグが今になって発見され、CVE-2015-0235 通称 GHOSTと命名されました。ネットワークで何らかの通信を行うアプリケーションは必ず※この関数を使用します。 ※追記: 名前解決をサポート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く