这里这里...
Microsoft SQL Server 的安全性研究-原创论文-刨文网：
这是Microsoft SQL Server 的安全性研究的原创论文 自己去下~
虽然我不懂吧，但我用心找了！应该有点儿用吧
还有，附上1些资料 要自己写的话肯定会用得上
Microsoft SQL Server 2005 安装过程中出现的问题：
一．MSDTC运行帐户问题
确认MSDTC (Microsoft Distributed Transaction Coordinator)服务正在运行，并且其启动帐户是NT AUTHORITY\Network Service”。按照以下步骤来检查：
1. 点击“开始”->“运行”->services.msc
2. 在服务列表中找到Distributed Transaction Coordinator，双击以编辑其属性
3. 在属性窗口切换至登录选项卡，确认其启动帐号为”NT AUTHORITY\Network Service”(密码为空即可)
4. 启动DTC服务再尝试安装SQL Server 2005
结果：这个步骤我已经尝试过，不是这个问题。
二．分析SQL Server 2005安装日志
将C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\目录下所有的文件(包括Summary.txt和Files子目录下的所有文件)发送给微软技术支持工程师进行分析。
结果：这个步骤我没有做过，不过微软工程师好像也没有发现线索。
三．COPY安装程序到硬盘安装尝试
建立 D:\SQLServer2005 文件夹, 创建以下两个子文件夹：Servers和Tools。Serviers文件夹拷贝SQL Server2005的第一张安装盘，包含所有要安装主 SQL Server 2005 组件。 Tools文件夹拷贝SQL Server 2005的第二张盘，包含为 SQL Server 2005 联机丛书和工具组件。运行D:\SQLServer2005\Servers 文件夹下的Setup.exe，启动 SQL Server 2005 安装程序。
结果：以上方式安装过程中还是碰到同样的问题。
四．重新安装 COM+应用程序
1.从控制面板的“添加或删除程序”中，单击“添加/删除 Windows 组件”。
2．在“Windows 组件向导”中，不对选择做任何更改，单击“下一步”。一直单击以完成向导，然后再次运行 SQL Server 2005 安装程序。
结果：问题没有解决。
通过以上分析微软的工程师总结如下：
目前还不确定引起这个错误的原因，并且在安装日志中也没有找到更多的有用信息。可能引起此类错误的原因有以下几种：
1. COM+的配置问题。
2. 帐号权限问题。
3.有一些安装失败的Microsoft.SqlServer.MSMQTask.dll情况出现在测试版中，或者是由于未完全删除的测试版组件而导致安装失败。
4. 除此之外还有一些类似的问题都是与64位操作系统或者Cluster环境有关。
我认为以上的一些原因可以排除，看来又是Live Meeting的时候了，和微软工程师约定时间联机查找问题。
五．手工注册Microsoft.SqlServer.MSMQTask.dll
使用regsvcs.exe应用程序工具注册.NET服务
使用cmd执行过程如下：
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regsvcs.exe "C:\Program Files\Micr
osoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll"
Microsoft(R) .NET Framework 服务安装实用工具版本 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
出现下列安装错误:
1: 要执行此任务，您必须具有管理凭据。请与您的系统管理员联系以获得帮助。
2: 注册程序集“Microsoft.SqlServer.MSMQTask, Version=9.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91”失败。
3: 对注册表项“HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.
DataFileMessage”的访问被拒绝。
分析结果：
这看起来是由于当前Windows用户在该注册表键值上没有足够的权限造成的。经过研究类似案例，在某些情况下，即使是Administrators组的用户也可能出现对这些键值没有Full Control的情况。需要确认一下在这些注册表值上，Administrators组用户是否有Full Control。在注册表中右键点击注册表值->选择权限来查看及改变该值上的权限设置。如果权限设置都正确的话，可以试着抓一个RegMon trace来看到底是不是注册表键值的权限问题导致这个错误。
看来问题终于找到了。
六．监控注册表
1. 运行RegMon工具，通过菜单Options->Filter中设置Include list，把Regsvcs.exe加入Include list中。
2. 执行regsvcs.exe "C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll"
3. 在Regsvcs.exe执行失败停止后，保存RegMon生成的log。
分析RegMon Trace。定位问题如下：
5484 17.98829079 RegSvcs.exe:3404 OpenKey HKCR\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.MessageQueueTask ACCESS DENIED NBCN-ZZ\Administrator
5488 17.98927116 RegSvcs.exe:3404 CreateKey HKCR\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.MessageQueueTask ACCESS DENIED NBCN-ZZ\Administrator
5489 17.98955727 RegSvcs.exe:3404 CreateKey HKCR\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.MessageQueueTask ACCESS DENIED NBCN-ZZ\Administrator
6431 19.89454460 RegSvcs.exe:3404 OpenKey HKCR\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.MessageQueueTask ACCESS DENIED NBCN-ZZ\Administrator
以上其实就是我一开始使用RegMon 时应该发现的问题，结果到现在才发现。
从这几条记录来看，问题是对注册表值HKCR\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.MessageQueueTask的权限问题。而RegSvcs进程在遇到这些权限问题之后，并没有马上终止，还有一些别的注册表活动。我查看了注册表HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.
DataFileMessage项的权限，Administrators组没有“完全控制”和“读取”权限，对其进行授权。重新运行注册，结果又报另外的注册表项没有权限，对其进行添加，直到注册成功，以下是输出结果。
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regsvcs.exe "C:\Program Files\Micr
osoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll"
Microsoft(R) .NET Framework 服务安装实用工具版本 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
正在自动将“Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91”导出为“C:\WINDOWS\assembly\GAC_MSIL\Microsoft.
SqlServer.ManagedDTS\9.0.242.0__89845dcd8080cc91\Microsoft.SqlServer.ManagedDTS.
tlb”。
警告: 程序集未声明 ApplicationAccessControl 属性。默认情况下启用应用程序安全性。
已安装的程序集:
程序集: C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.Sql
Server.MSMQTask.dll
应用程序: Microsoft.SqlServer.MSMQTask
TypeLib: C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.Sq
lServer.MSMQTask.tlb
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>
修改授权的相关注册表项如下：
HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.MessageQueueTask
HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.EncryptionAlgorithmWrapper
HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.ServCompMQTask
HKEY_CLASSES_ROOT\Microsoft.SqlServer.Dts.Tasks.MessageQueueTask.Formatter
再次运行“dcomcnfg”，打开系统组件服务。展开控制台根目录->组件服务->计算机->我的电脑->COM+应用程序节点，发现Microsoft.SqlServer.MSMQTask节点，该COM+服务已经安装成功。
就这些了...
与微软合作的物理学家在arXiv上发表了一篇惊人的研究论文，涵盖了80页，为新颖，细致的万物理论提供了一个很好的表面论证。将宇宙描述为符合进化定律的自学系统，换句话说： 我们生活在正在自学的计算机中 。宇宙是一台计算机，而不是固态存在，而是通过一系列随时间变化的定律而永存。
研究人员通过调用机器学习理论将宇宙解释为学习系统。就像我们可以教机器随着时间的推移执行某种功能（即学习）一样，宇宙定律本质上是以学习的形式起作用的算法。
是否可以想象一下，宇宙本身就是从一种自学系统演化而来的，而自学系统是从最简单的起始条件产生的，就像原始物理定律，它是非常简单的，具有自我延续性，并且能够学习和发展。
也就是说如果宇宙通过一系列定律运行，这些定律虽然起初很简单，但却是自学成性的（自学），因此能够随着时间而发展，或许这就解释了物理学为什么这么难学，因为说不定它一直在变。
也许宇宙不是从大爆炸开始的，而是粒子之间的简单相互作用。 研究人员通过指出“信息架构通常会放大很小数量的粒子的因果关系”来暗示这一渊源。
当然，所有这些都是基于理论物理学的推测。因为作为一个过程，我们无法逆转宇宙，不存在对其过程进行内部可验证的记录， 除非有宇宙硬盘在某个地方的空间中漂浮。毕竟计算机还有硬盘来记录它经历了什么。
将人类之间的对话转录成文字一直是机器的噩梦。即使语音文件质量很高，没有任何背景噪音，算法依旧要努力区分不同的声音，中断，犹豫，纠正，以及冗长会话中的细微差别。
微软研究院的一篇新论文宣称他们的语音转录技术已经能小胜人类对话转录专家，即使人类专家的文本已经接受了另外一个人的复核。研究团队并没有将此成就归功于算法或者数据上的突破，而是对现有的AI架构进行调整。
为了测试他们的算法能否跟人类分出胜负，研究者们首先要确定一个基线。微软找来一个第三方，他们有一个确认100%正确转录的音频。测试分两个阶段：一个人听写音频，第二个人听音频并纠正转录的错误。比照正确的文本后，专业人士的错误率为5.9%和11.3%。
在学习完2000小时的人类讲话后，微软的系统也听写了同样的音频，错误率为5.9%和11.1%。这0.2%的差距就是少了12处错误。
微软的下一个挑战就是让这一水平的语音识别在更加嘈杂的环境里工作，比如在车内或者在趴体上。视线这个对微软而言极为重要，而且它也远远超出了转录本身。
这项研究是微软力图让人机对话更加流畅和轻松的重要一步。如果电脑无法理解一个人的画，那么它完成指令或者回答问题就会更加困难。微软要想取得其他方面的突破，这是基础。今年早些时候，微软CEO萨提亚?纳德拉说人工智能是该公司的未来，而会话能力则是它的基石。
尽管它取得了成功，但是人工智能系统跟人类转录员还有一个巨大的区别：它不能理解对话中那些细微的变化，比如“嗯”。出现“嗯”的时候，往往是一个人在对话中正在思考，或者是让对方继续说话，比如“嗯哼”。专业的人类转录员可以注意到这是犹豫还是确定，但是机器就会忽视这些微小的线索，它们无法理解其中的含义，也不知道为什么会发出这样的声音。
文：许叔/煎蛋网
关于煎蛋：资深新鲜事推送鸡。网站 Jandan.net，公众号：煎蛋（公众号ID：jandancom，并没有i）
