搜索到
152
篇与
软件类
的结果
-
批量扫描照片Exif元数据 · 写回标准 Exif 标签 本项目依赖exiftool,程序已打包这个插件 本工具使用exiftool深度扫描exif被破坏的图片,将exif信息还原到标准 EXIF 段  那么多开源js库,为什么选择exiftool插件? JS 库（exif-js /piexifjs/sharp /exifr）都不能 “匹敌 exiftool”， 也都做不到 exiftool 那种级别的 “还原 PS 丢失的 EXIF”。 相机名称、镜头名称、拍摄参数，只要这些字段还在文件里没被真正删掉，这几个库都能读； 但 PS 重写 / 清空 / 改写过的深层元数据（特别是 MakerNote、厂商私有标签、XMP 历史、Photoshop IRB 等）， JS 库基本读不到，更不可能 “还原”。 exiftool 强在哪（为什么能 “还原”） exiftool 是 Perl 写的全能元数据引擎，特点： 支持：EXIF + XMP + IPTC + Photoshop IRB + MakerNote（几十家相机厂商私有数据）+ ICC + JFIF … 能读：正常 EXIF + 被删但残留在文件里的元数据块 + PS 留下的隐藏段 + 厂商私有注释（MakerNote） 所谓 “还原”： PS “存储为” 时，会扔掉 MakerNote、很多私有标签、XMP 历史 但有时文件里还有旧数据残片，exiftool 能扫全文件、把这些碎片捞出来 JS 库只解析标准 EXIF 段（APP1），根本不读 MakerNote、IRB、深层 XMP 一句话：exiftool 是在 “整个文件里挖元数据”，JS 库只是 “读标准 EXIF 表头”。 没有一个 JS 库能匹敌 exiftool，尤其是在 PS 处理过的照片上。 https://abpyu.lanzoul.com/itvzA3q9kznc 密码:2sqo -
摄影老司机_给照片加边框 摄影老司机_给照片加边框工具 **如果打不开,或者黑屏,什么都不显示 请百度 搜索EdgeWebView2 安装后再运行看看 不支持win7** 提要求可以 请描述清楚 最好给出效果图说明!!!! 我不想猜 也猜不到 猜出来最终改完可能不是你想要的 我不想做无用功!!!!!!!!!!!! 2026-05-25 更新 细节调整 增加时间显示标签 删除了竖版相关控件 边框颜色默认叠加,可以通过明度设置叠加深度 https://abpyu.lanzoul.com/iOUDL3qcmqqb 密码:51v4  2026-05-25 更新 细节调整 修复某些照片GPS不显示问题 2026-05-24 更新 增加了磨砂边框效果 增加了字体大小调整 各滑条增加了说明,鼠标悬停可显示出来 2026-05-23 更新 更换了尼康logo 更新了富士和索尼logo,之前旧版有轻微白边 2026-05-23 更新 添加的元素,自动计算距离,等距分布 尽可能减少手动调整位置 以下为手机版,安卓版,华为手机似乎无法保存文件,我的vivo没问题 https://abpyu.lanzoul.com/iZPh63q61jij 密码:23bd 手机版截图  https://github.com/exif-js/exif-js https://github.com/hMatoba/piexifjs https://github.com/lovell/sharp https://github.com/MikeKovarik/exifr 上面四个项目,是否有哪一个能匹敌 exiftool 只需要读取照片的exif信息,例如相机名称,镜头名称,以及参数那些信息,照片被ps处理过,有些信息缺失了,使用exiftool可以还原,上述四个连接的js库是否可以做到还原信息? 为什么电脑版的可以做到离线,手机版不能? 本项目依赖exiftool,这个程序只能在电脑端运行,电脑版程序已打包这个插件,手机无法运行这个插件,只能依赖服务器 那么多开源js库,为什么选择exiftool插件? JS 库（exif-js /piexifjs/sharp /exifr）都不能 “匹敌 exiftool”，也都做不到 exiftool 那种级别的 “还原 PS 丢失的 EXIF”。 相机名称、镜头名称、拍摄参数，只要这些字段还在文件里没被真正删掉，这几个库都能读； 但 PS 重写 / 清空 / 改写过的深层元数据（特别是 MakerNote、厂商私有标签、XMP 历史、Photoshop IRB 等），JS 库基本读不到，更不可能 “还原”。 exiftool 强在哪（为什么能 “还原”） exiftool 是 Perl 写的全能元数据引擎，特点： 支持：EXIF + XMP + IPTC + Photoshop IRB + MakerNote（几十家相机厂商私有数据）+ ICC + JFIF … 能读：正常 EXIF + 被删但残留在文件里的元数据块 + PS 留下的隐藏段 + 厂商私有注释（MakerNote） 所谓 “还原”： PS “存储为” 时，会扔掉 MakerNote、很多私有标签、XMP 历史 但有时文件里还有旧数据残片，exiftool 能扫全文件、把这些碎片捞出来 JS 库只解析标准 EXIF 段（APP1），根本不读 MakerNote、IRB、深层 XMP 一句话：exiftool 是在 “整个文件里挖元数据”，JS 库只是 “读标准 EXIF 表头”。 没有一个 JS 库能匹敌 exiftool，尤其是在 PS 处理过的照片上。 2026-05-23 更新 旧版只检索C盘的 WebView2,此版本在c盘检测不到时,再检测D盘 如果检测不到,则提供友好提示界面 将配置文件放在 %TEMP%\SamPhotoFrame 无论有无检索到WebView2,都会生成配置文件 方便手动编辑,指定c盘d盘之外的WebView2路径 2026-05-23 更新 修复两个bug 下载图片时,排版好的元素会有移位 一字板排版logo和相机名称会有联动,这个不对 2026-05-22 更新 提升代码健壮性 端口改成随机,避免端口冲突造成黑屏 2026-05-22 更新 图片可以直接拖进来 可以不用点击右上角选择文件按钮 经测试,1亿像素载入没有问题,体积60mb单张 2026-05-22 更新 修复了移动边框元素抖动问题,现在移动调整位置丝滑 使用exiftool检测照片的exif信息 ps输出的图片exif破坏严重,原先的js识别信息不准 现在原厂和第三方镜头绝大部分都能准确识别了 缺点是体积又大了十几mb 还好,单文件38.6mb 电脑硬件差点的,可能显示界面要慢点 解压有个过程 此版已修复镜头信息无法修改的bug 2026-05-21 更新 增加了扫描Edge和WebView2区分功能 如果找不到WebView2会有提示 2026-05-20 更新 增加圆角效果 增加投影效果 增加输出分辨率调整,调整的是短边边长 以后不会再到吾爱发帖 2026-05-19 更新 修复取色习惯失效的bug 切换到EdgeWebView2引擎 比旧版丝滑,不会花屏卡顿 一般win11自带这个插件 win10可能需要自己安装下 如果你电脑安装了比较新版本的ps 则自动调用ps自带的 EdgeWebView2内核不用重新安装 很多软件有集成 EdgeWebView2内核,软件会自动检查 实在检索不到,或者是版本过低会有提示 由于换到系统 EdgeWebView2内核了 所以体积大幅降低,直接打包成单文件了 另外,预览时会比较模糊,正常,为了效率输出时不会压缩 再次更新,字体下拉框,显示的是你系统里面安装的中文字体, 更新,主要减肥20mb 改善1080屏幕的最小窗口状态 将默认主题左右居中 离线使用，不访问外网。 这里是原创,不是转载 使用简单, 支持自定义主题 自定义logo 内置四个常用的logo 为什么没有佳能? 因为我没有佳能 外框和内框是什么意思? 外框就是纯色边框 内框,就是将你上传的照片复制一张,放大,作为外框 外框宽度可以自定义 摄影师署名自定义 相机型号有时候识别出来又臭又长,说的就是尼康,所以也加了可以自定义 镜头型号也是,有时候很长,也加了自定义 主题以及logo 还有esif信息,都可以通过鼠标拖拽缩放 [1]: https://abpyu.lanzoul.com/iuEZU3pyierc
-
基于FLUX.2-klein_二创的_人像修饰工具_AI修图 基于FLUX.2-klein 二创的 人像修饰工具 ### **仅适用于单人人像修饰,对大头贴效果比较好** 限于当前模型,目前无法做多人的,例如两人的,以及合影的,等等,这些不是软件问题,是模型问题,这个解决不了 不限制最高像素,4000w像素输入,4000w像素输出,峰值需要12gb显存 低于1024分辨率的,自动补齐1024 有单张模式,也有批量模式 33元离线授权 后续如有新版升级免费 供72小时无限制全功能试用 该项目需要12gb显存,4060 tis 16gb显卡,约60秒一张,5090 32gb显卡14秒一张,3000x4500像素的  2.0版 https://pan.baidu.com/s/18iM2sfSHhC3h9O6N3ZANdw?pwd=gpcb
-
傻木摄影_Bing每日壁纸_更新 新版下载链接 https://abpyu.lanzoul.com/iaHPs3peq8jg 密码:e9ct 发布原因,旧版必应API连接失效 py 3.12开发,不兼容win7 尽可能的保持原版样式,原版使用易语言写的 此版使用py写的 本来不想更新的,因为我现在不用这个了 但是架不住总是有人私信,我也不好回复,回复要扣币的 防止有人不会用 这个软件双击运行不会有窗口 静默的 想看见窗口,请右键点击右下角的图标 双击小图显示大图,大图标题栏有写注意事项 我写软件,会按照用户是猪的原则写 原则上都是极简 如果这都不会用 那应该找下自己的原因了. **bing改api接口了,导致取不到图片实际连接,本软件已失效** ** 经过几天测试下来，目前没有发现什么致命bug，主要问题在每日首次运行时由于下载壁纸而后加载8张1080的预览图，比较消耗网络资源（壁纸按照5mb一张（有些不到1mb有些二十几mb）加上8张1080每张按照1.5mb算，就是17mb左右的流量）看你的网络环境，下载17mb需要多长时间，一般网络情况大概需要3-5秒钟，这期间是假死状态，后台在下载图片。这个暂时没有什么办法优化，先这样了，我觉得不影响使用。另外再说一句，拉取的4K壁纸不是1080放大的，是直接拉去Bing高清HD壁纸，只有预览图是拉取的1080，下载的也是4K的（如果有更高分辨率的，优先下载更高分辨率的）** **软件运行时是没有窗口的，请在任务栏找到图标点击右键，选择“预览全部”或者左键双击图标** 已更新，可以设置壁纸显示方式，例如平铺，拉伸等，任务栏图标点右键设置 本站更新级别最高，一般只要有更新，就会先更新本站，外站资源除大版本外不会更新 软件运行时是没有窗口的，请在任务栏找到图标点击右键，选择“预览全部”或者左键双击图标 Bing壁纸一直比较火，各种软件都有，但是有些收费，有些广告，绝大多数都是1080 分辨率较低，就自己写了个4K分辨率的 视你计算机以及你的网络环境 再加上壁纸都是高分辨率的（我这刚刚拉取了一张21.1mb的壁纸） 可能加载有些慢，这是正常的，另外，加载时，可能点击图标无反应 1.已设置开机自动运行，每次开机都会自动下载今天的壁纸，并设置为你的电脑桌面 2.第一次运行会在软件根目录新建一个JPG目录，之后每日更新后会将下载的图片保存到这个目录 3.如果今日的壁纸不喜欢，可以右键点击任务栏图标，点击前一张（Bing会保存最近一周的） 4.第一次运行，可以点击最近一周，会直接下载最近一周的壁纸（只是保存到JPG目录） 5.点击Bing今日，则会使用你默认浏览器打开今天壁纸的搜索页面 6.每日第一次运行时，可能会假死无响应，因为壁纸是拉取4K（有更高分辨率的就会优先拉取最高的） 7.易语言写的，部分杀毒软件会报毒，介意勿用 8.零点自动刷新壁纸 9.只允许运行一个实例 10.应用壁纸时是4K分辨率（优先更高分辨率） 11.双击预览小图，打开大图 12.双击大图，打开Bing搜索页 13.右键点击大图关闭大图预览 14.右键点击小图，设为壁纸 15.点击右上角的X时，是最小化 16.如需退出，任务栏图标右键，退出.或者使用任务管理器结束任务 17.预览时是拉取的1080分辨率.应用壁纸时是4K分辨率（优先更高分辨率） 18.零点刷新壁纸有延时2秒钟，如果不会刷新，请检查你计算机时间是否正确（尝试同步网络时间） 19.每日第一次运行延迟6秒钟会自动加载预览（不会主动显示预览窗口） 20.预览加载完后零点前不会重新加载，零点后会重新加载（有设置延迟几秒钟，下载新壁纸优先） 
-
朋友之间不应该推荐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/
-
执念化成的WEBgerber查看工具 执念化成的WEB gerber查看工具 从学校出来,就从事PCB行业了 一开始在钻孔厂待了四年 之后又从业过CAM工程 再之后又从事过一段时间的CAM报价工程 虽然十多年不做与PCB相关的工作了 但是一直有关注     写的这个工具主要供报价用 导入文件后,影响报价的参数就自己计算好了 外形尺寸 线路层数 阻焊字符层数 线宽 孔径 孔数 测试点数 还能直接输出pdf文件 提供q键目视检查元素尺寸 提供w键供高亮网络 提供简单的点对点测试 导入资料后,后台自动OCR 可以直接搜索字符层的位号   已更新,带PCB仿真功能,能大概看到PCB成品板样子
-
网管工具箱_Plus 傻木摄影_网管工具箱_Plus 这是个网管工具,用来维护网络等等 当然,我也做了两个小游戏用来检测键盘是否失灵 每次运行,配色都会变化,随机的 这个工具好不好用我不发表看法 但是所有网络维护工具里面,俄罗斯方块一定是最佳! 何况,还有贪吃蛇! 俄罗斯方块玩法,上下左右空格,C键寄存   更新,磁盘管理更改为打印机管理 更新,右上角的关闭按钮位置调整 更新,网络修复按钮,增加确认对话框,修复网络之后,需要重启系统,然后重新设置IP地址 [https://abpyu.lanzoul.com/i7MLX3l465kf][2] 密码:gy0e [2]: https://abpyu.lanzoul.com/i7MLX3l465kf
-
原片导出助手 原片导出助手 使用说明 原片导出助手 是一个用于快速整理照片和视频的小工具，支持全盘检索并一键分类导出。 主要用于摄影方面,插入相机内存卡后,有些视频文件藏了好几层,没错,我说的就是索尼   功能简介 软件会自动检索电脑中常见的： 普通图片：JPG / JPEG / PNG RAW 原片：RAF / NEF / CR2 / NRW / ARW / DNG / RW2 / CR3 视频文件：MP4 / MOV / MTS / M2TS 检索完成后，可按类别一键： 复制到目标文件夹 剪切到目标文件夹 使用方法 打开软件后，先选择要扫描的盘符。 如有需要，可在 照片主题 中输入本次拍摄主题。 点击 开始全盘搜索文件，等待检索完成。 检索结果会分别显示在： 普通图片 RAW 原片 视频文件 确认无误后，点击： 复制到目标文件夹：保留原文件 剪切到目标文件夹：移动原文件 导出规则 导出时，软件会自动在目标目录下建立日期文件夹，并按类型分类整理： JPG RAW 视频 如果填写了 照片主题，文件夹名称会自动带上主题名，方便后期归档。 配置文件说明 软件首次运行后，会在程序所在目录生成配置文件： 傻木摄影_原片导出.ini 可在配置文件中自定义： 默认盘符 目标导出路径 支持检索的文件后缀 照片主题等参数 注意事项 软件支持检索隐藏目录中的文件。 导出到目标目录后，会自动清除隐藏、只读等属性。 若扫描整盘文件较多，首次检索可能需要一些时间，请耐心等待。 建议在使用 剪切 功能前先确认检索结果，避免误移动原文件。 适合人群 适合摄影师、修图师，以及需要快速整理拍摄素材的用户使用。 更新,检索时,会搜索被隐藏的文件,点击复制或剪切时,会将其文件属性去除 更新,双击图片raw或者视频卡片控件,会自动打开ini配置文件,可以增加支持的文件后缀名,以便支持其他类型的文件 更新,在检索到的文件,点右键,有复制,剪切,删除,打开文件夹选项 更新,双击检索到的文件,可以直接打开 [https://abpyu.lanzoul.com/iJMGi3kxczuj](https://abpyu.lanzoul.com/iJMGi3kxczuj) 密码:fin0
网站版权本人所有，你要有本事，盗版不究。 sam@gpcb.net