サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
2025-07-06 設定ファイルと起動オプションに不備があったので修正しました。今度こそ大丈夫です！！！！！ 2025-07-09 設定ファイルに不備があり、セッションの更新がされずAPIエラーになる事象を修正しました。本当に今度こそ大丈夫だと思います！！！！！！！ 2025-07-10 挑戦に失敗はつきもの Claude Codeくんは便利ですが、ちょっとドジなところもあるので目を離すのはちょっとこわいですね。 このようなときはVMやコンテナで開発環境を完全に隔離すれば安全安心が手に入るわけですが、プロジェクトごとに設定するのは面倒くさい。 悪意のないAIのうっかりミスを防げる程度の軽量なサンドボックスがあると嬉しいのですが、Macには意外と手頃なものがないんですね。 普段dev containerを使ってる人ならそれで良さそうですが、わたしはMac上で直接開発したいので……。 ところ
A deep dive intoApple’s Darwin OS and XNU kernel architecture, tracingits evolution fromMach and BSD roots to poweringmacOS, iOS, andApple Silicon. This post explores the hybrid kernel’s design,its adaptation to new hardware andsecurity paradigms, and why XNU remains a uniquely resilient andscalable foundation forApple’s platforms. This post is the result of megoing down a several week l
こんにちは。JuliaのPlots.jlでフォントが正しく表示されない問題にハマったので、その時の解決法を書いておきます。 Plots.jlでヒラギノ角ゴシックを使おう！ 環境macOS Sequoia 15.3.2Julia 1.11.3 Plots 1.40.11 GR 0.73.13 結論 using Plots using Unicode gr() @eval Plots begin function gr_set_font( f::Font, s; halign = f.halign, valign = f.valign, color = f.color, rotation = f.rotation,) family = lowercase(f.family) GR.setcharheight(gr_point_mult(s) * f.pointsize) GR.setch
ミッチェル・ハシモト氏の個人開発によるターミナルエミュレータ「Ghostty 1.0」、12月に正式リリース予定。オープンソースとして公開へ HashiCorpの創業者の一人であるミッチェル・ハシモト氏は、個人のプロジェクトとして開発してきたターミナルエミュレータ「Ghostty」のバージョン1.0を今年（2024年）12月にリリースし、合わせてオープンソースとして公開することを明らかにしました。 ハシモト氏は2023年12月にHashiCorpを退職。その後、個人プロジェクトとしてターミナルエミュレータの開発をしていることをX/Twitterなどで以前から発信していました。 これは2023年5月のポストです。「ここ数年、なんとなく自分用のターミナルエミュレーターを作っていた。過去18カ月、これを自分だけのターミナルとしてフルタイムで使っている」と書いていることから分かるとおり、Hashi
Pluralistic 「Macカルト（Cult ofMac）」の基本的な教義は、時価総額3兆ドル企業から製品を購入すると迫害されたマイノリティの一員になれるということであり、したがってその企業へのあらゆる批判は民族的中傷ということになるらしい。 https://pluralistic.net/2024/01/12/youre-holding-it-wrong/#if-dishwashers-were-iphones これを「Apple例外主義」と呼ぼう。ビッグテック企業の中でAppleだけが善良であり、したがってその行動は善意のレンズを通して解釈されるべきだという考え方である。この美徳の源泉は都合よく曖昧なので、Appleの罪が明らかになったとて、Macカルトのメンバーはどこまでもゴールポストを移動させる。Appleが「プライバシーを尊重している」という主張を考えてみよう。これは、A
![メタクソ化するアップル――Macカルトと“アップル例外主義” » p2ptk[.]org](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f1104bd774ee83cd14eeb72bb1d28cf0ca3935fc2%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fp2ptk.org%252Fwp-content%252Fuploads%252F2024%252F05%252Fapple-antitrust-doj.jpg&f=jpg&w=240)
ホットエントリに挙がっていたこの記事に触発されて書きました。 はじめに 私は、さすらいの野良エンジニアです。システム開発歴は20年以上になり、現在は在宅で仕事をしています。先日ふと思い立って、サブで使っていたラップトップにUbuntuを入れました。その結果あまりに良すぎてメイン環境として普段使いするようになり、ラップトップではゲーミング性能が足りないので、余っていたデスクトップ機にもインストールして更に快適になってしまいました。 以降前の私の状況は下記です。 メインで使っていたのは、Windowsデスクトップ(RTX2060でゲームもする) サブ機としてM1MacbookAirとWindowsラップトップ(XPS13)を使っていた その他、N100ミニPCにUbuntuを入れてちょっとしたサーバーとして使用Windowsデスクトップ(RTX2060)が一台余っていた ここから、現在の
日本語表記ルールの目的と方向性 表記ゆれをなくしたい 日本語は表記ゆれを起こしやすい言語。同義語が多く存在するし、一つの文章内にひらがな／カタカナ／漢字／アルファベットが混合し、同じ読みの単語ですら文字種の混ぜ方によっていく通りものバリエーションが存在する。何も考えずに闇雲に混ぜ合わせると読みにくい文章が生まれてしまう。そのため新聞や雑誌では書き手が異なる記事が混在していても読みやすいよう全体で統一した表記ルールを持っている。 これはコンピュータのユーザインターフェイス（UI）でも同じ話。考えてみればユーザがアプリケーションを行き来しながら画面の断片にその都度注目する行為は新聞で複数の記事をまたぎながら流し読みするのと似たようなものだ。 とはいえ UI においては短いテキストが多いためルールの重要性が想像しにくいかもしれない。ここで一つの例を考えてみよう。ほとんどのアプリケーションで編集メ
実行環境Macbook Pro 16 M1 Max 32 coregpunpakaさんの記事ではmetal利用の高速化の影響が確認できなかったとのことでしたが私の環境ではmetalを使った方が高速化したので報告しておきます。 llama.cppのリポジトリはクローン済の前提でバージョン的には下記のコミットのあたりを含む最新バージョンです llama-2-13b-chat.ggmlv3.q4_0.binのWeightはwgetでダウンロード済。 ビルドとかも野良スクリプトでLLAMA_METAL=1で実行しました。 llama.cppクローンとビルドとモデルダウンロード# Clone llama.cpp git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp #Buildit LLAMA_METAL=1 ma
著者：関 勝寿 公開日：2021年4月22日 キーワード： video オンライン授業などで動画を作成する機会が増えた。動画は短めに作成してMacのQuickTimeで結合している。異なるアスペクト比（縦横比）の動画を結合する際に、まずはFFmpeg によってアスペクト比を変換する方法についてまとめる。FFmpeg のインストール 動画の変換にはFFmpegが便利であり、Homebrewをインストールしてから brew installffmpeg でインストールできる。ffmpeg を使えば、さまざまなファイル形式の動画ファイル INPUT_FILE をffmpeg -i INPUT_FILE -pix_fmt yuv420p output.mp4 のように、INPUT_FILE をQuickTimeで再生できるYUV420 形式のmp4 に変換することができる。 アスペクト比の変
Docker Desktop forMacDocker Desktop forMacでは、仮想マシン上のLinuxでDockerを動かしている。仮想マシンにはhyperkitやQEMUが使われていた。が4.14.0からVirtualization frameworkがデフォルトで使われる。 Set Virtualization framework as the default hypervisor formacOS >= 12.5. Virtualization frameworkはmacOS内蔵の仕組みで、macOS 11で導入されてから、徐々に機能が拡張されている。Virtualization frameworkは高レベルなAPIで、より低レベルなAPIとしてmacOS 10.10から搭載されているHypervisor frameworkがあり、おそらくVirtualizati
Apple SiliconMac(M1、M2) で Lima を使ったLinux VMs withRosetta 上で intel x86-64のdocker container イメージを実行するDockercontainerLimaRosettaAppleSilicon はじめに M2Macも発売され、そろそろintelMacで開発している方々も少数派となってきているのではないでしょうか。 M1、M2といったApple SiliconMacのCPUはARMアーキテクチャを採用している一方、多くの開発ではプロダクション環境はx86-64 (amd64)であり、Docker周りの環境構築に一工夫必要な場合も多いのではないでしょうか。また、Docker Desktopの有償化に伴い、所属している組織によっては開発環境のコンテナセットアップの方法を見直しているところもあるかと思い
NTTTech Conferenceは、NTTグループのエンジニアたちが一堂に会し、NTTグループ内外のエンジニアたちと技術交流を行うためのカンファレンスです。ここで「macOSの仮想化技術について~ virtualization-rsRust bindings for Virtualization」をテーマに鈴ヶ嶺氏が登壇。まずはmacOSの仮想化技術の変遷と、ツールについて紹介します。 発表の内容とアジェンダ紹介鈴ヶ嶺聡哲氏（以下、鈴ヶ嶺）：よろしくお願いします。鈴ヶ嶺です。まず概要を説明します。macOSの「11 Big Sur」から、新しくLinux VM作成の高レベルAPIのVirtualization.frameworkが登場しました。本発表ではこれがメインになります。 Objective-CやSwiftのAPIが提供されていますが、「あれ？ RustAPIがないなぁ」「
M1MacではRosetta 2を使って x86, x86_64 (以下x64) のIntelアプリやライブラリを実行できるのは有名だが、ターミナルを切り替えて使うことで、ARM非対応のツールやライブラリを使ってIntel版の開発を進めることができ、かつARM版と共存させることができる。 ARMとIntelのターミナルを切り替えて使う記事は既にあるものの、2021/2/5にARMに正式対応したHomebrew 3.0.0以前の記事しか見当たらず、Homebrew 3.0.0以降の正式対応後の手順と設定を改めてまとめてみることにした。iTermをインストール デフォルトのターミナルでも良いのだけれど、後述の見た目を分けることができなかったり、名称変更後のターミナルがSpotlightで呼び出しにくいなどで不便が多いので、iTermをインストールしている前提で以下説明する。 Intel版
これは何 備忘録も兼ねて、PCのセットアップで自分のやることをまとめてみました。 随時更新していく予定です。 VS Code VS Codeの環境設定 setting.jsonに下記を追加します。 内容はコメントで書いているので、詳細は省きます。 { "editor.fontSize": 12, //フォントサイズを変更 "editor.guides.bracketPairs": true, // 対応している括弧にガイドを表示する "editor.minimap.renderCharacters": false, // ミニマップに実際の文字を表示しない "editor.renderControlCharacters": true, // 制御文字を表示する "editor.renderLineHighlight": "all", // 現在の選択行をハイライトする "editor.r
前提 はじめに virtiofsさっそく試す もうちょっとちゃんと計測してみる Named Volumeを試してみる まとめ 追記（超重要） 追記2 前提 特にVSCodeのRemote Containers使ってる人には耳寄りです。別に使ってなくてもMacでDocker Desktop使ってる人ならあてはまります。 あと、このポストはMacといってもM1 MaxなMacBook Proで確認したものです。なので同じMacでもIntelMacとかだと違う結果になるかもしれません。 また、ここで紹介しているものはまだExperimental（試験的）な機能なので不具合や問題を引き起こす可能性があります。なので試す方はその辺は承知の上で試してみてください。 はじめに さて、MacでDocker Desktopというと「遅い」というのがこれまでの常識。自分のように普段VSCodeのRemote
Apple Silicon 版のMac を使っていても、依然として成果物をデプロイする先は ISA が x86-64 (amd64) のマシンであることが多い。 となると、どうしても x86-64 の環境を使って作業をしたい場面が出てくる。 もちろん、IaaS を利用してリモートにマシンを立ち上げれば良いんだけど、簡単な検証なら手元で手軽に済ませたい。 今回は、そんなニーズを埋めてくれるかもしれない Lima を使ってみる。 Lima を使うと、Apple Silicon 版のMac 上で ISA が x86-64 のLinux 仮想マシンを手軽に立ち上げることができる 1。 ただし、バックエンドは QEMU のソフトウェアエミュレーション (qemu-system-x86_64) なので、ネイティブな環境に比べるとパフォーマンスは大きく劣る。 使った環境は次のとおり。 $ sw_v
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
