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.
On Tue, 2010-08-31 at 15:44 -0400, Matthew Miller wrote:
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*
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?
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?
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
On Tue, Aug 31, 2010 at 04:33:25PM -0400, seth vidal wrote:
- 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.
- 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.
- 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.
- 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.GA102...
(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 wrote:
On Tue, Aug 31, 2010 at 04:33:25PM -0400, seth vidal wrote:
- 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
On Tue, 2010-08-31 at 16:33 -0400, seth vidal wrote:
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.
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.
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
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 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
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
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. :)
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
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.
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
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....
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
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@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
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@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
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*
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 (tmraz@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
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!
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
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?
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
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
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 yabootNow - 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
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?
seth vidal (skvidal@fedoraproject.org) said:
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
On Thu, Sep 2, 2010 at 12:25, Bill Nottingham notting@redhat.com wrote:
seth vidal (skvidal@fedoraproject.org) said:
- 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.
On Tue, 2010-08-31 at 15:44 -0400, Matthew Miller wrote:
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
On Tue, Aug 31, 2010 at 04:56:21PM -0400, seth vidal wrote:
- 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.
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:
- 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
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:
- 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.
server@lists.fedoraproject.org
-
Bill Nottingham -
Dan Horák -
Daniel Mach -
Jeroen van Meeuwen -
Jon Masters -
Leam Hall -
Matthew Miller -
Seth Vidal -
Stephen John Smoogen -
Tomas Mraz