On Tuesday, 31 August 2010 at 11:35, Leam Hall wrote:
Long term support would be very useful, as would:
1. Minimal OS build that fit onto one CD per ARCH.
a. That build allowed ssh, vi, yum, and networking so updates and adds
b. That build had a kernel that was less full. Most servers don't use
Bluetooth, for example.
A quick idea: join the kernel maintainers team and create
a kernel-server subpackage with a minimal config.
2. Application packages that installed in FHS compliant application
filesystems vice OS filesystems. For example, apachectl should not be in
/usr/sbin but /opt/httpd/sbin or something similar. Logs should go in
Um, no. There are reasons why we don't package anything in /opt.
a. Those filesystems, like "/opt" and /srv", should
b. Applications that fill up their own space do not crash the server.
I think you've just reinvented quotas, badly.
c. Applications can be backed-up seperately from the OS and then
quickly in case of disaster recovery or server consolidation.
With rpm packages you don't need to back-up the applications, only
configuration files, data and logs. Installing applications in separate
directory trees doesn't improve the situation a lot.
3. Base OS packages that needed very little outside what was in the
a. There would probably be multiple levels of inclusion. For example,
Python should not be in the base OS but should be one of the first tools
A rephrasing of 1.a.?
b. Editor and other religious wars would favor Unix-common
4. Documentation that favored command line solutions vice GUI tools.
Well, someone needs to write that documentation.
To be honest, I'm not sure how much work this would entail and
there are things to correct or add in my list. What I would suggest is
that we take the small subset mentioned earlier and use F12 or F13 as a
proof of concept. The real target should be F15 or F16; by then we
should have enough practice to build the base OS and enough credibility
to convince the Project Leader to include our efforts.
I think the low-hanging fruit is working on reducing package
interdependencies. There's an ongoing effort, which is and will be of
benefit to both Server and Mini SIGs.
Interestingly, I can see one advantage Fedora-Server would have over
something like CentOS; more frequent critical OS updates would allow
usage in secure environments where latest kernel and other security
patches must be applied soon after their availability.
RHEL solves that by backporting. We can't and won't do that due to
lack of manpower, so yes, it can be seen as an advantage.
On the other hand, new versions sometimes come with new bugs,
so I wouldn't push the "enterprise" angle too much. :)
| MPlayer http://mplayerhq.hu
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"