微软发布用Rust编写的Linux版经典MS-DOS编辑器

这是一款适用于简单需求的简洁编辑器。

该编辑器向经典的MS-DOS 编辑器致敬,但采用了现代化的界面和与 VS Code 类似的输入控制。其目标是提供一个易于使用的编辑器,即使是那些对终端操作不太熟悉的用户也能轻松上手。

图0:微软发布用Rust编写的Linux版经典MS-DOS编辑器

安装

图1:微软发布用Rust编写的Linux版经典MS-DOS编辑器

您还可以从 我们的发布页面 下载二进制文件。

Windows

您可以使用 WinGet 安装最新版本:

winget install Microsoft.Edit

构建说明

  • 安装 Rust
  • 安装夜间工具链:rustup install nightly
  • 或者,设置环境变量 RUSTC_BOOTSTRAP=1
  • 克隆仓库
  • 对于发布构建,运行:cargo build --config .cargo/release.toml --release

给包维护者的注意事项

包命名

元素周期表标准可执行文件名称为 “edit”,替代名称为 “msedit”。我们意识到 “edit” 可能与现有命令冲突,因此建议将包和可执行文件命名为 ‘msedit’。应避免使用 “ms-edit” 等名称。如果可能,建议为 “edit” 设置别名。

ICU 库名称(SONAME)

本项目可选地依赖于 ICU 库以实现搜索和替换功能。默认情况下,项目将查找不带版本后缀的 SONAME:

  • Windows:icuuc.dll
  • macOS:libicuuc.dylib
  • UNIX 及其他操作系统:libicuuc.so

如果您的安装使用了不同的 SONAME,请在构建时设置以下环境变量:

  • EDIT_CFG_ICUUC_SONAME:例如,libicuuc.so.76
  • EDIT_CFG_ICUI18N_SONAME:例如,libicui18n.so.76

此外,本项目假设 ICU 导出符号不带 _ 前缀且不带版本后缀,例如 u_errorName。如果您的安装使用带版本的导出符号,请设置:

  • EDIT_CFG_ICU_CPP_EXPORTS:如果设置为 true,将搜索 C++ 符号如 _u_errorName。在 macOS 上默认启用。
  • EDIT_CFG_ICU_RENAMING_VERSION:如果设置为版本号,例如 76,则会查找符号如 u_errorName_76

最后,您可以设置以下环境变量:

  • EDIT_CFG_ICU_RENAMING_AUTO_DETECT:如果设置为 true,可执行文件将在运行时尝试检测 EDIT_CFG_ICU_RENAMING_VERSION 的值。这种检测方式未获得 ICU 的官方支持,因此不建议依赖此功能。在 UNIX 系统(不包括 macOS)上,如果未设置其他选项,此功能默认启用。

要测试您的设置,请再次运行 cargo test,但添加 --ignored 标志。例如:

cargo test -- --ignored

292 Responses to 微软发布用Rust编写的Linux版经典MS-DOS编辑器

  1. jksmith says:

    这只是一个“因为我想做”的项目。我理解这种心情;我自己也做过很多类似的项目,只是为了弄清楚到底发生了什么。但将Turbo Vision重写为FPC并编译到六个目标平台的项目已经存在了20年。Turbo Vision可能是目前存在的最好的文本模式窗口库。当你可以将整个文本屏幕映射到一个数组时,乐趣就来了:var Screen: Array[1..80,1..25] Of Byte Absolute $B800; // 或者类似的,我记得是这样

    Turbo Vision为游戏带来的是一些可移动的、(非)模态窗口。基本上就是在一个循环中不断重写那个数组。相当流畅。我靠这个库赚了不少钱。

    • dleslie says:

      对于好奇的人,这里有一个支持 Unicode 的 C++ Turbo Vision 现代移植版本:

      https://github.com/magiblot/tvision

      • san1927 says:

        哈哈,还有人用Turbo C++吗?

        • srvmshr says:

          如果你知道印度的几所大学很久没有更新课程大纲,而Turbo C++(及其非标准C++变体)仍是首选工具,你一定会感到惊讶。21世纪初的学校董事会更倾向于教授计算机科学领域的编程语言,其课程体系围绕这种C++方言展开。我正是用这种语言通过了高中毕业考试(2004年时它已被认为过时。聪明学生都知道真正的C++编程应使用Visual Studio 6生态系统。但为了通过考试,仍不得不使用它。)

          诚然,过去几年间确实发生了一些变化。MATLAB正被Python取代。教授8085与8051的课程正被RasPi/Arduino取代。8086与ARM及RISC架构并列教学,不再被视为尖端技术。

          我最后一次在大学环境中看到Turbo被使用是在2016-17年,当时是在DosBox中运行(因为Windows 7及以上版本已不再支持此类老旧程序)。这听起来疯狂,但确实如此。

          • Arnavion says:

            是的,我也在21世纪初的印度学校通过Turbo C++学习了C++。搜索“conio.h”会发现,截至2024年,印度人仍在博客和C/C++论坛中讨论它。

          • ethbr1 says:

            > 如果你知道印度的几所大学很久没有更新课程大纲,你会感到惊讶

            我曾问过一位印度同事,为什么印度人使用美式/英式非标准英语,比如“kindly”、“do the needful”和“revert”。

            他想了一会儿,然后说:“哦,大家用来学习英语的教材都写着,正式信件必须以‘Kindly’开头。”

            Sokath,他的眼睛睁大了。

          • ashoeafoot says:

            拥抱。扩展。死胡同。

          • zozbot234 says:

            不错。如果这个编辑器能够获得面向开发者的功能,比如 LSP、DAP 和树坐解析器,那么它在这些领域会非常有用。作为一个用 Rust 编写的编辑器,它对资源的要求可能会比通常的现代选择(通常涉及 VSCode 或 Jetbeans 加上特定语言的插件)要低得多。

        • nazgulsenpai says:

          核心内存解锁…当我大约10-12岁时,我问我父亲(他虽然对计算机一无所知,却自以为是专家)如何为Windows编写程序,因为我在QBasic中无法做到。他的回答是“用C++!”。他带回了一本《24小时学会C++》的书,里面附带了一张3.5英寸软盘,上面有Turbo C++。当然,这并没有成功,但我仍然乐在其中,尝试编写每一个程序,尽管每次都失败。

        • dleslie says:

          OpenWatcom是那些仍在编写DOS应用程序的人的首选,但仍有一些人出于怀旧而使用Turbo C++。

          • iforgotpassword says:

            哦,几年前我想写一个简单的 DOS 程序。由于我家其他设备都是 Linux 系统,我欣喜地发现 OpenWatcom 有 Linux 版本。我花了好半小时试图让我想写的程序的第一个版本运行起来,但它总是立即崩溃。我不断简化代码,直到基本上只剩下“Hello World”。出于直觉,我用Wine运行了Windows版本的OpenWatcom,结果程序竟然完美运行!后来我谷歌了一下,发现有几个论坛帖子提到“当然,Linux版本会生成有问题的二进制文件”。

            问题从来不是编译器,直到问题出在编译器上。只是没想到在家里做些简单的编程乐趣时会遇到这种情况。:)

        • keyle says:

          我希望我是。

    • nathell says:

      数组[1..25, 1..80] of Word 绝对地址 $B800:0000。

      TP中的数组以行优先顺序布局,每个字符由两个字节表示,一个表示字符本身,另一个表示属性(前景/背景颜色和闪烁)。因此,更好的是,数组[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000。

      将 $B800 替换为 $B000 以实现单色文本显示(模式 7),例如在 Hercules 上。

    • throwaway127482 says:

      我很好奇你是如何通过它赚钱的,如果你不介意分享的话。

      • jksmith says:

        我大学毕业后第一份工作是在一家销售基于DOS系统的电视广告应用程序的公司。该程序负责生成所有报告、制作广告套餐、测量覆盖率和频率、计算每千次展示成本等。数据来源采用尼尔森收视率。当时该公司除了支付薪资外,还会向程序员发放佣金。该应用程序至今仍在Windows系统上运行,但我已离开该领域数十年。该程序最初用TP语言为DOS系统开发,后来改用Delphi语言移植到Windows平台。

    • macjohnmcc says:

      我希望VSCode能有一个类似的界面,即使在终端中运行也行。

    • electroly says:

      每次看到新的现代TUI框架,我的失望都一样:“哦。这比不上Turbo Vision。”

    • TiredOfLife says:

      > 这只是一个“因为我想做”的项目。

      不是的。他们需要一个与Windows捆绑且支持SSH的小型TUI编辑器。

      https://news.ycombinator.com/item?id=44034961

      • jksmith says:

        嗯,我没有权限将任何东西与Windows捆绑,也不想这样做。如果使用FPC实现,你只需要一个轻量级播放器来重现TUI界面,而且它并不局限于Windows。我只是想说,我们在开发中往往会受到近期偏见的影响,即使这会花费更多时间和金钱。我确信自己过去也犯过同样的错误。

  2. wasimanitoba says:

    与此同时,他们强行将AI Copilot的臃肿功能植入记事本,而记事本的唯一设计初衷本应是专注于做好“一件事”,避免冗余功能。

    • pjmlp says:

      遗憾的是,新版编辑器也未能幸免于此类决策。

      尽管萨蒂亚可能通过这一改动让微软更亲近开源社区,但盖茨/鲍尔默时代对Windows开发者更为友好。

      如今我们面临Web与桌面框架的分裂,而微软自身几乎不使用这些框架。曾经舒适的VS向导或插件,如今可能变成一个输出Excel文件的命令行工具,这表明新加入的团队几乎缺乏Windows开发文化,或是其高层管理层。

      • CineSnaccs says:

        我不知道有多少人不知道这一点,但现在你实际上无法在Windows上发布应用程序,除非你在安装时显示警告,除非你使用EV证书进行签名,而EV证书的费用每年高达500美元。

        正如你可能猜到的,这简单地挤出了小型开发者。过去并非如此。不应该这样。

        • wronex says:

          我强烈建议考虑使用Azure代码签名。虽然设置起来有些复杂,但它能立即提升信誉,且每月仅需10美元。

          EV证书一直让我觉得是彻头彻尾的骗局和敲诈。至少现在有了替代方案。

        • simplyinfinity says:

          不错。这对开源开发者可能不太友好,但对普通用户来说,如果他们收到一个随机的可执行文件链接,这很好。我接到过很多亲戚的电话,当他们尝试运行一些未识别的应用程序时,大多数时候是无害的,但偶尔也会遇到恶意软件。

          • conductr says:

            这是为了保护无知者而征收的重税。听到这样的事情,我想到自己使用电脑近40年,从未遇到过类似情况。也许这类人需要重新评估自己的技术选择(也许iPad更合适),而不是让整个生态系统为保护他们而买单。

            • simplyinfinity says:

              低收入国家买不起iPad。我父母用的是一台五年前买的300欧元电脑。我爸爸虽然懂点电脑,但现在都六十多岁了。我妈妈能打开Facebook和YouTube。有时他们会下载一些东西并打开它们。所以你的解决方案是“让数百万消费者花钱购买昂贵的硬件和更加封闭的系统,这样数百名开源开发者就不用花500美元来验证他们的应用(无论如何,如果他们想在iOS平台上发布应用,都必须这样做)”。这不可能。

            • cwyers says:

              如果你计算使用Windows的无知用户数量与你这类用户数量的对比,你会很快意识到,这种保护措施对所覆盖的人群而言,其成本非常低廉。

              • ethbr1 says:

                正确的答案应该是法律强制规定的一次性逃生通道。

                把它埋得再深,微软想怎么埋就怎么埋,但……

                  1) 每个人都可以使用它
                  2) 它关闭所有监护检查
                  3) 它使未来的检查变为选择加入而非选择退出
                
            • dec0dedab0de says:

              弹出警告并非沉重负担。

          • hulitu says:

            > 很好。这对开源开发者可能不利,但对普通用户而言,这有助于防范随机可执行文件链接。

            该随机可执行文件链接由微软签名。

        • rollcat says:

          不幸的是,苹果公司首先通过iPhone规范了这一流程。虽然理论上这有好处(减少垃圾应用),但审核/筛选流程无法扩展,而且没错——小型开发者实际上被要求滚开。

          10年前,我想要开发一个Love2D游戏,并发布到三大操作系统。.love文件本质上是ZIP存档,有点像卡带,但你需要正确的Love2D版本(他们每隔一年左右就会打破API兼容性)。Windows和Mac以前是:“cat love.exe game.zip > game.exe”。

          Linux给我带来了最多的麻烦,因为制作一个便携的、半静态的构建是一个噩梦;你不能依赖发行版,因为每个发行版都包含不同版本的Love2D。

          现在 Linux 实际上变得更可行了,不是因为它取得了多少进展,而是因为两大主流平台正在倒退。

        • throwaway290 says:

          现在我明白为什么我参与的项目只针对苹果设备签名,而不针对Windows… 价格高出5倍,天啊

      • shortrounddev2 says:

        目前Windows上没有理想的原生应用开发框架。WinForms是最接近的选项

        • Timwi says:

          听到有人主动提到这一点我感到很高兴。我尝试过WPF,发现它比WinForms难用一百万倍,甚至懒得去尝试MAUI(虽然我把它当作对WPF的道歉,哈哈)。我每天仍在使用一个 WinForms 应用程序(Git Extensions),并且能够为它做出贡献,这在很大程度上是因为它是熟悉的 WinForms。

          这并不是说 WinForms 没有问题。我经常想,如果将开发 WPF 和 MAUI 的所有努力都用于维护、现代化和改进 WinForms,会是什么样子。

          • shortrounddev2 says:

            我认为操作系统供应商提供的原生 GUI 开发 API 首先需要一种“无头”实现,让你可以像 WinForms 一样用纯代码构建 UI,然后再在其上提供一个框架。我个人讨厌 XAML。它比 HTML/CSS 更严格,而且对应用程序的组织方式有很强的意见。我认为XAML框架应该有一个类似于Windows Forms的通用API作为底层,用户可以随时切换到该API。但我发现,手动使用C#代码 behind API来开发WPF、UWP、MAUI等,比Windows Forms要冗长得多。

            我对Winforms的唯一主要问题是它仍然在底层使用GDI,尽管许多人认为它已经过时,但实际上它仍然主要依赖软件渲染。如果他们能够在底层用Direct2D替换Winforms(或者至少在启动时允许客户端提示“优先使用Direct2D”),我认为这将为Winforms注入新的活力。

            我还希望有一个比MFC更现代的C++原生GUI API

            • WorldMaker says:

              “C#标记语言”[1][2]听起来正是你所寻找的。作为该领域唯一的“第三方”选项,它专注于MAUI且仅支持MAUI,这确实有趣,但我想这就是“最新潮流”。

              类似的F#库和第三方C#库已经存在一段时间,它们在使用方式上似乎也相当不错。

              [1] https://learn.microsoft.com/en-us/windows/apps/windows-dotne

              [2] https://github.com/CommunityToolkit/Maui.Markup

            • pjmlp says:

              不幸的是,微软似乎无法做到这一点。

              MFC 与 OWL 相比已经相对较差。Borland[0] 通过 VCL 不断改进它,如今则有了 FireMonkey。

              还有 Qt 也是如此。

              微软则推出了ATL,当他们终于有了能与C++ Builder抗衡的C++/CX时,一小群人却因不喜欢扩展而用C++/WinRT取代了它,这真是讽刺。

              对付费客户完全缺乏尊重,因为C++/WinRT从未拥有过与C++/CX相同的Visual Studio工具体验。

              如今,它处于维护状态,停留在 C++17,仅够用于 WinUI 3.0 和 WinAppSDK 实施工作,而暴乱团体正在享受 Rust 的 Windows 绑定。

              因此,不要指望微软在现代 C++ GUI 框架方面会带来什么好的东西。

              [0] – 是的,如今其他人正在掌舵。

              • trinix912 says:

                Borland在图形用户界面方面做得相当不错,我认为我们忘记了在Delphi中快速启动项目是多么容易。微软至今仍未能在这一领域理清头绪,令人费解。自WinRT时代以来,他们一直在发布新的框架,并希望其中某个能成功。

                • ethbr1 says:

                  微软的图形用户界面问题有两方面。

                  首先,没有人相信他们声称的“新图形用户界面框架”将是未来并用于一切。真的。因为这次与以往不同。

                  其次,预发布用户反馈。这很讽刺,因为微软的其他部门在反馈方面做得很好。

                  依我之见,微软要真正取代WinForms的唯一途径是启动一个为期五年的开源项目,部分由社区而非内部团队主导。

                  并加入一些诱因,比如免费应用签名之类。

        • pjmlp says:

          同意这是最简单的方案,但也可以在与Forms相同的风格下使用WPF,拥有更多功能,无需过度依赖MVVM,保持简单的代码 behind。

          不过,从第三方角度来看,Avalonia可能是最佳选择。

          虽然我认为Uno也很出色,但他们押注于WinUI作为Windows的基础,而自Project Reunion以来,这带来的只有一次又一次的失望。

        • LordDragonfang says:

          我们花了一整年的时间研究要将我们的MFC应用程序更新到哪个框架。我们真的很喜欢保持第一方的想法,因为我们的UI明确是Windows专用的,我们查看了每一个框架——MAUI、WinForms或带有C#层的WPF、WinUI3…

          很快便明确,WinUI3是唯一一个在我们的使用场景下勉强可行的框架,我们尝试用旧版后端代码运行一个基本原型。但我们不断遇到一些希望在未来版本中得到解决的致命缺陷,比如缺少表格功能,或是令人费解的缺乏图形用户界面设计工具(就像之前所有Windows框架一样)。

          …我们目前正在用Qt编写图形界面。

      • naikrovek says:

        新的 Edit.exe 确实避免了这些问题。

        该工具的一个要求是必须尽可能小,以便可以包含在 Windows 的最小发行版中,如 Nano Server。它是那里的救援文本编辑器。

        我敢肯定插件会实现所有人都不想要(或想要)的功能,但默认的edit.exe将保持精简,我敢打赌。

    • dwattttt says:

      我记得雷蒙德·陈曾提到,记事本实际上比你想象的更常被使用;它是功能测试的常见实验对象:https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98

    • GardenLetter27 says:

      这太糟糕了——我的 ISP 出现了间歇性中断(一些 IPv4/MTU 问题),我无法在不关闭 Notepad 的情况下保存文件。

      我正在尝试配置Wireguard来绕过ISP的问题。

    • 0cf8612b2e1e says:

      我截了图并粘贴到新的Win11画图工具中。即使最小化,画图工具仍在持续占用5%的CPU并占用约250MB的内存。我勉强能接受内存占用,但如此浪费CPU资源实在荒谬。

      质量控制或自尊心都去哪了?

    • saturn5k says:

      自从他们引入标签功能后,我就不再使用记事本了。

    • OptionOfT says:

      如果你卸载了现代记事本,开始菜单的搜索功能就找不到旧版本了。

    • masfoobar says:

      感谢你的分享!

      我不得不打开记事本亲自看看。哇!我看到了那个图标。

      我记得Co-pilot突然出现在我的任务栏上,觉得很烦人。尽管我已经删除了它,但它仍然在周围游荡……现在我发现它其实是一个名为记事本的简单文本编辑程序。

      哇。

    • bgro says:

      每个产品都有奇怪的臃肿。我明白随着新功能的添加,产品可能会变得越来越臃肿,但20年前的Office仍然运行得相当不错。事实上,在我日常使用中,我甚至看不到任何缺失的新功能。实际上,任何存在于新版本中的功能都是我主动不想要的。例如,按月/按年订阅、在打字时弹出广告新功能的弹窗,以及专门用于将任何文件导入 PowerPoint 演示文稿或邮件的按钮。

      看看 Outlook。屏幕上不到 25% 的区域用于显示邮件内容。我之所以说“字面意思”,是因为我实际测量过,记得大概是 18% 到 20%。微软不断添加这些巨大的工具栏,每个工具栏都有重复的按钮,这些按钮通常无法调整、删除或隐藏。或者可能是一个“全有或全无”的场景,即某些功能可以删除,但随后你无法例如发送邮件。

      与其解决问题,微软的解决方案是添加一个新工具栏。这种情况经常发生。只是再添加一个工具栏,将部分按钮集中在一个地方,以便用户能找到。现在,我们有一些额外的空白区域……不如把天气信息放进去,为什么不把新闻也放进去呢?能有什么问题呢?

      然后加载新闻时,一些完全无关且非关键的功能会被强制默认加载,这些功能通常至少有一个关键的严重漏洞,例如异步获取过程会使CPU负载飙升至最大并导致整个系统崩溃。要禁用新闻功能,必须先打开Outlook并进入高级设置,而此时新闻内容已经加载完毕。

      看看 Outlook 2003。它几乎完美无缺。界面简洁、直观,没有任何干扰。这真是令人惊叹,就像许多由工程师开发的微软产品一样,但我不知道我们是如何走到今天这个地步的,现代 Outlook 感觉像是由 10 到 50 个不同的项目经理团队膨胀而成,经常包含重复的功能。

      这已经够糟糕了,但更糟糕的是,我们没有像我之前提到的那样修复它,也没有通过减少或整合团队或产品工作来修复它,而是通过推出同一产品的多个版本,为微软的臃肿增添了另一层负担。于是我们有了Outlook(经典版),这个名字让你觉得使用旧版本很糟糕,或者让你相信它不会得到支持。然后是Outlook(新版)。还有Outlook(经典版),它既不是旧版也不是新版,而是一个奇怪的混合体。还有一个网页版本,他们试图强迫所有人使用,因为它“完美无缺”,没有理由不使用……但他们似乎没有注意到,邮件不会在文件夹中加载,除非你点击进入,或者排序规则不相同,或者不支持所有相同的条件。与其修复这些问题,你反而会因使用边缘案例的无谓高级功能而受到指责。比如,谁会想让邮件预先分类到收件箱以外的任何文件夹?看来你使用邮件的方式有问题。

      我跳过关于Outlook多个分支版本的讨论。但还有政府版、教育版、学生版、试用版、免费版、标准版、专业版、商业版、商业专业版、商业高级版等。

      我抱怨的最后一个令人恼火的点在于他们的命名标准。不知为何,他们总喜欢将旧名称改为完全新的名称,而他们选择的名称不仅已经存在,还是另一款微软产品。这在向只熟悉旧名称或新名称的人解释时简直是一场噩梦,这种混淆甚至在技术能力强且专业的团队中也时有发生。为了加分,名称必须是通用名称。即使像“Windows”这样的例子也不算好,因为操作系统太过流行,但你可以想象类似名称会导致搜索混淆。或者想象一下尝试搜索操作系统中用于显示文件夹内文件的图形用户界面(GUI)窗口,同时尝试调试与之相关的技术问题并获取相关信息。

      微软的类似操作层出不穷,以至于在记事本中添加AI功能之类的事情已不足为奇。我并不喜欢他们这样做,但如果他们最初提出的描述与你提到的内容一致,我可能不会如此介意。他们不断违背自己创造并作为核心声明的信息,这让我感到恼火。

      • samiv says:

        既然你提到了Outlook……在公司我们使用Outlook 2019,情况和你描述的完全一样。

        用户界面布满了无用的垃圾,文件菜单回到了这个奇怪的、完全不同的界面布局等等等等。

        最糟糕的是,如果VPN暂时断开连接,它将无法发送或接收新邮件,直到重新启动。

        让我再重复一遍。

        如果网络出现故障,它无法完成其核心功能,无法发送或接收邮件。这简直是无能到极点。

        • ethbr1 says:

          显然你不在场时,Lync^H^H^H^HSkype for Business会无限次重试错误密码,直到锁定用户账户。

          是的,即使在某个Windows服务器/VDI上运行未连接的会话时也是如此。

      • EvanAnderson says:

        > 我抱怨的最后一个令人恼火的点在于他们的命名标准。不知为何,他们总喜欢将旧名称改为完全新的名称,而他们选择的名称不仅已经存在,还是另一款微软产品。

        微软似乎从90年代中期开始就一直在命名方面表现不佳。这几乎无法通过搜索引擎检索,但我记得在90年代中期反垄断诉讼中,一位微软员工试图回答关于“Internet Explorer”与“Explorer”(即“Windows Explorer”,指壳界面)的区别问题,结果变得一团糟。他们的回答总是回到“一个探索者”这个说法。这几乎毫无意义。多年后,在接触了大量微软产品后,我才意识到“探索者”是90年代初微软对“允许你浏览一组内容的工具”的称呼(就像“向导”是逐步引导用户操作程序的过程一样)。

        此外,回顾我关于微软产品命名的“经典评论”:https://news.ycombinator.com/item?id=40419292

      • navane says:

        我刚刚在谷歌上搜索了一些Outlook 2003的截图,感觉很平静。

  3. orsenthil says:

    这篇文章一周内被发布了三次,真是令人兴奋

    1. 作者发布 – https://news.ycombinator.com/item?id=44034961 2. Ubuntu 发布 – https://news.ycombinator.com/item?id=44306892

    以及这篇帖子。

  4. masfoobar says:

    大约一个月前,我听说微软推出了自己的Linux发行版,旨在让Windows用户感到更加熟悉。据我所知,这是一个相当简单的GNOME环境。没什么特别的。

    我惊讶于微软没有利用这个机会创建一个微软专属的Linux发行版,用PowerShell替换Bash,用Vim、Nano等编辑器替代Edit,以及通过开发者安装包集成.NET和Visual Studio Code。

    微软本可以将此作为其默认的WSL安装。

    它可能无法在与Ubuntu或Debian等典型发行版的竞争中获胜,但它可以获得一定份额,并成为Windows用户的常见选择——而Windows用户数量庞大!

    微软无法主导Linux内核,但可以在用户空间获得控制权。想象一下,如果他们的应用程序在流行发行版中默认安装,他们可能会获得 traction。

    这款微软编辑器已支持Linux,就像PowerShell和其他工具一样。如果他们十年前能妥善布局——或许——今天他们的发行版就能跻身前五,仅仅因为许多Windows用户将其作为WSL使用。

    大型公司(如微软)可以将他们的痕迹植入我的个人空间。现在,我们只需要微软编辑器默认启用Co-Pilot。..

    • martinald says:

      我强烈怀疑,未来微软将转向Linux,至少在Windows Server和嵌入式Windows等领域。随后,Windows桌面系统将逐步转型,或出现类似“Windows遗产版”与“Windows Linux工作站版”的桌面选项。具体而言,可能是Linux内核搭配某种“超级”WINE,同时在虚拟机中保留与Windows经典环境紧密集成的备用方案,以支持特定程序。

      唯一的问题是,从设计角度来看,NT内核在许多方面都优于Linux内核(例如,NT内核可以处理GPU驱动程序的完全崩溃并自行恢复,而我认为Linux在这方面会遇到很大困难——其他许多驱动程序也是如此)。

      但Windows正逐渐成为微软的负担而非资产,尤其是在服务器领域。其主要收入来源是Azure和Office 365,这两者仍在以两位数的速度增长,而Windows许可证销售增长则停滞不前。

      至少我预计微软会推出基于Linux的Windows Server版本,以及某种基于Linux的Windows工作站版本。

      • naikrovek says:

        > 我强烈怀疑,随着时间的推移,微软将转向Linux,至少在Windows Server和嵌入式Windows等领域会如此。

        您可能不明白微软有多重视向后兼容性。切换到 Linux 内核将彻底消除这一切,而这对于微软来说绝非选项。

        Linux 内核缺少许多 NT 内核具备且用户频繁使用的特殊功能。

        我们今天所说的Windows(任何版本)都不会切换到Linux内核。

        我希望有一天微软能在Linux上实现一个真正的图形用户界面,不是X,不是Wayland,而是比它们更智能、更好的东西。虽然这可能不会发生,但我真的很想看到他们能做到这一点。

        • trelane says:

          > 我希望有一天微软能在 Linux 上实现一个真正的图形用户界面,不用 X,不用 Wayland,而是比它们更智能、更好的东西。

          https://xkcd.com/927/

          不过,我这么说,这确实听起来像微软会做的事情。他们确实非常喜欢其他平台。

    • Arnavion says:

      >大约一个月前,我听说微软有自己的Linux发行版,旨在让微软Windows用户感到更熟悉。据我所知,这是一个相当简单的GNOME设置。没什么特别的。

      你把微软的官方Linux发行版Azure Linux(原名CBL-Mariner)与多年来人们为Linux桌面环境制作的各种Windows风格皮肤混淆了。Azure Linux是作为微软支持的容器、虚拟机、服务器等环境的常规操作系统设计的。

    • repler says:

      >我惊讶于微软没有利用这个机会创建一个微软专属的Linux发行版

      上一个版本表现不佳,他们将其命名为“Xenix”

    • LionEgo says:

      WSL之所以存在,是因为企业开发人员需要一种运行Linux的方式。IT支持和技术人员通常对Linux一无所知,也不愿意处理支持它的问题。WSL解决了这个问题。

      大多数开发者根本不想使用Linux。许多开发者甚至不知道如何使用终端,而是依赖图形界面工具。

      • masfoobar says:

        > 大多数开发者根本不想使用Linux。许多开发者甚至不知道如何使用终端,而是依赖图形界面工具。

        首先,我不同意这个观点。

        然而,假设你是对的……平均而言,“Windows开发者”在GNU/Linux方面的技能几乎为零。

        如果真是这样,这反而更证明了我的观点:微软错过了创建一个微软Linux发行版的机会……该发行版应包含PowerShell、Visual Studio Code、编辑器,以及可能的Edge、SQL Server等。

        它仍然是Linux,但保持了他们在Windows中熟悉的界面——这将使微软在Linux世界中拥有更多影响力。

        • LionEgo says:

          > 首先,我不同意这个评论。

          你可以不同意,但这是事实。我在英国和欧洲做过合同工作。大多数开发者甚至不知道现代 shell(据我所知 cmd.exe 支持此功能)可以使用 tab 键完成大多数命令。这包括微软公司和使用开源堆栈的公司,例如 LAMP 及类似架构。

          我在西北部的一家大型公司工作时,一个 30 人的团队中只有两名开发者掌握了 基本 的 Bash 和 Vim 技能。

          这就是为什么“如何退出Vim”会成为一个梗。大多数人根本不知道如何操作。

          > 如果真是这样,这反而更证明了我的观点:微软错过了创建一个微软Linux发行版的机会……该发行版应包含PowerShell、Visual Studio Code、Edit,以及可能的Edge、SQL Server等。

          坦率地说,你似乎从未与我描述的人共事过。你列出PowerShell,仿佛他们会使用它。我的一位前同事曾被问及为何要用PowerShell编写一个在Windows服务器上运行的脚本。他们本以为他会写一个C#程序。

      • 8-prime says:

        > 大多数开发者根本不想使用Linux。我不确定这是否一定正确。我认识的许多开发人员更喜欢图形用户界面(GUI)应用程序而非命令行工具,这一点我能理解。但这与Linux和Windows的对比无关。不过,我与Windows的斗争不胜枚举,我的同事们也面临同样的情况。我很难相信我们是特例而非普遍现象。

      • lpcvoid says:

        抱歉发表了刻薄的评论,但那些开发者只是水平不够。Windows是过时的,未来在开源。

        • LionEgo says:

          > 抱歉说了刻薄的话,但那些开发者确实很差

          是的。这是大多数开发者的情况。我今天不得不向一位开发者(人还不错)解释,他必须实际运行测试。

          > Windows是过时的,未来在开源。

          你可以声称未来是开源的,但行业已经转向了SAAS、PAAS、IAAS,这些比使用Windows等专有操作系统更具锁定性。

          因此,尽管你可能使用开源操作系统,但你使用的许多程序都将是专有软件,而且是以最糟糕的方式。

      • trelane says:

        > 许多开发者甚至不知道如何使用终端,而是依赖于图形用户界面工具。

        幸运的是,Linux用户也可以使用图形界面。

        • LionEgo says:

          你对我的评论的嘲讽完全没有必要。

          我真的不应该解释以下内容。但我会解释。

          安装任何第三方开发工具都需要在命令行上进行。查阅在Debian上安装Node LTS、.NET或Golang的说明。你需要使用命令行。即使在更易于使用的发行版上,流程也是一样的。根据工具的不同,你可能需要设置额外的环境变量,这些通常在你的.bashrc文件或类似文件中设置。

          通常发生的情况是,人们盲目地将内容复制粘贴到终端中,而不阅读文档。这个问题在Ubuntu发布之前就已经存在于Linux系统中了。这不仅仅是新手的问题。

          顺便说一下,图形用户界面(GUI)的状态也不尽如人意。许多GUI看起来不错,大多数时候也能正常工作,*但有时会出现问题*,例如,如果我双击一个deb文件进行安装,有时会成功,有时则不会。因此,我不再尝试使用GUI,而是直接使用dpkg/apt。顺便说一句,其他发行版的情况也好不到哪里去。所以我还是得切换到命令行来解决问题。

          因此,你迟早需要学习 Bash,阅读手册页,并手动编辑配置文件。这是 Linux 系统中不可避免的。

    • dfedbeef says:

      你认为微软专门维护了一个秘密发行版,只是为了让 Windows 用户感到“宾至如归”。

      • masfoobar says:

        > 你认为微软维护了一个完整的秘密发行版,只是为了让 Windows 用户感到“宾至如归”。

        抱歉,我不明白你的观点。

        我并没有暗示他们有一个“秘密发行版”,我只是建议他们可以声称在 Linux 发行版中占据主导地位,作为 WSL 的默认发行版。

    • subjectsigma says:

      我猜想品牌认知度对他们有帮助。没有开发者愿意安装一个从未听过的发行版,但他们确实愿意安装Ubuntu。如果WSL支持Ubuntu,他们就能从中获利。

    • delfinom says:

      >微软无法主导Linux内核,但可以在用户空间获得控制权。想象一下,如果他们的应用程序默认安装在流行发行版中,他们就能获得影响力。

      是的,但他们通过这种方式如何赚钱?

      与那些最终掌控发行版的社会主义集体思维不同,微软需要支付薪水和账单。

      就我所见,每个人都喜欢免费使用微软的软件,但没有人愿意为产品付费。

      • masfoobar says:

        我并非商业专家,但我认为他们的成功并非仅源于Windows操作系统。我认为Windows的成功不在于利润,而在于对用户的控制。如果大多数用户使用Windows,他们不太可能改变习惯去使用其他熟悉的系统。

        此外,对于新电脑/笔记本电脑,微软已与多家零售商达成协议,预装Windows(家庭版)。因此,在某种程度上,Windows对用户来说是免费的,除非他们购买专业版或其他当前提供的版本。

        当然,普通用户会创建一个微软账户来完成安装。 🙂

        除了Windows操作系统——真正重要的是他们提供的服务。Azure、Office365、SQL Server、PowerBI等。我认为这才是收入的主要来源……企业愿意为此付费!

        我为那些愿意为这些服务付费的公司工作——这一切都是为了“支持”

        如果出现问题,就向微软反馈。即使我知道问题所在,也必须通过工单系统处理。把问题交给微软,继续工作。

        尽管如此,微软也提供“免费”软件。他们已开始开源许多软件,支持Linux和Windows系统。例如Visual Studio Code、SQL Server、PowerShell等。

        这又回到了我的观点。当他们推出WSL时,本可以提供一个“MS Linux”发行版,并将其宣传为“方便Windows用户使用”。如果该发行版变得流行,将迫使微软在用户空间获得更多控制权……这将使大多数Windows用户远离Ubuntu等系统。

        就像Windows一样,这是一种让用户群体依赖他们所熟悉的事物的手段。

  5. scoopr says:

    最初的edit.com,大约在DOS 6.22(以及后来的7.0,即Windows 95)时代,是我使用的第一个集成开发环境(IDE)。我最初是从QBasic开始学习的,因此对edit.com比较熟悉(因为它与QBasic类似,或者说相同?),但当我开始学习C/C++并使用djgpp时,我继续使用edit.com。

    我的“项目文件”是`e.bat`,其中包含`edit file1.cpp file2.cpp file3.cpp`,因为这是我所知道的少数几个支持多文件编辑且切换方便(Alt-1,2,3…)的编辑器之一。我仍然继续重新映射编辑器的键盘快捷键,以便使用Alt/Cmd-1,2,3…切换文件 并尽量将我的“活动文件集”设置为编辑器中前几个文件

    它并不是一个优秀的代码编辑器,因为它没有语法高亮功能,而且缩进行为也不是特别好(这就是为什么在我职业生涯早期,我的缩进设置为两个空格,因为这样手动操作起来比较简单,而且不像制表符那样麻烦)。但无论如何,我对代码的操作感觉非常直接。

    我知道许多人使用像`qedit`这样的编辑器,但不知为何它们从未让我感到顺手。Unix风格的编辑器在DOS环境下也感觉不对劲。

    快速尝试后,它似乎无法使用相同的键绑定切换缓冲区,尽管它似乎支持多个缓冲区。

    • JdeBP says:

      你应该将此作为问题提出。如果这类问题能尽早反馈,就会得到重视。

      而且这不仅仅是类似。它实际上完全相同。EDIT.COM 只是通过特殊参数启动 QBASIC。只需带上该标志运行QBASIC即可。如我在https://news.ycombinator.com/item?id=44037509中所说,我确实这么做过,只是为了好玩。

    • mysterydip says:

      它可能没有语法高亮功能,但确实有语法大写功能(暂且这么称呼吧?)。如果你输入一行全小写文本,按下回车后,保留字符会自动大写。虽然功能有限,但确实有所帮助

    • unsupp0rted says:

      在`copy con`时代之后,edit真是个救星

      • naikrovek says:

        我记得在早期使用计算机时经常使用edlin。学习它非常困难,但一旦掌握了使用方法,它就非常出色。我不知道为什么被迫学习它,但当时我需要它来完成某些任务,因此在使用DOS的整个过程中都坚持使用它。当别人看到你使用它时,他们都会感到惊叹。“那是什么鬼东西!?”

  6. nhatcher says:

    我喜欢这个软件的太多地方了!

    首先,依赖项列表是空的!我完全被征服了!它运行得非常出色。我不敢相信他们专门为此开发了一个TUI,还配有对话框和文件浏览器。我想把它用于我的一个项目,不知道使用起来有多容易。如果参与这个项目的人在这里,为什么不使用Ratatui呢?

    代码质量一流,只能说一句:

    太棒了!

  7. pxc says:

    我以前会向这类编辑器的目标用户推荐micro[1]。不知道现在是否需要改变推荐。

    1: https://micro-editor.github.io/

    • seabrookmx says:

      我认为不应该改变。

      `edit` 甚至不支持语法高亮(至少在我尝试时是这样)。

    • prmoustache says:

      上次我查看时,根据二进制文件大小,micro 本应被称为 macro。

      • pxc says:

        难道二进制文件相对较大只是因为它用 Golang 编写的吗?Go 可执行文件会随附自己的 Go 运行时副本。仅此一项就占了这类小型程序的大部分空间。

        Nano 还依赖于 ncurses,其大小与 micro 的压缩 tarball 相当。我正在查看每个包的依赖闭包,在nix-tree[1]中,微型程序的闭包总大小为15.04 MiB,而纳诺的为12.78 MiB——从这个角度看,这并不算“数量级差异”(如一位评论者所言)。

        诚然,nano 的依赖项(在我的系统上是 `file` 和 `ncurses`)很可能作为任何 Linux 发行版的“基础系统”的一部分随系统一起提供;它对任何发行版实际增加的大小可以忽略不计。但对我来说,没有迹象表明 micro 像流传的 meme 所说的那样“臃肿”;它所需的运行条件似乎合理且与其他具有相同功能的工具相当。

        1: 参见:https://github.com/utdemir/nix-tree;尝试执行 `nix run nixpkgs#nix-tree — $(nix build –no-link –json nixpkgs#nano | jq -r .[0].outputs.out)`

      • 3836293648 says:

        嗯,它比 nano 大几个数量级,所以……

      • sime2009 says:

        seriously? 我们在2025年还要为一个文本编辑器的几兆字节大小抱怨?

        • prmoustache says:

          就像我母亲常说的那样。小溪汇聚成大河。

          对几兆字节的大小不屑一顾,正是导致一些现代系统如此臃肿的原因。

        • mixmastamyk says:

          是的,我无法在路由器上使用它,因为它的体积太大。没有理由让一个文本用户界面(TUI)变得如此庞大。除了语法高亮外,其他高级功能并不实用。应该有一个轻量级版本。

          我安装了带有CUA键绑定的新版。

    • smartmic says:

      还有dte[1]. 它正好填补了这一空白,提供了一个极简的编辑器,支持Unicode、CUA键绑定以及更多功能。它已经取代nano成为我的终端编辑器。

      [1]: https://craigbarnes.gitlab.io/dte/

      • whou says:

        我建议大家查看并阅读一些dte的源代码。这是现代C语言优雅编写的绝佳范例。

      • sneak says:

        为什么你反对学习已经广泛安装的vi?

        • 4ggr0 says:

          作为一个经常使用命令行文本编辑器的人,但使用频率不够高到能形成记忆VI快捷键的肌肉记忆,我真的很欣赏简单的文本编辑器。

          我知道我可以按下3-4个任意按钮来标记一个块并将其移动到不同位置——为什么我不能用光标标记它,然后按CTRL-X CTRL-V,就像其他所有程序一样。

          我明白在刚安装或已加固的服务器上使用VI是必要的,但对于日常使用的工具,我只想让它保持简单(KISS原则)。我已经预料到有人会回答“但Vim简单又易用”。我想意见确实因人而异。

          https://www.youtube.com/watch?v=9n1dtmzqnCU

        • pxc says:

          我非常喜欢Vim,并且在可能的情况下使用Vim风格的键绑定。

          但在学会骑自行车之前,我使用了训练轮;在掌握足够的Vim知识以真正享受使用Vim之前,我依赖于nano。

          当有人第一次开始探索 GNU/Linux,甚至深入研究 macOS 的 Unix 内核时,他们正在学习一个全新的世界,而不仅仅是一个新的文本编辑器。对于某些人来说,通过他们熟悉的桥梁(如 CUA 或 Windows 风格的快捷键)来过渡,可以让这个过程更加有趣且不那么疲惫。有时这种差异对保持学习和探索的动力至关重要。

          无论如何,我认为学习Vim是值得的(如果打算在老旧或特殊系统上工作,或许还应了解老派vi的一些特性)。问题不在于“是否”推荐学习Vim,而在于“何时”学习。在深入探索编辑器之前,Micro似乎是大多数人的理想选择。

          我还想说:作为 Unix 类操作系统的爱好者,或是欣赏其持久优势的专业人士,我们真的应该抱持“因为它存在”的教条吗?这种思维方式难道不是导致我们每天不得不应对那些令人沮丧的平庸之作的根源吗?

          作为一个热爱由志愿者最初构建的生态系统的人,我认为将软件项目仅仅因为它们尚未成为主导玩家就轻率地否定,是令人遗憾的,甚至可以说是虚伪的。我所热爱的绝大多数软件曾经都处于边缘地位,其用户不惜费力将其安装在自己使用的系统上,只因它们比默认软件更令人愉悦。我们应该在实际可行的范围内,尽量在对待计算的方式中留出一小块空间——即使我们随着年龄增长变得越来越挑剔。

        • IshKebab says:

          因为 vi 的易用性就像用刺猬做的键盘一样糟糕。

          • s1mplicissimus says:

            我不会认为 vi 的易用性总体上是糟糕的。当然,其“可操作性”(“是否能轻松理解可执行的操作,而无需耗费太多认知努力?”)确实糟糕。

            搭建一个良好的环境也非常麻烦,但如今你可以直接跳入预先配置好的环境,如 Normalvim 或 LunarVim。

            但可用性不仅仅是“是否容易学习”,还包括“一旦掌握后,使用起来有多困难”

            一旦这些操作被深深植入你的肌肉记忆中,效率就会变得极其惊人。di{、dat、yaf等只是入门级操作,一旦开始使用正则表达式、宏和插件,真正的乐趣才刚刚开始。

          • sneak says:

            vi 不可用。它很糟糕。但事实是它安装在每个地方,你可以在 10-15 分钟内学会如何使用它。弥补你对基本 vi 的无知比在每台你将要编辑的机器上安装软件更容易。

        • smartmic says:

          我很久以前就学会了 vi,并在没有其他编辑器可用时使用它。事实上,我根据任务需求和可用工具同时使用多个编辑器。我偶然发现 dte,因为我喜欢尝试新事物。由于dte在许多方面都符合我的需求,我将其安装在经常需要终端编辑器的机器上。仅仅因为在某个时间点学会了使用某一工具就束缚自己,这并非我的理念。幸运的是,开源世界提供了如此多的替代方案和创新,几乎能满足所有人的口味和习惯。除了需要培养肌肉记忆以在需要时切换外,这几乎没有成本。

        • JdeBP says:

          你意识到你在讨论一个旨在直接安装在微软Windows上的工具,而vi并没有直接安装在Windows上,对吧?你的“无处不在”并不包括这里所强调的主要使用场景。

        • mixmastamyk says:

          对于大多数人来说,学习 CUA 一次更现实/方便。

    • mattbee says:

      你可以在 Windows 上通过“winget install zyedidia.micro”获取它。这让我想起了同一时代类似的 8 位和 16 位编辑器。

  8. pulkitsh1234 says:

    我很好奇,像这样的项目是如何在微软这样规模的组织中获得批准的?这是开发人员的一些副项目,还是产品路线图的一部分?他们是如何说服领导层花时间在这一点上的?

    • zamalek says:

      文本编辑器是集成 copilot 的明显目标。

    • dark-star says:

      正如他们所解释的,他们需要一个能在命令行环境下运行的文本编辑器(适用于Windows Core服务器安装),支持SSH连接(因为Windows已内置SSH服务器,可通过SSH完全管理系统),并且能被没有vi使用经验的Windows管理员使用(即无模式编辑器)。

    • sublimefire says:

      每个团队都需要做些事情,他们会提出各种想法。有时这些想法是由不同领导者推动的,例如“使用Copilot”。有时这些想法源自某些黑客日活动并被进一步扩展。有时这些想法在研究部门中由一群闲置的技术人员提出。有时这些想法需要经过深入分析和多个学期的研究才能获得资金支持。

      看看这里有多少贡献者。这个项目很可能是某种战略投资。它并非一朝一夕就能完成。

  9. red_admiral says:

    我现在正在等待EDLIN,但需要支持Unicode。

    我记得可以在批处理文件中使用它,通过从标准输入管道传输键盘输入来脚本化某些编辑操作。某种程度上可以替代sed或awk的部分功能。

    我还没试过,但这应该也能用vi实现。至于这是否会带来深层诅咒,那就是另一个问题了。

  10. majkinetor says:

    我以为这可能通过Enter-PSSession实现,但不幸的是它返回了错误0x80070006:句柄无效。

    令人难以置信的是,到了2025年我们远程会话中仍没有TUI。

    • DSMan195276 says:

      完全同意,这是我每次在远程PowerShell和SSH之间切换时感受到的最大差异,进行基本的文件修改总是感觉像是一场斗争。

  11. anyfoo says:

    有趣。我必须承认我不知道这到底是为谁准备的,但看起来很有趣。

    • tim-- says:

      这是为那些希望使用Windows终端编辑文件的人设计的。自2006年以来,Windows已不再支持旧的`edit`命令,因此自那时起就没有微软提供的命令行编辑器可用。

      看到这个编辑器运行得如此之快令人印象深刻。https://github.com/microsoft/edit/pull/408

      > 通过编写专门用于换行符定位的SIMD例程,我们可以将速度提升至[125GB/s]

      • _verandaguy says:

        这……是一个有意义的基准测试吗?

        谁会定期使用交互式编辑器处理足够大的文件,以从120GBps的吞吐量中获得实际收益,而不是通过脚本/工具/ETL处理数据,具体取决于数据的大小和性质?

        • magicalhippo says:

          在工作中,我们偶尔需要修改一些500MB的XML文件,因为源文件会以非重复的方式破坏它们。

          通常我们只是手动编辑它们。实际上,我对VS Code处理它们的方式感到非常惊喜,非常流畅。

        • 0points says:

          对于文本编辑器,当然,绝对需要。

          作为开发人员,我们经常需要处理大型数据集,无论是数千兆字节的日志、CSV数据、SQL导出文件还是其他类型。

          无法打开和编辑这些文件意味着你无法完成工作。

          • _verandaguy says:

            我完全在Windows生态系统之外工作,因此我通常会先通过命令行中的过滤工具处理这些文件,然后再用编辑器打开它们。

          • Geezus_42 says:

            但你真的打算在Windows服务器上做这件事吗?我觉得有更好的工具适合这个任务。

            • delfinom says:

              “更好的工具”并不总是“当前带来$$$$$$$$$$$$$$”的工具。所以你只能接受现状。

              当然,也许通过切换到 Linux,你可以通过解雇所有员工并用熟悉 Linux 的开发人员取代他们,然后将所有内容重新编写为在 Linux 上运行,从而挤出相当于一个 CPU 核心的性能提升。

              或者,接受现状并赚钱赚钱赚钱赚钱。

        • tiagod says:

          我经常需要滚动查看大型文件,这就是我安装 Sublime Text 的原因,因为它处理这类文件非常出色。

        • WD-42 says:

          谁在乎?这很有趣。编程可以很有趣。

          • anyfoo says:

            换个角度看,你可以一边享受乐趣,一边思考某件事是否在乐趣之外还有意义。如果有,很好。如果没有,也没关系。

          • _verandaguy says:

            我不是说这样做不能有趣,甚至可以从中学习,但当它被吹捧为一个功能或规格时,我不得不问它是否是一个合法的点。

            如果你建造了世界上最宽的自行车,那很酷,我很高兴你做这件事很有趣,但这可能不是自行车最有用优化的目标。

        • anyfoo says:

          虽然不是经常这样做,但确实有时我会因为各种原因在Emacs中加载非常大的文件。在这种情况下,Emacs会问我是否要启用“字面模式”。不过我不会在EDIT中这样做。

        • tim-- says:

          作为一个具体的基准测试,不是。但链接到PR的重点不在这里。尽管这个命令看起来像一个基本的编辑器,但它实际上功能丰富。

          模糊搜索、正则表达式查找和替换。

          我好奇这个新命令未来还会投入多少开发工作?它会支持语法高亮(有人已经分支并添加了 Python 语法高亮:https://github.com/gurneesh9/scriptly)和语言服务器支持吗? 🙂

          • _verandaguy says:

            没错,这些功能在我看来比每秒处理125GB数据的能力更有用。我可以没有后者,但语法高亮是关键功能,而对于某些语言,LSP支持是一个非常重要的附加功能。我认为在当今时代,这两者都是名副其实的一流/内置功能。模糊搜索和PCRE查找替换也是如此。

            再加上一个设计良好的插件API,这将与Vim和Emacs等工具名义上处于同一水平。

        • tomrod says:

          挑战。接受。

      • axpvms says:

        这非常方便。我之前不得不使用bash -c “vi myfile.txt”,这有点烦人。

      • cerved says:

        可能更像是需要使用它。基本上就是Windows版的nano

    • DrJokepu says:

      其实在读我文件里就写得很清楚:

      > 目标是提供一个易于使用的编辑器,即使对终端不熟悉的用户也能轻松操作。

      • scblock says:

        这可能是书面目标,但我怀疑这并非该项目存在的真正原因。

        • cosignal says:

          是的……我认为“对终端不熟悉的用户”与“足够技术娴熟以至于会听说这个仓库的 Linux 用户”之间没有重叠。

          • paulfharrison says:

            假设你正在运行一个集群,而你的用户是生物学家,他们需要处理大量数据集。他们需要运行一些非常特定的命令行软件来组装基因组。他们需要通过SSH编辑SLURM脚本。这些操作都超出了他们的舒适区。你需要为他们推荐一个文本编辑器,你会选择哪个?

            我遇到过喜欢挑战vim的生物学家,但他们很少见。nano能完成任务,但界面丑陋。micro稍好一些,是我目前的推荐。它们都不是开箱即用的完美体验。如果微软能改善这种开箱即用的体验——这是他们擅长的领域——那当然更好。如果你不喜欢微软,那就自己做一个类似的。

            • hulitu says:

              > 你需要引导他们使用文本编辑器,你会选择哪个?

              mcedit ?

            • 0points says:

              > 你正在运行一个集群,而你的用户是生物学家,他们需要处理大量数据集。他们需要运行一些非常特定的命令行软件来组装基因组。他们需要通过SSH编辑SLURM脚本。这完全超出了他们的舒适区。你需要引导他们使用文本编辑器,你会选择哪个?

              场景描述有误。如果你是为生物学家运行这个集群,你应该为他们构建一个前端界面来“编辑SLURM脚本”,否则你可能会发现自己需要找新工作。

              > 生物信息学工程师开发软件、算法和数据库以分析生物数据。

              你是一名工程师,为什么不设计一个解决方案呢?

          • zamadatix says:

            标题的含义因阅读方式而异。编辑并非“专为”Linux设计,就像PowerShell并非为取代bash、zsh、fish等而生。两者只是也提供了适用于Linux的二进制文件。

            之前HN帖子中链接的博客文章,详细解释了该工具在Windows上的背景和存在原因,比一个随机标题指向仓库的描述要全面得多。

            • egorfine says:

              今天学到:PowerShell 存在于 Linux 上。

              但……为什么?

              • trelane says:

                嗯,至少部分是这样。

                就像 .net 一样,它并不打算让你轻松摆脱微软。

                https://learn.microsoft.com/en-us/powershell/scripting/whats

              • skc says:

                那为什么不呢?

                Linux 难道应该只有一个官方指定的 shell 吗?PowerShell 在 Linux 上只是众多选择之一。

                • egorfine says:

                  我并不反对。绝对可以尝试。

                  我只是想知道移植它的原因,然后我想和实际使用该 shell 的真实用户聊聊。

                  • WorldMaker says:

                    PowerShell 非常适合编写跨平台 shell 脚本,这些脚本在任何可以启动 PowerShell 7+ 的环境中都能正常运行。其源自.NET脚本的背景意味着,即使在跨平台支持出现之前,PowerShell脚本编写中已普遍采用了一些高级编程模式,例如使用$pathINeed = Join-Path $basePath ../sub-folder-name可智能处理路径分隔符,而非简单地进行字符串拼接。

                    其面向对象的编程方式易于使用,并提供了一些与 Unix “一切皆文本” 工具集形成鲜明对比的实用工具。例如,对于任何输出 JSON 的内容,使用 ConvertFrom-Json 将其转换为 PowerShell 对象的过程非常便捷。(类似于使用 `jq` 的方式,但它是“原生 shell”工具。)同样,对于接受 JSON 输入的任何内容,你可以使用 `ConvertTo-Json` 构建复杂的 PowerShell 对象结构,然后轻松将其作为 JSON 传递。(我偶尔也会使用 `ConvertTo-Json` 进行 REPL 调试。)

                    PowerShell 中 shell 脚本参数/参数解析的标准化也非常方便。我认为这使得从头开始编写新脚本更加容易。虽然你可以复制粘贴大量 bash 风格的代码来启动一个 bash 脚本,但 PowerShell 提供了许多内置功能,包括自动缩写和基本使用文档,这些都“免费”包含在其内置的参数绑定支持中。

                  • MattSteelblade says:

                    我认为这是最初的公告 https://azure.microsoft.com/en-us/blog/powershell-is-open-so…。我在 Linux 上使用过它,它默认包含在 Kali 和 ParrotOS 中。

          • 0points says:

            这是一个 Windows 11 终端编辑器。不要因为它也支持 Linux 而感到困惑。

          • joseda-hg says:

            我不知道,我一直使用edit,因为我听说过它,而不是去弄清楚为什么我的vim配置在Windows上会出问题

            我可能会通过WSL使用nano(或者到那时直接用nvim),但它也有自己的小问题

            它占据了和我之前使用的micro相同的空间,但它/它将被预装,所以更好(这也是我最初关心vi的原因)

          • rtpg says:

            我不知道,我在高中时用了很多年Linux,但使用像Vim这样的工具让我感到很困惑(而且周围没有人告诉我使用Nano)。

            EDIT.COM,另一方面……在我看来,它简单直观

          • kevin_thibedeau says:

            在 Linux 服务器上使用 nano 进行编辑的非技术人员并不少见。如果有一种比 nano 更易于使用的工具,肯定会有一批用户。

            • mikepurvis says:

              尤其值得注意的是,它是一个仅有 222KB 的单一二进制文件(在 x86_64 架构上)——这使其成为基础系统中“默认安装”的绝佳候选工具。Vim 和 Emacs 都远超这个大小,即使是 vim-tiny 也达到 1.3MB,且对非技术用户而言比 Vim 本身更具挑战性。

              我认为 msedit 确实有其用武之地。

            • hulitu says:

              Midnight Commander 附带 mcedit。

          • cAtte_ says:

            显然这个编辑器主要是为 Windows 设计的,不明白为什么标题里写着 Linux

        • justsomehnguy says:

          我的猜测是,微软内部可能还有一些人,以某种方式,还能做些有趣的事情。因为他们没有被分配到另一个项目,去让 OOBE 变得更加糟糕。

          /吐槽 今天我花了3个小时试图安装一台新的MSI一体机并安装Windows Pro系统。尽管这台电脑将加入本地ADDS并从那里进行管理,但我必须先连接到某个互联网网络,设置3个愚蠢的恢复问题(这些问题连NIST都会感到脸红),然后再等待30分钟强制下载更新(无法跳过)。哦,出错了——让我们重复这个过程3次。

      • Gormo says:

        已经有足够多的类似工具,比如jed、mcedit等。

        这个特定的应用程序极其基础——甚至比DOS上的EDIT还要有限。

    • iknowstuff says:

      我乐意用它替换vim,尤其是如果它支持LSP或通过ripgrep搜索。我现在使用Helix,但更喜欢一个好的tui。

    • z3ratul163071 says:

      这是我想要的,作为终端中更合理的nano替代品,因为我讨厌vi。

    • kgwxd says:

      它比记事本好得多

  12. gnabgib says:

    讨论(271分,1个月前,185条评论)https://news.ycombinator.com/item?id=44031529

  13. Aldipower says:

    我欣赏这个项目中展现的幽默感。例如,从发布说明中: “正如史蒂夫·鲍尔默著名所言:修复!修复!修复!”。

    看到在一家价值数十亿美元的公司中,员工也能享受乐趣,令人耳目一新。

  14. 0x0 says:

    我原本希望这能在macOS终端应用程序中通过SSH运行,但上次尝试时,编辑的文本文件中插入了各种奇怪的字符。

    Windows现在自带官方OpenSSH服务器,但据我所知,目前还没有好的官方文本编辑器能在OpenSSH上正常工作。

    我不得不用“copy con output.txt”来将内容写入文本文件,每次在Windows-OpenSSH上操作时都得这么做…

  15. parliament32 says:

    人们为了避免学习 Vim 而采取的种种手段,至今仍让我感到惊讶。

  16. pcunite says:

    1993 年,我曾打开二进制文件进行编辑,并享受看到心形图案的乐趣。

    • samplatt says:

      这,以及DOS磁盘碎片整理的可视化效果,还有我自己编辑存档文件的十六进制编辑,基本上就是我今天成为开发者的原因。

  17. dbuxton says:

    我原本以为这是Gemini CLI(它是Claude Code的克隆版)的克隆版。既高兴又失望地发现自己错了。

  18. csense says:

    有趣项目#1:让二进制大小与EDIT.COM相当

    有趣项目#2:移植到MS-DOS(带DPMI)

    有趣项目#3:移植到16位MS-DOS (可在原生8086上运行)

  19. bluedino says:

    > 该编辑器向经典MS-DOS编辑器致敬

    奇怪的是,它看起来更像Borland的编辑器。

  20. oliverkwebb says:

    看到一个明确不是集成开发环境(IDE),更像记事本的编辑器很不错。在编辑配置文件等场景时,使用记事本类工具比使用VSCode等工具更方便。

    这个编辑器没有不切实际的野心,更注重易用性而非功能堆砌,因此更胜一筹。

  21. kspacewalk2 says:

    多久之后它会变成 Copilot 365 Edit?

  22. ashoeafoot says:

    如果你是个有想法的人,想让你的想法成真,你只需要制作一个花哨的假预告片来宣布它,然后看着公司去实现它,那些高管们是如此空洞,任何外部人士都能操控那些幽灵船。

  23. tempire says:

    假。它不是蓝色的。

  24. napolux says:

    哦,回忆。gorilla.bas 🙂

  25. DrNosferatu says:

    有Flatpak或Snap版本吗?

  26. pmarreck says:

    我最近很喜欢TUI。

    我希望这个能在nixpkgs上

  27. gadders says:

    接下来做Edlin。

    这让我想起了我在支持热线工作的日子。

    “输入 edit autoexec.bat…..” 等

    • trinix912 says:

      还有 DEBUG。真遗憾,Windows 已经不再捆绑调试器/(反)汇编器/二进制编辑器了。那个工具虽然小巧,但功能强大。

  28. Fokamul says:

    Nano完全可以胜任这个任务。不,让我们烧点钱,重新发明轮子吧。

    与其捐款给Nano开发者,或者雇佣他们中的一些人,

    这家愚蠢的公司真是到了极点。

    • masfuerte says:

      Nano 是一个功能简陋的编辑器,拥有自己独特的键盘快捷键设置。这有什么用?如果我想学习新的键盘快捷键,我会选择一个功能齐全的编辑器。

      msedit 的键盘快捷键基于 IBM CUA 标准。这对于许多人来说非常熟悉。

  29. andrewstuart says:

    我喜欢 edit。

    它是我以前最喜欢的编辑器。

    它运行良好,基本功能非常出色,能够完成工作。很高兴看到它又回来了。

  30. amelius says:

    我原本希望有一个内置大语言模型(LLM)的 MS-DOS 编辑器。

  31. ubermonkey says:

    我不理解大家为什么这么喜欢这个项目。它刚推出时是一个糟糕的编辑器;几年前,我们都开始使用其他编辑器了。

  32. 1vuio0pswjnm7 says:

    没有二进制文件。可能仅适用于使用 glibc 的 Linux 发行版。

  33. guerrilla says:

    也许这可以弥补他们破坏记事本对某些人的影响。

  34. fsniper says:

    微软喜欢将通用术语如“编辑”用于其产品。我不知道这怎么说得通。

    SQL Server 就像是发现 SQL 的那个,或者它是唯一提供 SQL 的产品。

    • red_admiral says:

      复制命令被称为“copy”,这似乎说得通?我记得曾看到一位同事的.bashrc文件中写着“alias copy=cp”。当然,标志参数不会以相同方式工作。

      “chcp”确实是个拗口词,但“del”或“erase”与学习“rm”是“remove”的缩写一样合理。你很快就能掌握这两种约定,不过我总是用“where”来表示“which”。也许我应该创建一个别名之类的。

      别让我开始谈论PowerShell的“看,我们可以用正式的单词,让我们看看能把它弄多长”。

    • not_a_bot_4sho says:

      我明白你的意思,但大家都这么做。

      苹果有Pages、Numbers、Keynote等。谷歌有Drive、Docs、Sheets等。Meta有Messenger。例子太多,列不完。

      相反,使用不明显的名称是荒谬的。

    • delfinom says:

      >我不知道这怎么飞。

      他们没有注册商标,可能也注册不了。

      但没有理由不允许任何人使用通用名称为产品命名。许多软件应用程序都这样做,坦率地说,这比想出不真实的名称更能吸引新用户。

      我认为虚构名称存在的唯一原因,是为了让市场部门有事可做,试图向用户解释这些毫无必要的概念。

  35. umeshunni says:

    这能移植到MacOS吗?

  36. xyst says:

    要让我放弃多年来建立和改进的 neovim 设置,光靠怀旧和 rust 是不够的。Lsp、dap、自动完成、别名和每个编程语言的绑定。当然,它采用懒加载,所以仍然非常敏捷。

    使用 nix 管理配置和外部依赖项,例如 lsps。

    然后为每个项目创建独立的 Nix 终端,以在隔离且可重复的会话中加载工具和其他依赖项。添加 direnv 以实现更流畅的开发体验。

  37. 90s_dev says:

    我不明白为什么他们要选择 DLL 进行脚本编写,而不是 WASM + wamr,后者真的非常小巧。也许我在这方面还不够经验丰富。

  38. LAC-Tech says:

    需要LSP和Tree-Sitter 🙂

  39. nhinck3 says:

    又一个微软的极客洗脑项目。

  40. kgwxd says:

    也支持Windows!它有“重做”功能,不要与“撤销撤销”混淆。固定宽度制表符是一个巨大的进步。LF(不带CR)可以将文件大小减半。

  41. herbst says:

    有人要求在你的Linux机器上再安装一个微软编辑器吗?

  42. 486sx33 says:

    为什么应该避免使用“ms-edit”?

  43. ocdtrekkie says:

    如果他们不推荐使用winget进行安装就好了。winget是一个严重的安全风险,微软只是假装遵循最基本的安全实践,尽管它四年前推出时没有任何保护措施,而且自那以后从未实施过任何改进。

    • easton says:

      免责声明:我过去经常使用winget,现在不再使用了。

      ……但它真的比brew或choco更不安全吗?安装程序来自相对可信的来源,并由微软扫描恶意软件,社区贡献者必须批准清单更改,而清单本身不能包含与链接可执行文件无关的任意代码。感觉这已经是很好的安全措施了,无需要求ISV自行维护仓库。

      • ocdtrekkie says:

        这些安装程序来自互联网上的随机用户。大多数软件仓库都有可信的贡献者,并且有政策要求软件必须有足够的理由才能被纳入。也许因为微软害怕选择赢家,所以winget上允许任何垃圾软件存在,而且无法限制谁可以对哪些包进行更改。

        有些ISV希望锁定他们的软件以便维护,但一家万亿美元的公司却不愿意花一美元来制定一个“业务流程”来实现这一点。据我所知,微软只有一名员工参与其中,他对于任何安全担忧都一笑置之,说“自动恶意软件扫描器会发现的”。

        所谓的“社区贡献者”只是在 winget 发布时活跃在 GitHub 上的用户。有人对他们进行过任何审核吗?没有。

        微软应用商店有真正的应用审核人员,而 winget 只有“嗯,没问题”。

        • 90s_dev says:

          在项目名称旁显示作者姓名,并附带一些表明这是真实作者而非冒名顶替者的标识,我认为这可能是我们能得到的最佳方案,因为到那时一切都取决于社区信任。

    • dale_huevo says:

      winget 只是 Windows 开发者的 curl | bash 版本。又一个微软抄袭 Linux 功能的例子。

      • TiredOfLife says:

        Windows已经拥有

        irm | iex

      • ocdtrekkie says:

        但curl | bash确实会执行作者控制的URL中的代码,如果URL是HTTPS,则以相对安全的方式执行。

        使用 winget 时,无法验证可执行文件是否来自官方来源,也无法确保第三方贡献者未篡改其维护方式。

        • tim-- says:

          > 以相对安全的方式

          对于远程服务器而言,通过传统的 `curl | bash` 管道提供两个不同版本的脚本是轻而易举的。https://lukespademan.com/blog/the-dangers-of-curlbash/

          没有验证机制确保你通过管道传入 bash 的脚本就是你期望的脚本。即使通过在浏览器中复制粘贴 URL 验证命令,或使用 curl 并通过 more/less 管道传输,也无法充分保护您。

          • bee_rider says:

            >> 不过,curl | bash 确实会执行由控制 URL 的作者编写的代码,且如果 URL 是 HTTPS,则以相对安全的方式执行。

            > 对于远程服务器而言,通过传统的 `curl | bash` 管道传递两个不同版本的脚本是轻而易举的。

            我对此感到困惑;这似乎是以纠正的语气撰写,但你们似乎都在说,你得到的正是服务器发送的内容。(?)

            • tim-- says:

              > 你们似乎都在说,你得到的正是服务器发送的内容

              是的,但我也在说,你无法验证在第一台机器上通过管道运行的脚本与在第二台机器上通过管道运行的脚本是否相同。

              原陈述的关键部分是服务器可以根据不同因素选择发送不同的脚本。在机器 1 上运行的 curl&bash 脚本并不一定意味着在机器 2 上运行的 curl&bash 脚本是相同的。

              通过curl | bash管道提供的工具完全没有安全性。

              使用winget时,至少可以通过工具验证下载并安装的文件(具有相同哈希值)是否相同。

              有更好的方法来实现这一点,例如,可以查看 https://hashbang.sh。该文件包含一个GPG签名,该签名会在安装脚本传递给curl之前进行验证。

          • ToValueFunfetti says:

            父级提到了中间人攻击(MITM),这可以通过 TLS 和 curl 防止,但 winget 无法做到。他们认为 curl 严格来说更好,但并非不可突破。如果你信任域名所有者,你可以信任 curl | bash,但不能信任 winget

            • tim-- says:

              为什么不能信任 winget?

              运行 `show` 命令即可查看 winget 安装的具体操作。https://learn.microsoft.com/en-us/windows/package-manager/wi

              查看清单文件也非常简单(例如,https://github.com/microsoft/winget-pkgs/blob/2ecf2187ea0bf1…)而且,与使用裸 cURL 和 Bash 实现的中间人攻击防护相比,它可能更优,仅仅是因为所有安装程序文件都由第三方提供了文件哈希值。

              > 他们说 cURL 严格来说更好,但并非不可突破

              没错。但严格来说,它未必更好。

              > 你不能信任 winget

              同样,这没有依据。我信任 winget。我可以信任清单至少经过了人工审核,且安装的应用程序应是我请求的版本。我无法信任 curl | bash 也能做到这一点。如果安装的应用程序不是我请求的版本,系统有工具和流程来排查原因,并标记问题以防止其他用户遇到相同情况。而 curl | bash 没有这些机制。

        • dale_huevo says:

          如果你认为HTTPS在进行代码验证,我得告诉你一个事实。

          HTTPS仅保证包含未经验证的恶意代码的包在从服务器到你的过程中未被篡改。而服务器本身可能已被入侵,并被植入替代代码。

          你这里做了一个严重的错误类比。请重新阅读你所说的话。

          你可以通过普通HTTP传输数字签名代码,其安全性将高于你举例中的HTTPS场景。遗憾的是,许多缺乏正确信息的开发者仍相信关于HTTPS的诸多误传。

        • dgfitz says:

          curl | bash绝对是我“绝不会做的事情”清单上的首要项,每次看到都让我感到不适。从根目录开始执行rm -rf也是其中之一。我曾经看到有人(以 root 身份)输入“rm -rf / home/user/folder”。当我意识到发生了什么时,已经为时已晚。

  44. jedisct1 says:

    可能完全是由人工智能生成的。

  45. tmaly says:

    这是因为有人想用 Rust 做某件事而制作的吗?

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注