back to article Relying on plain-text email is a 'barrier to entry' for kernel development, says Linux Foundation board member

Linux kernel development – which is driven by plain-text email discussion – needs better or alternative collaborative tooling "to bring in new contributors and maintain and sustain Linux in the future," says Sarah Novotny, Microsoft's representative on the Linux Foundation board. Said tooling could be "a text-based, email- …

  1. jake Silver badge
    IT Angle

    Where's the IT content?

    All I see is management in this article. Clueless management at that. The kernel has no place for clueless management.

    1. diodesign (Written by Reg staff) Silver badge

      Re: Where's the IT content?

      Wha... what kind of IT are you in that doesn't have project management?

      And what part is clueless? Have you tried recently submitting a patch to an open-source project that insists on plain-text email lists from a modern client? I have and it was a bit of an unexpected ritual.

      Also, attributing the word "clueless" to someone with years of experience working with open-source at Google and Microsoft is rather unkind.

      Edit: Before you get the wrong idea, I use plain-text email all the time -- at home and work. As I found out the hard way, no, modern clients don't format inlined patches well. And yes, it turns out there are command-line tools to send the email for you. OTOH GitHub is quite nice for submitting patches and following feedback etc IMHO...

      If someone identifies a barrier to entry to a project -- particularly a project whose leader has said it's hard to find maintainers -- it's a bit shortsighted to dismiss those concerns and shoot down attempts to provide alternative means for submitting, reviewing and accepting code.

      Keyword: alternative.

      The exact quote is: "a text-based email-based patch system that can then also be represented in a way that developers who have grown up in the last five or ten years are more familiar with."

      And to head off obvious arguments, lowering the barrier to entry doesn't mean lowering the quality. Being able to use 'git format-patch' and 'git send-email' doesn't guarantee you are a kernel-coding genius.

      C.

      1. Nate Amsden

        Re: Where's the IT content?

        Haven't talked with sarah in probably 12 years but knew her when she was a consultant at a Seattle company named blue gecko(they were db experts, company was later sold). She was really good back then has been interesting to see her rise so much in importance (?) Since then. Meanwhile I'm still doing the same sort of things I was 12 years ago. More refined of course but was not interested in any radical departure from my core skillset.

      2. jake Silver badge

        Re: Where's the IT content?

        Note that I wasn't commenting on the article, rather I was commenting on what the article was reporting.

        Yes, I contribute to FOSS projects regularly. Have been doing since before BSD was BSD. I generally use an email client. It is quite up to date and modern, with the latest stable release dated June 19th of this year. It's called Alpine. You may have heard of it. I don't find it to be a ritual at all ... unless you consider dotting the ts and crossing the is to be ritualistic.

        Seriously, how can anyone with a clue say with a straight face that plain old ASCII text is a barrier to communications? It's the LCD for a human readable version of the lingua franca of Kernel development. The barrier doesn't get much lower than that, at least not without losing signal ... and in the kernel, losing even a tiny piece of signal leads to crashes, or worse.

        Perhaps our friendly neighborhood commentard, Shadow Systems, would like to comment on Teletubby Toolkits and Fischer Price development systems compared to ASCII when it comes to barriers to communications ...

        1. diodesign (Written by Reg staff) Silver badge

          "plain old ASCII text is a barrier to communications"

          It's not a barrier to communications -- it's a potential barrier to tracking, submitting, revising, reviewing, and accepting patches. Some people have better ways of tracking patches, submissions, and feedback, and it may not involve a mailing list.

          And to stress: this sounds like an alternative interface to the underlying email-based patch system.

          C.

          1. Yes Me Silver badge
            Mushroom

            Re: "plain old ASCII text is a barrier to communications"

            The thing about plain old ASCII email is that it is remarkably robust and (excuse shouty) IT LOOKS THE SAME ON EVERYBODY'S SCREEN (as long as they have the sense to use a fixed width font; I like Consolas). Yes, occasionally some italics or boldface might be handy but the advantage of universality trumps all.

            Use a version control system for the code, by all means. Use Git if you must. Use an issue tracker. But for accurate communication between geeks at long distances, plain text wins every time.

            1. Charles 9 Silver badge

              Re: "plain old ASCII text is a barrier to communications"

              "The thing about plain old ASCII email is that it is remarkably robust and (excuse shouty) IT LOOKS THE SAME ON EVERYBODY'S SCREEN"

              That assumes you live in the West and communicate using Latin letters and so on. As a lot of coding is now being done in the East, with its cavalcade of non-Latin scripts, particularly RTL languages, a bit of unintentional bias starts to creep in.

              1. Dan 55 Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                Plain text sent with UTF-8 is a thing, but to be honest I think patches using Asian language glyphs would be quite a high barrier to everyone else in the world.

              2. jake Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                "That assumes you live in the West and communicate using Latin letters and so on."

                There is no such assumption, rather it is a fact. We are talking about the Linux Kernel and the LKML. We have an agreed upon common language to use for this, a lingua franca if you will. That language, like it or not, is American English. Which can effectively use 7-bit ASCII.

                BSD is worse. Its lingua franca is Californian English. This applies to Apple's bastardization of BSD, too. Scary, eh?

                1. Bruce Ordway

                  Re: "plain old ASCII text is a barrier to communications"

                  >>>>Apple's bastardization of BSD

                  And now that you mention it...

                  Lately, when I read articles about MS and Linux, I find my mind wandering in some strange directions.

                  I have imagined MS creating their own bastardizations, loosely based on that "Apple model".

                  Is my fantasy I try to envision a Windows desktop environment and... Linux?

                  Heresy? Probably.... maybe. For some reason I find it interesting to think about though.

                2. Anonymous Coward
                  Anonymous Coward

                  Re: "plain old ASCII text is a barrier to communications"

                  Californian English?

                  Woah, I thought I was grokking some far out gnarly vibes in the grody language those radical dudes use.

                3. Charles 9 Silver badge
                  WTF?

                  Re: "plain old ASCII text is a barrier to communications"

                  "There is no such assumption, rather it is a fact."

                  So you can conclusively prove there are no people on the LKML who do not use a non-Latin language as their first written language. Sounds like a high-handed, potentially dangerous assumption if you ask me, smacking of certain things best left unsaid.

                  1. jake Silver badge

                    Re: "plain old ASCII text is a barrier to communications"

                    I made no such claim, and you know it.

                    Don't be disingenuous, Chuck. It doesn't become you.

                    1. Charles 9 Silver badge
                      Unhappy

                      Re: "plain old ASCII text is a barrier to communications"

                      You just did. Thing is, you didn't recognize you did it because it was implicit...SUBconscious. That's exactly what makes it so dangerous.

                      1. jake Silver badge

                        Re: "plain old ASCII text is a barrier to communications"

                        Read the rest of the paragraph that you carved the single sentence out of. As with most paragraphs, it is supposed to be read as a coherent whole. Context is kind of important, no?

                        1. Charles 9 Silver badge

                          Re: "plain old ASCII text is a barrier to communications"

                          I was writing IN context. lingua fracas tend to be informal and discriminatory. Meaning implicit bias, which like I said can be dangerous.

                          1. jake Silver badge

                            Re: "plain old ASCII text is a barrier to communications"

                            "lingua fracas"

                            I think I see your misunderstanding ...

                4. MachDiamond Silver badge

                  Re: "plain old ASCII text is a barrier to communications"

                  "BSD is worse. Its lingua franca is Californian English."

                  Dooooooood, that is so harsh.

                  1. jake Silver badge

                    Re: "plain old ASCII text is a barrier to communications"

                    Life is harsh. We manage to muddle through it anyway.

              3. james_smith Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                "That assumes you live in the West and communicate using Latin letters and so on. "

                Yes, how dare the Linux kernel coders insist on English as their *ahem* lingua franca. Must be a consequence of being started by that well known native English speaker, Linus Torvalds. Oh, wait...

                (Interesting to note that Finnish cannot be represented in ASCII since it uses accented characters - they are a part of so called "Extended ASCII", but that is not a standard).

                1. Peter Gathercole Silver badge

                  Re: "plain old ASCII text is a barrier to communications"

                  I think when it comes to the character set that the kernel is programmed in, you have to look at the computer language that it is mostly written in. That is C. C is a computer language that assumes a certain character set, and that will almost certainly be similar or the same as 7 bit ASCII, or one of the related supersets in ISO or UTF 8 bit character sets.

                  You can almost certainly write comments or function or variable names using whatever is allowed by the superset that a compiler will accept, but the basic keywords are defined in English.

                  I'm sure that there are some code written in Cyrillic, or the compound ideograms used by East Asian languages, but as soon as you start doing this, you close the code from the rest of the world. You already see this when looking at, say, electronic datasheets on the Internet, as those written in Chinese for devices that originate in China are incomprehensible to the majority of the world.

                  This may be cultural imperialism, because English speaking countries were so dominant during the development of the basic computing infrastructure. but I believe that writing compilers and complex systems in something like zhōngwén is complicated and unlikely to happen.

                  1. rcxb Silver badge

                    Re: "plain old ASCII text is a barrier to communications"

                    This may be cultural imperialism, because English speaking countries were so dominant during the development of the basic computing infrastructure.

                    Unlikely. Baudot code was only 5 bits. Moving up to 7 bit ASCII was a huge improvement. 16-bit Unicode would have been terribly impractical in the days of Z80 processors and a few kilobytes of RAM. ASCII did make allowances for some non-English characters.

                    Basic English was created back in 1930. English was becoming increasingly the universal language from the start of the industrial revolution through the world wars, and had certainly become the unchallenged de-facto language of science and research (taking over from German) after WW2.

                    ASCII is good for more than English... Several nationalities can forego accented characters (or use the available diacritics) with little impact and use ASCII just fine. Even some symbols commonly used by English speakers were missing from the original ASCII standard, too... Such as the pound (£).

                2. Norman Nescio

                  Re: "plain old ASCII text is a barrier to communications"

                  Yes, how dare the Linux kernel coders insist on English as their *ahem* lingua franca. Must be a consequence of being started by that well known native English speaker, Linus Torvalds. Oh, wait...

                  (Interesting to note that Finnish cannot be represented in ASCII since it uses accented characters - they are a part of so called "Extended ASCII", but that is not a standard).

                  Ahem, Linus' mother tongue is, in fact, Swedish. His family come from the roughly 5% minority in Finland who are Swedish speakers. But your point stands: Swedish has non-ASCII characters too.

                  https://www.tfir.io/which-is-linus-torvalds-native-language-finnish-or-swedish/

                  Swapnil: What is your native language, Finnish or Swedish?

                  Linus: Swedish is my mother tongue, so I grew up speaking Swedish in Finland. It’s a small minority of language. It’s about 5 percent of Finland. It’s concentrated mostly along the coast.

                  So I went to Swedish speaking school. I went to Swedish speaking high-school and University. About half of my courses were Swedish speaking, of the rest I have a strong minor in Maths and Computer Science. My math was mostly in Finnish and my computer science was half Finnish and half English because all the literature is in English.

                  You have to speak Finnish in Finland. When you go to the shops and do things, 95% of everybody speaks Finnish so I learned Finnish as a second language and these days it’s my weakest language by far.

                  I speak, obviously, English and at home I speak Swedish with kids and my wife; they usually answer in English because they go to English speaking school. I can get by with Finnish. I am fluent in it, but fluent in a way that if talk to a Finnish person in Finnish they notice that I am not really a native speaker.

                  1. red floyd
                    Linux

                    Re: "plain old ASCII text is a barrier to communications"

                    "Ahem, Linus' mother tongue is, in fact, Swedish. His family come from the roughly 5% minority in Finland who are Swedish speakers. But your point stands: Swedish has non-ASCII characters too."

                    I believe that that you have fallen into the sar-chasm.

                  2. james_smith Silver badge

                    Re: "plain old ASCII text is a barrier to communications"

                    Although he's from the Swedish minority, Linus speaks Finnish as a native language as well as the Finnish dialect of Swedish. Although the country is officially multi language (including Sami in the North), you really need to be able to speak Finnish since that's overwhelmingly the language of the majority. Only in the remote Aland Islands is Swedish spoken exclusively,

                    1. jake Silver badge

                      Re: "plain old ASCII text is a barrier to communications"

                      I think Norman Nescio's reply here more than adequately addressed Linus' native tongue.

                3. Anonymous Coward
                  Anonymous Coward

                  Re: "plain old ASCII text is a barrier to communications"

                  It'll never be Finnish. Not while they're still working on it and patching it.

            2. guyr

              Re: But for accurate communication between geeks at long distances, plain text wins every time.

              I worked in software development for 40 years, now mostly retired but dabble in open source projects to keep my brain working. In the early years, we used rudimentary editors and makefiles. Got the job done, but the toolset was not really helpful to comprehension.

              For the last 25+ years, we've used IDEs for the development task, which greatly facilitates understanding. Tools don't replace the need for a developer to understand what the code is doing, or even more important, fundamental software concepts. But it certainly helps competent developers to do their jobs with fully cross-referenced source, source-level debuggers, etc.

              To your point, plain text facilitates accurate communication between remote systems. Today we have tremendous tooling that enables easier communication between people. Think distributed reviews.

              1. Anonymous Coward
                Anonymous Coward

                Re: But for accurate communication between geeks at long distances, plain text wins every time.

                "Today we have tremendous tooling that enables easier communication between people. "

                ... and by happy coinsidence, those can be bought from Microsoft. That's the idea here, obviously.

                Another MS fanboy from team Novotny.

              2. jake Silver badge

                Re: But for accurate communication between geeks at long distances, plain text wins every time.

                "Today we have tremendous tooling that enables easier communication between people."

                Yes, we do. USENET, IRC and email built TehIntraWebTubes, with a little help from telnet and FTP. All plain old 7-bit ASCII (until FTP bollixed it up with 8-bit clean binaries, of course!). Ain't it grand?

            3. jake Silver badge

              Re: "plain old ASCII text is a barrier to communications"

              "Yes, occasionally some /italics/ or *boldface* might be handy but the advantage of universality trumps all."

              FTFY

            4. Anonymous Coward
              Anonymous Coward

              Re: "plain old ASCII text is a barrier to communications"

              Yeah it looks the same but can end up being mindbogglingly frustrating to catch up on if you jump in mid thread.

              I've been involved in comparatively simple stuff where email threads have got out of hand.

              It's especially problematic if say you have an email thread that is currently n emails long and someone replies to email n - 3 or something. It fucks the thread hard. Also the way mail clients handle things can get confusing. We've all see Re: Re: Re: Fw: Re: Re: subjects before.

              Trouble is, email is linear but the conversations happening in it aren't necessarily linear.

              Email is fine one to one, but it sucks giant hairy balls for many to many.

              I think at the very least we need more than RE: and FW: tags to give us a fighting chance at building new ways to display "multiplayer" mail threads in a more cohesive manner.

              Adding markdown to email clients would help as well.

              1. tfb Silver badge
                Black Helicopters

                Re: "plain old ASCII text is a barrier to communications"

                Trouble is, email is linear but the conversations happening in it aren't necessarily linear.

                This in fact does seem to be something that lots of recent email clients have just fucked up. Email has (or should have) both references and in-reply-to fields (these date back to RFC 724 in 1977, which was successively obsoleted by RFC 733, RFC 822 (the one everyone knows), RFC 2822 & RFC 5322, which seems to be mostly current.

                These two fields enable a mail application to know what message a message is replying to, and what other messages are relevant to it. Just using the first of these is sufficient to let the client reconstruct the tree of replies in a conversation (it needs to have the intermediate mail messages, or at least have kept a record of their message IDs and the IDs of the messages they're in reply to.

                And that's what good mail applications used to do: they'd show you the tree of the thread and display messages at the appropriate point in the tree. Some of them let you even say 'I'm interested in this branch, but not that branch').

                But for some reason a lot of current mail programs have lost that ability. I'm not sure why, because It's really annoying. Perhaps some still have it.

                1. Claptrap314 Silver badge

                  Re: "plain old ASCII text is a barrier to communications"

                  Which gets to the crux of the matter. As usual, an u$ employee is pushing a solution that works reasonably well for maybe 85% of the population as the mandatory fix for the 15% who were using superior tools DECADES ago.

                  The frustrations I had with elm & pine seem positively quaint when compared to the BS I am constantly faced with in newer email clients.

              2. rcxb Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                I think at the very least we need more than RE: and FW: tags to give us a fighting chance at building new ways to display "multiplayer" mail threads in a more cohesive manner.

                They already exist. E-mail has Message-ID, References, and In-Reply-To headers.

                Some e-mail clients simply screw-up, badly, which is how you end up with Re: Re: Re: Re: Re: subject lines, which you never should see...

              3. ibmalone Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                HTML doesn't fix this either, I've seen plenty of long chains with the older content indented until it's only a couple of characters wide. (Usenet long had quoting conventions and newsgroup specific tags which worked well, but they required people to know what they were doing and read the FAQ, which is obviously too much to expect of anyone.)

                Plain text is ideal for code. It's also /more/ accessible than html-heavy email as the writer needs to put their thoughts into words not wingdings. If your email client can't do plain text it is broken, and I think that suggesting this, of all things, is a barrier to entry to contributing to the kernel is fairly silly.

            5. Antron Argaiv Silver badge
              Linux

              Re: "plain old ASCII text is a barrier to communications"

              Yeah, I'm kinda a fan of minimalist tools. Straight ASCII email has been very good to me and I see no reason not to use it. I actually prefer it.

              That's not to say rich text is bad. It certainly has its place, but plain text is unambiguous, if longer.

              Word processor for looks, plain text for basics. Things should be only as complex as they need to be to do the job at hand.

            6. Ian 55

              Re: "plain old ASCII text is a barrier to communications"

              At some point, everyone who isn't trying to push ads will accept that HTML email was a mistake.

              1. Charles 9 Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                I'm pretty sure junk e-mail predated HTML e-mail. As for tracking, the header would provide plenty of room for that.

                Personally, I think the only way to end the debate is to hear it from the man himself.

          2. Shak

            Re: "plain old ASCII text is a barrier to communications"

            >And to stress: this sounds like an alternative interface to the underlying email-based patch system.

            If what's being advocated is some kind of web interface to email that enforces plain text and decent threading then I'm sure most here won't object.

            But personally I don't blame the suspicion that there's a different (misguided of not malicious) agenda.

            1. Anonymous Coward
              Anonymous Coward

              Re: "plain old ASCII text is a barrier to communications"

              " suspicion that there's a different (misguided of not malicious) agenda."

              Hey, it's *Microsoft*. They have only one kind of agenda: Malicious. Never have had anything else.

              1. Antron Argaiv Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                ...with a healthy dash of incompetence and a sprinkle of incompatibility.

                1. Doctor Syntax Silver badge

                  Re: "plain old ASCII text is a barrier to communications"

                  All with a strong flavour of NIH

            2. Anonymous Coward
              Anonymous Coward

              Re: "plain old ASCII text is a barrier to communications"

              That exists. It's called mailman.

          3. Anonymous Coward
            Anonymous Coward

            Re: "plain old ASCII text is a barrier to communications"

            "And to stress: this sounds like an alternative interface to the underlying email-based patch system."

            Specifially: MS -defined interface or tool to *replace* open and standard e-mail.

            That's the *actual* problem for Novotny/MS: They don't have a control of tools used.

            Control the tool, control the kernel development. *That's* the idea here.

            MS is evil and so is Novotny, whatever BS she spews to cover it up.

          4. jake Silver badge

            Re: "plain old ASCII text is a barrier to communications"

            Who is having these issues with tracking, submitting, revising, reviewing, and accepting patches? Is it really an issue? Or does somebody have a bee in her bonnet because her partner doesn't know how to configure his "easy to use" Mac?

            1. Anonymous Coward
              Anonymous Coward

              Re: "plain old ASCII text is a barrier to communications"

              "Or does somebody have a bee in her bonnet because her partner doesn't know how to configure his "easy to use" Mac?"

              Yes, but not for that reason: It's because she's *paid* to do so as it's *not a Microsoft controlled tool set*.

              That's the problem here, really.

            2. keithpeter
              Windows

              Re: "plain old ASCII text is a barrier to communications"

              What I see here is a lot of untested hypotheses and anecdotes, which is fine, that is the *starting* point for research.

              Has anyone done any actual *research* on why it is difficult to nominate new maintainers?

              Is there a general aging of the 'funnel' at all skills levels?

              Or is there a specific issue about the big ball of mud now being so complex it is difficult to gain an overview?

              Or is it simply that employers are not freeing senior staff to take on significant responsibility?

              Or perhaps it is something else entirely.

              If the first, then, yes 'onboarding' needs to be looked at, and part of that might be providing a different *presentation* of the patch process. If the second then the barrier represented by setting up a standard compliant email client may not be the key issue. If the third then some kind of paid sabbatical process will need to be funded.

              Icon: generational handover is real and it can be a problem. I've faced the issues in a non-IT related field. At some point, ownership of institutions and processes ('the way we do things here') has to be passed on, and you have to let them get on with it. The rite of passage / ritual of retirement is useful like that. We are after all primates with a bit of a patch in our wetwear.

              1. Doctor Syntax Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                Is it that there are too many management types coming into the set-up?

          5. Charlie Clark Silver badge

            Re: "plain old ASCII text is a barrier to communications"

            Virtually all VCS systems are based around the way stuff is handled by e-mail clients and they do this for a reason.

            Moaning about having to switch e-mail clients to one that does text/plain properly suggests that the barrier is in the person themselves. E-mail clients that do not handle text/plain properly should be considered broken.

          6. bombastic bob Silver badge
            Devil

            Re: "plain old ASCII text is a barrier to communications"

            when I first saw the title i was thinking "what, some idiot wants HTML mail instead?" But then I read the article and realized what it was about.

            From the article: Should it migrate toward something more like, say, issues and pull requests on the Microsoft-owned GitHub?. (/me points out it had that before MS bought it).

            Yes, Github's "issues" system might be one possible answer. In short, you need a blog-like environment in which you can track things. Example, when you do a branch merge to a pull request, an issue is effectively created in which you can comment on the resulting merge. And ideally it tracks back to the other issues involved in the decisions that led up to the pull request, all of the people discussing it, yotta yotta. I like it, at any rate, even with its imperfections.

            So in a way the answer is already staring at them. Just "make it better".

            and last I checked, you can still track issues with e-mail notifications.

            what I feared: FB or Tweet-like threads designed for 4-inch phone screens oriented vertically, emojis, excessive HTML-i-ness, and bandwidth-hogging fluff. OK some of that is already in 'issues' but still...

          7. Man inna barrel

            Re: "plain old ASCII text is a barrier to communications"

            ASCII was meant as a universal communication medium. Look up the acronym. You have to consider that ASCII is an encoding convention, which assigns graphical symbols to byte numbers. Though ASCII contains a good deal of cruft, and is rather arbitrary in its selection of symbols, it is almost universally understood, which is why it is preferred for writing computer programmes, and so on.

            1. Kristian Walsh

              Re: "plain old ASCII text is a barrier to communications"

              "a universal communication medium. Look up the acronym. "

              I didn’t need to. ASCII stands for American Standard Code for Information Interchange.

              Hmmm.. Very universal. At least it’s not EBCDIC, I suppose.

              1. jake Silver badge

                Re: "plain old ASCII text is a barrier to communications"

                ASCII was developed alongside, and in cooperation with, ISO/IEC 646 in the early 1960s. That's the International Standards Organization.

                Seems fairly Universal to me. (amfM, any comment?)

                I agree that at least it's not EBCDIC ...

                1. Kristian Walsh

                  Re: "plain old ASCII text is a barrier to communications"

                  Yes and no, really. ASCII-1963 was published as an uppercase-only alphabet; CCITT and ISO used this as a base for a two-case system, which began standardisation in 1964 and was published in 1967. ASCII was then revised in 1967 to be fully compatible with the new ISO standard. I suspect that a clean-sheet ISO design would have had fewer control codes (most likely just 16) and more printable glyphs so that the national replacement characters wouldn’t have clashed with punctuation characters that were often used as field delimiters in documents... despite ASCII having four control codes specifically for delimiting fields in the form of FS,GS,RS and US, it seems that nobody ever used them (@jake, you're at this game much longer than I am, maybe you've come across something? Personally I often use these as delimiters when I need to bundle multiple outputs from one *nix tool that may contain tab/spaces/linefeeds into another shell-script. ASCII-safe and almost guaranteed not to already be in the data being processed)

                  But ASCII is the classic example of how an inadequate but ubiquitous standard drags everything down to its level. Even by the standards of the 1960s, and even in the fiercely monolingual USA, it had considerable shortcomings - most notably, it is incapable of correctly encoding the proper names of places in parts of the USA that were first settled by the French or Spanish. Sadly, this shortcoming was then set in stone by the US Postal Service, which disallowed accented letters in official “preferred” addresses, simply because at one time its OCR and database vendors could not handle them or their terminals couldn't enter them. (Many state DMVs did the same later with names on driving licenses)

                  Back when I visited the Bay Area a lot, there was a sign I used to pass on I-280 for what was originally signed as “Cañada College” but was now misleadingly spelled “Canada College” thanks to this policy — as someone who was working a lot with text encoding and processing at the time (I wrote software localization tools), what struck me about it most was that you could still see the shadow of the tilde that had been removed from the sign-face after the official street-address changed; obviously someone was perfectly well able to deal with Spanish names back before computerization came along to limit their horizons.

                  (Actually, a quick look at Google StreetView shows me that a newer sign for the Cañada Road exit has regained its tilde, so there is hope for the future... although that’s one ugly tilde)

                  But on the original topic of kernel submissions, the biggest problem with insisting on “ASCII” is that nobody uses it, because there are pretty much no 7-bit text computer systems in use anymore. That leaves “an unspecified superset of ASCII” as your de-facto standard. (If I had a buck for every time I heard someone say “8-bit ASCII” like it was an actual thing that had ever existed...). To avoid this ambiguity, Linux Kernel submissions are actually to be submitted as UTF-8, not ASCII, as this allows maintainers to use their actual names in those submissions, not some bastardised, accent-stripped version of it.

                  1. jake Silver badge

                    Re: "plain old ASCII text is a barrier to communications"

                    You are, of course, quite correct on ASCII and ISO ... mine was just a quick wrap-up. However, my point that the American Standards Organization (Great Grandfather of ANSI) and the International Standards Organization worked in cooperation for the eventual standard right from the git-go is correct. The version of ASCII that most of us use is a defacto International standard. (With that said, so-called "US-ASCII" is a whole 'nuther kettle o' worms.)

                    The separators, FS,GS,RS and US (file, group, record, unit), were used to separate punch cards into logical groupings, and also used in punched tape to logically do the same thing. You can throw EM (End of Medium) in with those four ... and some people suggest that SP should be WS (Word Separator). I've seen 'em used as separators for various pet projects on disk, usually simple databases. I've also seen them used similarly to what you are doing. I have never seen them used "system wide" outside of holes punched in paper (mylar, whatever).

                    The original 7-bit ASCII was a "best effort", given the world of telecom as it existed back then. It is, by it's very nature, a compromise. The reason it still exists today is because it is a very good first approximation of a method for computerized communications. (Kind of like C is a very good first approximation of a systems programming language. Running code trumps all.)

                    The removal of accents in American English is a personal peeve ... As a sometime teacher at Cañada College, I was among the first to start bitching to anyone who would listen at the dumbing down of our Californian Heritage ... With me it started in Elementary School, when the school tried to rename my friend José to Jose ... to us kids, it was obvious that José was a different name than our other friend, Jose Goldberg. Eventually the school capitulated. This, and similar, has pissed me off for over half a century ...

                    Yes, what we call ASCII isn't really ASCII. But we all know what we mean when we say it. There are some fights that I see no real reason to fight.

        2. gnasher729 Silver badge

          Re: Where's the IT content?

          ASCII based? No UTF-8 in comments? Many developers can't even spell their name correctly in ASCII, so that is going back to the stone ages.

        3. Dave559 Bronze badge

          Alpine

          I'm not sure that "modern" is an adjective that I'd really apply to Alpine!

          Yes, it still works, and yes, we have a die-hard set of people still using it at work (and, yes, my first email client was elm, and I have also used alpine), but the three-pane folders/headers/message layout that's been a de facto standard in graphical mail clients since the 90s suits me much better.

          But, yes, each to their own preferred tool.

      3. Anonymous Coward
        Anonymous Coward

        @diodesign - Re: Where's the IT content?

        You mean they don't know how to send a plain-text email and they want to contribute to Linux kernel ? Sorry but for me the accusation of being clueless stays. I wouldn't let these kids raised from the cradle with Microsoft Office to handle Linux kernel development.

        1. diodesign (Written by Reg staff) Silver badge

          "they don't know how to send a plain-text email"

          It's more than sending a plain-text email. It's following discussions, submitting formatted code, following feedback and revising parts, and resubmitting it, and accepting it.

          Mailing lists have been a place for that. But they're not the only way to do it.

          And to stress: this sounds like an alternative interface to the underlying email-based patch system.

          C.

          1. seven of five Silver badge

            Re: "they don't know how to send a plain-text email"

            > And to stress: this is would be an alternative interface to the underlying email-based patch system.

            And to stress: There is no need for an alternative system, the current one is fine. She does not like it? Fine, there is the door.

            1. Charles 9 Silver badge

              Re: "they don't know how to send a plain-text email"

              She herself said it's hard to keep maintainers as it stands now due to barriers of entry. The risk is that if she leaves, others may follow and soon there aren't enough people to maintain the beast. You ever seen that bit where the one told the door whistles...and everyone else follows the former out the door? That's the risk they're facing right now. Be careful what you wish for.

              1. Lee D Silver badge

                Re: "they don't know how to send a plain-text email"

                Barriers to entry?

                Or a handy test for minimal IT skills?

                1. bombastic bob Silver badge
                  Devil

                  Re: "they don't know how to send a plain-text email"

                  Sending plain text e-mail as a handy test for minimal IT skills

                  YES!!!

                  From the article: It is just that the modern mail client has intentionally moved towards HTML

                  "Modern" - like the way certain desktop environments are called "modern" ?

                  If my inbox gets an e-mail that says "you must enable HTML to view the content" it's automatically marked as spam. For security reasons, I _NEVER_ view e-mail as HTML unless there's some compelling reason to do so and I know exactly who sent it, etc.. And NEVER on a windows machine does HTML mail get viewed nor previewed in other-than-plain-text.

                  Thunderbird's EASY to configure for plain text, viewing as well as sending. I think that "modern" e-mail clients SHOULD be able to do the same thing.

                  /me points out that many years ago I circulated an e-mail to friends that deliberately illustrated the dangers of HTML e-mail, including script and embedded multimedia content you could not turn off - you'd hear me doing a "devil voice" saying "what is this?" "It's a message from HELL!" along with embedded flaming things and rotating pentagrams, and things like that. And of course if I could do THAT, then anybody could...

              2. seven of five Silver badge

                Re: "they don't know how to send a plain-text email"

                OK, then we die. So be it.

              3. jake Silver badge

                Re: "they don't know how to send a plain-text email"

                "it's hard to keep maintainers as it stands now due to barriers of entry."

                If they are already maintainers and in need of keeping, they have already entered by definition. So it seems to me that these so-called "barriers" are obviously bogus.

                1. jelabarre59 Silver badge

                  Re: "they don't know how to send a plain-text email"

                  "it's hard to keep maintainers as it stands now due to barriers of entry."

                  If they are already maintainers and in need of keeping, they have already entered by definition. So it seems to me that these so-called "barriers" are obviously bogus.

                  The issue becomes' who takes over later on as maintainers? Today's maintainers started out as developers, who learned procedures, how to direct the work of others, etc. If you don't have enough of a pool of new talent, you don't get enough of a pool to select maintainers from.

                  It's much like what's happened to many science-fiction conventions; not enough new staff coming in to learn the ropes, so the old committee members burn out, move on to other hobbies, or (as is happening more often percentage-wise, die).

              4. Doctor Syntax Silver badge

                Re: "they don't know how to send a plain-text email"

                "The risk is that if she leaves, others may follow and soon there aren't enough people to maintain the beast."

                I don't see any suggestion in the article that she's a maintainer. She's MS's representative on the Linux Foundation. Her leaving would not decrease the maintainers in any way. Neither would others in similar positions leaving.

                It's possible that top-level politics is inhibiting people taking on maintainer roles.

              5. Inkey

                Re: "they don't know how to send a plain-text email"

                She herself said it's hard to keep maintainers

                I'll bet my 8 bit ASCI that a plain text mailing list is not the reason its hard ..... more like trying to keep the concept pure, especialy from the corporate money hungry dinosours from eating everyone at the table

            2. jelabarre59 Silver badge

              Re: "they don't know how to send a plain-text email"

              I don't see it as a replacement for the existing tools, but rather providing more than one way to view/parse/analyze existing data. Think of it like searching through a text file inside Notepad/Gedit (or whatever your favourite GUI text editor is) or using grep, awk, sort, etc from the command line. Both let you find particular strings of text, but depending on your workflow at the moment, one may be better than the other (the appropriate tool for the task at hand).

              You could bring up source code in a tabbed text editor or IDE, maybe even with syntax highlighting, but maybe if you want to understand the logical flow, perhaps a diagramming tool showing interraction and interrelations in the source may help see what you can't see in the raw code. Doesn't change the required formatting of the code being submitted. In fact, a good tool might be a checker to make sure code formatting meets the requirements, so a new contributor can learn proper code submission that much quicker (once you start seeing now your code gets properly reformatted, it eventually, hopefully, starts sinking in).

              I know, this is coming from someone whose C/C++ programming experience consists of "./configure && make && make install".

            3. Warm Braw Silver badge

              Re: "they don't know how to send a plain-text email"

              Fine, there is the door

              I can't imagine why a community with such welcoming attitudes and openness to technological change says that it’s really hard to find maintainers. You'd think people would be queuing around the block to join them.

              1. tfb Silver badge
                Terminator

                Re: "they don't know how to send a plain-text email"

                I suspect you're mistaking the Linux kernel community with a bunch of whining pseudonymous trolls (and, entertainingly, pseudonymous trolls who largely don't understand what the problem is) in the comments to an article. I'm sure the Linux kernel community has its problems, but I'm equally sure they're not these problems.

              2. seven of five Silver badge

                Re: "they don't know how to send a plain-text email"

                This is not about welcoming attitude and openness to change. This is about someone uninvolved trying to join (and I use this very liberal here), being to thick to configure the required tools and then getting all shouty about how bad the tools are.

          2. Dan 55 Silver badge

            Re: "they don't know how to send a plain-text email"

            I take it this is the "extend" part of the plan, with Teams and Github connectors, Visual Studio Code plus associated plug-ins and the like?

            All major e-mail clients do plain text and conversation threading, is submitting a diffpatch using e-mail really too difficult? If this really is a barrier to entry, perhaps we should be grateful for it:

            Linux kernel maintainers tear Paragon a new one after firm submits read-write NTFS driver in 27,000 lines of code

            1. Anonymous Coward
              Anonymous Coward

              Re: "they don't know how to send a plain-text email"

              "I take it this is the "extend" part of the plan, with Teams and Github connectors, Visual Studio Code plus associated plug-ins and the like?"

              Obviously: Embrace & extend. Control the tools, control the development. And then kill it.

              That is and has been MS plan since Linux was commercially available and it hasn't changed an iota, no matter how much they lie about it.

          3. jake Silver badge

            Re: "they don't know how to send a plain-text email"

            "It's following discussions, submitting formatted code, following feedback and revising parts, and resubmitting it, and accepting it."

            Which we are doing. And it's not exactly difficult. For proof, I submit the fact that Linux has been ported to damn near everything, and it runs better on all those things than any closed-source option that I can think of.

            "Mailing lists have been a place for that. But they're not the only way to do it."

            So she should actually design herself a system that works the way she wants to see it work, and make the source available to all and sundry. If people like it, it will get used. Thats how FOSS works. Kicking open the door and yelling "The way you are doing it is wrong! Microsoft is going to fix it!" is guaranteed to get her laughed at. Because that is also how FOSS works.

          4. Cuddles Silver badge

            Re: "they don't know how to send a plain-text email"

            "It's more than sending a plain-text email. It's following discussions, submitting formatted code, following feedback and revising parts, and resubmitting it, and accepting it."

            If that's the case, maybe the article should actually talk about it? The only complaint I can see in the article is that someone who apparently wants to be involved in serious programming is so poor at actually using a computer that they can't figure out how to send a simple text email, despite at least two of the clients mentioned (Outlook and Gmail) both making it trivial to do in just a couple of clicks (seriously, Compose -> Menu -> Plain text mode. It's literally two extra clicks in the most obvious place possible). Someone with tech skills on a par with my grandmother (who, for the record, is dead, although that has not materially affected her computer skills in any way) probably shouldn't be trying to get involved in kernel programming, or telling other people how to do it.

            As for the wider discussion, I agree that mailing lists aren't the only, or even the best, way to manage something like this. But trying to have two parallel systems would be much, much worse. And let's be honest, even if it claims to want to be just an alternative interface, it will effectively be a parallel system. Even just changing to a single new system would be a huge effort, not least because everyone is already familiar with this system - making it more friendly for newcomers doesn't help if it screws things up for established people.

            The current system works, it has done for years, and it's incredibly simple to use. Yes, a better system could be created if you started from scratch today, but that's not a great idea and is simply not necessary. If you can't figure out how to send a simple text email, the problem lies very firmly on your end and not with the existence of mailing lists.

            1. Peter Gathercole Silver badge

              Re: "they don't know how to send a plain-text email"

              Other people have hinted at what I'm about to say, but I don't think anybody has explicitly said it.

              Using a tool that is not open source (say Teams or Slack) puts the project at risk of changes in those tools. The good thing about email, and it's lowest common denominator 7 bit ASCII is that email is a distributed system that would allow Microsoft or Google or any other mail provider to disappear overnight, and still continue to operate.

              Even if GitHub were to disappear, as long as there was a copy of the source in another git repository, it could be re-built relatively easily.

              If there were a non-propriety, open source, distributed collaboration system available, that may be better. This is not the way the computing ecosystem is going, as these systems need to be paid for by someone, and for a non-profit that does not charge for what they produce, finding money to pay for something is difficult.

              Everyone has email servers or at least access to them, so Linux kernel development is piggybacking on something that is being provide for other reasons.

          5. Dave559 Bronze badge

            Re: "they don't know how to send a plain-text email"

            There's a good and perfectly valid argument that being able to contribute to kernel development should have quite a high (skills) barrier to entry; I know I certainly couldn't do it, for example.

            But I do also agree that alternatives to perhaps rather fiddly email processes probably aren't really such a bad idea.

            Linux development started in the 90s, at a time when permanently online, realtime, worldwide, internet connectivity was a rare thing, with uucp, relay gateways, and dial-up access (with phone call charges on top) being rather more common. And in the early part of that decade there was no web, of course.

            Obviously, this gradually changed, and we now find ourselves in the situation where almost everyone (for some value of almost) now has always-on direct internet and web access, with no per-minute charges. As that happened, we gradually moved from discussion mailing lists to forums, to Q&A sites like StackExchange, to issue trackers (and also to certain eternally scrolling platforms that we will of course not mention here, and which happen to be completely useless for any form of structured discussion).

            Is it really such a bad thing to perhaps have a wider variety of tools available in the tool chest, such as the now quite powerful web-based tools that most repository hosting systems now have?

            And to give a tiny example (and which probably also serves as another good example as to why I'm not a kernel developer), if I want to diff two files, I don't use 'diff', as I find it very hard to follow, I use 'meld', which suits my way of visualising things so much better. Times change, tools change.

            (But having said all that, Micros~1 having the world's worst almost-but-not-quite-email program quite probably doesn't help matters, so, if they want to get more involved, they probably need to take a good look much closer to home first!)

      4. big_D Silver badge

        Re: Where's the IT content?

        I agree with you for the most part.

        But plain text email is a decades old standard. It should be the lowest common denominator. If the email client can't generate standards conform emails, that is the email client's problem and a bug report should be raised with the developers of that software - or choose a standards compliant tool.

        Microsoft is notoriously bad with its mail protocol adherence, especially anti-spam and secure email authentication, it regularly malforms the headers - I worked for a security company that was always having problems with customers using Exchange and it malforming the headers, so critical emails were being rejected by the recipient system, because they didn't adhere to the standards and were therefore classified as phishing or hoax emails. You could hear the CTO's rants about Microsoft's woeful attempts at email headers from the other end of the building!

        I think that is a bigger part of the problem today. So much software ignores the established standards and does it "their" way, which is standard, but not quite standard.

        The advantage of the current system is that it is free, open standards based and anyone with a (standards compliant) email client can use it and use it when they don't have a reliable internet connection. They can receive a batch of emails, read them offline, write the replies offline and then send the replies, when an internet connection is available. That is difficult to do on a system that requires a permanent internet connection.

        (E.g. a builder managed to break the main line into our town, the whole town was without Internet for several days and then 1mbps for 2 weeks after that, until the provider could re-splice the fibre. Currently I know of a outage where a cable has been broken, but is laid alongside the railway track, so they have to negotiate with Die Bahn to close the stretch (main East-West arterial link, I believe), so they can dig up the cable and repair it, the cable broke last Thursday and negotiations are still going on to get access to the cable to repair it a week later! During such times, you have to fall back on either slow links or links with very limited data, so you have to work offline and send and receive changes in bursts.)

        1. Tim99 Silver badge
          Windows

          Re: Where's the IT content?

          Microsoft... The joys of receiving an unreadable Mail Attachment.eml on a “standard” email client after a couple of “standard” attachments have been routed through a couple of different corporate Outlook/Exchange systems...

          1. gobaskof

            Re: Where's the IT content?

            Some companies, such as where I work, will turn off IMAP on their exchange servers so if you are on Linux you can only use outlook webmail as a client*.

            * Well you can use DavMail, and whatever you want. DavMail has finally stopped accepting every calendar request!

        2. jelabarre59 Silver badge

          Re: Where's the IT content?

          Microsoft is notoriously bad with its mail protocol adherence, especially anti-spam and secure email authentication, it regularly malforms the headers

          Sounds a lot like Lotus Notes, although Notes wasn't originally designed as an email client (I have the impression the email functionality in Notes was originally hacked together as a *sample* application, never intended to be an active part of the entire product).

        3. Mike 137 Silver badge

          Re: Where's the IT content?

          "Microsoft is notoriously bad with its mail protocol adherence ..."

          It's also appalling at generating plain text parts for emails. It creates the HTML part first and then crudely strips out the tags, leaving masses of redundant vertical white space in the plain text part. The resulting plain text part is often effectively unreadable.

          As this essentially trivial problem to solve has been in evidence for absolutely ages and has not so far been fixed, any recommendation from Redmond about tools should be taken with a big dose of Epsom salts.

      5. BinkyTheMagicPaperclip

        Re: Where's the IT content?

        With respect Dio, you haven't thought this through. Not only does this affect the submission process, which may force some contributors to use a different client or in some cases hardware (if they're using something really old), but more importantly it affects the mailing list archives which are both distributed and easily searchable.

        If someone wants to write a shell script/program that automates this, there's nothing stopping them, but the one thing it absolutely shouldn't do is pander to HTML mail clients, which just make parsing harder.

    2. Robert Grant Silver badge

      Re: Where's the IT content?

      They're trying to attract people who can't do plaintext email, but are insanely good enough technically to be Linux maintainers.

      So what I'm saying is, the IT context is this is some hilarious bikeshedding.

    3. gregzeng

      Re: Where's the IT content?

      Wonk. With Out Normal Knowledge. Normal is the error. Solutions come from a tiny part of the very many outers who are not currently part of normality. Innovation is hard for the normals.

      1. Man inna barrel

        Re: Where's the IT content?

        I had a need to grep my emails for some content I knew was there. The built in webmail search was not working. This text-level search would have been quite possible if the format were just HTML. But my BT Mail had to go further than that. All the HTML was base64 encoded. Aargh!

        1. jake Silver badge

          Re: Where's the IT content?

          So add a base64 decoder to the pipeline. Simples.

    4. Anonymous Coward
      Anonymous Coward

      Re: Where's the IT content?

      Here's Jake being an arse again.

  2. hayzoos

    So not just about plain text email

    I came to post my preference for plain text. It is simple, effective, and efficient. When "Hello World" is HTMLized it can consume mind boggling amounts of resources. I have intentionally crossed email messaging and programming/developing boundaries by referring to "Hello World". Developers have overly complicated programs. The push to HTMLize communications represents a furthering of the complicating. In fact, even HTML has been overly complicated from it's original intent.

    Email is a text communication medium with the ability to transmit additional media. It has been subverted to a more complicated messaging system. I receive a simple message via email which could be less than 1kb if text only, but turns out to be over 1mb when HTMLized under modern HTML.

    With the above comment, I see this goes beyond just the technicalities of messaging. It goes to the heart of the takeover by the clueless.

    1. Andrew Commons

      Re: So not just about plain text email

      The thing is that HTML email clients provide really good support for tracking technology.

      Now that's got to be a good thing!!!

      Well, actually no, and maybe the folk who are aware of and concerned by the tracking implications are the sort of folk you want in the kernel.

      Have an up-vote.

    2. oiseau Silver badge
      WTF?

      Re: So not just about plain text email

      I came to post my preference for plain text. It is simple, effective, and efficient.

      +1

      I came here for the same reason as you and also to give you an additional upvote.

      ... the heart of the takeover by the clueless.

      Not so clueless.

      It is Microsoft Corporation you are talking about.

      Takeover? Yes, undoubtedly.

      Clueless? No, not really.

      They have 30+ years of practise at this.

      Their ultimate goal is to infest the Linux ecosystem and rot it from the inside.

      Clueless are those who can't see what is going on and act accordingly.

      O.

    3. Nate Amsden

      Re: So not just about plain text email

      I'm sure I'm a tiny minority here when I say i host my own email(since 1997) and even have it auto strip most html tags. Sometimes that means the email is hard to read and in rare cases end up completely blank. But most of the time it's fine. Also of course compose in plain text.

      I haven't spent much time messing with my email system over the years other than OS updates. hell just recently i dug into some errors and turns out one of the RBLs i was using shut down about 7 years ago. Wow. But wait then i saw another RBL shut down 14 years ago. Never caused an issue other than errors in the logs but finally removed them.

      I was forced to switch to html mail for work last year i usually use OWA on office 365. However they put a critical bug breaking composition of text emails by auto removing line breaks. I complained to IT who brought it up with MS. (UPDATED) - more than a year after I reported this issue the line break problem still exists today. The message in "Sent" email looks fine, but when it came back to my inbox it was mangled.

      1. jake Silver badge

        Re: So not just about plain text email

        "I'm sure I'm a tiny minority here when I say i host my own email"

        Probably not all that tiny. Hands up all you ex- Demon users ...

        1. Peter2 Silver badge

          Re: So not just about plain text email

          "I'm sure I'm a tiny minority here when I say i host my own email"

          You might be in a tiny majority on some sites but this is a site that aims at IT Professionals, power users, and people who aspire to be in the first two categories. You are probably in much less of a minority than you think you are.

          I have hosted my own emails for a couple of decades.

        2. Vometia Munro

          Re: So not just about plain text email

          *waves*

          Been through several ISPs since the glory days, moving on as their fortunes have waxed and waned, but only those who'll give me a static IP and not get the arse-ache about me using SMTP.

      2. james_smith Silver badge

        Re: So not just about plain text email

        I think there's an option in OWA to enable IMAP support. Then you can use a real email client like Thunderbird that has the option to present all emails as plain text. Whether you can get whoever administers your O365 setup to enable that option is another matter though - it was hard enough sometimes in the days when MSexchange was taking over the world, although we (the developers on Unixy platforms) succeeded at one company by pointing out that mandating Outlook as mail client was fine as long as manglement accepted we'd never reply to their emails.

      3. This post has been deleted by its author

      4. NoKangaroosInAustria

        Re: So not just about plain text email

        I also host my own mail server.

        And speaking of standards compliance (warning - rant alert), after a fair bit of deliberation, i recently implemented DKIM and SPF to try and reduce the amount of spam emails i get. I can only handle so many offers for cheap boner pills and love in all the wrong places per day.

        I was quite surprised at some of the major corporations with improperly configured or non-existent SPF records i discovered.

        In one instance, a Company had some of their mail servers located in a cloud environment. Presumably, this wasn't their original setup, because while they actually did have an SPF record, their SPF record reflected only their actual domain but not the domains / IP adresses of the cloud provider on which their mail servers were hosted, prompting my mail server to reject all emails coming from them as most likely being spam.

        Since I do need to continue receiving emails from them, I took the easy way out and whitelisted their cloud provider from SPF checking at my end.

        *sigh*

    4. meritamity

      Re: So not just about plain text email

      "It goes to the heart of the takeover by the clueless."

      This. A profound statement actually, but some might take it the wrong way.

      It really isn't a barrier to require a bit of experience and ingenuity to follow conversations. I also become wary when corporate executives and consultants start wanting changes, since I'm apt to think, "Give 'em an inch, and they'll take a mile."

      Or, maybe it's harder to Extend when it's difficult to see what's being Embraced.

    5. Nunyabiznes Silver badge

      Re: So not just about plain text email

      As an aside to your point (excellent btw):

      Can you imagine how fast our computers today would be if all programmers were made to code /and test/ their software on ancient hardware? Even if they were forced to use the median performance level home computer in the wild to do their work on, it would be an eye-opening experience.

      It seems the better the hardware, the sloppier the coding (in general).

      1. tfb Silver badge
        Alien

        Re: So not just about plain text email

        Exactly. Because the old hardware was so slow they'd spend a lot of time optimising everything into the ground. Languages which encouraged you to write safe code, with all their hairy type checks, automatic bounds checking and slow complicated compilers would not be used: instead everyone would use languages which were close to the hardware. No-one would add explicit checks because they make things really slow. Systems which automatically encrypted data at rest would be far to expensive to use, so all but the most critical data would be stored in plain.

        It would be great.

      2. swm Silver badge

        Re: So not just about plain text email

        The Xerox STAR office product was slow because the developers never used it. They used XDE that ran on the same hardware to develop the code. XDE ran like lightning.

        1. jake Silver badge

          Re: So not just about plain text email

          "The XeroxSTAR Office automation software package[0] was slow because the hardware it was designed for was under powered for that kind of system. The developers didn't use STAR because it was an office automation system, not a development environment. The DE that they used was called Tajo[1], an early IDE. As with most intelligently designed IDEs, Tajo used few system resources and ran OK on the slow hardware of the day."

          FTFY

          [0] The thingie known as STAR was just the software tools for office automation. The hardware, OS and networking were completely separate, if linked, projects.

          [1] Outside Xerox, Tejo was called Xerox Development Environment, or XDE.

  3. Gene Cash Silver badge

    Is setting up a non-shitty email client really that hard?

    It boils down to people being lazy and impolite.

    How about people stop the goddamn top posting?

    How about email clients having a plain-text version of the email instead of a choice between HTML and fuck-you? A true modern email client should be able to provide plain-text email by checking a preference. If it can't, then it is broken.

    The advantage of plain text is that you can search it, and quote it, and thread a conversation in an archiving page, and do a lot of things that HTML breaks.

    Why should I have to deal with parsing the shitty HTML a lot of mail clients (including Thunderbird) put out?

    gmail and the Apple Mail do a lot of shitty things. For example, I regularly get work emails at home because Apple Mail just puts "Gene Cash" in the address, and people can't tell if that's my work address or my home address. People don't give a shit to the point that I've had to stop responding to these emails from home.

    Why are people focusing on the HTML wrapper instead of the message inside it?

    If you can't configure your email client, do you really belong on the LKML or writing kernel code?

    1. oiseau Silver badge
      Facepalm

      Re: Is setting up a non-shitty email client really that hard?

      Hello:

      If you can't configure your email client, do you really belong on the LKML or writing kernel code?

      In one word two words?

      Fuck no.

      O.

    2. _andrew

      Re: Is setting up a non-shitty email client really that hard?

      Apple Mail is perfectly capable of sending and displaying plain text email, and I'm fairly sure that the default is the correct option: reply according to the source message type.

      The display or non-display of full email addresses in the composition bar is also an option: you could choose to show the whole thing to avoid your (own) confusion. What you see of email addresses when composing or reading has no relationship with what your recipients see: that will be up to their email clients and the settings that they've configured.

      Apple Mail does have a couple of infelicities that I'd prefer it didn't: the "load remote content" switch is global; you can't train it that certain senders are OK but most aren't, and so the only safe way to operate (no automatic download of images) requires an extra click for the messages that you do want to see images in. It also has this "guess which outgoing account is most appropriate" mechanism, and I have also had it choose to send work email from my home account, and that in turn has been because I have the default real-name display turned on. It has improved a bit lately, in that it does display your full email address in the From: field when composing, but you still have to be paying attention if it guesses incorrectly.

      That said, Apple Mail is still my favorite email client, by far. I never found its equal when I ran a Unix desktop, and don't know of anything comparable on Windows, either.

      1. Tim99 Silver badge
        Gimp

        Re: Is setting up a non-shitty email client really that hard?

        Sorry, this is probably because I’m a grouchy old fart - My Apple Mail is configured to always reply in plain text. That way, I know roughly what it will look like at "their" end. I did this (to keep what little mental capacity I have left) after seeing what my emails looked like when they came back via a long chain of additional comments and replies where each author had used "whatever" platform. Many people now use their phones for almost all of this - I put in a feedback request to Apple to give me a similar option on iOS, but no luck there - My workaround is to copy/paste everything in/out of txt4ios or QuickText before sending it.

        1. Anonymous Coward
          Anonymous Coward

          Re: That way, I know roughly what it will look like at "their" end.

          I once (perhaps a year or two ago) submitted a job application by email which consisted of (as requested) a pdf CV and a short two paragraph covering letter. I did the covering "why I'd be good at this" paragraphs in plain text, so it could be quickly and easily read without difficulty, and without any pointless "see attached" nonsense.

          The acknowledgement of my application was a cc of a forwarded version of my email from the HR contact to the guy in charge of hiring. In this forwarded version, my carefully crafted covering paragraphs had been indented and re-wrapped to different line lengths by some automatic process, making them ugly to look at and difficult to read. As a consequence, I strongly suspect my application (as internally forwarded) barely even got looked at.

          Even plain text is no defense against other email clients remangling one's elegant formatting. :-(

          My current bugbear at the moment is ms office calendar-generated meeting reminders, which, even on close inspection, contain no human intelligible information whatsoever, even in the subject line.

          1. Tim99 Silver badge

            Re: That way, I know roughly what it will look like at "their" end.

            If you are ever tempted to try sending plain text again, can I suggest no line breaks except at the end of paragraphs? Using a double break is usually OK, single breaks do seem to get mangled...

      2. Charlie Clark Silver badge

        Re: Is setting up a non-shitty email client really that hard?

        Apple Mail fucks up a lot of things in e-mail, particularly the way it handles attachments, especially images.

        I much prefer MailMate.

    3. Dan 55 Silver badge
      Trollface

      Re: Is setting up a non-shitty email client really that hard?

      The barrier is very high, if you search for "Get Thunderbird" using Microsoft's Bing, Lord knows where it would send you.

      1. jake Silver badge

        Re: Is setting up a non-shitty email client really that hard?

        Bing still exists? Who knew?

        1. Tim99 Silver badge

          Re: Is setting up a non-shitty email client really that hard?

          People who’s browser often displays pornography?

        2. jelabarre59 Silver badge

          Re: Is setting up a non-shitty email client really that hard?

          Bing still exists? Who knew?

          I should hope so. Whenever I send a sarcastic feedback to Google for the latest thing they've fucked up, I usually suggest they should do a search for solutions on Bing.

    4. Dave559 Bronze badge

      Re: Is setting up a non-shitty email client really that hard?

      Massive thumbs-up for highlighting the problem of email programs which only show the person's name and not also which email address is actually being used for that person.

      Given that many/most people have different email addresses for different contexts, not just work/home, which fucktard ever thought that was a good idea? (And Apple, who generally have quite good UI guidelines, should be especially ashamed of themselves.)

      Hiding email addresses also helps enable all those phishing attacks supposedly

      From: "Your Company It Service Departement Central" <baitedhook@phishyphishy.invalid>

      Grrr!

  4. ST Silver badge
    Devil

    No that's not how it works

    GMail is perfectly capable of sending and receiving plain text email. No, you don't have to switch email clients to send plain text emails. You can do that from GMail's web interface, or from some other email client connecting to GMail via IMAP/POP3/SMTP.

    BOHICA: Microsoft got involved in Linux*. Next thing: the Linux kernel should switch to Microsoft Project for feature tracking.

    -----

    [*] US vets will know what that means.

    1. David 132 Silver badge
      Trollface

      Re: No that's not how it works

      the Linux kernel should switch to Microsoft Project for feature tracking.

      I like the way you think, though personally I feel Project is too lightweight for such an important task, and MSFT should push for the use of Sharepoint/Teams for the Linux Kernel development process. (Trollface icon)

      But I’m sure they’ll be a bit more subtle about it and encourage Mr L. Poettering to step up to the plate instead. Why, at this very moment he’s probably beavering away on a LinuxKernelTrackerD add-in for SystemD...

      1. seven of five Silver badge

        Re: No that's not how it works

        Och. Do you want me to laugh or to cry? Maybe I just become sick and throw up over here.

        1. oiseau Silver badge
          Alert

          Re: No that's not how it works

          ... become sick and throw up over here.

          I just did. =^ ⁷

          O.

      2. stiine Silver badge
        Facepalm

        Re: No that's not how it works

        Don't give him any ideas.

    2. tfb Silver badge
      Pirate

      Re: No that's not how it works

      GMail is perfectly capable of sending and receiving plain text email. No, you don't have to switch email clients to send plain text emails. You can do that from GMail's web interface [...]

      Well, if you type git help format-patch you will read this:

      GMail does not have any way to turn off line wrapping in the web interface, so it will mangle any emails that you send. You can however use "git send-email" and send your patches through the GMail SMTP server, or use any IMAP email client to connect to the google IMAP server and forward the emails through that.

      So no, no it isn't perfectly capable of sending plain text unless your definition of 'plain text' includes ' wrapping the lines for you' which is often a bit unfriendly to code.

      Entertainingly I had to manually remove line-breaks in the above to make it format properly here.

      1. ST Silver badge
        FAIL

        Re: No that's not how it works

        > So no, no it isn't perfectly capable of sending plain text [ ... ]

        Have you heard of email attachments? They're really cool. Been using them myself for 20+ years.

        Proper patch submission etiquette - and not just for LKML - strongly recommends that patches be sent to the mailing list as attachments, not inline.

        Yes, mailing lists can handle attachments just fine.

        For one, copying and pasting a context/diff patch into an email client text editor will remove formatting. It will definitely translate tabs into spaces. Which will break the patch header, and the patch will no longer apply.

        For two, it's much easier to download the patch sent to the mailing list as a properly formatted attachment, rather than requiring the patch/code reviewer(s) to copy-and-paste the inline - and badly - re-formatted patch into a new file, and then attempt to restore the formatting by hand.

        I take it you don't have much experience with submitting patches to major open source projects. Neither does Ms. Novotny, apparently.

        1. tfb Silver badge
          Terminator

          Re: No that's not how it works

          Have you heard of email attachments? They're really cool. Been using them myself for 20+ years.

          Surprisingly enough, yes, I have heard of them.

          Proper patch submission etiquette - and not just for LKML - strongly recommends that patches be sent to the mailing list as attachments, not inline.

          I see. So, hmm, there's this document, you see, and if you look at section 6 you will read this (mildly reformatted by me to preserve bold &c, text unaltered):

          6) No MIME, no links, no compression, no attachments. Just plain text

          Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to “quote” your changes, using standard e-mail tools, so that they may comment on specific portions of your code.

          For this reason, all patches should be submitted by e-mail “inline”.

          Warning Be wary of your editor’s word-wrap corrupting your patch, if you choose to cut-n-paste your patch.

          Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted.

          Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME.

          See Documentation/process/email-clients.rst for hints about configuring your e-mail client so that it sends your patches untouched.

          So, well, I'm sure the people who wrote that don't have any say in how people are expected to submit Linux patches. Who is this 'Linus' guy anyway, and what's he doing telling us what do do?

          I should feel sorry for you for making such a fool of yourself in public, but I don't, because, really, how hard was it to check what the guidelines actually were? Too hard, I suppose. Unlike Sarah Novotny, who clearly has read them.

          1. ST Silver badge
            FAIL

            Re: No that's not how it works

            > No MIME, no links, no compression, no attachments. Just plain text.

            You should have read the entire document:

            https://www.kernel.org/doc/html/latest/process/email-clients.html#email-clients:

            Patches for the Linux kernel are submitted via email, preferably as inline text in the body of the email. Some maintainers accept attachments, but then the attachments should have content-type=text/plain. However, attachments are generally frowned upon because it makes quoting portions of the patch more difficult in the patch review process.

            Email clients that are used for Linux kernel patches should send the patch text untouched. For example, they should not modify or delete tabs or spaces, even at the beginning or end of lines.

            Don’t send patches with format=flowed. This can cause unexpected and unwanted line breaks.

            Don’t let your email client do automatic word wrapping for you. This can also corrupt your patch.

            Email clients should not modify the character set encoding of the text. Emailed patches should be in ASCII or UTF-8 encoding only. If you configure your email client to send emails with UTF-8 encoding, you avoid some possible charset problems.

            Email clients should generate and maintain “References:” or “In-Reply-To:” headers so that mail threading is not broken.

            Copy-and-paste (or cut-and-paste) usually does not work for patches because tabs are converted to spaces. Using xclipboard, xclip, and/or xcutsel may work, but it’s best to test this for yourself or just avoid copy-and-paste.

            So: It's perfectly OK to send patches as attachments, as long as you follow the rules for sending patches as attachments.

            Maybe you can clarify here for all of us what any of this has to do with your earlier assertion about GMail being unable to send or receive email in plain text.

            Do you work at Microsoft?

            1. tfb Silver badge
              Terminator

              Re: No that's not how it works

              So it says 'Some maintainers accept attachments' from which you deduce that 'It's perfectly OK to send patches as attachments'. Um.

              And it also says:

              Gmail (Web GUI)

              Does not work for sending patches.

              With a bunch of information about why, which amounts to 'it mangles the text you send'.

              I'm done here: you could gracefully admit you are wrong, but clearly you're too up yourself to do that.

              1. ST Silver badge
                FAIL

                Re: No that's not how it works

                Gmail (Web GUI)

                Does not work for sending patches.

                Sadly, you are very confused.

                GMail is a Mail Transfer Agent. You should read the Wikipedia article at this URL. You might learn what a Mail Transfer Agent is, and what it does.

                GMail's Web GUI is NOT a Mail Transfer Agent. It's a Mail User Agent. Or an Email Client.

                Think of it this way: GMail's Web GUI is like Microsoft Outlook 365's browser-based interface. GMail - the Mail Transfer Agent - is like Microsoft Exchange. It sends and receives your emails.

                Your GMail email address does not change depending on which Mail User Agent (email client) you use. You can use several email clients for the same GMail account.

                The browser-based interface provided by Google that you see in your browser is one of the many possible GMail Mail User Agents. It is an interface to GMail.

                So: No. Your assertion that GMail cannot send or receive plain text emails is confused, uninformed and wrong. There is a big difference between a Mail Transfer Agent and an Email Client.

                The URL I posted earlier provides a long cookbook on how to configure an email client (Mail User Agent) to send correctly formatted attachments to LKML.

                Thunderbird and KMail are two of the email clients mentioned in that cookbook. There are many others. Any of these email clients can use GMail as a Mail Transfer Agent.

    3. jelabarre59 Silver badge

      Re: No that's not how it works

      BOHICA: Microsoft got involved in Linux*. Next thing: the Linux kernel should switch to Microsoft Project for feature tracking.

      CMVC would be *much* more fun...

  5. Some Random Kiwi
    Facepalm

    And he also couldn’t do it from Apple Mail.

    So, she has an educated partner who can't find the Format/Make Plain Text (shift-command-T shortcut) in Apple Mail? Really.

    1. A Non e-mouse Silver badge

      Re: And he also couldn’t do it from Apple Mail.

      And switching between plain text and HTML on Outlook isn't difficult either.

      1. T. F. M. Reader

        Re: And he also couldn’t do it from Apple Mail.

        And going (quite a few years, let's say >10 to protect the guilty) back to my IBM Research days when I worked fairly tightly with both the IBM Linux Technology Center and the non-IBM Linux development community, it was standard practice to have two mailboxes - one internal with Lotus Notes and one external with normal plain text email. IIRC to get the second, non-Lotus mailbox you had to request it and say that you needed to work with the Linux community to justify the request, but I don't remember much (or any) bureaucracy or undue difficulties around it. Even IBM realized that it was not as big as the whole world and that its internal tools caused problems interfacing with the rest of the Universe, occasionally. They made an effort - not huge, but commendable nonetheless - to deal with the "barrier to entry".

        But that was then...

        1. Doctor Syntax Silver badge

          Re: And he also couldn’t do it from Apple Mail.

          "But that was then..."

          Exactly. It's developers who grew up in the last 5 to 10 years who are the problem.

          1. Yet Another Anonymous coward Silver badge

            Re: And he also couldn’t do it from Apple Mail.

            >Exactly. It's developers who grew up in the last 5 to 10 years who are the problem.

            They can presumably instagram screenshots of the code, captured on their phone?

    2. tfb Silver badge
      Pirate

      Re: And he also couldn’t do it from Apple Mail.

      Here's the thing: if you'd tried that, you'd know it does not work. Because 'plain text' means 'plain text with lines wrapped' which is just a little bit hostile to patches.

  6. Mr. Balise
    Facepalm

    Plain text. Microsoft was always wrong. Always.

    1. Neil Barnes Silver badge

      Faintly ironic

      That the trend to html or other formatted text in email was started by MS, and here we have an MS spokesbeing complaining about its effects.

      Count me in the 'no html in email' crowd.

      1. Doctor Syntax Silver badge

        Re: Faintly ironic

        Even more ironic in that it was MS in the person of Gates who resisted the WWW until it was top big for even them to ignore.

        1. Teiwaz Silver badge

          Re: Faintly ironic

          Even more ironic in that it was MS in the person of Gates who resisted the WWW until it was top big for even them to ignore.

          After which point, they did their best to give the impression it was invented at Microsoft, or at the very least that they had a important role in it's creation and direction.

    2. Lotaresco Silver badge

      Not least because Microsoft chose to implement top-posting as the default in Outlook, breaking the model used by previous email clients.

      "Plain text. Microsoft was always wrong. Always."

      1. seven of five Silver badge

        lovely.

        I see what you did there.

        And the natural flow of reading.

  7. perlcat

    As usual

    Microsoft corrupts everything it touches.

  8. CrackedNoggin

    I'm ignorant about Kernel contributions, but familiar with using git with the Github front end. "git" was created by Linus. I must be missing something because I can't see how submitting patches via text email could be superior to using git with a suitable front end, sending data over https or ssh.

    1. cbars Silver badge

      Now you've got two things to manage, the front end (bug riddled, got-to-be-on-trend javascript wasteland) AND the Kernal.

      So you outsource, now you've got a dependency and potentially a revenue impact. And you rely on a single hosted site, vs the redundant infrastructure of email which for the most part will route around problems - so only a single contributer goes offline instead of the whole lot.

      Its just not an argument. Kernel developers are not consumers, and do not need to web-scale in this Silicon Valley grow-like-mad model. They are few and far between, and if undestanding a 1980s (earlier?) text protocol is beyond you, so is the kernel.

      You dont even need to install a new client, I myself have previously sent email direct from the command line on Linux, and via a 20 line python script* that I wrote on Windows. Email is piss-easy.

      *OK, fine, there might have been a library in there, I can't remember the details as it was a 20 minute job several years ago

      1. CrackedNoggin

        Yes, I've done the same (sending mail from linux command line). But to make it work I had to first sign up for free service from a mail forwarder because I didn't want to lower the security settings on gmail account , which would have been required to use gmail as the forwarder. To forward system warnings on a VPS.

        How about setting up a website to which a submitter can login using ssh/2FA and upload, which then sends the uploaded file as mail, including the account name and mail address of the submitter? That would be more secure than trusting plaintext email.

  9. demon driver

    LKML should...

    ... just move from mailing list to usenet newsgroup.

    1. Alan J. Wylie

      Re: LKML should...

      > ... just move from mailing list to usenet newsgroup.

      You can already read it over NNTP

      nntp+news.gmane.io:gmane.linux.kernel

    2. 2+2=5 Silver badge

      Re: LKML should...

      > ... just move from mailing list to usenet newsgroup.

      Came here to say the exact same thing. And add that the content could be checked by a bot automatically: patches have to follow a template and any that don't can be flagged by the bot. Maintainers can then filter their feed to see only the group/sub-group for the bit they maintain and only patches that have passed the initial checks. Should at least cut down on the noise.

      Maybe the GNU foundation could consider it for a selection of their smaller projects as a trial run?

  10. dboyes

    Reality check to Sarah: I do Linux device driver development for very nice pay on a machine that is literally on another continent separated by two oceans and 4 satellite links. That machine cannot be located nearer to me; my living room isn't big enough and doesn't have sufficient power to run it, there are no better communications options available and I don't have several million dollars for the equipment. Cross-compiling is not sufficient to deal with issues so close to the bare metal. If you want to change my tools, I have some non-negotiable requirements: 1) the tool be publicly documented in full, zero closed source or binary only bits at all, 2) it must be compilable and fully functional on non-PC hardware without a GUI of any kind, and 3) it must be completely functional and usable over a low-speed high-latency network involving significant round trip times for character echo. If your 'improvements' can't cope with a 2-3 second RTT, then I'm not interested.

    Plain text is used because it works seamlessly over highly degraded communications scenarios and Linux has to be buildable and supported on non-PC systems. Until you can deal realistically with that concept, you've got no business trying to change things that work. It's also characteristic of really large development projects that new developers have to learn the conventions being used by the project; if you're not a team player you don't have any business being there. If new developers can't learn how the project operates and the tooling involved, then there isn't much hope for them to progress successfully.

    TL;DR: Ain't broke, don't fix it. Your proposal doesn't work or progress the development process in an environment that has to live on so many different platforms and environments, and those environments are getting more diverse, not less. The current setup does. Working code beats style in every conceivable case.

    1. tiggity Silver badge

      Wish I could upvote more.

      Be it opensource or working for a company, you have to fit in with processes in use.

      Usually (not always, but there are in this case) there are reasons why particular methods are used.

      As was implied above, plain text email as lowest common denominator available to just about any OS / hardware, works on dismal connectivity,plain text body is not a potential malware vector (unlike HTML mail) etc, etc.

    2. A Non e-mouse Silver badge

      I thought Sarah was talking about how developers share their work on the kernel, not how how each developer should write said code..

      1. Anonymous Coward
        Anonymous Coward

        "I thought Sarah was talking about how developers share their work on the kernel, not how how each developer should write said code.."

        First one, then the other. Embrace - Extend - Extinguish. That's the mantra for MS since 1980s and you already can see the *second* step here. *Demanded* by a MS puppet. What a surprise, eh?

        Novotny herself was the first step. Outright evil from the start: The goal *always* is step 3: Extinguish.

        Doubly so for Linux, the major, and basically only, competitor.

      2. eldakka Silver badge

        I thought Sarah was talking about how developers share their work on the kernel, not how how each developer should write said code..

        But how does @dboyes share their code then? They are writing the code on this remote high-latency system. And do they then submit that code to be included in the kernel?

        I'd imagine right now, they write their code on that remote system, then just use a command-line email client on that remote system to send the code they've just written to the LKML. And likewise to receive any responses that may have code changes in it.

        If they have to use some sort of GUI HTML-ised application that only runs on x86 windows PCs, which this remote system isn't, how are they now going to send that code? They'd have to copy to their local system (scp/sftp etc.), then fire up that HTMLized client, and then submit the code - and vice versa if someone in the LKML suggests enchancements, they'd have to copy it out to that remote machine before using it. And that assumes tehy have a compliant local system that can run this sugested GUI for the messaging system.

    3. Anonymous Coward
      Anonymous Coward

      settle down stallman with your demands

      this is the reason maintainers are hard to find, who wants to wrangle a bunch of prima donna oddballs who have spent too much time at baremetal to understand that this discussion is about the fact that to attract new blood your going to have to move on from 80's tech, , like it or not the next gen uses noddy devices for everything, if plain text is impossible on a mobile device then you need an alternative end of.

      whether that is of any interest to you and your very limited niche doesnt matter, wont effect you, but your opposition to it just does what; keep open closed? leave your legacy to the great unmaintained and deprecated archive in the sky?, if we are talking about 10 years from now, then your average senior dev will be a digital native, maybe with vague memories of going to preschool and parents having feature phones with polyphonic ringtones, so yeah enjoy your isolation, but if they cant use there phone to do it, they wont, only reason watches are worn again is because they link to phone and give them graphs about excercise and other puritanical no fun crap millennials seem to be into, other wise its one device for 99% of use cases, watch, phone, alarm, comms, camera all one device, ignore it and face irrelavancy...

      1. Anonymous Coward
        Anonymous Coward

        " to attract new blood your going to have to move on from 80's tech, , "

        This is patentable BS from the start. Another MS droid who doesn't understand an iota *why* such tools are being used and what are the issues with "modern", i.e. Microsoft-owned tech.

        And, as usual, buttload of whining about "old tools" but not a single example of free (as in GPL) *new tools* to have same set of features without malfeatures. MS isn't providing any, that's for sure.

        " then your average senior dev will be a digital native, " They already are. Have been a long time, moot point. Also: Playing with phones isn't going to get you ever to senior developer position, toy-level technology.

        "other wise its one device for 99% of use cases, "

        Which is blatant BS. Majority of servers run on Linux now and those are much important to Linux than phones or watches. The *amount* of toys is always irrelevant when you working on tools to do actual work.

        1. Anonymous Coward
          Anonymous Coward

          I called them noddy devices, you call them toys same diff

          Not an ms droid, run *nix for daily driver for last 25 years...

          Im a fan of plain text generally, but the usual OSS/Kernel crowd hysteria at change and pragmatism is why OSS tech gets USED but not REWARDED, fact is the next gen and the current school kids will use different tech, and given the crap level of support for plain text on wonder devices there will need to be something to cater for that

          My 99% of use cases have nothing to do with linux, just the fact that in 99% of usecases in real world i.e. away from desk and monitor is done on a phone now, who carries a digital camera, pda, phone, diary, watch and gps any more???

          Its that 99% of the population you have to think about not us 1%ers who know what a computer, avoid touch interfaces and sees a smart phone as nothing more than laptop i wish i could have had 20 years ago....

          True if you expect to commit kernel code you probably should be able to setup a plain text client, but frankly its daft to assume that nothing better could be conceived of, and to deny a conversation on it is a bit backwards in my opinion...

          1. Charles 9 Silver badge

            IOW, this sounds a lot like "Get off my lawn" talk, with the newer generation quipping, "Like we give a screw, Gramps!" Recall there were operating systems before Linux and there will likely be ones after it as well. How long Linux remains relevant can depend on these kinds of choices.

      2. m4r35n357

        Hmm, "pragmatic, plausible sounding" anonymous windbaggery. You guys just don't give up, but we are used to it!

        1. Yet Another Anonymous coward Silver badge

          >Hmm, "pragmatic, plausible sounding"

          "share and enjoy"

          1. David 132 Silver badge
            Happy

            "Go Stick Your Head In A Pig"

      3. Doctor Syntax Silver badge

        @A/C

        You'll find a shift key or two somewhere on your keyboard. Just don't overuse it.

      4. cbars Silver badge

        If their smart phone is 1) not able to send plain text email or 2) where they're doing the majority of dev... they are not kernel developers

        Want to send plain email from your phone? Thousands of ways to do this. Want to try and write code with only your thumbs, no mouse, AND fucking autocorrect - you're insane. There is a reason keynoard shortcuts exist and its not for playing angry birds (or whatever people play now)

        1. Anonymous Coward
          Anonymous Coward

          To be fair i dont think anyone is suggesting coding on a phone, but browsing and replying to a mailing list why wouldnt you expect to be able to do that with a standard mail app?

          If plain text in the right format is hard/impossible to do on a mobile then why would anyone object to an alternative.

          If i cant reply/join in using my primary mail app, and have to use a secondary app yeah it will get used and accessed a lot less, it is a speedbump and will put people off, if its meant to be an aptitude test thats some of the dumbest guff ive heard for a long time.

          While plain text may work and will always be around, same can be said of GSM phone networks and mono audio, which sure for compatibility reasons are fine, but if you have access to something better/more conveinent/more usable why they hell would you not use it?

          1. cbars Silver badge

            @anon, from the above post suggesting exactly that

            "if they cant use there phone to do it, they wont"

            They're therefore either doing everything on their phone, or using appropriate tools.

  11. Adam Foxton
    Trollface

    Absolutely.

    This is just the sort of change Linux needs. Good forward-thinking changes. Maybe HTML formatting could be brought into the Terminal too, and format-sensitivity so programs know bold arguments are to be taken extra seriously.

    I can't wait for them to release a Kernel written in something more advanced, like Java. Come on Linus, get all that hardware-specific rubbish out of the kernel!

    1. GrumpenKraut Silver badge
      Go

      Re: Absolutely.

      > bold arguments are to be taken extra seriously.

      I want Comic Sans arguments, animated by Javascript pulled from random third party hosts. Plus OLE and DirectX for full compatibility with agile management. And blockchain, blockchain is good.

      1. james_smith Silver badge

        Re: Absolutely.

        Perhaps a file system based on an eventually consistent NoSQL database?

      2. jelabarre59 Silver badge

        Re: Absolutely.

        I want Comic Sans arguments, animated by Javascript pulled from random third party hosts.

        What, you want text-based command arguments??? Why, I'd want commands I can enter with animated emojis. Can we use this ( https://tenor.com/bjWjA.gif ) for submitting crash reports?

        1. GrumpenKraut Silver badge
          Pint

          Re: Absolutely.

          Whilst composing my post I actually thought of animated emojis (Mr. Hankey to be specific) but discarded the idea as over the top.

          1. David 132 Silver badge
            Happy

            Re: Absolutely.

            Whilst composing my post I actually thought of animated emojis (Mr. Hankey to be specific) but discarded the idea as over the top.

            Err, surely Mr Hankey is under the Bottom.

  12. Anonymous Coward
    Anonymous Coward

    Nobody exhibiting the sheer lack of discipline to prefer the convenience of HTML email over the reliability and portability of plain text, when dealing with something so important and volatile, has any business being even near a microcontroller ROM, let alone the Linux kernel. At work, we use HTML email for daily use and it is convenient; but then, we're not risking a malformed OS kernel by sending emails that way. (Anon as my employer might be reading this).

  13. petethebloke

    You don't have to be old to hate HTML emails

    ...but what I *really* hate is HTML emails without a plain-text version included.

    1. Esme

      Re: You don't have to be old to hate HTML emails

      I am not a coder, although I dabbled back when home computers were a new thing. I have never used HTML email - because when it first became a thing, it was rapidly found to be a security issue, and I haven't heard anything to contradict that since.

      Businesses do not have a good track record of being rational where IT is concerned; cheap (or alternatively - "It's expensive so it must be good." Yeah, pull the other one, wanna buy a bridge?) shiny and "well everybody else is using it so it must be OK" tend to carry too much weight with businesses, as against security, (business) sustainability, failover options and avoiding vendor-lock-in.

      I'd be interested to know what more modern forms of communication wannabe developers would like to use in order to get involved with the Linux kernel. Then we could sensibly compare and assess the pros and cons of those methods as against plain text email.

      Personally, I don't use any of the more recently developed methods of communication, as email along with IRC and forums serves my particular needs just fine. So I'm not aware of the various boons that more modern methods of communication may have. Perhaps some of the young coders out there are not aware of the capabilities that older and well-tested methods have, and simply need educating in them? Hang on - aren't we talking folk with the kind of skillset that can handle Linux kernel development, for heaven's sake?!

      No. No, I am not going to assume that young coders of that kind of skill level are unaware of the capabilities of text email, but if they feel that change is needed to replace or add to a communication system that is robust and gets the job done, then some explanation of what precisely they'd like to bring to the party would be a good starting point for a conversation about it. Which the article author seems to have missed. What's in the article appears to say simply "young coders don't like text email because it's soo ooold and they're not used to it" If exactly that really is the case, then I don't want them working on the core of my preferred OS, thank you very much.

      If the article author (or their interviewee) meant to convey more, then they did a remarkably poor job of it, hence all the downvotes, I'd wager.

      As for the revelation that folk within Microsoft have constantly been reinventing the wheel, rather than pooling knowledge and collectively working out how to make a better wheel; well yes, that's been pretty obvious for many years, and is why I switched to Linux many years ago. Linux has generally simply got better and better over the years. <sarcasm> How's it working out with Windows, eh? </sarcasm>

      1. oiseau Silver badge
        Facepalm

        Re: You don't have to be old to hate HTML emails

        What's in the article appears to say simply "young apprentice coders don't like text email because it's soo ooold and they're not used to it"

        There.

        Reads better, methinks.

        What will happen is that they will never evolve to be coders.

        Real coders.

        O.

      2. 2+2=5 Silver badge

        Re: You don't have to be old to hate HTML emails

        Drifting away from your main point...

        > If the article author (or their interviewee) meant to convey more, then they did a remarkably poor job of it, hence all the downvotes, I'd wager.

        Actually, I think the author has done a great job of bringing home to Microsoft that Slack / Yammer / Teams / SharePoint / Visual Studio Enterprise Edition [1] / whatever simply don't cut it for real projects that require meaningful collaboration. Email is clearly less than ideal but it's still light-years ahead of the alternatives.

        [1] Or whatever it's called this month.

    2. GrumpenKraut Silver badge

      Re: You don't have to be old to hate HTML emails

      HTML emails without a plain-text version are actually convenient. They go straight into the bin so I never see them.

      1. Martin-73 Silver badge

        Re: You don't have to be old to hate HTML emails

        I haven't been bound by a legal update to terms from ebay or paypal for well over a decade due to them sending updates that when viewed as text/plain are entirely empty.

  14. Anonymous Coward
    Anonymous Coward

    The same goal here MS has always had: Kill Linux.

    "Novotny said it is also a barrier to new contributors"

    This reeks badly as MS embrace and extend- tactics, thus this Novotny-person is outright evil. MS is and will be so not a strech a bit.

    Whole claim is outright stupid and it's obvious sign MS wants some MS-only tool for *kernel developers* and the goal is obviosly to rot Linux from the inside.

    Rest of the talk is BS to cover this up and thus irrelevant.

  15. druck Silver badge
    Stop

    Keep stupid out

    Anyone that cannot set up a plain text email client, has no business being anywhere near kernel development.

    There should be barriers to entry when dealing with highly technical areas, and anything that keeps stupidity away from the Linux kernel is a good thing.

    1. Anonymous Coward
      Anonymous Coward

      Re: Keep stupid out

      nah just smacks of secret handshakes, a literal old boys club and boomers getting in the way again

      1. Anonymous Coward
        Anonymous Coward

        Re: Keep stupid out

        "a literal old boys club and boomers getting in the way again"

        That's BS and if you don't know it, it's time for a re-education camp.

        But kernel is complicated and you don't get it with 5 year java development experience.

        10 years of experience on programming + 5-10 years experience on Linux kernel + university degree + family, yes, you tend to be over 40.

        That's the reality. It's always bunch of teenagers who *believe* they know everything. They don't. Just like commenter above. Or Pöttering.

        1. Adair Silver badge

          Re: Keep stupid out

          Yes, there does seem to be evidence of the spirit of Systemd metastasizing.

          Why have something simple, that everyone can understand and use, when we can deploy something complicated that concentrates power amongst the few?

          1. Anonymous Coward
            Anonymous Coward

            Re: Keep stupid out

            $ sudo systemctl start lkml-alternate.service

        2. Doctor Syntax Silver badge

          Re: Keep stupid out

          "It's always bunch of teenagers who *believe* they know everything."

          Not just teenagers unfortunately.

          1. jelabarre59 Silver badge

            Re: Keep stupid out

            "It's always bunch of teenagers who *believe* they know everything."

            The appropriate term I've seen is "Chuunibyou" (https://en.wikipedia.org/wiki/Ch%C5%ABniby%C5%8D ). And yes, the URL has non-ASCII characters, just to make it more humorous for this discussion.

            Or if you want to spend a couple hours chasing multiple link threads, https://tvtropes.org/pmwiki/pmwiki.php/Main/Chuunibyou

      2. oiseau Silver badge
        Facepalm

        Re: Keep stupid out

        nah just smacks of secret handshakes ...

        Seems you forgot to use the 'Troll' icon.

        Don't do that, it is there for a reason.

        ie: so that the rest of us don't think you are absolutely full of shit.

        O.

        1. Anonymous Coward
          Anonymous Coward

          Re: Keep stupid out

          Cant anon post and choose icon, if anon its troll anyway...

          Seem to have struck a nerve though ;)

          and which ever comentard invoked java in this discourse that was a low blow lol

          Stand by my opinion though, kernel is C and ASM little bit of digital voodoo and takes quite a bit of effort to get into the lofi mindset to be dangerous with it, but plain text email is just AN method to use, which is increasingly irrelevant to the devs of tomorrow because there wonder device doesnt do it very well, but as i mentioned the old boys club is having a hissyfit at the prospect of change, but its not for them, its for the poor bastards who will pick up there reigns once they carked it....

          1. David 132 Silver badge
            Facepalm

            Re: Keep stupid out

            Seem to have struck a nerve though ;)

            Well, yes. Assuming you're the OP AC, you did indeed "strike a nerve".

            You'd have gotten the same reaction if you'd walked into a room and started scooping faeces out of your underpants and flinging them at people.

            Doesn't mean it's anything to feel proud of.

            1. Anonymous Coward
              Anonymous Coward

              Re: Keep stupid out

              Guess you're not a South Park fan, then. Shows that one's disgust is another's glee.

          2. cbars Silver badge

            Re: Keep stupid out

            The distinction between the spelling of there, their and they're is also increasingly irrelevant, right?

            Excellent parallelism though, if that was your aim! If not, then its nicely demonstrsting how hard it is to communicate via text, and why layering more complexity on top of that basic medium is likely to reduce clarity further, and by coincidence strongly erodes your argument

            1. oiseau Silver badge
              Facepalm

              Re: Keep stupid out

              The distinction between the spelling of there, their and they're is ...

              Quite obviously unknown to the poster, who evidently lacks some basic English language skills.

              O.

  16. Tom 7 Silver badge

    Plain text is plain text. HTML is not necessarily what you think it is.

    One thing about HTML is style sheets and javascript. One idea behind them is the recipient can use their style sheets to enhance accessibility amongst other things. Its also possible to completely obfuscate the content by a simple change to a style sheet which can move a word forward or backward in a message.

    In the same way I would never be dumb enough to send a legal document as a PDF to someone to print and sign I would never expect HTML to look exactly like it does on my machine because I cannot guarantee how it appears - you must have noticed how web sites fail to display sometimes as the CSS or javascript doesnt load for some reason Its not safe enough for important things.

    1. Anonymous Coward
      Anonymous Coward

      Re: Plain text is plain text. HTML is not necessarily what you think it is.

      If the recipient has sight issue, plain text is better as a screen reader can understand it and their client can easily apply sizing/contrast/fonts etc. Stylesheets and other bullshit prevents that from happening, or makes it orders of magnitude harder.

      We basically have MS to thank for the HTML bloat.

  17. The BigYin

    Plain text is king

    Well...OK...UTF-8 encoded Plain Text is king but whatever.

    If your mail client HTML-ises a plain text email then, I this is just my opinion, it the email client that is to blame. End of.

    Email should be plain text. HTML leads to too many quirks, rending problems, bugs, attack vectors and bloats email size.

    Outside of the vomit that is Outlook, every email client I have used will respond in plain text to a plain text email, allow you to specify plain text, RTF, HTML or whatever in a few clicks and has easily accessible defaults in the setting. If this is hard then either you are a bit thick or (more likely) your email client is utter garbage.

    1. Anonymous Coward
      Anonymous Coward

      Re: Plain text is king

      "If this is hard then either you are a bit thick or (more likely) your email client is utter garbage."

      Or ... you are working for Microsoft.

      1. This post has been deleted by its author

      2. Doctor Syntax Silver badge

        Re: Plain text is king

        "It is difficult to get a man to understand something when his salary depends upon his not understanding it." also applies to women

  18. Crypto Monad

    "transparency and a really good software supply security model.”

    This from the company that gave us the Microsoft Word Macro Virus. A gift that keeps on giving.

  19. Anonymous Coward
    Anonymous Coward

    If being able to send plain ASCII email is a technical barrier to someone, then their technical skills are too low.

    1. oiseau Silver badge
      Facepalm

      If being able to send plain ASCII email is a technical barrier to someone, then their technical skills are too low inexistent.

      There, reads better.

      O.

  20. Anonymous Coward
    Anonymous Coward

    "says Linux Foundation board member"

    Absolute garbage of a headline here.

    It *should read* : "says Microsoft drone" because that's what she is: A mole and saboteur. No more, no less.

    WTF she sits in the Linux Foundation board anyway?

    MS hasn't *anything* to give, except rotten company culture and greed with piece of shit code. Smells like a bought position, i.e. bribes.

    Nice way to rot Linux from inside, bribe the foundation management. That's the goal here. This person is just a preview what will happen later.

    1. Peter Gathercole Silver badge

      The Linux Foundation

      The Linux Foundation is an organizing group that looks to standardize and co-ordinate Linux development. It appears that all you need to do to become a platinum member (necessary to get a seat on the board) is donate $500,000 per year, and have some interest in Linux development.

      Microsoft has an interest in Linux development. They are building Linux based technology into Windows, and they have to support Linux in their Azure cloud, because customers want it.

      I believe that there are quite a lot of Microsoft contributions to the Linux kernel. According to some articles, in the last year they have been the fifth largest contributor. I have not looked myself, but they are almost certain to have put code in to ease Azure compatibility, and the Windows Subsystem for Linux will almost certainly have some code in the kernel tree to smooth out the interface with Windows. And it would not surprise me if they have more in there as well.

      I am suspicious about Microsoft involvement, but it may be that there is a place in the Foundation for them. But I would be wary of it, if I was another board member.

      1. Dr AntiSol, astrophysicist

        Re: The Linux Foundation

        It appears that all you need to do to become a platinum member (necessary to get a seat on the board) is donate $500,000 per year, and have some interest in Linux development.

        Nope, there's no requirement that you have an interest in Linux development.

  21. Lotaresco Silver badge

    This sounds like MS at work

    MS have always had a policy of adopt, adapt, improve, enclose, control. Every OpenSource initiative that I have been involved with that has MS members on the team gets nudged bit-by-bit into a situation where MS dominate the direction of development. If they can't achieve that they then have a history of taking their ball back.

  22. Lars Silver badge
    Coat

    Hmm

    "we need to manage it to the standards that enterprises are used to".

    1. GrumpenKraut Silver badge
      Trollface

      Re: Hmm

      Multi gigabyte Excel spreadsheets? Kernel developers will *love* this!

      1. DuncanLarge Silver badge

        Re: Hmm

        > Multi gigabyte Excel spreadsheets?

        Then you get the call to the helpdesk as the email client says the max attachment size is 20MB :D

    2. Doctor Syntax Silver badge

      Re: Hmm

      "we need to manage it to the standards that enterprises are used to"

      No problem with the existing setup. The S in ASCII is for Standard.

      1. Alumoi

        Re: Hmm

        MS standard? Apple standard? Google standard?

        1. Doctor Syntax Silver badge

          Re: Hmm

          ANSI standard.

  23. T. F. M. Reader

    LKML is a lot more than a patch submission mechanism. It is first and foremost a highly technical discussion forum that revolves around code and software engineering and related ideas. For an effective discussion, it is essential to include pieces of code without extra formatting, use contextual inline responses (don't start me on top-posting...), prevent any cluelessly "helpful" automatic formatting such as not respecting the sender's line breaks, etc., etc. It is also essential to be able to copy/paste directly from a C file to an email's body, quote formatted code without mangling when one responds to a post, adding notes/markings/etc. to the quoted code...

    I don't see how the above may be achieved with non-plain-text email (or monospace font, for that matter). This is true not only for LKML, but for any discussion involving code.

    Yes, I do realize that the above looks foreign and weird to non-technical types (or to those used to squint at phone screens to read emails - a group that highly overlaps with "non-technical types", in my experience). So I developed a habit of using 2 MUAs for the 2 different types of communications - it's not such a big technical challenge. At least not outside of MSFT, it isn't.

  24. BinkyTheMagicPaperclip

    Looking at the wrong target

    It would be much better if mail clients defaulted to plain text, and switched automatically to HTML if formatting is added. Outlook can certainly be set up to default to plain text, and if formatting is added prompts if HTML is desired. For 98% of my work e-mail plain text suffices, to handle the other 2% containing screenshots and tables HTML works.

    HTML is a huge pain when encountered on plain text mailing list archives, it's not easily searchable, and frankly unnecessary most of the time.

    Sarah's partner shouldn't be surprised by the OpenBSD plain text requirement, it's signposted clearly on the website, and really is not difficult to do.

    Frankly I'm less than worried about Linux contributors - it's overflowing with those, and well funded by contributing commercial companies. I'd be more concerned with the BSDs or minority OS where the contributor list is small.

    I'm getting into NetBSD kernel development and the largest barrier to entry so far is getting it working on hardware that's really good for 2012 (I suspect dual CPU and/or multiple PCI-e bus shenanigans) as I'm unwilling to buy multiple systems to handle dev, gaming, and Windows. Fortunately after a lot of faffing I've set up a dual boot to ESXi, and hope to use that to host a NetBSD debug source until I can fix the issues that prevent me running it on bare metal.

  25. cantankerous swineherd Silver badge

    someone with a non job poking their nose into things they don't understand.

  26. GrumpenKraut Silver badge
    Thumb Up

    "Now that we have lost the fight against open source" she said,

    followed by "scratch that", "Now that we have won with open source...", followed by uncontrolled laughter.

  27. DuncanLarge Silver badge

    Yeah I'm not falling into that trap.

    After all these years of turning off displaying images by default and displaying the text body over the HTML one by default someone comes along and complains?

    Text doesn't have embedded fonts that can pwn my machine.

    Text cant hide links behind a false description.

    Text doesnt embed images and other files that may also carry a payload.

    I dont know if HTML emails can run Javascript? If they can well text blocks that too.

    When developing on the kernel I'd like to be immune from XSS attacks when reading a bug report. Its just one less attack vector to worry about, I can then concentrate on securing my browser properly.

    All email clients can view the text body that is send along with the HTML body, assuming that the sending client is actually following the many ancient RFC documents and sending text bodies along with HTML ones. In fact working in IT in a windows environment and having to use outlook I view the text body by default "just in case". I typically end up switching to the HTML view once I know this is an email I typically get (the HTML view does offer nicer formatting obviously).

    I need to check the encoding used but I think most emails sent text only are using UTF? Doesnt that even include emoji these days?? Do you realty need the fonts?

    If everything follows the RFC's surely this "barrier to entry" is a non issue as it simply doesnt exist. Just send the replies as text! Its easy. What next? Binary config files, binary logfiles?

    Oh god that may have already happened...

  28. tfb Silver badge
    Alien

    As always, it's easy to sneer

    I'm not a Linux kernel person. I'm also not a young person: the first mail client (which would not then have been called a 'client') I used was called 'mail', and for all of the 1990s and most of the 2000s I used rmail and then vm in emacs to read mail. But now I'm kind of over having to maintain my own email client (still more my own sendmail...), and since I use a mac, I use the Mac mail client which is mostly fine. And I've used that since, I think, 2006 or so. I use it in plain text mode, of course, except when I have to talk to someone where rich text is going to help. Other than an iCloud account (which I don't use really) I use a non-major email provider (not google or microsoft or ... in other words), talking POP3 so I'm never relying on someone else's system for long-term mail storage. And it's mostly fine (obviously not completely fine) and I have a bunch of rules set up to shunt mailing lists &c to the right place. And I have quite a lot of mail in this system: something like 10% of my home directory is email.

    So, I tried the obvious thing: use git format-patch to make a patch, of well-behaved code (no long lines, no non-ASCII characters), pasted it into an email to myself, looked at the resulting email when it arrived. And of course it's got MIME noise in it (not much noise, but enough: mostly quoting of '=' I think).

    So if I wanted to start doing Linux kernel stuff (I don't) then I'd need a way around that. I certainly can work out how to send patches via 'git format-patch' / git 'send-email' (and I've done that in the past), but I have to deal with the other end of it: is my normal mail client going to mangle patches on the way in? I don't know, actually. Does 'git am' defang MIME? I don't know. Perhaps I will need a completely new mail client which is better behaved. So now I either need to start using that and work out how to move all my mail into it, or I will need two mail clients with all the chaos that means. Perhaps I could solve that by having a special email address for LKML mail and a client which reads only that: that would probably work. But, well, it's a good thing I don't want to do this because the thought of sorting it all out is not fun.

    I don't think a proprietary system is any kind of solution (so in particular I *don't* think that, say GitHub issues are any kind of answer). An email-based system is probably actually fine, but such a system should be easy to use with mail clients that people use, and not require them to set up some completely new client, which is only easy if you don't actually have any existing email.

    1. Dr AntiSol, astrophysicist
      Mushroom

      Re: As always, it's easy to sneer

      So what you're saying is that your email client is buggy. Maybe you should consider submitting a bug report so that the vendor can make it compliant with the ~40 year old standard?

      An alternative approach would be for you to be more discerning about the software you use. I can personally recommend software that isn't shit. And if you're coming from shit software then you'll be amazed how not-shit it is. You'll find yourself pausing what you're doing every now and then just to say to yourself: "wow, this software really isn't shit!". It's a nice feeling.

      I shouldn't have to change how I work because you happened to choose a shitty email client. Especially when I'm working using simple, easy-to-implement, agreed-on standards.

      Complaining that we should change how things are done simply because some commonly-used email client can't be bothered to conform to the standard is akin to me claiming that the formula 1 rules should be changed because my little 4 cylinder Hyundai hatchback keeps losing races.

      1. GrumpenKraut Silver badge
        Happy

        Re: As always, it's easy to sneer

        > I can personally recommend software that isn't shit.[...] and then just to say to yourself: "wow, this software really isn't shit!". It's a nice feeling.

        Poetry award incoming!

        1. Dr AntiSol, astrophysicist
          Thumb Up

          Re: As always, it's easy to sneer

          hehe, aw thanks!

    2. Doctor Syntax Silver badge

      Re: As always, it's easy to sneer

      "I use the Mac mail client ...So if I wanted to start doing Linux kernel stuff"

      If you wanted to do Linux kernel stuff and equipped yourself accordingly would you really need to use a Mac mail client?

      1. jake Silver badge

        Re: As always, it's easy to sneer

        "If you wanted to do Linux kernel stuff and equipped yourself accordingly would you really need to use a Mac mail client?"

        Considering that Mac userland is (to all intents and purposes) BSD, and BSD & Linux share most (all?) email clients, I rather suspect the question is moot.

        Assuming the "you" in question had any competence, of course. And if they didn't have that competence, I'm not all that certain that working on the kernel is the best use of whatever talents they may have ...

  29. Doctor Syntax Silver badge

    “moving from a more text-based, email-based, or not even moving from, but having a text-based, email-based patch system that can then also be represented in a way that developers who have grown up in the last five or ten years are more familiar with."

    Developers who have grown up in the last five or ten years need to become familiar with text-based email. They'll then find it a lot easier to deal with text-based source code editors and text-based compilers.

  30. noboard
    Facepalm

    Trouble at home?

    As anyone doing kernal work wouldn't have an issue sending a plain text email, does anyone else believe what actually happened was he had a "moment" and forgot to send it as plain text. The type of silly mistake we've all done many times over the years, but means nothing. His partner has now taken this and turned it into a "He finds sending email in plain text a struggle", just for the sake of a PR blog post.

  31. Zippy´s Sausage Factory
    Meh

    Reading between the lines, I think the impression she is trying to convey - either of her own volition, or because it has been impressed on her by senior management that it would be a serious career-limiting move not to do so - is that Linux should stop its mailing list and move exclusively to Microsoft Teams.

    Which, given that Teams is proprietary and does not run on Linux, is a good idea in the same way as is attempting to trim your fingernails with a chainsaw.

    1. Ken Hagan Gold badge

      Nitpick: Teams does run on Linux.

      But yeah, not the right tool for the job.

    2. razorfishsl Silver badge

      TEAMS might be fine in the US... but it is having MASSIVE problems in other areas of the world.....

  32. Anonymous Coward
    Anonymous Coward

    Just checked my uucp mail archive from 1990

    I can still read it as it's 7bit text. How many file formats are unreadable today?

    From my POV, if someone hasn't got a logical enough brain to be able to process a mailing list and follow a thread, I wouldn't want them near the Kernel, let them play with the latest language of the day on some personal gitblob project.

  33. Binraider

    Not enough maintainers? How many people are taught C today?

    How many are taught library scripting rather than programming? Some might say they are the same thing. I'm not one of them especially in OS-land. Library scripting is partly why Windows is bloatware hell. Applications that should be a couple of kb often run to megabytes for no good reason. Mouse drivers eating over 100MB for gibberish gesture controls on a trackpad. Must try harder!

    If you are talking about ticketing systems, email full stop is, with appropriate rules for cross referencing (such as a ticket number) an OK system. The most powerful? No. But whining about plain text email over formatted email? Give it a rest. Get an appropriate mail client. Debian has a choice of well over a dozen that I can think of off top of head that would be suitable.

    The rather excellent Jitbit is a ticketing system our company picked up a license for; highly capable and integrates audio, text, video into a ticketing system and runs a KB in parallel. Something like that would be a step up from mail.

    This just smacks of "use our development and communication tools pretty please" to further the quest for dominance. There are better options than MS comms tools available. I do wish more would use them.

    1. GrumpenKraut Silver badge
      Pirate

      > Mouse drivers eating over 100MB for gibberish gesture controls on a trackpad. Must try harder!

      For cases like this I prefer the approach "some programs should never be executed but some programmers should".

  34. Anonymous Coward
    Anonymous Coward

    Its aint tools, its skills..

    The actual problem is that the vast majority of younger developers entering the business in the last decades or so have CompSci degrees but very few have any real heavy duty programming skills or aptitude. Whereas back in the 80's and 90's most of the members of dev teams that actually *shipped* successful software if they had degrees (or had actually finished their degree) they had them in every subject under the sun but CompSci. They ended up as developers because they had real aptitude and skills, not because of some paper qualification. Because being a senior / lead level developer is a artisan skill requiring talent, not some taught clerical skill.

    In the same way that a PhD in English will not make you into a good writer of readable prose, or a PhD in Music will not make you into an accomplished musician, a degree in CompSci just means that someone who has been taught by people who have never written shipping software had passed an exam on theoretical questions that almost never come up in real life software development. They might have some actual aptitude for writing software, but probably not.

    So you have a situation where hiring managers (with paper qualifications) make paper qualification like CompSci degrees a minimum standard for even interviewing people for dev teams. So after about a decade or two the actual talent pool of younger people with the rich and deep practical real world development experience on commercial product necessary to make them successful kernel developers will be small and getting smaller.

    It ant a problem of an email based development process. Its a problem of the incremental credentialiization of what is very much a craft skill. Eventually you end up with everyone having paper credentials and no one with any real ability to write complicated working software. Like spelunking the Linux kernel, for instance.

  35. George Spiggott

    Yeah right, MS want you to use github and sharepoint for development.

    I'd rather self immolate.

  36. Alan W. Rateliff, II
    Windows

    Nice place you built up over the past 25 years

    Now, we just need to Microsoft-up this thing a bit.

  37. Anonymous Coward
    Anonymous Coward

    Glad to see...

    Janine from Ghostbusters has moved up in the world.

  38. Ilgaz

    No

    I don't want anyone who can't communicate/code in plain text/command line in my devices kernel.

    We are talking about Linux Kernel here, not gorilla.bas

  39. Philip Hands
    Flame

    Typical

    So the company that's been making offensively useless email clients for decades, with toxic defaults, and generally ignoring both RFCs and established norms are complaining that some users are incapable of dealing with plain text email?

    They basically crapped in our pool, and are now suggesting that swimming isn't very hygenic.

    Utter tossers.

  40. gregzeng

    ASCII. Reddit uses it. These messages here use it. Seems the comments here do not understand this.

    This communication medium has words,sentences, paragraphs, headings, praise or punishment markers. These meta-structures are an essential management system. It sorts confusing ASCII into digestive priorities.

    Reddit, messaging systems here also use CAPS, Bold fonts, spelling correctors, instant language translation services, etc. Non-English readers & messages can be readily & quickly understood or translated.

    The OP seems unfamiliar with Reddit and the message system used here.

    Seemingly also needed are emotional symbols, to allow Linus to show emotions about SNAFU, FUBAR, wonk, woke, etc.

    Micro-aggressions seem trendy now are happening. Glass ceilings about women, region, skin colour, disability, sexual preferences, etc.

    Hardcore coders,with noses to the grindstone, mighty not see the forest, because of the trees. The retires, especially the senior managers like myself, can notice familiar patterns. Reinventing the wheel, shooting the messenger, punishment to the unusual (xenophobia), etc.

    1. Doctor Syntax Silver badge

      I think you wandered in here from some other thread. Please reply to that one instead.

      1. GrumpenKraut Silver badge

        Looks more like a case of frogpill overdose to me.

        1. PeteA

          Welcome back, amanfrommars

          See title

          1. jake Silver badge

            Re: Welcome back, amanfrommars

            This was NOT amfM ... amfM sticks to whatever point he[0] is making.

            [0] Are Men from Mars properly referred to as "he", as it would appear at first blush? I'd hate to start an interplanetary incident over improper use of pronouns ...

  41. Claverhouse Silver badge
    Mushroom

    To Misquote Samuel Butler

    O God ! O Microsoft !

  42. John Smith 19 Gold badge
    Coat

    Now I wonder which email clients screw up the worst?

    Any suggestions?

  43. Dr AntiSol, astrophysicist
    Mushroom

    Why would anybody care what she has to say?

    "I have a broad remit to investigate and engage in open source across the company,” she told us.

    Oh good! So you're the person who will be in charge of open sourcing directx then?

    Because MS Loves open source now. The whole "we love open source" thing totally isn't an act to cosy up to the open source projects so that you can a) take over and/or b) destroy them.

    So, since the "we love open source thing" is 100% legit and not at all a scam, I just assume you'll be open sourcing directx any day now, right? Frankly I'm surprised it hasn't happened yet. And you'll obviously be the person spearheading that initiative. Yay you!

    my first question as a total open source pragmatist is what do you think you get by being open source? What is the benefit to Microsoft in making this open source?

    Aah, right, so that'll be a "no" to open source directx then. What you're saying is that Microsoft only loves open source in as much as they can benefit by doing so.

    What. A. Shock. That's totally not something I've been predicting ever since this scam new stragegy was announced.

    So, in other words, what you're saying is that there is zero reason why anybody should have any interest in anything you say about open source development, let alone Linux kernel development.

    I propose an arrangement: you prove your good faith first (good luck with that), and then I'll consider your suggestion on any merits that it might have.

  44. Anonymous Coward
    Anonymous Coward

    Theres a reason for that

    ... it focuses people on content not some bells and whistles brought about by formatting. Im an old dog.. I couldnt care much about all that formatting garbage.

  45. TripodBrandy

    Microsoft Loves (Controlling) Linux

    Microsoft has already captured many free software and open-source projects (including major parts of GNU) that are now developed on Microsoft GitHub (which has embraced Git and extended it with non-exportable, proprietary metadata). It seems quite clear they would love to effectively control the development of the Linux kernel proper, by bringing it under GitHub, and then using their usage policies to pressurize and deplatform developers that won't comply to their demands.

  46. PeteA
    FAIL

    Dear Microsoft....

    How about you bugger off and get your own house in order. When you've caught up with the processes pioneered in OSS to deliver reliable software at scale, we'll talk.

    Thank you.

  47. JulieM Silver badge

    We've been there before

    There is form for this sort of thing.

    Way back in the mists of time, before Git was invented, Linux kernel development was carried out using the proprietary BitKeeper system for version control; with the suppliers "generously" offering free licences to kernel developers, in the expectation that giving away free licences to a major Open Source project would serve as a good enough advertisement for the paid version to make up for what they were giving away.

    Of course, it was a matter of time -- and not much time, at that -- before a bunch of highly-talented developers comfortable with working at the bare-metal level and steeped in the Open Source ethic managed successfully to reverse-engineer the proprietary protocols and created their own improved Open Source client software, which was fully amenable to independent audit and improved on the feature set of the paid-up BitKeeper client; following which (and just as predictably) BitKeeper spat out their dummies and withdrew their goodwill.

    Thus was created Git, the only version control system powerful enough to deal with the complexity of the Linux kernel development project; and thus did BitKeeper vanish into obscurity. And even although you have forgotten all about BitKeeper, Kernel developers will remember. "Fool me once, shame on you; fool me twice, shame on me", as the old saying goes.

    1. jake Silver badge

      Re: We've been there before

      The difference is that in the one case, a tool that probably never should have been relied on in the first place was jerked out from under the Linux developers. In the other case, someone is suggesting that configuring an email client is entirely too difficult for (some) prospective Linux developers, and so we need to come up with an entirely new way to collaborate on the kernel to bring these non-technically inclined people on board. No child left behind, dontchaknow.

      We'll be serving KoolAid and singing Kumbaya in the atrium after service.

      1. JulieM Silver badge

        Re: We've been there before

        Aye.

        I would expect the Venn diagram of "People who are dissuaded by the complexity of configuring an e-mail client" and "People with the potential to be bare-metal developers" to resemble two circles with a wide space between them.

        Every attempt to introduce caged software into the Open Source development process must be resisted. There is no benign caged software. It is always a trap, always ultimately a way to restrict your ability to use your computer freely; and manual methods are always to be preferred to the use of any proprietary tool.

        1. jake Silver badge

          Re: We've been there before

          Those circles are orthogonal to each other ... in at least three dimensions.

          1. Tom 7 Silver badge

            Re: We've been there before

            So MS are indulging in rhythmic gymnastics in an attempt to insert their ring in your ring!

  48. karlkarl Silver badge

    I do hope the Linux Foundation realises that Microsoft is not one of us. It does not move in the same direction.

    Though, digging into it, the Linux Foundation is looking less and less like one of us too sadly. It is starting to cater more for corporations rather than the communities who made it.

  49. Dinsdale247

    Whatever

    FreeBSD uses Pharbicator.

    1. jake Silver badge

      Re: Whatever

      That's Phabricator. Poor things.

  50. razorfishsl Silver badge

    MS further leveraging GITHUB to use their product range.

    Every single aspect of linux is having MS shove its gigantic member inside....

  51. 759b954e-617b-408b-a2b1-f5a42c3688d4
    Linux

    Barrier to entry

    She says "barrier to entry" like it's a bad thing. That ain't necessarily so.

    1. jake Silver badge

      Re: Barrier to entry

      Indeed. Apparently she (and others) don't realize that the actual barriers to entry are the ability to speak the C programming language like a native, an in-depth working knowledge of the ins and outs of several different compilers, and an intimate knowledge of the assembly language of various hardware architectures ... all of which most curricula seem to be ignoring these days.

  52. Mark Wallace

    Should have known better than to let MS get involved.

    In a few months, they'll be demanding baby-blocks, ribbons, and live tiles, just you wait and see.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020