| 15 Sep 2025 |
 🐰 xiaoxiangmoe | But not build in source | 11:53:22 |
 K900 | So you have to ship Microsoft binaries or vscodium | 11:53:20 |
| K900 | ^ | 11:53:30 |
 Randy Eckenrode | It also still wouldn’t have access to the extension store. | 11:53:30 |
| K900 | You can't use the extension store on unofficial binaries | 11:54:33 |
| 🐰 xiaoxiangmoe | Would code-oss redistributable? | 11:54:35 |
| K900 | By EULA | 11:54:36 |
| K900 | Not if you just build the sources exactly as they are in the repo | 11:55:21 |
| K900 | If that's what you mean by "code-OSS" | 11:55:32 |
| K900 | That's the point | 11:56:09 |
| K900 | And why vscodium and such exists | 11:56:18 |
| 🐰 xiaoxiangmoe | Maybe I can make it and mark it as unfree? | 11:57:34 |
| 🐰 xiaoxiangmoe | 🤔 | 11:57:40 |
| 🐰 xiaoxiangmoe | Visual Studio Code is a distribution of the Code - OSS repository with Microsoft-specific customizations released under a traditional Microsoft product license.
| 11:58:45 |
| K900 | Why do you want this so much? | 11:58:46 |
| 🐰 xiaoxiangmoe | * Visual Studio Code is a distribution of the Code - OSS repository with Microsoft-specific customizations released under a traditional Microsoft product license. | 11:58:55 |
| K900 | And what is the problem with just using Microsoft binaries or vscodium? | 11:59:12 |
| 🐰 xiaoxiangmoe | I want to it built in source | 11:59:33 |
| K900 | Why? | 11:59:50 |
 emily | a source VSCodium build sounds sensible | 12:38:46 |
| emily | or do we already have that | 12:39:12 |
| K900 | IIRC we fdo | 12:39:27 |
| K900 | * IIRC we do | 12:39:28 |
| emily | I think VS Code has binary blobs | 12:47:25 |
| emily | so probably a source build of it does not make sense | 12:47:35 |
| emily | sadly https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vscode/vscodium.nix | 12:48:13 |
| emily | so there is benefit to be had here | 12:48:19 |
| emily | Randy Eckenrode: wrt darwin.libcxx version, we can either maintain a mapping from SDK versions to libc++ versions, or I could just hard-code apple-sdk_15 in the derivation and we assume that's the one being used. I kinda lean towards the latter since now that Swift gets its own libc++ headers there are no users of overrideLibcxx left, and it's simpler? | 17:10:39 |
| emily | we no longer have Clangs old enough for version compatibility to be an issue | 17:11:48 |
| emily | thankfully | 17:11:49 |
