Greg Kroah-Hartman

Conventional mail clients and web clients are a non-starter if you want to work with mailing lists or git email workflows. To begin with, both of them rely heavily on email threads. Patch sets and reviews are both threaded. Modern clients don't emphasize these threading well enough, and can leave you confused about the context of the messages when using these workflows.

Another problem is html mail. Lists and patches are easier to read as plain text. But again, it's hard in modern clients to figure out if you are composing a plain-text or html mail. As a result, you end up with mangled patches and badly formatted text in the mailing list. Another really annoying problem is top-posting when replying to a mail. Ideally, the quotes from original message and the reply should be interleaved, so that the context of the discussion is very clear. But web clients often just quote the entire original message and hide it away at the bottom of the reply. It isn't even easy to expand and split the quotes.

Finally, there is the problem of applying patches to repository from email. I don't think this was even a design consideration for modern clients.

> What am I missing from some amazing holy grail mail client

I assume you are unfamiliar with the workflow. The reality is that the UI is never ideal, even with traditional text mail clients. List support is better than with modern clients, but patches need hacks or a bunch of other tools. But the tool selection makes it way more…

It's much more complex than that. Security bugs have different levels of severity, with different reactions to those.

Let's for example see the Microsoft ESU policy:
https://docs.microsoft.com/en-us/lifecycle/faq/extended-security-updates

For Windows 7, only Critical and Important security updates are shipped to those _paying_ customers. This leaves Moderate and Low as uncovered.

For Linux: http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

> Older LTS release

> There is one huge caveat when using a kernel like this. The number of security fixes that get backported are not as great as with the latest LTS release, because the traditional model of the devices that use these older LTS kernels is a much more reduced user model. These kernels are not to be used in any type of “general computing” model where you have untrusted users or virtual machines, as the ability to do some of the recent Spectre-type fixes for older releases is greatly reduced, if present at all in some branches

> So again, only use older LTS releases in a device that you fully control, or lock down with a very strong security model (like Android enforces using SELinux and application isolation). Never use these releases on a server with untrusted users, programs, or virtual machines.

There are several documentation projects about the Linux kernel, of wildly varying quality. Honestly, though, I believe you'd be better served by the Stevens books and the Tanenbaum MINIX book, if you're not already familiar with kernels or the UNIX architecture, in general. The Stevens books are, bar none, the best books about UNIX programming and TCP/IP network programming, and as far as I can tell every serious Linux developer has a working knowledge of Stevens, and many have referenced Stevens when discussing implementation details. And, of course, Linux was originally developed as kind of a response to MINIX and shares many characteristics, and was designed as a teaching operating system (there are other teaching operating systems, but none are probably closer to Linux than older MINIX versions).

Here's some Linux kernel specific stuff:

http://tldp.org/LDP/tlk/tlk.html

http://www.kroah.com/lkn/

http://www.amazon.com/Linux-System-Programming-Talking-Directly/dp/1449339530/ref=pd_sim_sbs_b_2?ie=UTF8&refRID=0C0WQPSNFZGST1372VTZ

The first two have some age on them, but are still relatively reflective of the overall architecture of Linux, even if a lot of detail has changed. Anyway, these three are of reasonable quality. Some of the other stuff out there is pretty rough.

If you know, and followed the enactment of the "Linux Kernel Community Enforcement Statement " [1] [2] [3] which started out as an effort to stop a "rouge" developer from being a copyright toll, then further devolved with interactions with the core linux group and SFC based on a fundamental difference in the understanding of the GPL problem, and what GPL enforcement should be

SFC wants to use the law as a stick, while trying to get people to comply with out legal action. Many core members prefer to not even engage with the threat of legal action at all, they believe that simply asking nicely will get companies like VmWare to comply. of course this is rarely true but.....

[1] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/tree/Documentation/process/kernel-enforcement-statement.rst

[2] http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/

[3] http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/

> It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads.

So much this; Linux Plumbers conference years ago was bitching about how every gorram vendor wanted to be a special snowflake, so even though the architecture was ARM, you basically had to port the kernel all over again to every new phone. I haven't kept up with it, but I can't imagine it's gotten better. The problems they're listing as reasons to move to a new kernel aren't caused by Linux and they won't go away until you slap the vendors and slap them hard for the bullshit they pull, both on developers and users.

As for kernel ABI, this has been rehashed to death: just release your fucking driver as open source code, and it will be integrated and updated in mainline forever: http://www.kroah.com/log/linux/free_drivers.html

According to https://access.redhat.com/articles/3311301 PTI should be enabled on Intel even with the new microcode, so the microcode update probably doesn't fix variant 3 (Meltdown).

Also, I don't think the microcode updates just expose some chicken bits. IBRS seems to be exposing one or more chicken bits as a single bit, but IBPB seems to be a command to run a routine in the microcode to immediately clear part of the branch predictor state, not a chicken bit.

Yes, the kernel changes in the Linus tree only fix variant 3, there are several partial and/or mutually incompatible patch sets being posted on the linux kernel mailing list to fix the other variants; the Red Hat kernel seems to have an early version of some of these. See also the just posted http://kroah.com/log/blog/2018/01/06/meltdown-status/ for more detail.