From owner-freebsd-questions@freebsd.org Tue Jun 16 15:38:05 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 53F5A33F03B for ; Tue, 16 Jun 2020 15:38:05 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49mXQh1lZLz4BV9 for ; Tue, 16 Jun 2020 15:38:03 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.8.33.9]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.183]) with ESMTPA (Nemesis) id 1N8ojI-1irRYF0X1q-015sqe; Tue, 16 Jun 2020 17:38:01 +0200 Date: Tue, 16 Jun 2020 17:37:59 +0200 From: Polytropon To: Chris Knipe Cc: Aryeh Friedman , "Steve O'Hara-Smith" , FreeBSD - Subject: Re: Mailing List Etiquette was freebsd vs. netbsd Message-Id: <20200616173759.5368a67b.freebsd@edvax.de> In-Reply-To: References: <20200613154409.GA89618@neutralgood.org> <13115.1592302784@segfault.tristatelogic.com> <20200616071153.00006f4d@seibercom.net> <20200616075548.000066f1@seibercom.net> <20200616140416.bd7b8bf2.freebsd@edvax.de> <20200616142043.7d599458.freebsd@edvax.de> <20200616144141.6203d978e9bd43418b17dcbc@sohara.org> <20200616164751.dbc4888a.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:VcjNoOmPs0wKDwvV2RfB9e0LyZhXleQMqooDogTNJCMoILjT83X zI7p+cI1xLtsvTyR7zzVE3D+bR4hMD8zT38nhFJdJrj7J3La7UvNghjLgFJF6yr/Z1TAI/f Fwlxcz1Fpgz5xKKPAF2Iw+LmLDGXyUAXda3gbx5PmEpM7hw/Fdp87XaIox9KR7KaT5+5b71 s3Yd7XcY+dUyUJggEMFtw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:k6kRjnyrXHY=:ID3a2+OHMy0um51aD6BASH xw1d74bbYmE/3xKhVn1rmSVZkd1MtLWGxZSvEnnFqIj9ZpOqHly/5FF2HZtAQvB15Steh3riR IqKKQsy/Zd4kGi7f+Ve07o6xbOGJOCvJdsSl5zI6cYw1uEtA0ZGfRcGBWFUv4/uPmg1BlYWBx o/O/HCdKI+9UnlUyrh6p1EhpglkbQ+dD0MERvB9oIotZrry69bY6J6rHyhnbKWQX7FSBmQCeB TpirEAaiLQa/RHLDotLl7SBgcJNKfXyFUkZTiQds2RvFwVVkBf1qnUzx/siGVZQLadF+IS6wu yPXp3MuFyoV+DJF1qNu/GAFc4hwaGeD8IwcxJasCR5Wu5E3x/RmG+jItOVbVe3mZud7tqOMgV 20XibTTeE843vhV/0bkapcDR65nTl4cWuN4t52Px2yYZwNQHK0wukZuGALXSij8fdkuWDJCLN p1CDyqykYOo9nFqmw0Huf65srmQVd8l4820WL5kfT9Qxz2SsAETMTp+JQJ7/4Ksn1zSUIWQlc 9keEXs6PQj3SjsBQZW8vlXUJfLMTfKHVhUAA3itr5r/ZbdMTD7bl+0YAzjPxdqrC3YGtaEXBB MdUBtXCJZaaY/QSEaErOb0movWeqZ23sZXAatPfr8JB1at5OCAXYZnlo/iDviEHdRcywLq5E6 CXBmTTL72AXGDfRlghYc21z22mH3zO7hLyCMmAxuU//UgOR+lOXN+xhOn8QarGj3y9lpp64N5 rC4DAZsXvMjjhC/lA5BruVeU8PnNRpYWnSc4JIuP7Qvl/7vhto3VpGqXYLn2YIMF6FwtE/pE0 qGGr+XyLTJZhCyOs291bYKGLGZBspoahasLZRzfytUJTPlchJ4RWl8iLd6zFSU2l/c/g4gG X-Rspamd-Queue-Id: 49mXQh1lZLz4BV9 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.17.10) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.25 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.23)[-0.229]; RECEIVED_SPAMHAUS_PBL(0.00)[178.8.33.9:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.01)[0.010]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.57)[0.572]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.17.10:from]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.10:from]; FREEMAIL_CC(0.00)[gmail.com,sohara.org,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 15:38:05 -0000 On Tue, 16 Jun 2020 17:01:45 +0200, Chris Knipe wrote: > On Tue, Jun 16, 2020 at 4:47 PM Polytropon wrote: > > [...] > > > If you do, attach it as an attachment (MIME is > > > there for a reason)... > > > > > > There's GIT / CVS / Take your pick for a reason... :-) > > > > Those are external resources that can vanish for some reason. > > > > And if I use IMAP, and my IMAP server is unreachable? Then I also don't > have access to my email and therefore it has also 'vanished'. You're not understanding. Intendedly? Some users do not live in an "always online" environment. They obtain their messages via IMAP or POP3. Then they read and answer them offline, and finally establish an Internet connection again to send their answers via IMAP or SMTP. During the offline phase, they do not need any external resources to be able to read the entire message, including code, logs, tables, diagrams, or config file snippets (or whole example programs). > I see no difference to having code in an online repository, vs. in an email > client. There is a big difference. I tried to explain it. With IMAP, you know the presence of the "offline cache", and email is not tied to being online all the time, nor is email defined by the requirement of external resources. There are even valid arguments against (!) incorporating external resources as I wrote (security considerations, privacy, etc.). > The difference is that an online code repository has been > specifically designed to hold, and format code correctly, a MUA, has not. > That is not what a MUA's intended purpose is. Again, the use of the MUA here is not regarding sharing code. It's about correctly (!) displaying code used within a technical discussion by technical participants. > > The goal of the mailing list is that messages can be processed > > off-line, and they are perfectly allowed (!) to contain things > > like source code, ASCII tables, even simple networking diagrams > > or even formulas. Incornporating "external technology" for > > something the medium can do in its own doesn't sound very > > convenient (even though it sounds "modern", so it could probably > > appeal to certain users just due to this fact). Some mailing > > lists, such as this one, do not use binary attachments. > > Using text attachments for code is probably possible. > > However, this is a _discussion_ mailing list, not primarily > > intended for sharing code. That doesn't stop users from > > presenting code in the context of questions (and when I say > > code, I also mean scripts, logs, sometimes ASCII diagrams, > > or configuration files). > > > > > I have to be 'online' to get messages from the mailing list, I can be > 'online' to view code in a repository. No. If you get the messages, say using IMAP or POP3, you do not automatically retrieve any external resources. I'm not aware of a MUA that does this. You could, you know, add something like http://code.example.com/bigfile.txt (4069 MB) and your conncection would be saturated for minutes or hours, or your mobile Internet plan would run out of space. > If I solely rely on gmail, and I'm > offline? You do. Not everyone does. Some users prefer not to share all their life with mighty Google (or any other online service for that matter). As it seems, many users on _this_ mailing list prefer using a MUA program (local installation), for whatever reason they chose to do so. Is that wrong? Should email requiring you to always use a web browser? > I can't view my emails, I can't view said code (formatted > correctly or not). I can view everything even without any Internet. Power of MUA. :-) > We are in a modern society where connectivity is paramount (again, I am > talking about the majority, not the minority stuck in the basement using > 360K floppy drives). You know that Internet access often isn't for free? That you pay for being connected, or for using a mobile device to connect? You also acknowledge that a growing amount of people doesn't seem to like the idea of always being forced to do things online, in a walled garden? So _if_ you talk about the majority, you should also admit that the majority, always online, does not use email at all, as someone else pointed out. > The majority of us have connectivity 24x7x365 (or > some reasonable alternative to that). Especially on a technical mailing list where users arrive with Internet problems (cannot connect, connection drops, doesn't work as fast as it should, and so on), requiring them to have a working connection all the time is snob mode. And not helpful. > What if my POP3 email is at home, > and I am traveling? Mark as read, keep on the server, connect with IMAP. Use a trusted device. > How will I see said code? What if I have access to > some 'random' WiFi hotspot, but can't access the mailing list archives? Then you probably can't access your webmailer either. :-) > I hear what you are saying - however email is not, and never was intended > to be used for archival purposes. The mailing list archives, as an important source for help in "solved problems", and for reference purposes, begs to differ. > Source Code repositories such as GIT > were designed specifically for this purpose. No, they were not intended for technical discussions involving code snippets. Yes, I know, they can be _used_ for that, but that's not their primary purpose. You can use a knife to beat a nail into the wall, but wouldn't it be easier to use a hammer? > I can argue just as much as > you can. You maintain you will have 24x7x365 access to your email whilst > you may not have 24x7x365 access to a resource on the Internet. That is not what I wrote, for more information please reread. > unfortunately, goes both ways. I can very much have access to online > resources, but not to my email. So also to the mailing list archive. Your argument is invalid, my bike is a unicorn. :-) > > Visual presentation of data is a different "layer" than > > the data itself. And there is no 1:1 relation. Things like > > font size and displaying should not be a matter of the > > mail message itself, except... yes, it's not that easy! > > > > As a programmer, you will surely agree that there is: > > > > a) text that should be presented as it was written, > > > > b) text that the MUA is free to (and should) arrange, and > > > > c) text where it simply doesn't matter what the MUA does. > > > > Making this choice isn't always easy. Multipart-MIME can be > > helpful. Even though a mailing list is, by no means, a "one size > > fits all" solution, so there is a certain consensus about what > > is useful and what is rather not. This consensus changes over > > time, and within this consensus, there are many ways a user can > > express his questions, answers, suggestions and thoughts in a > > mailing list message. > > > > > I agree with you. The MUA should NOT modify the message, and I despise > this as much as you do. Fact remains, you're not going to change every > single MUA in the world, and you are most certainly not going to get > everyone to use the same MUA either. Work WITH the MUA, and not AGAINST > the MUA. Your code belongs online, not in some arbitrary MUA that formats > said text as it 'believes' is best. No, it does _not_, ***IF*** it is part of the discussion. Again, see code as logs, diagrams, simple formulas, config files, or programming language code, or scripts. In the mailing list archives, you can find a lot of code: temporary fixes for problems, scripts that solve a specific problem, program invocations, awk examples to get something out of a log file, or things like that. They are part of the discussion, so they are part of the message. Sometimes they even evolve (!) during the discussion, and the included code snippets express that. It has nothing to do with code contribution to a project, not with revision control. It is what it is - a part of the discussion. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...