挂载和同步一类，在本地有文件系统结构的，可以搭配 boxcrypter 。网盘自己客户端能支持的比如说 onedriver 、坚果云，第三方能支持的比如说可以看 rclone 的支持列表。

容量和隐私的问题主要是看网盘的性质，对于阿里云盘、百度网盘这种以分享为主的网盘，它实际就是把公共资源在你的帐号下面登记了一份，并不是说你的文件就是你的，只是一个引用，其他人也可以引用，用这种方法降低资源分享的成本，给你一个容量很大的幻觉。区分权限的正确性全看智商和良心

针对锁和 python 效率的问题：
- 如果你的计算任务可以用 c/rust 的模块，最好是在 c/rust 的部分处理，最好能批处理
- 如果是 pure python ，也许可以试试 taichi 或者类似的东西。因为 python 可以被再次编译成 native 或者 gpu kernel ，并针对架构优化
针对 asyncio 只管异步切换，计算存在长时间阻塞的问题
- （不同进程、单独服务的方案）要么 celery ，或者自己搓一个简单的队列
- （简单在同一个进程中的方案）要么 thread pool executor

存路径这个做法本身有点怪……我可能会选择文件的其他特征来做这个事情……

不清楚场景，假设场景必须要存路径，考虑一下把 SOMEHASH(filepath, account), account 作为 key 呢？比如说 trigger 去 set 一下额外的列为 SHA2(CONCAT(filepath,"\\/", account), 256)，把这个列作为 unique key 的一个 column 。降低碰撞概率的话，多加一种两种哈希呢？

我是写业务的菜鸡，暂时还只能想怎么实现的问题。要不然就只能业务上限制一下了

听歌是为了解决更严重的问题，不解决特定的问题就不需要听歌，比如说噪音、状态引导、blablabla

@gridsah 赞！

> 原理是 OpenZFS 直接和内核里的 NFS 子系统通信
哈，我暂时还没有研究这些。如果是这样的话，其实我就比较倾向直接用 exports ，因为最近非常喜欢 nixos 那种 declarative 的理念，而且这种方法管理的系统很容易统一各种 id ，不过不开心的就是还有很多工具不大好声明式管理，需要写很多足够健壮的脚本

> btrfs 离开群晖之后只能在特定几个版本的 Linux 内核下读数据
群晖用了一些私有的 flag ，是有问题。对于我来说，我更多的是被 arch wiki 里面的警告吓到了：The RAID 5 and RAID 6 modes of Btrfs are fatally flawed 。所以之前尝试 btrfs 的时候，叠了一层 mdadm ，btrfs 跑在单个 md 设备上。

> 快照用的空间被写满
对照了一下使用场景，我的 use case 里面数据大部分时候是增加的，不会有很多改变，所以对于我来说分配好 volume 留出冗余就还好。对于经常有变更的场景感觉是个问题

本地构建以后放到单独的存储里面啊，没必要放到 git 里面，这玩意儿不需要管理版本，只要有一个文件能告诉研发这个构建产物是哪个 reference （ commit/tag ）构建产生的就行。

像是 github 、gitea 、gitlab 、bitbucket 都提供了 repo release 这类功能，就是给你建立一个 release 然后放产物用的。

再不行有个 nfs 、samba 、s3 、nexus 、webdav 什么的都可以放产物嘛。

如果是把 git 当存储，就把构建放到一个单独分支里面。如果存二进制建议再开个 git lfs

不要暴露自己的服务在公网上。

- 建议找个技术向的朋友，或者你自己懂一些 IT 的话，在国内租个最便宜的主机、并且做好安全措施。然后用 headscale ，或者 zerotier-one + 自建的一个发现服务（我不记得是叫 moon 还是什么了）。用这些公网发现、建立点对点的方案。

- 其他的 vpn 服务来建虚拟网络也可以，比如说 cloudflare 这类，但是我自己没有用过，所以我不做评价。
- 直接用 wireguard 也是一个选择，但是自己用服务器中转速度会受限于你的服务器的速度，并且流量可能会计费
- tailscale 、zerotier （公共的发现服务）这类国外的服务，有的时候发现的不是最短的路径，可能会绕很远的一圈。headscale 是 tailscale 的自建服务器，我自己测试是 ok 的，zerotier-one 的 moon 也是类似的东西，我没有正儿八经的配置过。

补充内存计算的问题：java8 用 8u372 及以上版本，修了 cgroup2 支持，这是很多新发行版默认的 cgroup 实现，涉及到内存的限制和计算。

java11 以上可能没这个问题了

Dockerfile 略微注意一下就好了

- 尽量使用多阶段构建，要不然代码拷到 layer 里面了
- 慎用 alpine ，不清楚的时候一律用 debian 作为基础镜像
- 部署环境内核比较新的时候，base 不要使用 centos7 这种带着很老的 glibc 的 image ，java 和库依赖 glibc 的时候，很老的 glibc 在新内核上会有问题

现在 zfs 主要是在 openzfs 上做开发了吧，bsd 那边可能也切过来了？我这两年没有特别多用其他 unix ，不大好横向比较

我的 pc 现在是 nixos root on openzfs ，compression=on ，开 dedup 以后资源消耗有点大，但是我感觉在公司用 xfs vdo 也是有点，后来关掉了，因为发现我的用例来说即使算上 rust / node_modules 实际上好像也没有那么多 duplication 。文件系统自带 samba/nfs 这种感觉有点……奇异。现在处于不停的啃 openzfs 、gentoo 、solaris 之类的文档的状态，打算先在日常使用、变更最多的机器上尝试各种新技术以后再上 nas 。

nas 之前是 btrfs ，但是我心里有点打鼓，尤其是我没有用专门的很好的设备，而是捡了个垃圾，供电什么的都没有那么好。所以也是先换 debian + mdadm + xfs 了，在公司用的多，我自己解决一部分问题，大佬解决一部分问题。btrfs 以后再尝试吧。

比较在意 lvm2 的 snapshot 在什么方面不能满足需求？我自己感觉 lvm2 的 snapshot 一般情况也够用了

truenas core 现在还是 freebsd 吧？我看 truenas scale 是 linux 的样子。以前尝试过 core ，后来没太多用这个。

部署：
> 需要支持服务端 windows/linux/mac/bsd 部署
如果你能搞定不同端 go 的 CI （构建、测试），go 的评分会略微高一些，否则脚本类会好一些。

其他因素：
评分的构成还有你具体的业务，以及你所在的地区不同语言找到能用的人的难易度

写的不够多，写的多了语言不是问题，在于怎么样设计架构来更好的满足需求和解决问题，一步步细化以后后面才有语言的选择问题，那个时候不是我们选择语言，而是生态和需求确定语言

- 分区是很早以前的一种需求，我记得主要是应对早期存储驱动器寻道时间的问题吧。SSD 是完全没有寻道问题的。
- 分区的确可以简化重装系统的流程，但是重装系统丢数据的问题也可以通过网络存储和网盘来解决。

三个担忧的回答：
- 写权限，没事儿不写系统目录，其他目录基本上不会有啥大问题。
- 尽量往自己的 USERPROFILE 里面赛
- 尽量使用同步工具，实时上传到网络存储，机器当成一个瘦终端，数据尽早随时上传。也可以单独或者合并使用 rclone 这种方案定时备份

补充：
- 容量问题：像是坚果云云桥，或者我很久没有用了估计 onedrive 也有，都可以本地懒加载文件，不需要的时候释放掉空间。
- 其他的要注意的地方
- 我被 bitlocker 背刺了两次，没有提示的情况下加密了我的用户数据目录以后，因为 tpm 的 bug 无法解锁，并且官网的用户账户中没有找到根据文档提示应该已经上传了的 recovery key 。建议时不时看一眼，给自己的数据多备份一下
- 自己的目录如果要设置安全/权限，可能需要理解一下 windows 的用户和权限机制，要不然重装完系统可能会有新系统不认老系统设的权限还要自己再设置一次的麻烦的事情，但是也不算是大问题。

floccus + 坚果云，坚果云单独目录设置不同步到本地。

但是移动端不好使，换个思路是不依赖浏览器，在浏览器之外有一个应用来管理这些，加上桌面浏览器有集成。raindrop.io

不同的用户对不同的注册要求比较敏感，不一定是同时出现
- 邮箱：有的人一辈子就用一次两次邮箱
- 手机：对追踪比较敏感
- 用户名：昵称起名废，遇到多次已有用户名
- 验证码、各种形式的验证：麻烦
- 密码记忆：有的用户觉得同一个密码不安全，记多个密码占脑子
- 委托：有的用户会把一些网站的用户和访问权限集中给一个同事处理
- 单纯不想在网上留踪
- TODO：奇奇怪怪的可能性非常多，列不完

零成本就是 Gitee Pages 这种方案了，如果有构建的步骤可以用 Gitee Go 补全，或者本地构建。缺点是会收到厂商制约

如果想独立于厂商的话，CDN + 对象存储会比较便宜。

访问量不大的话，还有个思路是有很多鼓励开发者的小网站方案，比如说楼上老哥说的 Vercel ，但是我没用过，不清楚国内的速度。

不过博客还是要先写，写了有人读，读了有反馈，反馈有对自己的奖励效应。这之后才是怎么建的问题。

因为“写程序”并不是一个单纯编代码的过程，其中涉及到很多计算机的知识、涉及到方法论，涉及到积累和设计。


就是上面几层说的，其实中间是有两条路径的：

一条是以有趣为核心。
先写简单有趣但是不带有目的的程序，取悦自己，取悦身边的人，这可以让你以一些简单的 topic 为中心，逐渐接触到更深的东西。像是 App 就不是一个简单的东西，并不适合作为新手村第一个任务，这玩意儿涉及到语言、系统、网络、UI 。如果要涉及到特定的任务，比如说编辑视频，那么还需要学习编解码、学习设计、考虑怎么让自己用着舒服，涉及到的领域和问题就非常的繁杂，很难推进学习进度。换个领域可能好理解一些，炒菜。相对的，从命令行对话、表白，到做一个命令行工具，到做一个命令行的文字冒险游戏，到做一个带界面的 Video game ，到做一个带界面的视频编解码工具，到做一个视频编辑工具，这就是一个比较平缓的路径。

另一条是以知识和技能网络为核心。
根据自己发展方向，在学习前和学习中优先构建路线图（ roadmap ），根据路线图遍历节点学习有关的知识。这其中其他学科有的会倾向于先学知识再动手，相比之下计算机是理科中非常具有工科动手性质的理论学科领域，我个人觉得应该清楚目标以后，边学边动手边动手边学。这点我觉得 OP 没有什么别的大问题，无非是没有路线图而且选择的目标过大，无法取得进展所以引发了自己的焦虑。


无论哪条路线，"每天都要去更改视频中的文字...能不能自己写一个软件然后装到手机上" 都不是一个简单的事情，"Python 写爬虫" 也不是一个简单的按照格式写逻辑就可以爬下来内容的事情，环境、网络千变万化，不理解自己做了什么的话、有一丢丢变化导致的失败都会焦头烂额。


关于语言、工具的选择。OP 提到以前学过 Python ，那么其实可以先多用用 Python 。

写程序其实是一个把想法表达出来让对方（电脑里面其他的程序，也就是库）理解的过程，考虑一下我们和其他人沟通的过程，我们要考虑我们现在这个语言怎么表达我的意思，最终会拆解到，语言、表达方式、对方的思考（架构，逻辑），再加上对于特定的主题需要有足够的词汇积累。写程序是类似的，我们需要学习语言语法，学习怎么把自己的想法表达出来，学习语言的逻辑，学习有什么库和库的逻辑。我们有想法的时候，最好是可以把想法用画图也好、文字也好，先用自然语言叙述清楚自己想要什么，然后再按照自己写的布瑞符去用程序实现，有的时候逻辑复杂了，我们可以自己写一点点验证想法，然后按照关键词从积累里面找词汇找库，这个时候“各种模块都不熟悉，也不知道有哪些模块能干事情”的问题就没有了，因为你可以查了。


有的时候开始都不知道从哪里开始，可以从两个角度理解这个问题，一个是有趣但是曲线过于陡峭，一个是路线图上基础缺失，从语言表达来说也可以理解成词汇量不够，甚至不能用简单的语言转述复杂的想法。这种情况我觉得能做的就是，要么放一放，舒缓一下心态，要么多了解一下行业和周边，一点点做词汇积累，如果可以用简单语言转述一个复杂的想法，那么这个时候去搜索就是合适的了。


提到英语，我们查资料也不会用很复杂的英语，native speaker 并没有那么多，rephrasing into simple english 重新用简单英语表达，其实是大部分时候的常态。我也经常跟不上视频，不过我看视频也不多，阅读更多一些，技术文章没啥修辞不会太难的。


最后从编辑视频的角度来说，我建议用 Python 来处理视频，不要做 app 。不需要界面，跑命令即可。涉及到的知识主要是要理解视频由视频流、音频流、字幕流之类的这些流组成，涉及到的库就是视频编辑的，二选一 moviepy 或者 opencv ，还有音频编辑的。opencv 更多是个计算机视觉的库，只不过可以视频输入、按帧处理图像、输出视频，所以很多工具需要自己写。moviepy 我没有用过，看介绍是说音视频都没有用过。

- 非开发人员方案：坚果云 + 任意编辑器，本地文件系统可以集成加密工具，也可以集成 webdav 。服务器和本地都有备份，有历史记录，协作有付费团队的审计，包括 md 在内渲染好的文档可以直接分享。文档类的可以用客户端增量上传，注意 webdav 都是全量。坚果云公司内部用自己的产品管理自己的文档，公司自身是自己的用户
- 我自己作为开发的方案：任意 Git 托管 /git-ssh + Drone/嫖公有云 CI + Hugo 这类渲染引擎 /自己写脚本 + 嫖 S3 ，手机也有很多编辑器有 git 集成。

@skiy 我是觉得国内现在首先就是缺生态，缺应用，普通用户用不起来。其实底层的东西国内做了很多了，lvs 、tidb 、nginx 、linux 内核模块（比如说华为），甚至有些差不多算是正常用的服务器用的国产的 CPU （有些网站就跑在这些服务器上）。有了用户才知道脖子被别人卡在了什么地方，知道下来要做什么优化什么，没有用户就空想只能给别人养用户，或者做了东西有问题但是发现不了。

碎片化这个是个问题，但是不只是版本的问题，版本其实还好，snap 之类的工具就是解决这些。主要是桌面环境本身的能力，有的环境有 A 有 B 没 C，有的有 A 有 C 没 B 。鸿蒙、Fuchsia 都是把能力细化以后，应用按照能力分发，比如说现在 Android 本地 apk 只是一个形式，内部都是分解开的，分发的不一定是一个完整的应用。