微软:你好用户,我是你爹

两个路人

联想到outlook被玩坏，现在三哥扎堆终于由量变引起了质变呀

r_ex

这glibc就是毒瘤。不知道llvm libc现在怎么样了，能用吗

—— 来自 Sony XQ-DQ72, Android 13上的 S1Next-鹅版 v2.1.2

posthoc

虽然微软连依赖版本都不检查十分草台，不过用lts的还要在非官方源软件上面追最新版本本身就是问题操作吧。贴吧还看到一个人为了vscode重装了服务器的glibc的，然后理所当然的寄了。

hgfdsa

微软自家win10，18年的版本停止支持了，你个第三方系统18年的版本还想指望微软？

hgfdsa

posthoc 发表于 2024-2-5 16:02
虽然微软连依赖版本都不检查十分草台，不过用lts的还要在非官方源软件上面追最新版本本身就是问题操作吧。 ...

有啥草台，10年支持是Canonical自己要搞的，当然该他自己维护。

如果现在有人砸钱成功的让微软重新支持xp，是不是那些连win8都不支持的主流厂商都成了草台？

御坂MKII

posthoc 发表于 2024-2-5 16:02
虽然微软连依赖版本都不检查十分草台，不过用lts的还要在非官方源软件上面追最新版本本身就是问题操作吧。 ...

它天天跳更新的弹窗还能不让人点的吗

posthoc

hgfdsa 发表于 2024-2-5 00:38
有啥草台，10年支持是Canonical自己要搞的，当然该他自己维护。

如果现在有人砸钱成功的让微软重新支持x ...

我不是Ubuntu用户不知道具体情况如何，不过包管理器安装之前检查依赖版本是否符合要求是常规操作吧，apt不会没有这个功能，那么微软在自己提供的包（应该是一个微软官方的源）里应该标记最低glibc版本2.28，这样就会直接无法更新，而不是现在这样更新了之后break。

Prushka

谁维护，谁打包，谁负责

论坛助手,iPhone

posthoc

御坂MKII 发表于 2024-2-5 00:44
它天天跳更新的弹窗还能不让人点的吗

装完机第一个干掉的就是packagekit

可爱美味祥子

类比一下假如Win11要求最低16G内存，然后微软无条件给所有Win10用户推送更新，系统升级完了，8G内存用户发现进不了系统了

Midnight.Coup

LTS 的是 Ubuntu 又不是 VSCode算给大家一点小小的 Linux 兼容性震撼
微软给的方法也很简单：滚回 VSCode 1.85

hgfdsa

posthoc 发表于 2024-2-5 16:46
我不是Ubuntu用户不知道具体情况如何，不过包管理器安装之前检查依赖版本是否符合要求是常规操作吧，apt ...

看了下github，报错是在windows远程开发，但是远程服务器装不了对应版本的vscode server，因为glibc版本不对，没有安装成功，所以开启远程开发失败。
直接ubuntu上apt安装，装上的版本肯定能用，正常的源都会分版本。

御坂MKII

pm 没搞清楚他们现在的位置，vscode 现在是使用量大的基础软件，而且使用者里的绝大多数并不是直接面向个人终端用户的开发者。升级问题最简单的当然就是个人终端用户，升级就升级。但是升级问题在整个使用链路是会被逐步放大的，有太多原因没法升级了，机器是公司it维护的，是大学it维护的，开发者开发的是另一个基础软件然后那个基础软件有自己的Linux支持要求所以开发环境会同样被锚定的看另一个issue https://github.com/microsoft/vscode/issues/203375 里有多少 centos7/rhel7 的就能知道 vscode 要面临的实际问题有多复杂了。然后它最开始居然连检查 warning 都没报就直接炸掉打不开了

hgfdsa

御坂MKII 发表于 2024-2-5 17:16
pm 没搞清楚他们现在的位置，vscode 现在是使用量大的基础软件，而且使用者里的绝大多数并不是直接 ...

In this milestone, we have updated the toolchains to build our desktop client. From this release onwards, VS Code desktop is only compatible with Linux distributions based on glibc 2.28 or later, and glibcxx 3.4.25 or later, such as Debian 10, RHEL 8, or Ubuntu 20.04.
If you are unable to upgrade your Linux distribution, the recommended alternative is to use our web client. If you would like to use the desktop version, then you can download the VS Code release 1.85. Depending on your platform, make sure to disable updates to stay on that version. A good recommendation is to set up the installation with Portable Mode.

升级日志里面这段不知道是一开始就有还是被喷后加的，当然了，正常人谁看升级日志。

Nyan_arzine

工作机的Ubuntu 18.04 WSL懒得动了，降级VSCode+禁用更新完事
降级完VSC后还需要把WSL的插件也降一下级

win8

glibc不能安装多个版本的嘛？

Hieda

所以是微软推送了主动更新，用户点了确认？

ubuntu不熟，按照我理解包管理打包时应该要补丁去掉自动更新功能的

如果是用户自己装的就是另一回事了感觉符合vscode用户刻板印象

Rainwedell

这几天软子从Xbox到Outlook再到这个，咖喱溢出了这是？

xmcp

Hieda 发表于 2024-2-5 18:01
所以是微软推送了主动更新，用户点了确认？

ubuntu不熟，按照我理解包管理打包时应该要补丁去掉自动更新功 ...

一般情况是在windows上安装vscode用ssh远程连接到ubuntu开发。

于是vscode在windows上提示更新，但没有警告glibc的兼容性问题，用户点了确定，然后就再也连不上ubuntu了

御坂MKII

win8 发表于 2024-2-5 17:58
glibc不能安装多个版本的嘛？

它现在只检测了系统的 glibc（全局的 LD_LIBRARY_PATH），多版本维护的话大部分人不会动系统的。
centos7 rhel7 之类的，敢动系统 glibc 大概率就是整个服务器陪葬（

Orianna

我用 vscode 记笔记。1.86 markdown 自动完成有问题，比如代码块不能自动带出来后面的 ` 或 ```。

limon

大概是 vscode-server 对 glibc 有要求，这种应该可以自己下一套 glibc，然后 patchelf set-rpath，nixos 都这么搞

—— 来自 S1Fun

Midnight.Coup

Flatpak 版本目前还是 1.85，只能说 Docker 的出现几乎是必然

noahhhh

更新公告都写了还嗯更新，真把微软当自己爹了，啥事都要管
Linux minimum requirements update
In this milestone, we have updated the toolchains to build our desktop client. From this release onwards, VS Code desktop is only compatible with Linux distributions based on glibc 2.28 or later, and glibcxx 3.4.25 or later, such as Debian 10, RHEL 8, or Ubuntu 20.04.

If you are unable to upgrade your Linux distribution, the recommended alternative is to use our web client. If you would like to use the desktop version, then you can download the VS Code release 1.85. Depending on your platform, make sure to disable updates to stay on that version. A good recommendation is to set up the installation with Portable Mode.

御坂MKII

noahhhh 发表于 2024-2-5 21:30
更新公告都写了还嗯更新，真把微软当自己爹了，啥事都要管
Linux minimum requirements update
In this mil ...

https://github.com/microsoft/vscode/issues/203375
因为 vscode remote 极大的在各种团队里使用，压力已经是在按照团队的级别而不是个人在逐层转移了，另一个 issue 里已经是 cloud service manager/团队 manager了。

按目前过于粗暴的动态库检查办法，有太多内部维护的大型集群环境连靠 admin 或者个人本身简单的搞个 non default glibc patch 的方式来让 vscode remote 正常工作都做不到

It will make all Amazon Linux 2 (AL2) EC2 machines unable to use VS Code, while also affecting enterprise users who may use customized or parallel versions of the glibc library for their own development needs.

A number of leaders at Amazon are tracking this issue, we are very concerned about the impact to those customers and hopeful we can work with you on a workaround like Will suggested.

My org (not amazon) is on a RHEL7 compatible OS for the time being. It's EOL'd later this year, but not for several months if i understand correctly. I'm sure there are many people out there in a similar situation.

Thank you so much for your work; I lead a team of cancer researchers and part of a consortium of ~100 people with many proudly using now VSCode for data analysis and software development. Our academic systems (HPC of research centers hosting thousands of people) do not satisfy the new minimum requirements and this new update has become absolutely disruptive for us.

Chipping in as a software engineer at an MNC developing enterprise-grade software, this issue seems to affect a significant number of developers here as well.

すぴぱら

猜猜debian用户为什么没叫
哦 死人不会说话

正云明宏

微软最近出的问题是不是有点太多了，难绷

antugar

有时候有些软件的自动更新防不胜防，mac上装了一个vscode主要是看文档的，刚连上热点在后台给更新了，连个弹窗都不给

Midnight.Coup

antugar 发表于 2024-2-5 23:25
有时候有些软件的自动更新防不胜防，mac上装了一个vscode主要是看文档的，刚连上热点在后台给更新了 ...

然而 Linux 上 VSCode 不会自动更新，而是和其他软件一样通过包管理更新或者手动下载 tar 解压覆盖，会有 glibc 检查
自动更新的是本地客户端(macOS/Win)和上面的插件(Remote Development extensions)，然后插件跟随本地版本，自动更新服务器端的 VSCode Server毕竟 VSCode Server 不会单独安装

plumlis

主要是你去微软官方下载 vscode，会自动添加微软的软件源，所以更新的时候就是直接从微软下载的 deb

canonical 提供的 10 年更新，人家提供的是 snap 的版本

Midnight.Coup

再给一年时间过渡远程插件更新 VSCode Server 的时候没做 glibc 检查，建议下次更新的时候自带，或者规范点通过包管理装

想想 Ubuntu 24.04 长达 12 年的 SLTS 版本，过半怕不是就会出事，3 万个自带包得专门雇人 backporting，然后 VSCode 这种是要维护一个开源版吗

香港记者巴拉森

御坂MKII 发表于 2024-2-5 17:16
pm 没搞清楚他们现在的位置，vscode 现在是使用量大的基础软件，而且使用者里的绝大多数并不是直接 ...

centos7和各路严重路径依赖的运维们真的是毒瘤，一个用了十几年的内核还要装在一台新机器上用

可爱美味祥子

香港记者巴拉森 发表于 2024-2-6 12:55
centos7和各路严重路径依赖的运维们真的是毒瘤，一个用了十几年的内核还要装在一台新机器上用 ...

这不怪运维吧

有的商业软件安装环境就是红帽特定版本或者CentOS特定版本，运维只是负责维护的

limon

Midnight.Coup 发表于 2024-2-6 10:03
再给一年时间过渡远程插件更新 VSCode Server 的时候没做 glibc 检查，建议下次更新的时候自带，或 ...

这个的确只能 ubuntu 自己解决，不可能我一做软件的配合你 12 年的支持周期

wewai

研究了一下，感觉这个锅很难完全扣到微软头上

这个应该是万恶之源 https://github.com/microsoft/vscode-linux-build-agent/issues/41 [Breaking change] Update build agent distros · Issue #41 · microsoft/vscode-linux-build-agent VSCode 官方版本的服务端之前使用 RHEL 7 系 + Node.js 16 构建，但是 Node.js 16 在去年⑨月份就 EoL 了，观察 Node.js 的版本历史（ https://github.com/nodejs/releas ... nd-of-life-releases ），会发现 16 的支持周期比较短，因为它依赖的 OpenSSL 1.1.1 在同一时间 EoL 了： https://nodejs.org/en/blog/announcements/nodejs16-eol Node.js — Bringing forward the End-of-Life Date for Node.js 16 ，导致 Node.js 16 必须提前终止支持（正常的话是到今年 4 月）。再往前倒是 OpenSSL 的下一个版本 3 在 21 年 9 月才发布，而 Node.js 16 计划是在 21 年 4 月。不过说来 OpenSSL 3 的 LTS 是到 26 年⑨月，今年 4 月再没有新的 LTS 版本的话同样的屎估计可以贷款再吃一遍了，也不知道他们打算怎么处理这个问题。

所以 VSCode 就升到了 Node.js 的下一个 LTS 也就是 18。Node.js 之前也是用 RHEL 7 系构建的，但是 18 的 EoL 时间（25 年 4 月）就又又比 RHEL 7（24 年 7 月）的要晚了，这个简单，换个环境就是，于是升到了 RHEL 8，glibc 版本要求也对应从 2.17 升到了 2.28（ https://github.com/nodejs/node/pull/42659 doc: update minimum glibc requirements for Linux by richardlau · Pull Request #42659 · nodejs/node ）。VSCode 也对应把构建环境升到了 glibc 2.28 的（ https://github.com/microsoft/vscode-linux-build-agent/pull/43 refactor: migrating from containers to sysroots by deepak1556 · Pull Request #43 · microsoft/vscode-linux-build-agent ）。

然后就是安静的两个月，然后有一天微软那边 PM 发布完新的 1.86 版本下班，然后就喜闻乐见的炸了。

RHEL 8 这个东西很有意思，或者说整个 Linux 世界这方面都很有意思，请欣赏：
Amazon Linux 2 - glibc 2.26; Ubuntu 18.04 - glibc 2.27; RHEL 8/Debian 10 - glibc 2.28
所以因为 Node.js 那边用 RHEL 构建，而 RHEL 8 恰好是 glibc 版本最新的（虽然就差一两个版本，主要是比 Ubuntu 晚一年发布），于是 RHEL 8 构建出来的东西把前面两个拉一起 A 了。（别跟我提 CentOS 7，我永远不会同情 CentOS 7 用户）
（另外 Debian 9 早就 EoL 了，Debian 10 看起来不会出问题，版本遥遥领先）
当然这些系统不是已经过时了就是马上就要过时了，人要向前看，对于新的系统，我强烈建议各大开源项目使用 Debian 12 构建，请欣赏：
RHEL 9 - glibc 2.34; Ubuntu 22.04 - glibc 2.35; Debian 12 - glibc 2.36



微软这个东西会出问题，大概是因为他们触了两条一般不怎么会在意的线，一个是不同 Linux distro 子生态的线（虽然都叫 Linux 但不一定通用，要看脸），另一个是终端和服务器的线（虽然他们把两边的构建分开了但是然并卵）。当然 distro 可以糊，很多东西都可以帮忙糊（比如 OpenSSL 1.1.1 这玩意 distro 就都在糊 https://ubuntu.com/blog/running- ... eol-with-ubuntu-pro Running OpenSSL 1.1.1 after EOL? Stay secure with Ubuntu Pro. | Ubuntu ），但是微软这玩意我不咋看好，因为问题是出在 Remote 上面，然后他们是把 Remote 作为 VSCode 的专有功能，而不是 Code - OSS 的一部分的，这让社区怎么帮你糊。

马上过年了，送大家一副对联吧
本性难移，机关算尽 VSC，自讨苦吃
贪小便宜，纵容巨企 EEE，求仁得仁
横批 好死
（昨晚骑车还正好路过微软门口，就应该给它贴上）

---

倒是发现一个有意思的事情，Electron 虽然同时依赖 Chromium 和 Node.js 两个重量级，但是依赖倒是出奇地宽松，他们声称现在是在 Ubuntu 20.04 上构建，但是居然能在 14.04 上跑（ https://github.com/electron/elec ... le#platform-support ）。官方发布的 executable 里面最新也只引用了 glibc 2.17，甚至就连 VSCode 的 executable 也是这样。VSCode 会出问题不是因为 Electron，而是因为他们自己加了几个 Node native module（我也不是很明白为什么一个 JavaScript 程序会需要 spdlog 的 binding）。

Electron 虽然是在 Ubuntu 20.04 上构建的，但是是由一个 cross-compile 的流程完成的，使用的是 Debian 11 的 sysroot 环境（ https://github.com/electron/elec ... cript/sysroots.json ），继续看下去发现这个 sysroot 有学问，glibc 被动过手脚，他们搞了一个叫做 reversion 的东西来处理 glibc，把所有重名的高版本 symbol 都隐藏了（ https://github.com/electron/debi ... /reversion_glibc.py ）。这是 Chromium 里面的流程，被 Electron 继承过来了。不过 VSCode 貌似现在也是使用了 Debian 11 的 sysroot 来 cross-compile，但是他们的 sysroot 看上去就是拿官方包拼的（见 #43）。

Midnight.Coup

wewai 发表于 2024-2-7 03:33
研究了一下，感觉这个锅很难完全扣到微软头上

这个应该是万恶之源 https://github.com/microsoft/vscode-l ...

万恶之源 glibc以及只要追求复用就会有的典中典的“Dependency Hell”，经常和包管理一起出现
Windows 过去也有 DLL Hell，现在的 .Net Hell，还有 JAR Hell

可爱美味祥子

Midnight.Coup 发表于 2024-2-7 14:50
万恶之源 glibc以及只要追求复用就会有的典中典的“Dependency Hell”，经常和包管理一起出现
Wind ...

VC/VB运行库大礼包（2005-2024）
.net 2.0-4.x挨个装一遍

Midnight.Coup

可爱美味祥子 发表于 2024-2-7 16:21
VC/VB运行库大礼包（2005-2024）
.net 2.0-4.x挨个装一遍

VC 运行库一般也不用全装，除非打老游戏，.Net 2-3.5 基本自带了，.Net Core 按需装，DX9.0c 也要装一下
不过 Linux 的软件依赖真有这么简单就好了