V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 21 页 / 共 92 页
回复总数  1830
1 ... 17  18  19  20  21  22  23  24  25  26 ... 92  
2022-04-02 03:27:14 +08:00
回复了 dijia1124 创建的主题 Android 这个时间点好像没什么我喜欢的安卓手机值得买了
弟弟 V9 第三次碎屏(多手贱了一次内屏又出问题)第二次电源键失灵(官方售后还订不到货),所以干脆就上了个红魔 7P 。
确实还是很多不爽(所以我一个官解 BL 的弟弟 V9 能撑那么多年),但是,禁不住人家大啊( 18G+1T ,反正比我 SB2 大
8Gen1 是真的……但一时也没得选,希望风扇能压住吧。重量勉强能接受,系统优化续航不指望了(这机器快充功率属实吓人,应该能减少点影响)。
看在 3.5mm 耳机孔的份上没 IP68 就忍了。
摄像正好没什么需求,而且真全面屏算是治好一部分强迫症了。
刷系统反而是小问题,只要不是三星那种 eFuse 或者不给解 BL 的(直接不考虑)。反正不指望刷公版 Linux 了。
@learningman 那种一般就不会叫虚拟内存。
实际能替换的,基本就只限于光栅图缓冲区这种,也不是 placement new ,还要有 swap buffer 的真 IO 。一些看大图的软件就有这种机制,上面也有人提。但看 OP 的描述,加载都已经分块了,到后面显示渲染还不够用,那这个 swap 就不是重新复制缓冲区那么简单,横竖还得改渲染算法在光栅化之前做文章。这就跟虚拟内存更没共同点了。
@learningman 你想少了。虚存是带地址翻译的,没硬件和系统支持下,首先得把访存的寻址都替换掉,原则上需要多出至少一倍指令。这就还是有类似 MPU 之类的硬件中断的情况,纯软件实现你得模拟缺页中断,基本就是把非交换访存全替换为模拟中断例程的函数调用。要实现这个基本得改编译器(从前端把*替换成 builtin 开始,只改后端还不够)。
直接 placement new 不能改善同时占用的问题。placement new 要求有已经分配好空间随时能用的指针,都没法用 fancy pointer (而且现在标准库的 allocator model 能分配的还要求在地址空间内连续)。
@BeyondBouds 你这什么屑产品经理还管那么多?要空间不够用负责帮用户加内存么?
@learningman 你清楚在说什么么。
在没有 MMU 或者没有系统特权的情况下实现虚存跟实现个没硬件加速的系统级虚拟机的工作差不多少。(虽然 iOS 不管 ISA 细节横竖都禁止加速了。)
2022-03-31 18:49:04 +08:00
回复了 w741069229 创建的主题 Java Java 项目该不该用 stream 流来编写代码?考虑 code viewer
@RobberPhex @dreamramon @loryyang @byte10

提到的一些通病比这里说的原始问题更有毛病得多。

栈作为活动记录的一种实现,本来就用于隐藏过程运行时状态的实现细节。只有直接能在程序中显式访问活动记录的语言(比如至少得有 first-class one-shot continuation ),这种东西才配被要求是和程序员交互的标配。
说白了,在抽象能力弱鸡的语言里没事依赖栈帧是一种习惯性纵容实现泄露抽象的病。
特别是要知道 Java 不光不支持 continuation capture ,甚至连 proper tail call 都没有……设计 JVM 的丈育还用 stack inspection 当挡箭牌,结果差不多被正面打脸: https://stackoverflow.com/a/5097402
退一步讲,真是想要照顾调试体验,又不是 C 这种滥依赖 ABI 兼容的历史包袱,这么多年了连个 shadow stack 都不会实现的弟弟怎么好意思变成工业主流的?

算了,还是先停止把 stack 叫做什么劳什子“堆栈”开始吧。

(反思为什么 NPE PTSD 以及 optional 实质套娃的问题就不提了,本质算不上 Java 特色,虽然这年头也快成了 Java 特供问题了。)
2022-03-31 18:23:15 +08:00
回复了 gantleman 创建的主题 游戏开发 MMO 万人同屏实验成功发布!
@paopjian 使劲儿时间膨胀完事……
2022-03-31 18:17:15 +08:00
回复了 godleon 创建的主题 程序员 Java 语言代码实现一个最优写法。
?现在 Java 普及了 Babel 类似物了么?不卡源语言版本的?
(要能用 transpiler 一般也是全体 JVM 语言,用不着特指 Java 。)
这类古董挺多了……
收藏夹里正好也有个,也是搜狐的,比 9L 的早:
http://news.sohu.com/01/18/news206991801.shtml
以前曾经经常引用(
@ryd994 “脱库的问题与是否进行客户端 hash 无关”,这显示出你的理解的偏差。
虽然不直接相关,但脱库得到的内容的使用方式可以类似,使用 hash 的动机也一致。
而这种敏感数据除了脱库还可以通过劫持客户端通信来获取(于是你说的对策反而不够用)。即便没像服务器被攻击那么瞩目;就受害者看,威力一点都不小。

对抗这种攻击,要做到攻击者本人通过唯密文攻击的方式无法分辨出敏感数据中可能带有的感兴趣的特征,至少不能一眼认出来。
至于是不是正经的加密,其实相对无关紧要,所以一个像样的 hash 都行。(当然,得别被随便能反查。)
若有这种客户端 hash ,攻击者要实现相同的效果,除非强行爆破 hash ,基本还需要多攻破客户端系统基础设施。
因为系统厂商普遍盯得比较紧,后者一般比单纯让 TLS 失效(各种意义上)难得多,或者至少没法长期利用。
使用非公开 hash 算法时,强行爆破成本很难预期。
首先,若攻击者无法获得程序取得其中的算法,这就无解。(当然,网站就弃疗好了,毕竟浏览器属于公共白嫖设施。)而想要通过攻击得到能分析的样本,也需攻破基础设施。
虽然要强行作为加密系统,这明显不符合 Kerckhoffs 原则而影响适用性,但是:
(1)说了用 hash 就强调不需要加密,虽然其实加密也能用,但拿来恶心攻击者这就杀鸡用牛刀了;
(2)让攻击者知难而退这种更普遍的方法论甚至就不算是密码学的原理;反倒是使安全性和加密信道的密码学强度正相关的实践,只是其中的一种特例罢了。
其次,即便有样本能逆向,非公开算法自动化手段相比查表之类可以说是极弱,光分析客户端行为就够普通攻击者喝一壶的了。
再退一步,能逆向成功甚至能直接看源码,之后怎么破还得密码分析,也根本没通解。

硬从理论角度讲,这里能保障的安全性的定义根本不同:系统的安全性不是以存在确定明文(以及加密和解密)作为前提来定义的密码系统的保密性(不论是信息论安全性还是计算安全性),而是使从信息中提取任何攻击者感兴趣的函数的计算开销的度量(若资源确定,也可以用成功概率)。
一些假设:(1)攻击成功前攻击者无法预先给出区分是否有兴趣(或度量利用价值)的算法;(2)(有兴趣的信息足够少)任意不依赖内容的选取子集符合兴趣的方法的概率现实地任意接近于 0 ;(3)人基于现实不可描述的、依赖个体对敏感信息特征识别的经验,有一定概率(使用未指定的未知算法)超越任意机器提取信息的能力,特别地,蕴含筛选出提高成功率的正确决策方法。
基于(1)和(2),任何现有机器在都不能分辨被 hash 隐藏的特征是否符合攻击者的兴趣(否则这机器得能自主定义什么叫兴趣判断什么值得继续爆破,基本就是强 AI 了);于是,结合(3),确定时间内,攻击的成功严格依赖于人。
那么 hash 的作用就是专门欺负人:消除特征,添加噪音,让人肉攻击者的经验失效,概率无限接近于 0 ,成功提取信息的代价任意地大,从而实现不可攻击。

是不是值得保障这种安全是另一回事,但这种安全性的现实存在是确定的。(并且很容易有木桶效应。)
@FrankHB 注:我不清楚 21L“包括了键盘序列加生日和手机号等常见密码组合”具体是指什么,但是要全覆盖,光是手机号(杠一点,其实还有国际区号)都有些难度,更不用说“特定前缀+手机号+特定后缀”的组合了。注意这些 pattern 是可以每个凭据都有变化的,没法大规模自动撞库。
@ryd994 要防止撞库的自动化攻击只要避免完全一样的口令即可。能反查的仅限全文匹配的没加盐的。
而且,规模受限;比如生日这个空间不够大够放表里,那么手机号呢?

另一方面,实践中用户可能使用的简单生成策略,比如把相对容易反查的数据和某个无法预测但是攻击者可以人工推断的前后缀串接,就能让反查失效。这个也算是盐,不过是加在了用户的脑子里罢了。
如果没 hash ,这仍然是一种明显的复用而会受到威胁;不巧的是,这种编码方式实际还真是挺顶用的,最起码对大多数人来讲比全随机串好记得多。

用户为什么要复用密码?因为实现成本低。这又是因为,密码这种形式,要求用户自己实现密钥的重现。
只要 UI 上需要用户日常记忆的密码(而不是你说的所谓“高安全的鉴权方式”)的情况普遍存在,“复用”基本就是刚需。但是想要高安全的鉴权方式替代,如何普及?多出来的成本你搞定?
所以说,问题的根源并非鉴权方式不够安全,而是欠缺鉴权的服务等级,无法落实对合适的路径使用合适的鉴权机制。对不重要的账户,就应该避免要求高成本的鉴权方式,而不是逼着用户平摊鉴权成本自己搭建可能对某几个关键路径不够安全的服务。
但不重要也只是相对而言,并不是说无所谓了。所以即便有智能卡的情形你能说 hash 没用,没智能卡就弃疗的思路显然是不对的。这种情况下,有没有多一层 hash ,安全性不可能一样。
特别地,考虑到这样做的主要理由正是应付直接推高用户记忆成本的被大量滥用的密钥策略,你要是想甩锅给用户这样就是安全习惯不好,是用户的错,此路更加不通。

而如果真要提高安全性,那么只有方案也是不够的。现有基础设施无法提供的安全机制的实现,服务方也应该一并提供——比如银行可以提供 USB key ,但不应该把设计甩给用户让用户自己造一个,造不出来就后果自负。
所以有没有 hash 不可忽视的情形下,hash 应该由服务方提供而非用户自己变通。

至于“hash 的结果成为了实质上的密码”,只要被截获的信息不能被反查出明显特征,这就不是用户需要关心的。服务器用哪个 hash 都不提高用户保障安全性的成本,这才是所谓的“一样”。因为成本原因,智能卡可以没有,这种“一样”反倒是优先该有的。
。。。对不起,看到“小公举”忍不住喷射早餐到屏幕上了。。
2022-03-29 08:49:52 +08:00
回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
这种东西,有确保执行力专家的就直接让专家起草,否则放 wiki 页面找个召集人让项目成员一起写,免得规范没讲清楚,style 上就先扯皮了。
负责代码层次上具体规范和往上提供工程支持明显是两码事,职责得分清。

主流大厂也不见得质量好哪去,说好听点是妥协,直说就是菜。

比如,Google C++ Style (官方叫 Guideline )这种几乎每一条都有槽点到跟 anti pattern 都没差多少的,如果看不出来问题,那就足够说明 C++不怎么熟悉,不能胜任一般意义的起草规范的工作。
其实我是觉得至少要能发现 GSL 的大部分缺点才算得上是规范管理专家的入门水平。Google 那种明显属于怂了不合格;具体点,如禁用异常,理由是不信大部分员工会用好……(这么基础的东西,啧啧)。

这种规范,有时候明文还不如事实标准慢慢磨( copyright notice 之类法务要求的另说)。

而要帮助提供工具,设计流程之类,自己怎么方便怎么发挥,就没这个限制。
2022-03-29 08:37:21 +08:00
回复了 cpf 创建的主题 程序员 求一份软考中级软件设计师的备考资料
。。。软考中级基本就是氵本科没毕业大都混过的水平,也没什么很超越通识的题,随便百度之类的花一小时摸清楚大概范围就差不多了。而且出题的水平就是菜,我当年笔试做完题为了避免太快交卷还把题重新过了几遍数(腹)落(诽)出题人显示在题干的技术错误来磨时间。
还是说这几年难度突然增加了……?
另外中级跟高级其实没啥可比性,后者要写作文,有点考公的味儿。
@ryd994 你的分析有个明显的缺陷:完全假定对凭据的攻击是机器进行的。然而攻击的原理并不一定是密码学,至少还可能是社会工程学。这包括人可读而机器不可读的口令——一个常见的应用是,根据“密码”中包含的 pattern 猜测用户设置口令的偏好(比如是否包含某种明显像是生日之类的个人可识别信息),缩小相关的其它需要碰撞的敏感信息的解空间,显著优化攻击效率。而一旦经过任何一个常规的 hash ,甚至不需要 salt ,这种 pattern 就被完全破坏,也就直接报销了一个重要的攻击向量。
2022-03-28 16:00:46 +08:00
回复了 yongchiu 创建的主题 程序员 写 C++代码有感
@LotusChuan 这是公共空间的讨论。回复框边“请尽量……能够对 [别人] 有帮助”未必要包含你。重复强调对“你”没意义,才对谁更没意义。但为了让你能认识到,这个回复我先假定当作有意义。

我自忖我前面的回复全是展开的技术话题,倒是你的回复里都有断片得都出戏而莫名其妙的。所谓“拿去写自己的博客会好一点”,言下之意,个人观点不该在这发……那 OP 发这主题算啥?现在又来个“答非所问”,“问”是什么? OP 的题是“有感”,压根没问。这里就没人在问。所谓的“答”就是对回复的观点评价,是主题讨论的间接展开,也没你的评论更跑题。“不信的话……多少人回你呢”就更奇葩了,照这逻辑,你第一个提到 K&R 的回复要不是我回还就没意义了?

奉劝停止狡辩;为减少跑题影响,压缩对你多得离谱的理解偏差和显摆不理解的回复,还是得费劲。
2022-03-28 15:18:12 +08:00
回复了 yongchiu 创建的主题 程序员 写 C++代码有感
@LotusChuan 你确实没理解。
这表达的主要就是嘲讽类似“很个人的事情”这样的观点。
作为常识,统一这类风格的项目规范不一定是所谓“很个人的事情”;虽然姑且你也知道需要“方便沟通服务”,但后来强调“我自己写”那就又矛盾了。
说直接点,你要真局限讨论给你自己写的,那的确是所谓很个人的事情,我没兴趣评价。但实际呢?
(顺便,我倒是不反对使用不同的缩进宽度,这是很 local 的问题;一级缩进是个整体,强调一定该“等于”几个空格,反倒显得没分清一个常识:缩进是缩进,对齐是对齐,两者天然不保证可以互换。)

针锋相对地,制造误导和散布谣言(指鼓吹未经查实的所谓的优点以及仅凭个人习惯否认存在适用性差异这两方面)是公共领域问题。
之后就是通过指出对其它语言的设计的劣化来点明在这里不求甚解以个人问题为借口逃避的一些危害罢了。
我不觉得这种入门级的语用常识有单独成篇的必要,所以就是顺便一踩。有谁跳起来了我不关心;不过强行拒绝理解的话,我只能表示遗憾。

clang format 真不太够用,不过和这里无关(软硬回车和按语义换行的问题也没办法指望)。
我觉得你这里强调没理解和认为没意义的强辩确实是单方面浪费你的时间;至于我的时间,不劳您费心,况且让我多补充几段说明,客观上也有利于阐明我先前的观点。
2022-03-27 17:22:03 +08:00
回复了 BlackZhu 创建的主题 程序员 为什么 spring 源码中类的关系那么复杂?
@thinkershare 显然有,比如抽象太多并且泄露出来被用户发现了的这种 OP 问题。
1 ... 17  18  19  20  21  22  23  24  25  26 ... 92  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1706 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 64ms · UTC 16:40 · PVG 00:40 · LAX 09:40 · JFK 12:40
Developed with CodeLauncher
♥ Do have faith in what you're doing.