很多科技媒体都报道了微软将在 Windows 10 中启用原生的 Bash Shell 支持,没错,微软已经说明 Ubuntu on Windows 将在下个即将发布的 Windows 10 主要版本(Redstone)中到来。
误区澄清
在展开今天的内容之前,我们先要为大家澄清两个误区:
- 微软支持是的 Ubuntu on Windows,而非 Linux on Windows。
- Ubuntu 母公司 Canonical 此次与微软的合作是要直接支持 Windows 原生库和程序:Windows 子系统 for Linux(WSL),而不是通过容器技术或虚拟机运行 Ubuntu。
Ubuntu on Windows 10工作方式
其实 WSL 相关代码早在 2016 年 1 月下旬便被微软悄悄内置进了 Windows 10 Build 14251 预览版中,此后微软的开发人员制订了 lxcore.sys 与 lxss.sys 这两个新的子系统文件,让其成为 Windows 程序员开发 Linux 应用程序的桥梁。
WSL 的首要工作是支持 Ubuntu 用户态映像,微软发言人解释说:「我们为 Windows 建立了新的基础架构,WSL 让 Ubuntu 的缔造者 Canonical 公司可以实现运行 Ubuntu 用户模式映像。基于此,用户就可以在 Ubuntu on Windows 10 中直接运行原生 Bash。」
Canonical Ubuntu 产品和战略执行团队的 Kirkland 提到:「我们此次是将 Ubuntu ELF 二进制文件与 Windows 进行 bit 到 bit 的校验和直接对接。」
为实时将 Linux 系统调用转换成 Windows 系统调用(WSL,目前尚未开源),一个做事非常犀利的 Ubuntu 开发团队一直在努力配合和适应微软的研发技术,以期尽快实现对接。(说以此,想必很多 Linux 爱好者应该已经联想到 wine,这款可在 Windows 中原生运行 Linux 二进制文件的工具。)
目前从微软内部的压力测试工具和实验数据来看,Ubuntu on Windows 10 应用与 Windows 10 应用几乎可以获得同等的 CPU、内存和 I/O 性能结果。
对 Windows 工作原理和发展历史非常了解的用户应该知道,微软此次与 Canonical 的合作似乎显得有些姗姗来迟。其实从 Windows NT 开始就内置了 POSIX 子系统,它就是专门为 Windows 提供原生 Unix-Linux 支持而开发的。
为什么变革
很多人在考虑微软此次为什么要做出如此大的变革?其实不难看出,从 Satya Nadella 上台微软 CEO 宝座之后,一直在致力于推广「移动为先,云为先」的理念,Microsoft Azure 云平台也在不断拥抱开源(一个只支持微软产品的平台,还能叫公有云?)。从用户的角度来看,除了桌面端的 Windows、Mac 和 Linux 外,很多用户同时拥有并管理多套异构平台,就经常需要在 Windwos 中折腾占资源的异构虚拟机、SSH 和 Cygwin 等。在有了 Ubuntu on Windows 后只需点击几下,便可以访问一个功能丰富的 Ubuntu Shell,而无需再在本地虚拟化或重新编译。
而对于 Canonical 来说,其 Ubuntu 是 Microsoft Azure 和其它云平台中最流行的 Linux 发行版,也是普及率非常高的 Linux 桌面端。将 Ubuntu Shell 内置进 Windows 桌面,可以帮助用户和开发人员更容易地使用 Visual Studio、vim 或 emacs 编辑代码、更简便地使用 git、scp 或 rsync 向云实例推送数据。
小结
很显然,不论对微软、Canonical、还是最终用户,此次几方史无前例、似乎有些违背惯例的合作对各方都非常有好处,希望微软在这个方向上的探索会有一个三赢的结果。
如果你对 Ubuntu on Windows 有兴趣,Ubuntu 14.04 LTS for Windows 10 的首个映像将很快会发布,Ubuntu 16.04 LTS 映像会在 4 月 21 日正式发布之后不久取代 Ubuntu 14.04 LTS 上线到 Windows Store。不过由于所有 Ubuntu on Windows 的映像都基于 Redstone 代码,所以最快需要等到今年夏天 Windows 10 Redstone 正式发布最终用户才能正式用上。
最新评论
1.你贴的方法我没测试,如果有效,也只适用于个人或小规模使用,不具备普遍性。 2.根据微软最佳实践,是建立一个本地帐户专门用来远程连接。 3.在域环境中,不存在使用 Microsoft 帐户的情况。
关于rdp无法连接win11微软账户的问题 有很简单的解决办法 不需要退出微软账户或者重置之类的 在中文互联网搜索到的教程内容一般是使用MicrosoftAccount\邮箱作为用户名 密码填微软账户密码然后链接 但是这有个问题就是如果服务端(被控端)本身无缓存时将无法链接 改用英文在google搜索后发现了这样一篇微软社区问答 https://answers.microsoft.com/en-us/windows/forum/all/remote-desktop-not-working-with-microsoft-account/71f0c323-688a-4c97-8740-e80eb31ae11d 打开cmd终端后输入runas /u:MicrosoftAccount\你的邮箱 winver并回车 在出现类似输入MicrosoftAccount\xxx@xxx.com:的密码的文本时输入你的微软账户密码并回车(密码不会显示) 如果密码正确 稍后你将会看到一个Windows关于信息框 关掉它既可 这条命令的意思是 以xxx@xxx.com的身份运行winver程序 在完成后它即可以在本地生成关于该账户信息的缓存 接下来即可在客户端(控制端)输入对应地址链接 用户名为MicrosoftAccount\你的邮箱 密码为微软账户密码 如果一切顺利 在建立连接后 即可弹出证书验证框(如果以前从未链接此计算机) 确定即可 稍等即可进入远程桌面 对于伸手不看理论党的直白概括: 被控端: 打开运行框输入cmd回车 在cmd输入runas /u:MicrosoftAccount\你的邮箱 winver并回车 在出现新的文本时输入微软账户密码并回车(密码不会显示的) 关闭新弹出的窗口及cmd 控制端: 打开rdp客户端 输入计算机的地址回车 用户名:MicrosoftAccount\你的邮箱 密码:微软账户密码 回车后保存证书即可链接 您好,这是我转自B站的评论,不知道这个方法是否具有普遍性来辅助我们用同一个账号进行远程控制
没有用哦,
应用安装失败,错误消息: 从 (Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.Appx) 使用程序包 Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe 中的目标卷 C: 执行的部署 Add 操作失败,错误为 0x80040154。有关诊断应用部署问题的帮助,请参阅 http://go.microsoft.com/fwlink/?LinkId=235160。 (0x80040154) 大佬看看怎么解决