With regards, Ntentos Stavros
On Sat, 27 Mar 2021 at 11:54, Eric Wong <[email protected]> wrote: > > I thought you said you deployed it :/ > > Oops :x I finished the deploy, now :> Yeah, I saw it a bit later :-p :-D > > Would it make sense for you to "symlink" /meta/ to /public-inbox/? > > (as it is for git.git --> /git/) > > Not really, since the address is [email protected]. > "public-inbox" is already a long name, and > "public-inbox.org/public-inbox" is kinda annoyingly long. > > (and I've been preferring <80x24.org|yhbt.net>/public-inbox.git > for the git repo). Remember that a symlink (or a 30x redirect) does not cost you anything :-p It _is_ longer, and it doesn't cost you anything, for the sake of "finding where is something where you look for it to be" ;-) > It's been a few years since I checked, but I seem to recall > there being an option in the web UI of Gmail. It does, and it is a bit hidden, and a bit global-ish: If you send e-mails at night ... > Everything I've read about Docker sounds scary when people are > grabbing binaries and code from random distributors and just > running it blindly. IMHO it encourages dangerous behavior. Pulling solely from "sane-ish sources" (buster from Debian and your code from your repo), should it be okay. The risks (as stated above) should ... > Having duplicates of things like libc or even Perl is total > overkill here and not remotely lightweight in my book. > > I don't expect anybody to trust me enough to run public-inbox > without reading it (which is why there'll never be JavaScript). > > We only distribute source so people can always read what they're > running. We even use a language that makes binary distribution > (nearly) impossible. ... be outweighed by benefits (clean add and remove, single-ish up-and-running command). Of course, you are right of claiming that anywhere, anything can be inserted - and the more you pull, the more things you expose yourself to. https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/ > I would never introduce any soft or hard dependency into a > project without being knowledgeable and comfortable about it, > first; and that can take a LOT of time and lead me down rabbit > holes... Yeah, me too :-D Having a more clean deploy&isolation&remove process would facilitate in me testing more and providing a cleaner patchset to you. You might have fixed my patchset yourself (thanks!) but not everyone is willing to spend time on it. On the other hand, I am not willing to "pollute" my system with something tying itself more or less to my system. (It's not the pollution that I am afraid of, but the sanitization afterwards). I've barely used chroots, and I am not comfortable using them (because they require sudo). Not to say that I am "that comfortable" using docker either! However, they have created a group which, if I add myself on it, it (hopefully) uses only the minimal set of required privileges to do, whatever it is that it does, without requiring me to type "sudo" (which, I keep telling to myself that it is "something dangerous" overall). If you have some tl;dr knowledge on how to make (s)chroots to work cleanly without any sudo (after I review a specific subset of rights & get myself access to e.g. `/var/chroots/*` directory), I am all ears! A lot of compiled deb packages use that one way or another, and (mistakenly?) I feel more comfortable installing via `apt-get install package.deb` than `make install`.
