你都不知道。就凭这两行中文描述，我们也没法知道呀。

要么你放个 demo 上来看看？

@wolflikai 微信 同昵称

还是要多学点东西才合适。愿意的话跟我私聊一下

同 P2415Q，这个应该可以保修的吧

他不是根据 DNS 生成的，他是一个预置的 namesapce 标记，一般这个 namespace 内的值是 dns 类型的数据。

Namespace 可以是任意 uuid 字符串，你可以选择 uuid1 或者 uuid4 或者自己随便编造一个合法数据使用。


根据文档，可以找到预置的 uuid dns namespace 是怎么算的。For version 3 and version 5 UUIDs the additional command line arguments namespace and name have to be given. The namespace is either a UUID in string representation or an identifier for internally pre-defined namespace UUIDs (currently known are "ns:DNS", "ns:URL", "ns:OID", and "ns:X500"). The name is a string of arbitrary length.

你确定 app 的优化可以克服物理限制么。。
目测是异步预加载+离线缓存

现行标准里有一条新的用法
在不合适打ü 的时候，可以用 yu 来替换，比如 lyu nyu 这种。
现在护照那边都是这么办的了
（但是我自己从姓 lv 变成姓 lyu，感觉似乎没有以前看上去值钱了）

所以你为什么需要推送呢。你或许需要一个 [随机列表生成器]

（我每天纠结与去哪个食堂吃饭的时候经常用这个 [逃]

@LeoNG 移植完主题之后就在赶 paper，两三个月没 care 过博客的事情了
（其实主要是我懒啦）

> 我这段代码是基于将近一个世纪计算机科学逻辑理论基础上写就的。

可是你的这个 topic 里的逻辑怕是都过不了一般大学本科的计算理论课程

另外 @winglight2016：

真随机数本身是一个数学定义，鉴于其容易证伪却几乎难以证真的特点，另外考虑到理想自然噪声本身也是一种理想化数学定义，并不见得真实存在。所以我们只能探讨的是有多大的可信度相信题主的思路。（但是试图证伪一个广泛接受的其他方案并不影响我们探讨楼主方案是否正确）

讨论问题不可能是没有前提的。我们只能假设前提为依据当前科学主流支持的理论为基础进行，这无可厚非。

至于现在人类科学到底是可信的还是胡扯的，That's not our business.

（当然作为科研工作者的一部分，我们还是倾向于相信它可能有一些是胡扯的。不然后人搞科研都要没饭吃了😂😂）

楼主确实像炼丹，而不是现代制药

区别在于后者是在现有理论和逻辑学定义基础内的发展和研究，前者是一股脑扔进去看看。

不过也不是说这样没用，毕竟上次炼丹成功的那位，不是发明了火药了嘛:-D

最严格的真随机数生成器，比如对量子态的观测数据，是不可被设计和预测的。（除非楼主打算把量子力学也革命一发了）

当然可以认为 everything 都受到物理噪声的影响。但是 CPU 并不是噪声发生器，其本身信号数据的信噪比非常高（不然我们的电脑还怎么运转呢）。你给出的方法更大程度上取决于 OS 层级的调度，CPU 层级的优化和实现，时钟信号和外部重点数据 IO，噪声在内部根本就是忽略不计的量级。

所以说啊，不能因为 CPU 本身有噪声，就认为 CPU 拿到的数据就是噪声影响的。实际上很可能那点噪声的影响根本都不到一个最小观测单位呢。

楼主小心走向啊民科啊 [逃

> 宇宙的粒子数目也是有限的，那么状态也是有限的，难道这证明宇宙不存在随机？

有限数据与随机性并无直接关联。有限数据是可以构成不可预测的随机序列的。

况且量子观测数据的理论重点在于其在观测前，叠加态无法预测

CPU 的运转这种相比之下已经很宏观的事情，还没有这个底气跟量子力学比试比试，甚至就连比比物理噪声都差得远

这里看你的真随机数定义是怎么样了。

目前常见理解里，最为严格的定义观点来看，这个世界上只有一种真随机：取量子观测数据。

而目前比较广泛接受的稍微弱化一些的定义，一般认为来自物理学环境观测的数据属于真随机。常见用于各种硬件随机数生成器，比如热噪声或者光噪声采集卡。这种数据本身弱于量子观测数据，但是对于当前人类技术而言也还算可以、

至于程序生成的各种算法上。除了民用日用的并不严格的领域以外，基本上也没人承认过其能达到真随机的地步。

> Randomness is the lack of pattern or predictability in events.[1] A random sequence of events, symbols or steps has no order and does not follow an intelligible pattern or combination. Individual random events are by definition unpredictable, but in many cases the frequency of different outcomes over a large number of events (or "trials") is predictable. For example, when throwing two dice, the outcome of any particular roll is unpredictable, but a sum of 7 will occur twice as often as 4. In this view, randomness is a measure of uncertainty of an outcome, rather than haphazardness, and applies to concepts of chance, probability, and information entropy.

来自 wikipedia 词条 Randomness

个人理解，随机与分布没有相关性。随机的定义是围绕在数据不可预测和无规律上。而分布究竟如何，并不是一个限制条件，只是不同类型的随机分布的 feature 罢了。

不可能

存在偏差的原因很复杂，OS 底层上看到的，或许有进程调度问题，有 IO 请求的延迟等待，有可能遇到内存页 miss，有可能即将执行的指令被 CPU 尝试预测到了等等。尽管看起来很复杂，但是这些大部分在系统层面都是可预测的可重现的。而且分布不可预测。目测并不会有很均匀的随机效果

> 假设系统（或 runtime ）稳定的话
如何定义一个系统是“稳定”的呢。扣字眼一点的话，只有正常运转与不正常运转之分。压力大与小只要没有崩溃，这个系统都是稳定正确的呢。

一般情况下也不是很需要真随机数的吧。真的特别需要的话，https://www.random.org/ 是个好选择。

仔细读了一下你的代码，你可以开一下调试看看，问题很明显在 canvas 的参数上可以看出来的：你的 canvas 大小实际上比 renderer 渲染的目标大小要大很多，所以图像被放大了。

开调试看一下 canvas 的参数，style 的大小应该是你给的，而 renderer 之后依照的大小却是 width height 属性的数值。这样并不正确。

所以正确的方法应该是在创建 renderer 之后执行如下代：

```
renderer.setSize(element.clientWidth, element.clientHeight);
```

这样就可以正确渲染了。另外 mipmap 不应该关掉，highp 也不一定要有的。renderer.setPixelRatio(window.devicePixelRatio);这个开启 HIDPI 可以考虑留着。

看一下加上我给的那句话之后的效果：


https://ws2.sinaimg.cn/large/75a4d8cdly1fmtil59ow8j210a0huwei.jpg

1，个人一般习惯读作姜狗
2，直接用 Django 自带的 ORM 模块，日常大部分弱智注入漏洞足够了。
3，消息队列 定时任务 试试 Celery