CSCI3150 Lab01 环境配置

课程：CSCI3150 Introduction to Operating Systems · 2026T1 本讲：Lab01 环境配置，第 1 部分 / 共 2 部分 · 原件 Lab01-环境配置与编译-2026T1.pdf（本地课件） · PDF页码副本（本地课件） p.1–14 定位：以2026T1评分环境为准理解工具链，复用已登记工作区。 前后：后接 GCC与Makefile。

逐页伴读

p.1–3：环境一致性是可复现的一部分

p.1介绍本次Lab，p.2分为环境、GCC和练习，列出9月18日截止；这是所读版本中的日期。p.3明确Linux20.04、64位、GCC9.4.0。代码在宿主macOS编译成功不代表在课程Linux上成功，系统接口、库和工具链都可能不同。

仓库开发约定（本地资料）登记已有工作根 课程工作目录/CSCI3150-Lab1，容器路径 /work，Lab01在exercise。登记的ARM64、GCC9.4.0、Make4.2.1来自9月17日既有验证，本次重写没有重新运行容器。64位也不自动等于x86-64，涉及汇编或二进制时还需核对架构。

四条原件路线补齐。 p.3 列 VirtualBox、Docker、CSE Linux Server，以及仅供 Windows 用户的 WSL2。列出路线不等于四条路线的架构、内核与软件版本自然相同；本 Lab 的比较基准仍是所列 64 位 Linux 20.04 与 GCC 9.4.0。p.2 的 Sept.18 截止与当期独立教学计划中的 Sept.24 不一致，笔记保留这一来源冲突，不能用旧页的日期覆盖 Blackboard 通知。

p.4–6：虚拟机与容器分别封装什么

原VirtualBox方案为XUbuntu20.04、4CPU、4GB内存、100GB虚拟磁盘与GCC9.4.0。Docker方案先装Docker Desktop，再装VS Code Dev Containers扩展。图p.6标出扩展市场中的Dev Containers，不是随意名称相近的插件。

容器共享其Linux宿主内核环境中的机制，VM提供整套虚拟硬件上的系统；macOS上的Docker还有Linux虚拟化层。课程目的是得到匹配的执行环境，而不是比较哪一个工具名字更新。

p.7–9：打开工作目录，不是打开配置子目录

原目录树把.devcontainer/devcontainer.json放在源码工作根下面，macOS点开头目录默认隐藏，可用Command+Shift+.显示。图p.9选择“Open Folder in Container”时应选包含.devcontainer的工作根；若选配置目录本身，源码挂载与相对路径都会错。

已有工作区无需再按旧课件复制一份覆盖。新增兼容单元在同一根下独立建目录，先比较OS、编译器、架构和依赖，具体遵守规则登记（本地资料）。本伴读仅解释步骤，没有改动环境配置或作答。

原操作顺序（p.7–9）。 先启动 Docker Desktop；Linux 用户可启动 Docker daemon。把教师包中的 .devcontainer 配置放到准备存源码的工作根下；macOS 用 Command+Shift+. 显示隐藏目录。在 VS Code 按 Ctrl+Shift+P（macOS 为 Cmd+Shift+P），选择 Dev Containers: Open Folder in Container…，再选这个工作根。首次操作会拉取镜像并创建容器，因而比以后重开慢。这里转述课件操作；本课程已有登记的共用环境时，按开发约定复用，不覆盖已完成源码。

p.10–12：验证的是容器内命令

p.10是课件版本的Docker CLI可发现性排查截图；p.11终端示例显示GCC9.4.0，应在容器终端运行ASCII命令 gcc --version。课件正文的长横线不是可直接复制的参数。

p.12说明工作目录挂载让宿主可看到文件；容器内另装的包与挂载源码不是同一种持久性，重建容器可能需要重装包。图中约600MB与4GB是其示例体积，不是当前下载大小保证。

补充：一次环境检查要产生可解释的证据。 在将实际编译的终端依次看当前目录、源文件、操作系统、架构与编译器。目录回答“读写哪一份文件”；架构回答“生成给哪类CPU执行的程序”；编译器与参数决定如何翻译源码。宿主窗口上写着Linux项目，并不能证明终端已经进入容器。

持久性也有两个方向：工作目录挂载通常让宿主与容器看到同一份源码，编辑后双方应能看见同一修改；容器里临时安装的包则可能只属于那份容器文件系统，重建后需按配置恢复。停止容器通常不会删除宿主挂载源码，删除/覆盖宿主文件却会影响容器看到的内容。判断操作影响前先确认它作用于挂载目录还是容器内部目录。

p.10 截图的排查路径是 Docker Desktop → Settings → Advanced → CLI tools 选择 System mode，Apply 后重启 VS Code 再试；若仍失败联系 TA 或改用课程 VM。这是课件版本的 UI 路径，后续软件版本可能调整。p.12 给出的继续阅读地址为 https://docker-curriculum.com/#introduction；这里只保留课件链接，不声称本次重新核验了教程。

p.13–14：重开既有容器与远程Linux

图p.13通过Remote Explorer的Dev Containers入口重开已有环境，避免无意新建另一个工作根。p.14给远程路径：先SSH到课程网关，再到Linux服务器；替代方案需CSE VPN。这些主机名是课件信息，本次没有联网登录验证可用性。无论本地还是远程，先确定源码在哪个文件系统、命令在哪个系统执行，再解释编译结果。

p.14 的完整远程命令顺序如下，YourUnixName 是需自行替换的账号占位，不是实际账号；第二条在成功进入网关后执行。

ssh [email protected]
ssh linux2

原页替代路线为先连接 CSE VPN，再从终端执行 ssh [email protected]。这段保留来源提供的主机名，本次未发起登录，也未把该历史地址当作已验证可用的服务。

补充：重新打开项目与重建环境解决的问题不同。 重新打开一个已经配置好的工作目录，目的是进入与它关联的开发环境；重建环境则会重新创建环境层，可能需要重新安装依赖。源码能在挂载目录中保留，不代表旧环境里手动装过的所有软件都自动变成可恢复配置。

判断是否真的需要重建，先定位故障发生在哪一步：编辑器尚未进入目标环境、终端目录错误、编译依赖缺失，还是程序自身报错。前两类只需纠正入口与路径，不能靠反复重建证明代码正确。课件的步骤用于理解这几个层次；具体按钮与软件版本采用当期说明，不把历史截图当成当前界面的保证。

本讲核心考点

• [C] 说明宿主系统与课程编译执行环境为何可能不兼容。
• [C] 正确辨认工作根、.devcontainer配置目录与容器/work。
• [C] 解释源码挂载和容器依赖的持久性差别。

附录

本份没有需要移至附录的长推导；计算过程已在对应页正文写全。

来源与证据

• 原件：Lab01-环境配置与编译-2026T1.pdf（本地课件）；PDF副本（本地课件） p.1–14。本文页码均为 PDF 页号。

• 考试证据：读了 课程大纲-2026T1.pdf、教学计划-2026T1.pdf、T08-期中参考-2025T2-题目-解答.pdf、T07-多级反馈队列-2025T2.pdf（p.13–15内嵌历史试题）；未识别用途的 PDF：无

• 2026-10-13 内容补全：保留原页顺序与版本，补入对应页的程序、接口、字段、条件和演算；原程序片段保留课件行号、拼写与省略处，不能据此视为经过编译的完整软件。本文已有运行记录属于其标注日期，本次未重新运行课程容器或提交作业。