最新

我创建了Lime Reader，这是一个简约的网站，展示了来自Hacker News、Tildes、Lobsters、Slashdot、Bear以及一些与科学、技术和编程相关的subreddit的按时间排序的热门帖子。 您可以通过点击我网站顶部的口号“您每日的STEAMD网络指南”来了解更多关于该网站的信息： <a href="https://limereader.com/about" rel="nofollow">https://limereader.com/about</a> 之前，我一直使用Rust或NodeJS作为后端，Postgres作为数据库。 这次，我首次使用Swift作为后端构建网站，使用SQLite作为数据库，仅使用了一个第三方依赖：在Swift应用中使用Vapor作为Web服务器，并将其全部自托管在一台旧的Mac mini上。 我非常厌恶庞大臃肿的网站，也不喜欢在没有绝对必要的情况下添加第三方框架。因此，我将Lime Reader设计得尽可能小，以便能够瞬间加载。PageSpeed Insights和Pingdom均将我网站的性能评为优秀。 它是服务器端渲染的，因此即使禁用JavaScript也能正常工作（虽然启用它会为每个链接提供一些额外功能，如快速访问archive.org）。即使禁用CSS，它也能在一定程度上工作。 该网站没有任何广告（我讨厌广告，并在各处安装了广告拦截器！），没有追踪器或分析工具。CloudFlare会自动在网站上启用真实用户监控（RUM）。我做的第一件事就是禁用这个功能。 我在一台旧的Mac mini上自托管该网站。这是一款2020年的Intel型号，配备2018年的芯片（Intel的3 GHz 6核Core i5）和32GB内存。Qwen模型的内存使用约为5.5GB，每个标题分类大约需要2秒。 Swift应用与本地运行的Qwen3 8b LLM进行通信，以判断标题是否属于政治类。这是通过Ollama的REST API完成的。这似乎效果很好，远胜于Apple的基础模型。最初，我尝试使用Apple的基础模型进行分类。当它有效时，效果还不错。然而，许多标题（甚至一些相当平淡的标题）会不知为何触发其保护机制。我在Stack Overflow上寻求帮助，但像往常一样，他们因缺乏细节而关闭了问题： <a href="https://stackoverflow.com/questions/79785822/how-to-disable-apple-intelligences-guardrails" rel="nofollow">https://stackoverflow.com/questions/79785822/how-to-disable-...</a> 例如，这个标题： > SEC批准德克萨斯证券交易所，这是几十年来美国首个新的综合交易所 会触发Apple的保护机制，并抛出一个错误，提示“拒绝：可能包含敏感内容”。 Apple确实提供了一个“宽松的保护模式”，具体见： <a href="https://developer.apple.com/documentation/foundationmodels/improving-the-safety-of-generative-model-output#Use-permissive-guardrail-mode-for-sensitive-content" rel="nofollow">https://developer.apple.com/documentation/foundationmodels/i...</a> 这确实允许某些文本正常工作。然而，对于其他一些文本，它仍然失败。这时我放弃了使用Apple的基础模型，转而使用没有此类问题的Qwen3 8b模型。令人遗憾的是，基础模型有很大的潜力，但Apple却严重削弱了它们。 我最初在配备M4芯片的新Mac上尝试了Apple的基础模型，一旦遇到保护机制的问题，我决定切换到在Intel上运行的Qwen模型，并使用我的旧Mac mini。 我遇到的一个问题是我的Swift应用间歇性崩溃。根本原因有两个： 1. 第一个与从多个线程访问SQLite数据库有关。显然，对于多线程使用，SQLite需要用`SQLITE_OPEN_FULLMUTEX`标志进行初始化。 2. 第二个是来自macOS操作系统本身的“坏文件描述符”错误。这与Process.run()中的一个可能的bug有关，导致它在一段时间后崩溃： <a href="https://github.com/swiftlang/swift/issues/57827" rel="nofollow">https://github.com/swiftlang/swift/issues/57827</a> 我能够通过上述“fileHandleForReading.close()”的解决方法修复它。 让我们看看这个网站现在能持续多久而不崩溃 :) 如有任何问题，请随时询问。

这是我最近看到的一个例子 - https://x.com/ycombinator/status/1988366241460089118 最近我发现越来越多这样的无意义的商业模式，而我并不是唯一有这种感觉的人。你怎么看？

我不使用名片，更喜欢让人们扫描我手机上的二维码。不过，这里有两个问题： - 其他人往往会给我名片，结果这些名片堆成一堆，难以区分。 - 当人们扫描我的二维码时，信息会直接进入他们的联系人中，之后再也看不到了。 为了解决这个问题，我创建了netcards。这是一个非常简单的渐进式网页应用（PWA），我和Claude一起编写了代码。工作流程如下： - 在“我的名片”页面输入你的信息和事件名称并保存。二维码会随之出现。 - 在标签页面设置标签。 - 当人们用手机的应用扫描二维码时，信息会直接进入他们的联系人黑洞，但至少会有一个事件名称和你的所有信息。 - 如果在应用之间扫描，你可以选择标签，之后可以根据事件名称和标签进行筛选。 - 然后你可以分享联系人，为他们生成二维码，或者保存vcards以导入到你的本地联系人应用中。 显然，使用的人越多，这个工具就越有用，所以我想先在HN上分享一下。 技术： - 原生JavaScript，支持离线的PWA - 使用IndexedDB进行本地持久化 - 使用jsQR和qrcodejs进行扫描/生成 - Bulma CSS，所有依赖项来自CDN - 网址：<a href="https://netcards.app" rel="nofollow">https://netcards.app</a> GitHub: <a href="https://github.com/evronm/net-cards/" rel="nofollow">https://github.com/evronm/net-cards/</a> 我只在我的安卓手机上测试过这个，所以我特别想听听iPhone用户的使用体验。不过，总的来说，我想知道大家是否觉得这个工具有用，以及是否有人有任何建议。