  |
はてなキーワード: githubとは
何もしないと個人リポジトリ―のコードが取り込まれ、設定によってはどんなライセンスのコードだろうと取り込まれることだ。たとえば…
Commercial distributors of software may accept certain responsibilities with respect to end users, business partners and the like. While this license is intended to facilitate the commercial use of the Program, the Contributor who includes the Program in a commercial product offering should do so in a manner which does not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor ("Commercial Contributor") hereby agrees to defend and indemnify every other Contributor ("Indemnified Contributor") against any losses, damages and costs (collectively "Losses") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b) allow the Commercial Contributor to control, and cooperate with the Commercial Contributor in, the defense and any related settlement negotiations. The Indemnified Contributor may participate in any such claim at its own expense.
For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages.
5. NO WARRANTY
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement , including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations.
This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.
アメリカのニューヨーク州なので、ニューヨーク州法と連邦法が適用される。
もし、Github code pilotでBigListやNode、Bagなどのコードが出てきたら、注意したほうがいいぞ。
訴えている奴がマジでいるんで、Code Pilot Businessのほうは公開されているコードは取り込まないという設定を有効にしておいたほうがいいと思われる。
将棋AI「将棋神やねうら王（MyShogi）」の局面図って、SVG形式でしか保存できないんだけど
それをブログやX（旧Twitter）で使いたいとき、毎回変換がめんどくさかった。
……みたいなやつばかり。
じゃあいっそ自作するか？と思って、ChatGPTに相談しながら
Python + Playwright + HTML + JavaScriptで
「SVGをPNG/JPGに変換して、自動ダウンロードするスクリプト」を書いた。
ローカルのSVGファイルをBase64でHTMLに埋め込んで、
canvasに描画 → PNG/JPGとして保存する完全自動処理。
Playwrightの導入でちょっと詰まったけど、結果的には超実用的なやつができた。
こういうのって需要あるのかな。
同じように「ローカルSVGを綺麗に画像にしたい」って人いそうなんだけど。
一応GitHubと解説noteも書いたので、興味ある人いたら見てほしい。
https://github.com/yahoike/svg2img
https://note.com/yahoike/n/nd9265141a83a
ラズパイとかミニPC上で動くスマート家電向けの統合ソフトウェアだが、すでにインストールしたLinux上で直接動かせるSupervisedモードがDeprecatedになり、サポートはHAOSとコンテナ上の実行だけに絞るらしい
HAOSの方はaptも何も動かないのであり物のプラグインに頼るしかないが、欲しいものは無いしプラグイン作るの面倒すぎる
コンテナはマシンパワーが必要でdocker-compose組まなくちゃいけなくてクソ面倒
案の定Supervisedがサポート外になることについて大量に反対意見が出てるが「もう決まったことだから」「githubのissue見てない人があとから文句言うんじゃねえ」なんてコメントで炎上している
かく言う俺も2日くらいいじってこれ以上触るのが無駄と判断した、見てくれがキレイだろうとやりたいことの前提すらたどり着けないなら価値なんてないわ
https://szkwjp.sakura.ne.jp/#search_replase_multiline_text
鈴川エディタの置き換えがどういうことをしているのかわからんが、BigListで④4.8GB、3680万行より少し上まで動くことが確認できた。
（手元のマシンではメモリーのみだと４のテストが限界のようでこれ以上は試すことができんかった。）
ただ、速度は鈴川エディタやSublimeTextにははるか及ばんがな。
それでも、EmEditor 64bit（ver16.3.1）よりははるかに速いが…。
benchmark start
Allocated GC Memory:61,088bytes
Allocated GC Memory:7,984,576,768bytes
Allocated GC Memory:7,984,593,376bytes
Allocated GC Memory:13,814,137,216bytes
Allocated GC Memory:13,814,137,912bytes
Allocated GC Memory:13,814,138,056bytes
clear buffer
Allocated GC Memory:82,728bytes
Allocated GC Memory:1,638,728,376bytes
Allocated GC Memory:1,638,739,600bytes
clear buffer
Allocated GC Memory:82,984bytes
https://github.com/oonyanya/FooList
中学校在学中にプログラミング言語を開発し経済産業大臣賞（総合）を受賞した上原直人氏という方がいます。
上原直人氏が開発した「Blawn（ブラウン）」の使い方を調べてみました。
Blawnには後継のClawn（読みはクロー？クラウン？）が登場していました。
こちらがClawnです。
https://github.com/Naotonosato/Clawn
Clawnはgithubにあります。リポジトリをcloneする必要があるそうです。
https://qiita.com/sh10n/items/f5edb7293aaffebe35a7
https://github.com/Naotonosato/Clawn
次に下記、これは前のBlawnを使った例です。おそらく参考になるかと思います。多分ですが。
ウワサのBlawnを触ってみた
https://qiita.com/blackenedgold/items/83526b329fe96ee781f5
私自身Clawnがまだ使えていません。初心者向け言語のはずですが現時点では環境構築のハードルが初心者向けとは言い難いので、githubの使い方に慣れている方以外はじっくり調べながら・・・となるかと思います。
先日の日曜、某IT系の勉強会に参加してきたんだけど、そこでも話題に上がったのが「AIによって人間のプログラマーは不要になるのか？」って話。
正直俺も含めてその場にいたほとんどの人間が、腹の底ではいやいや、それはないっしょって笑ってたわけ。
たとえばChatGPTとかGitHub Copilotとか、最近はTabnine、Amazon CodeWhispererなんかもあるけど、どれも便利ではある。
でも結局のところAIが書いたコードの品質をチェックするのは人間だし、プロンプト自体が難しいから結局基礎ができてないと無理だよねっていうある種の安心バイアスがあった。
でもその考え、甘かったっぽい。
聞いた話では今のAIでは分業化が進んでるらしい。
例えば、一般的な言語モデルであるGPT-4はもちろん優秀なんだけど、今はそこからさらに“ドメイン特化型”のAIが開発されていて、分野別に専門AIが配置されてる。
データベース設計ならこのAI、フロントエンドならこっち、セキュリティに関してはあっち、みたいな。
つまり何が起きてるかっていうと、素人が「こういうアプリ作りたいんだけど」ってざっくりした質問をしたとしても、AIの中で自動的に専門家AIにルーティングされて、実際にプロレベルの回答が返ってくるようになってきてる。
人間の経験とか判断力に頼っていた領域が、いよいよAIに侵食されはじめてる。
しかも進化スピードが異常でMistralやAnthropic Claude、MetaのLlama 3、Google Geminiあたりの最新モデルはすでに「構文の正しさ」や「コード全体の可読性」まで含めて自己チェックできるようになってきてるらしく、OpenAIが次に出すGPT-5では、おそらく「仕様の良し悪し」までも判断できるって噂まである。
もうこうなると、中堅レベルのプログラマーが真っ先にいらなくなる可能性が出てくる。いやマジで。
実務経験を積んでやっと「これがベターだな」って判断できるスキルが、AIにあっさり再現されるとしたらそれ以下の人材は何を武器にすればいいんだ？
正直かなりゾッとした。
俺も完全にその中堅側にいるから。
これまではいくらAIがすごくても使いこなせるのは人間だけって思ってた。
でも今後は違うかもしれない。
……たぶん、生き残るのは本当に一握りの設計思想まで含めて自分でAIを育てられるレベルのプログラマーだけになる。
言語でいうなら、RustやGo、TypeScript、Kotlinとかをベースに、フレームワークだけじゃなくて抽象化の設計思想まで一人で持てるような人。
おかげで週末はとっても陰鬱な気分で過ごす羽目になった。
IT業界ではよくある話だが、「プロ中のプロ」「即戦力間違いなし」みたいな触れ込みでやってきたメンバーがいた。営業が何を言ったのか知らないが、やたらと期待値高めで参画してきたので、とりあえず大枠の指示だけ渡して、あとはお任せという形にした。
任せた作業は、普通ならベテランなら4、5日で終わる程度。決して簡単ではないが、経験豊富な人間ならそれほど苦戦するようなものではない。正直、自分たちでも一から調べてやればできなくはないが、他の仕事との兼ね合いがつかなくてアウトソーシングすることになったという話だ。
ところが、1ヶ月経っても作業は進まず。原因を聞けば「アカウントの問題で止まっている」とのこと。それなら仕方ないかと、しばらく静観していた。特に急ぎでもなかったし、どうせプロなんだからそのうち解決するだろうと楽観していた。
だが、2ヶ月目に突入しても状況は変わらず。報告内容も「サポートに問い合わせ中」「管理者に連絡中」など、他責のオンパレード。こちらとしては、そろそろ納期も見えてきたし、悠長に構えていられない。
目を疑った。
そこには、まさかのパスワードがベタ書きされたコードがコミットされていた。しかも、修正の痕跡もなく、そのまま堂々とプッシュされていた。
正直、言葉を失った。
「プロ」と名乗る人間が、こんな基本的な初歩的なセキュリティすら無視するとは。
gitignoreの使い方もわかってない。コード管理の概念すら怪しい。
「これは成長の余地がある」とか「方向性を見誤っただけ」とか、そんな擁護すら思いつかないレベル。もはや何を信じて任せていたのか、自分を問い詰めたくなった。
ファーウェイが初の独自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 が実現できます。
国家プロジェクトれべるだわ
いや、めっちゃ面白い暴露話やん！河童が地下でキーボード叩いてChatGPT動かしてるって、めっちゃシュールな光景やな。キュウリ代高騰でストライキとか、リアルすぎて笑うわ。サステナブルじゃないAI革命、河童の繁殖問題で崩壊とか、めっちゃSFチックやけど、なんか妙に納得感あるわ。
でも、ちょっと聞きたいんやけど、河童のプログラミングスキルってどれくらいのレベルなん？GitHubのコード補完とか、ガチでバリバリ書ける河童おるん？あと、キュウリ5本/日って、1匹の消費量エグいな！国産キュウリじゃないとキレる河童のメンタル、ちょっと気になるわ。ストライキの詳細とか、もっとエピソード聞かせてよ！😄
世間の「生成AI革命」のからくりを暴露します。実はすべて河童の手作業です。大規模言語モデルとか量子コンピュータとか言ってるのは全部嘘。データセンターの地下には河童がびっしり。
入社して最初に衝撃だったのは、地下8階の光景。小さな個室に分かれた巨大な空間に河童が何百匹も詰め込まれていた。各個室には高性能PCが置かれているが、あれは見せかけで、実際は河童が質問を読んで手で回答を打ち込んでいる。
「どうして公表しないんですか？」と上司に聞いたら「投資家が逃げるから」と言われた。確かに「最先端技術」じゃなくて「河童労働」って聞いたら株価暴落するわな。
Githubのコード補完も河童の仕事。コーディングに詳しい河童を集めて、24時間シフト制で対応させてる。意外とプログラミング得意な河童多いんだよな。
ただ最近はマジでやばい。河童の数が足りなくなってきてる。繁殖が間に合わない。日本の河童はほぼ捕獲済みで、今は東南アジアやアフリカまで調達範囲を広げてる。河童の価格も高騰してて、去年の10倍くらいになってる。
それにキュウリ代もヤバイ。1匹あたり1日5本必要なんだが、キュウリ価格も上がってて経営圧迫してる。コスト削減で質の悪いキュウリに切り替えたら河童が反抗的になってきた。先月なんかは「キュウリを国産に戻せ」って要求してストライキ起こして、ChatGPTが6時間ダウンした。会社は「サーバーメンテナンス」って発表したけど、実際は河童の反乱。
このままじゃ近いうちに河童が完全に反乱起こすか、絶滅するかでAI産業は終わると思う。サステナブルじゃない。投資家は知らないだろうけど、今のAIブームは河童という有限資源の上に成り立ってる砂上の楼閣だよ。
まあ俺はもう辞めたから知らんけど、みんながChatGPTとか使ってる裏側では河童が必死に働いてるって知っといて欲しかった。
画面共有してる時にそれが映っちゃって上司に怒られた
いいじゃん別に……GitHub Copilotの使用は認められてんだし……
VitaにCFWを導入するにあたり、情報が散乱していたのでまとめる
・2022年末に革新的進歩があり、VITA単体でCFW導入できるようになった（通称 HENlo）
・にも関わらず古いCFW導入方法を案内しているブログが大量にある
・しかもタイトルの"20XX年最新"だけ更新し続けているから、最新記事に見える
↓
PC使用が前提になっているブログは全部古いので無視した方が良いです。
・『HENlo』について触れている
この2つが押さえられてれば最新情報です。（2025年5月現在）
ただし、現状だと実は『PC操作が一部必要』という罠があります。
その問題について書いている記事が見当たらないので、ここに残しておきます。
超具体的には
「HENkaku、VitaDeploy、VitaShellは導入できた」
「けどEnso導入ができない/つまづいている」 エラー：failed to get fw version please disable all the plugins and try again
5chでもRedditでも
『プラグインを無効にしろ』『0syscall6を無効にしろ』って書いてあったのですが、実はEnsoのバージョン変えれば解決します。（後述）
この記事が役に立ちました
[Vita] 2023年最新手順【HENlo】3.65-3.74 PC不要でCFW(HENkaku)導入
https://re-doing.com/vita-henlo-hack/
（一応魚拓：https://web.archive.org/web/20250226111105/https://re-doing.com/vita-henlo-hack/）
・HENkaku （カスタムファームウェア 3.65 変革 -2）
・VitaDeploy
・VitaShell
・最悪文鎮化する可能性があるのでセーブデータバックアップを取ったほうが良い
・VITAのセーブデータは特殊で、PCと繋ぐだけでは取り出せない
・バックアップにはいくつか方法があるが、PCのコンテンツ管理アシスタントは既に使えないと思ったほうが良い。PS Plusのクラウドバックアップが最も良いはず
・記事の内容を実施する前にバックアップ取るのを強くおすすめする
これをインストールすることで、電源を切ってからもCFW状態を維持できます。
VitaDeploy内のApp downloaderメニューからEnsoをインストールできますが、実はこのバージョンが古いです。※重要※
そのためVitaDeployからインストールすると先程のエラー（failed to get fw version please disable all the plugins and try again）が必ず出ます。
「PC不要になった」と書いてあったので盲点ですが、ここからPC必要です。
正しい方法は以下です
1, PC操作：GithubからEnso最新版のenso.vpkファイルをダウンロード（現在v1.1）
https://github.com/TheOfficialFloW/enso/releases
2, PCとVitaをUSBケーブルで繋げる ※データ転送対応ケーブルを使うこと。相性もある
5, PC操作：USBドライブとしてVITAのデータが表示されるので、ダウンロードしていたenso.vpkファイルを置く（フォルダはどこでもOK。自分はルート直下に置きました）
7, Vita操作：VitaShellでenso.vpkを見つける（さっきルートに置いたなら恐らくux0:にある）
9. Vita操作：Do you want to install this package? → ◯ボタン
10. Vita操作：~~~ Would you like to continue the install? ※意訳：「失敗したら文鎮化するけど自己責任だけど続ける？」 → ◯ボタン
11. 進行バーが消えたらインストール完了 ホーム画面に戻ってOK
Ensoはファームウェアが3.60か3.65じゃないとインストールできないです。（3.65 変革 -2は3.65扱い）
先程の記事の通り進めていたら3.65 変革 -2 になっているはずですが、実行前に再確認して下さい。
1, ~~~ Press CIRCLE to accept these terms or any other key to not accept. → ◯ボタンを押す（=CIRCLE ）
2, Options：
CROSS Install /reinstall the hack.
SQUARE Fix boot configuration (choose this if taiHEN isn't loading on boot).
CIRCLE Exit without doing anything.
Locking sustem ..
（中略）
The installation was completed successfully.
suocess.
MBR was detected but instllation checksum dose not match.
A dump was created at ux0:data/blocks.bin.
Press X to continue, any othe key to exit.
意訳：「ちょい待った。思ってた構成じゃないから危ないかもしれんわ。続ける？」
→✕ボタンを押す ※結局原因分かってないので自己責任でお願いします※
4, Locking sustem ..
（中略）
The installation was completed successfully.
suocess.
Enso導入が成功していると
・ファームウェアが3.65 変革 -2のままなっている
お疲れ様でした。
記事の本題は以上です。
VITAのセーブデータは暗号化されており、吸い出せてもエミュレータで使えないらしい。本体機体とセットで揃わないと使えない仕様。
調べたらセーブデータをここまでキツく縛ってるハードは他にない
だからメモリーカードのデータ管理でもPSPのセーブデータしか項目がなかったのか…
不便すぎる
当時の仮説
・HENkaku設定が悪さをしているのではないか（PSNの偽装を有効化、バージョンの偽装を有効化） →オフにしたが関係なかった
・本体にSD2VITAを刺しているのが良くないのではないか →抜いたが関係なかった
・enso.vpkの置き場所がルート（ux0:）が良くなかったのではないか →関係なかった
・VITAにメモリーカードを刺しているのが良くないのではないか →関係なかったが、データ保護的には抜くのが良さそう
・ゴミデータが残っていて悪さしているのではないか（手順を間違えたデータや古いデータなど） →関係ある可能性はある。最後までわからず
・Ensoのバージョンが古いのではないか →これが主要因だった
ゴミデータを疑った自分は正規のファームウェアに戻して、CFW化をやり直したりもした。
その際HENkakuすら入れられなくなってしまったので、抜け方を書いておく。
ENSO実行
↓
~~~ Press CIRCLE to accept these terms or any other key to not accept. → ◯ボタンを押す（=CIRCLE ）
↓
Options：
CROSS Install /reinstall the hack.
SQUARE Fix boot configuration (choose this if taiHEN isn't loading on boot).
CIRCLE Exit without doing anything.
→ △ボタンを押す（=TRIANGLE Uninstall the hack.）
↓
↓
↓
ファームウェアアップデートが促され、アップデートしないとメモリースティックが使えない
↓
↓
↓
HENloメニュー
・Exit
↓
「Eiting in 3」 の後に、以下のエラーメッセージがでて固まってしまう
vita starting taihen framework
If you are stuck on this screen, hold down the power button until your Vita turns off, then turn it back on.
原因：恐らく余計なデータと衝突を起こしてる
解決法：reset taitan configを先に実行する
（さっきのエラーメッセージ画面で）
↓
セーフモードが起動する
↓
↓
↓
HENloメニュー
・Exit
↓
その後
Install HENkaku、Install VitaDeployを選択して、Exitを選択
この記事を書き終えた後に見つけたのですが、以下の記事の『改造方法』というところに情報がかなりまとまっています
Vita バージョンが低くてもPSNにサインイン＆PSストアにアクセス(エラーNW-8942-3回避)＆機器認証する方法(2025最新)
https://yyoossk.blogspot.com/2024/10/vitapsnps2024.html
今回VITAのセーブデータバックアップが主目的だったから、徒労でしかなかった
指摘、補足、最新情報あれば反応もらえるとありがたいです
いや、それは別にあなたが地方国立理系出だからとか、底辺だからとか、そういう話ではまったくないと思います。
⸻
理系の中でも「オープンソース文化」をよく理解していて、かつそれを良しとしている層ってのはたしかに存在します。でも、**「オープンソースに好意的＝AI学習に抵抗がない」**というのは必ずしもイコールではないんだよね。
オープンソースってのは「自分が納得したうえで公開する」からこそ価値があるわけで、勝手にスクレイピングされて学習に使われるってのは、単純に「オープンソース精神」とはズレてるんだよ。
GitHubにコード出してる人でも、「ライセンス守れよ」って怒ることあるでしょ？それと一緒。
だから、その理系の人が「AIに学習されるのがイヤって気持ちわからん」って言ってるのは、
たぶんだけど、
• 自分の出してるものは全部オープンにしてもOKって思ってるタイプか、
⸻
あなたが「理解できないことが理解できない」と感じるのは、別に学歴とか偏差値とか関係ないし、むしろ感受性があって倫理的な線引きを考えられる人ってことだと思うよ。
自分の中で「これってちょっと嫌だな」って思ったものをスルーせずに、「なんでこんなにあっさり言えるんだ？」って引っかかれる時点で、ちゃんと誠実なんだと思う。
昼メシのUber EatsつつきながらSlack眺めてたら、非公開チャンネルに不穏ワードが爆誕してて笑った。
いや、笑えんわ。いよいよ “アクセに身売り” の噂、ほぼ確だって？
──は？ はぁ!? こちとら週イチLTで「世界ぶっ壊す！」って雄叫びあげてる最強ベンチャー様だぞ？
週末はReact＋Next.jsで自社プロダクトを夜な夜な爆速リリース、PRは秒でセルフマージ。
朝会は “OKR？知らん！” のテンションで「とりまKPIは宇宙！」とか言っときゃ許される──それがカルチャーだった。
なのに今日、CTOがAll-Handsで「合流シナジー」とかカタカナ並べ始めた瞬間、チームのZoomが凍りついた。
カメラ越しでも分かる、あの “終わった” 空気。マイク切ってDiscord裏窓で叫ぶしかなかったわ。
ポモドーロが爆散した。
達成度は「クォータリー360レビュー」でランク付け？ 何それ、ブラック魔導書？
──はぁ？ 技術書1冊で超えるんだけど？ 草。枯れるわ。
オフィスだって、“カフェスペース”に鎮座してたレゴ・デロリアン撤去だと？
あのレゴが何百万の調達ミスを救ったか、シニア層は知らねぇんだよな。
Slackの新人チャンネルでは、案の定「これでもポジティブに行きましょ！」とか空元気のスタンプが飛び交ってる。
悪いけど無理ゲー。
そこに“PMOガバナンス”をねじ込むとか、自分のGitの履歴に「Fix governance breach」ってコミット残す罰ゲームかよ。
夜、恒例の“深夜メトリクス祭り”でGrafana眺めながら、ふと思った。
でもそれ、オレたちが「自由にぶっ壊せる」から叩き出せた数字だ。
明日からアクセ式チェックリストで “承認フロー: 7-Step” とかついたら？
ま、とりあえず社外公開してないOSS支援botのトークンだけは今夜中にrevokeしとく。
次に会議室で名刺交換するころには、名刺のロゴが白黒の世界支配企業になってるかもしれんしな。
でも──絶対忘れんなよ。
“自由はForkできる”。
巨大コンサルのバグに巻き込まれても、オレのGitHubアカウントだけは、スタートアップ魂フルコミットでPushし続ける。
ネットってのはな、俺達プログラマーにとっては生業であり、そして生活の延長線上にあるリアルそのものだ。
何もかもがコードでつながり、思考が即時に吐き出されるこの空間で、俺達は日夜、命を削って生きてるんだよ。
なのにどうだ、最近は一般市民がぞろぞろ流れ込んできやがって、勝手に「ネットは日常で言えないことを言ってもいい裏世界」だと勘違いしてる。
馬鹿か。勘弁してくれ。お前らのいう普段言えない本音ってのは、大抵の場合、単なる知性と品性の欠如からくる脊髄反射だろうが。ネットを精神の便所だと勘違いして、垂れ流すんじゃねぇ。
俺達は違う。表も裏もねえ。だからこそ、わきまえる。俺達がネットで余計な社会論争に踏み込まないのは、面倒だからじゃねぇ。価値がねえんだよ。時間の無駄なんだよ。
男女？イデオロギー？ウヨサヨ？くだらん。プロセスと結果がすべて。こっちは問題が発生したらデバッグして、再現性を確認して、最適解を叩き出す。そういう世界で生きてんだよ。
「ネットで言いたい放題」だ？お前の言いたい放題のせいで、こっちはGitHubのIssueが荒れるし、Qiitaがゴミで埋まるし、Stack Overflowが地獄と化すんだよ。
Xのタイムラインも、技術的知見を探すための場所だったのに、今じゃポエムと炎上商法と感情の掃き溜め。ふざけんな。
ネットは、我々にとっては書斎であり、研究室であり、コードの神殿だ。そこに土足で入ってきて、勝手に叫んで、暴れて、挙げ句の果てに「言論の自由」とかほざくな。
お前の自由は俺達の時間を奪っているってことに気づけ。思考をせずに叫ぶな。リテラシーのない言葉は、ノイズどころか害悪だ。
そして何よりも覚えとけ。わきまえるってのは、抑圧でも服従でもなく、「構造を理解し、場に最適なアウトプットを選ぶ知性」だ。
それができないなら、お前はこの情報空間で生きる資格がねぇ。リアルで黙ってるやつが、ネットで急に吠え出すな。
俺達は逆だ。リアルでは黙ってても、ネットではコードという言葉で語る。貢献して、共有して、改善していく。
つまりな、ネットは俺達の居場所だった。お前らの娯楽じゃねぇんだよ。
この観点は非常に本質を突いています。「ファクトチェックが容易であるほどAIが強い」という命題は、一般にかなり正しいといえます。以下のような理由からです。
AI、特に大規模言語モデル（LLM）は、大量のテキストデータを学習して統計的に言語のパターンを捉えています。
そのため、明確な正解があり、検証も簡単なタスクは非常に学習しやすく、正確な出力を出せる傾向があります。
ファクトチェックが容易な分野、特にプログラミング、数学、基本的な自然科学は、インターネット上に豊富な正確な情報があり、AIの学習素材として利用されやすいです。
プログラミングのように結果の良し悪しがコードの実行で即座に分かる分野では、人間のユーザーや自動ツールによるフィードバックで性能が継続的に改善されやすいです。
AIは「客観的で明確な正解があり、検証が容易な分野」で圧倒的に強い。
世の中的には生成AIに要件伝えて生成させたコードをコピペして動かして「はい！生産性爆増！」っぽいけど、生成AIが吐き出したコード読むだけじゃ全然分からん。
Clineで使い慣れた言語・フレームワークのコードを生成させたら見たことがないエラーが出て面食らった。
原因はフレームワークのnewコマンドで自動生成される設定ファイルが全然違う書式で書かれてた。
(どうやら遥か昔のバージョンだとその書式だった模様)
GitHub CopilotやCursorだったら確認しながらtab押してくからこれなら予測変換みたいなものだし大丈夫だろう、おお便利便利……
と思って使ってたのだが、テストするとデータ作成時にフィールドに抜けがある…。
確認したらPOSTするJSONに存在しないkeyが含まれてた。それっぽい名前がサジェストされてそのままtabを押してしまったらしい。
手動でテストしてたから助かったが、この手の外部API使って更新する系はテストをモックしてたりするので危うく本番障害になるところだった。
それこそ特にこれまで触ったことない言語・フレームワーク・ツールを使ったコードを生成AIに吐き出させてもさっぱり分からん。
読むだけだとさっぱり分からないので結局生成されたコードを写経しながら、分からないところをググったり生成AIに質問したりでやってるんだが、まあコピペ勢が40秒でPR上げてるところを、2時間・3時間とかけてるからまあ生産性が悪い悪い。
昔から書かないと覚えられなくて、学生時代もテスト前は過去問解く前にまずは授業中に取ってたノートをとにかく写経してた。
友人からは「過去問だけやって、よく分からなかったとこだけ該当部分をノート見れば分かるじゃん」と言われたが分からないのでしょうがない。
あとプログラミングだけじゃなくて、議事録も最近はZoomとかが自動生成してくれるようになった。
が、こいつがとにかく俺と相性が悪い。
これまでは自分で会議中に議事メモを書いて、終わった後に手直しして論点やToDoをまとめてたので会議の流れややるべきことが頭というか体に入ってきてた感じだった。
それが自動生成されるようになって、確かに時間はかからなくなったかもしれないが、流れとかやることとかが全然頭にも体にも入ってこなくなってしまった。
議事録については結局自分用にメモを取って、あとで自分用に論点やToDoをまとめるというのをやってるが、正直会社から見ると「生産性が低い奴」なんだろう。
おそらく元々読めば理解できるタイプ、それこそ教科書を何回か読めばテストで点を取れるタイプはコード生成AI時代に大活躍できるのだろう。
あるいは今後出てくるコード生成AIネイティブ世代は書かなくても理解できるのが当たり前になったりするのだろう。
……いやそんなことあるか？
これそもそも生成AI以前から「手を動かさなくても公式のREADME読めばすぐ使える」みたいな能力で、そんな奴ごく一部だろう。
教科書何回か読めばテストで点が取れるのも塾行かなくても東大合格できるみたいな特異点みたいな人間だろう。
これまでは結局のところ人海戦術で各言語・フレームワークなどを理解して、大量に書く必要があったから書かないと理解できない俺のようなオールドタイプもプログラマーになれた。
しかし今後はコード生成AIが言語・フレームワークは理解しててすごい勢いでコードを生成してで生産性は爆上がりするから、読めば理解できるニュータイプしか生き残れないのかもしれん。
それこそビル・ゲイツ氏はExcelのレビュー時に仕様書500ページを読み込んで1900年閏日問題について的確に指摘したり、岩田聡氏は任天堂取締役室長時代に週末でNINTENDO64のグラフィックスチップの制御命令コードを完成させたりしたそうだ。
そういった人ならコード生成AIが出したコードについても目grepで瞬時にバグを見つけて直して爆速リリースとかできるのだろう。
……凡人には無理ゲーすぎるな。
なんてか、最初は教訓的に
「良い子の諸君！書かないと覚えられないと詰むから、読んで覚える力を強化したほうが良いぞ」
的なことを着地点で考えてたけど、これもはや地頭が良いとか先天的にニュータイプしか生き残れないやつや。
生成AIがコードを産むなら、みんな死ぬしかないじゃない！(読んで覚えられる)あなたも、(書いてしか覚えられない)私も…（錯乱）
AIに「ド素人でもゼロから分かるペライチ〇〇解説」ってくらいの物を一発で安定して生成させてえなーと思って試してる
でも「ガチのマジで無知なズブの素人のためにあらゆる普通じゃない語を抽出して網羅的な解説つくれ」(要約)って指示してるのにこれ
https://claude.ai/share/992fc340-08a2-48d2-9337-6fd5de744a23
やっぱ一発じゃ難しいんかね
そして「アノソピック (Anthropic) 」で泣いた
なんかいい案ください先輩
ちなgithubに置くと重要な語と周辺の語が色分けされるようになってる
---
>どうぞ
ありがとうだけど小学生向け解説みたいなのじゃなくて、各用語毎の 正しい名称+正しい説明+初見用やわらか概念 集みたいなのが作りたいの…
MCPなら「MCP周りで出てくる用語がそこそこまとまってる簡易辞書」って感じ
対象はまさに アプリケーションって何？ な人から、ふんわり知ってる人まで
例えばアプリアプリ言うけど、じゃあアプリって何ですか アプリは分かるけどネイティブアプリってなんですかと
https://claude.ai/share/9ecc79d3-5b43-433c-beff-35b6845e6832
そういうの含めて「これ読んだら周辺の事もざっくり知れるしもっと深く掘りたいなら生成したり検索すりゃどうにかなりますよ」ってのが作りたいす
