HackerTrans
TopNewTrendsCommentsPastAskShowJobs

flubbergusto

no profile record

comments

flubbergusto
·السنة الماضية·discuss
> I recently spent a few hours evaluating different terminals. I went back to urxvt, tried Alacritty again, gave Ghostty a try, and spent quite some time configuring Kitty. After all this I found that they all suck in different ways

Last time I did the same (days not hours tho lol) was somewhat surprised to find myself landing on xterm. After resolving a couple of gotchas (reliable font-resizing is somewhat esoteric; neovim needs `XTERM=''`; check your TERM) I have been very pleased and not looked back.

urxvt is OG but xterm sixel support is nice.
flubbergusto
·السنة الماضية·discuss
Have any issues with mupdf? I find it suckless.
flubbergusto
·السنة الماضية·discuss
Sure, but at least those of us reading this thread have learned this lesson and will be prepared. Right?
flubbergusto
·السنة الماضية·discuss
This is supported in the client/daemon. You configure your client to use a self-hosted registry mirror (e.g. docker.io/distribution or zot) with your own TLS cert (or insecure without if you must) as pull-through cache (that's your search key word). This way it works "automagically" with existing docker.io/ image references now being proxied and cached via your mirror.

You would put this as a separate registry and storage from your actual self-hosted registry of explicitly pushed example.com/ images.

It's an extremely common use-case and well-documented if you try to RTFM instead of just throwing your hands in the air before speculating and posting about how hard or impossible this supposedly is.

You could fall back to DNS rewrite and front with your own trusted CA but I don't think that particular approach is generally advisable given how straightforward a pull-through cache is to set up and operate.
flubbergusto
·السنة الماضية·discuss
VMs are great for coarse isolation ("dev box", "web surfing", etc). A typical qubesos workstation would have a handful.

In the setup I linked, separation is more fine-grained. Ephemeral container for each cargo/nodejs/python/go/gcc process. The IDE is in a separate container from its own language servers, and from the shell, which is separate from both the X server and the terminal window, the ssh agent, etc. Only relevant directories are shared. This runs my devenv with vscode fine on a 16GB RAM 8c machine.

You'd need like 1T RAM and over 9000 cores to have that run smoothly with real VMs ;)

Basically containers can give you far more domains (with better performance and weaker isolation) on the same host.

The other upside is that the entire containerized setup can be run as unprivileged user. So an escape means they are still nerfed local user. A typical VM escape would have much shorter path to local root.
flubbergusto
·السنة الماضية·discuss
I think containers is the way to go. Maybe on top of VM (defense in depth-swiss-cheese is the only way to go imo). Something like Qubes can be great for VMs.

https://github.com/legobeat/l7-devenv/pull/153

This works for me (which I do run in VMs also, yes). A key thing is some secrets like GH token and signing keys are not available even for the IDE and code in the environment requiring them. Like a poor-mans HSM, made for dev, kinda. Also LLM assistant gets access to exactly what it needs. No more, No Less.

You can have your cake and eat it too.

https://github.com/legobeat/l7-devenv
flubbergusto
·قبل سنتين·discuss
[dead]