user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: "Σταύρος Ντέντος" <>
Cc: Eric Wong <>
Subject: Re: [PATCH v1] git-send-email-reply: Append subject
Date: Sat, 27 Mar 2021 16:01:50 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210327095431.GA32057@dcvr>

With regards,
Ntentos Stavros

On Sat, 27 Mar 2021 at 11:54, Eric Wong <> 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
> "public-inbox" is already a long name, and
> "" is kinda annoyingly long.
> (and I've been preferring <|>/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.

> 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`.

  reply	other threads:[~2021-03-27 14:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 16:31 Stavros Ntentos
2021-03-26 19:36 ` Eric Wong
     [not found]   ` <>
2021-03-26 21:35     ` Eric Wong
2021-03-27  8:39       ` Stavros Ntentos
2021-03-27  9:54         ` Eric Wong
2021-03-27 14:01           ` Σταύρος Ντέντος [this message]
2021-03-27 19:32             ` Eric Wong
2021-03-28 16:00               ` Σταύρος Ντέντος
2021-03-28 22:58                 ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \
    --subject='Re: [PATCH v1] git-send-email-reply: Append subject' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).