----- Ursprüngliche Nachricht -----
Von: M. Andree
Gesendet am: 30 Nov 2010 18:14:39
>> Interesting. How does one know this if he's not the list maintainer?
> Read the list websites perhaps?
Well, there's no godly rule that a list must have a website nor does everyone subscribe
to a list through a web interface.
And there's no general rule what the name of a website has to be if it belongs to a list.
Maybe this is common to sourceforge lists, but there are many others.
Thinking that everything is the same everywhere as it is here and everyone must be
knowing this, is simply hybris.
This is not a mailing list about mailing lists for mailing list administration experts.
It is a list for mspgcc users, and neither mspgcc nor users implies special or even
general knowledge of what you think what is 'usual' for mailing lists.
Also, not knowing that something (that is not 'common' for 'everyone') is possible
implies that one does not actively search for it.
The list is/was working so why searching the web or reading manuals
Simply turning away is the easier choice. And saves much time.
And cannot be desireable.
>> Yes. The webmailer. Then the copies are in a private folder of the mailer,
>> and not where they are on my main system.
> My webmailers run off an IMAP server, no big deal here.
With the most important word written last.
That something is working for you does not mean that it is the global revelation for everyone.
Else everyone would use MAC, Linux, Windows (pick one and delete the others).
>> Anyway, as I said before, there i sno sense in forcing people to rearrange their
>> organisation to fit this group. As the reuired reorganisation needed of a different group
>> may be incompatible, leaving people to decide to use one of them but not both. That's
>> surely not the intention of a mailing list.
>Certainly there aren't individual persons, however helpful they are, to
>overthrow all common mailing list conventions.
Sure. As sure as the term 'common mailing list conventions' can be questioned.
'Sourceforge list conventions' or 'mailman based list conventions' or whatever, well, maybe.
But definitely not 'common'.
There's always a world beyond the own horizon. And who thinks he has the largest
usually has the narrowest.
>> Hmm, well, I didn't know and will look into this, but I doubt there's anything I can do.
> Yes there is. Use an IMAP or POP3 account to subscribe/reply, and Thunderbird.
Once more, you think just because things aren't working for others like they do for you means
that they use the wrong tools and have to change.
I don't like nor use outlook, but I don't try to force (this way or that) others to stop using it.
if Thunderbird is the only mail client that 'does it right' in your opinion, so maybe it's your opinion that's wrong.
That one or two clients implement features which are niche doesn't make them any standard nor is it a reason
to discriminate everything and everyone who does not use them.
if you want your world exactly as you think it has to be, then close your eyes and mouth and be happy
with yourself. Or accept that the world isn't as you think it should be. And that not everyone will agree to
what you think.
>> The mailing program I usually use is a portable low-footprint program that does not
>> mess with the inbox unless I explicitely tell it so.
> Mutt gets threading right, if that's low-footprint.
What's 'right'? That some mail client has introduced a more clever way to do threading than scanning the subject
is fine, but does not mean that everything else is wrong.
I also fought windmills in the past about how things should be. And I've seen many clever ideas failing agains
the less clever but more common (or better pushed) competitors. And I calmed down over the years.
Maybr you'll arrive at this point somewhen - If you didn't get an heart attack before.
>> No. IMHO, it increases the percentage of people who need assistance and therefore have to subscribe, by
>> filtering out a large number of those who could provide assistance 'on-the-fly' but won't due to the registration effort.
> So. It keeps the on-the-fly spammer out just the same.
indeed. But some spammers will find their way as well as some users. The question is what's the desired condition?
The two border-situations are clear: all interested users as well as any fly-by spammer or
no spammers, no effort, no tiem to spend but also no users. Both not desireable. Where to put the border?
"the optimum tax rate is between 0 and 100%"
Sounds obvoius at first, but on the second thought it has more than one deeper truth.
[about challenging list posters]
>> So you want to punish people because their provider uses a system you don't like?
>This isn't about punishing, but about adhering to decade-old conventions.
>Automated replies to list postings, to my personal address, are considered undue
>harrassment, a breach of conventions, and I consider that spamming.
To the first part I agree. To the last, partly.
Yet spamming is a problem anyway. Once more the question is where to put the border
between fighting spam and producing one through the fight against it.
Anyway, often people cannot do anythign against it except searching for another service.
Do they? Well, facebook still exists, so the obvious answer is: no. :)
>And consider the scare it gives if you are the on-the-fly "supporter" from your
>scenario and get a dozen challenges back. This mustn't happen, it drives
>(again, scares) far more people away.
Well, if they are really only on-the-fly-supporters, then they did their work before getting the 'spam'
So they surely won't return and delete their post. :)
No, that's not nice thinking, ignore the last sentence :)
>> Well, push the task of doing technical adjustments to users who are often unskilled inthis area or have
>> no influence on it, to keep work from the skilled operator. Great approach.
>Come on, we're talking about developers. If they can't be bothered to configure
> their mailers properly, how can they write decent software for a microcontroller?
We're talking about MSP developers. An MSP does not have enough memory to hold a typical linux makefile.
And has NOTHING to do with mailign list adminstration or common computer knowledge at all.
In many cases it does nto even mean that there are any programming skills above elementary school.
As one of the main supporters at TIs E2E community I know what I'm talking about.
People coming there often do not have the slightest clue how to start with the project they are paid for.
>> Plain text posting is a technique from the last milennium and neither up-to-date nor commonly available
>> unless you're system administrator and deliberately configure your system against the default.
>Yes. Mailman strips of the alternative text/html (which is useless and often
>dangerous) part and leaves the text/plain in no matter if it's in utf-8, koi8-r,
>iso-8859-* or us-ascii (usually), and if it's quoted-printable, base64 or whatnot.
Fine. Why not converting it to UTF8 or ASCII at teh same time? Then it's really plain.
>> Count how many people are doing plain tex tposting in this group. You and me and who else?
>> The rest is using mime-encoded, double-mime-encoded, Base64 encoding and others.
>So? The point is not letting random screenshots, excess HTML markup garbage
>from old Microsoft-weds-Office-to-the-Web style software that doesn't convey
>information but formats every word in an explicit font (I take it this got fixed
>in later versions of the software I have in mind), and random other attachments.
Well, you're right (especially with this specific software) But then again, where to stop?
Personally, I'd be happy if the texts weren't in mime multipart/alternative blocks but just plain.
But I can live with those mails which do. And didn't complain in the past.
But this is really going much too far. I never intended to start something that more and more
goes into the direction of a flamewar.
Nor did I want to be told that I have to change my mail client, OS, computer, work,
name, religion or whatever.
I just wanted to state (originally) that the proposed changes, as 'obvious' or desireable they
might look at first, might (will) have some side-effects that are neiterh obvious nor desireable.
If you or whoever decides it wants to go that way, fine. I can live with (or without) it.
And to the relief of the rest of the list, we should either stop or continue directly (but I don't see any
point in the second alternative)