Mailing List Etiquette was freebsd vs. netbsd
freebsd at edvax.de
Tue Jun 16 15:09:12 UTC 2020
On Tue, 16 Jun 2020 16:21:52 +0200, Chris Knipe wrote:
> On Tue, Jun 16, 2020 at 4:06 PM Aryeh Friedman <aryeh.friedman at gmail.com>
> > Simple - don't email it. If you do, attach it as an attachment (MIME is
> >> there for a reason)...
> >> There's GIT / CVS / Take your pick for a reason... :-)
> > If you don't like email then you should not be using FreeBSD because for
> > better or worse the community has standardized on email as the primary tech
> > support venue and thus absolutely needs to have something that can be used
> > to give tech support (including 100% accurate cut and pasting).
> And again - there's absolutely -nothing- wrong with that at all, I never
> said that there was... Millions of companies provide support to millions of
> users every day using email... That being said, I get a 80 character plain
> text email from a company as "support," I deem that as unprofessional, and
> the email will more than likely just be deleted. We live in modern times,
> unfortunately. Presentation matters, whether you like it or not.
Interesting apoach. Do you value presentation more than content?
In case of support, personally I would want something that helps
me solving my problem, not something that looks good. Sadly, the
"looks good" has lead to many technically inferior solutions
becoming a de-facto standard, because the better solutions simply
"don't look as good".
> Cut & paste from the attachment, then you won't have any formatting issues
> from any MUAs, but I guess it's too much effort to open the attachment.
Certain MUAs display the attachmend right underneath the message,
especially if it's things like images or text that can be easily
embedded. Depending on the MUA in use, getting the content of the
attachment requires one or more additional steps, but it should
not be a problem.
What _could_ be a problem is that the mailing list explicitely
does not support attachments in general, or only allows a specific
subset of formats (like plain text attachments).
But as I mentioned in an earlier message, sometimes code is "inlined"
in a message, or even in a paragraph, for example:
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/sysroot 213G 196G 480M 100% /
devfs 1,0K 1,0K 0B 100% /dev
tmpfs 5,8G 4,0K 5,8G 0% /compat/linux/dev/shm
procfs 4,0K 4,0K 0B 100% /proc
linprocfs 4,0K 4,0K 0B 100% /compat/linux/proc
And see that I didn't put any linebreaks here, so if a MUA now
goes ahead and collapses it into one line, then rendering that
line in a paragraph mode (ragged right or justified), depending
on your settings (font size, font face, window size etc.), it
became totally useless.
> There's plenty of solutions (UUEncode/BASE64, as you so nicely put it, has
> also been trialed and tested over many, many years, just FYI - it also has
> the benefit of < 80 characters wide), 80x25 is not one of them, and whether
> you like it or not, you will -never- get the world to adhere to a 80 (or 74
> or whatever) character wide email. The world has moved on, deal with it.
The choice of how wide a line of text in a message is is not
defined by the world; it's the choice of the writer. Sometimes,
you may intendedly _want_ to write things in a specific, non-
sometimes like this,
or even so,
that - think about it! -,
in the result,
the text gets a specific formatting which carries a certain
intention, defined by the writer.
I admit that this was a stupid example, but still a valid one. :-)
> The fact is, you should be committing your code to a repository, and
> checking said code out of said repository when you need it.
That is not a solution for a technical _discussion_, as I
mentioned in an earlier message. Sometimes you just want to
embed some code (in a broad sense) into your text, and to
employ external resources for claiming that
is a better endless loop than
is definitely overkill (that would be, with modern services, how
many HTTP requests for essentialls 2 lines of code?). I could've
added some comments that should not be line-broken... :-)
> No, code
> should not be shared via email - and if you do then so be it - your choice,
> not a requirement. You don't need to email the code, all you can do is
> email a URL to your commit / diff...
As I said, things like external code storage and submission
including version control have their place, but they are surely
not the tool of choice for including code snipperts in the
kind of discussions taking place on this mailing list.
Again, see the word "code" as anything that should be presented
as-is: logs, configuration files, diagrams, formulas.
> Again, too much effort to open a URL
If you are offline, yes. Having a message full of external
resources and not being able to access them reduces the value
of said message to zero.
Now you might say, but it also appears in the archives, which
are "online by definition" - great, so if an external resource
goes to 404 or the company responsible for hosting goes belly-up,
or gets bought by a bigger fish just to discontinue their service,
you have noting.
But if you have a message that contains the code, you can still
get its value, because it is simply "in there".
> I forgot that in the old days without GUIs, we couldn't even double
> click. I guess you still can't today.
Please don't insult people. And: Yes, there are a few users who
probably can't click, or use any GUI at all. They surely are a
minority, but excluding them just by being in "snob mode" is not
fair. Yes, I'm primarily talking about users with extremely
limited eyesight, and blind users.
> Again, it's the minority that is sharing code via email... In fact, I would
> say very, very, very little people do it.
You are free to check the mailing list archives, just to discover
that this has been successfully done for decades.
> Oh - and I love email.... Never said I didn't.
Always use the right tool in the preferred way of a specific
context to achieve the most value. There is no "one size fits
all" egg-laying wool-milk-sow. :-)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions