返回首页
最新
嗨，HN！<p>我创建了Openinary，因为Cloudinary和Uploadcare会锁定你的图片，并按请求收费。<p>Openinary让你可以自托管完整的图像处理流程：在你的基础设施上转换、优化和缓存图像；支持S3、Cloudflare R2或任何兼容S3的存储。<p>这是唯一一个自托管的类似Cloudinary的工具，能够通过简单的URL API同时处理转换和交付（/t/w_800,h_800,f_avif/sample.jpg）。<p>该工具使用Node.js构建，支持Docker。<p>GitHub: <a href="https://github.com/openinary/openinary" rel="nofollow">https://github.com/openinary/openinary</a><p>欢迎反馈，特别是来自希望在自己基础设施上实现相同用户体验的Cloudinary用户！
嗨，HN，
和许多人一样，我开始使用“轮盘”策略（卖出看跌期权/覆盖性看涨期权）来生成收入。很快我意识到，跟踪我的真实成本基础简直是一场噩梦。
我的经纪公司显示股票的购买价格，但它并不知道我在过去三个月中收取了400美元的期权溢价。最终，我不得不制作一个庞大的电子表格，每周五手动更新一次，只为了查看我是否真的盈利。
于是我开发了PremiumFlow来实现自动化。它将期权溢价和基础股票视为一个整体金融单位。
功能介绍：
自动成本调整：如果你对一个长期期权或股票卖出看涨期权，你的“盈亏平衡”价格会立即更新。
行权风险：它监控你卖出的看跌期权距离实值（ITM）的情况。
无需电子表格混乱：所有的计算（年化收益、到期天数等）都在仪表板中处理。
我希望你能试用一下，并告诉我你的想法。我特别想听听你对用户界面的反馈，以及你自己期权策略中可能被我忽视的边缘案例！
我开源了一个用于构建基于MCP服务器的ChatGPT应用的简易启动套件（支持流式HTTP和SSE），并部署在Vercel上。<p>我故意将其保持在一个小而易于审计的范围内，因为我多次遇到SSE头部、CORS预检、运行时差异和部署问题。<p>核心代码库采用MIT许可证，旨在作为一个可用的参考，而不是一个框架。还有一个可选的专业包，包含额外的示例，但免费的代码库本身就足够使用。<p>欢迎反馈。
我正在经历一段互动，过程中出现了一些可疑的迹象，目前我有信心这可能是一次黑客攻击的尝试。但我想在这里询问一下，或许能从外部获得更好的视角。以下是事件的经过：
有人在LinkedIn上联系我，声称有与我的个人资料匹配的全职和兼职职位。我表示我对兼职工作感兴趣，他们立即回复说每月有4000美元的薪水，工作时间为每周15-20小时。
我回复说这相当于我时薪的一半，他们回复说客户几乎愿意接受，但想先和我见面。第一个可疑点：愿意将报价翻倍。
我接受了，并与他们的技术人员预约了时间。第二个可疑点：日历上几乎有满档的可用时间。
他们让我在会议前完成一个任务，并提供了一个与他们团队成员的Microsoft Teams聊天，以讨论这个任务。
聊天中的人给我发了两个问题的截图。我问他们是否在GitHub上有代码，他们回复“GitHub？”第三个可疑点。
然后同一个人给我发了一个压缩文件，并询问我的Node版本。第四个可疑点。
此时我已经开始怀疑，不愿意在我的机器上运行那段代码。我在一台旧机器上全新安装了Linux，并下载了代码。我请Cursor查找任何可疑之处，唯一发现的是package.json和package-lock.json之间的依赖不匹配。我检查了package-lock中存在的包`json-map-source`，该包在https://security.snyk.io/package/npm/json-map-source上被标记为恶意包。这个包在18天前已从npm中移除。大大的可疑点。
我查看npm对这种不匹配的解决方案，发现它会安装`json-mappings`。我在npm上检查，这个包是在18天前创建的，第一版也是唯一一版是2.3.8，恰好与被标记为恶意的`json-map-source`包的版本相同。巨大的可疑点。
此外，这个包没有在Git上，使用的是一个临时邮箱上传的，npm上显示的README中列出的yarn安装命令是`yarn add json-map-source`（即恶意包）。在代码中，这个包只是被加载并作为中间件传递给一个express应用。该包有`sqlite3`作为本地依赖，编译本地代码。
在我写这条消息时，我真的看不出这会是什么其他情况，除了黑客攻击的尝试，但我很想听听其他人的看法。特别是那些比我更了解安全问题的人，这一点很简单。
谢谢！
嘿，HN，我是一名从系统管理员转行的开发者。
在假期期间将你的矿机置于无人监控的状态是有风险的，因此我开发了一个工具来实现自动化。
我厌倦了来自像PJM和ERCOT这样的ISO的延迟和碎片化数据，所以我构建了一个标准化的API，以实时跟踪电网压力。
技术栈：
- 抓取工具：使用Python 3.11（Pandas/Requests）处理混乱的ISO格式。
- 计算：使用Azure Functions（消费计划）将成本保持在接近零的水平。
- 存储：使用Azure Data Lake Gen2（Parquet）进行历史数据保留。
我还为比特币矿工编写了一个简单的Python客户端“杀开关”，以在价格飙升期间自动减少算力。
代码库在这里： [https://github.com/Norris-Eng/gridwatch-kill-switch](https://github.com/Norris-Eng/gridwatch-kill-switch)
API在这里： [https://rapidapi.com/cnorris1316/api/gridwatch-us-telemetry](https://rapidapi.com/cnorris1316/api/gridwatch-us-telemetry)
欢迎提问关于抓取逻辑或Azure成本的问题！