搜索到
625
篇与
傻木
的结果
-
2026五一江西 这次江西没拍到什么满意的片子 本不想发的 还是水一贴以作留念 除最后一张是相机拍的 其他都是手机拍摄             -
关于织布的忌讳 有件衣服,穿着十分不舒适 有点像洋布 就是那种小时候农村手工织的那种 就想起小时候农村织布的事 感慨良多 好些人都不在了 好多事都在记忆里一点点淡忘 关于织布,有非常非常多的忌讳 当然了,这个是对于会织布的人讲的 我们这代,已经不会了 甚至于织布的机器都不全了 织布的忌讳非常非常非常多 多到什么地步呢? 你平时说的好的那些词,放在织布这个行当里面 可能都是不受欢迎的 你看着线多长啊 你看着卷的好厚啊 这些你觉得是夸奖的 实际全都是不好的 主人家心里可能已经骂你骂的一头狗血了 一般人家牵布会选择风和日丽的,人少的地方 例如学生上学的日子 没小孩过去 自然就少了话语 我们这代已经很少很少人知道这些了 下一代? 就更不知道了 小时候电话都没有,更别提照片了 放上一张网图 
-
即用即删,内网远程协助&便携副屏 刚刚编辑其他帖子时,微信到账30元 谢谢某位大佬的打赏 这个是大佬打赏的版本 https://abpyu.lanzoul.com/iiiSL3p4fj9g 密码:ahnw V11版更新 多网卡情况下,支持切换网卡 切换后,自动保存,下次运行自动使用你切换后的网卡 点击最小化时,最小化到托盘 点击图标恢复窗口 支持自定义端口了,但是我设置了范围,7777-8888之间都是可以的 超出这个区间,会自动用回8765端口 为什么用7777-8888? 原先用的6666,发现与浏览器某些端口有冲突,为了降低小白上手难度,定义为7777-8888之间 怎么自定义端口? 屏幕共享,远程协助.exe 这是默认文件名, 你改成 屏幕共享,远程协助7777.exe 那么自定义端口就是7777了 为什么不做个可以编辑的编辑框? 我不喜欢把界面改的乱七八糟的 这个已经是在不改UI界面的情况下,让功能实现的最简单的方式了 # 内网远程协助 & 便携副屏工具 — 发布说明 ---    ## 一、下载与分发 | 项目 | 说明 | |------|------| | **形式** | 绿色免安装；单文件分发，首次运行可能有解压/加载过程，属正常现象 | | **运行后** | 点击界面上的 **二维码** 可查看简要说明 | --- ## 二、工具定位 在 **局域网** 内：只需 **被控电脑运行本程序**，手机 / 平板 / 电视 / 其他电脑用 **浏览器打开页面** 即可 **看屏 + 远控**；可选 **虚拟副屏**，把平板当无线扩展屏。 **不主打公网穿透**；**不做** 锁屏后的系统级解锁（受系统安全层限制）。 --- ## 三、版本更新摘要 ### V10（近期更新） - **音频**：手机或平板访问页面后，可输出远端电脑声音。 - **浏览器限制**：因安全策略，**不能自动出声**，需用户 **手动点击喇叭** 解除静音。 - **全屏**：全屏时可用 **双指双击** 唤出顶栏等按钮。 - **延迟**：音频有延迟属正常现象，与路由器、电脑性能、接收端设备与网络有关。 - **说明**：点击程序内 **二维码** 有简单使用说明。 ### V9.5 - 删除两组快捷键：**Ctrl+Y**（使用少）、**Ctrl+Alt+Del**（浏览器安全层下无效）。 - 增加 **Del** 键。 ### V9 - 修复：浏览器里点击画面已显示鼠标指针，但被控电脑指针 **不同步** 的问题。 ### V8.5 - 修复 **iPad** 无法唤出键盘等问题。 - **双指双击**：唤出底部 **常用键** 与 **屏幕切换** 等，切屏更方便。 ### 虚拟副屏 / 系统兼容（重要） - **Windows 11 22H2 及以上**：**不兼容** 当前虚拟副屏驱动，**无法新增虚拟副屏**。 - 启用虚拟副屏时可能出现 **约 2～3 秒闪屏**，为驱动安装过程，属正常现象。 - **关闭软件** 会自动注销虚拟副屏。 ### 公网与其它能力 - 公网类 FRP / P2P 等方案经测试 **效果不理想**（动态画面、指针等不流畅），**不作为本工具方向**。 - **锁屏后无法解锁登录**：需要系统级能力，**当前不做**。 - 节假日等时段若无法及时修 Bug，以楼主在帖内说明为准。 --- ## 四、使用说明 ### 1. 环境与适用 - **适用系统**：Windows **10 / 11**（**不支持 Win7**）。 - **控制端**：手机、iPad、平板、电视或其它电脑等，**无需安装客户端**，现代浏览器打开即可。 - **场景**：内网协助、现场指导、问题排查、轻量「副屏」扩展等。 ### 2. 核心特点 - 绿色、无广告、**纯内网**离线使用为主。 - 浏览器直连，免装 App。 - **多显示器切换**；**虚拟副屏**扩展。 - 触控远控：**缩放、拖动**、指针定位。 - 移动端 **键盘与常用快捷键**。 ### 3. 快速开始 1. 双击启动程序（打包为单文件，**窗口显示略慢** 为解压过程，正常）。 2. 用手机/平板浏览器 **扫码** 进入控制页。 3. 进入后即可查看并操作电脑画面。 ### 4. 界面与操作 | 区域 / 按钮 | 说明 | |-------------|------| | **屏幕按钮组** | 以 **独立按钮** 切换目标屏幕（已由下拉改为按钮）。 | | **新增虚拟屏** | 为单物理屏电脑扩展 **无线副屏**（受系统版本限制见上文）。 | | **全屏** | 网页全屏显示远程画面。 | | **重置** | 画面缩放后可用；**一键恢复** 原始自适应大小。 | **触控手势** - **单指**：移动 / 点击（随当前映射）。 - **双指捏合**：缩放画面。 - **双指拖动**：平移已放大的画面。 - **iPad Safari 长按右键**：已针对性修复。 **鼠标指针** - 移动端点击画面后，会显示 **远端指针位置**，便于精确定位。 ### 5. 移动端键盘与快捷键 - **双指双击**：呼出底部 **常用功能键** 栏（Esc、Win、Enter、Ctrl+C/V 等）。 - **全键盘**（若界面有入口）：调起系统输入法进行文本输入。 - 功能键栏支持 **空闲一段时间后自动隐藏**。 ### 6. Token（访问密钥） - 默认 **随机临时 Token**，程序重启后一般会变。 - **双击 Token** 可改为 **固定值**；规则：**4～8 位字母或数字**。 - 恢复随机：双击 Token → **清空** → 回车。 ### 7. 副屏扩展（虚拟显示器） - 启用时 **2～3 秒闪屏** 多为驱动安装，正常。 - 可把平板 / iPad 当 **无线副屏**。 - **退出本软件** 会尽量 **注销虚拟副屏**。 - 虚拟副屏显示异常等问题，楼主已在多分辨率场景做过验证与修复说明（详见原帖）。 ### 8. 常见问题（FAQ） | 问题 | 说明 | |------|------| | 电脑 **锁屏 / 主动息屏** 后断连 | 可能发生；**不支持** 在锁屏界面做系统级解锁。 | | **公网 / 跨网段** 稳定直连 | **非本工具目标**；楼主测试多类 P2P/穿透，效果不理想，故不主推。 | ### 9. 已知限制 - 主控 **主动锁屏 / 息屏** 后，连接可能中断。 - 虚拟副屏 **驱动较老**，与 **Win11 22H2+** 等新版系统存在 **不兼容** 情况。 - 定位为 **轻量可视协作**，不替代企业级远程桌面方案。 ### 10. 开发初衷 在内网场景提供 **简单、直观、无广告、低门槛** 的远控/副屏能力：**少配置、少学习成本、即开即用**，适合同事协助、现场演示、临时排查等。 --- ## 五、反馈 Bug 时请尽量提供 以下信息 **非常必要**，否则难以复现与定位： 1. **电脑系统完整版本号**（例如 Windows 11 22H2）。 2. **显示器尺寸、分辨率、DPI 缩放** 比例。 3. **控制端设备**：手机 / 平板；**Android / iOS**。 4. **现象描述**：具体出现了什么异常。 5. **完整操作步骤**：从打开软件到触发问题，**每一步**如何操作。 ---
-
朋友之间不应该推荐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%的 随机组合数量瞬间指数级下降 再加上不同精度的电阻,直接影响充电时间 又给这个组合增加无限可能 真是一个神奇的方案 因此,任何器件,在选用替代料时,一定要尊重客户的设计,如果你不懂 一定要问客户
网站版权本人所有，你要有本事，盗版不究。 sam@gpcb.net