Show HN: Boardzilla, a framework for making web-based board games #
Boardzilla 是一个数字化棋盘游戏平台，提供简单易用的界面和游戏规则表达功能。它允许玩家在浏览器中玩游戏和开发棋盘游戏。目前，Boardzilla 提供了几款游戏，包括《7 Wonders Duel》、《Cursed》、《Hex》和《Power Grid》。此外，Boardzilla 还提供了详细的文档，帮助用户了解如何制作自己的游戏。
请注意，Boardzilla 目前处于 Beta 测试阶段，可能会有一些功能限制或改进的空间。如果您对该平台感兴趣，建议您访问官方网站以获取更多详细信息和最新动态。
HN 评论 95 comments | 作者：joshbuddy | 1 day ago #
https://news.ycombinator.com/item?id=39180953
这篇帖子中的评论观点可以归纳如下：
有人认为在登陆页面上突出显示“加入我们的 Discord”并不合适，应该更多地展示示例和源代码/文档的链接。
有人对 Discord 的使用持负面态度，认为它更适合临时交流，而不适合作为支持和文档的主要平台。
有人建议使用其他替代品来进行临时交流，以避免对不同社交环境进行语言调整的压力。
有人反馈在网页上找不到相关信息，需要滚动页面才能找到游戏示例和其他内容。
有人建议将 Discord 支持频道作为可索引的网站进行发布，以便更方便地搜索解决方案。
有人建议提供更详细的教程，以帮助开发者更好地使用该框架进行游戏开发。
有人指出项目名称中的“Zilla”后缀可能会引发与 Godzilla 版权相关的问题，并建议更换域名和项目名称。
有人表示对于服务器端的游戏逻辑，希望能够支持 Python，因为 Python 在开发者社区中更为流行和强大。
有人认为使用 TypeScript 和 CSS 是合理的选择，因为 TypeScript 可以同时在客户端和服务器端使用相同的代码，而且具有更好的类型系统。
有人认为 Lua 是一种常用的游戏开发脚本语言，可以方便地嵌入到游戏引擎中，但也有人认为 Python 在表达能力和库支持方面更强大。
有人建议支持 Python 服务器端，并提到可以将 Python 代码交叉编译为 TypeScript。
有人认为使用 React 作为前端框架对于游戏来说可能过于重量级，建议考虑其他更轻量级的框架。
有人表示对该框架感兴趣，因为他们有很多棋盘游戏的原型，但没有足够的时间来完善它们。
有人推荐了另一个低级别的框架 boardgame.io，以及其它相关项目。
有人认为在这个领域很难取得成功，除非拥有一个瞬间爆红的游戏，或者付出巨大的社区努力来吸引玩家。
这些观点是根据提供的链接中的评论总结而来的。
Alzheimer’s cases tied to no-longer-used medical procedure #
根据 Stat News 的报道，科学家首次记录到与一种不再使用的医疗程序相关的传播性阿尔茨海默病病例。这些病例与儿童时期接受的来自人类尸体脑部的生长激素有关。这些患者在 40 多岁、50 多岁甚至 30 多岁时就出现了阿尔茨海默病的症状，远早于通常发展该病的人群。他们甚至没有已知的可能导致早发性阿尔茨海默病的遗传突变。然而，这些患者共同的经历是在儿童时期接受了来自人类尸体脑部的生长激素治疗，这种治疗曾经是治疗矮小症等多种疾病的方法。几十年后，这些患者开始出现阿尔茨海默病的症状。科学家们发现，这种类型的激素治疗可能会无意中将蛋白质碎片转移到受体的大脑中。在某些情况下，这可能导致致命的克雅氏病（Creutzfeldt-Jakob disease，CJD）——这一发现导致该程序在 40 年前被禁止使用。
科学团队在《自然医学》杂志上报告称，这种激素移植在一些受体的大脑中引发了阿尔茨海默病的标志性蛋白质 β-淀粉样蛋白的形成，几十年后演变成导致疾病的斑块。这是已知的首例传播性阿尔茨海默病病例，可能是科学上的异常现象，但这一发现为关于阿尔茨海默病的真正原因的持续争论增添了另一个复杂因素。
这些病例并不意味着阿尔茨海默病是一种可以通过照顾亲属等方式传染的传染病。与尸体来源的生长激素治疗相关的阿尔茨海默病病例也已不再可能，几十年来一直使用合成激素代替。这项研究的作者们在伦敦经营着一个专门研究和治疗传染性蛋白质疾病的中心，他们在英国从 1959 年到 1985 年期间已知有超过 1800 人接受了尸体来源的生长激素治疗，其中只有五名患者被诊断为阿尔茨海默病或可能患有阿尔茨海默病。
这些病例的发现不仅仅是科学上的好奇，也是使用尸体来源的生长激素的后果的又一个例子，这些病例可能会引发长达数十年的关于阿尔茨海默病根源的争论。许多科学家认为 β-淀粉样蛋白在阿尔茨海默病的发展中起到了一定的作用，而能够清除人脑中的这种蛋白质的疗法终于在数十年的失败尝试后开始对患者产生一些益处。但大多数专家也认为 β-淀粉样蛋白并不是唯一的原因。因此，在这些病例中，除了 β-淀粉样蛋白的转移之外，是否还存在其他因素？
这项研究的作者和外部研究人员都强调，阿尔茨海默病并不是一种可以通过照顾亲属等方式传染的疾病。与尸体来源的生长激素治疗相关的病例也已不再可能。然而，研究人员表示，这些发现提醒人们继续重视类似于对神经外科器械进行消毒的实践，因为如果在患者之间没有正确清洁，可能会传播蛋白质。
这些病例的发现可能会引发长达数十年的关于阿尔茨海默病根源的争论。科学家们认为，这些病例提供了令人着迷的证据，表明在特殊情况下，阿尔茨海默病可能通过类似于传染病的机制传播，这一机制类似于克雅氏病等人类传染性蛋白质疾病的传播方式。
然而，这些病例的发现仍然存在一些疑问。研究人员指出，有关这些病例的信息有限，只有少数患者的结果被报道，并且只有一部分患者进行了基因测序和尸检。他们还注意到，尽管这些患者出现了认知损害，但他们的大脑中似乎没有太多的炎症，这是阿尔茨海默病的另一个标志，可能是由 β-淀粉样蛋白引起的。他们还对患者的大脑中几乎没有 tau 蛋白的存在感到困惑，尽管 tau 蛋白水平通常与认知下降相关。一些研究人员认为，这些患者可能具有其他增加患阿尔茨海默病风险的基因突变。其中两名患者患有智力障碍，这是另一个风险因素。
总的来说，这项研究发现了与一种不再使用的医疗程序相关的传播性阿尔茨海默病病例。这些病例与儿童时期接受的来自人类尸体脑部的生长激素有关。这些发现提醒人们继续重视类似于对神经外科器械进行消毒的实践，以防止蛋白质的传播。然而，这些病例的发现仍然存在一些疑问，需要进一步的研究来解决。
HN 评论 211 comments | 作者：leeny | 1 day ago #
https://news.ycombinator.com/item?id=39183063
这篇帖子中的评论观点可以归纳如下：
有人指出，这个发现并不是完全新的。他们提到了一篇 2018 年的文章，该文章讨论了通过从尸体中提取的生长激素传播（或者更准确地说是“种植”）阿尔茨海默病的问题。这篇新文章可能提供了额外的证据，或者之前的文章只是怀疑存在因果关系，而这篇文章证明了确实存在关联。然而，他们并没有详细阅读这篇新文章。
有人提到了脑蛋白质的污染，让人联想到朊病毒。他们引用了一段论文中的描述，该论文指出淀粉样蛋白有时候在外观和行为上类似于朊病毒。然而，另一个评论者指出，朊病毒只是一种特定的蛋白质（PrP）才能成为朊病毒，而不是其他蛋白质。
有人提到了其他一些疾病，怀疑它们可能存在类似朊病毒的机制，即某些蛋白质的错误折叠作为模板引起更多的错误折叠。他们引用了关于肌萎缩性脊髓侧索硬化症（ALS）的研究，该研究表明 SOD1 和 TDP-43 的错误折叠形式在神经细胞内自我传播，并传播到邻近细胞。
有人提到了其他可能的朊病毒，例如 α-突触核蛋白的朊病毒形式被认为可能引起多系统萎缩症。
有人提出了一个研究问题，即接受脊柱、脑部和视网膜手术的人是否与其他人群相比患阿尔茨海默病的发病率更高。他们认为，如果没有这种手术的人没有更高的发病率，那么追踪“其他蛋白质行为类似朊病毒”的途径就没有意义。
有人提到了 Creutzfeldt-Jakob 病，这是一种朊病毒疾病，该疾病与这种手术的禁止有关。
有人担心使用尸体组织进行其他手术（例如牙龈和骨移植）的风险。
有人提到，只要不涉及脊柱或脑部物质，使用尸体组织进行其他手术可能是安全的。
有人提到，牛海绵状脑病（BSE）爆发期间，英国禁止了“带骨牛肉”，但并没有禁止所有牛肉。
有人提到，克雅氏病是由农民使用磨碎和加工的牛脑来喂养牛而引起的。他们总结说，不要吃脑子。
有人提到了一种人类朊病毒疾病，库鲁病，它是由家人进行丧葬食人行为引起的。他们总结说，不要吃脑子。
有人提到，他们年轻时认为脑子是动物最美味的部分，但现在已经不吃肉了。他们还提到了一种关于人类进化中脑骨折和骨髓的假设，认为这在提供丰富的长链脂肪酸方面起到了重要作用。
有人提到，脑子中含有大量的胆固醇，可能会对心脏病有风险。
有人提到，牙周病医生与阿尔茨海默病的发病率有关。
有人问牙周病医生或他们的患者是否有更高的风险。
有人提到，如果是朊病毒，那么牙周病医生可能会通过牙科器械的高温灭菌来传播疾病。
这些观点涉及了阿尔茨海默病与朊病毒的关联、其他蛋白质类似朊病毒的机制、其他疾病的类似机制、手术与阿尔茨海默病的关系、牙周病医生与阿尔茨海默病的关系以及牙科器械的高温灭菌等问题。请注意，这些观点来自于 Hacker News 上的评论，可能是个人观点，并不一定代表科学共识。
Researchers have found a faster way to do integer linear programming #
https://www.quantamagazine.org/researchers-approach-new-speed-limit-for-seminal-problem-20240129/
《Quanta Magazine》的这篇文章介绍了研究人员在解决一个重要问题的速度上取得的新突破。该问题被称为整数线性规划（Integer Linear Programming，ILP），它可以帮助解决各种现实世界的问题。研究人员发现了一种更快的方法来解决这个问题。
ILP 问题的解决一直以来都是一个具有挑战性的任务。直到 1983 年，数学家 Hendrik Lenstra 才证明了这个问题是可解的，并提出了第一个能够解决它的算法。Lenstra 从几何角度思考了 ILP 问题。首先，他将 ILP 问题的不等式转化为一个凸多边形等凸形状。这个形状代表了你要解决的具体问题的约束条件，无论是沙发生产还是航空公司的排班问题，形状的内部对应于能够解决这些不等式的所有可能值，从而解决了问题。Lenstra 将这个形状称为凸体(convex body)。问题的维度影响着这个形状的维度：在二维情况下，它是一个平面多边形；在三维情况下，它是一个柏拉图立体，依此类推。
接下来，Lenstra 将所有整数想象成一个无限的网格点集合，数学上称为格点(lattice)。二维版本看起来像是一片点的海洋，三维版本则看起来像是建筑物中钢梁连接的点。格点的维度也取决于给定问题的维度。
为了解决给定的 ILP 问题，Lenstra 证明了你只需要寻找可能的解与整数集合的交点：即凸体和格点的交点。他提出了一种可以穷举搜索这个空间的算法，但为了有效，有时需要将问题分解为更低维度的片段，从而增加了运行时间。
在接下来的几年里，一些研究人员探索了如何使这个算法运行得更快。1988 年，Ravi Kannan 和 László Lovász 引入了一个概念，称为覆盖半径(covering radius)，借鉴了纠错码的研究，以帮助凸体和格点更高效地相交。粗略地说，覆盖半径确保凸体始终包含至少一个整数点，无论你将其放在格点的任何位置。因此，覆盖半径的大小也决定了你能够有效解决 ILP 问题的效率。
因此，问题的关键在于确定理想覆盖半径的大小。不幸的是，这本身就是一个困难的问题，Kannan 和 Lovász 能做的只是通过寻找上下界来缩小可能的值范围。他们证明了上界（覆盖半径的最大大小）与维度成线性关系。这是相当快的，但并不能显著加快 ILP 的运行时间。在接下来的 30 年里，其他研究人员只能稍微改进。
Reis 和 Rothvoss 最终突破的关键是一个与格点完全无关的数学结果。在 2016 年，Oded Regev 和 Stephens-Davidowitz 实际上展示了一个特定形状内可以容纳多少格点。Reis 和 Rothvoss 将这个结果应用到其他形状上，从而更好地估计了包含在 ILP 覆盖半径内的格点数量，降低了上界。Regev 表示：“最新的突破在于意识到你实际上可以使用其他类型的形状。”
这个新的上界改进了很多，使得 Reis 和 Rothvoss 能够显著加快整个 ILP 算法的运行速度。他们的工作将运行时间缩短到(log n)O(n)，其中 n 是变量的数量，O(n)表示它与 n 成线性关系。（这个表达式被认为“几乎”与二进制问题的运行时间相同。）
目前，这个新算法实际上还没有被用于解决任何物流问题，因为要更新现有程序以利用它需要太多的工作量。但对于 Rothvoss 来说，这并不是关键。“这是关于对一个具有基本应用的问题的理论理解，”他说。
至于 ILP 的计算效率是否可以进一步提高，研究人员仍然希望他们能够接近理想的运行时间，但这不会很快实现。“那将需要一个根本性的新想法，”Vempala 说。
文章来源：Quanta Magazine
HN 评论 183 comments | 作者：pseudolus | 23 hours ago #
https://news.ycombinator.com/item?id=39185198
根据提供的链接，这篇帖子中的评论观点可以归纳如下：
降低核心 NP 完全问题的算法上限总是非常有趣的。然而，这并不一定与改进解决问题的实际运行时间有关。
混合整数规划（MIP）求解器使用许多算法与大量的启发式方法。改进 MIP 求解器的关键在于构建启发式方法和策略的库，这是为什么 MIP 求解器的改进超过了摩尔定律的关键部分。
这篇引用的文章可能成为继续改进 MIP 求解器性能的谜题的一部分，但它并不是必然的。
这项工作是理论性的，是基于对 R^n 中凸体结构及其如何被整数格子（格点）覆盖的分析，得到了比以前最好的指数时间算法。
大多数实际的整数线性规划问题使用启发式方法和分支定界算法，并利用特定问题形式的特殊结构。目前还不清楚这项工作是否可以帮助这些方法，除非有 Gurobi（或类似软件）的人参与进来，否则从论文中无法判断。
目前，新算法实际上还没有用于解决任何物流问题，因为更新现有程序以利用它将需要太多工作。但对于 Rothvoss 来说，这并不重要。他说：“这是关于对一个具有基本应用的问题的理论理解。”
一些评论者认为，将新算法整合到现有求解器中可能需要大量的研究工作。
请注意，这些观点是根据提供的链接中的评论总结而来，可能不代表所有观点。
Senator Wyden Letter Confirms NSA Is Buying US Persons' Data from Data Brokers #
根据 Techdirt 网站上的一篇文章，美国参议员罗恩·怀登（Ron Wyden）的一封信证实了国家安全局（NSA）正在从数据经纪商购买美国人的数据。政府经常从数据经纪商购买国内数据，绕过最高法院的限制。联邦机构（以及地方执法机构）正在从乐意参与其中的私营公司那里获取各种国内数据。
虽然政府可以声称第三方原则适用于此处的数据收集，但大部分通过手机应用和其他服务收集的数据可能并非设备用户完全知情的情况下进行的。这些数据往往隐藏在使用条款的深处，诱使人们泄露各种数据，因为他们错误地认为一个看似无害的连连看游戏不会尝试获取他们手机的位置并将其与特定设备 ID 关联起来。
因此，这一最新消息并不令人意外，只是涉及到了哪个机构。罗恩·怀登参议员发布了一份文件，证实了国家安全局购买了美国人的互联网记录，这些记录可以揭示他们访问的网站和使用的应用程序。作为对这一揭示的回应，怀登今天呼吁政府确保情报机构停止购买通过非法手段从美国人手中获取的个人数据。最近的联邦贸易委员会（FTC）的一项规定要求数据经纪商在出售数据之前必须获得美国人的知情同意。
虽然国家安全局拥有全球范围内最具普遍性的监视体系之一，但你可能会认为它能够在不从可疑的第三方供应商购买数据的情况下获得这些数据。毕竟，它完全有能力进行国内监视。实际上，它经常这样做！那么为什么它需要购买它可以通过自己的大规模监控手段（更合法地）获取的东西，并冒着其收集技术的一部分被曝光的风险呢？
除了政府有足够的资金可以轻易花掉之外，这个问题没有明确的答案。怀登的信函提供了更多细节，但出于明显的原因，它并不等同于从 NSA 数据中心偷偷带走证明性文件并在离开国家后交给记者的行为。
尽管如此，为了让政府承认其从经纪商购买数据以进行国内监视，怀登不得不以 NSA 高级职位为人质。
数据购买的保密性加剧了情报机构试图让美国人民蒙在鼓里的情况。我花了将近三年的时间才获得公开发布有关国家安全局购买国内互联网元数据的信息。国防部首先在 2021 年 3 月向我提供了这些信息，以回应我办公室对购买美国人个人数据的国防部组件的信息请求。国防部随后拒绝了我在 2021 年 5 月提出的将非机密信息公开发布的请求。直到我对 NSA 局长候选人提出了拖延，这些信息才被批准发布。
怀登要求每个情报机构元素对从数据经纪商购买数据进行调查，以及对数据经纪商的商业行为进行联邦贸易委员会的调查。每个情报机构元素还被要求提供从数据经纪商购买的个人数据清单。
怀登的信涉及从经纪商购买的所有数据，但特别揭示了国家安全局获取的互联网浏览器记录，显示用户访问的网站和使用的应用程序。国家安全局在去年晚些时候发给怀登的回复中否认了做其他事情的说法。
国家安全局不会购买和使用从已知在美国使用的手机收集到的位置数据，无论是否有法院命令。
这是信中唯一明确的否认，而且它只涉及位置数据，而不是怀登所关心的内容。
然而，国家安全局在同一封 2023 年的信中承认了怀登指控的事实：
国家安全局确实购买并使用与国内互联网通信完全相关的商业可用的流量（即非内容）数据，其中一方是美国的互联网协议地址，另一方位于国外。
国家安全局承认进行国内监视。对于一个仍然希望恢复声誉的机构来说，这并不是一个好的表现，尤其是在经历了几年的泄密、调查和无意中曝光之后。我们已经知道国家安全局完全有能力“无意中”收集到美国人的数据和通信，而这正是联邦调查局经常滥用以进行国内监视的东西。它不应该需要从经纪商那里购买这些数据，因为它一直能够以其他方式获取这些数据。
这似乎是国家安全局因为机会出现而收集更多数据，而不是出于任何明确的国家安全需求。这是任何美国人都不应该愿意将其视为政府常态的事情。
来源：Techdirt
HN 评论 194 comments | 作者：rntn | 11 hours ago #
https://news.ycombinator.com/item?id=39189481
根据您提供的链接，以下是评论中观点的中文摘要：
政府未经合理理由购买公民信息是对第四修正案的违反，应该更新第四修正案以适应现代时代的大量信息收集。
第三方原则是指一旦将数据交给第三方，您就不再拥有“合理的隐私期望”，因此这不算是搜索。需要通过新的法律和/或修正案来改变这种情况。
第三方原则与国家行为者原则相反，国家行为者原则表示政府不能通过私人机构进行审查。这是一种由司法裁定选择的任意区别，没有民主运动来加强第一修正案并削弱第四修正案/第五修正案。修复这种奇怪的不一致性至少是合理的。
购买公民已经自愿交给第三方的数据不违反现行法律，因为这些数据不再是您的财产。但是，许多人不知道他们已经同意将这些数据交给服务提供商，这是一个需要解决的问题。
第三方原则并不意味着您自愿交出数据，因为在我们的社会中，为了参与，人们被迫使用第三方工具进行沟通、获取班级照片、参加体育活动等。数据收集并不是“自愿”的，我们无法看到整个局势。
个人数据的财产权在法律框架中与知识产权不同，因此很难将个人数据的财产权纳入现有的财产权框架中。
可以通过类似于《视频隐私保护法》和《存储通信法》的法律来扩大对第三方持有的所有或大部分个人数据的保护。
公司应该被要求非常明确地披露他们收集的数据以及如何使用这些数据，而不是埋在文件的页数中，而不需要阅读 20 页的服务条款/隐私政策。
同意一个 20 页的服务条款/隐私政策在法律上是不具约束力的，除非有超过 1% 的人实际阅读他们同意的内容。
同意必须是完全知情和理解的，而且必须有一种现实和有意义的方式来拒绝同意。
人们没有选择不关注隐私的权利，问题在于人们没有被清楚告知。我们不能强迫人们关心隐私，但我们可以提供更好的信息披露和选择权。
没有替代方案的情况下，同意是不可能的。在没有替代方案的情况下，同意是不可能的。
公司、法院和国会显然不关心这个问题。在美国，欧洲似乎有点关心，但即使如此，我也不确定解决方案是否足够适当。
应该有明确的方式来拒绝同意，因为隐含的同意对于正在发生的数据收集和聚合来说是不够的。
我们应该寻找不依赖于人们被告知的解决方案，因为这显然不是一种可扩展和稳定的机制。
公司应该要求用户明确知情并同意他们如何使用数据，并且用户应该有一种有意义的方式来拒绝同意，而不仅仅是完全放弃使用任何在线服务。
请注意，这些摘要是根据评论中的观点进行的总结，并不代表我的观点或立场。
How to deal with receiving a cease-and-desist letter from Big Tech #
https://12challenges.substack.com/p/how-to-deal-with-receiving-a-cease
这篇文章是关于如何应对收到大型科技公司的停止与放弃信的。作者分享了自己在 2021 年 7 月收到 Facebook 的停止与放弃信的经历，并提供了一些建议。文章指出，如果你正在开发与大型科技平台相互作用的软件或进行对抗性研究，你有可能收到停止与放弃信。作者建议采取以下几个步骤来应对这种情况：
意识到停止与放弃信可能随时发生，尽量降低风险。
下载你在该平台上的所有数据备份，并定期进行备份。
确保你的生活中没有过多依赖该平台，避免对其产生重要联系、娱乐或获取最新信息的依赖。
阅读平台的服务条款，了解可能违反协议的行为。
请律师咨询，了解你的行为是否违反了服务条款或知识产权法等，并在需要时随时与律师保持联系。
如果收到停止与放弃信，第一步是暂停提供相关软件或服务，除非这样做对你来说没有太大的损失。
不要急于回复停止与放弃信，先找到律师咨询。回复之前，不要在邮件中做出可能被对方用来对付你的陈述。
寻找律师的同时，下载所有账户的数据备份，以防对方尚未发现某些账户。
接收到停止与放弃信后，你有三个选择：忽略、遵守或辩护。
忽略是非常冒险的选择，大型科技公司可能会采取法律行动。
遵守是让问题消失并恢复正常生活的最佳方式，但你可以有选择地遵守要求。
辩护需要时间、金钱和意志力，即使你是完全正确的，也可能会带来巨大的痛苦。
如果你想通过非法律手段反击，可以将争议带到公众舆论的法庭上，向世界宣布发生的事情。
与同情你的记者、用户和其他支持者联系，寻求帮助和支持。
如果你决定接受现实并继续其他工作，你可以通过在公众舆论中引起轰动来推动变革。
无论你做出什么决定，记住你会度过这个困难的经历。
请注意，这只是文章的摘要，详细内容可以在原文中阅读。文章作者还分享了自己的经历和一些建议，以帮助那些收到大型科技公司停止与放弃信的人。
HN 评论 158 comments | 作者：louisbarclay | 9 hours ago #
https://news.ycombinator.com/item?id=39190791
根据提供的链接，这篇帖子中的评论观点可以总结如下：
收到 C&D 信并不一定意味着违法行为，有些公司只是表达不喜欢对方的做法。
收到 C&D 信后，第一步是与律师沟通，了解信中所述的问题。如果认为自己的行为可能存在法律风险，可以进行相应调整。否则，律师会确认收到 C&D 信，并忽略它，除非对方真的有严重的问题，需要提起诉讼。
有人分享了收到多个 C&D 信的经历，但并不意味着自己没有经历足够的冒险。
有人分享了收到 Dealogic 公司的 C&D 信的经历，但对该公司的了解有限。
有人对 Dealogic 公司的描述感到困惑，认为其描述听起来像黑帮。
有人解释了 Dealogic 公司的业务，认为该公司是通过强制性或监管手段迫使其他公司购买其产品。
有人分享了收到多个公司的 C&D 信的经历，包括 Google、Netflix、Microsoft、LinkedIn、Salesforce 等。
有人分享了第一次收到 C&D 信的经历，表示一开始感到非常恐惧，但后来意识到其实并不是什么大不了的事情。
如果没有律师，可以自己学习阅读法律文件，以便能够与律师进行更有意义的对话。
不要让律师为你做出业务决策，他们的工作是指出风险，而你的工作是找到如何降低风险的方法。
有人询问没有律师时应该采取的正确行动，其他人建议学会起草法律文件，以减少律师的费用。
有人询问雇佣律师的成本，其他人提供了大致的费用范围，但强调具体情况会有所不同。
有人分享了家庭拥有律师的经历，认为这是常态。
有人分享了自己需要律师的经历，包括商标问题和游戏规则的相似性问题。
有人分享了自己的经验，认为找到一个好的律师需要经历一些尝试。
有人分享了自己的经验，认为律师的信头纸具有一定的威慑力。
请注意，这些观点仅基于提供的链接中的评论，可能不代表所有人的观点。
Quickemu: Quickly run optimised Windows, macOS and Linux virtual machines #
https://github.com/quickemu-project/quickemu
quickemu-project/quickemu 是一个用于快速创建和运行优化的 Windows、macOS 和 Linux 桌面虚拟机的项目。它提供了一个简单的命令行界面，可以帮助用户快速创建和管理虚拟机。该项目支持多个操作系统版本，包括 Ubuntu、Debian、Fedora、Windows 等，并提供了丰富的功能，如完整的 SPICE 支持、文件共享、USB 设备重定向等。它还提供了优化的配置选项，以提高虚拟机的性能。该项目的目标是使虚拟机的创建和管理变得简单和高效。
HN 评论 115 comments | 作者：overbytecode | 14 hours ago #
https://news.ycombinator.com/item?id=39188432
根据提供的链接，这篇帖子中的评论观点可以总结如下：
有用户推荐使用 virt-manager 作为虚拟机管理软件，认为它功能强大且被低估。
有用户提到 Gnome Boxes 是一个简化的虚拟机管理软件，适合对虚拟机不太熟悉或需要简单操作的用户。
有用户赞同 virt-manager 具有直接编辑 XML 的功能，对于初学者来说非常有帮助。
有用户表示对于 virt-manager 的端口转发功能不太了解。
有用户喜欢 virt-manager 的界面，认为它比 Gnome Boxes 更适合初学者。
有用户提到 Quickemu 可以通过 SSH 远程运行，也可以在本地运行。
有用户赞扬 Virt Manager 在连接到 TrueNAS Scale 服务器并在网络上运行虚拟机方面的稳定性。
有用户认为 Libvirt 和 virt-manager 只是对真正软件（qemu 和 KVM）的简化用户界面，建议直接使用 qemu 和 KVM 以获得更多控制权。
有用户提到 IBM/Red Hat 似乎已经不再推荐 virt-manager，而是推出了一个新的 Web 界面。
有用户认为 Quickemu 更有趣，因为它允许在快速查看示例后立即启动新的虚拟机，而无需学习复杂的用户界面。
有用户指出 libvirt 不仅适用于 qemu，还适用于其他软件。
有用户质疑为什么有人希望使用 Qt 前端，而不是直接调用命令行包装器或核心二进制文件。
有用户希望 Quickemu 能更容易地与 libvirt 进行交互，但该项目似乎不支持这个功能。
有用户表示喜欢直接在 QEMU 命令行中传递选项。
有用户希望 virt-manager 有一个 Web 界面选项，或者推荐使用 proxmox 或 webvirtcloud。
有用户询问在 Mac 上运行 virt-manager 是否可以连接到同一网络上的无头 Linux 虚拟化主机，但遇到了一些问题。
这些是帖子中的主要观点和讨论，涵盖了对 virt-manager、Gnome Boxes、Quickemu 和 Libvirt 等虚拟机管理软件的评价和使用经验。
I just wanted Emacs to look nice – Using 24-bit color in terminals #
https://chadaustin.me/2024/01/truecolor-terminal-emacs/
根据提供的链接，文章标题为《I Just Wanted Emacs to Look Nice — Using 24-Bit Color in Terminals》。这篇文章是关于如何在终端中使用 24 位真彩色（24-bit color）来美化 Emacs 的。
文章作者提到，他最近重新开始使用 Emacs，并且发现 Emacs 社区比他上次接触时更加活跃。他想要让 Emacs 看起来更漂亮，尤其是使用他喜欢的主题（如 Solarized）时。然而，由于他主要在终端中工作，多年来他一直使用的是终端版本的 Emacs，而终端版本的 Emacs 看起来并不那么漂亮。
作者指出，实际上，多年来流行的终端已经支持 24 位真彩色，但很少被使用。这主要是由于历史遗留问题和政策原因。控制码是一种协议，对该协议的更改需要时间传播，特别是在过程中出现错误的情况下。
HN 评论 105 comments | 作者：signa11 | 11 hours ago #
https://news.ycombinator.com/item?id=39189881
根据提供的链接，这篇帖子中的评论观点可以归纳如下：
对终端应用程序的复杂性表示感激，对开发者们的工作表示感谢。
有人选择使用自己的终端，不关心 terminfo，而是假装是 rxvt 终端，以避免应用程序因无法识别 TERM 变量而产生混乱。
对于大多数应用程序来说，支持 terminfo 可能没有太大意义，现代终端已经通过自动检测、环境变量或其他方法解决了 terminfo 不支持新特性的问题。
有些终端默认声称自己是 xterm，但实际上并不兼容 xterm。
有人通过编写自己的终端来满足个人需求，例如输出混合应用程序的纯 Ruby 库、测试其他终端变化等。
有人调整终端应用程序的颜色配置，以获得更好的外观效果。
有人建议使用图形界面的 Emacs，以获得更多功能和更好的用户体验。
有人喜欢在终端中使用 Emacs，因为终端程序的显示性能通常比 X11 设置更好。
有人认为 terminfo 的维护者保守，而新的终端开发者希望快速推进。
有人提到 Emacs 28 不再需要 terminfo 数据库。
COLORTERM 环境变量的设置可能会影响终端显示效果。
有人推荐使用 Tmux 支持 24 位色彩。
有人建议使用 Emacs 的图形界面与远程服务器连接。
有人对 TRAMP 的性能问题表示不满，但喜欢其概念。
有人提到可以通过设置持久的 SSH 连接来改善 TRAMP 的性能。
有人对在远程终端浏览文件并打开文件的过程感到不便，更倾向于直接在远程使用 Vim。
以上是根据提供的链接中的评论观点进行的中文摘要。
Show HN: Open-source x64 and Arm GitHub runners #
https://www.ubicloud.com/use-cases/github-actions
Ubicloud 提供托管的 Ubicloud runners，用于 GitHub Actions。通过改变一行代码，您可以获得 10 倍更便宜的构建，并加快速度。
您可以在 5 分钟内开始使用，每月获得 1250 分钟的免费使用时间。Ubicloud 可以将您的 GitHub Actions 账单降低 10 倍，并减少 GitHub 工作流成本。它提供不同配置的虚拟机实例，包括 2 vCPU / 8GB RAM、4 vCPU / 16GB RAM、8 vCPU / 32GB RAM 和 16 vCPU / 64GB RAM。这些实例的定价分别为 $0.008/min、$0.0008/min、$0.016/min 和 $0.0016/min。
Ubicloud 提供高性能的运行，即使在这个价格下也能快速运行。它专为安全和隐私而构建，使用 Linux KVM 进行完全隔离的虚拟机，并为每个作业提供干净和临时的虚拟机。Ubicloud 还提供与 GitHub Actions 的完全兼容性，您只需更改一行代码即可将 GitHub 工作流配置为使用 Ubicloud runners。
Ubicloud 是一个开放、免费和可移植的云平台，可以将其视为云提供商的开放替代品，就像 Linux 是专有操作系统的替代品一样。您可以在 GitHub 上查看 Ubicloud 的源代码，或者使用他们的托管 runners 来运行您的 GitHub Actions。这个页面上还提到了 Ubicloud 的安全性和开放性，以及如何开始使用 Ubicloud 和 GitHub Actions。
HN 评论 85 comments | 作者：umur | 8 hours ago #
https://news.ycombinator.com/item?id=39191870
这篇帖子中的评论观点可以归纳如下：
Ubicloud 是一个开源云平台，类似于 Linux 是专有操作系统的开放替代品。
Ubicloud 提供了与 GitHub Actions 集成的功能，支持 x64 和 arm64 Linux runners，并且可以降低 GitHub Actions 的费用。
Ubicloud 为每个作业提供了一个干净且临时的虚拟机，作业完成后会销毁虚拟机并擦除与之关联的块存储设备。
Ubicloud 的运行器与 GitHub 运行器完全兼容，只需在工作流文件中更改一行即可开始使用。
有用户对 Ubicloud 的定价和性能表示赞赏，认为它比 GitHub Actions 更便宜且更快。
有用户对 Ubicloud 的落地页提出了一些建议，包括改进定价页面和提供更清晰的产品描述。
有用户提到 GitHub Actions 在 MacOS 上的费用较高，询问 Ubicloud 是否提供 MacOS 的托管服务。
有用户提到 GitHub Actions 的缓存功能速度较慢，建议禁用缓存并在每次构建时重新执行所有操作。
有用户讨论了 GitHub Actions 在使用旧硬件方面的问题。
有用户提到 Ubicloud 的定价页面看起来很棒，因为小数点的轻微偏移。
有用户提到 GitHub Actions 的计算费用非常高，认为这是 GitHub 对计算资源的高额标价所致。
有用户提到在 Hetzner 上设置 GitHub Actions 运行器可以显著节省费用并提高构建时间。
有用户提到 GitHub Actions 在集成测试方面的性能较差，使用 Ubicloud 的运行器可以获得 5 倍到 10 倍的性能提升。
有用户提到 CI/CD 和 GitHub Actions 是旧云硬件的去处。
有用户提到 Ubicloud 的定价页面看起来很棒，因为小数点的轻微偏移。
有用户提到 Ubicloud 的运行器在 Rust 项目中的使用效果很好，CI 时间从 10-15 分钟缩短到 6-7 分钟，费用从每月 300 美元降低到 30 美元。
请注意，这些观点是根据提供的链接进行的摘要，可能不包含所有评论。
A Tour of the Lisps #
https://www.fosskers.ca/en/blog/rounds-of-lisp
《Lisp 之旅》是 Colin 在 2024 年 1 月 28 日发布的一篇博客文章，最近更新于 2024 年 1 月 30 日。在这篇文章中，Colin 分享了他在 2023 年对几种主要的 Lisp 方言进行探索的经历，并介绍了他对每种方言的看法和使用情况。
Colin 在 2022 年接触到 Elixir 后，开始对 Lisp 产生了兴趣。他认为 Lisp 的代码简洁而优雅，而且通过使用结构化编辑，可以快速编辑和移动代码。在过去的一年中，他使用了 Guile、Common Lisp、Fennel、Clojure 和 Emacs Lisp 这五种 Lisp 方言，并分享了他对每种方言的评价和使用经验。
在文章中，Colin 提到了他对 Lisp 方言的吸引之处。他认为 Lisp 的代码美学重要，因为美丽和简洁的代码更不容易出错。Lisp 的语法简洁，而且通过一些经验，人们可以不再注意到括号的存在。此外，Lisp 方言还提供了强大的调试和交互性能，使开发者能够在程序运行时进行调试。
Colin 对每种 Lisp 方言的评价如下：
Guile：拥有 Scheme 的简洁性和一致性，但在没有使用 Guix 的情况下，难以用于大型项目。
Common Lisp：具有丰富的生态系统和热情的社区，提供了一流的调试和交互性能。但是，它需要选择一个实现来使用，并且缺乏现代的 LSP（Language Server Protocol）支持。
Fennel：简单、干净，可以编译为 Lua，并且可以轻松使用 Lua 库。但是，由于完全依赖于 Lua 的运行时，它缺乏 Common Lisp 的调试能力。
Clojure：非常干净，具有一流的人机工程学和工具支持。它与 JVM 的紧密集成可能会让一些人望而却步，但也有其他平台的实现可供选择。然而，Clojure 的错误消息不够友好，并且缺少 Common Lisp 的条件系统。
Emacs Lisp：作为 Emacs 的配置语言，它始终可用，并且具有非常活跃的生态系统和社区项目。然而，由于其历史悠久，它缺乏一些现代功能。
在文章的结尾，Colin 总结了他对理想 Lisp 方言的期望，希望它能融合 Clojure 和 Common Lisp 的优点，并具备更强大但可选的静态类型特性。他认为 Lisp 方言的学习应该从一个合适的设置开始，充分利用 REPL（Read-Eval-Print Loop）进行交互式开发，并通过实际项目的构建来加深理解。他还提供了一些建议，包括加入相关的社区和寻找学习资源。
总的来说，这篇文章提供了对几种主要的 Lisp 方言的综合评价和使用经验分享，对于对 Lisp 感兴趣的读者来说是一篇有价值的阅读材料。
HN 评论 250 comments | 作者：medo-bear | 1 day ago #
https://news.ycombinator.com/item?id=39182721
根据提供的链接，这篇帖子中的评论观点可以总结如下：
Gauche 是一个比 Python 更强大的 Lisp 方言，具有更多的功能和文档支持。
Scheme 是一个非常“简约”的语言，但作为 Guile 和 Gauche 等更大型语言的基础非常出色。
Clojure 是一种非常酷的语言，作为“第三种”方言，与 Common Lisp 和 Scheme 相辅相成。
Hy 是一个编译成 Python 的语言，类似于 Fennel 对 Lua 的作用，它在保留底层语言语义的同时，添加了 s 表达式的功能。
Hyrule 是 Hy 的第一方实用库，从 Common Lisp 和 Clojure 中借鉴了很多有用的宏。
有人在 2023 年的 AoC 中尝试了 Hy，但在某个问题上遇到了性能问题。
Gauche 是一个易于使用的 Guile 替代品，具有更好的文档和更多的功能。
Guile 在某些方面可能不是性能最佳的 Lisp 方言，但它作为嵌入式语言非常出色。
Racket 是一个易于设置和学习的编译 Scheme 方言，具有强大的宏和自定义语言的能力。
Janet 是用于命令行工具的完美 Lisp 方言，具有易于嵌入、简洁的 C API 和丰富的标准库。
Chicken Scheme 是一个愉快的编译 Scheme 方言，具有友好的社区和丰富的包。
Chez Scheme 具有强大的 FFI 和良好的文档，但不确定是否会支持 R7RS。
SBCL 是一个将代码编译为本机代码的 Lisp 方言，可以生成可执行文件。
Gambit Scheme 适用于构建小型命令行实用程序。
Larceny 是一个支持 R7RS 的 Scheme 方言，可以编译为 x86、x64 和 ARM 代码。
有人开发了一个自包含的解释器，可以将 Lisp 代码嵌入到可执行文件中。
这些是评论中的主要观点，涵盖了对不同 Lisp 方言的评价、性能问题、嵌入性和编译能力等方面。
Apple Vision Pro review #
https://www.wsj.com/tech/apple-vision-pro-review-39f2d82e
本文是于苹果 Vision Pro 混合现实盔的测试。在 24 小时时间穿戴这款 Apple Vision Pro，并试在种场下使用。作者发现并不眩晕，还能高效完成作，甚至做一顿味的饭菜。然而，于大数人说，买这款售价 3500 元的盔可能不现实。文章点介了这头盔功能以及它日常活中应用场景。
HN 评论 491 comments | 作者：fortran77 | 10 hours ago #
https://news.ycombinator.com/item?id=39190468
根据提供的链接，评论中的观点可以归纳如下：
Apple Vision Pro 的负面观点：
通过透视效果的质量有限，存在运动模糊、像素化、失真、色彩和动态范围受限等问题。
眼动追踪输入方法在一段时间后变得令人讨厌，因为人们并不总是自然地看着他们想要点击的东西。
人物角色功能还不完善。
缺乏增强现实（AR）功能，而高质量的体验主要集中在虚拟现实（VR）方面。
无法满足其主要用途：
- 用于生产力的话，无法运行 MacOS 应用程序，如果想要使用实际的 Mac，则无法使用多个显示器。
- 用于娱乐的话，人们希望与他人一起欣赏照片、视频、电影，但 Vision Pro 无法实现这一点。
与其他产品的类比：
有人将其与第一代 iPhone 进行了类比，认为评论中的观点与第一代 iPhone 的评论相似。
也有人提到了其他苹果产品的初期评价，如第一代 iPod、第一代 iPad 和 Apple Maps，指出它们在初期都存在一些问题，但随着时间的推移逐渐改进和成熟。
对 Apple 产品的期望：
有人质疑苹果高层对 Vision Pro 的期望，是否认为这只是一个初期的难题，随着时间的推移会变得更好。
也有人提到苹果通常会在产品的后续版本中进行改进和完善，将其定义为该类别的标杆。
请注意，以上总结仅基于提供的链接中的评论，可能不代表所有人的观点。