搜索到
642
篇与
傻木
的结果
-
婺源・弦高城・弦高古城夜市 婺源・弦高城・西湖凼街区（也常称 弦高古城夜市） 五一去了江西 这个景点并不在计划内 但是这个景点比其他景点显然更有看头 丝毫不比凤凰古城差 某些情况下,还远比凤凰古城好的多 本来不想写的 今天去了华强北 对华强北感慨非常 只要有一家卖充电宝的挣钱了 边上有十家店铺的话,立马这十家店铺全都上充电宝 自己把自己卷死了 全都跟着一起玩完 再说婺源 这个字读wu,雾 婺源古城,是婺源古时候的中心区 非常有特色的古城区 不收门票 十分热闹 几乎每家店都不重样 这个在中国十分罕见 个个古城,几乎都是什么挣钱来什么 但是在这里,每一家都不一样 当然了,我没有全部逛完 也没有真的去统计是不是全部都没有重复的 只是我目之所及 这就够了 逛华强北,逛两家店面,就等于把华强北千百家店铺逛完了 这就是华强北现在没落的原因 婺源・弦高城・弦高古城夜市 位置：婺源县城（紫阳镇）老城核心区 核心夜市街巷：先儒街、油灯街、北门街 一带 特色：徽派古街、免费、鱼灯巡游、小吃、非遗、灯光夜景 别称：当地人 / 游客也叫 弦高古城夜市、婺源古城夜市、西湖凼夜市 十分推荐!!!!  -
2026五一江西 这次江西没拍到什么满意的片子 本不想发的 还是水一贴以作留念 除最后一张是相机拍的 其他都是手机拍摄            
-
关于织布的忌讳 有件衣服,穿着十分不舒适 有点像洋布 就是那种小时候农村手工织的那种 就想起小时候农村织布的事 感慨良多 好些人都不在了 好多事都在记忆里一点点淡忘 关于织布,有非常非常多的忌讳 当然了,这个是对于会织布的人讲的 我们这代,已经不会了 甚至于织布的机器都不全了 织布的忌讳非常非常非常多 多到什么地步呢? 你平时说的好的那些词,放在织布这个行当里面 可能都是不受欢迎的 你看着线多长啊 你看着卷的好厚啊 这些你觉得是夸奖的 实际全都是不好的 主人家心里可能已经骂你骂的一头狗血了 一般人家牵布会选择风和日丽的,人少的地方 例如学生上学的日子 没小孩过去 自然就少了话语 我们这代已经很少很少人知道这些了 下一代? 就更不知道了 小时候电话都没有,更别提照片了 放上一张网图 
-
朋友之间不应该推荐Ollama Ollama 最初凭借其作为首个简易的 llama.cpp 封装库而获得成功，随后却花了数年时间规避署名、误导用户，并转向云端，而这一切都建立在利用他人引擎赚取的风险投资之上。 以下是完整的历史，以及为什么其他替代方案更胜一筹。 Ollama 是运行本地 LLM 最流行的工具，但它不应该如此。 它之所以能占据这个位置，是因为它开创了先河，成为第一个让llama.cpp不想编译 C++ 或编写服务器配置的用户也能轻松使用 LLM 的工具。 这在当时确实是一项贡献。但此后，该项目多年来一直在系统性地掩盖其技术来源，误导用户对其运行的程序存在误解，并逐渐偏离了最初赢得用户信任的“本地优先”理念。 与此同时，它还在接受风险投资。 这不是一篇“正反两方都适用”的文章。我曾经用过Ollama，现在已经不用了。以下是你也应该不用的原因。 一个带有失忆症的 llama.cpp 包装器 Ollama 的所有推理能力都源自llama.cpp，这是一个由 Georgi Gerganov 于 2023 年 3 月创建的 C++ 推理引擎。 Gerganov 的项目使得在消费级笔记本电脑上运行 LLaMA 模型成为可能。他仅用一个晚上就完成了第一个版本，并由此开启了整个本地 LLM 运动。 如今，llama.cpp 在 GitHub 上拥有超过 10 万颗星，450 多位贡献者，并且是几乎所有基于 GGUF 的工具所依赖的基础。 Ollama 由 Jeffrey Morgan 和 Michael Chiang 于 2021 年创立，他们此前都曾参与开发Kitematic，这是一款 Docker 图形用户界面工具，后被 Docker 公司收购。 他们参加了 Y Combinator 2021 年冬季创业营，获得了种子轮融资，并于 2023 年正式上线。从一开始，他们的理念就是“面向机器学习模型的 Docker”，一个便捷的封装工具， 只需一条命令即可下载并运行模型。其底层代码是 llama.cpp，它负责完成所有工作。 一年多以来，Ollama 的 README 文件中完全没有提及 llama.cpp。README文件中没有，网站上也没有，他们的宣传材料中也没有。 该项目的二进制发行版也没有包含其所分发的 llama.cpp 代码所需的 MIT 许可声明。这并非开源礼仪的问题，MIT 许可只有一个主要要求： 包含版权声明。Ollama 没有做到这一点。 社区注意到了这个问题。GitHub上的 #3185 号 issue于 2024 年初提交，要求解决许可合规性问题。 但维护者 400 多天都没有回应。2024年 4 月， #3697 号 issue提交，专门要求对 llama.cpp 进行致谢，几个小时后，社区 PR #3700便随之而来。 Ollama 的联合创始人 Michael Chiang 最终在 README 文件末尾添加了一行文字：“llama.cpp 项目由 Georgi Gerganov 创建。” 对公关稿的回应颇具启发性。Ollama 团队写道：“我们花费大量时间修复和修补漏洞，以确保 Ollama 用户获得流畅的使用体验……随着时间的推移，我们将过渡到更系统化构建的引擎。” 言下之意：我们不会给 llama.cpp 署名，而且我们计划与之保持距离。 正如一位Hacker News 评论者所说：“我一直对他们的做法感到困惑，这简直是自找麻烦。基于 Llama 进行开发完全合理，而且他们也确实提升了易用性。 只是应该给予 Llama 团队应有的认可。”另一位评论者则表示：“Ollama 一直淡化他们对 llama.cpp 的依赖，这在本地 LLM 社区早已是公开的秘密。” 让事情变得更糟的那把叉子 2025 年年中，Ollama 兑现了这一承诺。他们不再使用 llama.cpp 作为推理后端，而是直接基于ggml（llama.cpp 本身使用的底层张量库）构建了一个自定义实现。 他们给出的理由是稳定性，llama.cpp 更新频繁，容易出现问题，而 Ollama 的企业合作伙伴需要的是可靠性。 结果却恰恰相反。Ollama 的自定义后端重新引入了 llama.cpp 多年前已经修复的 bug。社区成员在多个版本中都发现了结构化输出支持失效、视觉模型运行失败以及 GGML 断言崩溃等问题。 在上游 llama.cpp 中运行良好的模型在 Ollama 中却无法正常工作，包括像 GPT-OSS 20B 这样的新版本，因为 Ollama 的实现缺少对模型所需张量类型的支持。 Georgi Gerganov 本人也指出，Ollama 对 GGML 进行了分支并做出了错误的修改。 真是莫大的讽刺。多年来，他们一直淡化对 llama.cpp 的依赖，结果最终尝试独立开发时，却做出了一个不如原作者的版本，而他们之前却拒绝承认这一点。 基准测试结果说明了一切。多项社区测试表明，在相同硬件和相同型号的处理器上， llama.cpp 的运行速度比 Ollama 快 1.8 倍，每秒处理 161 个令牌，而 Ollama 仅为 89 个。 在 CPU 端，两者的差距高达30% 至 50%。最近在 Qwen-3 Coder 32B 上进行的对比测试显示，llama.cpp 的吞吐量比 Ollama 高出约 70%。 性能上的不足源于 Ollama 的守护进程层、糟糕的 GPU 卸载启发式算法以及落后于上游的第三方后端。 误导性的模型命名 DeepSeek 于 2025 年 1 月发布了 R1 模型系列，而 Ollama 在其库和命令行界面中仅将其列为“DeepSeek-R1”，即较小的精简版本， 例如 DeepSeek-R1-Distill-Qwen-32B，这些模型是对 Qwen 和 Llama 模型进行微调后的结果，并非真正的 6710 亿参数 R1 模型。 运行该ollama run deepseek-r1模型会拉取一个 80 亿参数的 Qwen 衍生精简版，其行为与真实模型截然不同。 这并非疏忽。DeepSeek 自己给这些型号起了“R1-Distill”前缀。Hugging Face 也正确地列出了它们。Ollama 却去掉了这个前缀。 结果导致社交媒体上涌现出大量帖子，声称他们在消费级硬件上运行了“DeepSeek-R1”，随后人们又困惑于它为何性能不佳，这无疑损害了 DeepSeek 的声誉。 GitHub 问题#8557和#8698请求将模型分离。这两个问题均被标记为重复问题并关闭，且未进行任何修复。截至目前，它ollama run deepseek-r1仍然启动一个精简版的模型。 Ollama 知道其中的区别，但选择将其隐藏，大概是因为“DeepSeek-R1”的下载量比“DeepSeek-R1-Distill-Qwen-32B”更高。 闭源应用程序 2025年7月，Ollama发布了一款适用于macOS和Windows的图形用户界面桌面应用程序。该应用程序在一个私有代码库中开发github.com/ollama/app，没有提供许可证，源代码也不公开。 对于一个以开源著称的项目来说，这无疑是一个令人震惊的举动。 社区成员立即提出了担忧。许可证问题获得了 40 个赞。开发者在二进制文件中发现了潜在的 AGPL-3.0 依赖项。 网站将下载按钮放在 GitHub 链接旁边，使用户误以为下载的是 MIT 许可的开源工具，而实际上下载的是一个未授权的闭源应用程序。 维护者几个月来一直保持沉默。代码最终于 2025 年 11 月合并到主代码库中，但最初的发布暴露了该项目的真实意图。 正如XDA 所说：“如果你的项目以开源为卖点，那么在发布时你就不能含糊其辞地说明哪些内容是开源的，哪些内容不是开源的。” 模型文件：重新发明一个已解决的问题 GGUF 是由 Georgi Gerganov 创建的模型格式，其设计核心原则是：单文件部署。GGUF 规范的第一条写道：“完整信息： 加载模型所需的所有信息都包含在模型文件中，用户无需提供任何额外信息。”聊天模板、停止令牌、模型元数据，所有这些都嵌入在文件中。 只需将 llama.cpp 指向一个 GGUF 文件，即可正常工作。 Ollama 在此基础上添加了 Modelfile。这是一个独立的配置文件，其灵感显然来自 Dockerfile，它指定了基础模型、聊天模板、系统提示符、采样参数和停止令牌。 这些信息大部分已经存在于 GGUF 文件中。正如一位 Hacker News 评论者所说：“我们好不容易摆脱了多文件混乱的局面，结果 Ollama 又把它加了回来。” 这种方法的弊端会迅速累积。Ollama 只能从硬编码的列表中自动检测已知的聊天模板{{ .Prompt }}。 如果一个 GGUF 文件的元数据中嵌入了一个有效的 Jinja 聊天模板，但它与 Ollama 已知的模板都不匹配，Ollama 就会回退到使用一个裸模板，从而悄无声息地破坏模型的指令格式。 用户必须手动从 GGUF 文件中提取聊天模板，将其转换为 Go 模板语法（与 Jinja 不同），然后写入模型文件。而 llama.cpp 却直接读取嵌入的模板并使用它。 修改参数更糟糕。如果你想更改从 Ollama 注册表中提取的模型的温度或系统提示，工作流程是： 导出模型文件ollama show --modelfile，编辑它，然后运行命令ollama create创建新的模型条目。用户报告称，这个过程会复制整个模型（30 到 60 GB），而仅仅是为了更改一个参数。 正如一位用户所描述的：“‘模型文件’工作流程简直是噩梦。这简直是胡闹，我讨厌它。有些模型有 30 到 60 GB，为了更改一个参数就复制整个模型，这简直愚蠢至极。” 相比之下，llama.cpp 中的参数是命令行标志。想要不同的温度？传递参数即可--temp 0.7。想要不同的系统提示符？在 API 请求中传递。 无需创建文件，无需复制 GB 的数据，也无需学习任何专有格式。 模型文件还将用户限制在 Ollama 的 Go 模板语法中，这与模型创建者实际发布的 Jinja 模板语言不同。LM Studio 直接接受 Jinja 模板。 llama.cpp 从 GGUF 读取这些模板。只有 Ollama 要求用户在模板语言之间进行转换，而且转换错误率很高， 以至于GitHub 上有很多 issue专门讨论 Ollama 库和上游 GGUF 元数据之间模板不匹配的问题。 注册瓶颈 当有新模型发布时，例如新的 Qwen、Gemma 或 DeepSeek 变种，GGUF 通常会在几小时内出现在 Hugging Face 上，并由 Unsloth 或 Bartowski 等社区成员进行量化。 使用 llama.cpp，您可以立即运行它们：只需llama-server -hf unsloth/Qwen3.5-35B-A3B-GGUF:Q4_K_M一条命令，即可直接从 Hugging Face 运行，无需任何中间环节。 使用 Ollama 时，你需要等待。Ollama 的某位工作人员需要将模型打包到他们的注册表中， 选择要提供的量化方式（通常只提供 Q4_K_M 和 Q8_0，不提供 Q5、Q6 或 IQ 量化），将聊天模板转换为 Go 格式，然后提交。 在此之前，除非你自己手动修改模型文件，否则该模型在 Ollama 的系统中并不存在。 这在 r/LocalLLaMA 上形成了一种反复出现的模式：新模型发布后，人们通过 Ollama 进行测试，结果发现模型存在问题、运行缓慢或聊天模板错误， 而问题却被归咎于模型本身，而不是运行时环境。最近一篇题为“如果你想测试新模型， 请使用 llama.cpp/transformers/vLLM/SGLang”的公告记录了 Qwen 模型在工具调用和响应错误方面出现的问题， 这些问题“只会在使用 Ollama 时出现”，原因是其后端依赖了第三方库，并且模板处理存在缺陷。正如一位评论者所说：“朋友之间不会互相推荐使用 Ollama。” 量化方面的限制尤其令人沮丧。Ollama仅支持创建 Q4_K_S、Q4_K_M、Q8_0、F16 和 F32 量化格式。 如果您需要 Q5_K_M、Q6_K 或任何其他 IQ 量化格式（llama.cpp 多年来一直支持这些格式），除非您在 Ollama 之外自行进行量化，否则将无法实现。 当用户询问 Q2_K 支持时，得到的回复实际上是“使用其他工具”。 对于一个标榜自己是运行模型最简便的工具的项目来说，让用户去别处寻找基本的量化选项，这本身就说明了一些问题。 Hugging Face 最终通过动态生成 Docker 风格的清单文件来支持此功能ollama run hf.co/{repo}:{quant}，这在一定程度上解决了可用性问题。 但即便如此，该文件仍会被复制到 Ollama 的哈希 blob 存储中，你仍然无法与其他工具共享 GGUF，模板检测问题依然存在。 其基本架构依然不变：Ollama 将自身置于你和你的模型之间，而这个中间人比它所依赖的工具速度更慢、功能更弱、兼容性更差。 云枢纽 2025 年末，Ollama 在本地模型库之外推出了云托管模型。这款原本以本地私有推理著称的工具开始将请求路由到第三方云服务提供商。 诸如 MiniMax 之类的专有模型出现在模型列表中，但并未明确告知用户选择这些模型会将数据发送到外部服务器。 用户对数据路由提出了担忧。当通过“Ollama Cloud”运行像MiniMax-m2.7这样的闭源模型时，用户的提示信息可能会被转发给实际托管该模型的外部服务提供商。 Ollama官方文档称“我们会处理您的提示和响应以提供服务，但不会存储或记录这些内容”，但并未说明第三方服务提供商如何处理这些信息。 对于托管在阿里云上的模型，用户指出，阿里云并不提供零数据保留保证。 CVE-2025-51471漏洞加剧了这一问题，该漏洞是一个令牌泄露漏洞，影响所有 Ollama 版本。 恶意注册表服务器可以诱骗 Ollama 在正常拉取模型期间将其身份验证令牌发送到攻击者控制的端点。 该漏洞的修复程序已以 PR 的形式提交，但耗时数月才最终合并。对于一款以本地隐私保护著称的工具而言，一个会将凭据泄露给任意服务器的漏洞绝非小事，而是一个架构理念上的问题。 VC模式 当你了解其激励机制时，这一切就更容易理解了。 Ollama 是一家由 Y Combinator 投资的初创公司（W21），由一群工程师创立，他们之前开发了一个 Docker 图形用户界面，后来被 Docker 公司收购。 他们的模式很常见：将现有的开源项目封装成一个用户友好的界面，建立用户群，筹集资金，然后找到盈利模式。 这一过程完全遵循了这一模式： 在开源平台上发布，基于 llama.cpp 构建，赢得社区信任 尽量减少归因，让产品在投资者眼中显得自给自足。 创建锁定、专有模型注册表格式、与其他工具不兼容的哈希文件名 启动闭源组件，即 GUI 应用程序 添加云服务，即货币化途径 模型注册表值得研究。Ollama 使用其特有的格式，以哈希文件名存储下载的模型。 如果您已经通过 Ollama 导入模型数月，那么如果不进行额外操作，就无法直接在 llama.cpp 或 LM Studio 中使用这些文件。 您可以通过 Modelfile 将自己的 GGUF 文件导入 Ollama，但移除这些文件的过程却异常繁琐。这是一种厂商锁定，大多数用户只有在尝试移除时才会注意到。 可以用什么代替 Ollama 包装盒内的工具可以直接使用，而且设置起来也并不难。 llama.cpp是引擎。它拥有一个兼容 OpenAI 的 API 服务器（llama-server），内置 Web 用户界面， 可以完全控制上下文窗口和采样参数，并且吞吐量始终优于 Ollama。2026 年 2 月，Gerganov 的 ggml.ai加入 Hugging Face，以确保项目的长期可持续发展。 该项目真正由社区驱动，采用 MIT 许可证，目前正处于积极开发阶段，拥有 450 多位贡献者。 Mozilla 的llamafile将单文件理念更进一步，它将模型和运行时打包成一个可执行文件，无需安装即可在六种操作系统上运行。下载、双击，即可完成。 llama-swap通过单一 API 接口，按需处理多模型编排、加载、卸载和热替换。 将其与LiteLLM结合使用，即可获得一个统一的、兼容 OpenAI 的代理，该代理能够跨多个后端进行路由，并支持正确的模型别名。 如果你需要桌面图形用户界面，那么你确实有真正的开源选择。Jan （AGPLv3）是一款本地优先的聊天应用，界面简洁，源代码完整。 koboldcpp （AGPL）是llama.cpp的一个分支，内置Web用户界面和丰富的配置选项，完全开源且可审计。 两者都是真正的自由开源软件项目，而不是将专有代码隐藏在开源引擎背后的封装程序。 此外，还有一些闭源封装软件。LM Studio是一款基于 llama.cpp 构建的专有软件，它之所以成为 Ollama 最受欢迎的替代方案，原因显而易见： 它提供了同样便捷的一键式操作，并拥有完善的图形用户界面 (GUI)，支持所有 GGUF 格式，且所有参数都公开透明。 至关重要的是，LM Studio 的开发者对整个生态系统秉持着良好的合作精神。他们维护了一个完善的致谢页面，注明了 llama.cpp 及其许可证， 并且没有试图掩盖其底层代码。虽然它是闭源产品，但它并非寄生于其他生态系统。Msty是另一个基于开源推理的闭源 GUI，它支持多模型并内置了 RAG（红绿灯）功能。 我并不反对有人通过让开源软件（FOSS）更便捷来建立自己的商业模式。这无可厚非。但我们必须坦诚地指出这些工具的本质： 它们是基于 llama.cpp 而存在的商业产品，而非 Ollama 的开源替代品。善意封装和恶意封装的区别不在于它们是否收费或发布专有代码， 而在于它们是否尊重自己所依赖的成果。LM Studio 做到了这一点，而 Ollama 则没有。 Red Hat 的ramalama也值得一看，它是一个容器原生模型运行器，会明确地将上游依赖项放在最显眼的位置。这正是 Ollama 从一开始就应该做的。 这些工具的设置都只需要几分钟。认为 Ollama 是唯一无障碍选择的观点早已过时。 大局观 2023年3月的一个晚上，Georgi Gerganov 匆匆编写了 llama.cpp，由此开启了本地人工智能领域的革命。 他和数百名贡献者组成的社区多年来致力于让在消费级硬件上运行功能日益强大的模型。这项工作意义非凡，它是本地推理技术保持开放性和可访问性的基础。 Ollama 将这项工作封装成一个漂亮的命令行界面 (CLI)，并以此获得了风险投资，之后却拒绝署名一年多，还糟糕地 fork 了项目，同时发布了一个闭源应用， 最后又将整个项目转向了云服务。在每一个本可以成为优秀开源公民的决策点上，他们都选择了让自己在投资者眼中显得更加自给自足的道路。 本地LLM生态系统不需要Ollama，它只需要llama.cpp。其余部分都是打包问题，而更好的打包方案已经存在。 [本文转载][1] [1]: https://sleepingrobots.com/dreams/stop-using-ollama/
-
看工地、守仓库、做点零活 我说的是现在退休  明白，你现在就是：40 岁、单身、湖北农村、有房有地、现在就不想干活了，直接躺平退休，不靠子女，就靠存款过日子。 下面按从现在（40 岁）活到 85 岁，共 45 年，给你算一笔最现实、保守、不浮夸的账（农村、自建房、种菜、无房租）。 一、你现在退休，每月大概要花多少钱？（农村单身） 安稳、不苦、不奢侈： 吃穿用（买菜买肉、日用品）：900 / 月 水电、话费、人情、零碎：300 / 月 小病买药、门诊备用：300 / 月 合计：1500 元 / 月（非常稳） 你自己种菜，实际还能再省 200～300，我按1500 保守算。 二、社保情况（你现在 40 岁，城乡居民养老） 城乡居民养老：必须 60 岁才能领钱，现在一分钱没有人社通 你现在 40 岁，接下来 20 年完全靠存款生活 到 60 岁后，每月能领几百块（前面算过，大概 260～520 元 / 月，看你交哪个档） 一句话：40～60 岁，20 年纯花存款；60 岁以后有一点养老金补贴。 三、现在直接退休，总共要准备多少钱？（40 岁→85 岁） 1）40～60 岁（20 年，无养老金） 每月：1500 20 年：1500 × 12 × 20 = 36 万 2）60～85 岁（25 年，有养老金） 按你交中档养老（2000 元 / 年），60 岁后月领≈526 元 缺口：1500 − 526 = 974 元 / 月 25 年缺口：974 × 12 × 25 ≈ 29.2 万 3）再留一笔大病应急金（单身农村最重要） 最少：10 万（防大病、住院、意外） 四、最终结论：你现在直接退休，需要多少钱？ 40～60 岁生活费：36 万 60～85 岁生活费缺口：29.2 万 大病应急金：10 万 合计：约 75 万 给你一个好记的数： 在农村，单身、有房有地、40 岁现在退休，准备 70～80 万，足够安稳躺平到 85 岁。 五、如果你钱没到 70 万，现实一点的方案 有 50 万：可以现在半退休，找点轻松活（看工地、守仓库、做点零活），每月挣 1000 左右，完全够稳。 有 30～40 万：别完全躺，做个轻松小生意或打点零工，社保交中档（2000 / 年），60 岁后压力很小。 低于 30 万：不建议现在完全停，先把社保交上，再干 10 年，存到 50 万左右再退，会从容很多。 这还没算通胀,算上通胀,保底要90万才能退休,还是低保状态的 看工地、守仓库、做点零活
-
执念化成的WEBgerber查看工具 执念化成的WEB gerber查看工具 从学校出来,就从事PCB行业了 一开始在钻孔厂待了四年 之后又从业过CAM工程 再之后又从事过一段时间的CAM报价工程 虽然十多年不做与PCB相关的工作了 但是一直有关注     写的这个工具主要供报价用 导入文件后,影响报价的参数就自己计算好了 外形尺寸 线路层数 阻焊字符层数 线宽 孔径 孔数 测试点数 还能直接输出pdf文件 提供q键目视检查元素尺寸 提供w键供高亮网络 提供简单的点对点测试 导入资料后,后台自动OCR 可以直接搜索字符层的位号   已更新,带PCB仿真功能,能大概看到PCB成品板样子
-
关于元器件高精度是否能替代低精度的杂谈 关于元器件高精度是否能替代低精度的杂谈  以前一直认为,高精度的电阻电容百分百可以直接替换低精度的 前段时间机房买了个定时遥控器 有时候机房电源会闪断,这个与物业有关,有时候维护 服务器有UPS,不会停机,但是空调没接UPS 这会导致空调直接停机 这个是买定时遥控的背景 说回遥控器 这个遥控器有个优点,说是批量装机时 通电后,不会马上执行遥控开机动作 会随机乱序执行开机动作 为什么这么做? 因为空调是耗电大户,整个机房如果有一千台空调,同时开机,势必造成巨大的电流冲击 乱序随机延时执行,给电源以及电线带来一定的缓冲时间 再说这个随机乱序延时执行的功能 其实没多高深 例如给不同的电容充电,充满即执行开关动作 这里就需要选择低精度的电容,例如100uf 正负20%的都可以 这个区间非常大,给随机乱序带来的组合非常多 如果给这个电容换成精度非常高的,例如5%的 随机组合数量瞬间指数级下降 再加上不同精度的电阻,直接影响充电时间 又给这个组合增加无限可能 真是一个神奇的方案 因此,任何器件,在选用替代料时,一定要尊重客户的设计,如果你不懂 一定要问客户
-
软件设计哲学 程序员的工作不是编程，而是通过抽象，来管理软件的复杂性。 如果你做到了这一点，那么编程就很容易了。  我们一直以来都用错了软件开发方法。当试图改进糟糕的代码库时，我们常常想到一些通用且技术性的解决方案： 将前端迁移到 React，将后端拆分成微服务，或者用 Rust 重写所有代码。在某些情况下，这些方法确实能带来一些好处，但它们都无法从根本上解决糟糕代码库的问题。 摘自约翰·奥斯特豪特的《软件设计哲学》： 编写软件的最大限制在于我们理解所创建系统的能力。 糟糕代码库的核心问题在于它们变得过于复杂，难以理解。Rust 或 React 都无法解决这个问题。那么，什么方法可以呢？ 让事情变得更简单 解决方案在于抽象。抽象是指隐藏不重要细节、突出重要细节的概念。请注意，这里指的是概念，而不是表达这些概念的代码。 这些概念是对实际复杂性的简化模型，因此能帮助你更轻松地理解正在使用的系统。你可以进行概括性思考，只在必要时才深入探究底层细节。 记住：抽象是思想，所以好的抽象应该改变你对部分代码库的思考方式。 如果你引入了一个抽象，但它并没有改变你的思考方式，那么你创造的就不是抽象，而是一层间接层。 设计 抽象究竟该如何设计？ 有时候，好的抽象概念会非常明显地出现在你的脑海中。它们是你业务中已经存在的概念，只需要稍加梳理，并用代码恰当地表达出来。 例如，发票、产品、客户或订阅。但请注意，当你的业务谈到客户时，他们指的不是英语词典中“客户”的定义，而是他们自己的客户，这些客户有特定的规则和结构化的互动方式。 这本身就是一种抽象！你只需要用代码表达出所有这些概念，就像你的业务用语言表达它们一样。 有些抽象概念可能比较难找，需要你发挥创造力。这类工作没有万能的灵丹妙药；你只需要找到复杂性，然后尝试各种方法来应对。 通常这类工作甚至不需要编写代码，把想法写下来就足以评估你提出的抽象概念是否有效。这听起来可能有点难，但做得越多就越容易。 我之前提到的抽象概念中存在一种模式。它们都是数据类型。如果你在寻找抽象概念，你会发现数据中蕴含着大量的抽象概念。这应该不难理解！ 数据绝不仅仅是数据。数据几乎总是有其修改规则，而这些规则往往隐藏在某种概念之中，即便它们原本并不隐藏。 重新设计 有时，找到一个好的抽象概念很困难，因为代码中已经存在很多抽象概念，但它们不再适用。 桑迪·梅茨 (Sandi Metz) 在《错误的抽象》(The Wrong Abstraction) 一文中提到了一种很好的技巧来解决这个问题： 移除一个你认为不再适用的抽象概念，然后重新引入重复的部分。如果你能发现重复的部分，找到好的抽象概念就比在糟糕的抽象代码库中寻找好的抽象概念要容易得多。 值得注意的是，你不应该因为害怕出错而不敢设计抽象概念。你肯定会出错！设计抽象概念是一项创造性的工作，而创造性的工作需要反复试验。 与其害怕出错，不如大胆地设计抽象概念，并做好准备，一旦它们弊大于利，就及时进行重构。 正如编辑是写作的重要组成部分一样，重构也是软件开发的重要组成部分，而随着时间的推移，最需要重构的往往是你使用的抽象概念。 编程 你的工作不是编程，而是通过设计、改进和重新设计抽象概念来管理复杂性。如果你做到了这一点，那么编程就很容易了。 如果你不这样做，随着时间的推移，你的代码库会变得越来越难以维护。 你将无法有效地指导新开发人员。 简单的功能会变得复杂。 复杂的功能最终将变得不可能实现。 但事情并非一定要如此，如果你已经深陷其中，那么还有出路： 找出应用程序中的复杂性，弄清楚哪些重要哪些不重要，将所有内容提炼成一个概念，然后重复这个过程。你可以一次构建一个抽象层，逐步摆脱困境。 [本文转载][1] [1]: https://codeandcake.dev/posts/2025-12-12-your-job-isnt-programming
网站版权本人所有，你要有本事，盗版不究。 sam@gpcb.net