Aleksandr Ilin

Okay, it's actually `2_35` vs `2_31` which are glibc versions, and here is what I have: ``` ⬢ [Docker] ❯ ldd --version ldd (Debian GLIBC 2.31-13+deb11u11) 2.31 ```

It seems that in my case solution was to move from `bullseye` to `bookworm`: ``` ⬢ [Docker] ❯ lsb_release -d No LSB modules are available. Description: Debian GNU/Linux 12 (bookworm)...

I'd keep this issue open but repurpose it to improve debug logging in `is_supported_by_environment()` so It would tell that my glibc is too old.

I think some kind of fuzzy search or levenshtein distance would allow to filter supported tag and then do some additional parsing / explanation.

Will do thanks!

 # `.devcontainer/devcontainer.sh` ```bash #!/usr/bin/env bash set -euxo pipefail DEVCONTAINER_DIR=$(dirname $0) WORKSPACE_FOLDER=$(dirname "${DEVCONTAINER_DIR}") function cleanup() { CONTAINER_ID=$(jq -r .containerId .devcontainer/up.json) docker rm -f "${CONTAINER_ID}" } trap cleanup EXIT devcontainer --workspace-folder...

I feel like it worked already before... P. S. VSCode: 0 Me: 1 ```json "customizations": { "vscode": { "settings": { "tasks": { "version": "2.0.0", "tasks": [ { "label": "echo", "type":...

Maybe, it does feel like I only started to notice it after I started to use secret for SSH key.

Weird, I disabled `redhat.vscode-yaml` in Dev Container but I still have it installed after rebuild container command. ``` [Error - 11:57:31 PM] Server initialization failed. Error: command 'jumpToSchema' already exists...

How do I ban `redhat.vscode-yaml` for good? ``` ⬢ [Docker] ❯ grep redhat.vscode-yaml .devcontainer/devcontainer.json // "redhat.vscode-yaml", # TODO:command 'jumpToSchema' already exists ``` It seems it's still being installed as dependency...