论“实际情况”和 Linux
Redshift_Shine · · 科技·工程
见此游记有感而发。
根据本省实际情况，本次考试提供 Windows + NOI Linux 虚拟机。我选择在 __ 系统下完成本场考试。
:::info[TL;DR Part 1 / 我如何走进实体机 Linux 的大门]
在我目前并不突出的竞赛经历中，有一件事让我颇为自豪。从初一首次打进 CSP-S 复赛开始，每一次存在上面的这道填空题时，我都会不加思索地直接写上 NOI Linux 2.0。除了在初二时输入文件中的一处编码问题让我焦头烂额之外，我没有碰到过任何问题。
初三时，Hyprland 那相比 Windows 来说极致美观的界面驱使我尝试在我的电脑上安装 Arch Linux 作为实体机系统。那时，之前只在 VMware 虚拟机和 WSL 中用过 Linux 的我对 Linux 相比于 Windows 的优越性感到深深的震撼：在相同的工作条件下，Linux 的 CPU 占用远小于 Windows。而且，先前在 Windows 中，每次运行一个 C++ 程序的用时都不会小于 30ms。甚至在某一次系统更新后，每次程序开始运行后至少 500ms 才会开始实际工作，这让我感到极大的不便。但 Linux 没有这些麻烦。通过 bash 令程序开始运行后，没有多余的检查步骤，程序直接开始运行，随后结束运行，毫不拖泥带水，程序的实际运行时间就是它的实际工作时间（单线程情况下）。
此外，在 Linux 下安装软件甚至不需要你知道它的官网网址，只需要知道它的软件包名字：一行命令，直接安装，没有多余步骤。Linux 的开发理念天然地避免了对硬盘分区所会碰到的各种问题，因此安装删除，来去自由。
现在距离我在电脑上安装实体机 Arch Linux 恰好一年。我发现我已经无法忍受 Windows 那糟糕的温度管理以及繁琐的软件安装步骤。
:::
现在进入正题。
由游记分类下的文章可知，有相当多的选手在今年省选的 Day 2 联合编译题目（也就是交互题）中出现了问题。
Day 2 共有两道联合编译题目，分别是 T1 和 T2。这两道题都在题目 PDF 中给出了明确的编译指令。换言之，出题者不期望选手在赛时出现任何的编译问题。
实际上，这个问题显然也是 CCF 所不期望选手碰到的。因此，在每年的 NOI 以及与其共享举办地的 WC 中，选手电脑均只提供 NOI Linux 系统。在此情况下，选手所需要做的唯一一件事情就是将 PDF 提供的编译指令原样抄写或复制进工作目录正确的终端，随后就可以正常地进行解题或调试。
我们尝试描述可能出现的各种情况。
- 承办方强制选手使用实体机 NOI Linux 系统进行作答，且选手根据 NOI 大纲要求清楚【1】Windows、Linux 等操作系统的基本概念及其常见操作，【1】常用编译命令 g++ 的基本使用。
在这种情况下，可以保证不会出现任何问题。
- 承办方强制选手使用实体机 NOI Linux 系统进行作答，但选手未使用过 NOI Linux。但是，选手曾在 Windows 上使用 cmd 等命令行工具进行 C++ 程序编译。
在这种情况下，仍然不会出现任何问题。得益于 MinGW-w64 等优秀的移植项目，Windows 下 g++ 的命令行操作与 Linux 下的操作几乎没有任何不同，选手只需要经过一些尝试（成功在文件夹内点击鼠标右键或打开应用栏中的任意一个）就可以打开终端，继而使用熟悉的命令行操作正常完成编译。
- 承办方强制选手使用实体机 NOI Linux 系统进行作答，但选手未使用过 NOI Linux，且未曾使用任何命令行工具进行编译。
我们暂时不讨论这种情况。
- 承办方提供 Windows 和 NOI Linux 双系统。选手熟悉 VMware 虚拟机的基础设置，并且有足够的命令行编译经验，且熟悉 NOI Linux 下的各项操作。
这是提供双系统考区的最理想情况，且这恰好是我的情况。
在该情况下，我的操作是：在开始作答前，在指定位置创建选手文件夹，并将选手文件夹添加至虚拟机的共享文件夹，且使用 vmhgfs-fuse 命令使得新的共享文件夹被正确挂载，在 NOI Linux 虚拟机中全程在该文件夹中进行解题。
当然，若无法做到这一点，使用默认的 public 文件夹也是可行的。
- 承办方提供 Windows 和 NOI Linux 双系统。选手未使用过 NOI Linux，但曾在 Windows 上使用 cmd 等命令行工具进行 C++ 程序编译。
在选手充分熟悉 Windows 和 Linux 下 C++ 编译行为的不同的前提下，该配置也不会出现任何问题。
- 承办方提供 Windows 和 NOI Linux 双系统。选手未使用过 NOI Linux，且未曾使用任何命令行工具进行编译。
我们将要讨论这种情况。
上述论述中，我暂时略过了两种情况。
- 承办方强制选手使用实体机 NOI Linux 系统进行作答，但选手未使用过 NOI Linux，且未曾使用任何命令行工具进行编译。
- 承办方提供 Windows 和 NOI Linux 双系统。选手未使用过 NOI Linux，且未曾使用任何命令行工具进行编译。
按照一般想法，g++ 编译指令既然已经被纳入了 CSP-S 的初赛考题，这两种情况就不应该发生。然而从实际情况来看，确实发生了。
为什么会发生这种情况？我们不妨猜测一下原因。
首先是操作系统问题。Windows 等商业操作系统（包括手机操作系统等）的设计目标是让没有任何专业知识的人也能流畅地使用。因此，Windows 毫无疑问地成为了全世界所有非专业用户使用的电脑中使用最广泛的系统。也就因此，除某些特殊时段（如华为电脑由 Windows 到鸿蒙系统的过渡期）外，提供预装 Linux 的面向非专业用户的电脑相当稀少。
对于非服务器端来说，Windows 很好用啊！实际上，除了那些真的对“自定义电脑”有一股狂热的人之外，所有人都会认为 Windows 很好用。实际上，我们可以认为大部分 OI 选手的父母都是非计算机专业人群，因此，使用 Linux 的氛围根本就没有被大规模培养起来的可能。
既然 Windows 是设计给广大的非专业人群的，大部分 Windows 用户的日常使用是完全摸不到终端的。但在 Linux 下，命令可以更方便地解决很多问题。这就导致大部分人领略不到 Linux 的方便。
其实我很想说软件生态问题的。不过，因为一些神奇的文件，国内一批大厂应用纷纷开始适配，硬生生地把国内主要生态的半壁江山拉进了 Linux。那也没法说什么了。
接下来说一说现实问题。按照传统，中学的学习生活就是永无休止的听课+写作业。就光是这一项就已经耗光了学生可自行支配的时间，而对于信竞生来说，宝贵的不用写作业的集训时间都要用在做题上，而对于 Linux 的使用这一项看起来不太重要的事项就基本不可能花时间做。Dev-C++ 的一键编译多好用啊，有换的必要吗？肯定没有啊！这就是直到 2026 年，这个老旧的 Dev-C++ 5.11 仍然是大多数信竞生的主力编辑器的根本原因。
考虑到这一点，各个省份的组织单位自然也没有只提供 Linux 的动力。不用想，能够在纯 Linux 考场快速解决各种技术问题的志愿者一定是很不好找的。同时，一部分志愿者由于长期脱离甚至根本就不了解 OI 广大选手的实际情况，就会出现令人啼笑皆非的在这篇文章中出现的选手把编译器文件路径直接告诉志愿者结果志愿者直接说让其他选手去 C 盘自己找的事情。志愿者大概是不知道大部分选手完全不知道 Dev-C++ 的编译器默认文件路径。
而且，并不是所有学校都有提供 Linux 环境的条件。在没有 Linux 环境的条件下，自然不可能熟悉 Linux 的操作，更不可能在考场上一瞬间理解联合编译的操作方法。
那咋办。现实问题和技术问题都这么多，看起来想要在短时间内扭转这个局面完全不可能啊。
实际上洛谷已经为避免这种情况做出了很多努力。Unofficial Mirror 工作组将 KTSC 2026 的两场比赛都搬运到了洛谷。作为韩国的国家队选拔比赛，这两场比赛中的总计八道题目全部采用联合编译，且复现时间都位于省选前不久，理论上可以帮助选手快速熟悉联合编译的操作方法。文章区也有用户投稿了联合编译原理简述，选手可以阅读这篇文章来了解原理，从而掌握联合编译的操作方法。
讲个笑话。结合时事，可以乘着近期 OpenClaw 的热潮自己尝试在电脑上安装 Linux，用命令行装个 OpenClaw，熟悉 Linux 下复杂项目的配置。我不想干这事，但是不乘着这种被官方刻意炒起来的半成品风潮，很有可能真的解决不了现实问题。