宏观整体上应该有一个 scope 的概念，类似代码中的变量作用域。不管是社会科学还是自然科学，所有的理论都是人类存活到现在能够总结出来的经验，这些理论只是到目前为止还是正确的，不代表它永远正确。宏观上看，人类目前得到的经验和盲人摸象并没有区别，无非是 scope 的大小不同。

所谓夏虫不可语于冰，每个个体受限于历史局限性，无法获得永远正确的理论，但由于寿命是有限的，正确理论的 scope 能够覆盖个体存在时间，应该就能获取相对永远正确的理论。

虚无主义无法治疗，以上是我对自己虚无的一些“民哲”思考，个体有必要使用一些“相对”来稳定自己的存在。

关于相对和绝对、对立和统一，严肃哲学对这些应该有很好的解释和系统论证，能沉下心看书的话，应该能解惑。

@slrey K29 同好握手。用了快十年了，目前还是日常主力使用。chrome 长期 50+tab ，外加一个 vscode ，CPU 占用会高一些，但也没有感到卡顿。什么叫 CPU 过剩，十年了，3 代 i5 ，还是 ES QBNX ，现在竟然用的还不错。可能的确是没什么生产力需求，外接显示器、键鼠，笔记本盖子一年都开不了几次。

见过脚踩的，不过作为企业工业化生产还是用脚踩，且不说效率，公共卫生健康和消费者的心理影响真的不考虑一下吗？如果卖点就是所谓的古法且消费者了解这个古法，只要卫生能达标，自由市场，愿打愿挨那另说。
吃的东西，除了基本卫生标准外，心理影响也很重要。其实大部分家庭的卫生状况也就那样，但看别人家做饭比较别扭，自己做就无所谓了。有时候吃别人家饭会拉肚子，同吃的其他人就没问题，可能是肠道敏感，和肠道菌群类似的说法，可能还有所谓的家庭菌群。

每天洗澡时听，每次 10 分钟左右。太长的播客可能要洗一周的澡才能听完。

OP 对于镜像站不是最新感到意外，我觉得应该区分一下 proxy 和 mirror ，虽然有时候它们的界限不是太清晰。

proxy 和 mirror 都有可能拉不到最新的包，但底层逻辑可能不太一样。proxy 拉不到最新包一般是缓存没到期，mirror 拉不到最新包一般是定时同步周期问题。就底层逻辑和使用经验来看，proxy 拉不到最新包的概率比 mirror 要低很多，但仍有可能，具体依赖管理员的参数配置了。

就 docker 这里来说，虽然配置项叫 mirror ，国内主流加速器地址也都包含 mirror 字符串，但我更倾向于它是一个 proxy 配置。

@nightwitch 1688 关键词 站立桌 就有很多款式，我买的是那种两个分离 30X60 桌面，独立升降的。企图用桌子本身高度差来适配键盘和显示器的不同高度，但我刚刚意识到我下单这个的最大高度可能达不到这样的效果，最终还是需要调整显示器高度。包括邮费 88 元，由于还没有到手使用，无法给出评估或推荐。

一些思考，供参考：
- 预算充足，吃灰也不心疼的可以直接考虑电动，频繁（个人觉得一小时一次）切换坐立状态是使用站立桌的主要目的。毕竟手动等于不动。
- 手动也有应用场景的。个人理解的手动是指首次部署调试时可以进行调节的手动，后续使用一般不会进行调整。坐立切换是通过多个工位来实现的，这样就需要额外的设备，比如显示器、键盘、主机等。个人致力于打造在家里多个地点使用电脑的场景，多设备、工作区一致性都没问题，说以选择了手动。
- 虽然说动起来是最健康的，但不想动的时候想办法降低健康损耗也是有意义的。

预算有限，昨天下午刚在 1688 下单的站立桌，手动调节，到货了装上试试。

迫于贫穷，没有采用主流的电动升降方案，毕竟电动和手动价差 20 倍往上。目前使用多设备、多工位方案，反正在家，布置一个坐着办公和一个站着办公的工位也不麻烦。

是的，不是桌动，是人动。

感谢 op 的分享，非常赞同日志页面为主，降低心智负担的说法，准备再次入坑 logseq ，希望这次能坚持下去，改善一下自己的信息流。

@zinwalin 我上面说的 3 个都支持本地部署，不过不全部是开源的。
- azure devops server 非开源，需要授权，可以试用。目前公司主力使用，感觉优势主要是在大一统的项目管理方面，涵盖了产品需求、代码管理、测试计划、CI/CD 等。个人不太喜欢，微软的东西和主流开源产品的操作逻辑总是感觉不一样。
- gitlab 开源，有企业版和社区版。非重度使用，简单使用过流水线，在 CI/CD 和运维集成方面特性比较多，个人比较推荐体验。
- drone 开源，0.8 版本后似乎是私有协议了，目前有社区 fork 版本 https://github.com/woodpecker-ci/woodpecker ，整体比较轻量化，专注流水线本身，没有太多附加特性。

具体还是要根据使用场景选择，比如说自动化程度较低时，像 #8 提到的手动触发的参数化构建场景可能就是一个强需求，就我个人使用经验，这个场景 Jenkins 算是支持的最好的了，drone 几乎没有支持（一两年前使用体验），gitlab 支持但比较难受，azure 稍微好一点。

azure devops server
gitlab
drone

更换环境会带来新鲜感，但不一定能从根本上解决问题。

马克思主义有两个观点可以参考：
- 劳动是人的本质属性
- 资本对人的异化

人不能两次踏进同一条河流。

就这点来说，时间对所有人都是公平的。

耳石症资深患者，每年都会发作一两次，有快 5 年了。

个人经验：如果确认是耳石症，基本不用去医院看医生，可以在 B 站、微博搜搜相关视频，有自我复位的方法，差不多复位几次就能减轻，一到两天就会恢复。

抵抗虚无

Windows + Hyper-V 稳定使用多年。
还是看自己是否需要一个 7X24 开机的桌面，如果需要，则一般是在保证桌面使用情况下兼顾虚拟化、容器等各种玩具。这种场景下的 Windows 桌面 + Hyper-V 和 Linux 桌面 + KVM 都是不错的选择。当然也可以反过来，保证虚拟化平台优先，再考虑兼顾桌面使用，各种 Hypervisor+虚拟机桌面直通，会比较折腾一些。

@ugvfpdcuwfnh 就我个人了解到的信息，不考虑管理组件，Hyper-V Server 和 Windows 桌面中的 Hyper-V 都是 type-1 的虚拟化，层级应该是一致的。VMware Workstation 和 VBox 是 type-2 虚拟化，和 Hyper-V 的层级不一致。

没有部署过 gogs ，不过看你配置，证书文件似乎不太对，.csr 一般是指证书签发请求，证书文件一般是 crt 、cer 、pem 后缀。

据了解，hyper-v 并不是必须要一个桌面环境，可以以无头方式安装，然后虚拟机安装桌面系统直通。既然有 windows 桌面需求，还是推荐 windows server+hyper-v 方式来玩。

@4rat 其他的没有使用过，有需要可以参考 https://github.com/awesome-selfhosted/awesome-selfhosted#personal-dashboards ，或者逛逛 reddit 上的 selfhosted 板块。

运维是一个庞杂的工作或者说工种，传统上会划分很多角色，如网络运维、系统运维、应用运维等等。并且，运维和开发这两个词汇在现实中用来描述岗位时的精度不是一个级别的，不同公司的运维岗可能是完全不同的工作职责和范围。一般情况下，目前说运维是在说利用各种新技术进行应用运维以提高整体研发交付效率，提高业务可用性这么一个角色。

概念性的词汇可以暂时忽略，它们都是自带上下文，需要一定工作经验去理解的。个人理解的运维工作的核心就是：部署应用并监控其运行状态。建议围绕这个核心进行扩展学习。

可以简单的拆解为：
- 部署应用，即编译、构建、打包、分发、部署。涉及到各种主流语言或框架的编译方法、构建工具使用、各种制品输出、制品仓库的部署维护使用、部署平台的维护使用（如 Windows 、Linux 、虚拟化、云、容器、集群等）。以此推导到自带上下文的概念性词汇，如 DevOps 、CI/CD 、Pipeline 等等。
- 监控应用，核心目标是保障应用的可用性，可以按照流行的可观测性来划分，指标、日志、追踪等。还有其它的如性能分析、容量规划、运营数据支撑等等。