FrankHB 最近的时间轴更新
↓挽……
229 天前
FrankHB's repos on GitHub
C++ · 18 人关注
CppTemplateTutorial
中文的C++ Template的教学指南。与知名书籍C++ Templates不同,该系列教程将C++ Templates作为一门图灵完备的语言来讲授,以求帮助读者对Meta-Programming融会贯通。(正在施工中)
C++ · 4 人关注
nano-signal-slot
Pure C++11 Signals and Slots
3 人关注
Crash-Course-Computer-Science-Chinese
:computer: 计算机速成课 | Crash Course 字幕组 (全40集 2018-5-1 精校完成)
C++ · 2 人关注
NPLC
NPL console (main test repository for NPLA1 implementation of YSLib)
TeX · 1 人关注
draft
C++ standards drafts
JavaScript · 0 人关注
.github
The github tools
C++ · 0 人关注
Baka-MPlayer
The libmpv based media player
C++ · 0 人关注
Basilisk
The Basilisk web browser
0 人关注
co
An elegant and efficient C++ basic library for Linux, Windows and Mac.
C++ · 0 人关注
ConEmu
Customizable Windows terminal with tabs, splits, quake-style, hotkeys and more
C++ · 0 人关注
Corecat
Corecat: Core of The Cats Project
C++ · 0 人关注
CxxFunctionBenchmark
benchmark for various C++ function implementations
Python · 0 人关注
english-please
Offer for repositories whose README are written in Chinese.
C++ · 0 人关注
fancy2d
0 人关注
feel
An open source cross-platform programming language focused on efficiency.
C++ · 0 人关注
function2
Improved and configurable drop-in replacement to std::function that supports move only types, multiple overloads and more
0 人关注
google-group-docs
Public text for Google groups discussion
HTML · 0 人关注
itoa-benchmark
C++ integer-to-string conversion benchmark
C · 0 人关注
LCUI
A simple graphical interface library
C · 0 人关注
libfat
FAT library for GBA, DS, Gamecube & Wii
C · 0 人关注
libnds
C library for Nintendo DS
C · 0 人关注
llmd
如果将markdown视作一门编程语言可以做哪些有趣的事情?
0 人关注
mdBook
Create book from markdown files. Like Gitbook but implemented in Rust
C++ · 0 人关注
MdCharm
MdCharm Source Code
C++ · 0 人关注
mingw-std-threads
Standard threads implementation currently still missing on MinGW GCC on Windows
C++ · 0 人关注
minicodecvt
C++上的简单编解码实现
C++ · 0 人关注
modern-cpp-tutorial
📚 C++11/14/17 On the Fly
C · 0 人关注
newlib
C++ · 0 人关注
nix
Nix, the purely functional package manager
C · 0 人关注
opensgx
OpenSGX
FrankHB

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
FrankHB 最近回复了
19 小时 0 分钟前
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
既然可读性有没有所谓都会成问题,再提个更一般的现象好了。

其实平心而论,只有 py 式缩进实际并不会浪费我多少阅读源代码的时间,毕竟就算真的要做 semantic transformation 也完全是 one-pass 的,比 Lisp 宏都省事多了(不过 Lisp 宏我真不用傻乎乎去这么理解)。
关键问题是,隐含一个前提:我得假定我看的代码(至少在语法上)是对的。
尽管搞错缩进实在是很低级的问题,以至于这个假设绝大部分时候并不会被违反,存在这个假设本身就令我相当不爽。并且这种罕见性的低效用直接导致了不爽的升级。
——因为为了一个实际罕见的低级错误分支,我不得不在脑子里准备 fallback path ,继续跟 cache locality 过不去。
( Haskell 也有类似的问题,而且因为对一些上下文混用空白符的检查的缺乏,后果更严重,却反而导致了罕见性的弱化,某种意义上反而没那么恶心了——看,你学了这么多旮旯,也不是用不上嘛。而这类严重后果在 Python ,或者至少是鼓吹了 PEP-8 以后的 Python 中,并不那么显见。)

类似的强迫劣化人脑中语言实现的问题其实很普遍,不是 py 专利。
比如说 C 的声明符语法就被我认为是垃圾设计,除了人和机器的正确实现都麻烦而实际技术好处基本就是省纸这么个可笑的投入产出比(也是低效用的实例)外,它还暗示读者除了理解正确的语法规则,最好需要掌握次等的小聪明——所谓“右左法则”——才能去跟那些学得不到家(不知道正经的声明的形式语法)的 C 用户。这让交流更加困难不说,还嘲讽了正经学习语言规则的用户是傻子。
这里有个类似的罕见性技术细节:所谓右左法则其实绝大多数情况下是形式上正确的,能得到正确的分析结果。但是它依赖读者事先知道什么标识符未被声明,这是一个全局(至少一个翻译单元)的语义性质。于是为了保证正确,我不得不准备两套思路,脑补实现比编译器更复杂的算法——以便回溯出错误时,能和那些不懂形式语法的半吊子用户沟通。而编译器根本不需要鸟这套,照着正式的文法产生式直接实现 parser 就能几乎完全处理所有情况。(几乎是指 C 的文法设计上下文相关的例外,这是另外的糟粕。)
如果抛开罕见性,那么所谓的右左法则和谭浩强之流其实本质没什么区别,都是应当纯粹被鄙视的:鼓励放着正经规则不学,非得去做二道贩子,然后粉饰虚假的“简单”诱骗更多 noob 上当,搞烂整个用户群体。

Py 在这里有点不同就在于形式上由设计者背书,所以不会导致 py 意义上的技术错误。
但是当大量用户依赖 py 入门正经编程甚至理论计算机科学基础的时候,用户会不自觉地试图把 py 的局限性迁移到其它语言上照猫画虎,结果污染的远不只是 py 用户这个群体。
这个客观现象导致我即便无所谓 py 的设计和个别人的口味,也不得不面对这些不论是有意还是无意强迫我把智商下限拉低才配和他们交流的敌人了。
(虽然其实这里有资格到我需要特地婊的大约只有 MIT 的 6.01 。GvR 这种连个 PTC 都要 feel educated 的实在不配。)
19 小时 28 分钟前
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
@KENNHI 复制的最后一段就是怼借口有 IDE 拉屎恶心读者的。何必凑上来对号入座呢?真要 write-only 舒服怎么不 Perl ?连 IDE 都无关紧要了。
(虽然 py 的 IDE 其实历来不怎么样,不过这里是次要的。)
1 天前
回复了 ACMCoder 创建的主题 Python Python 之父谈缩进和大括号
复制粘贴一遍回复:

除非你只用一个空格,缩进用空格就是逻辑上扯蛋的,总是无法避免在源文件编码层次上允许光标卡进缩进内部出现“半个缩进”的破坏不变量奇葩状态,跟 malloc 到处乱飞找不到 free 的破烂代码本质上是同种的可恶。顺带还没事 bloat 一下源代码。
虽然(水平)制表符在语义上也不那么适合缩进,但至少没这种低级问题,在许多语言的基本字符集内也没别的得选的。于是高下立判。
注意在根本上,前缀空格干的活是对齐。虽然缩进可以提示对齐,插入缩进跟缩进的理由逻辑上完全是两码事。
至于可读性,py 式缩进直接干掉了 free form 语法允许具有的上下文无关性,分析这坨玩意儿现实就没法只是 parser 的事(想用 parser 做对会极其扭曲),基本只能加语义预处理,又是个不适合机器又不适合熟练的人类阅读者的奇葩设计,纯属没事找事的自以为是了。另一方面,无法局部调整缩进导致传统纸质书那样的分页排版在换页处的可读性极其看脸,一不小心跨页就得数缩进,怎么看都比用括号直接从视觉上显式辅助定位恶心得多。
相对来说,写起来可能还能用 IDE 和结构化编辑器(现在还基本是空气)解决,没读起来那么严重。但是要把这个混淆成可读性,心智多少有些问题。

@youdoit yaml 的垃圾程度比缩进大得多。
@rozbo 共存?试试 Haskell ?
在你显然对被迫记忆上下文相关的缩进的语义(虽然技术上被钦定为语法)没什么经验的时候,姑且还是给你一些反悔的机会吧。
@jones2000 把立法选举之类的忽悠上网,看谁来断。来就恐怖分子呗。
当然,可以白名单嘛……
@netabare 把被公认怀疑成中心的夹了就是。(什么陶片放逐……
中本聪润物细无声,直接搞得没人能有效栽赃他是骗子。头部矿场和交易所要能老实自裁的话也没类似的问题了。对不老实配合的,自然需要外力代替。只是很遗憾,这方面机制一直很弱。
但是这跟现在瞎放水的哪个更没下限,还真不那么好说,因为·对两种头部玩家的道德上的要求本来就是不同的·。
结果还有意义的就剩谁来夹谁的问题了。
@Danswerme 理论上不过是鼓吹信用就是生产力的一种表现罢了。
现在更直接的问题是你以为能叫生产力的大部分东西都过剩了,而纠正资源错配的机制严重不足。所以这对理性人来说自然是个好的投机方向。
提高生产力?你咋不说改进分配呢……莫得前途。
@wanmyj “已经没什么需求做不到了”……什么学姐台词。
敢加上支持 cvs/svn/hg/bzr/fossil...么。还有 hg-git 之类的。
要是光说原生,实际上那么多个插件之类的我都没发现打得过乌龟 hg 的。( SourceTree 勉勉强强。)
再光说 git ,支持干净 git replace 了吗?然后 git filter-repo ?
……其实吧,git bash 的部署方式就经常是个槽点,我要不想 bash 呢?或者我 Windows 上想要 MSYS2 ucrt64 又不想 bloat 呢?
@JohnBull 这哪来的设计初衷?又哪看出了 OP 要的是配置文件的功能?
照你的说法是不是 Windows 系统属性里设置环境变量的界面也是违反初衷,该改用配置文件?
(要是非得把注册表当配置文件,行吧,当我没说。)
@opentrade 写文档不是文化,而是工程师的本职工作。文档是标准化工程流程的主要接口和交付物之一,不管这个文档会不会交付到客户手上。
至于实现产品的反而不需要是工程师,甚至未必是人——比如 copilot 都能凑数。
第二篇文章中“密码管理器存储主密码”是个词不达意的错误翻译。
原文相关段落:
Some applications stored the entered master password in plaintext or implemented hard-coded crypto keys in the program code. Consequently, attackers can easily circumvent the crypto algorithm altogether and thereby gain access to all of the user’s data.
很显然如何存储和访问都有更明确的限定。

不过,TeamSIK 的这个说法也是有问题的。
现实中最显著不安全因素来自用户对系统错误的安全假设,而替用户定义什么叫 security 是造成这个现象的原因之一。
具体来说,原文中隐含假定理想的密码管理器总是应当且能够保证不泄漏敏感信息,给用户以错觉认为密码管理器能提供保密保证,然而这就是体系上的重要潜在漏洞——仅仅是方便方案提供者甩锅而无助于实际确保安全性。另一个更常见的可比的例子是鉴权者无原则要求强口令的密钥策略,导致不少用户倾向于以不安全的方式另行储存密码,凭空增加攻击侧信道,反而引起更大的风险(讽刺的是,密码管理器在一定程度上就是为了应对这种问题而被发明的)。

安全系统想要达到的一个主要根本目标是:让理解安全的用户得到预期的安全属性。获取用户数据并不总破坏这种属性,例如考虑用户可以极低成本地有意投毒而愚弄攻击者。
当然,极端的安全系统玩家可以不在乎这种密码管理器的限制问题(若有,也可以自己实现密码管理器,这至少发明现实可靠的加密算法容易得多)。而对大多数密码管理器的用户,他们仅仅需要一种把密钥视为最需要避免泄密的数据而容易访问的方案。但这个意义上,如何存储主密码也不是什么大不了的问题了——尽管用明文、硬编码加密的代码和真正的密码(cipher)具有密码学强度上的显著不同,攻击者一旦获知主密码就可以访问所有敏感数据的这点不会有差异——注意主密码可以被密码管理器“存储”阶段前截获。要修补这里的缺陷,需要用 2FA 等方式代替单一的固定口令。不过,这又增加了使用的困难,削弱易用性和灵活性,而在另一方面同样可能增加前述的风险。
作为实用解决方案,密码管理器应当把容易做的事情做好,而不是妄图面面俱到。这个意义下,花费较小的代价而明确减少显著的风险的设计是“好”的——包括避免使用明文存储主密码。但是,鉴于密码管理器不是入侵检测系统也不需要实现访问权限控制,它的“管理”行为并没有在字面上必须提供对主密码的反泄密存储保护(作为和用户的接口约定),即便退到这个地步,不合理的主密码存储方案仍然是个实现质量(QoI) 问题,而不是所谓的 security vulnerability 。真正的漏洞直至用户错误地信任密码管理器会提供这种保密才会形成——尽管这种错误信任非常普遍,远甚于这里强调的对开源密码管理器的无原则的信任。

另一个更现实的例子是 Chrome 通过明文保存密码: https://www.v2ex.com/t/872745 。这里,Chrome 的实现也不算是严格的安全漏洞,因为一个应用程序假定一个多用户宿主系统提供正确实现的访问控制是合理的,对文件系统的访问控制的正确实现是宿主系统的职责,正确利用系统提供的访问控制排除非预期访问是用户的职责,两者都不是 Chrome 需要关心的本职工作,所以 Chrome 的维护者的确有理由拒绝承认这是功能缺陷。但是,无论是宿主实现的安全性不可保证(乃至不可审计),还是用户普遍缺乏安全意识的现实,都使不确定的攻击更容易实现,因此这里的 QoI 问题相比 Firefox 等替代,无疑是足够显著的了。
23 天前
回复了 jsun969 创建的主题 程序员 看看程序员鱼皮的嘴脸
@FrankHB 好吧没发现链接能点进去空间……
23 天前
回复了 jsun969 创建的主题 程序员 看看程序员鱼皮的嘴脸
这谁啊很有名么……
挂一个混睿站的你好歹上个 UID 吧,否则 6 硬币又是一条好汉……
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3945 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 01:20 · PVG 09:20 · LAX 17:20 · JFK 20:20
Developed with CodeLauncher
♥ Do have faith in what you're doing.