lavagna v2 发布了
Lavagna 是一款协作黑板软件，旨在用于在线会议期间创建简单的草图。它有一个（可选的）极简UI，以避免画图时分心。您可以使用键盘或可选的工具栏控制颜色和线条宽度。
那么，第二版有什么变化呢？
- 将应用程序从基于 pixels crate的架构移植到了强大的 bevy 游戏引擎上
- 增加了缩放和平移功能，现在可以在无限平面上创建无限的草图
- 支持wasm，因此您可以直接在浏览器中使用它
在线演示 https://lavagna.devand.dev/?collab-url=wss://lavagna-server.devand.dev/demo
那么二进制文件大小呢？ 通过应用 Unofficial Bevy Cheat Book 和 Minimizing Rust Binary Size 文章中的一些技巧，我成功将整个 wasm 二进制文件压缩到不到10M，当使用gzip压缩时，大小仅为2.8M。
请随意尝试，无论是在Web（在此处）还是在本地（在发布页面中的链接）。非常欢迎您提供反馈！如果您想创建新房间，只需更改演示 URL 中的 collab-url 参数或在本地版本中设置 --collab-url 命令行参数即可。
ReadMore: https://github.com/alepez/lavagna
需要多少内存才能运行100万个并发任务？
在这篇博客文章中，我深入比较了异步和多线程编程在流行语言（如 Rust、Go、Java、C#、Python、Node.js 和 Elixir）中的内存消耗。一段时间以前，我需要比较几个计算机程序在处理大量网络连接时的性能。我发现这些程序的内存消耗存在巨大差异，甚至超过了20倍。有些程序的内存消耗仅略高于100 MB，而另一些在处理1万个连接时则达到了将近3 GB。不幸的是，这些程序非常复杂，而且功能也不同，因此很难直接比较它们并得出有意义的结论，因为这不是苹果与苹果之间的比较。这启发我想到创建一个合成基准测试。
我在各种编程语言中创建了以下程序：
启动 N 个并发任务，每个任务等待10秒钟，然后在所有任务完成后程序退出。任务数量由命令行参数控制。
在 ChatGPT 的帮助下，我可以在几分钟内编写出这样的程序，即使在我不常用的编程语言中也可以。为了方便起见，所有基准测试代码都可以在我的 GitHub 上找到。
ReadMore: https://pkolaczk.github.io/memory-consumption-of-async/
一份关于 cargo 目录是否符合平台标准的报告
如果你对这个主题不熟悉，这个介绍可能对你来说有点不清楚。为了更好地了解这是什么，让我们深入了解一些低级细节。
当你在终端中运行
cargo build
时，cargo需要一堆配置值来确定它想要做什么；例如“我是否向编译器传递附加标志？”，“我使用哪个链接器？”，“默认优化级别是什么？”等等。它会在当前目录、每个父目录和一个特殊路径 ~/.cargo/config 中查找配置文件。
此外，cargo还想要保留先前构建的crate、下载的源文件、凭证令牌等的缓存。所有这些文件都将存储在路径如 /.cargo/git、/.cargo/credentials 等的位置。
cargo还保留了rust工具链（cargo本身、rustfmt、rustc等）和所有全局安装的二进制文件，这些文件都在 ~/.cargo/bin 中。该目录通常在首次安装后添加到$PATH中，因此在运行了
cargo install somerustprogram
之后，你可以像运行任何其他命令一样直接从终端运行 somerustprogram。
目前，你可以通过设置环境变量 $CARGO_HOME 来更改 ~/.cargo 部分。如果你设置了CARGO_HOME=/foo/bar ，那么你的全局配置文件将在 /foo/bar/config 中，你的凭证文件将在/foo/bar/credentials 中，等等。
但是，没有办法“拆分”cargo home。没有办法说：“我希望配置文件在一个文件夹中，临时文件在另一个文件夹中，二进制文件在另一个文件夹中。”
然而，这正是一些用户想要的！特别是在Linux上，有一个越来越流行的标准叫做XDG基本目录：
XDG_CONFIG_HOME：应写入用户特定配置的位置（类似于/etc）。默认应为$HOME/.config。
XDG_CACHE_HOME：应写入用户特定非必要（缓存）数据的位置（类似于/var/cache）。默认应为$HOME/.cache。
XDG_DATA_HOME：应写入用户特定数据文件的位置（类似于/usr/share）。默认应为$HOME/.local/share。
XDG_STATE_HOME：应写入用户特定状态文件的位置（类似于/var/lib）。默认应为$HOME/.local/state。
（非标准，但流行的）XDG_BIN_HOME：应写入用户特定可执行文件的位置（类似于/usr/bin）。默认为$HOME/.local/bin。
（Mac、Windows和其他操作系统有自己的惯例，我不太熟悉。）
关于这些惯例真正带来了多少好处存在争议。有些人真的不在意，有些人则坚信它们。
人们提到的一些好处包括：
- 减少主目录的混乱，使查找相关文件更容易。
- 将所有配置文件集中在一个易于备份的
~/.config/文件夹中，没有混乱。 - 将所有缓存文件集中在一个易于销毁的
~/.cache文件夹中。 - 将所有本地二进制文件放在一个单独的文件夹中，这个文件夹“保证”（你的发行版可能不同意）包含在默认的$PATH中。
- 遵循标准路径使与类似Flatpak这样的沙盒框架合作更加容易（尽管在实践中似乎不那么整洁）。
- 更抽象的好处，例如让分析和备份工具更好地理解你的文件结构。
- Windows不使用XDG路径，而是有自己的标准路径，并且很少使用点文件。对于用户来说，使用点文件可能会令人困惑和烦恼。
作为一个经常需要重新安装环境的人，前两点对我很重要：我真的希望应用程序开发人员停止为所有数据使用自己特殊的顶层文件夹，这样当我尝试将我的配置移植到新的笔记本电脑/PopOS安装程序/等等时，我必须跟踪并手动复制它们。曾经我认为NixOS可能是解决方案，但是，嗯，它并没有实现。
此外，我列出的所谓好处强烈依赖于网络效应：只有开发人员编写符合 XDG 假设的应用程序，人们才会编写更多基于 XDG 假设的工具；开发人员将更有动力编写符合 XDG 标准的应用程序，如果这样做有生态系统的好处。这可能会导致令人沮丧的情况，其中一些 major 项目的维护者会相互拖延并指责对方说：“如果 X 没有费心去做，我为什么要费心做？”不过，2023年，我会说支持已经进展到足以清楚地表明生态系统正在朝着广泛支持的方向发展（尽管进展缓慢）。
ReadMore: https://poignardazur.github.io/2023/05/23/platform-compliance-in-cargo/
From 日报小组 Koalr
社区学习交流平台订阅：
评论区
写评论还没有评论