• 哇,被光速嘲讽

  • 某些民营宽带供应商,为了降低与电信或联通等主干通讯的开销,可能会缓存一些静态资源。像长城宽带有一套非常复杂的缓存机制,但有时依然会误判缓存上了不该缓存的东西,很多后端开发都有过大受其害的经历吧。

  • 招募项目合伙人 at 2017年07月21日

    我觉得想怎么说都无所谓,只是能不能说服别人的问题。但一旦落到人身攻击了,就不好了。

  • 如何读文档? at 2017年07月19日
  • 如何读文档? at 2017年07月17日

    Spring 新的大版本更新我也是晕了,彻底写出了一种 Spark 的感觉

  • 如何读文档? at 2017年07月17日

    这就产生了一个很大的问题,为什么会产生那种只会 Rails CRUD 的熟练工,或者在 Java Spring 甚至连 PHP 上我们也有很多这样的程序员。Web 框架,特别是已经做好了 MVC 抽象的 Web 框架是一个巨大的黑盒,作者做得那么复杂是积累了大量的经验和想法,背后的实现非常复杂,光靠熟练是很难了解其根本的。这就是在 Getting Started 之后需要了解一个框架的大局,再去通过项目去熟练,去具体了解其细节的原因。

  • 如何读文档? at 2017年07月16日

    其实单从功能上来说 ActiveSupport 的 try 好像还是 &. 的超集。但这件事情就很奇怪,就好像一些人认为面向对象和面向接口甚至和函数式编程都可以是等价的,从数理上如此,但并不代表对人的感知上是如此的。所以 Ruby 放着一个已有的超集去实现一个子集,这其实就是 Ruby 平衡性的一个考量了。

  • 如何读文档? at 2017年07月16日

    我只是说类似啦。。。并不是说完全一样。try 还有一些奇怪的用法比如 Array#try(:[], key) 之类的。

  • 如何读文档? at 2017年07月16日

    我记错了,确实是 ActiveSupport 提供的。不过其实自己通过元编程也可以实现一个类似的。

  • Challenge 1 就是个 DP,Challenge 2 就是个 AC 自动机。而且这题目没有绕弯,基本上都是算法课涉及这两个算法最经典的例题了吧。。。

  • challenge #1 - #6 update 06/03 at 2017年07月08日

    对于 challenge 6 的 easy 来说,其实也挺不 easy 的。由于题目要求精确到小数点后 30 位,基本超出了浮点数的精确范围。如果不考虑这点的话,可能无论什么方法都很难做对。

    为了正确做对这道题,你需要定义一个自己的数据结构能够处理更多位的小数,比较方便的是定义成定点数,理论上定义个 100 位,做一个 30 位精确的题目应该是足够了。然后你需要实现这个数字的加减乘除运算。一旦这点做好,就有很多方法可以做对,无论是割圆法还是蒙特卡洛迭代,或者定义一个大正方形然后遍历每个点,应该都能算对。

    如果要收敛得比较快,那么比较常用的是梅钦公式。不过梅钦公式中有个 arctan,这对于才实现了加减乘除的自定义数据结构来说很不方便。但可以用泰勒级数展开这个 arctan,从而把问题转换成一个迭代问题 。现代常用的计算圆周率的方法一般都是梅钦公式的改进,称为梅钦类公式。

    除了这些方法以外,另一个难点是,如何证明自己的程序已经收敛到前 30 位完全正确了。证明自己是对的这一点也挺有意思,特别是我们假设 30 位的圆周率还没有被人类算出来,我们需要自行证明自己是对的,而不是拿一个正确答案来比较。这一点对于梅钦公式来说比较容易,对于蒙特卡洛方法来说则很难。

  • challenge #1 - #6 update 06/03 at 2017年07月08日

    用 eval 相当于没写。。。背后的字符串解析完全没有碰到,而且还会遇到注入的问题,在非动态语言上也运行不起来。

    关于 nim game 的定义建议看英文的维基百科,中文的没有翻译完整。

    尼姆游戏开始前就需要知道每个堆的数量 nx。有一个特殊的变形,尼姆堆只有一个堆的时候,通常还需要限制最多能取 m 个子。这个变形是最好证明的,我可以给一个例子,当 n0 = 30,而 m = 4 的时候,后手必胜。因为 n0 是 5 的整倍数,当先手每次取 x 的时候,后手取 (5-x) 个。那么最后这个堆一定只剩下 5 个子,且是先手行动,这时候无论先手拿几个子,后手都可以把剩下的子全拿完。关于一个堆的所有数量都可以被很容易地证明。结论是 n0 是 (m+1) 的整倍数时,后手必胜,反之,先手必胜。你可以试一下。

    关于多个堆比较麻烦一些,用逻辑异或处理一下即可。英文维基百科给出了完整的证明。你看中文维基也写了 Nim Game 是一个无偏博弈。无偏博弈的特点之一就是完全信息博弈,双方都能完全看到局势,不可能存在「不会知道堆中含棋子的个数」的问题。

  • 量产型炮灰工程师 at 2017年07月07日

    elsif i % 15 == 0 puts 'FizzBuzz'不会执行 是因为 15 的余数已经被 3 的余数处理过了啊。。。怎么可能是因为 Ruby 不支持这么多分支。。。你用什么语言写都一样啊。。。

    • Debian 9
    • KDE Plasma
    • KWin
    • 物理机

    邪教徒😂

  • 第一次你说,用一样的 Cipher 就代表安全性一样。我帮你 fix 了一轮。

    第二次你又改说,都用了 OpenSSL,所以就安全性一样。我再来帮你 fix 一下吧。

    我两句概括,我不得不说,是典型的倾向性误导。

    我无论在 3# 还是 13#,我都没有说过「Cipher 就代表安全性一样」。

    我在 3# 的中我在比较 PPTP 本身的安全性问题和 Shadowsocks 出现过的安全性问题的严重程度,还没有来得及提及 Cipher。

    我在 13# 的回复中提到 Cipher 的部分,提及的是 Shadowsocks 在加密过程中与 IKEv2 选用的 Cipher 都是较新的选项。同时我也提及了,Shadowsocks 和 IKEv2 在验证上使用了不同的方式,丝毫没有说过「Cipher 就代表安全性一样」。

    我在 35# 的回复中,也没有说过「用了 OpenSSL,所以就安全性一样」这样的观点

    我整段提到 OpenSSL 的一共只有两处

    像 OpenSSL 之前 Heartbleed bug 缓冲区过读,这是实现的问题。无论是使用 IKEv2 也好还是使用 Shadowsocks 也好,只要调用了 OpenSSL 受影响的版本都会触发这样的问题。这不能用来比较说同一个 Cipher 在建立连接后双方是否存在安全性问题。

    还有

    如果确实是 Cipher 本身的问题,在实现上大多操作系统同样在调用 OpenSSL 的 Cipher 实现,并没有本质上的区别。

    我指的是大家都是在调用 OpenSSL 本身 Cipher 的实现,如果由于 OpenSSL 的 Cipher 的实现有问题,那么无论是什么协议,只要基于 OpenSSL 的实现,就有问题。

    我说的是:「如果 A 有问题,那么 B 一定有问题」,这和你概括的所谓「如果用了 A,那么 B 就一样」是一个观点。安全是木桶效应,只要有一处有问题,那就是有问题;一处没问题,不代表全没问题。

    后续你的回复,已经开始玩纯粹的文字游戏了,一会儿拿协议和实现工具对比,一会儿拿 Cipher 和协议对比,因为如果是协议对协议,工具对工具,Cipher 对 Cipher,你想拔高的协议就一项都没优势了。

    我从头到尾都是拿 Shadowsocks 与 IKEv2 和 PPTP 作比较,他们不是协议吗?

    我拿 Shadowsocks 使用的 Cipher 和 IKEv2 使用的 Cipher 作比较,他们不是 Cipher 吗?

    我拿 PPTP 的安全性问题和 Shadowsocks 的安全性问题作比较,他们不是来安全性问题的严重性的吗?难道我指出的 PPTP 的安全性问题在握手过程中可以 MITM 上,而 Shadowsocks 的安全性问题落在 MtE 和 E&M 导致可嗅探,是为了对比这两者吗?

    相反,你每段中粗体的概括,每次都和我之前的回复中的观点完全都是不一致的,将内容以偏概全、断章取义的,我倒是想知道是谁在玩文字游戏。

    PPTP 作为一个 1997 年诞生的协议,在全球的眼睛盯着下,诞生15年后,其 MS-CHAP-v2 方式在2012年才发现可行的攻击方式。而且需要23小时才能攻击成功一个 Key。

    Shadowsocks 作为一个 2013 年诞生的协议,只在中国特定人群关注下,3 年内发现多个攻击方式和安全问题。

    按这个说法 IKEv2 本身也是一个演进协议,要是算上它爸爸 IKE,先后都改过 8 稿了。如果光说 IKEv2 这一代,2005 年 RFC 4306 标准被定义后,2008 年就爆出针对 IKEv2 first packet 的攻击的方案,从而实现嗅探。随后 IKEv2 就进行了标准的更新。难道 3 年内被发现安全问题就可以认为一个演进中的协议之后不安全吗?相反只要演进过程修复掉这样的问题,那么它又再是安全的了。怕的只有 PPTP 这种 2001 年后补充了一个 MPPE 后就再也不演进的协议。

  • 1. 你认为用相同 Cipher 就有相同的安全性。

    我的观点是使用相同的 Cipher 一旦建立起加密后,他们的安全性是一致的。这一个观点是面向楼主质疑加密本身安全性的问题。

    事实上确实是这样,我们可以认为如果说交换 Key 的过程存在漏洞,比如 SSL 3.0 的漏洞就是这样的问题。对于这样的问题,如果用木桶效应来解释,这已经是超过协议本身范围的东西了。像 OpenSSL 之前 Heartbleed bug 缓冲区过读,这是实现的问题。无论是使用 IKEv2 也好还是使用 Shadowsocks 也好,只要调用了 OpenSSL 受影响的版本都会触发这样的问题。这不能用来比较说同一个 Cipher 在建立连接后双方是否存在安全性问题。

    如果这个可以被当成问题,那么再比如 Windows XP 的 System API 中提供的伪随机数发生器也有一个漏洞,这使得无论你用哪种方法生成出来的 key 都存在问题,那么这样的问题不能看作是协议本身的问题,这也就是你所说的木桶效应。如果说我们讨论加密的安全性,那么交换密钥的部分应该额外讨论。他们任何一部分的问题确实都会影响安全性,但并非是 Cipher 本身的问题。如果确实是 Cipher 本身的问题,在实现上大多操作系统同样在调用 OpenSSL 的 Cipher 实现,并没有本质上的区别。

    2. 你说 StrongSwan 文档中,有数个加密方式被标记被 broken,所以使用 IKEv2 不安全。

    我的观点并非是 IKEv2 本身不安全,我指的是 IKEv2 本身的 Cipher 是可选可配置的,有一些 Cipher 是不安全的,所以已经很少使用了。这件事上也是和 Shadowsocks 一致的。大多数的操作系统内置的实现,也都已经禁用掉了这些不安全的算法。Shadowsocks 目前安装后也不会默认选择这些有问题的加密方式。

    和 StrongSwan 一样,大多数可选 Cipher 的加密实现中都实现了一些有问题的算法,大多都是出于向下兼容的目的。一旦由于向下兼容遇到这些算法,那么其安全性确实是需要质疑。像 3DES 和 Blowfish 在过去的一两年内,破解方案都有了极大的飞跃。从同样的木桶效应来看,哪怕是 IKEv2,如果使用了不当的 Cipher 本身也是不安全的。从这一点上,我并不是批判 IKEv2。而是相反,我认为这不是 IKEv2 本身的问题,就像你不能把用 rc4-md5 造成的安全问题归咎到 Shadowsocks 本身的问题上。

    3. 你说 Cipher 一样,所以 Shadowsocks 和 IKEv2 的加密流一模一样。

    只要不是 CFB 类似的模式,你没办法重放出两个一模一样的加密流还能通过校验,如果能,这协议一定是垃圾。

    我觉得你可能想说的是 ECB 而不是 CFB。当然如果你把校验的部分、IV 和 Key 都认为是加密流的一部分,那么我同意他们的加密流不一样。

    补充

    所以就我的观点,如果我们把问题落在单纯的加密上,事实上目前正在使用的各种协议的主流实现都是在基于 OpenSSL 的 Cipher 之上。一般出现的安全性问题确实都会落在生成 IV 和 Key 的方式、交换 Key 的方式、验证的方式之上。在这些问题上,目前也缺乏可靠的攻击来面对无论说 Shadowsocks 也好还是 IKEv2 也好。

    我们可以认为 PPTP 是一个 1 米 4 的个子,是因为我们已经摸到了它的天花板。我们无法评价 Shadowsocks 或者 IKEv2 的个子,因为我们连它们的天花板都没有摸到。虽然 IKEv2 的安全设计环环相扣,我们也确实目前找不到可靠有效的攻击。但这对于目前 Shadowsocks 的情况也是一样的。如果我们翻旧账的话,那么 Shadowsocks 在去年变过过 1 米 6 过,因为可以通过对 CFB 的嗅探得知这是一个 Shadowsocks,但是无法对它进行有效的 MITM 攻击。当然我们可以直接墙掉它,这至少比 PPTP 的 MITM 安全,它无法被得知你的通讯内容。但 Shadowsocks 协议仍然持续演进,这不像 PPTP 之类成为 RFC 后修改变得非常困难。经过这次 AEAD 的升级之后,我们再一次摸不到它的天花板了,换句话说,也就是暂时找不到有效的攻击。

    Shadowsocks 的协议设计确实比 IKEv2 简单太多,但正如你所说的:

    安全是木桶效应

    并不会因为协议设计的复杂了,它就一定安全。如果我们要找到一个协议设计的安全问题,并不是通过另一个更复杂的协议来说明,而是通过找到对这个协议的有效攻击来说明的。而对于 Shadowsocks 来说,它还有一些比较魔幻的功能,比如通过自定义插件来二次封装发包,从而增加流量识别的成本之类,这些功能比起 VPN 更专注于做安全的虚拟内网来说也更有显示意义。

  • 关于嗅探上的漏洞,Shadowsocks repo 中被讨论过多次。有关于OTA的,有关于 AEAD 的。这些都是官方讨论之后修复了的问题,我不知道你是从哪得出的 你跟我说 SS 的缺陷是嗅探?,但这些问题确实是存在的,而且直到最近几个月才刚被修复。 至于所谓 SS 在加密方面没有缺陷,也跟 SS 作者说得相反 Shadowsocks 一旦建立握手使用的加密 Cipher,官方目前默认推荐的 chacha20-ietf-poly1305AES-256-GCM 是 OpenSSL 的一部分,尚没有任何 vulnerability 出现。你说的 跟 SS 作者说得相反 建议你找到相关的 Issue。

    至于 IKEv2,根据 RFC4306 定义的标准,其实是一个密钥交换协议,至于传输过程,使用的 Cipher 也是可选的,见 StrongSwan 文档(云梯就是基于这个进行搭建的),你可以看到里面已经有数个加密方式别标记了 broken,也就是因安全性问题而不再被推荐。实际上常用的加密协议还是 chacha20poly1305aes256gcm128 ,这两个都是 Shadowsocks 支持的加密 Cipher,和 Shadowsocks 的加密流一模一样。他们的主要区别在于 IKEv2 使用了 X.509 作为安全认证。而 Shadowsocks 使用长密钥作为安全认证。

    密码学是个严肃的数学问题,不是靠我说它有缺陷或者我说它很安全它就安全了。

  • 100% 是把一个核心吃满还是把所有核心吃满了?如果是后者那肯定是 handle_thread 方法里线程相关的问题了。如果是前者我读了一圈觉得有几个可能出现死循环问题的地方,但这脚本不太方便部署调试。

  • 量产型炮灰工程师 at 2017年06月27日

    你怎么解决用人单位的要求和普通本科毕业生之间的最后一公里 这不是你口口声声 进高校说这个估计你会被群殴 的高校教育的问题吗?自学你想学理论学理论,想碰工程碰工程,根本没人拦着你。

    知道为啥ruby在国内发展的没有php火吗,就是这样的贵族思维在作怪 本来就是 Ruby 没有 PHP 好学啊。那全世界范围内 Ruby 都没 PHP 火啊,所以全世界 Ruby 工程师都是贵族思维;那 Haskell 也没 PHP 火啊,所以 Haskell 工程师也是贵族思维了?显然不是啊。一个语言的流行程度,要考虑到自身的奋斗,也要考虑到历史的进程,考虑到其设计目的和适合的场景。

    Ruby 社区从各种角度上来说都是新手友好的。达○、北○○鸟那样的机构去培训 Java、Objective-C、PHP 搞定招和校企合作,使中国 PHP 工程师的数量确实是 Ruby 的数倍甚至数十倍。这是因为 PHP 社区没有贵族思维产生的吗?如果是的话,那 Python 现在市场占有率越来越高已经超过 PHP 好几个百分点了,怎么这些培训机构还是在执着于 PHP 呢?

    这是由于 PHP 语言比起 Python 也好 Ruby 也好更容易教学,成为了这些培训班的选择。Ruby 这门语言根本就不会被这些市场选择到,它缺乏这种可以量产的基数,所以要有才会有那种全○培训营这种打着高端旗号收智商税的东西出来。

    但反过来问,数倍数十倍于 Ruby 的工程师,但国内的 PHP 社区贡献者的数量呢?国内绝大多数的 PHP 开发者与 PHP 社区本身完全是极大隔离的。这到底对 PHP 发展是好事还是坏事,这里多少 PHP 工程师是只能做重复劳动性的外包业务工作的,多少人是技术主管口中「天天做负功」的人?

    这些问题的原因怎么扯也扯不上什么「贵族思维」吧。

  • 量产型炮灰工程师 at 2017年06月27日

    没有懂 有经验的人自学 有什么冲突的地方,自学又不是闭门造车。我也不懂 压根儿不信明白吗你这想法太主观了 这两点哪个想法更主观。进高校说这个估计你会被群殴,只要不去武术学校,应该讲这个都没有什么问题。😩

  • 加密的 PPTP 至少比 SS 安全

    没有明白这个结论是怎么的出来的,PPTP 握手时候的 MS-CHAPv2 的破解复杂度已经降低到破解一个 DES 56-bit key 的难度了。几秒钟就干掉了。握手阶段就可以利用这个漏洞实现 MITM Attack,从而监听到通讯的全部内容。

    而 SS 的安全性问题主要集中在「嗅探」上,也就是所谓通过畸形包探查这是不是一个 Shadowsocks 服务器,至少整个流加密过程是不会被监听的。最早被发现的问题是,由于使用了流加密,可以暴力尝试握手包后的一个字节,如果服务器在 2^8 次尝试中有一到三次没有主动关闭链接就可以证明是 Shadowsocks 服务器。然而这样也并不能监听到内容。之后提出了一个 OTA 的防御,但 OTA 协议本身 Length 上也有缺陷,并没有解决问题,最近新版本则是引入了 AEAD,从原理上避免了 MAC 和加密分离被嗅探的情况。

    但无论如何这都是在嗅探层面上的安全性问题,一旦握手后则进入一个流加密的过程,只要选择的 cipher 得当,目前没有合适的攻击手段。而 PPTP 直接被 MITM 已经是无法解决的问题了,是整个通讯被监听的问题了。

  • 这个段子好冷啊。。。😂

  • 👍

  • 我有个问题:

    其实可以将尼特值简单理解为亮度值。 白天,人的眼睛能适应亮度的值高于 3.4 尼特;夜晚,主体颜色接近 0.034 尼特,最亮元素低于 3.4 尼特的亮度眼睛会比较舒适。将尼特值换算成 HSB 颜色模式。也就是说主色调颜色(一般指背景色或最暗的颜色)的亮度不超过 20 ( 0<B<20 ),避免使用极端颜色(纯黑),最亮的颜色亮度尽量不超过 50 。

    这个 nit 到 brightness 的转换是怎么实现的。这是假定了屏幕亮度是 17.34 nits 吗?另外如果屏幕的对比度很差,特别是一些糟糕的 TN-TFT 屏幕的话,限定 B 在 20-50 会不会造成阅读的困难?

  • 申请删帖 at 2017年06月04日

    我百行的 WebSocket 就把 rfc6455 标准中提到的错误情况全处理了,只有一个 Continuous Frame 没有实现,并且在遇到时会抛出,也不会让程序 crash。你以为写个框架这几十页几百页的标准文档是不用看的?你看看 nginx 处理 WebSocket 长连接的部分,除了兼容试验性版本所以加了一堆代码,实际部分也就这么多代码。

    我 HTTP/1.1 标准已经几乎全部兼容了,除了标准中非 Web 服务器的部分。你要说「读完 Apache 的 Souce 你能一天写完吗」,答案当然是不能。但也没有就写了一天,就跑到论坛上各种帖子下回复我比你强比你棒的,你这不是拱火是什么?

    「我说的路由规则是指根据 URL 来反射对应的 Controller 处理」 你 URL 怎么处理的?你自己好意思说这句话吗。