近两年虚拟机的发展给开发人员带来了极大便利，安装一个新环境，只需从别人那里copy一份虚拟机文件即可，分分钟搞定。我之前一直在Ubuntu下工 作，Windows偶尔使用，于是在Ubuntu VirtualBox下安装了一个Windows 7。今年将工作环境迁移到Mac Air下了，但偶尔也有Windows的使用需求，于是直接从我原来的Ubuntu下将Win7的Vdi文件Copy到Air上，便直接可以使用Win7 了，省去了重新安装Win7以及庞大的Office组件的工作。

前两天，打开Mac Air下的VirtualBox，启动Win7虚拟机，在Win7登录界面输入密码后，系统提示我密码错误。反复输入多次，将我常用的密码都试了一遍依旧 无法进入。我只能在原Ubuntu下临时用用Win7。但毕竟在Air上没有Win7十分不便，一些Word, PPT文档需要在两天机器上传来传去。无奈下，我都由了重新在Air下安装一个Win7甚至是Win8的打算了。

今天又有一个PPT编写的task，这件事再次被提上日程。我换了下思维：能不能破解一下Win7登录密码呢？于是求助度娘（谷哥离去好久了）。还别说， 还真是有破解方法，多数是通过PE工具盘快速修改登录密码。但PE工具盘挺大（几百兆，公司下载不便），我的又是虚拟机环境，这种方法不是我的菜啊。于是 又看到另外一种思路：通过某个Linux livecd或安装盘引导，mount windows分区，将C:\Windows\System32\cmd.exe改名为osk.exe。osk.exe是虚拟键盘程序。在Win7登录页 面的左下角可以启动这个虚拟键盘程序。一旦我替换成功，启动虚拟键盘程序就变成了启动Win7命令行程序。有了命令行，我们就可以通过net user命令查看当前账户列表、重置某个用户的password了。思路很清晰，是我的菜。

在我的Ubuntu机器上倒是有几个Linux发行版的live cd iso文件，比如ubuntu 14.04.1 desktop, centos7 desktop，不过个头都太大了，传到我的Air上还是很费劲的。我想最好有一个tiny的linux发行版。度娘告诉我有很多选择。我首先选了Tiny Core Linux， TinyCore-5.4.iso才不到14M。于是打开Win7虚拟机的“设置”页面，将 TinyCore-5.4.iso作为虚拟iso“插入”IDE光驱。TinyCore的启动就是秒秒的事情。TinyCore的桌面风格模仿Mac OS，桌面下方放置了一个dock条。TinyCore自带mount tools，打开后，用鼠标点击sda2，sda2盘符由红变绿，说明mount成功。

打开TinyCore的Terminal程序，进入/mnt/sda2，本想安装方案修改cmd.exe的名字，但Tiny Core提示：这是个Read-Only Filesystem。显然这是个只读mount。于是各种尝试读写挂在（包括修改/etc/fstab、mount -a, mount -o remount等），都无法改变Read-Only Filesystem的事实，于是放弃。

换国人的发行版：CDLinux，这个发行版似乎已经不再更新，最新版本 CDlinux_mini-0.9.7.1.iso，发布时间是2012年3月18日。CDLinux的Size比TinyLinux稍大些，36M。 CDLinux启动略慢，并且只是Console Only（标准版带有桌面环境），没有图形桌面。进入命令行后，执行一下mount命令，发现/dev/sda2居然是rw方式挂载载/media /xxx下的，于是进入该目录，尝试touch test.txt，完全没有问题。

于是按照方案说明，将C:\Windows\System32下的osk.exe备份一下，将cmd.exe改名为osk.exe。

将光盘盘片删除，启动Win7，进入登陆页面时，点击左下角“轻松访问”按钮，选择“不使用键盘键入”，确定。命令行窗口弹出。

在命令行窗口执行net user 查看用户名列表。我的用户名是tonybai，再通过net user tonybai newpassword重置tonybai的密码。执行成功后，用新密码登陆，顺利进入Win7 Desktop。Crack成功！

本文翻译自Dr. Dobb’s杂志主编Andrew Binstock的"Putting Absolutely Everything in Version Control"一文。

持续交付(Continuous Delivery)的一个关键原则就是将所有东西都放入版本控制系统中。这解决了一些重大问题，但也引入了一些其他问题。

持续交付是持续集成(CI)的一个自然扩展。后者旨在每次代码签入后运行构建并为开发者提供即时的反馈，而持续交付的目标则涵盖更广。它谋求在每 次代码签入后进行构建、测试以及最终可执行程序的部署（这里的部署针对的是测试环境，而不是生产环境）。这个想法保证了一个工程在任何时候都拥有 一个已知部署安全的可交付的应用。这个应用也许不是功能完备的，但却是可以运行起来的。

在一些拥抱敏捷开发的地方，持续交付正逐渐追上了持续集成的脚步，因为它在许多领域促进了最佳实践的使用，并消除了在部署过程中发现意外缺陷的问 题。它还使得团队熟知部署，让依靠传统手段进行部署所带来的那令人屏息的时刻成为历史。

把所有东西都放入版本控制系统(Version Control System, VCS)是对持续交付很重要的一个最佳实践。是所有东西，我说的的确是所有东西。这里引用一段对持续交付有着重要意义的文字：“当然，开发者应该使用版本 控制系统管理源码，但是也应该将其用于测试、数据库脚本、构建和部署脚本、文档、库以及你的应用的配置、你的编译 器和工具集等等。这样一个刚进入团队的新成员便可以从头开始工作了”。

这是一种激进的状态 — 我们中有多少人会把编译器放入版本控制系统中呢？但是，它解决了一个重要的问题：重建旧版本的软件，虽然这种情况很少见，但一旦出现，可能会给你带来很大困难。大 多数从事过编程维护工作的人都有无法重现一个缺陷的经验，因为任意一个工具的改变都会导致原先的二进制程序无法被复制出来。这种方法还给我们提供 了另外一个好处：可以保证每个团队成员在开发中使用相同的文档和工具。无需再担心海外的团队成员获取到不同的需求或使用一个更新版本的编译器等问 题了。团队中的每个人都是从同一口井里取水的。

然而，完成这一任务并非易事。最近在波士顿举行的Citcon(译者注：CITCON, the Continuous Integration and Testing Conference)上，这个话题就在一个CI爱好者的会议上被提出讨论。第一个问题是许多开发工具不只是一个简单的二进制程序和一些动态库，相反，他 们依赖OS库并且必须安装后才能正确的运行起来（尤其是在Windows上）。这个问题在某种程度上可以通过使用虚拟机来补救。在虚拟机上安装OS以及用 于自动化构建的工具，接下来将整个虚拟机签入到版本控制系统中。这种方式工作起来很好，不过它也需要你在虚拟机中构建你的产品，否则你需要建立两套独立的 环境，他们难免会不同步。（Linux和Unix受这个问题影响较小，因为它们没有注册表。上帝请保佑那些将二进制文件和配置文件放在同一个目录下的产品 的工具制造者吧！）

一个更隐蔽的问题是并不是所有的版本控制系统都能很好地支持二进制文件。例如，Git被设计成一个纯粹的SCM（而不是VCS， 译注：SCM，Software Configuration Management，软件配置管理系统），在处理规模较大的工程或具有大量二进制文件的工程时十分困难。（如果你将工具和虚拟机签入，从SCM角度来 说，你的项目将自动变大）。在这个领域，商业产品更加擅长。尤其是Perforce，它在快速处理二进制文件，尤其是大工程上面下了大量功夫。

另一个挑战是脚本中存在的密码。持续交付中的部署针对的是非生产环境，将密码留在非生产环境（即测试环境）下风险可能很小，这可部分抵消这个问题的影响面。对其它组织而言，对密码进行加密是可以提供的另外一个解决方案。

最后，我应该注意到即便上面提到的那本书（译注：指的是《持续交付》这本书）也是不推荐将构建产生的二进制文件放入VCS中的，这是有道理的。毕竟二进制 文件很大并且样式繁多。而将所有东西都放入VCS的重点只是为了能够在未来的某个时间点上重建出那些相同的二进制文件。

就个人而言，我不认为可能将每个项目的所有东西都放入SCM中。基于Linux的使用开源工具的工程最有希望达成这一目标。然而，我相信为了尽可能地接近 这个目标而付出的努力是值得的。它赋予你一种安全感：可以在任一时刻，回到过去重建旧版本的产品，并且所有人都基于同一个工具源上工作。在我看来，这些益 处要远大于其他原则引入的弊端。