K8s grinds my gears, and yet, I'd rather debug it than, or beholden to, AWS or Azure, every day of the week

I've been following Theia for years (hi GitPod people), though mostly lost interest when vscode started being browser accessible, and back when they were using that old UI stack.

But I'm confused, how does this compare with code-server, or openvscode-server?

I use the latter in a web browser to do fully remote dev on my beefy machine hooked up to Google Fiber.

It kind of seems like this isn't something I need to consider, unless I wanted to ship my own custom white-labeled IDE. (Which... Nah, and why?)

because the tooling for VS code extensions to be part of the VS code UI is lackluster. It shoehorns people and prevents the development of something like a fully integrated SQL workbench. Or a form editor. Or reusable property panes, editor widget UI. If vscode had those things, it would be a proper IDE. Take for example this outline view: https://raw.githubusercontent.com/eclipse-theia/theia/master... - not something that would be easy to integrate into VS code as an extension. Very nice work. Why VS code doesn't have it is probably related to cannibalizing other MS products.

Odd example - VS Code already has an outline view, and it’d be very easy to build one yourself as an extension if you wanted. (TreeViewProvider API).

With the addition of Webview Editors and Views there’s not really anything an extension can’t do to its UI. Notice this is very different from saying there’s not much an extension can’t do to VS Code’s UI. Extensions are given a box, and they gotta stay in it. Personally, I’m fine with that.

The outline view has been part of VSCode for years though

HN. Very free market. Except Apple. The cognitive dissonance, and entitlement is crazy.

Even funnier after years of "Apple knows best". God forbid anyone buy an Android phone. No, apparently folks would rather force their abuser to be slightly nicer and then stay in that toxic relationship.

Yeah, it's crazy there's no other options, like a platform that openly allows sideloading. Its terrible that were all forced to buy Apple products, especially when this behavior from them is just so surprising.

/s in case.

Time to re-read "Fall, or Dodge in Hell".

I feel it might be more unsettling than when I read it ~5 years ago.

Its not black magic. Its yet another one-off nat hole punch implementation. Absolutely no reason to even think of this when tailscale exists.

Nickel feels like my end game for this kind of thing.

How about Mozilla figure out wtf is going on with their builds being language specific and it basically being impossible to convert Spanish Firefox to English Firefox. Absolutely baffling. (No really, changing the spell check language doesn't change the spell check language and you can only side-load non-official English spell check packs in the Spanish build. Its one of those things where so many wrong decisions had to be made, and leaves users out to dry.

Or, at the very least, don't do the same stupid crap every other site does, aka: sniff my geo-ip and then opaquely serve me a specialized build without my knowledge. Just another thing on the list of reasons why i don't bother being a Firefox advocate anymore. There's so many basics not accounted for.

I got so excited, but it doesn't seem to support multiple keys and seems overly eager to encourage people to leave a valuable key lying around on disk.

So if a single dev machine is compromised, all of your prod secrets are exposed?

I wish this were closer to sops with support for gpg and or ssh keys. Because sops is a great idea locked in a questionable codebase.

Happy to discuss a proposal to add asymmetric key support to the project in the GitHub issue tracker. Although I'm not sure how the security changes with an asymmetric key, as either way the worst case scenario is the same?

Note that you don't have to leave the key "lying around" as you can secure it the same way you would an asymmetric key. And it certainly beats leaving the plaintext secrets themselves lying around in a .env file or similar.

EDIT:

I see you were saying "dev machine" exposes "prod secrets" but that's not the case. The protocol is designed so you would have secrets.json and secrets.prod.json, encrypted with different keys and (necessarily) managed separately but with the same tools and api. Dev machines being compromised compromises dev keys, not prod keys.

Read the last section in the README on GitHub for more on the dev/prod split.

Asymmetric keys mean you can you can have per-dev or per-team keys and allow one team to rotate them and resign them for all other consumers. I don't know how you'd do that with symmetric keys. This is an important feature of sops, imo.

It also means I can do things like seal them to a key that is stored in KeyVault and then allow the transparent retrieval of that key at runtime on Instances that have been given an identity with access.

This means that production secrets are sealed in place and only openable by effectively authenticated workloads.

And if you use sops-nix, this becomes a "setup once and never think about it ever again, ever" kind of operation.