On Tue, 2010-08-31 at 15:44 -0400, Matthew Miller wrote:
1. More with Less
Simplicity. A modern server doesn't do everything; it provides the
minimal services it needs, with no overhead. We should work to pare down
the minimal set of packages installed, and avoid bringing in complicated
systems as dependencies in that base. Whenever something new would add to
what's running by default, we should look for another way.
This makes systems run more efficiently and with require less management
overhead, and reduces risk from to package errors or intentional attacks.
try removing dbus sometime... I can't remember - why is dbus needed on a
KVM guest? yum remove dbus\*
2. Avoid Churn at the Core
It may be that in order to best provide for the typical Fedora user,
frequent updates are a necessity. But Fedora should place extra emphasis
on keeping the base of the operating system from changing within a stable
release.
This makes system changes more auditable, and keeps security and
important bugfix updates from being lost in the noise. It reduces risk
from accidental new bugs or from incompatible version changes.
Should the churn be avoided BETWEEN releases, too? Ie: f13->f14 should
we avoid core churn?
3. Fedora is Unix-like
The operating environment in Fedora builds on over 40 years of
experience. Some of that is quirky and strange, but it's a strangeness
that has become familiar. Changes from that legacy should only be made
with the recognition that simply making things different has a cost, and
that cost must be justified.
This means knowledge transfers to and from Fedora. It means certain
basic tools are always there.
Except when they are obsoleted and ignored and the only way to get them
back in place is to have a long thread vociferously arguing for them.
Good times, that. It doesn't take a lot of those to stop wanting to be
involved at all, does it?
4. The Command Line is Power, and Key=Value is a Key Value
The command line user interface appears intimidating, but its flexibility
is incredibly hard to match in a GUI. Fedora can't require new software
to be developed with command-line access in mind, but if that software
replaces older software, it should not cause regressions in this area.
Configuration files for services should be text files, easily fixable in
a pinch. Formats like XML are to be avoided — they're good for computer
processing, but terrible for human brains.
This means systems can be scripted, controlled remotely, managed in bulk,
tracked with version control, and, when necessary, fixed from a minimal
rescue environment.
So gconf and dconf are..... what? A tree of key=value pairs, aren't
they?
Ever looked inside the gconf variables that evolution makes? You'll claw
your eyes out.
Key=Accounts
Value=<xmldump>
-sv