Auto-sync: 2026-04-17 08:37
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Nano-Banana Pro: Prompting Guide & Strategies
|
||||
title: Nano-Banana Pro:Prompting Guide & Strategies
|
||||
source: https://dev.to/googleai/nano-banana-pro-prompting-guide-strategies-1h9n
|
||||
author: shenwei
|
||||
published: 2025-11-28
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch.
|
||||
title: codecrafters-io/build-your-own-x:Master programming by recreating your favorite technologies from scratch.
|
||||
source: https://github.com/codecrafters-io/build-your-own-x?tab=readme-ov-file#build-your-own-insert-technology-here
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: [教學] ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報
|
||||
title: 教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報
|
||||
source: https://www.playpcesor.com/2025/10/chatgpt-canva-gamma-ai.html
|
||||
author: shenwei
|
||||
published: 2025-10-26
|
||||
|
||||
163
raw/Agent/AI-Memory-Tools-Two-Camps.md
Normal file
163
raw/Agent/AI-Memory-Tools-Two-Camps.md
Normal file
@@ -0,0 +1,163 @@
|
||||
# I Went Through Every AI Memory Tool I Could Find. There Are Two Camps.
|
||||
|
||||
**来源**: Twitter/X @witcheer
|
||||
**时间**: 2026-04-15 16:44:14
|
||||
**链接**: https://x.com/witcheer/status/2044456778843238689
|
||||
|
||||
**互动数据**: ❤️ 330 | 🔁 43 | 💬 33
|
||||
|
||||
|
||||
|
||||
there are 450+ repos tagged "agent-memory" on github and 460+ tagged "context-management." me and my agentic best friends went through them.
|
||||
|
||||
what I expected to find: 40 tools doing roughly the same thing with different APIs.
|
||||
|
||||
what I actually found: two fundamentally different paradigms, almost no one drawing the line between them, and a category that doesn't have a name yet.
|
||||
|
||||
I run a 24/7 agent setup on a Mac Mini M4. every session compounds on the last. that setup is the reason I noticed the split, most memory tools couldn't power what I'm doing, and the ones that could weren't being talked about as memory tools at all.
|
||||
|
||||
here's the map.
|
||||
|
||||
## The Two Camps
|
||||
|
||||
**camp 1: memory backends -** these tools extract facts from your conversations, store them in vector databases, and retrieve relevant ones when you ask. automated note-takers. they file things away and pull them back when needed.
|
||||
|
||||
**camp 2: context substrates -** these maintain structured, human-readable context that accumulates across sessions. nothing gets "extracted." the context is the files. your agent reads them, works within them, writes back to them, and the whole thing compounds over time.
|
||||
|
||||
camp 1 asks: "what should the AI remember?"
|
||||
|
||||
camp 2 asks: "what context should the AI work inside?"
|
||||
|
||||
most of the space (and most of the github stars) sit in camp 1. but camp 2 is where the architectures that actually scale to continuous, multi-session, multi-project work are emerging. and the language is starting to shift in that direction.
|
||||
|
||||
## Camp 1: The Memory Backends
|
||||
|
||||
Mem0 — 53.1k stars
|
||||
|
||||
the category leader by adoption. four operations: add, search, update, delete. extracts facts from conversations, stores them at three levels (user, session, agent), retrieves them via hybrid search.
|
||||
|
||||
dead simple to integrate. python and typescript SDKs. works with everything.
|
||||
|
||||
the limitation: memories are flat entries. no relationships between them. every extraction requires an LLM call, so quality depends entirely on how good the extraction prompt is. and once stored, they don't evolve, a fact from january sits next to a fact from april with no notion that one might supersede the other.
|
||||
|
||||
MemPalace — 46.2k stars
|
||||
|
||||
local-first verbatim memory. instead of extracting facts, MemPalace stores conversations word-for-word and organises them into wings (entities), rooms (topics), and drawers (original content). searches them with ChromaDB.
|
||||
|
||||
the benchmark numbers are the highest in the space: 96.6% retrieval recall on LongMemEval using raw semantic search alone, no API calls, no LLM. 98.4% with hybrid pipeline. 99%+ with LLM reranking.
|
||||
|
||||
the limitation: verbatim storage scales linearly. the more you talk, the bigger it gets. no compression, no synthesis. if your problem is "find the thing I said three weeks ago," this is the best tool. if your problem is "give me the current state of my work across five projects," it's the wrong tool.
|
||||
|
||||
Supermemory — 21.8k stars
|
||||
|
||||
positions itself explicitly as "memory is not RAG." the differentiator is temporal awareness, say "I just moved to San Francisco" and it supersedes your old city. expired facts get forgotten automatically. user profiles combine stable facts with recent activity at ~50ms retrieval.
|
||||
|
||||
connectors for google drive, gmail, notion, onedrive, github. multi-modal across PDFs, images, videos, code. they created their own benchmark framework (MemoryBench) and claim #1 on LongMemEval, LoCoMo, and ConvoMem.
|
||||
|
||||
most camp 1 tools treat facts as permanent. Supermemory treats them as evolving. that's the closest camp 1 gets to thinking about state, not just storage.
|
||||
|
||||
Honcho — 2.4k stars
|
||||
|
||||
smaller but architecturally distinct. Honcho treats both humans and agents as "peers" in a unified model. an async reasoning service runs in the background, deriving psychological insights about each peer from their sessions. it's not just remembering what you said, it's building a model of how you think.
|
||||
|
||||
PostgreSQL + pgvector required. AGPL-3.0 (restrictive). heavier infrastructure than most.
|
||||
|
||||
the closest thing in camp 1 to caring about entity evolution rather than just fact storage.
|
||||
|
||||
the rest of camp 1, briefly:
|
||||
|
||||
Cognee (15.4k) combines vector search with graph databases for relational reasoning. Memori (13.3k) intercepts LLM API calls to capture execution context, hits 81.95% on LoCoMo using only 4.97% of full-context tokens. AgentScope, MemOS, EverOS, MIRIX, SimpleMem, Memobase, all variations on the same loop.
|
||||
|
||||
## What Camp 1 Tools Have In Common
|
||||
|
||||
every tool above runs the same fundamental loop:
|
||||
|
||||
conversation happens → system extracts facts or stores content → facts go into a database (vector, graph, or both) → next conversation, relevant facts get retrieved and injected
|
||||
|
||||
the intelligence is in the extraction and retrieval. the human interacts with the agent. the memory system works behind the scenes. you never touch the memory directly and you trust the system to remember the right things and surface them at the right time.
|
||||
|
||||
this works. the benchmarks prove it. but it's solving one specific problem: **fact recall.** "what did I say about X?" "what does the user prefer?"
|
||||
|
||||
there's a different problem none of these tools address.
|
||||
|
||||
## Camp 2: The Context Substrates
|
||||
|
||||
OpenClaw — 358k stars
|
||||
|
||||
you know what it is already, but its memory architecture is the part that matters here. plain markdown files: MEMORY.md for long-term storage, daily notes (YYYY-MM-DD.md) for running context, DREAMS.md for consolidation summaries.
|
||||
|
||||
the line from their docs that defines the philosophy: "the model only 'remembers' what gets saved to disk, there is no hidden state."
|
||||
|
||||
no vector database. no extraction pipeline. files the agent reads and writes to.
|
||||
|
||||
the most interesting feature is **dreaming**: a background process that consolidates daily notes into long-term memory in three phases:
|
||||
|
||||
- **light sleep** — screens daily notes, groups nearby lines into coherent chunks
|
||||
- **REM** — weighted recall promotion, frequently-accessed information becomes "lasting truths"
|
||||
- **deep sleep** — replay-safe promotion into MEMORY.md, reconciles rather than duplicates
|
||||
|
||||
only entries passing all threshold gates get promoted: minimum score 0.8, minimum recall count 3, minimum unique queries 3. six weighted signals score every candidate, relevance (0.30), frequency (0.24), query diversity (0.15), recency (0.15), consolidation (0.10), conceptual richness (0.06).
|
||||
|
||||
this is background consolidation of lived context. the system doesn't decide what's a "fact" but it promotes what keeps coming up as relevant.
|
||||
|
||||
Zep — 4.4k stars
|
||||
|
||||
Zep recently rebranded their entire positioning **from "memory" to "context engineering."** that one move is the strongest market signal in this entire landscape. a funded company with 4.4k stars looked at where the space was going and decided "memory" was the wrong word for what they were building.
|
||||
|
||||
under the hood, Zep uses a temporal knowledge graph (their Graphiti framework). facts include valid_at and invalid_at timestamps. it extracts relationships automatically and returns pre-formatted context blocks optimised for LLM consumption. sub-200ms retrieval. SOC2 Type 2 and HIPAA compliant.
|
||||
|
||||
Zep sits between the two camps architecturally, it still extracts and retrieves. but the rebrand is the tell. the company closest to the camp 1 / camp 2 boundary chose camp 2's language.
|
||||
|
||||
Thoth — 145 stars
|
||||
|
||||
tiny project, deepest architecture I found in the entire landscape. Thoth builds a personal knowledge graph with 10 entity types connected by 67 typed directional relations. FAISS vector search with one-hop graph expansion before every LLM call.
|
||||
|
||||
the standout is the **dream cycle**, a nightly four-phase process:
|
||||
|
||||
duplicate merging at 0.93+ similarity threshold → description enrichment from conversation context → relationship inference between co-occurring entities → confidence decay on relations older than 90 days
|
||||
|
||||
three anti-contamination layers prevent cross-entity fact bleed. it's the most sophisticated automated memory refinement I found. it's sitting at 145 stars because it requires you to take the camp 2 thesis seriously enough to set up a knowledge graph for your own context. most people don't.
|
||||
|
||||
worth watching.
|
||||
|
||||
TrustGraph — 2.0k stars
|
||||
|
||||
introduces "Context Cores", portable, versioned bundles that contain domain schemas, knowledge graphs, vector embeddings, evidence sources, and retrieval policies. treats context like code: version it, test it, promote it, roll it back.
|
||||
|
||||
the framing matters. every camp 1 tool treats memory as a side effect of conversations. TrustGraph treats context as a first-class artifact with identity, versioning, and a lifecycle. you can hand a Context Core to a new agent and it inherits the full operational context. you can fork one for an experiment and merge it back.
|
||||
|
||||
this is the closest thing in the space to what a packaged, portable unit of context looks like. the implementation is heavy (Cassandra + Qdrant), but the conceptual model is the right one.
|
||||
|
||||
MemSearch (by Zilliz) — 1.2k stars
|
||||
|
||||
markdown-first memory from the team behind Milvus. memories are .md files, human-readable, editable, version-controllable. Milvus runs as a "shadow index" derived from the files, fully rebuildable. **the files are the source of truth. the vector search is just an access layer on top.**
|
||||
|
||||
three-layer progressive disclosure: semantic chunks → full sections → raw transcripts. hybrid search (dense vectors + BM25 + RRF reranking).
|
||||
|
||||
what's notable is that this came from Zilliz, a vector database company. they shipped a memory system where their own product is downstream of the files. that's a meaningful concession about where the source of truth actually lives.
|
||||
|
||||
## What Camp 2 Tools Have In Common
|
||||
|
||||
the loop is different:
|
||||
|
||||
agent reads structured context before working → agent works within that context → agent (or background process) writes back to the structured context → next session, the context is richer than before
|
||||
|
||||
the intelligence is in accumulation. the context is the memory. and because it's files (markdown, knowledge graphs, context containers), a human can read it, edit it, correct it, and understand exactly what the agent knows.
|
||||
|
||||
camp 1 optimises for **recall**: can the system find the right fact?
|
||||
|
||||
camp 2 optimises for **compounding**: does the system get better over time?
|
||||
|
||||
## Where This Is Heading, And What I'm Working On
|
||||
|
||||
the pattern from running a 24/7 agent setup is clear. memory and context aren't the same problem. my agent doesn't need to "remember" that I prefer dark mode. it needs to operate inside a context that includes my active projects, the people I work with, recent decisions, and what happened yesterday.. and that context needs to be richer tomorrow than today.
|
||||
|
||||
memory backends solve recall. 96%+ accuracy, sub-200ms latency, drop-in APIs. if you need a chatbot to remember user preferences, Mem0 or MemPalace will do it.
|
||||
|
||||
but if you're running an agent continuously, one that works while you sleep, reads from the same knowledge base your other tools write to, and gets meaningfully better over weeks and months, the context substrate approach is what makes that work.
|
||||
|
||||
my prediction is that within 6 months, "context engineering" replaces "memory" as the default term for what serious agent infrastructure does. the projects building substrate-style architectures will pull ahead of the ones still framing the problem as fact storage. the benchmarks will get rewritten or new ones will replace them.
|
||||
|
||||
the project I'm working with is **ALIVE** (alivecontext.com / @AliveContext_). structured context substrate, file-native, agent-agnostic. walnuts as portable context containers. zero infrastructure dependencies, plain files that compound. it's what I run on top of Hermes Agent on the Mac Mini and in Claude Code, and it's the reason that setup actually works instead of resetting every session.
|
||||
|
||||
the category needs a name. I think it's context substrate. either way, if you're building agents that need to run for more than one conversation, you're going to end up here.
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Polymarket Autopilot: Automated Paper Trading
|
||||
title: Polymarket Autopilot:Automated Paper Trading
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Project State Management System: Event-Driven Alternative to Kanban
|
||||
title: Project State Management System:Event-Driven Alternative to Kanban
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Todoist Task Manager: Agent Task Visibility
|
||||
title: Todoist Task Manager:Agent Task Visibility
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Cloud Operating Model: Key Strategies and Best Practices
|
||||
title: Cloud Operating Model:Key Strategies and Best Practices
|
||||
source: https://www.bacancytechnology.com/blog/cloud-operating-model
|
||||
author: shenwei
|
||||
published: 2025-02-07
|
||||
@@ -8,7 +8,6 @@ description: Learn how to design a future-ready Cloud Operating Model for govern
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
Organizations are rapidly abandoning traditional IT infrastructures for cloud-first architectures, accelerating migration. By 2025, it is predicted that 89% of organizations will operate from the cloud to enhance scalability, agility, and cost-efficiency ([Gartner](https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences)). But a mere shift to the cloud is not sufficient. Companies may run into unexpected costs and security loopholes and may be met with chaos in operations if they have not structured their approach well.
|
||||
|
||||
A Cloud Operating Model (COM) guarantees orderliness and is the foundation upon which cloud investments can be managed effectively, securely, and sustainably. [Flexera’s 2024 State of the Cloud Report](https://info.flexera.com/CM-REPORT-State-of-the-Cloud) argues that while 59% of enterprises experience difficulty managing cloud costs, while 8% organizations are worried about sustainability and reducing carbon footprint.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation | LinkedIn
|
||||
title: DevOps Culture and Transformation:Fostering Collaboration, Agile Practices, and Innovation | LinkedIn
|
||||
source: https://www.linkedin.com/pulse/devops-culture-transformation-fostering-collaboration-hemant-sawant-4qsve/?trackingId=fob2ofyA9J1dl534m3n0SA%3D%3D
|
||||
author: shenwei
|
||||
published: 2001-02-27
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: DevOps Maturity Model: From Traditional IT to Advanced DevOps
|
||||
title: DevOps Maturity Model From Traditional IT to Advanced DevOps
|
||||
source: https://www.bacancytechnology.com/blog/devops-maturity-model
|
||||
author: shenwei
|
||||
published: 2024-08-14
|
||||
created: 2025-03-01
|
||||
description: Explore the DevOps Maturity Model: its five stages, benefits, progress metrics, security considerations & how to avoid challenges for effective implementation.
|
||||
description: Explore the DevOps Maturity Model:its five stages, benefits, progress metrics, security considerations & how to avoid challenges for effective implementation.
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets
|
||||
title: How to Simplify Multi-Account Deployments Monitoring:Centralized Logs for AWS CloudFormation StackSets
|
||||
source: https://aws.amazon.com/blogs/devops/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets/
|
||||
author: shenwei
|
||||
published: 2025-10-24
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Public vs Private vs Hybrid: Cloud Differences Explained
|
||||
title: Public vs Private vs Hybrid:Cloud Differences Explained
|
||||
source: https://www.bmc.com/blogs/public-private-hybrid-cloud/
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: RTO vs RPO: Key Differences for Modern Disaster Recovery
|
||||
title: RTO vs RPO:Key Differences for Modern Disaster Recovery
|
||||
source: https://launchdarkly.com/blog/rto-vs-rpo/
|
||||
author: shenwei
|
||||
published: 2019-01-18
|
||||
created: 2025-07-26
|
||||
description: Understand RTO vs. RPO: their critical differences, their impact on modern software delivery, and how to effectively achieve your disaster recovery goals.
|
||||
description: Understand RTO vs. RPO:their critical differences, their impact on modern software delivery, and how to effectively achieve your disaster recovery goals.
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Modern ITSM: Driving Efficiency, Security & Resilience
|
||||
title: Modern ITSM:Driving Efficiency, Security & Resilience
|
||||
source: https://www.linkedin.com/feed/update/urn:li:activity:7301120918150352896/?utm_source=share&utm_medium=member_ios&rcm=ACoAADE1eGIB9ndhzD0qmslDUew4rjAk2upsYtg
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
@@ -4,7 +4,7 @@ source: https://www.bacancytechnology.com/blog/what-is-devsecops
|
||||
author: shenwei
|
||||
published: 2023-10-30
|
||||
created: 2025-12-19
|
||||
description: Understand What is devsecops: importantce,its security integration at every stage of the SDLC, its benefits, best practices, challenges, and more.
|
||||
description: Understand What is devsecops:importantce,its security integration at every stage of the SDLC, its benefits, best practices, challenges, and more.
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
@@ -1,114 +0,0 @@
|
||||
---
|
||||
title: 输出可能为: origin https://github.com/ishenwei/tiktok_pm.git (fetch)
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: [github, proxy, push, socks5]
|
||||
---
|
||||
|
||||
#github #push #proxy #socks5
|
||||
|
||||
|
||||
这是一个典型的**网络连接干扰**问题，特别是在国内访问 GitHub 时非常常见。
|
||||
|
||||
### 核心原因分析
|
||||
|
||||
`Recv failure: Connection was reset`（连接重置）并不是账号权限验证失败，而是 **TCP 连接层面的中断**。
|
||||
|
||||
- **现象：** 客户端尝试与 GitHub 服务器建立安全连接（TLS Handshake），但中间的网络防火墙（GFW）检测到了流量特征或目标域名，强行发送了 TCP RST 包阻断连接。
|
||||
|
||||
- **为何间歇性：** GitHub 的 CDN 节点众多，部分 IP 被封锁，部分未被封锁；或者是干扰策略存在由于流量负载导致的“漏网之鱼”。
|
||||
|
||||
|
||||
### 解决方案
|
||||
|
||||
最有效、最根本的解决方案是让 Git 的流量走你本地的代理通道（既然你之前提到过使用 V2RayN，这是最直接的利用方式）。
|
||||
|
||||
#### 方法一：为 Git 单独配置代理（推荐）
|
||||
|
||||
这种方法只会影响 Git 命令，不会干扰终端里其他命令的网络请求。
|
||||
|
||||
假设你的代理软件（如 V2RayN, Clash 等）本地监听端口如下（请根据你实际设置修改端口号）：
|
||||
|
||||
- HTTP/HTTPS 代理端口：`10809`
|
||||
|
||||
- SOCKS5 代理端口：`10808`
|
||||
|
||||
|
||||
**1. 设置 HTTP 代理（最通用）** 在终端（Terminal 或 PowerShell）执行：
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
git config --global http.proxy http://127.0.0.1:10809
|
||||
git config --global https.proxy http://127.0.0.1:10809
|
||||
```
|
||||
|
||||
_注意：即使是访问 `https://`，配置项名称也是 `https.proxy`，但代理协议通常写 `http://` 即可，除非你的代理明确要求 https。_
|
||||
|
||||
**2. 设置 SOCKS5 代理（速度通常更快）** 如果你想走 SOCKS5 协议：
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
git config --global http.proxy socks5://127.0.0.1:10808
|
||||
git config --global https.proxy socks5://127.0.0.1:10808
|
||||
```
|
||||
|
||||
**验证配置是否生效：**
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
git config --global --get http.proxy
|
||||
```
|
||||
|
||||
**如何取消代理：** 如果你切换了网络环境（例如到了国外），不再需要代理，可以使用以下命令取消：
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
git config --global --unset http.proxy
|
||||
git config --global --unset https.proxy
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 方法二：从 HTTPS 切换到 SSH 协议
|
||||
|
||||
有时候 HTTPS 的 443 端口干扰严重，但 SSH 的 22 端口相对稳定（或者反过来）。你可以尝试更改远程仓库地址。
|
||||
|
||||
**1. 查看当前远程地址**
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
git remote -v
|
||||
# 输出可能为: origin https://github.com/ishenwei/tiktok_pm.git (fetch)
|
||||
```
|
||||
|
||||
**2. 修改为 SSH 地址**
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
git remote set-url origin git@github.com:ishenwei/tiktok_pm.git
|
||||
```
|
||||
|
||||
_前提：你必须已经生成了 SSH Key (`ssh-keygen`) 并将公钥上传到了 GitHub Settings 中。_
|
||||
|
||||
**进阶：如果 SSH 直连也不稳** 可以通过修改 `~/.ssh/config` (Linux/Mac) 或 `C:\Users\你的用户名\.ssh\config` (Windows)，让 SSH 连接也走代理：
|
||||
|
||||
Plaintext
|
||||
|
||||
```
|
||||
Host github.com
|
||||
User git
|
||||
Hostname github.com
|
||||
# Windows 下使用 connect.exe (Git自带)
|
||||
ProxyCommand connect -S 127.0.0.1:10808 %h %p
|
||||
# Linux/Mac 下使用 ncat (需安装 netcat)
|
||||
# ProxyCommand nc -X 5 -x 127.0.0.1:10808 %h %p
|
||||
```
|
||||
@@ -1,155 +0,0 @@
|
||||
---
|
||||
title: 1. 安装Plex
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created: 2025-02-23
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
|
||||
# 1. 安装Plex
|
||||
|
||||
## 1.1 群晖NAS安装Plex Server
|
||||
|
||||
目前在群晖的套件中心里直接找到 Plex Media Server直接安装即可
|
||||
|
||||
目前我的Plex账号是用Apple ID: ishenwei@hotmail.com来进行登录的
|
||||
|
||||
## 1.2 在当贝盒子上安装Plex客户端
|
||||
|
||||
客厅里的电视是用当贝盒子进行视频播放的，从AppMirror网站上下载了最新版本的
|
||||
|
||||
|
||||
|
||||
com.plexapp.android_10.26.0.2578-966828321_minAPI23(armeabi-v7a)(nodpi)_apkmirror.com
|
||||
|
||||
## 1.3 在卧房电视机的华为盒子上安装Plex客户端
|
||||
|
||||
因为该盒子里的操作系统较老，所以不支持Android 6.0+只能支持5.0+,所以我找到了能支持5.0+的最高的版本
|
||||
|
||||
com.plexapp.android_10.5.0.4996-944846913_minAPI21(armeabi-v7a)(nodpi)_apkmirror.com
|
||||
|
||||
|
||||
|
||||
以上两个APK文件我保存在： NAS/Software/家庭影视平台/Plex
|
||||
|
||||
# 2.安装Xiaoya Alist
|
||||
|
||||
这个是利用NAS的container manager的docker方式来进行安装的，整个过程比较波折，其中还学习到了一些关于Doker的技巧
|
||||
|
||||
总的来说Xiaoya Alist是一个网络资源分享平台，运行以后可以出现一个列表，当配置好云盘链接后，可以将相关资源直接转存到自己的云盘上，比如Aliyun
|
||||
|
||||
我自己 NAS上小雅的链接是：
|
||||
|
||||
[http://192.168.3.17:5678/](http://192.168.3.17:5678/)
|
||||
|
||||
|
||||
|
||||
## 2.1 安装xiaoya alist
|
||||
|
||||
首先我的NAS上的Container Manager除了问题，怎么呀刷不出注册表信息，就是无法读取docker hub的信息。我尝试了用Putty通过SSH登录NAS，然后用docker pull的命令下载也不行。在这里必须要主要，要NAS支持可以通过SSH访问必须进行配置。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
后来我查询了ChatGPT, 里面选择了另一个从另一台机器下载Docker Image然后再load到NAS机器上的方法。 整个过程如下：
|
||||
|
||||
我在我自己工作的笔记本上安装了DockerDesktop版本，然后正常的pull xiaoya 的image:
|
||||
|
||||
```docker
|
||||
docker pull xiaoyaliu/alist
|
||||
```
|
||||
|
||||
通过以下命令将下载的image打包成tar文件
|
||||
|
||||
```docker
|
||||
docker save -o xiaoya.tar xiaoyaliu/alist
|
||||
```
|
||||
|
||||
我将打包好的xiaoya.tar文件上传到NAS文件系统里去，然后还是通过Putty来运行docker命令将image导入NAS的Docker中去。
|
||||
|
||||
```docker
|
||||
#cd 到xiaoya.tar存放的路径之后运行以下命令
|
||||
docker load < xiaoya.tar
|
||||
```
|
||||
|
||||
然后再进入NAS的Container Manager 界面后在image里就可以看到扫xiaoya/alist这个image了
|
||||
|
||||
|
||||
|
||||
接下来需要进行一些配置工作：
|
||||
|
||||
在本地先准备三个txt文件，然后根据官方文档配置Aliyun的token
|
||||
|
||||
**myopentoken.txt**
|
||||
|
||||
访问这个链接 后，用手机阿里云盘扫描二维码，然后在手机上确认授权，然后点击I have scan, 将生成的token保存在myopentoken.txt文件里。
|
||||
|
||||
[Get Aliyundrive Refresh Token](https://alist.nn.ci/tool/aliyundrive/request.html)
|
||||
|
||||
|
||||
|
||||
**mytoken.txt**
|
||||
|
||||
访问这个链接 然后用阿里云盘的App扫描二维码，将生成的token保存在mytoken.txt里
|
||||
|
||||
[阿里云盘 / 分享](https://alist.nn.ci/zh/guide/drivers/aliyundrive.html)
|
||||
|
||||
|
||||
|
||||
**temp_transfer_folder_id.txt**
|
||||
|
||||
登录网页版阿里云盘，在资源盘目录下创建一个folder, 将URL里的folder 的token保存在这个txt文件里。 这个目录将来会用于存放从xiaoya那边转存过来的视频
|
||||
|
||||
|
||||
|
||||
最后将这三个txt文件全部上传至 NAS/docker/xiaoya/ 目录下
|
||||
|
||||
配置Docker启动xiaoya，请注意以下圈出的是需要配置的地方：
|
||||
|
||||
|
||||
|
||||
启动后检查日志，看小雅是否正常启动。
|
||||
|
||||
[http://192.168.3.17:5678/](http://192.168.3.17:5678/)
|
||||
|
||||
# 3. 配置安装CloudDrive2来在NAS挂载Aliyun盘
|
||||
|
||||
在套件中心，设置里添加矿神源
|
||||
|
||||
|
||||
|
||||
然后在社群里找到CloudDrive2这个应用, 并安装。因为我的DSM是7+版本，所以需要额外在Putty root 下执行一条命令：
|
||||
|
||||
```docker
|
||||
sudo -i
|
||||
#input NAS admin password
|
||||
|
||||
sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege
|
||||
```
|
||||
|
||||
|
||||
|
||||
安装成功后打开CloudDrive进行配置：
|
||||
|
||||
[http://192.168.3.17:19798/](http://192.168.3.17:19798/)
|
||||
|
||||
|
||||
|
||||
用阿里云盘app扫描二维码，并授权，请主要，不要授权备份目录，仅资源目录即可
|
||||
|
||||
|
||||
|
||||
对Aliyun目录进行mount
|
||||
|
||||
|
||||
|
||||
# 4. 在Plex里导入Aliyun盘的内容
|
||||
|
||||
|
||||
|
||||
目前的策略是，可以用xiaoya选择要看的视频，然后在aliyun盘里移动到相应的目录比如 aliyun-movie, aliyun-tvshows, aliyun-documentory 然后让Plex进行视频刮削，并显示在Plex Media Server里。
|
||||
@@ -7,8 +7,6 @@ created: 2025-03-06
|
||||
description:
|
||||
tags: [docker, nas, synology]
|
||||
---
|
||||
|
||||
|
||||
#docker #synology #nas
|
||||
|
||||
Here is a example about transfer Docker images from my work laptop to my Synology NAS Docker
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: 为什么 Obsidian 让我戒掉了碎片化记录？
|
||||
source: https://mp.weixin.qq.com/s?__biz=MzI3NzcwOTY4MQ==&mid=2247486972&idx=1&sn=e61477c9f8628c7f534fc2183d87e2d3&scene=21#wechat_redirect
|
||||
author: shenwei
|
||||
published:
|
||||
created: 2025-03-13
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
Original *2025年03月05日 23:02*
|
||||
|
||||
### 以前的笔记，像是丢进了黑洞
|
||||
|
||||
老实讲，我以前的笔记习惯非常糟糕——想到什么记什么，但从不复盘。印象笔记里塞满了各种“灵光一闪”，但基本没打开过；微信收藏夹里躺着上百条“稍后阅读”，但从来没“稍后”过；甚至连 Obsidian 早期的使用，也是把它当成一个炫酷的 Markdown 记事本，结果就是……又堆了一堆“存而不读”的笔记。
|
||||
|
||||
说白了，**我只是把信息收集起来，却没让它发挥价值**。
|
||||
|
||||
我相信很多人都有类似的困扰——记了那么多，为什么到用的时候，脑子还是一片空白？
|
||||
|
||||
### Obsidian 的核心魅力：关系，而不是堆砌
|
||||
|
||||
如果说 Obsidian 改变了什么，那就是让我真正意识到：**笔记的价值，不在于“存”，而在于“联”**。
|
||||
|
||||
📌**双链（Backlinks）**是个神奇的功能。一开始我也觉得“双链”这种东西玄乎其玄，但当我尝试把**“零散的记录” 和 “已有的知识” 关联起来**，一切都变了。
|
||||
|
||||
• 某天我写了一篇关于“如何提高写作灵感”的笔记，意外发现它和我三个月前记下的“输入-输出模型”有关联。
|
||||
|
||||
• 我整理一篇关于“番茄工作法”的文章时，发现它跟“沉浸式深度工作”可以结合起来用。
|
||||
|
||||
这种“点对点”的连接，让零碎的笔记慢慢长成了一张网络，我开始真正用自己的方式消化知识，而不是简单存档。
|
||||
|
||||
### 如何用 Obsidian 让笔记“活”起来？
|
||||
|
||||
光说理论没用，我分享几个我自己在用的方法，大家可以试试看：
|
||||
|
||||
✅**每天用“每日笔记”串联想法**
|
||||
|
||||
别让你的笔记变成“死笔记”，每天写几行，总结当天学到的新东西，并顺带看看有没有旧笔记可以连接。
|
||||
|
||||
✅**尝试用“地图笔记”整理核心主题**
|
||||
|
||||
选几个你关心的主题（比如“写作技巧”），整理一个“索引页”，让你所有相关的笔记都能快速导航过去。
|
||||
|
||||
✅**定期复盘，把无用笔记删掉或合并**
|
||||
|
||||
Obsidian 不等于“记了就有用”，定期翻翻旧笔记，把无意义的删掉，或者整理成更有逻辑的知识模块。
|
||||
|
||||
### 你的笔记，也被“信息黑洞”吞噬了吗？
|
||||
|
||||
如果你也有“记了但不用”的困扰，不妨试试上面的方法。笔记的最终目的是让信息为你所用，而不是让你被信息淹没。
|
||||
|
||||
📢**你是如何管理你的笔记的？你有没有遇到相似的问题？**欢迎在评论区聊聊你的笔记方法，或者你对 Obsidian 还有哪些疑问！🎯
|
||||
|
||||
如果你对 Obsidian、知识管理、效率工具感兴趣，欢迎关注**赫点茶**🍵！我会持续分享**实用数字产品、成长思维、以及工作和生活中的高效技巧**。
|
||||
|
||||
👇 点击下方卡片，一起提升效率，优化生活！🚀
|
||||
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: 为什么你的笔记总是乱糟糟？试试这个方法，彻底告别信息混乱！
|
||||
source: https://mp.weixin.qq.com/s?__biz=MzI3NzcwOTY4MQ==&mid=2247486984&idx=1&sn=51232deb29cb0a2ed81fac0daa972217&scene=21&poc_token=HDC7RGmjnpWk-8uvZfBeR3Ky26-5B19_c0nN7BR7
|
||||
author: shenwei
|
||||
published:
|
||||
created: 2025-12-19
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
原创 赫点茶 [赫点茶](https://mp.weixin.qq.com/) *2025年3月6日 21:02*
|
||||
|
||||
|
||||
|
||||
效率工具 183
|
||||
|
||||
Obsidian 79
|
||||
|
||||
继续滑动看下一个
|
||||
|
||||
赫点茶
|
||||
|
||||
向上滑动看下一个
|
||||
|
||||
赫点茶
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 输出: /opt/homebrew/bin/gog
|
||||
title: 输出:/opt/homebrew/bin/gog
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
|
||||
Reference in New Issue
Block a user