V2EX › rekulas 的所有回复 › 第 16 页 / 共 100 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 12 13 14 15 16 17 18 19 20 21 ... 100

❮

❯

2024 年 9 月 6 日

回复了 izzy27 创建的主题 › 程序员 › 独立开发好做吗？

多起来不一定是风来了，也可能是短时间内裁的太多了，考虑现在的经济环境，你觉得哪个可能性大

2024 年 9 月 6 日

回复了 dai269619118 创建的主题 › 程序员 › 为什么 ai 生成的图片手指总会有问题

这个网上不是很多分析了么，根本原因就是 ai 在缺乏对基础知识（投影、形体、物理、空间关系、力学等）的真正理解，而手虽然看起来简单，实际是一个比较复杂的结构，不同手势、角度带来的变化太大了，以目前 ai 的训练量还很难较为完美绘制

mj 在手部上不算特别出色，现在有一些针对手部的增强模型，可以 mj 画了主图之后用增强模型修复手部，可以上 civitai 搜搜

另外我觉得这也只是暂时的，大力出奇迹，ai 还在不断迭代，只要训练数据够多别说手千手观音都 so easy

2024 年 9 月 5 日

回复了 drymonfidelia 创建的主题 › 信息安全 › 从原理上分析，把明文进行 100 轮 [SHA512->SHA256] 这样哈希计算，随机性会比直接 SHA256 更差吗？运算后结果可能性不都是 2^256 种吗？照这么说的话加 salt 也会影响随机性？

@edward1987 好吧，那确实是的，我只是针对上面的评论回复，不是针对 op 的 hash 算法变化的情况

2024 年 9 月 5 日

@rekulas 抱歉是 10 种

2024 年 9 月 5 日

@edward1987 come on, 你这个推理有点钻牛角尖了，我说的“ hash 的结果再次 hash”当然是指同一个 hash 算法，包括输入应该是同样范围的

你这个我再翻译下，相当于把任何输入映射为 0-9 的数字，再对这个数字进行 hash ，那 hash 结果当然只有 9 种

如果你第二次 hash 的算法也是同一种，那数学安全性是没有区别的

2024 年 9 月 5 日

@dzdh 你自己都说了是 hash 了，看下源码就知道任何输入都会映射到固定区间，在数学上不存在输入更复杂就更安全的情况

所以“任意字符输入的组合的 hash 结果” 跟 hash 的结果再次 hash 仅从概率上是一样安全的

2024 年 9 月 4 日

作为一款加密算法,如果随机性都做不到稳定那也太拉了,怎么可能被选为标准

不会增加随机性,但会增加安全性

2024 年 9 月 2 日

回复了 colderforever 创建的主题 › 程序员 › 非前端程序员用 Cursor 两小时搞定了一个 SEO 友好的网站

f 不过你这个网站完全表现不出 cursor 的优势来，我用 gpt 甚至国内模型也能写出来而且用不了 2 小时

2024 年 8 月 29 日

回复了 xuewei 创建的主题 › 程序员 › 程序员自由创业周记#40：结束了

根据身边成功和不成功的案例来分析经验,会发现专注于一个垂直方向的更容易成功, 毕竟你只是一个人, 除非转变下思维,用站群的模式去经营...

2024 年 8 月 28 日

回复了 HFX3389 创建的主题 › Go 编程语言 › 大家用 Go 写程序时会追新版本吗？追大版本还是追小版本？

我一般落后 2 个月更新到最新毕竟向下兼容做的还是可以基本问题不大

2024 年 8 月 28 日

回复了 assassing 创建的主题 › 程序员 › Go 语言中延迟语句修改返回值算陷阱还是特性？

@assassing 后续单独使用一个函数来处理返回值
自然也是可以的，但如果你的逻辑依赖的数据是函数内部变量，那你可以选择定义内部函数然后每个退出都调用一次，总归没有 defer 方便，而且可能遗漏导致 bug ，另外有些场景下可能需要对返回值进行二次处理，用 defer 也更方便，不容易出 bug
举个例子，一个典型场景函数内部开启事务，在 defer 中 commit 就可以避免出现事务未提交阻塞数据库的情况，现在很多 orm 也用这个原理封装了事务函数，尽最大可能降低了 bug 产生率

2024 年 8 月 27 日

回复了 iqoo 创建的主题 › 程序员 › 使用 AES 生成伪随机数如何？

可以用只是没啥必要, go 本身带了随机数库为啥用 aes 来转一遍,这个强度只取决于你的种子,用了 aes 也不能提高强度反而变慢了

说个题外话,说 aes 的速度快其实是说在对称加密算法上快,跟随机数生成器比起来其实很慢,可以慢几百甚至上千倍

2024 年 8 月 27 日

回复了 assassing 创建的主题 › 程序员 › Go 语言中延迟语句修改返回值算陷阱还是特性？

算特性吧, 会这样写的大多应该了解这样做会产生什么影响,不至于引起意外 bug
我很喜欢这特性,当做函数的析构逻辑来用,例如某些复杂方法内部可能包含多个判断,可能会涉及提前返回,不同的返回可能关联了不同的退出逻辑,我就可以在 defer 里统一处理,而不用每个 return 都去调用或者判断

2024 年 8 月 27 日

回复了 baiyekaslana 创建的主题 › MySQL › Mysql 主从同步问题

@rekulas 10-500 毫秒

2024 年 8 月 27 日

回复了 baiyekaslana 创建的主题 › MySQL › Mysql 主从同步问题

mysql 自带主从很拉跨，内网同步都能各种 bug ，不然也不会有这么多三方解决方案了

我们之前用的阿里 canal 代替，比较稳定除了服务器断电几乎没出过什么问题，时延能控制在 10-500 内

2024 年 8 月 26 日

回复了 noconfuse 创建的主题 › 程序员 › 2 年独立开发，我要去吃土了

没尝试过 saas 服务然后线下推？

2024 年 8 月 22 日

回复了 humbass 创建的主题 › Node.js › 关于断点续传

移动文件应该很快,耗时应该是在合并上,增加了额外的 io 时间

所以最佳方案应该就是预申请空间,然后不同的线程可以在不同的段进行 io 写入不会冲突(如果是单线程写入那就更不会了), 只需要验证分块 hash 正确最后的文件应该就没啥问题了

2024 年 8 月 21 日

回复了 drymonfidelia 创建的主题 › Chrome › 逆天 Chrome，新版本连下载链接都不让看了

不是第一次两次了，chrome 之前的各种作看的人恶心，看看 google 出的产品，无论编程语言还是工具，都是硬抗社区抵抗强制按自己喜好来更新，这就是我越来越觉得 google 傲慢的理由
希望来个公司能取代它

2024 年 8 月 20 日

回复了 zhng920823 创建的主题 › 分享创造 › 可视频可随意创建的聊天室聊天内容前端加密服务端看不到

梦回 2006

1 ... 12 13 14 15 16 17 18 19 20 21 ... 100

❮

❯