[arch-dev-public] Kernel - vanilla vs patched?
a.radke at arcor.de
Fri Nov 9 15:12:45 EST 2007
> /me disappears and takes a full timeout for an uncertain amount of
> time. have fun guys,
Tobias, you have proved to do a very good job maintaining the kernel26
now for both architectures. And our community seems to be satisfied with
Yes, Arch's mission is to ship KISS packages. Mainly in the way to use
and setup the system, not always KISS to package. The package should
simply work in most cases. And when it's broken in certain parts we fix
it. Even if this means backporting features(=sometimes hardware
enhancements) and fixes not applied in Linus tree.
Hey, we are Arch - means we are known to ship a binary metadistribution
offering the base for latest and greatest OpenSource features and
packages. Keeping that in mind I wonder why some of us want to break
down all patching and feature enhancements.
Some of us are working on LiveCDs, why not. Others work on Compiz'ing
all desktops. Why do you want to forbid the master kernel26 maintainer
to add features he wants to support? Me just wonders. As Linus said
it's up to the distributions to make a good kernel out of what they
ship "vanilla". It just depends on your target user group. We are not
here to only satisfy our own!
The only point I see tpowa should improve is a bit more documentation
for all the added lines and patches.
What I see more and more becoming a big problem is defining the Arch
see dev /wiki/Goals/
- both are just suggestions. Did we finish that discussion?
The bigger we grow the harder it becomes to satisfy the
"edge" (desktop) user at the same time together with those who want to
run Arch on critical (server) systems. Many compromises we made and
just are discussing about could be solved by splitting arch up into two
dedicated parts: one for the edge and one for critical systems. Some
seem to like it and some don't.
More information about the arch-dev-public