Threads for 0blivian
-
What the article doesn’t spell out is that at least on etcd 2.x, activating user/password authentication is a true performance killer. So if you want ACLs a bit more complex than “client has a valid TLS certificate to connect with”, you had to either take the huge performance hit, or get creative and proxy etcd via nginx to support a better auth model[1].
Even then, etcd has never been designed as something that could be exposed directly to the internet, I wouldn’t blame the developers for not foreseeing people ignoring the most basic security principles (like: don’t have any of your datastores directly exposed to the internet); but I would blame them for attaching an auth model post-facto to etcd, and for the fact that, along all the 2.x series, auth was basically unusable (see e.g. https://github.com/coreos/etcd/issues/5840 or https://github.com/coreos/etcd/issues/3223) and has been “fixed” in 3.1 and following releases by allowing to do RBAC based on the common name of a client TLS certificate…
-
While I like “simple” tools, and I share the appreciation of simplicity of the author, I don’t think having to maintain a C language patch tree to configure my window manager qualifies as simple - it means it lacks features that I need, and a clear extensible interface.
Given the article is well written, though, I decided to read up a bit on dwm, and right in the “differences” section of the homepage I found: “Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.”
I don’t know if that sentence wanted to be tongue-in-cheek, but that sentence turned me away.
Anecdotally, I do actually have binary packages of my dwm setup built by CI, pushed to a binary cache and then that cached package is what my tower (and another machine of mine) install and use. It’s pretty nice.
That seems like the most reasonable thing to do, but indeed it’s not simple :)
Out of curiosity, how do you manage the patches? You keep everything in a git repository and rebase upon upstream whenever there is an update, or you use some tool for managing patches on upstream like quilt?
I have my own fork of dwm here and just manually apply patches when I want new behavior. Sometimes I need to apply them manually (like with the patch file split against the source code of dwm), but I only end up learning more about my window manager by doing this. This also ends up working great with my NUR repo because I can just re-run the update versions of software script and it will bump the config here. When I commit this to the repo, Travis will pre-build the package and push it to cachix. Then when I rebuild the configuration on my desktop with
sudo nixos-rebuild switch, the new version of dwm will be pulled from my package repo and the binary built in CI will be pulled from cachix. This gives me all the advantages of building things from source and having binary packages.