Questions tagged «internals»

Coda Hale的文章“如何安全存储密码”声称： bcrypt具有内置的盐，可以防止彩虹表攻击。 他引用了这篇论文，该论文说在OpenBSD的实现中bcrypt： OpenBSD从arcfour（arc4random（3））密钥流生成128位bcrypt盐，该密钥流以内核从设备时序收集的随机数据作为种子。 我不知道这怎么工作。在我的盐概念中： 每个存储的密码都需要不同，因此必须为每个密码生成一个单独的彩虹表 它需要存储在某个地方以便可重复：当用户尝试登录时，我们尝试输入密码，重复与最初存储密码时相同的盐和哈希程序，然后进行比较 当我将Devise（Rails登录管理器）与bcrypt一起使用时，数据库中没有salt列，因此感到困惑。如果盐是随机的并且没有存储在任何地方，我们如何可靠地重复哈希过程？ 简而言之，bcrypt如何内置盐？

615 security  hash  internals  bcrypt 

您能否解释一下internalC＃中关键字的实际用法？ 我知道internal修饰符会限制对当前程序集的访问，但是我应该在何时何地使用它？

419 c#  access-modifiers  internals 

我们的一个项目中有很多代码如下所示： internal static class Extensions { public static string AddFoo(this string s) { if (s == null) { return "Foo"; } return $({s}Foo); } } 除了“以后更容易公开该类型？”以外，还有其他明确的理由吗？ 我怀疑这仅在非常奇怪的情况下（在Silverlight中反射）才重要，或者根本不重要。

250 c#  scope  public  internals 

我一直想知道调试器如何工作？特别是可以“附加”到已运行的可执行文件的程序。我知道编译器会将代码翻译成机器语言，但是调试器如何“知道”它所附加的内容？

170 debugging  internals 

R中的基本数据类型之一是因子。根据我的经验，因素基本上是痛苦的，我从不使用它们。我总是转换为字符。我感到奇怪的是，我想念一些东西。 在需要使用因子数据类型的情况下，有一些重要的函数示例将因子用作分组变量吗？是否有具体情况时，我应该使用的因素？

95 r  language-design  internals  r-factor 

尽管这个问题在实际中没有任何实际用途，但我对Python如何进行字符串实习感到好奇。我注意到以下内容。 >>> "string" is "string" True 这是我所期望的。 您也可以这样做。 >>> "strin"+"g" is "string" True 那真是太聪明了！ 但是您不能这样做。 >>> s1 = "strin" >>> s2 = "string" >>> s1+"g" is s2 False Python为什么不评估s1+"g"，并意识到它s2与指向相同的地址相同？最后一个块到底在做什么False呢？

92 python  string  internals 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 3年前关闭。 改善这个问题 在过去的几年中，我一直在使用数据库，我想我在使用它们方面已经相当胜任。但是，我最近在阅读有关乔尔泄漏抽象定律的信息，我意识到，即使我可以编写查询从数据库中获取几乎所有我想要的东西，但我也不知道数据库实际上是如何解释查询的。有谁知道解释数据库内部工作方式的好文章或书籍？ 我感兴趣的一些特定事物是： 数据库实际上要做什么才能找出与select语句匹配的内容？ 数据库如何用几个“ where key1 = key2”语句对查询的联接进行不同的解释？ 数据库如何存储其所有内存？ 索引如何存储？

80 database  reference  internals 

.Net库中的许多方法都是用本机代码实现的。那些来自框架本身的标记为[MethodImpl(MethodImplOptions.InternalCall)]。来自非托管DLL的那些标记有[DllImport]（例如[DllImport("kernel32.dll")]）。到目前为止，没有任何异常。 但是在写另一个问题的答案时，我发现有很多用标记的方法[DllImport("QCall")]。它们似乎是.Net的内部实现（例如GC._Collect()）。 我的问题是：究竟是什么[DllImport("QCall")]意思？[DllImport("QCall")]和之间有什么区别[MethodImpl(MethodImplOptions.InternalCall)]？

71 .net  dllimport  internals 

Git与大多数其他版本控制系统之间的主要区别之一是，其他版本控制系统倾向于将提交存储为一系列增量-一个提交与下一个提交之间的变更集。这似乎是合乎逻辑的，因为它是存储有关提交的尽可能少的信息。但是提交历史记录越长，用于比较修订范围的计算就越多。 相比之下，Git在每个修订版中存储整个项目的完整快照。每次提交不会使仓库的大小显着增加的原因是项目中的每个文件都作为文件存储在Git子目录中，并以其内容的哈希命名。因此，如果内容未更改，则哈希值也未更改，并且提交仅指向同一文件。还有其他优化。 所有这些对我来说都是有意义的，直到我偶然发现了有关pack文件的信息，Git定期将数据放入其中以节省空间： 为了节省空间，Git利用了packfile。这是一种格式，其中Git仅将更改过的部分保存在第二个文件中，并带有指向该文件的指针。 这基本上不是回到存储增量吗？如果没有，那有什么不同？如何避免Git遭受其他版本控制系统所遇到的相同问题？ 例如，Subversion使用增量，而回滚50个版本意味着撤消50个差异，而使用Git，您只需获取适当的快照即可。除非git也将50个差异存储在packfile中...否则是否有某种机制说“在少量增量之后，我们将存储一个新快照”，这样我们才不会堆积太大的变更集？Git还能如何避免三角洲的弊端？

70 git  version-control  internals