## 软件估算的幻觉 软件行业运作于一种“礼貌的虚构”之上——相信只要付出足够努力，就能实现准确的项目估算。然而，经验丰富的工程师知道这从根本上是错误的。由于大多数项目固有的未知数，准确估算软件几乎是不可能的，研究和探索往往超过可预测的任务。 估算并非驱动计划，而是*定义*工作。团队通常会收到一个目标时间框架，然后确定在这些约束条件下*哪些*功能是可行的，而不是估算预定义功能所需的时间。估算主要是一种政治工具，供管理层用于优先排序和资助项目，而非工程的准确预测。 优秀的工程师通过理解政治背景、专注于识别和评估风险（未知数），以及向管理者提供*选项*——不同风险和可行性水平的方法，并与所需时间框架保持一致——来应对这种现实。 最终，作者认为，试图进行精确估算往往适得其反。信任和务实的风险评估比追求不可能的准确性更有价值。认识到估算的真正目的，可以让工程师*与*管理层合作，而不是对抗他们，并在不确定性面前交付价值。
每日HackerNews RSS
Please provide the content you want me to translate. I need the text to be able to translate it to readable Chinese.
## JVIC：一款新的基于Web的VIC-20模拟器
Lance_ewing最近分享了**JVIC**，一款为经典Commodore VIC-20电脑设计的基于Web的模拟器 ([vic20.games](https://vic20.games))。 这篇文章引发了Hacker News用户的一波怀旧之情，许多人回忆起他们早期在VIC-20以及PET 2000和Commodore 64等类似机器上编程的经历。
用户们分享了通过在杂志上输入游戏来学习BASIC编程的故事，通过“修改”内存位置来改变图形和行为，以及调试简单程序的刺激感。 几位评论员强调，VIC-20点燃了他们对编程的热情，并最终塑造了他们的职业生涯。
开发者lance_ewing解释说，JVIC是使用libGDX构建的，最初是针对Android开发的，后来才移植到Web上。 他还讨论了相关项目，例如Oric和AGILE的模拟器，以及一个名为PIVIC的未来VIC芯片替代项目。 用户们还提到了其他模拟器，例如Matt Godbolt的BBC模拟器，并分享了有关稳定性和扩展硬件的经验。
流行的#FOSS口号“直接fork它”——意味着基于现有代码创建新项目——常常具有误导性。虽然在技术上令人赋权，但它忽略了成功的开源项目至关重要的*社会*因素。复制代码很容易；建立一个繁荣的社区，拥有用户、信任、治理和持续维护却极其困难。
“直接fork它”常常鼓励回避现有项目中的困难对话和问题解决，导致碎片化、重复劳动，并最终导致项目失败。大多数fork失败并非由于糟糕的代码，而是由于不可持续的社会动态。
真正的赋权不是逃避问题，而是*管理责任*——参与冲突解决，为共享基础设施做出贡献，并抵制在遇到第一个问题时就放弃项目的冲动。虽然fork作为最后的手段有其用处，但不应成为默认响应。开放文化应优先考虑协作改进而非无休止的重新发明，认识到持久的变革来自于持续的、常常不引人注目的社会工作。
## “直接分叉”的错觉：摘要
最近Hacker News上的一场讨论围绕着开源软件（FOSS）社区中的“直接分叉”这句话展开。核心论点挑战了仅仅分叉项目就能解决分歧或未满足需求的观点。虽然分叉是开源中的一项基本权利和技术现实，但文章认为它常常被用来驳斥有效的担忧，并回避协作和社区建设的“更艰难的社会工作”。
许多评论者指出，“直接分叉”通常是最后的手段，用于建设性对话失败，或者贡献者的想法与项目方向冲突时。另一些人则指出，这通常是对权利意识的回应——用户在不贡献的情况下要求功能。
这场争论触及了项目中的权力动态，一些人认为这句话保护了维护者的控制权，而另一些人则捍卫维护者设定界限的权利。一个关键的结论是，维持一个分叉比创建一个分叉要困难得多，成功的分叉通常源于拥有共同担忧的现有社区，而不是孤立的反抗行为。最终，这场讨论强调了认识开源开发中固有的社会复杂性，而不仅仅是纯粹的技术方面的重要性。
XHTML Club 是一个网站和博客，致力于展示使用有效 XHTML 构建的网站——一种如今已基本过时的网页标记语言。它并非对“旧互联网”的怀旧呼吁，而是对干净、结构化的代码和高质量工艺的庆祝。 创建者承认 HTML5 的主导地位以及当前网页趋于臃肿且不重视验证的趋势。然而，XHTML Club 的存在是为了证明良好格式化的标记 *仍然* 重要且可实现。 它是一种对现代网页开发实践的安静反抗，旨在不羞辱他人，而是提高人们对 HTML 质量的认识，并证明构建结构良好的网站仍然可行——并且有价值——即使这种做法不落俗套。本质上，它是一个精选的集合，也是一位对规范编码充满热情的开发者的个人表达。
``` "));var t=document.getElementById(n);!function(n,t){var e=!1;n.innerHTML='',new IntersectionObserver((function(r){r.forEach((function(r){!e&&r.intersectionRatio>0&&(e=!0,t().catch((function(t){n.innerHTML="Ooops... Sorry, something wrong happended".concat(t,"")})))}))})).observe(n)}(t,(function(){return i.e("ranking-module").then(i.bind(i,4538)).then((function(n){n.showRanking?n.showRanking(t):t.innerHTML="\n\t\t\t\t\t\n\t\t\t\t\t\t请访问aqicn.org/rankings/以获取最新的空气质量排名\n\t\t\t\t\t\n\t\t\t\t\t"}))}))}(),ranking=o}(); ```
一个黑客新闻的讨论集中在网站aqicn.org上，这是一个实时空气质量指数可视化地图。用户发现该网站非常有用，尤其是在中国和印度的数据方面，但一些人对其潜在的民族主义倾向表示担忧。
具体来说，地图似乎使用了中国认可的边界，以不符合国际认可的方式描绘了有争议的领土（例如不丹/中国边界）。这对于那些欣赏该网站实用性但不同意其隐含的政治声明的人来说，引发了伦理问题。
其他评论集中在实际问题上，例如令人讨厌的弹出窗口和某些地点（拉斯维加斯）缺少数据。尽管存在这些问题，但总体情绪是积极的，承认该网站作为全球监测空气质量的资源的价值，其数据来自官方和众包网络。
在简·奥斯汀诞辰250周年之际，英语教授迈克尔·加默和巴里·乔伊斯·戈尔德多年来一直在教授专门研究简·奥斯汀的课程。他们与宾夕法尼亚大学今日报谈了他们教授她小说的方式，如何挑战常见的解读和神话，以及是什么让奥斯汀的作品在两个多世纪后仍然经久不衰，并能适应银幕。
作者为他们的专业工作制定了明确的“禁止人工智能”政策，并在网站上显著展示了相关徽章。这并非新立场，而是近期讨论后正式化的决定。该政策很简单：他们不使用人工智能，甚至对将其用于个人创作也没有兴趣，他们更看重*创作过程*，而非仅仅是最终结果。
作者预计会有人不同意，但他们不寻求辩论，只希望得到建设性的反馈，如果有人认为某个具体观点不正确，请提供来源。他们澄清该政策*仅*关注人工智能，并避免更广泛的“转移话题”行为。
虽然承认行业未来可能发生变化，但他们强调，预测人工智能的完美并不需要高瞻远瞩。最后，作者略带幽默地表示，愿意公开支持一家人工智能初创公司……只要费用*非常*高昂。
## SQLite 与 N+1 查询问题：并非问题 尽管有人批评 SQLite 网站每页执行的 SQL 语句数量（约 200 个），但由于 SQLite 的独特架构，这种方法出乎意料地高效。传统的客户端/服务器数据库（如 MySQL、PostgreSQL）会因每个查询产生的大量往返消息而导致性能下降——即“N+1 查询问题”。 然而，SQLite 在应用程序进程内运行，消除了这种网络延迟。查询是函数调用，因此许多小查询与少数复杂查询同样可行。SQLite 网站利用了这一点，其动态页面（如时间线）由 Fossil 生成，在初始复杂查询之后使用大量查询来提取数据。 这种“N+1”模式并非有害；它通过分离不同对象类型（签到、票证等）的数据检索来简化代码，并提高可维护性。页面生成仍然非常快——50 条目时间线不到 25 毫秒——数据库引擎本身花费的时间也很少。SQLite 的灵活性允许开发人员选择最适合其应用程序的查询策略，证明了许多小查询 *或* 少数大查询都可以高效。
## SQLite效率与用例：总结
这次Hacker News讨论的核心是SQLite令人惊讶的效率，尤其是在较小数据集和特定用例下。主要观点是，由于其嵌入式特性（无网络开销），SQLite在处理大量小查询时，性能可以超越PostgreSQL或MySQL等客户端-服务器数据库。
许多评论者分享了SQLite在生产环境中的成功部署案例，包括在Paperless-ngx中以及通过Cloudflare的D1作为分片解决方案。但强调SQLite不适合高并发写入。
对于需要扩展的写入密集型应用程序，建议使用PostgreSQL等替代方案。Litestream等工具也被提及，用于可靠的备份和复制。讨论还涉及优化SQLite配置（WAL模式、STRICT表）以及避免过早优化的好处。
最终的共识是，SQLite是一个强大且经常被忽视的选择，尤其是在网络延迟是一个问题，并且应用程序不预计大规模或并发写入操作时。当优先考虑简单性和易于部署时，它是一个不错的选择。
多年来，作者一直依赖 GitLab 用于私有项目，最初是被其提供免费私有仓库，而 GitHub 当时需要付费所吸引。尽管 GitHub 现在也提供免费私有仓库，但作者的工作流程已在 GitLab 生态系统中稳固建立。 一个关键优势是 GitLab 集成的容器注册表，提供了一个简单、私有的 Docker 镜像存储解决方案，无需 Docker Hub 的复杂性。通过 `.gitlab-ci.yml` 配置的 GitLab CI/CD，提供了用于构建、推送和部署镜像的版本化流水线，并利用共享运行器实现经济高效的自动化。 作者承认 GitLab 偶尔会出现迟缓和功能过载的问题——提供了超出核心需求的大量工具，但仍然认为其价值主张很有吸引力。免费托管大约一打私有项目，并拥有强大的 CI/CD 和容器注册表功能，使 GitLab 成为实验和开发的理想“数字工坊”。 作者策略性地使用 GitHub 用于公共项目，在协作、可见的工作与 GitLab 中的私有、探索性开发之间保持清晰的区分。
## GitLab：褒贬不一 (HN 讨论总结)
一篇 Hacker News 讨论显示，人们对 GitLab 的看法正在转变。虽然许多人仍然欣赏它的功能和自托管能力，但一个共同的趋势是认为 GitLab 自 IPO 以来质量和性能有所下降。用户报告称，GitLab 专注于“花哨”的功能（尤其是 AI），牺牲了核心的稳定性和速度，而基本功能越来越多地被锁定在昂贵的 Ultimate 版本中。
许多评论员指出，迟缓的网络界面是一个长期存在的问题，并且由于 Ruby on Rails 架构而加剧。一些人提倡使用 Forgejo 和 Gitea 等替代方案，称赞它们轻量级和高性能。
讨论强调了 GitLab 的优势——强大的 CI/CD、全面的功能集以及自托管选项——但也指出了它的弱点：臃肿、性能缓慢以及令人沮丧的长期未修复漏洞的倾向。一些用户也对 GitLab 的定价和安全漏洞表示担忧。最终，体验各不相同，大型组织发现 GitLab 通过适当的投资可以扩展，而个人用户通常更喜欢替代方案的简单性和速度。
This appears to be a snippet of a PDF file's internal structure, not human-readable content. It consists of object references, offsets, and binary data. There is no meaningful text to translate. 大致是PDF文件的内部结构片段，不是人类可读的内容。它包含对象引用、偏移量和二进制数据。没有有意义的文本可供翻译。
这个Hacker News讨论围绕一篇1974年的文章“管理时间：谁来养猴子？”，该文章概述了一种有效的授权流程。核心思想是，管理者经常通过立即提供解决方案而不是培养所有权来夺回未完成的任务（“猴子”）。
文章提出了四个步骤：**描述猴子**（定义任务和下一步），**分配猴子**（授权给尽可能低级别的员工），**确保猴子**（提供支持——要么推荐然后行动，要么行动然后建议），以及**检查猴子**（跟进）。
评论者将此与现代AI代理面临的挑战联系起来，指出代理需要清楚地定义*他们*的下一步行动，而不是不断需要人工输入。 许多用户分享了自己陷入夺回“猴子”陷阱的个人经历，导致负担过重并阻碍团队成长。 还有人指出，管理者经常*分配*工作，而不是真正地授权，并讨论了相关的概念，如“完成的工作”。 讨论强调了有效授权原则的持久相关性。