Mailing List Etiquette was freebsd vs. netbsd
freebsd at edvax.de
Tue Jun 16 15:51:22 UTC 2020
On Tue, 16 Jun 2020 17:18:43 +0200, Chris Knipe wrote:
> > > 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".
> You hardly get good support these days from companies irrespective of how
> the email is formatted, so for the most part I don't personally bother with
> emails to begin with.
It's good that in general and everywhere, companies invest in
skilled personnel rather than shiny ads promoting their services.
And instead of employing good programmers, they employ designers
so at least the ad-filled emails look good, even if it doesn't
help anyone. :-)
> Google for the most part, yields much better
> results, and for the most part I don't need to care how an email is
> formatted. Again, we live in an online, and connected world (for the most
People with technical problems (who address the mailing lists)
often don't. That's why they ask for help.
> > > 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.
> And I copy and paste that into a text editor, it formats perfectly.
This is as it should be. Stupid MUAs would have rearranged this
into a single line:
> > 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.
It displayed in a paragraph to fit the user's settings. (I see this
already in my composer window: formats nicely, adapts when I change
the window size, and is absolutely useless.)
The problem is not MUAs doing the right thing. The problem is MUAs
"knowing better" and doing the wrong thing, therefore stopping the
user from properly reading and dealing with a message.
> agree with you, the MUA is the problem - I maintain what I'm saying
> however, you're not going to change the MUA, and you're not going to change
> what MUA users use, or don't use. There is no solution to this. We can go
> on about this every few years, as has been happening on this mailing list
> every few years since I've been subscribed to it.
We can try to do the best with the tools we have, try to create
better tools, and hope users will, sooner or later, use the
better tools available. But as you know from history, the last
part probably isn't going to happen. :-)
> But if I'm offline, I might not have access to my email either? I fail to
> see the difference?
Use the concept of "online on demand": Connect, get, disconnect.
Read and write. Connect, send, disconnect. There are users for
whom this is the normal way they participate on mailing lists,
and sometimes the only way they can afford.
For synchronous communication, there are other tools (that will
force "always online"), such as IRC, web chat, or any of the
smartphone-based messenger services.
> Then please don't insult me either.
Where did I? (That's a honest and non-polemic question, I'm not
aware I did, especially not on purpose.)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions