[arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Bigby James]

On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:
> 
> Here are three arguments to motivate my disagreement.
> 
> * First, removing LSM support makes it difficult for users to test
> LSM. Before 3.13 kernel, users needed to recompile their kernel (or to
> install linux-selinux AUR package) to be able to use SELinux. This is
> a hard first step and I know too many people who thinks "I don't want
> to recompile my kernel as I've already done magical things to make my
> graphic card works and I don't want to break my fragile config". Now
> people just needs to install packages (from unofficial repos or from
> the AUR) as described in the wiki [4] and reboot to start using
> SELinux.
> * Second, it's possible to compile things which are disabled at
> runtime. For example, I don't need to compile the kernel without IPv4
> to test what breaks when running a non-IPv4 kernel, I only need to add
> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
> for LSM. Even if they are compiled, they can be enabled/disabled with
> such runtime configuration and this config doesn't require much work.
> * Third, users who want to combine several unofficial features for
> their kernel already have to do weird things. For example, I'm using a
> grsec kernel with SELinux. A few months ago, there were linux-grsec
> and linux-selinux in the AUR but no package which provided both. Hence
> I needed to build a custom package to have both. Now, the next time
> linux-grsec's maintainer will sync its config with the official repo,
> SELinux will be available in this package (unless I've missed
> something) and I'll no longer need to build my custom kernel.

As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning
comes down to "*I* use it, so don't take it away from me." But your case is
hardly representative; I highly doubt that the typical desktop user (that is,
the typical Arch user) makes use of SELinux or its cohorts; no doubt there are
people running Arch servers that use it, but again that's not representative of
the community at large, in which many people just install Arch on their laptops
and desktops for everyday production and entertainment use.
 
When I build a custom kernel for my laptop, the LSM stuff and kernel debugging
options are the first to go, as they have absolutely no benefit for someone who
uses a computer primarily for reasearch and writing, coding and design work, web
browsing and music.  They're complements for specific use-cases---server
administration (most likely when multiple users are involved) and kernel
hacking, respectively---and are of no use to anyone who doesn't partake in those
use-cases (how necessary is MAC to someone who interacts with and monitors a
single machine all day?). Besides, as you've said, you already need to build the
userspace utilities from source (because not too long ago, the devs voiced their
opposition to maintaining SELinux officially), so leaving such features in the
kernel to ease "testing" is both specious and a mismeasure of how useful or
vital they might be. Suppose the majority of people who test SELinux decide to
drop it, as seems to be the case in my (admittedly limited) observations. Of
what value, then, is the work the devs did to maintain it?

> That been said, I agree that having a kernel with less features would
> be good. To my mind, here are possible ways :
> 
> a) Create a linux-light package with less features than the linux
> package, and don't trim linux' configuration.
> b) Rename linux as "linux-full" (as an official package) and trim linux' config.
> c) Create a package ("linux-src"?) which install the kernel sources
> and provides an easy way to customize the config before making the
> packages (with pkgbuild). Currently linux-grsec AUR package provides
> this feature by using the MENUCONFIG environment variable [5].
> d) Don't create new packages and trim linux' config (this is your
> idea, if I understood correctly).
> 
> Any of a) or b) would suits fine for me if you choose to drop LSM in
> the lighter config.
> 

I've used Arch for years now, but I can remember what it was like as a n00b.
>From the perspective of someone who is new to Arch, this is grossly misleading.
Someone unfamiliar with how Arch packaging works (or a long-term Archer who
doesn't pay close enough attention to the news and mailing lists) will
conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and
"linux-src" = "I have to screw with it for two hours to get my GPU working."
They'll likely just install linux-full anyway, unaware of the distinction. 

It seems far more reasonable to me to trim the kernel to those things typical of
everyday desktop use, and trust that members of the community will maintain
those things which they find useful separately. I don't mean to be presumptuous,
but it's my understanding that the primary goal of the Arch devs and repo
maintainers is to provide a minimal, functional distribution platform that users
can utilize to craft their systems as they see fit. They don't want to cover
every imaginable use-case, but provide users with tools with which to fulfill
their own desires and needs themselves. What the devs provide in the base group,
the [core] and [extra] repos are those things most common for mundane computer
use via Linux-based operating systems. Special use cases are precisely what ABS
and the AUR are there for.

Requiring people to build a custom kernel in order to *not have these features*
is the exact situation are already in *right now.* Asking the devs to maintain
multiple kernels just to save what I suspect is a minority---who already build
several packages from the AUR, for rarely used functionality---a little time
isn't reasonable.  Moreover, while I may mistake your meaning, the list above
reads like you're asking the developers to make your preferred kernel build the
default, and reasoning that "It's no big deal, if people don't want that stuff
they can just build their own through ABS." That's not a solution at all, and
again, *it's already the case right now.*

-- 
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams