我将向您介绍发生在我身上的奇怪情况，以及如何成为著名项目的贡献者。
不久前，我忙于一个主意：直接从UEFI引导Linux ...
这个主意并不是什么新鲜事物，并且有许多关于此主题的手册。
在这里可以看到其中之一
。实际上，我为解决这个问题所做的长期努力导致了一个格式正确的
解决方案 。 该解决方案相当有效，我可以在家用计算机的某些部分上使用它。 此解决方案在
此处更详细地描述。
UEFI-Boot的本质是将ESP（EFI系统分区）分区与/ boot目录结合在一起。 即 所有内核和引导映像（initrd）都位于同一部分，UEFI可以从该部分运行可执行文件，尤其是运行系统引导加载程序。 但是Linux内核本身已经通过UEFISTUB选项在许多发行版中构建，该选项允许从UEFI启动该内核。
该解决方案有一个令人不愉快的时刻-ESP分区采用FAT32格式，因此无法在其上创建硬链接（系统在更新initrd时会定期创建硬链接）。 对此并没有什么特别的犯罪规定，但是在更新内核组件时看到系统警告并不是很好...
还有另一种方式。
UEFI引导管理器（您需要注册OS加载器的启动管理器）可以加载Linux加载器/内核之外的驱动程序。 因此，您可以加载具有/ boot的文件系统的驱动程序，然后直接使用UEFI从那里加载内核。 当然，驱动程序需要放在ESP部分中。 这就是GRUB装载机的工作。 但是最重要的是，所有常用的GRUB功能已经在UEFI中。 更确切地说，在他的下载管理器中。 而且更无聊的是，UEFI引导管理器在某些方面具有更多选择。
这似乎是一个不错的解决方案，但是有一个“ BUT”（或者说是，但是稍后会更多）。 事实是UEFI驱动程序系统非常简单。 没有安装文件系统或将驱动程序与特定设备相关联的事情。 有一个条件名称为Map（Eng。）的系统调用，它将依次轮流每个驱动程序，并尝试将其与所有至少合适的设备连接。 如果设备可以接驱动程序，则将创建映射-绑定记录。 这正是新加载的驱动程序应与其他所有驱动程序一起在公共堆中初始化的方式。 并且所有必要的是在驱动程序的启动记录中将1（LOAD_OPTION_FORCE_RECONNECT）放入1，UEFI将在加载后执行相同的全局重映射。
但这不是那么容易。 标准efibootmgr实用程序（通过其配置UEFI卸载管理器）无法（更确切地说，是无法设置）此位。 我不得不用手经过一个相当复杂和危险的过程。
再一次，我尝试着用手做，但我受不了了，
在GitHub上写了一个
问题，要求开发人员添加此功能。
几天过去了，但是没人注意到我的要求。 出于好奇，我查看了源代码...分叉，并想出了“如何在膝盖上”添加此功能...“在我的膝盖上”，因为我没有进行任何设置，而是直接在浏览器中编辑了源代码。
C（编程语言）我很肤浅，但是我提出了一个解决方案（主要是复制粘贴）...好吧，然后我想-至少我那里可能有很多错误（我以前编辑别人C代码的尝试是从10号开始的）我将发出拉取请求。
设计精良 。
在那里，Travis CI被拧紧以检查拉动请求。 他仔细地把我所有的错误都给了我。 好吧，如果知道错误，那么什么都可以纠正：再次在浏览器中，从第四次尝试中收集了代码（对我来说是一项成就）。
因此，我在不爬出浏览器的情况下，将一个非常真实的“拉取请求”设计成一个实用程序，几乎在所有现代Linux发行版中都使用该实用程序。
我感到惊讶的是，我没有真正的语言，也没有自己设置任何东西（取决于依赖项，我需要一小束用于汇编的库），甚至没有启动编译器，我只是在浏览器中“弹出”了一个有用的功能。
但是，自2019年3月19日以来，我的请求一直没有做出任何反应，并且我已经开始忘记它了。
但是昨天，此请求已添加到主服务器。
那我的故事是关于什么的。 事实是，在现代技术的框架内，事实证明，可以在浏览器中编写真实的代码，而不必在本地部署任何开发工具和依赖项。
此外，我必须承认，这是我对知名（至少在狭窄的圈子中）实用程序的第二次请求。 上次，由于我要求更正SyncThing Web界面中某些字段的显示，导致我在根本不了解的环境中进行了单行编辑。