最新

我创建了Lekh，这是一个极简的写作网站，秉持只写的理念。你可以创建lekh.space/你的名字，设置密码，然后开始写作——无需认证，无需信息流，无需干扰。自动保存；内容以加密形式存储；阅读不是重点（你可以在/你的名字/all查看自己的历史记录）。<p>网站地址：lekh.space<p>代码地址：github.com/swappysh/lekh<p>我希望能收到关于以下方面的反馈： (1) “无法编辑”的限制 (2) 你会尝试的使用场景 (3) 首先需要修复的粗糙之处。我在这里回答问题！

嘿，HN， 多年来，我一直在与典型的开发者生产力循环作斗争：我感到灵感迸发，接下太多任务，结果被一大堆待办事项压得喘不过气，最终因为不知道从哪里开始而拖延。当我在一个周末或被打断后终于开始处理一个复杂任务时，我往往会浪费一个小时仅仅是为了回忆我之前在做什么。 现有的待办事项应用似乎是问题的一部分。它们在制作列表方面很出色，但并没有帮助我进行专注和可持续的工作。它们更像是项目经理的工具，而不是在一线的开发者所需的工具。 详细文章： https://medium.com/@priyeshnd555/i-built-a-minimalist-todo-app-to-fight-developer-procrastination-and-burnout-ffcb7cde9836

我在2010年代为iOS和Android开发了一款名为《Putter King Adventure Golf》的游戏。虽然它早已从应用商店消失，但我儿子最近问他能否玩这款游戏，这让我开始思考是否有可能找回它。 我在想，是否有办法在网上找到它的副本（我猜它在某个时间点可能被盗版过）。如果我能找到它，最好的方法是什么来让它重新运行？ 这里有没有人成功找回并复活过他们的旧移动应用？我会很感激任何关于以下方面的建议： * 哪里可以查找存档的APK或IPA文件 * 如何在现代设备上侧载/运行旧移动应用 * 模拟器是否可能是一个可行的选择

我开发了InterceptSuite，以解决我作为安全工程师时常遇到的问题：几乎没有适用于非HTTP协议的优秀中间人代理，而现有的少数工具在协议从明文升级到TLS时完全失效。 核心技术挑战是实现通用的TLS升级检测。当PostgreSQL、MySQL、SMTP或任何其他协议发出StartTLS命令时，大多数工具都无能为力。它们只会显示初始的明文握手，然后在TLS加密启动时就不再显示任何内容。 InterceptSuite能够自动检测任何协议何时切换到TLS，并无缝处理拦截。这不仅仅是另一个HTTP代理，它是专门为数据库连接、电子邮件协议以及使用TLS或TLS升级的桌面厚客户端应用程序流量而设计的。 技术亮点： - 自动处理任何协议的TLS升级，包括SMTP、PostgreSQL等的StartTLS - 跨平台图形用户界面（Windows、macOS、Linux） - 实时流量拦截和修改 - 安全评估的项目管理 标准版是免费的开源软件。还有一个专业版，提供PCAP导出和项目管理等额外功能。 期待您的反馈。

嗨，HN， 我19岁，正在开发VigyanVerse，这是一个通过结构化“卡片”探索知识的网页应用。每张卡片都有快速摘要 → 深入部分 → 如果需要，还可以查看高级细节。 早期版本： [https://vigyanverse.netlify.app](https://vigyanverse.netlify.app) 目前的功能包括： - 通过互动卡片浏览科学/技术主题 - “深入了解”以获取更详细的解释 - 暗黑/亮色模式，适合移动设备的用户界面 - 跟踪浏览量和分享次数 我希望能得到以下方面的反馈： - 什么能让你每天回来使用？ - 有哪些缺失的功能或值得添加的功能？ - 如何让这个学习过程更加有趣和上瘾？ 我独立开发，零资金，仅使用HTML/JS + Firestore + Netlify。

注意：这是对[这篇](<a href="https://news.ycombinator.com/item?id=44568529">https://news.ycombinator.com/item?id=44568529</a>)“Show HN”帖子的更新。 timep 是一个最先进的基于 [debug-]trap 的 bash 性能分析工具，具有高效和极高的准确性。与其他性能分析工具不同，timep 记录： 1. 每个命令的实际墙钟时间 2. 每个命令的 CPU 时间 3. 每个命令的父函数调用/子进程的层级结构 墙钟时间与 CPU 时间的组合使您能够判断特定命令是 CPU 受限还是 IO 受限，而层级日志记录则为您提供了代码实际执行的“如何”图谱。 timep 的突出特点是它会自动生成一个原生 bash 火焰图（显示 bash 命令，而不是系统调用）。 ------------------------------------------------ 使用方法 timep 非常易于使用 - 只需从仓库中引入 `timep.bash` 文件，并在您想要分析的命令前加上“timep”。例如： ```bash . /path/to/timep.bash timep ./some_script echo "stdin" | timep some_function ``` 被分析的代码无需进行任何更改！ ------------------------------------------------ 示例 [将要被分析的测试代码](<a href="https://github.com/jkool702/timep/blob/main/TESTS/timep.tests.bash" rel="nofollow">https://github.com/jkool702/timep/blob/main/TESTS/timep.tests.bash</a>) [该测试代码的输出分析](<a href="https://github.com/jkool702/timep/blob/main/TESTS/OUTPUT/out.profile" rel="nofollow">https://github.com/jkool702/timep/blob/main/TESTS/OUTPUT/out.profile</a>) [该测试代码的火焰图](<a href="https://github.com/jkool702/timep/blob/main/TESTS/OUTPUT/flamegraph.ALL.svg" rel="nofollow">https://github.com/jkool702/timep/blob/main/TESTS/OUTPUT/flamegraph.ALL.svg</a>) [来自“真实世界”测试的火焰图，测试的是用 bash 编写的并行化引擎“forkrun”](<a href="https://github.com/jkool702/timep/blob/main/TESTS/FORKRUN/flamegraph.ALL.svg" rel="nofollow">https://github.com/jkool702/timep/blob/main/TESTS/FORKRUN/flamegraph.ALL.svg</a>) 在“forkrun 测试”中，使用 28 个并行工作者在内存盘上计算了约 670,000 个小文件的 13 个不同校验和。这一过程重复进行了两次。总共，这个测试运行了大约 67,000 个单独的 bash 命令。[这是它的 `perf stat`（未使用 timep）](<a href="https://github.com/jkool702/timep/blob/main/TESTS/FORKRUN/perf.compare.txt" rel="nofollow">https://github.com/jkool702/timep/blob/main/TESTS/FORKRUN/perf.compare.txt</a>)。 ------------------------------------------------ 效率与准确性 forkrun 测试（参见上面的“示例”部分）基本上是 bash 中最苛刻的工作负载之一。它充分利用了 14c/28t i9-7940x CPU 的 24.5 个核心，在约 34.5 秒的墙钟时间内积累了超过 840 秒的 CPU 时间。在使用 timep 对这 67,000 个命令进行分析时： 1. 带有 debug-trap 工具的代码运行时间约为 38 秒，增加幅度略超过 10%。CPU 时间的增加幅度相似。 2. 时间分析在 +2 分钟时准备就绪（分析运行结束后 1 分钟 + 15 秒）。 3. 火焰图在 +5 分钟时准备就绪（分析运行结束后 4 分钟 + 15 秒）。 请注意，timep 为每个命令记录了“开始”和“停止”时间戳，debug trap 工具在一个命令的“停止”时间戳和下一个命令的“开始”时间戳之间运行，这意味着分析时间的误差远低于 10% 的开销。比较 perf stat（未使用 timep）给出的总 CPU 时间（系统 + 用户）和 timep 提供的 CPU 时间（通过汇总所有 67,000 个命令的 CPU 时间），差异几乎总是小于 0.5%，而且通常小于 0.2%。我见过低至 0.04%，这在一次大约 850 秒的 CPU 时间的运行中相当于 1/3 秒。 ------------------------------------------------ 自上一个“Show HN”帖子以来的重大变化 1. 现在也记录 CPU 时间（而不仅仅是墙钟时间）。这是通过一个可加载的内置函数实现的，该函数调用 `getrusage` 和（如果可用）`clock_gettime`，以高效且准确地确定进程及其所有子进程的 CPU 时间。 2. 使用第 1 点提到的可加载内置函数所需的 .so 文件直接构建到脚本中，并嵌入了压缩的 base64 序列。我还开发了它所使用的原生 bash 压缩方案。x86_64、aarch64、ppc64le 和 i686 的 .so 文件均已包含。我希望很快也能添加 arm7。火焰图生成的 perl 脚本也已嵌入，使得脚本 100% 完全自包含。注意：这些嵌入的 base64 字符串包含生成的 .so 文件的 sha256 和 md5 校验和，并在提取时进行验证。 3. 火焰图生成已完全重构。火焰图现在 a) 根据运行时间着色（热色 = 较长的运行时间），b) 对于 CPU 时间远小于墙钟时间的命令（例如，阻塞读取、休眠、等待等）去饱和颜色，c) 使用运行时加权的 CDF 颜色映射，确保无论底层数据的分布如何，生成的火焰图在颜色空间中每种颜色的数量大致相等（“相等”意味着“每种颜色显示的像素数量相同”）。timep 还通过将多个火焰图（显示墙钟时间与 CPU 时间，以及完整与折叠的跟踪集）垂直堆叠到一个单一的 SVG 图像中，生成“双堆叠”和“四堆叠”火焰图。 4. 后处理工作流程基本上已完全重写，使其更加稳健、易于理解/维护，并且速度更快。上述链接的“forkrun”测试（运行了 67,000 个命令）之前需要约 20 分钟。使用新版本，您可以在 2 分钟内获得分析，或在 5 分钟内获得分析 + 火焰图 - 速度提升 4 到 10 倍！