V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ryd994  ›  全部回复第 46 页 / 共 494 页
回复总数  9880
1 ... 42  43  44  45  46  47  48  49  50  51 ... 494  
@flynaj 这和 CA 没关系。而是要 TPM 。不用 TPM 的话,证书登录也就是一个比较长的密码而已。虽然比短密码安全,但也就那么回事。
但是如果正确使用 TPM,那安全的同时还更方便。可以用短密码,因为重试次数过多 TPM 可以锁死或自毁

CA 解决的是两个不认识的人之间的信任问题。这里没有这个问题。这里用户可以把公钥(证书)告诉网站,网站已经靠用户名和密码验证过用户的身份。当然,有 CA 的话更方便,都不用上传证书信息了
2021-08-03 11:20:22 +08:00
回复了 chrosing 创建的主题 问与答 求助:针对固定价格和浮动价格的排序.
固定价格一个表排序。浮动价格一个表排序。查询的时候查两个表然后手动合并结果。
如何合并两个( N 个)已经排序的列表,经典面试题了,不用我说了吧?
2021-08-02 23:10:38 +08:00
回复了 yezheyu 创建的主题 程序员 请教一个很基础的变量内存分配问题
编译原理是一方面。另一方面你可以学一下汇编。写过一个小汇编程序的话你就知道自己的程序编译后是什么样子的了。
进阶还可以看看自己写的程序的反编译。然后发现编译器这都什么怪物?优化的比我写的汇编好多了
2021-08-02 17:30:42 +08:00
回复了 weichengwu 创建的主题 NGINX 请教一个 nginx 的端口转发问题
你再看看前端请求的资源文件是在根路径下还是在 /sss/下?
你可能需要 proxy_redirect 和 subs_filter 。
但是更正确的做法是修改后端,让后端正确配置到 /sss/
2021-07-31 21:16:33 +08:00
回复了 powerman 创建的主题 汽车 接上回 去杭州检车 出结果了 老哥们这车能买吗?
减震器换了,但是减震器座(塔顶)没动过。
应该是没伤到塔顶吧。
减震器更换不一定就是事故原因,也可能是漏了。要问问
2021-07-31 17:03:50 +08:00
回复了 dangyuluo 创建的主题 路由器 家用 pfsense 防火墙硬件推荐?
你真的需要 16 口的路由器吗?
加个交换机就好了。如果要求更多可以加带管理的交换机
2021-07-29 18:48:53 +08:00
回复了 CallmeDredd 创建的主题 分享发现 淘宝运费险骗局
我觉得你当时就不用说拒收什么的,而是应该要求平台介入。你不按规矩来不用平台支持的途径发货,关我 p 事。
找个有 xp 驱动的 usb 网卡。
只要能跑起来,网卡是小问题。又不是贵东西,随便加个 usb/pcie 的,反正能用就行

(除非你要 10G 网卡那当我没说)
数字是随机的。问题在于人类的十进制。而且不是只有平均分布才叫随机。正态分布,泊松比,二项分布,这些都是自然界经常出现的分布。完全平均的随机才是少数。
(论为什么你没有长成一堆白噪声散沙)
所以企业盘有电容保证掉电也可以清空缓存
2021-07-26 12:36:32 +08:00
回复了 James369 创建的主题 Linux ubuntu 下的 sshd 是否具备抗暴力破解的拒绝服务功能?
换端口+证书登录
换端口主要是排除一些低端脚本,省得心烦
2021-07-25 23:47:06 +08:00
回复了 lzjamao 创建的主题 程序员 基于 mmap 相比于 fwrite 写日志,是否有性能优势?
其实你仔细看文一文二,说的都是安卓系统或者移动平台,也就是说,没有 root 权限,不一定能修改 page cache 回写的时机。那这种情况下用 mmap 就是不是办法的办法。因为 mmap 必定不阻塞,所以可以突破系统的限制。
但是这说白了是没有权限的情况下的投机取巧。而且这种情况下对 mmap 也是有限制的。反复 map unmap 还有 page fault 的开销也不小。所以实际效果如何还有待商榷。
2021-07-25 22:21:43 +08:00
回复了 Osk 创建的主题 微软 旧闻: 微软的 RDCMan 远程桌面连接管理器又复活了?
死不了,内部一直在用 rdg 做运维工作。具体细节不知道能不能讲所以不讲。反正平均我每周至少能用到一次。
2021-07-25 21:55:34 +08:00
回复了 lzjamao 创建的主题 程序员 基于 mmap 相比于 fwrite 写日志,是否有性能优势?
@ipwx write 只保证写入 page cache 。vfs 还有 IO scheduler 都可以对操作进行重排或者合并。所以你就算随机写,只要范围不大而且最终结果是连续的,那操作系统就能够合并操作,结果还是连续的
平时 write 会 block 是因为有缓存限制。但是这是可以调整的。
而且还可以用 non blocking write 。缓存满了就失败,你自己再想办法处理。
again,这些都是 page cache,由操作系统管理。

如果你认真了解过 mmap 的实现机制,就会知道,mmap 实际上就是把 page cache map 给你了。既然 write 也是写入 page cache,那写入之后的事情就没有区别了。
2021-07-25 21:44:37 +08:00
回复了 lzjamao 创建的主题 程序员 基于 mmap 相比于 fwrite 写日志,是否有性能优势?
其实多线程还要高性能写入日志,最好的一个线程一个文件。事后再归并。大部分情况下系统时钟或者 monotonic 时钟就足够精度了。
如果你要求绝对的时间顺序,那就最好用无锁队列或其他方式,然后把日志写入交给专门的线程。
也可以开独立的日志进程,比如 syslog 。
2021-07-25 21:40:55 +08:00
回复了 lzjamao 创建的主题 程序员 基于 mmap 相比于 fwrite 写日志,是否有性能优势?
@ipwx 你是不是忘了文件缓存也是由操作系统管理的?你 write 的时候是写入 page cache,flush 才是物理写入。如果你说的是进程挂了,那 write 进去的会在文件被关闭的时候自动 flush 。挂了也会由系统关闭所有文件。

如果你说的是系统挂了,那不管 mmap 还是 write 都得挂。
fwrite 是另一回事,因为 libc 可能另外有缓冲,但是你大可以不用 fwrite 。

fprintf 也是这样。只是写入 fd,并不会物理写入。建议你再看看 write 的文档。

@nuk 1.这里讨论的就是日志。2. 请解释 mmap 比 write 性能更好的理由。write 和 mmap 实际上都是操作 page cache 。除了 write 多一次拷贝之外,最终都是由系统管理何时写入物理媒介。
其实多线程还要高性能写入,最好的一个线程一个
2021-07-25 20:35:49 +08:00
回复了 lzjamao 创建的主题 程序员 基于 mmap 相比于 fwrite 写日志,是否有性能优势?
@nuk 那你多线程写 mmap 就不用锁了?
2021-07-25 19:20:47 +08:00
回复了 lzjamao 创建的主题 程序员 基于 mmap 相比于 fwrite 写日志,是否有性能优势?
@ipwx 问题是你内存里那一份又是哪来的?
要记录的数据那肯定是软件运行时本身就用的数据。那为什么不 fprintf 直接格式化进文件呢?
如果你是怕储存速度跟不上的话,那比起写 mmap 然后指望不知道什么时候会 flush,还不如加大文件 write buffer 和使用 nonblocking 然后加逻辑处理满了的情况。
mmap 更多的时候是用于直接映射到 struct 指针这种邪教玩法。

对于顺序写来说,mmap 只不过是隐藏了储存性能不足和 file write buffer 设置不当的问题。副作用是你彻底失去了对上述两者的控制。

而且以一般的持久储存媒介的性能,少一两次拷贝不会有实质性的影响。
我只信 bogleheads,满仓 sp500 。
美股不只是美国的公司,跨国公司还有全世界的公司的在美股上市。能进 sp500 的没有差公司。如果 sp500 都完蛋了,地球也差不多完蛋了。
投资当然有风险,以上言论都是以二三十年的跨度来说的。
2021-07-24 10:23:04 +08:00
回复了 hzhengy 创建的主题 问与答 谷歌计算器的结果和微软计算器的结果不一致
Bing 直接显示科学计数法了。虽然不精确但也没有错
1 ... 42  43  44  45  46  47  48  49  50  51 ... 494  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2272 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 5026ms · UTC 15:55 · PVG 23:55 · LAX 08:55 · JFK 11:55
Developed with CodeLauncher
♥ Do have faith in what you're doing.