2:44 p.m.
I've made a list of a handful of what I think are important foundational
concepts for Fedora from a server perspective. They'd be essential for a
separate Fedora spin or even complete branch, but ideally, the core Fedora
project will keep them in mind when adapting new features and considering
overall direction. I believe that a general recognition of the value of
these points will be good for everyone, not just our particular special
interest.
In each case, I've tried to consider a developer tasked with targeting the
general productivity / web desktop user. These ideas shouldn't block that
developer from focusing on the intended case while still not causing harm to
wider uses.
Your comments and discussion are of course appreciated — this is a starting
point, not my idea of graven stone tablets.
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.
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.
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.
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.
5. Write Good Man Pages
Any documentation is welcome, but man pages have a unique place. They're
concise technical documentation with a standardized and expected format.
This means it's easy to find out how to do something even when a more
full-featured environment isn't available.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:33 p.m.
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
4:03 p.m.
On Tue, Aug 31, 2010 at 04:33:25PM -0400, seth vidal wrote:
> 1. More with Less
[...]
try removing dbus sometime... I can't remember - why is dbus
needed on a
KVM guest? yum remove dbus\*
I think the case can be made that dbus is a useful technology for a lot of
server systems. But I agree, it's the sort of thing where the case needs to
be made.
> 2. Avoid Churn at the Core
[...]
Should the churn be avoided BETWEEN releases, too? Ie: f13->f14
should
we avoid core churn?
You're right; the statement should include that too. The balance is
_different_ at that point, but yes, there's a cost there too, and that cost
should be remembered.
> 3. Fedora is Unix-like
[...]
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?
Yeah. That's why we put this somewhere in some guiding principles.
> 4. The Command Line is Power, and Key=Value is a Key Value
[...]
So gconf and dconf are..... what? A tree of key=value pairs,
aren't
they?
If you config file needs trees, you are probably Doing It Wrong.
For example, see:
http://sourceforge.net/mailarchive/message.php?msg_name=20100827144215.GA...
(I have high hopes for that actually going somewhere, by the way. It's too
bad I didn't look at it before the RHEL6 documentation was written.)
Ever looked inside the gconf variables that evolution makes?
You'll claw
your eyes out.
Key=Accounts
Value=<xmldump>
Hey, if I clawed my eyes out every time I saw a horrible configuration file
syntax choice, I would have been run out of eyes a long time ago.
But yeah. Gconf is a stellar example of Please, Not Like That. The files are
text, but they are not meant for human consumption.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:22 a.m.
Matthew Miller wrote:
On Tue, Aug 31, 2010 at 04:33:25PM -0400, seth vidal wrote:
> > 1. More with Less
[...]
> try removing dbus sometime... I can't remember - why is dbus needed on a
> KVM guest? yum remove dbus\*
I think the case can be made that dbus is a useful technology for a lot of
server systems. But I agree, it's the sort of thing where the case needs to
be made.
Bluetooth and pcmcia services... anyone? ;-)
-- Jeroen
11:34 p.m.
On Tue, 2010-08-31 at 16:33 -0400, seth vidal wrote:
> 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?
I was talking with mizmo about core stability earlier. I think it's very
important that we (Fedora) define a core Platform. Not a set of packages
(though it can start with crit-path+perhaps a few other comps) but
rather a specific set of use cases and a general description that
encompasses that we expect the following to be stable:
1). Bootup.
2). Basic Libraries
3). Core system utilities
<etc>
That means that you could replace desktop apps, or provide a new
feature, but you would have a harder time touching a core system
library, replacing a whole subsystem, or impacting upon boot. We could
collectively work on defining what is a basic platform and take that as
a proposal back to the main body.
I would advocate for an extremely vigorous process to getting any of
these components needed for the core platform updated, never after a
release, and place the bar very high on re-implementing them outright.
Make it so you have to prove a case before you go impacting upon stuff
that should be working well (enough) after two decades. And if you do
decide to touch it, it should work just as well immediately after you
touched it as it did before you started. Yes, that might mean we don't
get yet another re-write of something that just about works now, but
that isn't necessarily bad either. Plenty of new problems out there.
> 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?
People coming into Linux now might not have been involved ten, fifteen
or twenty years ago, and might not have touched a proprietary UNIX. Plus
screwing with stuff is fun, re-inventing it even better. But users get
rather accustomed to certain things working, to the value of standards,
to the import of that crufty ten-second-old book on the shelf entitled
"Fedora 13 for beginners" (or whatever). There should be a very high bar
to making changes that render large amounts of experience and
documentation obsolete. Not that it can't be done if *needed*.
So gconf and dconf are..... what?
Nice for the desktop but slowly infecting other areas. It is a very
valid point that it's time to reclaim text config files.
Jon.
9:34 a.m.
Jon Masters wrote:
I was talking with mizmo about core stability earlier. I think
it's very
important that we (Fedora) define a core Platform. Not a set of packages
(though it can start with crit-path+perhaps a few other comps) but
rather a specific set of use cases and a general description that
encompasses that we expect the following to be stable:
1). Bootup.
2). Basic Libraries
3). Core system utilities
<etc>
Here's a Radical Idea(TM);
- We take whatever is the package set of a current Enterprise Linux release as
the basis.
Please bear with me while I put out this one:
- We branch off those packages and our policy is in the realm of "bug-fixes
and security fixes only" -give or take-, but we allow ourselves to surprise
you with a minor bump if we think it doesn't break anything (like, not kde-4.3
to kde-4.4, but puppet-0.24 to puppet-0.25). In my opinion, if any of the
consuming parties thinks otherwise it's about time such party had its voice
heard upstream -and committed to doing the work.
- We provide "regular" support for one year -basically a stable update stream,
possibly categorized like Jon suggests.
- We provide security-fix only support for half a year -for all of what would
be considered "stable" for 19 months, the workload would come close to approx.
1 FTE to do this on all and any current Fedora release. That would give the
consuming party an additional 6 months to cope with either upgrading to the
next release or making sure that the upcoming release does what he/she/it
requires.
- We may or may not choose to include some of what is in EPEL.
-- Jeroen
10:10 a.m.
On Wed, Sep 01, 2010 at 04:34:53PM +0200, Jeroen van Meeuwen wrote:
Here's a Radical Idea(TM);
- We take whatever is the package set of a current Enterprise Linux release as
the basis.
I think that's too big.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:51 a.m.
Matthew Miller wrote:
On Wed, Sep 01, 2010 at 04:34:53PM +0200, Jeroen van Meeuwen wrote:
> Here's a Radical Idea(TM);
> - We take whatever is the package set of a current Enterprise Linux
release
as
> the basis.
I think that's too big.
Fair enough. Let's suppose we take what is in EL as a basis, and allow
ourselves to strip it down. Any (categories of) packages we'd be thinking of
specifically?
-- Jeroen
11:22 a.m.
Jeroen van Meeuwen píše v St 01. 09. 2010 v 17:51 +0200:
Matthew Miller wrote:
> On Wed, Sep 01, 2010 at 04:34:53PM +0200, Jeroen van Meeuwen wrote:
> > Here's a Radical Idea(TM);
> > - We take whatever is the package set of a current Enterprise Linux
release as
> > the basis.
>
> I think that's too big.
>
Fair enough. Let's suppose we take what is in EL as a basis, and allow
ourselves to strip it down. Any (categories of) packages we'd be thinking of
specifically?
I would start with the @core comps group (even with a smaller set) and
then add groups of packages creating a server feature. This will build
the server platform from down will make possible to check the
dependencies and to validate whether the set works as expected.
Dan
11:39 a.m.
On Wed, Sep 01, 2010 at 06:22:54PM +0200, Dan Horák wrote:
> Fair enough. Let's suppose we take what is in EL as a basis,
and allow
> ourselves to strip it down. Any (categories of) packages we'd be thinking of
> specifically?
I would start with the @core comps group (even with a smaller set) and
then add groups of packages creating a server feature. This will build
the server platform from down will make possible to check the
dependencies and to validate whether the set works as expected.
+1
After all, "More with Less" is principle #1. :)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:09 p.m.
On Wed, 2010-09-01 at 12:39 -0400, Matthew Miller wrote:
On Wed, Sep 01, 2010 at 06:22:54PM +0200, Dan Horák wrote:
> > Fair enough. Let's suppose we take what is in EL as a basis, and allow
> > ourselves to strip it down. Any (categories of) packages we'd be thinking
of
> > specifically?
> I would start with the @core comps group (even with a smaller set) and
> then add groups of packages creating a server feature. This will build
> the server platform from down will make possible to check the
> dependencies and to validate whether the set works as expected.
+1
After all, "More with Less" is principle #1. :)
okay
http://skvidal.fedorapeople.org/misc/core-f14-resolved.txt
that's f14-core resolved into a bare chroot.
start there.
-sv
7:14 p.m.
On Wed, Sep 01, 2010 at 01:09:36PM -0400, seth vidal wrote:
> > I would start with the @core comps group (even with a
smaller set) and
> > then add groups of packages creating a server feature. This will build
> > the server platform from down will make possible to check the
> > dependencies and to validate whether the set works as expected.
> After all, "More with Less" is principle #1. :)
okay
http://skvidal.fedorapeople.org/misc/core-f14-resolved.txt
that's f14-core resolved into a bare chroot.
start there.
Cool. A few things strike me as potentially troublesome, like cairo, since
that's prone to update-requirements-to-suit-the-latest-desktop-things. But
paring down the list can happen over time.
How would this server branch interact with Fedora, um, core? Would we
configure both the server repo and the main repo, with the server repo set
to be a preferred source via yum crack^H^H^H^H^H magic?
From the repo compose side, presumably the packages would inherit from
the
corresponding main Fedora release, and be forked only if we need to change
them.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:24 p.m.
On Wed, 2010-09-01 at 20:14 -0400, Matthew Miller wrote:
On Wed, Sep 01, 2010 at 01:09:36PM -0400, seth vidal wrote:
> > > I would start with the @core comps group (even with a smaller set) and
> > > then add groups of packages creating a server feature. This will build
> > > the server platform from down will make possible to check the
> > > dependencies and to validate whether the set works as expected.
> > After all, "More with Less" is principle #1. :)
> okay
> http://skvidal.fedorapeople.org/misc/core-f14-resolved.txt
> that's f14-core resolved into a bare chroot.
> start there.
Cool. A few things strike me as potentially troublesome, like cairo, since
that's prone to update-requirements-to-suit-the-latest-desktop-things. But
paring down the list can happen over time.
How would this server branch interact with Fedora, um, core? Would we
configure both the server repo and the main repo, with the server repo set
to be a preferred source via yum crack^H^H^H^H^H magic?
>From the repo compose side, presumably the packages would inherit from the
corresponding main Fedora release, and be forked only if we need to change
them.
my opinion:
a server 'spin' is a ks file like:
install
lang en_US.utf8
keyboard us
url --url fillinurlhere
network --device eth0 --onboot no --bootproto dhcp --hostname localhost
firewall --disabled
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone --utc America/New_York
bootloader --location=mbr --driveorder=sda --append=""
%packages --nobase
@core
and let the admin do the rest.
If you want to get clever you make the inverse of a yum plugin like
'appmarket'. You prune out all the stuff that no server should ever have
near it from search results.
-sv
7:55 p.m.
On Wed, Sep 01, 2010 at 08:24:18PM -0400, seth vidal wrote:
my opinion:
a server 'spin' is a ks file like:
[...]
Really? 'Cause I was going with your "separate branch" idea....
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:29 p.m.
On Wed, 2010-09-01 at 20:55 -0400, Matthew Miller wrote:
On Wed, Sep 01, 2010 at 08:24:18PM -0400, seth vidal wrote:
> my opinion:
> a server 'spin' is a ks file like:
[...]
Really? 'Cause I was going with your "separate branch" idea....
I thought you were against it? From your posts to my blog you seemed
against it.
-sv
8:51 p.m.
New subject: server branch idea [was Re: Five basic principles ...]
On Wed, Sep 01, 2010 at 09:29:42PM -0400, seth vidal wrote:
> Really? 'Cause I was going with your "separate
branch" idea....
I thought you were against it? From your posts to my blog you seemed
against it.
Sorry, I didn't mean to sound entirely against it. Actually, I think the
idea answers a lot of questions nicely. (Like, not least of all, how can we
stop arguing and _get some cool stuff done_?)
But the idea of _aspiring_ to a common base is something I'd like to see as
a cornerstone of a server branch project [¹]. Where we need to deviate from
the main project, I'd rather be the kind of fork that says: we hope this can
all be merged together again soon.
Reasons for that can tie in nicely to the Fedora slogan -- freedom: yes we
can do this kind of thing; friends: it works best if we can work together as
a community, not as two separate projects; features: sure, we want cool
stuff in the server branch too, but we need to be more cautious, so we'll
move towards them more slowly; first: by keeping our use cases from being
blockers, we can let the main distro do more radical things more quickly,
and still probably get them before other server distributions.
Eehhhhh. Or something like that. :)
And of course, on a pragmatic level, the less we split, the less new work
there is to be done.
...
1. And in return I'd like to see some of the basic principles necessary for
that at least *recognized* as valuable by the broader project too.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
1:29 p.m.
Matthew Miller (mattdm(a)mattdm.org) said:
Cool. A few things strike me as potentially troublesome, like cairo,
since
that's prone to update-requirements-to-suit-the-latest-desktop-things. But
paring down the list can happen over time.
... the cairo that's shipped the same library ABI since Fedora Core 6? I'm
not trying to be too much of a smartass, but that seems a bit facetious.
Bill
2:05 p.m.
On Thu, Sep 02, 2010 at 02:29:27PM -0400, Bill Nottingham wrote:
> Cool. A few things strike me as potentially troublesome, like
cairo, since
> that's prone to update-requirements-to-suit-the-latest-desktop-things. But
> paring down the list can happen over time.
... the cairo that's shipped the same library ABI since Fedora Core 6? I'm
not trying to be too much of a smartass, but that seems a bit facetious.
Cairo seems to be a very well-run project, so I'm not terribly worried it
breaking things. But new versions have new API features, which desktop stuff
needs. And bugfix updates may be essential to the desktop, but we probably
don't care at all on the server. So if we have a common core, it's likely to
get updated more than we really would like -- avoiding updates altogether is
one of the reasons to keep the package list small.
Like I said, not urgent, but if we can remove it from the list, it's a win.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
2:17 p.m.
Matthew Miller (mattdm(a)mattdm.org) said:
> ... the cairo that's shipped the same library ABI since
Fedora Core 6? I'm
> not trying to be too much of a smartass, but that seems a bit facetious.
Cairo seems to be a very well-run project, so I'm not terribly worried it
breaking things. But new versions have new API features, which desktop stuff
needs. And bugfix updates may be essential to the desktop, but we probably
don't care at all on the server. So if we have a common core, it's likely to
get updated more than we really would like -- avoiding updates altogether is
one of the reasons to keep the package list small.
Perhaps, but given that it's only ever been updated once post-release since
Fedora 9, I'm not seeing that it's a huge deal. I suspect you'll get more
superfluous updates for SELinux features that are only tangentially related
to @core usage, for example.
Bill
5:16 p.m.
On Thu, Sep 02, 2010 at 03:17:46PM -0400, Bill Nottingham wrote:
Perhaps, but given that it's only ever been updated once
post-release since
Fedora 9, I'm not seeing that it's a huge deal. I suspect you'll get more
Okay, I retract. :)
superfluous updates for SELinux features that are only tangentially
related
to @core usage, for example.
*nod*
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
2:30 p.m.
On Thu, 2010-09-02 at 15:05 -0400, Matthew Miller wrote:
On Thu, Sep 02, 2010 at 02:29:27PM -0400, Bill Nottingham wrote:
> > Cool. A few things strike me as potentially troublesome, like cairo, since
> > that's prone to update-requirements-to-suit-the-latest-desktop-things. But
> > paring down the list can happen over time.
> ... the cairo that's shipped the same library ABI since Fedora Core 6? I'm
> not trying to be too much of a smartass, but that seems a bit facetious.
Cairo seems to be a very well-run project, so I'm not terribly worried it
breaking things. But new versions have new API features, which desktop stuff
needs. And bugfix updates may be essential to the desktop, but we probably
don't care at all on the server. So if we have a common core, it's likely to
get updated more than we really would like -- avoiding updates altogether is
one of the reasons to keep the package list small.
Like I said, not urgent, but if we can remove it from the list, it's a win.
Actually the culprit is dbus-glib, that requires gobject-introspection,
that requires cairo. cairo then pulls in bunch of other libraries
(libX11 etc.). So it would be actually really worth it to cut this
dependency chain somewhere.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
3:39 p.m.
Tomas Mraz (tmraz(a)redhat.com) said:
> Like I said, not urgent, but if we can remove it from the list,
it's a win.
Actually the culprit is dbus-glib, that requires gobject-introspection,
that requires cairo. cairo then pulls in bunch of other libraries
(libX11 etc.). So it would be actually really worth it to cut this
dependency chain somewhere.
Fixed in 0.9.3-6.fc15.
Bill
5:17 p.m.
On Thu, Sep 02, 2010 at 04:39:59PM -0400, Bill Nottingham wrote:
> Actually the culprit is dbus-glib, that requires
gobject-introspection,
> that requires cairo. cairo then pulls in bunch of other libraries
> (libX11 etc.). So it would be actually really worth it to cut this
> dependency chain somewhere.
Fixed in 0.9.3-6.fc15.
Yay! We're useful!
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
5:43 a.m.
Dne 1.9.2010 19:09, seth vidal napsal(a):
On Wed, 2010-09-01 at 12:39 -0400, Matthew Miller wrote:
> On Wed, Sep 01, 2010 at 06:22:54PM +0200, Dan Horák wrote:
>>> Fair enough. Let's suppose we take what is in EL as a basis, and allow
>>> ourselves to strip it down. Any (categories of) packages we'd be thinking
of
>>> specifically?
>> I would start with the @core comps group (even with a smaller set) and
>> then add groups of packages creating a server feature. This will build
>> the server platform from down will make possible to check the
>> dependencies and to validate whether the set works as expected.
>
> +1
>
> After all, "More with Less" is principle #1. :)
I'd like to see a
versatile distro with sane deps rather than
maintaining another branches.
okay
http://skvidal.fedorapeople.org/misc/core-f14-resolved.txt
that's f14-core resolved into a bare chroot.
start there.
-sv
I started with packages required for almost any installation.
It's only few packages, but it doesn't make sense to move further until
at least some of these issues get fixed.
Goal is to remove dependency cycles and keep deps sane so any user can
select packages for his system (regardless it's server or desktop).
filesystem requires setup
- either remove this dep, or reverse it
(dirs get installed first, files after)
basesystem
- empty, only requires filesystem and setup
- is it really needed at all?
fedora-release
- ok
tzdata
- ok
libgcc
- ok
glibc
- glibc-common requires bash due to:
- /usr/bin/catchsegv (/bin/sh)
- /usr/bin/tzselect (/bin/bash)
- is rewrite to C possible?
e2fsprogs
- requires only couple libs
- probably not needed, but recommended for most installations
nss-softokn-freebl - glibc dependency cycle
- probably ok
coreutils - pam dependency cycle
- need to break it if possible
- pulls a lot of another crap
- selinux libs come into play here
pam - passwd dependency cycle
- need to break it if possible
udev - initscripts dependency cycle
- need to break it if possible
pam
- requires bash:
- /etc/security/namespace.init (/bin/sh)
- dlopen.sh in SRPM
- is rewrite to C possible?
some non-leaf packages with sane deps
zlib, popt, pcre
--
Daniel Mach <dmach(a)redhat.com>
Release Engineering, Red Hat
6:51 a.m.
New subject: reducing 'base' [was Re: Five basic principles ...]
On Thu, Sep 02, 2010 at 12:43:53PM +0200, Daniel Mach wrote:
>> After all, "More with Less" is principle #1. :)
I'd like to see a versatile distro with sane deps rather than
maintaining another branches.
I'd like to explore the idea at least as a thought-experiment for a little
bit further. More on that later today.
I started with packages required for almost any installation.
It's only few packages, but it doesn't make sense to move further until
at least some of these issues get fixed.
Goal is to remove dependency cycles and keep deps sane so any user can
select packages for his system (regardless it's server or desktop).
This is a valuable goal no matter what we do, and not just for server. Maybe
cc the fedora-mini list?
glibc
- glibc-common requires bash due to:
- /usr/bin/catchsegv (/bin/sh)
- /usr/bin/tzselect (/bin/bash)
- is rewrite to C possible?
If it's just those two programs, yeah. File bugs. A rewrite isn't the only
option, though -- there's no real reason for these particular scripts to be
in this package. (That may go for some of the other binaries in glibc-common
too.)
e2fsprogs
- requires only couple libs
- probably not needed, but recommended for most installations
I think we need e2fsck at boot time. There's no good way to introduce a dep
based on what filesystems are in use. (And, in any case, we've got lsattr
and chattr here.)
coreutils - pam dependency cycle
- need to break it if possible
- pulls a lot of another crap
- selinux libs come into play here
Pretty sure we're not booting without this. What's the other crap that gets
pulled in?
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:19 a.m.
New subject: reducing 'base' [was Re: Five basic principles ...]
Dne 2.9.2010 13:51, Matthew Miller napsal(a):
On Thu, Sep 02, 2010 at 12:43:53PM +0200, Daniel Mach wrote:
>>> After all, "More with Less" is principle #1. :)
> I'd like to see a versatile distro with sane deps rather than
> maintaining another branches.
I'd like to explore the idea at least as a thought-experiment for a little
bit further. More on that later today.
> I started with packages required for almost any installation.
> It's only few packages, but it doesn't make sense to move further until
> at least some of these issues get fixed.
> Goal is to remove dependency cycles and keep deps sane so any user can
> select packages for his system (regardless it's server or desktop).
This is a valuable goal no matter what we do, and not just for server. Maybe
cc the fedora-mini list?
Not sure. They have similar, but not the same goal.
> glibc
> - glibc-common requires bash due to:
> - /usr/bin/catchsegv (/bin/sh)
> - /usr/bin/tzselect (/bin/bash)
> - is rewrite to C possible?
If it's just those two programs, yeah. File bugs. A rewrite isn't the only
option, though -- there's no real reason for these particular scripts to be
in this package. (That may go for some of the other binaries in glibc-common
too.)
> e2fsprogs
> - requires only couple libs
> - probably not needed, but recommended for most installations
I think we need e2fsck at boot time. There's no good way to introduce a dep
based on what filesystems are in use. (And, in any case, we've got lsattr
and chattr here.)
> coreutils - pam dependency cycle
> - need to break it if possible
> - pulls a lot of another crap
> - selinux libs come into play here
Pretty sure we're not booting without this. What's the other crap that gets
pulled in?
Hmm, I took a look and it's not that bad, actually.
I've filed a bug to get rid of less package:
https://bugzilla.redhat.com/show_bug.cgi?id=629580
9:48 a.m.
On Thu, 2010-09-02 at 12:43 +0200, Daniel Mach wrote:
I'd like to see a versatile distro with sane deps rather than
maintaining another branches.
by sane, it seems like you mean 'reduced to an ABSOLUTE minimum rather
than some not-quite-required-but-useful-to-have' which is what we end up
with now. IS that right?
I started with packages required for almost any installation.
It's only few packages, but it doesn't make sense to move further until
at least some of these issues get fixed.
Goal is to remove dependency cycles and keep deps sane so any user can
select packages for his system (regardless it's server or desktop).
well, unless we change something in anaconda it is installing @core no
matter what.
so the best we could do with f14, for example is:
acl
attr
audit
authconfig
basesystem
bash
coreutils
cpio
cronie
cronie-anacron
dhclient
e2fsprogs
fedora-release
file
filesystem
glibc
initscripts
iproute
iprutils
iptables
iptables-ipv6
iputils
kbd
libgcc
ncurses
openssh-server
passwd
policycoreutils
procps
readline
rootfiles
rpm
rpmfusion-free-release
rsyslog
selinux-policy-targeted
setserial
setup
shadow-utils
sudo
util-linux-ng
vim-minimal
yum
efibootmgr
grub
ppc64-utils
s390utils
sendmail
silo
yaboot
Now - I've installed @core and then stripped more stuff out on vms I've
deployed - it's not hard - but a kickstart config would have to DO that.
filesystem requires setup
- either remove this dep, or reverse it
(dirs get installed first, files after)
but look at the files in setup. it's most of the critical items in /etc/
basesystem
- empty, only requires filesystem and setup
- is it really needed at all?
It seems like it is related to glibc - since glibc requires it - but I'm
not at all sure _why_ - definitely worth asking.
pam - passwd dependency cycle
- need to break it if possible
why? I'm not sure I understand the goal
udev - initscripts dependency cycle
- need to break it if possible
why? Ditto.
-sv
10:05 a.m.
Dne 2.9.2010 16:48, seth vidal napsal(a):
On Thu, 2010-09-02 at 12:43 +0200, Daniel Mach wrote:
> I'd like to see a versatile distro with sane deps rather than
> maintaining another branches.
by sane, it seems like you mean 'reduced to an ABSOLUTE minimum rather
than some not-quite-required-but-useful-to-have' which is what we end up
with now. IS that right?
Correct.
"Useful-to-have" deps can be covered by recommended installation sets in
comps or deps-only packages.
>
>
> I started with packages required for almost any installation.
> It's only few packages, but it doesn't make sense to move further until
> at least some of these issues get fixed.
> Goal is to remove dependency cycles and keep deps sane so any user can
> select packages for his system (regardless it's server or desktop).
>
well, unless we change something in anaconda it is installing @core no
matter what.
so the best we could do with f14, for example is:
acl
attr
audit
authconfig
unfortunately required by anaconda
never used authconfig on single-user desktop or on my home server
basesystem
bash
coreutils
cpio
cronie
cronie-anacron
cronie-noanacron is more suitable for server
dhclient
e2fsprogs
fedora-release
file
filesystem
glibc
initscripts
iproute
iprutils
iptables
iptables-ipv6
iputils
kbd
libgcc
ncurses
openssh-server
not needed, but useful
passwd
policycoreutils
procps
readline
rootfiles
rpm
rpmfusion-free-release
we need more of these :)
rsyslog
selinux-policy-targeted
setserial
setup
shadow-utils
sudo
also not needed, but (for me) must have on server
util-linux-ng
vim-minimal
yum
efibootmgr
grub
ppc64-utils
s390utils
sendmail
or postfix / ssmtp
silo
yaboot
Now - I've installed @core and then stripped more stuff out on vms I've
deployed - it's not hard - but a kickstart config would have to DO that.
Yep,
kickstart can do that.
BTW, I usually don't use neither anaconda gui or kickstarts, but
bootstrap a flash disk and use yum install --installroot to setup a
running system. Not a big deal, packages do not need setup usually.
>
> filesystem requires setup
> - either remove this dep, or reverse it
> (dirs get installed first, files after)
>
but look at the files in setup. it's most of the critical items in /etc/
Yep, I
know, but filesystem provides /etc so it makes sense to install
it first. (Maybe I'm too paranoid here)
> basesystem
> - empty, only requires filesystem and setup
> - is it really needed at all?
It seems like it is related to glibc - since glibc requires it - but I'm
not at all sure _why_ - definitely worth asking.
>
> pam - passwd dependency cycle
> - need to break it if possible
why? I'm not sure I understand the goal
> udev - initscripts dependency cycle
> - need to break it if possible
why? Ditto.
To make installer's life easier and to make sure all packages
require
only what they need?
On the other you're right.
Udev has to be executed before most other init scripts.
It also requires initscripts to get started.
-sv
10:32 a.m.
On Thu, 2010-09-02 at 12:43 +0200, Daniel Mach wrote:
coreutils - pam dependency cycle
- need to break it if possible
- pulls a lot of another crap
- selinux libs come into play here
The dependency cycle on pam is not at all
artificial. It is really how
these packages depend on each other. It could be removed only by
splitting out some coreutils into a subpackage that would contain the
tools that require pam (these tools are not needed by the pam post
scripts).
pam - passwd dependency cycle
- need to break it if possible
I don't see the cycle here, can you please
enlighten me?
pam
- requires bash:
- /etc/security/namespace.init (/bin/sh)
- dlopen.sh in SRPM
- is rewrite to C possible?
Nope - that does not make any sense. Also note,
that it
requires /bin/sh. Do we really want to drop a requirement for
bourne-compatible shell from all the core packages?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
1:25 p.m.
seth vidal (skvidal(a)fedoraproject.org) said:
> 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?
That appears to define that there should *never* be core churn. To cherry-pick
examples at random, that means:
- we never add yum?
- we never introduce PAM?
- we never add sssd?
- we never switch to udev?
- we never switch from ipchains to iptables?
- we never switch from ext2 to ext3 to ext4?
- we never switch from sysklogd to rsyslog?
Obviously, some of those are pretty old. But at the time, they were the
same sort of large-scale changes that affect the way the system operates,
affects the commands an administrator might use, and affects the
configuration files that would need to be edited. I understand being averse
to large scale change, but this seems to be
skewing against our listed Foundations:
...
Features represents our commitment to excellence. The Fedora community
creates many of the technical features that have made Linux powerful,
flexible, and usable for a wide spectrum of millions of users,
administrators, and developers worldwide. We recognize the status quo is
worth changing when the potential gain is to empower additional end-users,
or create a more flexible and powerful environment for building new
solutions on the free software we provide.
...
Bill
2:09 p.m.
On Thu, Sep 2, 2010 at 12:25, Bill Nottingham <notting(a)redhat.com> wrote:
seth vidal (skvidal(a)fedoraproject.org) said:
> > 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?
That appears to define that there should *never* be core churn. To cherry-pick
examples at random, that means:
- we never add yum?
- we never introduce PAM?
- we never add sssd?
- we never switch to udev?
- we never switch from ipchains to iptables?
- we never switch from ext2 to ext3 to ext4?
- we never switch from sysklogd to rsyslog?
How many of these were done in an active release? EG did we switch
from ext2 -> ext3 in the middle of 6.1 or did we wait til 6.1 for it
to happen? Did PAM etc show up in the middle of a release cycle or at
the beginning? etc etc.
My recollection is probably wrong but I thought they were usually
major things at the beginning of a release cycle. Or if they were not
that existing systems didn't break (eg ext2 -> ext3 on a rpm -Uvh ).
That is how I took BETWEEN to mean. So glibc does not go from 2.11 ->
2.12 in the middle of a release.
On the other hand, the amount of wailing and gnashing of teeth and
great revolts of people leaving Fedora because of systemd has no where
reached the level that say PAM integration did or the libc4 -> libc5
change did.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
3:56 p.m.
On Tue, 2010-08-31 at 15:44 -0400, Matthew Miller wrote:
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.
Matt,
I'd also like to quote from a blogpost about gnome-os and gnome3:
"What lies underneath is mostly just implementation detail. What matters
is what we expose to the user and the developer. I propose that we take
notes from Android, WebOS, Meego, and others and consider Linux an
implementation detail and start to define the OS as we see fit."
That's from
http://blogs.gnome.org/mccann/2010/08/01/shell-yes/
how do you reconcile #3 there with that?
b/c I am having a difficult time doing that.
-sv
4:12 p.m.
On Tue, Aug 31, 2010 at 04:56:21PM -0400, seth vidal wrote:
> 3. Fedora is Unix-like
[...]
I'd also like to quote from a blogpost about gnome-os and
gnome3:
"What lies underneath is mostly just implementation detail. What matters
is what we expose to the user and the developer. I propose that we take
notes from Android, WebOS, Meego, and others and consider Linux an
implementation detail and start to define the OS as we see fit."
That's from
http://blogs.gnome.org/mccann/2010/08/01/shell-yes/
how do you reconcile #3 there with that?
b/c I am having a difficult time doing that.
Is there something more to that post then conflation of a desktop
environment with an "OS"? There's multiple places where one can draw the
line, from "only the kernel is the OS" all the way up to this view. But
fundamentally, here, Gnome shell or whatever is just a fancy application
stack running on top of something else.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
4:55 p.m.
On Tue, 2010-08-31 at 17:12 -0400, Matthew Miller wrote:
On Tue, Aug 31, 2010 at 04:56:21PM -0400, seth vidal wrote:
> > 3. Fedora is Unix-like
[...]
> I'd also like to quote from a blogpost about gnome-os and gnome3:
>
> "What lies underneath is mostly just implementation detail. What matters
> is what we expose to the user and the developer. I propose that we take
> notes from Android, WebOS, Meego, and others and consider Linux an
> implementation detail and start to define the OS as we see fit."
>
> That's from
>
> http://blogs.gnome.org/mccann/2010/08/01/shell-yes/
>
> how do you reconcile #3 there with that?
>
> b/c I am having a difficult time doing that.
Is there something more to that post then conflation of a desktop
environment with an "OS"? There's multiple places where one can draw the
line, from "only the kernel is the OS" all the way up to this view. But
fundamentally, here, Gnome shell or whatever is just a fancy application
stack running on top of something else.
And all the intervening layers required to get there.
-sv
11:37 p.m.
On Tue, 2010-08-31 at 17:55 -0400, seth vidal wrote:
On Tue, 2010-08-31 at 17:12 -0400, Matthew Miller wrote:
> On Tue, Aug 31, 2010 at 04:56:21PM -0400, seth vidal wrote:
> > > 3. Fedora is Unix-like
> [...]
> > I'd also like to quote from a blogpost about gnome-os and gnome3:
> >
> > "What lies underneath is mostly just implementation detail. What matters
> > is what we expose to the user and the developer. I propose that we take
> > notes from Android, WebOS, Meego, and others and consider Linux an
> > implementation detail and start to define the OS as we see fit."
> >
> > That's from
> >
> > http://blogs.gnome.org/mccann/2010/08/01/shell-yes/
> >
> > how do you reconcile #3 there with that?
> >
> > b/c I am having a difficult time doing that.
>
> Is there something more to that post then conflation of a desktop
> environment with an "OS"? There's multiple places where one can draw
the
> line, from "only the kernel is the OS" all the way up to this view. But
> fundamentally, here, Gnome shell or whatever is just a fancy application
> stack running on top of something else.
And all the intervening layers required to get there.
There's one *giant problem* with that blog post. All of the examples
refer to non-general purpose Operating Systems intended for specific use
cases, such as cellphone or a web tablet. If I wanted Fedora to be just
for my cellphone or for an iPad on my desk, I'd stab my eyes out right
now and be done with it. Yes, those other OSes can take for granted that
they're supplying everything (and they do a very good job at coherence,
managing upgrades, user experience, all the things not happening here),
but we could do just as well having a stable, cohesive core platform.
Jon.
4983
days inactive
4985
days old
server@lists.fedoraproject.org
35 comments
10 participants
participants (10)
-
Bill Nottingham -
Dan Horák -
Daniel Mach -
Jeroen van Meeuwen -
Jon Masters -
Leam Hall -
Matthew Miller -
Seth Vidal -
Stephen John Smoogen -
Tomas Mraz