V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mayli  ›  全部回复第 12 页 / 共 23 页
回复总数  450
1 ... 8  9  10  11  12  13  14  15  16  17 ... 23  
TIL: 屎真臭
181 天前
回复了 drymonfidelia 创建的主题 程序员 给大家见识一下日本的逆天 IT 水平
的确,而且是可以移动的,源码里有,但是注释了,这个应该是硬件实现摄像头的 mjpeg 视频流,技术上大概也是 20 年左右了吧
mjpeg 现在也算能用,至少比某些只能用 app 才能看的摄像头,可用性高了很多,过去没有便宜的硬 avc 编码器的时候,这个挺流行的,而且现在有些设备还在用

而且这么多年还能用,日本 IT 水平的确还行。
应该只有超高并发有携程的需求,io 密集到一定程度,携程也没啥优势。
感觉只有高并发是硬需求
198 天前
回复了 AnyTurtle999 创建的主题 Apple 新款 iPad Air 涉嫌虚假宣传
如果你只是想最简单的解法(不考虑最高效率或者多机并发)可以试试 sort+uniq

sort 是可以排序比内存大的文件的: https://vkundeti.blogspot.com/2008/03/tech-algorithmic-details-of-unix-sort.html
然后排序后的 uniq 是不怎么吃内存

不过我看有个需求是要保持文件顺序的话,你可以用 uniq --repeated 来找到重复行,如果你重复行不多,那搞个脚本直接过滤一遍源文件就好,也是线性的。
206 天前
回复了 yuhu96 创建的主题 Python 机器上的 Python 解释器装的太多
推荐 rye
207 天前
回复了 mayli 创建的主题 问与答 homelab 做无盘系统,有啥合适的路子吗?
@BurYiA 最后发现我的需求大概 maas.io 可以覆盖,先 pxe 无盘启动扫描硬件,配置 bmc ,然后自动化装个 ubuntu ,需要啥再后面装。

反正有了系统后面就容易多了。
208 天前
回复了 newtonMiku 创建的主题 宽带症候群 高校如何高效利用 40G 对等线路
@newtonMiku 教育网一般有 iptv 具体怎么做的不大清楚
209 天前
回复了 newtonMiku 创建的主题 宽带症候群 高校如何高效利用 40G 对等线路
内网搞个电视直播( IPTV 那种)

限速打开吧,到峰值再 QoS ,开个开源镜像站。

搞个集群跑 PCDN

其实利用率不高没啥问题,就两端 iperf 24/7 压测呗
一般来说,业界会使用成熟的加密算法和方法来进行验证,也就是不会自行发明轮子。例如安全密码验证会使用类似 bcrypt 和 salt 之类,为了增加安全性引入 2fa 。这种经过验证的安全性技术,用起来一般都不容易出现安全性问题。

对于题主的不信任 https ,进而选择在客户端进行“加密”,在安全性分析逻辑上其实属于“混淆”。因为客户端代码和逻辑都是可以被逆向和检查的,从传统的安全性上来说,基本上属于事倍功半的行为,而且一般情况下,系统的复杂度与漏洞数成正比,可以说系统越复杂存在的漏洞就会越多。引入一个这种技术,大概率是面向 KPI 的 feature ,而不是真的传统意义上的安全。比如说,你如果是客户端实现加密,是否需要引入 salt 或者 key ,那么这个 secret 是否也会通过所谓不安全的 https 通道传输到服务器,这个 secret 服务器需要明文还是可以进一步 hash ,这些都是当造轮子时需要考虑的问题。

当然,另一角度也可以说,我这是特别强力的混淆,就像 D 加密那样,没人可以逆向。这么说也行,不过对于实际场景来说,解决明文用户名密码泄漏的 2fa 技术已经足够流行和有效。即使在 http 情况下,也能一定程度避免 replay attack ,所以大部分公司没有必要投入资源去实现客户端加密。

所以和大部分计算机系统一样,当一个方案已经足够好,另一个方案没有明显优势的情况下,就不会被替换。

另外关于第三方的论点

> 重要的是,各个流程链条上,各自尽量做好自己环节的事情,三方厂商做好自己这一层,出了问题它是要赔钱的,我们不能确保三方一定不出问题,所以自己方负责的链条也做得安全强度更高,有错吗?

“我们不能确保三方一定不出问题”这个思路倒是正确的,但是大部分工业场景是妥协的结果,也就是预算情况下的最廉价解决方案。比如 TCP 本身已经保证不会丢包和乱序,在 tcp 初期,这个 tcp 第三方因为不被信任所以好多程序会自己发明个网络协议。但是 2024 年,不会有程序在 tcp 层上面再去检测乱序或者丢包,大多数情况下,文件传输后,算一下整体的 hash 就够了。妥协的结果就是,大部分的底层结构已经足够可信,对于登陆安全性方面,fidelity 用的明文,chase 用的混淆,我觉得都可以接受。
Taskmgr?
213 天前
回复了 Jaeger 创建的主题 macOS 求 MacOS 下的终端推荐
同样推荐 kitty, 不过菜的话就别玩了
213 天前
回复了 mouseman 创建的主题 游戏 黑神话悟空这个定价什么水平?
3a 这个价格有些不自信,感觉至少定价 299 ,后期才有打折促销的空间。毕竟开发了好几年的游戏了。
@juniorzhou 感觉目前应该没啥更优的解法了,普通的文件系统可能要删更久,大部分文件系统都没有对删除一堆小文件做特殊优化,每个删除都是个复杂的原子操作。除非你可以不走 linux 的文件系统,直接调用某些 gpfs 的某些接口。
的确 删除文件一直是个老大难问题
一般来说单线程 rsync 是最快的
你后台 io 够的话,试试多线程 rsync ,find 限制深度 然后用 xargs/parallel 去删
日历?重复性事件
1 ... 8  9  10  11  12  13  14  15  16  17 ... 23  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2116 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 430ms · UTC 00:22 · PVG 08:22 · LAX 16:22 · JFK 19:22
Developed with CodeLauncher
♥ Do have faith in what you're doing.