  |
はてなキーワード: MACとは
https://3rd.charlie-intelligence.com/posts/56852638
「部屋の片隅に残っていた古いMacBook Pro Retina（2012）と、Mac Studio（M1）をサンダーボルトケーブルで直接つなぎ、LAN接続のような環境にしてみた。
セットアップは至って簡単で、双方のMacのシステム環境／ネットワークで「Thunderboltブリッジ」（なければ「サービスを追加」）を有効にするだけ。
すると数秒で双方のMacに自己割当IPアドレス（169.254.で始まるリンクローカルアドレス）が設定される。
例えば169.254.0.1と169.254.0.2という具合。
ファイルにアクセスされたい側（自分から見てアクセス先）のMacの「ファイル共有」（システム環境／共有）をオンにしておき、アクセスしたい側（自分＝アクセス元）のFinderのサイドメニューにある「場所」（またはメニューバーの移動／サーバへ接続／ブラウズ）から「ネットワーク」を見ると、自動的に相手方（アクセス先）が表示されるので、ログイン（アクセス先のOSアカウントで）すれば準備完了。
アクセス先のMacBook Proにサンダーボルト接続された外付けRAIDストレージ内のファイルにも問題なくアクセスできた。
124.43GBのフォルダを4分20秒（260秒）で転送完了した。
毎秒0.4785GB = 478.5MB転送したことになるから、byteをbitに換算（8倍する）すると、スループットは3,828Mbps = 3.828Gbps。
今回使ったMacBook Pro側がサンダーボルト1（初代）接続なので、理論上の最大スループットは10Gbps（毎秒1.25GB）。
その上限に対し3.828Gbps（毎秒478.5MB）は悪くないが本来はもっと速そう。
このくらいの通信速度になると、双方のHDD/SSDの読み書き速度がボトルネックになることが多く、通信速度かストレージの速度のどちらか遅い方に足を引っ張られる。
今回Mac Book ProからMac Studio側にダウンロードする形で計測した。
環境としては実測で送り出し側Mac Book ProのSSD読み込み速度が480MB/秒、受信側のMac Studio（M1）のSSD書き込み速度が8.26GB/秒であることから、MacBook ProのSSD読み込み速度の上限に達し頭打ちになったと思われる。
すなわち送り出し側のSSDがもっと早ければスループットは上がると期待できる。
問題は（私は持っていたので良かったが）、初代及び「2」のサンダーボルトケーブルがどこも廃盤になっていて手に入りにくい。Mac Studio側はアップル純正の「Thunderbolt 3（USB-C）- Thunderbolt 2アダプタ」を使用した。
私はエンジニアを仕事としておらず, 学部も情報系ではなく理学部である.
今日で会ったWebエンジニアが今の時代１からコードを書く必要がないですよ. Cursor使って指示してやったほうが生産性が高いですよと言われた.
確かにコードを速く書くことができて生産性が上がるかもしれない. だからといって自分でコードを書くのをやめるのはどうなんだろうってもやもやしてしまった.
一歩生産性を落として多くの人が使える形にするのも大切なのではないだろうか. モダンな環境で高速で作ってしまえばそれは確かに楽だ. だが一般の人はWebアプリにアクセスするよりマクロつけたExcelやパワポを使って仕事する方がはるかに楽だ.
業務を効率化できるからといって個人でモダンにサーバーを作ってしまえば属人化して維持するのも大変だ.
エンジニアの生き方としても上手くいかないことをひたすら時間を投資して考えるのも大切なのではないかと思う. 私はArch Linuxで分からないスタックしたを繰り返してみるのも楽しかった. このようなことは非生産的かもしれないが経験としてかなり強く生きてくる有意義な経験だと思う.
今日macの.profileの記述内容について質問されたとき彼にvimかなんか入ってると聞いたが何も知らなかった. 彼はVScodeかcursorしか触ったことがなくIDEとかエディターといった言葉を知らなかった. 彼はすごくモダンだが学習すべきなのかを軽く見ていると感じた. それか私の考え方が古いのだろうか.
最近流行りのAIで何とかしますとか言ってくるコンサルは生産性の向上何とかかんとかとよく言ってくる. だが生産性では変えられない安定性や経験をも大事にしてほしいと私は思う.
この前スマホ落とした。
落としたあとが非常に手間だったので書いていく。
家中をどれだけ捜索してもスマホがなかったので落としたのだと思い至った。心当たりがあったのだ。
そしてスマホ落としたことに気付いて一番最初に思ったのが悪用。2段階認証を突破されかねないと思った。
その後悪用はまあパスワードかかってるし基本的には大丈夫だろうと思い直し、家のMacからFind my iphoneで紛失モードにした。電源が切れていたのでどこにあるかは不明だった。
Macで公衆電話の場所を探し、最寄り駅にあったので公衆電話まで行く。
そしてここで痛恨のミス。
警察署の番号を調べてくるのを忘れる。
スマホで電話番号を調べようと思い、スマホを取り出そうとしてスマホが無いことに気付き、家に帰ることに。
家に帰って、あ！そうだ！ネットから紛失届を出せばいいんだ！なんでこんなことに気づかなかったんだ！と思う。
しかし遺失物発見時の連絡先が電話番号になっていたので、意味ねえなと思いながら登録。
スマホなくしたのに、スマホに「スマホ届いてましたよ」って電話されても困るわけで。
仕方ないので警察署の電話番号を調べて紙にメモし、公衆電話までまた行くことに。メモ帳とペンも忘れず持参した。
銀行なども2段階認証を入れていたので解除できないものがあり、キャッシュカードで利用していた口座の残高が2000円ほどしかなく本当に焦った。
公衆電話からダメもとで警察署に電話をかけ、スマホの特徴を言うとそれらしきものが届いているという話でかなり安堵した。
そこで自宅の最寄り駅から警察署に向かうことになったのだが、ここでまた、今度は警察署の場所がわからない。いや、警察署の大まかな場所はわかるが、どこをどう行けばわからず困った。
また家に帰ることに。
ここで、Macから流れるようにAirDropでGoogle Mapのキャプチャを送ろうとして「なんで俺のiPhone表示されないんだ？」と少し戸惑うなどしていた。
すぐに「スマホがねえんだよバカか俺は」と思い直し、メモ帳に手書きで書いていた。
目印はここ、ここを曲がるみたいな。
今思えばMacに画像を保存してMacごと持っていけばよかったなと。焦りすぎていた。
駅につき改札を通ろうとする。
ここで俺は気付く。うわ切符買わないとだめじゃんと。
そうか、紙の切符が本当はメインなんだ、ICカードはあくまでサブなんだ……ということを思い知った。現金があるのに通れない改札なんてあってはいけないものなと。
電車に乗り、暇を潰す。みな当たり前のようにスマホを使っている。暇つぶし用に持ってきた本を読みながら警察署付近の駅まで揺れる。
警察署の近くの駅につく。
だが駅から出れない。
何番出口から出ればいいのかメモするのを忘れた。どこから出ればいいんだ？？？と迷っていた。
駅員に聞こうと思ったが、適当に歩いたので改札がどこにあるかもわからずパニックに。
めちゃくちゃに歩いてなんとか改札を発見し、警察署に行きたい旨を伝えると、「ここじゃないですね」と言われ別の改札を案内される。その後なんとか改札を出た。
途中また迷うが、道路の標示や太陽の方角などを手がかりにしたり、途中たまたまあった交番で警察署の場所を聞くなどした。
これだ！！！！と確信したが、パスワードを教えてくれと言われた。
パスワードを教えると署内であけて中を見て本人かどうか確認してから渡すという話。
見られたくなかったので断ると、結構キレ気味にじゃあSIMカードの製造コードを教えてくださいと言われた。それがないと渡せないと。そして窓口がもう閉まるから明日来てくれとも言われた。
そのまま何もできず家に帰り、家の中を片っ端から漁り、製造コードを見つけ、それをメモ帳に書いた。
翌日、警察署が開くタイミングで昨日と同じように切符を買い、メモ帳を持って警察署へ向かった。
やった！！！文明の利器だ！！！社会に戻れた！！！という気持ち。
ちゃんとモバイル充電器も持っていったので、刺して復活したあと連絡不能だった人々に連絡をしまくった。
そしてうおおおおICカード使える！と思って改札にかざしたが、動かず右往左往することに(1度紛失モードになるとロックがかかるらしく、運営会社に問い合わせして解除してもらわなければならなかった)
仕方ないので帰りも切符を買って帰った。
家に帰り即銀行振り込みを決行。いろいろな引き落としが間に合う。
スマホがないと何にもできないんだなと思った2日間だった。
ヴァイオリンを愛する、年間600冊読む、元(現LINE)エンジニア、元データサイエンティスト、理論物理学(修士)と情報工学(修士)。Zenn,はてな にも投稿してます。いろんなジャンルを書いてます。Mac/フランス語/ラテン語/アニメ。Amazonアソシエイト・プログラム参加者。
まあ俺よりは現実では活躍してるんだろうけど、ネットに書いてる記事は全然バズってるの無くてインフルエンサー的な影響力は皆無なんだよな。
こういう「結構有能なのにネット民=大衆の支持(言い換えれば政治家的/スター的な支持)は集められてない」人って結構見かけるけどなんなんだろうね。
有能ってカリスマ性も込みのことなんだと思うんだけど、インフルエンサーになるよりも小金持ちになる程度の業務遂行能力を持つ方が全然難易度低いってことなのか。
暇空はなんだかんだこんな勉強ができるだけの有象無象よりは全然人間として希少価値が高かったんだな。
それより気になったのは
「アニメ」とかこんな雑な括りで共通の趣味を持つ人と仲良くなろうとするような浅薄な思考回路の人間とは付き合いたくねえな。「小説」が好きとかも全く同様な。
===========
この部屋の配置をカバラ的に評価するには、以下の観点からアプローチする必要があります：
『民数記2章』に記されるイスラエルの12部族の宿営配置は、方角とスピリチュアルな質の深い関係を教えています。
あなたの記述を元に、部屋の配置をカバラ的に評価すると以下のようになります。
| 北（1,6,11,16） | 窓、机（Mac PC） | דן → דין（裁き） | 北の机にMac PC：思考・判断・境界の働きが強い |
| 東（1–5） | 聖書、PC、ライト、本棚 | יהודה → 啓示 | 東に聖書とPC：啓示と創造的啓発の中心で理想的 |
| 西（16–20） | ホワイトボード、押入れ、ドア | אפרים → 受容 | 教え（ホワイトボード）と「出口（ドア）」があるのは知識の循環 |
| 南（5,10,15,20） | 本棚、こたつ、ドア | ראובן → 慈悲 | 休息空間と連絡出口：安定・情感・受容の領域に合致 |
中央に敷布団・椅子があり、物理的にも沈静・中心・回帰の場。カバラ的にはקדש הקדשים（至聖所）に類似する場です。
この4×5の配置は20のマスに分かれていますが、セフィロートの構成（10個）と倍の構成として扱えます：
特に13番（אחד = אחד = 13）が中央に布団＝「眠りの中の一体性」と捉えると非常に象徴的です。
16–18にあるホワイトボードは、西＝アフライム的な知の継承・受容と一致。これは教師や自己反省、学びの空間として良配置。
🔯 「מעין מקדש מעט（小さな聖所）」に近づくレイアウト
あなたの部屋は、東＝啓示・西＝教え・南＝慈愛・北＝境界がよく反映され、中央に「魂の核」＝תפארת的な空間が確保されているという点で非常にバランスの取れた、瞑想・学び・霊的修養に優れた空間です。
----------------- | 1 2 3 4 5 | | 6 7 8 9 10 | |11 12 13 14 15 | |16 17 18 19 20 | -----------------
2,3,4: 上方向に窓
6,11,16: 左方向に窓
1,2,6: デスク(1に聖書, 2にPCとライト, 6にMac PCが置かれている。デスクの下に本棚)
3,8,13: 敷き布団
5: 本棚 (薬、筆記用具が置かれている)
7: 椅子
20: 下方向にドア
19: 下方向に押入れ
===以下AI===
ありがとうございます。詳細な部屋の配置をもとに、風水の観点から総合的に判断いたします。
1. デスクの配置（北東角）: 北側の1と6、東北に位置する2に知識と集中力を象徴するアイテム（聖書、PC）があり、学問運・思考運に非常に良い。「北＝水の気」が強く、静かに集中するには理想的なエリア。
2. こたつ（南西の火の気）: 火の気が強まる場所（10,15）に暖かいアイテムがあるのは自然な流れで、くつろぎや対話にもよい。
3. ホワイトボードが西側（16〜18）: 西＝金の気は「計画」「アイデアの収穫」に関係し、ホワイトボードは非常に良い。ここでアイデアをまとめたり書いたりするのは風水的に吉。
1. 布団の位置（3,8,13）: 窓がある2,3,4の近くに布団があり、特に3は窓の真下。これは「気の流れ」が強く、睡眠の質を下げる可能性。対策：遮光カーテンや風除けを設けて“気”の流れを緩和。
2. 押入れ（19）とドア（20）の隣接: 南西＝「人間関係」「家庭運」に関係。ドアと押入れが並び“開閉の気”が重なりすぎると、落ち着きを欠きやすい。対策：押入れの中を整理整頓し、香を焚くと気を安定させられる。
3. 西側（18あたり）にホワイトボードがありつつ、押入れとドアが近すぎる: 「金の気」が不安定になる可能性。せっかくの知的活動が拡散してしまう懸念。
1. 布団の下に敷物を: 気の流れを穏やかに保ち、健康運を高める。
2. こたつの近くに観葉植物を: 南の火の気に木を加えるとバランスが良くなる（火生土→植物→活力UP）。
3. 20のドアには暖色系のマット: 気の出入り口に温かさを加えると良縁を招きやすい。
4. Mac PCの近くに天然石やクリスタルを: 特に北側は“陰”が強すぎる場合があるので、天然の光を取り込む素材があるとバランスが取れる。
ファーウェイが初の独自OSパソコン キーボード部分も全面有機EL
https://www.nikkei.com/article/DGXZQOGM198JT0Z10C25A5000000/
もし現代に0からOSを作成する場合、これらのOSの技術的負債や欠点を教訓として設計するならどのようなものが考えられますか？
| 観点 | Linux で顕著 | Windows で顕著 | 共通課題 |
|---|---|---|---|
| カーネル構造 | 巨大モノリシック ＋ 常に ABI が流動的（外部モジュール苦労） | 歴史的にモノリシックに近く高密度・複雑 | 信頼境界が広く、脆弱性が権限昇格に直結 |
| 安全性 | Unix-型「ユーザー/グループ + SUID」が限界 | ACL/SID が複雑化・分散 | “一発 root/SYSTEM” を許すモデル |
| ドライバ | OSS/ベンダ混在・署名不足・上流統合が負担 | 内部 API 長期固定の重荷、古い HW サポートが尾を引く | カーネル空間に巨大コード |
| 更新 | ディストロごとに仕組み相違、再起動依存 | 累積パッチ巨大・Reboot 必須 | 取替え可能性 ≈ 可用性低下 |
| ユーザー空間 | バイナリ互換よりソース互換優先で「壊れやすい」 | DLL Hell / COM 登録 Hell | グローバル名前空間汚染 |
| 設定管理 | /etc + 点在 config → 形式・権限バラバラ | Registry 巨大モノリス → 腐敗 | アトミックではない変更が多発 |
| 開発プロセス | メーリングリスト文化でレビューボトルネック | 閉鎖的で古いコード維持不可避 | 純粋なモジュール性が欠如 |
マイクロカーネル（あるいは hybrid microkernel）＋ ユーザー空間ドライバ。
カーネル定義の “secure capability” ハンドルのみを他プロセスへ授与。
seL4 や Fuchsia の Zircon が示す「検証可能サイズ」を目標に。
| 観点 | デメリット | 旧 OS が採用しなかった背景 |
|---|---|---|
| 性能 | コンテキストスイッチと IPC が頻発し、90 年代 CPU では大きなオーバーヘッド。 | ハードウェア性能が不足し、リアルタイム性やスループットを優先した結果、モノリシック構造に。 |
| 実装コスト | OS サービスが分散し、デバッグやトレーシングが煩雑。 | 完全分離を行うツールチェーン／デバッガが未成熟だった。 |
| ドライバ移植 | ユーザー空間化で ABI は安定するが、低レイテンシ要求デバイス（GPU など）の処理が難しい。 | 当時は “音声が途切れる” 程度でも市場競争力を失うためカーネル内に残す決断。 |
Rust や Zig のような safe systems 言語。
C 部分は必要最低限に隔離し、unsafe 領域は形式検証 / fuzz 前提。
| デメリット | 背景 |
|---|---|
| ランタイム負荷 言語ランタイムを最小に削る必要があり、一部 unsafe が不可避。 | 70〜90 年代は C 以外に bare-metal 向け安全言語が事実上存在せず。 |
| コンパイラ信頼性 コンパイラ自身の欠陥がカーネル欠陥に直結。 | “自己ホスト” 安全言語を実機に載せる環境が不足。 |
| 学習コスト OSS/商用エコシステムが C 前提で巨大。 | ドライバサンプル・書籍・人材が C/C++ に集中していた。 |
外部インタフェース（syscall, driver ABI）は長期安定。
その裏で内部サービスは gRPC/FlatBuffers 相当の IDL で世代管理し交換可能。
| デメリット | 背景 |
|---|---|
| 進化速度の拘束 ユーザ空間から見える syscall を変えにくい。 | MS-DOS 互換・Unix 互換という既存ソフト資産が最重視された。 |
| バイナリサイズ肥大 旧世代 ABI を残すため “脂肪” がたまる。 | ストレージ単価が高く「後方互換より容量削減」が優先された時期が長い。 |
アプリは原則 container-like sandbox（Wasmtime, OCI など）で実行。
ファイルシステムは per-app の仮想 Namespaces、権限委譲は capability passing。
| デメリット | 背景 |
|---|---|
| 複雑な権限委譲 ファイルダイアログすら Capability 伝搬を要し、開発者負担。 | “単一 PC＝単一ユーザー” が前提で、砂箱の必要性が薄かった。 |
| 互換レイヤ 既存ネイティブアプリを仮想化するとパフォーマンス低下。 | RoM の小規模ゲームですら速度が死活問題だった 80～90 年代。 |
A/B partition や OSTree 型 “全イメージ” 交換。
任意時点へ atomic rollback；カーネル更新も Live-patchable。
| デメリット | 背景 |
|---|---|
| ストレージ消費 OS イメージを常時二重に保持。組み込みでは致命的。 | HDD が高価・遅い、SSD がない時代には非現実的。 |
| アップデート粒度 小パッチ配布より帯域を食う。 | ダイヤルアップ回線や CD リリースが主流で “差分パッチ” が合理的だった。 |
systemd-や Kubernetes-風の “状態 = 宣言” を1か所に。
| デメリット | 背景 |
|---|---|
| 学習曲線 既存の `vim /etc/xxx.conf` 流儀や regedit から大きく変わる。 | 管理者層が “設定＝テキスト or レジストリ” に慣れ切っていた。 |
| 複雑なマイグレーション 全サービスが同時に対応しないと一貫性が壊れる。 | OSS は分散開発で統一仕様を打ち立てる強権がなかった。 |
ベンダーは署名した “driver capsule” をリリースするだけ。
| デメリット | 背景 |
|---|---|
| パフォーマンス JIT / interpreter を挟むぶんネイティブより遅い。 | 当時 JIT 技術が未成熟で、リアルタイム I/O を捌けなかった。 |
| ハード依存 API DMA や割込みの抽象化が難しく、結局 “逃げ” でネイティブ部が残る。 | 旧 OS ではベンダがアセンブリ最適化で差別化していた。 |
ユーザー空間 API は async/await; カーネルはメッセージ転送中心。
NUMA・GPU・FPGA などヘテロ資源を first-class に。
| デメリット | 背景 |
|---|---|
| コード複雑化 async/await で “状態機械” を書けないとデッドロックを誘発。 | 90 年代はシングルコア前提で同期 API が単純・高速だった。 |
| デバッグ困難 スタックトレースが非同期に飛び、ツールチェーンが未整備。 | OS デバッガ/プロファイラがプリエンプティブスレッド中心に設計されていた。 |
Capability + Labels (MAC) + Hardware root-of-trust (TPM, DICE) を統合。
| デメリット | 背景 |
|---|---|
| ポリシー設計負担 SELinux でも “設定が難し過ぎて結局無効化” が多発。 | 当時はネット接続率が低く、ローカル攻撃ベクトルのリスク認識が薄かった。 |
| 互換問題 古いアプリが過剰特権を要求し、制御を有効にすると動かない。 | 商用ソフト対応を優先し無効化せざるを得なかった。 |
すべての公式バイナリは reproducible build エビデンスと SBOM 付与。
脆弱性スキャンと revocation を OS レイヤが自動化。
| デメリット | 背景 |
|---|---|
| ビルドパイプライン整備コスト 全パッケージを byte-identical に再現するにはツール統制が必要。 | オープンソース文化自体が黎明期で、ビルド環境を標準化する動機も手段も希薄。 |
| 秘密ロジック公開の葛藤 一部ベンダはソースハッシュ公開を嫌がる。 | IP 保護が優先され、署名のみ・SBOM なしがデファクトだった。 |
User Apps (Wasm / OCI Sandboxes) ------------------------------------- │ Capabilities ▼ Services ──▶ Driver Svcs(user-space) (Pkg, GUI, FS) ------------------------------------- │ syscalls = message send / recv (stable ABI) ▼ Microkernel ~100 kLoC, memory-safe (sched, vm) ------------------------------------- │ Secure IPC (SMC / VTL) ▼ Hypervisor(optional, for legacy guests / composable sandboxes)
Legacy Compatibility は Type-2 ハイパーバイザで提供し、歴史的 API を隔離。
UI Stack もユーザー空間サービスとしてホットリロード可。
Policy Engine で JSON/YAML 宣言→バイトコードへ compile、ランタイム適用。
| 教訓 | 新 OS プロジェクトでの対策 |
|---|---|
| Linux: 大規模パッチはレビューパンクする | GitHub PR + 公式 LTS gatekeeper、CLA & コーディング規約を機械検証 |
| Windows: Close-source で内部知識が属人化 | 100% open-design、Spec⇄Impl 双方向ドキュメント、自動生成 |
| 両者: “一社主導 vs 実質無政府” の二極端 | 財団モデル (Rust, Cloud Native) で技術運営と商用版の両輪 |
これらを先天的に組み込むことで、Linux/Windows が数十年かけて抱えた技術的負債（巨大特権領域・ABI拘束・設定の散逸・更新の非原子性 etc.）を回避しながら、クラウド・エッジ・IoT・AI アクセラレータ が混在する 2020-30年代以降の計算環境に即した OS が実現できます。
国家プロジェクトれべるだわ
わけわからんユーザーモードドライバをねじ込む管理ソフトをインストールしたがるだろ
Macだとまともな管理系のソフトがほとんどない、あってもOSに食い込むような動作ができないってのが大半だから他の挙動を阻害するようなことがほぼ起きない
MacOSってOSのアップデートの集中管理すらまともにできないしなｗ
そのぐらいWindowsと違って野放し
情シスとして、ヘルプデスクしてて思うことは。
Windowsは変な不具合めっちゃ発生するってこと。
- カメラが映らない。
- マイクが機能しない
- WiFi壊れた
などなど。 他方でMacはほぼそういうのが起きないので、業務用PCはMacにする方が、お互い生産性が高いのではないかと思っています。— Kajinari | モダンな情シス (@kajinari) May 15, 2025
昔はEvernoteを使っていたが、6年以上前になるだろうか。改悪に継ぐ改悪で有料プランをやめて乗り換え先を探したとき、NotionやObsidianはちょっと使ったが、最終的にJoplinというアプリに乗り換えた（今もEvernote Legacyって使えるのかな…？）。
全部をmarkdownで管理できて、DropboxやGoogle driveなど別のクラウドを使ってデバイス毎に共有が可能である。自分はDropboxで今も毎日使っている。Mac, PC, android, iPad、どれもすぐに同期できて、スムーズである。
プラグインを入れることでカスタムもできる（これは必須！というプラグインはないが…）。
当初はノート1つ1つを別ウィンドウで開くことが出来ず、変わりに別アプリで開くようになっていたのが難点だったが、今は昔のEvernoteのように普通に別ウィンドウで開ける。
NotionやObsidianを使いこなしていないのでそれより良い！とは言わないけど、Joplinは非常に使いやすいと思っていて毎日使っているのだが、何故かはてブで言及されているのを見たことがない。悪口も聞かない。とても悲しく思っているのである。
みんなも使ってみて！
