首页
友情链接
全景相册
随机剧照
本站声明
壁纸
Search
1
diffusers-image-outpaint,智能扩图工具,懒人包,有更新
8,939 阅读
2
AIGC数字影像馆,键盘摄影大师(一键懒人包)
4,231 阅读
3
Diffusers-Image-Community,AI扩图,新版懒人包
3,274 阅读
4
三款离线OCR对比(供下载)
3,235 阅读
5
Deepseek本地部署(内置32B和14B模型)2月21更新
3,204 阅读
摄影类
茶余饭后
软件类
登录
Search
标签搜索
AI
园博园
五一
锦绣园
大模型
甘坑
重庆
荔枝公园
开源
懒人包
台湾
相机
大梅沙
沙井
大沙河
南头古城
锦绣中华
博物馆
华强北
一个公园
傻木摄影
累计撰写
656
篇文章
累计收到
150
条评论
首页
栏目
摄影类
茶余饭后
软件类
页面
友情链接
全景相册
随机剧照
本站声明
壁纸
登录
搜索到
656
篇与
的结果
2026-05-09
关于织布的忌讳
有件衣服,穿着十分不舒适。有点像洋布,就是那种小时候农村手工织的那种。就想起小时候农村织布的事,感慨良多:好些人都不在了,好多事都在记忆里一点点淡忘。关于织布的记忆与传承关于织布,有非常非常多的忌讳。当然了,这个是对于会织布的人讲的。我们这代,已经不会了,甚至于织布的机器都不全了。织布的忌讳非常非常非常多,多到什么地步呢?你平时说的好的那些词,放在织布这个行当里面,可能都是不受欢迎的:你看着线多长啊你看着卷的好厚啊这些你觉得是夸奖的,实际全都是不好的,主人家心里可能已经骂你骂的一头狗血了。一般人家牵布会选择风和日丽的、人少的地方。例如学生上学的日子,没小孩过去,自然就少了话语。逐渐消逝的技艺我们这代已经很少很少人知道这些了。下一代?就更不知道了。小时候电话都没有,更别提照片了。
2026年05月09日
60 阅读
0 评论
0 点赞
朋友之间不应该推荐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 公司收购)。他们参加了 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 团队写道:“我们花费大量时间修复和修补漏洞……随着时间的推移,我们将过渡到更系统化构建的引擎。” 言下之意:我们不会给 llama.cpp 署名,而且我们计划与之保持距离。让事情变得更糟的那把叉子自定义后端的性能倒退2025 年年中,Ollama 兑现了这一承诺。他们不再使用 llama.cpp 作为推理后端,而是直接基于 ggml 构建了一个自定义实现。他们给出的理由是稳定性,而 Ollama 的企业合作伙伴需要的是可靠性。结果却恰恰相反。Ollama 的自定义后端重新引入了 llama.cpp 多年前已经修复的 bug。社区成员在多个版本中都发现了结构化输出支持失效、视觉模型运行失败以及 GGML 断言崩溃等问题。在上游 llama.cpp 中运行良好的模型在 Ollama 中却无法正常工作,因为 Ollama 的实现缺少对模型所需张量类型的支持。Georgi Gerganov 本人也指出,Ollama 对 GGML 进行了分支并做出了错误的修改。基准测试结果说明了一切多项社区测试表明,在相同硬件和相同型号的处理器上:运行速度:llama.cpp 的运行速度比 Ollama 快 1.8 倍(161 tokens/s vs 89 tokens/s)。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)。运行 ollama run deepseek-r1 会拉取一个 80 亿参数的 Qwen 衍生精简版,其行为与真实模型截然不同。这并非疏忽。DeepSeek 自己给这些型号起了“R1-Distill”前缀,Hugging Face 也正确地列出了它们。Ollama 却去掉了这个前缀,导致社交媒体上涌现出大量关于性能不佳的误导性讨论,这无疑损害了 DeepSeek 的声誉。GitHub 问题 #8557 和 #8698 请求将模型分离,但均被标记为重复并关闭。Ollama 知道其中的区别,但选择将其隐藏,大概是因为“DeepSeek-R1”的下载量比完整名称更高。闭源应用程序2025 年 7 月,Ollama 发布了一款适用于 macOS 和 Windows 的图形用户界面桌面应用程序。该程序在一个私有代码库中开发(github.com/ollama/app),没有提供许可证,源代码也不公开。对于一个以开源著称的项目来说,这无疑是一个令人震惊的举动。网站将下载按钮放在 GitHub 链接旁边,使用户误以为下载的是 MIT 许可的开源工具,而实际上下载的是一个未授权的闭源应用程序。正如 XDA 所说:“如果你的项目以开源为卖点,那么在发布时你就不能含糊其辞地说明哪些内容是开源的,哪些内容不是开源的。”模型文件:重新发明一个已解决的问题GGUF 的设计核心原则是单文件部署。所有聊天模板、停止令牌、模型元数据都嵌入在文件中,只需将 llama.cpp 指向它即可工作。Ollama 在此基础上添加了 Modelfile(灵感来自 Dockerfile),这反而增加了复杂性:模板匹配问题:Ollama 只能从硬编码列表中检测已知模板。如果 GGUF 嵌入了有效的 Jinja 模板但不在 Ollama 的列表内,它会回退到裸模板,破坏指令格式。用户必须手动转换语法,而 llama.cpp 直接读取即可。修改参数的噩梦:更改温度或系统提示时,用户必须执行 ollama show $\rightarrow$ 编辑 $\rightarrow$ ollama create。这个过程会复制整个模型(30 到 60 GB),仅仅是为了更改一个参数。相比之下,llama.cpp 只需命令行标志(如 --temp 0.7)。注册瓶颈与量化限制等待时间使用 llama.cpp,你可以通过一条命令直接从 Hugging Face 运行新模型。而使用 Ollama,你需要等待工作人员将模型打包、选择量化方式、转换模板并提交到注册表。这导致新模型发布后,用户往往会因为 Ollama 的环境问题(如模板错误)误以为是模型本身的问题。量化限制Ollama 仅支持特定的量化格式(Q4_K_S, Q4_K_M, Q8_0 等)。如果你需要 Q5_K_M、Q6_K 或任何 IQ 量化格式,除非自行量化,否则无法实现。对于一个标榜“最简便”的工具来说,让用户去别处寻找基本选项是极其矛盾的。云枢纽与安全性2025 年末,Ollama 推出了云托管模型。原本以本地私有推理著称的工具开始将请求路由到第三方云服务(如 MiniMax),但并未明确告知用户数据会被发送到外部服务器。安全隐患隐私担忧:对于托管在阿里云等平台上的模型,用户无法获得零数据保留保证。令牌泄露漏洞 (CVE-2025-51471):该漏洞允许恶意注册表服务器诱骗 Ollama 发送身份验证令牌。对于一款以本地隐私保护为卖点的工具,这种架构层面的设计缺陷是致命的。VC 模式:商业逻辑的必然Ollama 的行为完全遵循了典型的初创公司增长模式:在开源平台上发布,基于 llama.cpp 构建,赢得社区信任。尽量减少归因,让产品在投资者眼中显得自给自足。创建锁定、专有且不兼容的格式(如哈希文件名存储模型)。启动闭源组件(GUI 应用)和云服务(货币化途径)。这种“厂商锁定”使得用户即便导入了模型,也难以直接在其他工具中使用这些文件。可以用什么代替Ollama 包装盒内的工具可以直接使用,且设置并不难:核心引擎与命令行llama.cpp:真正的引擎。拥有兼容 OpenAI 的 API 服务器、内置 Web UI,性能始终优于 Ollama,且完全由社区驱动(MIT 许可证)。Mozilla llamafile:将模型和运行时打包成单个可执行文件,实现“下载即用”。llama-swap + LiteLLM:通过单一接口处理多模型编排、加载与热替换。桌面图形用户界面 (GUI)Jan (AGPLv3):本地优先的聊天应用,界面简洁,源代码完整且开源。koboldcpp (AGPL):llama.cpp 的分支,内置 Web UI 和丰富配置,完全开源可审计。LM Studio (闭源):虽然是闭源软件,但它提供了极佳的一键式操作和透明的参数控制,且对 llama.cpp 保持了良好的致谢精神,并非“寄生”。Msty:支持多模型并内置 RAG 功能的闭源 GUI。ramalama (Red Hat):容器原生的模型运行器,明确标注上游依赖。大局观2023 年 3 月的一个晚上,Georgi Gerganov 编写了 llama.cpp,开启了本地 AI 革命。这项工作是本地推理技术保持开放性和可访问性的基础。Ollama 将这项工作封装成一个漂亮的 CLI 并以此获得风险投资,随后却在署名、项目 fork、闭源应用和云服务等每一个关键决策点上,选择了让自己在投资者眼中显得更加“自给自足”的道路。本地 LLM 生态系统不需要 Ollama,它只需要 llama.cpp。其余部分都是打包问题,而更好的打包方案已经存在。本文转载
2026年04月24日
134 阅读
0 评论
0 点赞
2026-04-23
看工地、守仓库、做点零活
我说的是现在退休明白,你现在就是:40 岁、单身、湖北农村、有房有地、现在就不想干活了,直接躺平退休,不靠子女,就靠存款过日子。下面按从现在(40 岁)活到 85 岁,共 45 年,给你算一笔最现实、保守、不浮夸的账(农村、自建房、种菜、无房租)。一、你现在退休,每月大概要花多少钱?(农村单身)目标:安稳、不苦、不奢侈吃穿用(买菜买肉、日用品):900 / 月水电、话费、人情、零碎:300 / 月小病买药、门诊备用:300 / 月合计:1500 元 / 月(非常稳)注:你自己种菜,实际还能再省 200~300,这里按 1500 保守计算。二、社保情况(你现在 40 岁,城乡居民养老)城乡居民养老:必须 60 岁才能领钱,现在一分钱也没有。过渡期:你现在 40 岁,接下来 20 年完全靠存款生活。养老金:到 60 岁后,每月能领几百块(大概 260~520 元 / 月,取决于缴纳档次)。核心逻辑:40~60 岁,20 年纯花存款;60 岁以后有一点养老金补贴。三、现在直接退休,总共要准备多少钱?(40 岁 $\rightarrow$ 85 岁)1. 40~60 岁(20 年,无养老金)每月:1500 元20 年总计:$1500 \times 12 \times 20 = 36$ 万2. 60~85 岁(25 年,有养老金)按交中档养老(2000 元 / 年),60 岁后月领 $\approx 526$ 元每月缺口:$1500 - 526 = 974$ 元25 年总缺口:$974 \times 12 \times 25 \approx 29.2$ 万3. 大病应急金(单身农村最重要)最少预留:10 万(防大病、住院、意外)四、最终结论:你现在直接退休,需要多少钱?项目金额40~60 岁生活费36 万60~85 岁生活费缺口29.2 万大病应急金10 万合计约 75 万总结建议:在农村,单身、有房有地、40 岁现在退休,准备 70~80 万,足够安稳躺平到 85 岁。⚠️ 特别提醒: 以上未计算通胀。若算上通胀,保底要 90 万 才能退休,且仍属于低保状态。五、如果你钱没到 70 万,现实一点的方案有 50 万:可以现在半退休,找点轻松活(看工地、守仓库、做点零活),每月挣 1000 左右,完全够稳。有 30~40 万:别完全躺,做个轻松小生意或打点零工,社保交中档(2000 / 年),60 岁后压力很小。低于 30 万:不建议现在完全停,先把社保交上,再干 10 年,存到 50 万左右再退,会从容很多。可选轻体力活参考: 看工地、守仓库、做点零活
2026年04月23日
152 阅读
0 评论
0 点赞
2026-04-17
执念化成的WEBgerber查看工具
执念化成的 WEB Gerber 查看工具从学校出来,就从事 PCB 行业了。一开始在钻孔厂待了四年,之后又从业过 CAM 工程,再之后又从事过一段时间的 CAM 报价工程。虽然十多年不做与 PCB 相关的工作了,但是一直有关注。工具核心功能写的这个工具主要供报价用。导入文件后,影响报价的参数就自己计算好了:外形尺寸线路层数阻焊字符层数线宽孔径孔数测试点数此外,它还能直接输出 PDF 文件。操作与交互特性快捷键支持:提供 Q 键目视检查元素尺寸提供 W 键供高亮网络测试功能:提供简单的点对点测试智能识别:导入资料后,后台自动 OCR,可以直接搜索字符层的位号版本更新说明已更新,带 PCB 仿真功能,能大概看到 PCB 成品板样子。
2026年04月17日
85 阅读
0 评论
0 点赞
2026-04-10
关于元器件高精度是否能替代低精度的杂谈
关于元器件高精度是否能替代低精度的杂谈以前一直认为,高精度的电阻电容百分百可以直接替换低精度的。背景:机房空调的维护需求前段时间机房买了个定时遥控器。有时候机房电源会闪断(这与物业有关),有时候维护服务器有 UPS 不会停机,但是空调没接 UPS,这会导致空调直接停机。这是买定时遥控器的背景。案例分析:随机乱序执行的功能说回遥控器,这个遥控器有个优点:在批量装机时,通电后不会马上执行遥控开机动作,而是会随机乱序执行开机动作。为什么要这么做?因为空调是耗电大户。如果整个机房有一千台空调同时开机,势必造成巨大的电流冲击。通过乱序随机延时执行,可以给电源以及电线带来一定的缓冲时间。技术原理:精度与随机性的关系再说这个随机乱序延时执行的功能,其实没多高深:充电机制:例如给不同的电容充电,充满即执行开关动作。低精度的优势:这里需要选择低精度的电容(例如 $100\mu F \pm 20\%$ 的都可以)。这个误差区间非常大,为随机乱序带来的组合非常多。高精度的劣势:如果把电容换成精度非常高的(例如 $\pm 5\%$),随机组合的数量瞬间会呈指数级下降。再加上不同精度的电阻直接影响充电时间,又给这个组合增加了无限可能。真是一个神奇的方案。总结因此,任何器件在选用替代料时,一定要尊重客户的设计。如果你不懂,一定要问客户。
2026年04月10日
119 阅读
0 评论
1 点赞
2026-04-03
软件设计哲学
程序员的工作不是编程,而是通过抽象,来管理软件的复杂性。如果你做到了这一点,那么编程就很容易了。我们一直以来都用错了软件开发方法。当试图改进糟糕的代码库时,我们常常想到一些通用且技术性的解决方案:将前端迁移到 React,将后端拆分成微服务,或者用 Rust 重写所有代码。在某些情况下,这些方法确实能带来一些好处,但它们都无法从根本上解决糟糕代码库的问题。摘自约翰·奥斯特豪特的《软件设计哲学》:编写软件的最大限制在于我们理解所创建系统的能力。糟糕代码库的核心问题在于它们变得过于复杂,难以理解。Rust 或 React 都无法解决这个问题。那么,什么方法可以呢?让事情变得更简单解决方案在于抽象。 抽象是指隐藏不重要细节、突出重要细节的概念。请注意,这里指的是概念,而不是表达这些概念的代码。这些概念是对实际复杂性的简化模型,因此能帮助你更轻松地理解正在使用的系统。你可以进行概括性思考,只在必要时才深入探究底层细节。记住:抽象是思想,所以好的抽象应该改变你对部分代码库的思考方式。如果你引入了一个抽象,但它并没有改变你的思考方式,那么你创造的就不是抽象,而是一层间接层。设计1. 如何寻找抽象?抽象究竟该如何设计?有时候,好的抽象概念会非常明显地出现在你的脑海中。它们是你业务中已经存在的概念,只需要稍加梳理,并用代码恰当地表达出来。例如:发票、产品、客户或订阅。但请注意,当你的业务谈到客户时,他们指的不是英语词典中“客户”的定义,而是他们自己的客户,这些客户有特定的规则和结构化的互动方式。这本身就是一种抽象!你只需要用代码表达出所有这些概念,就像你的业务用语言表达它们一样。2. 创造性抽象有些抽象概念可能比较难找,需要你发挥创造力。这类工作没有万能的灵丹妙药;你只需要找到复杂性,然后尝试各种方法来应对。通常这类工作甚至不需要编写代码,把想法写下来就足以评估你提出的抽象概念是否有效。这听起来可能有点难,但做得越多就越容易。我之前提到的抽象概念中存在一种模式:它们都是数据类型。如果你在寻找抽象概念,你会发现数据中蕴含着大量的抽象概念。数据绝不仅仅是数据。数据几乎总是有其修改规则,而这些规则往往隐藏在某种概念之中,即便它们原本并不隐藏。3. 重新设计有时,找到一个好的抽象概念很困难,因为代码中已经存在很多抽象概念,但它们不再适用。桑迪·梅茨 (Sandi Metz) 在《错误的抽象》(The Wrong Abstraction) 一文中提到了一种很好的技巧来解决这个问题:移除一个你认为不再适用的抽象概念,然后重新引入重复的部分。 如果你能发现重复的部分,找到好的抽象概念就比在糟糕的抽象代码库中寻找好的抽象概念要容易得多。值得注意的是,你不应该因为害怕出错而不敢设计抽象概念。你肯定会出错!设计抽象概念是一项创造性的工作,而创造性的工作需要反复试验。与其害怕出错,不如大胆地设计抽象概念,并做好准备,一旦它们弊大于利,就及时进行重构。正如编辑是写作的重要组成部分一样,重构也是软件开发的重要组成部分,而随着时间的推移,最需要重构的往往是你使用的抽象概念。编程你的工作不是编程,而是通过设计、改进和重新设计抽象概念来管理复杂性。如果你做到了这一点,那么编程就很容易了。如果你不这样做:随着时间的推移,你的代码库会变得越来越难以维护。你将无法有效地指导新开发人员。简单的功能会变得复杂。复杂的功能最终将变得不可能实现。但事情并非一定要如此,如果你已经深陷其中,那么还有出路:找出应用程序中的复杂性,弄清楚哪些重要哪些不重要,将所有内容提炼成一个概念,然后重复这个过程。你可以一次构建一个抽象层,逐步摆脱困境。本文转载
2026年04月03日
116 阅读
0 评论
0 点赞
2026-03-29_梅拉尼亚小镇
2026年04月01日
103 阅读
0 评论
0 点赞
2026-04-01
2026-03-29_梅拉尼亚小镇
2026-03-31
今天又遇到一个头疼医脚的
今天又遇到一个头疼医脚顾头不顾腚的现状:高度自定义带来的“双刃剑”效应我们用勤哲,具有高度自定义功能,好,也不好。好的地方:全可自定义。不好的地方:全可以自定义。这就导致一个问题:修修补补,补丁超多。想到什么补什么,根本不管是不是符合流程。再加上人多了,全都想偷懒。思考:关于“偷懒”的边界偷懒是好事,我也喜欢偷懒,我也鼓励偷懒。偷懒发明了电梯,但是你不能因为早晚高峰电梯难等,你从8楼跳窗下楼;偷懒发明了汽车,但是你不能横冲直撞,不能违反交规;偷懒也造成了黄河变悬河!!!!!!!!!!!!!!!!只要你还在三界内,还在五行中,有些规矩你必须遵守。问题:网状交叉的逻辑泥潭T类工艺单关联的表单至少有40张以上。任何表单有问题,你只顾改有问题的那张,那么所有与之关联的,全都要引用你改的这张表。这导致了严重的后果:数据混乱:久而久之形成大量循环引用、隐性依赖、脏数据。逻辑复杂:关联关系网状交叉。排查困难:后期想排查一个数据错误,需要逐张表单检查逻辑,根本不知道哪张是对的。成本激增:修改成本指数级上升。方案:回归 ERP 的核心本质ERP 的核心是数据同源、流程贯通。 你这种改法根本不具备可维护性。正确的做法:如果你更改源头表单(T类工艺单),那么所有表单只引用这一张工艺单即可。这样做的好处:口径一致:既能保证全系统数据口径一致,又能将维护点集中在一处。根治依赖:从根源上避免循环依赖与逻辑混乱。提升稳定性:大幅提升 ERP 系统的稳定性、可扩展性与长期可维护性。实现价值:真正实现源头统一、流程贯通的 ERP 管理价值。
2026年03月31日
80 阅读
0 评论
0 点赞
1
...
5
6
7
...
82
网站版权本人所有,你要有本事,盗版不究。 sam@gpcb.net