【Rust日报】2023-01-04 turmoil - 由 Tokio 推出用于开发和测试分布式系统的框架

< 返回版块

【Rust日报】2023-01-04 turmoil - 由 Tokio 推出用于开发和测试分布式系统的框架

mook 发表于 2023-01-04 18:59

Tags：rust,日报

turmoil - 由 Tokio 推出用于开发和测试分布式系统的框架

测试分布式系统比较困难，很多不确定性（比如：网络、时间、线程等），使得可重复的结果难以实现。

turmoil通过模拟主机、时间和网络来解决这些问题。可以使整个分布式系统在一个单进程的单一线程中运行，实现确定性的执行。还提供了对网络的细粒度控制，支持在主机之间丢弃、保留和延迟消息。

ReadMore: https://tokio.rs/blog/2023-01-03-announcing-turmoil

alloc-track

这个项目允许按每个线程和每个回溯实时内存剖析。

用法：

alloc-track = "0.2.3"

use alloc_track::{AllocTrack, BacktraceMode};
use std::alloc::System;

#[global_allocator]
static GLOBAL_ALLOC: AllocTrack<System> = AllocTrack::new(System, BacktraceMode::Short);

3.调用 alloc_track::thread_report() 或 alloc_track::backtrace_report() 来生成一个报告。

ReadMore:https://crates.io/crates/alloc-track

sync_cow - 线程安全的写时克隆容器，用于快速并发写入和读取。

读取是无锁的，并立即返回。写入只被其他写入所禁止，而不会被任何读取所禁止。一个只有一个写者和任意一个读者的系统永远不会阻塞。

例子：

Simple Read/Write - Simple showcase of functionsSyncCow
Thread Read/Write - Sharing a between threads using for concurrent accessSyncCowstd::sync::Arc

ReadMore: https://crates.io/crates/sync_cow

如何在 Rust 中生成没有三方库依赖的随机数

随机数非常有趣。感觉就像魔术一样，我们可以从确定性来源产生这种不可预测的熵。

但这是如何发生的呢？在开始在 Rust 中生成随机数之前，让我们先了解随机数生成的过程，以及如果没有特殊的硬件，就永远无法创建真正的随机性。

...

ReadMore:https://blog.orhun.dev/zero-deps-random-in-rust/

From 日报小组冰山上的 mook && MalikHou

社区学习交流平台订阅：

评论区

写评论

github.com/shanliu/lsys 2023-01-05 20:57

都是用于普通场景的伪随机数不加硬件来生成的情况下不可能产生真随机数

zhuxiujia 2023-01-04 23:45

加盐法：盐也是随机数，随机取当前时间的值（精确到纳秒级）一定是随机的

苦瓜小仔 2023-01-04 19:28

注意，随机数的这篇文章在 reddit 发布 20 小时之后仅有个位数的 upvote，而且被招致许多批评，所以它并不是一篇值得参考的文章。

The current timestamp is often used as a unique seed value. That precise time never occurs again

Except for all the reasons for it to happen again e.g. leap seconds, ntp adjustment, incorrectly configured clock, plain fucking with clock, etc... etc...

The difference between /dev/random and /dev/urandom is that /dev/random only returns random bytes within the estimated number of bits of noise in the entropy pool

That's a linuxism: on openbsd and freebsd they're literally the same device, both block until seeded then never block anymore (and they might never block at all because both have at-boot entropy data).

And it's not even true anymore since kernel 5.6, now /dev/random blocks until initialised then stops blocking forever (/dev/urandom still never blocks, so can provide degraded randomness during boot).

Thus /dev/urandom is theoretically vulnerable to a cryptographic attack on the algorithms used by the driver and less random than /dev/random. /dev/random is more suitable for very high-quality randomness applications such as one-time pad or key generation.

This is and has always been utter nonsense. This literally links to a list of "myths about /dev/urandom then proceeds to repeat these myths ffs.

Another external way of generating random numbers is to call the C library function rand(). [...] This has the same disadvantages as getrandom, it requires the C library for linking and has unsafe code.

The primary disadvantage of rand() is that it's unspecified and usually trash. All the BSDs literally title the manpage "bad pseudo-random number generator". rand(3) is barely a step up from xkcd/221 (if it's a step up at all, at least xkcd/221 is reproducible cross-platform, or even at all, there's no guarantee whatsoever that updating your libc won't change the behaviour of rand(3)).

The bottom line is, if we allocate something, take the pointer to it, retrieve the address, and cast it to an integer; we will get a random number. The address in the memory is not totally random, but probably random enough to do stuff™.

The "randomness" comes from ASLR, which is extremely limited on 32b systems (8~16 bits of entropy). 64b systems have more room, but it's still absolutely awful as an rng, IIRC on x86_64 Linux it defaults to 28 bits (you can check /proc/sys/vm/mmap_rnd_bits for the value on your system, last I checked it could be set from 28 to 32 inclusive).

If the allocator uses brk instead of mmap, it's worse, you get 13 bits of entropy out of the brk ASLR. Or less if you use huge pages.

from: masklinn

Sigh... It's disheartening how often "number of dependencies" gets used as a crate evaluation metric. As I wrote in this proposal, I believe that more often than not it's a misleading metric. You don't like that rand has getrandom, rand_core, and rand_chacha as dependencies? But those crates are developed by rand developers! From a practical standpoint, a project split into a number of crates is as good as a single dependency. Even better, such crates enable parallel compilation and free reuse of relevant parts of the project without pulling the whole monolith with kitchen sink.

from: newpavlov

1 共 3 条评论, 1 页